[FFmpeg-devel] [RFC] Talk about subtitles
nicolas.george at normalesup.org
Tue Nov 29 13:30:00 CET 2011
Le quartidi 4 frimaire, an CCXX, Clément Bœsch a écrit :
> One filter combining every part you mentioned yes.
As Reimer pointed out, the different parts must be available separately for
users who want to make adjustments in the middle of the process.
OTHO, nothing prevents the engine from automatically inserting necessary
conversion filters, just like it does for colorspace conversion.
> Mmh, don't you think we could just improve the subtitles API and use it in
> the filter is a simpler and fine way to deal with it? I may completely
> miss your point though.
> -hardsub could be used as an alias: if hardsub is specified, let's insert
> a subtitles video filter for transparency. Not sure how easily we can do
> If we insert a filter (and first the user would just specify it manually),
> we won't have to need that AFAIU. Also note it will be easier to integrate
> it in ffplay for instance (hell yeah subtitles in ffplay!).
I think you missed one of the points I was making here: libavfilter
currently does not support subtitles. Do we want hardsub support right now,
or can it wait until libavfilter gets proper support?
The design decisions depend a great deal on the answer to this question. The
paragraphs I just quoted assume libavfilter is used, but they answer to the
part of my message where I wrote about an immediate solution, without
> I believe ASS is a fine universal markup. Since we can render (almost?)
> everything (with some pain sometimes), it should be fine.
The more I think about it, the more I believe subtitles formats should be
handled the same way as pixel formats: convert between them as necessary,
but only if necessary.
Of course, if our only text-to-bitmap converter accepts only ASS markup, we
have to convert anything to ASS. But new engines could appear, that may have
both pros and cons compared to libass.
> And if not, the codec could output bitmap with its own rendering and use
> the markup ASS common text field for a "verbatim" text version where his
> markup is stripped.
This one seems to me like a rather bad idea.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel