[Ffmpeg-devel] [PATCH] generated PTS in MPEGTS wrong

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> Hi
>
> 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 ( 2.4.3.7 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.

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