From: Tomasz Figa <tfiga@chromium.org>
To: Nicolas Dufresne <nicolas@ndufresne.ca>
Cc: "Hans Verkuil" <hverkuil@xs4all.nl>,
"Linux Media Mailing List" <linux-media@vger.kernel.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Mauro Carvalho Chehab" <mchehab@kernel.org>,
"Paweł Ościak" <posciak@chromium.org>,
"Alexandre Courbot" <acourbot@chromium.org>,
"Kamil Debski" <kamil@wypas.org>,
"Andrzej Hajda" <a.hajda@samsung.com>,
"Kyungmin Park" <kyungmin.park@samsung.com>,
"Jeongtae Park" <jtp.park@samsung.com>,
"Philipp Zabel" <p.zabel@pengutronix.de>,
"Tiffany Lin" <tiffany.lin@mediatek.com>,
"Andrew-CT Chen" <andrew-ct.chen@mediatek.com>,
"Stanimir Varbanov" <stanimir.varbanov@linaro.org>,
"Todor Tomov" <todor.tomov@linaro.org>,
"Paul Kocialkowski" <paul.kocialkowski@bootlin.com>,
"Laurent Pinchart" <laurent.pinchart@ideasonboard.com>,
dave.stevenson@raspberrypi.org,
"Ezequiel Garcia" <ezequiel@collabora.com>,
"Maxime Jourdan" <maxi.jourdan@wanadoo.fr>
Subject: Re: [PATCH v2 2/2] media: docs-rst: Document memory-to-memory video encoder interface
Date: Fri, 25 Jan 2019 12:29:11 +0900 [thread overview]
Message-ID: <CAAFQd5DXWc1mBYZ=2zH0fPitLc=L2UGem85wokB6oht4CxVrsQ@mail.gmail.com> (raw)
In-Reply-To: <ea1b39bf1a14f73b74d17c925f67ea3613ea6eae.camel@ndufresne.ca>
On Fri, Jan 25, 2019 at 5:04 AM Nicolas Dufresne <nicolas@ndufresne.ca> wrote:
>
> Le mercredi 23 janvier 2019 à 12:28 +0100, Hans Verkuil a écrit :
> > On 01/23/19 11:00, Tomasz Figa wrote:
> > > On Sat, Nov 17, 2018 at 8:37 PM Hans Verkuil <hverkuil@xs4all.nl> wrote:
> > > > On 11/17/2018 05:18 AM, Nicolas Dufresne wrote:
> > > > > Le lundi 12 novembre 2018 à 14:23 +0100, Hans Verkuil a écrit :
> > > > > > On 10/22/2018 04:49 PM, Tomasz Figa wrote:
> > > [snip]
> > > > > > > + rely on it. The ``V4L2_BUF_FLAG_LAST`` buffer flag should be used
> > > > > > > + instead.
> > > > > >
> > > > > > Question: should new codec drivers still implement the EOS event?
> > > > >
> > > > > I'm been asking around, but I think here is a good place. Do we really
> > > > > need the FLAG_LAST in userspace ? Userspace can also wait for the first
> > > > > EPIPE return from DQBUF.
> > > >
> > > > I'm interested in hearing Tomasz' opinion. This flag is used already, so there
> > > > definitely is a backwards compatibility issue here.
> > > >
> > >
> > > FWIW, it would add the overhead of 1 more system call, although I
> > > don't think it's of our concern.
> > >
> > > My personal feeling is that using error codes for signaling normal
> > > conditions isn't very elegant, though.
> >
> > I agree. Let's keep this flag.
>
> Agreed, though a reminder of the initial question, "do we keep the EOS
> event ?", and I think the event can be dropped.
>
I would happily drop it, if we know that it wouldn't break any
userspace. Chromium doesn't use it either.
Best regards,
Tomasz
> >
> > Regards,
> >
> > Hans
> >
> > > > > > > +
> > > > > > > +3. Once all ``OUTPUT`` buffers queued before the ``V4L2_ENC_CMD_STOP`` call and
> > > > > > > + the last ``CAPTURE`` buffer are dequeued, the encoder is stopped and it will
> > > > > > > + accept, but not process any newly queued ``OUTPUT`` buffers until the client
> > > > > > > + issues any of the following operations:
> > > > > > > +
> > > > > > > + * ``V4L2_ENC_CMD_START`` - the encoder will resume operation normally,
> > > > > >
> > > > > > Perhaps mention that this does not reset the encoder? It's not immediately clear
> > > > > > when reading this.
> > > > >
> > > > > Which drivers supports this ? I believe I tried with Exynos in the
> > > > > past, and that didn't work. How do we know if a driver supports this or
> > > > > not. Do we make it mandatory ? When it's not supported, it basically
> > > > > mean userspace need to cache and resend the header in userspace, and
> > > > > also need to skip to some sync point.
> > > >
> > > > Once we agree on the spec, then the next step will be to add good compliance
> > > > checks and update drivers that fail the tests.
> > > >
> > > > To check if the driver support this ioctl you can call VIDIOC_TRY_ENCODER_CMD
> > > > to see if the functionality is supported.
> > >
> > > There is nothing here for the hardware to support. It's an entirely
> > > driver thing, since it just needs to wait for the encoder to complete
> > > all the pending frames and stop enqueuing more frames to the decoder
> > > until V4L2_ENC_CMD_START is called. Any driver that can't do it must
> > > be fixed, since otherwise you have no way to ensure that you got all
> > > the encoded output.
> > >
> > > Best regards,
> > > Tomasz
> > >
>
next prev parent reply other threads:[~2019-01-25 3:29 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-22 14:48 [PATCH v2 0/2] Document memory-to-memory video codec interfaces Tomasz Figa
2018-10-22 14:48 ` [PATCH v2 1/2] media: docs-rst: Document memory-to-memory video decoder interface Tomasz Figa
2018-10-29 9:45 ` Stanimir Varbanov
2018-10-29 10:06 ` Tomasz Figa
2018-10-29 10:07 ` Tomasz Figa
2018-11-12 11:37 ` Hans Verkuil
2019-01-22 10:02 ` Tomasz Figa
2019-01-22 14:47 ` Hans Verkuil
2019-01-23 5:27 ` Tomasz Figa
2019-01-23 8:10 ` Hans Verkuil
2019-01-24 9:06 ` Tomasz Figa
2019-01-24 19:55 ` Nicolas Dufresne
2019-01-25 3:27 ` Tomasz Figa
2019-01-30 4:02 ` Nicolas Dufresne
2019-02-06 5:35 ` Tomasz Figa
2019-04-09 9:47 ` Tomasz Figa
2019-04-10 9:26 ` Hans Verkuil
2018-11-12 15:04 ` Stanimir Varbanov
2018-11-15 14:34 ` Hans Verkuil
2018-11-17 4:31 ` Nicolas Dufresne
2018-11-17 11:43 ` Hans Verkuil
2018-11-18 1:25 ` Nicolas Dufresne
2018-10-22 14:49 ` [PATCH v2 2/2] media: docs-rst: Document memory-to-memory video encoder interface Tomasz Figa
2018-11-12 13:23 ` Hans Verkuil
2018-11-17 4:18 ` Nicolas Dufresne
2018-11-17 11:37 ` Hans Verkuil
2018-11-18 1:34 ` Nicolas Dufresne
2019-01-23 10:02 ` Tomasz Figa
2019-01-24 20:02 ` Nicolas Dufresne
2019-01-23 10:00 ` Tomasz Figa
2019-01-23 11:28 ` Hans Verkuil
2019-01-24 20:04 ` Nicolas Dufresne
2019-01-25 3:29 ` Tomasz Figa [this message]
2019-01-23 9:52 ` Tomasz Figa
2019-01-23 13:04 ` Hans Verkuil
2019-01-24 20:14 ` Nicolas Dufresne
2019-01-25 3:59 ` Tomasz Figa
2019-01-30 15:06 ` Nicolas Dufresne
2019-02-06 5:49 ` Tomasz Figa
2018-10-22 15:41 ` [PATCH v2 0/2] Document memory-to-memory video codec interfaces Hans Verkuil
2018-10-23 0:54 ` Tomasz Figa
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='CAAFQd5DXWc1mBYZ=2zH0fPitLc=L2UGem85wokB6oht4CxVrsQ@mail.gmail.com' \
--to=tfiga@chromium.org \
--cc=a.hajda@samsung.com \
--cc=acourbot@chromium.org \
--cc=andrew-ct.chen@mediatek.com \
--cc=dave.stevenson@raspberrypi.org \
--cc=ezequiel@collabora.com \
--cc=hverkuil@xs4all.nl \
--cc=jtp.park@samsung.com \
--cc=kamil@wypas.org \
--cc=kyungmin.park@samsung.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=maxi.jourdan@wanadoo.fr \
--cc=mchehab@kernel.org \
--cc=nicolas@ndufresne.ca \
--cc=p.zabel@pengutronix.de \
--cc=paul.kocialkowski@bootlin.com \
--cc=posciak@chromium.org \
--cc=stanimir.varbanov@linaro.org \
--cc=tiffany.lin@mediatek.com \
--cc=todor.tomov@linaro.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).