[FFmpeg-devel] Bugreport: mpegts-demuxer gives wrong pts/dts with avchd files

[Thorsten Jordan]

Thorsten Jordan schrieb:
> M?ns Rullg?rd schrieb:
>> Thorsten Jordan <tjordan at macrosystem.de> writes:
>>
>>> Hello,
>>>
>>> i just stumbled over misbehvaiour of the mpegts-demuxer of ffmpeg. I
>> [...]
>>
>>> Who maintains the mpegts demuxer?
>> That would be me.  Please upload a sample to mphq.
>>
> 
> Hello,
> 
> i debugged a bit more and deeper and found out more things.
> 
> Intro (again): What is the problem?
> 
> I have here AVCHD-files from a Camera (kind of transport-stream) that
> store h.264 video (and AC3 audio) in PAFF mode - that is field after
> field. Only every top field has PTS values, only I/P frames have DTS
> values. When reading the file with libavformat, wrong values are given
> for AVPacket's pts/dts, the pts of the top field of the second frame
> (B-frame) is associated to the bottom field of the first frame (I-frame).
> After some debugging i suppose this is not h.264/PAFF specific but could
> happen with mpeg2 video as well.
> 
> Here is the reason: payload of ts packets is given to av_parser_parse()
> in libavformat/utils.c line ca. 795 together with pts/dts that is
> available for the data chunk. Then in libavcodec/parser.c, in
> av_parser_parse() line ca. 125 the pts/dts values are stored. AFTER that
> parser->parser_parse() is called - the format specific frame parser.
> It will report a frame (here a field) as finished when the current data
> chunk allows to find its end. The TS-packet payload here just starts
> with a new frame/field. But there the pts/dts values of the NEXT
> frame/field are already stored and attached in line 142 ff.

more details after more debugging:

parser.c is correct, i apologize.
The trouble starts when parser's pts/dts are both AV_NO_PTS after
parsing the bottom field of the first frame. It is correct that there is
no pts/dts. Then libavformat/utils.c line 815 is done, a few lines after
"got_packet:"-label: compute_pkt_fields() is called, and this does wrong
things. It assigns pts/dts as if the packet would be next frame, so it
computes with 3600 of 90kHz units, not 1800, and also misses the fact
that this is a bottom field of a frame.

So it seems that if parsers give fields instead of frames, here is
something fundamentally broken in libavformat/utils.c/av_read_frame.

This should be a problem for mpeg2 too (and maybe other formats).

-- 
Regards, Thorsten