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. -- Xenocrates
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
