linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexandre Courbot <acourbot@chromium.org>
To: Tomasz Figa <tfiga@chromium.org>,
	Paul Kocialkowski <paul.kocialkowski@bootlin.com>,
	Maxime Ripard <maxime.ripard@bootlin.com>,
	Hans Verkuil <hverkuil@xs4all.nl>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Pawel Osciak <posciak@chromium.org>,
	Linux Media Mailing List <linux-media@vger.kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3] media: docs-rst: Document m2m stateless video decoder interface
Date: Wed, 13 Feb 2019 14:58:32 +0900	[thread overview]
Message-ID: <CAPBb6MUDK0s665wjSjvo3ZePtmFXFrs2WqpaywOSjnRxp08Ong@mail.gmail.com> (raw)
In-Reply-To: <20190213055317.192029-1-acourbot@chromium.org>

On Wed, Feb 13, 2019 at 2:53 PM Alexandre Courbot <acourbot@chromium.org> wrote:
> [snip]
> +Buffers used as reference frames can be queued back to the ``CAPTURE`` queue as
> +soon as all the frames they are affecting have been queued to the ``OUTPUT``
> +queue. The driver will refrain from using the reference buffer as a decoding
> +target until all the frames depending on it are decoded.

Just want to highlight this part in order to make sure that this is
indeed what we agreed on. The recent changes to vb2_find_timestamp()
suggest this, but maybe I misunderstood the intent. It makes the
kernel responsible for tracking referenced buffers and not using them
until all the dependent frames are decoded, something the client could
also do.

Thanks!
Alex.

  reply	other threads:[~2019-02-13  5:58 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-13  5:53 [PATCH v3] media: docs-rst: Document m2m stateless video decoder interface Alexandre Courbot
2019-02-13  5:58 ` Alexandre Courbot [this message]
2019-02-13  8:59   ` Hans Verkuil
2019-02-13  9:20     ` Paul Kocialkowski
2019-02-13  9:57       ` Hans Verkuil
2019-02-13 11:04         ` Paul Kocialkowski
2019-02-26  3:33           ` Alexandre Courbot
2019-02-28 10:14             ` Hans Verkuil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPBb6MUDK0s665wjSjvo3ZePtmFXFrs2WqpaywOSjnRxp08Ong@mail.gmail.com \
    --to=acourbot@chromium.org \
    --cc=hverkuil@xs4all.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=maxime.ripard@bootlin.com \
    --cc=mchehab@kernel.org \
    --cc=paul.kocialkowski@bootlin.com \
    --cc=posciak@chromium.org \
    --cc=tfiga@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).