[FFmpeg-devel] [PATCH 2/3] textdec: Rename all generic parts from srt to text.

[Clément Bœsch]

On Thu, Aug 02, 2012 at 07:25:18PM +0200, Nicolas George wrote:
> Le sextidi 16 thermidor, an CCXX, Clément Bœsch a écrit :
> > Oh so another codec to handle that special case? Sounds weird... Does
> > these exceptions need so much attention?
> 
> I really do not understand what you mean.
> 

Re-reading your mail, you seem to propose to add a new codec [id]
CODEC_ID_TAGSOUP for mixed SubRip+ASS markup which will be used all the
time with SRT file or muxed in MKV.

And in that case my point is that that soup of mixed system should be
handled at a different level (so we can use this capability for SAMI and
potentially more if we expect samples): we should add a CODEC_ID_SUBRIP to
solve the timing issue (if I recall correctly that was the original
issue), and add the escaping as explained at the end of the previous mail.

> > In that case the second solution I propose is more appropriate.
> 
> Why?
> 

For the context, you said "Yes, but my point is that this option
[subtitles escape ASS general option] should be on by default in most
codecs.". And what I meant here was just that if the decoders are
responsible for ASS markup escaping (solution 1), it's more pain than
making it at avcodec_decode_subtitle level.

> > I was wondering if the decode would do a convert from the AVSubtitle to
> > ASS; see below, I'm correcting myself.
> 
> Definitely no.
> 
> Except, of course, during a transition period, for compatibility.
> 
> > OK so based on what you just said, and the initial second suggestion I was
> > proposing, maybe we could come with:
> > 
> > Let's assume the SubRip decoder is fed with the following event:
> > 
> >     {\an6}<i>Hello <b>World</b></i>
> > 
> > The decoder would output AVSubtitles (impl. detail: modified to become an
> > AST, maybe AVASTSubtitles or whatever) containing an event list such as:
> > 
> >     [content="{\an6}Hello ", style=ITALIC] --> [content="World", style=BOLD|ITALIC]
> > This is then exploitable by the app for one use or another (impl. detail:
> > this is what will be injected to libavfilter as well so we might want to
> > put that new subtitles struct in lavu).
> 
> Until now, ok.
> 
> >					  Then assuming this app is a player
> > and want to burn/display the subtitle with libass by itself, it would
> > encode that AVASTSubtitles to ASS with a avcodec_encode_subtitle2(); then
> > AVPacket received can then be directly piped to libass.
> 
> It would need to be muxed as well, since the timestamps should be eliminated
> from the ASS packets.
> 

I think libass can understand ASS chunks as they are muxed in matroska.
But sure, it will be possible to call the muxer as well...

> Or a helper function, since we will need to implement it anyway for
> compatibility.
> 

Wouldn't we be able to just make the deprecated avcodec_decode_subtitle()
call avcodec_encode_subtitle2() to encode the string into ASS markup? It's
strange to propose an alternative function name for doing the encode/mux;
at least I don't see the point.

> > Now concerning the escaping, we can have some pre processing in the new
> > avcodec_decode_subtitles2(): before calling the demuxer decode function,
> 
> s/demuxer/decoder/, I suppose?
> 

Sure, sorry.

> > we can escape all the '{' and '}' according to a global option (and the
> > codec will need to support the operation: this can't be done that easily
> > with MicroDVD which uses { } as well; at first that flag could be set only
> > for SubRip and SAMI). Or we can do it after the decode as well.
> 
> Definitely not before, for exactly the reason you said, and because we do
> not know how the codec handles \. It can be done afterwards, or it can be
> done during by a helper function, that does not matter.
> 

-- 
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/20120803/4c045118/attachment.asc>