From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: javier Martin <javier.martin@vista-silicon.com>
Cc: Sylwester Nawrocki <snjw23@gmail.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
linux-media@vger.kernel.org, hverkuil@xs4all.nl,
kyungmin.park@samsung.com, shawn.guo@linaro.org,
richard.zhao@linaro.org, fabio.estevam@freescale.com,
kernel@pengutronix.de, s.hauer@pengutronix.de,
r.schwebel@pengutronix.de, Pawel Osciak <p.osciak@gmail.com>
Subject: Re: MEM2MEM devices: how to handle sequence number?
Date: Tue, 3 Jan 2012 15:00:22 +0100 [thread overview]
Message-ID: <201201031500.23732.laurent.pinchart@ideasonboard.com> (raw)
In-Reply-To: <CACKLOr3gc9o7JYzG+rV9Mp9C7xtgf0Q5W7vgxQ5H8wQDvO-ong@mail.gmail.com>
Hi Javier,
On Monday 02 January 2012 12:44:08 javier Martin wrote:
> Just one more question about this.
>
> The v4l2 encoder, which is the last element in my processing chain, is
> an H.264 encoder that has to know about previous frames to encode.
> For these kind of devices it is very useful to know whether a frame
> has been lost to introduce a skip frame and improve the encoding
> process.
>
> But, with the current approach we don't have any way to communicate
> this to the device.
>
> One option would be that the user specified a sequence number when
> issuing VIDIOC_QBUF at the output queue so that the device could
> detect any discontinuity and introduce a skip frame. But this would
> break your rule that sequence number introduced at the output queue
> has to be ignored by the driver.
That's a use case I haven't thought about. Using sequence numbers could indeed
help in that case. My concern is that most (if not all) applications don't set
the sequence number before queuing a buffer, so requiring them to do so could
introduce breakages. This could be limited to H.264 encoders (or more
generally codecs) though.
Another option would be to queue a 0-bytes frame. That might be a bit hackish
though.
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2012-01-03 14:00 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-22 14:34 MEM2MEM devices: how to handle sequence number? javier Martin
2011-12-23 7:09 ` Marek Szyprowski
2011-12-23 11:28 ` Laurent Pinchart
2011-12-23 11:35 ` Marek Szyprowski
2011-12-23 11:54 ` Laurent Pinchart
2011-12-23 15:55 ` Sylwester Nawrocki
2011-12-25 21:19 ` Laurent Pinchart
2012-01-02 10:22 ` javier Martin
2012-01-02 11:06 ` Laurent Pinchart
2012-01-02 11:44 ` javier Martin
2012-01-03 14:00 ` Laurent Pinchart [this message]
2011-12-23 11:57 ` Andy Walls
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=201201031500.23732.laurent.pinchart@ideasonboard.com \
--to=laurent.pinchart@ideasonboard.com \
--cc=fabio.estevam@freescale.com \
--cc=hverkuil@xs4all.nl \
--cc=javier.martin@vista-silicon.com \
--cc=kernel@pengutronix.de \
--cc=kyungmin.park@samsung.com \
--cc=linux-media@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=p.osciak@gmail.com \
--cc=r.schwebel@pengutronix.de \
--cc=richard.zhao@linaro.org \
--cc=s.hauer@pengutronix.de \
--cc=shawn.guo@linaro.org \
--cc=snjw23@gmail.com \
/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