[FFmpeg-devel] Status and Plans for Subtitle Filters

Anton Khirnov anton at khirnov.net
Fri Feb 28 06:55:19 EET 2020

Quoting Clément Bœsch (2020-02-27 19:36:24)
> On Thu, Feb 27, 2020 at 12:35:03PM +0100, Anton Khirnov wrote:
> [...]
> > AFAIU one of the still-open questions for the subtitle redesign is what
> > does it mean to decode or encode a subtitle.
> There are multiple markups available for text subtitles, and there are
> multiple ways of representing graphic rectangles for bitmap subtitles.
> So for text subtitles, decoding and encoding respectively means
> transforming them in a common markup to represent them all (currently ASS
> is our "raw" representation) and back into their markup specifications. We
> have a bunch of those already (subrip, microdvd, subviewer, ...).

Is it still true that ASS is a superset of everything? Is that likely to
remain the case for the foreseeable future?

> For bitmap subtitles, decoding and encoding respectively means
> transforming the bitstream into rectangle structures with RAW images
> inside and back into the codec-specific bitstream.
> > And one of the options is putting the AVPacket->"decoded subtitle"
> > (whatever that is) and "decoded subtitle"->AVPacket conversions into a
> > separate library.
> And then you can't have them in libavfilter, so you can't have a sane
> harmony with medias including subtitle streams. It's problematic with many
> basic use cases. One random example: if you're transcoding an audio/video
> and somehow altering the timings within lavfi, you have to give the
> subtitles.

I don't see why that necessarily follows from not using AVFrame.
avfilter does not have to be tied to only using AVFrame forever for all
eternity. It could have a different path for subtitles. Their handling
is going to be pretty different in any case.

Note that I'm not saying it SHOULD be done this way. I'm saying that it
seems like an option that should not be disregarded without

Anton Khirnov

More information about the ffmpeg-devel mailing list