[gst-devel] 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
>> gstreamer-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>>