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 [multiplex] 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 moment.
