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

Reimar Döffinger Reimar.Doeffinger at gmx.de
Mon May 21 18:38:31 CEST 2012


On Mon, May 21, 2012 at 08:25:19AM -0700, Philip Langdale wrote:
> 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.

You need that anyway if you want to strictly support plain text
subtitles (i.e. without any formatting) so I don't quite see
what the point is.
And I think we will want such a plain text demuxer, for example
most real-word mov timed text subtitles would work fine with it,
and requiring someone to implement a special decoder for every single
format even if in 99% of use cases it just is plain text isn't a good
solution.

> 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.

I'm afraid I don't exactly understand the issue with that round-trip
thing.

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

Well, I always thought it a bad idea, though SSA/ASS has some special
issues like I believe overlapping time stamps etc. that can cause
issues and somewhat justify it.

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

Well, the disadvantage is that it is really a major API change (though
if the past is any indication everyone will be happy to ignore that fact),
it will for example completely mess up MPlayer's display of the subtitles
(uh, I just realize: the other patch will, with this one it
might just stop displaying any subtitles, not sure).


More information about the ffmpeg-devel mailing list