matroskadec, matroskadec, srtenc: Read/Write duration for subtitles.
authorPhilip Langdale <philipl@overt.org>
Wed, 23 May 2012 04:50:02 +0000 (21:50 -0700)
committerPhilip Langdale <philipl@overt.org>
Sat, 1 Sep 2012 03:22:49 +0000 (20:22 -0700)
commit9d89c8b3ac80134f0bd32512eb208b113795ab9e
tree69d2f7f93e53afe2599209619c2fdb6acdbde653
parent6a0dfe3b9dc6b9420b25bfd089c655583cf045d6
matroskadec, matroskadec, srtenc: Read/Write duration for subtitles.

After much discussion and back-and-forth, we reached the conclusion
that matroska uses convergence_duration for subtitle duration because
a 32bit value isn't large enough to store the duration if sub-micro-second
timebases are used. Matroska may not be the only one that supports these
timebases, but it's certainly the only one that ffmpeg attempts to support
in this way.

The long term solution that we seemed to reach was that if we encounter
a matroska file with a sub-micro-second timebase, we should internally
scale it up to at least micro-second, and then duration can be used
normally. This suggests that on the encode side, we should not allow
generation of files with sub-micro-second timebases, but that's a separate
issue.

That being a non-trivial change, and the subtitle interoperability breakage
being very real, I'm re-submitting this small change for consideration.

In this diff, we make sure that duration is populated by the matroska
demuxer, and that convergence_duration is respected in matroskaenc and
srtenc, but that duration is used otherwise. This ends up being a strict
improvement - pipelines that use convergence duration are unchanged, and
ones that are currently broken due to the duration mismatch will start
working - except for the ones with the extreme timebases, but those were
already broken.

Signed-off-by: Philip Langdale <philipl@overt.org>
libavformat/matroskadec.c
libavformat/matroskaenc.c
libavformat/srtenc.c