fix gles2 plugin not being built

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
sout: chromecast: close connection on load failure

only msgClose won't stop listening, so we need to
flag as CONN_DEAD as well so it will send the close
message and exit thread
demux: libmp4: fix heap overflow in stdp debug code (fix #12358)
demux: mp4: fix heap buffer ofw with zero chunk (fix #12356)
demux: tta: fix heap buffer ofw (fix #12357)
demux: livavi: fix heap buffer ofw in strf parsing (fix #12359)
demux: libavi: fix heap write ofw
demux: ogg: fix use after free (fix #12360)
demux: asfpacket: fix use after free (fix #12361)
demux: libmp4: add quicktime mp4a/wave/mp4a rule
mmal/vout: Configure latency target

The mmal video_render element allows to configure a latency target. Although
the parameter is named AUDIO_LATENCY_TARGET it is not actually related to
audio but synchronizes frame draws with hdmi vsync. It tries to match the hdmi
vsync rate to the picture render rate by slightly varying the hdmi pixel
clock. This makes only sense if the actual display refresh rate matches the
video frame rate, so that only minimal drift compensation is required. Thus
enable it only when mmal-adjust-refreshrate is activated.

Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
mmal/vout: Apply phase offset to match vsync period

As the latency target alone is not ensuring that we start with a sane phase
shift between vsync and drawing, we read back the phase shift provided by the
mmal rendering statistics and use it to compute a phase offset which we apply
to the picture date, so that the core shifts the display call accordingly.
Doing this frequently allows us to resync if a distortion or display reset
caused the offset to break.
This is only enabled if mmal-adjust-refreshrate is enabled, because the whole
vsync synchronisation makes only sense if display and videorate match.

Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
mmal: Fix buffer size computation

The buffer sizes in opaque case were computed by a mixture of hardcoded values
and mmal defaults. This caused breakage due to changes of the default values
in recent mmal versions. To avoid this in the future, the buffer sizes are
completely hardcoded now. As we have a shared header for mmal now, move the
required define for shared values into that header.
Using this new computation we can reduce the buffer size for opaque case by 2,
which saves some memory.

Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
mmal/vout: Use current pictures format for rate matching

Instead of using the video_format which was set on output creation, always
check the refreshrate against the current pictures frame duration.

Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
demux: libmp4: fix heap buffer write ofw in chpl (fix #12366)
demux: mp4: fix last chunk size computation (fix #12362)
mmal/codec: Set progressive flag on frames

Query the interlace type from the mmal decoder on format change and pass it
through to vlc_pictures.

Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
contrib: don't hardcode android api

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
contrib/bootstrap: add x86_64 for android

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
android: fix nanf detection

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