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