[FFmpeg-devel] [PATCH] matroska: Identify S_TEXT/UTF-8 tracks as SRT and not TEXT.
philipl at overt.org
Mon May 21 18:50:24 CEST 2012
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
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
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
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
argue that the html-style tags supported by the current decoder need
be SRT specific as you could embed them anywhere, and they're not
part of the SRT spec anyway).
> I'm afraid I don't exactly understand the issue with that round-trip
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
>> with this approach than pushing timestamp handling into the SRT
> Well, the disadvantage is that it is really a major API change
> if the past is any indication everyone will be happy to ignore that
> it will for example completely mess up MPlayer's display of the
> (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
Anyway, if this is the consensus, I can return to my original timestamp
patch. I had originally implemented it as a small modification to the
decoder to fallback to packet timestamps if it can't parse timing out
text stream. It sounds like you'd rather not do this - and have a
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
support as the current SRT decoder, so I think sharing the decoder
most sense - especially when you remember that a proper timed text
a genuinely different beast - and even more so when it get styling
first version will not have that).
More information about the ffmpeg-devel