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

[Marton Balint]

On Sun, 9 Jul 2017, Paul B Mahol wrote:

> On 7/9/17, Marton Balint <cus at passwd.hu> wrote:
>>
>> On Sun, 9 Jul 2017, Paul B Mahol wrote:
>>
>>> On 7/9/17, Marton Balint <cus at passwd.hu> wrote:
>>>>
>>>> On Sat, 24 Jun 2017, Nicolas George wrote:
>>>>
>>>>> Le sextidi 6 messidor, an CCXXV, Paul B Mahol a ecrit :
>>>>>> The reverted commit breaks lot of filters and I failed to find fix,
>>>>>> the only logical solution
>>>>>
>>>>> It breaks a corner-case option of, indeed a lot of, filters. I have not
>>>>> yet been able to track down the exact cause of the problem, I still have
>>>>> all this in my work tree.
>>>>>
>>>>
>>>> The revert itself broke a rather simple buffersrc->buffersink case as
>>>> well:
>>>>
>>>> ffmpeg -f lavfi -i "testsrc[out0];sine[out1]" -bsf:a noise=dropamount=1
>>>> out.avi
>>>>
>>>> ffmpeg is now consuming all memory, it seems video frames are stuck in
>>>> the
>>>> filter graph forever.
>>>>
>>>> (the dropamount parameter to the noise bitstream filter was just
>>>> committed
>>>> to be able to drop all packets of a stream)
>>>
>>> I believe you are referring to another commit which also needs to be
>>> reverted.
>>
>> No, definitely this one (04aa09c4bcf2d5a634a35da3a3ae3fc1abe30ef8). The
>> input frames are arriving just fine, so ffmpeg can initialize the
>> filtergraph, but only one video frame comes out of the filtergraph, the
>> others are stuck there forever.
>
> Nope. Without that revert bunch of filters are simply broken.

I am not saying they aren't, I'm just showing a case where your revert is 
breaking another case which was working before. Nicolas also stated there 
can be cases where the old code (before the revert) worked better. I just 
hope that I found a simple enough case, so somebody can take a look and 
find the root cause.

Regards,
Marton