HDTV [FreeBSD WIKI]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== HDTV Support ======

Support for HDTV on %%FreeBSD%% is just starting out.  [[/JohnMarkGurney|JohnMarkGurney]] has added support an ATSC based card with work underway for a second.  There is no known support for the DVB family.  (Actually that's no longer true, there is now support for several USB devices via the multimedia/webcamd port using Linux v4l/dvb drivers, see [[/HTPC]])

===== Supported Devices =====

  * PCI Devices:
  * [[http://www.dvico.com/|DViCO]] FusionHDTV5 Lite and FusionHDTV5 RT Lite (''%%fusionhdtv.co.kr/eng/Products/RTLite.aspx%%'') -- [[JohnMarkGurney/HDTV/DViCOFusionHDTV5Lite|Support Information]]
  * Ethernet Devices:
  * [[http://www.silicondust.com/|SiliconDust]] [[http://www.silicondust.com/products/hdhomerun|HDHomeRun]] (as of libhdhomerun_20081002, no special options are required to build)

===== Support in Progress =====

  * ATI [[http://ati.amd.com/products/hdtvwonder/index.html|HDTV Wonder]] -- [[JohnMarkGurney/HDTV/ATIHDTVWonder|Support Information]]

===== Future Work =====

The following are comments/thoughts of [[/JohnMarkGurney|JohnMarkGurney]]:

I have been advocating keeping most of capture card drivers support code in userland.  The kernel should support data moving and protecting hardware (i.e. not letting users program arbitrary memory addresses like bktr currently does in METEORSVIDEO).  Putting non-time critical and little used code in the kernel only bloats the kernel.  In the days gone by, there was some value to keeping the code closer to the hardware and provide simpler kernel interfaces as it reduced userland code size, but today, userland code size is not a big issue.  Supporting a library which does the control work of tuning is feasible, easier to debug and can reduce memory size by only loading the code for the card that you have.

Though it would seem that doing tuning and initalization in userland would prevent supporting the V4L API, that isn't the case.  We could create a device that passes it's kernel calls to a userland program.  That program then would be linked against the userland API, doing the necessary work.  The userland daemon would not even have to do extra copies, as it could either obtain mappings to the original processes pages like w/ shared memory.

----

{{tag>InactiveProject}}