[FFmpeg-devel] [PATCH] libavfilter-soc: Make overlay handle still images

Vitor Sessak vitor1001
Thu May 7 22:54:52 CEST 2009

Michael Niedermayer wrote:
> On Thu, May 07, 2009 at 10:45:53PM +0300, Martin Storsj? wrote:
>> Hi Vitor,
>> On Wed, 6 May 2009, Vitor Sessak wrote:
>>> Just a question: how are you testing those changes?
>> I'm testing it with the following command line:
>> ffplay in.mov -vfilters "movie=0:png:overlay.png, scale=0:0 [over1], [in] [over1] overlay=10:10 [out]"
>> and similarly with ffmpeg.
>>>> +        oldpts = over->pics[idx][1]->pts;
>>>>          if(avfilter_request_frame(link->src->inputs[idx]))
>>>>              return -1;
>>>> +        if(over->pics[idx][1]->pts == oldpts) {
>>>> +            /* no new pts, we're probably at eof, pull a frame
>>>> +               from the other queue to keep it moving */
>>> The correct way to know if the video is over is to check if request_frame()
>>> returned -1.
>> That was my initial guess, too, but the movie source filter provides the 
>> last frame repeatedly instead of returning -1.
> I think repeatly providing a frame with the same PTS ad infinitum is not
> correct
>> This can easily be fixed by the first attached patch. (It contains checks 
>> both before and after movie_get_frame, to avoid unnecessary calls to the 
>> underlying layers after reaching eof.)
>> When this is applied, the eof handling in the overlay filter can be fixed 
>> in a few other ways, named -overlay-eof2 and 4.
>> The first one, -eof2, alters the frame pulling logic only slightly. The 
>> request_frame function returns -1 when unable to pull frames from both 
>> streams. Since a stream may contain only one frame, it requires the image 
>> copying to try to check over->pics[idx][1] if over->pics[idx][0] is null.
>> The second way of solving it, -eof4, moves the last frame from 
>> over->pics[idx][1] into over->pics[idx][0] by a 
>> start_frame(link->src->inputs[idx], NULL) if there still is a frame in 
>> over->pics[idx][1]. This way, all input frames should be output too. (In 
>> the original overlay filter logic, the last input frame wouldn't be 
>> output.)
>> Do these look sensible?
> returning -1 is not good, it should be AVERROR_EOF and this must be
> documented in the header.
> also poll_frame() likely should similarly return AVERROR_EOF

I saw that avfilter.h does not say what to do in case of EOF. What I 
suggest is:

1- request_frame() should return AVERROR_EOF
2- poll_frame() should return 1

The last point seems weird, but for me it is very practical in two cases:

1- Filters that do not implement poll_frame() (like vsrc_movie, that can 
decodes always more as needed) will keep behaving correctly

2- Filters that need to do considerable work to know if the file reached 
EOF or not. Think again of vsrc_movie with a truncated file. The only 
way to know that there is no more frames is to try (and fail) to decode 
the last one. Putting all this code in poll_frame() would make 
everything a big mess.

And the header should document that here EOF actually means "no more 
frames" instead of EOF...


More information about the ffmpeg-devel mailing list