[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