[mythtv] Re: Adding DVB-T support to MythTV
kedlm at knology.net
Wed Mar 19 12:23:25 EST 2003
I just can't help but wonder if you are going to put Myth in a Philips
product? Kind of curious after working at Philips for 8 years....
On Wed, 2003-03-19 at 04:28, matt.jarvis at philips.com wrote:
> Dear Richard
> I'm very interested in getting this to work, so lets' keep this thread
> going and encourage some discussion about the problems that would be
> 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 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.
> 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. )
> 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.
> 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 !!
> Matt Jarvis
> Product Marketing Manager
> Marantz Professional Europe
> Kingsbridge House, Padbury Oaks, 575-583 Bath Road, Longford, Middx,
> UB7 0EH, United Kingdom
> +447796610410 - Mobile
> +441753686080 - UK Office
> +441753686020 - Fax
> matt.jarvis at philips.com
> Richard King
> <rak at cs.man.ac.uk>
> 2003-03-18 18:54
> mythtv-dev at snowman.net
> cc: Matt
> Jarvis/LGD/CE/PHILIPS at EMEA1
> Re: Adding DVB-T
> support to MythTV
> Hi Matt,
> > Yep, I think MJPeg tools would definitely do the conversion to
> > different video formats, while ts2ps would demultiplex the initial
> > transport stream.
> It will. though as as I said in my last message you're going to have
> have a way of telling ts2ps which PID's you want.
> > The only problem then is to get this stream into a
> > virtual v4l interface ( if indeed this is possible ). I did look
> I'm not sure this is the most useful way of doing it. Myth currently
> doesnt support incoming MPEG2 streams from a V4L device and I'm not
> the V4L api supports datastreams with both the audio and video
> It would certainly take a while to implement this in Myth so you might
> well write some direct support into Myth.
> If you meant decoding the MPEG2 stream and then feeding it into the
> subsystem this is definately possible with something like vloopback
> (though it might need a bit of work to get it into a useful shape for
> this - disclaimer: only looked at it for 2 mins :S ) This method is
> to be incredibly wasteful of resources though.
> > on the web to try and find out if it's possible to pipe a stream in
> > way but couldn't find anything referring to similar stuff - if
> > knows how to do this I will certainly test it out. I would also
> > there would be timing and synchronising issues.
> vloopback looks like a good start. You said in another mail that it
> supports sending from a V4L device, my initial impressions suggest
> this is
> not the case, though they are VERY initial impressions ;) AFAICS
> requires you to feed a virtual V4L device (say /dev/video0) and it
> then mirror than input out on another V4L device (say /dev/video1). As
> long as you have a program that can feed it the video in the right
> it should work
> > As I said in my previous mail the channel changing would require a
> > script and a config file. The config file lists the channel
> > on the dvb signal, and cross references them to the mythtv epg. This
> > would need to be filled somehow by tv_grab_uk, or perhaps generated
> > automatically by another script. The channel change script would
> > convert the mythtv channels to the correct frequency and call
> In some countries it should be possible to get the data for the EPG
> out of
> the transport stream. (I think freeview in the UK only broadcasts Now
> Next information right now though)
> > However, even on the initial feedback to this post it certainly
> > like there is some interest so here's hoping someone picks this up
> > runs with it. I'm available for testing, documentation and other
> > non-programmer type stuff .....
> This is my /big/ project when I finish uni this summer, assuming I'm
> beaten to it. My intention is to make Myth support a form of plugins
> support various inputs with my target being: V4L, DVB and internet
> streams; with FM radio, DAB and American Digital TV/HDTV being easily
> supported if someone wanted to write the support.
> Richard King
> E-mail: rak at cs.man.ac.uk
> mythtv-dev mailing list
> mythtv-dev at snowman.net
Michael Kedl <kedlm at knology.net>
More information about the mythtv-dev