[FFmpeg-devel] [PATCH] af_asetnsamples: push as many frames as ready

Andrey Utkin andrey.krieger.utkin at gmail.com
Sun Aug 12 19:43:09 CEST 2012


2012/8/8 Nicolas George <nicolas.george at normalesup.org>:
> Le duodi 22 thermidor, an CCXX, Andrey Utkin a écrit :
>> Could you please elaborate what you mean?
>> Personally I don't see any possible pushing behaviour except the
>> currently implemented.
>
> Let us assume the frame size is 1000:
>
> Version 1:
>
> prev->asetnsamples: push 0000-2999
> asetnsamples->next: push 0000-0999 (1000-2999 still in FIFO)
>                     stop
> prev->asetnsamples: push 3000-5999
> asetnsamples->next: push 1000-1999 (2000-5999 still in FIFO)
>                     stop
>
> This version is bad, because data is accumulating in the FIFO.
>
>
> Version 2:
>
> prev->asetnsamples: push 0000-2999
> asetnsamples->next: push 0000-0999
>                     push 1000-1999
>                     push 2000-2999
>                     stop
> prev->asetnsamples: push 3000-5999
> asetnsamples->next: push 3000-3999 (4000-5999 still in FIFO)
>                     push 4000-4999 (5000-5999 still in FIFO)
>                     push 4000-4999 (FIFO empty)
>                     stop
>
> This version is acceptable: no data is accumulating. But it is not perfect,
> because asetnsamples is flooding next instead of returning. The application
> is stuck inside libavfilter, and during that time some soundcard buffer may
> be underrunning.
>
>
> Version 3:
>
> prev->asetnsamples: push 0000-2999
> asetnsamples->next: push 0000-0999 (1000-2999 still in FIFO)
>                     stop
> prev->asetnsamples: push 3000-5999
> asetnsamples->next: push 1000-1999 (2000-2999 still in FIFO)
>                     push 2000-2999 (FIFO empty)
>                     push 3000-3999 (4000-5999 still in FIFO)
>                     stop
>
> In this version some data stays in the FIFO longer than strictly necessary,
> but the amount is bounded by by the size of the pushes from the previous
> filter.
>
> The benefit is that before prev pushes the next batch, next has time to
> request the rest of the data, at its own rhythm.
>
>
> Version 2 would be implemented by the following pseudo-code:
>
>         add_frame_to_fifo(inref);
>         while (fifo_large_enough())
>             push_one_frame();
>
> Version 3 would be implemented by the following code:
>
>         while (fifo_large_enough())
>             push_one_frame();
>         add_frame_to_fifo(inref);
>         if (fifo_large_enough())
>             push_one_frame();

I have re-read your explanation like ten times in different days.
Unfortunately, i fail to get the point. As long as i don't understand
it, i can't take responsibility of posting a patch with your "Variant
3" under my authorship.
So i ask you for preparing the "Variant 3" patch, or pushing "Variant
2" patch which i have already posted.
Patching this bug manually makes it uncomfortable for me to test my
app, so please push something as soon as possible. Thanks.
-- 
Andrey Utkin


More information about the ffmpeg-devel mailing list