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

Le 28/10/2014 23:11, Frédéric Yhuel a écrit :
>  static int MP4_NextBox( stream_t *p_stream, MP4_Box_t *p_box )
>  {
> -    MP4_Box_t box;
> +    MP4_Box_t box = {0};
>
>      if( !p_box )
>      {
>

Better fail early. (untested, no sample)
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

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

picture_pool_NonEmpty() still won´t work quite right when the overflow
happens, but that function is a horrible dysfunctional hack anyway.

libgcc_s is still needed, for C++ modules

Gotta love libtool

Ref #12620

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

Use picture_Release() directly.

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>