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

[Philip Langdale]

On 21.05.2012 09:38, Reimar Döffinger wrote:
>
> 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.

It actually doesn't work with timed text (these changes are all leading
up to my timed text decoder and encoder) as the packet isn't just plain
text. It's a Pascal style string with leading size and no null 
terminator.

Additionally, the text can be followed by a bunch of binary structs
defining the styling effects (and I'm pretty sure the way that mplayer
handles these will break if there are any styles includes - as it 
ignores
the text length field and assumes the rest of the packet is text).

The core of the SRT decoder could be shared, to be sure (and you can 
even
argue that the html-style tags supported by the current decoder need 
not
be SRT specific as you could embed them anywhere, and they're not 
formally
part of the SRT spec anyway).

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

It's impossible to stick an SRT track into an mkv today and get it back
as SRT just using ffmpeg.

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

mplayer doesn't interact with the 'normalised' SSA form of the 
subtitles?

Anyway, if this is the consensus, I can return to my original timestamp 
based
patch. I had originally implemented it as a small modification to the 
SRT
decoder to fallback to packet timestamps if it can't parse timing out 
of the
text stream. It sounds like you'd rather not do this - and have a 
separate TEXT
decoder? But, remembering that in 100% of cases, the input into the mkv
container was an SRT file, the decoder really needs to have the same 
styling
support as the current SRT decoder, so I think sharing the decoder 
makes the
most sense - especially when you remember that a proper timed text 
decoder is
a genuinely different beast - and even more so when it get styling 
support (my
first version will not have that).

--phil