[FFmpeg-devel] New design problem with filters

Michael Niedermayer michaelni at gmx.at
Sun Aug 19 17:32:48 CEST 2012


On Sun, Aug 19, 2012 at 03:59:40PM +0200, Nicolas George wrote:
> I just found another design problem with filters and ffmpeg (command-line
> tool).
> 
> Just try this:
> 
> ffmpeg -i some_big_video /tmp/a.mkv -t 1 /tmp/b.mkv
> 
> and watch it eat all system memory. The reason is that decoded frame are
> still added to the filter to b.mkv, and since they are never requested the
> accumulate in buffersrc.
> 
> Note that the problem is present in avconv too, and was probably already
> present in ffmpeg for quite some time: I just found it, I did not create it.
> 
> For simple filters, the solution is easy, since when we close the output
> stream we can flag the corresponding input filter too. Making
> ist->decoding_needed a counter and not a boolean might help.
> 
> For complex filters, the problem is more complex, but I have a suggestion:
> 
> - First, add AV_BUFFERSRC_FLAG_PUSH to make buffersrc push the frame as soon
>   as it is added and not buffer it. That way, the frame will arrive to the
>   output, and be discarded. Expensive processing is performed for nothing,
>   but at least it does not eat memory.
> 
> - Second, define a return code for filters to refuse frames on their input,
>   and add an API to trigger it on buffersink: the error will follow the
>   calls back to the corresponding buffersrc and allow us to stop feeding it.
>   The obvious choice for the error code would be AVERROR(EPIPE) (the code
>   you get when you try to write on a closed pipe and ignore SIGPIPE), but
>   AVERROR_EOF is probably a better choice for portability.
> 
> Any comments before I start coding?

yes, discarding frames for ended outputs and returning an error if
more is pushed there sounds like the best fitting solution ...

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120819/6ff9385f/attachment.asc>


More information about the ffmpeg-devel mailing list