[FFmpeg-devel] lavfi: push / poll / flush / drain implementation

[Nicolas George]

L'octidi 28 ventôse, an CCXX, Michael Niedermayer a écrit :
> I suggest to change this to:
> When a filter has output-able frame(s) for an output link, it should
> output them before buffering more output-able frames for the same
> output link.
> 
> As example, if yadif gets a frame, it turns it in 2 fields and
> outputs one and buffers the second.
> If now it gets a request_frame call it outputs the 2nd and returns
> to its initial state.
> If OTOH it gets another push it returns (at least) all fields it has
> buffered and stores the new fields for request_frame() to pull.
> 
> This should reduce CPU usage spikes due to push multiplication

That is a very interesting idea. I have to think some more about it, but it
does not seem to cause any adverse effects.

> as an alternative this could be implemented using existing fifo filters
> that ping the following filter when new frames become available and
> allow the following filter to inspect their whole que.
> I do not know if its better to worse to your suggestion, actually it
> looks pretty much identical from the outside.

It looks rather complicated, and I fail to see any benefit, compared to
having the queue directly in the filters, with a common API to implement it
cleanly.

> This rule will be broken by filters that attempt to achive realtime
> communication. An example would be a multiway teleconference where
> 3 people each see a split screen of 2 other people.
> Here a combine filter would likely mix what it has and not wait long
> for the other side if for whatever reason no data is received.

Indeed. This would be a case where the nature of the filter would warrant an
exception, with proper documentation. Or I can go Jesuit on this, and say
that the output does not depend on the order of arrival but the time of
arrival, and as such is deterministic. But on the whole we agree.

> But i guess such filter in this configuration would not be used in a
> loop
> maybe some flag(s) should be added to filters so the core can know if
> they are loop safe or not. This isnt really important ATM though

Agre.

> I agree with the remainder of your mail

Thanks.

I would like some feedback from Stefano and/or Clément too, if possible.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120318/6ab82de8/attachment.asc>