Hi Andy, Thank you for your kindly suggestion on this! Basically we will make the secondary device node (for preview) as a simple V4L2 device node which support most of the ioctls. This device node will be seperated from the primary device node and treated as an independent device. For your questions: >Will any of the ioctl() calls on the preview buffer node affect the >settings made by ioctl()'s on the primary device? This device node will be seperated from the primary device and treated as an independent device >The secondary node could be treated as a full fledged V4L2 video devices >by existing daemons and applications. Would you be supporting things >like QUERYCAP on this node? Yes, the device node will support most of the V4L2 ioctls as a nomorl device. Thanks Wen >-----Original Message----- >From: Andy Walls [mailto:awalls@xxxxxxxxxxxxxxxx] >Sent: 2010年5月10日 1:17 >To: Wang, Wen W >Cc: linux-media@xxxxxxxxxxxxxxx; Zhang, Xiaolin; Huang, Kai; Hu, Gang A >Subject: Re: Linux V4L2 support dual stream video capture device > >On Sat, 2010-05-08 at 02:20 +0800, Wang, Wen W wrote: >> Hi all, >> >> I'm wondering if V4L2 framework supports dual stream video capture >> device that transfer a preview stream and a regular stream (still >> capture or video capture) at the same time. > >Yes. > >At least for the ivtv and cx18 drivers, multiple streams can come from >the same hardware device and driver using differnet device nodes. > >I.e. > /dev/video0 MPEG stream (compressed audio and video) > /dev/video24 PCM audio stream > /dev/video32 YUV video stream > >The PCM and YUV stream are really just the intermediate products the >CX2341[568] chips make available as they are needed for the MPEG >encoding anyway. > >Because of the special relationship of the YUV and MPEG stream inside >the CX2341[568] chip, there is a restriction with the cx18 and ivtv >drivers that the MPEG stream and YUV stream have to be at the same >resolution and frame rate. The cx18 and ivtv drivers handle the >enforcement of this, so the /dev/video* device nodes are not completely >indpendent: changing the controls or settings on one of the related >device nodes affects the others. > > > > >> We are developing a device driver with such capability. Our proposal >> to do this in V4L2 framework is to have two device nodes, one as >> primary node for still/video capture and one for preview. > >Sounds OK so far. > > >> The primary still/video capture device node is used for device >> configuration which can be compatible with open sourced applications. >> This will ensure the normal V4L2 application can run without code >> modification. > >Be sure to keep in mind what userspace daemons can do here. Daemons >like hald can open() secondary device nodes and call ioctl()'s on them >when the user is not even aware. Pulseaudio will keep ALSA audio nodes >held open(). If there are interlocks on operations between secondary >and primary device nodes, users may run into some problems. > >Some things I've noticed: > >- Pulseaudio keeps a cx18-alsa provided ALSA device node open, making it >difficult to unload the cx18-alsa module and hence making it difficult >to unload the cx18 module. > >- hald runs through all the /dev/video* device nodes as they appear, >calling ioctl()'s that query capabilities, causing what were deferred >firmware loadings to happen early. > > >> Device node for preview will only accept preview buffer related >> operations. > >Will any of the ioctl() calls on the preview buffer node affect the >settings made by ioctl()'s on the primary device? > >The secondary node could be treated as a full fledged V4L2 video devices >by existing daemons and applications. Would you be supporting things >like QUERYCAP on this node? > >I guess what I'd suggest is that you not create a crippled V4L2 device >node. It may be better to have it support as many of the V4L2 ioctl()'s >as possible that make sense for the secondary device. > > >> Buffer synchronization for still/video capture and preview will be >> done internally in the driver. > >Why exactly do you need synchronization? > > >> This is our initial idea about the dual stream support in V4L2. Your >> comments will be appreciated! >> >> Thanks >> Wen > >Regards, >Andy ?韬{.n?????%??檩??w?{.n???{炳g???^n?■???h?璀?｛?夸z罐?+€?zf＂?????i?????_璁?:+v??撸?
