Re: How to support hardware controlled time multiplexing ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



Hi Gerd,

> > The second way to implement the hardware multiplexing would be for the
> > driver to return the input number in the v4l2_buffer structure passed to
> > DQBUF. The application would also need a way to enable or disable a
> > specific input. The problem with that approach is that it leads to a
> > change in the API. On the other hand, this method uses 4 times less input
> > buffers than the first method (when using mmaped streamed I/O), and
> > doesn't modify the framerate behind the application's back.
>
> This one.  Havn't found time yet to look into this in detail (your
> mails still sitting in my inbox waiting ...).  Basic idea is to make
> one of the reserved ints in v4l2_buffer a input number and add a new
> bit for the flags field to indicate that the new input field is used.
> To use the new feature apps must set the flag and fill the input field
> when queuing buffers via QBUF.  That should be backward compatible
> because old apps don't set that flag.  Feel free to go ahead with a
> implementation and check out whenever it really works this way.

This seem an extremely good idea. We will implement that and post our results 
and feeling on this list.

Thanks for your help.

Laurent Pinchart




[Index of Archives]     [Linux DVB]     [Video Disk Recorder]     [Asterisk]     [Photo]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Free Photo Albums]     [Fedora Users]     [Fedora Women]     [ALSA Users]     [ALSA Devel]     [Linux USB]

Powered by Linux