[Ffmpeg-devel] mpeg transport streams

Måns Rullgård mru
Fri May 27 12:38:56 CEST 2005


"Eric L. Hernes" <eric at hernes.ws> writes:

> Hi all,
>
> I've been working on encoding transport streams.  I am playing the
> files through a digital cable distribution, hardware multiplexer, QAM
> mod, etc.  Attached are three sets of I've been using to generate
> transport streams that play on the set top.
>
> The changes to mpegtsenc.c are
> * Send full frames as PES packets rather than breaking them into
> * transport sized blocks.

Oversized frames are not handled properly.  I-frames exceeding 64k are
not uncommon at moderate bitrates.

> * Properly stuff the adaptation field if a packet is short.
> * Calculate a PCR from the PTS - framesize

It's not that simple.  The PCR doesn't have any direct relation to the
PTS.  The PCR is defined as the exact time the bits comprising the PCR
leave the muxer (pretend it's real-time), whereas the PTS is the time
(as given by the PCR) at which a frame should be displayed.  The
elementary streams may have a variable bitrate (within VBV
constraints), so the offset between PTS and PCR will vary.  The only
requirement is that the PTS never be less than the PCR.  Allowing a
few additional milliseconds for decoding is usually a good idea.  The
allowed PCR jitter is 500 ns, and your method doesn't get anywhere
near that.  Also note that the maximum interval between PCR values is
100 ms (40 ms being commonly used), whereas PTS values may have up to
700 ms intervals.

Another problem with your muxer is that it doesn't interleave the
streams at the TS packet level.  VBV buffer sizes often approach a
full second, so a transmission time of a few hundred milliseconds for
a single frame is not unlikely.  If this happens, and there is no
interleaving of audio data, the audio decoder is likely to underrun
unless it has a very large buffer, which is unusual with hardware
decoders.

-- 
M?ns Rullg?rd
mru at inprovide.com





More information about the ffmpeg-devel mailing list