[linux-dvb] DVB file formats

Andrew de Quincey adq_dvb at lidskialf.net
Thu Jun 16 04:35:43 CEST 2005

On Thursday 16 June 2005 02:30, Felix Domke wrote:
> >>I agree it would be good to use the DVB specified ONID/TSID. However,
> >>I am not using that on purpose because I have found several instances
> >>of transponders with what appear to be "default" settings for these
> >>values.. i.e. the IDs are the _same_ as on other transponders.
> >
> >...
> > satellite (if both are available)... OTOH, services might move and their
> > ONID:TSID:SID might change, but it will still be the same service. For
> > such cases, referencing the service name would be better, but some
> > service names can be found several times, e.g. I think there are a couple
> > "Bloomberg"'s on ASTRA 19.2°E... Maybe the presets file should contain
> > ONID:TSID:SID _and_ service name (and maybe network and provider name)
> > and even the adapter ID, so that the application can then look for the
> > closest match.
> Our practical approach was to add a "namespace" to the ONID:TSID:SID.
> For "sane" sources, like Astra 19.2 (are there any other? :), the
> "namespace" is just the source-id, let it be "0192" or whatever.
> For non-sane sources, a heuristical approach is used to determine if the
> ONID/TSID is considered as "good enough". If not, a hash of the
> Transponder data is added (for example, some bits of the frequency - yes
> i know that this doesn't work perfectly in some border-cases, but it's
> still far better than ignoring these cases at all).
> We thus end up with something like "00c00000:0001:044d" as a unique
> transponder id, or something like "00822acd:ffff:0001" in case of a bad
> one. (as you see, in this case the namespace consists of 16bits "orbital
> position" and 16 bits "0000 in the  good case" or "hash in the bad
> case", but that's just one way to do it.)
> Then, services get this namespace as well, for example
> "00c00000:0001:044d:6dca" uniquely references to "Das Erste" on 19.2E.
> This has some advantages:
>  - Linkage ("Premiere Sport" as a very bad example - unfortunately,
> there aren't any better ones..) is still possible. You just keep the
> namespace, and replace the rest with the given onid-sid-pair.
>  - Services on different sources ("ZDF" used to have the same ONID:TSID
> on Astra 19.2E and Hotbird once - not sure if that's still the case) are
> separated (and that's good - you don't want merge them)
>  - "Bad" transponders don't need any special intervention other than in
> the scanning part of the application. You need no other workarounds or
> stuff, just save your tuning parameters together with the
> "namespace:onid:tsid"-id.
>  - namespace:onid:tsid/sid are exchangeable between systems, so you can
> sync favourite lists or whatever (Note that this has a small problem
> with "bad" transponders, but i don't have any other idea how to fix
> that. It will work in most of these cases, too.)
>  - you can insert arbitrary transponders to your list (by just inventing
> a namespace:onid:tsid) to add non-dvb services (like feeds or stuff),
> and all the service handling function work like for any other service.
> We keep the general advantages of referencing services "in the way it's
> meant to be:" (onid+sid) , like:
>  - Services can move / rename, and no rescan is required, they even keep
> their place in the favourite lists
>  - you only need the SDT while scanning (no PAT/PMT scanning which is
> error prone as some services might not be available all the time)
> I know that this handling is a big "non-standard", and some people don't
> like it. However, it was the method which was considered to be "most
> user friendly together with being technically (almost) sane". Ok, it's a
> compromise, but of all options, I like it most.
> Any thoughts of this?

Sounds interesting - I'll have to mull it over for a bit, but it definitely 
sounds like a strong possibility.

More information about the linux-dvb mailing list