[FFmpeg-devel] [PATCH] doc: update filter_design.txt to API changes.
Stefano Sabatini
stefasab at gmail.com
Fri Nov 30 01:31:23 CET 2012
On date Thursday 2012-11-29 17:42:15 +0100, Nicolas George encoded:
>
> Signed-off-by: Nicolas George <nicolas.george at normalesup.org>
> ---
> doc/filter_design.txt | 69 +++++++++++++++++++++++++++++--------------------
> 1 file changed, 41 insertions(+), 28 deletions(-)
>
>
> I performed the corresponding reindents. A word-diff would probably be more
> readable.
>
>
> diff --git a/doc/filter_design.txt b/doc/filter_design.txt
> index 362fce4..4da281b 100644
> --- a/doc/filter_design.txt
> +++ b/doc/filter_design.txt
> @@ -15,13 +15,13 @@ Format negotiation
> the list of supported formats.
>
> For video links, that means pixel format. For audio links, that means
> - channel layout, and sample format (the sample packing is implied by the
> - sample format).
> + channel layout, sample format (the sample packing is implied by the sample
> + format) and sample rate.
>
> The lists are not just lists, they are references to shared objects. When
> the negotiation mechanism computes the intersection of the formats
> - supported at each ends of a link, all references to both lists are
> - replaced with a reference to the intersection. And when a single format is
> + supported at each end of a link, all references to both lists are replaced
> + with a reference to the intersection. And when a single format is
> eventually chosen for a link amongst the remaining list, again, all
> references to the list are updated.
>
> @@ -68,15 +68,15 @@ Buffer references ownership and permissions
>
> Here are the (fairly obvious) rules for reference ownership:
>
> - * A reference received by the start_frame or filter_frame method
> - belong to the corresponding filter.
> + * A reference received by the filter_frame method (or its start_frame
> + obsolete version) belong to the corresponding filter.
belongS
>
> Special exception: for video references: the reference may be used
> internally for automatic copying and must not be destroyed before
> end_frame; it can be given away to ff_start_frame.
>
> - * A reference passed to ff_start_frame or ff_filter_frame is given
> - away and must no longer be used.
> + * A reference passed ff_filter_frame (or the obsolete ff_start_frame) is
> + given away and must no longer be used.
A reference passed _to_ ... (or _to_ the ...
>
> * A reference created with avfilter_ref_buffer belongs to the code that
> created it.
> @@ -93,21 +93,22 @@ Buffer references ownership and permissions
> The AVFilterLink structure has a few AVFilterBufferRef fields. Here are
> the rules to handle them:
>
> - * cur_buf is set before the start_frame and filter_frame methods to
> - the same reference given as argument to the methods and belongs to the
> + * cur_buf is set before filter_frame (or start_frame) method to
> + the same reference given as argument to the method and belongs to the
> destination filter of the link. If it has not been cleared after
> - end_frame or filter_frame, libavfilter will automatically destroy
> - the reference; therefore, any filter that needs to keep the reference
> - for longer must set cur_buf to NULL.
> + filter_frame returns (or end_frame), libavfilter will automatically
To me it sounds more natural:
If it has not been cleared after filter_frame (or end_frame) returns, ...
> + destroy the reference; therefore, any filter that needs to keep the
> + reference for longer must set cur_buf to NULL.
>
> * out_buf belongs to the source filter of the link and can be used to
> store a reference to the buffer that has been sent to the destination.
> - If it is not NULL after end_frame or filter_frame, libavfilter will
> + If it is not NULL after filter_frame (or end_frame), libavfilter will
> automatically destroy the reference.
>
> - If a video input pad does not have a start_frame method, the default
> - method will request a buffer on the first output of the filter, store
> - the reference in out_buf and push a second reference to the output.
> + If a video input pad have neither filter_frame nor start_frame
> + methods, the default method will request a buffer on the first output
> + of the filter, store the reference in out_buf and push a second
> + reference to the output.
>
> * src_buf, cur_buf_copy and partial_buf are used by libavfilter
> internally and must not be accessed by filters.
> @@ -119,8 +120,10 @@ Buffer references ownership and permissions
> the code that owns the reference is allowed to do to the buffer data.
> Different references for the same buffer can have different permissions.
>
> - For video filters, the permissions only apply to the parts of the buffer
> - that have already been covered by the draw_slice method.
> + For video filters that implement the obsolete
I think "obsolete" is not the right term, "deprecated" seems more
correct.
> + start_frame/draw_slice/end_frame API, the permissions only apply to the
> + parts of the buffer that have already been covered by the draw_slice
> + method.
>
> The value is a binary OR of the following constants:
>
> @@ -179,7 +182,7 @@ Buffer references ownership and permissions
> with the WRITE permission.
>
> * Filters that intend to keep a reference after the filtering process
> - is finished (after end_frame or filter_frame returns) must have the
> + is finished (after filter_frame (or end_frame) returns) must have the
Nit: possibly skip evil annidated ((..))
> PRESERVE permission on it and remove the WRITE permission if they
> create a new reference to give it away.
>
> @@ -198,11 +201,11 @@ Frame scheduling
> Simple filters that output one frame for each input frame should not have
> to worry about it.
>
> - start_frame / filter_frame
> - ----------------------------
> + filter_frame (or start_frame)
> + -----------------------------
Well that's weird, you already predicted how the name was going to
change.
>
> - These methods are called when a frame is pushed to the filter's input.
> - They can be called at any time except in a reentrant way.
> + This method is called when a frame is pushed to the filter's input. It
> + can be called at any time except in a reentrant way.
>
> If the input frame is enough to produce output, then the filter should
> push the output frames on the output link immediately.
> @@ -213,7 +216,7 @@ Frame scheduling
> filter; these buffered frames must be flushed immediately if a new input
> produces new output.
>
> - (Example: framerate-doubling filter: start_frame must (1) flush the
> + (Example: framerate-doubling filter: filter_frame must (1) flush the
> second copy of the previous frame, if it is still there, (2) push the
> first copy of the incoming frame, (3) keep the second copy for later.)
>
> @@ -233,8 +236,8 @@ Frame scheduling
>
> This method is called when a frame is wanted on an output.
>
> - For an input, it should directly call start_frame or filter_frame on
> - the corresponding output.
> + For an input, it should directly call filter_frame on the corresponding
> + output.
>
> For a filter, if there are queued frames already ready, one of these
> frames should be pushed. If not, the filter should request a frame on
> @@ -266,4 +269,14 @@ Frame scheduling
>
> Note that, except for filters that can have queued frames, request_frame
> does not push frames: it requests them to its input, and as a reaction,
> - the start_frame / filter_frame method will be called and do the work.
> + the filter_frame method will be called and do the work.
> +
> +Legacy API
> +==========
> +
> + Until libavfilter 3.23, the filter_frame method was split:
> +
> + - for video filters, it was made of start_frame, draw_slice (that could be
> + called several times on distinct parts of the frame) and end_frame;
> +
> + - for audio filters, it was called filter_samples.
LGTM otherwise, thanks.
BTW, as noted by Clement there are some "avfilter_" in the docs which
should be replaced by "ff_".
--
FFmpeg = Faithful Fast Majestic Problematic Exuberant Guide
More information about the ffmpeg-devel
mailing list