[linux-dvb] DVB file formats

Felix Domke tmbinc at elitedvb.net
Thu Jun 16 14:29:55 CEST 2005


> BTW: I was thinking last night. Do we actually need to know all the PMT 
> entries for the services.
> 
> On the sample for a channel, I have:
> es = <pid> <type> [<language>] [pcr]
> ...
> 
> Where I was expecting there to be a line for each entry in the PMT. 
> 
> However, the only reason for having this information is to speed up lock 
> times. We don't actually need information on _every_ ES - just the last 
> audio/video ES that the user selected. The rest can be pulled from the PMT 
> once the channel is up and running. Comments?
We also use precached PIDs, first for faster zapping, and next to store
the last selected audio-stream.

I know the PID isn't the best criteria for it, but you can't really rely
on other stuff (even a language code) being available. When the PMT is
parsed, and the selected PID is found there, it's kept as the active
pid. otherwise, the first one (or whatever) is choosen, like if there
were no audio pid stored.

I think it makes sense to store them, as you almost get these two
feature for free. You certainly want to cache them on runtime anyway, so
you just have to read them into your cache structure.

If an application don't want to cache, it can just ignore the ES fields
and don't store any. They should be optional.

I agree that not all PMT services should be stored. We're not trying to
cache the PMT.

In our application we have another features, which seemlessly integrates
with the storage of the ES-PIDs:

We have a special per-service flag, which has a meaning like "no DVB
service". If this flag is set, there will be no attempt to parse any DVB
tables, and just take the ES-Pids. We then invent a random SID, thus
having an arbitrary es-pid-combination which behaves like a service.

With this, we support stuff like feeds, with only minimal changes.

Felix




More information about the linux-dvb mailing list