[FFmpeg-devel] [PATCH] avfilter/scene_sad: add AArch64 SIMD

[quinkblack]

From: Zhao Zhili 

For 8 bit depth:
./ffmpeg -threads 1 -f lavfi -t 10 -i 
'yuvtestsrc=size=4096x2048,format=yuv444p' -vf 'freezedetect' -f null 
-benchmark -

Test results on Snapdragon 845:
Before:
frame=  250 fps= 23 q=-0.0 Lsize=N/A time=00:00:10.00 bitrate=N/A 
speed=0.924x
bench: utime=8.360s stime=2.350s rtime=10.820s
After:
frame=  250 fps= 51 q=-0.0 Lsize=N/A time=00:00:10.00 bitrate=N/A 
speed=2.04x
bench: utime=2.650s stime=2.210s rtime=4.909s

Test results on HiSilicon Kirin 970:
Before:
frame=  250 fps=6.0 q=-0.0 Lsize=N/A time=00:00:10.00 bitrate=N/A 
speed=0.239x
bench: utime=35.156s stime=6.604s rtime=41.820s
After:
frame=  250 fps= 10 q=-0.0 Lsize=N/A time=00:00:10.00 bitrate=N/A 
speed=0.403x
bench: utime=18.400s stime=6.376s rtime=24.798s

For 16 bit depth:
./ffmpeg -threads 1 -f lavfi -t 10 -i 
'yuvtestsrc=size=4096x2048,format=yuv444p16' -vf 'freezedetect' -f null 
-benchmark -

Test results on Snapdragon 845
Before:
frame=  250 fps= 19 q=-0.0 Lsize=N/A time=00:00:10.00 bitrate=N/A 
speed=0.756x
bench: utime=8.700s stime=4.410s rtime=13.226s
After:
frame=  250 fps= 27 q=-0.0 Lsize=N/A time=00:00:10.00 bitrate=N/A 
speed=1.07x
bench: utime=4.920s stime=4.350s rtime=9.356s

Test results on HiSilicon Kirin 970:
Before:
frame=  250 fps=4.0 q=-0.0 Lsize=N/A time=00:00:10.00 bitrate=N/A 
speed=0.161x
bench: utime=48.868s stime=13.124s rtime=62.110s
After:
frame=  250 fps=5.1 q=-0.0 Lsize=N/A time=00:00:10.00 bitrate=N/A 
speed=0.205x
bench: utime=35.600s stime=13.036s rtime=48.708s
---
 libavfilter/aarch64/Makefile |   2 +
 libavfilter/aarch64/scene_sad_init.c |  37 +++
 libavfilter/aarch64/scene_sad_neon.S | 149 +++
 libavfilter/scene_sad.c  |   2 +
 libavfilter/scene_sad.h  |   2 +
 5 files changed, 192 insertions(+)
 create mode 100644 libavfilter/aarch64/scene_sad_init.c
 create mode 100644 libavfilter/aarch64/scene_sad_neon.S

diff --git a/libavfilter/aarch64/Makefile b/libavfilter/aarch64/Makefile
index 6c727f9859..3a458f511f 100644
--- a/libavfilter/aarch64/Makefile
+++ b/libavfilter/aarch64/Makefile
@@ -1,7 +1,9 @@
 OBJS-$(CONFIG_NLMEANS_FILTER)+= aarch64/af_afir_init.o
 OBJS-$(CONFIG_NLMEANS_FILTER)+= aarch64/af_anlmdn_init.o
+OBJS-$(CONFIG_NLMEANS_FILTER)+= aarch64/scene_sad_init.o
 OBJS-$(CONFIG_NLMEANS_FILTER)+= aarch64/vf_nlmeans_init.o
 
 NEON-OBJS-$(CONFIG_NLMEANS_FILTER)   += aarch64/af_afir_neon.o
 NEON-OBJS-$(CONFIG_NLMEANS_FILTER)   += aarch64/af_anlmdn_neon.o
+NEON-OBJS-$(CONFIG_NLMEANS_FILTER)   += aarch64/scene_sad_neon.o
 NEON-OBJS-$(CONFIG_NLMEANS_FILTER)   += aarch64/vf_nlmeans_neon.o
