[vlc-devel] [vlc-commits] vout: fix picture lock/unlock with private pool
remi at remlab.net
Mon Nov 3 21:19:45 CET 2014
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
> 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,
> 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.
More information about the vlc-devel