plugin working with realimentation

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

plugin working with realimentation

Antonio Marqués
Hello developers,

I am interesting to design a plugin which has as inputs N-1 number of
pads (some images from a filesrc for example) and another input which
would be the result of the plugin's output, so I would like to implement
a kind of realimentation in that plugin.

In that plugin I would like to have all the N input buffers in the
process function. So I have thought in using the collect pad method for
all the pads. The problem is that, for the first buffer I would have not
the buffer of the pad N (because it would be the output of the buffer),
so the pipeline would not be set on PLAYING state never. Does anyone
know how to solve this problem? The main purpose of the plugin is, to
make an initial computation for the first frame taking into account the
N-1 images and for the other frames taking also into account the
previous output, which would be the N pad.

If anyone knows a plugin with similar function it would be great for me
to look at its source code.

Thanks in advance.

--
Toni Marqués Marqués
Telefónica I+D
División de Tecnologías de Video
[hidden email]
933653188





------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: plugin working with realimentation

Stefan Sauer
hi,
Antonio Marqués schrieb:
> Hello developers,
>
> I am interesting to design a plugin which has as inputs N-1 number of
> pads (some images from a filesrc for example) and another input which
> would be the result of the plugin's output, so I would like to implement
> a kind of realimentation in that plugin.
>  
honestly, I did not understood what you want to do. Also
"realimentation" seem to be a strange word (seems to be a medical term).
If you want to have a history of the last N buffers you need to
implement a ringbuffer that would keep a reference of them.

Stefan

> In that plugin I would like to have all the N input buffers in the
> process function. So I have thought in using the collect pad method for
> all the pads. The problem is that, for the first buffer I would have not
> the buffer of the pad N (because it would be the output of the buffer),
> so the pipeline would not be set on PLAYING state never. Does anyone
> know how to solve this problem? The main purpose of the plugin is, to
> make an initial computation for the first frame taking into account the
> N-1 images and for the other frames taking also into account the
> previous output, which would be the N pad.
>
> If anyone knows a plugin with similar function it would be great for me
> to look at its source code.
>
> Thanks in advance.
>
>  


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: plugin working with realimentation

Antonio Marqués
Sorry, what I meant is that I want to have as an input of a plugin the
output of other plugin that comes after this one. It is a kind of
feedback.

The first plugin delivers a buffer, which is processed by another
filter. The buffer pushed by this filter would be also pushed to the
previous plugin. I have tried to do so in Gstreamer and it did not work
at all. I had this output:


0:00:02.508437079 28071       0x6060b0 WARN                   bin
gstbin.c:1747:gst_bin_sort_iterator_next:<pipeline0> loop dected in
graph

(gst-launch-0.10:28071): GStreamer-WARNING **: loop detected in the
graph of bin pipeline0!!

I would like to know if there is a way in implementing this feedback
from a downstream element to an upstream element.

Sorry and thanks in advanced
On Thu, 2009-01-15 at 13:03 +0100, Stefan Kost wrote:

> hi,
> Antonio Marqués schrieb:
> > Hello developers,
> >
> > I am interesting to design a plugin which has as inputs N-1 number of
> > pads (some images from a filesrc for example) and another input which
> > would be the result of the plugin's output, so I would like to implement
> > a kind of realimentation in that plugin.
> >  
> honestly, I did not understood what you want to do. Also
> "realimentation" seem to be a strange word (seems to be a medical term).
> If you want to have a history of the last N buffers you need to
> implement a ringbuffer that would keep a reference of them.
>
> Stefan
> > In that plugin I would like to have all the N input buffers in the
> > process function. So I have thought in using the collect pad method for
> > all the pads. The problem is that, for the first buffer I would have not
> > the buffer of the pad N (because it would be the output of the buffer),
> > so the pipeline would not be set on PLAYING state never. Does anyone
> > know how to solve this problem? The main purpose of the plugin is, to
> > make an initial computation for the first frame taking into account the
> > N-1 images and for the other frames taking also into account the
> > previous output, which would be the N pad.
> >
> > If anyone knows a plugin with similar function it would be great for me
> > to look at its source code.
> >
> > Thanks in advance.
> >
> >  
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
--
Toni Marqués Marqués
Telefónica I+D
División de Tecnologías de Video
[hidden email]
933653188





------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: plugin working with realimentation

Ron McOuat
It would likely be easier to combine the 2 elements you are considering.
Then from the outside it would have only a sink pad for input and a
source pad for output. Inside the combined element you would have a
queue of N buffers where the first N-1 are a chain of the last N-1
buffers received on the sink and buffer N is a copy of the output sent
on the source after processing of the N-1 input buffers. The processing
algorithm can then process the N buffers by referencing their data as
they sit in the queue. The buffer sequence for the N-1 inputs you could
model on what the queue element does as a starting point for
implementation. That is what I believe Stefan had in mind when he said
use a ring buffer. The assumption in all of this is the first N-1
buffers are simply the N-1 most recent buffers from the input unaltered
and only buffer N provides the feedback. You may have problems with
pre-roll during pipeline startup, a buffer needs to get from the initial
source to the final sink and it sounds like you need to process N-1
input buffers before your first output on this element.

Hope that helps.

Ron

Antonio Marqués wrote:

> Sorry, what I meant is that I want to have as an input of a plugin the
> output of other plugin that comes after this one. It is a kind of
> feedback.
>
> The first plugin delivers a buffer, which is processed by another
> filter. The buffer pushed by this filter would be also pushed to the
> previous plugin. I have tried to do so in Gstreamer and it did not work
> at all. I had this output:
>
>
> 0:00:02.508437079 28071       0x6060b0 WARN                   bin
> gstbin.c:1747:gst_bin_sort_iterator_next:<pipeline0> loop dected in
> graph
>
> (gst-launch-0.10:28071): GStreamer-WARNING **: loop detected in the
> graph of bin pipeline0!!
>
> I would like to know if there is a way in implementing this feedback
> from a downstream element to an upstream element.
>
> Sorry and thanks in advanced
> On Thu, 2009-01-15 at 13:03 +0100, Stefan Kost wrote:
>  
>> hi,
>> Antonio Marqués schrieb:
>>    
>>> Hello developers,
>>>
>>> I am interesting to design a plugin which has as inputs N-1 number of
>>> pads (some images from a filesrc for example) and another input which
>>> would be the result of the plugin's output, so I would like to implement
>>> a kind of realimentation in that plugin.
>>>  
>>>      
>> honestly, I did not understood what you want to do. Also
>> "realimentation" seem to be a strange word (seems to be a medical term).
>> If you want to have a history of the last N buffers you need to
>> implement a ringbuffer that would keep a reference of them.
>>
>> Stefan
>>    
>>> In that plugin I would like to have all the N input buffers in the
>>> process function. So I have thought in using the collect pad method for
>>> all the pads. The problem is that, for the first buffer I would have not
>>> the buffer of the pad N (because it would be the output of the buffer),
>>> so the pipeline would not be set on PLAYING state never. Does anyone
>>> know how to solve this problem? The main purpose of the plugin is, to
>>> make an initial computation for the first frame taking into account the
>>> N-1 images and for the other frames taking also into account the
>>> previous output, which would be the N pad.
>>>
>>> If anyone knows a plugin with similar function it would be great for me
>>> to look at its source code.
>>>
>>> Thanks in advance.
>>>
>>>  
>>>      
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by:
>> SourcForge Community
>> SourceForge wants to tell your story.
>> http://p.sf.net/sfu/sf-spreadtheword
>> _______________________________________________
>> gstreamer-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>>    

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel