> 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
