1. 09 Oct, 2014 3 commits
    • Julian Scheel's avatar
      mmal: Fix buffer size computation · 54f93974
      Julian Scheel authored
      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: default avatarJulian Scheel <julian@jusst.de>
      Signed-off-by: default avatarJean-Baptiste Kempf <jb@videolan.org>
      54f93974
    • Julian Scheel's avatar
      mmal/vout: Apply phase offset to match vsync period · 04e9ee96
      Julian Scheel authored
      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: default avatarJulian Scheel <julian@jusst.de>
      Signed-off-by: default avatarJean-Baptiste Kempf <jb@videolan.org>
      04e9ee96
    • Julian Scheel's avatar
      mmal/vout: Configure latency target · 28c484c2
      Julian Scheel authored
      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: default avatarJulian Scheel <julian@jusst.de>
      Signed-off-by: default avatarJean-Baptiste Kempf <jb@videolan.org>
      28c484c2
  2. 08 Oct, 2014 13 commits
  3. 07 Oct, 2014 5 commits
  4. 06 Oct, 2014 18 commits
  5. 05 Oct, 2014 1 commit
    • Rémi Denis-Courmont's avatar
      XCB/XVideo: do not fallback to YUYV output for RGB inputs · 2c1940d7
      Rémi Denis-Courmont authored
      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.
      2c1940d7