The video output thread never allocates pictures from the decoder
thread. It uses the reserve private pool and, when if not rendering
directly, the display pool. Thus it has nothing particular to do when
a decoder pool picture is released.

(vout_PutPicture() wakes the thread up to kick rendering.)

Default disabled for now.

The pixels allocated from picture_NewFromFormat were replaced (and leaked) by
pixels allocated by android native windows. This also leaded to a crash on
Close when subtitles_picture was freed.

Use picture_NewFromResource with an empty to resource in order to don't
allocate any pixels.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Use a separate callback for pictures allocated in heap and pictures
allocated from video output buffers.

This is only used in error corner cases, and is always the same as
calling subpicture_Delete() directly.

All variants of the filter_t.video.buffer_del callback invoke
picture_Release() - possibly through recursion.

Most filters used picture_Release() directly already.

Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

This makes picture_pool_Get() reentrant.

This reduces the size of picture_gc_sys_t. The callbacks are always the
same for all pictures in a given pool.

We can offload the picture deletion to Destroy() in all cases.

The item-change callback might be called very often, and thus an
own code path is better, with only necessary updates.

Additionally, this fixes multiple resume playback dialogs occuring
at once when starting playback in certain situations.

refs #11981

Also handles CustomAttributes

Was downloading regardless of consumer

Fixes most of glitches for non live streams, especially on
quality change.