[gst-devel] data-sink in rsvgoverlay

[Olivier Aubert]

On Thu, 2010-09-09 at 14:37 +0200, Sebastian Dröge wrote:
> On Thu, 2010-09-09 at 14:12 +0200, Olivier Aubert wrote:
> > Hello
> > 
> > I have implemented a data-sink to feed SVG data to the proposed new
> > rsvgoverlay element. However, I still have one issue: the following
> > pipeline:
> > 
> > pygst-launch videotestsrc ! ffmpegcolorspace ! rsvgoverlay name=overlay ! ffmpegcolorspace ! xvimagesink filesrc blocksize=102400 location=/tmp/a.svg ! image/svg ! overlay.data_sink
> > 
> > works only if I specify the blocksize= parameter to filesrc, so that the
> > SVG file is sent as one chunk. It greatly simplifies the rsvgoverlay
> > code to make this assumption (else I would have to gather chunks in the
> > overlay code to build the whole data). However, the blocksize hack is
> > not satisfactory. Is there any way to specify this (whole files wanted)
> > in the pad definition? I am attaching the code to also get some feedback
> > about problems that could still be there.
> 
> You can simply wait and concatenate buffers until you get the EOS event
> and only then start the real processing.
Hello Sebastian. Thanks for the answer. Yes, it is not that complicated,
but I would have hoped that the gstreamer infrastructure provided some
infrastructure to do this, optimizing memory allocation and freeing,
since it looks like a common thing in gstreamer elements. Is there no
such thing?

o.