[FFmpeg-trac] #2212(undetermined:open): Application provided invalid, non monotonically increasing dts to muxer in stream 2: 1372390 >= 1372390 av_interleaved_write_frame(): Invalid argument

FFmpeg trac at avcodec.org
Thu Jan 31 19:51:44 CET 2013


#2212: Application provided invalid, non monotonically increasing dts to muxer in
stream 2: 1372390 >= 1372390 av_interleaved_write_frame(): Invalid argument
-------------------------------------+-------------------------------------
             Reporter:  julian       |                    Owner:
                 Type:  defect       |                   Status:  open
             Priority:  normal       |                Component:
              Version:  git-master   |  undetermined
             Keywords:               |               Resolution:
  av_interleaved_write_frame ass     |               Blocked By:
  mov_text                           |  Reproduced by developer:  1
             Blocking:               |
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------

Comment (by Cigaes):

 Ok, I understand what is going on. There are bugs upon bugs.

 The first bug, the one that causes the "non monotonically increasing"
 message, is this pair of lines:
 {{{
 Dialogue: 0,0:22:52.39,0:22:52.43,ed kara
 other,,0,0,0,fx,{\fad(0,0)(\pos(930,13)}nande dare mo wakatte kunnai no to
 Dialogue: 0,0:22:52.39,0:22:52.43,ed trans
 other,,0,0,0,fx,{\fad(0,0)(\pos(830,713)}"Why doesn't anyone even try to
 understand me?"
 }}}
 (simultaneous transcription + traduction) because of this:
 {{{
 | + Block group
 |  + Block (track number 3, 1 frame(s), timecode 1372.390s = 00:22:52.390)
 |   + Frame with size 89
 |  + Block duration: 40.000000ms
 |+ Cluster
 | + Cluster timecode: 1372.288s
 | + Block group
 |  + Block (track number 3, 1 frame(s), timecode 1372.390s = 00:22:52.390)
 |   + Frame with size 104
 |  + Block duration: 40.000000ms
 }}}

 In other words, due to some happenstance in the Matroska construction, two
 simultaneous ASS event packets are in different clusters, and matroskadec
 does not merge them in that case.

 That can be considered a bug in the Matroska demuxer, but Clément and I
 are working on removing the merging of ASS packet altogether, so fixing it
 would probably be a waste of time (it does not look trivial).

 Now, as for your experiences with {{{-fix_sub_duration}}} and shifted
 subtitles, the offending line is the first one here:
 {{{
 Dialogue: 10,0:00:36.93,0:02:06.89,Default,,0,0,0,,{OP}
 Dialogue: 1,0:00:51.38,0:00:55.61,op
 kara,,0,0,10,,{\fs41\fnCorbel\b1\fad(200,200)\c&HA26310&\bord3\3c&HFFFFFF&}shibaraku
 {\c&H6203E2&}mi{\c&HA26310&}tsume atte kara
 }}}

 The first line generates an end packet at 2:06.89. Since that happens
 inside the muxer, lavf is not aware of it and does not take it into
 account for "non monotonic timestamps". The next line tries to generate a
 packet at 0:51.38, but that would go back in time, and therefore reaches
 the file in a bogus way. That is consistent with the ~75 seconds shift you
 are reporting.

 There are several points that can be considered problems, but the crux of
 the story is that mov_text-in-MP4 is just not powerful enough to encode
 complex ASS scripts.

 Using {{{-fix_sub_duration}}} will partially hide the problem by clamping
 the timestamps, but that will produce subtitles with wrong timestamps.
 Depending on the script, it may be a severe problem or completely
 invisible; it can not be considered a reliable solution and was not
 designed as such.

 I do not think there is an automatic solution for the problem of
 converting overlapping subtitles into non-overlapping: deciding what lines
 can disappear quickly, what lines can be merged together, what lines can
 be ignored, etc., requires human analysis.

-- 
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2212#comment:13>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker


More information about the FFmpeg-trac mailing list