1. 05 Aug, 2019 1 commit
  2. 11 Jul, 2019 1 commit
  3. 17 Jun, 2019 2 commits
  4. 07 Jun, 2019 1 commit
  5. 04 Jun, 2019 1 commit
  6. 03 Jun, 2019 1 commit
    • Niels De Graef's avatar
      meson: Bump minimal GLib version to 2.44 · a0b9c96f
      Niels De Graef authored
      This means we can use some newer features and get rid of some
      boilerplate code using the G_DECLARE_* macros.
      As discussed on IRC, 2.44 is old enough by now to start depending on it.
  7. 13 May, 2019 1 commit
  8. 25 Apr, 2019 2 commits
    • George Kiagiadakis's avatar
      gstomx: remove gst_omx_buffer_set_omx_buf/get_omx_buf · fbe0d070
      George Kiagiadakis authored
      They are no longer used anywhere
    • George Kiagiadakis's avatar
      omxbufferpool: refactor to allow memory sharing · 783e58fc
      George Kiagiadakis authored
      One big restriction of the OMX buffer pool has always been
      that the GstMemory objects were flagged with NO_SHARE.
      This was because the buffer pool needed to be sure that when
      a buffer returned to the pool, it would be safe to release the
      OMX buffer back to OpenMAX.
      With this change, this is no longer a restriction. What this
      commit introduces is a new allocator that allows us to track
      the GstMemory objects independently. Now, when a buffer returns
      to the pool, it is not necessary for the memory to be released
      as well. We simply track the memory's ref count in the allocator
      and we return the OMX buffer back when the memory's ref count
      drops to 0.
      The reason for doing this is to allow implementing zero-copy
      transfers in situations where we may need to copy or map a
      certain region of the buffer. For instance, omxh264enc ! h264parse
      should be possible to be zero-copy by using an OMX buffer pool
      between them.
  9. 23 Apr, 2019 1 commit
    • Guillaume Desmottes's avatar
      omxbufferpool: fix memory mapping with offset · 3018ea58
      Guillaume Desmottes authored
      gst_memory_map() is already adding the offset to the mapped pointer.
      Doing it in the memory implementation was resulting in the offset being
      accounted twice.
      It doesn't matter yet as we are only creating memory without offset for
      now but it will once we'll start sharing OMX memories.
  10. 19 Apr, 2019 1 commit
  11. 18 Apr, 2019 1 commit
  12. 16 Apr, 2019 1 commit
    • Julien Isorce's avatar
      Fixes build with omx >= 1.2.0 · 18927f33
      Julien Isorce authored
      gstomx.c:1405:10: error: ‘OMX_IndexParamCustomContentPipe’ undeclared (first use in this function)
          case OMX_IndexParamCustomContentPipe
      Some enums have been deprecated in 1.2.0
  13. 12 Apr, 2019 3 commits
  14. 10 Apr, 2019 1 commit
  15. 09 Apr, 2019 2 commits
  16. 06 Apr, 2019 1 commit
    • Jordan Petridis's avatar
      Add Gitlab CI configuration · 91356c9a
      Jordan Petridis authored
      This commit adds a .gitlab-ci.yml file, which uses a feature
      to fetch the config from a centralized repository. The intent is
      to have all the gstreamer modules use the same configuration.
      The configuration is currently hosted at the gst-ci repository
      under the gitlab/ci_template.yml path.
      Part of gstreamer-project#29
  17. 26 Mar, 2019 5 commits
  18. 25 Mar, 2019 1 commit
  19. 04 Mar, 2019 1 commit
  20. 26 Feb, 2019 1 commit
  21. 14 Feb, 2019 1 commit
  22. 25 Jan, 2019 6 commits
  23. 17 Jan, 2019 1 commit
  24. 09 Jan, 2019 1 commit
  25. 08 Jan, 2019 1 commit
    • Guillaume Desmottes's avatar
      omxbufferpool: fix race when releasing input buffers · 9dc359d0
      Guillaume Desmottes authored
      If buffers were released from the pool while
      gst_omx_video_enc_handle_frame() was waiting for new buffers,
      gst_omx_port_acquire_buffer() was never awaken as the buffers weren't
      released through OMX's messaging system.
      GQueue isn't thread safe so also protect it with the lock mutex.
  26. 21 Dec, 2018 1 commit
    • Guillaume Desmottes's avatar
      omxbufferpool: fix early input buffer release · 3828d976
      Guillaume Desmottes authored
      We used to track the 'allocating' status on the pool. It is used while
      allocating so output buffers aren't passed right away to OMX and input
      ones are not re-added to the pending queue.
      This was causing a bug when exporting buffers to v4l2src. On start
      v4l2src acquires a buffer, read its stride and release it right away.
      As no buffer was received by the encoder element at this point, 'allocating'
      was still on TRUE and so the the buffer wasn't put back to the pending
      queue and, as result, no longer available to the pool.
      Fix this by checking the active status of the pool instead of manually
      tracking it down. The pool is considered as active at the very end of
      the activation process so we're good when buffers are released during
      the activation.