Linux Media Controller development
 help / color / mirror / Atom feed
From: Marek Szyprowski <m.szyprowski@samsung.com>
To: 'javier Martin' <javier.martin@vista-silicon.com>,
	linux-media@vger.kernel.org, laurent.pinchart@ideasonboard.com,
	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
Cc: 'Pawel Osciak' <p.osciak@gmail.com>
Subject: RE: MEM2MEM devices: how to handle sequence number?
Date: Fri, 23 Dec 2011 08:09:25 +0100	[thread overview]
Message-ID: <013f01ccc141$cdf78ed0$69e6ac70$%szyprowski@samsung.com> (raw)
In-Reply-To: <CACKLOr0H4enuADtWcUkZCS_V92mmLD8K5CgScbGo7w9nbT=-CA@mail.gmail.com>

Hello,

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.

Best regards
-- 
Marek Szyprowski
Samsung Poland R&D Center




  reply	other threads:[~2011-12-23  7:10 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 [this message]
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
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='013f01ccc141$cdf78ed0$69e6ac70$%szyprowski@samsung.com' \
    --to=m.szyprowski@samsung.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=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    --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