[linux-dvb] DVB file formats

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>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?

Felix



[Index of Archives]     [Linux Media]     [Video 4 Linux]     [Asterisk]     [Samba]     [Xorg]     [Xfree86]     [Linux USB]

  Powered by Linux