[FFmpeg-devel] [PATCH] matroska: Identify S_TEXT/UTF-8 tracks as SRT and not TEXT.

[Philip Langdale]

On Mon, 21 May 2012 09:24:33 +0200
Hendrik Leppkes <h.leppkes at gmail.com> wrote:

> And now i just see your other commit (it helps marking them PATCH 1/2
> to make it clear its a set), yet i still don't think its the right
> way to go. It seems quite inefficient to write the timings into the
> packet just so that the subtitle decoder can read them from there,
> instead of just teaching the subtitle decoder to also handle
> CODEC_ID_TEXT and using the timings from the AVPacket fields.

So, this is actually the first approach I took, but I'm not comfortable
with it when I think about all the implications.

1) What is the "subtitle decoder?" Do we take the SRT decoder, add
support for reading pkt.pts, and then say it supports CODEC_ID_TEXT?
Semantically, this isn't an SRT subtitle stream any more. What if
another container has a TEXT stream with different semantics. If
you're being rigorous, you need a separate TEXT decoder that is
almost exactly but not quite the SRT decoder - which is silly.

2) Round-trip consistency: Today it is not possible to mux an
SRT file into an mkv container and then demux it out again. With
my proposed change, it becomes possible (modulo me not generating
index numbers, which can be done in the future), but if we do the
timestamp thing, we haven't improved the situation - unless, that
is, you want to write an "SRT muxer" that does the same basic work
as my patch.

3) Tool consistency: mkvextract, when confronted with a TEXT/UTF-8
track will extract it as an SRT file.

4) Why does the existing mkv demuxer go out of its way not to
associated timestamps with subtitle packets? My initial patch had to
change this behaviour. Why is it there? Surely there was some reason
for it.

5) Semantic consistency with SSA handling. Today, we reconstruct the
SSA stream, so why not for SRT?

I know it seems a little convoluted, but I feel much more comfortable
with this approach than pushing timestamp handling into the SRT decoder.

--phil