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

[Clément Bœsch]

On Tue, May 22, 2012 at 04:59:49PM +0200, Nicolas George wrote:
> Le tridi 3 prairial, an CCXX, Philip Langdale a écrit :
> > 1) What is the "subtitle decoder?"
> 
> Before that, we have to ask: What is a decoded subtitle?
> 
> We know what a decoded video frame is: array(s) of pixel values. We know
> what a decoded audio frame is: array(s) or PCM sample values.
> 
> But we do not have consensus on what decoded data is supposed to look like
> for text-based subtitles format. Surely it consists mostly of text. But what
> about markup?
> 
> Once there is a clear policy about that, we can start worrying about what is
> the role of the demuxer and what is the role of the decoder.
> 
> My opinion:
> 
> * Decoded text subtitles should be in a structure where the time and
>   duration is stored as a number, and the text in a string without the
>   timing information.
> 
> * The text should always be in Unicode (probably UTF-8, but using ints
>   instead of chars is also a reasonable option (wchar_t is not)).
> 
> * For the markup, two options:
> 
>   - Choose / invent a universal markup syntax and always convert to/from it.
> 
>   - Handle markup syntax more or less the same way we handle pixel or sample
>     formats.
> 
>   Note that subtitles are much less performance-relevant than video frames,
>   so the systematic conversion is not a problem. On the other hand, there
>   are so many features in various subtitles formats that maintaining an
>   universal syntax would probably be problematic. So I guess I am rather in
>   favour of the second solution.
> 

Most players use ASS rendering for every subtitles (assuming a conversion
of the original subtitles markup into ASS), which is BTW what we do in our
text subtitles decoders (SubRip, MicroDVD, and JacoSUB). ASS rendering is
expected by most people even for these formats.

ASS also handles mostly every "useful" markups (of course I have a bunch
of exceptions in mind) at the moment. If a new subtitle format is meant to
replace ASS, it will likely keep some kind of retro compatibility with it
(otherwise it will be a pain for almost every current decoders/players),
and so moving our internal formats to this new one should not be much a
problem.

I'm not sure about what you mean by handling the markup syntax the same
way we handle pixel/sample formats.

BTW, I had in mind something about subtitles: I think the decode subtitles
API should do the ASS rendering if possible; calling
avcodec_decode_subtitles() with a "render_ass" flag to decode
ASS-compliant subtitles (aka the decoder returns ASS packets) into a
bitmap layout ready-to-blit by the player/transcoder (ffplay can already
do that kind of subtitles bitmap rendering). It might avoid some pain with
lavfi (except hardsubbing, does anyone see any more potentially useful
subtitles filtering for lavfi?).

Last time I looked for this solution I expected quite a few problems
(which I can't remember now I admit), but maybe it's worth looking at this
again.

[...]

PS: sorry for hijacking this thread with a OT, if anyone wants to reply to
this, it might be wise to start a new thread.

-- 
Clément B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120522/23e84811/attachment.asc>