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.

Signed-off-by: Adrien Maglo <magsoft@videolan.org>

aka flip4mac format.

The "libvlc_MediaListPlayerPlayed" event was defined but unused.
It is now fired when libvlc_media_list_player is played until last item in the playlist
Signed-off-by: Igor Prokopenkov <cmyk777@gmail.com>
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>

utility function to convert hvcC extradata to annex b.
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>

If the XVideo driver does not provide any RGB image format, then we
are definitely better off with GLX than XVideo. Consider:
 - GLX supports proper subpicture blending - not XVideo,
 - GLX does not need chroma conversion - XVideo does in this case.

This change makes no difference if the XVideo driver supports RGB.

The core cannot blend subpictures to hardware surfaces. In principles,
blending could be performed post chroma conversion, but this is not
supported by the video output wrapper so far.