1. 28 Apr, 2021 2 commits
  2. 29 Mar, 2021 2 commits
  3. 03 Mar, 2021 1 commit
  4. 14 Jan, 2021 1 commit
  5. 25 Nov, 2020 1 commit
  6. 18 Dec, 2019 1 commit
  7. 09 Dec, 2019 1 commit
  8. 19 Nov, 2019 1 commit
  9. 18 Nov, 2019 2 commits
  10. 02 Nov, 2019 1 commit
    • Guillaume Desmottes's avatar
      x(v)image: use gst_video_meta_set_alignment() · f9617bf3
      Guillaume Desmottes authored
      Use the new API to tell buffer consumers about alignment details.
      
      This change is backward compatible as non ported elements can safely
      ignore the alignment information and keep processing buffers as they use
      to, copying if necessary.
      f9617bf3
  11. 13 Oct, 2019 1 commit
  12. 30 Aug, 2019 1 commit
  13. 13 May, 2019 1 commit
  14. 27 Jul, 2018 1 commit
  15. 19 Jul, 2018 1 commit
  16. 25 Apr, 2018 1 commit
  17. 29 Jan, 2018 1 commit
  18. 11 Dec, 2017 1 commit
  19. 08 Dec, 2017 1 commit
    • Akinobu Mita's avatar
      ximagesink, xvimagesink: fix incorrect type conversion of pointer position · 6e770e0e
      Akinobu Mita authored
      I'm currently playing with modified ximagesink that does XGrabPointer()
      in order to receive the mouse events occurred outside of the window and
      send them to the navigation interface.
      
      The pointer positions usually have positive coordinates, but it could
      be negative with that change.
      
      When the ximagesink handles XEvent that contains a negative pointer
      coordinate, it incorrectly generates the GstEvent that contains an
      extremely large positive pointer coordinate.
      
      This is because the negative pointer position in XEvent is incorrectly
      converted from signed to unsigned and passed as an argument to
      gst_navigation_send_mouse_event() which causes implicit conversion from
      integer to double.  So the pointer position in the received XEvent and
      generated GstEvent are completely different.
      
      This potential problem does not seem to be a real problem with unmodified
      ximagesink but there is no reason to leave it as is.  This also fixes
      xvimagesink that has the same potential problem.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=791140
      6e770e0e
  20. 06 Dec, 2017 1 commit
  21. 06 Sep, 2017 1 commit
  22. 17 May, 2017 1 commit
  23. 16 May, 2017 1 commit
  24. 10 Mar, 2017 1 commit
  25. 09 Mar, 2017 1 commit
  26. 09 Jan, 2017 1 commit
  27. 20 Aug, 2016 1 commit
  28. 18 Jul, 2016 3 commits
  29. 26 Apr, 2016 1 commit
    • xhaakon's avatar
      ximagesink: generate reconfigure on window handle change · 59d7f9c6
      xhaakon authored
      When ximagesink is given a new window handle, it should check
      its geometry and if the size of the new window differs from
      the previous one, create reconfigure event in order to get
      a chance to negotiate a more suitable image resolution with
      the upstream elements.
      
      We can't rely on receiving Expose or ConfigureNotify from
      the X server for the newly assigned window, which would also
      generate reconfigure.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=765424
      59d7f9c6
  30. 24 Mar, 2016 1 commit
  31. 20 Feb, 2016 1 commit
    • Tim-Philipp Müller's avatar
      Fix use of undeclared core debug category symbols · a62c7bd5
      Tim-Philipp Müller authored
      libgstreamer currently exports some debug category
      symbols GST_CAT_*, but those are not declared in any
      public headers.
      
      Some plugins and libgstvideo just use GST_DEBUG_CATEGORY_EXTERN()
      to declare and use those, but that's just not right at
      all, and it won't work on Windows with MSVC. Instead look
      up the categories via the API.
      a62c7bd5
  32. 17 Nov, 2015 1 commit
  33. 04 Oct, 2015 1 commit
  34. 14 Sep, 2015 1 commit
  35. 07 Jul, 2015 1 commit