[gst-devel] Usage of gst_pad_alloc_buffer in source elements ?

[Julien Moutte]

If your source element directly produce video frames then it makes sense to
implement such allocation functions.

As most source elements are producing compressed data (filesrc,
demuxers,etc...), it does not really make sense to write into a downstream
allocated buffer.

Hope this helps,

Julien Moutte,
FLUENDO S.A.


On Tue, Dec 22, 2009 at 10:47 AM, Lionel Landwerlin
<llandwerlin at gmail.com>wrote:

> Hi gstreamer-devel,
>
> I'm interested in writing a bunch of plugins/elements to get gstreamer
> perform well enough to display SD/HD videos on a set top box chip.
> >From my firsts investigations, it seems quite possible and development
> should start quite soon. However, after reading a few article about
> gstreamer on TI OMAP chips (this one in particular
>
> http://www.eetimes.com/news/design/showArticle.jhtml?articleID=193401461&pgno=2
> ),
> I'm wondering why most of the source elements does not use the
> gst_pad_alloc_buffer function.
>
> In my case, this would be quite interesting to avoid a memory copy and
> to directly write into a contigeous dma mmapped buffer.
>
> Is it something to be done ?
> Is there a very few interest from the community ?
>
> Thanks in advance for your responses.
>
> --
> Lionel Landwerlin
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20091222/be0ec786/attachment.htm>