[mythtv] DVB Support suggested Roadmap
linux.news at bucksch.org
Sun Apr 20 20:35:41 EDT 2003
ramon.roca at xcombo.com wrote:
>>(Sorry for the HTML
(eh, I reflexively pressed the button to convert to plaintext, duh.)
>Your "basic" is absolutely OK.
>My worry is to find out how I can contribute effectively. I do have to learn a lot of this stuff ans also get better knowledge of the code.
I don't know much about low-level stuff like accessing devices and pipes
either, so we'd be almost on the same page here. If you want to try to
help, you could check, where in the code MythTV opens /dev/video (of
course that's configurable) and how that could be changed to take a pipe
from a program instead. Also how to control the external program
execution. Maybe QT provides functions for that (I'd guess it does), so
check out the QT docs for "exec" or "spawn" functions. You'll likely
find info on how to access pipes around there as well.
>Better than just add the DVB card as another v4l source (/dev/video1) and thus reencode it, which means quality loss, I vote for let it work in the way that PVR does when providing MPEG2 stream.
I totally agree. Reencoding is totally useless for me, then I could just
as well use the analog tuner I have now.
>Although I already have the DVB card, as i told before, I'm not ready for doing 1, I lack expertise and knowledge.
It not as hard as it sounds, it's mainly looking around and finding the
necessary info and then trying out things.
>Since I have VDR running, I can get understanding of the necessary tunning data and I can provide working examples (channels.conf file). DVB drivers provides also utilities (szap, tzap...) for tuning...
As for channels.conf (aggregating the tuning data), see below.
As for using the data, dvbstream takes the tuning info as parameters, so
we're set there, we don't need to care about tuning separately, unless I
am missing something.
dvbstream -f 12441 -p v -s 27500 512 660 | ts2ps 512 660 | mplayer -
> I will only suggest to use a "dvb" compatible format here
> (channels.conf) which is something like "Sky
> News:12552:v:S19.2E:22000:305:306:0:0:3995:0:0:0...". I know that looks
> worst that your format, but think that potentially you could get thousands
> of channels so it's important to feed the database with "compatible"
> that already provides that info, then we don't have to take care on how to
> get updated channel info, unless we write a converter (wich by the way
> hasn't to be difficult).
Yes. Personally, I'd perfer to keep a consistent format internally, i.e.
put the information in the database in the described format and let the
myth programs read from there, that's cleaner within myth and most
likely much faster as well. We can then use a converter from
channels.conf, which fills the database. We have to write a parser for
that fileformat anyways (or adapt an existing one), so I'd suggest to
use a little app reading the channels.conf and placing that info in the
database, which the user runs manually. If you want to write it, it
could be written in a language of your choice (or of the existing
parser), if Isaac accepts that. But I'd consider the stream stuff as
more important, for now as can fill the db manually.
More information about the mythtv-dev