[linux-dvb] DVB file formats
mws at twisted-brains.org
Thu Jun 16 14:00:55 CEST 2005
On Thursday 16 June 2005 13:51, Andrew de Quincey wrote:
> On Thursday 16 June 2005 12:42, Johannes Stezenbach wrote:
> > Andrew de Quincey 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?
> > You need he pcr pid, too, but other pids are superflous for fast
> > zapping (well, maybe + ac3 pid).
> Ah k, have added the PCR PID.
> Wouldn't the AC3 pid be the same as the audio PID though? I mean - the user
> wouldn't want to play a non-AC3 audio stream AND an ac3 stream at the same
> I've updated the wiki with the latest round of ideas, including the following:
> zap_pids = <video_pid> <video_type> <audio_pid> <audio_type> <pcr_pid>
> Would that do what you want? or does it need tweaked...
from point of view "user" that's right.
but, ac3 streams are not sent permanently, so if the user chooses to have
ac3 but thatone is missing in current es you might want to have a fallback to "normal" audio.
imho saving all those pids (that can change within each pmt version change) is not really an advantage.
to have them cached within the running session of an dvb-apps for accellerated zaptimes is right.
> linux-dvb mailing list
> linux-dvb at linuxtv.org
More information about the linux-dvb