Author: Vic Date: To: hampshire Subject: Re: [Hampshire] Converting a .TS Video Stream file
> If you have no audio then this is quite possibly to do with the ID of the
> audio stream (PID) not being what the transcoding program expects and
> therefore being ignored. TSes consist of a number of Packetized Elemental
> Streams (PES) each of which has a PID that the player uses to look up in a
> data table or to make an assumption as to what the stream is (audio,
> video, teletext, RS422 data, etc.) Big problems happen if different values
> are used, the data table doesn't get read and the player assumes what the
> stream types are based on assumed default numbers for the PIDs .
Oooh - that would be a very buggy implementation.
The PIDs to use for PES streams and PCR are found in the PMT for that
channel. The PMT is found in a PID as described by the PAT. MPEG PSI is a
really simple heirarchy...
> Can you
> find a utility to find out the stream IDs in the file and demux the
> streams from the file or alter the PIDs in place? You may need to alter
> (remap) the PIDs to the values your converter program expects or to tell
> the converter what the audio, video and PCR PIDs in the file are.
I would file a bug report against the converter; PES streams should be
handled on any non-reserved PID. This gets conmplicated slightly when you
go to ATSC (they have defined PIDs for each channel), but that's a subset
of the MPEG requirements.
> If so you may have an issue with the program not correctly
> using the Program Clock Reference (PCR) and Presentation Time (PT) to
> display them at the correct times.
I was thinking just the same - sounds like another bug in the decoder.
If the decoder in question has been anywhere near ST's dvbref refence
software, it'll be the same A/V sync bug that was in there when all the
Sky boxes first shipped - the clock was recovered, but due to a hardware
"feature", the STC could only be rate-locked, not value-locked to the PCR
(the register wasn't writeable). The decoder software then logs the
difference between STC and PC, and uses that as an offset when calculating
presentation tmiings.
Unfortunately, this offset was measured independently for audio and video
- so each stream played back at the right rate, but the synchronisation
between them was essentially random. I fixed this before I left ST, then I
fixed it again for a number of manufacturers, then I kept on seeing it in
the field (the "wall of TVs" they do in shops is a dead giveaway - the
pictures weren't synchronised between different displays).
