[FFmpeg-devel] Writing filters

[Nicolas George]

Le tridi 23 prairial, an CCXXII, Clément Bœsch a écrit :
> Yes, request_frame() is still a bit magic to me so I didn't feel
> comfortable explaining it.

> It's important to note that the API evolved quite a bit since the
> beginning. I *think* we can avoid request_frame in various cases nowadays
> with the help of FF_LINK_FLAG_REQUEST_LOOP.
> 
> Nicolas or Stefano can probably give more insight.

It is really not that complicated once you understand that the whole process
is deeply recursive.

It all starts, for example, when the application asks a sink for a frame.
The sink calls request_frame() on its input filter, and the input filter
does the same, recursively, until it reaches a source. The source somehow
produces a frame and calls filter_frame() on its output, which does
the same, recursively, until it reaches the sink. Then everyone returns
success.

Of course, it is not that simple.

The first issue is filters that require several frames to produce one, tile
for example. In that case, request_frame() has to loop until enough frames
are received to produce one. The framework is now capable of doing it: if
your filter requires just that, you can omit request_frame() and rely on the
default.

The second issue is filters with several inputs: consider concat versus
overlay, for example: only the filter knows what input needs a frame right
now in order to produce output. In that case, request_frame() can definitely
not be omitted, although it can rely on standard helpers for common cases.

The last issue is EOF: some filters need to detect the end of their input;
for example tile produces an incomplete last frame. The problem is that EOF
is only propagated through the return code of request_frame().

That last point is something I want to change. All the more because the
return code AVERROR_EOF does not carry a timestamp. I believe filters should
be able to receive not only frames but some kind of messages. I have not yet
decided how these messages should be encoded in order to make the system as
simple as possible without breaking compatibility. If anyone has
suggestions...

HtH.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140611/874c8430/attachment.asc>