[FFmpeg-devel] New design problem with filters

[Nicolas George]

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?

Regards,

-- 
  Nicolas George
-------------- 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/40041ce9/attachment.asc>