The framerate of pictures might change without a change of the general input
format information. So to ensure that we always handle the correct refreshrate
we compare the refreshrate of each picture with the currently configured one.
Signed-off-by: Julian Scheel <julian@jusst.de>
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>

Makes debugging of badly deinterlaced content a bit easier.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

The logic setting the top_field_first flag was broken as it evaluated the
actual mode in case of progressive instead of in interlaced case.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

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

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

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

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

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>

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>

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>

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>

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>

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

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

This is necessary for compatibility with C++. The keyword is only
meaningful in definition, not in declaration anyway.

generate_new_chunk() never proceeds to the last fragment run if the
sentinel is included.
Signed-off-by: Tristan Matthews <tmatth@videolan.org>

ogg was still being pulled in as a dependency when cross-compiling, which
would break certain build configurations.