[FFmpeg-devel] [bug/patch] MPEG-TS muxer: PCR not in sync with PTS/DTS

Michael Niedermayer michaelni
Wed Jul 22 00:32:29 CEST 2009

On Tue, Jul 21, 2009 at 05:24:53PM +0200, Niobos wrote:
> I'm trying to transcode a video file to h264/x264 + aac into an MPEG-TS 
> container. FFmpeg almost immediately (after a few seconds encoding) warns 
> me that "dts < pcr, TS is invalid". When I try to play the resulting 
> TS-file, it stops playing around the timestamp the warning showed up. I 
> tried playing on iPhone and VLC, both show the problem.
> I only have a limited knowledge of MPEG-TS and ffmpeg, so be warned.
> ffmpeg (libavformat/mpegtsenc.c in particular) calculates a muxrate from 
> the stream bitrates. The PCR is generated from this muxrate; the PTS (and 
> DTS) are generated from the stream itself.
> The calculated muxrate is too low, this causes the stream (DTS) and 
> container (PCR) to slowly drift apart. Specifying a higher -muxrate on the 
> command line solves the "DTS < PCR" warning.
> I'm not an expert programmer, but I gave it a shot to write a patch:
> * mpegts-varname-freq-period.diff : Pure cosmetics : I was trying to 
> understand the calculation-code. There are 3 variables 
> {sdt,pat,pcr}_packet_freq. They contain the number of packets between an 
> {sdt,pat,pcr} insertion. I suggest renaming these to 
> {sdt,pat,pcr}_packet_period. A higher *frequency* means less time between 
> items, this is not how the vars are used in the code. A higher *period* 
> means more time between the items, which _is_ how they're used. (period = 
> 1/frequency)
> * mpegts-overhead-calc.diff : Algorithm change : I rewrote the overhead 
> calculations. The PES overhead is correct for my specific case (1 PES per 
> video frame, 1 PES per 150ms audio), but might need some work to be more 
> generic. The PAT, PMT, SDT and PCR overhead calculations should be correct; 
> the original code was wrong: a _longer_ time between PCRs would _increase_ 
> the overhead...
> The resulting code works much better, but the PCR still drifts apart from 
> the DTS. A "normal" MPEG-TS contains a NULL-stream to keep the required 
> bitrate constant. Another way to implement it would be to indicate a rate 
> incontinuity and change the muxrate. I consider inserting NULL packets 
> easier. The third patch is a try to implement this in ffmpeg:
> * The muxrate is put at 2% higher than calculated
> * If DTS - PCR becomes larger than 1.5 seconds (just a guess, hardcoded for 
> now) one (or more) NULL-packet(s) is (are) inserted to get the PCR near the 
> DTS again

If you do work on mpegts, maybe you want to look at our mpeg ps muxer it
should implement the mpeg buffer model correctly and IIRC mpeg-ts and ps
are similar ...
also just in case you didnt, read the mpeg specs

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090722/607f0e73/attachment.pgp>

More information about the ffmpeg-devel mailing list