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

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.