diff --git a/libavfilter/aarch64/scene_sad_init.c 
b/libavfilter/aarch64/scene_sad_init.c
new file mode 100644
index 00..8de769ac10
--- /dev/null
+++ b/libavfilter/aarch64/scene_sad_init.c
@@ -0,0 +1,37 @@
+/*
+ * 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 "libavutil/aarch64/cpu.h"
+#include "libavfilter/scene_sad.h"
+
+void ff_scene_sad_neon(SCENE_SAD_PARAMS);
+
+void ff_scene_sad16_neon(SCENE_SAD_PARAMS);
+
+ff_scene_sad_fn ff_scene_sad_get_fn_aarch64(int depth)
+{
+int cpu_flags = av_get_cpu_flags();
+if (have_neon(cpu_flags)) {
+if (depth == 8)
+return ff_scene_sad_neon;
+if (depth == 16)
+return ff_scene_sad16_neon;
+}
+
+return NULL;
+}
diff --git a/libavfilter/aarch64/scene_sad_neon.S 
b/libavfilter/aarch64/scene_sad_neon.S
new file mode 100644
index 00..5b3b027a53
--- /dev/null
+++ b/libavfilter/aarch64/scene_sad_neon.S
@@ -0,0 +1,149 @@
+/*
+ * Copyright (c) 2020 Zhao Zhili
+ *
+ * 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 WITHOU

Re: [FFmpeg-devel] [PATCH] af_volume: fix integer clip

[zhilizhao]

> On Jan 27, 2020, at 6:28 PM, Zhao Zhili  wrote:
> 
> 
> 
>> On Jan 27, 2020, at 12:59 AM, Carl Eugen Hoyos > > wrote:
>> 
>> Am So., 26. Jan. 2020 um 17:13 Uhr schrieb Zhao Zhili 
>> mailto:quinkbl...@foxmail.com>>:
>>> 
>>> ---
>>> Or specify an upper limit on volume. What do you think?
>>> 
>>> libavfilter/af_volume.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>> 
>>> diff --git a/libavfilter/af_volume.c b/libavfilter/af_volume.c
>>> index 213c57195a..029925cbfb 100644
>>> --- a/libavfilter/af_volume.c
>>> +++ b/libavfilter/af_volume.c
>>> @@ -200,7 +200,7 @@ static inline void scale_samples_s16(uint8_t *dst, 
>>> const uint8_t *src,
>>> int16_t *smp_dst   = (int16_t *)dst;
>>> const int16_t *smp_src = (const int16_t *)src;
>>> for (i = 0; i < nb_samples; i++)
>>> -smp_dst[i] = av_clip_int16(((int64_t)smp_src[i] * volume + 128) >> 
>>> 8);
>>> +smp_dst[i] = (int16_t)av_clip64(((int64_t)smp_src[i] * volume + 
>>> 128) >> 8, INT16_MIN, INT16_MAX);
>> 
>> The cast looks unnecessary and confusing but if a limit works, it is likely
>> simpler imo.
> 
> The function is supposed to handle smp_src[i] * volume > INT32_MAX, so the 
> cast is necessary.
> 
> case AV_SAMPLE_FMT_S16:
> if (vol->volume_i < 0x1)
> vol->scale_samples = scale_samples_s16_small;
> else
> vol->scale_samples = scale_samples_s16;
> break;
> 
> I'm not sure about the use case. Does the function suppose to handle
> (((int64_t)smp_src[i] * volume + 128) >> 8) > INT32_MAX?
> 
> By the way, there is another overflow in set_volume():
> 
> if (vol->precision == PRECISION_FIXED) {
> vol->volume_i = (int)(vol->volume * 256 + 0.5);
> vol->volume   = vol->volume_i / 256.0;
> av_log(ctx, AV_LOG_VERBOSE, "volume_i:%d/255 ", vol->volume_i);
> }

Ping. Any suggestions?

> 
>> 
>> 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] [PATCH] avfilter/af_anlmdn: add AArch64 SIMD for compute_distance_ssd

[zhilizhao]

> On Jan 25, 2020, at 12:13 AM, Carl Eugen Hoyos  wrote:
> 
> Am Fr., 24. Jan. 2020 um 10:15 Uhr schrieb Zhao Zhili  >:
>> 
>> ./ffmpeg -threads 1  -f lavfi -t 60 -i anoisesrc -af 'anlmdn' -f null 
>> -benchmark -
>> 
>> Test results on Snapdragon 845:
>>Before:
>>size=N/A time=00:01:00.00 bitrate=N/A speed=11.2x
>>video:0kB audio:5625kB subtitle:0kB other streams:0kB global 
>> headers:0kB muxing overhead: unknown
>>bench: utime=5.320s stime=0.010s rtime=5.358s
>>bench: maxrss=14172kB
>> 
>>After:
>>size=N/A time=00:01:00.00 bitrate=N/A speed=15.4x
>>video:0kB audio:5625kB subtitle:0kB other streams:0kB global 
>> headers:0kB muxing overhead: unknown
>>bench: utime=3.870s stime=0.000s rtime=3.902s
>>bench: maxrss=14036kB
> 
> In case anybody is curious:
> This is a higher speedup than the x86 asm optimization offers.
> 

Ping for review, 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] [PATCH] avfilter/af_afir: add AArch64 SIMD for fcmul_add

[zhilizhao]

> On Jan 24, 2020, at 6:54 PM, Paul B Mahol  wrote:
> 
> Seems very trivial.

Yes it is. Please help review the patch, thanks!

> 
> On 1/18/20, Zhao Zhili  wrote:
>> ./ffmpeg -threads 1 -f lavfi -i anoisesrc -f lavfi -t 30 -i anoisesrc  -t
>> 600  -lavfi afir -benchmark  -f null -
>> 
>> Test results on Snapdragon 845:
>>Without SIMD:
>>  size=N/A time=00:10:00.00 bitrate=N/A speed=32.2x
>>  bench: utime=21.900s stime=1.000s rtime=18.607s
>>  bench: maxrss=46708kB
>>With SIMD:
>>  size=N/A time=00:10:00.00 bitrate=N/A speed=46.6x
>>  bench: utime=16.150s stime=1.040s rtime=12.867s
>>  bench: maxrss=46608kB
>> 
>> Test results on HiSilicon Kirin 970:
>>Without SIMD:
>>  size=N/A time=00:10:00.00 bitrate=N/A speed=20.7x
>>  bench: utime=32.292s stime=1.032s rtime=28.963s
>>  bench: maxrss=42412kB
>>With SIMD:
>>  size=N/A time=00:10:00.00 bitrate=N/A speed=27.6x
>>  bench: utime=24.964s stime=0.952s rtime=21.703s
>>  bench: maxrss=42368kB
>> 
>> ---
>> libavfilter/aarch64/Makefile   |  2 ++
>> libavfilter/aarch64/af_afir_init.c | 31 +
>> libavfilter/aarch64/af_afir_neon.S | 43 ++
>> libavfilter/af_afir.c  |  2 ++
>> libavfilter/af_afir.h  |  1 +
>> 5 files changed, 79 insertions(+)
>> create mode 100644 libavfilter/aarch64/af_afir_init.c
>> create mode 100644 libavfilter/aarch64/af_afir_neon.S
>> 
>> diff --git a/libavfilter/aarch64/Makefile b/libavfilter/aarch64/Makefile
>> index b58daa3a3f..f52d7a4842 100644
>> --- a/libavfilter/aarch64/Makefile
>> +++ b/libavfilter/aarch64/Makefile
>> @@ -1,3 +1,5 @@
>> +OBJS-$(CONFIG_NLMEANS_FILTER)+= aarch64/af_afir_init.o
>> OBJS-$(CONFIG_NLMEANS_FILTER)+= aarch64/vf_nlmeans_init.o
>> 
>> +NEON-OBJS-$(CONFIG_NLMEANS_FILTER)   += aarch64/af_afir_neon.o
>> NEON-OBJS-$(CONFIG_NLMEANS_FILTER)   += aarch64/vf_nlmeans_neon.o
>> diff --git a/libavfilter/aarch64/af_afir_init.c
>> b/libavfilter/aarch64/af_afir_init.c
>> new file mode 100644
>> index 00..db06536380
>> --- /dev/null
>> +++ b/libavfilter/aarch64/af_afir_init.c
>> @@ -0,0 +1,31 @@
>> +/*
>> + * 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 "libavutil/aarch64/cpu.h"
>> +#include "libavfilter/af_afir.h"
>> +
>> +void ff_fcmul_add_neon(float *sum, const float *t, const float *c,
>> +  ptrdiff_t len);
>> +
>> +av_cold void ff_afir_init_aarch64(AudioFIRDSPContext *s)
>> +{
>> +int cpu_flags = av_get_cpu_flags();
>> +
>> +if (have_neon(cpu_flags))
>> +s->fcmul_add = ff_fcmul_add_neon;
>> +}
>> diff --git a/libavfilter/aarch64/af_afir_neon.S
>> b/libavfilter/aarch64/af_afir_neon.S
>> new file mode 100644
>> index 00..60583f9591
>> --- /dev/null
>> +++ b/libavfilter/aarch64/af_afir_neon.S
>> @@ -0,0 +1,43 @@
>> +/*
>> + * Copyright (c) 2020 Zhao Zhili
>> + *
>> + * 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 "libavutil/aarch64/asm.S"
>> +
>> +// void ff_fcmul_add_neon(float *sum, const float *t, const float *c,
>> ptrdiff_t len);
>> +function ff_fcmul_add_neon, export=1
>> +1:
>> +ld2 {v0.4S, v1.4S}, [x1], #32   // load t
>> +ld2 {v2.4S, v3.4S}, [x2], #32   // load c
>> +ld2 {v4.4S, v5.4S}, [x0]// load sum
>> +fmlav4.4S, v0.4S, v2.4S
>> +fmlsv4.4S, v1.4S, v3.4S
>> +f

Re: [FFmpeg-devel] [IMPORTANT] FOSDEM meeting

[James Darnley]

On 28/01/2020, Liu Steven  wrote:
>
>
>> 在 2020年1月27日，下午3:29，Jean-Baptiste Kempf  写道：
>> It will be joinable through some VideoConf tool.
> Can we join by IRC or other things on internet?
> Because these days are Spring Festival (Chinese New Year, Important
> festivals that have lasted for thousands of years),
> The more important reason is New infectious virus epidemic areas here. :(

Since I don't think it was said yet: yes, there will be participation
on IRC.  At the very least I plan to be there and will relay things
to<->from #ffmpeg-meeting on freenode.

Other people are responsible for other solutions.
___
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] [IMPORTANT] FOSDEM meeting

[Jean-Baptiste Kempf]

On Sat, 1 Feb 2020, at 11:32, James Darnley wrote:
> On 28/01/2020, Liu Steven  wrote:
> >> 在 2020年1月27日，下午3:29，Jean-Baptiste Kempf  写道：
> >> It will be joinable through some VideoConf tool.
> > Can we join by IRC or other things on internet?
> > Because these days are Spring Festival (Chinese New Year, Important
> > festivals that have lasted for thousands of years),
> > The more important reason is New infectious virus epidemic areas here. :(
> 
> Since I don't think it was said yet: yes, there will be participation
> on IRC.  At the very least I plan to be there and will relay things
> to<->from #ffmpeg-meeting on freenode.
> 
> Other people are responsible for other solutions.

Yes.

Room is H.3242 at 14.00

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
___
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] Unable to log into the bug tracker

[Michael Niedermayer]

On Thu, Jan 30, 2020 at 10:32:56PM +0100, Michael Niedermayer wrote:
> On Thu, Jan 30, 2020 at 08:07:36PM +0100, Alberto Salvia Novella wrote:
> > Screencast 
> 
> you succeeded in creating your account but it has no verified email address
> associated with it.
> check your spam folder for a email with a verify link maybe

looking at this a bit more today
i noticed that one of the DNS blacklists we use is broken and marks everyone
as spammer, ive removed that blacklist.

trying to create an account myself, it worked i got an email immedeatly once
i removed that blacklist and clicked on resend

also i saw that your account is now marked as "This address has been verified 
successfully."
not sure if you found the verify link or some other admin helped ...
but
you should be able to login or if you forgot your password get a password
reminder thingy sent now.
If it still doesnt work, just contact one of the admins or reply here

Thanks


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras


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] What new instructions would you like?

[James Darnley]

On 30/12/2019, Lauri Kasanen  wrote:
> Hi,
>
> For the Libre RISC-V project, I'm going to research the popular codecs
> and design new instructions to help speed them up. With ffmpeg being
> home to lots of asm folks for many platforms, I also want to ask your
> opinion.
>
> What new instructions would you like? Anything particular you find
> missing in existing ISAs, slow, or cumbersome?

Do you mean SIMD instructions?  I have no idea what exists in RISC-V
already or what capabilities or limitations it has, and I am going to
use x86 language and terms such as byte, word, dword, qword.

Things I have found missing in old(er) x86 instruction sets are
missing word size and signed/unsigned variants for existing
operations.  Some operations may have byte and word variants but dword
and qword might be missing, or there might be a signed version but not
an unsigned version (and vice versa).  A couple of things I had to
emulate:
* packed absolute value of dwords
* packed maximum unsigned words
* packed max and min signed dwords (I might have really wanted
unsigned for this)
* arithmetic right shift of qwords
* pack dwords to words with unsigned saturation

Shuffle instructions.  pshufb is very useful and I think I read on IRC
that arm/aarch64/neon does not have an equivalent.  (Or was that other
shuffles?)  It allows for arbitrary reordering of bytes and setting
bytes to 0.  On x86 it takes the shuffle pattern from another SIMD
register but I usually use it with a constant pattern that gets loaded
from memory.  An interesting improvement would be if you can encode 17
* 16 (or however long your vectors might be) values in an immediate
value so it doesn't require another register.

Good documentation.  The intel instruction manual has pretty good
explanation of what the instructions do.  The old instructions from
around the time of MMX and SSE had excellent diagrams, these might
have been mostly for shuffle operations.  I need to look and jog my
memory.  I think punpcklbw is an example of what I mean.  The entry in
the manual for it has a good diagram IMO.  (At least the version I am
currently looking at)

No stupid lane stuff.  AVX2 brought us a SIMD vector length extension
from 16 to 32 bytes.  Good except for the stupid lanes they were split
into making it hard to "mix" data from the low 0-15 bytes and the high
16-31 bytes.

I forgot about this email for a month.  Sorry about that.  Seeing
RISC-V in the schedule at FOSDEM reminded me about this.
___
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] af_volume: fix integer clip

[Michael Niedermayer]

On Sat, Feb 01, 2020 at 06:06:39PM +0800, zhilizhao wrote:
> 
> 
> > On Jan 27, 2020, at 6:28 PM, Zhao Zhili  wrote:
> > 
> > 
> > 
> >> On Jan 27, 2020, at 12:59 AM, Carl Eugen Hoyos  >> > wrote:
> >> 
> >> Am So., 26. Jan. 2020 um 17:13 Uhr schrieb Zhao Zhili 
> >> mailto:quinkbl...@foxmail.com>>:
> >>> 
> >>> ---
> >>> Or specify an upper limit on volume. What do you think?
> >>> 
> >>> libavfilter/af_volume.c | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>> 
> >>> diff --git a/libavfilter/af_volume.c b/libavfilter/af_volume.c
> >>> index 213c57195a..029925cbfb 100644
> >>> --- a/libavfilter/af_volume.c
> >>> +++ b/libavfilter/af_volume.c
> >>> @@ -200,7 +200,7 @@ static inline void scale_samples_s16(uint8_t *dst, 
> >>> const uint8_t *src,
> >>> int16_t *smp_dst   = (int16_t *)dst;
> >>> const int16_t *smp_src = (const int16_t *)src;
> >>> for (i = 0; i < nb_samples; i++)
> >>> -smp_dst[i] = av_clip_int16(((int64_t)smp_src[i] * volume + 128) 
> >>> >> 8);
> >>> +smp_dst[i] = (int16_t)av_clip64(((int64_t)smp_src[i] * volume + 
> >>> 128) >> 8, INT16_MIN, INT16_MAX);
> >> 
> >> The cast looks unnecessary and confusing but if a limit works, it is likely
> >> simpler imo.
> > 
> > The function is supposed to handle smp_src[i] * volume > INT32_MAX, so the 
> > cast is necessary.
> > 
> > case AV_SAMPLE_FMT_S16:
> > if (vol->volume_i < 0x1)
> > vol->scale_samples = scale_samples_s16_small;
> > else
> > vol->scale_samples = scale_samples_s16;
> > break;
> > 
> > I'm not sure about the use case. Does the function suppose to handle
> > (((int64_t)smp_src[i] * volume + 128) >> 8) > INT32_MAX?
> > 
> > By the way, there is another overflow in set_volume():
> > 
> > if (vol->precision == PRECISION_FIXED) {
> > vol->volume_i = (int)(vol->volume * 256 + 0.5);
> > vol->volume   = vol->volume_i / 256.0;
> > av_log(ctx, AV_LOG_VERBOSE, "volume_i:%d/255 ", vol->volume_i);
> > }
> 
> Ping. Any suggestions?

no but a question
for the 64bit clip to make a difference the volume needs to be increased by
like a factor of 65536. so everything will clip. Does this have a usecase ?
or maybe iam missing something ?

Thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Does the universe only have a finite lifespan? No, its going to go on
forever, its just that you wont like living in it. -- Hiranya Peiri


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] Vulkan hwcontext and filters

[Lynne]

Jan 21, 2020, 23:03 by s...@jkqxz.net:

> On 10/01/2020 21:05, Lynne wrote:
>
>> From 04c1836f89d89dcdc892cef66ee82afbcfda9f2d Mon Sep 17 00:00:00 2001
>> From: Lynne 
>> Date: Sun, 27 Oct 2019 14:44:00 +
>> Subject: [PATCH 4/9] lavfi: add Vulkan filtering framework
>>
>> This commit adds a Vulkan filtering infrastructure for libavfilter.
>> It attempts to abstract as much as possible of the Vulkan API from filters.
>>
>> The way the hwcontext and the framework are designed permits for parallel,
>> non-CPU-blocking filtering throughout, with the exception of up/downloading
>> and mapping.
>> ---
>>  configure   |3 +
>>  libavfilter/Makefile|2 +
>>  libavfilter/glslang.cpp |  215 +++
>>  libavfilter/glslang.h   |   49 ++
>>  libavfilter/vulkan.c| 1221 +++
>>  libavfilter/vulkan.h|  323 +++
>>  6 files changed, 1813 insertions(+)
>>  create mode 100644 libavfilter/glslang.cpp
>>  create mode 100644 libavfilter/glslang.h
>>  create mode 100644 libavfilter/vulkan.c
>>  create mode 100644 libavfilter/vulkan.h
>>
>> diff --git a/configure b/configure
>> index 3113ebfdd8..fc075f2a15 100755
>> --- a/configure
>> +++ b/configure
>> ...
>> @@ -6258,6 +6260,7 @@ enabled fontconfig&& enable libfontconfig
>>  enabled libfontconfig && require_pkg_config libfontconfig fontconfig 
>> "fontconfig/fontconfig.h" FcInit
>>  enabled libfreetype   && require_pkg_config libfreetype freetype2 
>> "ft2build.h FT_FREETYPE_H" FT_Init_FreeType
>>  enabled libfribidi&& require_pkg_config libfribidi fribidi 
>> fribidi.h fribidi_version_info
>> +enabled libglslang&& require_cpp libglslang 
>> glslang/SPIRV/GlslangToSpv.h "glslang::TIntermediate*" -lglslang 
>> -lOSDependent -lHLSL -lOGLCompiler -lSPVRemapper -lSPIRV -lSPIRV-Tools 
>> -lSPIRV-Tools-opt -lpthread -lstdc++
>>
>
> Using Debian-packaged glslang, the headers seem to be in slightly different 
> places: SPIRV headers in their own directory under include, so it is just 
> SPIRV/GlslangToSpv.h.  With the paths edited, the version in testing works.
>
> I don't whether there is a single official way which we should support, but 
> this looks like it could be an evil source of confusion.
>

glslang change the headers directory from just SPIRV to glslang/SPIRV. Debian's 
package already contains this, and so does arch, and I'd rather not have 
ifdeffery and additional header checks, so I'll keep it like this.



>> enabled libgme&& { check_pkg_config libgme libgme gme/gme.h 
>> gme_new_emu ||
>>  require libgme gme/gme.h gme_new_emu -lgme -lstdc++; }
>>  enabled libgsm&& { for gsm_hdr in "gsm.h" "gsm/gsm.h"; do
>> ...
>> diff --git a/libavfilter/glslang.cpp b/libavfilter/glslang.cpp
>> new file mode 100644
>> index 00..cf534d8ac5
>> --- /dev/null
>> +++ b/libavfilter/glslang.cpp
>> @@ -0,0 +1,215 @@
>> +/*
>> + * 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 
>> +
>> +extern "C" {
>> +#include "libavutil/mem.h"
>> +}
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>>
>
> (This path too.)
>
>> +
>> +#include "glslang.h"
>> +
>> +using namespace glslang;
>> +
>> +static pthread_mutex_t glslang_mutex = PTHREAD_MUTEX_INITIALIZER;
>> +static int glslang_refcount;
>> +
>> +int glslang_init(void)
>> +{
>> +int ret = 1;
>> +
>> +pthread_mutex_lock(&glslang_mutex);
>> +if (glslang_refcount++ == 0)
>> +ret = InitializeProcess();
>> +pthread_mutex_unlock(&glslang_mutex);
>> +
>> +return ret;
>>
>
> Inverting the normal sense of success is weird.
>

Fixed.



>> +}
>> +
>> +void glslang_uninit(void)
>> +{
>> +pthread_mutex_lock(&glslang_mutex);
>> +if (--glslang_refcount == 0)
>> +FinalizeProcess();
>> +if (glslang_refcount < 0)
>>
>
> Assert?  This looks like a "something has gone horribly wrong" case.
>

Fixed.



>> +glslang_refcount = 0;
>> +pthread_mutex_unlock(&glslang_mutex);
>> +}
>> +
>> +#define GLSL_VERSION EShTargetVulkan_1_0
>> +#define SPIRV_VERSION EShTargetSpv_1_0
>> +
>> +extern const TBuiltInResource DefaultTBuiltInResource;
>> +
>> +GLSlangResult *glslang_compile(cons

Re: [FFmpeg-devel] [PATCH] af_volume: fix integer clip

[zhilizhao]

> On Feb 1, 2020, at 8:00 PM, Michael Niedermayer  
> wrote:
> 
> On Sat, Feb 01, 2020 at 06:06:39PM +0800, zhilizhao wrote:
>> 
>> 
>>> On Jan 27, 2020, at 6:28 PM, Zhao Zhili  wrote:
>>> 
>>> 
>>> 
 On Jan 27, 2020, at 12:59 AM, Carl Eugen Hoyos >>> > wrote:
 
 Am So., 26. Jan. 2020 um 17:13 Uhr schrieb Zhao Zhili 
 mailto:quinkbl...@foxmail.com>>:
> 
> ---
> Or specify an upper limit on volume. What do you think?
> 
> libavfilter/af_volume.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavfilter/af_volume.c b/libavfilter/af_volume.c
> index 213c57195a..029925cbfb 100644
> --- a/libavfilter/af_volume.c
> +++ b/libavfilter/af_volume.c
> @@ -200,7 +200,7 @@ static inline void scale_samples_s16(uint8_t *dst, 
> const uint8_t *src,
>int16_t *smp_dst   = (int16_t *)dst;
>const int16_t *smp_src = (const int16_t *)src;
>for (i = 0; i < nb_samples; i++)
> -smp_dst[i] = av_clip_int16(((int64_t)smp_src[i] * volume + 128) 
> >> 8);
> +smp_dst[i] = (int16_t)av_clip64(((int64_t)smp_src[i] * volume + 
> 128) >> 8, INT16_MIN, INT16_MAX);
 
 The cast looks unnecessary and confusing but if a limit works, it is likely
 simpler imo.
>>> 
>>> The function is supposed to handle smp_src[i] * volume > INT32_MAX, so the 
>>> cast is necessary.
>>> 
>>>case AV_SAMPLE_FMT_S16:
>>>if (vol->volume_i < 0x1)
>>>vol->scale_samples = scale_samples_s16_small;
>>>else
>>>vol->scale_samples = scale_samples_s16;
>>>break;
>>> 
>>> I'm not sure about the use case. Does the function suppose to handle
>>> (((int64_t)smp_src[i] * volume + 128) >> 8) > INT32_MAX?
>>> 
>>> By the way, there is another overflow in set_volume():
>>> 
>>>if (vol->precision == PRECISION_FIXED) {
>>>vol->volume_i = (int)(vol->volume * 256 + 0.5);
>>>vol->volume   = vol->volume_i / 256.0;
>>>av_log(ctx, AV_LOG_VERBOSE, "volume_i:%d/255 ", vol->volume_i);
>>>}
>> 
>> Ping. Any suggestions?
> 
> no but a question
> for the 64bit clip to make a difference the volume needs to be increased by
> like a factor of 65536. so everything will clip. Does this have a usecase ?
> or maybe iam missing something ?

I’m wondering the usecase too. There are codes check volume_i against
(65536 * 256) explicitly (merged as b38c79bf232). Does support
change volume on the fly is the answer?

It’s really a corner case. I’m trying to figure it out before implement AArch64
SIMD.

case AV_SAMPLE_FMT_U8:
if (vol->volume_i < 0x100)
vol->scale_samples = scale_samples_u8_small;
else
vol->scale_samples = scale_samples_u8;
break;

> 
> Thanks
> 
> [...]
> 
> -- 
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> Does the universe only have a finite lifespan? No, its going to go on
> forever, its just that you wont like living in it. -- Hiranya Peiri
> ___
> 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] [PATCH] avfilter: add afirsrc filter

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi   |  38 +
 libavfilter/Makefile   |   1 +
 libavfilter/allfilters.c   |   1 +
 libavfilter/asrc_afirsrc.c | 330 +
 4 files changed, 370 insertions(+)
 create mode 100644 libavfilter/asrc_afirsrc.c

diff --git a/doc/filters.texi b/doc/filters.texi
index a3cc92200d..7081e1c0dc 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -5857,6 +5857,44 @@ aevalsrc="0.1*sin(2*PI*(360-2.5/2)*t) | 
0.1*sin(2*PI*(360+2.5/2)*t)"
 
 @end itemize
 
+@section afirsrc
+
+Generate a FIR coefficients using frequency sampling method.
+
+The resulting stream can be used with @ref{afir} filter for filtering the 
audio signal.
+
+The filter accepts the following options:
+
+@table @option
+@item taps, t
+Set number of filter coefficents in output audio stream.
+Default value is 1025.
+
+@item frequency, f
+Set frequency points from where magnitude and phase are set.
+This must be in non decreasing order, and first element must be 0, while last 
element
+must be 1. Elements are separated by white spaces.
+
+@item magnitude, m
+Set magnitude value for every frequency point set by @option{frequency}.
+Number of values must be same as number of frequency points.
+Values are separated by white spaces.
+
+@item phase, p
+Set phase value for every frequency point set by @option{frequency}.
+Number of values must be same as number of frequency points.
+Values are separated by white spaces.
+
+@item sample_rate, r
+Set sample rate, default is 44100.
+
+@item nb_samples, n
+Set number of samples per each frame. Default is 1024.
+
+@item win_func, w
+Set window function. Default is blackman.
+@end table
+
 @section anullsrc
 
 The null audio source, return unprocessed audio frames. It is mainly useful
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 72804323d5..55898e3b5d 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -144,6 +144,7 @@ OBJS-$(CONFIG_VOLUME_FILTER) += af_volume.o
 OBJS-$(CONFIG_VOLUMEDETECT_FILTER)   += af_volumedetect.o
 
 OBJS-$(CONFIG_AEVALSRC_FILTER)   += aeval.o
+OBJS-$(CONFIG_AFIRSRC_FILTER)+= asrc_afirsrc.o
 OBJS-$(CONFIG_ANOISESRC_FILTER)  += asrc_anoisesrc.o
 OBJS-$(CONFIG_ANULLSRC_FILTER)   += asrc_anullsrc.o
 OBJS-$(CONFIG_FLITE_FILTER)  += asrc_flite.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index f7ab2def92..e31a958f40 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -137,6 +137,7 @@ extern AVFilter ff_af_volume;
 extern AVFilter ff_af_volumedetect;
 
 extern AVFilter ff_asrc_aevalsrc;
+extern AVFilter ff_asrc_afirsrc;
 extern AVFilter ff_asrc_anoisesrc;
 extern AVFilter ff_asrc_anullsrc;
 extern AVFilter ff_asrc_flite;
diff --git a/libavfilter/asrc_afirsrc.c b/libavfilter/asrc_afirsrc.c
new file mode 100644
index 00..b90ffad57f
--- /dev/null
+++ b/libavfilter/asrc_afirsrc.c
@@ -0,0 +1,330 @@
+/*
+ * Copyright (c) 2020 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 "libavutil/eval.h"
+#include "libavutil/opt.h"
+#include "libavutil/tx.h"
+#include "audio.h"
+#include "avfilter.h"
+#include "internal.h"
+#include "window_func.h"
+
+typedef struct AudioFIRSourceContext {
+const AVClass *class;
+
+char *freq_points_str;
+char *magnitude_str;
+char *phase_str;
+int nb_taps;
+int sample_rate;
+int nb_samples;
+int win_func;
+
+AVComplexFloat *complexf;
+float *freq;
+float *magnitude;
+float *phase;
+int freq_size;
+int magnitude_size;
+int phase_size;
+int nb_freq;
+int nb_magnitude;
+int nb_phase;
+
+float *taps;
+float *win;
+int64_t pts;
+
+AVTXContext *tx_ctx;
+av_tx_fn tx_fn;
+} AudioFIRSourceContext;
+
+#define OFFSET(x) offsetof(AudioFIRSourceContext, x)
+#define FLAGS AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
+
+static const AVOption afirsrc_options[] = {
+{ "taps",  "set number of taps",   OFFSET(nb_taps), 
AV_OPT_TYPE_INT,{.i64=1025}, 9, UINT16_MAX, FLAGS },
+{ "t", "set number of taps",   OFFSET(nb_taps), 
AV_OPT_TYPE_INT,{.i64=1025}, 9, UI

Re: [FFmpeg-devel] [PATCH] avfilter: add xfade opencl filter

[Mark Thompson]

On 26/01/2020 18:28, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  configure |   1 +
>  doc/filters.texi  |  97 
>  libavfilter/Makefile  |   1 +
>  libavfilter/allfilters.c  |   1 +
>  libavfilter/opencl/xfade.cl   | 136 +++
>  libavfilter/opencl_source.h   |   1 +
>  libavfilter/vf_xfade_opencl.c | 420 ++
>  7 files changed, 657 insertions(+)
>  create mode 100644 libavfilter/opencl/xfade.cl
>  create mode 100644 libavfilter/vf_xfade_opencl.c
> 
> ...
> +
> +void slide(__write_only image2d_t dst,
> +   __read_only  image2d_t src1,
> +   __read_only  image2d_t src2,
> +   float progress,
> +   int2 direction)
> +{
> +const sampler_t sampler = (CLK_NORMALIZED_COORDS_FALSE |  \
> +   CLK_FILTER_NEAREST);

From the Mali driver:

:87:21: error: non-kernel function variable cannot be declared in 
constant address space
const sampler_t sampler = (CLK_NORMALIZED_COORDS_FALSE |  \
^

error: Compiler frontend failed (error code 60)

OpenCL 1.2 §6.9:

"The sampler type (sampler_t) can only be used as the type of a function 
argument or a
variable declared in the program scope or the outermost scope of a kernel 
function."

I think just make it global, since you're now using the same sampler in every 
kernel?

> +int   w = get_image_dim(src1).x;
> +int   h = get_image_dim(src1).y;
> +int2 wh = (int2)(w, h);
> +int2 uv = (int2)(get_global_id(0), get_global_id(1));
> +int2 pi = (int2)(progress * w, progress * h);
> +int2 p = uv + pi * direction;
> +int2 f = p % wh;
> +
> +f = f + (int2)(w, h) * (int2)(f.x < 0, f.y < 0);
> +float4 val1 = read_imagef(src1, sampler, f);
> +float4 val2 = read_imagef(src2, sampler, f);
> +write_imagef(dst, uv, mix(val1, val2, (p.y >= 0) * (h > p.y) * (p.x >= 
> 0) * (w > p.x)));
> +}
> +
> ...
> +
> +AVFilter ff_vf_xfade_opencl = {
> +.name= "xfade_opencl",
> +.description = NULL_IF_CONFIG_SMALL("Cross fade one video with 
> another video."),
> +.priv_size   = sizeof(XFadeOpenCLContext),
> +.priv_class  = &xfade_opencl_class,
> +.init= &ff_opencl_filter_init,
> +.uninit  = &xfade_opencl_uninit,
> +.query_formats   = &ff_opencl_filter_query_formats,
> +.activate= &xfade_opencl_activate,
> +.inputs  = xfade_opencl_inputs,
> +.outputs = xfade_opencl_outputs,
> +.flags_internal  = FF_FILTER_FLAG_HWFRAME_AWARE,
> +};
> 

No other comments from me, so LGTM with that fixed.

Thanks,

- Mark
___
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 001/244] Add a new channel layout API

[Nicolas George]

Anton Khirnov (12020-01-28):
> That makes no sense. The filter cannot "have needs" when the current API
> does not support the use case you have in mind (which is good). The
> filter can either be modified to allow multiple inputs or a new filter
> can be added.

It makes perfect sense: I know what I planned when I wrote them, and the
plan was always that when we would replace the channel layout API, it
would be able to express duplicated channels. And we will not demand
users to learn new filters for that.

You can continue to disregard my arguments, and getting close to being
insulting while you are at it, but you will not get me to change my mind
like that. The API, as it is, is rejected. Either we design a good API,
one that can satisfy the needs you see and the needs I see, or we keep
the current, very simple, API. No half-measure that brings all the
drawbacks and almost no benefit.

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] lavc/h265_profile_level: Fix the default profile in ff_h265_guess_level

[Mark Thompson]

On 15/01/2020 06:54, Linjie Fu wrote:
> Default to use multiplication factors for Main profile.
> 
> Introduced since cd3578a8e4e11e0ba021e621367a7974d6de5da0.
> 
> Fixed the notation at the same time.
> 
> Signed-off-by: Linjie Fu 
> ---
>  libavcodec/h265_profile_level.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/h265_profile_level.c b/libavcodec/h265_profile_level.c
> index 70db1a5..a5347f6 100644
> --- a/libavcodec/h265_profile_level.c
> +++ b/libavcodec/h265_profile_level.c
> @@ -187,8 +187,8 @@ const H265LevelDescriptor *ff_h265_guess_level(const 
> H265RawProfileTierLevel *pt
>  else
>  profile = NULL;
>  if (!profile) {
> -// Default to using multiplication factors for Main profile.
> -profile = &h265_profiles[3];
> +// Default to use multiplication factors for Main profile.
> +profile = &h265_profiles[4];
>  }
>  
>  pic_size = width * height;
> 

Oops, yeah.  Applied.

Thanks,

- Mark
___
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] lavu/hwcontext_vaapi: cope with race map for YUV420P

[Mark Thompson]

On 15/01/2020 06:55, Linjie Fu wrote:
> There is a race condition for AV_PIX_FMT_YUV420P when mapping from pix_fmt
> to fourcc, both VA_FOURCC_I420 and VA_FOURCC_YV12 could be found by pix_fmt.

The title and this comment are very confusing.  As far as I can see this has 
nothing to do with a race condition, since only one thread is ever involved.

> Currently, vaapi_get_image_format will go through the query results of
> pix_fmt and returned the first matched result according to the declared
> order in driver.This may leads to a wrong image_format.
> 
> Modify to find image_format via fourcc.
> 
> Fix vaapi CSC to I420:
> ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -f rawvideo
> -pix_fmt nv12 -s:v 1280x720 -i NV12.yuv -vf
> 'format=nv12,hwupload,scale_vaapi=format=yuv420p,hwdownload,format=yuv420p'
> -f rawvideo -vsync passthrough -vframes 10 -y aa.yuv
> 
> Reviewed-by: Zhong Li 
> Signed-off-by: Linjie Fu 
> ---
>  libavutil/hwcontext_vaapi.c | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> index cd215a0..199f425 100644
> --- a/libavutil/hwcontext_vaapi.c
> +++ b/libavutil/hwcontext_vaapi.c
> @@ -63,6 +63,7 @@ typedef struct VAAPIDevicePriv {
>  typedef struct VAAPISurfaceFormat {
>  enum AVPixelFormat pix_fmt;
>  VAImageFormat image_format;
> +uint32_t fourcc;
>  } VAAPISurfaceFormat;
>  
>  typedef struct VAAPIDeviceContext {
> @@ -178,15 +179,21 @@ static int vaapi_get_image_format(AVHWDeviceContext 
> *hwdev,
>VAImageFormat **image_format)
>  {
>  VAAPIDeviceContext *ctx = hwdev->internal->priv;
> +VAAPIFormatDescriptor *desc;
>  int i;
>  
> +desc = vaapi_format_from_pix_fmt(pix_fmt);

This would now only find the first entry in the map, so YV12 and YV16 could 
never work, nor could the IYUV alias for old drivers.

The point of this function is that it finds the first matching format supported 
by the driver being used, but I can see that that goes wrong when a driver 
declares support for the same format under multiple different names which are 
not interchangable.

What conflicting formats are actually being advertised in the broken case?

> +if (!desc || !image_format)
> +goto fail;
> +
>  for (i = 0; i < ctx->nb_formats; i++) {
> -if (ctx->formats[i].pix_fmt == pix_fmt) {
> -if (image_format)
> -*image_format = &ctx->formats[i].image_format;
> +if (ctx->formats[i].fourcc == desc->fourcc) {
> +*image_format = &ctx->formats[i].image_format;
>  return 0;
>  }
>  }
> +
> +fail:
>  return AVERROR(EINVAL);
>  }
>  
> @@ -375,6 +382,7 @@ static int vaapi_device_init(AVHWDeviceContext *hwdev)
>  av_log(hwdev, AV_LOG_DEBUG, "Format %#x -> %s.\n",
> fourcc, av_get_pix_fmt_name(pix_fmt));
>  ctx->formats[ctx->nb_formats].pix_fmt  = pix_fmt;
> +ctx->formats[ctx->nb_formats].fourcc   = fourcc;
>  ctx->formats[ctx->nb_formats].image_format = image_list[i];
>  ++ctx->nb_formats;
>  }
> 

Thanks,

- Mark
___
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 001/244] Add a new channel layout API

[Paul B Mahol]

On 2/1/20, Nicolas George  wrote:
> Anton Khirnov (12020-01-28):
>> That makes no sense. The filter cannot "have needs" when the current API
>> does not support the use case you have in mind (which is good). The
>> filter can either be modified to allow multiple inputs or a new filter
>> can be added.
>
> It makes perfect sense: I know what I planned when I wrote them, and the
> plan was always that when we would replace the channel layout API, it
> would be able to express duplicated channels. And we will not demand
> users to learn new filters for that.
>
> You can continue to disregard my arguments, and getting close to being
> insulting while you are at it, but you will not get me to change my mind
> like that. The API, as it is, is rejected. Either we design a good API,
> one that can satisfy the needs you see and the needs I see, or we keep
> the current, very simple, API. No half-measure that brings all the
> drawbacks and almost no benefit.

Why you think you are not insulting other developers by your way of
expressing your side of view.

Very short sighted reasoning.
___
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] fftools/ffmpeg_filter: add -autoscale to disable/enable the default scale

[Mark Thompson]

On 15/01/2020 07:05, Linjie Fu wrote:
> Currently, ffmpeg inserts scale filter by default in the filter graph
> to force the whole decoded stream to scale into the same size with the
> first frame. It's not quite make sense in resolution changing cases if
> user wants the rawvideo without any scale.
> 
> Using autoscale/noautoscale to indicate whether auto inserting the scale
> filter in the filter graph:
> -noautoscale or -autoscale 0:
> disable the default auto scale filter inserting.
> 
> Update docs.
> 
> Signed-off-by: U. Artie Eoff 
> Signed-off-by: Linjie Fu 
> ---
>  doc/ffmpeg.texi | 16 
>  fftools/ffmpeg.c|  1 +
>  fftools/ffmpeg.h|  4 
>  fftools/ffmpeg_filter.c |  2 +-
>  fftools/ffmpeg_opt.c|  8 
>  5 files changed, 26 insertions(+), 5 deletions(-)
> 
> diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> index dd461c0..716dd2c 100644
> --- a/doc/ffmpeg.texi
> +++ b/doc/ffmpeg.texi
> @@ -734,10 +734,6 @@ ffmpeg -dump_attachment:t "" -i INPUT
>  Technical note -- attachments are implemented as codec extradata, so this
>  option can actually be used to extract extradata from any stream, not just
>  attachments.
> -
> -@item -noautorotate
> -Disable automatically rotating video based on file metadata.
> -
>  @end table
>  
>  @section Video Options
> @@ -819,6 +815,18 @@ Create the filtergraph specified by @var{filtergraph} 
> and use it to
>  filter the stream.
>  
>  This is an alias for @code{-filter:v}, see the @ref{filter_option,,-filter 
> option}.
> +
> +@item -autorotate
> +Automatically rotate the video according to file metadata. Enabled by
> +default, use @option{-noautorotate} to disable it.
> +
> +@item -autoscale
> +Automatically scale the video according to the resolution of first frame.
> +Enabled by default, use @option{-noautoscale} to disable it. When autoscale 
> is
> +disabled, all output frames of filter graph might not be in the same 
> resolution
> +and may be inadequate for some encoder/muxer. Therefore, it is not 
> recommended
> +to disable it unless you really know what you are doing.
> +Disable autoscale at your own risk.
>  @end table
>  
>  @section Advanced Video options
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index 6bcd7b9..864c1fb 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -2125,6 +2125,7 @@ static int ifilter_send_frame(InputFilter *ifilter, 
> AVFrame *frame)
>  
>  /* determine if the parameters for this input changed */
>  need_reinit = ifilter->format != frame->format;
> +fg->autoscale = ifilter->ist->autoscale;
>  
>  switch (ifilter->ist->st->codecpar->codec_type) {
>  case AVMEDIA_TYPE_AUDIO:
> diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
> index 7b6f802..1602406 100644
> --- a/fftools/ffmpeg.h
> +++ b/fftools/ffmpeg.h
> @@ -133,6 +133,8 @@ typedef struct OptionsContext {
>  intnb_hwaccel_output_formats;
>  SpecifierOpt *autorotate;
>  intnb_autorotate;
> +SpecifierOpt *autoscale;
> +intnb_autoscale;
>  
>  /* output options */
>  StreamMap *stream_maps;
> @@ -285,6 +287,7 @@ typedef struct FilterGraph {
>  
>  AVFilterGraph *graph;
>  int reconfiguration;
> +int autoscale;
>  
>  InputFilter   **inputs;
>  int  nb_inputs;
> @@ -335,6 +338,7 @@ typedef struct InputStream {
>  int guess_layout_max;
>  
>  int autorotate;
> +int autoscale;
>  
>  int fix_sub_duration;
>  struct { /* previous decoded subtitle and related variables */
> diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
> index 40cc4c1..dafcab7 100644
> --- a/fftools/ffmpeg_filter.c
> +++ b/fftools/ffmpeg_filter.c
> @@ -469,7 +469,7 @@ static int configure_output_video_filter(FilterGraph *fg, 
> OutputFilter *ofilter,
>  if (ret < 0)
>  return ret;
>  
> -if (ofilter->width || ofilter->height) {
> +if ((ofilter->width || ofilter->height) && fg->autoscale) {
>  char args[255];
>  AVFilterContext *filter;
>  AVDictionaryEntry *e = NULL;
> diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
> index 1510e02..37083f2 100644
> --- a/fftools/ffmpeg_opt.c
> +++ b/fftools/ffmpeg_opt.c
> @@ -743,7 +743,9 @@ static void add_input_streams(OptionsContext *o, 
> AVFormatContext *ic)
>  MATCH_PER_STREAM_OPT(ts_scale, dbl, ist->ts_scale, ic, st);
>  
>  ist->autorotate = 1;
> +ist->autoscale  = 1;
>  MATCH_PER_STREAM_OPT(autorotate, i, ist->autorotate, ic, st);
> +MATCH_PER_STREAM_OPT(autoscale, i, ist->autoscale, ic, st);
>  
>  MATCH_PER_STREAM_OPT(codec_tags, str, codec_tag, ic, st);
>  if (codec_tag) {
> @@ -3650,6 +3652,12 @@ const OptionDef options[] = {
>  { "autorotate",   HAS_ARG | OPT_BOOL | OPT_SPEC |
>OPT_EXPERT | OPT_INPUT,
> { .off = OFFSET(autorotate) },
>  "automatically insert correct rotat

Re: [FFmpeg-devel] [PATCH 1/2] libavcodec/amfenc_hevc.c: Fix constant QP settings for I, P

[Mark Thompson]

On 28/01/2020 16:23, OvchinnikovDmitrii wrote:
> ---
>  libavcodec/amfenc_hevc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/amfenc_hevc.c b/libavcodec/amfenc_hevc.c
> index 7c9a33ab33..8b4d289fac 100644
> --- a/libavcodec/amfenc_hevc.c
> +++ b/libavcodec/amfenc_hevc.c
> @@ -254,10 +254,10 @@ static av_cold int amf_encode_init_hevc(AVCodecContext 
> *avctx)
>  }
>  
>  if (ctx->qp_p != -1) {
> -AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder, 
> AMF_VIDEO_ENCODER_HEVC_QP_I, ctx->qp_p);
> +AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder, 
> AMF_VIDEO_ENCODER_HEVC_QP_P, ctx->qp_p);
>  }
>  if (ctx->qp_i != -1) {
> -AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder, 
> AMF_VIDEO_ENCODER_HEVC_QP_P, ctx->qp_i);
> +AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder, 
> AMF_VIDEO_ENCODER_HEVC_QP_I, ctx->qp_i);
>  }
>  AMF_ASSIGN_PROPERTY_BOOL(res, ctx->encoder, 
> AMF_VIDEO_ENCODER_HEVC_RATE_CONTROL_SKIP_FRAME_ENABLE, ctx->skip_frame);
>  
> 

Yep, applied.

Thanks,

- Mark
___
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] libavcodec/amfenc_hevc.c: Fix Profile level option on AMF HEVC.

[Mark Thompson]

On 28/01/2020 16:23, OvchinnikovDmitrii wrote:
> Patch was made by Sitan Liu 

If you are not the author then please ensure that the git author field is 
filled correctly.

> The same code already exists in amfenc_h264.c
> ---
>  libavcodec/amfenc_hevc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/amfenc_hevc.c b/libavcodec/amfenc_hevc.c
> index 8b4d289fac..77e57d2461 100644
> --- a/libavcodec/amfenc_hevc.c
> +++ b/libavcodec/amfenc_hevc.c
> @@ -136,7 +136,7 @@ static av_cold int amf_encode_init_hevc(AVCodecContext 
> *avctx)
>  AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder, 
> AMF_VIDEO_ENCODER_HEVC_TIER, ctx->tier);
>  
>  profile_level = avctx->level;
> -if (profile_level == 0) {
> +if (profile_level == FF_LEVEL_UNKNOWN) {

This looks right.

>  profile_level = ctx->level;
>  }
>  if (profile_level != 0) {
> @@ -144,7 +144,7 @@ static av_cold int amf_encode_init_hevc(AVCodecContext 
> *avctx)
>  }
>  AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder, 
> AMF_VIDEO_ENCODER_HEVC_QUALITY_PRESET, ctx->quality);
>  // Maximum Reference Frames
> -if (avctx->refs != 0) {
> +if (avctx->refs != -1) {

This looks unrelated?

>  AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder, 
> AMF_VIDEO_ENCODER_HEVC_MAX_NUM_REFRAMES, avctx->refs);
>  }
>  // Aspect Ratio
> 

Thanks,

- Mark
___
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] fate/filter-video.mak: do not use bit-exact check for dnn_processing

[Guo, Yejun]

> -Original Message-
> From: Guo, Yejun
> Sent: Wednesday, January 22, 2020 9:45 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Guo, Yejun 
> Subject: [PATCH V2] fate/filter-video.mak: do not use bit-exact check for
> dnn_processing
> 
> The reason is that the tested models are in float format. And also
> remove fate-filter-dnn_processing-halve_gray_float to make reference
> files smaller.
> 
> Signed-off-by: Guo, Yejun 
> ---
>  tests/fate/filter-video.mak|  7 +--
>  ...filter-dnn_processing-halve_first_channel_float | 55 
> --
>  .../fate/filter-dnn_processing-halve_gray_float| 55 
> --
>  3 files changed, 4 insertions(+), 113 deletions(-)
>  delete mode 100644
> tests/ref/fate/filter-dnn_processing-halve_first_channel_float
>  delete mode 100644 tests/ref/fate/filter-dnn_processing-halve_gray_float
> 
> diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
> index 02986b5..6e744b5 100644
> --- a/tests/fate/filter-video.mak
> +++ b/tests/fate/filter-video.mak

I set up windows environment today with msys2 and configure with "--arch=x86_64 
--target-os=mingw64",
this test also passed.  So, this fate passed on x86 + linux/windows, and IMB 
PowerPC + linux.

has not got an arm-based system yet.

Just checked the master and found the original patch is reverted. I'm ok for 
it, but think it is still valuable to update the status.
___
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] lavc/qsv: adding DX11 support

[Mark Thompson]

On 24/01/2020 19:37, Artem Galin wrote:
> On Fri, 24 Jan 2020 at 00:46, Mark Thompson  wrote:
> 
>> On 23/01/2020 15:18, Artem Galin wrote:
>>> This enables DX11 support for QSV with higher priority than DX9.
>>> In case of multiple GPUs configuration, DX9 API does not allow to get
>>> access to QSV device in some cases - headless.
>>> Implementation based on DX11 resolves that restriction by enumerating
>> list of available GPUs and finding device with QSV support.
>>>
>>> Signed-off-by: Artem Galin 
>>> ---
>>>  libavcodec/qsv.c  |  38 
>>>  libavcodec/qsv_internal.h |   5 +
>>>  libavcodec/version.h  |   2 +-
>>>  libavfilter/qsvvpp.c  |  19 +---
>>>  libavutil/hwcontext_d3d11va.c |  57 +++-
>>>  libavutil/hwcontext_qsv.c | 169 +-
>>>  libavutil/hwcontext_qsv.h |  13 ++-
>>>  libavutil/version.h   |   2 +-
>>>  8 files changed, 242 insertions(+), 63 deletions(-)
>>
>> This should be split into separate commits for the three libraries you
>> touch.
>>
>> These changes are logically one piece of code and do not work
> independently.

I don't understand what you mean by this comment.  libavutil does not depend on 
the other libraries, and incompatible changes to libavutil are not allowed.

>> ...
>>>
>>> +static int d3d11va_device_find_qsv_adapter(AVHWDeviceContext *ctx, UINT
>> creationFlags)
>>> +{
>>> +HRESULT hr;
>>> +IDXGIAdapter *adapter = NULL;
>>> +int adapter_id = 0;
>>> +int vendor_id = 0x8086;
>>> +IDXGIFactory2 *factory;
>>> +hr = mCreateDXGIFactory(&IID_IDXGIFactory2, (void **)&factory);
>>> +while (IDXGIFactory2_EnumAdapters(factory, adapter_id++, &adapter)
>> != DXGI_ERROR_NOT_FOUND)
>>> +{
>>> +ID3D11Device* device = NULL;
>>> +DXGI_ADAPTER_DESC adapter_desc;
>>> +
>>> +hr = mD3D11CreateDevice(adapter, D3D_DRIVER_TYPE_UNKNOWN, NULL,
>> creationFlags, NULL, 0, D3D11_SDK_VERSION, &device, NULL, NULL);
>>> +if (FAILED(hr)) {
>>> +av_log(ctx, AV_LOG_ERROR, "D3D11CreateDevice returned
>> error\n");
>>> +continue;
>>> +}
>>> +
>>> +hr = IDXGIAdapter2_GetDesc(adapter, &adapter_desc);
>>> +if (FAILED(hr)) {
>>> +av_log(ctx, AV_LOG_ERROR, "IDXGIAdapter2_GetDesc returned
>> error\n");
>>> +continue;
>>> +}
>>> +
>>> +if(device)
>>> +ID3D11Device_Release(device);
>>> +
>>> +if (adapter)
>>> +IDXGIAdapter_Release(adapter);
>>> +
>>> +if (adapter_desc.VendorId == vendor_id) {
>>> +IDXGIFactory2_Release(factory);
>>> +return adapter_id - 1;
>>> +}
>>> +}
>>> +IDXGIFactory2_Release(factory);
>>> +return -1;
>>> +}
>>> +
>>>  static int d3d11va_device_create(AVHWDeviceContext *ctx, const char
>> *device,
>>>   AVDictionary *opts, int flags)
>>>  {
>>> @@ -519,7 +559,9 @@ static int d3d11va_device_create(AVHWDeviceContext
>> *ctx, const char *device,
>>>  IDXGIAdapter   *pAdapter = NULL;
>>>  ID3D10Multithread  *pMultithread;
>>>  UINT creationFlags = D3D11_CREATE_DEVICE_VIDEO_SUPPORT;
>>> +int adapter = -1;
>>>  int is_debug   = !!av_dict_get(opts, "debug", NULL, 0);
>>> +int is_qsv = !!av_dict_get(opts, "d3d11va_qsv", NULL, 0);
>>
>> The only constraint you actually check here is the vendor ID, right?  I
>> think it would make more sense to add code which goes looking for a device
>> given the vendor ID rather than hard-coding a special function doing this
>> specific case in here - compare with how VAAPI does exactly the same thing.
>>
>> Agree to change interface to support given vendor id.
> 
> 
>> (That is, make "ffmpeg -init_hw_device d3d11va=,vendor=0x8086" do what
>> you  would expect rather than hacking in a special libmfx case here.)
>>
> 
> Agree that your proposal to have option to choose vendor by given vendor id
> via command line is nice to have optionally and could be added later. This
> patch is about enabling DX11 for qsv at the moment.

The point of adding the option is then to use it in the libmfx code rather than 
dumping ad-hoc libmfx code in the D3D11 file.

>>> ...
>>> +#endif
>>>  #if CONFIG_DXVA2
>>>  { MFX_HANDLE_D3D9_DEVICE_MANAGER, AV_HWDEVICE_TYPE_DXVA2,
>> AV_PIX_FMT_DXVA2_VLD },
>>>  #endif
>>> @@ -124,18 +131,21 @@ static int qsv_device_init(AVHWDeviceContext *ctx)
>>>  int i;
>>>
>>>  for (i = 0; supported_handle_types[i].handle_type; i++) {
>>> -err = MFXVideoCORE_GetHandle(hwctx->session,
>> supported_handle_types[i].handle_type,
>>> - &s->handle);
>>> -if (err == MFX_ERR_NONE) {
>>> -s->handle_type   =
>> supported_handle_types[i].handle_type;
>>> -s->child_device_type =
>> supported_handle_types[i].device_type;
>>> -s->child_pix_fmt = supported_handle_types[i

[FFmpeg-devel] [PLEASE IGNORE] [PATCH] avfilter: add xfade opencl filter

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 configure |   1 +
 doc/filters.texi  |  97 
 libavfilter/Makefile  |   1 +
 libavfilter/allfilters.c  |   1 +
 libavfilter/opencl/xfade.cl   | 145 +++
 libavfilter/opencl_source.h   |   1 +
 libavfilter/vf_xfade_opencl.c | 440 ++
 7 files changed, 686 insertions(+)
 create mode 100644 libavfilter/opencl/xfade.cl
 create mode 100644 libavfilter/vf_xfade_opencl.c

diff --git a/configure b/configure
index c02dbcc8b2..fbb1a86511 100755
--- a/configure
+++ b/configure
@@ -3596,6 +3596,7 @@ zscale_filter_deps="libzimg const_nan"
 scale_vaapi_filter_deps="vaapi"
 vpp_qsv_filter_deps="libmfx"
 vpp_qsv_filter_select="qsvvpp"
+xfade_opencl_filter_deps="opencl"
 yadif_cuda_filter_deps="ffnvcodec"
 yadif_cuda_filter_deps_any="cuda_nvcc cuda_llvm"
 
diff --git a/doc/filters.texi b/doc/filters.texi
index a3cc92200d..ad2ae681cb 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -21443,6 +21443,103 @@ Apply a strong blur of both luma and chroma 
parameters:
 @end example
 @end itemize
 
+@section xfade_opencl
+
+Cross fade two videos with custom transition effect by using OpenCL.
+
+It accepts the following options:
+
+@table @option
+@item transition
+Set one of possible transition effects.
+
+@table @option
+@item custom
+Select custom transition effect, the actual transition description
+will be picked from source and kernel options.
+
+@item fade
+@item wipeleft
+@item wiperight
+@item wipeup
+@item wipedown
+@item slideleft
+@item slideright
+@item slideup
+@item slidedown
+
+Default transition is fade.
+@end table
+
+@item source
+OpenCL program source file for custom transition.
+
+@item kernel
+Set name of kernel to use for custom transition from program source file.
+
+@item duration
+Set duration of video transition.
+
+@item offset
+Set time of start of transition relative to first video.
+@end table
+
+The program source file must contain a kernel function with the given name,
+which will be run once for each plane of the output.  Each run on a plane
+gets enqueued as a separate 2D global NDRange with one work-item for each
+pixel to be generated.  The global ID offset for each work-item is therefore
+the coordinates of a pixel in the destination image.
+
+The kernel function needs to take the following arguments:
+@itemize
+@item
+Destination image, @var{__write_only image2d_t}.
+
+This image will become the output; the kernel should write all of it.
+
+@item
+First Source image, @var{__read_only image2d_t}.
+Second Source image, @var{__read_only image2d_t}.
+
+These are the most recent images on each input.  The kernel may read from
+them to generate the output, but they can't be written to.
+
+@item
+Transition progress, @var{float}. This value is always between 0 and 1 
inclusive.
+@end itemize
+
+Example programs:
+
+@itemize
+@item
+Apply dots curtain transition effect:
+@verbatim
+__kernel void blend_images(__write_only image2d_t dst,
+   __read_only  image2d_t src1,
+   __read_only  image2d_t src2,
+   float progress)
+{
+const sampler_t sampler = (CLK_NORMALIZED_COORDS_FALSE |
+   CLK_FILTER_LINEAR);
+int2  p = (int2)(get_global_id(0), get_global_id(1));
+float2 rp = (float2)(get_global_id(0), get_global_id(1));
+float2 dim = (float2)(get_image_dim(src1).x, get_image_dim(src1).y);
+rp = rp / dim;
+
+float2 dots = (float2)(20.0, 20.0);
+float2 center = (float2)(0,0);
+float2 unused;
+
+float4 val1 = read_imagef(src1, sampler, p);
+float4 val2 = read_imagef(src2, sampler, p);
+bool next = distance(fract(rp * dots, &unused), (float2)(0.5, 0.5)) < 
(progress / distance(rp, center));
+
+write_imagef(dst, p, next ? val1 : val2);
+}
+@end verbatim
+
+@end itemize
+
 @c man end OPENCL VIDEO FILTERS
 
 @chapter VAAPI Video Filters
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 72804323d5..ead47c2855 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -442,6 +442,7 @@ OBJS-$(CONFIG_WAVEFORM_FILTER)   += 
vf_waveform.o
 OBJS-$(CONFIG_WEAVE_FILTER)  += vf_weave.o
 OBJS-$(CONFIG_XBR_FILTER)+= vf_xbr.o
 OBJS-$(CONFIG_XFADE_FILTER)  += vf_xfade.o
+OBJS-$(CONFIG_XFADE_OPENCL_FILTER)   += vf_xfade_opencl.o opencl.o 
opencl/xfade.o
 OBJS-$(CONFIG_XMEDIAN_FILTER)+= vf_xmedian.o framesync.o
 OBJS-$(CONFIG_XSTACK_FILTER) += vf_stack.o framesync.o
 OBJS-$(CONFIG_YADIF_FILTER)  += vf_yadif.o yadif_common.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index f7ab2def92..5fd93c43ed 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -421,6 +421,7 @@ extern AVFilter ff_vf_waveform;
 extern AVFilter ff_vf_weave;
 extern AVFilter ff_vf_xbr;
 extern AVFilter ff_vf_xfade;
+

Re: [FFmpeg-devel] [PATCH] avcodec/binkaudio: Check sample_rate to avoid integer overflow

[Michael Niedermayer]

On Tue, Jan 14, 2020 at 04:04:29PM +0100, Paul B Mahol wrote:
> This better belong to generic code.

This specific check (which checks for INT_MAX) is specific to our
bink audio code which does a +1
so it would not fit in generic code

We could arbitrarily decide on a maximum sample rate hardcode that 
and check for that in generic code.
I can implement that if people prefer. It would not avoid all
sample rate checks in codecs though ...

Thanks

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

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope


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/binkaudio: Check sample_rate to avoid integer overflow

[Paul B Mahol]

On 2/1/20, Michael Niedermayer  wrote:
> On Tue, Jan 14, 2020 at 04:04:29PM +0100, Paul B Mahol wrote:
>> This better belong to generic code.
>
> This specific check (which checks for INT_MAX) is specific to our
> bink audio code which does a +1
> so it would not fit in generic code
>
> We could arbitrarily decide on a maximum sample rate hardcode that
> and check for that in generic code.
> I can implement that if people prefer. It would not avoid all
> sample rate checks in codecs though ...

sample rate can not be > INT_MAX

> Thanks
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> In a rich man's house there is no place to spit but his face.
> -- Diogenes of Sinope
>
___
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] MAINTAINERS: Add myself as mxf* maintainer

[Tomas Härdin]

Hi

I've been poking at mxfdec recently, and I keep an eye on the mxf tag
on trac, so I might as well add myself as maintainer again.

/Tomas
From 87f37fdbddc72aa472b9b5ce9d69ed77dcf9ed74 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?= 
Date: Sat, 1 Feb 2020 16:15:53 +0100
Subject: [PATCH] MAINTAINERS: Add myself as mxf* maintainer

I have more time for this these days
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index dfa9439ab8..5244d9237a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -451,7 +451,7 @@ Muxers/Demuxers:
   mpegtsenc.c   Baptiste Coudurier
   msnwc_tcp.c   Ramiro Polla
   mtv.c Reynaldo H. Verdejo Pinochet
-  mxf*  Baptiste Coudurier
+  mxf*  Baptiste Coudurier, Tomas Härdin
   nistspheredec.c   Paul B Mahol
   nsvdec.c  Francois Revol
   nut*  Michael Niedermayer
-- 
2.20.1



signature.asc
Description: This is a digitally signed message part
___
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] MAINTAINERS: Add myself as mxf* maintainer

[Paul B Mahol]

On 2/1/20, Tomas Härdin  wrote:
> Hi
>
> I've been poking at mxfdec recently, and I keep an eye on the mxf tag
> on trac, so I might as well add myself as maintainer again.
>
> /Tomas
>

Do you plan to waste significant non trivial time on mxf and plan send
patches instead of arguing how same code should be removed from tree,
then I'm ok with it.
___
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] fate/filter-video.mak: do not use bit-exact check for dnn_processing

[zhilizhao]

> On Feb 1, 2020, at 10:50 PM, Guo, Yejun  wrote:
> 
> 
> 
>> -Original Message-
>> From: Guo, Yejun
>> Sent: Wednesday, January 22, 2020 9:45 PM
>> To: ffmpeg-devel@ffmpeg.org
>> Cc: Guo, Yejun 
>> Subject: [PATCH V2] fate/filter-video.mak: do not use bit-exact check for
>> dnn_processing
>> 
>> The reason is that the tested models are in float format. And also
>> remove fate-filter-dnn_processing-halve_gray_float to make reference
>> files smaller.
>> 
>> Signed-off-by: Guo, Yejun 
>> ---
>> tests/fate/filter-video.mak|  7 +--
>> ...filter-dnn_processing-halve_first_channel_float | 55 
>> --
>> .../fate/filter-dnn_processing-halve_gray_float| 55 
>> --
>> 3 files changed, 4 insertions(+), 113 deletions(-)
>> delete mode 100644
>> tests/ref/fate/filter-dnn_processing-halve_first_channel_float
>> delete mode 100644 tests/ref/fate/filter-dnn_processing-halve_gray_float
>> 
>> diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
>> index 02986b5..6e744b5 100644
>> --- a/tests/fate/filter-video.mak
>> +++ b/tests/fate/filter-video.mak
> 
> I set up windows environment today with msys2 and configure with 
> "--arch=x86_64 --target-os=mingw64",
> this test also passed.  So, this fate passed on x86 + linux/windows, and IMB 
> PowerPC + linux.
> 
> has not got an arm-based system yet.

Kind of off topic, I’d like to share my test environment. In addition to real 
ARM board like Raspberry Pi,
a standard Android device + termux works pretty good. I did native 
development/build/test/debug on
two Android phone.

https://github.com/termux/termux-app 
> 
> Just checked the master and found the original patch is reverted. I'm ok for 
> it, but think it is still valuable to update the status.
> ___
> 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] MAINTAINERS: Add myself as mxf* maintainer

[Carl Eugen Hoyos]

> Am 01.02.2020 um 16:22 schrieb Paul B Mahol :
> 
>> On 2/1/20, Tomas Härdin  wrote:
>> Hi
>> 
>> I've been poking at mxfdec recently, and I keep an eye on the mxf tag
>> on trac, so I might as well add myself as maintainer again.
>> 
>> /Tomas
>> 
> 
> Do you plan to waste significant non trivial time on mxf and plan send
> patches instead of arguing how same code should be removed from tree,
> then I'm ok with it.

(While hard to parse)
+1

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] fate/filter-video.mak: do not use bit-exact check for dnn_processing

[Carl Eugen Hoyos]

> Am 01.02.2020 um 15:50 schrieb Guo, Yejun :

> Just checked the master and found the original patch is reverted.

Yes, I sent an email as a reply to the relevant mailing list thread (created by 
you) to the list:
http://ffmpeg.org/pipermail/ffmpeg-devel/2020-January/256482.html

> I'm ok for it, but think it is still valuable to update the status.

I don’t understand.

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] avcodec/utils: remove extra brackets

[Michael Niedermayer]

On Sat, Feb 01, 2020 at 05:12:13PM +0800, leozhang wrote:
> Signed-off-by: leozhang 
> ---
>  libavcodec/utils.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

will apply

thx

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

The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."


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] What new instructions would you like?

[Lauri Kasanen]

On Sat, 1 Feb 2020 12:53:28 +0100
James Darnley  wrote:

> On 30/12/2019, Lauri Kasanen  wrote:
> > For the Libre RISC-V project, I'm going to research the popular codecs
> > and design new instructions to help speed them up. With ffmpeg being
> > home to lots of asm folks for many platforms, I also want to ask your
> > opinion.
> >
> > What new instructions would you like? Anything particular you find
> > missing in existing ISAs, slow, or cumbersome?
>
> Do you mean SIMD instructions?  I have no idea what exists in RISC-V
> already or what capabilities or limitations it has, and I am going to
> use x86 language and terms such as byte, word, dword, qword.
>
> Things I have found missing in old(er) x86 instruction sets are
> missing word size and signed/unsigned variants for existing
> operations.  Some operations may have byte and word variants but dword
> and qword might be missing, or there might be a signed version but not
> an unsigned version (and vice versa).  A couple of things I had to
> emulate:
> * packed absolute value of dwords
> * packed maximum unsigned words
> * packed max and min signed dwords (I might have really wanted
> unsigned for this)
> * arithmetic right shift of qwords
> * pack dwords to words with unsigned saturation
>
> Shuffle instructions.  pshufb is very useful and I think I read on IRC
> that arm/aarch64/neon does not have an equivalent.  (Or was that other
> shuffles?)  It allows for arbitrary reordering of bytes and setting
> bytes to 0.  On x86 it takes the shuffle pattern from another SIMD
> register but I usually use it with a constant pattern that gets loaded
> from memory.  An interesting improvement would be if you can encode 17
> * 16 (or however long your vectors might be) values in an immediate
> value so it doesn't require another register.
>
> Good documentation.  The intel instruction manual has pretty good
> explanation of what the instructions do.  The old instructions from
> around the time of MMX and SSE had excellent diagrams, these might
> have been mostly for shuffle operations.  I need to look and jog my
> memory.  I think punpcklbw is an example of what I mean.  The entry in
> the manual for it has a good diagram IMO.  (At least the version I am
> currently looking at)
>
> No stupid lane stuff.  AVX2 brought us a SIMD vector length extension
> from 16 to 32 bytes.  Good except for the stupid lanes they were split
> into making it hard to "mix" data from the low 0-15 bytes and the high
> 16-31 bytes.
>
> I forgot about this email for a month.  Sorry about that.  Seeing
> RISC-V in the schedule at FOSDEM reminded me about this.

Thanks for your thoughts. The project scope is both SIMD and scalar, if
there's for example a particular bit packing that's slow and
unparallelizable, it might benefit from a dedicated instruction.

- Lauri
___
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/adpcm_argo: simplify and move duplicated logic into a function

[Michael Niedermayer]

On Sat, Feb 01, 2020 at 06:59:59AM +, Zane van Iperen wrote:
> Signed-off-by: Zane van Iperen 
> ---
>  libavcodec/adpcm.c | 40 ++--
>  1 file changed, 18 insertions(+), 22 deletions(-)

it seems theres no fate test for adpcm_argo
this patch looks ok but the codepath seems untested, maybe you can add a test ?

thx

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

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates


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".

[FFmpeg-devel] [PATCH] avformat: Add AMQP version 0-9-1 protocol support

[Andriy Gelman]

From: Andriy Gelman 

Supports connecting to a RabbitMQ broker via AMQP version 0-9-1. The
broker can redistribute content to other clients based on "exchange" and
"routing_key" fields.
---

Compilation notes:
- Requires librabbitmq-dev package (on ubuntu). 
- The pkg-config libprabbitmq.pc has a corrupt entry. 
  The line "Libs.private: rt; -lpthread" should be changed to 
  "Libs.private: -lrt -lpthread". I have made a bug report.
- Compile FFmpeg with --enable-librabbitmq 

To run an example: 
#
# Start the RabbitMQ broker (I use docker)
# The following starts the broker on localhost:5672. A webui is available on
# localhost:15672 (User/password is "guest" by default)
#
$ docker run -it --rm --name rabbitmq -p 127.0.0.1:5672:5672 -p 
127.0.0.1:15672:15672 rabbitmq:3-management

#
# Stream to the RabbitMQ broker:
#
$ ./ffmpeg -re -f lavfi -i yuvtestsrc -codec:v libx264 -f mpegts -routing_key 
"amqp" -exchange "amq.direct" amqp://localhost:5672

#
# Connect any number of clients to fetch data from the broker:
# The clients are filtered by the routing_key and exchange.
#
$ ./ffplay -routing_key "amqp" -exchange "amq.direct" amqp://localhost:5672


 Changelog   |   1 +
 configure   |   5 +
 doc/general.texi|   1 +
 doc/protocols.texi  |  53 
 libavformat/Makefile|   1 +
 libavformat/libamqp.c   | 272 
 libavformat/protocols.c |   1 +
 7 files changed, 334 insertions(+)
 create mode 100644 libavformat/libamqp.c

diff --git a/Changelog b/Changelog
index a4d20a94310..0d2c1dcc2d9 100644
--- a/Changelog
+++ b/Changelog
@@ -33,6 +33,7 @@ version :
 - Argonaut Games ADPCM decoder
 - Argonaut Games ASF demuxer
 - xfade video filter
+- AMQP protocol (RabbitMQ)
 
 
 version 4.2:
diff --git a/configure b/configure
index c02dbcc8b23..e421ecb5004 100755
--- a/configure
+++ b/configure
@@ -254,6 +254,7 @@ External library support:
   --enable-libopenmpt  enable decoding tracked files via libopenmpt [no]
   --enable-libopus enable Opus de/encoding via libopus [no]
   --enable-libpulseenable Pulseaudio input via libpulse [no]
+  --enable-librabbitmq enable rabbitmq library [no]
   --enable-librav1eenable AV1 encoding via rav1e [no]
   --enable-librsvg enable SVG rasterization via librsvg [no]
   --enable-librubberband   enable rubberband needed for rubberband filter [no]
@@ -1786,6 +1787,7 @@ EXTERNAL_LIBRARY_LIST="
 libopenmpt
 libopus
 libpulse
+librabbitmq
 librav1e
 librsvg
 librtmp
@@ -3430,6 +3432,8 @@ unix_protocol_deps="sys_un_h"
 unix_protocol_select="network"
 
 # external library protocols
+libamqp_protocol_deps="librabbitmq"
+libamqp_protocol_select="network"
 librtmp_protocol_deps="librtmp"
 librtmpe_protocol_deps="librtmp"
 librtmps_protocol_deps="librtmp"
@@ -6305,6 +6309,7 @@ enabled libopus   && {
 }
 }
 enabled libpulse  && require_pkg_config libpulse libpulse 
pulse/pulseaudio.h pa_context_new
+enabled librabbitmq   && require_pkg_config librabbitmq "librabbitmq >= 
0.7.1" amqp.h amqp_new_connection
 enabled librav1e  && require_pkg_config librav1e "rav1e >= 0.1.0" 
rav1e.h rav1e_context_new
 enabled librsvg   && require_pkg_config librsvg librsvg-2.0 
librsvg-2.0/librsvg/rsvg.h rsvg_handle_render_cairo
 enabled librtmp   && require_pkg_config librtmp librtmp librtmp/rtmp.h 
RTMP_Socket
diff --git a/doc/general.texi b/doc/general.texi
index 85db50462c2..4057a07632d 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -1326,6 +1326,7 @@ performance on systems without hardware floating point 
support).
 
 @multitable @columnfractions .4 .1
 @item Name @tab Support
