File Format Comparison: Difference between revisions

From LinuxTVWiki
Jump to navigation Jump to search
No edit summary
m (category)
 
(83 intermediate revisions by one other user not shown)
Line 1: Line 1:
==Index==
Comparison of existing DVB file formats.


==THIS IS DEPRECATED. REFER TO THE .h FILES IN LIBDVBCFG FOR ALL FILE FORMAT INFORMATION.==


===Ideas for a services file format===


Current idea:
-----------------------------------------------
<pre>
'''Examination of "Nokia" format'''
[dvbconfig]
version=0.1
date=<unixdateoflastmodification>

[multiplex]
umid = <source_id>:<original_network_id>:<transport_stream_id>:<multiplex_differentiator>
delivery = dvbt <frequency> <bandwidth> <code_rate_hp> <code_rate_lp> <constellation> <transmission_mode> <guard_interval> <hierarchy_information>

[service]
usid = <program_number>:<service_differentiator>
name = <...>
flags = <ignorepmt>
ca_systems = <...> <...> <...> ....
zap_pids = <pid>:<type> ....
pmt_extra = <pid>:<type> ....

[service]
...

[service]
....


[multiplex]
....

[service]
...

[service]
...

[service]
...

</pre>

* Note: flags, zap_pids, and pmt_extra fields above are optional.
* If a channel is encrypted, ca_systems will contain a list of the CA system IDs supported by it, so channels which are unencryptable by the user can be filtered out easily. If a channel is completely unencrypted, there should be no ca_systems key at all.
* Keep file format as simple as possible, with just as much information as needed.
* Any other information can be retieved using the DVB library and parsing PMTs etc.
* zap_pid entries are optional. The user is not expected to add them by hand. They could be automatically extracted by the DVB application on the first tune to the channel in order to accelerate zap times. However, when the service is zapped, the PAT/PMT should be parsed _as well_, and the zap_pids/ca entries updated if they are incorrect.
* <type> in zap_pids/pmt_extra is nominally one of the stream type codes defined in the ISO 13818-1/ITU.T 222.0 for elementary streams in PMT tables. However, this is not possible for stream types like AC3, DTS, videotext etc. These all share the same PMT type (0x81/private). In these cases, instead of the ISO code, special types are defined, currently: _ac3, _dts, _tt, and _pcr.
* We need to have scripts that convert between the old formats and the new in both directions, in order to provide as few hassles as possible to end-users.
* Only one delivery line per multiplex - the above gives an example of a DVBT one. Others might be:

<pre>
delivery = dvbs <frequency> <inversion> <polarization> <symbol_rate <fec_inner>
delivery = dvbc <frequency> <inversion> <symbol_rate> <fec_inner> <modulation>
delivery = atsc <modulation>
</pre>

* The differentiator keys will be calculated automatically if needed. They are to fix problems caused by rubbish in the SI tables (i.e. to fix the numerous Hotbird problems - conflicting network ids, and even service ids). The differentiators should be set to 0 if not needed.
* For a service, the differentiator will be the index into the PAT table of the entry for that service, and will only be used if two or more services in the same multiplex have the same program_number.
* For a multiplex, the differentiator will be based on the delivery parameters as follows:

<pre>
DVBS: ((frequency / (symbolrate/1000)) << 1) | polarisation
DVBT: (frequency / bandwidth)
DVBC: (frequency / symbolrate)
</pre>
Polarisation is 0 for H and 1 for V. Again this will only be used if two multiplexes in the same source are otherwise indistinguishable by just using their original_network_id/transport_stream_ids.

* id lines are not expected to be entered by the user - if they're missing the application should fill them out.
* pmt_extra is a hardwired list of PIDs for channels that do not have a PMT, or are missing entries from the PMT.. e.g. for data transmission channels. Each entry consists of a <pid> and a <type>, where <type> is the same as described above for zap_pids. If this key is present, it should be used to supplement the PMT table entries if a PMT exists.

===Ideas for a seed transponder file format===

This file would contain seed transponder definitions for scanning. It is directly equivalent to the files in util/scan/dvb-*.

