[mythtv] DVB Support suggested Roadmap

Richard King rak at cs.man.ac.uk
Mon Apr 21 20:20:19 EDT 2003


On Mon, 21 Apr 2003, Ben Bucksch wrote:

> Richard King wrote:
> 
> >only requires getting the MPEG data into Myth. External channel changing 
> >can take care of the rest.
> >
> IF the cards or drivers can demultiplex by themselves, then yes, that 
By 'getting the data into myth' I meant 'demuxing the data and getting it 
into myth' ;)
> should more or less pretty much out of the box, given that Myth can now 
> read MPEG2 from /dev/video.
/dev/video is different from /dev/dvb/* if you have a full card you 
definately get a /dev/video with the analogue version but i'm not sure 
whether you can get the MPEG data using the V4L interface. 

> I am not sure about the Nova cards (which I am looking at). They can't 
> demux in hardware, right? Can the driver do that? If so, does it allow 
Nova cards cant AFAIK though I believe that some other bugdet cards might. 
The driver doesnt do the demuxing
> to read several programs from the same transport stream at once?
This is partly why the budget cards are good. You cannot get the transport 
stream out of the full cards whereas you can with the budget cards.

> >For the 'full' support in Myth I think its important to get the database 
> >into a shape that fully encompases the data in channels.conf. I don't like the idea of putting the channels.conf line in one field [...]
> >full support and then I think that the everything in one field approach is insufficient anyway.
> >
> What would you propose? An extra table for DVB?
I'm afriad I haven't had time to properly look at it, I did have a more 
concrete idea of what I was going to suggest in January but I'm afraid 
I've forgotten it now. :( As soon as I've got my degree out of the way I 
shall get back to looking at this and post a proper proposal. This doesn't 
have a huge impact on getting the basic support working though.

> I thought that the tuning data should all be in one table, and because 
> there might be any number of (future) tuning models, I thought that 
> putting it all in one field would be the best way.
Well, we certainly want to come up with a format that is fairly future 
proof, but I think that we need to have the data in channels.conf 
available in seperated fields. I'm sorry for being vague but its been a 
while since I looked at Myth because whenever I do I don't get any work 
done on my project.

-- 
Richard King
E-mail: rak at cs.man.ac.uk



More information about the mythtv-dev mailing list