| Both sides previous revision Previous revision Next revision | Previous revision |
| johnmarkgurney:hdtv [2008/06/17 21:38] – converted to 1.6 markup 127.0.0.1 | johnmarkgurney:hdtv [2021/03/28 07:53] (current) – Third time's a charm. Use preview this time. KubilayKocak |
|---|
| ====== HDTV Support ====== | ====== 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. | 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 Cards ===== | ===== Supported Devices ===== |
| |
| * [[http://www.dvico.com/|DViCO]] FusionHDTV5 Lite and [[http://www.fusionhdtv.co.kr/eng/Products/RTLite.aspx|FusionHDTV5 RT Lite]] -- [[HDTV/DViCOFusionHDTV5Lite|Support Information]] | * 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 ===== | ===== Support in Progress ===== |
| |
| * ATI [[http://ati.amd.com/products/hdtvwonder/index.html|HDTV Wonder]] -- [[HDTV/ATIHDTVWonder|Support Information]] | * ATI [[http://ati.amd.com/products/hdtvwonder/index.html|HDTV Wonder]] -- [[JohnMarkGurney/HDTV/ATIHDTVWonder|Support Information]] |
| |
| ===== Future Work ===== | ===== Future Work ===== |
| |
| 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. | 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}} |
| |