[vlc-devel] [vlc-commits] vout: fix picture lock/unlock with private pool

[Rémi Denis-Courmont]

Le lundi 03 novembre 2014, 15:35:37 Thomas Guillem a écrit :
> With Mediacodec, we use android/opaque vout that use a pool with lock /
> unlock. Because of that, we don't use the code patch where direct
> rendering is enabled.

Combining DR and picture locking does not make much sense. With DR, the 
picture may still be referenced by the decoder or filters while it gets 
displayed. So I don't see the point in (locking and) unlocking then...

You might just as well call the locking code from the pool() callback and the 
unlocking code at plugin deactivation.

Then again, I don't think locking makes much sense at all. Even without DR, 
prepare() seems more practical than unlock() and picture_Release() than 
lock().

> A solution for my problem is to move the "!picture_pool_NeedsLocking()"
> check and have, at the end of vout_InitWrapper:
> 
> if (!picture_pool_NeedsLocking(sys->decoder_pool))
>     sys->private_pool = picture_pool_Reserve(sys->decoder_pool,
>     private_picture);
> 
> I have a working patch, but I'm not sure about all the consequences.

vout->p->private_pool will be NULL and the process will crash if the 
private_pool is ever required (see src/video_output/video_output.c).

Assuming the video output supports direct rendering and subpicture blending, 
the private pool seems to be needed for:
- snapshot while a subpicture is present,
- filter-allocated pictures.
And there are some more cases otherwise. Maybe none of those ever happens on 
Android but in general, they most definitely do.

-- 
Rémi Denis-Courmont
http://www.remlab.net/