[FFmpeg-devel] Internal handling of subtitles in ffmpeg

[Michael Niedermayer]

On Fri, Dec 19, 2008 at 12:57:19PM +0100, Reimar D?ffinger wrote:
> On Fri, Dec 19, 2008 at 12:20:46PM +0100, Michael Niedermayer wrote:
> > the subtitle decoders are supposed to output what is stored in the bitstream
> > in a decompressed and generic repressentation.
> 
> I am arguing that this generic representation is bitmap format also for
> text.

find my reply in the attached file.bmp


> 
> > this repressentation can contain bitmaps as well as pieces of text,
> > a subtitle decoder outputs a AVSubtitle which contains several AVSubtitleRect
> > each of these could be a bitmap, or text (text isnt supported yet).
> 
> What would be the advantage of allowing text in AVSubtitleRect? Well, I
> can think of a few,

ffmpeg is supposed to be able to convert files, that wouldnt work when
text is converted to bitmaps, unless you propose encoders do OCR ...


> bug I think it will be a really huge, giant,
> incredibly complex mess to support ASS that way.

we dont have to use the mplayer memcpy() if you think it is too comlpex
really, what is it that can be complex by copying the relevant part of
ASS into a char* of AVSubtitleRect ?
Please explain/elaborate on this


> I let myself happily be proven wrong, but I don't want a format that
> barely works for some text formats but has no chance of ever supporting
> extended text stuff.

and how could the suggested architecture even in theory let alone practice
affect what is supported?
what you suggest is to do text->bitmap in the decoder (that implicates
you have some code that is capable of doing this with all effects)

what i suggest is to split the ASS string into parts (in reallity that
being 1 part 99% of the time) extract time and position into the AVSubtitleRect
put the ASS string with its encoded effects into a char* of the struct
and return that. The renderer (which you above implicitly assume to posses)
then can convert this to a bitmap. Or a encoder could encode it again.


> 
> > If a ASS supports bitmaps in addition to text this would not even need a
> > change to what i suggested. The output of our subtitle
> > decoders IS vector based and always was, there is no issue with mixing
> > text and graphics.
> 
> The way you suggest there is no issue with mixing them, but I see an
> issue with representing styled text.
> Also I had thought the idea was to have two basic formats: ASS for text
> subtitles, bitmaps for others. As I see it, you are suggesting
> a third one that seems like a mixture of those? I would have been
> in favour of just a way to convert between those two.

There are 2 formats for AVSubtitleRect, text(ASS based) and bitmap
but there are multiple AVSubtitleRect per AVSubtitle

encoders (AVCodec) have a list of capabilities (thats an int) that will
have 1 bit saying that it supports text AVSubtitleRect and 1 bit saying
that it supports bitmap AVSubtitleRect

Convertion between text->bitmap would happen on a per AVSubtitleRect base
when needed

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081219/dd5e7c18/attachment.pgp>