From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: "'javier Martin'" <javier.martin@vista-silicon.com>,
linux-media@vger.kernel.org, s.nawrocki@samsung.com,
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: Fri, 23 Dec 2011 12:28:44 +0100 [thread overview]
Message-ID: <201112231228.45439.laurent.pinchart@ideasonboard.com> (raw)
In-Reply-To: <013f01ccc141$cdf78ed0$69e6ac70$%szyprowski@samsung.com>
Hi Marek,
On Friday 23 December 2011 08:09:25 Marek Szyprowski wrote:
> On Thursday, December 22, 2011 3:34 PM Javier Martin wrote:
> > we have a processing chain composed of three v4l2 devices:
> >
> > --------------------- -----------------------
> > ----------------------
> >
> > | v4l2 source | | v4l2 fixer | | v4l2
> > | encoder |
> > |
> > | (capture) |---------->| (mem2mem)| ------------>| (mem2mem) |
> >
> > ------------>
> >
> > |___________| |____________| |____________|
> >
> > "v4l2 source" generates consecutive sequence numbers so that we can
> > detect whether a frame has been lost or not.
> > "v4l2 fixer" and "v4l2 encoder" cannot lose frames because they don't
> > interact with an external sensor.
> >
> > How should "v4l2 fixer" and "v4l2 encoder" behave regarding frame
> > sequence number? Should they just copy the sequence number from the
> > input buffer to the output buffer or should they maintain their own
> > count for the CAPTURE queue?
>
> IMHO mem2mem devices, which process buffers in 1:1 way (there is always
> exactly one 'capture'/destination buffer for every 'output'/source buffer)
> can simply copy the sequence number from the source buffer to the
> destination.
>
> If there is no such 1:1 mapping between the buffers, drivers should
> maintain their own numbers. video encoder is probably an example of such
> device. A single destination ('capture') buffer with encoded video data
> might contain a fraction, one or more source ('output') video
> buffers/frames.
>
> > If the former option is chosen we should apply a patch like the
> > following so that the sequence number of the input buffer is passed to
> > the videobuf2 layer:
> >
> > diff --git a/drivers/media/video/videobuf2-core.c
> > b/drivers/media/video/videobuf2-core.c
> > index 1250662..7d8a88b 100644
> > --- a/drivers/media/video/videobuf2-core.c
> > +++ b/drivers/media/video/videobuf2-core.c
> > @@ -1127,6 +1127,7 @@ int vb2_qbuf(struct vb2_queue *q, struct
> > v4l2_buffer *b)
> > */
> > list_add_tail(&vb->queued_entry, &q->queued_list);
> > vb->state = VB2_BUF_STATE_QUEUED;
> > + vb->v4l2_buf.sequence = b->sequence;
> > /*
> > * If already streaming, give the buffer to driver for
> > processing.
>
> Right, such patch is definitely needed. Please resend it with
> 'signed-off-by' annotation.
I'm not too sure about that. Isn't the sequence number supposed to be ignored
by drivers on video output devices ? The documentation is a bit terse on the
subject, all it says is
__u32 sequence Set by the driver, counting the frames in the sequence.
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2011-12-23 11:28 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 [this message]
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
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=201112231228.45439.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=s.nawrocki@samsung.com \
--cc=shawn.guo@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