[FFmpeg-devel] Timestamp problems when transcoding asf/wmav2/wmv3 to ts/aac/h264

[Michael Niedermayer]

On Fri, Dec 06, 2013 at 06:03:22PM +0100, Anders Rein wrote:
> After transcoding a asf file with wmav2/wmv3 to a ts file with
> aac/h264 using the ffmpeg executable, the audio packet timestamps
> are wrong when I again use libavformat to demux the file. I've
> tested with both the ffmpeg aac encoder and libfdk_aac and the
> problem remains the same.
> 
> When I transcode I get the warning log message:
> [aac @ 0xa55ee0] Queue input is backward in time
> [mpegts @ 0xa56be0] Non-monotonous DTS in output stream 0:1;
> previous: 1089818, current: 1087511; changing to 1089819. This may
> result in incorrect timestamps in the output file.
> [mpegts @ 0xa56be0] Non-monotonous DTS in output stream 0:1;
> previous: 1089819, current: 1089431; changing to 1089820. This may
> result in incorrect timestamps in the output file.
> 
> What is happening as far as I understand is that the wmav2 packets
> have slightly wrong timestamps so that sometimes the dts gap is much
> smaller than the actuall sample duration in the packets. wmav2 has
> much larger frames than what is sent in to the aac encoder. When
> FFMpeg uses ff_filter_frame_needs_framing to divide the big audio
> frames into smaller frames for the aac encoder, the smaller frames
> at the end of the large frames get timestamps larger than the next
> big frame from the asf demuxer.
> 
> The ffmpeg executable solves this in write_frame(ffmpeg.c:545) by
> moving the next packets 1 timestamp in front of the previous packet.
> This is when the "Non-monotonous DTS" shows up. This work pretty
> well, and I can play the file afterwards. The problem comes when I
> afterward run the fille into my own software that uses libavformat.
> Some of the packets that I then read from the file have
> non-monotonous increasing dts. Putting a log line in the mpegts
> demuxer shows that the actuall dts in the file is correct (only
> increasing), however somewhere in parse_packet
> (libavformat/utils.c:1201) the timestamps are corrupted by
> compute_pkt_fields.
> 
> I don't fully understand what is going on in parse_packet, but it
> seems like with the help of the ac3 parser the packet is spilt into
> serveral smaller packets and execpt for the first sub packet, the
> timestamps are calculated using duration. This caluculation end up
> giving non-monotonous increasing dts in packets returned to the
> public API. Can anyone help shed some light on what is going on
> here?

if this is still reproduceable and if it can be reproduced with
ffmpeg alone, maybe by showing incorrect timestamps, then opening
a ticket on trac with reproduceable testcase might make sense

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140109/b04b1665/attachment.asc>