Re: [FFmpeg-devel] [PATCH] avformat/mux: skip parameter and pts checks for data muxer

[Gyan]

On 04-05-2019 06:42 PM, Nicolas George wrote:

Gyan (12019-05-02):

The flow is

avformat_write_header -> avformat_init_output -> init_muxer

And in the last function, lines 293-385 (as of 7eba26451) carry out the
checks, and which my patch skips.

I missed this. My bad.


The problem is that there is no clean set of flags which isolate the
parameter-agnostic muxers - not surprising as this is a library for making
valid media files. A new flag could be invented, if the present patch is too
idiosyncratic. On a related note, as I mentioned elsewhere in this thread,
an existing flag AVFMT_NOTIMESTAMPS, which in theory I could use, is of no
help here, as it has been set for muxers which do handle timestamps in some
way.

Yet, the name test is wrong: there are other muxers that absolutely do
not care about timestamps, or any other kind of parameters. The null
muxer, for starter.

I see a few options to make this work properly:

- Add an option "-noout" for ffmpeg to let it run without output, until
   the end of inputs. This would be useful for other situations,
   including cases when the log from filters is what the user is
   interested in. It would replace "-f null -" that we always use.

- Add an option "-mux_params_check 0" for ffmpeg output streams, tu
   allow skipping these tests explicitly. Your use case is specific
   enough that an additional option is acceptable.

- Create the required flags to mark muxers that do not require these
   tests.
I think what I would prefer is a combination of 2 and 3. Mark muxers 
which don't need checks but add an option to actually disable checks. 2 
alone can produce invalid files if used with a regular muxer. At 
minimum, a warning should be issued. 3 alone has no flexibility.


If acceptable, I'll revise the patch that way.

Thanks,
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] lavfi/gblur: doing several columns at the same time

[Ruiling Song]

Instead of doing each column one by one, doing several columns
together gives about 30% better performance.

Signed-off-by: Ruiling Song 
---
below is some of performance numbers(fps) on my i7-6770HQ (decode + gblur):

resolution:480p | 720p | 1080p | 4k
without patch: 393  | 146  | 71| 14
with patch:502  | 184  | 95| 18
 libavfilter/vf_gblur.c | 62 --
 1 file changed, 42 insertions(+), 20 deletions(-)

diff --git a/libavfilter/vf_gblur.c b/libavfilter/vf_gblur.c
index 5d05cac44c..9f07705ec4 100644
--- a/libavfilter/vf_gblur.c
+++ b/libavfilter/vf_gblur.c
@@ -108,6 +108,40 @@ static int filter_horizontally(AVFilterContext *ctx, void 
*arg, int jobnr, int n
 return 0;
 }
 
+static void do_vertical_columns(float *buffer, int width, int height,
+int column_begin, int column_end, int steps,
+float nu, float boundaryscale, int column_step)
+{
+const int numpixels = width * height;
+int i, x, k, step;
+float *ptr;
+for (x = column_begin; x < column_end;) {
+for (step = 0; step < steps; step++) {
+ptr = buffer + x;
+for (k = 0; k < column_step; k++) {
+ptr[k] *= boundaryscale;
+}
+/* Filter downwards */
+for (i = width; i < numpixels; i += width) {
+for (k = 0; k < column_step; k++) {
+ptr[i + k] += nu * ptr[i - width + k];
+}
+}
+i = numpixels - width;
+
+for (k = 0; k < column_step; k++)
+ptr[i + k] *= boundaryscale;
+
+/* Filter upwards */
+for (; i > 0; i -= width) {
+for (k = 0; k < column_step; k++)
+ptr[i - width + k] += nu * ptr[i + k];
+}
+}
+x += column_step;
+}
+}
+
 static int filter_vertically(AVFilterContext *ctx, void *arg, int jobnr, int 
nb_jobs)
 {
 GBlurContext *s = ctx->priv;
@@ -117,31 +151,19 @@ static int filter_vertically(AVFilterContext *ctx, void 
*arg, int jobnr, int nb_
 const int slice_start = (width *  jobnr   ) / nb_jobs;
 const int slice_end   = (width * (jobnr+1)) / nb_jobs;
 const float boundaryscale = s->boundaryscaleV;
-const int numpixels = width * height;
 const int steps = s->steps;
 const float nu = s->nuV;
 float *buffer = s->buffer;
-int i, x, step;
-float *ptr;
-
-/* Filter vertically along each column */
-for (x = slice_start; x < slice_end; x++) {
-for (step = 0; step < steps; step++) {
-ptr = buffer + x;
-ptr[0] *= boundaryscale;
-
-/* Filter downwards */
-for (i = width; i < numpixels; i += width)
-ptr[i] += nu * ptr[i - width];
-
-ptr[i = numpixels - width] *= boundaryscale;
+int aligned_end;
 
-/* Filter upwards */
-for (; i > 0; i -= width)
-ptr[i - width] += nu * ptr[i];
-}
-}
+aligned_end = slice_start + (((slice_end - slice_start) >> 3) << 3);
+/* Filter vertically along columns (process 8 columns in each step) */
+do_vertical_columns(buffer, width, height, slice_start, aligned_end,
+steps, nu, boundaryscale, 8);
 
+// Filter un-aligned columns one by one
+do_vertical_columns(buffer, width, height, aligned_end, slice_end,
+steps, nu, boundaryscale, 1);
 return 0;
 }
 
-- 
2.17.1

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v1 2/2] fftools/ffmpeg Add stream metadata from first frame's metadata

[Jun Li]

On Sun, May 5, 2019 at 6:06 PM Michael Niedermayer 
wrote:

> On Sat, May 04, 2019 at 07:13:34PM -0700, Jun Li wrote:
> > Fix #6945
> > Exif extension has 'Orientaion' field for image flip and rotation.
> > This change is to add the first frame's exif into stream so that
> > autorotation would use the info to adjust the frames.
> > ---
> >  fftools/ffmpeg.c | 45 +
> >  1 file changed, 45 insertions(+)
>
> This breaks converting jpegs
>
> try this
> (file shoudl be here:
> https://trac.ffmpeg.org/raw-attachment/ticket/3424/bug.jpg)
>
> ./ffmpeg -i ~/tickets/3424/bug.jpg new.jpg
> ./ffmpeg -i ~/tickets/3424/bug.jpg new.bmp
>
> ./ffplay ~/tickets/3424/bug.jpg
> ./ffplay new.jpg
> ./ffplay new.bmp
>
> All 3 above should produce a image with the same and correct orientation
> they do before these 2 patches, they do not after
>
> Thanks
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Into a blind darkness they enter who follow after the Ignorance,
> they as if into a greater darkness enter who devote themselves
> to the Knowledge alone. -- Isha Upanishad
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Thanks Michael for review and testing !
Yes, this is a bug in the patch. I missed the case when "Orientation" is 1,
which is horizontal(normal) .
Now the issue has been addressed in v2 as follows:
https://patchwork.ffmpeg.org/patch/13000/
https://patchwork.ffmpeg.org/patch/13001/

Best Regards,
Jun
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v2 1/2] fftools/ffmpeg_filter, ffplay: Add flip support to rotation

[Jun Li]

Current implemantion for autoratation does not support flip.
That is, if the matrix contains flip info, the API get_rotation
only reflects partial information. This change is for adding
support for hflip (vflip can be achieved by rotation+hflip).
---
 fftools/cmdutils.c|  4 ++--
 fftools/cmdutils.h|  2 +-
 fftools/ffmpeg_filter.c   | 31 ++-
 fftools/ffplay.c  | 22 ++
 libavutil/display.c   | 12 
 libavutil/display.h   | 14 ++
 libavutil/tests/display.c |  8 
 tests/ref/fate/display|  4 
 8 files changed, 85 insertions(+), 12 deletions(-)

diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 9cfbc45c2b..1235a3dd7b 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -2172,13 +2172,13 @@ void *grow_array(void *array, int elem_size, int *size, 
int new_size)
 return array;
 }
 
