3 ms·
Video capture is something that's "just worked" for me for as long as I can remember (unlike audio). What's the value gained from the added latency of an interm
by dmw_ng 3y ago
Video capture is something that's "just worked" for me for as long as I can remember (unlike audio). What's the value gained from the added latency of an intermediary? Is it only to ease containerization?
- predictabl3 3y agoFor one, without this two applications can't use your camera simultaneously. I think this is also key for getting libcamera in the mix. And pipewire is phenomenal, I assume this opens the door for video transformations, a+v effects, etc. I'm quite excited about it.
- fulafel 3y agoWith audio, accessing kernel interfaces directly in olden days lead to problems with multiple apps using the device & inability to provide inputs/sinks from userspace (eg post/preprocessing or hw driver implemented in userspace). It's still that way with video. People have been using a out of tree loopback video kernel driver for these things which is hard to use and hacky and slow.
- tadfisher 3y agoThat still is the case, it's just that nobody runs hardware DSPs so nobody needs to deal with anything but a single userspace sound server. Video just has order-of-magnitude higher processing requirements, so dumping raw buffers into userspace and letting a "video server" do the work isn't usable for use cases that care about latency, throughput or resource usage (e.g. game streaming). So you end up with a bunch of kernel interfaces for hardware-accelerated video transforms (many driver-specific), a few competing userspace APIs (gstreamer, vulkan extensions, vaapi, vdpau, etc), zero-copy kernel buffer APIs, the list goes on. You end up with something like Pipewire just to abstract over the complexity.