[FFmpeg-devel] libavfilter and subtitles (was: [RFC] Talk about subtitles)

[Stefano Sabatini]

On date Thursday 2011-12-22 14:32:09 +0100, Nicolas George encoded:

Sorry for the slow reply.

[...]
> IMHO, the real, clean, solution, would be to device a way for the movie
> source to be able to output both the video and the subtitles if necessary.
> And, while we are at it, the audio too.
> 
> Here is what I suggest:
> 
> - In the structure describing a filter, an input or output pad can be
>   flagged as an "array".
> 
> - If an input is an array, it must be connected with the following syntax:
>   [ref_a,ref_b,ref_c].
> 
> - If an output is an array, when referencing it to connect it to an input,
>   an index must be supplied: [ref.5]; the indices can be sparse (ref.2 can
>   be used even if ref.1 is not), but not too much so (a small array is
>   suitable to store the references).
> 

> - Input and output pads arrays are created with exactly the pads present in
>   the graph description. Thus '[a,b] [c] some_filter' will have a as
>   input[0], b as input[1] and c as input[2]. A new field in the filter
>   structure allows the init function to find the exact mapping.

What if you want to connect an output pad array with an input pad
array?

For example you may want to connect a movie source with a movie
sink. The number and type of streams in the source is variable, so it
would be nice to find a way to connect them without knowing in advance
that information.
 
> This way, we solve several problems at once:
> 
> - The movie source has three outputs: video, audio, subtitles, all of them
>   arrays; the index in the array is the index of the stream. If the user
>   wants one of the streams, it connects something to it.

What would be able to output an array pad?
Would it support streams of different type?  In other words, the movie
sink would work like:

movie=INPUT [vout][aout][sout]

or would it support a single output array pad containing all the
streams (A/V/S)?

> - The amerge filter I am working on can have one array input instead of two
>   normal ones.
> 
> What do you think about it?

That's surely interesting, we need to understand what's the better
design in terms of flexibility, and which are the
complexity/performance penalties we might incur upon.
-- 
FFmpeg = Freak Fancy Mind-dumbing Power Encoding/decoding Gospel