data-sink in rsvgoverlay

[Olivier Aubert-2]

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.

Thanks for any hint.
Olivier


------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Sebastian Dröge-7]

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.

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Olivier Aubert-2]

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.


------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Sebastian Dröge-7]

On Thu, 2010-09-09 at 15:05 +0200, Olivier Aubert wrote:

> 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?

GstAdapter could help here. You push buffers into it and after EOS can
get a single, large buffer from it

http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer-libs/html/GstAdapter.html

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Olivier Aubert-2]

On Thu, 2010-09-09 at 15:34 +0200, Sebastian Dröge wrote:

> GstAdapter could help here. You push buffers into it and after EOS can
> get a single, large buffer from it
>
> http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer-libs/html/GstAdapter.html
Yup, I found that out just after sending my e-mail by looking at some
code. Sorry for the noise. Anyway, the data-sink property is now
implemented, and the new code is attached to the bug
https://bugzilla.gnome.org/show_bug.cgi?id=435120

Regards,
Olivier


------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel