This is no longer necessary as picture pools are locked internally.

The pool can now have its own independent garbage collector, that no
longer clobbers the original garbage collector.

Otherwise picture references from the private pool get clobbered.

That fork uses a different path to avoid problems

Why be consistent, Qt?

Close #12671

For resumption we need to rely on the "time" variable instead of
"position", as the total duration of the file might not have been
set yet.

Also simplifies the code.

close #11981

The cone does not really fit and looks ugly. Instead, use the
broadcast icon for all internet-related sd's and local icon for
devices category.

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

picture_Hold() is reentrant anyway. The vout picture lock protects
the decoder pool. The decoder pool may be modified by picture_Release()
but not by picture_Hold().

The picture FIFO has a lock internally to protect its internal state
while picture references protect the pictures.

There is no need to protect the FIFO usage with the picture lock.
At this point, the picture lock is only protected the decoder pool.

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.