[Ffmpeg-devel] Mpeg2-ts encoder uses fixed PES payload size

[Alexander Kurpiers]

M?ns Rullg?rd wrote:

> Alexander Kurpiers said:
>> Kling, Fredrik wrote:
>>
>>> Hi,
>>>
>>> I have noticed that the MPEG2 TS Encoder (mpegtsenc.c in libavformat)
>>> uses a fixed size buffer for the PES data.
>>> Is there a reason for this ?
>>>
>>> Ex: ffmpeg -i videofile.264 -vcodec copy -f mpegts file.mpegts
>>>
>>> Will produce quite a data-overhead due to ineffective PES handling.
>>> Changing the PES handling to using the size (supplied by the AVPacket
>>> structure, in function mpegts_write_packet) and reallocating properly
>>> would allow for dynamic payload sizes instead of fixed.
>>>
>>> Some other 'issues' found:
>>> - The current mpegtsenc.c can not handle VC-1
>>> - the SDT packet frequence seems quite flawed (adding an SDT packet
>>> every second packet!), causing the TS to grow up to 64% bigger than the
>>> actual ES it encapsulates...
>>>
>> As we discuss the issues (and have already started fixing some of them)...
>> It is still wrong to put a PTS in every PES. I fixed that a year ago but we
>> all concluded that more was needed to fix mpegtsenc.c - but now we start
>> fixing issues and patches get applied...
>>
>> To refresh your memory:
>> MPEG2 System spec:
>>
>> "... 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. "
>>
>> But we don't know where video packets actually start - at least not at this
>> point.
> 
> The muxer should be fed complete frames, so we do know.
> 


Yes, that's why my patch worked. But right now we blindly put PTS in every
(fixed-size) PES - losing the relation to the frames.

Nevertheless one of the problems to be solved is PCR.