[Ffmpeg-devel] [PATCH] generated PTS in MPEGTS wrong
Thu Mar 2 22:07:22 CET 2006
Michael Niedermayer <michaelni at gmx.at> writes:
> On Thu, Feb 23, 2006 at 10:55:58AM +0100, Alexander Kurpiers wrote:
>> The current code in mpegtsenc.c tries to squeeze everything in PES
>> packets of same size (DEFAULT_PES_PAYLOAD_SIZE), combining packets to
>> always output complete packets. The PTS is included in every PES
>> generated and is taken from the packets passed to mpegts_write_packet().
>> This leads to wrong PES packets.
>> The MPEG-2 system standard says ( 22.214.171.124 Semantic definition of fields
>> in PES packet ):
>> "... In the case of video, if a PTS is present in a PES packet header it
>> shall refer to the access unit containing the first picture start code
>> that commences in this PES packet. A picture start code commences in PES
>> packet if the first byte of the picture start code is present in the PES
>> packet. "
>> As there can be many picture start codes in the PES packet written, it
>> is wrong to repeat the PTS on every packet, it is only valid for the
>> first packet - that is the first bug. The second bug is that the PTS as
>> delivered through pkt->pts belongs to the AVpacket passed. As the code
>> in mpegts_write_packet() keeps filling up PES packets until they are
>> "full", the new PTS is only written after the beginning of the AVpacket
>> is already used up (to fill the last PES). So in general PTS information
>> in the PES packets written lags by some bytes (the corresponding picture
>> start code is not in the PES with the new PTS).
>> My patch (attached) fixes the problem: the PTS is only written for the
>> first PES packet and every delivered AVpacket starts a new PES packet. The
>> drawback of this change is now that the length of generated PES packets
>> is not constant anymore. If that is an issue, than I would see no
>> alternative but to analyze the data and look for start codes (not nice...).
>> I hope it helps. What I did not check (and what might be broken now) is the
>> PCR though :-(
> Mans Rullgard, you are listed as maintainer for mpegts* ...
I looked at the patch briefly and meant to get back to it later.
> if mans doesnt reply, then my oppionion is "rejected, the muxer should be
> fixed similar to how we do mpeg-ps muxing, there is alot more then just
> pts which must be correct"
The TS muxer needs some fixing to be correct. There were some patches
posted on the list a long time ago that were supposed to improve
things. I'll see if I can dig them out again.
mru at inprovide.com
More information about the ffmpeg-devel