-double get_rotation(AVStream *st)
+double get_rotation_hflip(AVStream *st, int* hflip)
 {
 uint8_t* displaymatrix = av_stream_get_side_data(st,
  
AV_PKT_DATA_DISPLAYMATRIX, NULL);
 double theta = 0;
 if (displaymatrix)
-theta = -av_display_rotation_get((int32_t*) displaymatrix);
+theta = -av_display_rotation_hflip_get((int32_t*) displaymatrix, 
hflip);
 
 theta -= 360*floor(theta/360 + 0.9/360);
 
diff --git a/fftools/cmdutils.h b/fftools/cmdutils.h
index 6e2e0a2acb..0349d1bea7 100644
--- a/fftools/cmdutils.h
+++ b/fftools/cmdutils.h
@@ -643,6 +643,6 @@ void *grow_array(void *array, int elem_size, int *size, int 
new_size);
 char name[128];\
 av_get_channel_layout_string(name, sizeof(name), 0, ch_layout);
 
-double get_rotation(AVStream *st);
+double get_rotation_hflip(AVStream *st, int* hflip);
 
 #endif /* FFTOOLS_CMDUTILS_H */
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 72838de1e2..b000958015 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -807,22 +807,43 @@ static int configure_input_video_filter(FilterGraph *fg, 
InputFilter *ifilter,
 last_filter = ifilter->filter;
 
 if (ist->autorotate) {
-double theta = get_rotation(ist->st);
+int hflip = 0;
+double theta = get_rotation_hflip(ist->st, );
 
-if (fabs(theta - 90) < 1.0) {
+if (fabs(theta) < 1.0) {
+if (hflip)
+ret = insert_filter(_filter, _idx, "hflip", NULL);
+} else if (fabs(theta - 90) < 1.0) {
 ret = insert_filter(_filter, _idx, "transpose", "clock");
-} else if (fabs(theta - 180) < 1.0) {
-ret = insert_filter(_filter, _idx, "hflip", NULL);
 if (ret < 0)
 return ret;
-ret = insert_filter(_filter, _idx, "vflip", NULL);
+if (hflip)
+ret = insert_filter(_filter, _idx, "hflip", NULL);
+} else if (fabs(theta - 180) < 1.0) {
+if (hflip) { // rotate 180 and hflip equals vflip
+ret = insert_filter(_filter, _idx, "vflip", NULL);
+} else {
+ret = insert_filter(_filter, _idx, "hflip", NULL);
+if (ret < 0)
+return ret;
+ret = insert_filter(_filter, _idx, "vflip", NULL);
+}
 } else if (fabs(theta - 270) < 1.0) {
 ret = insert_filter(_filter, _idx, "transpose", "cclock");
+if (ret < 0)
+return ret;
+if (hflip)
+ret = insert_filter(_filter, _idx, "hflip", NULL);
 } else if (fabs(theta) > 1.0) {
 char rotate_buf[64];
 snprintf(rotate_buf, sizeof(rotate_buf), "%f*PI/180", theta);
 ret = insert_filter(_filter, _idx, "rotate", rotate_buf);
+if (ret < 0)
+return ret;
+if (hflip)
+ret = insert_filter(_filter, _idx, "hflip", NULL);
 }
+
 if (ret < 0)
 return ret;
 }
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 8f050e16e6..2c77612193 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -1914,19 +1914,33 @@ static int configure_video_filters(AVFilterGraph 
*graph, VideoState *is, const c
 } while (0)
 
 if (autorotate) {
-double theta  = get_rotation(is->video_st);
+int hflip;
+double theta  = get_rotation_hflip(is->video_st, );
 
-if (fabs(theta - 90) < 1.0) {
+if (fabs(theta) < 1.0) {
+if (hflip)
+INSERT_FILT("hflip", NULL);
+} else if (fabs(theta - 90) < 1.0) {
 INSERT_FILT("transpose", "clock");
+if (hflip)
+INSERT_FILT("hflip", NULL);
 } else if (fabs(theta - 180) < 1.0) {
-INSERT_FILT("hflip", NULL);
-INSERT_FILT("vflip", NULL);
+if (hflip) { // rotate 180 and hflip equals vflip
+INSERT_FILT("vflip", NULL);
+

[FFmpeg-devel] [PATCH v2 2/2] fftools/ffmpeg: Add stream metadata from first frame's metadata

[Jun Li]

Fix #6945
Exif extension has 'Orientaion' field for image flip and rotation.
This change is to add the first frame's exif into stream so that
autorotation would use the info to adjust the frames.
---
 fftools/ffmpeg.c | 52 
 1 file changed, 52 insertions(+)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 01f04103cf..cea85c601e 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -2341,6 +2341,56 @@ static int decode_audio(InputStream *ist, AVPacket *pkt, 
int *got_output,
 return err < 0 ? err : ret;
 }
 
+static void set_metadata_from_1stframe(InputStream* ist, AVFrame* frame) 
+{
+// read exif Orientation data
+AVDictionaryEntry *entry = av_dict_get(frame->metadata, "Orientation", 
NULL, 0);
+int orientation = 0;
+uint8_t* sd = NULL;
+if (entry) {
+orientation = atoi(entry->value);
+sd = av_stream_new_side_data(ist->st, AV_PKT_DATA_DISPLAYMATRIX, 
+sizeof(int32_t) * 9);
+memset(sd, 0, sizeof(int32_t) * 9);
+switch (orientation)
+{
+case 1: // horizontal (normal)
+av_display_rotation_set((int32_t*)sd, 0.0);
+break;
+case 2: // mirror horizontal
+av_display_rotation_set((int32_t*)sd, 0.0);
+av_display_matrix_flip(sd, 1, 0);
+break;
+case 3: // rotate 180
+av_display_rotation_set((int32_t*)sd, 180.0);
+break;
+case 4: // mirror vertical
+av_display_rotation_set((int32_t*)sd, 0.0);
+av_display_matrix_flip(sd, 0, 1);
+break;
+case 5: // mirror horizontal and rotate 270 CW
+av_display_rotation_set((int32_t*)sd, 270.0);
+av_display_matrix_flip(sd, 0, 1);
+break;
+case 6: // rotate 90 CW
+av_display_rotation_set((int32_t*)sd, 90.0);
+break;
+case 7: // mirror horizontal and rotate 90 CW
+av_display_rotation_set((int32_t*)sd, 90.0);
+av_display_matrix_flip(sd, 0, 1);
+break;
+case 8: // rotate 270 CW
+av_display_rotation_set((int32_t*)sd, 270.0);
+break;
+default:
+av_display_rotation_set((int32_t*)sd, 0.0);
+av_log(ist->dec_ctx, AV_LOG_WARNING,
+"Exif orientation data out of range: %i. Set to default 
value: horizontal(normal).", orientation);
+break;
+}
+}
+}
+
 static int decode_video(InputStream *ist, AVPacket *pkt, int *got_output, 
int64_t *duration_pts, int eof,
 int *decode_failed)
 {
@@ -2423,6 +2473,8 @@ static int decode_video(InputStream *ist, AVPacket *pkt, 
int *got_output, int64_
 decoded_frame->top_field_first = ist->top_field_first;
 
 ist->frames_decoded++;
+if (ist->frames_decoded == 1)
+set_metadata_from_1stframe(ist, decoded_frame);
 
 if (ist->hwaccel_retrieve_data && decoded_frame->format == 
ist->hwaccel_pix_fmt) {
 err = ist->hwaccel_retrieve_data(ist->dec_ctx, decoded_frame);
-- 
2.17.1

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 0/3] *** VDPAU: HEVC YUV 4:4:4 Support ***

[Manoj Bonda]

Thanks Philip for pushing the changes, sorry for the churn. 

I am not familiar with the MPV code much, but from a quick check by enabling 
the direct mode for 444 surfaces by modifying the condition

p->direct_mode = mapper->dst_params.hw_subfmt == IMGFMT_NV12 ||
 mapper->dst_params.hw_subfmt == IMGFMT_420P ||
to
p->direct_mode = mapper->dst_params.hw_subfmt == IMGFMT_NV12 ||
 mapper->dst_params.hw_subfmt == IMGFMT_420P ||
 mapper->dst_params.hw_subfmt == IMGFMT_444P;

the playback seems to be fine. But I see this might be since we are downscaling 
the chroma texture
in function mapper_map ?

I don’t see semi-planar formats for 444 in MPV code. 
VDPAU OpenGL interop supports only semiplanar surfaces as per the spec 
(https://www.khronos.org/registry/OpenGL/extensions/NV/NV_vdpau_interop2.txt)
I see the proper way to enable direct mode in MPV is to add support for 444 
semiplanar format. Please correct me if I am wrong. 

Sorry, but I won’t have bandwidth to take up this MPV task now. I will try to 
get back to it once I find some time. 

Thanks, 
ManojGupta.

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Philip
> Langdale
> Sent: Monday, May 6, 2019 12:08 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 0/3] *** VDPAU: HEVC YUV 4:4:4 Support
> ***
> 
> On Thu, 25 Apr 2019 22:00:16 -0700
> Philip Langdale  wrote:
> 
> > On Fri, 26 Apr 2019 09:43:39 +0530
> > ManojGuptaBonda  wrote:
> >
> > > Latest generation video decoder on Turing Chips supports decoding
> > > HEVC 4:4:4 decoding. These changes adds support for the same for
> > > VDPAU
> > >
> > > ManojGuptaBonda (3):
> > >   VDPAU: Add support for decoding HEVC 4:4:4 content
> > >   Pass sps and pps range extension flags to VDPAU.
> > >   Map 444 pix fmts to new VdpYCbCr types defined in VDPAU.
> > >
> > >  libavcodec/hevcdec.c|  9 +++-
> > >  libavcodec/vdpau_hevc.c | 41
> > > + libavcodec/vdpau_internal.h
> |
> > > 3 +++ libavutil/hwcontext_vdpau.c |  8 
> > >  4 files changed, 56 insertions(+), 5 deletions(-)
> > >
> >
> > Hi Manoj,
> >
> > Thanks for putting these patches together. I'll push these this
> > weekend if there aren't any comments from anyone else.
> >
> 
> I've pushed them with version bumps, changelog, and a couple of fixes to
> #define checks because you can't check for the PROFILE which was added
> ages ago. Need to check for the new FORMAT instead.
> 
> Thanks,
> 
> --phil
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org
> with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v1 2/2] fftools/ffmpeg Add stream metadata from first frame's metadata

[Michael Niedermayer]

On Sat, May 04, 2019 at 07:13:34PM -0700, Jun Li wrote:
> Fix #6945
> Exif extension has 'Orientaion' field for image flip and rotation.
> This change is to add the first frame's exif into stream so that
> autorotation would use the info to adjust the frames.
> ---
>  fftools/ffmpeg.c | 45 +
>  1 file changed, 45 insertions(+)

This breaks converting jpegs

try this 
(file shoudl be here: 
https://trac.ffmpeg.org/raw-attachment/ticket/3424/bug.jpg)

./ffmpeg -i ~/tickets/3424/bug.jpg new.jpg
./ffmpeg -i ~/tickets/3424/bug.jpg new.bmp

./ffplay ~/tickets/3424/bug.jpg
./ffplay new.jpg
./ffplay new.bmp

All 3 above should produce a image with the same and correct orientation
they do before these 2 patches, they do not after

Thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/aacdec: fix demuxing of very small frames

[James Almer]

On 5/4/2019 6:41 PM, James Almer wrote:
> On 4/25/2019 7:04 PM, James Almer wrote:
>> 10 bytes (id3v2 header amount of bytes) were being read before any checks
>> were made on the bitstream. The result was that we were overreading into
>> the next frame if the current one was 8 or 9 bytes long.
>>
>> Fixes tickets #7271 and #7869.
>>
>> Signed-off-by: James Almer 
>> ---
>>  libavformat/aacdec.c | 34 +-
>>  1 file changed, 21 insertions(+), 13 deletions(-)
> 
> Will push soon.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] libavutil: add an FFT & MDCT implementation

[Lynne]

May 5, 2019, 1:52 PM by d...@lynne.ee:

> May 4, 2019, 10:00 PM by > d...@lynne.ee > :
>
>> May 4, 2019, 8:10 PM by > >> mich...@niedermayer.cc 
>> >>  > mich...@niedermayer.cc 
>> >> >> :
>>
>>> On Fri, May 03, 2019 at 09:08:57PM +0200, Lynne wrote:
>>>
 This commit adds a new API to libavutil to allow for arbitrary 
 transformations
 on various types of data.

>>> breaks build on mips
>>>
>>> CC  libavutil/fft.o
>>> src/libavutil/fft.c:47: error: redefinition of typedef ‘AVFFTContext’
>>> src/libavutil/fft.h:25: note: previous declaration of ‘AVFFTContext’ was 
>>> here
>>> make: *** [libavutil/fft.o] Error 1
>>>
>>> [...]
>>>
>>
>> Fixed, v2 attached. Changes:
>> -Stride really is in bytes now.
>> -Corrected some comments (stride supported by all (i)mdcts, not just compound
>>  ones, some clarifications regarding the scale).
>>
>> Also that 28-point FFT comparison was a typo, its 128.
>>
>
> Managed to further optimize the 15-point transform by rewriting it as an 
> exptab-less
> compound 3x5 transform and embedding its input map into the parent 
> transform's map.
> Updated comparisons to libfftw3f:
> 120:
>   22353 decicycles in fftwf_execute, 1024 runs,  0 skips
>   21836 decicycles in compound_fft_15x8, 1024 runs,  0 skips
>
> 480:
>   103998 decicycles in   fftwf_execute,    1024 runs,  0 skips
>   102747 decicycles in compound_fft_15x32,    1024 runs,  0 skips
> 960:
>   186210 decicycles in  fftwf_execute,    1024 runs,  0 skips
>   215256 decicycles in compound_fft_15x64,    1024 runs,  0 skips
>

Attached a v4 of the patch which adjusts transform direction by reordering the
coefficients like the power of two transforms do. This allowed for the exptabs
to be computed just once on startup and stored in a global array.
Didn't even consider it was possible to do so for odd-sized transforms and
especially for compound 5x3 transforms but after some experimentation I found
the key was to perform the permutation before the second permutation to
embed the 5x3's input map in.

I don't think there are any more feasible ways to improve the code, short of
having 15 different versions for all power of two transforms by hardcoding
the output reindexing, so I'd like to get some feedback on the API.
The old SIMD from lavc is unusable, especially the power of two part,
so it would be nice to get started on rewriting that soon.
>From 77cd00aa76f97e9116585a4b409b3efb0096094a Mon Sep 17 00:00:00 2001
From: Lynne 
Date: Thu, 2 May 2019 15:07:12 +0100
Subject: [PATCH] libavutil: add an FFT & MDCT implementation

v2 changes:
Stride really is in bytes now.
Corrected some comments (stride supported by all (i)mdcts, not just compound
ones, some clarifications regarding the scale).

v3 changes:
Optimized the 15-point transform by making it compound as well.

v4 changes:
Reorder coefficients instead of relying on exptab phase for the nptwo
transforms, and compute the exptabs just once on startup.

This commit adds a new API to libavutil to allow for arbitrary transformations
on various types of data.
This is a partly new implementation, with the power of two transforms taken
from libavcodec/fft_template, the 5 and 15-point FFT taken from mdct15, while
the 3-point FFT was written from scratch.
The (i)mdct folding code is taken from mdct15 as well, as the mdct_template
code was somewhat old, messy and not easy to separate.

A notable feature of this implementation is that it allows for 3xM and 5xM
based transforms, where M is a power of two, e.g. 384, 640, 768, 1280, etc.
AC-4 uses 3xM transforms while Siren uses 5xM transforms, so the code will
allow for decoding of such streams.
A non-exaustive list of supported sizes:
4, 8, 12, 16, 20, 24, 32, 40, 48, 60, 64, 80, 96, 120, 128, 160, 192, 240,
256, 320, 384, 480, 512, 640, 768, 960, 1024, 1280, 1536, 1920, 2048, 2560...

The API was designed such that it allows for not only 1D transforms but also
2D transforms of certain block sizes. This was partly on accident as the stride
argument is required for Opus MDCTs, but can be used in the context of a 2D
transform as well.
Also, various data types would be implemented eventually as well, such as
"double" and "int32_t".

The avfft_transform() function is awkward but avoids some other more
awkward ideas to isolate the private parts of the structure and not
make them part of the API, as well as reducing call overhead from
an additional function call.

Some performance comparisons with libfftw3f (SIMD disabled for both):
120:
  22353 decicycles in fftwf_execute, 1024 runs,  0 skips
  21836 decicycles in compound_fft_15x8, 1024 runs,  0 skips

128:
  22003 decicycles in   fftwf_execute,   1024 runs,  0 skips
  23132 decicycles in monolithic_fft_ptwo,   1024 runs,  0 skips

384:
  75939 decicycles in  fftwf_execute,1024 runs,  0 skips
  73973 

Re: [FFmpeg-devel] [DECISION] scaletempo filter

[Marton Balint]

On Sat, 4 May 2019, John Warburton wrote:


On Sat, May 4, 2019 at 3:34 PM Nicolas George  wrote:


John Warburton (12019-05-04):

> Is there a patch I can use to test scaletempo to compare it against
atempo?
> It'll be no trouble to do that with the normal audio that is
time-adjusted
> on that radio station. It may be that its increased quality is most

John, we would appreciate your input about whether these new
implementation of atempo is superior or equal to the existing one with
regard to your needs.


I tested scaletempo (with default settings) and it is definitely worse 
than atempo for small scaling factors like 25/24.


Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avdevice/decklink: fix checking video mode in SDK version 11

[Marton Balint]

On Sun, 5 May 2019, Devin Heitmueller wrote:


Hello Marton,


On May 5, 2019, at 2:28 PM, Marton Balint  wrote:


On Wed, 1 May 2019, Marton Balint wrote:


Apparently in the new SDK one cannot query if VANC output is supported, so we
will fall back to non-VANC output if enabling the video output with VANC fails.

Fixes ticket #7867.


Applied.


I know it’s a bit late for a review given I’m only seeing this after 
it’s been applied.  However, has it been confirmed that the new logic 
works with decklink SDKs older than version 11?  If not, then the old 
logic probably needs to stay and the new logic probably needs to be 
#ifdef’d based on the SDK version.  If we’re talking about increasing 
the minimum SDK version for ffmpeg to build against, that’s also an 
option (although given version 11 is very new I wouldn’t particularly be 
in favor of that).


There were two code hunks. The one which called DoesSupportVideoMode was 
an already ifdefed part to SDK version 11 only. The other hunk (the 
fallback to non-VANC mode if enabling output with VANC fails) seemed 
useful/harmless for all SDK versions, so I saw no reason to complicate it 
with ifdefry.


Also, have you ascertained that the change in question works with more 
than one model of card?  What card did you encounter this issue with, 
and what other cards did you test with?  I’m just concerned about the 
possibility that you committed a change to address an issue with some 
particular card, and we don’t know what the effects are on other cards.


As far as I see the added code can't cause regressions for any HW/SDK 
combo. If you see something in it where it can, then please let me know.


Thanks,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Quo vadis, code of conduct?

[Nicolas George]

Nicolas George (12019-05-06):
> Hi. Replying in private to avoid feeding the flame.

Well, fumbled that. Yet, what I said was true and I made no judgement in
my mail. I singled somebody, but since it was specifically who would
have been in breach of the CoC just today, the singling was warranted.

Regards,

-- 
  Nicolas George


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Quo vadis, code of conduct?

[Nicolas George]

Hi. Replying in private to avoid feeding the flame.

Reimar Döffinger (12019-05-05):
> If you want a code of conduct, you actually need to speak up.
> 
> If nobody speaks up, it's just useless blabla.
> 
> You can't expect others to do it.
> 
> Or be honest enough to say there isn't really one because
> nobody ACTUALLY stands behind it (even if most live
> up to it, that is quite a different thing from standing
> up for it).

There was a discussion some time ago (I do not have time to search the
reference just now) on the procedure to enforce it. A few people spoke
strongly against it, and it mostly died. As you can guess, Paul was
amongst them.

Regards,

-- 
  Nicolas George


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avdevice/decklink: fix checking video mode in SDK version 11

[Devin Heitmueller]

Hello Marton,

> On May 5, 2019, at 2:28 PM, Marton Balint  wrote:
> 
> 
> On Wed, 1 May 2019, Marton Balint wrote:
> 
>> Apparently in the new SDK one cannot query if VANC output is supported, so we
>> will fall back to non-VANC output if enabling the video output with VANC 
>> fails.
>> 
>> Fixes ticket #7867.
> 
> Applied.

I know it’s a bit late for a review given I’m only seeing this after it’s been 
applied.  However, has it been confirmed that the new logic works with decklink 
SDKs older than version 11?  If not, then the old logic probably needs to stay 
and the new logic probably needs to be #ifdef’d based on the SDK version.  If 
we’re talking about increasing the minimum SDK version for ffmpeg to build 
against, that’s also an option (although given version 11 is very new I 
wouldn’t particularly be in favor of that).

Also, have you ascertained that the change in question works with more than one 
model of card?  What card did you encounter this issue with, and what other 
cards did you test with?  I’m just concerned about the possibility that you 
committed a change to address an issue with some particular card, and we don’t 
know what the effects are on other cards.

Regards,

Devin

---
Devin Heitmueller - LTN Global Communications
dheitmuel...@ltnglobal.com

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH V5 1/2] configure: sort decoder/encoder/filter/... names in alphabet order

[avih]

> I guess you were looking at the right patch. I mean this one:
>   http://ffmpeg.org/pipermail/ffmpeg-devel/2019-May/243380.html

I was referring to this patch indeed. Thanks.


> > > Agreed; of course we shouldn't just use awk because we can.
> > >
> > > Though I think not implementing things in shell is often
> > > lower risk, as we have no isolation in POSIX shell, we all
> > > share the same variables etc. and the configure script is
> > > quite big. Then shell is not suited for many tasks because
> > > of the way it works
> > > ...
> >
> > This actually sounds to me like you're saying we shouldn't use awk because
> > we can, but rather use it where possible because it'd be better than shell.
> >
> > In other words: we should write new configure code in awk.
> > 
> > Did I misinterpret the statement or its implications?
> 
> You got me totally wrong :(


I'm only human, it happens. But you didn't explain what you actually meant.

Specifically:

- What makes this patch a good candidate to use awk rather than shell like
  the rest of configure?

- What should be the general criteria to choose a scripting language for
  future patches?
 

On Saturday, May 4, 2019 10:43 PM, Alexander Strasser  
wrote:
 

 Hi!

On 2019-05-04 06:28 +, avih wrote:
> > On 2019-05-02 08:55 +, avih wrote:
> > > > It seems awk is unconditionally required already. However I wanted to
> > > > say that it's a very nice dep to have
> > >
> > > While it's possibly nicer than other deps to have, it's still better to 
> > > use
> > > it IMHO only when it adds some value, like simpler code, better 
> > > performance,
> > > compliance with some things, etc.
> >
> > Agreed; of course we shouldn't just use awk because we can.
> >
> > Though I think not implementing things in shell is often
> > lower risk, as we have no isolation in POSIX shell, we all
> > share the same variables etc. and the configure script is
> > quite big. Then shell is not suited for many tasks because
> > of the way it works
> > ...
>
> This actually sounds to me like you're saying we shouldn't use awk because
> we can, but rather use it where possible because it'd be better than shell.
>
> In other words: we should write new configure code in awk.
>
> Did I misinterpret the statement or its implications?

You got me totally wrong :(

[...]
> >
> > Did you look at the version I attached in this thread? Or the one I
> > posted in the new patch set?
> >
> > I changed it to use an algorithm more similar to the latest shell
> > version discussed here.
>
> I think so, yes. As I said, it's similar to the shell version. I don't
> think it's worse in any way, but I also didn't see an added value.
>
> Please post a link to the actual patch if you think I'm not looking
> at the patch version you refer to.

I guess you were looking at the right patch. I mean this one:

  http://ffmpeg.org/pipermail/ffmpeg-devel/2019-May/243380.html


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] Quo vadis, code of conduct?

[Reimar Döffinger]

Hello everyone!
I noticed that there seems to be a code of conduct nowadays
(https://ffmpeg.org/developer.html#Code-of-conduct).

Now I assume that if it's there, there is SOMEONE who wanted it.
I'm sorry, but I for my part don't think that it's being
particularly lived up to.

So I'll say this, on the suspicion that it might need saying:

If you want a code of conduct, you actually need to speak up.

If nobody speaks up, it's just useless blabla.

You can't expect others to do it.

Or be honest enough to say there isn't really one because
nobody ACTUALLY stands behind it (even if most live
up to it, that is quite a different thing from standing
up for it).

My apologies for barging in here and starting this kind of thing.
But if you haven't lately given it a thought where you stand on
the topic, I take the liberty to ask you to.

Best regards,
Reimar Döffinger

P.S.: I followed my own advice and thought about it.
And I think I likely don't have time to stick around anyway.
While I do, I might speak up occasionally. But I honestly
just don't care enough to make it my fight. If you're looking
for a torchbearer, look elsewhere.
I'll sit and watch and hope I'll learn from doing things like
writing this email. Maybe I'll step up to go poke a few
bears next (or maybe boars, not enough bears in this part of
Sweden).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] avformat/ifv: added support for ifv cctv files

[Reimar Döffinger]

On Sun, May 05, 2019 at 10:05:17PM +0200, Carl Eugen Hoyos wrote:
> Am So., 5. Mai 2019 um 21:59 Uhr schrieb Reimar Döffinger
> :
> > > +if (aud_magic == MKTAG('G','R','A','W')) {
> > > +ifv->is_audio_present = 1;
> > > +} else if (aud_magic == MKTAG('P','C','M','U')) {
> > > +ifv->is_audio_present = 0;
> > > +} else {
> > > +avpriv_request_sample(s, "Unknown audio codec %x\n", aud_magic);
> > > +}
> >
> > Why does PCMU mean "no audio"?
>
> We have several files with "PCMU" and several files with "GRAW".
> All files with GRAW contain audio data, none of the files with PCMU
> contain audio data.
> I originally thought that the two bytes at 0x40/0x41 (iirc) show number
> of streams but a test with the proprietary player confirmed that this
> is not correct.
> Another test would be to overwrite GRAW with PCMU to find out if
> audio is still played...

Ok, makes sense.
I think it's good (and good enough) to have a comment that this
is just heuristics/guesswork based on existing samples and
might be quite wrong.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH]lavf/utils: Do not read "@" without ":" as user name separator

[Carl Eugen Hoyos]

Am So., 5. Mai 2019 um 21:56 Uhr schrieb Hendrik Leppkes :
>
> On Sun, May 5, 2019 at 9:47 PM Carl Eugen Hoyos  wrote:
> >
> > Am So., 5. Mai 2019 um 21:18 Uhr schrieb Hendrik Leppkes 
> > :
> > >
> > > On Sun, May 5, 2019 at 9:08 PM Carl Eugen Hoyos  
> > > wrote:
> > > >
> > > > Hi!
> > > >
> > > > Attached patch fixes ticket #7871 without re-introducing #7816.
> > > >
> > >
> > > There is no patch here. However, please note that its perfectly valid
> > > to have a username without a password (ie. an @ without a ":") - while
> > > it is not valid to have a slash in there.
> >
> > > For the record, the original ticket 7816 was not even about a slash,
> > > it was about URI encoding not being supported. As such, it was never
> > > resolved in the first place (and closed unjustly), and cannot regress.
> >
> > There is no url encoding in ftp according to the rfc.
> >
>
> FTP is not being passed the URI at all, its entirely for the
> convenience of the application. As such, that argument makes no sense.
>
> Either way, this does not fix the underlying problem.
>
> Take this perfectly valid URI: (it does not point to an actual file,
> but that is irrelevant): http://ffmpeg.org:80/foo@bar
> If you support slashes in the username or password, this points at a
> host named "bar" and has login details - both a username and a
> password. If you don't, then this points at ffmpeg.org, port 80, and
> some valid path.
>
> Only one of those interpretations is correct, and everyone else,
> including the RFC, says it should be the second.

I apparently missed the part of the rfc where a slash is
forbidden for the password.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] avformat/ifv: added support for ifv cctv files

[Carl Eugen Hoyos]

Am So., 5. Mai 2019 um 21:59 Uhr schrieb Reimar Döffinger
:

> > +avio_skip(s->pb, 0x5c);
>
> If for any of these skips you have any idea what data they
> contain, it would be nice to document it.

Iirc, all values we understood are used now.

> > +if (aud_magic == MKTAG('G','R','A','W')) {
> > +ifv->is_audio_present = 1;
> > +} else if (aud_magic == MKTAG('P','C','M','U')) {
> > +ifv->is_audio_present = 0;
> > +} else {
> > +avpriv_request_sample(s, "Unknown audio codec %x\n", aud_magic);
> > +}
>
> Why does PCMU mean "no audio"?

We have several files with "PCMU" and several files with "GRAW".
All files with GRAW contain audio data, none of the files with PCMU
contain audio data.
I originally thought that the two bytes at 0x40/0x41 (iirc) show number
of streams but a test with the proprietary player confirmed that this
is not correct.
Another test would be to overwrite GRAW with PCMU to find out if
audio is still played...

Thank you for your comments, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] avformat/ifv: added support for ifv cctv files

[Reimar Döffinger]

Hello!
Nothing major, but a few comments on things that might make
sense to polish below.

On Sat, May 04, 2019 at 06:42:40PM +0530, Swaraj Hota wrote:
> +#define IFV_MAGIC "\x11\xd2\xd3\xab\xba\xa9\xcf\x11\
> +\x8e\xe6\x00\xc0\x0c\x20\x53\x65\x44"

> +if (!memcmp(p->buf, IFV_MAGIC, 17))

Using an array and sizeof() instead of the hard-coded 17 might be a bit
nicer.

> +int ret;
> +
> +if (frame_type == AVMEDIA_TYPE_VIDEO) {
> +ret = av_reallocp_array(>vid_index, ifv->total_vframes, 
> sizeof(IFVIndexEntry));
> +if (ret < 0)
> +return ret;
> +
> +} else if (frame_type == AVMEDIA_TYPE_AUDIO) {
> +ret = av_reallocp_array(>aud_index, ifv->total_aframes, 
> sizeof(IFVIndexEntry));
> +if (ret < 0)
> +return ret;
> +}

Could just declare "ret" right where it is assigned.

> +avio_skip(s->pb, 0x5c);

If for any of these skips you have any idea what data they
contain, it would be nice to document it.

> +if (aud_magic == MKTAG('G','R','A','W')) {
> +ifv->is_audio_present = 1;
> +} else if (aud_magic == MKTAG('P','C','M','U')) {
> +ifv->is_audio_present = 0;
> +} else {
> +avpriv_request_sample(s, "Unknown audio codec %x\n", aud_magic);
> +}

Why does PCMU mean "no audio"? Could you add a comment?
Also, wouldn't it be more consistent to explicitly set
is_audio_present in the "else" case?

> +/*read video index*/
> +avio_seek(s->pb, 0xf8, SEEK_SET);
[...]
> +avio_skip(s->pb, ifv->vid_index->frame_offset - avio_tell(s->pb));

Why use avio_seek in one place and avio_skip in the other?

> +pos = avio_tell(s->pb);
> +
> +for (i = 0; i < ifv->total_vframes; i++) {
> +e = >vid_index[i];
> +if (e->frame_offset >= pos)
> +break;
> +}

This looks rather inefficient.
Wouldn't it make more sense to either
use a binary search or at least to
remember the position from the last read?
This also does not seem very robust either,
if a single frame_offset gets corrupted
to a very large value, this code will
never be able to find the "correct" position.
It seems to assume the frame_offset
is ordered increasingly (as would be needed for
binary search), but that property isn't
really checked/enforced.

> +av_freep(>vid_index);
> +if (ifv->is_audio_present)
> +av_freep(>aud_index);

Shouldn't the if () be unnecessary?

Best regards,
Reimar Döffinger
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH]lavf/utils: Do not read "@" without ":" as user name separator

[Hendrik Leppkes]

On Sun, May 5, 2019 at 9:47 PM Carl Eugen Hoyos  wrote:
>
> Am So., 5. Mai 2019 um 21:18 Uhr schrieb Hendrik Leppkes 
> :
> >
> > On Sun, May 5, 2019 at 9:08 PM Carl Eugen Hoyos  wrote:
> > >
> > > Hi!
> > >
> > > Attached patch fixes ticket #7871 without re-introducing #7816.
> > >
> >
> > There is no patch here. However, please note that its perfectly valid
> > to have a username without a password (ie. an @ without a ":") - while
> > it is not valid to have a slash in there.
>
> > For the record, the original ticket 7816 was not even about a slash,
> > it was about URI encoding not being supported. As such, it was never
> > resolved in the first place (and closed unjustly), and cannot regress.
>
> There is no url encoding in ftp according to the rfc.
>

FTP is not being passed the URI at all, its entirely for the
convenience of the application. As such, that argument makes no sense.

Either way, this does not fix the underlying problem.

Take this perfectly valid URI: (it does not point to an actual file,
but that is irrelevant): http://ffmpeg.org:80/foo@bar
If you support slashes in the username or password, this points at a
host named "bar" and has login details - both a username and a
password. If you don't, then this points at ffmpeg.org, port 80, and
some valid path.

Only one of those interpretations is correct, and everyone else,
including the RFC, says it should be the second.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH]lavf/utils: Do not read "@" without ":" as user name separator

[Carl Eugen Hoyos]

Am So., 5. Mai 2019 um 21:18 Uhr schrieb Hendrik Leppkes :
>
> On Sun, May 5, 2019 at 9:08 PM Carl Eugen Hoyos  wrote:
> >
> > Hi!
> >
> > Attached patch fixes ticket #7871 without re-introducing #7816.
> >
>
> There is no patch here. However, please note that its perfectly valid
> to have a username without a password (ie. an @ without a ":") - while
> it is not valid to have a slash in there.

> For the record, the original ticket 7816 was not even about a slash,
> it was about URI encoding not being supported. As such, it was never
> resolved in the first place (and closed unjustly), and cannot regress.

There is no url encoding in ftp according to the rfc.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/2] Revert "avcodec/qtrle: Do not output duplicated frames on insufficient input"

[Hendrik Leppkes]

On Sun, May 5, 2019 at 8:51 PM Marton Balint  wrote:
>
> This reverts commit a9dacdeea6168787a142209bd19fdd74aefc9dd6.
>
> I don't think it is a good idea to drop frames from CFR input just because 
> they
> are duplicated, that can cause issues for API users expecting CFR input. Also
> it can cause issues at the end of file, if the last frame is a duplicated
> frame.
>
> Fixes ticket #7880.
>

qtrle is not the only codec such a change was applied to, and I've in
the past objected to this class of changes without much support.
"Security" arguments were used to squat any counter-argument.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH]lavf/utils: Do not read "@" without ":" as user name separator

[Hendrik Leppkes]

On Sun, May 5, 2019 at 9:08 PM Carl Eugen Hoyos  wrote:
>
> Hi!
>
> Attached patch fixes ticket #7871 without re-introducing #7816.
>

There is no patch here. However, please note that its perfectly valid
to have a username without a password (ie. an @ without a ":") - while
it is not valid to have a slash in there.

For the record, the original ticket 7816 was not even about a slash,
it was about URI encoding not being supported. As such, it was never
resolved in the first place (and closed unjustly), and cannot regress.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH]lavf/utils: Do not read "@" without ":" as user name separator

[Carl Eugen Hoyos]

Am So., 5. Mai 2019 um 21:08 Uhr schrieb Carl Eugen Hoyos :
>
> Hi!
>
> Attached patch fixes ticket #7871 without re-introducing #7816.

And with the attachment.

Carl Eugen
From 969e30264d4f64885a943d347a5fa397efc0cd17 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sun, 5 May 2019 21:05:40 +0200
Subject: [PATCH] lavf/utils: Do not read "@" without ":" as user name
 separator.

Fixes ticket #7871.
---
 libavformat/utils.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index a63d71b0f4..c8d7f82a55 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -4730,7 +4730,7 @@ void av_url_split(char *proto, int proto_size,
   char *hostname, int hostname_size,
   int *port_ptr, char *path, int path_size, const char *url)
 {
-const char *p, *ls, *ls2, *ls3, *at, *at2, *col, *brk;
+const char *p, *ls, *ls2, *ls3, *ls4, *at, *at2, *col, *brk;
 
 if (port_ptr)
 *port_ptr = -1;
@@ -4761,7 +4761,8 @@ void av_url_split(char *proto, int proto_size,
 ls = strchr(p, '/');
 ls2 = strchr(p, '?');
 ls3 = strchr(p, '@');
-if (ls3 && ls3 > ls && (!ls2 || ls2 > ls3))
+ls4 = strchr(p, ':');
+if (ls3 && ls3 > ls && (!ls2 || ls2 > ls3) && ls4 && ls4 < ls3)
 ls = strchr(ls3, '/');
 if (!ls)
 ls = ls2;
-- 
2.21.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH]lavf/utils: Do not read "@" without ":" as user name separator

[Carl Eugen Hoyos]

Hi!

Attached patch fixes ticket #7871 without re-introducing #7816.

Please comment, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [DECISION] colorhold filter

[Paul B Mahol]

On 5/5/19, Reimar Döffinger  wrote:
> On 05.05.2019, at 18:04, Paul B Mahol  wrote:
>
>> On 5/5/19, Reimar Döffinger  wrote:
>>> On 04.05.2019, at 15:40, Paul B Mahol  wrote:
 Hi,

 I open voting for 7 days, for inclusion of colorhold filter in FFmpeg,
 with minor changes.

 Thanks.
>>>
>>> Why is there a need to vote?
>>
>> Because Nicolas objected on initial implementation. Dunno if he still
>> object something
>> on current updated patch.
>>
>>> What would be the objections existing or expected that would make a vote
>>> necessary vs. the normal development process? I so far assumed voting was
>>> purely a last-resort conflict resolution process.
>>> Is there a quorum required, or would a vote be accepted even if there was
>>> only one vote cast?
>>
>> This is to move forward and not be held back with blocking "arguments".
>
> Not that I am entirely unsympathetic to some of the arguments (quite a few
> of my patches never made it in due to objections I did not agree with),
> but it seems to me that in the end this is about the year-long feud between
> you and Nicolas.
> Voting won't resolve that, and I can't imagine that many people look forward
> to
> voting on a significant number of your patches (also because a proper vote
> really
> would require them to review, and lack of reviewers seems to be part of the
> issue?).
> Unfortunately unless there is someone you both respect enough to follow
> their decision even if you do not like it and who volunteers to arbitrate
> between you (small, direct and non-public votes so to say), I am rather
> short on actual solutions to suggest.
> I expect that the fact alone that you both care enough about FFmpeg to still
> be around (in contrast to me) doesn't suddenly somehow provide enough common
> ground for you to find a way to work together constructively?
>

Nicolas want dumb stupid filters, while I work on advanced filters.

> Best regards,
> Reimar
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [DECISION] colorhold filter

[Reimar Döffinger]

On 05.05.2019, at 18:04, Paul B Mahol  wrote:

> On 5/5/19, Reimar Döffinger  wrote:
>> On 04.05.2019, at 15:40, Paul B Mahol  wrote:
>>> Hi,
>>> 
>>> I open voting for 7 days, for inclusion of colorhold filter in FFmpeg,
>>> with minor changes.
>>> 
>>> Thanks.
>> 
>> Why is there a need to vote?
> 
> Because Nicolas objected on initial implementation. Dunno if he still
> object something
> on current updated patch.
> 
>> What would be the objections existing or expected that would make a vote
>> necessary vs. the normal development process? I so far assumed voting was
>> purely a last-resort conflict resolution process.
>> Is there a quorum required, or would a vote be accepted even if there was
>> only one vote cast?
> 
> This is to move forward and not be held back with blocking "arguments".

Not that I am entirely unsympathetic to some of the arguments (quite a few of 
my patches never made it in due to objections I did not agree with), 
but it seems to me that in the end this is about the year-long feud between you 
and Nicolas.
Voting won't resolve that, and I can't imagine that many people look forward to
voting on a significant number of your patches (also because a proper vote 
really
would require them to review, and lack of reviewers seems to be part of the 
issue?).
Unfortunately unless there is someone you both respect enough to follow their 
decision even if you do not like it and who volunteers to arbitrate between you 
(small, direct and non-public votes so to say), I am rather short on actual 
solutions to suggest.
I expect that the fact alone that you both care enough about FFmpeg to still be 
around (in contrast to me) doesn't suddenly somehow provide enough common 
ground for you to find a way to work together constructively?

Best regards,
Reimar
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/2] Revert "lavf/utils: Allow url credentials to contain a slash."

[Carl Eugen Hoyos]

Am So., 5. Mai 2019 um 20:51 Uhr schrieb Marton Balint :
>
> This reverts commit dd06f022b07438d650c82255dff16908ba04244a.
>
> Fixes ticket #7871 and reopens ticket #7816.

I'll send an alternative patch in a moment.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/2] Revert "avcodec/qtrle: Do not output duplicated frames on insufficient input"

[Carl Eugen Hoyos]

Am So., 5. Mai 2019 um 20:51 Uhr schrieb Marton Balint :
>
> This reverts commit a9dacdeea6168787a142209bd19fdd74aefc9dd6.
>
> I don't think it is a good idea to drop frames from CFR input just because 
> they
> are duplicated, that can cause issues for API users expecting CFR input. Also
> it can cause issues at the end of file, if the last frame is a duplicated
> frame.

> Fixes ticket #7880.

I am sure that this issue is reproducible with other codecs so I
would prefer a solution in ffmpeg.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/2] Revert "lavf/utils: Allow url credentials to contain a slash."

