public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@infradead.org>
To: Pawel Osciak <p.osciak@samsung.com>
Cc: 'Laurent Pinchart' <laurent.pinchart@ideasonboard.com>,
	'Hans Verkuil' <hverkuil@xs4all.nl>,
	linux-media@vger.kernel.org
Subject: Re: More videobuf and streaming I/O questions
Date: Fri, 26 Feb 2010 09:04:54 -0300	[thread overview]
Message-ID: <4B87B8E6.6040608@infradead.org> (raw)
In-Reply-To: <001b01cab6b6$631d05f0$295711d0$%osciak@samsung.com>

Pawel Osciak wrote:
>> On Tuesday 23 February 2010 08:41:49 Pawel Osciak wrote:
>>>> On Mon, 22 Feb 2010 00:12:18 +0100
>>>> Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
>>> As for the REQBUF, I've always thought it'd be nice to be able to ask the
>>> driver for the "recommended" number of buffers that should be used by
>>> issuing a REQBUF with count=0...
>> How would the driver come up with the number of recommended buffers ?
> 
> From the top of my head: when encoding a video stream, a codec driver could
> decide on the minimum number of input frames required (including reference
> frames, etc.).
> 
> Or maybe I am missing something, what is your opinion on that?

There are some cases where this feature could be useful. For example, there are
some devices used for surveillance that have one decoder connected to several
inputs. For example, several bttv boards have one bt848 chip for each 8 inputs.
Each input is connected to one camera. The minimum recommended number of buffers
is 16 (2 per each input). This is poorly documented, on some wikis for some of
the boards with such usage.

That's said, there's currently a few missing features for surveillance: the user
software need to manually switch from one input to another, and the video buffer
metadata doesn't indicate the input. 

The better would be to provide a way to let the driver to switch to the next camera 
just after the reception of a new buffer (generally at the IRQ time), instead of 
letting the userspace software to do it at the DQBUF.

-- 

Cheers,
Mauro

  reply	other threads:[~2010-02-26 12:05 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-20 14:00 More videobuf and streaming I/O questions Hans Verkuil
2010-02-21 23:12 ` Laurent Pinchart
2010-02-22  9:47   ` Jean-Francois Moine
2010-02-23 12:45     ` Laurent Pinchart
2010-02-23  7:41   ` Pawel Osciak
2010-02-25 23:46     ` Laurent Pinchart
2010-02-26  7:36       ` Pawel Osciak
2010-02-26 12:04         ` Mauro Carvalho Chehab [this message]
2010-02-26 13:05           ` Muralidharan Karicheri
2010-02-26 14:29             ` Laurent Pinchart
2010-02-26 14:41               ` Karicheri, Muralidharan
2010-02-26 14:24           ` Laurent Pinchart

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=4B87B8E6.6040608@infradead.org \
    --to=mchehab@infradead.org \
    --cc=hverkuil@xs4all.nl \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    --cc=p.osciak@samsung.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