#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
_______________________________________________
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
http://avcodec.org/mailman/listinfo/ffmpeg-trac
