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

[Nicolas George]

Le sextidi 16 thermidor, an CCXX, Clément Bœsch a écrit :
> A lot of formats don't define a clear standard either. If the current
> SubRip markup gets renamed into TagSoup, it will likely evolve to support
> more tags initially not supposed to be in SubRip. I'm not sure that's a
> good idea. Example: "MySubFormat supports tags like <i>, <b> just like the
> generic TagSoup but I also have the tag <img>, let's add the support in
> TagSoup", and now you can decode MKV+TEXT with muxed <img>, and you can
> put <img> into SRT files as well.

The format will not evolve without our control. Or more precisely: the
features of the lavc decoder will not evolve without our control.

But if some idiot fansub team starts to create Matroska files with S_TEXT
tracks and <img> tags, and users are nagging us to support them, we will
have to consider it.

On the other hand, if someone invents a format with pseudo-HTML tags,
including IMG, and wants ffmpeg to support it, a new, dedicated CODEC_ID can
be added.

> Where do you want to handle this?
> 
> The ASS tags presence is unconditional to the formats. You can have
> extra ASS tags in SRT, as well as SAMI and maybe more. That needs to be
> handled at a higher level, for every subtitles I guess.

Did you actually meet some of these files, or are you guessing?

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.

If you want to define CODEC_ID_SUBRIP for text with a finite set of known
tags, and not recognizing wild ASS tags, that is fine with me, but people
will probably complain.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120802/4982d7f1/attachment.asc>