[mythtv] DVB Support suggested Roadmap

[ramon.roca at xcombo.com]

>   (Sorry for the HTML, but I used a lot of structural formatting. There
> is a plaintext version, if you perfer that.)

And I'm ashamed of still using Outlook as an email client! I'm new on Linux
but I hope to drop all the ms stuff as soon as I can.

> Although I haven't looked at VDR at all, I think that merging different
> projects with overlapping funtionality, with the motivation to get a
> superset of functionality, is usually something not viable. The

I do have VDR already. That's right, that provides a lot of overlapping,
which is not good.

> I think all that applies in this case. Although I haven't looked that
> deeply into it, the changes needed to support DVB in MythTV seem minor
> to me in comparison to what you are proposing. To get "good" DVB
> support, a few more changes will be necessary, but I think that's still
> less work and additionally would greatly benefit MythTV in general, by

Nice to hear that. Maybe I was speaking because of my current level of
understanding of all of this. I do still have a lack of knowledge. Your
"attack plan" is already more precise than my "general thinkings", so just
lets go in that direction.

> So, the general route I'd propose would be to first try to implement DVB
> in a very simple, maybe slightly hackish way, to MythTV, which I believe
> could be done within a few days. Several people have issued interest in
> making MythTV more general and providing a solid base for DVB support in
> it, so I am optimistic about "good" DVB support in the long term (6-9
> months).

:-D

> Please see below at "Basic tuning", if you think that's enough to enjoy
> basic
>

Your "basic" is absolutely OK. In fact with the roadmap that I was writing,
that only happens until phase 2, you're a lot ahead. I've already tried in
the way that Edward Wildgoose is pointing in his post, but without success,
then I've just added a button that calls a shell that handles the alsa mixer
to change the sound settings and kvdr (I'd already it installed) and worked.
No big deal on this.

>
> Funnily, I also wrote an "DVB attack plan" yesterday, but didn't post it
> yet, because I wasn't entirely confident with it yet. I guess I'll just
> post it now:
>
>
>
> Here is my current (personal?) idea what's necessary for DVB support. I
> haven't looked much at the MythTV code yet (only DB layout), to see how
> it handles channel tuning. Please correct me. Did I miss something?
>

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. Maybe, by
now,  I'm going a start just doing the i18n translation to Spanish, that
will provide me a better understanding.  I'm still a newbie on Linux, but I
already love it.

>
>   1. Basic tuning
>
>
>   1.1. Goal
>
> Make DVB work at all

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.
>
>
>   1.2. Tasks
>
>    1. Run userspace demultiplexer. I see 2 alternatives:
>           * Running dvbstream and ts2ps as external programs. Need to
>             look into how to invoke it from mythtv and how to feed the
>             data from them to mythtv. The potential problems I see are
>             accepting streams from pipes rather than devices as well as
>             controlling external programs, including shutting them down.
>             Any help here would be appreciated.
>             Advantage is that this might be beneficial to other input
>             sources later which can be invoked via the commandline and
>             pipe an MPEG stream (DVD, whatever).
>           * Merge and adapt dvbstream and ts2ps and to make it an
>             alternative to the current tuner / recorder.
>             Advantage is that it seems cleaner to me from a code design
>             standpoint. It's unclear what would be more work.
>             Disadvantage is that it's basically a fork and would need to
>             be updated to upstream once in a while.
>    2. Feed demux with tuning data (incl. PID) from the mythtv database,
>       add necessary info to db.
>    3. Optionally make the normal tuner use the new db fields.
>
> If my time permits, I might do 2 and maybe 3. I don't have a DVB card
> yet (and can't connect one atm, in fact it's unclear, if I can at all),
> so if somebody else could cover 1, that would be great.
>

Although I already have the DVB card, as i told before, I'm not ready for
doing 1, I lack expertise and knowledge. If someone else can, great, if not,
maybe I'll can but that could be a few weeks from now.
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...
>
>   1.3. Database changes
>
>     * Add a "tuning" varstr column to table channel, which will keep a
>       list of tuning parameters specific to a tuning method, parameters
>       separated by "|", name/value separated by "=", e.g.
>       "channum=SE4|finetune=3" or "pos=19.2O|freq=12483|pol=v".

that looks good since will provide enough flexibility for all the
parameters. 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" sources
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).

>     * Maybe remove finetune column for new setups, add that information
>       to tuning column, but keep reading the finetune column for now for
>       backwards compat.
>     * Add "subtuning" varstr column, same formal format as tuning. E.g.
>       "VPID=255". If channels only differ in subtuning and the tuning
>       column matches, they can be tuned to and recorded at the same time
>       (see below).
>       Not sure, if that should be considered a hack in the light of more
>       generic solutions. I guess we should just add it for now and then,
>       when we have better solutions, provider upgraders an SQL script
>       which adds subtuning to tuning ala tuning = tuning + "|" +
subtuning.
>
>
>   1.4. Sideeffects
>
> Incidentially, making the normal analog tuner use channum and finetune
> from tuning column, not channum and finetune columns, will allow
> European users to abuse "channum" as channel "preset" as a temporary
> hack until we have the channel redesign.
>
>
>   2. Advanced tuning
>
>
>   2.1. Goal
>
> Allow recording several channels from the same transport stream at once
> with a single tuner card.
>
>
>   2.2. Tasks
>
> Make scheduler do a string (better yet parameter) comparison of the
> channel.tuning column to see, if 2 channels can be tuned to at the same
> time (if so, there is no conflict). I am not sure, how much needs to be
> done here - how much of the current design already allows, if we need
> some redesign, e.g. concept of a station and <rak at cs.man.ac.uk>
> <mailto:rak at cs.man.ac.uk>'s input plugins, which would then have to
> answer the question, if there is a conflict.
>
>
>   2.3. Database changes
>
> None apart from those in the "Basic tuning" step.
>
>
>   2.4. Sideeffects
>
> Nothing significant expected
>
>
>   3. Input plugins
>
>
>   3.1. Goal
>
> Abstract gathering of video/audio streams (raw or compressed) and the
> relevant tuning, including conflicts.
>
> May not be necessary, but beneficient, for DVB, thus not detailed here.
>
> Significant DB and code changes.
>
>
>   4. Channel redesign
>
>
>   4.1. Goal
>
> Separate "channel" and "station". Automatic chosing of the best input
> source available for a given station. UI updates to (optionally) hide
> internal tuning details like channum from users.
>
> May not be necessary, but beneficient, for DVB, thus not detailed here.
>
> Significant DB and code changes.
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at snowman.net
> http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-dev
>
>
>

Well, that's a start! :-)