[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