[FFmpeg-devel] Internal handling of subtitles in ffmpeg

Reimar Döffinger Reimar.Doeffinger
Fri Jan 2 19:20:06 CET 2009


On Fri, Jan 02, 2009 at 05:47:24PM +0100, Michael Niedermayer wrote:
> > Reason: require generation of alternative formats when they are not
> > wanted?
> 
> did you want simplicity? if so text/ass surely should always be set for
> text/ass types, i cant imagine the O(n) loop over n chars where n being
> < 1000 once a second could matter speedwise ...

Well, thought that the API might provide a way to get the subtitle
directly converted to the requested format.
I just have a general dislike against duplicated information, and it
might require some extra effort when an external application decodes,
updates an passes the subtitles back again to FFmpeg.
Of course that is assuming you want it to be a requirement, and not just
a promise from FFmpeg side to set them.

> but if you prefer, it surely could be omitted

It is easier to add once we know the exact API and how it will be used than
to remove it ;-)

> > Colour is somewhat questionable I admit, why not add bold, font size,
> > name etc. until you have reimplemented ASS. I don't really know the
> > answer to that.
> 
> Dialogue event lines in ASS have 10 fields
> if we drop the actual text and effects 8
> They are
> Layer, Start, End, Style, Name, MarginL, MarginR, MarginV
> 
> What is your oppinion about adding the ones that are interger to the struct?

I would prefer to implement few to none and see what people request,
except that I have doubts that the "request" part will work out.
All of those fields must be set by an application that generates
subtitles after all, though a helper function can reduce that issue.

> > I suspect you have your good reasons for not wanting a union, still some
> > grouping IMO would be good.
> 
> a union would directly conflict with the idea of caching, that is the
> requirements you set that there be a plain text and a plain ASS char* field
> always and directly could then only be met if these where outside the union.

Yes, I just can not estimate how important caching actually will be.
Probably better to choose a design that can support anyway.

> > Also I think AVSubtitle should specify which types might be used in the
> > AVSubtitleRects so you can do something simple in the spirit of
> > if (subs.types != TEXT_SUBTITLE)
> >   av_convert_subs(subs, TEXT_SUBTITLE);
> 
> hmm, yes but i dont know how to do that cleanly (in terms of documentation
> because if the enum has 1,2,4 values and is set per OR it will be confusing
> in relation to the real enum field in AVSubtitleRect)

I think just a common_type field would be "good enough", where a special NONE
value indicates not all have the same type.

Greetings,
Reimar D?ffinger




More information about the ffmpeg-devel mailing list