* It would be the same format as the new channels file (whatever that may be), only just containing transponders - no channels.
* We could consolidate all the existing seed files into a single file, since the transponders identify what source they are for. Or we could keep it as seperate files for each seed, or seperate files for each DVB type. Whatever is most convenient.
* Perhaps we could find people willing to host these files on mirror sites - so clients could automatically download the latest seed files when asked. Just putting them on the linuxtv.org website might not be good - it might cause lots of unwanted load.


===Ideas for a diseqc configuration file format===

This gives a command sequence of diseqc operations to use to tune to a source.

Example:
<pre>
S19.2E 11700 V 9750 t v W15 [E0 10 38 F0] W15 A W15 t
S19.2E 99999 V 10600 t v W15 [E0 10 38 F1] W15 A W15 T
S19.2E 11700 H 9750 t V W15 [E0 10 38 F2] W15 A W15 t
S19.2E 99999 H 10600 t V W15 [E0 10 38 F3] W15 A W15 T
</pre>


To find the diseqc sequence for a channel, find the source_id, the frequency, and the polarity. Using those,
the entries in diseqc.conf are searched for a matching entry. When found, the associated command string is executed.

Command string example: S19.2E 11700 V 9750 t v W15 [E0 10 38 F0] W15 A W15 t

This matches channels which are from S19.2E, are less than 11700 frequency, V polarity. When matched, it says subtract 9750 from the base frequency, and execute the following diseqc sequence: turn the tone off, 13v, wait 15ms, send a disqec master command, wait 15ms, send tone burst A, wait 15 seconds, turn tone off.

* Use VDR's diseqc.conf - it is simple and to the point.
* Extend the command syntax to include the remaining DISEQC operations (i.e. turn voltage OFF, and control "LNB high voltage").
* Need to have a 'default' entry in case a particular sources is not defined. This should just issue the "back compatable" DISEQC command sequence as described in the DISEQC specs.



===Ideas for a sources file format===

This gives a standard identifier to each satellite cluster as there is no other such standard IDs for them defined anywhere.

Example:
<pre>
S5E Sirius 2/3
S7E Eutelsat W3
S10E Eutelsat W1R
S13E Hotbird 1-(5)-6
S16E Eutelsat W2
Tau-Adelaide A DVB-T transmitter in Australia.
Tuk-BlackHill A DVB-T transmitter in the UK serving the central belt of scotland.
</pre>

* Use VDR's sources.conf - it is simple and to the point.
* Add ids for different DVBT and DVBC networks though. There would have to be an ID for each DVBT transmitter as they all use different frequencies - e.g. Tau-Adelaide. Also (at least in the UK), different DVBT transmitters carry different sets of channels for regional programming.


===Ideas for an adapter configuration file format===

This file would describe the mapping from DVB adapters in a machine to sources they support.

e.g. say you have 1 DVBS(Sirius 2/3), 1DVBS(Eutelsat W3), and 1DVBT(uk-BlackHill), the file could contains entries such as:

<pre>
# <adapterid> <source1>...
DVB0.0 S5E
DVB1.0 S7E
DVB2.0 Tuk-BlackHill
</pre>

Adapterid is a string identifying a piece of DVB hardware. The example above uses "DVB<adapterid>.<frontendid>". This format could be used to do interesting things in the future - e.g. "DVB0.0@someotherhost" could specify a remote DVB adapter. BUT: this sort of feature is _way_ beyond the scope of the library - but it would good not to impose any unnecessary constraints prohibiting it in the library structures/parsing code.

Multiple source ids (as specified in sources.conf) can be specified for each adapter so that multiswitches supporting more than one dish are supported. The diseqc commands necessary to switch between them would be stored in diseqc.conf.


===Ideas for a presets file format===

This format relies on the concept of a Global Service ID (GSID), a Unique Multiplex ID (UMID) and a Unique Service ID (USID) which allow a channel to be identified across the entire space of supported broadcasting types. Well, so we hope :)

The UMID is the value in the id= field of the [multiplex] defintions of the dvbsettings file - i.e.
<pre>
<source_id>:<original_network_id>:<transport_stream_id>:<multiplex_differentiator>
</pre>

The USID is
<pre>
<program_number>:<service_differentiator>
</pre>
(i.e. a USID uniquely identifies a service _within_ its multiplex - not globally)