+@item AMQP @tab X
 @item file @tab X
 @item FTP  @tab X
 @item Gopher   @tab X
diff --git a/doc/protocols.texi b/doc/protocols.texi
index 5e8c97d1649..3d236291e77 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -51,6 +51,59 @@ in microseconds.
 
 A description of the currently available protocols follows.
 
+@section amqp
+
+Advanced Message Queueing Protocol (AMQP) version 0-9-1 is a broker based
+publish-subscribe communication protocol.
+
+FFmpeg must be compiled with --enable-librabbitmq to support AMQP. A separate
+AMQP broker must also be run. An example open-source AMQP broker is RabbitMQ.
+
+When connecting to the broker, a client sets an "exchange" and a "routing key".
+These keys are used to filter connections: A streaming client will only receive
+the data that matches their "exchange" and "routing key".
+
+After starting the broker, an FFmpeg client may stream data to the broker using
+the command:
+
+@example
+ffmpeg -re -i input -f mpegts amqp://[user:password@@]hostname:port
+@end example
+
+Where hostname and port is the location of the broker. The client may also
+set a user/password for authentication. The defaults for both fields are
+"guest".
+
+A separate instance can stream

Re: [FFmpeg-devel] [PATCH] lavc/ac3dec: disable DRC by default

[Paul B Mahol]

