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>

The Wayland background thread dereferences said variable, but is started
before the value is written there. Occasionally the thread would win
the race and segfault in wl_display_get_fd.
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

Ulgy resampler produces really noisy output with some samples,
it is way better with libsamplerate.

Use global pmt es count, as there's no multiple pmt

Because the no-trust-pcr thing isn't a real fix.

A variable cannot be inherited if it is not a configuration item.
Note this only avoids generating an error; VBI cannot work without the
plugin anyway.

Since (*) we can't tell if the sample is v0 follows the ISO
spec or comes from qt and then means uncompressed,
we can't agregate samples reliably.

* our muxer removed qt brand from files.

This reverts commit 39353b9c.