[FFmpeg-devel] [PATCH] doc: update filter_design.txt to API changes.
Stefano Sabatini
stefasab at gmail.com
Sun Jan 6 10:53:36 CET 2013
On date Saturday 2013-01-05 17:04:26 +0100, Nicolas George encoded:
>
> Signed-off-by: Nicolas George <nicolas.george at normalesup.org>
> ---
> doc/filter_design.txt | 82 +++++++++++++++++++++++--------------------------
> 1 file changed, 39 insertions(+), 43 deletions(-)
>
>
> Updated to take Stefano's comments from one month ago into account.
> Also removed explanations to cur_buf and out_buf.
>
>
> diff --git a/doc/filter_design.txt b/doc/filter_design.txt
> index 362fce4..772ca9d 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
> + deprecated version) belongs to the corresponding filter.
>
> 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 to ff_filter_frame (or the deprecated
> + ff_start_frame) is given away and must no longer be used.
>
> * A reference created with avfilter_ref_buffer belongs to the code that
> created it.
> @@ -90,27 +90,11 @@ Buffer references ownership and permissions
> Link reference fields
> ---------------------
>
> - 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
> - 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.
> -
> - * 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
> - 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.
> -
> - * src_buf, cur_buf_copy and partial_buf are used by libavfilter
> - internally and must not be accessed by filters.
> + The AVFilterLink structure has a few AVFilterBufferRef fields. The
> + cur_buf and out_buf were used with the deprecated
> + start_frame/draw_slice/end_frame API and should no longer be used.
> + src_buf, cur_buf_copy and partial_buf are used by libavfilter internally
> + and must not be accessed by filters.
>
> Reference permissions
> ---------------------
> @@ -119,8 +103,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 deprecated
> + 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,9 +165,9 @@ 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
> - PRESERVE permission on it and remove the WRITE permission if they
> - create a new reference to give it away.
> + is finished (after filter_frame returns) must have the PRESERVE
> + permission on it and remove the WRITE permission if they create a new
> + reference to give it away.
>
> * Filters that intend to modify a reference they have kept after the end
> of the filtering process need the REUSE2 permission and must remove
> @@ -198,11 +184,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
> + ------------
>
> - 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 +199,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 +219,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
> @@ -255,7 +241,7 @@ Frame scheduling
> }
> while (!frame_pushed) {
> input = input_where_a_frame_is_most_needed();
> - ret = avfilter_request_frame(input);
> + ret = ff_request_frame(input);
> if (ret == AVERROR_EOF) {
> process_eof_on_input();
> } else if (ret < 0) {
> @@ -266,4 +252,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 as well, thanks.
Note: I think it would be useful to integrate this in the libavfilter
doxy, in a section named like "internal API" or such, that way there
are more chances that an occasional contributor can find it.
--
FFmpeg = Fanciful & Fundamentalist Martial Political Exuberant Gospel
More information about the ffmpeg-devel
mailing list