[mythtv] [PATCH] DVB support

Edward Wildgoose Edward.Wildgoose at FRMHedge.com
Fri May 2 15:44:02 EDT 2003


The punchline for anyone watching this thread is that:

a) if you are pretty technical, 
b)understand how to make your DVB card work without any help (tzap, scan, vdr, etc), and 
c) you can debug a little C++ if needed

...Then this is a good time to have a play with this patch.

It is running on my machine at the moment, and on request I can supply settings for channels on the Crystal Palace transmitter (ie London).

Right now it needs you to understand how to tweak the channels table by hand (you can actually read off the settings from the scan program though).  However, you can now tune and record the digital DVB mpeg broadcasts successfully! (and they look very good)

Problems at the moment include playback issues, and perhaps some channel change issues when watching live tv (although this may be just a problem with my mysql setup...)  

The playback problem is that the nuv video file plays perfectly in mplayer, however, both live tv, and playing back the nuv file from the recorded programs menu is using more than 100% cpu on my 1Ghz machine and there is v. bad framedropping and sound sync problems (presumably as a result).  

I can provide a sample nuv file and I wonder if someone could take a look at it and see if there is something obviously wrong with it?  I'm wondering if it could be something like a colourspace issue, and myth is trying to transcode it, or something similar...  It's wierd that mplayer should have no bother with it anyway.

So there we have it.  Huge congratulations to Ben for getting the code to this point, especially as he doesn't have a DVB card and is writing and debugging over an SSH link to my machine!

If you can help to finish this patch off and get it fully tested, then I for one would be very grateful

Ed


-----Original Message-----
From: Ben Bucksch [mailto:linux.news at bucksch.org]
Sent: 02 May 2003 03:13
To: Development of mythtv
Subject: [mythtv] [PATCH] DVB support


I think I am done so far with DVB support, as far as I can get from here 
without an card locally.


 1. State


 1.1. DVB

Tuning works, the initial channel is set correctly. I am not sure, if 
switching channels works, because the box with the DVB card is a few 
thousand km away :-) (thanks again Edward).

Recording of the data also works. I fetch an MPEG TS from the card, 
either prefiltered to the right channel or the full TS, filter out the 
right channel, convert it to MPEG PS and write it into the 
nuppelfile/ringbuffer the same way Isaac did it with the PVR (incl. his 
recent seeking support).

The resulting file plays correctly in mplayer, although the same file 
seems to have framedrops or the like when streamed via MythTV, I have no 
clue why that is, Edward should write more about that.

Tuning to several channels at the same time should work in theory, 
although I haven't tested it and the required support within MythTV (to 
know that it can get 2 channels from the same card) does not exist yet.

Channels must be entered manually into the database (see docs posted 
earlier). Somebody needs to write a importer from a channel listing 
format, e.g. dvbtune's XML output (data directly from the DVB feed) or 
channels.conf. Ideally, we should one day have a manual graphical config 
tool as well, at least to change the names and presets of the channels.


 1.2. Stream

I have a simple recorder and channel implementation (the normal external 
channel impl. had some dependencies on analog TV tuning) which should 
allow people to use an external program to tune and to receive an MPEG 
stream via stdout/pipe. If there was no built-in DVB support in MythTV, 
though would have allowed to use dvbstream to add DVB support in a 
hackish / home-brewn way. It is meant to allow "Unix toolsmith" users 
without programming knowledge to extend/adapt MythTV for their purposes. 
However, the implementation I have is rudimentaty, unfinished and 
completely untested, so it's probably not ready to be checked in, and I 
don't know, if I'll further work on it, given that I have no immediate 
need for it. It is included for your possible enjoyment or adoption and 
as a simple example on how to use the new baseclasses / add new data 
sources / add new tuning/recording methods. It should be renamed as 
well, "stream" is confusing.


 1.3. General changes

I had to make some changes to the design of MythTV. I checked analog TV 
on my box, and it still seems to work for me.


 2. Changes

Here a high-level overview over the changes I did.


 2.1. libdvbdev

This new library adds DVB- and MPEG-specific functions required for DVB 
support. Mainly, there are 3 functions:

   * tune_it() tunes the DVB card. implemented solely by tune.c/h.
   * set_ts_filter() sets the PID filters in the DVB hardware or
     driver. Implemented solely within dvbdev.c.
   * ts_to_ps() filters for certain (currently 2) PIDs in (userlevel)
     software and also converts an MPEG TS to an MPEG PS. (I can't
     believe that I spent 3 days to write this simple function,
     including finding a suitable base lib). Implemented using the
     prestine mpegtools files transform.c/h, ringbuffy.c/h, remux.c/h
     and ctools.c/h.


 2.2. Base classes

