On Fri, 28 Mar 2008 22:25:59 -0700 Brandon Philips <brandon@xxxxxxxx> wrote: > > I've opened 3 mplayer windows, reading /dev/video0. I closed the second one and > > opened again. I got an error: > > Shouldn't V4L2 devices not be able to stream to multiple applications at > once? Quoting the spec: > > "V4L2 drivers should not support multiple applications reading or > writing the same data stream on a device by copying buffers, time > multiplexing or similar means. This is better handled by a proxy > application in user space. When the driver supports stream sharing > anyway it must be implemented transparently. The V4L2 API does not > specify how conflicts are solved." > > How about this patch? The patch is wrong. V4L2 API states that it should be possible for a driver to have multiple opens[1]. Most drivers support this. There are two main usages for multiple open: 1) a driver may open the device for streaming, while another thread or userspace app will open to configure. This is generally the way I use here to test video controls: I open "qv4l2" (under v4l2-apps/util) while streaming. This way, I can test any changes at the driver, without needing to have the feature implemented at the userspace app; 2) you can see a program with an userspace app and record the stream with another app. Both xawtv and xdtv do this, when you ask for record: They call mencoder, asking it to read from /dev/video0. This way, you'll have the tv app reading, using mmap() or overlay methods, while mencoder is calling read() to receive the stream. In fact, at least bttv, cx88 and saa7134 allows multiple opens for streaming. They have a limit, due to driver/hardware constraints: You cannot open two transfers of the same type. But you can open one overlay, one mmap() and one read() at the same time. While I don't have much concerns of not allowing multiple streaming on vivi for the same device (since you can ask vivi to create several different virtual devices, by using "n_devs" modprobe parameter), for sure videobuf should keep supporting this feature, otherwise it will break the other drivers that relies on this feature. Yet, vivi should allow multiple open to allow "panel" applications, to be compliant with V4L2 API. [1] From V4L2 API doc, rev 0.24: "1.1.3. Multiple Opens In general, V4L2 devices can be opened more than once. When this is supported by the driver, users can for example start a "panel" application to change controls like brightness or audio volume, while another application captures video and audio. In other words, panel applications are comparable to an OSS or ALSA audio mixer application. When a device supports multiple functions like capturing and overlay simultaneously, multiple opens allow concurrent use of the device by forked processes or specialized applications. Multiple opens are optional, although drivers should permit at least concurrent accesses without data exchange, i. e. panel applications. This implies open() can return an EBUSY error code when the device is already in use, as well as ioctl() functions initiating data exchange (namely the VIDIOC_S_FMT ioctl), and the read() and write() functions." Cheers, Mauro _______________________________________________ v4l-dvb-maintainer mailing list v4l-dvb-maintainer@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/v4l-dvb-maintainer