1. 28 May, 2022 8 commits
  2. 27 May, 2022 18 commits
  3. 26 May, 2022 4 commits
    • Steve Lhomme's avatar
      vout: win32: simplify CommonControl · 269ac301
      Steve Lhomme authored and Jean-Baptiste Kempf's avatar Jean-Baptiste Kempf committed
      269ac301
    • Steve Lhomme's avatar
      vout: win32: do not return errors when CommonControl fails · 7696d313
      Steve Lhomme authored and Jean-Baptiste Kempf's avatar Jean-Baptiste Kempf committed
      We do not handle the reset_pictures callback so we can't return an error
      here. We never returned one anyway.
      7696d313
    • Jeffrey Knockel's avatar
      egl: add intermediate X11 window controlled by EGL · 2fe4871b
      Jeffrey Knockel authored and Jean-Baptiste Kempf's avatar Jean-Baptiste Kempf committed
      Asynchronous window resizes cannot be kept in sync with EGL.
      To keep the underlying X11 window and the EGL drawable sizes in sync,
      embed a new X11 window so that EGL can synchronously resize.
      
      At a high level, to resize, we (1) wait until EGL is done drawing, (2)
      resize the X11 window, and (3) wait for the window to be resized before
      EGL resumes drawing.
      
      With Nvidia, eglWaitNative() is sufficient to wait for the window to be
      resized.  With Mesa, it is not, so after eglWaitNative() we (for the
      Xlib backend) check if Xlib knows if the X server has already processed
      the resize and, if not, XSync(), or (for the XCB backend) wait on the
      void cookie corresponding to our resize request.
      
      To work around an issue with Mesa, we also call
      eglQuerySurface(EGL_HEIGHT) to coerce Mesa to observe the new X11 window
      size and resize its EGL surface.  On Nvidia, this is not required, but
      we call it in any case.
      
      Refs #26734 for EGL.
      2fe4871b
    • Jeffrey Knockel's avatar
      glx: add intermediate X11 window controlled by GLX · d0836b10
      Jeffrey Knockel authored and Jean-Baptiste Kempf's avatar Jean-Baptiste Kempf committed
      Asynchronous window resizes cannot be kept in sync with GLX.  To keep
      the underlying X11 window and the GLX drawable sizes in sync, embed a
      new X11 window so that GLX can synchronously resize.
      
      At a high level, to resize, we (1) wait until GLX is done drawing, (2)
      resize the X11 window, and (3) wait for the window to be resized before
      GLX resumes drawing.
      
      With Nvidia, glXWaitX() is sufficient to wait for the window to be
      resized.  With Mesa, it is not, so after glXWaitX() we check if Xlib
      knows if the X server has already processed the resize and, if not,
      XSync().
      
      Refs #26734 for GLX.
      d0836b10
  4. 25 May, 2022 8 commits
    • Marvin Scholz's avatar
      codec: videotoolbox: handle kVTVideoDecoderReferenceMissingErr · f7434e60
      Marvin Scholz authored and Jean-Baptiste Kempf's avatar Jean-Baptiste Kempf committed
      The kVTVideoDecoderReferenceMissingErr error is not a critical one,
      but without it being handled here, it would lead to aborting with
      VideoToolbox and falling back to Software.
      
      Reproduced this with a sample provided by zhilizhao(赵志立),
      related to !1790.
      
      I assume that before this error code was introduced in macOS 12/iOS 15,
      VT did just return the NULL image buffer with a success status code,
      leading to the issue seen in !1790.
      f7434e60
    • Alexandre Janniaux's avatar
      video_output: reset chrono on Request and Flush · ca40c0c0
      Alexandre Janniaux authored and Hugo Beauzée-Luyssen's avatar Hugo Beauzée-Luyssen committed
      Chrono are estimating the duration of the rendering when displaying
      frames, but they were only initialized at the vout thread creation, and
      not whenever the decoder outputs a different format (eg. because it's a
      different decoder). It means that when rendering a 8k 24fps frame, and
      then 360p 60fps picture, we'd expect that the first frames from the 360p
      stream renders with the same timing as the 8k 24fps, which could lead to
      useless drops. vout_Request was usually followed with a forced picture,
      which helped mitigate the issue, but the chrono are averaging with
      previous values, leading to local increase of expected rendering time at
      the beginning.
      
      Likewise, when flushing, timing constraints could have change, though
      admittedly there is less obvious reason for the constraints to change
      in this case. It still solves issues in the following cases:
      
       - The framerate matches the refresh rate and the offset-to-VSYNC has
         changed. It would reduce or increase the rendering time virtually
         without controls from VLC.
      
       - The rendering has been paused by a debugger at the middle of the
         measurement. It would artifically set chrono to a very high value,
         like 30 seconds, which means that a frame must arrive 30 seconds in
         advance from the decoder to the video output to be displayed.
      
      Rationnally, the chrono system is a heuristic to fast-forward the video
      pipeline when the stream cannot be rendered in normal condition and
      resetting the timestamps would not break already working streams,
      whereas it would only display at most one more late picture in the
      broken stream, which was already the case at the beginning of the stream
      because of forced pictures.
      ca40c0c0
    • Alexandre Janniaux's avatar
      video_output: flush static filters on picture drop · 8d390163
      Alexandre Janniaux authored and Jean-Baptiste Kempf's avatar Jean-Baptiste Kempf committed
      Filters like deinterlacers are using timestamps interpolation to
      generate intermediate frames, which might not work reliably when the
      timestamps are not from consecutive frames.
      
      When dropping a decoded picture, we were not notifying those filters and
      the next frame was arbitrarily further than the one the filter might
      expect.
      
      Ideally, we would notify which frames has been dropped to the filter, so
      that it can differentiate a real discontinuity from a drop and can
      handle its history correctly, but flushing is still better than doing
      nothing and history is not really well exposed for now anyway.
      8d390163
    • Pierre Lamot's avatar
      vgl: fix swap callback called without current context · e2614dd4
      Pierre Lamot authored and Jean-Baptiste Kempf's avatar Jean-Baptiste Kempf committed
      fix regression from 9b7514f9
      e2614dd4
    • Marvin Scholz's avatar
      caopengllayer: always use kCGLPFASupportsAutomaticGraphicsSwitching · e08c1dfb
      Marvin Scholz authored and Hugo Beauzée-Luyssen's avatar Hugo Beauzée-Luyssen committed
      VLC 4.0 targets macOS 10.11, so we can always assume this is available.
      e08c1dfb
    • Marvin Scholz's avatar
      caopengllayer: remove unused variable · 95bbd30f
      Marvin Scholz authored and Hugo Beauzée-Luyssen's avatar Hugo Beauzée-Luyssen committed
      95bbd30f
    • Marvin Scholz's avatar
      caopengllayer: remove unnecessary size saving · c7f4f114
      Marvin Scholz authored and Hugo Beauzée-Luyssen's avatar Hugo Beauzée-Luyssen committed
      The size saved here is always overwritten right before
      rendering so it is not necessary at all, as nothing is
      reported anymore here, this is handled by the window.
      c7f4f114
    • Marvin Scholz's avatar
      caopengllayer: fix wrong fullscreen size · 3f012cc3
      Marvin Scholz authored and Hugo Beauzée-Luyssen's avatar Hugo Beauzée-Luyssen committed
      When transitioning to fullscreen, the codepath for non-live
      resize was used and did not trigger rendering here.
      As the size if now handled by the window however, this resulted
      in a wrong size as it was never actually updated. To prevent that,
      always render with the proper size from the layer regardless
      if we are in live-resize or not.
      
      Fixes #26962
      3f012cc3
  5. 24 May, 2022 2 commits