[mythtv] DVB Support suggested Roadmap

[Ben Bucksch]

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

ramon.roca at xcombo.com wrote:

> So what I am pointing is that perhaps better than constructing a 
> complete new story for mythtv, maybe the best is to link both projects.

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 
architecture/design is usually so vastly different that it costs far 
more time to merge the projects than to implement the needed features in 
one project natively. And with merging projects, you usually get a 
hybrid beast that's a pain for both developers and users because of the 
inconsistencies.

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 
providing a more flexible design. In contrast, there are a lot of tasks 
to solve for using VDR from MythTV. For example, controlling VDR 
scheduling from MythTV, merging record lists, conversion of files after 
we moved to MythTV's player, users having to set up yet another client 
and server (why should I bother with MythTV at all, then?) etc..

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).
Please see below at "Basic tuning", if you think that's enough to enjoy 
basic


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?


  1. Basic tuning


  1.1. Goal

Make DVB work at all


  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.


  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".
    * 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.