[mythtv] Re: Adding DVB-T support to MythTV

Richard King rak at cs.man.ac.uk
Wed Mar 19 22:41:50 EST 2003


On Wed, 19 Mar 2003, Matthew S. Hallacy wrote:

> Why bother using MythTV for it at all, if it's not done (reasonably) right?
> 
> For my WinTV PVR-250, I use the 'player6' application to write to a ringbuffer,
> then I open that with xine/mplayer/etc. I can pause/rewind/fastforward with ease.
> 
> Something similar could be done with the DVB cards (and perhaps it already has),
> but an ugly hack that wastes that much cpu (and yes, it will be more than even
> some of the higher-end systems can handle at any decent res/quality) is just
> dumb, IMHO. 
The processor intensive hack is not something that I think people are 
seriously considering. There are easier ways of doing it. It was just 
discussed as a possibility.

As to why use Myth? This is a good question. Until yesterday the only
program i'd seen that offered the range of options and the set-top box
style interface that I'm looking for thats, in a usable state, was Myth.  
VDR is a DVB equivalent but it has its own flaws and only supports MPEG
based streams (AFAIK). I'm looking for something that offers the
convergance thats the idea behind myth.

Yesterday I saw links to dbox. All the documents are in german so I'm not
sure about all the features but it does look like it offers some
attractive features. Nonetheless, Myth's code seems pretty clean and very
easy to understand, especially considering the fact that there are very
few comments and as such is a project that I feel that I can contribute to 
fairly easily. We shall have to wait to see whether that materialises 
though :p
 
> > > > The proper way to do this, does NOT require a 'rewrite' of MythTV. As
> 
> > I wasnt suggesting this. Just rearranging the NuppelVideo bits with bit of 
> > glue.
> 
> I was responding to Mr. Jarvis. 
When Matt mentioned rewriting Myth he was referring to my email even if he 
misinterpreted me. ;)
 
> > If you've been following the thread its not quite as simple as that. Thats 
> > all you need to do if you've got one of the Hauppauge PVR cards but DVB is 
> > not quite the same. Though for simple support its still not that difficult 
> > if you pipe data in from external commands.
> 
> The multiple stream issues, right? Even from my limited knowledge of A/V codecs
> I know that it's not hard to select which stream ID you want, or to demux
> the audio and video for further processing (although, if the target storage
> format is MPEG-2, you don't really need to do any processing on it) 
The target format is seperate MPEG2 video and audio element streams 
encapsulated in an NUV file. Not particularly difficult to do but still 
more than just dumping an incoming stream to disk.

> I do have some questions about the streams produced by the DVB cards:
> 
> 1) If channels 100 through 120 are in the same 'block', then I change to
> channel '110' does the 'block' contain 110-130, or 100-120? If it's 100-120
> then MythTV would have to know how the blocks are setup so that it can 
> pick the proper stream ID, otherwise it could pick stream 0 and use it.
> (With added support for pseudo multiple tuners at a later point in time,
> assuming the other channels are within the same block)
I'm afraid it doesnt work anything like this.

Each multiplex ('block') is found on a radio frequency. Usually occupying
the same amount of space as an ordinary TV channel. with DVB these
frequencies are usually specified directly though you can specify them
using the traditional analogue style channels (ie channel 22) + an offset.  
Within each of these multiplexes there are many streams (tens, potentially
hundreds if not broadcasting video). These streams have an ID that could
be 1,80,600, whatever (no guarantees about starting from 0 or about
uniqueness between multiplexes AFAIK). Each TV channel consists of
multiple streams: video, (possibly multiple) audio, teletext, interactive
tv, etc. As with European analogue TV the channel numbers you press on
your remote control don't directly map to frequencies or streams. They are
effectively a bookmark to tell the tv/pc/etc what streams on what
multiplexes it needs to decode.

There are no fixed number of channels per multiplex and there is no
blocking so you cannot make assumptions about which channels are on which
multiplex. there is the channels.conf format that stores all the details
needed to receive the channel via terrestrial, cable or satellite.  A
small sample follows to give you an idea of the number of variables you
need to take into account:

BBC ONE eng(TV):641833:V:0:27500:600:601:603:0:4167
BBC TWO eng(TV):641833:V:0:27500:610:611:613:0:4231
Sky One eng(TV):842000:V:0:27500:544:545:1074:1:16512
 
> 2) Are the blocks of channels hardset, or can you pick and choose which
> ones you want? It would be very nice if you could actually pick 24 (or
> whatever the number is) channels to get in the stream, but I suspect this
> is not the case.
Yes the card gets its feed straight out of the air so you are stuck with 
the way the multiplexes are defined, however you can choose which streams 
you take out of that multiplex and which you ignore when you demultiplex 
it.

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



More information about the mythtv-dev mailing list