File Format Comparison

---

Ideas for a services file format

Current idea:

[services]
version=0.1
date=<unixdateoflastmodification>

[multiplex]
id = <source_id> <differentiator> <original_network_id> <transport_stream_id>
delivery = dvbt <frequency> <bandwidth> <code_rate_hp> <code_rate_lp> <constellation> <transmission_mode> <guard_interval> <hierarchy_information>

[service]
id = <program_number> <differentiator>
name = <...>
ca = <...> <...> <...>  ....
zap_pids = <video_pid> <audio_pid> <pcr_pid> [<ac3_pid>]

[service]
...

[service]
....


[multiplex]
....

[service]
...

[service]
...

[service]
...

• 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/ca 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 is one of the stream type codes defined in the ISO 13818-1/ITU.T 222.0 for elementary streams in PMT tables.
• 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 are optional, and 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).
• 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 in some manner. Will describe this when I've thought about it a bit more.
• id lines are not expected to be entered by the user - if they're missing the application should fill them out.

An alternative idea, now discarded:

: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)

---

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.

---

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.

---

Comparison of existing DVB file formats.

---

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.