It fixes buffer allocations on some old android versions.
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>

CVE-2014-9495

Move to configure.ac

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

Extended version of libvlc_media_parse_async. It uses a flag to specify parse
options and returns an int for error handling.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Expose an event to libvlc users which allows them to get notified when a media
list reached the end. That is, when the media list is attached to a media
(subitems) that completed a parsing. Or when the media list is attached to a
media discovery that stopped.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

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

Don't call libvlc_media_list_set_media from media since it causes
p_md->p_subitems to retain p_md while p_md is already retaining
p_md->p_subitems, therefore these 2 objects won't be releasable.

Add a new internal variable: p_internal_md that is set from media without
retaining it.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

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

 default.
Signed-off-by: Jean-Paul Saman <jpsaman@videolan.org>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

 not have audio
Signed-off-by: Jean-Paul Saman <jpsaman@videolan.org>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

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

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

media's sub_items should be only writable by media.
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

This way, libvlc_media_subitems can be called before, during or after a
parsing. Furthermore, this allows to attach media_list events before
libvlc_media_parse is called.
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

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

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

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

It returns true if the demux is a playlist (an archive, a directory or a
network share is also a playlist).

It will be used by the preparser in order to know if it should call demux_Demux
to fetch sub items.
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

Until now error concealment was disabled for h264 decoding because the mmal
h264 decoder did not properly parse SEI so that depending on the stream it
could happen that no valid picture would be detected at all and therefore no
picture would be shown at all. Latest raspberry firmware fixed this, so that
error concealment works properly and can be enabled.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

Ensure that the pictures which are rendered by display() are released before
display() returns. This is required to ensure that on stop all pictures are
released and the core can safely cleanup the pool. Without this the core
might detect pictures as leaks and free them on its own. Once this happens
we're running straight into a double free.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

It is required to flush the filter properly for stopping of playback to work
reliably. Without flushing the code might detect pictures currently held in
the filter as lost which will lead to double frees later on.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

The in- and ouput port callbacks lead to access on the mmal pools, which are
not thread-safe. To deal with this the sys->mutex is used to lock against
usage of the mmal pools from the main thread.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

With previours cleanups we reduced the number of allocated mmal buffers and
buffer headers. This caused some issues as the mmal components had to wait for
buffers frequently, which slowed them down. To avoid framedrops and even
picture stalls revert to the old buffer configuration, which wastes a bit
memory in theory but works way more reliably and smoothly.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

The framerate stored in vd->source is not reliable in any case. Instead we use
the internally cached framerate which is updated from the actual pictures
which are rendered.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

The previous approach of calculating the buffers in transit was broken because
it assumed that buffers which were currently processed in the video output
stage are in transit. In fact only those buffers which are currently handed
off to the mmal output port of the filter plugin are to be counted as buffers
in transit. Fixing this avoids some framedrops due to missing/late buffers.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

The previous approach of calculating the buffers in transit was broken because
it assumed that buffers which were currently processed in the video output
stage are in transit. In fact only those buffers which are currently handed
off to the mmal output port of the video_decode plugin are to be counted as
buffers in transit. Fixing this avoids some framedrops due to missing/late
buffers.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

This hack is not required anymore as the buffer header lifecycle is properly
handled now. This ensures that the codec only sees buffers which are ready for
reuse and avoids some misbehaviour of the codec.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

Normally the decoder should not run out of input buffers as it is fed with
packetized data and for each input block a picture shall be generated. In rare
situations the decoder seems to fail internally and does stop generating
pictures. In this case the input buffers are not released either. If this
happens the whole pipeline stalls and vlc buffers input data until system runs
out of memory. To avoid this error case force the decoder to flush its port
if it runs out of input buffers. This causes a short image distortion but the
decoder won't block anymore.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

The mutex held within mmal_pictures is used to lock access of mmal
picture/buffer pools between vlc main thread and mmal callback threads. This
is only required to be locked per pool and not globally for all mmal modules.
Thus using a global mutex caused a slight performance hit when using mmal vout
and deinterlace simultaneously which operate on independent picture pools. Now
the pool owner provides the mutex handle when allocating the pictures, so
that independent locking can be used.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

If buffers were discarded because of wrong size or type a mmal buffer header
would be leaked each time.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

Instead of assuming that p_pixels[0] points to the mmal opaque handle retrieve
it from the picture_sys structure. Using p_pixels for the pointer was broken
due to vlc core copying p_pixels only for formats with actual data.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

The mmal/bcm host libraries haven been restructured lately, which requires
some tweaking in the detection.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>