1. 29 Jan, 2013 3 commits
  2. 28 Jan, 2013 5 commits
    • Gwenole Beauchesne's avatar
      wayland: use a local event queue to avoid lock contention. · 1d16669a
      Gwenole Beauchesne authored
      This improves performance when rendering several surfaces from within
      the same process. e.g. a tee of vaapidecode'd buffers to vaapisink.
    • Gwenole Beauchesne's avatar
      wayland: fix thread-safe issues. · 96d12f9e
      Gwenole Beauchesne authored
      The Wayland API is not fully thread-safe and client applications shall
      perform locking themselves on key functions. Besides, make sure to
      release the lock if the _render() function fails.
    • Gwenole Beauchesne's avatar
      wayland: really wait until the pending redraw completed. · 1fb25b08
      Gwenole Beauchesne authored
      Introduce gst_vaapi_window_wayland_sync() helper function to wait for
      the completion of the redraw request. Use it in _render() function to
      actually block until the previous draw request is completed.
    • Gwenole Beauchesne's avatar
      wayland: fix frame_redraw callback. · 23c6053b
      Gwenole Beauchesne authored
      The redraw callback needs to be attached to the surface prior to the
      commit. Otherwise, the callback notifies the next surface repaint,
      which is not the desired behaviour. i.e. we want to be notified for
      the surface we have just filled.
      Another isse was the redraw_pending was reset before the actual completion
      of the frame redraw callback function, thus causing concurrency issues.
      e.g. the callback could have been called again, but with a NULL buffer.
    • Gwenole Beauchesne's avatar
      wayland: fix display sharing. · 087bf30c
      Gwenole Beauchesne authored
      When the Wayland display is shared, we still have to create our own local
      shell and compositor objects, since they are not propagated from the cache.
      Likewise, we also need to determine the display size or vaapisink would
      fail to account for the display aspect ratio, and will try to create a 0x0
  3. 23 Jan, 2013 3 commits
  4. 22 Jan, 2013 7 commits
  5. 21 Jan, 2013 2 commits
  6. 18 Jan, 2013 4 commits
  7. 17 Jan, 2013 5 commits
  8. 14 Jan, 2013 5 commits
  9. 11 Jan, 2013 6 commits
    • Holger Kaelberer's avatar
      overlay: fix build without advanced GstVideoOverlayFormatFlags. · 082a5659
      Holger Kaelberer authored
      Check for global-alpha support in GstVideoOverlayComposition API.
      Signed-off-by: default avatarGwenole Beauchesne <gwenole.beauchesne@intel.com>
    • Gwenole Beauchesne's avatar
      overlay: fix ordering of composition layers. · 7e1a8eab
      Gwenole Beauchesne authored
      Make sure to maintain the association order of composition layers when
      GstVideoOverlayRectangle objects are kept around (cached).
    • Holger Kaelberer's avatar
      overlay: fix support for global-alpha. · 2ecb9556
      Holger Kaelberer authored
      Fix support for global-alpha subpictures. The previous changes brought
      the ability to check for GstVideoOverlayRectangle changes by comparing
      the underlying pixel buffer pointers. If sequence number and pixel data
      did not change, then this is an indication that only the global-alpha
      value changed. Now, try to update the underlying VA subpicture global-alpha
      Signed-off-by: default avatarGwenole Beauchesne <gwenole.beauchesne@intel.com>
    • Gwenole Beauchesne's avatar
      overlay: detect render-rect changes. · e6390d6e
      Gwenole Beauchesne authored
      Don't re-upload VA subpicture if only the render rectangle changed.
      Rather deassociate the subpicture and re-associate it with the new
      render rectangle.
    • Gwenole Beauchesne's avatar
      overlay: fix check for pixels buffer change. · e876d9a5
      Gwenole Beauchesne authored
      A GstVideoOverlayRectangle is created whenever the underlying pixels data
      change. However, when global-alpha is supported, it is possible to re-use
      the same GstVideoOverlayRectangle but with a change to the global-alpha
      value. This process causes a change of sequence number, so we can no longer
      check for that.
      Still, if sequence numbers did not change, then there was no change in
      global-alpha either. So, we need a way to compare the underlying GstBuffer
      pointers. There is no API to retrieve the original pixels buffer from
      a GstVideoOverlayRectangle. So, we use the following heuristics:
      1. Use gst_video_overlay_rectangle_get_pixels_unscaled_argb() with the same
         format flags from which the GstVideoOverlayRectangle was created. This
         will work if there was no prior consumer of the GstVideoOverlayRectangle
         with alternate (non-"native") format flags.
      2. In overlay_rectangle_has_changed_pixels(), we have to use the same
         gst_video_overlay_rectangle_get_pixels_unscaled_argb() function but
         with flags that match the subpicture. This is needed to cope with
         platforms that don't support global-alpha in HW, so the gst-video
         layer takes care of that and fixes this up with a possibly new
         GstBuffer, and hence pixels data (or) in-place by caching the current
         global-alpha value applied. So we have to determine the rectangle
         was previously used, based on what previous flags were used to
         retrieve the ARGB pixels buffer.
    • Gwenole Beauchesne's avatar
      overlay: optimize cache at the GstVideoOverlayRectangle level. · a14d2590
      Gwenole Beauchesne authored
      We previously assumed that an overlay composition changed if the number
      of overlay rectangles in there actually changed, or that the rectangle
      was updated, and thus its seqnum was also updated.
      Now, we can cope with cases where the GstVideoOverlayComposition grew
      by one or a few more overlay rectangles, and the initial overlay rectangles
      are kept as is.