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

[Sam Logen]

--- Daniel Kristjansson <danielk at cuymedia.net> wrote:

> On Sat, 2008-03-08 at 22:31 -0800, Sam Logen wrote:
> > 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.
> 
> Well if they have to be fixed on the software side,
> it's much
> easier to fix this in the driver, no?

Then why is its implementation in ivtv functional only
on some hardware, and broken in other hardware?

 Otherwise the
> applications
> need to know how delayed each hardware's /dev/videoX
> file is
> with respect to the /dev/vbiX file.

I addressed this in my first message with the use of a
buffer and a manual delay setting - much like the
audio delay setting present in mythfrontend's OSD
menu.

 Then they need
> to demux the
> stream, insert the vbi and then remux into a new
> stream.

True, or let the vbi data sit in a separate file
linked through the database to the recording file. 
This was also one of my concerns with the idea.

> 
> Now while I don't think MythTV is where the hardware
> driver
> should be implemented, if you submit a patch it will
> be considered.

I'm sorry but I'm really no good at coding - it's my
kryptonite, so to speak.  If you think it's
frustrating for you, consider my position, offering
ideas, but without a line of code to back me up.

> We already work around a lot of different driver
> deficiencies in
> MythTV. But you might find it easier to write your
> patches to the 
> drivers themselves.

The driver developers didn't think so, and I must
defer to their judgment because, as you know, my
knowledge in these regards is limited.

 You might be able to skip the
> whole demux/remux
> step by telling the hardware to give you a little
> scratch space
> in the stream...

Well, I'll pass on the word and see what others think
of these ideas.

Kindest regards,
Sam



      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