[FFmpeg-devel] Internal handling of subtitles in ffmpeg

Reimar Döffinger Reimar.Doeffinger
Fri Dec 19 15:49:16 CET 2008

On Fri, Dec 19, 2008 at 02:40:57PM +0100, Michael Niedermayer wrote:
> I dont see the problem. Let me be more concrete
> typedef struct AVSubtitleRect {
>     int postype;///< 0->position encoded in data (only allowed when format is text-ASS), 
>                      1->video (0x0..1x1) relative, 
>                      2->screen (0x0..1x1) relative, 
>                      3->pixel relative
>     int format; ///< Describes what is in data, 0-> bitmap, 1->ASS based text
>     PixelFmt pix_fmt;
>     int x;      ///< horizontal pos in 16.16 fixed point
>     int y;      ///<   vertical pos in 16.16 fixed point
>     int w;      ///< horizontal size in 16.16 fixed point
>     int h;      ///<   vertical size in 16.16 fixed point
>     uint8_t *data[4];
>     int linesize[4]
> } AVSubtitleRect;

Well, obviously it can be made to work (if you insist you can use
MPlayer as a text editor...), but to me this feels like a horribly
complex way to pass around of strings without much of an advantage.

> > A corollary to this was that thus subtitle decoders should not be used
> > for anything that does not create (pure) bitmap subtitles.
> maybe i was unclear
> the architecture in ffmpeg is
> demuxer -> decoder -> encoder -> muxer
> thus there WILL be a decoder and encoder when converting subtitles,
> You fight about the terminology (and seem not to realize it)

Ok, make it "subtitle decoders as they are currently designed, and IMO
also designs that are too similar to the current one".
Of course there will be decoders/encoders etc., but I have some doubts
if it is really the sanest way to have the same API for text and bitmap
subtitles. Of course we will only know once someone actually implements
it, so I'll try to end the discussion here.

> demuxer -> A -(common format)-> B -> muxer is the simplest choice
> and in this case in ffmpeg A is called a decoder and B a encoder
> and the common format is a AVSubtitle this is per definition so
> even if you rm AVSubtitle all encoders and all decoder and completely
> redesign them, they still could and should be called like that.

Well, you could have AVTextSubtitle (aka char * containing ASS), AVBitmapSubtitle
and a converter between them, which would not change the current API but
instead only add to it, AVBitmapSubtitle not being used for mixed
formats but a render-on-video-only format in the long term (and making
sure that it stays simple enough that the using application does not
need hundreds of "if(valid positions) ... else ...; if(text) convert;

Reimar D?ffinger

More information about the ffmpeg-devel mailing list