1. 23 Nov, 2018 1 commit
  2. 15 Nov, 2018 1 commit
  3. 13 Nov, 2018 1 commit
  4. 12 Nov, 2018 1 commit
  5. 11 Nov, 2018 2 commits
    • Sjoerd Simons's avatar
      glupload: dmabuf: be explicit about gl formats used · 989f5338
      Sjoerd Simons authored and Nicolas Dufresne's avatar Nicolas Dufresne committed
      Rather then letting gst_gl_memory_setup_buffer guess the GL format used
      for an eglimage after importing a dmabuf be explicit about it. This
      fixes issues where dmabuf import may have used another format then
      gst_gl_format_from_video_info would guess on the basis of the available
      GL extensions.
      
      In particular on etnaviv the gst_gl_format_from_video_info would
      assuming a luminance + alpha GL format is used for YUY2, but the dmabuf
      import will always use RG88. Which causes images to end up somewhat pink when
      displayed on the screen.
      989f5338
    • Sjoerd Simons's avatar
      gl/egl: Determine correct format on dmabuf import · 99ac4e66
      Sjoerd Simons authored and Nicolas Dufresne's avatar Nicolas Dufresne committed
      When importing an egl image from dmabuf gst_gl_format_from_video_info
      was used to work what the result GL format will be. Unfortunately that
      will only work if the conventional format and the choosen DRM fourcc for
      the format match up.
      
      On etnaviv platforms there is no support for GL_EXT_texture_rg, so the
      GL format chosen for YUY2 ends up being GST_GL_LUMINANCE_ALPHA. However
      DRM does not do luminance + alpha as it's a legacy GL thing, so the
      dmabuf import ends up using DRM_FORMAT_GR88.
      
      To fix this, tie the DRM_FORMAT and the GL format together so they
      always match up.
      99ac4e66
  6. 01 Nov, 2018 2 commits
    • Nicolas Dufresne's avatar
      glupload: Only renegotiate if the caps are incompatible · e074eff5
      Nicolas Dufresne authored
      There is new code that ensures that we renegotiate after an
      uploader transition if the negotiated caps have changed.
      
      The problem is that the raw uploader will not really try and
      fixate the input caps, but instead of return a subset with the
      only the supported target texture.
      
      This had two effect, raw uploads was always done renegotiated
      once and the raw upload unit test was now failing as it didn't
      expect a renegotiation.
      
      As it's a valid check, simply relax the gst_caps_is_equal() check
      and use a gst_caps_is_subset() instead.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=783521
      e074eff5
    • Nicolas Dufresne's avatar
      glupload: Do prepend the preferred caps · c8c7672f
      Nicolas Dufresne authored
      The direct dmabuf upload does color conversion, so when it transforms
      the caps, it replaces the format with all formats found through the
      format query. When this uploader can't be used, it makes the upstream
      source pick a unsupported format.
      
      To fix this, we only append the caps with a list of format. So the
      source will only pick one of these formats if the downstream preferred
      format is not supported. A negotiation failure after this would be
      normal.
      
      This fixes pipelines without a glcolorconvert element.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=783521
      c8c7672f
  7. 30 Oct, 2018 10 commits
  8. 04 Oct, 2018 8 commits
  9. 03 Oct, 2018 3 commits
  10. 02 Oct, 2018 2 commits
  11. 26 Sep, 2018 1 commit
  12. 25 Sep, 2018 2 commits
  13. 24 Sep, 2018 1 commit
    • Tim-Philipp Müller's avatar
      libs: fix API export/import and 'inconsistent linkage' on MSVC · dc29bc4e
      Tim-Philipp Müller authored
      For each lib we build export its own API in headers when we're
      building it, otherwise import the API from the headers.
      
      This fixes linker warnings on Windows when building with MSVC.
      
      The problem was that we had defined all GST_*_API decorators
      unconditionally to GST_EXPORT. This was intentional and only
      supposed to be temporary, but caused linker warnings because
      we tell the linker that we want to export all symbols even
      those from externall DLLs, and when the linker notices that
      they were in external DLLS and not present locally it warns.
      
      What we need to do when building each library is: export
      the library's own symbols and import all other symbols. To
      this end we define e.g. BUILDING_GST_FOO and then we define
      the GST_FOO_API decorator either to export or to import
      symbols depending on whether BUILDING_GST_FOO is set or not.
      That way external users of each library API automatically
      get the import.
      
      While we're at it, add new GST_API_EXPORT...
      dc29bc4e
  14. 21 Sep, 2018 1 commit
  15. 18 Sep, 2018 4 commits