[FFmpeg-devel] New design problem with filters
nicolas.george at normalesup.org
Sun Aug 19 15:59:40 CEST 2012
I just found another design problem with filters and ffmpeg (command-line
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel