summaryrefslogtreecommitdiff
path: root/omx/gstomxbufferpool.c
Commit message (Collapse)AuthorAgeFilesLines
* omxbufferpool: use gst_video_meta_set_alignment()Guillaume Desmottes2019-11-051-1/+9
| | | | | | | Tell buffer consumer about our paddings. v4l2src can now uses these paddings information when trying to import buffers to configure the v4l2 driver accordingly.
* omxbufferpool: fix dmabuf importGuillaume Desmottes2019-09-021-3/+6
| | | | | | | When importing dmabuf from downstream, we want the allocator to be in OTHER_POOL mode despite output_mode being DMABUF. So check first if other_pool is set before checking for pool's output_mode.
* omxbufferpool: refactor to allow memory sharingGeorge Kiagiadakis2019-04-251-262/+167
| | | | | | | | | | | | | | | | | | | | | | 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.
* omxbufferpool: fix memory mapping with offsetGuillaume Desmottes2019-04-231-1/+1
| | | | | | | | | 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.
* omxbufferpool: don't use CAT_PERFORMANCE if pool will copyGuillaume Desmottes2019-03-261-4/+1
| | | | | | | | | | This was the single place where this category was used in gst-omx so most users, including me, are generally not turning it and were missing this important information from logs. The copying code uses gst_video_frame_copy() which is already logging with CAT_PERFORMANCE so we can still have this information when using only this debug category.
* omxbufferpool: fix race when releasing input buffersGuillaume Desmottes2019-01-081-1/+1
| | | | | | | | | 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.
* omxbufferpool: fix early input buffer releaseGuillaume Desmottes2018-12-211-3/+1
| | | | | | | | | | | | | | | | | 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.
* omxvideoenc: implement dmabuf export on input buffersGuillaume Desmottes2018-08-301-35/+109
| | | | | | | | | | Propose pool upstream so input buffers can be allocated by the port and exported as dmabuf. The actual OMX buffers are allocated when the pool is activated, so we don't end up doing useless allocations if the pool isn't used. https://bugzilla.gnome.org/show_bug.cgi?id=796918
* omxbufferpool: reference the OMX componentGuillaume Desmottes2018-08-301-1/+3
| | | | | | | | | Now that the pool is responsible of freeing the OMX buffers, we need to ensure that the OMX component stay alive while the pool is as we rely on the component to free the buffers. The GstOMXPort is owned by the component so no need to ref this one. https://bugzilla.gnome.org/show_bug.cgi?id=796918
* omxbufferpool: deallocate OMX buffers when stoppingGuillaume Desmottes2018-08-301-0/+3
| | | | | | | | The pool is stopped when all the buffers have been released. Deallocate when stopping so we are sure that the buffers aren't still used by another element. https://bugzilla.gnome.org/show_bug.cgi?id=796918
* omx: factor out gst_omx_buffer_get/set_omx_buf()Guillaume Desmottes2018-08-301-14/+4
| | | | | | | Move the qdata code to helper functions as I'm going to need them in omxvideoenc to implement dmabuf export. https://bugzilla.gnome.org/show_bug.cgi?id=796918
* add support for NV12_10LE32 and NV16_10LE32 on zynqultrascaleplusGuillaume Desmottes2018-02-281-0/+2
| | | | | | | The encoder and decoder on zynqultrascaleplus support these new 10 bits format. https://bugzilla.gnome.org/show_bug.cgi?id=793694
* omxbufferpool: add PERFORMANCE DEBUG message when copying output framesGuillaume Desmottes2018-02-211-0/+9
| | | | | | | | | | I spent quiet some time figuring out why performance of my pipeline were terrible. Turned out it was because of output frames being copied because of stride/offset mismatch. Add a PERFORMANCE DEBUG message to make it easier to spot and debug from logs. https://bugzilla.gnome.org/show_bug.cgi?id=793637
* omxvideodec: add dmabuf support for outputGuillaume Desmottes2017-07-181-7/+57
| | | | | | | | | | | The zynqultrascaleplus OMX implementation has a custom extension allowing decoders to output dmabuf and so avoid buffers copy between OMX and GStreamer. Make use of this extension when built on the zynqultrascaleplus. The buffer pool code should be re-usable for other platforms as well. https://bugzilla.gnome.org/show_bug.cgi?id=784847
* omxbufferpool: Copy buffers if the stride does not match and we can't use ↵Sebastian Dröge2014-06-241-28/+55
| | | | | | video meta https://bugzilla.gnome.org/show_bug.cgi?id=731672
* omxbufferpool: Fix format string compiler warningSebastian Dröge2014-06-241-1/+1
|
* omxbufferpool: Initialize debug categoryMichal Lazo2014-06-241-1/+6
|
* omxbufferpool: Properly convert OMX alignment to GStreamer alignmentSebastian Dröge2014-06-241-2/+14
| | | | | | | GStreamer uses a bitmask for the alignment while OMX uses the alignment itself. Let's convert. https://bugzilla.gnome.org/show_bug.cgi?id=710564
* omxvideodec: add support of more color formatAurélien Zanelli2014-04-151-0/+10
| | | | | Add support for ABGR, ARGB, RGB16, BGR16, YUY2, UYVY, YVYU, GRAY8 and NV16 color format.
* omxbufferpool: make video stride and offset calculation easierAurélien Zanelli2014-04-151-17/+11
| | | | It will be easier to support more color format.
* omxbufferpool: return buffers to the pool instead of freeing themJosep Torra2014-03-241-2/+2
| | | | | | | | | | We have to return the buffers back to the pool in when stopping to not mess with the GstBufferPool accounting. The OMX buffers will be freed when those won't be in charge of the pool in the chained up call to 'stop'. Fixes segfaults on finalize and pool not being properly deactivated. https://bugzilla.gnome.org/show_bug.cgi?id=726337
* omxbufferpool: fix memory leak if used on output portJulien Isorce2014-03-171-0/+11
| | | | | | | | | | | | | When using GstOMXBufferPool on an output port, it internally uses a GPtrArray to manage the GstBuffers instead of the default queue from the GstBufferPool base class. In this case GstBufferPool::default_free_buffer is not called when the pool is stopped. Because the queue is empty. So explicitely call gst_omx_buffer_pool_free_buffer on each buffer contained in the GPtrArray. https://bugzilla.gnome.org/show_bug.cgi?id=726337
* omxvideodec: separate the buffer pool from the decoderChristian König2014-03-121-0/+574
https://bugzilla.gnome.org/show_bug.cgi?id=726025
View Lorry Controller Status