Both the |Channel| (used for tuning) and the |MpegRecorder| (used to 
record MPEG data) have fairly large dependencies on V4L / analog TV 
(/dev/video devices etc.). While I needed some generic functionality in 
these classes, and other classes (TVRec, most notably) use the Channel 
interface extensively, the dependency on V4L of course broke DVB 
support, because there is no /dev/video. So, I separated the generic 
functionality and interface from the V4L dependencies, kept the generic 
functionality where it was and introduced new subclasses for analog TV, 
which then contain the V4L-specific parts. The new hierarchy is:
Channel
+-AnalogChannel
+-DVBChannel
+-StreamChannel
RecorderBase
+-NuppelVideoRecorder
+-MpegRecorder
  +-AnalogHwMpegRecorder
  +-DVBRecorder
  +-StreamRecorder


 2.3. New tuning parameter storage

As discussed recently, DVB tuning needs quite a number of new tuning 
parameters for each channel. I tried to come up with a generic and 
future-proof method how to store them. Unfortunately, Isaac didn't like 
my first solution, I haven't gotten any feedback on my other suggestion. 
I hope we'll see a good solution being proposed later, and it'll be 
implemented, but for now, I kept the method I already implemented, 
namely to store a list of parameters/properties in one field.

Analog tuning can optionally (per a compile-time flag, defaulf off) use 
the new way to store tuning parameters. If used, the channum column can 
be (ab)used as "preset" the way Europeans expect or even need (I can't 
enter a channum like "SE11" on my remote, and many of my analog channels 
have that format). In that case, the UI will show the preset in all 
places where it now shows the channum.
For DVB, the channum is free to be used as preset anyways.

For a documentation of the parameters and the format, see an earlier 
post of mine to the dev list.


 2.4. SetOption

Currently, the RecorderBase takes a SetBaseOption(QString, QString) and 
the MpegRecorder and nuppelrecorder take a SetEncodingOption(QString, 
int). Both functions have basically the same purpose. Because I needed a 
string in the streamrecorder, and I didn't see a point in the 
distinction, I merged these 2 functions and used overloading and 
inheritance/polymorphy to (optionally) have both the string and the int 
version in the base and the encoder. Because the trigger for this change 
was the StreamRecorder (not the DVBRecorder as I thought), this change 
is not strictly necessary, but would need some rework to remove it. 
However, I believe this change makes the purpose of these functions 
clearer and is more flexible.


 2.5. Don't use device in DB query

TVRec uses the videodevice as parameter for almost every query. This 
breaks, if there is no video device, e.g. for StreamChannel, maybe also 
for DVBChannel. I don't think that's needed anyways, the card id should 
work just as well, so I queried for that instead.


 3. Patches

Many of these changes have interdependencies, at least on the patch 
level. There are too many changes next to each other to separate them 
all cleanly, it often was just not possible without several complete 
rewrites.
DVB support even inherently depends on all of these changes apart from 
SetOption (but still depends on the latter on the patch level).

Nevertheless, Isaac requested that I separate the changes into different 
patches. I can understand that, to more easily see which changes are 
related. I tried my best to keep them separate and created a number of 
patches, each with a different change. But, as said, in some places, the 
changes were so close to each other (or depending on each other) that 
|diff| stuffed them together. In these cases, I placed them in 
mixed.diff, you'll have to sort out these changes manually, I'm sorry. 
But that way, I could separate the bulk of the changes, without needing 
to rewrite/change the code itself. The patches add up to the cumulative 
patch in dvb-N.tar.bz2, but the latter also contains the required new files.

The new base class files already use SetOption() and newtuning and thus 
depend on those patches. nodevice depends on base classes (GetCardID is 
implemented there). DVB depends on all other changes apart from the 
StreamChannel/Recorder and misc.diff.

The current patch is at <http://www.bucksch.org/xfer/dvb-21.tar.bz2>, 
with the separated diffs at 
<http://www.bucksch.org/xfer/separated-21.tar.bz2>. The attachment was 
too large. These URLs are temporary.

Ben

_______________________________________________
mythtv-dev mailing list
mythtv-dev at snowman.net
http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-dev



More information about the mythtv-dev mailing list