Signed-off-by: Hugo Beauzée-Luyssen <hugo@beauzee.fr>

This should avoid numerous crashes

This is meant to serve as a base for our Outreachy student's project:
https://wiki.gnome.org/Outreachy/2015/MayAugust#VideoLAN
refs #9396

On the one hand, when decoding in hardware, the video surface
dimensions will match the coded dimensions, rather than the visible
ones. Otherwise the hardware decoder would not have enough space for
its output. In this the libavcodec plugin does not add padding (since
libavcodec SIMD optimizations are not involved).

On the other hand, when decoding in software, the video surface height
must not include the padding added by libavcodec SIMD optimizations. So
then the visible height needs to be used to avoid bleeding green lines.

This reverts commit 3447e875.

It allows an application to re-activate video when the media was played without
video (i.e. with :no-video).

It happens in case of underflow: if there is too much delay between two
consecutives call of Play or TimeGet.

If activated, most of  the resampling  will be done by VLC.

Deactivated for now since android resampler is better than the ugly resampler.

A wise man once said: "always do a make distcheck when you move some files"

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

A failing decoder_UpdateVideoFormat is critical, unlike a failing
decoder_NewPicture.

Now that we can open and close MediaCodec from the same thread, we can reach
quickly the limit of 512 LocalRefs.

Don't abort if H264 fmt doesn't have any valid size or extra. The SPS/PPS will
be parsed from DecodeVideo, MediaCodec will be (re)started if video size changes
and valid SPS/PPS will be sent via BUFFER_FLAG_CODEC_CONFIG flag.

Via PutInput with the BUFFER_FLAG_CODEC_CONFIG flag. It allows to send codec
specific data during playback without restarting MediaCodec. If you choose to
configure codec via this flags, you shouldn't set the "csd-0" buffer during
MediaCodec initialization.

Since it's the buffer containing the "csd-0" configuration buffer.

The goal is to expose h264_parse_sps and h264_parse_pps functions that can be
used from decoders.

It fetches the SPS and PPS pointers from an Annex B buffer.

This fixes a regression in vlc2.2. It is described on the forum at :
https://forum.videolan.org/viewtopic.php?f=15&t=125790&sid=05f4d8a32853034ce6d497ca15bab1e8

This fallback was an attempt to recover when a skin is poorly designed,
but it causes problems under some circumstances. So let's remove it !

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

after changes on the way the codec is reinitialized after seeking and the internal lock
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>

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>

may share some resources between the decoder pool pictures and the va.
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

Pointed-out-by: Thomas Guillem <thomas@gllm.fr>

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