[FFmpeg-devel] [PATCH 2/2] lavfi: add tile video filter. (WIP)
nicolas.george at normalesup.org
Mon Mar 5 09:24:42 CET 2012
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
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
- Similarly, the default error code for vsrc_buffer when no frame is
available should be EAGAIN, not EINVAL.
- 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.
I have added that to my TODO list, I will try to cook up something, unless
someone do it before me.
More information about the ffmpeg-devel