#1154 closed defect (fixed)
Application provided invalid, non monotonically increasing dts to muxer
Reported by: | Greeny | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | undetermined |
Version: | git-master | Keywords: | av_interleaved_write_frame flv h264 |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | yes | |
Analyzed by developer: | no |
Description
I am trying to remux a rtmpdump created .flv file with h264 video and speex audio into an .mp4 file. To do this I am copying the h264 video and converting the speex audio to aac using libfaac. However, when attempting this I get the following error:
[mp4 @ 0x10180c400] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 54363 >= 54363
av_interleaved_write_frame(): Invalid argument
When using an older version of ffmpeg (specifically SVN-r25783 from 2010) the h264 video is copy okay even though there are a lot of errors such as:
[mp4 @ 0x10101cc00] st:0 error, non monotone timestamps 97547 >= 97547
Even with these errors the video turns out fine. I have attached a -report from the command that produces the error.
Attachments (3)
Change History (18)
by , 12 years ago
Attachment: | ffmpeg-20120331-070413.log added |
---|
comment:1 by , 12 years ago
Keywords: | av_interleaved_write_frame flv h264 added |
---|---|
Version: | 0.10.2 → git-master |
comment:2 by , 12 years ago
Just for some background info, the older version of ffmpeg that I used was downloaded from here: http://trick77.com/2010/11/22/how-to-convert-flv-flash-video-to-mp4-on-the-mac/
In his post, he mentions "I also had to apply a small fix in utils.c so ffmpeg doesn’t abort with “error, non monotone timestamps n >= n” while remuxing slightly out-of-sync Flash videos." Those are the errors that show up using that older build but the file still turns out fine. I imagine the timestamp errors are because when you download a live stream using rtmpdump, the resulting .flv file is unseekable. Every file I've remuxed with the older build plays fine in several media players, even with those errors.
As for the input sample, the file is of a pornographic nature. I'll try to upload a portion where nothing is going on later tonight if that's alright with everyone! ;)
Edit: I can also provide a sample of an output file from the older build (the one that works) if that helps in anyway.
comment:3 by , 12 years ago
I've attached a different sample file with no naughty content as well as the -report for the file indicating the same problem. If you need anything else from me, please don't hesitate to ask.
comment:4 by , 12 years ago
I thought I'd let anyone know that I applied the patch suggested in this ticket: http://ffmpeg.org/trac/ffmpeg/ticket/177
Everything works fine now. I'm sure that could theoretically bite me in the ass down the road since I'll admit I have absolutely no clue what that code does but the output file works fine with the patch applied.
comment:5 by , 12 years ago
Reproduced by developer: | set |
---|---|
Status: | new → open |
comment:9 by , 12 years ago
Still reproducible with current git head:
$ ffmpeg -i denykiss.flv -vcodec copy -an out.mp4 ffmpeg version N-43716-g92b8c9d Copyright (c) 2000-2012 the FFmpeg developers built on Aug 18 2012 18:47:44 with gcc 4.6.1 (GCC) configuration: --cc=/usr/local/gcc-4.6.1/bin/gcc libavutil 51. 70.100 / 51. 70.100 libavcodec 54. 53.100 / 54. 53.100 libavformat 54. 25.104 / 54. 25.104 libavdevice 54. 2.100 / 54. 2.100 libavfilter 3. 11.101 / 3. 11.101 libswscale 2. 1.101 / 2. 1.101 libswresample 0. 15.100 / 0. 15.100 Guessed Channel Layout for Input Stream #0.1 : mono Input #0, flv, from 'denykiss.flv': Duration: 00:03:23.27, start: 0.000000, bitrate: 82 kb/s Stream #0:0: Video: h264 (Main), yuv420p, 320x240 [SAR 1:1 DAR 4:3], 15 tbr, 1k tbn, 30 tbc Stream #0:1: Audio: speex, 16000 Hz, mono Output #0, mp4, to 'out.mp4': Metadata: encoder : Lavf54.25.104 Stream #0:0: Video: h264 ([33][0][0][0] / 0x0021), yuv420p, 320x240 [SAR 1:1 DAR 4:3], q=2-31, 1k tbn, 1k tbc Stream mapping: Stream #0:0 -> #0:0 (copy) Press [q] to stop, [?] for help [mp4 @ 0x1485080] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 2673 >= 2673 av_interleaved_write_frame(): Invalid argument
comment:10 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | open → closed |
Fixed for the sample provided. I cannot say for sure if AV sync is ok or if further issues remain.
If some issues remain with this sample then please reopen this ticket.
If the same error shows up with other files then please open seperate tickets, its unlikely that it would be the same bug.
comment:12 by , 5 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
I am encountering this same issue with:
ffmpeg version N-88804-g3af2bf0af0 Copyright (c) 2000-2017 the FFmpeg developers
built with gcc 7.2.0 (GCC)
I get the error trying to copy a Blu-Ray m2ts with subtitles. It doesn't matter what codecs I use. If I leave out subtitles, the operation works.
comment:13 by , 5 years ago
I just tried with:
ffmpeg version N-93863-g58d167bcd5 Copyright (c) 2000-2019 the FFmpeg developers
built with gcc 8.3.1 (GCC) 20190414
I get the error messages but it doesn't abort the operation. Instead, I get hundreds of messages like this:
Non-monotonous DTS in output stream 0:2; previous: 291274410, current: 291274408; changing to 291274411. This may result in incorrect timestamps in the output file.
I'll check the resulting file, once it's done. I'm doing a copy operation for all codecs (audio, video, subtitle).
-- update --
Hmm, the output file was no good. It had the audio/video tracks but the subtitles didn't work and showed up as a "Data: bin_data" streams.
follow-up: 15 comment:14 by , 5 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Please so not reopen seven-year old tickets.
comment:15 by , 5 years ago
Replying to cehoyos:
Please do not reopen seven-year old tickets.
Understood. Thanks for letting me know!
Replying to greenythebeast:
The resulting file was invalid and if any player could play it, it was pure luck.
Please provide the input sample.
Possibly a duplicate of ticket #1125.