[FFmpeg-devel] [PATCH 2/2] lavfi: add tile video filter. (WIP)

[Clément Bœsch]

On Mon, Mar 05, 2012 at 09:24:42AM +0100, Nicolas George wrote:
> Le primidi 11 ventôse, an CCXX, Mark Himsley a écrit :
> > If you do discover a way to flush the last frames still in the
> > filtergrph after it has been fed the last decoded frame then I'd
> > really like to know. Several filters - including yadif, and two I'm
> > working on - would benifit. I note that Baptiste's FFmbc includes a
> > 'flush' parameter passed to poll_frame(), which works will there...
> 
> After much consideration, I believe the proper solution is to realize that
> the filtering process is output-driven. Output-driven processes do not need
> flushing, they just need to be activated until the end is reached. In this
> particular case, I believe the condition is that request_frame returns
> AVERROR_EOF.
> 
> That is the main problem: ffmpeg.c assumes that the process is input driven:
> it pushes a frame in input and expects one as an immediate result.
> 
> There are other secondary problems, but they would be easily fixed:
> 
> - When vsrc_buffer is used as input, there must be a way to make it return
>   AVERROR_EOR: vsrc_buffer_set_return_code(buf, AVERROR_EOF) should be
>   enough.
> 
> - Similarly, the default error code for vsrc_buffer when no frame is
>   available should be EAGAIN, not EINVAL.
> 

About EAGAIN vs EINVAL:

For the buffer source filter, wouldn't that mean "you need to feed me more
data before I'll be able to give you something back in the buffersink",
or "you can feed me more data since my internal buffer can still get
filled"?

For the buffer sink (get buffer ref), wouldn't that mean "I can't output
you a frame ATM, but it seems there is enough data internally to do, so
you should try again" or simply "here is a frame, but I you should try
again since I may have some more"?

> - poll_frame is (almost) useless. If Unix has taught us something, it is
>   this: the robust way of doing things is not to check and then do, it is to
>   do and accept failure. We do not write "if (readable(fd)) read(fd);", we
>   write "read(fd); if (errno == EAGAIN)". poll_frame should be kept for the
>   same purpose as Unix's poll: blocking/non-blocking situations. And this is
>   mostly unimplemented yet anyway.

That's indeed what I proposed in another thread (see "ffmpeg -af,
libavfilter"). Note that lavfi device doesn't use poll_frame while ffmpeg
does, and thus I'm sure some filters behave differently.

> 
> I have added that to my TODO list, I will try to cook up something, unless
> someone do it before me.
> 

I won't, so thank you for working on this :)

-- 
Clément B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120305/44c98e3f/attachment.asc>