[gst-devel] Use of own buffer_alloc function
TK, Pratheesh Gangadhar
pratheesh at ti.com
Thu Mar 12 12:02:50 CET 2009
> -----Original Message-----
> From: Felipe Contreras [mailto:felipe.contreras at gmail.com]
> Sent: Thursday, March 12, 2009 3:00 PM
> To: Discussion of the development of GStreamer
> Subject: Re: [gst-devel] Use of own buffer_alloc function
> On Thu, Mar 12, 2009 at 11:12 AM, Tim-Philipp Müller <t.i.m at zen.co.uk>
> > On Thu, 2009-03-12 at 09:29 +0200, Felipe Contreras wrote:
> >> The filesrc is probably accessing the file with mmap,
> > FWIW, filesrc does not use mmap by default, you have to enable that
> > manually by setting the right properties (this is mostly for error
> > handling reasons).
> >> and doing pad_alloc on the demuxer.
> > Not sure what you mean by that, but I doubt filesrc ever does a
> > gst_pad_alloc_buffer() downstream, since this doesn't really make much
> > sense afaics.
> Right, I was contradicting myself.
> Still the point remains: the memory domains of filesrc and a dma sink
> are separate, so a memcpy/mmap is unavoidable.
This can be quite a bit of an overhead for camera capture use cases in embedded devices - V4L2 driver allocates buffers and resizes before sending to encoder. We resize to a pad_alloc buffer from encoder_input_pad for contiguous buffer. We have patched v42src for doing this and don’t understand why this can’t work. Memcpy at encoder input for raw video frames is a significant overhead.
More information about the gstreamer-devel