[mythtv] Enabling VBI for a broader array of drivers and hardware

Sam Logen starz909 at yahoo.com
Sun Mar 9 06:31:57 UTC 2008


Hello,

I'm posting here to continue the discussion on the
bugtracker for bug #4891, which seems to be an
inefficient way to communicate.

To be brief, I have had this discussion with several
linux driver developers.  They, in turn, have had
conversations with the firmware developers, and there
does not appear to be any progress.  As it seems to
me, the majority believes that all these faults are to
be fixed on the software side.

Let us assume for a moment that issues in device
firmware will not be addressed in the foreseeable
future.

One side (the driver developers) is arguing that the
vbi node is sufficient and any capture software should
point to it to receive vbi data.  The other side
(mythtv developers) evidentially argues the opposite;
that the drivers should address this issue, so mythtv
will always capture the same format data no matter the
driver being used.

Who can say who is correct?

Hans Verkuil is providing an enormously large public
service in developing his drivers to splice in the vbi
data - and he is spending a lot of time to get this
support with more hardware supported by ivtv. 
However, currently not all ivtv hardware benefits from
this.

In contrast, the blackbird developers are relying on a
stable, dedicated device node to provide all the
essential vbi data.

At the same time, mplayer, and I think kdetv and
zapping are providing vbi node functionality.

Now it seems to me that the effort to get these
drivers to splice in quality vbi information for all
hardware that these drivers support is an enormous and
time-consuming task, and that having mythtv point to
one extra optional node is considerably less work.

Ideally [mythtv developers] are correct, the
processing of vbi data should be in firmware, or if
not, then drivers, but that then means closer
communication between the mythtv developers and driver
developers, because otherwise, driver development will
continue in one direction, and mythtv development in a
different direction.

The notion that "it's still more economic to work
around the bugs in one place, the driver" seems to
imply that coding the drivers to splice in vbi data is
a simple task, when my observations indicate the
opposite. Perhaps one day the drivers will have these
features, and mythtv can drop deprecated support
options.  But this seems unlikely right now, though if
I had the time to learn it all, I'd jump at the chance
to fix this.

I'm just asking that mythtv includes support for all
of v4l's driver features, and not guess that all the
drivers will provide the same ideal functionality,
which they do not.  I'd like to believe that if on
this list there were handicapped individuals, or
people who work with them, they would agree with me.

Respectfully as always,
Sam



      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping


More information about the mythtv-dev mailing list