[vlc-devel] [PATCH] Avcodec: limit the number of threads automatically selected to 12

Denis Charmet typx at dinauz.org
Tue Jan 3 23:36:36 CET 2012


Le jeudi 29 décembre 2011 à 04:24:44, Laurent Aimar a écrit :
> On Thu, Dec 29, 2011 at 09:31:07AM +0100, Denis Charmet wrote:
> > Le mercredi 28 décembre 2011 à 11:59:49, Rafaël Carré a écrit :
> > > Le 2011-12-28 21:08, Jean-Baptiste Kempf a écrit :
> > > > It seems that over 16 doesn't behave well. Reduce it further for safety
> > > 
> > > What is the problem exactly ?
> > > 
> > IMO, as I said earlier I strongly suspect a race condition in picture
> > pool with two threads working on the same picture. Would'nt it be
> > cleaner and safer to just lock/unlock around decoder_NewPicture in
> > avcodec/video.c ?
>  A decoder goes through vout_GetPicture() which already protects the
> pool used with a lock.
>  I think the issue is that the pool might be too small when there is
> too much thread as the latency increase.

As usual you are right, it's not a race condition... it's just
vout_FixLeaks that randomly release a picture if the pool is empty with
picture_pool_NonEmpty.

>  For a quick test, could you test by increasing the value dpb_size
> in src/input/decoder.c by the number of threads (in the function
> vout_new_buffer()). If it fixes the issue, decoder_t will have to be
> extended to allow transmitting the value.

Using the number of thread doesn't work an H264 pool use a dpb_size of
18 and 6 threads are enough to cause the assertion failure. With 6
threads I can't reproduce the assertion failure with a dpb_size of 21.
I'll let ffmpeg-mt expert determine what may be the best value for this.

Regards,


-- 
TypX
Le mauvais esprit est un art de vivre



More information about the vlc-devel mailing list