Re: [FFmpeg-devel] [PATCH 4/4] VP4 video decoder
On 1/6/19, Peter Ross wrote: > --- > Changelog | 1 + > doc/general.texi| 2 + > libavcodec/codec_desc.c | 2 +- > libavcodec/vp3.c| 701 ++-- > libavformat/riff.c | 1 + > 5 files changed, 671 insertions(+), 36 deletions(-) Why is it not using own codec id? It is better that way IMHO. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/bsf_list: implement a AVBSFContext.flush callback
On 1/6/19, James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavcodec/bsf.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/libavcodec/bsf.c b/libavcodec/bsf.c
> index 03841da682..41dde4dcc8 100644
> --- a/libavcodec/bsf.c
> +++ b/libavcodec/bsf.c
> @@ -350,6 +350,16 @@ static int bsf_list_filter(AVBSFContext *bsf, AVPacket
> *out)
> return ret;
> }
>
> +static void bsf_list_flush(AVBSFContext *bsf)
> +{
> +BSFListContext *lst = bsf->priv_data;
> +int i;
> +
> +for (i = 0; i < lst->nb_bsfs; ++i)
Weird style, please use i++
Also use for (int i;
> +av_bsf_flush(lst->bsfs[i]);
> +lst->idx = lst->flushed_idx = 0;
> +}
> +
> static void bsf_list_close(AVBSFContext *bsf)
> {
> BSFListContext *lst = bsf->priv_data;
> @@ -398,6 +408,7 @@ const AVBitStreamFilter ff_list_bsf = {
> .priv_class = &bsf_list_class,
> .init = bsf_list_init,
> .filter = bsf_list_filter,
> +.flush = bsf_list_flush,
> .close = bsf_list_close,
> };
>
> --
> 2.20.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] dstdec: big-endian compatiblity
for the '127-bit shift left' algorithm to work as intended, little-endian reads and writes must be used. libavcodec/dstdec.c | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/libavcodec/dstdec.c b/libavcodec/dstdec.c index 511861f4d2..e9653edc9f 100644 --- a/libavcodec/dstdec.c +++ b/libavcodec/dstdec.c @@ -343,8 +343,15 @@ static int decode_frame(AVCodecContext *avctx, void *data, v = ((predict >> 15) ^ residual) & 1; dsd[((i >> 3) * channels + ch) << 2] |= v << (7 - (i & 0x7 )); -AV_WN64A(status + 8, (AV_RN64A(status + 8) << 1) | ((AV_RN64A(status) >> 63) & 1)); -AV_WN64A(status, (AV_RN64A(status) << 1) | v); +#if HAVE_BIGENDIAN +#define RL64A AV_RL64 +#define WL64A AV_WL64 +#else +#define RL64A AV_RN64A +#define WL64A AV_WN64A +#endif +WL64A(status + 8, (RL64A(status + 8) << 1) | ((RL64A(status) >> 63) & 1)); +WL64A(status, (RL64A(status) << 1) | v); } } -- 2.17.1 -- Peter (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avcodec/huffyuvdec: Check that slices do not exceed frame height
Fixes: Out of array access
Fixes:
12367/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HYMT_fuzzer-5662313959391232
Fixes:
12370/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HYMT_fuzzer-5670984961490944
Fixes:
12376/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HYMT_fuzzer-564402618368
Fixes:
12383/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HYMT_fuzzer-5722087214284800
Fixes:
12390/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HYMT_fuzzer-5696653095337984
Fixes:
12408/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HYMT_fuzzer-5729689379799040
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/huffyuvdec.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/huffyuvdec.c b/libavcodec/huffyuvdec.c
index dfe3585e6e..8226c07743 100644
--- a/libavcodec/huffyuvdec.c
+++ b/libavcodec/huffyuvdec.c
@@ -1254,7 +1254,8 @@ static int decode_frame(AVCodecContext *avctx, void
*data, int *got_frame,
slices_info_offset = AV_RL32(avpkt->data + buf_size - 4);
slice_height = AV_RL32(avpkt->data + buf_size - 8);
nb_slices = AV_RL32(avpkt->data + buf_size - 12);
-if (nb_slices * 8LL + slices_info_offset > buf_size - 16 ||
slice_height <= 0)
+if (nb_slices * 8LL + slices_info_offset > buf_size - 16 ||
+slice_height <= 0 || nb_slices * (uint64_t)slice_height > height)
return AVERROR_INVALIDDATA;
} else {
slice_height = height;
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avcodec/huffyuvdec: Check that slice height is non negative.
Fixes: out of array access
Fixes:
12381/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HYMT_fuzzer-5705474280783872
Fixes:
12384/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HYMT_fuzzer-5725303345774592
Fixes:
12389/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HYMT_fuzzer-5704033050820608
Fixes:
12391/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HYMT_fuzzer-5707284146028544
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/huffyuvdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/huffyuvdec.c b/libavcodec/huffyuvdec.c
index 4e00692631..dfe3585e6e 100644
--- a/libavcodec/huffyuvdec.c
+++ b/libavcodec/huffyuvdec.c
@@ -1254,7 +1254,7 @@ static int decode_frame(AVCodecContext *avctx, void
*data, int *got_frame,
slices_info_offset = AV_RL32(avpkt->data + buf_size - 4);
slice_height = AV_RL32(avpkt->data + buf_size - 8);
nb_slices = AV_RL32(avpkt->data + buf_size - 12);
-if (nb_slices * 8LL + slices_info_offset > buf_size - 16)
+if (nb_slices * 8LL + slices_info_offset > buf_size - 16 ||
slice_height <= 0)
return AVERROR_INVALIDDATA;
} else {
slice_height = height;
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] VP4 video decoder
On Sun, Jan 06, 2019 at 10:11:14AM +0100, Paul B Mahol wrote: > On 1/6/19, Peter Ross wrote: > > --- > > Changelog | 1 + > > doc/general.texi| 2 + > > libavcodec/codec_desc.c | 2 +- > > libavcodec/vp3.c| 701 ++-- > > libavformat/riff.c | 1 + > > 5 files changed, 671 insertions(+), 36 deletions(-) > > Why is it not using own codec id? It is better that way IMHO. seperate ids would enable users to independently disable the decoder. but other than that, i don't know what value this brings. the codecs are very similar. even the reference implementation only uses the version field to distinguish them. if i change a true VP3 file to use the 'VP40' fourcc, it decodes correctly. if i change a true VP4 file to use the 'VP31' fourcc, it also decodes correctly. -- Peter (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] VP4 video decoder
2019-01-06 12:50 GMT+01:00, Peter Ross : > On Sun, Jan 06, 2019 at 10:11:14AM +0100, Paul B Mahol wrote: >> On 1/6/19, Peter Ross wrote: >> > --- >> > Changelog | 1 + >> > doc/general.texi| 2 + >> > libavcodec/codec_desc.c | 2 +- >> > libavcodec/vp3.c| 701 ++-- >> > libavformat/riff.c | 1 + >> > 5 files changed, 671 insertions(+), 36 deletions(-) >> >> Why is it not using own codec id? It is better that way IMHO. > > seperate ids would enable users to independently disable the decoder. > but other than that, i don't know what value this brings. It would theoretically improve remuxing, if in doubt, please use a separate id. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] VP4 data tables
2019-01-06 8:43 GMT+01:00, Peter Ross :
> +static const uint32_t vp4_generic_dequant[64] = {
> +16, 17, 18, 20, 22, 24, 26, 28,
> +17, 18, 20, 22, 24, 26, 28, 32,
> +18, 20, 22, 24, 26, 28, 32, 36,
> +20, 22, 24, 26, 28, 32, 36, 40,
> +22, 24, 26, 28, 32, 36, 40, 44,
> +24, 26, 28, 32, 36, 40, 44, 48,
> +26, 28, 32, 36, 40, 44, 48, 52,
> +28, 32, 36, 40, 44, 48, 52, 56
> +};
> +
> +static const uint32_t vp4_y_dc_scale_factor[64] = {
> +180, 180, 180, 180, 180, 180, 175, 170,
> +165, 160, 157, 155, 152, 150, 147, 145,
> +142, 140, 137, 135, 132, 130, 127, 125,
> +122, 120, 117, 115, 112, 110, 107, 105,
> +102, 100, 97, 95, 92, 90, 87, 85,
> + 82, 80, 77, 75, 72, 70, 67, 65,
> + 62, 60, 57, 55, 52, 50, 47, 45,
> + 42, 40, 37, 35, 32, 30, 27, 25
> +};
> +
> +static const uint32_t vp4_uv_dc_scale_factor[64] = {
> +150, 150, 150, 150, 150, 150, 150, 150,
> +150, 150, 150, 150, 150, 150, 147, 145,
> +142, 140, 137, 135, 132, 130, 127, 125,
> +122, 120, 117, 115, 112, 110, 107, 105,
> +102, 100, 97, 95, 92, 90, 87, 85,
> + 82, 80, 77, 75, 72, 70, 67, 65,
> + 62, 60, 57, 55, 52, 50, 47, 45,
> + 42, 40, 37, 35, 32, 30, 27, 25
> +};
If there is a performance reason why they are not uint8_t,
please mention it in a comment.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] dstdec: big-endian compatiblity
2019-01-06 12:12 GMT+01:00, Peter Ross : > for the '127-bit shift left' algorithm to work as intended, little-endian > reads and writes must be used. > > libavcodec/dstdec.c | 11 +-- > 1 file changed, 9 insertions(+), 2 deletions(-) > > diff --git a/libavcodec/dstdec.c b/libavcodec/dstdec.c > index 511861f4d2..e9653edc9f 100644 > --- a/libavcodec/dstdec.c > +++ b/libavcodec/dstdec.c > @@ -343,8 +343,15 @@ static int decode_frame(AVCodecContext *avctx, void > *data, > v = ((predict >> 15) ^ residual) & 1; > dsd[((i >> 3) * channels + ch) << 2] |= v << (7 - (i & 0x7 )); > > -AV_WN64A(status + 8, (AV_RN64A(status + 8) << 1) | > ((AV_RN64A(status) >> 63) & 1)); > -AV_WN64A(status, (AV_RN64A(status) << 1) | v); > +#if HAVE_BIGENDIAN > +#define RL64A AV_RL64 > +#define WL64A AV_WL64 > +#else > +#define RL64A AV_RN64A > +#define WL64A AV_WN64A > +#endif > +WL64A(status + 8, (RL64A(status + 8) << 1) | ((RL64A(status) >> > 63) & 1)); > +WL64A(status, (RL64A(status) << 1) | v); Why not using AV_WL64() and and AV_RL64()? Is there a measurable speed difference? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/dxva2: d3d11va: don't try to get surface description for nullptr
2019-01-05 11:44 GMT+01:00, Anton Fedchin :
> From: Anton Fedchin
>
> after 153b36f there is a possibility to crash when trying to get index of
> a surface which points to nirvana. it may occurs when a stream starts with
> non i-frame.
> ---
> libavcodec/dxva2.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c
> index 32416112bf..dfae500444 100644
> --- a/libavcodec/dxva2.c
> +++ b/libavcodec/dxva2.c
> @@ -771,16 +771,18 @@ unsigned ff_dxva2_get_surface_index(const
> AVCodecContext *avctx,
> #if CONFIG_D3D11VA
> if (avctx->pix_fmt == AV_PIX_FMT_D3D11)
> return (intptr_t)frame->data[1];
> -if (avctx->pix_fmt == AV_PIX_FMT_D3D11VA_VLD) {
> +if (avctx->pix_fmt == AV_PIX_FMT_D3D11VA_VLD && surface) {
> D3D11_VIDEO_DECODER_OUTPUT_VIEW_DESC viewDesc;
>
> ID3D11VideoDecoderOutputView_GetDesc((ID3D11VideoDecoderOutputView*)
> surface, &viewDesc);
> return viewDesc.Texture2D.ArraySlice;
> }
> #endif
> #if CONFIG_DXVA2
> -for (i = 0; i < DXVA_CONTEXT_COUNT(avctx, ctx); i++) {
> -if (avctx->pix_fmt == AV_PIX_FMT_DXVA2_VLD && ctx->dxva2.surface[i]
> == surface)
> -return i;
> +if (avctx->pix_fmt == AV_PIX_FMT_DXVA2_VLD) {
> +for (i = 0; i < DXVA_CONTEXT_COUNT(avctx, ctx); i++) {
> +if (ctx->dxva2.surface[i] == surface)
> +return i;
> +}
How is this change related?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/huffyuvdec: Check that slices do not exceed frame height
On 1/6/19, Michael Niedermayer wrote:
> Fixes: Out of array access
> Fixes:
> 12367/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HYMT_fuzzer-5662313959391232
> Fixes:
> 12370/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HYMT_fuzzer-5670984961490944
> Fixes:
> 12376/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HYMT_fuzzer-564402618368
> Fixes:
> 12383/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HYMT_fuzzer-5722087214284800
> Fixes:
> 12390/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HYMT_fuzzer-5696653095337984
> Fixes:
> 12408/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HYMT_fuzzer-5729689379799040
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/huffyuvdec.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/huffyuvdec.c b/libavcodec/huffyuvdec.c
> index dfe3585e6e..8226c07743 100644
> --- a/libavcodec/huffyuvdec.c
> +++ b/libavcodec/huffyuvdec.c
> @@ -1254,7 +1254,8 @@ static int decode_frame(AVCodecContext *avctx, void
> *data, int *got_frame,
> slices_info_offset = AV_RL32(avpkt->data + buf_size - 4);
> slice_height = AV_RL32(avpkt->data + buf_size - 8);
> nb_slices = AV_RL32(avpkt->data + buf_size - 12);
> -if (nb_slices * 8LL + slices_info_offset > buf_size - 16 ||
> slice_height <= 0)
> +if (nb_slices * 8LL + slices_info_offset > buf_size - 16 ||
> +slice_height <= 0 || nb_slices * (uint64_t)slice_height >
> height)
> return AVERROR_INVALIDDATA;
> } else {
> slice_height = height;
> --
> 2.20.1
>
ok
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/huffyuvdec: Check that slice height is non negative.
On 1/6/19, Michael Niedermayer wrote:
> Fixes: out of array access
> Fixes:
> 12381/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HYMT_fuzzer-5705474280783872
> Fixes:
> 12384/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HYMT_fuzzer-5725303345774592
> Fixes:
> 12389/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HYMT_fuzzer-5704033050820608
> Fixes:
> 12391/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HYMT_fuzzer-5707284146028544
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/huffyuvdec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/huffyuvdec.c b/libavcodec/huffyuvdec.c
> index 4e00692631..dfe3585e6e 100644
> --- a/libavcodec/huffyuvdec.c
> +++ b/libavcodec/huffyuvdec.c
> @@ -1254,7 +1254,7 @@ static int decode_frame(AVCodecContext *avctx, void
> *data, int *got_frame,
> slices_info_offset = AV_RL32(avpkt->data + buf_size - 4);
> slice_height = AV_RL32(avpkt->data + buf_size - 8);
> nb_slices = AV_RL32(avpkt->data + buf_size - 12);
> -if (nb_slices * 8LL + slices_info_offset > buf_size - 16)
> +if (nb_slices * 8LL + slices_info_offset > buf_size - 16 ||
> slice_height <= 0)
> return AVERROR_INVALIDDATA;
> } else {
> slice_height = height;
> --
> 2.20.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
ok
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] swscale/output: VSX-optimize 9-16 bit yuv2planeX
2019-01-04 20:43 GMT+01:00, Lauri Kasanen : > +#ifdef __POWER8_VECTOR__ If this is correct, I assume it fixes a bug in the current code and should be a separate patch, no? > case 16: > c->yuv2plane1 = isBE(dstFormat) ? yuv2plane1_16BE_vsx : > yuv2plane1_16LE_vsx; > +c->yuv2planeX = isBE(dstFormat) ? yuv2planeX_16BE_vsx : > yuv2planeX_16LE_vsx; > break; > -#endif > +#endif /* __POWER8_VECTOR__ */ Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] patch for failing on WavPack DSD files
2019-01-03 6:19 GMT+01:00, David Bryant : > On 12/28/18 3:56 AM, Paul B Mahol wrote: >> On 12/24/18, Derek Buitenhuis wrote: >>> On 24/12/2018 17:47, David Bryant wrote: I want to do that, but am swamped at work right now, so it will probably be a few months before I can get to that. In the meantime, I think this patch would be a safe stopgap (and prevent the Kodi crash). >>> I think it's OK for the meantime (my opinion). >> Applied. > The guys at Kodi asked me to request that this patch be backported to 4.0. While this may be ok, somebody should tell the Kodi developers to fix the crash as I would expect it's possible to create files that are still tried to be decoded but produce identical output as before. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add HCOM decoder
2019-01-03 0:51 GMT+01:00, Rostislav Pehlivanov :
> On Wed, 2 Jan 2019 at 19:02, Paul B Mahol wrote:
>> +while (bits-- > 0) {
>> +
>> +if (current & 0x8000) {
>> +s->dict_entry = s->dict[s->dict_entry].r;
>> +} else {
>> +s->dict_entry = s->dict[s->dict_entry].l;
>> +}
>
> No need for brackets here.
Fwiw, I believe these brackets are useful.
But that may only be me debugging.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter: add anlmdn audio filter
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 23
libavfilter/Makefile | 1 +
libavfilter/af_anlmdn.c | 249 +++
libavfilter/allfilters.c | 1 +
4 files changed, 274 insertions(+)
create mode 100644 libavfilter/af_anlmdn.c
diff --git a/doc/filters.texi b/doc/filters.texi
index 98858c5356..4031d1ef9a 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -1750,6 +1750,29 @@ Full filter invocation with asendcmd may look like this:
asendcmd=c='4.0 anequalizer change 0|f=200|w=50|g=1',anequalizer=...
@end table
+@section anlmdn
+
+Reduce broadband noise in audio samples using Non-Local Means algorithm.
+
+Each sample is adjusted by looking for other samples with similar contexts.
This
+context similarity is defined by comparing their surrounding patches of size
+@option{p}. Patches are searched in an area of @option{r} around the sample.
+
+The filter accepts the following options.
+
+@table @option
+@item s
+Set denoising strength. Allowed range is from 1 to . Default value is 1.
+
+@item p
+Set patch radius in number of samples. Allowed range is from 0 to 4096.
+Default value is 32.
+
+@item r
+Set research radius in number of samples. Allowed range is from 1 to 4096.
+Default value is 200.
+@end table
+
@section anull
Pass the audio source unchanged to the output.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 6e2658186d..d31fa59e0d 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -63,6 +63,7 @@ OBJS-$(CONFIG_AMETADATA_FILTER) += f_metadata.o
OBJS-$(CONFIG_AMIX_FILTER) += af_amix.o
OBJS-$(CONFIG_AMULTIPLY_FILTER) += af_amultiply.o
OBJS-$(CONFIG_ANEQUALIZER_FILTER)+= af_anequalizer.o
+OBJS-$(CONFIG_ANLMDN_FILTER) += af_anlmdn.o
OBJS-$(CONFIG_ANULL_FILTER) += af_anull.o
OBJS-$(CONFIG_APAD_FILTER) += af_apad.o
OBJS-$(CONFIG_APERMS_FILTER) += f_perms.o
diff --git a/libavfilter/af_anlmdn.c b/libavfilter/af_anlmdn.c
new file mode 100644
index 00..3eaea68dfa
--- /dev/null
+++ b/libavfilter/af_anlmdn.c
@@ -0,0 +1,249 @@
+/*
+ * Copyright (c) 2019 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include
+
+#include "libavutil/avassert.h"
+#include "libavutil/audio_fifo.h"
+#include "libavutil/opt.h"
+#include "avfilter.h"
+#include "audio.h"
+#include "formats.h"
+
+#define SQR(x) ((x) * (x))
+
+typedef struct AudioNLMeansContext {
+const AVClass *class;
+
+float a;
+int K;
+int S;
+
+int N;
+int hop_size;
+
+AVFrame *in;
+AVFrame *cache;
+
+int64_t pts;
+
+AVAudioFifo *fifo;
+
+float (*compute_distance)(const float *f1, const float *f2, int K);
+} AudioNLMeansContext;
+
+#define OFFSET(x) offsetof(AudioNLMeansContext, x)
+#define AF AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
+
+static const AVOption anlmdn_options[] = {
+{ "s", "set denoising strength", OFFSET(a), AV_OPT_TYPE_FLOAT, {.dbl=1},
1, , AF },
+{ "p", "set patch radius", OFFSET(K), AV_OPT_TYPE_INT, {.i64=32},
0, 4096, AF },
+{ "r", "set research radius",OFFSET(S), AV_OPT_TYPE_INT, {.i64=200},
1, 4096, AF },
+{ NULL }
+};
+
+AVFILTER_DEFINE_CLASS(anlmdn);
+
+static int query_formats(AVFilterContext *ctx)
+{
+AVFilterFormats *formats = NULL;
+AVFilterChannelLayouts *layouts = NULL;
+static const enum AVSampleFormat sample_fmts[] = {
+AV_SAMPLE_FMT_FLTP,
+AV_SAMPLE_FMT_NONE
+};
+int ret;
+
+formats = ff_make_format_list(sample_fmts);
+if (!formats)
+return AVERROR(ENOMEM);
+ret = ff_set_common_formats(ctx, formats);
+if (ret < 0)
+return ret;
+
+layouts = ff_all_channel_counts();
+if (!layouts)
+return AVERROR(ENOMEM);
+
+ret = ff_set_common_channel_layouts(ctx, layouts);
+if (ret < 0)
+return ret;
+
+formats = ff_all_samplerates();
+return ff_set_common_samplerates(ctx, formats);
+}
+
+static float compute_distance_ssd(const float *f1, const float *f2, int K)
+{
+float distance = 0.;
+
+for (int k = -K; k <= K; k++) {
+distance += SQR(f1[k] - f2[k]);
+}
+
+
Re: [FFmpeg-devel] [PATCH]configure: ole32 is needed for shared libavcodec linking with dxva2.
2018-12-31 2:44 GMT+01:00, James Almer : > On 12/30/2018 5:52 PM, Carl Eugen Hoyos wrote: >> 2018-12-30 21:37 GMT+01:00, Hendrik Leppkes : >>> On Sun, Dec 30, 2018 at 9:16 PM Carl Eugen Hoyos >>> wrote: >> Attached patch fixes a Windows linking issue described in ticket #7642, only shared linking was tested so far. >>> >>> ole32 is a dependency of dxva2 already, it should already be pulled in >>> through that, shouldn't it? >> >> Please test this... >> >> Carl Eugen > > The issue here is that dxva2 is enabled (thus compiling dxva2.c), but > every dxva2 module isn't, which means the dependency generator in > configure will not pull dxva2 dependencies for avcodec. > > I think the more correct solution would be to add dxva2_extralibs to > avcodec_extralibs. I will push my patch if no alternative solutions are provided. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/bsf_list: implement a AVBSFContext.flush callback
On 1/6/2019 6:08 AM, Paul B Mahol wrote:
> On 1/6/19, James Almer wrote:
>> Signed-off-by: James Almer
>> ---
>> libavcodec/bsf.c | 11 +++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/libavcodec/bsf.c b/libavcodec/bsf.c
>> index 03841da682..41dde4dcc8 100644
>> --- a/libavcodec/bsf.c
>> +++ b/libavcodec/bsf.c
>> @@ -350,6 +350,16 @@ static int bsf_list_filter(AVBSFContext *bsf, AVPacket
>> *out)
>> return ret;
>> }
>>
>> +static void bsf_list_flush(AVBSFContext *bsf)
>> +{
>> +BSFListContext *lst = bsf->priv_data;
>> +int i;
>> +
>> +for (i = 0; i < lst->nb_bsfs; ++i)
>
> Weird style, please use i++
> Also use for (int i;
Yeah, it's weird but it's consistent with bsf_list_close() below.
I'll change it anyway.
>
>> +av_bsf_flush(lst->bsfs[i]);
>> +lst->idx = lst->flushed_idx = 0;
>> +}
>> +
>> static void bsf_list_close(AVBSFContext *bsf)
>> {
>> BSFListContext *lst = bsf->priv_data;
>> @@ -398,6 +408,7 @@ const AVBitStreamFilter ff_list_bsf = {
>> .priv_class = &bsf_list_class,
>> .init = bsf_list_init,
>> .filter = bsf_list_filter,
>> +.flush = bsf_list_flush,
>> .close = bsf_list_close,
>> };
>>
>> --
>> 2.20.1
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/avpacket: Avoid unspecific return -1 for av_grow_packet()
2019-01-02 0:23 GMT+01:00, Michael Niedermayer :
> ffmpeg | branch: master | Michael Niedermayer | Mon
> Dec 31 18:25:18 2018 +0100| [9520d51e21f9aa5adc807b0b89322bd822b06738] |
> committer: Michael Niedermayer
>
> avcodec/avpacket: Avoid unspecific return -1 for av_grow_packet()
>
> Reviewed-by: Paul B Mahol
> Signed-off-by: Michael Niedermayer
>
>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=9520d51e21f9aa5adc807b0b89322bd822b06738
> ---
>
> libavcodec/avpacket.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
> index e160ad3033..11ac4e80cd 100644
> --- a/libavcodec/avpacket.c
> +++ b/libavcodec/avpacket.c
> @@ -112,7 +112,7 @@ int av_grow_packet(AVPacket *pkt, int grow_by)
> av_assert0((unsigned)pkt->size <= INT_MAX -
> AV_INPUT_BUFFER_PADDING_SIZE);
> if ((unsigned)grow_by >
> INT_MAX - (pkt->size + AV_INPUT_BUFFER_PADDING_SIZE))
> -return -1;
> +return AVERROR(ENOMEM);
>
> new_size = pkt->size + grow_by + AV_INPUT_BUFFER_PADDING_SIZE;
> if (pkt->buf) {
> @@ -124,7 +124,7 @@ int av_grow_packet(AVPacket *pkt, int grow_by)
> } else {
> data_offset = pkt->data - pkt->buf->data;
> if (data_offset > INT_MAX - new_size)
> -return -1;
> +return AVERROR(ENOMEM);
Is this really correct?
At least on some 64bit systems, larger allocations should be possible,
we are simply assuming invalid data if such an allocation is tried, no?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/avpacket: Avoid unspecific return -1 for av_grow_packet()
On 1/6/2019 10:36 AM, Carl Eugen Hoyos wrote:
> 2019-01-02 0:23 GMT+01:00, Michael Niedermayer :
>> ffmpeg | branch: master | Michael Niedermayer | Mon
>> Dec 31 18:25:18 2018 +0100| [9520d51e21f9aa5adc807b0b89322bd822b06738] |
>> committer: Michael Niedermayer
>>
>> avcodec/avpacket: Avoid unspecific return -1 for av_grow_packet()
>>
>> Reviewed-by: Paul B Mahol
>> Signed-off-by: Michael Niedermayer
>>
>>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=9520d51e21f9aa5adc807b0b89322bd822b06738
>> ---
>>
>> libavcodec/avpacket.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
>> index e160ad3033..11ac4e80cd 100644
>> --- a/libavcodec/avpacket.c
>> +++ b/libavcodec/avpacket.c
>> @@ -112,7 +112,7 @@ int av_grow_packet(AVPacket *pkt, int grow_by)
>> av_assert0((unsigned)pkt->size <= INT_MAX -
>> AV_INPUT_BUFFER_PADDING_SIZE);
>> if ((unsigned)grow_by >
>> INT_MAX - (pkt->size + AV_INPUT_BUFFER_PADDING_SIZE))
>> -return -1;
>> +return AVERROR(ENOMEM);
>>
>> new_size = pkt->size + grow_by + AV_INPUT_BUFFER_PADDING_SIZE;
>> if (pkt->buf) {
>> @@ -124,7 +124,7 @@ int av_grow_packet(AVPacket *pkt, int grow_by)
>> } else {
>> data_offset = pkt->data - pkt->buf->data;
>> if (data_offset > INT_MAX - new_size)
>> -return -1;
>> +return AVERROR(ENOMEM);
>
> Is this really correct?
> At least on some 64bit systems, larger allocations should be possible,
> we are simply assuming invalid data if such an allocation is tried, no?
Even if av_max_alloc() allows the API user to allocate more than INT_MAX
bytes, AVPackets can't handle it as they use int for size.
And afaik, we have been using ERANGE as return error when an attempted
allocation is outside the allowed range. So maybe that's what should be
used here.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/avpacket: Avoid unspecific return -1 for av_grow_packet()
2019-01-06 14:43 GMT+01:00, James Almer :
> On 1/6/2019 10:36 AM, Carl Eugen Hoyos wrote:
>> 2019-01-02 0:23 GMT+01:00, Michael Niedermayer :
>>> ffmpeg | branch: master | Michael Niedermayer |
>>> Mon
>>> Dec 31 18:25:18 2018 +0100| [9520d51e21f9aa5adc807b0b89322bd822b06738] |
>>> committer: Michael Niedermayer
>>>
>>> avcodec/avpacket: Avoid unspecific return -1 for av_grow_packet()
>>>
>>> Reviewed-by: Paul B Mahol
>>> Signed-off-by: Michael Niedermayer
>>>
http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=9520d51e21f9aa5adc807b0b89322bd822b06738
>>> ---
>>>
>>> libavcodec/avpacket.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
>>> index e160ad3033..11ac4e80cd 100644
>>> --- a/libavcodec/avpacket.c
>>> +++ b/libavcodec/avpacket.c
>>> @@ -112,7 +112,7 @@ int av_grow_packet(AVPacket *pkt, int grow_by)
>>> av_assert0((unsigned)pkt->size <= INT_MAX -
>>> AV_INPUT_BUFFER_PADDING_SIZE);
>>> if ((unsigned)grow_by >
>>> INT_MAX - (pkt->size + AV_INPUT_BUFFER_PADDING_SIZE))
>>> -return -1;
>>> +return AVERROR(ENOMEM);
>>>
>>> new_size = pkt->size + grow_by + AV_INPUT_BUFFER_PADDING_SIZE;
>>> if (pkt->buf) {
>>> @@ -124,7 +124,7 @@ int av_grow_packet(AVPacket *pkt, int grow_by)
>>> } else {
>>> data_offset = pkt->data - pkt->buf->data;
>>> if (data_offset > INT_MAX - new_size)
>>> -return -1;
>>> +return AVERROR(ENOMEM);
>>
>> Is this really correct?
>> At least on some 64bit systems, larger allocations should be possible,
>> we are simply assuming invalid data if such an allocation is tried, no?
>
> Even if av_max_alloc() allows the API user to allocate more than INT_MAX
> bytes, AVPackets can't handle it as they use int for size.
That's what I am saying: There is no memory issue in above case,
just that we refuse to handle the case.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]configure: ole32 is needed for shared libavcodec linking with dxva2.
On 1/6/2019 10:32 AM, Carl Eugen Hoyos wrote: > 2018-12-31 2:44 GMT+01:00, James Almer : >> On 12/30/2018 5:52 PM, Carl Eugen Hoyos wrote: >>> 2018-12-30 21:37 GMT+01:00, Hendrik Leppkes : On Sun, Dec 30, 2018 at 9:16 PM Carl Eugen Hoyos wrote: >>> > Attached patch fixes a Windows linking issue described in ticket #7642, > only shared linking was tested so far. ole32 is a dependency of dxva2 already, it should already be pulled in through that, shouldn't it? >>> >>> Please test this... >>> >>> Carl Eugen >> >> The issue here is that dxva2 is enabled (thus compiling dxva2.c), but >> every dxva2 module isn't, which means the dependency generator in >> configure will not pull dxva2 dependencies for avcodec. >> >> I think the more correct solution would be to add dxva2_extralibs to >> avcodec_extralibs. > > I will push my patch if no alternative solutions are provided. > > Carl Eugen I just gave you one. Can you send another patch adding dxva2_extralibs to avcodec_extralibs? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]configure: ole32 is needed for shared libavcodec linking with dxva2.
2019-01-06 14:57 GMT+01:00, James Almer : > On 1/6/2019 10:32 AM, Carl Eugen Hoyos wrote: >> 2018-12-31 2:44 GMT+01:00, James Almer : >>> On 12/30/2018 5:52 PM, Carl Eugen Hoyos wrote: 2018-12-30 21:37 GMT+01:00, Hendrik Leppkes : > On Sun, Dec 30, 2018 at 9:16 PM Carl Eugen Hoyos > wrote: >> Attached patch fixes a Windows linking issue described in ticket >> #7642, >> only shared linking was tested so far. > > ole32 is a dependency of dxva2 already, it should already be pulled in > through that, shouldn't it? Please test this... Carl Eugen >>> >>> The issue here is that dxva2 is enabled (thus compiling dxva2.c), but >>> every dxva2 module isn't, which means the dependency generator in >>> configure will not pull dxva2 dependencies for avcodec. >>> >>> I think the more correct solution would be to add dxva2_extralibs to >>> avcodec_extralibs. >> >> I will push my patch if no alternative solutions are provided. >> >> Carl Eugen > > I just gave you one. Can you send another patch adding dxva2_extralibs > to avcodec_extralibs? No, unfortunately I cannot test, but please do! Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] configure: add dxva2 extralibs to avcodec
DXVA2 may be enabled even when every relevant module is disabled, which would result in the dependency generator not including its extralibs to avcodec. Fixes ticket #7642. Signed-off-by: James Almer --- configure | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index ead5181bc3..785a9be79f 100755 --- a/configure +++ b/configure @@ -3545,7 +3545,7 @@ swresample_suggest="libm libsoxr" swscale_deps="avutil" swscale_suggest="libm" -avcodec_extralibs="pthreads_extralibs iconv_extralibs" +avcodec_extralibs="pthreads_extralibs iconv_extralibs dxva2_extralibs" avfilter_extralibs="pthreads_extralibs" avutil_extralibs="d3d11va_extralibs nanosleep_extralibs pthreads_extralibs vaapi_drm_extralibs vaapi_x11_extralibs vdpau_x11_extralibs" -- 2.20.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] VP4 data tables
On 1/6/2019 4:43 AM, Peter Ross wrote: > --- > libavcodec/vp4data.h | 3784 ++ > 1 file changed, 3784 insertions(+) > create mode 100644 libavcodec/vp4data.h This should be squashed with the patch adding the decoder before pushing. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: add dxva2 extralibs to avcodec
On 1/6/19, James Almer wrote: > DXVA2 may be enabled even when every relevant module is disabled, > which would result in the dependency generator not including its > extralibs to avcodec. > > Fixes ticket #7642. > > Signed-off-by: James Almer > --- > configure | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/configure b/configure > index ead5181bc3..785a9be79f 100755 > --- a/configure > +++ b/configure > @@ -3545,7 +3545,7 @@ swresample_suggest="libm libsoxr" > swscale_deps="avutil" > swscale_suggest="libm" > > -avcodec_extralibs="pthreads_extralibs iconv_extralibs" > +avcodec_extralibs="pthreads_extralibs iconv_extralibs dxva2_extralibs" > avfilter_extralibs="pthreads_extralibs" > avutil_extralibs="d3d11va_extralibs nanosleep_extralibs pthreads_extralibs > vaapi_drm_extralibs vaapi_x11_extralibs vdpau_x11_extralibs" > probably ok ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: add dxva2 extralibs to avcodec
2019-01-06 16:19 GMT+01:00, James Almer : > DXVA2 may be enabled even when every relevant module is disabled, > which would result in the dependency generator not including its > extralibs to avcodec. > > Fixes ticket #7642. Thank you! Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] swscale/output: VSX-optimize 9-16 bit yuv2planeX
On Sun, 6 Jan 2019 13:23:43 +0100 Carl Eugen Hoyos wrote: > 2019-01-04 20:43 GMT+01:00, Lauri Kasanen : > > +#ifdef __POWER8_VECTOR__ > > If this is correct, I assume it fixes a bug in the current code > and should be a separate patch, no? > > > case 16: > > c->yuv2plane1 = isBE(dstFormat) ? yuv2plane1_16BE_vsx : > > yuv2plane1_16LE_vsx; > > +c->yuv2planeX = isBE(dstFormat) ? yuv2planeX_16BE_vsx : > > yuv2planeX_16LE_vsx; > > break; > > -#endif > > +#endif /* __POWER8_VECTOR__ */ These mails do tend to get long with so many bench results, but that was covered: > The existing VSX yuv2plane1 is also ifdefed out for POWER7, even though it > works there. > This is for cleanliness mainly, separating the macros would be a bit > uglier. If we have POWER7 users who need that one, please speak up. - Lauri ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] swscale/output: VSX-optimize 9-16 bit yuv2planeX
2019-01-04 20:43 GMT+01:00, Lauri Kasanen : > The existing VSX yuv2plane1 is also ifdefed out for POWER7, > even though it works there. > This is for cleanliness mainly, separating the macros would > be a bit uglier. Please make it a bit uglier. Sorry for missing this paragraph, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] dstdec: big-endian compatiblity
On Sun, Jan 06, 2019 at 12:57:37PM +0100, Carl Eugen Hoyos wrote: > 2019-01-06 12:12 GMT+01:00, Peter Ross : > > for the '127-bit shift left' algorithm to work as intended, little-endian > > reads and writes must be used. > > > Why not using AV_WL64() and and AV_RL64()? good question. > Is there a measurable speed difference? x86: no difference, compiler output is identical. other cpus that do not support unaligned reads: big difference, due to the compiler inserting additional instructions to check the alignment of the data. mipsel: RN64A: bench: utime=105.902s stime=0.040s rtime=105.933s RN64: bench: utime=230.055s stime=0.004s rtime=230.082s why so much difference? the 127-bit shift left operation must happen for each 1-bit DSD sample. in a single channel of DSD audio, there are at least 2.8 millions 1-bit samples per second. -- Peter (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] VP4 data tables
On Sun, Jan 06, 2019 at 02:40:44PM -0300, James Almer wrote: > On 1/6/2019 4:43 AM, Peter Ross wrote: > > --- > > libavcodec/vp4data.h | 3784 ++ > > 1 file changed, 3784 insertions(+) > > create mode 100644 libavcodec/vp4data.h > > This should be squashed with the patch adding the decoder before pushing. shall do. and i will change those arrays to use uint8_t. thanks for spotting that. -- Peter (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] dstdec: big-endian compatiblity
2019-01-06 23:55 GMT+01:00, Peter Ross : > On Sun, Jan 06, 2019 at 12:57:37PM +0100, Carl Eugen Hoyos wrote: >> 2019-01-06 12:12 GMT+01:00, Peter Ross : >> > for the '127-bit shift left' algorithm to work as intended, >> > little-endian >> > reads and writes must be used. >> > >> Why not using AV_WL64() and and AV_RL64()? > > good question. > >> Is there a measurable speed difference? > > x86: no difference, compiler output is identical. > > other cpus that do not support unaligned reads: big difference, due to the > compiler inserting additional instructions to check the alignment of the > data. > > mipsel: > RN64A: bench: utime=105.902s stime=0.040s rtime=105.933s > RN64: bench: utime=230.055s stime=0.004s rtime=230.082s > > why so much difference? the 127-bit shift left operation must happen for > each 1-bit DSD sample. in a single channel of DSD audio, there are at > least 2.8 millions 1-bit samples per second. Sounds to me as if we would need AV_R[BL]xxA which is aligned for native endian (only). But this may be unrelated to your patch, you could add a comment tough that this makes a difference. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/qpeg: Optimize long runs in qpeg_decode_intra() not spanning a full row
Fixes: Timeout
Fixes:
11354/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_QPEG_fuzzer-5766275943366656
Before: Executed
clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_QPEG_fuzzer-5766275943366656
in 9470 ms
After : Executed
clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_QPEG_fuzzer-5766275943366656
in 134 ms
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/qpeg.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavcodec/qpeg.c b/libavcodec/qpeg.c
index cb452621e7..654fd998d6 100644
--- a/libavcodec/qpeg.c
+++ b/libavcodec/qpeg.c
@@ -80,7 +80,10 @@ static void qpeg_decode_intra(QpegContext *qctx, uint8_t
*dst,
p = bytestream2_get_byte(&qctx->buffer);
for(i = 0; i < run; i++) {
-dst[filled++] = p;
+int step = FFMIN(run - i, width - filled);
+memset(dst+filled, p, step);
+filled += step;
+i += step - 1;
if (filled >= width) {
filled = 0;
dst -= stride;
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/avpacket: Avoid unspecific return -1 for av_grow_packet()
On Sun, Jan 06, 2019 at 10:43:53AM -0300, James Almer wrote:
> On 1/6/2019 10:36 AM, Carl Eugen Hoyos wrote:
> > 2019-01-02 0:23 GMT+01:00, Michael Niedermayer :
> >> ffmpeg | branch: master | Michael Niedermayer |
> >> Mon
> >> Dec 31 18:25:18 2018 +0100| [9520d51e21f9aa5adc807b0b89322bd822b06738] |
> >> committer: Michael Niedermayer
> >>
> >> avcodec/avpacket: Avoid unspecific return -1 for av_grow_packet()
> >>
> >> Reviewed-by: Paul B Mahol
> >> Signed-off-by: Michael Niedermayer
> >>
> >>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=9520d51e21f9aa5adc807b0b89322bd822b06738
> >> ---
> >>
> >> libavcodec/avpacket.c | 4 ++--
> >> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
> >> index e160ad3033..11ac4e80cd 100644
> >> --- a/libavcodec/avpacket.c
> >> +++ b/libavcodec/avpacket.c
> >> @@ -112,7 +112,7 @@ int av_grow_packet(AVPacket *pkt, int grow_by)
> >> av_assert0((unsigned)pkt->size <= INT_MAX -
> >> AV_INPUT_BUFFER_PADDING_SIZE);
> >> if ((unsigned)grow_by >
> >> INT_MAX - (pkt->size + AV_INPUT_BUFFER_PADDING_SIZE))
> >> -return -1;
> >> +return AVERROR(ENOMEM);
> >>
> >> new_size = pkt->size + grow_by + AV_INPUT_BUFFER_PADDING_SIZE;
> >> if (pkt->buf) {
> >> @@ -124,7 +124,7 @@ int av_grow_packet(AVPacket *pkt, int grow_by)
> >> } else {
> >> data_offset = pkt->data - pkt->buf->data;
> >> if (data_offset > INT_MAX - new_size)
> >> -return -1;
> >> +return AVERROR(ENOMEM);
> >
> > Is this really correct?
> > At least on some 64bit systems, larger allocations should be possible,
> > we are simply assuming invalid data if such an allocation is tried, no?
>
> Even if av_max_alloc() allows the API user to allocate more than INT_MAX
> bytes, AVPackets can't handle it as they use int for size.
>
> And afaik, we have been using ERANGE as return error when an attempted
> allocation is outside the allowed range. So maybe that's what should be
> used here.
about error codes
allocation can fail for many reasons
for example lack of physical memory, per process or per allocation
limits, or others.
we could return something else if people want, but iam not sure ERANGE is
ideal here
from libc docs:
-- Macro: int ERANGE
Range error; used by mathematical functions when the result value
is not representable because of overflow or underflow.
if one looks at a function like av_grow_packet() it makes some sense
but the error codes are often passed through many functions and
when a final demux/decode/encode/... function then returns the failure
I think ENOMEM is closer than ERANGE to what the error is about.
I mean if a encode() returns
"Range error; used by mathematical functions when the result value is not
representable because of overflow or underflow."
this doesnt lead directly to a allocation size issue but sounds more
like an issue in some math computation
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/file: Fix file delete for Windows
>On 12/31/18, 1:08 PM, "Karthick J" wrote: > >From: Karthick Jeyapal > >Fixes bug id : 7638 >--- > libavformat/file.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > [...] Pushed ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH V5 1/2] avutil: add ROI (Region Of Interest) data struct and bump version
thanks a lot for all your valuable comments. > -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Nicolas George > Sent: Saturday, January 05, 2019 12:51 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH V5 1/2] avutil: add ROI (Region Of > Interest) data struct and bump version > > James Almer (12019-01-04): > > We already did size_t for AVSphericalMapping and had to change them to > > uint32_t. > > size_t is not the correct type at all, as video dimensions are not > > system dependent, > > I fully agree with that. > > > and it will generate the same issues we already > experienced with > >AVSphericalMapping in fate tests. > > I disagree with that: for some things, size_t would be the correct type, and > in > that case, the FATE test should work. A misdesigned FATE test should not > direct the choice of type. Also, IIUC, somebody said the issue was fixed. > > For me, the definite argument is: All the rest of the code uses int for frame > size and coordinate, so new code should use int too unless there is a very > good and specific reason. > > Note that while we disagree on the reasons, I think we agree on the > conclusion, which is what matter. > > Regards, > > -- > Nicolas George > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel For the type of ROI coordinate, in struct AVFrame, there are ' int width, height;' and 'size_t crop_top;' as reference, I'll choose int. For the type of qoffset, I'll change to AVRational. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH V5 2/2] avcodec/libx264: add support for ROI-based encoding
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Moritz Barsnick
> Sent: Friday, January 04, 2019 7:58 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH V5 2/2] avcodec/libx264: add support
> for ROI-based encoding
>
> On Fri, Jan 04, 2019 at 00:35:43 +0800, Guo, Yejun wrote:
> > @@ -345,6 +350,50 @@ static int X264_frame(AVCodecContext *ctx,
> > AVPacket *pkt, const AVFrame *frame,
> [...]
> > +if (sd) {
> > +if (x4->params.rc.i_aq_mode == X264_AQ_NONE) {
> > +av_log(ctx, AV_LOG_WARNING, "Adaptive quantization must be
> enabled to use ROI encoding, skipping ROI.\n");
> > +} else {
> > +if (frame->interlaced_frame == 0) {
> [...]
> > +} else {
> > +av_log(ctx, AV_LOG_WARNING, "interlaced_frame not
> supported for ROI encoding yet, skipping ROI.\n");
> > +}
>
> Are these warnings given on every frame, if applicable? If so, that may give a
> lot of console spam.
yes, it acts so, just like the av_log in function reconfig_encoder in the same
file.
looks it is not good, I'll add a flag to print only once.
>
> Moritz
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2] libswscale/ppc: VSX-optimize 9-16 bit yuv2planeX
./ffmpeg_g -f rawvideo -pix_fmt rgb24 -s hd1080 -i /dev/zero -pix_fmt
yuv420p16be \
-s 1920x1728 -f null -vframes 100 -v error -nostats -
9-14 bit funcs get about 6x speedup, 16-bit gets about 15x.
Fate passes, each format tested with an image to video conversion.
Only POWER8 includes 32-bit vector multiplies, so POWER7 is locked out
of the 16-bit function. This includes the vec_mulo/mule functions too,
not just vmuluwm.
yuv420p9le
12341 UNITS in planarX, 130976 runs, 96 skips
73752 UNITS in planarX, 131066 runs, 6 skips
yuv420p9be
12364 UNITS in planarX, 131025 runs, 47 skips
73001 UNITS in planarX, 131055 runs, 17 skips
yuv420p10le
12386 UNITS in planarX, 131042 runs, 30 skips
72735 UNITS in planarX, 131062 runs, 10 skips
yuv420p10be
12337 UNITS in planarX, 131045 runs, 27 skips
72734 UNITS in planarX, 131057 runs, 15 skips
yuv420p12le
12236 UNITS in planarX, 131058 runs, 14 skips
73029 UNITS in planarX, 131062 runs, 10 skips
yuv420p12be
12218 UNITS in planarX, 130973 runs, 99 skips
72402 UNITS in planarX, 131069 runs, 3 skips
yuv420p14le
12168 UNITS in planarX, 131067 runs, 5 skips
72480 UNITS in planarX, 131069 runs, 3 skips
yuv420p14be
12358 UNITS in planarX, 130948 runs,124 skips
73772 UNITS in planarX, 131063 runs, 9 skips
yuv420p16le
10439 UNITS in planarX, 130911 runs,161 skips
157923 UNITS in planarX, 131068 runs, 4 skips
yuv420p16be
10463 UNITS in planarX, 130874 runs,198 skips
154405 UNITS in planarX, 131061 runs, 11 skips
Signed-off-by: Lauri Kasanen
---
v2: Separate macros so that yuv2plane1_16_vsx remains available for power7
libswscale/ppc/swscale_ppc_template.c | 4 +-
libswscale/ppc/swscale_vsx.c | 190 +-
2 files changed, 189 insertions(+), 5 deletions(-)
diff --git a/libswscale/ppc/swscale_ppc_template.c
b/libswscale/ppc/swscale_ppc_template.c
index 00e4b99..11decab 100644
--- a/libswscale/ppc/swscale_ppc_template.c
+++ b/libswscale/ppc/swscale_ppc_template.c
@@ -21,7 +21,7 @@
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
-static void FUNC(yuv2planeX_16)(const int16_t *filter, int filterSize,
+static void FUNC(yuv2planeX_8_16)(const int16_t *filter, int filterSize,
const int16_t **src, uint8_t *dest,
const uint8_t *dither, int offset, int x)
{
@@ -88,7 +88,7 @@ static void FUNC(yuv2planeX)(const int16_t *filter, int
filterSize,
yuv2planeX_u(filter, filterSize, src, dest, dst_u, dither, offset, 0);
for (i = dst_u; i < dstW - 15; i += 16)
-FUNC(yuv2planeX_16)(filter, filterSize, src, dest + i, dither,
+FUNC(yuv2planeX_8_16)(filter, filterSize, src, dest + i, dither,
offset, i);
yuv2planeX_u(filter, filterSize, src, dest, dstW, dither, offset, i);
diff --git a/libswscale/ppc/swscale_vsx.c b/libswscale/ppc/swscale_vsx.c
index 70da6ae..1fd392e 100644
--- a/libswscale/ppc/swscale_vsx.c
+++ b/libswscale/ppc/swscale_vsx.c
@@ -83,6 +83,8 @@
#include "swscale_ppc_template.c"
#undef FUNC
+#undef vzero
+
#endif /* !HAVE_BIGENDIAN */
static void yuv2plane1_8_u(const int16_t *src, uint8_t *dest, int dstW,
@@ -180,6 +182,76 @@ static void yuv2plane1_nbps_vsx(const int16_t *src,
uint16_t *dest, int dstW,
yuv2plane1_nbps_u(src, dest, dstW, big_endian, output_bits, i);
}
+static void yuv2planeX_nbps_u(const int16_t *filter, int filterSize,
+ const int16_t **src, uint16_t *dest, int dstW,
+ int big_endian, int output_bits, int start)
+{
+int i;
+int shift = 11 + 16 - output_bits;
+
+for (i = start; i < dstW; i++) {
+int val = 1 << (shift - 1);
+int j;
+
+for (j = 0; j < filterSize; j++)
+val += src[j][i] * filter[j];
+
+output_pixel(&dest[i], val);
+}
+}
+
+static void yuv2planeX_nbps_vsx(const int16_t *filter, int filterSize,
+const int16_t **src, uint16_t *dest, int dstW,
+int big_endian, int output_bits)
+{
+const int dst_u = -(uintptr_t)dest & 7;
+const int shift = 11 + 16 - output_bits;
+const int add = (1 << (shift - 1));
+const int clip = (1 << output_bits) - 1;
+const uint16_t swap = big_endian ? 8 : 0;
+const vector uint32_t vadd = (vector uint32_t) {add, add, add, add};
+const vector uint32_t vshift = (vector uint32_t) {shift, shift, shift,
shift};
+const vector uint16_t vswap = (vector uint16_t) {swap, swap, swap, swap,
swap, swap, swap, swap};
+const vector uint16_t vlargest = (vector uint16_t) {clip, clip, clip,
clip, clip, clip, clip, clip};
+const vector int16_t vzero = vec_splat_s16(0);
+const vector uint8_t vperm = (vector uint8_t) {0, 1, 8, 9, 2, 3, 10, 11,
4, 5, 12, 13, 6,
