On Tuesday, July 26, 2011 13:44:28 Sakari Ailus wrote:
> Hi Hans and Guennadi,
<snip>
> > I realized that it is not clear from the documentation whether it is
> > possible to call
> > VIDIOC_REQBUFS and make additional calls to VIDIOC_CREATE_BUFS afterwards.
>
> That's actually a must if one wants to release buffers. Currently no other
> method than requesting 0 buffers using REQBUFS is provided (apart from
> closing the file handle).
I was referring to the non-0 use-case :-)
> > I can't remember whether the code allows it or not, but it should be
> > clearly documented.
>
> I would guess no user application would have to call REQBUFS with other than
> zero buffers when using CREATE_BUFS. This must be an exception if mixing
> REQBUFS and CREATE_BUFS is not allowed in general. That said, I don't see a
> reason to prohibit either, but perhaps Guennadi has more informed opinion
> on this.
<snip>
> > > > > Future functionality which would be nice:
> > > > >
> > > > > - Format counters. Every format set by S_FMT (or gotten by G_FMT)
> > > > > should
> > > > > come with a counter value so that the user would know the format of
> > > > > dequeued buffers when setting the format on-the-fly. Currently
> > > > > there are
> > > > > only bytesperline and length, but the format can't be explicitly
> > > > > determined from those.
> >
> > Actually, the index field will give you that information. When you create
> > the
> > buffers you know that range [index, index + count - 1] is associated with
> > that
> > specific format.
>
> Some hardware is able to change the format while streaming is ongoing (for
> example: OMAP 3). The problem is that the user should be able to know which
> frame has the new format.
Ah, of course.
> Of course one could stop streaming but this would mean lost frames.
>
> A flag has been proposed to this previously. That's one option but forces
> the user to keep track of the changes since only one change is allowed until
> it has taken effect.
Something to discuss next week, I think.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