On 1/29/20, rcombs  wrote:
> This issue has been argued before, with the status quo being preserved under
> the logic that the spec says this parameter is supposed to default to 1,
> and that we should follow the spec. The spec was misguided, and thus so was
> blindly following it.
>
> The (E-)AC3 DRC architecture is a clever optimization: the (relatively)
> heavy
> lifting of analyzing the audio data and calculating the per-block gain
> needed
> is offloaded to the encoder, so that the player only needs to apply the gain
> coefficients (at the desired scale) to get the DRC effect. In theory, this
> seems like an efficient way to reduce the computational complexity of
> playback.
> In practice, this isn't actually the case.
>
> Actual (E-)AC3 is not guaranteed to have useful DRC metadata at all. For
> instance, ffmpeg's encoder has never supported generating it. This means
> that
> a user who wants DRC can't merely use the internal filter for (E-)AC3 and an
> external one for other codecs; they have to use an external filter at al
> times! They could also apply the internal filter, but it's hard to see what
> benefit this would give.
>
> I've also seen it argued that (E-)AC3 DRC does a better job of reproducing
> the
> intent of the audio mastering engineer than playback-time DRC can. I don't
> believe this argument is credible either. The official encoder does support
> passing in custom gain values, but it doesn't appear that this capability is
> frequently used. I'm not aware of any tooling that actually passes custom
> data
> into the encoder's loudness parameters, and Dolby's first-party GUI tools
> don't
> appear to support doing so. Dolby's own tools expose the parameters
> available in
> the encoder itself, which comprise a set of 5 presets with no
> customizability:
> "Film Standard", "Film Light", "Music Standard", "Music Light", and
> "Speech",
> along with the null profile. These profiles are documented (minus their time
> constants) in this PDF on the Dolby website:
> https://www.dolby.com/us/en/technologies/a-guide-to-dolby-metadata.pdf
> These are not advanced filters; they don't provide any complex control to
> the
> content producer, who can't even tune the details or _know_ the time
> constants.
> Even if the mastering engineer did want to customize the DRC with some
> custom
> tool, in most cases I don't think they'd have the ability to do so because
> they
> don't have access to the point in the pipeline where audio encoding occurs.
> In TV, audio is often encoded live rather than streaming a pre-compressed
> bitstream. In web streaming, masters are usually delivered with uncompressed
> PCM audio and no loudness metadata, and encoded using stock configurations.
> Film for DVD or Blu-Ray is the only plausible case, but again, I'm not aware
> of any widely-used tooling for this with any more configurability than
> Dolby's.
>
> Additional context: the AudioToolbox (E-)AC3 decoder (which is Dolby's)
> seems
> not to apply DRC; you can see this by comparing the output of ffmpeg's
> decoder
> with drc_scale set to 0 and 1 with the output of the (e)ac3_at decoder.
>
> So to summarize:
> - (E-)AC3 DRC is designed as an optimization for the decoder
> - There's no inherent reason (E-)AC3 _requires_ DRC for playback more than
> any
>   other codec
> - Due to inconsistent encoding, it can't be relied upon
> - There's no reason to believe it's better than decode-side DRC when it
> works
> - It's not universally applied by other software
>
> I think this makes a compelling case to stop applying (E-)AC3 DRC by
> default.
> The user can enable it on their own if they prefer, but I believe having it
> off
> by default will improve the apparent quality of (E-)AC3 playback for the
> vast
> majority of ffmpeg users, and improve the consistency between (E-)AC3
> playback
> and playback of any other codec. Thus, this patch.
> ---
>  libavcodec/ac3dec_fixed.c | 2 +-
>  libavcodec/ac3dec_float.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/ac3dec_fixed.c b/libavcodec/ac3dec_fixed.c
> index bd66175d50..312616edfd 100644
> --- a/libavcodec/ac3dec_fixed.c
> +++ b/libavcodec/ac3dec_fixed.c
> @@ -169,7 +169,7 @@ static void ac3_downmix_c_fixed16(int16_t **samples,
> int16_t **matrix,
>
>  static const AVOption options[] = {
>  { "cons_noisegen", "enable consistent noise generation",
> OFFSET(consistent_noise_generation), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1,
> PAR },
> -{ "drc_scale", "percentage of dynamic range compression to apply",
> OFFSET(drc_scale), AV_OPT_TYPE_FLOAT, {.dbl = 1.0}, 0.0, 6.0, PAR },
> +{ "drc_scale", "percentage of dynamic range compression to apply",
> OFFSET(drc_scale), AV_OPT_TYPE_FLOAT, {.dbl = 0.0}, 0.0, 6.0, PAR },
>  { "heavy_compr", "enable heavy dynamic range compression",
> OFFSET(heavy_compression), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, PAR },
>  { NULL},
>  };
> diff --git a/libavcodec/ac3dec_float.c b/libavcodec/ac3dec_f

[FFmpeg-devel] [PATCH] lavc/ac3dec: disable DRC by default

[rcombs]

This issue has been argued before, with the status quo being preserved under
the logic that the spec says this parameter is supposed to default to 1,
and that we should follow the spec. The spec was misguided, and thus so was
blindly following it.

The (E-)AC3 DRC architecture is a clever optimization: the (relatively) heavy
lifting of analyzing the audio data and calculating the per-block gain needed
is offloaded to the encoder, so that the player only needs to apply the gain
coefficients (at the desired scale) to get the DRC effect. In theory, this
seems like an efficient way to reduce the computational complexity of playback.
In practice, this isn't actually the case.

Actual (E-)AC3 is not guaranteed to have useful DRC metadata at all. For
instance, ffmpeg's encoder has never supported generating it. This means that
a user who wants DRC can't merely use the internal filter for (E-)AC3 and an
external one for other codecs; they have to use an external filter at al
times! They could also apply the internal filter, but it's hard to see what
benefit this would give.

I've also seen it argued that (E-)AC3 DRC does a better job of reproducing the
intent of the audio mastering engineer than playback-time DRC can. I don't
believe this argument is credible either. The official encoder does support
passing in custom gain values, but it doesn't appear that this capability is
frequently used. I'm not aware of any tooling that actually passes custom data
into the encoder's loudness parameters, and Dolby's first-party GUI tools don't
appear to support doing so. Dolby's own tools expose the parameters available in
the encoder itself, which comprise a set of 5 presets with no customizability:
"Film Standard", "Film Light", "Music Standard", "Music Light", and "Speech",
along with the null profile. These profiles are documented (minus their time
constants) in this PDF on the Dolby website:
https://www.dolby.com/us/en/technologies/a-guide-to-dolby-metadata.pdf
These are not advanced filters; they don't provide any complex control to the
content producer, who can't even tune the details or _know_ the time constants.
Even if the mastering engineer did want to customize the DRC with some custom
tool, in most cases I don't think they'd have the ability to do so because they
don't have access to the point in the pipeline where audio encoding occurs.
In TV, audio is often encoded live rather than streaming a pre-compressed
bitstream. In web streaming, masters are usually delivered with uncompressed
PCM audio and no loudness metadata, and encoded using stock configurations.
Film for DVD or Blu-Ray is the only plausible case, but again, I'm not aware
of any widely-used tooling for this with any more configurability than Dolby's.

Additional context: the AudioToolbox (E-)AC3 decoder (which is Dolby's) seems
not to apply DRC; you can see this by comparing the output of ffmpeg's decoder
with drc_scale set to 0 and 1 with the output of the (e)ac3_at decoder.

So to summarize:
- (E-)AC3 DRC is designed as an optimization for the decoder
- There's no inherent reason (E-)AC3 _requires_ DRC for playback more than any
  other codec
- Due to inconsistent encoding, it can't be relied upon
- There's no reason to believe it's better than decode-side DRC when it works
- It's not universally applied by other software

I think this makes a compelling case to stop applying (E-)AC3 DRC by default.
The user can enable it on their own if they prefer, but I believe having it off
by default will improve the apparent quality of (E-)AC3 playback for the vast
majority of ffmpeg users, and improve the consistency between (E-)AC3 playback
and playback of any other codec. Thus, this patch.
---
 libavcodec/ac3dec_fixed.c |  2 +-
 libavcodec/ac3dec_float.c |  2 +-
 tests/fate/ac3.mak| 32 
 3 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/libavcodec/ac3dec_fixed.c b/libavcodec/ac3dec_fixed.c
index bd66175d50..312616edfd 100644
--- a/libavcodec/ac3dec_fixed.c
+++ b/libavcodec/ac3dec_fixed.c
@@ -169,7 +169,7 @@ static void ac3_downmix_c_fixed16(int16_t **samples, 
int16_t **matrix,
 
 static const AVOption options[] = {
 { "cons_noisegen", "enable consistent noise generation", 
OFFSET(consistent_noise_generation), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, PAR },
-{ "drc_scale", "percentage of dynamic range compression to apply", 
OFFSET(drc_scale), AV_OPT_TYPE_FLOAT, {.dbl = 1.0}, 0.0, 6.0, PAR },
+{ "drc_scale", "percentage of dynamic range compression to apply", 
OFFSET(drc_scale), AV_OPT_TYPE_FLOAT, {.dbl = 0.0}, 0.0, 6.0, PAR },
 { "heavy_compr", "enable heavy dynamic range compression", 
OFFSET(heavy_compression), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, PAR },
 { NULL},
 };
diff --git a/libavcodec/ac3dec_float.c b/libavcodec/ac3dec_float.c
index b85a4ce336..69bd47aa6a 100644
--- a/libavcodec/ac3dec_float.c
+++ b/libavcodec/ac3dec_float.c
@@ -33,7 +33,7 @@
 
 static const AVOption options[

Re: [FFmpeg-devel] [PATCH] lavc/ac3dec: disable DRC by default

[James Almer]

On 2/1/2020 4:34 PM, rcombs wrote:
> This issue has been argued before, with the status quo being preserved under
> the logic that the spec says this parameter is supposed to default to 1,
> and that we should follow the spec. The spec was misguided, and thus so was
> blindly following it.
> 
> The (E-)AC3 DRC architecture is a clever optimization: the (relatively) heavy
> lifting of analyzing the audio data and calculating the per-block gain needed
> is offloaded to the encoder, so that the player only needs to apply the gain
> coefficients (at the desired scale) to get the DRC effect. In theory, this
> seems like an efficient way to reduce the computational complexity of 
> playback.
> In practice, this isn't actually the case.
> 
> Actual (E-)AC3 is not guaranteed to have useful DRC metadata at all. For
> instance, ffmpeg's encoder has never supported generating it. This means that
> a user who wants DRC can't merely use the internal filter for (E-)AC3 and an
> external one for other codecs; they have to use an external filter at al
> times! They could also apply the internal filter, but it's hard to see what
> benefit this would give.
> 
> I've also seen it argued that (E-)AC3 DRC does a better job of reproducing the
> intent of the audio mastering engineer than playback-time DRC can. I don't
> believe this argument is credible either. The official encoder does support
> passing in custom gain values, but it doesn't appear that this capability is
> frequently used. I'm not aware of any tooling that actually passes custom data
> into the encoder's loudness parameters, and Dolby's first-party GUI tools 
> don't
> appear to support doing so. Dolby's own tools expose the parameters available 
> in
> the encoder itself, which comprise a set of 5 presets with no customizability:
> "Film Standard", "Film Light", "Music Standard", "Music Light", and "Speech",
> along with the null profile. These profiles are documented (minus their time
> constants) in this PDF on the Dolby website:
> https://www.dolby.com/us/en/technologies/a-guide-to-dolby-metadata.pdf
> These are not advanced filters; they don't provide any complex control to the
> content producer, who can't even tune the details or _know_ the time 
> constants.
> Even if the mastering engineer did want to customize the DRC with some custom
> tool, in most cases I don't think they'd have the ability to do so because 
> they
> don't have access to the point in the pipeline where audio encoding occurs.
> In TV, audio is often encoded live rather than streaming a pre-compressed
> bitstream. In web streaming, masters are usually delivered with uncompressed
> PCM audio and no loudness metadata, and encoded using stock configurations.
> Film for DVD or Blu-Ray is the only plausible case, but again, I'm not aware
> of any widely-used tooling for this with any more configurability than 
> Dolby's.
> 
> Additional context: the AudioToolbox (E-)AC3 decoder (which is Dolby's) seems
> not to apply DRC; you can see this by comparing the output of ffmpeg's decoder
> with drc_scale set to 0 and 1 with the output of the (e)ac3_at decoder.
> 
> So to summarize:
> - (E-)AC3 DRC is designed as an optimization for the decoder
> - There's no inherent reason (E-)AC3 _requires_ DRC for playback more than any
>   other codec
> - Due to inconsistent encoding, it can't be relied upon
> - There's no reason to believe it's better than decode-side DRC when it works
> - It's not universally applied by other software
> 
> I think this makes a compelling case to stop applying (E-)AC3 DRC by default.
> The user can enable it on their own if they prefer, but I believe having it 
> off
> by default will improve the apparent quality of (E-)AC3 playback for the vast
> majority of ffmpeg users, and improve the consistency between (E-)AC3 playback
> and playback of any other codec. Thus, this patch.
> ---
>  libavcodec/ac3dec_fixed.c |  2 +-
>  libavcodec/ac3dec_float.c |  2 +-
>  tests/fate/ac3.mak| 32 
>  3 files changed, 18 insertions(+), 18 deletions(-)
> 
> diff --git a/libavcodec/ac3dec_fixed.c b/libavcodec/ac3dec_fixed.c
> index bd66175d50..312616edfd 100644
> --- a/libavcodec/ac3dec_fixed.c
> +++ b/libavcodec/ac3dec_fixed.c
> @@ -169,7 +169,7 @@ static void ac3_downmix_c_fixed16(int16_t **samples, 
> int16_t **matrix,
>  
>  static const AVOption options[] = {
>  { "cons_noisegen", "enable consistent noise generation", 
> OFFSET(consistent_noise_generation), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, PAR 
> },
> -{ "drc_scale", "percentage of dynamic range compression to apply", 
> OFFSET(drc_scale), AV_OPT_TYPE_FLOAT, {.dbl = 1.0}, 0.0, 6.0, PAR },
> +{ "drc_scale", "percentage of dynamic range compression to apply", 
> OFFSET(drc_scale), AV_OPT_TYPE_FLOAT, {.dbl = 0.0}, 0.0, 6.0, PAR },
>  { "heavy_compr", "enable heavy dynamic range compression", 
> OFFSET(heavy_compression), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, PAR },
>  { NULL},

Re: [FFmpeg-devel] [PATCH] lavc/ac3dec: disable DRC by default

[Derek Buitenhuis]

On 01/02/2020 19:34, rcombs wrote:
> This issue has been argued before, with the status quo being preserved under
> the logic that the spec says this parameter is supposed to default to 1,
> and that we should follow the spec. The spec was misguided, and thus so was
> blindly following it.

If "I don't agree with the spec" or "this spec does something stupid" were valid
arguments, we may as well not have specs at all, and FFmpeg would have a lot 
more
garbage in it. You can write at length why you think it's bad, but that does not
negeate the fact that it's the spec, and the defacto way to handle decoding 
AC-3.

And I'd rather not give Dolby more ammunition for their anti-FOSS FUD campaign.

For whatever my opinion is worth nowadays on this list, it's a very, very hard
NAK from me.

- Derek
___
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] MAINTAINERS: Add myself as mxf* maintainer

[Marton Balint]

On Sat, 1 Feb 2020, Carl Eugen Hoyos wrote:





Am 01.02.2020 um 16:22 schrieb Paul B Mahol :


On 2/1/20, Tomas Härdin  wrote:
Hi

I've been poking at mxfdec recently, and I keep an eye on the mxf tag
on trac, so I might as well add myself as maintainer again.

/Tomas



Do you plan to waste significant non trivial time on mxf and plan send
patches instead of arguing how same code should be removed from tree,
then I'm ok with it.


(While hard to parse)
+1


Tomas was always helpful reviewing my and other's mxf patches, this alone 
makes your comments unfair towards him, because he actually worked on 
improving in-tree mxf by his reviews. So maybe we should thank him and be 
grateful that some part of the code becomes officially maintained.


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".

[FFmpeg-devel] [EXTREMELY IMPORTANT] [PLEASE DO NOT IGNORE] [PATCH] avfilter/framesync: do not pick AV_TIME_BASE for time base when not needed.

[Paul B Mahol]

Fixes picking time base when all input time bases are same and for example
20833/50.

Signed-off-by: Paul B Mahol 
---
 libavfilter/framesync.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/framesync.c b/libavfilter/framesync.c
index bc95f7d904..94abb469e6 100644
--- a/libavfilter/framesync.c
+++ b/libavfilter/framesync.c
@@ -144,7 +144,7 @@ int ff_framesync_configure(FFFrameSync *fs)
 if (fs->time_base.num) {
 gcd = av_gcd(fs->time_base.den, fs->in[i].time_base.den);
 lcm = (fs->time_base.den / gcd) * fs->in[i].time_base.den;
-if (lcm < AV_TIME_BASE / 2) {
+if (lcm <= AV_TIME_BASE / 2) {
 fs->time_base.den = lcm;
 fs->time_base.num = av_gcd(fs->time_base.num,
fs->in[i].time_base.num);
-- 
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] MAINTAINERS: Add myself as mxf* maintainer

[Paul B Mahol]

On 2/1/20, Marton Balint  wrote:
>
>
> On Sat, 1 Feb 2020, Carl Eugen Hoyos wrote:
>
>>
>>
>>> Am 01.02.2020 um 16:22 schrieb Paul B Mahol :
>>>
 On 2/1/20, Tomas Härdin  wrote:
 Hi

 I've been poking at mxfdec recently, and I keep an eye on the mxf tag
 on trac, so I might as well add myself as maintainer again.

 /Tomas

>>>
>>> Do you plan to waste significant non trivial time on mxf and plan send
>>> patches instead of arguing how same code should be removed from tree,
>>> then I'm ok with it.
>>
>> (While hard to parse)
>> +1
>
> Tomas was always helpful reviewing my and other's mxf patches, this alone
> makes your comments unfair towards him, because he actually worked on
> improving in-tree mxf by his reviews. So maybe we should thank him and be
> grateful that some part of the code becomes officially maintained.
>

Agreed, except part for removing our in tree implementation.

> 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".
___
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] lavc/ac3dec: disable DRC by default

[Paul B Mahol]

On 2/1/20, Derek Buitenhuis  wrote:
> On 01/02/2020 19:34, rcombs wrote:
>> This issue has been argued before, with the status quo being preserved
>> under
>> the logic that the spec says this parameter is supposed to default to 1,
>> and that we should follow the spec. The spec was misguided, and thus so
>> was
>> blindly following it.
>
> If "I don't agree with the spec" or "this spec does something stupid" were
> valid
> arguments, we may as well not have specs at all, and FFmpeg would have a lot
> more
> garbage in it. You can write at length why you think it's bad, but that does
> not
> negeate the fact that it's the spec, and the defacto way to handle decoding
> AC-3.
>
> And I'd rather not give Dolby more ammunition for their anti-FOSS FUD
> campaign.
>
> For whatever my opinion is worth nowadays on this list, it's a very, very
> hard
> NAK from me.

This does not have much logic or valid reasoning.

>
> - Derek
> ___
> 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] avfilter/scene_sad: add AArch64 SIMD

[Marton Balint]

On Sat, 1 Feb 2020, quinkbl...@foxmail.com wrote:


From: Zhao Zhili 

For 8 bit depth:
   ./ffmpeg -threads 1 -f lavfi -t 10 -i 
'yuvtestsrc=size=4096x2048,format=yuv444p' -vf 'freezedetect' -f null 
-benchmark -

   Test results on Snapdragon 845:
   Before:
   frame=  250 fps= 23 q=-0.0 Lsize=N/A time=00:00:10.00 bitrate=N/A 
speed=0.924x
bench: utime=8.360s stime=2.350s rtime=10.820s
   After:
   frame=  250 fps= 51 q=-0.0 Lsize=N/A time=00:00:10.00 bitrate=N/A 
speed=2.04x
bench: utime=2.650s stime=2.210s rtime=4.909s

   Test results on HiSilicon Kirin 970:
   Before:
   frame=  250 fps=6.0 q=-0.0 Lsize=N/A time=00:00:10.00 bitrate=N/A 
speed=0.239x
   bench: utime=35.156s stime=6.604s rtime=41.820s
   After:
   frame=  250 fps= 10 q=-0.0 Lsize=N/A time=00:00:10.00 bitrate=N/A 
speed=0.403x
bench: utime=18.400s stime=6.376s rtime=24.798s

For 16 bit depth:
   ./ffmpeg -threads 1 -f lavfi -t 10 -i 
'yuvtestsrc=size=4096x2048,format=yuv444p16' -vf 'freezedetect' -f null 
-benchmark -

   Test results on Snapdragon 845
   Before:
   frame=  250 fps= 19 q=-0.0 Lsize=N/A time=00:00:10.00 bitrate=N/A 
speed=0.756x
bench: utime=8.700s stime=4.410s rtime=13.226s
   After:
frame=  250 fps= 27 q=-0.0 Lsize=N/A time=00:00:10.00 bitrate=N/A 
speed=1.07x
bench: utime=4.920s stime=4.350s rtime=9.356s

   Test results on HiSilicon Kirin 970:
   Before:
   frame=  250 fps=4.0 q=-0.0 Lsize=N/A time=00:00:10.00 bitrate=N/A 
speed=0.161x
bench: utime=48.868s stime=13.124s rtime=62.110s
   After:
   frame=  250 fps=5.1 q=-0.0 Lsize=N/A time=00:00:10.00 bitrate=N/A 
speed=0.205x
bench: utime=35.600s stime=13.036s rtime=48.708s
---
libavfilter/aarch64/Makefile |   2 +
libavfilter/aarch64/scene_sad_init.c |  37 +++
libavfilter/aarch64/scene_sad_neon.S | 149 +++
libavfilter/scene_sad.c  |   2 +
libavfilter/scene_sad.h  |   2 +
5 files changed, 192 insertions(+)
create mode 100644 libavfilter/aarch64/scene_sad_init.c
create mode 100644 libavfilter/aarch64/scene_sad_neon.S


Does your ASM handles cases when width is not a multiple of the 
vector size? If not, then you should probably do something similar to what 
is done for X86.


Thanks,
Marton



diff --git a/libavfilter/aarch64/Makefile b/libavfilter/aarch64/Makefile
index 6c727f9859..3a458f511f 100644
--- a/libavfilter/aarch64/Makefile
+++ b/libavfilter/aarch64/Makefile
@@ -1,7 +1,9 @@
OBJS-$(CONFIG_NLMEANS_FILTER)+= aarch64/af_afir_init.o
OBJS-$(CONFIG_NLMEANS_FILTER)+= aarch64/af_anlmdn_init.o
+OBJS-$(CONFIG_NLMEANS_FILTER)+= aarch64/scene_sad_init.o
OBJS-$(CONFIG_NLMEANS_FILTER)+= aarch64/vf_nlmeans_init.o

NEON-OBJS-$(CONFIG_NLMEANS_FILTER)   += aarch64/af_afir_neon.o
NEON-OBJS-$(CONFIG_NLMEANS_FILTER)   += aarch64/af_anlmdn_neon.o
+NEON-OBJS-$(CONFIG_NLMEANS_FILTER)   += aarch64/scene_sad_neon.o
NEON-OBJS-$(CONFIG_NLMEANS_FILTER)   += aarch64/vf_nlmeans_neon.o
diff --git a/libavfilter/aarch64/scene_sad_init.c 
b/libavfilter/aarch64/scene_sad_init.c
new file mode 100644
index 00..8de769ac10
--- /dev/null
+++ b/libavfilter/aarch64/scene_sad_init.c
@@ -0,0 +1,37 @@
+/*
+ * 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 "libavutil/aarch64/cpu.h"
+#include "libavfilter/scene_sad.h"
+
+void ff_scene_sad_neon(SCENE_SAD_PARAMS);
+
+void ff_scene_sad16_neon(SCENE_SAD_PARAMS);
+
+ff_scene_sad_fn ff_scene_sad_get_fn_aarch64(int depth)
+{
+int cpu_flags = av_get_cpu_flags();
+if (have_neon(cpu_flags)) {
+if (depth == 8)
+return ff_scene_sad_neon;
+if (depth == 16)
+return ff_scene_sad16_neon;
+}
+
+return NULL;
+}
diff --git a/libavfilter/aarch64/scene_sad_neon.S 
b/libavfilter/aarch64/scene_sad_neon.S
new file mode 100644
index 00..5b3b027a53
--- /dev/null
+++ b/libavfilter/aarch64/scene_sad_neon.S
@@ -0,0 +1,149 @@
+/*
+ * Copyright (c) 2020 Zhao Zhili
+ *
+ * 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 publ

Re: [FFmpeg-devel] [PATCH 1/2] avformat/udp: remove setting cancel state from the TX thread

[Marton Balint]

On Sun, 26 Jan 2020, Marton Balint wrote:


Write mode does not use cancellation.


Ping, will apply the series soon.

Thanks,
Marton



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

diff --git a/libavformat/udp.c b/libavformat/udp.c
index dce4cf76c7..85c9e3a900 100644
--- a/libavformat/udp.c
+++ b/libavformat/udp.c
@@ -520,14 +520,12 @@ static void *circular_buffer_task_tx( void *_URLContext)
{
URLContext *h = _URLContext;
UDPContext *s = h->priv_data;
-int old_cancelstate;
int64_t target_timestamp = av_gettime_relative();
int64_t start_timestamp = av_gettime_relative();
int64_t sent_bits = 0;
int64_t burst_interval = s->bitrate ? (s->burst_bits * 100 / 
s->bitrate) : 0;
int64_t max_delay = s->bitrate ?  ((int64_t)h->max_packet_size * 8 * 100 / 
s->bitrate + 1) : 0;

-pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, &old_cancelstate);
pthread_mutex_lock(&s->mutex);

if (ff_socket_nonblock(s->udp_fd, 0) < 0) {
@@ -562,7 +560,6 @@ static void *circular_buffer_task_tx( void *_URLContext)
av_fifo_generic_read(s->fifo, s->tmp, len, NULL);

pthread_mutex_unlock(&s->mutex);
-pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, &old_cancelstate);

if (s->bitrate) {
timestamp = av_gettime_relative();
@@ -608,7 +605,6 @@ static void *circular_buffer_task_tx( void *_URLContext)
}
}

-pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, &old_cancelstate);
pthread_mutex_lock(&s->mutex);
}

--
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 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] lavc/ac3dec: disable DRC by default

[Derek Buitenhuis]

On 01/02/2020 20:18, Paul B Mahol wrote:
> This does not have much logic or valid reasoning.

Please stop your constant vague troll replies and ad hominem attacks.

They are rampant on this mailing list; practically every thread, but
specifically against some people. It's getting ridiculous. It makes
ffmpeg-devel unwelcoming to others, and appear childish in nature.

I will not reply to any further mails from you of this nature, and I
would encourage also not to.

- Derek
___
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] lavc/ac3dec: disable DRC by default

[Paul B Mahol]

On 2/1/20, Derek Buitenhuis  wrote:
> On 01/02/2020 20:18, Paul B Mahol wrote:
>> This does not have much logic or valid reasoning.
>
> Please stop your constant vague troll replies and ad hominem attacks.

I was not vague, your reasoning that because of dolby we need to comply to some
standards is not good.
Even dolby does not follow this as already mentioned on this same thread.

>
> They are rampant on this mailing list; practically every thread, but
> specifically against some people. It's getting ridiculous. It makes
> ffmpeg-devel unwelcoming to others, and appear childish in nature.
>

It is easy to deny truth. I'm not rampant at least not yet.

> I will not reply to any further mails from you of this nature, and I
> would encourage also not to.
>
> - Derek
> ___
> 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] lavc/ac3dec: disable DRC by default

[Derek Buitenhuis]

On 01/02/2020 20:37, Paul B Mahol wrote:
> I was not vague, your reasoning that because of dolby we need to comply to 
> some
> standards is not good.
> Even dolby does not follow this as already mentioned on this same thread.

So write this in the email instead of one completely devoid of any reasoning.
Replies that say something is wrong or that you disagree, and not /why/ are not
useful to the author, nor are they effective at persuading others. I'm certainly
reminded of why I stopped frequenting this list.

Anyway, your argument is basically that we shouln't conform to specs depending
on who wrote them? That's arbitrary, and a poor precedent to set, in my opinion.
Further, AudioToolBox, while it may use an official decoder, is not distributed 
by
Dolby, nor, as far as I know, endorsed by them (they won't even tell you if it's
theirs inside, I believe). I suspect Apple set it up to not apply DRC, not 
Dolby.

The rest of your mail is more trolling, which I will not reply to.

So, that's my two cents on the subject - the rest of the list can decide if they
have merit or not - I am done replying to you, since you cannot act like an 
adult.

- Derek
___
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] lavc/ac3dec: disable DRC by default

[Paul B Mahol]

On 2/1/20, Derek Buitenhuis  wrote:
> On 01/02/2020 20:37, Paul B Mahol wrote:
>> I was not vague, your reasoning that because of dolby we need to comply to
>> some
>> standards is not good.
>> Even dolby does not follow this as already mentioned on this same thread.
>
> So write this in the email instead of one completely devoid of any
> reasoning.
> Replies that say something is wrong or that you disagree, and not /why/ are
> not
> useful to the author, nor are they effective at persuading others. I'm
> certainly
> reminded of why I stopped frequenting this list.
>
> Anyway, your argument is basically that we shouln't conform to specs
> depending
> on who wrote them? That's arbitrary, and a poor precedent to set, in my
> opinion.
> Further, AudioToolBox, while it may use an official decoder, is not
> distributed by
> Dolby, nor, as far as I know, endorsed by them (they won't even tell you if
> it's
> theirs inside, I believe). I suspect Apple set it up to not apply DRC, not
> Dolby.
>
> The rest of your mail is more trolling, which I will not reply to.
>
> So, that's my two cents on the subject - the rest of the list can decide if
> they
> have merit or not - I am done replying to you, since you cannot act like an
> adult.

Easy pick, to stop discussion by ridiculing opponent.
___
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] lavc/ac3dec: disable DRC by default

[rcombs]

> On Feb 1, 2020, at 13:43, Derek Buitenhuis  wrote:
> 
> On 01/02/2020 19:34, rcombs wrote:
>> This issue has been argued before, with the status quo being preserved under
>> the logic that the spec says this parameter is supposed to default to 1,
>> and that we should follow the spec. The spec was misguided, and thus so was
>> blindly following it.
> 
> If "I don't agree with the spec" or "this spec does something stupid" were 
> valid
> arguments, we may as well not have specs at all, and FFmpeg would have a lot 
> more
> garbage in it. You can write at length why you think it's bad, but that does 
> not
> negeate the fact that it's the spec,

I'm not sure why the spec should have any bearing on the defaults of 
configurable options, particularly when those defaults result in unexpected 
behavior that's unlike that used for any other codec.

> and the defacto way to handle decoding AC-3.

Is it, though? My understanding is that AV receivers usually only enable AC3 
DRC in "night mode" or the like, and few even provide a fully-tunable setting 
for it. Apple's decoder in AudioToolbox (implemented on top of Dolby's) doesn't 
provide the feature at all (I haven't checked what Win32 Media Foundation does 
yet). So where does this "de facto" situation come from, other than lavc itself?

Meanwhile, Dolby's own decoder applies digital dialog normalization by default 
(contrary to how the spec says it should be applied downstream), and I haven't 
seen anyone arguing that lavc should do that.

Additionally, TrueHD has a very similar DRC feature that lavc doesn't support 
whatsoever, and nobody seems to mind.

One other thing I neglected to mention in the commit message: the actual audio 
encoded in an (E)AC3 track often has levels similar to those of a track in 
another codec (PCM, AAC, etc) from the same or other sources, but sounds very 
different when both are decoded with lavc. For instance, Netflix's EAC3 sounds 
about the same as BD audio of the same content when decoded without DRC, but in 
lavc-based players by default, it sounds, well... compressed. This had led to 
an impression in the anime community that Netflix applies excessive DRC to 
their EAC3 streams at encode-time, and thus that those streams were low-quality 
and should be avoided.

> 
> And I'd rather not give Dolby more ammunition for their anti-FOSS FUD 
> campaign.
> 
> For whatever my opinion is worth nowadays on this list, it's a very, very hard
> NAK from me.
> 
> - Derek
> ___
> 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 2/6] avcodec:v4l2_context: Remove NULL initialization

[Mark Thompson]

On 13/01/2020 04:11, Andriy Gelman wrote:
> From: Andriy Gelman 
> 
> Signed-off-by: Andriy Gelman 
> ---
>  libavcodec/v4l2_context.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
On 13/01/2020 04:11, Andriy Gelman wrote:> From: Andriy Gelman 

> 
> Before this commit s->avctx == NULL was used to infer that an encoder is
> being initialzed. Code readability has been improved by directly using
> !av_codec_is_decoder() instead.
> 
> Signed-off-by: Andriy Gelman 
> ---
>  libavcodec/v4l2_m2m.c | 4 ++--
>  libavcodec/v4l2_m2m_enc.c | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
On 13/01/2020 04:11, Andriy Gelman wrote:> From: Andriy Gelman 

> 
> Before this commit v4l2_m2m used two different logging contexts (from
> V4L2m2mPriv and AVCodecContext). For consistency always use AVCodecContext.
> 
> Signed-off-by: Andriy Gelman 
> ---
>  libavcodec/v4l2_context.c |  2 +-
>  libavcodec/v4l2_m2m.c | 18 +-
>  2 files changed, 10 insertions(+), 10 deletions(-)
> 
On 13/01/2020 04:11, Andriy Gelman wrote:> From: Andriy Gelman 

> 
> Change pointer symbol position.
> 
> Signed-off-by: Andriy Gelman 
> ---
>  libavcodec/v4l2_m2m.c | 10 +-
>  libavcodec/v4l2_m2m_dec.c |  2 +-
>  2 files changed, 6 insertions(+), 6 deletions(-)
> 

All four of these LGTM.  I did a little bit of testing and applied.

Thanks,

- Mark
___
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] lavc/ac3dec: disable DRC by default

[Derek Buitenhuis]

On 01/02/2020 21:03, rcombs wrote:
> 
>> If "I don't agree with the spec" or "this spec does something stupid" were 
>> valid
>> arguments, we may as well not have specs at all, and FFmpeg would have a lot 
>> more
>> garbage in it. You can write at length why you think it's bad, but that does 
>> not
>> negeate the fact that it's the spec,
> 
> I'm not sure why the spec should have any bearing on the defaults of 
> configurable options, particularly when those defaults result in unexpected 
> behavior that's unlike that used for any other codec.

Because it's the spec, and it defines that. It is the source of truth,
and, in my opinion, the expected default behavior as a result.

>> and the defacto way to handle decoding AC-3.
> 
> Is it, though? My understanding is that AV receivers usually only enable AC3 
> DRC in "night mode" or the like, and few even provide a fully-tunable setting 
> for it. Apple's decoder in AudioToolbox (implemented on top of Dolby's) 
> doesn't provide the feature at all (I haven't checked what Win32 Media 
> Foundation does yet). So where does this "de facto" situation come from, 
> other than lavc itself?

Because the spec defines what is de facto - it is what defines what AC-3 *is*.
You are choosing to ignore it here because you don't like what's in it.

I am of the opinion that a spec is better than a survey of a one software 
decoder
(not endorsed or acknowledged by Dolby afaik), and some unconfirmed info on some
recievers.

Is the spec dumb? Yeah probably, but lots of specs have dumb stuff in them. But
we follow them - which is the entire point of a spec.

> Meanwhile, Dolby's own decoder applies digital dialog normalization by 
> default (contrary to how the spec says it should be applied downstream), and 
> I haven't seen anyone arguing that lavc should do that.

Own decoder from where? Is it officially Dolby branded, or is this Apple again?

> Additionally, TrueHD has a very similar DRC feature that lavc doesn't support 
> whatsoever, and nobody seems to mind.

Missing support in another decoder is not a good argument in favour or changing
behavior in one that is not missing support.

(As an aside, I have heard this used as an argument against using FFmpeg's
TrueHD decoder in the past, in Profession Broadcast Vendor Trade Shows(TM))

> One other thing I neglected to mention in the commit message: the actual 
> audio encoded in an (E)AC3 track often has levels similar to those of a track 
> in another codec (PCM, AAC, etc) from the same or other sources, but sounds 
> very different when both are decoded with lavc. For instance, Netflix's EAC3 
> sounds about the same as BD audio of the same content when decoded without 
> DRC, but in lavc-based players by default, it sounds, well... compressed. 
> This had led to an impression in the anime community that Netflix applies 
> excessive DRC to their EAC3 streams at encode-time, and thus that those 
> streams were low-quality and should be avoided.

Netflix is the origin of that audio, not the master. I suspect it's a byproduct 
of how they
transcode, rather than inherent to the show/BD/master/whatever itself. I don't 
think it's
a good argument in favour of changing the default behavior to be contrary to 
the spec,
but YMMV, I'm only one person. If people on the list decide they prefer it that 
way, then
it'll be that way - this is just my opinion as an API user and someone who has 
dealt with
too much vendor FUD.

- Derek
___
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] lavc/ac3dec: disable DRC by default

[rcombs]

> On Feb 1, 2020, at 15:55, Derek Buitenhuis  wrote:
> 
>>> and the defacto way to handle decoding AC-3.
>> 
>> Is it, though? My understanding is that AV receivers usually only enable AC3 
>> DRC in "night mode" or the like, and few even provide a fully-tunable 
>> setting for it. Apple's decoder in AudioToolbox (implemented on top of 
>> Dolby's) doesn't provide the feature at all (I haven't checked what Win32 
>> Media Foundation does yet). So where does this "de facto" situation come 
>> from, other than lavc itself?
> 
> Because the spec defines what is de facto - it is what defines what AC-3 *is*.
> You are choosing to ignore it here because you don't like what's in it.

This is "de jure"; "de facto" means how it's actually implemented in practice.

>> Meanwhile, Dolby's own decoder applies digital dialog normalization by 
>> default (contrary to how the spec says it should be applied downstream), and 
>> I haven't seen anyone arguing that lavc should do that.
> 
> Own decoder from where? Is it officially Dolby branded, or is this Apple 
> again?

Their own decoder IP and reference tool; it's non-public, and it's what Apple's 
is built on top of.

> 
> ___
> 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] lavc/ac3dec: disable DRC by default

[Derek Buitenhuis]

On 01/02/2020 22:02, rcombs wrote:
>> Because the spec defines what is de facto - it is what defines what AC-3 
>> *is*.
>> You are choosing to ignore it here because you don't like what's in it.
> 
> This is "de jure"; "de facto" means how it's actually implemented in practice.

Woops, yes, you are correct. I misused the phrase.

I stand by my reasoning, however.

>> Own decoder from where? Is it officially Dolby branded, or is this Apple 
>> again?
> 
> Their own decoder IP and reference tool; it's non-public, and it's what 
> Apple's is built on top of.

Most proprietary AC-3 decoders are, to my knowledge - it comes with the IP 
licensing
package or something. But the vendor (Apple) in this case, may change things. 
This is
why I specifically asked for Dolby branded or endorsed decoders - to my 
knowledge,
Apple's AudioToolbox is neither of those.

- Derek
___
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] avcodec/v4l2_m2m_enc: Support changing qmin/qmax

[Mark Thompson]

On 19/01/2020 19:54, Andriy Gelman wrote:
> From: Andriy Gelman 
> 
> Hard coded parameters for qmin and qmax are currently used to initialize
> v4l2_m2m device. This commit uses values from avctx->{qmin,qmax} if they
> are set.
> 
> Signed-off-by: Andriy Gelman 
> ---
>  libavcodec/v4l2_m2m_enc.c | 33 +++--
>  1 file changed, 31 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/v4l2_m2m_enc.c b/libavcodec/v4l2_m2m_enc.c
> index 8059e3bb48f..318be0d3379 100644
> --- a/libavcodec/v4l2_m2m_enc.c
> +++ b/libavcodec/v4l2_m2m_enc.c
> @@ -31,10 +31,25 @@
>  #include "v4l2_context.h"
>  #include "v4l2_m2m.h"
>  #include "v4l2_fmt.h"
> +#include "internal.h"
>  
>  #define MPEG_CID(x) V4L2_CID_MPEG_VIDEO_##x
>  #define MPEG_VIDEO(x) V4L2_MPEG_VIDEO_##x
>  
> +#define CLIP_MIN_MAX(in, min_val, max_val, name, logctx)\
> +do {\
> +if ((in) < (min_val)) { \
> +av_log((logctx), AV_LOG_WARNING,\
> +   "Adjusted: " name " (%d)\n", (min_val)); \
> +in = min_val;   \
> +}   \
> +if ((in) > (max_val)) { \
> +av_log((logctx), AV_LOG_WARNING,\
> +   "Adjusted: " name " (%d)\n", (max_val)); \
> +(in) = (max_val);   \
> +}   \
> +} while (0)
> +
>  static inline void v4l2_set_timeperframe(V4L2m2mContext *s, unsigned int 
> num, unsigned int den)
>  {
>  struct v4l2_streamparm parm = { 0 };
> @@ -232,8 +247,15 @@ static int v4l2_prepare_encoder(V4L2m2mContext *s)
>  return 0;
>  }
>  
> -if (qmin != avctx->qmin || qmax != avctx->qmax)
> -av_log(avctx, AV_LOG_WARNING, "Encoder adjusted: qmin (%d), qmax 
> (%d)\n", qmin, qmax);
> +if (avctx->qmin >= 0) {
> +CLIP_MIN_MAX(avctx->qmin, qmin, qmax, "qmin", avctx);
> +qmin = avctx->qmin;
> +}
> +
> +if (avctx->qmax >= 0) {
> +CLIP_MIN_MAX(avctx->qmax, qmin, qmax, "qmax", avctx);
> +qmax = avctx->qmax;
> +}
>  
>  v4l2_set_ext_ctrl(s, qmin_cid, qmin, "minimum video quantizer scale");
>  v4l2_set_ext_ctrl(s, qmax_cid, qmax, "maximum video quantizer scale");
> @@ -349,6 +371,12 @@ static const AVOption options[] = {
>  { NULL },
>  };
>  
> +static const AVCodecDefault v4l2_m2m_defaults[] = {
> +{ "qmin", "-1" },
> +{ "qmax", "-1" },
> +{ NULL },
> +};
> +
>  #define M2MENC_CLASS(NAME) \
>  static const AVClass v4l2_m2m_ ## NAME ## _enc_class = { \
>  .class_name = #NAME "_v4l2m2m_encoder", \
> @@ -370,6 +398,7 @@ static const AVOption options[] = {
>  .send_frame = v4l2_send_frame, \
>  .receive_packet = v4l2_receive_packet, \
>  .close  = v4l2_encode_close, \
> +.defaults   = v4l2_m2m_defaults, \
>  .capabilities   = AV_CODEC_CAP_HARDWARE | AV_CODEC_CAP_DELAY, \
>  .wrapper_name   = "v4l2m2m", \
>  };
> 

Can we avoid some of the clumsiness around clipping twice in different ways by 
querying the quantiser values from the encode device here?

E.g. on s5p-mfc (exynos) I can see:

  h264_minimum_qp_value 0x00990a61 (int): min=0 max=51 step=1 
default=1 value=1
  h264_maximum_qp_value 0x00990a62 (int): min=0 max=51 step=1 
default=51 value=51

which matches the expected values for 8-bit H.264, but then for VP8 there is:

   vpx_minimum_qp_value 0x00990afb (int): min=0 max=11 step=1 
default=0 value=0
   vpx_maximum_qp_value 0x00990afc (int): min=0 max=127 step=1 
default=127 value=127

which is going to pretty much entirely stop qmin from doing anything useful, 
and it would be nice to diagnose that.

- Mark
___
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/binkaudio: Check sample_rate to avoid integer overflow

[Michael Niedermayer]

On Sat, Feb 01, 2020 at 04:17:10PM +0100, Paul B Mahol wrote:
> On 2/1/20, Michael Niedermayer  wrote:
> > On Tue, Jan 14, 2020 at 04:04:29PM +0100, Paul B Mahol wrote:
> >> This better belong to generic code.
> >
> > This specific check (which checks for INT_MAX) is specific to our
> > bink audio code which does a +1
> > so it would not fit in generic code
> >
> > We could arbitrarily decide on a maximum sample rate hardcode that
> > and check for that in generic code.
> > I can implement that if people prefer. It would not avoid all
> > sample rate checks in codecs though ...
> 
> sample rate can not be > INT_MAX

no and the code also doesnt check > INT_MAX 
I think you maybe missed the = in >=
theres a +1 and INT_MAX+1 is bad so INT_MAX is checked for
we can do that in generic code but its only this decoder that has this
issue other decoders may have other limits. That makes this specific
check threshold bad for a check in generic code. Another threshold
would work in generic code, it would be arbitrary though and limit
most decoders more than needed
Iam happy to implement what people prefer but the check as it is
makes not much sense if its moved as is into generic code

Thanks

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

If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.


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".

[FFmpeg-devel] [PATCH 1/2] lavc/dvdsubdec: Move palette parsing to new function

[Michael Kuron]

Signed-off-by: Michael Kuron 
---
 doc/decoders.texi  |  2 +-
 libavcodec/Makefile|  1 +
 libavcodec/dvdsub.c| 33 +
 libavcodec/dvdsubdec.c | 22 ++
 libavcodec/internal.h  |  2 ++
 5 files changed, 43 insertions(+), 17 deletions(-)
 create mode 100644 libavcodec/dvdsub.c

diff --git a/doc/decoders.texi b/doc/decoders.texi
index 0582b018b0..83515ae363 100644
--- a/doc/decoders.texi
+++ b/doc/decoders.texi
@@ -280,7 +280,7 @@ palette is stored in the IFO file, and therefore not 
available when reading
 from dumped VOB files.
 
 The format for this option is a string containing 16 24-bits hexadecimal
-numbers (without 0x prefix) separated by comas, for example @code{0d00ee,
+numbers (without 0x prefix) separated by commas, for example @code{0d00ee,
 ee450d, 101010, eaeaea, 0ce60b, ec14ed, ebff0b, 0d617a, 7b7b7b, d1d1d1,
 7b2a0e, 0d950c, 0f007b, cf0dec, cfa80c, 7c127b}.
 
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 3cd73fbcc6..ddc923304a 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -282,6 +282,7 @@ OBJS-$(CONFIG_DST_DECODER) += dstdec.o dsd.o
 OBJS-$(CONFIG_DVBSUB_DECODER)  += dvbsubdec.o
 OBJS-$(CONFIG_DVBSUB_ENCODER)  += dvbsub.o
 OBJS-$(CONFIG_DVDSUB_DECODER)  += dvdsubdec.o
+OBJS-$(CONFIG_DVDSUB_DECODER)  += dvdsub.o
 OBJS-$(CONFIG_DVDSUB_ENCODER)  += dvdsubenc.o
 OBJS-$(CONFIG_DVAUDIO_DECODER) += dvaudiodec.o
 OBJS-$(CONFIG_DVVIDEO_DECODER) += dvdec.o dv.o dvdata.o
diff --git a/libavcodec/dvdsub.c b/libavcodec/dvdsub.c
new file mode 100644
index 00..a03ff27754
--- /dev/null
+++ b/libavcodec/dvdsub.c
@@ -0,0 +1,33 @@
+/*
+ * DVD subtitle decoding/encoding
+ * Copyright (c) 2005 Fabrice Bellard
+ *
+ * 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 "internal.h"
+#include "libavutil/avstring.h"
+#include 
+
+void ff_dvdsub_parse_palette(uint32_t *palette, const char *p)
+{
+for (int i = 0; i < 16; i++) {
+palette[i] = strtoul(p, &p, 16);
+while (*p == ',' || av_isspace(*p))
+p++;
+}
+}
diff --git a/libavcodec/dvdsubdec.c b/libavcodec/dvdsubdec.c
index 741ea9fd1e..bf49788e1b 100644
--- a/libavcodec/dvdsubdec.c
+++ b/libavcodec/dvdsubdec.c
@@ -27,7 +27,6 @@
 #include "libavutil/colorspace.h"
 #include "libavutil/opt.h"
 #include "libavutil/imgutils.h"
-#include "libavutil/avstring.h"
 #include "libavutil/bswap.h"
 
 typedef struct DVDSubContext
@@ -626,18 +625,6 @@ static int dvdsub_decode(AVCodecContext *avctx,
 return buf_size;
 }
 
-static void parse_palette(DVDSubContext *ctx, char *p)
-{
-int i;
-
-ctx->has_palette = 1;
-for(i=0;i<16;i++) {
-ctx->palette[i] = strtoul(p, &p, 16);
-while(*p == ',' || av_isspace(*p))
-p++;
-}
-}
-
 static int parse_ifo_palette(DVDSubContext *ctx, char *p)
 {
 FILE *ifo;
@@ -719,7 +706,8 @@ static int dvdsub_parse_extradata(AVCodecContext *avctx)
 break;
 
 if (strncmp("palette:", data, 8) == 0) {
-parse_palette(ctx, data + 8);
+ctx->has_palette = 1;
+ff_dvdsub_parse_palette(ctx->palette, data + 8);
 } else if (strncmp("size:", data, 5) == 0) {
 int w, h;
 if (sscanf(data + 5, "%dx%d", &w, &h) == 2) {
@@ -748,8 +736,10 @@ static av_cold int dvdsub_init(AVCodecContext *avctx)
 
 if (ctx->ifo_str)
 parse_ifo_palette(ctx, ctx->ifo_str);
-if (ctx->palette_str)
-parse_palette(ctx, ctx->palette_str);
+if (ctx->palette_str) {
+ctx->has_palette = 1;
+ff_dvdsub_parse_palette(ctx->palette, ctx->palette_str);
+}
 if (ctx->has_palette) {
 int i;
 av_log(avctx, AV_LOG_DEBUG, "palette:");
diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index 5096ffa1d9..41281b1140 100644
--- a/libavcodec/internal.h
+++ b/libavcodec/internal.h
@@ -424,6 +424,8 @@ int64_t ff_guess_coded_bitrate(AVCodecContext *avctx);
 int ff_int_from_list_or_default(void *ctx, const char * val_name, int val,
 const int * array_valid_values, int 
default_value);
 
+void ff_dvdsub_parse_palette(uint32_t *palette, const char *p);
+
 #if defined(_WIN32)

[FFmpeg-devel] [PATCH 2/2] lavc/dvdsubenc: accept palette from options

[Michael Kuron]

Previously, the default palette would always be used.
Now, we can accept a custom palette, just like dvdsubdec does.

Signed-off-by: Michael Kuron 
---
 doc/encoders.texi  | 8 
 libavcodec/Makefile| 1 +
 libavcodec/dvdsubenc.c | 8 +++-
 3 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/doc/encoders.texi b/doc/encoders.texi
index eefd124751..a04f9f1b62 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -3116,6 +3116,14 @@ and they can also be used in Matroska files.
 @subsection Options
 
 @table @option
+@item palette
+Specify the global palette used by the bitmaps.
+
+The format for this option is a string containing 16 24-bits hexadecimal
+numbers (without 0x prefix) separated by commas, for example @code{0d00ee,
+ee450d, 101010, eaeaea, 0ce60b, ec14ed, ebff0b, 0d617a, 7b7b7b, d1d1d1,
+7b2a0e, 0d950c, 0f007b, cf0dec, cfa80c, 7c127b}.
+
 @item even_rows_fix
 When set to 1, enable a work-around that makes the number of pixel rows
 even in all subtitles.  This fixes a problem with some players that
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index ddc923304a..71ee8caeb3 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -284,6 +284,7 @@ OBJS-$(CONFIG_DVBSUB_ENCODER)  += dvbsub.o
 OBJS-$(CONFIG_DVDSUB_DECODER)  += dvdsubdec.o
 OBJS-$(CONFIG_DVDSUB_DECODER)  += dvdsub.o
 OBJS-$(CONFIG_DVDSUB_ENCODER)  += dvdsubenc.o
+OBJS-$(CONFIG_DVDSUB_ENCODER)  += dvdsub.o
 OBJS-$(CONFIG_DVAUDIO_DECODER) += dvaudiodec.o
 OBJS-$(CONFIG_DVVIDEO_DECODER) += dvdec.o dv.o dvdata.o
 OBJS-$(CONFIG_DVVIDEO_ENCODER) += dvenc.o dv.o dvdata.o
diff --git a/libavcodec/dvdsubenc.c b/libavcodec/dvdsubenc.c
index ff95ed2002..e54b5f0d7b 100644
--- a/libavcodec/dvdsubenc.c
+++ b/libavcodec/dvdsubenc.c
@@ -29,6 +29,7 @@
 typedef struct {
 AVClass *class;
 uint32_t global_palette[16];
+char *palette_str;
 int even_rows_fix;
 } DVDSubtitleContext;
 
@@ -436,7 +437,11 @@ static int dvdsub_init(AVCodecContext *avctx)
 int i, ret;
 
 av_assert0(sizeof(dvdc->global_palette) == sizeof(default_palette));
-memcpy(dvdc->global_palette, default_palette, 
sizeof(dvdc->global_palette));
+if (dvdc->palette_str) {
+ff_dvdsub_parse_palette(dvdc->global_palette, dvdc->palette_str);
+} else {
+memcpy(dvdc->global_palette, default_palette, 
sizeof(dvdc->global_palette));
+}
 
 av_bprint_init(&extradata, 0, AV_BPRINT_SIZE_AUTOMATIC);
 if (avctx->width && avctx->height)
@@ -467,6 +472,7 @@ static int dvdsub_encode(AVCodecContext *avctx,
 #define OFFSET(x) offsetof(DVDSubtitleContext, x)
 #define SE AV_OPT_FLAG_SUBTITLE_PARAM | AV_OPT_FLAG_ENCODING_PARAM
 static const AVOption options[] = {
+{"palette", "set the global palette", OFFSET(palette_str), 
AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, SE },
 {"even_rows_fix", "Make number of rows even (workaround for some 
players)", OFFSET(even_rows_fix), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, SE},
 { NULL },
 };
-- 
2.24.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 v3] doc/v4l2_m2m: Add documentation

[Mark Thompson]

On 17/01/2020 03:42, Andriy Gelman wrote:
> From: Andriy Gelman 
> 
> Signed-off-by: Andriy Gelman 
> ---
> 
> Gyan, I added an extra paragraph about the buffer parameters. It doesn't seem
> right to add the same content into each bullet point. Let me know your 
> thoughts. 

The discussion of them could go in general.texi instead?

It might be worth mentioning at the same time that you need recentish linux 
kernel headers installed to build.

>  doc/decoders.texi | 32 +
>  doc/encoders.texi | 51 +++
>  2 files changed, 83 insertions(+)
> 
> diff --git a/doc/decoders.texi b/doc/decoders.texi
> index f18226b3504..22a587ffdb9 100644
> --- a/doc/decoders.texi
> +++ b/doc/decoders.texi
> @@ -86,6 +86,38 @@ AVS2-P2/IEEE1857.4 video decoder wrapper.
>  
>  This decoder allows libavcodec to decode AVS2 streams with davs2 library.
>  
> +@section v4l2m2m
> +
> +libavcodec supports a set of v4l2m2m wrappers for interfacing with
> +hardware decoders. Depending on the hardware's capabilities the following 
> decoders may be selected:
> +h264, hevc, mpeg1, mpeg2, mpeg4, h263, vc1, vp8, and vp9.
> +
> +To use a specific decoder append a  _v4l2m2m suffix. For example to select 
> h264
> +decoder use:
> +@example
> +ffmpeg -codec:v h264_v4l2m2m -i INPUT OUTPUT
> +@end example
> +
> +libavcodec also supports changing the number of output and capture buffers on
> +the v4l2m2m device. If the API is used as per the recommendation, there 
> should
> +be no reason to change the parameters from the default values. The 
> description
> +of the parameters is as follows:
> +
> +@table @option
> +@item num_output_buffers
> +Number of memory mapped buffers to store the input packets. This value is 
> only a
> +suggestion to the hardware device. The device will attempt to allocate the
> +number of buffers, but the actual value may be smaller/larger and ultimately
> +depends on the device. The default for the option is 16, minimum is 6, and 
> any
> +large value (representable by an int) is accepted for the max.> +
> +@item num_capture_buffers
> +Number of memory mapped buffers to store the decompressed frames. The device
> +will attempt to allocate the number of buffers, but the actual value may be
> +smaller/larger and ultimately depends on the device. Default is 20, minimum 
> is
> +20, and any large value (representable by an int) is accepted for the max.
> +@end table

I wonder whether it would be more helpful to explain /why/ these values are 
exposed.

There are four factors competing here:
1) Reordering in the stream, if the decoder is returning reference frame 
buffers directly without any extra copies.  (This was what drove the choice of 
the default value.)
2) Allowing extra buffers that the user can hold on to outside the decoder 
without blocking forward progress.
3) Possible parallelism in the decoder, which may be able to increase 
single-stream throughput by using more buffers.
4) Minimising the amount of memory being used.

So: it's possible that a larger value may be required for some weird streams 
(not necessarily detectable in advance), while in many (most, even) cases quite 
a bit of memory can be saved by decreasing the numbers.

> +
>  @c man end VIDEO DECODERS
>  
>  @chapter Audio Decoders
> diff --git a/doc/encoders.texi b/doc/encoders.texi
> index 61e674cf968..f82500ca34c 100644
> --- a/doc/encoders.texi
> +++ b/doc/encoders.texi
> @@ -3117,6 +3117,57 @@ required to produce a stream usable with all decoders.
>  
>  @end table
>  
> +@section v4l2m2m
> +
> +libavcodec supports a set of v4l2m2m wrappers for interfacing with hardware 
> encoders.
> +Depending on the hardware's capabilities the following encoders may be 
> selected:
> +mpeg4, h263, h264, hevc, and vp8.
> +
> +To use a specific encoder append _v4l2m2m suffix. For example to select h264 
> use:
> +@example
> +ffmpeg -i INPUT [-pix_fmt pixfmt] -codec:v h264_v4l2m2m OUTPUT
> +@end example
> +In some cases, it may be necessary to insert a pixel format conversion with
> +@code{-pix_fmt}. This is required if the pixel format of the input does not
> +match the format of the encoder. If there is a mismatch, libavcodec will
> +exit and specify the required pixfmt to use.
> +
> +Standard libavcodec options (encoder and device dependent) that can be set 
> are:
> +@itemize
> +@item
> +@option{b} / @option{bit_rate}
> +@item
> +@option{g} / @option{gop_size}
> +@item
> +@option{bf} / @option{max_b_frames}
> +@item
> +@option{qpel}
> +@item
> +@option{qmin}
> +@item
> +@option{qmax}
> +@end itemize

Also profile.

> +
> +libavcodec also supports changing the number of output and capture buffers
> +on the v4l2m2m device. If the API is used as per the recommendation, there
> +should be no reason to change the parameters from the default values. The
> +description of the parameters is as follows:
> +
> +@table @option
> +@item num_output_buffers
> +Number of memory mapped buffers to store t

Re: [FFmpeg-devel] [PATCH] avcodec/adpcm_argo: simplify and move duplicated logic into a function

[Zane van Iperen]

2/2/20 4:04 am, Michael Niedermayer пишет:
> 
> On Sat, Feb 01, 2020 at 06:59:59AM +, Zane van Iperen wrote:
>> Signed-off-by: Zane van Iperen 
>> ---
>>   libavcodec/adpcm.c | 40 ++--
>>   1 file changed, 18 insertions(+), 22 deletions(-)
> 
> it seems theres no fate test for adpcm_argo
> this patch looks ok but the codepath seems untested, maybe you can add a test 
> ?
> 

I can. Would it best be send as a v2, or as a separate patch completely?

In the meantime, this patch doesn't break anything, as it passes my usual 
checks.
These are the files that gave the most grief when writing the decoder and I
know their expected hashes.

$ ./ffmpeg -loglevel error -i OUTRO.ASF -map 0:a -f md5 -
MD5=e0428a6c55382f48502f04b3a7f7b94b

$ ./ffmpeg -loglevel error -i CBK2.asf -map 0:a -f md5 -
MD5=589f3f3c518e5d58aa404b7576db5b70



> thx
> 
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> I am the wisest man alive, for I know one thing, and that is that I know
> nothing. -- Socrates
> ___
> 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".
> 

Zane

___
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 4/4] avcodec/ac3dec_fixed: Remove some temporary variables from scale_coefs()

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 libavcodec/ac3dec_fixed.c | 30 --
 1 file changed, 8 insertions(+), 22 deletions(-)

diff --git a/libavcodec/ac3dec_fixed.c b/libavcodec/ac3dec_fixed.c
index 1e1edc8964..336a538cad 100644
--- a/libavcodec/ac3dec_fixed.c
+++ b/libavcodec/ac3dec_fixed.c
@@ -110,28 +110,14 @@ static void scale_coefs (
   mul <<= shift;
   for (i=0; ihttps://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH 3/4] avcodec/mlpdsp: Fix a invalid shift in ff_mlp_rematrix_channel()

[Michael Niedermayer]

Fixes: left shift of negative value -2
Fixes: 
20305/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TRUEHD_fuzzer-5677196618498048

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

diff --git a/libavcodec/mlpdsp.c b/libavcodec/mlpdsp.c
index 32a4503b64..12bef3a721 100644
--- a/libavcodec/mlpdsp.c
+++ b/libavcodec/mlpdsp.c
@@ -79,7 +79,7 @@ void ff_mlp_rematrix_channel(int32_t *samples,
 
 if (matrix_noise_shift) {
 index &= access_unit_size_pow2 - 1;
-accum += noise_buffer[index] << (matrix_noise_shift + 7);
+accum += noise_buffer[index] * (1 << (matrix_noise_shift + 7));
 index += index2;
 }
 
-- 
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".

[FFmpeg-devel] [PATCH 1/4] avcodec/ac3dec_fixed: Fix several invalid left shifts in scale_coefs()

[Michael Niedermayer]

Fixes: left shift of negative value -14336
Fixes: 
20298/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AC3_FIXED_fuzzer-5675484201615360

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

diff --git a/libavcodec/ac3dec_fixed.c b/libavcodec/ac3dec_fixed.c
index bd66175d50..1e1edc8964 100644
--- a/libavcodec/ac3dec_fixed.c
+++ b/libavcodec/ac3dec_fixed.c
@@ -107,29 +107,30 @@ static void scale_coefs (
   }
 } else {
   shift = -shift;
+  mul <<= shift;
   for (i=0; ihttps://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/4] avcodec/flacdsp_template: Fix invalid shifts in decorrelate

[Michael Niedermayer]

Fixes: left shift of negative value -2
Fixes: 
20303/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FLAC_fuzzer-5096829297623040

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

diff --git a/libavcodec/flacdsp_template.c b/libavcodec/flacdsp_template.c
index 776c78da71..892418cddc 100644
--- a/libavcodec/flacdsp_template.c
+++ b/libavcodec/flacdsp_template.c
@@ -66,8 +66,8 @@ static void FUNC(flac_decorrelate_ls_c)(uint8_t **out, 
int32_t **in,
 int i;
 
 for (i = 0; i < len; i++) {
-int a = in[0][i];
-int b = in[1][i];
+unsigned a = in[0][i];
+unsigned b = in[1][i];
 S(samples, 0, i) =  a  << shift;
 S(samples, 1, i) = (a - b) << shift;
 }
@@ -80,8 +80,8 @@ static void FUNC(flac_decorrelate_rs_c)(uint8_t **out, 
int32_t **in,
 int i;
 
 for (i = 0; i < len; i++) {
-int a = in[0][i];
-int b = in[1][i];
+unsigned a = in[0][i];
+unsigned b = in[1][i];
 S(samples, 0, i) = (a + b) << shift;
 S(samples, 1, i) =  b  << shift;
 }
@@ -94,7 +94,7 @@ static void FUNC(flac_decorrelate_ms_c)(uint8_t **out, 
int32_t **in,
 int i;
 
 for (i = 0; i < len; i++) {
-int a = in[0][i];
+unsigned a = in[0][i];
 int b = in[1][i];
 a -= b >> 1;
 S(samples, 0, i) = (a + b) << shift;
-- 
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".

[FFmpeg-devel] [PATCH 1/1] libswscale: add area upscale

[Pavel Klimov]

area upscale is similar to neighbor upscale,
just better with non integer factors.
math comes from assumption that
neighbor filter works fine,
and then integrate it over pixel width.

Signed-off-by: Pavel Klimov 
---
 libswscale/options.c |  1 +
 libswscale/swscale.h |  1 +
 libswscale/utils.c   | 30 +-
 3 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/libswscale/options.c b/libswscale/options.c
index 7eb2752543..bbf71997fb 100644
--- a/libswscale/options.c
+++ b/libswscale/options.c
@@ -41,6 +41,7 @@ static const AVOption swscale_options[] = {
 { "experimental","experimental",  0, 
AV_OPT_TYPE_CONST,  { .i64  = SWS_X  }, INT_MIN, INT_MAX,
VE, "sws_flags" },
 { "neighbor","nearest neighbor",  0, 
AV_OPT_TYPE_CONST,  { .i64  = SWS_POINT  }, INT_MIN, INT_MAX,
VE, "sws_flags" },
 { "area","averaging area",0, 
AV_OPT_TYPE_CONST,  { .i64  = SWS_AREA   }, INT_MIN, INT_MAX,
VE, "sws_flags" },
+{ "area_upscale","averaging area upscale",0, 
AV_OPT_TYPE_CONST,  { .i64  = SWS_AREA_UPSCALE   }, INT_MIN, INT_MAX,
VE, "sws_flags" },
 { "bicublin","luma bicubic, chroma bilinear", 0, 
AV_OPT_TYPE_CONST,  { .i64  = SWS_BICUBLIN   }, INT_MIN, INT_MAX,
VE, "sws_flags" },
 { "gauss",   "Gaussian",  0, 
AV_OPT_TYPE_CONST,  { .i64  = SWS_GAUSS  }, INT_MIN, INT_MAX,
VE, "sws_flags" },
 { "sinc","sinc",  0, 
AV_OPT_TYPE_CONST,  { .i64  = SWS_SINC   }, INT_MIN, INT_MAX,
VE, "sws_flags" },
diff --git a/libswscale/swscale.h b/libswscale/swscale.h
index 7713f51ec6..1d677e0a94 100644
--- a/libswscale/swscale.h
+++ b/libswscale/swscale.h
@@ -66,6 +66,7 @@ const char *swscale_license(void);
 #define SWS_SINC  0x100
 #define SWS_LANCZOS   0x200
 #define SWS_SPLINE0x400
+#define SWS_AREA_UPSCALE  0x800
 
 #define SWS_SRC_V_CHR_DROP_MASK 0x3
 #define SWS_SRC_V_CHR_DROP_SHIFT16
diff --git a/libswscale/utils.c b/libswscale/utils.c
index b2c08a5983..b713c40812 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -316,6 +316,7 @@ typedef struct {
 
 static const ScaleAlgorithm scale_algorithms[] = {
 { SWS_AREA,  "area averaging",  1 /* downscale 
only, for upscale it is bilinear */ },
+{ SWS_AREA_UPSCALE,  "area averaging upscale",  1 },
 { SWS_BICUBIC,   "bicubic", 4 },
 { SWS_BICUBLIN,  "luma bicubic / chroma bilinear", -1 },
 { SWS_BILINEAR,  "bilinear",2 },
@@ -398,6 +399,32 @@ static av_cold int initFilter(int16_t **outFilter, int32_t 
**filterPos,
 }
 xDstInSrc += xInc;
 }
+} else if (xInc <= (1 << 16) && (flags & SWS_AREA_UPSCALE)) { // area 
upscale
+int i;
+int64_t xDstInSrc;
+double dInc, x, x1;
+
+filterSize = 2;
+FF_ALLOC_ARRAY_OR_GOTO(NULL, filter,
+   dstW, sizeof(*filter) * filterSize, fail);
+
+xDstInSrc = ((dstPos*(int64_t)xInc)>>8) - ((srcPos*0x8000LL)>>7);
+
+xDstInSrc += (1 << 15) - xInc / 2;
+dInc = (double)srcW / dstW * (1 << 16);
+for (i = 0; i < dstW; i++) {
+x = i * dInc;
+
+(*filterPos)[i] = (xDstInSrc + (int)x) >> 16;
+x1 = xDstInSrc - ((*filterPos)[i] << 16) + x;
+if (x1 + dInc <= (1 << 16)) {
+filter[i * filterSize + 0] = fone;
+filter[i * filterSize + 1] = 0;
+} else {
+filter[i * filterSize + 0] = fone * (((1 << 16) - x1) / dInc);
+filter[i * filterSize + 1] = fone - filter[i * filterSize + 0];
+}
+}
 } else {
 int64_t xDstInSrc;
 int sizeFactor = -1;
@@ -471,7 +498,7 @@ static av_cold int initFilter(int16_t **outFilter, int32_t 
**filterPos,
 else
 c = pow(c, A);
 coeff = (c * 0.5 + 0.5) * fone;
-} else if (flags & SWS_AREA) {
+} else if (flags & (SWS_AREA | SWS_AREA_UPSCALE)) {
 int64_t d2 = d - (1 << 29);
 if (d2 * xInc < -(1LL << (29 + 16)))
 coeff = 1.0 * (1LL << (30 + 16));
@@ -1229,6 +1256,7 @@ av_cold int sws_init_context(SwsContext *c, SwsFilter 
*srcFilter,
 
 i = flags & (SWS_POINT |
  SWS_AREA  |
+ SWS_AREA_UPSCALE  |
  SWS_BILINEAR  |
  SWS_FAST_BILINEAR |
  SWS_BICUBIC   |
-- 
2.17.0.windows.1

___
ffmpeg-devel mailing l

[FFmpeg-devel] [PATCH 0/1] libswscale: add area upscale

[Pavel Klimov]

I often encode pixelated videos from old game consoles emulators.
Usual workaround is upscale with neighbor, or exceeding upscale
followed by lanczos downscale. I knew that area upscale should
give similar effect, but didn't take effort to find out why ffmpeg
with area method doesn't give what I expected to see.
Up until recently.

Recently I did check sources to find out what is going on.
And I found in sources comment that area method falls into bilinear
when it's used for upscale. First thing I thought was: not implemented?
So, just for fun I tried to implement it. Why not? - I thought.

It was a bit challenging, because main function that makes coefficients
is using fixed point arithmetics and has no info about its units.
Also srcPos and dstPos initial values are not described.
Eventually, I just used approach where I don't really need to know much.

Idea is following. In area representation, any point is covered
by color of nearest pixel of source image. So, I just need to
integrate nearest neighbor formula over pixel width. Taking into
assumption that nearest neighborhood is correct, I integrated it.
And it worked. At least as I thought.

Then, I made python script using fractions with built-in big integers
to have perfect area upscale for reference. And made test images.
Also I made script for image comparison. It turned out that image
comming from ffmpeg is off by 4 for some pixels. So I made log of
resulting coefficients, and also made script that does same in python.
It turned out that only 4 most significant decimal digits of integer
coefficients were right. (by the way they are 53 bits of int64_t)

During some of this, I figured out that xInc is rounded fixed
point 16.16 width of pixel. So, assuming that xInc is always
calculated same, I made similar dInc but using type double,
and changed formulas taking it into account. After change
into doubles, only two least significant decimal digits were wrong.

Next, when it was working fine I thought about sharing patch
and read about fate. I've made fate, and it failed.
I didn't mention before, but I was changing existing area upscale
to not fall into bilinear and make it upscale using area method.
Here is list of failed testcases using -k switch:

hevc-paramchange-yuv420p-yuv420p10
vsynth_lena-dv-411
vsynth_lena-dnxhd-edge3-hr
vsynth_lena-dnxhd-edge2-hr
vsynth_lena-dnxhd-edge1-hr
vsynth2-dv-411
vsynth2-dnxhd-edge3-hr
vsynth2-dnxhd-edge2-hr
vsynth2-dnxhd-edge1-hr
vsynth1-dv-411
vsynth1-dnxhd-edge3-hr
vsynth1-dnxhd-edge2-hr
vsynth1-dnxhd-edge1-hr

First thoughts: why do you incorporate rescale into other stuff?
Why don't you use sources as is. But after a bit of thinking,
it didn't matter anymore. Yes you could change references and
behavior of scaling, but it doesn't fit usual cases.

Area scaling falling into bilinear upscale makes sense.
Usually you don't know for sure will you do upscale or downscale.
Or, at least you don't want to care about it. And current behavior
with area scale is win-win: if downscale - area is better,
if upscale - bilinear is better for normal video that you don't
want to be pixelated. Also, image often has planes of different size.
So, I switched to separate option falling into area downscale.

Oh, by the way. Area upscale is identical to theoretical upscale
to infinity by nearest neighbor followed by downscale by area.
But neither holds for neighbor upscale to infinity followed
by lanczos/neighbor downscale to target.

In short. I have:
1) fixed arithmetic version with bad precision
2) python perfect version, coefficients generator
3) floating point version with good precision

I don't insist on addition of area upscale method.
But if you like the idea of having it, then I could probably assist.

I provide patch that modify libswscale, because it was easiest
approach for me. Also, it naturally fits in there.

Any suggestions appreciated.

Things to consider:
Appropriate place: libswscale / .gitignore ?
Name: area-only, area-all, area-both, area-forced, area-up...
Fixed arithmetic / floating point version
Should I include change in docs at once, or in separate commit?
Should I add test in fate? I don't see lanczos or gauss tests.

Pavel Klimov (1):
  libswscale: add area upscale

 libswscale/options.c |  1 +
 libswscale/swscale.h |  1 +
 libswscale/utils.c   | 30 +-
 3 files changed, 31 insertions(+), 1 deletion(-)

-- 
2.17.0.windows.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 v2] avcodec/v4l2_m2m_enc: Support changing qmin/qmax

[Andriy Gelman]

On Sat, 01. Feb 22:38, Mark Thompson wrote:
> On 19/01/2020 19:54, Andriy Gelman wrote:
> > From: Andriy Gelman 
> > 
> > Hard coded parameters for qmin and qmax are currently used to initialize
> > v4l2_m2m device. This commit uses values from avctx->{qmin,qmax} if they
> > are set.
> > 
> > Signed-off-by: Andriy Gelman 
> > ---
> >  libavcodec/v4l2_m2m_enc.c | 33 +++--
> >  1 file changed, 31 insertions(+), 2 deletions(-)
> > 
> > diff --git a/libavcodec/v4l2_m2m_enc.c b/libavcodec/v4l2_m2m_enc.c
> > index 8059e3bb48f..318be0d3379 100644
> > --- a/libavcodec/v4l2_m2m_enc.c
> > +++ b/libavcodec/v4l2_m2m_enc.c
> > @@ -31,10 +31,25 @@
> >  #include "v4l2_context.h"
> >  #include "v4l2_m2m.h"
> >  #include "v4l2_fmt.h"
> > +#include "internal.h"
> >  
> >  #define MPEG_CID(x) V4L2_CID_MPEG_VIDEO_##x
> >  #define MPEG_VIDEO(x) V4L2_MPEG_VIDEO_##x
> >  
> > +#define CLIP_MIN_MAX(in, min_val, max_val, name, logctx)\
> > +do {\
> > +if ((in) < (min_val)) { \
> > +av_log((logctx), AV_LOG_WARNING,\
> > +   "Adjusted: " name " (%d)\n", (min_val)); \
> > +in = min_val;   \
> > +}   \
> > +if ((in) > (max_val)) { \
> > +av_log((logctx), AV_LOG_WARNING,\
> > +   "Adjusted: " name " (%d)\n", (max_val)); \
> > +(in) = (max_val);   \
> > +}   \
> > +} while (0)
> > +
> >  static inline void v4l2_set_timeperframe(V4L2m2mContext *s, unsigned int 
> > num, unsigned int den)
> >  {
> >  struct v4l2_streamparm parm = { 0 };
> > @@ -232,8 +247,15 @@ static int v4l2_prepare_encoder(V4L2m2mContext *s)
> >  return 0;
> >  }
> >  
> > -if (qmin != avctx->qmin || qmax != avctx->qmax)
> > -av_log(avctx, AV_LOG_WARNING, "Encoder adjusted: qmin (%d), qmax 
> > (%d)\n", qmin, qmax);
> > +if (avctx->qmin >= 0) {
> > +CLIP_MIN_MAX(avctx->qmin, qmin, qmax, "qmin", avctx);
> > +qmin = avctx->qmin;
> > +}
> > +
> > +if (avctx->qmax >= 0) {
> > +CLIP_MIN_MAX(avctx->qmax, qmin, qmax, "qmax", avctx);
> > +qmax = avctx->qmax;
> > +}
> >  
> >  v4l2_set_ext_ctrl(s, qmin_cid, qmin, "minimum video quantizer scale");
> >  v4l2_set_ext_ctrl(s, qmax_cid, qmax, "maximum video quantizer scale");
> > @@ -349,6 +371,12 @@ static const AVOption options[] = {
> >  { NULL },
> >  };
> >  
> > +static const AVCodecDefault v4l2_m2m_defaults[] = {
> > +{ "qmin", "-1" },
> > +{ "qmax", "-1" },
> > +{ NULL },
> > +};
> > +
> >  #define M2MENC_CLASS(NAME) \
> >  static const AVClass v4l2_m2m_ ## NAME ## _enc_class = { \
> >  .class_name = #NAME "_v4l2m2m_encoder", \
> > @@ -370,6 +398,7 @@ static const AVOption options[] = {
> >  .send_frame = v4l2_send_frame, \
> >  .receive_packet = v4l2_receive_packet, \
> >  .close  = v4l2_encode_close, \
> > +.defaults   = v4l2_m2m_defaults, \
> >  .capabilities   = AV_CODEC_CAP_HARDWARE | AV_CODEC_CAP_DELAY, \
> >  .wrapper_name   = "v4l2m2m", \
> >  };
> > 

> 
> Can we avoid some of the clumsiness around clipping twice in different ways 
> by querying the quantiser values from the encode device here?
> 

thanks, I'll investigate.

> E.g. on s5p-mfc (exynos) I can see:
> 
>   h264_minimum_qp_value 0x00990a61 (int): min=0 max=51 step=1 
> default=1 value=1
>   h264_maximum_qp_value 0x00990a62 (int): min=0 max=51 step=1 
> default=51 value=51
> 
> which matches the expected values for 8-bit H.264, but then for VP8 there is:
> 
>vpx_minimum_qp_value 0x00990afb (int): min=0 max=11 step=1 
> default=0 value=0
>vpx_maximum_qp_value 0x00990afc (int): min=0 max=127 step=1 
> default=127 value=127
> 
> which is going to pretty much entirely stop qmin from doing anything useful, 
> and it would be nice to diagnose that.

The max for vpx_maximum_qp_value has been bothering me. The usual qp range for 
vp8/9 is [0,63]. 

I checked today with a dev on #v4l and he told me that only 6 bits are used in
the driver so it's probably a bug. I'll look into this further. 

On a related note, I actually haven't been able to play a stream that's been
compressed with vp8/9 on the s5p-mfc (odroid xu4 for me). Have you had any
luck? 

Andriy
___
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 v1] avformat/sdp, rtsp: add rtcp attribute to sdp file

[Jun Li]

Fix #8479
1. write rtcpport to sdp file when rtpport is specified in url
2. apply rtcpport when sdp file contains rtcp attribute

Signed-off-by: Jun Li 
---
 libavformat/rtpproto.c | 11 +++
 libavformat/rtpproto.h |  2 ++
 libavformat/rtsp.c | 12 ++--
 libavformat/rtsp.h |  1 +
 libavformat/sdp.c  | 12 ++--
 5 files changed, 34 insertions(+), 4 deletions(-)

diff --git a/libavformat/rtpproto.c b/libavformat/rtpproto.c
index 1f0a82ac7e..81a39cc3de 100644
--- a/libavformat/rtpproto.c
+++ b/libavformat/rtpproto.c
@@ -524,6 +524,17 @@ int ff_rtp_get_local_rtp_port(URLContext *h)
 return ff_udp_get_local_port(s->rtp_hd);
 }
 
+/**
+ * Return the remote rtcp port used by the RTP connection
+ * @param h media file context
+ * @return the remote port number
+ */
+int ff_rtp_get_remote_rtcp_port(URLContext *h)
+{
+RTPContext *s = h->priv_data;
+return s->rtcp_port;
+}
+
 /**
  * Return the local rtcp port used by the RTP connection
  * @param h media file context
diff --git a/libavformat/rtpproto.h b/libavformat/rtpproto.h
index 131aac5f3c..d42327ea5c 100644
--- a/libavformat/rtpproto.h
+++ b/libavformat/rtpproto.h
@@ -27,4 +27,6 @@ int ff_rtp_set_remote_url(URLContext *h, const char *uri);
 
 int ff_rtp_get_local_rtp_port(URLContext *h);
 
+int ff_rtp_get_remote_rtcp_port(URLContext *h);
+
 #endif /* AVFORMAT_RTPPROTO_H */
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index cd6fc32a29..c892f21142 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -577,6 +577,10 @@ static void sdp_parse_line(AVFormatContext *s, 
SDPParseState *s1,
 if (s1->seen_fmtp) {
 parse_fmtp(s, rt, payload_type, s1->delayed_fmtp);
 }
+} else if (av_strstart(p, "rtcp:", &p) && s->nb_streams > 0) {
+rtsp_st = rt->rtsp_streams[rt->nb_rtsp_streams - 1];
+get_word(buf1, sizeof(buf1), &p);
+rtsp_st->rtcp_port = strtol(buf1, NULL, 10);
 } else if (av_strstart(p, "fmtp:", &p) ||
av_strstart(p, "framesize:", &p)) {
 // let dynamic protocol handlers have a stab at the line.
@@ -2367,6 +2371,7 @@ static int sdp_read_header(AVFormatContext *s)
 
 if (!(rt->rtsp_flags & RTSP_FLAG_CUSTOM_IO)) {
 AVDictionary *opts = map_to_opts(rt);
+int rtcp_port = rtsp_st->rtcp_port;
 
 err = getnameinfo((struct sockaddr*) &rtsp_st->sdp_ip,
   sizeof(rtsp_st->sdp_ip),
@@ -2377,10 +2382,13 @@ static int sdp_read_header(AVFormatContext *s)
 av_dict_free(&opts);
 goto fail;
 }
+
+if (rtcp_port <= 0)
+rtcp_port = rtsp_st->sdp_port + 1;
 ff_url_join(url, sizeof(url), "rtp", NULL,
 namebuf, rtsp_st->sdp_port,
-"?localport=%d&ttl=%d&connect=%d&write_to_source=%d",
-rtsp_st->sdp_port, rtsp_st->sdp_ttl,
+
"?localport=%d&localrtcpport=%d&ttl=%d&connect=%d&write_to_source=%d",
+rtsp_st->sdp_port, rtcp_port, rtsp_st->sdp_ttl,
 rt->rtsp_flags & RTSP_FLAG_FILTER_SRC ? 1 : 0,
 rt->rtsp_flags & RTSP_FLAG_RTCP_TO_SOURCE ? 1 : 0);
 
diff --git a/libavformat/rtsp.h b/libavformat/rtsp.h
index 54a9a30c16..15747fe6d1 100644
--- a/libavformat/rtsp.h
+++ b/libavformat/rtsp.h
@@ -448,6 +448,7 @@ typedef struct RTSPStream {
 /** The following are used only in SDP, not RTSP */
 //@{
 int sdp_port; /**< port (from SDP content) */
+int rtcp_port;/**< rtcp port (from SDP content) */
 struct sockaddr_storage sdp_ip; /**< IP address (from SDP content) */
 int nb_include_source_addrs; /**< Number of source-specific multicast 
include source IP addresses (from SDP content) */
 struct RTSPSource **include_source_addrs; /**< Source-specific multicast 
include source IP addresses (from SDP content) */
diff --git a/libavformat/sdp.c b/libavformat/sdp.c
index 34e9839b67..c3c2909090 100644
--- a/libavformat/sdp.c
+++ b/libavformat/sdp.c
@@ -26,11 +26,13 @@
 #include "libavutil/opt.h"
 #include "libavcodec/xiph.h"
 #include "libavcodec/mpeg4audio.h"
+#include "avio_internal.h"
 #include "avformat.h"
 #include "internal.h"
 #include "avc.h"
 #include "hevc.h"
 #include "rtp.h"
+#include "rtpproto.h"
 #if CONFIG_NETWORK
 #include "network.h"
 #endif
@@ -480,10 +482,16 @@ static char *latm_context2config(AVFormatContext *s, 
AVCodecParameters *par)
 return config;
 }
 
-static char *sdp_write_media_attributes(char *buff, int size, AVStream *st, 
int payload_type, AVFormatContext *fmt)
+static char *sdp_write_media_attributes(char *buff, int size, AVStream *st, 
int payload_type, AVFormatContext *fmt, int port)
 {
 char *config = NULL;
 AVCodecParameters *p = st->codecpar;
+URLContext* url_ctx = ffio_geturlcontext(fmt->pb);
+if (url_ctx) {
+ 

Re: [FFmpeg-devel] [PATCH V2] fate/filter-video.mak: do not use bit-exact check for dnn_processing

[Guo, Yejun]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Carl Eugen Hoyos
> Sent: Sunday, February 02, 2020 12:13 AM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH V2] fate/filter-video.mak: do not use
> bit-exact check for dnn_processing
> 
> 
> 
> 
> > Am 01.02.2020 um 15:50 schrieb Guo, Yejun :
> 
> > Just checked the master and found the original patch is reverted.
> 
> Yes, I sent an email as a reply to the relevant mailing list thread (created 
> by you)
> to the list:
> http://ffmpeg.org/pipermail/ffmpeg-devel/2020-January/256482.html

Quote: "Did this when I realized that the existing test breaks fate without
SAMPLES on all platforms."

thanks, just curious about the 'fate without SAMPLES on all platforms', my
understanding is that 'SAMPLES' means the directory 'fate-suite' (or another 
name)
which holds the material for FATE tests. And, if a system does not setup SAMPLES
correctly, all the tests needing the SAMPLES will fail, not just this test.

> 
> > I'm ok for it, but think it is still valuable to update the status.
> 
> I don’t understand.
> 
> 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] [PATCH] avfilter/scene_sad: add AArch64 SIMD

[zhilizhao]

> On Feb 2, 2020, at 4:26 AM, Marton Balint  wrote:
> 
> 
> 
> On Sat, 1 Feb 2020, quinkbl...@foxmail.com  
> wrote:
> 
>> From: Zhao Zhili 
>> 
>> For 8 bit depth:
>>   ./ffmpeg -threads 1 -f lavfi -t 10 -i 
>> 'yuvtestsrc=size=4096x2048,format=yuv444p' -vf 'freezedetect' -f null 
>> -benchmark -
>> 
>>   Test results on Snapdragon 845:
>>   Before:
>>   frame=  250 fps= 23 q=-0.0 Lsize=N/A time=00:00:10.00 bitrate=N/A 
>> speed=0.924x
>>  bench: utime=8.360s stime=2.350s rtime=10.820s
>>   After:
>>   frame=  250 fps= 51 q=-0.0 Lsize=N/A time=00:00:10.00 bitrate=N/A 
>> speed=2.04x
>>  bench: utime=2.650s stime=2.210s rtime=4.909s
>> 
>>   Test results on HiSilicon Kirin 970:
>>   Before:
>>   frame=  250 fps=6.0 q=-0.0 Lsize=N/A time=00:00:10.00 bitrate=N/A 
>> speed=0.239x
>>   bench: utime=35.156s stime=6.604s rtime=41.820s
>>   After:
>>   frame=  250 fps= 10 q=-0.0 Lsize=N/A time=00:00:10.00 bitrate=N/A 
>> speed=0.403x
>>  bench: utime=18.400s stime=6.376s rtime=24.798s
>> 
>> For 16 bit depth:
>>   ./ffmpeg -threads 1 -f lavfi -t 10 -i 
>> 'yuvtestsrc=size=4096x2048,format=yuv444p16' -vf 'freezedetect' -f null 
>> -benchmark -
>> 
>>   Test results on Snapdragon 845
>>   Before:
>>   frame=  250 fps= 19 q=-0.0 Lsize=N/A time=00:00:10.00 bitrate=N/A 
>> speed=0.756x
>>  bench: utime=8.700s stime=4.410s rtime=13.226s
>>   After:
>>  frame=  250 fps= 27 q=-0.0 Lsize=N/A time=00:00:10.00 bitrate=N/A 
>> speed=1.07x
>>  bench: utime=4.920s stime=4.350s rtime=9.356s
>> 
>>   Test results on HiSilicon Kirin 970:
>>   Before:
>>   frame=  250 fps=4.0 q=-0.0 Lsize=N/A time=00:00:10.00 bitrate=N/A 
>> speed=0.161x
>>  bench: utime=48.868s stime=13.124s rtime=62.110s
>>   After:
>>   frame=  250 fps=5.1 q=-0.0 Lsize=N/A time=00:00:10.00 bitrate=N/A 
>> speed=0.205x
>>  bench: utime=35.600s stime=13.036s rtime=48.708s
>> ---
>> libavfilter/aarch64/Makefile |   2 +
>> libavfilter/aarch64/scene_sad_init.c |  37 +++
>> libavfilter/aarch64/scene_sad_neon.S | 149 +++
>> libavfilter/scene_sad.c  |   2 +
>> libavfilter/scene_sad.h  |   2 +
>> 5 files changed, 192 insertions(+)
>> create mode 100644 libavfilter/aarch64/scene_sad_init.c
>> create mode 100644 libavfilter/aarch64/scene_sad_neon.S
> 
> Does your ASM handles cases when width is not a multiple of the vector size? 
> If not, then you should probably do something similar to what is done for X86.
> 

The code after `+   // scalar loop` handles that. It supports width and 
height >= 1.

> Thanks,
> Marton
> 
>> 
>> diff --git a/libavfilter/aarch64/Makefile b/libavfilter/aarch64/Makefile
>> index 6c727f9859..3a458f511f 100644
>> --- a/libavfilter/aarch64/Makefile
>> +++ b/libavfilter/aarch64/Makefile
>> @@ -1,7 +1,9 @@
>> OBJS-$(CONFIG_NLMEANS_FILTER)+= aarch64/af_afir_init.o
>> OBJS-$(CONFIG_NLMEANS_FILTER)+= aarch64/af_anlmdn_init.o
>> +OBJS-$(CONFIG_NLMEANS_FILTER)+= aarch64/scene_sad_init.o
>> OBJS-$(CONFIG_NLMEANS_FILTER)+= aarch64/vf_nlmeans_init.o
>> NEON-OBJS-$(CONFIG_NLMEANS_FILTER)   += aarch64/af_afir_neon.o
>> NEON-OBJS-$(CONFIG_NLMEANS_FILTER)   += aarch64/af_anlmdn_neon.o
>> +NEON-OBJS-$(CONFIG_NLMEANS_FILTER)   += aarch64/scene_sad_neon.o
>> NEON-OBJS-$(CONFIG_NLMEANS_FILTER)   += aarch64/vf_nlmeans_neon.o
>> diff --git a/libavfilter/aarch64/scene_sad_init.c 
>> b/libavfilter/aarch64/scene_sad_init.c
>> new file mode 100644
>> index 00..8de769ac10
>> --- /dev/null
>> +++ b/libavfilter/aarch64/scene_sad_init.c
>> @@ -0,0 +1,37 @@
>> +/*
>> + * 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 "libavutil/aarch64/cpu.h"
>> +#include "libavfilter/scene_sad.h"
>> +
>> +void ff_scene_sad_neon(SCENE_SAD_PARAMS);
>> +
>> +void ff_scene_sad16_neon(SCENE_SAD_PARAMS);
>> +
>> +ff_scene_sad_fn ff_scene_sad_get_fn_aarch64(int depth)
>> +{
>> +int cpu_flags = av_get_cpu_flags();
>> +if (have_neon(cpu_flags)) {
>> +if (depth == 8)
>> +return ff_scene_sad_neon;
>> +if (depth == 16)
>> +   

Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg_filter: add -autoscale to disable/enable the default scale

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Mark Thompson
> Sent: Saturday, February 1, 2020 22:18
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg_filter: add -autoscale
> to disable/enable the default scale
> 
> On 15/01/2020 07:05, Linjie Fu wrote:
> > Currently, ffmpeg inserts scale filter by default in the filter graph
> > to force the whole decoded stream to scale into the same size with the
> > first frame. It's not quite make sense in resolution changing cases if
> > user wants the rawvideo without any scale.
> >
> > Using autoscale/noautoscale to indicate whether auto inserting the scale
> > filter in the filter graph:
> > -noautoscale or -autoscale 0:
> > disable the default auto scale filter inserting.
> >
> > Update docs.
> >
> > Signed-off-by: U. Artie Eoff 
> > Signed-off-by: Linjie Fu 
> > ---
> >  doc/ffmpeg.texi | 16 
> >  fftools/ffmpeg.c|  1 +
> >  fftools/ffmpeg.h|  4 
> >  fftools/ffmpeg_filter.c |  2 +-
> >  fftools/ffmpeg_opt.c|  8 
> >  5 files changed, 26 insertions(+), 5 deletions(-)
> >
> > diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> > index dd461c0..716dd2c 100644
> > --- a/doc/ffmpeg.texi
> > +++ b/doc/ffmpeg.texi
> > @@ -734,10 +734,6 @@ ffmpeg -dump_attachment:t "" -i INPUT
> >  Technical note -- attachments are implemented as codec extradata, so this
> >  option can actually be used to extract extradata from any stream, not just
> >  attachments.
> > -
> > -@item -noautorotate
> > -Disable automatically rotating video based on file metadata.
> > -
> >  @end table
> >
> >  @section Video Options
> > @@ -819,6 +815,18 @@ Create the filtergraph specified by
> @var{filtergraph} and use it to
> >  filter the stream.
> >
> >  This is an alias for @code{-filter:v}, see the @ref{filter_option,,-filter
> option}.
> > +
> > +@item -autorotate
> > +Automatically rotate the video according to file metadata. Enabled by
> > +default, use @option{-noautorotate} to disable it.
> > +
> > +@item -autoscale
> > +Automatically scale the video according to the resolution of first frame.
> > +Enabled by default, use @option{-noautoscale} to disable it. When
> autoscale is
> > +disabled, all output frames of filter graph might not be in the same
> resolution
> > +and may be inadequate for some encoder/muxer. Therefore, it is not
> recommended
> > +to disable it unless you really know what you are doing.
> > +Disable autoscale at your own risk.
> >  @end table
> >
> >  @section Advanced Video options
> > diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> > index 6bcd7b9..864c1fb 100644
> > --- a/fftools/ffmpeg.c
> > +++ b/fftools/ffmpeg.c
> > @@ -2125,6 +2125,7 @@ static int ifilter_send_frame(InputFilter *ifilter,
> AVFrame *frame)
> >
> >  /* determine if the parameters for this input changed */
> >  need_reinit = ifilter->format != frame->format;
> > +fg->autoscale = ifilter->ist->autoscale;
> >
> >  switch (ifilter->ist->st->codecpar->codec_type) {
> >  case AVMEDIA_TYPE_AUDIO:
> > diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
> > index 7b6f802..1602406 100644
> > --- a/fftools/ffmpeg.h
> > +++ b/fftools/ffmpeg.h
> > @@ -133,6 +133,8 @@ typedef struct OptionsContext {
> >  intnb_hwaccel_output_formats;
> >  SpecifierOpt *autorotate;
> >  intnb_autorotate;
> > +SpecifierOpt *autoscale;
> > +intnb_autoscale;
> >
> >  /* output options */
> >  StreamMap *stream_maps;
> > @@ -285,6 +287,7 @@ typedef struct FilterGraph {
> >
> >  AVFilterGraph *graph;
> >  int reconfiguration;
> > +int autoscale;
> >
> >  InputFilter   **inputs;
> >  int  nb_inputs;
> > @@ -335,6 +338,7 @@ typedef struct InputStream {
> >  int guess_layout_max;
> >
> >  int autorotate;
> > +int autoscale;
> >
> >  int fix_sub_duration;
> >  struct { /* previous decoded subtitle and related variables */
> > diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
> > index 40cc4c1..dafcab7 100644
> > --- a/fftools/ffmpeg_filter.c
> > +++ b/fftools/ffmpeg_filter.c
> > @@ -469,7 +469,7 @@ static int configure_output_video_filter(FilterGraph
> *fg, OutputFilter *ofilter,
> >  if (ret < 0)
> >  return ret;
> >
> > -if (ofilter->width || ofilter->height) {
> > +if ((ofilter->width || ofilter->height) && fg->autoscale) {
> >  char args[255];
> >  AVFilterContext *filter;
> >  AVDictionaryEntry *e = NULL;
> > diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
> > index 1510e02..37083f2 100644
> > --- a/fftools/ffmpeg_opt.c
> > +++ b/fftools/ffmpeg_opt.c
> > @@ -743,7 +743,9 @@ static void add_input_streams(OptionsContext *o,
> AVFormatContext *ic)
> >  MATCH_PER_STREAM_OPT(ts_scale, dbl, ist->ts_scale, ic, st);
> >
> >  ist->autorotate = 1;
> > +ist->autoscale  = 1;
> >  MATCH_PER_STREAM_OPT(autorotate, i, ist-

Re: [FFmpeg-devel] [PATCH v2 1/6] avcodec/cbs_jpeg: Use memcpy when writing pictures

[Andreas Rheinhardt]

Andreas Rheinhardt:
> This is possible because the size of a scan header is always a multiple
> of a byte.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/cbs_jpeg.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/libavcodec/cbs_jpeg.c b/libavcodec/cbs_jpeg.c
> index b189cbd9b7..64fe70beab 100644
> --- a/libavcodec/cbs_jpeg.c
> +++ b/libavcodec/cbs_jpeg.c
> @@ -330,7 +330,7 @@ static int cbs_jpeg_write_scan(CodedBitstreamContext *ctx,
> PutBitContext *pbc)
>  {
>  JPEGRawScan *scan = unit->content;
> -int i, err;
> +int err;
>  
>  err = cbs_jpeg_write_scan_header(ctx, pbc, &scan->header);
>  if (err < 0)
> @@ -340,8 +340,12 @@ static int cbs_jpeg_write_scan(CodedBitstreamContext 
> *ctx,
>  if (scan->data_size * 8 > put_bits_left(pbc))
>  return AVERROR(ENOSPC);
>  
> -for (i = 0; i < scan->data_size; i++)
> -put_bits(pbc, 8, scan->data[i]);
> +av_assert0(put_bits_count(pbc) % 8 == 0);
> +
> +flush_put_bits(pbc);
> +
> +memcpy(put_bits_ptr(pbc), scan->data, scan->data_size);
> +skip_put_bytes(pbc, scan->data_size);
>  }
>  
>  return 0;
> 
Ping.

- Andreas
___
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".