Physically contiguous buffer handling

Tim-Philipp Müller t.i.m at
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?



More information about the gstreamer-devel mailing list