[FFmpeg-devel] [PATCH 3/3] ffmpeg: try to guess a good value for the thread message queue.
michaelni at gmx.at
Thu Feb 19 17:54:47 CET 2015
On Thu, Feb 19, 2015 at 12:25:44PM +0100, Nicolas George wrote:
> Le nonidi 29 pluviôse, an CCXXIII, Michael Niedermayer a écrit :
> > iam a bit concerned about the possibility of this unneccesarily
> > allocating a million packets
> > i think IIUC this amount will actually be alloated no matter if its
> > needed or not
> Yes, that will allocate all the FIFO, and with 1<<20 maximum, that makes
> 96 megaoctets, that is too much.
> On the other hand, my hardware really needs a queue size > ~500 to avoid
> ALSA overruns with a simple v4l2+ALSA capture. I suspect other settings may
> need even larger queues. Otherwise, the resulting capture is unusable.
> Well, I suspect the maximum size should be made an option, with a reasonable
> default (maybe 1024?).
> It would not take too much work to make the queue size dynamic, thus only
> eating memory when it is required. But it still needs a reasonable maximum
> in case something goes wrong.
> I will try to produce a new patch, but do not hesitate to share any thoughts
> about it.
i dont really have an idea about this problem but
more generally ive always had the feeling that input device buffering
belongs to libavformat/libavdevice and not the application
because that way it could be used by all applications.
This could possibly even be implemented as a seperate demuxer similar
to the cache demuxer and used by any demuxer which needs such
buffering. this would if it works out keep the buffering code cleanly
seperated from both demuxers/devices and the user application, making
maintaince easy as well
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I have often repented speaking, but never of holding my tongue.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 181 bytes
Desc: Digital signature
More information about the ffmpeg-devel