[Marton Balint]

This reverts commit dd06f022b07438d650c82255dff16908ba04244a.

Fixes ticket #7871 and reopens ticket #7816.

The introduced regression caused URL's with @ in them to be parsed incorrectly
which is a bigger issue then not being able to specify the slash character as a
password.

I think there are better ways to fix the original issue, like being able to
specify HTTP username and password as a protocol option, or adding a protocol
option to percent-decode the URL first.

Signed-off-by: Marton Balint 
---
 libavformat/utils.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index a63d71b0f4..6ef94239a4 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -4730,7 +4730,7 @@ void av_url_split(char *proto, int proto_size,
   char *hostname, int hostname_size,
   int *port_ptr, char *path, int path_size, const char *url)
 {
-const char *p, *ls, *ls2, *ls3, *at, *at2, *col, *brk;
+const char *p, *ls, *ls2, *at, *at2, *col, *brk;
 
 if (port_ptr)
 *port_ptr = -1;
@@ -4760,9 +4760,6 @@ void av_url_split(char *proto, int proto_size,
 /* separate path from hostname */
 ls = strchr(p, '/');
 ls2 = strchr(p, '?');
-ls3 = strchr(p, '@');
-if (ls3 && ls3 > ls && (!ls2 || ls2 > ls3))
-ls = strchr(ls3, '/');
 if (!ls)
 ls = ls2;
 else if (ls && ls2)
-- 
2.16.4

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/2] Revert "avcodec/qtrle: Do not output duplicated frames on insufficient input"

[Marton Balint]

This reverts commit a9dacdeea6168787a142209bd19fdd74aefc9dd6.

I don't think it is a good idea to drop frames from CFR input just because they
are duplicated, that can cause issues for API users expecting CFR input. Also
it can cause issues at the end of file, if the last frame is a duplicated
frame.

Fixes ticket #7880.

Signed-off-by: Marton Balint 
---
 libavcodec/qtrle.c|  12 ++---
 tests/ref/fate/qtrle-8bit | 109 ++
 2 files changed, 115 insertions(+), 6 deletions(-)

diff --git a/libavcodec/qtrle.c b/libavcodec/qtrle.c
index 2c29547e5a..7367f8688d 100644
--- a/libavcodec/qtrle.c
+++ b/libavcodec/qtrle.c
@@ -455,10 +455,12 @@ static int qtrle_decode_frame(AVCodecContext *avctx,
 int ret, size;
 
 bytestream2_init(>g, avpkt->data, avpkt->size);
+if ((ret = ff_reget_buffer(avctx, s->frame)) < 0)
+return ret;
 
 /* check if this frame is even supposed to change */
 if (avpkt->size < 8)
-return avpkt->size;
+goto done;
 
 /* start after the chunk size */
 size = bytestream2_get_be32(>g) & 0x3FFF;
@@ -472,20 +474,17 @@ static int qtrle_decode_frame(AVCodecContext *avctx,
 /* if a header is present, fetch additional decoding parameters */
 if (header & 0x0008) {
 if (avpkt->size < 14)
-return avpkt->size;
+goto done;
 start_line = bytestream2_get_be16(>g);
 bytestream2_skip(>g, 2);
 height = bytestream2_get_be16(>g);
 bytestream2_skip(>g, 2);
 if (height > s->avctx->height - start_line)
-return avpkt->size;
+goto done;
 } else {
 start_line = 0;
 height = s->avctx->height;
 }
-if ((ret = ff_reget_buffer(avctx, s->frame)) < 0)
-return ret;
-
 row_ptr = s->frame->linesize[0] * start_line;
 
 switch (avctx->bits_per_coded_sample) {
@@ -546,6 +545,7 @@ static int qtrle_decode_frame(AVCodecContext *avctx,
 memcpy(s->frame->data[1], s->pal, AVPALETTE_SIZE);
 }
 
+done:
 if ((ret = av_frame_ref(data, s->frame)) < 0)
 return ret;
 *got_frame  = 1;
diff --git a/tests/ref/fate/qtrle-8bit b/tests/ref/fate/qtrle-8bit
index 27bb8aad71..8da113d83e 100644
--- a/tests/ref/fate/qtrle-8bit
+++ b/tests/ref/fate/qtrle-8bit
@@ -4,60 +4,169 @@
 #dimensions 0: 640x480
 #sar 0: 0/1
 0,  0,  0,1,   921600, 0x1492e3ed
+0,  1,  1,1,   921600, 0x1492e3ed
+0,  2,  2,1,   921600, 0x1492e3ed
 0,  3,  3,1,   921600, 0x23ef4fc7
+0,  4,  4,1,   921600, 0x23ef4fc7
 0,  5,  5,1,   921600, 0xe406d4be
+0,  6,  6,1,   921600, 0xe406d4be
+0,  7,  7,1,   921600, 0xe406d4be
 0,  8,  8,1,   921600, 0x62b8b5a1
+0,  9,  9,1,   921600, 0x62b8b5a1
 0, 10, 10,1,   921600, 0x7d8ba674
+0, 11, 11,1,   921600, 0x7d8ba674
+0, 12, 12,1,   921600, 0x7d8ba674
 0, 13, 13,1,   921600, 0xfe666be7
+0, 14, 14,1,   921600, 0xfe666be7
 0, 15, 15,1,   921600, 0x721baec0
+0, 16, 16,1,   921600, 0x721baec0
+0, 17, 17,1,   921600, 0x721baec0
 0, 18, 18,1,   921600, 0xc237180a
+0, 19, 19,1,   921600, 0xc237180a
 0, 20, 20,1,   921600, 0xf03a7482
+0, 21, 21,1,   921600, 0xf03a7482
+0, 22, 22,1,   921600, 0xf03a7482
 0, 23, 23,1,   921600, 0x5612a391
+0, 24, 24,1,   921600, 0x5612a391
 0, 25, 25,1,   921600, 0x9dbcc46a
+0, 26, 26,1,   921600, 0x9dbcc46a
+0, 27, 27,1,   921600, 0x9dbcc46a
 0, 28, 28,1,   921600, 0xa128a5d5
+0, 29, 29,1,   921600, 0xa128a5d5
 0, 30, 30,1,   921600, 0x63e0025c
+0, 31, 31,1,   921600, 0x63e0025c
+0, 32, 32,1,   921600, 0x63e0025c
 0, 33, 33,1,   921600, 0x262359ed
+0, 34, 34,1,   921600, 0x262359ed
 0, 35, 35,1,   921600, 0x343688e8
+0, 36, 36,1,   921600, 0x343688e8
+0, 37, 37,1,   921600, 0x343688e8
+0, 38, 38,1,   921600, 0x343688e8
+0, 39, 39,1,   921600, 0x343688e8
+0, 40, 40,1,   921600, 0x343688e8
+0, 41, 41,1,   921600, 0x343688e8
+0, 42, 42,1,   921600, 0x343688e8
+0, 43, 43,1,   921600, 0x343688e8
+0, 

Re: [FFmpeg-devel] [PATCH 0/3] *** VDPAU: HEVC YUV 4:4:4 Support ***

[Philip Langdale]

On Thu, 25 Apr 2019 22:00:16 -0700
Philip Langdale  wrote:

> On Fri, 26 Apr 2019 09:43:39 +0530
> ManojGuptaBonda  wrote:
> 
> > Latest generation video decoder on Turing Chips supports decoding
> > HEVC 4:4:4 decoding. These changes adds support for the same for
> > VDPAU
> > 
> > ManojGuptaBonda (3):
> >   VDPAU: Add support for decoding HEVC 4:4:4 content
> >   Pass sps and pps range extension flags to VDPAU.
> >   Map 444 pix fmts to new VdpYCbCr types defined in VDPAU.
> > 
> >  libavcodec/hevcdec.c|  9 +++-
> >  libavcodec/vdpau_hevc.c | 41
> > + libavcodec/vdpau_internal.h |
> > 3 +++ libavutil/hwcontext_vdpau.c |  8 
> >  4 files changed, 56 insertions(+), 5 deletions(-)
> >   
> 
> Hi Manoj,
> 
> Thanks for putting these patches together. I'll push these this
> weekend if there aren't any comments from anyone else.
> 

I've pushed them with version bumps, changelog, and a couple of fixes
to #define checks because you can't check for the PROFILE which was
added ages ago. Need to check for the new FORMAT instead.

Thanks,

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH]lavf/rpl: Don't be case-sensitive detecting codecs

[Carl Eugen Hoyos]

Am So., 5. Mai 2019 um 18:29 Uhr schrieb Paul B Mahol :
>
> On 5/5/19, Carl Eugen Hoyos  wrote:
> > Hi!
> >
> > Attached patch fixes ticket #7859.
> >
> > Please comment, Carl Eugen
> >
>
> ok

Patch applied.

Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [DECISION] colorhold filter

[Paul B Mahol]

On 5/5/19, Nicolas George  wrote:
> Marton Balint (12019-05-05):
>> I don't think you can insist on waiting for a review unless you plan to
>> do
>> it yourself in a reasonable time frame.
>
> Do you really think I have a duty to help Paul after all the insults he
> have subjected me? Really?
>
> I am not the only developer here. Paul could, for example, politely ask
> somebody, for example Timo who authored the rest of the file, to have a
> look.
>
> Note: I am pushing Timo on the line here, but if anybody asks me to
> review a patch they think I might be competent to review, I will gladly
> do it. Anybody except Paul, who has repeatedly insulted me.
>
> Do you consider this unreasonable?
>
>> Yes, this can degrade code quality, but I guess there is a general
>> assumption that people who get commit rights won't mess up too badly, and
>> the gains of more/better features are considered greater than the risks
>> of
>> unreviewed code getting in.
>
> In the first thread, I noted that there was an obvious flaw in the
> patch. It was not the first time. It is not an isolated incident: the
> code quality has significantly degraded over the last few years: less
> future planning, increasing complexity. That happens because lack of
> review, amongst other things.

Stop spreading FUD!

>
> Regards,
>
> --
>   Nicolas George
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avfilter/vf_freezedetect: fix missing freeze_start when the freeze length is around the detection duration

[Marton Balint]

On Wed, 1 May 2019, Marton Balint wrote:


Fixes ticket #7875.


Applied.

Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avdevice/decklink: fix checking video mode in SDK version 11

[Marton Balint]

On Wed, 1 May 2019, Marton Balint wrote:


Apparently in the new SDK one cannot query if VANC output is supported, so we
will fall back to non-VANC output if enabling the video output with VANC fails.

Fixes ticket #7867.


Applied.

Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [DECISION] colorhold filter

[Nicolas George]

Marton Balint (12019-05-05):
> I don't think you can insist on waiting for a review unless you plan to do
> it yourself in a reasonable time frame.

Do you really think I have a duty to help Paul after all the insults he
have subjected me? Really?

I am not the only developer here. Paul could, for example, politely ask
somebody, for example Timo who authored the rest of the file, to have a
look.

Note: I am pushing Timo on the line here, but if anybody asks me to
review a patch they think I might be competent to review, I will gladly
do it. Anybody except Paul, who has repeatedly insulted me.

Do you consider this unreasonable?

> Yes, this can degrade code quality, but I guess there is a general
> assumption that people who get commit rights won't mess up too badly, and
> the gains of more/better features are considered greater than the risks of
> unreviewed code getting in.

In the first thread, I noted that there was an obvious flaw in the
patch. It was not the first time. It is not an isolated incident: the
code quality has significantly degraded over the last few years: less
future planning, increasing complexity. That happens because lack of
review, amongst other things.

Regards,

-- 
  Nicolas George


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] avformat/ifv: added support for ifv cctv files

[Paul B Mahol]

Some more or less important issues found:

On 5/4/19, Swaraj Hota  wrote:
> Fixes ticket #2956.
>
> Signed-off-by: Swaraj Hota 
> ---
> Revised patch. Made some minor changes based on original player:
> - Removed incorrect reading of frame_rate, instead frame rate
> is kept fixed at 25 (seems like this value is always same).
> - Added reading of frame width and height from input file.
>
> ---
>  Changelog|   1 +
>  libavformat/Makefile |   1 +
>  libavformat/allformats.c |   1 +
>  libavformat/ifv.c| 335 +++
>  libavformat/version.h|   4 +-
>  5 files changed, 340 insertions(+), 2 deletions(-)
>  create mode 100644 libavformat/ifv.c
>
> diff --git a/Changelog b/Changelog
> index a3fa0c14a2..03d2a9db01 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -26,6 +26,7 @@ version :
>  - lscr decoder
>  - lagfun filter
>  - asoftclip filter
> +- IFV demuxer
>
>
>  version 4.1:
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index 99be60d184..f68d41e4a5 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -231,6 +231,7 @@ OBJS-$(CONFIG_ICO_MUXER) += icoenc.o
>  OBJS-$(CONFIG_IDCIN_DEMUXER) += idcin.o
>  OBJS-$(CONFIG_IDF_DEMUXER)   += bintext.o sauce.o
>  OBJS-$(CONFIG_IFF_DEMUXER)   += iff.o
> +OBJS-$(CONFIG_IFV_DEMUXER)   += ifv.o
>  OBJS-$(CONFIG_ILBC_DEMUXER)  += ilbc.o
>  OBJS-$(CONFIG_ILBC_MUXER)+= ilbc.o
>  OBJS-$(CONFIG_IMAGE2_DEMUXER)+= img2dec.o img2.o
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index d316a0529a..cd00834807 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -188,6 +188,7 @@ extern AVOutputFormat ff_ico_muxer;
>  extern AVInputFormat  ff_idcin_demuxer;
>  extern AVInputFormat  ff_idf_demuxer;
>  extern AVInputFormat  ff_iff_demuxer;
> +extern AVInputFormat  ff_ifv_demuxer;
>  extern AVInputFormat  ff_ilbc_demuxer;
>  extern AVOutputFormat ff_ilbc_muxer;
>  extern AVInputFormat  ff_image2_demuxer;
> diff --git a/libavformat/ifv.c b/libavformat/ifv.c
> new file mode 100644
> index 00..f2d12b4fe7
> --- /dev/null
> +++ b/libavformat/ifv.c
> @@ -0,0 +1,335 @@
> +/*
> + * IFV demuxer
> + *
> + * Copyright (c) 2019 Swaraj Hota
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> + */
> +
> +#include "avformat.h"
> +#include "internal.h"
> +#include "avio_internal.h"
> +
> +#define IFV_MAGIC "\x11\xd2\xd3\xab\xba\xa9\xcf\x11\
> +\x8e\xe6\x00\xc0\x0c\x20\x53\x65\x44"
> +
> +typedef struct IFVIndexEntry {
> +uint32_t frame_offset;
> +uint32_t frame_size;
> +enum AVMediaType frame_type;
> +} IFVIndexEntry;
> +
> +typedef struct IFVContext {
> +IFVIndexEntry *vid_index;
> +IFVIndexEntry *aud_index;
> +uint32_t index_pos;
> +uint32_t total_vframes;
> +uint32_t total_aframes;
> +
> +int width, height;
> +int is_audio_present;
> +int sample_rate;
> +
> +int video_stream_index;
> +int audio_stream_index;
> +} IFVContext;
> +
> +static int ifv_probe(const AVProbeData *p)
> +{
> +if (!memcmp(p->buf, IFV_MAGIC, 17))
> +return AVPROBE_SCORE_MAX;
> +return 0;
> +}
> +
> +static int read_next_index_entry(AVFormatContext *s, enum AVMediaType
> frame_type)
> +{
> +IFVContext *ifv = s->priv_data;
> +IFVIndexEntry *e;
> +
> +if (frame_type == AVMEDIA_TYPE_VIDEO) {
> +if (ifv->index_pos >= ifv->total_vframes)
> +return 0;
> +
> +e = >vid_index[ifv->index_pos++];
> +
> +e->frame_offset = avio_rl32(s->pb);
> +e->frame_size = avio_rl32(s->pb);
> +e->frame_type = frame_type;
> +
> +avio_skip(s->pb, 20);

Are PTS stored here?

> +
> +} else if (frame_type == AVMEDIA_TYPE_AUDIO) {
> +if (ifv->index_pos >= ifv->total_aframes)
> +return 0;
> +
> +e = >aud_index[ifv->index_pos++];
> +
> +e->frame_offset = avio_rl32(s->pb);
> +e->frame_size = avio_rl32(s->pb);
> +e->frame_type = frame_type;
> +
> +avio_skip(s->pb, 16);


Are PTS stored here?

> +}
> +
> +return 1;
> +}
> +
> +static int read_index(AVFormatContext *s, 

Re: [FFmpeg-devel] [PATCH] avcodec/fits: Check bitpix

[Paul B Mahol]

On 5/5/19, Michael Niedermayer  wrote:
> Reference: Table 8: Interpretation of valid BITPIX value from FITS standard
> 4.0
> Fixes: runtime error: division by zero
> Fixes:
> 14581/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FITS_fuzzer-5652382425284608
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/fits.c | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/libavcodec/fits.c b/libavcodec/fits.c
> index 365347fc64..ad73ab70de 100644
> --- a/libavcodec/fits.c
> +++ b/libavcodec/fits.c
> @@ -138,6 +138,17 @@ int avpriv_fits_header_parse_line(void *avcl,
> FITSHeader *header, const uint8_t
>  case STATE_BITPIX:
>  CHECK_KEYWORD("BITPIX");
>  CHECK_VALUE("BITPIX", bitpix);
> +
> +switch(header->bitpix) {
> +case   8:
> +case  16:
> +case  32: case -32:
> +case  64: case -64: break;
> +default:
> +av_log(avcl, AV_LOG_ERROR, "invalid value of BITPIX %d\n",
> header->bitpix); \
> +return AVERROR_INVALIDDATA;
> +}
> +
>  dict_set_if_not_null(metadata, keyword, value);
>
>  header->state = STATE_NAXIS;
> --
> 2.21.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [DECISION] colorhold filter

[Marton Balint]

On Sun, 5 May 2019, Nicolas George wrote:


Paul B Mahol (12019-05-05):

Because Nicolas objected on initial implementation. Dunno if he still
object something on current updated patch.


Did it have a proper review on the mailing list? If yes, then I do not
oppose it. If no, then I oppose it.


I don't think you can insist on waiting for a review unless you plan to 
do it yourself in a reasonable time frame. FFmpeg (in contrast to libav) 
don't have mandatory peer review policy, and the fact that nobody cares 
enough for a patch to review it should not mean that the patch should be 
blocked indefinitely.


Yes, this can degrade code quality, but I guess there is a general 
assumption that people who get commit rights won't mess up too badly, and 
the gains of more/better features are considered greater than the risks of 
unreviewed code getting in.



Also, I would like to emphasize that you neglected to explain what you
changed in this new version of the patch. That would have made it easier
to decide.


This is to move forward and not be held back with blocking "arguments".


So the question is: shall Paul be allowed to push significant patches
that have not been reviewed?


There is some guideline about this in developer.texi, which says if noone 
answers within a week, and you think it is OK, then push it.


Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] avformat/ifv: added support for ifv cctv files

[Paul B Mahol]

On 5/4/19, Swaraj Hota  wrote:
> Okay. Thanks!
>

Sorry, but I found some issues while testing your patch.

Why are there no timestamps?

Seeking with mpv/ffplay caused hard crash.

You do not handle EOF, so ffmpeg with .ivf never exits.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avcodec/fits: Check bitpix

[Michael Niedermayer]

Reference: Table 8: Interpretation of valid BITPIX value from FITS standard 4.0
Fixes: runtime error: division by zero
Fixes: 
14581/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FITS_fuzzer-5652382425284608

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/fits.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/libavcodec/fits.c b/libavcodec/fits.c
index 365347fc64..ad73ab70de 100644
--- a/libavcodec/fits.c
+++ b/libavcodec/fits.c
@@ -138,6 +138,17 @@ int avpriv_fits_header_parse_line(void *avcl, FITSHeader 
*header, const uint8_t
 case STATE_BITPIX:
 CHECK_KEYWORD("BITPIX");
 CHECK_VALUE("BITPIX", bitpix);
+
+switch(header->bitpix) {
+case   8:
+case  16:
+case  32: case -32:
+case  64: case -64: break;
+default:
+av_log(avcl, AV_LOG_ERROR, "invalid value of BITPIX %d\n", 
header->bitpix); \
+return AVERROR_INVALIDDATA;
+}
+
 dict_set_if_not_null(metadata, keyword, value);
 
 header->state = STATE_NAXIS;
-- 
2.21.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] Insults

[Nicolas George]

Paul B Mahol (12019-05-05):
> You are so full of yourself and ignorant,  that you are so lazy to even look
> at patch to comment.

And you insulted me again.

Therefore, you owe me an apology, again.

-- 
  Nicolas George


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [DECISION] colorhold filter

[Paul B Mahol]

On 5/5/19, Nicolas George  wrote:
> Paul B Mahol (12019-05-05):
>> Because Nicolas objected on initial implementation. Dunno if he still
>> object something on current updated patch.
>
> Did it have a proper review on the mailing list? If yes, then I do not
> oppose it. If no, then I oppose it.
>
> Also, I would like to emphasize that you neglected to explain what you
> changed in this new version of the patch. That would have made it easier
> to decide.

You are so full of yourself and ignorant,  that you are so lazy to even look
at patch to comment.

>
>> This is to move forward and not be held back with blocking "arguments".
>
> So the question is: shall Paul be allowed to push significant patches
> that have not been reviewed?

Nobody takes you seriously any more.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [DECISION] colorhold filter

[Nicolas George]

Paul B Mahol (12019-05-05):
> Because Nicolas objected on initial implementation. Dunno if he still
> object something on current updated patch.

Did it have a proper review on the mailing list? If yes, then I do not
oppose it. If no, then I oppose it.

Also, I would like to emphasize that you neglected to explain what you
changed in this new version of the patch. That would have made it easier
to decide.

> This is to move forward and not be held back with blocking "arguments".

So the question is: shall Paul be allowed to push significant patches
that have not been reviewed?

-- 
  Nicolas George


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH]lavf/rpl: Don't be case-sensitive detecting codecs

[Paul B Mahol]

On 5/5/19, Carl Eugen Hoyos  wrote:
> Hi!
>
> Attached patch fixes ticket #7859.
>
> Please comment, Carl Eugen
>

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avfilter: add asr filter

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 configure|   4 +
 doc/filters.texi |  32 +++
 libavfilter/Makefile |   1 +
 libavfilter/af_asr.c | 177 +++
 libavfilter/allfilters.c |   1 +
 5 files changed, 215 insertions(+)
 create mode 100644 libavfilter/af_asr.c

diff --git a/configure b/configure
index d644a5b1d4..586c293bb9 100755
--- a/configure
+++ b/configure
@@ -307,6 +307,7 @@ External library support:
   --enable-opengl  enable OpenGL rendering [no]
   --enable-openssl enable openssl, needed for https support
if gnutls, libtls or mbedtls is not used [no]
+  --enable-pocketsphinxenable PocketSphinx, needed for asr filter [no]
   --disable-sndio  disable sndio support [autodetect]
   --disable-schannel   disable SChannel SSP, needed for TLS support on
Windows if openssl and gnutls are not used 
[autodetect]
@@ -1799,6 +1800,7 @@ EXTERNAL_LIBRARY_LIST="
 mediacodec
 openal
 opengl
+pocketsphinx
 vapoursynth
 "
 
@@ -3401,6 +3403,7 @@ afir_filter_deps="avcodec"
 afir_filter_select="fft"
 amovie_filter_deps="avcodec avformat"
 aresample_filter_deps="swresample"
+asr_filter_deps="pocketsphinx"
 ass_filter_deps="libass"
 atempo_filter_deps="avcodec"
 atempo_filter_select="rdft"
@@ -6299,6 +6302,7 @@ enabled openssl   && { check_pkg_config openssl 
openssl openssl/ssl.h OP
check_lib openssl openssl/ssl.h 
SSL_library_init -lssl32 -leay32 ||
check_lib openssl openssl/ssl.h 
SSL_library_init -lssl -lcrypto -lws2_32 -lgdi32 ||
die "ERROR: openssl not found"; }
+enabled pocketsphinx  && require_pkg_config pocketsphinx pocketsphinx 
pocketsphinx/pocketsphinx.h ps_init
 enabled rkmpp && { require_pkg_config rkmpp rockchip_mpp  
rockchip/rk_mpi.h mpp_create &&
require_pkg_config rockchip_mpp "rockchip_mpp 
>= 1.3.7" rockchip/rk_mpi.h mpp_create &&
{ enabled libdrm ||
diff --git a/doc/filters.texi b/doc/filters.texi
index 3c15bb95f4..3f25d12511 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -2131,6 +2131,38 @@ It accepts the following values:
 Set additional parameter which controls sigmoid function.
 @end table
 
+@section asr
+Automatic Speech Recognition
+
+This filter uses PocketSphinX for speech recognition. To enable
+compilation of this filter, you need to configure FFmpeg with
+@code{--enable-pocketsphinx}.
+
+It accepts the following options:
+
+@table @option
+@item rate
+Set sampling rate of input audio. Defaults is @code{16000}.
+This need to match speech models, otherwise one will get poor results.
+
+@item dict
+Set pronunciation dictionary.
+
+@item lm
+Set language model file.
+
+@item lmctl
+Set language model set.
+
+@item lmname
+Set which language model to use.
+
+@item logfn
+Set output for log messages.
+@end table
+
+The filter exports recognized speech as the frame metadata 
@code{lavfi.asr.text}.
+
 @anchor{astats}
 @section astats
 
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 59d12ce069..cf12365c8d 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -82,6 +82,7 @@ OBJS-$(CONFIG_ASHOWINFO_FILTER)  += af_ashowinfo.o
 OBJS-$(CONFIG_ASIDEDATA_FILTER)  += f_sidedata.o
 OBJS-$(CONFIG_ASOFTCLIP_FILTER)  += af_asoftclip.o
 OBJS-$(CONFIG_ASPLIT_FILTER) += split.o
+OBJS-$(CONFIG_ASR_FILTER)+= af_asr.o
 OBJS-$(CONFIG_ASTATS_FILTER) += af_astats.o
 OBJS-$(CONFIG_ASTREAMSELECT_FILTER)  += f_streamselect.o framesync.o
 OBJS-$(CONFIG_ATEMPO_FILTER) += af_atempo.o
diff --git a/libavfilter/af_asr.c b/libavfilter/af_asr.c
new file mode 100644
index 00..f14822215c
--- /dev/null
+++ b/libavfilter/af_asr.c
@@ -0,0 +1,177 @@
+/*
+ * Copyright (c) 2019 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include 
+
+#include "libavutil/avassert.h"
+#include "libavutil/avstring.h"
+#include "libavutil/channel_layout.h"
+#include "libavutil/opt.h"
+#include "audio.h"
+#include 

Re: [FFmpeg-devel] [DECISION] Project policy on closed source components

[Philip Langdale]

On Sun, 28 Apr 2019 22:02:11 +0200 (CEST)
Marton Balint  wrote:

> Hi All,
> 
> There has been discussion on the mailing list several times about the 
> inclusion of support for closed source components (codecs, formats, 
> filters, etc) in the main ffmpeg codebase.
> 
> Also the removal of libNDI happened without general consensus, so a
> vote is necessary to justify the removal.
> 
> So here is a call to the voting committee [1] to decide on the
> following two questions:
> 
> 1) Should libNDI support be removed from the ffmpeg codebase?

I'm conflicted. I agree they violated the licence and they have to
answer for that, but the decision to remove it has negatively affected
end users who didn't do anything wrong, and respected the licence as
understood. Additionally, I'm uncomfortable with the idea that it's
being removed because we say it should never have been there in the
first place, rather than as a direct response to the licence violation.
You might consider that simply playing with semantics but I don't like
the idea of moving the goal posts. At least if you say support was
removed due to licence violations you make it clear why it's happening.

So, I guess I'm voting NO in terms of how and why it was done, and I'd
want a proper discussion of how to do it that and what the basis was.

> 2) Should patches using closed source libraries which are not
> considered "System Libraries" according to the GPL be rejected?

I know the question was withdrawn, but this speaks to the issue of
making sure we understand why we're accepting or rejecting something.
We could say "we'll reject any patches that are LGPL incompatible" which
would obviously cover rejection on this basis, but it would also lead
to rejecting other open-source components which we think we are
comfortable with. We're then left trying to define what we will and
won't accept on less precise terms, which leads to the difficulty we
have today. You could say "any submissions must be covered by one of
the following open source licences", but that will actually allow
things that we seem not to want - like a BSD licenced dynamic loader
for a closed source library - that's clearly a BSD licenced submission
that is LGPL incompatible. Seems messy. It would be easier to construct
a policy if we didn't have LGPL-incompatible open-source components.

> Deadline for voting is 7 days from now.
> 
> Thanks,
> Marton
> 
> [1]
> http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2019-April/242574.html
> ___ ffmpeg-devel mailing
> list ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".



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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [DECISION] colorhold filter

[Paul B Mahol]

On 5/5/19, Reimar Döffinger  wrote:
> On 04.05.2019, at 15:40, Paul B Mahol  wrote:
>> Hi,
>>
>> I open voting for 7 days, for inclusion of colorhold filter in FFmpeg,
>> with minor changes.
>>
>> Thanks.
>
> Why is there a need to vote?

Because Nicolas objected on initial implementation. Dunno if he still
object something
on current updated patch.

> What would be the objections existing or expected that would make a vote
> necessary vs. the normal development process? I so far assumed voting was
> purely a last-resort conflict resolution process.
> Is there a quorum required, or would a vote be accepted even if there was
> only one vote cast?

This is to move forward and not be held back with blocking "arguments".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] About the scaletempo mess

[Nicolas George]

Nicolas George (12019-05-04):
> Either both votes are invalid (my point) or both are.

So, now that I do not have a train to catch, I can take a little more
time to explain the issue here and how to move forward.

First, I apologize to the rest of the project for the noise caused by
this stunt. My point was to use a catch-22 to prove to Paul that if we
do not follow reasonable procedures, votes can lead to unacceptable
results and therefore do not bring the legitimacy you require.

Now that is established, what would be a reasonable procedure.

Paul, please accept that I am in good faith: I am assuming that you are
interesting in COOPERATION on this project, and I am giving you honest
advice on how to act on it. If you follow the procedure I am about to
outline, and if the outcome goes your way, I promise I will not make any
more fuss. But if you refuse to follow it, then good luck explaining
why.

The two principles are:

(1) votes are for when we cannot agree;

(2) we need information to make a decision.

Based on these principles, I suggest the following procedure:

- First, start a discussion.

  - Take your time to explain things. You are not on IRC, where answers
need to be immediate. You are not on twitter where there is a
character count. Explain in detail. Remember that each minute you
spare now by omitting an useful sentence, you will lose later when
you need to re-explain yourself.

  - Summarize the arguments for both side. Yours, of course. But also
the other side's (in this instance, mine). It will show your good
will. It will also show that you have taken these arguments into
account. Of course, be very careful to not mis-represent the
opposite arguments.

- If the discussion leads to a consensus, then we, collectively, have
  won. Nothing more to do.

- Else, go for a vote if you think it is still necessary.

  - Summarise once again the arguments. You can copy-paste the first
mail, but you need to review the discussion to see of any side has
brought new arguments.

It may seem long and cumbersome, but that is the cost of working
together. I assure you, if you do not follow something that looks like
this procedure, you may think you will gain some time immediately, but
in the end you will lose much more time to bikeshedding, with only your
clumsiness to blame.

I hope you believe me that this mail was written in good faith and in
the hope that the project can move forward.

Regards,

-- 
  Nicolas George


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/truehd_core: reset state when flushing

[James Almer]

On 5/5/2019 5:36 AM, Paul B Mahol wrote:
> On 5/5/19, James Almer  wrote:
>> Signed-off-by: James Almer 
>> ---
>>  libavcodec/truehd_core_bsf.c | 7 +++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/libavcodec/truehd_core_bsf.c b/libavcodec/truehd_core_bsf.c
>> index 409e570eec..9e3ee07eed 100644
>> --- a/libavcodec/truehd_core_bsf.c
>> +++ b/libavcodec/truehd_core_bsf.c
>> @@ -174,6 +174,12 @@ fail:
>>  return ret;
>>  }
>>
>> +static void truehd_core_flush(AVBSFContext *ctx)
>> +{
>> +TrueHDCoreContext *s = ctx->priv_data;
>> +memset(>hdr, 0, sizeof(s->hdr));
>> +}
>> +
>>  static const enum AVCodecID codec_ids[] = {
>>  AV_CODEC_ID_TRUEHD, AV_CODEC_ID_NONE,
>>  };
>> @@ -182,5 +188,6 @@ const AVBitStreamFilter ff_truehd_core_bsf = {
>>  .name   = "truehd_core",
>>  .priv_data_size = sizeof(TrueHDCoreContext),
>>  .filter = truehd_core_filter,
>> +.flush  = truehd_core_flush,
>>  .codec_ids  = codec_ids,
>>  };
>> --
>> 2.21.0
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> 
> lgtm

Pushed, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH]lavf/rpl: Don't be case-sensitive detecting codecs

[Carl Eugen Hoyos]

Hi!

Attached patch fixes ticket #7859.

Please comment, Carl Eugen
From 3e5f467c050c3ca0eb1bb5ad65cc1108029886e8 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sun, 5 May 2019 16:32:11 +0200
Subject: [PATCH] lavf/rpl: Don't be case-sensitive detecting codecs.

Fixes ticket #7859
Reported and tested by Steffen Ohrendorf, steffen d ohrendorf a gmx d de
---
 libavformat/rpl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavformat/rpl.c b/libavformat/rpl.c
index fa6357666a..7aec3503da 100644
--- a/libavformat/rpl.c
+++ b/libavformat/rpl.c
@@ -210,10 +210,10 @@ static int rpl_read_header(AVFormatContext *s)
 ast->codecpar->codec_id = AV_CODEC_ID_PCM_S16LE;
 break;
 } else if (ast->codecpar->bits_per_coded_sample == 8) {
-if(strstr(audio_type, "unsigned") != NULL) {
+if(av_strcasecmp(audio_type, "unsigned") >= 0) {
 ast->codecpar->codec_id = AV_CODEC_ID_PCM_U8;
 break;
-} else if(strstr(audio_type, "linear") != NULL) {
+} else if(av_strcasecmp(audio_type, "linear") >= 0) {
 ast->codecpar->codec_id = AV_CODEC_ID_PCM_S8;
 break;
 } else {
-- 
2.21.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [DECISION] colorhold filter

[Reimar Döffinger]

On 04.05.2019, at 15:40, Paul B Mahol  wrote:
> Hi,
> 
> I open voting for 7 days, for inclusion of colorhold filter in FFmpeg,
> with minor changes.
> 
> Thanks.

Why is there a need to vote?
What would be the objections existing or expected that would make a vote 
necessary vs. the normal development process? I so far assumed voting was 
purely a last-resort conflict resolution process.
Is there a quorum required, or would a vote be accepted even if there was only 
one vote cast?

Best regards,
Reimar Döffinger
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [DECISION] colorhold filter

[Paul B Mahol]

On 5/4/19, Paul B Mahol  wrote:
> On 5/4/19, Paul B Mahol  wrote:
>> Hi,
>>
>> I open voting for 7 days, for inclusion of colorhold filter in FFmpeg,
>> with minor changes.
>>
>> Thanks.
>>
>
> See: http://ffmpeg.org/pipermail/ffmpeg-devel/2019-May/243481.html
>

And I vote for inclusion.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] libavutil: add an FFT & MDCT implementation

[Lynne]

May 4, 2019, 10:00 PM by d...@lynne.ee:

> May 4, 2019, 8:10 PM by > mich...@niedermayer.cc 
> > :
>
>> On Fri, May 03, 2019 at 09:08:57PM +0200, Lynne wrote:
>>
>>> This commit adds a new API to libavutil to allow for arbitrary 
>>> transformations
>>> on various types of data.
>>>
>> breaks build on mips
>>
>> CC   libavutil/fft.o
>> src/libavutil/fft.c:47: error: redefinition of typedef ‘AVFFTContext’
>> src/libavutil/fft.h:25: note: previous declaration of ‘AVFFTContext’ was here
>> make: *** [libavutil/fft.o] Error 1
>>
>> [...]
>>
>
> Fixed, v2 attached. Changes:
> -Stride really is in bytes now.
> -Corrected some comments (stride supported by all (i)mdcts, not just compound
>  ones, some clarifications regarding the scale).
>
> Also that 28-point FFT comparison was a typo, its 128.
>

Managed to further optimize the 15-point transform by rewriting it as an 
exptab-less
compound 3x5 transform and embedding its input map into the parent transform's 
map.
Updated comparisons to libfftw3f:
120:
  22353 decicycles in fftwf_execute, 1024 runs,  0 skips
  21836 decicycles in compound_fft_15x8, 1024 runs,  0 skips

480:
  103998 decicycles in   fftwf_execute,    1024 runs,  0 skips
  102747 decicycles in compound_fft_15x32,    1024 runs,  0 skips
960:
  186210 decicycles in  fftwf_execute,    1024 runs,  0 skips
  215256 decicycles in compound_fft_15x64,    1024 runs,  0 skips

>From 6f593542207c01d02ba4abe76bb3e9b433e1f85c Mon Sep 17 00:00:00 2001
From: Lynne 
Date: Thu, 2 May 2019 15:07:12 +0100
Subject: [PATCH] libavutil: add an FFT & MDCT implementation

v2 changes:
Stride really is in bytes now.
Corrected some comments (stride supported by all (i)mdcts, not just compound
ones, some clarifications regarding the scale).

v3 changes:
Optimized the 15-point transform by making it compound as well.

This commit adds a new API to libavutil to allow for arbitrary transformations
on various types of data.
This is a partly new implementation, with the power of two transforms taken
from libavcodec/fft_template, the 5 and 15-point FFT taken from mdct15, while
the 3-point FFT was written from scratch.
The (i)mdct folding code is taken from mdct15 as well, as the mdct_template
code was somewhat old, messy and not easy to separate.

A notable feature of this implementation is that it allows for 3xM and 5xM
based transforms, where M is a power of two, e.g. 384, 640, 768, 1280, etc.
AC-4 uses 3xM transforms while Siren uses 5xM transforms, so the code will
allow for decoding of such streams.
A non-exaustive list of supported sizes:
4, 8, 12, 16, 20, 24, 32, 40, 48, 60, 64, 80, 96, 120, 128, 160, 192, 240,
256, 320, 384, 480, 512, 640, 768, 960, 1024, 1280, 1536, 1920, 2048, 2560...

The API was designed such that it allows for not only 1D transforms but also
2D transforms of certain block sizes. This was partly on accident as the stride
argument is required for Opus MDCTs, but can be used in the context of a 2D
transform as well.
Also, various data types would be implemented eventually as well, such as
"double" and "int32_t".

The avfft_transform() function is awkward but avoids some other more
awkward ideas to isolate the private parts of the structure and not
make them part of the API, as well as reducing call overhead from
an additional function call.

Some performance comparisons with libfftw3f (SIMD disabled for both):
120:
  22353 decicycles in fftwf_execute, 1024 runs,  0 skips
  21836 decicycles in compound_fft_15x8, 1024 runs,  0 skips

128:
  22003 decicycles in   fftwf_execute,   1024 runs,  0 skips
  23132 decicycles in monolithic_fft_ptwo,   1024 runs,  0 skips

384:
  75939 decicycles in  fftwf_execute,1024 runs,  0 skips
  73973 decicycles in compound_fft_3x128,1024 runs,  0 skips

640:
 104354 decicycles in   fftwf_execute,   1024 runs,  0 skips
 149518 decicycles in compound_fft_5x128,1024 runs,  0 skips

768:
 109323 decicycles in  fftwf_execute,1024 runs,  0 skips
 164096 decicycles in compound_fft_3x256,1024 runs,  0 skips

960:
 186210 decicycles in  fftwf_execute,1024 runs,  0 skips
 215256 decicycles in compound_fft_15x64,1024 runs,  0 skips

1024:
 163464 decicycles in   fftwf_execute,   1024 runs,  0 skips
 199686 decicycles in monolithic_fft_ptwo,   1024 runs,  0 skips

With SIMD we should be faster than fftw for 15xM transforms as our fft15 SIMD
is around 2x faster than theirs, even if our ptwo SIMD is slightly slower.

The goal is to remove the libavcodec/mdct15 code and deprecate the
libavcodec/avfft interface once aarch64 and x86 SIMD code has been ported.
It is unlikely that libavcodec/fft will be removed soon as there's much SIMD
written for exotic or old platforms there, but nevertheless new code
should use this new API throughout the project.

The implementation passes fate when used in Opus 

Re: [FFmpeg-devel] [PATCH V2 7/7] libavfilter/dnn: add more data type support for dnn model input

[Carl Eugen Hoyos]

Am So., 5. Mai 2019 um 14:10 Uhr schrieb Guo, Yejun :

> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> > Carl Eugen Hoyos
> > Sent: Sunday, May 05, 2019 6:51 PM
> > To: FFmpeg development discussions and patches 
> > Subject: Re: [FFmpeg-devel] [PATCH V2 7/7] libavfilter/dnn: add more data 
> > type
> > support for dnn model input

Please consider telling your mail client that this is more information
than necessary.

> > Am So., 5. Mai 2019 um 10:45 Uhr schrieb Guo, Yejun :
> >
> > > I plan to first add unit tests in FATE for DNN module
> >
> > Does this module work without an external dependency?
> >
> > If not, you cannot add a fate test.
>
> The DNN module contains two parts, the native part with no external 
> dependency,
> and the other part depending on tensorflow c lib.
>
> Thanks for your info, how about to limit the fate test only on the native 
> part of
> DNN module?

If it is possible to test DNN without tensorflow, there is no problem
(I wasn't sure).

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/3] lavc/qsvdec: add query function and provide error message

[Li, Zhong]

> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Zhong Li
> Sent: Tuesday, April 30, 2019 5:04 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Li, Zhong 
> Subject: [FFmpeg-devel] [PATCH 1/3] lavc/qsvdec: add query function and
> provide error message
> 
> It is helpful to know why some clips decoding failed.
> Ticket#7330 is a good example, with this patch it is easily to know bitstream
> codec level is out of support range.
> 
> Signed-off-by: Zhong Li 
> ---
>  libavcodec/qsvdec.c | 33 +
>  1 file changed, 33 insertions(+)
> 
> diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c index
> 4a0be811fb..2a8a032111 100644
> --- a/libavcodec/qsvdec.c
> +++ b/libavcodec/qsvdec.c
> @@ -120,6 +120,33 @@ static inline unsigned int qsv_fifo_size(const
> AVFifoBuffer* fifo)
>  return av_fifo_size(fifo) / qsv_fifo_item_size();  }
> 
> +static int check_dec_param(AVCodecContext *avctx, QSVContext *q,
> +mfxVideoParam *param_in) {
> +mfxVideoParam param_out = { .mfx.CodecId =
> param_in->mfx.CodecId };
> +mfxStatus ret;
> +
> +#define CHECK_MATCH(x) \
> +do { \
> +  if (param_out.mfx.x != param_in->mfx.x) {   \
> +  av_log(avctx, AV_LOG_WARNING, "Required "#x" %d is
> unsupported\n", \
> +  param_in->mfx.x); \
> +  } \
> +} while (0)
> +
> +ret = MFXVideoDECODE_Query(q->session, param_in, _out);
> +
> +if (ret < 0) {
> +CHECK_MATCH(CodecId);
> +CHECK_MATCH(CodecProfile);
> +CHECK_MATCH(CodecLevel);
> +CHECK_MATCH(FrameInfo.Width);
> +CHECK_MATCH(FrameInfo.Height);
> +#undef CHECK_MATCH
> +return 0;
> +}
> +return 1;
> +}
> +
>  static int qsv_decode_init(AVCodecContext *avctx, QSVContext *q)  {
>  const AVPixFmtDescriptor *desc;
> @@ -206,6 +233,12 @@ static int qsv_decode_init(AVCodecContext *avctx,
> QSVContext *q)
>  param.ExtParam= q->ext_buffers;
>  param.NumExtParam = q->nb_ext_buffers;
> 
> +if (!check_dec_param(avctx, q, )) {
> +//Just give a warning instead of an error since it is still decodable
> possibly.
> +av_log(avctx, AV_LOG_WARNING,
> +   "Current input bitstream is not supported by QSV
> decoder.\n");
> +}
> +
>  ret = MFXVideoDECODE_Init(q->session, );
>  if (ret < 0)
>  return ff_qsv_print_error(avctx, ret,
> --
> 2.17.1

Ping for comment of this patch set.  
Thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH V2 7/7] libavfilter/dnn: add more data type support for dnn model input

[Guo, Yejun]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Carl Eugen Hoyos
> Sent: Sunday, May 05, 2019 6:51 PM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH V2 7/7] libavfilter/dnn: add more data type
> support for dnn model input
> 
> Am So., 5. Mai 2019 um 10:45 Uhr schrieb Guo, Yejun :
> 
> > I plan to first add unit tests in FATE for DNN module
> 
> Does this module work without an external dependency?
> 
> If not, you cannot add a fate test.

The DNN module contains two parts, the native part with no external dependency,
and the other part depending on tensorflow c lib.

Thanks for your info, how about to limit the fate test only on the native part 
of DNN module? thanks.

> 
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [DECISION] Project policy on closed source components

[Li, Zhong]

> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Marton Balint
> Sent: Monday, April 29, 2019 4:02 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [DECISION] Project policy on closed source
> components
> 
> Hi All,
> 
> There has been discussion on the mailing list several times about the
> inclusion of support for closed source components (codecs, formats, filters,
> etc) in the main ffmpeg codebase.
> 
> Also the removal of libNDI happened without general consensus, so a vote is
> necessary to justify the removal.
> 
> So here is a call to the voting committee [1] to decide on the following two
> questions:
> 
> 1) Should libNDI support be removed from the ffmpeg codebase?

Yes

> 2) Should patches using closed source libraries which are not considered
> "System Libraries" according to the GPL be rejected?
> 
> Deadline for voting is 7 days from now.

Yes.

(Looks it is a good chance to have a good summary (or guide) about the whole 
vote process, including which case can trigger a vote, how to define a vote 
period，
how to remove vote committee who are not active and add new committee, and so 
on )
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/qtrle: Do not output duplicated frames on insufficient input

[Paul B Mahol]

On 5/30/18, Michael Niedermayer  wrote:
> On Sun, May 27, 2018 at 09:59:58PM +0200, Michael Niedermayer wrote:
>> This improves performance and makes qtrle behave more similar to other
>> decoders.
>> Libavcodec does generally not output known duplicated frames, instead the
>> calling Application
>> can insert them as it needs.
>>
>> Fixes: Timeout
>> Fixes:
>> 6383/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_QTRLE_fuzzer-6199846902956032
>>
>> Found-by: continuous fuzzing process
>> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>> Signed-off-by: Michael Niedermayer 
>> ---
>>  libavcodec/qtrle.c|  12 ++---
>>  tests/ref/fate/qtrle-8bit | 109 --
>>  2 files changed, 6 insertions(+), 115 deletions(-)
>
> will apply

Please revert this one and any similar commit to all video decoders.

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> The worst form of inequality is to try to make unequal things equal.
> -- Aristotle
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/qtrle: Do not output duplicated frames on insufficient input

[Carl Eugen Hoyos]

Am So., 27. Mai 2018 um 22:00 Uhr schrieb Michael Niedermayer
:

> This improves performance and makes qtrle behave more similar to other 
> decoders.

> Libavcodec does generally not output known duplicated frames, instead the 
> calling
> Application can insert them as it needs.

The issue is apparently that one specific calling Application cannot
be convinced to
insert the frames, not even with "-vsync cfr", see ticket #7880.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH V2 7/7] libavfilter/dnn: add more data type support for dnn model input

[Carl Eugen Hoyos]

Am So., 5. Mai 2019 um 10:45 Uhr schrieb Guo, Yejun :

> I plan to first add unit tests in FATE for DNN module

Does this module work without an external dependency?

If not, you cannot add a fate test.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v10 1/2] lavc/svt_hevc: add libsvt hevc encoder wrapper

[Carl Eugen Hoyos]

Am So., 5. Mai 2019 um 12:10 Uhr schrieb Sun, Jing A :
>
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Carl 
> Eugen Hoyos
> Sent: Friday, April 26, 2019 11:28 PM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH v10 1/2] lavc/svt_hevc: add libsvt hevc 
> encoder wrapper
>
> 2019-04-26 8:41 GMT+02:00, Li, Zhong :
> >> Is it V11 now? (Just saw several V10 and I am a litter confused.)
> >> Since there is some existed software HEVC encoder, how about add a
> >> link to the SVT-HEVC writepaper in the commit message to make other
> >> easily to understand what is the advantage of SVT-HEVC and the benefit
> >> to plugin to FFmpeg?
>
> >Without knowing the white paper, I would prefer not to add a link.
> >Carl Eugen
>
> Thanks for the review!
>
> The whitepaper is not final, and I prefer not to add its link as well. Also 
> it's quite easy to locate
> it in the SVT HEVC GitHub page. Is that OK not to add it?

> For versions, I increased it if big changes were submitted and kept it the 
> same if only minor
> changes. I am new to the community and would you please guide me if that 
> strategy is all
> right or not? If not, I will resubmit the last with v11.

You add a new encoder, so you have to raise MINOR in
libavcodec/version.h (and reset MICRO).

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v10 1/2] lavc/svt_hevc: add libsvt hevc encoder wrapper

[Sun, Jing A]

-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Carl 
Eugen Hoyos
Sent: Friday, April 26, 2019 11:28 PM
To: FFmpeg development discussions and patches 
Subject: Re: [FFmpeg-devel] [PATCH v10 1/2] lavc/svt_hevc: add libsvt hevc 
encoder wrapper

2019-04-26 8:41 GMT+02:00, Li, Zhong :
>> Is it V11 now? (Just saw several V10 and I am a litter confused.)
>> Since there is some existed software HEVC encoder, how about add a 
>> link to the SVT-HEVC writepaper in the commit message to make other 
>> easily to understand what is the advantage of SVT-HEVC and the benefit 
>> to plugin to FFmpeg?

>Without knowing the white paper, I would prefer not to add a link.
>Carl Eugen

Thanks for the review!

The whitepaper is not final, and I prefer not to add its link as well. Also 
it's quite easy to locate it in the SVT HEVC GitHub page. Is that OK not to add 
it?
For versions, I increased it if big changes were submitted and kept it the same 
if only minor changes. I am new to the community and would you please guide me 
if that strategy is all right or not? If not, I will resubmit the last with 
v11. 

Regards,
Sun, Jing
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/2] configure: print_in_columns: Replace pr with awk

[Alexander Strasser]

Am 5. Mai 2019 03:53:20 MESZ schrieb "Guo, Yejun" :
>
>
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
>Of
>> Alexander Strasser
>> Sent: Thursday, May 02, 2019 12:08 AM
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: [FFmpeg-devel] [PATCH 1/2] configure: print_in_columns:
>Replace pr
>> with awk
>> 
>> Get rid of pr dependency and write the columns strictly
>> alphabetical for the given rows.
>> 
>> Before pr would attempt to write pages, thus if a page
>> boundary was reached, the output looked confusing as one
>> couldn't see there was a new page and the alphabetical
>> order was disrupted when scanning down one of the columns.
>> 
>> Fixes output for sizes with width < column width, too.
>> 
>> Fixes part of ticket #5680
>> 
>> Signed-off-by: Alexander Strasser 
>> ---
>>  configure | 18 --
>>  1 file changed, 16 insertions(+), 2 deletions(-)
>> 
>> diff --git a/configure b/configure
>> index b122b27268..81e3776060 100755
>> --- a/configure
>> +++ b/configure
>> @@ -3831,8 +3831,22 @@ die_unknown(){
>>  }
>> 
>>  print_in_columns() {
>> -cols=$(expr $ncols / 24)
>> -cat | tr ' ' '\n' | sort | pr -r "-$cols" -w $ncols -t
>> +tr ' ' '\n' | sort | tr '\r\n' '  ' | awk -v col_width=24 -v
>width="$ncols" '
>> +{
>> +num_cols = width > col_width ? int(width / col_width) : 1;
>> +num_rows = int((NF + num_cols-1) / num_cols);
>> +y = x = 1;
>> +for (y = 1; y <= num_rows; y++) {
>> +i = y;
>> +for (x = 1; x <= num_cols; x++) {
>> +if (i <= NF) {
>> +  line = sprintf("%s%-24s", line, $i);
>
>not sure how to use col_width instead of the magic number 24.

Good catch! Fortunately it's easy to fix:

  line = sprintf("%s%-" col_width "s", line, $i);

Will change it locally. Thanks.

  Alexander

>> +}
>> +i = i + num_rows;
>> +}
>> +print line; line = "";
>> +}
>> +}' | sed 's/ *$//'
>>  }
>> 
>>  show_list() {
>> --
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH V2 7/7] libavfilter/dnn: add more data type support for dnn model input

[Guo, Yejun]

> -Original Message-
> From: Pedro Arthur [mailto:bygran...@gmail.com]
> Sent: Tuesday, April 30, 2019 9:33 AM
> To: Guo, Yejun 
> Cc: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH V2 7/7] libavfilter/dnn: add more data type
> support for dnn model input
> 
> Em seg, 29 de abr de 2019 às 22:21, Guo, Yejun 
> escreveu:
> >
> >
> >
> > > -Original Message-
> > > From: Pedro Arthur [mailto:bygran...@gmail.com]
> > > Sent: Tuesday, April 30, 2019 1:47 AM
> > > To: FFmpeg development discussions and patches
> 
> > > Cc: Guo, Yejun 
> > > Subject: Re: [FFmpeg-devel] [PATCH V2 7/7] libavfilter/dnn: add more data
> type
> > > support for dnn model input
> > >
> > > Em qua, 24 de abr de 2019 às 23:15, Guo, Yejun 
> > > escreveu:
> > > >
> > > > currently, only float is supported as model input, actually, there
> > > > are other data types, this patch adds uint8.
> > > >
> > > > Signed-off-by: Guo, Yejun 
> > >
> > >
> > > LGTM.
> > >
> > > I think it would be valuable to add a few tests covering the features
> > > added by this patch series.
> >
> > thanks, good point. Do you mean FATE? Is there any previous test for DNN
> module that I can refer to? thanks. I'll investigate it after my holiday, I'm
> starting vacation today.
> 
> Yes, I mean FATE, unfortunately there isn't any tests for DNN atm.

I plan to first add unit tests in FATE for DNN module, since the DNN interfaces 
is not exported as ffmpeg APIs.
I'll add tests/fate/dnn.mak, and also a new folder at tests/dnn. There will be 
.c files under tests/dnn, and
each .c file contains main() function to verify one feature of dnn module. It 
will be a self-contained test, no
source samples nor reference data is required.

In the future, we can add tests/fate/dnn-filters.mak to verify deep learning 
based filters with source samples and reference data.

> 
> Have a nice vacation!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/truehd_core: reset state when flushing

[Paul B Mahol]

On 5/5/19, James Almer  wrote:
> Signed-off-by: James Almer 
> ---
>  libavcodec/truehd_core_bsf.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/libavcodec/truehd_core_bsf.c b/libavcodec/truehd_core_bsf.c
> index 409e570eec..9e3ee07eed 100644
> --- a/libavcodec/truehd_core_bsf.c
> +++ b/libavcodec/truehd_core_bsf.c
> @@ -174,6 +174,12 @@ fail:
>  return ret;
>  }
>
> +static void truehd_core_flush(AVBSFContext *ctx)
> +{
> +TrueHDCoreContext *s = ctx->priv_data;
> +memset(>hdr, 0, sizeof(s->hdr));
> +}
> +
>  static const enum AVCodecID codec_ids[] = {
>  AV_CODEC_ID_TRUEHD, AV_CODEC_ID_NONE,
>  };
> @@ -182,5 +188,6 @@ const AVBitStreamFilter ff_truehd_core_bsf = {
>  .name   = "truehd_core",
>  .priv_data_size = sizeof(TrueHDCoreContext),
>  .filter = truehd_core_filter,
> +.flush  = truehd_core_flush,
>  .codec_ids  = codec_ids,
>  };
> --
> 2.21.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] vf_tonemap.c: Support for slice thread for performance

[Paul B Mahol]

On 5/5/19, lance.lmw...@gmail.com  wrote:
> From: Limin Wang 
>
> ---
>  libavfilter/vf_tonemap.c | 109 +--
>  1 file changed, 81 insertions(+), 28 deletions(-)
>
> diff --git a/libavfilter/vf_tonemap.c b/libavfilter/vf_tonemap.c
> index efd4af5466..0b26dd5e7f 100644
> --- a/libavfilter/vf_tonemap.c
> +++ b/libavfilter/vf_tonemap.c
> @@ -1,5 +1,6 @@
>  /*
>   * Copyright (c) 2017 Vittorio Giovara 
> + * Copyright (c) 2019 Limin Wang 
>   *
>   * This file is part of FFmpeg.
>   *
> @@ -71,6 +72,13 @@ typedef struct TonemapContext {
>  const struct LumaCoefficients *coeffs;
>  } TonemapContext;
>
> +typedef struct ThreadData {
> +AVFrame *in, *out;
> +double peak;
> +const struct AVPixFmtDescriptor *desc;
> +const struct AVPixFmtDescriptor *odesc;
> +} ThreadData;
> +
>  static const enum AVPixelFormat pix_fmts[] = {
>  AV_PIX_FMT_GBRPF32,
>  AV_PIX_FMT_GBRAPF32,
> @@ -127,15 +135,10 @@ static float mobius(float in, float j, double peak)
>  }
>
>  #define MIX(x,y,a) (x) * (1 - (a)) + (y) * (a)
> -static void tonemap(TonemapContext *s, AVFrame *out, const AVFrame *in,
> -const AVPixFmtDescriptor *desc, int x, int y, double
> peak)
> +static void tonemap(TonemapContext *s, float *r_out, float *b_out, float
> *g_out,
> +const float *r_in, const float *b_in, const float
> *g_in,
> +const AVPixFmtDescriptor *desc, double peak)
>  {
> -const float *r_in = (const float *)(in->data[0] + x *
> desc->comp[0].step + y * in->linesize[0]);
> -const float *b_in = (const float *)(in->data[1] + x *
> desc->comp[1].step + y * in->linesize[1]);
> -const float *g_in = (const float *)(in->data[2] + x *
> desc->comp[2].step + y * in->linesize[2]);
> -float *r_out = (float *)(out->data[0] + x * desc->comp[0].step + y *
> out->linesize[0]);
> -float *b_out = (float *)(out->data[1] + x * desc->comp[1].step + y *
> out->linesize[1]);
> -float *g_out = (float *)(out->data[2] + x * desc->comp[2].step + y *
> out->linesize[2]);
>  float sig, sig_orig;
>
>  /* load values */
> @@ -189,17 +192,78 @@ static void tonemap(TonemapContext *s, AVFrame *out,
> const AVFrame *in,
>  *r_out *= sig / sig_orig;
>  *g_out *= sig / sig_orig;
>  *b_out *= sig / sig_orig;
> +
> +}
> +
> +static int do_tonemap_slice(AVFilterContext *ctx, void *arg, int jobnr, int
> nb_jobs)
> +{
> +TonemapContext *s = ctx->priv;
> +const ThreadData *td = arg;
> +const AVFrame *in = td->in;
> +AVFrame *out = td->out;
> +int x, y;
> +const AVPixFmtDescriptor *desc = td->desc;
> +const AVPixFmtDescriptor *odesc = td->odesc;
> +const int slice_start = (out->height *  jobnr   ) / nb_jobs;
> +const int slice_end   = (out->height * (jobnr+1)) / nb_jobs;
> +const int slice_h   = slice_end - slice_start;
> +uint8_t *dstr = out->data[0] + slice_start * out->linesize[0];
> +uint8_t *dstb = out->data[1] + slice_start * out->linesize[1];
> +uint8_t *dstg = out->data[2] + slice_start * out->linesize[2];
> +const uint8_t *srcr = in->data[0] + slice_start * in->linesize[0];
> +const uint8_t *srcb = in->data[1] + slice_start * in->linesize[1];
> +const uint8_t *srcg = in->data[2] + slice_start * in->linesize[2];
> +uint8_t *dsta = out->data[3] + slice_start * out->linesize[3];
> +const uint8_t *srca = in ->data[3] + slice_start * in->linesize[3];
> +
> +/* do the tone map */
> +for (y = slice_start; y < slice_end; y++) {
> +for (x = 0; x < out->width; x++) {
> +const float *r_in = (const float *)(srcr + x *
> desc->comp[0].step);
> +const float *b_in = (const float *)(srcb + x *
> desc->comp[1].step);
> +const float *g_in = (const float *)(srcg + x *
> desc->comp[2].step);
> +float *r_out = (float *)(dstr + x * desc->comp[0].step);
> +float *b_out = (float *)(dstb + x * desc->comp[1].step);
> +float *g_out = (float *)(dstg + x * desc->comp[2].step);
> +
> +tonemap(s, r_out, b_out, g_out, r_in, b_in, g_in, desc,
> td->peak);
> +}
> +srcr += in->linesize[0];
> +srcg += in->linesize[1];
> +srcb += in->linesize[2];
> +dstr += out->linesize[0];
> +dstg += out->linesize[1];
> +dstb += out->linesize[2];
> +}
> +
> +/* copy/generate alpha if needed */
> +if (desc->flags & AV_PIX_FMT_FLAG_ALPHA && odesc->flags &
> AV_PIX_FMT_FLAG_ALPHA) {
> +av_image_copy_plane(dsta, out->linesize[3],
> +srca, in->linesize[3],
> +out->linesize[3], slice_h);
> +} else if (odesc->flags & AV_PIX_FMT_FLAG_ALPHA) {
> +for (y = slice_start; y < slice_end; y++) {
> +for (x = 0; x < out->width; x++) {
> +AV_WN32(dsta + x * odesc->comp[3].step + y *
> out->linesize[3],
> +av_float2int(1.0f));
> +}
> + 

Re: [FFmpeg-devel] [PATCH] avfilter/f_interleave: switch to activate

[Paul B Mahol]

On 5/3/19, Paul B Mahol  wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  libavfilter/f_interleave.c | 125 +++--
>  1 file changed, 51 insertions(+), 74 deletions(-)
>

Will apply.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] vf_tonemap.c: Support for slice thread for performance

[lance . lmwang]

From: Limin Wang 

---
 libavfilter/vf_tonemap.c | 109 +--
 1 file changed, 81 insertions(+), 28 deletions(-)

diff --git a/libavfilter/vf_tonemap.c b/libavfilter/vf_tonemap.c
index efd4af5466..0b26dd5e7f 100644
--- a/libavfilter/vf_tonemap.c
+++ b/libavfilter/vf_tonemap.c
@@ -1,5 +1,6 @@
 /*
  * Copyright (c) 2017 Vittorio Giovara 
+ * Copyright (c) 2019 Limin Wang 
  *
  * This file is part of FFmpeg.
  *
@@ -71,6 +72,13 @@ typedef struct TonemapContext {
 const struct LumaCoefficients *coeffs;
 } TonemapContext;
 
+typedef struct ThreadData {
+AVFrame *in, *out;
+double peak;
+const struct AVPixFmtDescriptor *desc;
+const struct AVPixFmtDescriptor *odesc;
+} ThreadData;
+
 static const enum AVPixelFormat pix_fmts[] = {
 AV_PIX_FMT_GBRPF32,
 AV_PIX_FMT_GBRAPF32,
@@ -127,15 +135,10 @@ static float mobius(float in, float j, double peak)
 }
 
 #define MIX(x,y,a) (x) * (1 - (a)) + (y) * (a)
-static void tonemap(TonemapContext *s, AVFrame *out, const AVFrame *in,
-const AVPixFmtDescriptor *desc, int x, int y, double peak)
+static void tonemap(TonemapContext *s, float *r_out, float *b_out, float 
*g_out,
+const float *r_in, const float *b_in, const float *g_in,
+const AVPixFmtDescriptor *desc, double peak)
 {
-const float *r_in = (const float *)(in->data[0] + x * desc->comp[0].step + 
y * in->linesize[0]);
-const float *b_in = (const float *)(in->data[1] + x * desc->comp[1].step + 
y * in->linesize[1]);
-const float *g_in = (const float *)(in->data[2] + x * desc->comp[2].step + 
y * in->linesize[2]);
-float *r_out = (float *)(out->data[0] + x * desc->comp[0].step + y * 
out->linesize[0]);
-float *b_out = (float *)(out->data[1] + x * desc->comp[1].step + y * 
out->linesize[1]);
-float *g_out = (float *)(out->data[2] + x * desc->comp[2].step + y * 
out->linesize[2]);
 float sig, sig_orig;
 
 /* load values */
@@ -189,17 +192,78 @@ static void tonemap(TonemapContext *s, AVFrame *out, 
const AVFrame *in,
 *r_out *= sig / sig_orig;
 *g_out *= sig / sig_orig;
 *b_out *= sig / sig_orig;
+
+}
+
+static int do_tonemap_slice(AVFilterContext *ctx, void *arg, int jobnr, int 
nb_jobs)
+{
+TonemapContext *s = ctx->priv;
+const ThreadData *td = arg;
+const AVFrame *in = td->in;
+AVFrame *out = td->out;
+int x, y;
+const AVPixFmtDescriptor *desc = td->desc;
+const AVPixFmtDescriptor *odesc = td->odesc;
+const int slice_start = (out->height *  jobnr   ) / nb_jobs;
+const int slice_end   = (out->height * (jobnr+1)) / nb_jobs;
+const int slice_h   = slice_end - slice_start;
+uint8_t *dstr = out->data[0] + slice_start * out->linesize[0];
+uint8_t *dstb = out->data[1] + slice_start * out->linesize[1];
+uint8_t *dstg = out->data[2] + slice_start * out->linesize[2];
+const uint8_t *srcr = in->data[0] + slice_start * in->linesize[0];
+const uint8_t *srcb = in->data[1] + slice_start * in->linesize[1];
+const uint8_t *srcg = in->data[2] + slice_start * in->linesize[2];
+uint8_t *dsta = out->data[3] + slice_start * out->linesize[3];
+const uint8_t *srca = in ->data[3] + slice_start * in->linesize[3];
+
+/* do the tone map */
+for (y = slice_start; y < slice_end; y++) {
+for (x = 0; x < out->width; x++) {
+const float *r_in = (const float *)(srcr + x * desc->comp[0].step);
+const float *b_in = (const float *)(srcb + x * desc->comp[1].step);
+const float *g_in = (const float *)(srcg + x * desc->comp[2].step);
+float *r_out = (float *)(dstr + x * desc->comp[0].step);
+float *b_out = (float *)(dstb + x * desc->comp[1].step);
+float *g_out = (float *)(dstg + x * desc->comp[2].step);
+
+tonemap(s, r_out, b_out, g_out, r_in, b_in, g_in, desc, td->peak);
+}
+srcr += in->linesize[0];
+srcg += in->linesize[1];
+srcb += in->linesize[2];
+dstr += out->linesize[0];
+dstg += out->linesize[1];
+dstb += out->linesize[2];
+}
+
+/* copy/generate alpha if needed */
+if (desc->flags & AV_PIX_FMT_FLAG_ALPHA && odesc->flags & 
AV_PIX_FMT_FLAG_ALPHA) {
+av_image_copy_plane(dsta, out->linesize[3],
+srca, in->linesize[3],
+out->linesize[3], slice_h);
+} else if (odesc->flags & AV_PIX_FMT_FLAG_ALPHA) {
+for (y = slice_start; y < slice_end; y++) {
+for (x = 0; x < out->width; x++) {
+AV_WN32(dsta + x * odesc->comp[3].step + y * out->linesize[3],
+av_float2int(1.0f));
+}
+}
+}
+
+return 0;
 }
 
 static int filter_frame(AVFilterLink *link, AVFrame *in)
 {
-TonemapContext *s = link->dst->priv;
+AVFilterContext *ctx = link->dst;
+TonemapContext *s = ctx->priv;
 AVFilterLink *outlink = link->dst->outputs[0];
 AVFrame 

Re: [FFmpeg-devel] [DECISION] Project policy on closed source components

[Reimar Döffinger]

On 03.05.2019, at 20:16, Michael Niedermayer  wrote:

> On Fri, May 03, 2019 at 11:08:35AM +0200, Carl Eugen Hoyos wrote:
>> Am Fr., 3. Mai 2019 um 07:27 Uhr schrieb Jeyapal, Karthick
>> :
> 
>> And finally: What do you suggest to "punish the violator"?
> 
> while this question wasnt directed at me ...
> 
> Compete with it, provide a better product for a lower price, as in like a
> free open replacement. If you succeed the majority of people will be happy.
> 
> Its better to replace a feature by a supperior or equivalent one than to
> just remove it.

I agree with the idea, but it becomes a VERY unfair competition when one side 
enforces their "IP" rights beyond their legal rights (while ignoring any one 
else's) and the other side does nothing.
"What's mine is mine and what's yours is also mine" is not really competition.
From a quick read that seems to be the majority objection here...
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH V2 2/2] lavfi/opencl: add nlmeans_opencl filter

[Song, Ruiling]

Will apply.

> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".