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

[Clément Bœsch]

On Thu, Aug 02, 2012 at 05:59:51PM +0200, Nicolas George wrote:
> Le sextidi 16 thermidor, an CCXX, Clément Bœsch a écrit :
> > In SRT yes. For SAMI as I said it's based on the subtitles reader in
> > MPlayer. And it wouldn't be a surprise to find more of them. I can try
> > various subtitles editor and do some subtitles convert with them from ASS
> > to another format, I'm pretty sure I'll be able to generate mixed markups,
> > which will be btw "well" rendered in some players...
> 
> Creating broken files on purpose is always easy. I was wondering if such
> files actually existed outside that.
> 

Well it can not be on purpose; the procedure I was proposing is a typical
user behaviour. Anyway, these files are not common; at least I didn't find
much.

> > > My rationale to want TAGSOUP instead of SUBRIP is to make it clear when a
> > > format is really specified or when it is parsed defensively to handle
> > > anything in the wild.
> > Well, this tagging system is better known as "SubRip" so I think it makes
> > more sense to use that name...
> 
> No! I was not talking about SubRip, I was talking about SubRip+ASS.
> 

Oh so another codec to handle that special case? Sounds weird... Does
these exceptions need so much attention?

> > My point is that it should be in another pass.
> 
> Whether this is done in another pass or directly by the decoder using helper
> functions is implementation detail.
> 
> > 1) If we keep the current state (the decoders directly convert markup to
> >    ASS tags), we will need that each decoder access and honor a
> >    -subtitles_escape_ass general option. During the process of converting
> >    from markup to ass, { and } will need to be escaped or not. This is
> 
> Yes, but my point is that this option should be on by default in most
> codecs.

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

> 
> >			and then convert it to the RAW format for subtitles
> >    (ASS, right?).
> 
> What's this about a raw format? I do not understand what you are referring
> to.
> 

I was wondering if the decode would do a convert from the AVSubtitle to
ASS; see below, I'm correcting myself.

> Things currently work like that:
> 
> file ----> AVPacket -----> AVSubtitle -----> AVPacket -----> file
>      demux          decode            encode           mux
> 
> What I am suggesting in this thread is just to change the way the decoded
> subtitle is stored in AVSubtitle, from ASS lines with timestamps and style
> in a clumsy syntax to... what I described.
> 
> If people want ASS lines to feed libass, they can reconstruct it from
> AVSubtitle. We will probably provide an API to do that because it is such a
> common need and we will have to implement it to keep compatibility anyway.
> But the ASS lines should not be stored in AVSubtitle or anywhere.
> 

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

Now concerning the escaping, we can have some pre processing in the new
avcodec_decode_subtitles2(): before calling the demuxer decode function,
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.

And the same logic can be used for encoding; working on the content fields
should be easier.

-- 
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/20120802/6353fa2c/attachment.asc>