[vlc-devel] [vlc-commits] vout: fix picture lock/unlock with private pool
thomas at gllm.fr
Tue Nov 4 09:53:09 CET 2014
On Mon, Nov 3, 2014, at 21:19, Rémi Denis-Courmont wrote:
> 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
> unlocking code at plugin deactivation.
> Then again, I don't think locking makes much sense at all. Even without
> 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,
> > 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
> 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
> Android but in general, they most definitely do.
I proposed 2 patches to fix mediacodec on master with current pool
Even though, I'll try to have a look at both android surface and opaque
vout to get rid of picture looking.
> Rémi Denis-Courmont
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
More information about the vlc-devel