[FFmpeg-devel] [PATCH 1/7] Revert "Revert "lavfi/buffersrc: push the frame deeper if requested.""

Tobias Rapp t.rapp at noa-archive.com
Wed Oct 18 10:23:20 EEST 2017

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".


More information about the ffmpeg-devel mailing list