On Thu, 22 Dec 2016, Nicolas George wrote:
Le primidi 1er nivôse, an CCXXV, Marton Balint a écrit :
It seems after this patch I got an infinite loop if I try to convert the
attached file using this command line:
./ffmpeg -i amerge-test.mov -filter_complex "[0:a:0][0:a:1]amerge=2[aout]"
-map "[aout]" out.wav
Can you confirm the attached patch fixes the issue?
Yes, thanks.
If so, please do not hesitate to push it without waiting for me if (and
only if) that is convenient for you.
Ok, pushed.
Note that in my build FF_BUFQUEUE_SIZE in libavfilter/bufferqueue.h is set
to 256, because otherwise it errors out with ENOMEM, but that also happens
with the old filtering code. On the other hand, the old filtering code and
FF_BUFQUEUE_SIZE set to 256 does allow the file to properly convert.
I wish I remembered that precision before spending time tracking the
ENOMEM :(
Fortunately, one of the perks of these changes is they are a step closer
to getting rid of that particular issue once and for all. I suspect
rudimentary memory limitation will be needed first, but that can be
managed.
I guess we could buffer the undecoded packets instead of the decoded
frames if there is a higher-than-usual delay between the streams. Is this
also your plan?
Thanks,
Marton
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
