[FFmpeg-devel] [PATCH] avfilter/bufferqueue: Increase buffer queue size

[Nicolas George]

Le sextidi 16 prairial, an CCXXII, Tobias Rapp a écrit :
> It is the smallest increase that matches the "Powers of 2 are recommended"
> comment above the constant definition and does not cause an error with the

The comments exists just because there are "% N" in the code, and "% N" is
more efficient if N is a power of 2 (and the compiler has enough information
to exploit it, which I checked is true in this particular case).

The difference is certainly quite negligible, but AFAIK there are no other
criterion to chose the number.

> sample files available to me (the one file attached to ticket #3510 and two
> files generated by Adobe Premiere Pro CC).

The original value was quite arbitrary to start with: "normal" behaviour can
cause "a few" frames to arrive on the wrong stream, "a few" meaning much
less than 10, so 32 seemed quite safe.

It seems that adobe's product interleaving rules are to put one second of
preload at the beginning of each audio stream. At 48 kHz with 1024 samples
per frame, that makes 47 frames: more than 32, less than 64.

So yes, 64 will work, and since adobe's products are, unfortunately, quite
widely used, the change is certainly useful.

But we must bear in mind that it does not really solve the issue: if someone
works at 96 kHz, for example, it will probably break again.

I am still looking for a good solution for that issue.

Buffer queue overflow can occur also for filter graphs that are subtly
wrong, and that can happen if the user writes the wrong label, or the labels
in the wrong order, quite easily. The current value, 32, would eat >200 Mo
with frames from x11grab. But we can not raise the value too much: eating
200 Mo, even 1 Go, before reporting an error, is reasonably ok, but eating
32 Go and dragging the host to a crawl due to swapping, that is not ok.

I should probably be looking at more advanced heuristics: total amount of
memory required by the queued frames, difference between the head and tail
timestamps, etc. But there is no easy answer, and that will make the code
more complex.

In the meantime, I am ok with rising the value to 64, it is quite reasonable
and fixes a well identified and common case. The commit message should
explain it. Something like that: "Files produced by [that product] have the
first second of audio not interleaved. With common settings, that makes more
than 32 frames but less than 64."

And for people who need a still larger value, for now I say: double-check
your filter graph if you do not want to risk an oom crash, and then insert
fifo or afifo where the overflow occurs.

A possible short-term enhancement would be, when overflow occurs, to make
sure that the exact point it happens is printed. Not just ENOMEM or "Buffer
queue overflow, dropping" but "Buffer queue overflow at amerge:in0, check
that the filter graph is not clogged and consider adding the (a)fifo
filter". I have made a note in my TODO list for that (but do not consider it
a lock).

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140604/c0062fdf/attachment.asc>