So a GSID is created by concatenating the UMID and USID together - i.e.:
<pre>
<source_id>:<original_network_id>:<transport_stream_id>:<multiplex_differentiator>:<program_number>:<service_differentiator>
</pre>


Example:
<pre>
[dvbpresets]
version=0.1
date=<unixdate>

[group]
name = Presets

[group.News & Weather]
icon = <icon>

[service]
gsid = S5E:11:12:00:20:00
name = <name>
icon = <icon>

[service]
gsid = S5E:00:23:523:22:90

[group.Movies]
...

[group.Movies.Action]
...

[group.Movies.Horror]
...
</pre>

* File format allows nesting of presets.
* Can embed individual channels.
* Keeps the raw channel definitions seperate from the presets. Therefore presets can be shared between people, and they should refer to the same channels.
* The second [service] above gives an example of a "difficult" multiplex - its original_network_id clashes with some other multiplex's original_network_id. Therefore, the differentiator is used to make it unique.
* Because DVBT networks transmit the same channels, but at different frequencies, depending on which transmitter you are using, the source_ids need an extra wrinkle. A DVBT source_id example is "Tuk-BlackHill". In the services&seeds files, the full source_id is used. However, in the presets file, only the leading "Tuk" part is used so that presets can be shared between people using different transmitters.

===Example usage===

* The application looks at '''adapters.conf''' to determine what sources are supported on the machine.
* It presents a list of channels to the user by interrogating '''channels.conf''' and identifing transponders (and their channels) supported by those sources.
* User asks to watch "Channel9" on source 'S7E'.
* The application interrogates '''channels.conf''' to find Channel9/S7E.
* When found, as it is a DVBS channel, it looks up the diseqc command string in '''diseqc.conf'''.
* Finally, it executes the diseqc command, and tunes to the channel.



===Examination of "Nokia" format===


Satellite/network/transponder/channel listing.
Satellite/network/transponder/channel listing.
Line 26: Line 235:




===Examination of Metzler bros' libdvb XML===
-----------------------------------------------
'''Examination of Metzler bros' libdvb XML'''


Satellite/network/transponder/channel/etc listing.
Satellite/network/transponder/channel/etc listing.
Line 52: Line 260:




===Examination of Metzler bros' libdvb plaintext===
-----------------------------------------------
'''Examination of Metzler bros' libdvb plaintext'''


Satellite/network/transponder/channel/etc listing.
Satellite/network/transponder/channel/etc listing.
Line 76: Line 283:




===Examination of satcodx format===
-----------------------------------------------
'''Examination of satcodx format'''


Channel oriented listing.
Channel oriented listing.
Line 97: Line 303:




===Examination of *zap format===
-----------------------------------------------
'''Examination of *zap format'''


Channel oriented listing.
Channel oriented listing.
Line 117: Line 322:




===Examination of vdr sources.conf===
-----------------------------------------------
'''Examination of vdr sources.conf'''


This gives a standard identifier to each satellite cluster as there is no other such standard IDs for them defined anywhere.
This gives a standard identifier to each satellite cluster as there is no other such standard IDs for them defined anywhere.
Line 137: Line 341:




===Examination of vdr disceqc.conf===
-----------------------------------------------
'''Examination of vdr disceqc.conf'''


This defines diseqc sequences for tuning to a particular channel.
This defines diseqc sequences for tuning to a particular channel.
Line 150: Line 353:
S19.2E 99999 H 10600 t V W15 [E0 10 38 F3] W15 A W15 T
S19.2E 99999 H 10600 t V W15 [E0 10 38 F3] W15 A W15 T
</pre>
</pre>

To find the diseqc sequence for a channel, find the source_id, the frequency, and the polarity. Using those,
the entries in diseqc.conf are searched for a matching entry. When found, the associated command string is executed.

Command string example: S19.2E 11700 V 9750 t v W15 [E0 10 38 F0] W15 A W15 t

This matches channels which are from S19.2E, are less than 11700 frequency, V polarity. When matched, it says subtract 9750 from the base frequency, and execute the following diseqc sequence: turn the tone off, 13v, wait 15ms, send a disqec master command, wait 15ms, send tone burst A, wait 15 seconds, turn tone off.


