Differences between revisions 1 and 2
Revision 1 as of 2008-12-07 20:51:38
Size: 422
Editor: localhost
Comment:
Revision 2 as of 2008-12-07 21:00:51
Size: 1712
Editor: localhost
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
[[http://www.linuxtv.org/wiki/index.php/Main_Page|Video4Linux]](V4L) and it's associated digital video API (DVB) are the ''de facto'' open-source audio/video capture frameworks. Most popular recording applications (e.g. MythTV and Freevo) are designed around these APIs, and many other applications, such as VLC, provide specialized features that can talk directly to V4L/DVB-compliant devices. [[http://www.linuxtv.org/wiki/index.php/Main_Page|Video4Linux]](V4L) and it's associated digital video API (DVB) are the ''de facto'' open-source audio/video capture frameworks. Most popular recording applications (e.g. MythTV and Freevo) are designed around these APIs, and many other applications, such as VLC, provide specialized features that can talk directly to V4L/DVB-compliant devices. Therefore, it would be beneficial to add V4L/DVB API support to the cx88 drivers so that all of these applications could (hopefully) "just work".

Unfortunately, this isn't a straightforward task. While V4L/DVB are reasonably flexible APIs, they do make one big assumption that isn't necessarily compatible with modern driver design--they are entirely ioctl(2) based. This essentially requires a kernel presence for every V4L/DVB-compliant driver, even though some drivers (such as those for simple USB video devices) could otherwise be implemented entirely in userspace. The cx88 driver is a hybrid, in that it requires a kernel presence for hardware protection, register access, DMA control, and interrupt processing, but all peripheral control is performed in userspace. Moving highly-variable and non-performance-critical components like these to userspace seems to be the way forward, for reasons such as the following:
 * Reduced kernel bloat
 * Increased reliability (think segfault vs. kernel panic)
 * Increased programming flexibility (for example, the ability to do floating-point calculations for things like tuner signal-to-noise ratio)
 * Lower barriers to entry for contributors--familiarity with kernel driver design principles and restrictions is not necessary

V4L/DVB support

Video4Linux(V4L) and it's associated digital video API (DVB) are the de facto open-source audio/video capture frameworks. Most popular recording applications (e.g. MythTV and Freevo) are designed around these APIs, and many other applications, such as VLC, provide specialized features that can talk directly to V4L/DVB-compliant devices. Therefore, it would be beneficial to add V4L/DVB API support to the cx88 drivers so that all of these applications could (hopefully) "just work".

Unfortunately, this isn't a straightforward task. While V4L/DVB are reasonably flexible APIs, they do make one big assumption that isn't necessarily compatible with modern driver design--they are entirely ioctl(2) based. This essentially requires a kernel presence for every V4L/DVB-compliant driver, even though some drivers (such as those for simple USB video devices) could otherwise be implemented entirely in userspace. The cx88 driver is a hybrid, in that it requires a kernel presence for hardware protection, register access, DMA control, and interrupt processing, but all peripheral control is performed in userspace. Moving highly-variable and non-performance-critical components like these to userspace seems to be the way forward, for reasons such as the following:

  • Reduced kernel bloat
  • Increased reliability (think segfault vs. kernel panic)
  • Increased programming flexibility (for example, the ability to do floating-point calculations for things like tuner signal-to-noise ratio)
  • Lower barriers to entry for contributors--familiarity with kernel driver design principles and restrictions is not necessary

Ideas/V4L (last edited 2008-12-08 11:51:47 by localhost)