Skip to content
Snippets Groups Projects
  1. Dec 03, 2019
  2. Sep 23, 2019
  3. May 02, 2019
  4. Apr 18, 2019
  5. Apr 16, 2019
  6. Apr 12, 2019
  7. Apr 10, 2019
  8. Apr 09, 2019
  9. Apr 06, 2019
  10. Mar 26, 2019
  11. Mar 25, 2019
  12. Mar 04, 2019
  13. Feb 26, 2019
  14. Feb 14, 2019
  15. Jan 25, 2019
  16. Jan 17, 2019
  17. Jan 09, 2019
  18. Jan 08, 2019
    • 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.
      9dc359d0
  19. Dec 21, 2018
    • Guillaume Desmottes's avatar
      omxbufferpool: fix early input buffer release · 3828d976
      Guillaume Desmottes authored and Guillaume Desmottes's avatar Guillaume Desmottes committed
      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.
      3828d976
  20. Dec 05, 2018
  21. Nov 26, 2018
  22. Nov 05, 2018
  23. Sep 26, 2018
  24. Sep 19, 2018
  25. Sep 10, 2018
Loading