Physically contiguous buffer handling

Todd Fischer todd.fischer at
Fri Apr 5 08:40:35 PDT 2013


We have a H.264 encoder hardware accelerator which we expose as a 
GStreamer element.  The element checks to see if the video frame being 
encoded is in physically contiguous memory.  If so, the element uses a 
kernel driver to provide the physical buffer address containing the 
frame to the hardware to encode.  If the video frame is not physically 
contiguous, then the element has to first copy the frame data (which 
kills performance).  We had a kludgy way of handling this in GStreamer 
0.10.  As we create the GStreamer 1.0 H.264 hardware accelerated encoder 
element, we would like to get rid of the kludges.

What is the best way for an element to know if a GstBuffer is physically 
contiguous in memory?

My first thought is to have a enum GstMetaFlags 
GST_META_FLAG_CONTIGUOUS.  Then v4l2src could set the flag (if 
appropriate) so when the buffer gets to the H.264 hardware accelerated 
encoder element we can simply check the flag to see if we need to copy 
the video frame to a contiguous buffer.

I believe there is lots of audio and video hardware accelerators that 
require the data to be in physically contiguous memory.



More information about the gstreamer-devel mailing list