* Very extensible.
* Very extensible.
Line 164: Line 360:




===Examination of vdr channels.conf===
-----------------------------------------------
'''Examination of vdr channels.conf'''


Channel definitions.
Channel definitions.
Line 183: Line 378:




===Examination of xawtv format===


* I was unable to find a sample config file for xawtv & DVB support (which is still under development in CVS BTW). Please add an example if you find one.
-----------------------------------------------
[[Category:Software]]
'''Ideas for a new channel file format'''


An initial idea for channels:
<pre>
:DVBCHANNELS-0.1

:TRANSPONDER <source_id> <DVBT|DVBC|DVBS|ATSC> <transport_stream_id>
<original_network_id>
fe <frequency> <polarization> <inversion> <symbol_rate> <fec_inner>
fe <frequency> <inversion> <symbol_rate> <fec_inner> <modulation>
fe <frequency> <inversion> <bandwidth> <code_rate_hp> <code_rate_lp> <constellation> <transmission_mode> <guard_interval> <hierarchy_information>
fe <frequency> <inversion> <modulation>

:CHANNEL <program_number> <order_in_channels_list> <group_id>
name <name>
shortname <shortname>
ca <id> <id> ...
es <pid> <type> [<language>] [pcr]
.... (additional es entries)
</pre>

* The TRANSPONDER entries will only have one following fe line - as appropriate to the frontend type indicated.


An alternative format idea:
<pre>
[dvbchannels]
version=0.1

[transponder]
type = dvbt|dvbc|dvbs|atsc
source_id = <...>
transport_stream_id = <...>
original_network_id = <...>
frequency = <...>
polarization = <...>
inversion = <...>
symbol_rate = <...>
fec_inner = <...>
modulation = <...>
bandwidth = <...>
code_rate_hp = <...>
code_rate_lp = <...>
constellation = <...>
transmission_mode = <...>
guard_interval = <...>
hierarchy_information = <...>

[channel]
program_number = <...>
list_order = <...>
group_id = <...>
name = <...>
shortname = <...>
ca = <...> <...> <...> ....
es = <pid> <type> [<language>] [pcr]
</pre>


* Use VDR diseqc.conf and sources.conf as-is, but with a redesigned channels file format.
* Keep file format as simple as possible, with just as much information as needed.
* Any other information can be retieved using the DVB library and parsing PMTs etc.
* es entries are not strictly necessary as all information can be derived from the PMT once you have the program_number. However, it is useful to store these to accelerate channel changing speed.
* <type> in ES is one of the codes defined in the ISO 13818-1 for elementary streams in PMT tables.
* I thought of splitting the second format up further - e.g. having "[es]" sections instead of "es=" lines. I thought that the "es=" style was easier to understand though.


-----------------------------------------------
'''Ideas for a new seed transponder file format'''

This file would contain seed transponder definitions for autosetup.. it is directly equivalent to the files in scan/dvb-*.

* It would be the same format as the new channels file (whatever that may be), only just containing transponders - no channels.
* We could consolidate all the existing seed files into a single file, since the transponders identify what source they are for. Or we could keep it as seperate files for each seed, or seperate files for each DVB type. Whatever is most convenient.
* Perhaps we could find people willing to host these files on mirror sites- so clients could automatically download the latest seed files when asked. Just putting them on the linuxtv.org website might not be good - it might cause lots of unwanted load.


-----------------------------------------------
'''Ideas for a new diseqc configuration file format'''

* Use VDR's diseqc.conf - it is simple and to the point.
* Maybe extend the syntax to include the remaining DISEQC operations (i.e. turn voltage OFF, and control "LNB high voltage").



-----------------------------------------------
'''Ideas for a new sources file format'''

* Use VDR's sources.conf - it is simple and to the point.
* Add ids for different DVBT and DVBC networks though. There would have to be an ID for each DVBT transmitter as they all use different frequency - e.g. Tau-Adelaide.


-----------------------------------------------
'''Ideas for an adapter configuration file format'''

This file would describe the mapping from DVB adapters in a machine to sources they support.

e.g. say you have 1 DVBS(Sirius 2/3), 1DVBS(Eutelsat W3), and 1DVBT(uk), the file could contains entries such as:

<pre>
# <adapterid> <source1>...
DVB0.0 S5E
DVB1.0 S7E
DVB2.0 TUK
</pre>

Adapterid is a string identifying a piece of DVB hardware. The example above uses "DVB<adapterid>.<frontendid>". This format could be used to do interesting things in the future - e.g. "DVB0.0@someotherhost" could specify a remote DVB adapter. BUT: this sort of feature is _way_ beyond the scope of the library - but it would good not to impose any unnecessary constraints prohibiting it in the library structures/parsing code.

Multiple source ids (as per VDR sources.conf) can be specified for each adapter so that multiswitches supporting more than one dish are supported. The diseqc commands necessary would be stored in diseqc.conf.

When an application is asked to tune to "Channel9" on S7E, it can look up which adapters support this channel, and can choose an appropriate one, or reject the attempt.

Latest revision as of 13:51, 15 September 2005

Index

THIS IS DEPRECATED. REFER TO THE .h FILES IN LIBDVBCFG FOR ALL FILE FORMAT INFORMATION.

Ideas for a services file format

Current idea: 

[dvbconfig]
version=0.1
date=<unixdateoflastmodification>

[multiplex]
umid = <source_id>:<original_network_id>:<transport_stream_id>:<multiplex_differentiator>
delivery = dvbt <frequency> <bandwidth> <code_rate_hp> <code_rate_lp> <constellation> <transmission_mode> <guard_interval> <hierarchy_information>

[service]
usid = <program_number>:<service_differentiator>
name = <...>
flags = <ignorepmt>
ca_systems = <...> <...> <...>  ....
zap_pids = <pid>:<type> ....
pmt_extra = <pid>:<type> ....

[service]
...

[service]
....


[multiplex]
....

[service]
...

[service]
...

[service]
...
  • Note: flags, zap_pids, and pmt_extra fields above are optional.
  • If a channel is encrypted, ca_systems will contain a list of the CA system IDs supported by it, so channels which are unencryptable by the user can be filtered out easily. If a channel is completely unencrypted, there should be no ca_systems key at all.
  • Keep file format as simple as possible, with just as much information as needed.
  • Any other information can be retieved using the DVB library and parsing PMTs etc.
  • zap_pid entries are optional. The user is not expected to add them by hand. They could be automatically extracted by the DVB application on the first tune to the channel in order to accelerate zap times. However, when the service is zapped, the PAT/PMT should be parsed _as well_, and the zap_pids/ca entries updated if they are incorrect.
  • <type> in zap_pids/pmt_extra is nominally one of the stream type codes defined in the ISO 13818-1/ITU.T 222.0 for elementary streams in PMT tables. However, this is not possible for stream types like AC3, DTS, videotext etc. These all share the same PMT type (0x81/private). In these cases, instead of the ISO code, special types are defined, currently: _ac3, _dts, _tt, and _pcr.
  • We need to have scripts that convert between the old formats and the new in both directions, in order to provide as few hassles as possible to end-users.
  • Only one delivery line per multiplex - the above gives an example of a DVBT one. Others might be:
delivery = dvbs <frequency> <inversion> <polarization> <symbol_rate <fec_inner>
delivery = dvbc <frequency> <inversion> <symbol_rate> <fec_inner> <modulation>
delivery = atsc <modulation>
  • The differentiator keys will be calculated automatically if needed. They are to fix problems caused by rubbish in the SI tables (i.e. to fix the numerous Hotbird problems - conflicting network ids, and even service ids). The differentiators should be set to 0 if not needed.
  • For a service, the differentiator will be the index into the PAT table of the entry for that service, and will only be used if two or more services in the same multiplex have the same program_number.
  • For a multiplex, the differentiator will be based on the delivery parameters as follows:
DVBS: ((frequency / (symbolrate/1000)) << 1) | polarisation
DVBT: (frequency / bandwidth)
DVBC: (frequency / symbolrate)

Polarisation is 0 for H and 1 for V. Again this will only be used if two multiplexes in the same source are otherwise indistinguishable by just using their original_network_id/transport_stream_ids.

  • id lines are not expected to be entered by the user - if they're missing the application should fill them out.
  • pmt_extra is a hardwired list of PIDs for channels that do not have a PMT, or are missing entries from the PMT.. e.g. for data transmission channels. Each entry consists of a <pid> and a <type>, where <type> is the same as described above for zap_pids. If this key is present, it should be used to supplement the PMT table entries if a PMT exists.

