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

[Richard King]

Hi Matt,

On Wed, 19 Mar 2003 matt.jarvis at philips.com wrote:

> Your idea for a complete rewrite of Myth seems a bit drastic - and I'm not 
> sure the main developers on this project would be overly keen on a 
> fundamental change like this ( perhaps Isaac would like to comment ) . I 
I think a complete rewrite of Myth is a bit of an overstatement! I'm 
suggesting wrapping NuppelVideo* in a framework. The initial part of this 
would involve changing only those files out of the hundreds in myth and 
once in place would allow things like DVB, radio, internet streaming, etc 
to be added alot easier than it is now.

> understand your principle in abstracting the actual video source, so the 
> interface with myth is generic and a whole range of plugins could then be 
> used , but perhaps in the short term it may be possible to get this 
> working the short and dirty way via piping and vloopback - as a proof of 
> concept before changing the myth interface in this way.
Definately. As a proof of concept its a valid route of exploration. 
However, I do think that if you are going to invest the time writing a 
program to get the data into the v4l subsystem, etc then you may aswell 
just write crude support in myth to take the MPEG stream from a pipe. 

> I completely agree the decoding to re-encode is wasteful, but considering 
> that in order to run myth most people are using way powerful processors 
> anyway, there certainly looks like there should be enough cpu cycles 
> floating around to not make this an issue ( my box has an athlon xp 1800, 
> with 512mb of memory. )
For a single channel yes. But i think for things like pip no. And part of 
the reason I like DVB is that if we have the proper support for it then 
you can do pip with only 1 card (assuming both channels are on the same 
multiplex)

> With reference to ts2ps I see your point - that this would actually have 
> to be invoked by the channel change script rather than at an earlier 
> point, unless perhaps it is possible to demultiplex all the streams simultaneously. Again this is mostly conjecture on my point 
> as I haven't played with any of this code yet, just done a lot of reading 
> around the docs to see if it would theoretically be possible to integrate 
> dvb-t into myth.
If you take the hack basic support into myth route (which i think is best 
for quick, relatively clean, but limited support for dvb) then I see it 
slightly more as follows (if myth doesnt do things quite like this then 
i'd have thought it would be very simple to change):

before myth opens the video stream it executes the change channel command.
then it opens the video stream by calling dvbstream (using a shell wrapper 
that works out the PID's required) which pipes its output to myth.
before changing the channel myth shuts down dvbstream.

That might make changing channel take slightly longer if myth doesnt do it 
like this atm but it will result in no consitancy problems (MPEG streams 
etc).

> Vloopback should be easy to test out, if you have read the docs correctly. 
> I am still a little confused as to the docs :
> 
> For example: if you have a camera on /dev/video0 the input pipe will most 
> likely
> be /dev/video1 and the output on /dev/video2.
> e.g. if you want to watch an inverted image of the camera you would start 
> invert
> with /dev/video0 as its input and /dev/video1 as its output.
> 
> This seems to suggest that you still need a v4l device as an input !!

I just take it as showing you an example. If you already have a v4l device 
then the input to the vloopback device will be /dev/video1 instead of 
/dev/video0, etc. they are using a program to feed the vloopback device so 
I see no reason why you couldnt write a program that outputted the video in 
the right format.

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