On 17.10.2017 20:12, Nicolas George wrote:
Le sextidi 26 vendémiaire, an CCXXVI, Tobias Rapp a écrit :
This commit seems to break transcoding of some input files on machines with
a lot of CPU cores. See attached script that reproduces the problem
("-threads 32" is used to simulate the situation of a multi-core CPU).
Sorry for noticing late but it took me some time to track down the problem
and git bisecting it. The issue seems to be triggered by the high number of
audio packets in the input file (~375 packets per second). Input files that
have a lower audio packet rate work fine.
Thanks for reporting. I fear this will be tricky to debug.
I think the change you have tracked cannot be the cause of the issue,
since it does not touch anything related to threading.
Yes, I also don't see why this patch correlates with the number of
threads. But when bypassing the push_frame() function from the patch by
adding an immediate "return 0" the problem disappears.
What this change does, on the other hand, is increase the efficiency of
the scheduling in lavfi. That can cause more work for filters that do
use threading, and reveal a race condition there.
I do not have access to a 32-core system. Can the problem be reproduced
with your script with just "-threads 32" without such a system? How
ofter does it manifest?
I'm able to reproduce the issue reliably on each run of the test script
on three test machines:
- Windows 64bit 32-core, without "-threads 32"
- Windows 64bit 2-core, with "-threads 32"
- GNU/Linux 64bit 2-core, with "-threads 32"
What seem to help as a work-around is adding "-max_muxing_queue_size 1000".
Regards,
Tobias
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
