Physically contiguous buffer handling

Tim-Philipp Müller t.i.m at zen.co.uk
Fri Apr 5 08:51:18 PDT 2013


On Fri, 2013-04-05 at 09:40 -0600, Todd Fischer wrote:

Hi Todd,
> 
> 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.
> 
> Suggestions?

GST_MEMORY_FLAG_PHYSICALLY_CONTIGUOUS:
http://cgit.freedesktop.org/gstreamer/gstreamer/tree/gst/gstmemory.h#n48

Cheers
 -Tim



More information about the gstreamer-devel mailing list