Dmaiaccel GStreamer element
dmaiaccel is a quite simple GStreamer element for use with TI processors that support the DMAI standard. Its purpose is to ensure that buffers that pass through it are contiguous in memory. Buffers are required to be contiguous in memory because the hardware encoding/decoding/display coprocessors that will consume them don't use the memory management unit (MMU) so they can only use physical memory addressing. Buffers that are known to be contiguous are marked as "DMAI" buffers.
A simple pseudocode of the dmaiaccel element's logic is:
if buffer is dmai: forward buffer without doing anything else if buffer is contiguous: #Contiguous but not marked as dmai yet mark buffer as dmai forward buffer else #Not dmai nor contiguous create new dmai buffer copy buffer into dmai buffer forward dmai buffer
Note that the undesired case is the second else, where a memory copy of the whole buffer is performed. This is the only case where I can see the dmaiaccel inducing latency. This would happen if the incoming buffers were not contiguous. You can verify this is not your case by enabling debug:
GST_DEBUG=*accel*:4 gst-launch dualmcvipsrc ... ! dmaiaccel ! ...
You should see one of two messages: Copying into contiguous video buffer or Is contiguous video buffer.
The resizer queries the contiguousness of the buffers directly, instead of checking the DMAI header. This means that data is not being copied on the resizer even if there is no dmaiaccel in the pipeline. The hardware encoder elements, on the other hand, check the DMAI header. In the undesired case that the buffers are not marked as DMAI, the encoder element will fallback to copy the data itself.
The resizer indeed outputs DMAI buffers to the downstream elements. That's why the dmaiaccel is not needed, at least at a first glance. However, there are situations in which the GStreamer core needs to copy the buffer (by buffer I mean the container, not the data) loosing the DMAI header.