Re: [FFmpeg-devel] [PATCH 8/8] doc: update filter_design.txt.

2017-09-12 Thread Nicolas George
Le primidi 21 fructidor, an CCXXV, Nicolas George a écrit :
> Signed-off-by: Nicolas George 
> ---
>  doc/filter_design.txt | 251 
> +++---
>  1 file changed, 135 insertions(+), 116 deletions(-)

Series pushed.

(Without the zoompan fixes, this heap of bugs does not deserve starting
hostilities.)

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 8/8] doc: update filter_design.txt.

2017-09-07 Thread Nicolas George
Le primidi 21 fructidor, an CCXXV, Reto Kromer a écrit :
> tiny typo: first

Thanks, locally fixed.

Also fixed inut -> input in the same paragraph.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 8/8] doc: update filter_design.txt.

2017-09-07 Thread Reto Kromer
Nicolas George wrote:

>Signed-off-by: Nicolas George 
>---
> doc/filter_design.txt | 251 
>+++---
> 1 file changed, 135 insertions(+), 116 deletions(-)
>
>diff --git a/doc/filter_design.txt b/doc/filter_design.txt
>index e8a7c53ee9..90fa53367b 100644
>--- a/doc/filter_design.txt
>+++ b/doc/filter_design.txt

>+The typical task of an activate callback is to fisrt check the 
>backward

tiny typo: first

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH 8/8] doc: update filter_design.txt.

2017-09-07 Thread Nicolas George
Signed-off-by: Nicolas George 
---
 doc/filter_design.txt | 251 +++---
 1 file changed, 135 insertions(+), 116 deletions(-)

diff --git a/doc/filter_design.txt b/doc/filter_design.txt
index e8a7c53ee9..90fa53367b 100644
--- a/doc/filter_design.txt
+++ b/doc/filter_design.txt
@@ -5,7 +5,7 @@ This document explains guidelines that should be observed (or 
ignored with
 good reason) when writing filters for libavfilter.
 
 In this document, the word “frame” indicates either a video frame or a group
-of audio samples, as stored in an AVFilterBuffer structure.
+of audio samples, as stored in an AVFrame structure.
 
 
 Format negotiation
@@ -35,32 +35,31 @@ Format negotiation
   to set the formats supported on another.
 
 
-Buffer references ownership and permissions
-===
+Frame references ownership and permissions
+==
 
   Principle
   -
 
-Audio and video data are voluminous; the buffer and buffer reference
+Audio and video data are voluminous; the frame and frame reference
 mechanism is intended to avoid, as much as possible, expensive copies of
 that data while still allowing the filters to produce correct results.
 
-The data is stored in buffers represented by AVFilterBuffer structures.
-They must not be accessed directly, but through references stored in
-AVFilterBufferRef structures. Several references can point to the
-same buffer; the buffer is automatically deallocated once all
-corresponding references have been destroyed.
+The data is stored in buffers represented by AVFrame structures.
+Several references can point to the same frame buffer; the buffer is
+automatically deallocated once all corresponding references have been
+destroyed.
 
 The characteristics of the data (resolution, sample rate, etc.) are
 stored in the reference; different references for the same buffer can
 show different characteristics. In particular, a video reference can
 point to only a part of a video buffer.
 
-A reference is usually obtained as input to the start_frame or
-filter_frame method or requested using the ff_get_video_buffer or
-ff_get_audio_buffer functions. A new reference on an existing buffer can
-be created with the avfilter_ref_buffer. A reference is destroyed using
-the avfilter_unref_bufferp function.
+A reference is usually obtained as input to the filter_frame method or
+requested using the ff_get_video_buffer or ff_get_audio_buffer
+functions. A new reference on an existing buffer can be created with
+av_frame_ref(). A reference is destroyed using
+the av_frame_free() function.
 
   Reference ownership
   ---
@@ -73,17 +72,13 @@ Buffer references ownership and permissions
 
 Here are the (fairly obvious) rules for reference ownership:
 
-* A reference received by the filter_frame method (or its start_frame
-  deprecated version) belongs to the corresponding filter.
+* A reference received by the filter_frame method 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_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
+* A reference created with av_frame_ref() belongs to the code that
   created it.
 
 * A reference obtained with ff_get_video_buffer or ff_get_audio_buffer
@@ -95,89 +90,32 @@ Buffer references ownership and permissions
   Link reference fields
   -
 
-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 and partial_buf are used by libavfilter internally
-and must not be accessed by filters.
-
-  Reference permissions
-  -
-
-The AVFilterBufferRef structure has a perms field that describes what
-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 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:
-
-* AV_PERM_READ: the owner can read the buffer data; this is essentially
-  always true and is there for