[linux-dvb] Re: channels.conf syntax?

[Jamie Honan <jhonan@optusnet.com.au>]

> I must admit that the ?zap formats suck, but so does vdr's format, IMHO.
> 
> Anyway, the main problem is that there are too many different formats.
> It would be nice to agree on a standard format and have a simple library
> to support it. I would like to know how other DVB software authors think
> about that.
> 
> (Besides channel lists, we also need a standard way for configuring
> antennae setups / DiSEqC stuff.)

Yes, if we could all agree, then we'd all be in agreement :)

Seriously, the vdr format is simple; one line represents
one 'program' that a user would want to watch, but doesn't quite
cover all bases.

First of all, the information is not really as static as
'television channels'. Programs come and go, and services require
'rescanning' from time to time. For example, Australian television
stations reconfigure their names and lineups from time to
time.

Satellites do this as well, even more so as frequencies come on and
off (look at the lyngsat site, not for nothing that there is a date
column).

Scanned information has to be merged with previous information.
You have to have some way of having favorites, and things you
don't really want to bother with. Again Australian digital television
stations like to have the same program on different PID streams,
you simply want to ignore the other two copies. So you want to
remember that named services are to be associated with 'ignore'
or 'favorite - football' on a rescan.

The information is really hierarchical.
For example, repeating the FEC, guard etc., is really pointless
for a number of programs sharing the same frequency. In addition,
although a frequency has associated FEC and other characteristics,
you don't care if your recieving card is capable of auto detecting.

With satellites, you have a variety of equipment configuration that
may be needed, the LNB configuration and DiSEqC as alluded above.

Here's the format from dvbsak that I think shows expandability,
readability and simplicity:

transport_stream {
        id = 0x0009;
        original_network_id = 0x1000;
        sat_tuning_info {
                frequency = 12278000;
                symbol_rate = 30000000;
                polarization = 0;
        }
        service {
                id = 0x0064;
                pmt_pid = 0x0101;
                type = 144;
                name = "aGuide";
                provider_name = "A";
        }
        service {
                id = 0x238D;
                pmt_pid = 0x0623;
                type = 144;
                name = "aCar";
                provider_name = "A";
        }
}

It's not _THE_ answer, but certainly as good as the gourd and the sandal
:)

There are other associated lists that have to be kept.
For example for a rescan, you need a way of doing this as quickly
as possible, and keeping a list of possible frequencies is
one way.

But associated with such a list, other information is needed :
Possible FEC, carrier, bandwidth. In addition, in Australia,
broadcasters may choose to operate with a +/- 125 kHz offset from the 
published centre frequency. 

I haven't even got to CAMs.

Jamie



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