[FFmpeg-devel] [RFC] libavfilter-soc and variable-frame-size video streams

Stefano Sabatini stefano.sabatini-lala
Sat Dec 13 01:46:37 CET 2008

Hi all,

currently libavfilter (and in particular the vf_scale filter) can't
work with variable-frame-size video streams, VP6 in FLV video flash
files is a typical example of that.

I think this is one of the issue we have to deal with in order to be
able to include effectively libavfilter in SVN.

I've not a solution, so I'm posting here my analysis hoping that
someone will be able to give some ideas.

Let's consider the VP6 case, since its decoder doesn't set the width
and height in the context before the first decoding, the width/height
values are set to 0, and the vf_scale filter will fail to properly
configure itself issuing for example:
swScaler: 0x0 -> 100x100 is invalid scaling dimension

The first idea I considered was to set the swscale context not in
the config_props callback but in start_frame. This has two main
problems, which are:
1) start_frame() cannot fail, while setting a sws context with invalid
(e.g. zero values) can, so an API change would be necessary or we
could simply make it pass a black frame to the output link (the latter
looks better).

2) config_props has to set the w/h values for the output link, values
which it cannot detect before the first decoded frame (indeed the
input w/h parameters may be set to 0 - meaning that size has not to be
scaled, or -1 - meaning to keep the w/h ratio when setting that

So the problem with the current framework seems that the w/h size
values in each link have to be constant and need to be defined during
the configuration stage, which cannot work for variable-frame-size
video streams.

The only solution that I see is to make w/h not anymore an invariant
property of the link, but I cannot see at the moment how the whole
architecture would be affected by such change.

But maybe I'm just confused and there is a far simpler solution, or
maybe we could just decide that supporting variable-frame-size video 
streams is not worth that hassle.

Any advice is welcome.

FFmpeg = Fostering and Freak Monstrous Philosofic Efficient Gem

More information about the ffmpeg-devel mailing list