This is not needed after 2d9d6afb8d2f284f5e620ecc19f643d5cd3facb8.
Fix broken file when muxing with frag_interleave and an empty first track.
Signed-off-by: Xiaolei Yu
---
libavformat/movenc.c | 2 +-
tests/fate/mov.mak | 17 +
2 files changed, 18 insertions(+), 1 deletion(-)
> -Original Message-
> From: ffmpeg-devel On Behalf Of Frank
> Plowman
> Sent: 2024年11月29日 6:21
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v2] lavc/x86/videodsp: Drop MMX usage
>
> Ping
Pushed, thanks.
>
> On 16/11/2024 17:59, Frank Plowman wrote:
> > Remove t
also add STREAM_TYPE_PRIVATE_SECTION since a private_section() is not a
PES_packet().
---
libavformat/mpegts.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index b4bf70bcbf..e470f12d22 100644
--- a/libavformat/mpegt
Note ISO/IEC 13818-1 defines an Extension_descriptor with descriptor_tag value
0x3f (63), so I kept the DVB comment.
I don't know what defines stream_type value 0x8a as DTS.
I don't have any Blu-ray standards so I don't know where those stream_type
values are defined.
---
libavformat/mpegts.c
From: sunyuechi
k230 banana_f3
sad_8x16_c: 387.7 ( 1.00x)394.9 ( 1.00x)
sad_8x16_rvv_i32: 109.7 ( 3.53x)103.5 ( 3.82x)
sad_16x8_c: 378.2 ( 1.00x)384.7 ( 1.00x)
sad_16x8_rvv_i32:82.0 ( 4.61x
From: sunyuechi
k230 banana_f3
put_hevc_pel_pixels4_8_c: 61.6 ( 1.00x)69.5 ( 1.00x)
put_hevc_pel_pixels4_8_rvv_i32: 24.6 ( 2.50x)28.0 ( 2.48x)
put_hevc_pel_pixels8_8_c: 209.8 ( 1.00x)215.5 ( 1.00x)
From: sunyuechi
k230
banana_f3
put_chroma_pixels_8_4x4_c: 63.5 ( 1.00x)59.2 (
1.00x)
put_chroma_pixels_8_4x4_rvv_i32:26.5 ( 2.39x)28.0 (
2.12x)
put_chroma_pixels_8_8
From: sunyuechi
---
libavcodec/riscv/h26x/asm.S | 127 ++
libavcodec/riscv/vvc/vvc_mc_rvv.S | 117 ++-
2 files changed, 132 insertions(+), 112 deletions(-)
create mode 100644 libavcodec/riscv/h26x/asm.S
diff --git a/libavcodec/riscv/h26
From: sunyuechi
k230 banana_f3
dmvr_8_12x20_c: 619.3 ( 1.00x)624.1 ( 1.00x)
dmvr_8_12x20_rvv_i32: 128.6 ( 4.82x)103.4 ( 6.04x)
dmvr_8_20x12_c: 610.0 ( 1.00x)665.6 ( 1.00x)
dm
Hi, why is there an issue with the ABI? I previously just thought that s0
shouldn't be used here.
Rémi Denis-Courmont 于2024年12月1日周日 00:19写道：
> Le keskiviikkona 20. marraskuuta 2024, 3.26.52 EET u...@foxmail.com a
> écrit :
> > From: sunyuechi
> >
> > ---
> > libavcodec/riscv/rv40dsp_rvv.S | 11
From: sunyuechi
---
libavcodec/riscv/vvc/vvc_mc_rvv.S | 46 +++
1 file changed, 23 insertions(+), 23 deletions(-)
diff --git a/libavcodec/riscv/vvc/vvc_mc_rvv.S
b/libavcodec/riscv/vvc/vvc_mc_rvv.S
index 45f4750f82..18532616d9 100644
--- a/libavcodec/riscv/vvc/vvc_mc
Fixes: signed integer overflow: 2 * -4962931467012268000 cannot be represented
in type 'long'
Fixes:
376496313/clusterfuzz-testcase-minimized-ffmpeg_dem_MXF_fuzzer-4921469185884160
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by:
Fixes: signed integer overflow: 1239596184 + 2119376059 cannot be represented
in type 'int'
Fixes:
376136844/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_OSQ_fuzzer-6581164455821312
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-o
Fixes: Timeout
Fixes:
376320337/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TDSC_fuzzer-6259585758855168
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
tools/target_dec_fuzzer.c | 1 +
1 file chan
Fixes: signed integer overflow: -1082982400 + -1195645138 cannot be represented
in type 'int'
Fixes:
376136843/clusterfuzz-testcase-minimized-ffmpeg_SWS_fuzzer-4791844321427456
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Mic
Hi
On Sat, Nov 30, 2024 at 03:23:51PM +0100, Niklas Haas wrote:
> From: Niklas Haas
>
> ---
> libavutil/tests/color_utils.c | 110 ++
> tests/ref/fate/color_utils| 2650 +
> 2 files changed, 2760 insertions(+)
no objections to the patchset, but i didnt revi
Hi
On Sat, Nov 30, 2024 at 03:27:53PM +0100, Niklas Haas wrote:
> On Sat, 30 Nov 2024 15:23:50 +0100 Niklas Haas wrote:
> > From: Niklas Haas
> >
> > The existing av_csp_trc_func_from_id() mostly implements the OETF, except
> > for
> > PQ. As such, we are currently missing a precise definition
Hi Ramiro
On Sat, Nov 30, 2024 at 04:23:36PM +0100, Ramiro Polla wrote:
> For bit depths <= 14, the result is saturated to 15 bits.
> For bit depths > 14, the result is saturated to 19 bits.
>
> x86_64:
> chrRangeFromJpeg8_1920_c:5827.4 5804.5 ( 1.00x)
> chrRangeFromJpeg16_1920_c: 5793.2
Hi
On Sat, Nov 30, 2024 at 04:23:38PM +0100, Ramiro Polla wrote:
> There is an issue with the constants used in YUV to YUV range conversion,
> where the upper bound is not respected when converting to mpeg range.
>
> With this commit, the constants are calculated at runtime, depending on
> the bi
On Sat, Nov 30, 2024 at 8:30 PM llyyr wrote:
>
> On 8/8/24 1:44 AM, llyyr wrote:
> > On 6/7/24 1:29 PM, Hendrik Leppkes wrote:
> >> On Fri, Jun 7, 2024 at 9:47 AM Hendrik Leppkes
> >> wrote:
> >>>
> >>> On Mon, May 27, 2024 at 3:47 PM llyyr wrote:
>
> instead of just resyncing and skip
On Sat, Nov 30, 2024 at 10:58:03PM +0100, martin schitter wrote:
>
>
> On 30.11.24 21:41, Michael Niedermayer wrote:
> > What name should the repository have ?
> > ffmpeg-infra
> > ffmpeg-private
> >
> > (i dont like the sound of "private" for a open source project)
>
> ffmpeg-internals may so
On 30.11.24 21:41, Michael Niedermayer wrote:
What name should the repository have ?
ffmpeg-infra
ffmpeg-private
(i dont like the sound of "private" for a open source project)
ffmpeg-internals may sound nicer
___
ffmpeg-devel mailing list
ffmpeg-d
Hi
On Fri, Nov 29, 2024 at 05:05:02PM +0100, Michael Niedermayer wrote:
> Hi Anton
>
> On Thu, Nov 28, 2024 at 04:17:00PM +0100, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2024-11-19 23:16:17)
> > > > > 3. who has what access (physical and remote/software).
> > > > > 4. Who owns avcode
On 8/8/24 1:44 AM, llyyr wrote:
On 6/7/24 1:29 PM, Hendrik Leppkes wrote:
On Fri, Jun 7, 2024 at 9:47 AM Hendrik Leppkes
wrote:
On Mon, May 27, 2024 at 3:47 PM llyyr wrote:
instead of just resyncing and skipping a bunch of TS packets,
leading to
a loss of frames.
Before this, a stray by
On 11/29/2024 2:17 PM, Michael Niedermayer wrote:
ambisonics mode > 1 does not initialize any layer but layer 0
is unconditionally dereferenced
Fixes: poc-2024-11
Fixes: null pointer dereference
Found-by: 苏童 <220235...@seu.edu.cn>
Signed-off-by: Michael Niedermayer
---
libavformat/iamf_parse.
> 在 2024年12月1日，上午1:22，James Almer 写道：
>
> On 11/30/2024 2:19 PM, Zhao Zhili wrote:
>>> -Original Message-
>>> From: ffmpeg-devel On Behalf Of James
>>> Almer
>>> Sent: 2024年12月1日 0:51
>>> To: ffmpeg-devel@ffmpeg.org
>>> Subject: Re: [FFmpeg-devel] [PATCH 42/42] tests/fate/hevc: add a
On 11/30/2024 2:19 PM, Zhao Zhili wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of James Almer
Sent: 2024年12月1日 0:51
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH 42/42] tests/fate/hevc: add a test for
switching between single and multi-view
On 11/30/2024 1
> -Original Message-
> From: ffmpeg-devel On Behalf Of James Almer
> Sent: 2024年12月1日 0:51
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 42/42] tests/fate/hevc: add a test for
> switching between single and multi-view
>
> On 11/30/2024 1:38 PM, Zhao Zhili wrote:
>
On 11/30/2024 1:38 PM, Zhao Zhili wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of Anton Khirnov
Sent: 2024年8月27日 23:05
To: ffmpeg-devel@ffmpeg.org
Subject: [FFmpeg-devel] [PATCH 42/42] tests/fate/hevc: add a test for switching
between single and multi-view
---
tests/fate/
> -Original Message-
> From: ffmpeg-devel On Behalf Of Anton
> Khirnov
> Sent: 2024年8月27日 23:05
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH 42/42] tests/fate/hevc: add a test for
> switching between single and multi-view
>
> ---
> tests/fate/hevc.mak | 10
Le tiistaina 26. marraskuuta 2024, 5.01.56 EET flow gg a écrit :
> Updated them.
If you update a patchset, resend the series and add a version number like
others do. It's just too complicated to track series over email otherwise.
--
Rémi Denis-Courmont
http://www.remlab.net/
_
Le keskiviikkona 20. marraskuuta 2024, 3.26.52 EET u...@foxmail.com a écrit :
> From: sunyuechi
>
> ---
> libavcodec/riscv/rv40dsp_rvv.S | 113 ++---
> 1 file changed, 75 insertions(+), 38 deletions(-)
>
> diff --git a/libavcodec/riscv/rv40dsp_rvv.S b/libavcodec/risc
On Tue, Nov 26, 2024 at 11:56 AM Anton Khirnov wrote:
> Quoting Ramiro Polla (2024-10-22 11:25:58)
> > On Mon, Oct 21, 2024 at 1:41 AM Michael Niedermayer
> > wrote:
> > > On Thu, Oct 17, 2024 at 01:00:12PM +0200, Ramiro Polla wrote:
> > > > Consider APPx fields that are too short to contain an i
A55 A76
chrRangeFromJpeg16_1920_c: 28840.6 6323.5
chrRangeFromJpeg16_1920_neon: 8436.5 ( 3.42x) 3365.2 ( 1.88x)
chrRangeToJpeg16_1920_c: 23075.1 9195.6
chrRangeToJpeg16_1920_neon: 9393.6 ( 2.46x) 4084.5 ( 2.25x)
l
A55:
chrRangeFromJpeg8_1920_c:28833.8 ( 1.00x)
chrRangeFromJpeg8_1920_neon: 5309.9 ( 5.43x) 5313.1 ( 5.43x)
chrRangeToJpeg8_1920_c: 23070.6 ( 1.00x)
chrRangeToJpeg8_1920_neon:5550.8 ( 4.16x) 5550.8 ( 4.16x)
lumRangeFromJpeg8_1920_c:15388.1 ( 1.00x)
lumRangeFromJpeg8_1920_neon:
chrRangeFromJpeg16_1920_c: 5809.1
chrRangeFromJpeg16_1920_sse2: 3909.5 ( 1.49x)
chrRangeFromJpeg16_1920_avx2: 1985.3 ( 2.93x)
chrRangeToJpeg16_1920_c: 9261.5
chrRangeToJpeg16_1920_sse2:6053.2 ( 1.53x)
chrRangeToJpeg16_1920_sse4:4493.6 ( 2.06x)
chrRangeToJpeg16_1920_avx2:2405
aarch64 A55:
chrRangeFromJpeg8_1920_c: 28839.3 ( 1.00x)
chrRangeFromJpeg8_1920_neon: 5312.2 ( 5.43x) 5309.9 ( 5.43x)
chrRangeToJpeg8_1920_c: 44196.1 ( 1.00x)
chrRangeToJpeg8_1920_neon: 6035.9 ( 7.32x) 5550.8 ( 7.96x)
lumRangeFromJpeg8_1920_c: 15384.3 ( 1.00x)
lumRangeFromJpeg8
chrRangeFromJpeg8_1920_c: 5804.5 ( 1.00x)
chrRangeFromJpeg8_1920_sse2: 1960.2 ( 2.96x) 1955.2 ( 2.97x)
chrRangeFromJpeg8_1920_avx2: 996.1 ( 5.83x) 988.9 ( 5.87x)
chrRangeToJpeg8_1920_c: 9388.6 ( 1.00x)
chrRangeToJpeg8_1920_sse2:1963.7 ( 4.78x) 1949.9 ( 4.81x)
chrRangeToJpeg8_19
For bit depths <= 14, the result is saturated to 15 bits.
For bit depths > 14, the result is saturated to 19 bits.
x86_64:
chrRangeFromJpeg8_1920_c:5827.4 5804.5 ( 1.00x)
chrRangeFromJpeg16_1920_c: 5793.2 5792.8 ( 1.00x)
chrRangeToJpeg8_1920_c: 11726.2 9388.6 ( 1.25x)
chrRangeTo
Changes since v2:
- changed the type of some ints to better represent their signedness and range
(no changes in performance, but it makes the code clearer);
- added more comments about the integer types for coeff and offset depending
on SwsInternal->dstBpc;
- reordered new fields in SwsInternal
From: Niklas Haas
---
libavutil/csp.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/libavutil/csp.c b/libavutil/csp.c
index 7ef822c60b..3dd7bc2562 100644
--- a/libavutil/csp.c
+++ b/libavutil/csp.c
@@ -290,11 +290,7 @@ static const av_csp_trc_function trc_funcs[AVCOL_T
On Sat, 30 Nov 2024 15:23:50 +0100 Niklas Haas wrote:
> From: Niklas Haas
>
> The existing av_csp_trc_func_from_id() mostly implements the OETF, except for
> PQ. As such, we are currently missing a precise definition of an ITU-R EOTF.
> Introduce the new functions av_csp_itu_eotf() and av_csp_itu
From: Niklas Haas
The existing av_csp_trc_func_from_id() mostly implements the OETF, except for
PQ. As such, we are currently missing a precise definition of an ITU-R EOTF.
Introduce the new functions av_csp_itu_eotf() and av_csp_itu_eotf_inv(), to fill
this void. Note that this is not possible i
From: Niklas Haas
---
libavutil/tests/color_utils.c | 110 ++
tests/ref/fate/color_utils| 2650 +
2 files changed, 2760 insertions(+)
diff --git a/libavutil/tests/color_utils.c b/libavutil/tests/color_utils.c
index 9881cd2489..27ba8b529e 100644
--- a/libavut
From: Niklas Haas
Rewrite this test slightly to fix the formatting, improve the readability of
the output, and eliminate some unnecessary branching.
---
libavutil/tests/color_utils.c | 34 +-
tests/ref/fate/color_utils| 608 +-
2 files changed, 322 insertions
From: Niklas Haas
Mathematical inverse of av_csp_trc_from_id(), plus testing to make sure it
roundtrips correctly with the corresponding TRC.
---
doc/APIchanges| 3 +
libavutil/csp.c | 155 -
libavutil/csp.h | 5 +
libavutil/tests/color_uti
From: Niklas Haas
This explanation was inaccurate and highly misleading. The new wording is taken
more or less directly from ITU-T H.273, and also matches my understanding of
these functions.
---
libavutil/csp.h | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavuti
Hi
On Fri, Nov 29, 2024 at 11:39:06PM -0300, James Almer wrote:
> On 11/29/2024 11:20 PM, Michael Niedermayer wrote:
> > This fix doesnt feel optimal, better fix is welcome
>
> Would you be ok with the C23 stdckdint.h compat header patch i sent two
> months ago being committed and used for this k
On 11/14/2024 1:37 AM, Scott Theisen wrote:
When attempting to upstream this MythTV change in September 2022, it was
recommended to
use AV_CHANNEL_ORDER_CUSTOM with two AV_CHAN_FRONT_CENTER channels. See
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20220921192611.3241-1-scott.the@gmail.
On Sat, Nov 30, 2024 at 9:50 AM Anton Khirnov wrote:
>
> Quoting Manuel Lauss (2024-11-28 21:58:09)
> > On Thu, Nov 28, 2024 at 3:19 PM Anton Khirnov wrote:
> > >
> > > Quoting Manuel Lauss (2024-11-26 15:25:30)
> > > > Hello,
> > > >
> > > > I'd like to add some audio support for the old libavfo
On 30/11/2024 06:46, Nuo Mi wrote:
> On Fri, Nov 29, 2024 at 6:19 AM Frank Plowman wrote:
>
>> Previously, the code only stored the MIP mode and transpose flag in the
>> relevant tables at the top-left corner of the CU. This information ends
>> up being retrieved in ff_vvc_intra_pred_* not based
On Wed, Nov 27, 2024 at 07:15:09PM -0600, Marth64 wrote:
> ffprobe cannot access the inner codec context when setting up
> the streams, so the values for these fields are always 0.
>
> Signed-off-by: Marth64
> ---
> fftools/ffprobe.c | 2 --
> 1 file changed, 2 deletions(-)
this needs update to
On Sat, 30 Nov 2024 at 03:22, James Almer wrote:
>
> On 11/1/2024 2:21 PM, Clément Péron wrote:
> > The Producer Reference time contains the source time when the frame
> > has been produced. This is usefull in the muxer so propagate it.
> >
> > Signed-off-by: Clément Péron
> > ---
> > libavcode
On Fri, 29 Nov 2024 at 23:44, Timo Rothenpieler wrote:
>
> On 29.11.2024 21:46, Clément Péron wrote:
> > On Fri, 29 Nov 2024 at 20:06, Timo Rothenpieler
> > wrote:
> >>
> >> On 01.11.2024 18:21, Clément Péron wrote:
> >>> From: Troy Benson
> >>>
> >>> Cuvid data packet have specific format that
Hi,
Thank you very much for the review. Responses inline.
On 30/11/2024 06:39, Nuo Mi wrote:
> Hi Frank,
> Thank you for the patch set; I will apply it except for this one
>
> On Fri, Nov 29, 2024 at 6:19 AM Frank Plowman wrote:
>
>> In 7.4.3.20 of H.266 (V3), there are two similarly-named va
From: Zhao Zhili
MSVC messed up standard C features, again.
---
libavutil/mem_internal.h | 4
1 file changed, 4 insertions(+)
diff --git a/libavutil/mem_internal.h b/libavutil/mem_internal.h
index 249ec3a642..2eb4aef5b0 100644
--- a/libavutil/mem_internal.h
+++ b/libavutil/mem_internal.h
@
Quoting Manuel Lauss (2024-11-28 21:58:09)
> On Thu, Nov 28, 2024 at 3:19 PM Anton Khirnov wrote:
> >
> > Quoting Manuel Lauss (2024-11-26 15:25:30)
> > > Hello,
> > >
> > > I'd like to add some audio support for the old libavformat/smush
> > > formats (mainly the "ANIM" variants; the "SANM" varia
57 matches
Mail list logo
