Re: [FFmpeg-devel] [PATCH 1/6] ac3enc_fixed: convert to 32-bit sample format

Lynne: > The AC3 encoder used to be a separate library called "Aften", which > got merged into libavcodec (literally, SVN commits and all). > The merge preserved as much features from the library as possible. > > The code had two versions - a fixed point version and a floating > point version. FFm

Re: [FFmpeg-devel] [PATCH 1/6] ac3enc_fixed: convert to 32-bit sample format

Jan 12, 2021, 08:48 by andreas.rheinha...@gmail.com: > Lynne: > >> Jan 9, 2021, 22:01 by andreas.rheinha...@gmail.com: >> >>> Lynne: >>> @@ -165,7 +164,11 @@ typedef struct AC3EncodeContext { AVCodecContext *avctx; ///< parent AVCodecContext PutBitContext pb;

Re: [FFmpeg-devel] [PATCH 1/6] ac3enc_fixed: convert to 32-bit sample format

Jan 12, 2021, 08:59 by andreas.rheinha...@gmail.com: > Lynne: > >> The AC3 encoder used to be a separate library called "Aften", which >> got merged into libavcodec (literally, SVN commits and all). >> The merge preserved as much features from the library as possible. >> >> The code had two versio

Re: [FFmpeg-devel] [PATCH 6/6] fft_fixed: remove 16-bit FFT code

Jan 12, 2021, 08:50 by andreas.rheinha...@gmail.com: > Lynne: > >> Jan 9, 2021, 20:22 by d...@lynne.ee: >> >>> No longer used by anything. >>> Unfortunately the old FFT_FLOAT/FFT_FIXED_32 is left as-is. It's >>> simply too much work for code meant to be all removed anyway. >>> >>> Patch attached.

Re: [FFmpeg-devel] [PATCH 6/6] fft_fixed: remove 16-bit FFT code

Lynne: > Jan 12, 2021, 08:50 by andreas.rheinha...@gmail.com: > >> Lynne: >> >>> Jan 9, 2021, 20:22 by d...@lynne.ee: >>> No longer used by anything. Unfortunately the old FFT_FLOAT/FFT_FIXED_32 is left as-is. It's simply too much work for code meant to be all removed anyway.

Re: [FFmpeg-devel] [PATCH] libavcodec/hevcdsp: port SIMD idct functions from 32-bit.

Hi, On 2021-01-08 21:36, reimar.doeffin...@gmx.de wrote: From: Reimar Döffinger Makes SIMD-optimized 8x8 and 16x16 idcts for 8 and 10 bit depth available on aarch64. For a UHD HDR (10 bit) sample video these were consuming the most time and this optimization reduced overall decode time from 19

[FFmpeg-devel] [PATCH 1/3] avformat/dashdec: check init_section before use it.

because there have no Initialization in SegmentTemplate, so it will have no init_section for init segment file. but in the is_common_init_section_exist function it will be used for check to url, url_offset and size, so check init_section before use init_section fix ticket: 9062 Signed-off-by: liu

[FFmpeg-devel] [PATCH 3/3] avformat/dashdec: rename variable name for more readable

Rename is_init_section_common_audio to is_init_section_common_subtitle for is_common_init_section_exist(c->subtitles, c->n_subtitles). Because it is checked to subtitles, not audio. Signed-off-by: liuqi05 --- libavformat/dashdec.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff

[FFmpeg-devel] [PATCH 2/3] avformat/dashdec: fix code style in is_common_init_section_exist

make the code block short when it too long. Signed-off-by: liuqi05 --- libavformat/dashdec.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c index 5f9b9ba882..85b5f147e8 100644 --- a/libavformat/dashdec.c +++ b/libavformat/dash

[FFmpeg-devel] [PATCH v6] avformat/udp: return the error code instead of generic EIO

From: Limin Wang Signed-off-by: Limin Wang --- libavformat/udp.c | 58 ++- 1 file changed, 36 insertions(+), 22 deletions(-) diff --git a/libavformat/udp.c b/libavformat/udp.c index 13c346a..42e4563 100644 --- a/libavformat/udp.c +++ b/libavf

Re: [FFmpeg-devel] [PATCH v6] avformat/udp: return the error code instead of generic EIO

lance.lmw...@gmail.com (12021-01-12): > From: Limin Wang > > Signed-off-by: Limin Wang > --- > libavformat/udp.c | 58 > ++- > 1 file changed, 36 insertions(+), 22 deletions(-) > > diff --git a/libavformat/udp.c b/libavformat/udp.c > index 1

[FFmpeg-devel] [PATCH] avformat/webvttdec: Fix WebVTT decoder truncating files at first STYLE block

Bug-ID: 9064 The webvtt decoder truncates the file at the first such block. Since these blocks typically occur at the top of the webvtt file, this results in an empty file (except for the WEBVTT header line). Reason is that at STYLE block neither parses as a valid cue block nor is it skipped like

Re: [FFmpeg-devel] [PATCH] avformat/webvttdec: Fix WebVTT decoder truncating files at first STYLE block

Hijacking with related, similar patch from a few months ago: https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=2538 On Tue, Jan 12, 2021 at 4:56 PM Roderich Schupp wrote: > Bug-ID: 9064 > > The webvtt decoder truncates the file at the first such block. > Since these blocks typically occu

[FFmpeg-devel] [PATCH] libavcodec/hevcdsp: port SIMD idct functions from 32-bit.

From: Reimar Döffinger Makes SIMD-optimized 8x8 and 16x16 idcts for 8 and 10 bit depth available on aarch64. For a UHD HDR (10 bit) sample video these were consuming the most time and this optimization reduced overall decode time from 19.4s to 16.4s, approximately 15% speedup. Test sample was the

[FFmpeg-devel] [PATCH v2 1/5] ac3enc_fixed: convert to 32-bit sample format

The AC3 encoder used to be a separate library called "Aften", which got merged into libavcodec (literally, SVN commits and all). The merge preserved as much features from the library as possible. The code had two versions - a fixed point version and a floating point version. FFmpeg had floating po

[FFmpeg-devel] [PATCH v2 2/5] ac3enc: do not clip coefficients after transforms

In either encoder, its impossible for the coefficients to go past 25 bits right after the MDCT. Our MDCT is numerically stable. For the floating point encoder, in case a NaN is contained, lrintf() will raise a floating point exception during the conversion. Patch attached. >From e384c30349177bc7

[FFmpeg-devel] [PATCH v2 3/5] ac3enc: halve the MDCT window size by using vector_fmul_reverse

This brings the encoder in-line with the rest of ours and saves on a bit of memory. Patch attached. >From aa4464763919145eb3c58475b6f1fd1418d684c9 Mon Sep 17 00:00:00 2001 From: Lynne Date: Sat, 9 Jan 2021 17:27:16 +0100 Subject: [PATCH v2 3/5] ac3enc: halve the MDCT window size by using vecto

[FFmpeg-devel] [PATCH v2 4/5] ac3enc_fixed: drop unnecessary fixed-point DSP code

Patch attached. >From adfbae619a9ac2584e45096e3b98a3c7ad36ceb4 Mon Sep 17 00:00:00 2001 From: Lynne Date: Sat, 9 Jan 2021 03:19:18 +0100 Subject: [PATCH v2 4/5] ac3enc_fixed: drop unnecessary fixed-point DSP code --- libavcodec/ac3dsp.c | 60 --- libavcodec/ac3dsp.h

[FFmpeg-devel] [PATCH v2 5/5] fft: remove 16-bit FFT and MDCT code

No longer used by anything. Unfortunately the old FFT_FLOAT/FFT_FIXED_32 is left as-is. It's simply too much work for code meant to be all removed anyway. Merged the 2 patches and fixed all tests. >From 47da78c332dc00a69eb0fae75cba6d7f71f26070 Mon Sep 17 00:00:00 2001 From: Lynne Date: Sat, 9 J

Re: [FFmpeg-devel] [PATCH] libavcodec/hevcdsp: port SIMD idct functions from 32-bit.

> On 12 Jan 2021, at 13:24, Josh Dekker wrote: > > Hi, > > On 2021-01-08 21:36, reimar.doeffin...@gmx.de wrote: >> From: Reimar Döffinger >> Makes SIMD-optimized 8x8 and 16x16 idcts for 8 and 10 bit depth >> available on aarch64. >> For a UHD HDR (10 bit) sample video these were consuming the

Re: [FFmpeg-devel] [PATCH] Add support for "omp simd" pragma.

> > On 10 Jan 2021, at 19:55, Lynne wrote: > > Jan 10, 2021, 17:43 by reimar.doeffin...@gmx.de: > >> From: Reimar Döffinger >> >> real0m15.040s >> user0m18.874s (80.7% of original) >> sys 0m0.168s >> > > I think I have to disagree. > The performance gains are marginal, It’s alm

Re: [FFmpeg-devel] [PATCH] Add support for "omp simd" pragma.

> -Original Message- > From: ffmpeg-devel On Behalf Of > reimar.doeffin...@gmx.de > Sent: Sunday, January 10, 2021 5:44 PM > To: ffmpeg-devel@ffmpeg.org > Cc: Reimar Döffinger > Subject: [FFmpeg-devel] [PATCH] Add support for "omp simd" pragma. > > From: Reimar Döffinger > > This req

Re: [FFmpeg-devel] [PATCH v2] Replace arrays of pointers to strings by arrays of strings

> On 12 Jan 2021, at 02:41, Andreas Rheinhardt > wrote: > Of course I am all ears for how to make it clear that someone who > modifies the strings also needs to check the array dimensions. I think I kind of agree with the other comments, this would/should rather have to be something that can

Re: [FFmpeg-devel] [PATCH] Add support for "omp simd" pragma.

> On 12 Jan 2021, at 19:52, Soft Works wrote: > > > >> -Original Message- >> From: ffmpeg-devel On Behalf Of >> reimar.doeffin...@gmx.de >> Sent: Sunday, January 10, 2021 5:44 PM >> To: ffmpeg-devel@ffmpeg.org >> Cc: Reimar Döffinger >> Subject: [FFmpeg-devel] [PATCH] Add support fo

Re: [FFmpeg-devel] [PATCH] Add support for "omp simd" pragma.

Jan 12, 2021, 19:28 by reimar.doeffin...@gmx.de: >> >> On 10 Jan 2021, at 19:55, Lynne wrote: >> >> Jan 10, 2021, 17:43 by reimar.doeffin...@gmx.de: >> >>> From: Reimar Döffinger >>> >>> real0m15.040s >>> user0m18.874s (80.7% of original) >>> sys 0m0.168s >>> >> >> I think I have to

Re: [FFmpeg-devel] Development of a CUDA accelerated variant of the libav vf_tonemap

That's great! Any way for me to pull that branch or otherwise contribute? Have been using FFmpeg for a few years now, so hopping to be able to give back. On Tue, Jan 12, 2021 at 5:55 am, Lynne wrote: Jan 11, 2021, 23:27 by felix.leclair...@hotmail.com :

Re: [FFmpeg-devel] [PATCH v2 1/5] ac3enc_fixed: convert to 32-bit sample format

Lynne: > The AC3 encoder used to be a separate library called "Aften", which > got merged into libavcodec (literally, SVN commits and all). > The merge preserved as much features from the library as possible. > > The code had two versions - a fixed point version and a floating > point version. FFm

Re: [FFmpeg-devel] [PATCH] Add support for "omp simd" pragma.

> On 12 Jan 2021, at 21:46, Lynne wrote: > > Jan 12, 2021, 19:28 by reimar.doeffin...@gmx.de: > >> It’s almost 20%. At least for this combination of >> codec and stream a large amount of time is spend in >> non-DSP functions, so even hand-written assembler >> won’t give you huge gains. >> > I

Re: [FFmpeg-devel] [PATCH] Add support for "omp simd" pragma.

> -Original Message- > From: ffmpeg-devel On Behalf Of > Lynne > Sent: Tuesday, January 12, 2021 9:47 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH] Add support for "omp simd" pragma. > > Jan 12, 2021, 19:28 by reimar.doeffin

Re: [FFmpeg-devel] [PATCH v6] avformat/udp: return the error code instead of generic EIO

On Tue, 12 Jan 2021, Nicolas George wrote: lance.lmw...@gmail.com (12021-01-12): @@ -888,23 +901,24 @@ static int udp_open(URLContext *h, const char *uri, int flags) } if ((!is_output && s->circular_buffer_size) || (is_output && s->bitrate && s->circular_buffer_size)) { -

[FFmpeg-devel] [PATCH 4/4] avformat/electronicarts: More chunk_size checks

Fixes: Timeout Fixes: 26909/clusterfuzz-testcase-minimized-ffmpeg_dem_EA_fuzzer-6489496553783296 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavformat/electronicarts.c | 6 ++ 1 file changed, 6

[FFmpeg-devel] [PATCH 2/4] avformat/asfdec_o: Check lang_idx

Fixes: index 26981 out of bounds for type 'ASFStreamData [128]' Fixes: 27334/clusterfuzz-testcase-minimized-ffmpeg_dem_ASF_O_fuzzer-6197611002068992 Alternatively the array could be increased in size or the cases not fitting be ignored Found-by: continuous fuzzing process https://github.com/go

[FFmpeg-devel] [PATCH 1/4] avformat/asfdec_o: Check size vs. offset in detect_unknown_subobject()

Fixes: signed integer overflow: 2314885530818453566 + 7503032301549264928 cannot be represented in type 'long' Fixes: 26639/clusterfuzz-testcase-minimized-ffmpeg_dem_ASF_O_fuzzer-6024222100684800 Alternatively this could be ignored but then the end condition of the loop would be hard to reach as

[FFmpeg-devel] [PATCH 3/4] avformat/flvdec: Check for EOF in amf_skip_tag()

Fixes: Timeout Fixes: 29070/clusterfuzz-testcase-minimized-ffmpeg_dem_KUX_fuzzer-5650106766458880 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavformat/flvdec.c | 3 +++ 1 file changed, 3 insertion

Re: [FFmpeg-devel] [PATCH v6] avformat/udp: return the error code instead of generic EIO

On Tue, Jan 12, 2021 at 03:36:00PM +0100, Nicolas George wrote: > lance.lmw...@gmail.com (12021-01-12): > > From: Limin Wang > > > > Signed-off-by: Limin Wang > > --- > > libavformat/udp.c | 58 > > ++- > > 1 file changed, 36 insertions(+), 2

Re: [FFmpeg-devel] [PATCH v2 1/5] ac3enc_fixed: convert to 32-bit sample format

Jan 12, 2021, 22:24 by andreas.rheinha...@gmail.com: > Lynne: > >> The AC3 encoder used to be a separate library called "Aften", which >> got merged into libavcodec (literally, SVN commits and all). >> The merge preserved as much features from the library as possible. >> >> The code had two versio

Re: [FFmpeg-devel] [PATCH v4] avcodec/libvpxenc: add a way to set VP9E_SET_SVC_REF_FRAME_CONFIG

On Fri, Jan 8, 2021 at 3:33 PM Wonkap Jang wrote: > > In order to fine-control referencing schemes in VP9 encoding, there > is a need to use VP9E_SET_SVC_REF_FRAME_CONFIG method. This commit > provides a way to use the API through frame metadata. > --- > doc/encoders.texi | 32 ++

[FFmpeg-devel] [PATCH v7] avformat/udp: return the error code instead of generic EIO

From: Limin Wang Signed-off-by: Limin Wang --- libavformat/udp.c | 58 ++- 1 file changed, 36 insertions(+), 22 deletions(-) diff --git a/libavformat/udp.c b/libavformat/udp.c index 13c346a..c4e403b 100644 --- a/libavformat/udp.c +++ b/libavf

Re: [FFmpeg-devel] [PATCH v6] avformat/udp: return the error code instead of generic EIO

On Tue, Jan 12, 2021 at 10:35:52PM +0100, Marton Balint wrote: > > > On Tue, 12 Jan 2021, Nicolas George wrote: > > > lance.lmw...@gmail.com (12021-01-12): > > > @@ -888,23 +901,24 @@ static int udp_open(URLContext *h, const char *uri, > > > int flags) > > > } > > > > > > if ((!is_ou

Re: [FFmpeg-devel] [PATCH v2 1/3] kmsgrab: Use invalid modifier if modifiers weren't used.

A friendly ping on reviewing this series. Thanks! On Sat, Nov 14, 2020 at 12:15 AM Bas Nieuwenhuizen wrote: > > The kernel defaults to initializing the field to 0 when modifiers > are not used and this happens to be linear. If we end up actually > passing the modifier to a driver, tiling issues h

Re: [FFmpeg-devel] [PATCH v3 07/11] avcodec: add cbs for h266/vvc

On 1/11/2021 1:33 PM, Nuo Mi wrote: --- configure |2 + libavcodec/Makefile |1 + libavcodec/cbs.c |6 + libavcodec/cbs_h2645.c| 374 libavcodec/cbs_h266.h | 758 +++ l

Re: [FFmpeg-devel] Development of a CUDA accelerated variant of the libav vf_tonemap

Jan 12, 2021, 22:13 by felix.leclair...@hotmail.com: > That's great! Any way for me to pull that branch or otherwise contribute? > The branch is here for now - https://github.com/haasn/FFmpeg The only blocker to having it merged is for me to rewrite the vulkan synchronization mechanism we current