[linux-dvb] DVB file formats

Andrew de Quincey adq_dvb at lidskialf.net
Thu Jun 16 14:45:38 CEST 2005

On Thursday 16 June 2005 13:29, Felix Domke wrote:
> > 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.

Yeah, these are exactly my thoughts too.

> 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.

Do you mean stuff like a feed from an mpeg2 encoder? 

I've got something like this as well. In the new format, I was thinking you'd 
create a new multiplex, and have a new delivery type... e.g. for a v4l source 
you might have

source_id = Asomething
delivery = v4l <v4l specific parameters>

Then you just make up the remaining multiplex settings and add in your channel 
entries as normal.

But I don't want to get into that right now - I'm just thinking of DVB for the 

More information about the linux-dvb mailing list