[FFmpeg-devel] Frame blending filter

Robert Krüger krueger at signal7.de
Sat May 21 09:58:53 CEST 2011

On May 20, 2011, at 16:53 , Stefano Sabatini wrote:

> On date Friday 2011-05-20 15:12:30 +0200, Michael Niedermayer encoded:
>> On Fri, May 20, 2011 at 12:36:57PM +0200, Robert Krüger wrote:
>>> Hi,
>>> I'm trying to make slomos smoother, e.g. interpolating 25fps to 50fps to have a smooth 50% slomo when the resulting 50 fps is played back at 25 fps. My understanding is that no filter for that kind of thing exists currently as part of ffmpeg. AFAIK ffmpeg just duplicates frames when increasing frame rate or allows framerate to be interpreted differently using the setPTS filter.
>>> As a "cheap" alternative to real frame interpolation (which would probably involve motion vectors, I suppose btw. are these exposed in public API at the moment?)
>> AVFrame.motion_val
>> but that is libavcodec API and current not propagated through the
>> filter graph
>> though keep in mind that
>> 1. these would be the vectors the encoder used and thus a bad encoder
>>   means bad vectors and bad interpolation
>> 2. The vectors with good encoders are choosen to maximize quality per
>>   bitrate not "be close to the actual real motion"
>> So i suspect it would work better if you just redo the motion
>> estimation
> This was proposed much time ago, a filter doing motion estimation
> (relying on libavcodec code) would be cool and could even help to
> improve the current libavcodec ME implementation.

Thanks Thilo, Michael and Stefano for the helpful feedback! Yes, I agree it would be cool and I would be one of the first to use it, however I lack the theoretical background and resources to implement it myself, that is why I was thinking about going the cheap route with the blending (i.e. weighted averaging) approach for a start.

However, if someone more knowledgable has an estimate how much work is required for a proper interpolation solution, one could see whether there is a way to get some funding for this. However, I would assume it is not something anyone does in a few hours so I guess to pay a "normal" hour-rate would exceed what I could come up with at this point but maybe something to motivate someone to start something that makes sense anyway. Regardless of that, I'll start looking into the code.


More information about the ffmpeg-devel mailing list