[FFmpeg-devel] [PATCH] WIP: subtitles in AVFrame

Clément Bœsch u at pkh.me
Sun Nov 20 14:58:14 EET 2016

On Fri, Nov 11, 2016 at 12:45:03PM +0100, Nicolas George wrote:
> Le septidi 17 brumaire, an CCXXV, Clement Boesch a écrit :
> > I didn't. Duration is somehow broken currently for some reason. I did
> > nothing for sparseness: the reason I added basic support in lavfi is
> > because it was much simpler to handle at ffmpeg.c level, so it's currently
> > just a passthrough mechanism.
> A decision will need to be made pretty soon, though, or it will not help
> anything much. Sparseness will make things break badly OOM-killer-style
> if someone tries to use subtitles coming from the same multiplexed file
> than the corresponding video. Duration affects the visible API, a
> decision on it is more or less final. Here are the results of my current
> thoughts:
> For sparseness, the solution is to use heartbeat frames: if you have a
> subtitle event at 10s and the next one at 50s, emit a frame with no
> payload and just a timestamp at 10.1, 10.2, ... 49.1.

Right, I'll probably need that for the sub2video filter. I'll think about
it unless you want to implement it yourself.

> > I did't like having multiple fields for text based data. If we want to
> > decode in another form, we can still add an option to print out verbatim
> > text instead of ASS markup.
> I think we are not talking about the same thing. A long time ago, we
> considered replacing the ASS markup with a simple text field with
> styling in a separate, non-text, structure. Did you discard that idea?

Ah, yeah, I discarded that idea. First, I think it's a too large change
for now, and I just won't be able to finish this patchset ever if I start
going that way. Second, apparently it's considered over engineering by the
API users I talked with. They're fine using libass for markup or a simple
freetype-like custom engine for when there is no markup.

If we later decide to export as an AST, we will add a field to that
rectangle and that will do the trick. For now, this is already such as
huge work that I'm not willing to stick that in (and probably won't ever
TBH). It's already raising a ton of questions wrt design.


Clément B.

More information about the ffmpeg-devel mailing list