[linux-dvb] Re: Channel database format for dvbsak

[Holger Waechtler <holger@convergence.de>]

Juha Yrjölä wrote:
> Hi all,
> 
> I'm starting to write a channel list for dvbsak. I can choose at
> least three different formats of storing the list:
> 
> a) XML, using libxml
> 	+ Simple to add additional fields (e.g. VES1820 register values)
> 	+ Lots of parsers in different programming languages can be used
> 	+ Standardized
> 	- Depends on libxml
> 	- A bit hard to read

XML is not less proprietary than everything else, you always define the 
fields on your own - at the end no program will be able to read your 
channel list that does not has explicit support for your format.

If you use a tag-based format it's easy to add new fields as well, even 
if I don't understand what you want to do with register values in 
channel lists...


> b) scconf (from OpenSC <http://www.opensc.org>)
> 	+ Simple to add additional fields
> 	+ Minimal effort on my part =)
> 	+ Readable by humans (or at least C programmers =))
> 	- Depends on scconf
> 	+ ... which isn't too large and can easily be embedded
> 	  in dvbsak package
> 	- scconf depends on flex (until someone writes
> 	  a lightweight replacement parser)

I don't know opensc, I'll first have to take a look on this before I can 
say something useful...

(Flex is no dependency, flex is a tool;)


> c) Proprietary format
> 	- Somewhat difficult to add additional fields
> 	- Needs a lot of coding!
> 	+ No dependencies

I suppose an optimal self-defined format is much easier to code than the 
solutions above. I'd propose a tag-based binary format in addition to 
format (b).



> So a) could look like this (adapted partially from dvbtune):
> 
> <transport_stream id="0x0003" orig_nid="0x1234">
>   <sat_tuning_info>
>     <frequency>12345</frequency>
>     <symbol_rate>12345</symbol_rate>
>     <polarity>h</polarity>
>   </sat_tuning_info>
>   <cable_tuning_info>
>     <frequency>250000</frequency>
>     <symbol_rate>7146</symbol_rate>
>     <modulation>64-QAM</modulation>
>     <ves1820_regs reg5="123" reg7="231" />
>   </cable_tuning_info>
>   <ter_tuning_info>
>     ...
>   </ter_tuning_info>
>   <descriptor tag="0xab" data="123456" />
> 
>   <service id="0x0135" ca="1">
>     <description type="1" provider_name="Telenor" service_name="Canal+ BLÅ" />
>     <stream type="3" pid="0x02AC">
>       <language code="fin" type="0" />
>       ...
>     </stream>
>     <stream type="2" pid="0x0206">
>     ...
>     </stream>
>   </service>
>   <service id="0x0134" ca="1">
>     ...
>   </service>
> </transport_stream>
> 
> I'm not too fluent in XML, so forgive me if there's something really silly. =)

(XML looks always silly to me;)



> And b) would look like this:
> 
> transport_stream 0x0003 {
> 	original_network_id = 0x1234;
> 	descriptor = "ab:123456";
> 	descriptor = "cd:654321";
> 	sat_tuning_info {
> 		frequency = 22345;
> 		symbol_rate = 12345;
> 		polarity = h;
> 	}
> 	cable_tuning_info {
> 		frequency = 250000;
> 		symbol_rate = 7146;
> 		modulation = 64-QAM;
> 	}
> 	service 0x0135 {
> 		ca = true;
> 		type = 1;
> 		name = "Canal+ BLÅ";
> 		provider_name = "Telenor";
> 		stream 0x02AC {
> 			type = 3;
> 			language = "fin";
> 		}
> 	}
> 	...
> }
>
> As for c), any suggestions? =)

what about binary dumped and endian-corrected structs with a tag/length 
pair before? This is both extensible and very simple to code.

On the performance side you won't ever find a faster parser. Neither one 
with a smaller code size.

Maybe you don't even need endian correction if you use the format not 
for channel list distribution but only to save channel lists between 
program starts...


> What do you guys think? Which should I choose? Any other formats I
> should consider?

Option 2 for debugging and option 3 for real-world applications on 
settop boxes with limited memory.

Holger



--
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.