| |||||||||||||
LPC: What's happening with webcamsLPC: What's happening with webcamsPosted Sep 25, 2008 23:40 UTC (Thu) by bronson (subscriber, #4806)Parent article: LPC: What's happening with webcams
Frame server?? Why not just allow multiple applications to open a single video device simultaneously?
(Log in to post comments)
LPC: What's happening with webcams Posted Sep 26, 2008 14:14 UTC (Fri) by mattdm (subscriber, #18) [Link]
Presumably because the devices don't support that.
LPC: What's happening with webcams Posted Sep 26, 2008 15:35 UTC (Fri) by bronson (subscriber, #4806) [Link]
Sure, but that's the great thing about having the source code to your own kernel, you can fix things properly.
Did the V4L guys consider making this change and reject it because it would be too hard?
LPC: What's happening with webcams Posted Sep 26, 2008 15:54 UTC (Fri) by JoeBuck (subscriber, #2330) [Link] But then the code to arbitrate between the multiple devices that have the camera open has to be in the kernel, instead of in user space. It can be made to work, but is probably not the best design choice.
webcams and multiple users Posted Sep 26, 2008 16:49 UTC (Fri) by sdalley (subscriber, #18550) [Link]
It's a question of practicalities. Think it through a little bit.
Remember, it's in userspace that the simultaneous reads have to take place.
libv4l has to provide a stream of decoded video frames by reading the encoded video device via the kernel interface, decoding the data and providing a proxy "device" in userspace. It makes sense for at most one thing to be doing that, and AIUI something which they call a "frame server" is to be the thing doing the proxying.
The userspace client programs can then talk simultaneously to the proxy to get the data that they themselves happen to be interested in. This is going to be different for different clients. That being the case, the "server" has to be the thing arbitrating the access to data by the different clients, reading and decoding new frames and updating the pool of decoded data which the clients are reading and quite possibly seeking around. Timed callbacks may also be required. This implies a separate thread or process of execution. Only in the very simplest and most restrictive use cases could you do without this.
Simultaneous use of a single device by multiple clients implies this sort of complexity, and you have to stuff it somewhere. In this case, it has to be in userspace.
|
|||||||||||||