Ideas for a seed transponder file format

This file would contain seed transponder definitions for scanning. It is directly equivalent to the files in util/scan/dvb-*.

  • It would be the same format as the new channels file (whatever that may be), only just containing transponders - no channels.
  • We could consolidate all the existing seed files into a single file, since the transponders identify what source they are for. Or we could keep it as seperate files for each seed, or seperate files for each DVB type. Whatever is most convenient.
  • Perhaps we could find people willing to host these files on mirror sites - so clients could automatically download the latest seed files when asked. Just putting them on the linuxtv.org website might not be good - it might cause lots of unwanted load.


Ideas for a diseqc configuration file format

This gives a command sequence of diseqc operations to use to tune to a source.

Example: 

S19.2E  11700 V  9750  t v W15 [E0 10 38 F0] W15 A W15 t
S19.2E  99999 V 10600  t v W15 [E0 10 38 F1] W15 A W15 T
S19.2E  11700 H  9750  t V W15 [E0 10 38 F2] W15 A W15 t
S19.2E  99999 H 10600  t V W15 [E0 10 38 F3] W15 A W15 T


To find the diseqc sequence for a channel, find the source_id, the frequency, and the polarity. Using those, the entries in diseqc.conf are searched for a matching entry. When found, the associated command string is executed.

Command string example: S19.2E 11700 V 9750 t v W15 [E0 10 38 F0] W15 A W15 t

This matches channels which are from S19.2E, are less than 11700 frequency, V polarity. When matched, it says subtract 9750 from the base frequency, and execute the following diseqc sequence: turn the tone off, 13v, wait 15ms, send a disqec master command, wait 15ms, send tone burst A, wait 15 seconds, turn tone off.

  • Use VDR's diseqc.conf - it is simple and to the point.
  • Extend the command syntax to include the remaining DISEQC operations (i.e. turn voltage OFF, and control "LNB high voltage").
  • Need to have a 'default' entry in case a particular sources is not defined. This should just issue the "back compatable" DISEQC command sequence as described in the DISEQC specs.


Ideas for a sources file format

This gives a standard identifier to each satellite cluster as there is no other such standard IDs for them defined anywhere.

Example: 

S5E     Sirius 2/3
S7E     Eutelsat W3
S10E    Eutelsat W1R
S13E    Hotbird 1-(5)-6
S16E    Eutelsat W2
Tau-Adelaide A DVB-T transmitter in Australia.
Tuk-BlackHill A DVB-T transmitter in the UK serving the central belt of scotland.
  • Use VDR's sources.conf - it is simple and to the point.
  • Add ids for different DVBT and DVBC networks though. There would have to be an ID for each DVBT transmitter as they all use different frequencies - e.g. Tau-Adelaide. Also (at least in the UK), different DVBT transmitters carry different sets of channels for regional programming.


Ideas for an adapter configuration file format

This file would describe the mapping from DVB adapters in a machine to sources they support.

e.g. say you have 1 DVBS(Sirius 2/3), 1DVBS(Eutelsat W3), and 1DVBT(uk-BlackHill), the file could contains entries such as: 

# <adapterid> <source1>...
DVB0.0 S5E
DVB1.0 S7E
DVB2.0 Tuk-BlackHill

Adapterid is a string identifying a piece of DVB hardware. The example above uses "DVB<adapterid>.<frontendid>". This format could be used to do interesting things in the future - e.g. "DVB0.0@someotherhost" could specify a remote DVB adapter. BUT: this sort of feature is _way_ beyond the scope of the library - but it would good not to impose any unnecessary constraints prohibiting it in the library structures/parsing code.

Multiple source ids (as specified in sources.conf) can be specified for each adapter so that multiswitches supporting more than one dish are supported. The diseqc commands necessary to switch between them would be stored in diseqc.conf.


Ideas for a presets file format

This format relies on the concept of a Global Service ID (GSID), a Unique Multiplex ID (UMID) and a Unique Service ID (USID) which allow a channel to be identified across the entire space of supported broadcasting types. Well, so we hope :)

