[linux-dvb] DVB file formats
Andrew de Quincey
adq_dvb at lidskialf.net
Thu Jun 16 02:05:18 CEST 2005
On Thursday 16 June 2005 00:21, Robert Schlabbach wrote:
> From: "Andrew de Quincey" <adq_dvb at lidskialf.net>
> > http://www.linuxtv.org/wiki/index.php/File_Format_Comparison
> > Please let me know your thoughts.
> I'm not sure I fully understand your format. You have a "section" named
> "[transponder]" in there, and under it transponder data for one transponder
> (or channel). Where do you put the other transponders, or do you only store
> one per file?
In the current format, you would just create more than one [transponder]
section. [channel]s simply belong to the most recent [transponder] seen.
> BTW, I don't like the term "transponder" as it is specific to satellite
> reception. Microsoft uses the term "locator" in their unified tuning model,
> and this seems more appropriate to me.
Hmm, yes that is perhaps a good idea.. I was thinking it might be cool to
extend this to other types of... locators? (e.g. v4l devices)... in which
case transponder is even less appropriate. I'm not sure "locator" is quite
the word I would choose. but I can't think of anything better right now.
> FWIW, in my Windows application, I use the good old Windows "INI" file
> format, and the format is unified for DVB-C/S/T. The scanner "seed" files
> look like this:
> ; Name=Frequency;Polarisation;Bandwidth;Modulation;SymbolRate;CodeRate
> Trp 1 (1F)=11214250;1;-1;20;22000;6
> Trp 3 (1C)=11243750;1;-1;20;22000;6
> (for DVB-S) -or-
> CC 02=113000;-1;8;3;6900;-1
> CC 03=121000;-1;8;3;6900;-1
> (for DVB-C) -or-
> CH 05=177500;-1;7;-1;-1;-1
> CH 06=184500;-1;7;-1;-1;-1
> CH 07=191500;-1;7;-1;-1;-1
> (for DVB-T)
> I set unused/unneeded values to -1. This allows only one set of locators
> for one transmission system to be stored in a file, but then again I don't
> think it makes much sense to mix them. But if you wanted to store e.g. the
> transponder data for several satellite positions, how about appending them
> to the section name, e.g.
> [Locators.ASTRA 19.2°E]
> [Locators.HotBird 13.0°E]
The extended locators you suggest isn't flexible enough for what I need this
file format to support unfortunately. It would work, yes, but I prefer the
seperate "source" ids for use in the adapter.conf mapping file, and also the
automatic keying into the diseqc.conf file.
> BTW, originally I even used the same file for DVB-C and DVB-T... It might
> be a good idea to add an identification section, though, like your
> "dvbchannels" one, best also specifying the transmission system type, e.g.
I don't want to impose restrictions like that - for my purposes, putting all
types of transponders together in one file is exactly what I want to do. As
for the type of locator/transponder, in each [transponder] section, the
dvbs=, dvbt=, dvbc=, etc key tells you what type of transponder it is.
However, I admit putting them all in one file is not appropriate for all
purposes. If someone else doesn't want to mix the types, there is no
restriction on them only putting one type of transponder in each file; its
entirely up to them.
> Now the scanner will read the above locator file, and output its results in
> a similar format:
> 1:1008=Trp 8 (1F);11317500;2;-1;20;22000;6
> 1:1008:29802=ASTRA;DCH1;DISNEY CH. +1;1
> You could also add other data, e.g. the encryption system.
> The actual TV application then reads the Locators section and then the
> Services section and retrieves the corresponding locator data for each
> service by the ONID:TSID pair (as per DVB specification).
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. Specifically some of the weirder
channels on Hotbird have this problem. Or they did a few years ago - they may
be fixed now.
I'm sure I remember seeing a transponder where all the channels had the same
service_id as well :(
> For the TV
> application to store presets, I use another section in the same file:
> Now this could definitely be more sophisticated, e.g. to allow several
> presets groups. A simple extension would be:
> This could even be taken several levels deep:
> I'm not sure, though, if it is good to keep the presets and the scanner
> output together in one file, as the presets are a user preference, whereas
> the scanning results are not, and might be updated with a new scan. OTOH,
> there is somewhat of a relationship between the presets and the scan
> results... An alternative solution would be to make the presets somewhat
> independent of even the service identifiers, and leave it up to the
> application to find a matching service. Then you could get away with
> something as simple as this:
> And the application would try to find the closest matching service name...
> You could enhance this by adding a transmission system preference, e.g. if
> you prefer DVB-S reception over DVB-T...
Aha, a presets file is something I hadn't considered. I'd definitely want to
keep it seperate from the other files though.
> Just my thoughts,
Thank you very much!
More information about the linux-dvb