The UMID is the value in the id= field of the [multiplex] defintions of the dvbsettings file - i.e. 

<source_id>:<original_network_id>:<transport_stream_id>:<multiplex_differentiator>

The USID is 

<program_number>:<service_differentiator>

(i.e. a USID uniquely identifies a service _within_ its multiplex - not globally)

So a GSID is created by concatenating the UMID and USID together - i.e.: 

<source_id>:<original_network_id>:<transport_stream_id>:<multiplex_differentiator>:<program_number>:<service_differentiator>


Example: 

[dvbpresets]
version=0.1
date=<unixdate>

[group]
name = Presets

[group.News & Weather]
icon = <icon>

[service]
gsid = S5E:11:12:00:20:00 
name = <name>
icon = <icon>

[service]
gsid = S5E:00:23:523:22:90

[group.Movies]
...

[group.Movies.Action]
...

[group.Movies.Horror]
...
  • File format allows nesting of presets.
  • Can embed individual channels.
  • Keeps the raw channel definitions seperate from the presets. Therefore presets can be shared between people, and they should refer to the same channels.
  • The second [service] above gives an example of a "difficult" multiplex - its original_network_id clashes with some other multiplex's original_network_id. Therefore, the differentiator is used to make it unique.
  • Because DVBT networks transmit the same channels, but at different frequencies, depending on which transmitter you are using, the source_ids need an extra wrinkle. A DVBT source_id example is "Tuk-BlackHill". In the services&seeds files, the full source_id is used. However, in the presets file, only the leading "Tuk" part is used so that presets can be shared between people using different transmitters.

Example usage

  • The application looks at adapters.conf to determine what sources are supported on the machine.
  • It presents a list of channels to the user by interrogating channels.conf and identifing transponders (and their channels) supported by those sources.
  • User asks to watch "Channel9" on source 'S7E'.
  • The application interrogates channels.conf to find Channel9/S7E.
  • When found, as it is a DVBS channel, it looks up the diseqc command string in diseqc.conf.
  • Finally, it executes the diseqc command, and tunes to the channel.


Examination of "Nokia" format

Satellite/network/transponder/channel listing.

Example: 

:SAT "Astra" 19.2 E
:NET "Canal Sat
:TRP 1074 1189500 275000 1 V 0 3/4
:CHN "Canal Sat
:CHN "Hit List" 29461 R
  • Can only represent DVBS.
  • From libdvb - cannot find other examples.
  • Can be edited in a text editor.
  • Easy to parse.
  • Appears to be the format used by an unknown nokia receiver (?)
  • May not be the same across all nokia devices.


Examination of Metzler bros' libdvb XML

Satellite/network/transponder/channel/etc listing.

Example: 

<?xml version="1.0"?>
<satellite>
<transponder type="S" freq="11817000" srate="27500000" polarity="V" >
<service id="8001" ca="1">
<description tag="0x48" type="1" provider_name="CANALSATELLITE" service_name="S$
<ca_descriptor tag="0x09" system_id="0x0500" ca_pid="2" />
<ca_descriptor tag="0x09" system_id="0x0500" ca_pid="5" />
<stream type="198" pid="1251">
</stream>
</satellite>
  • Can represent all FE types.
  • Extensible
  • Can be edited in a text editor, but XML reduces clarity.
  • Easy to parse, but requires XML parser.


Examination of Metzler bros' libdvb plaintext

Satellite/network/transponder/channel/etc listing.

Example: 

LNB ID 2 TYPE 0  LOF1 9750000 LOF2 10600000 SLOF 11700000 DISEQCNR 2
  SAT ID 3592 NAME "Thor 2,3          " LNBID 2 FMIN 10700000 FMAX 12700000
    TRANSPONDER ID 0001 SATID 3592 TYPE 0 FREQ 11229000 POL H SRATE 24500000 FEC 7/8
      CHANNEL ID 0 SATID 3592 TPID 1 SID ca TYPE 0 VPID 2bc APID 2bd ANAME "eng" TTPID c9 PCRPID 2bc
      CHANNEL ID 1 SATID 3592 TPID 1 SID cb TYPE 0 VPID 200 APID 280 TTPID 240
      CHANNEL ID 2 SATID 3592 TPID 1 SID cd TYPE 0 VPID 258 APID 259 TTPID cb
      CHANNEL ID 3 SATID 3592 TPID 1 SID 196 TYPE 0 VPID 384 APID 385 TTPID 12d
  • Can represent all FE types.
  • Exact meaning of some values unclear.
  • Extensible.
  • Easy to edit in a text editor.
  • Easy to parse.


Examination of satcodx format

Channel oriented listing.

Example: 

SATCODX103PANAMSAT 9        TDIC10037200001USA Amer3020PAN009CA______195103000000000000000030000100001ESP__________ica Latina  
SATCODX103PANAMSAT 9        TDIC10037200001Cino Lat3020PAN009CA______195103000000000000000040000100001ESP__________ino         
SATCODX103PANAMSAT 9        TDIC10037200001Exa TV  3020PAN009CA______195103000000000000000050000100001ESP__________            
SATCODX103PANAMSAT 9        TDIC10037200001Hallmark3020PAN009CA______195103000000000000000060000100001ESP__________ Channel Mex
SATCODX103PANAMSAT 9        TDIC10037200001MVS Empr3020PAN009CA______195103000000000000000070000100001ESP__________esarial
  • Likely can only be able to represent DVBS.
  • Not easily editable.. or understood :)
  • Easy to parse.
  • Not extensible.


Examination of *zap format

Channel oriented listing.

Example: 

BBC Radio 1:658166670:INVERSION_OFF:BANDWIDTH_8_MHZ:FEC_2_3:FEC_1_2:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:0:6210:14336
BBC Radio 2:658166670:INVERSION_OFF:BANDWIDTH_8_MHZ:FEC_2_3:FEC_1_2:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:0:6226:14400
BBC Radio 3:658166670:INVERSION_OFF:BANDWIDTH_8_MHZ:FEC_2_3:FEC_1_2:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:0:6242:14464
BBC Radio 4:658166670:INVERSION_OFF:BANDWIDTH_8_MHZ:FEC_2_3:FEC_1_2:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:0:6258:14528
  • Can represent all FE types - but exact FE type is not encoded in the file.
  • Easily editable and understood.
  • Easy to parse.
  • Not easily extensible - you can keep adding on more stuff at the end, but this reduces clarity a great deal.


Examination of vdr sources.conf

This gives a standard identifier to each satellite cluster as there is no other such standard IDs for them defined anywhere.

Example: 

S5E     Sirius 2/3
S7E     Eutelsat W3
S10E    Eutelsat W1R
S13E    Hotbird 1-(5)-6
S16E    Eutelsat W2
  • Easy to parse
  • Extensible (e.g. to -C and -T)


Examination of vdr disceqc.conf

This defines diseqc sequences for tuning to a particular channel.

Example: 

S19.2E  11700 V  9750  t v W15 [E0 10 38 F0] W15 A W15 t
S19.2E  99999 V 10600  t v W15 [E0 10 38 F1] W15 A W15 T
S19.2E  11700 H  9750  t V W15 [E0 10 38 F2] W15 A W15 t
S19.2E  99999 H 10600  t V W15 [E0 10 38 F3] W15 A W15 T
  • Very extensible.
  • The nicest diseqc representation seen so far.
  • Easily editable and understood.


Examination of vdr channels.conf

Channel definitions. 

RTL Television,RTL;RTL World:12187:hC34:S19.2E:27500:163:104=deu:105:0:12003:1:1089:0
SAT.1;ProSiebenSat.1:12480:vC34:S19.2E:27500:1791:1792=deu;1795=deu:34:0:46:133:33:0
Sky News;BSkyB:11597:vC56:S19.2E:22000:305+131:306=eng:0:0:28707:1:1026:0
  • Can represent all FE types.
  • Derived from zap format.
  • Hard to parse.
  • Hard to extend without adding more complexity.
  • Not easy to understand.
  • Editable in text editor.


Examination of xawtv format

  • I was unable to find a sample config file for xawtv & DVB support (which is still under development in CVS BTW). Please add an example if you find one.
Retrieved from "https://www.linuxtv.org/wiki/index.php?title=File_Format_Comparison&oldid=5911"