[FFmpeg-devel] [PATCH v2 17/39] lavc/ffv1: always use the main context values of ac
It cannot change between slices.
---
libavcodec/ffv1.c | 6 +++---
libavcodec/ffv1dec.c | 19 +--
libavcodec/ffv1dec_template.c | 14 --
libavcodec/ffv1enc.c | 11 ++-
libavcodec/ffv1enc_template.c | 12 +++-
5 files changed, 33 insertions(+), 29 deletions(-)
diff --git a/libavcodec/ffv1.c b/libavcodec/ffv1.c
index 06a77c3a26..581e775ae2 100644
--- a/libavcodec/ffv1.c
+++ b/libavcodec/ffv1.c
@@ -59,7 +59,7 @@ av_cold int ff_ffv1_init_slice_state(const FFV1Context *f,
FFV1Context *fs)
for (j = 0; j < f->plane_count; j++) {
PlaneContext *const p = &fs->plane[j];
-if (fs->ac != AC_GOLOMB_RICE) {
+if (f->ac != AC_GOLOMB_RICE) {
if (!p->state)
p->state = av_malloc_array(p->context_count, CONTEXT_SIZE *
sizeof(uint8_t));
@@ -78,7 +78,7 @@ av_cold int ff_ffv1_init_slice_state(const FFV1Context *f,
FFV1Context *fs)
}
}
-if (fs->ac == AC_RANGE_CUSTOM_TAB) {
+if (f->ac == AC_RANGE_CUSTOM_TAB) {
//FIXME only redo if state_transition changed
for (j = 1; j < 256; j++) {
fs->c. one_state[ j] = f->state_transition[j];
@@ -167,7 +167,7 @@ void ff_ffv1_clear_slice_state(const FFV1Context *f,
FFV1Context *fs)
for (i = 0; i < f->plane_count; i++) {
PlaneContext *p = &fs->plane[i];
-if (fs->ac != AC_GOLOMB_RICE) {
+if (f->ac != AC_GOLOMB_RICE) {
if (f->initial_states[p->quant_table_index]) {
memcpy(p->state, f->initial_states[p->quant_table_index],
CONTEXT_SIZE * p->context_count);
diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
index 8464697fd3..992b6596ab 100644
--- a/libavcodec/ffv1dec.c
+++ b/libavcodec/ffv1dec.c
@@ -94,10 +94,9 @@ static inline int get_vlc_symbol(GetBitContext *gb, VlcState
*const state,
return ret;
}
-static int is_input_end(FFV1Context *s, GetBitContext *gb)
+static int is_input_end(RangeCoder *c, GetBitContext *gb, int ac)
{
-if (s->ac != AC_GOLOMB_RICE) {
-RangeCoder *const c = &s->c;
+if (ac != AC_GOLOMB_RICE) {
if (c->overread > MAX_OVERREAD)
return AVERROR_INVALIDDATA;
} else {
@@ -123,6 +122,7 @@ static int decode_plane(FFV1Context *f,
uint8_t *src, int w, int h, int stride, int
plane_index,
int pixel_stride)
{
+const int ac = f->ac;
int x, y;
int16_t *sample[2];
sample[0] = sc->sample_buffer + 3;
@@ -142,13 +142,13 @@ static int decode_plane(FFV1Context *f,
sample[0][w] = sample[0][w - 1];
if (s->avctx->bits_per_raw_sample <= 8) {
-int ret = decode_line(f, s, sc, gb, w, sample, plane_index, 8);
+int ret = decode_line(f, s, sc, gb, w, sample, plane_index, 8, ac);
if (ret < 0)
return ret;
for (x = 0; x < w; x++)
src[x*pixel_stride + stride * y] = sample[1][x];
} else {
-int ret = decode_line(f, s, sc, gb, w, sample, plane_index,
s->avctx->bits_per_raw_sample);
+int ret = decode_line(f, s, sc, gb, w, sample, plane_index,
s->avctx->bits_per_raw_sample, ac);
if (ret < 0)
return ret;
if (s->packed_at_lsb) {
@@ -197,7 +197,7 @@ static int decode_slice_header(const FFV1Context *f,
FFV1Context *fs,
av_assert0 ( (unsigned)sc->slice_x + (uint64_t)sc->slice_width <=
f->width
&& (unsigned)sc->slice_y + (uint64_t)sc->slice_height <=
f->height);
-if (fs->ac == AC_GOLOMB_RICE && sc->slice_width >= (1<<23))
+if (f->ac == AC_GOLOMB_RICE && sc->slice_width >= (1<<23))
return AVERROR_INVALIDDATA;
for (unsigned i = 0; i < f->plane_count; i++) {
@@ -284,7 +284,7 @@ static int decode_slice(AVCodecContext *c, void *arg)
pdst->state = NULL;
pdst->vlc_state = NULL;
-if (fssrc->ac) {
+if (f->ac) {
pdst->state = av_malloc_array(CONTEXT_SIZE,
psrc->context_count);
memcpy(pdst->state, psrc->state, CONTEXT_SIZE *
psrc->context_count);
} else {
@@ -319,7 +319,7 @@ static int decode_slice(AVCodecContext *c, void *arg)
x = sc->slice_x;
y = sc->slice_y;
-if (fs->ac == AC_GOLOMB_RICE) {
+if (f->ac == AC_GOLOMB_RICE) {
if (f->version == 3 && f->micro_version > 1 || f->version > 3)
get_rac(&fs->c, (uint8_t[]) { 129 });
fs->ac_byte_count = f->version > 2 || (!x && !y) ? fs->c.bytestream -
fs->c.bytestream_start - 1 : 0;
@@ -358,7 +358,7 @@ static int decode_slice(AVCodecContext *c, void *arg)
p->data[3] + ps * x + y * p->linesize[3] };
decode_rgb_frame(f, fs, sc, &gb, planes, width, height, p->linesize);
}
-if (fs->ac != AC_GOLOMB_RICE && f
[FFmpeg-devel] [PATCH v2 22/39] lavc/ffv1enc: stop using per-slice FFV1Context
All remaining accesses to them are for fields that have the same value
in the main encoder context.
---
libavcodec/ffv1enc.c | 55 +--
libavcodec/ffv1enc_template.c | 29 +-
2 files changed, 41 insertions(+), 43 deletions(-)
diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
index b861210462..23d757e5c6 100644
--- a/libavcodec/ffv1enc.c
+++ b/libavcodec/ffv1enc.c
@@ -269,14 +269,14 @@ static inline void put_vlc_symbol(PutBitContext *pb,
VlcState *const state,
#define RENAME(name) name ## 32
#include "ffv1enc_template.c"
-static int encode_plane(FFV1Context *f,
-FFV1Context *s, FFV1SliceContext *sc,
+static int encode_plane(FFV1Context *f, FFV1SliceContext *sc,
const uint8_t *src, int w, int h,
int stride, int plane_index, int pixel_stride)
{
int x, y, i, ret;
const int ac = f->ac;
-const int ring_size = s->context_model ? 3 : 2;
+const int pass1 = !!(f->avctx->flags & AV_CODEC_FLAG_PASS1);
+const int ring_size = f->context_model ? 3 : 2;
int16_t *sample[3];
sc->run_index = 0;
@@ -288,22 +288,22 @@ static int encode_plane(FFV1Context *f,
sample[0][-1]= sample[1][0 ];
sample[1][ w]= sample[1][w-1];
-if (s->bits_per_raw_sample <= 8) {
+if (f->bits_per_raw_sample <= 8) {
for (x = 0; x < w; x++)
sample[0][x] = src[x * pixel_stride + stride * y];
-if((ret = encode_line(f, s, sc, w, sample, plane_index, 8, ac)) <
0)
+if((ret = encode_line(f, sc, f->avctx, w, sample, plane_index, 8,
ac, pass1)) < 0)
return ret;
} else {
-if (s->packed_at_lsb) {
+if (f->packed_at_lsb) {
for (x = 0; x < w; x++) {
sample[0][x] = ((uint16_t*)(src + stride*y))[x];
}
} else {
for (x = 0; x < w; x++) {
-sample[0][x] = ((uint16_t*)(src + stride*y))[x] >> (16 -
s->bits_per_raw_sample);
+sample[0][x] = ((uint16_t*)(src + stride*y))[x] >> (16 -
f->bits_per_raw_sample);
}
}
-if((ret = encode_line(f, s, sc, w, sample, plane_index,
s->bits_per_raw_sample, ac)) < 0)
+if((ret = encode_line(f, sc, f->avctx, w, sample, plane_index,
f->bits_per_raw_sample, ac, pass1)) < 0)
return ret;
}
}
@@ -909,8 +909,7 @@ slices_ok:
return 0;
}
-static void encode_slice_header(FFV1Context *f, FFV1Context *fs,
-FFV1SliceContext *sc)
+static void encode_slice_header(FFV1Context *f, FFV1SliceContext *sc)
{
RangeCoder *c = &sc->c;
uint8_t state[CONTEXT_SIZE];
@@ -943,7 +942,7 @@ static void encode_slice_header(FFV1Context *f, FFV1Context
*fs,
}
}
-static void choose_rct_params(FFV1Context *fs, FFV1SliceContext *sc,
+static void choose_rct_params(const FFV1Context *f, FFV1SliceContext *sc,
const uint8_t *src[3], const int stride[3], int
w, int h)
{
#define NB_Y_COEFF 15
@@ -969,7 +968,7 @@ static void choose_rct_params(FFV1Context *fs,
FFV1SliceContext *sc,
int stat[NB_Y_COEFF] = {0};
int x, y, i, p, best;
int16_t *sample[3];
-int lbd = fs->bits_per_raw_sample <= 8;
+int lbd = f->bits_per_raw_sample <= 8;
for (y = 0; y < h; y++) {
int lastr=0, lastg=0, lastb=0;
@@ -1028,10 +1027,8 @@ static void choose_rct_params(FFV1Context *fs,
FFV1SliceContext *sc,
static int encode_slice(AVCodecContext *c, void *arg)
{
-FFV1Context *fs = *(void **)arg;
-FFV1Context *f = fs->avctx->priv_data;
-const int si = (FFV1Context**)arg - f->slice_context;
-FFV1SliceContext *sc = &f->slices[si];
+FFV1SliceContext *sc = arg;
+FFV1Context *f = c->priv_data;
int width= sc->slice_width;
int height = sc->slice_height;
int x= sc->slice_x;
@@ -1047,7 +1044,7 @@ static int encode_slice(AVCodecContext *c, void *arg)
sc->slice_coding_mode = 0;
if (f->version > 3) {
-choose_rct_params(fs, sc, planes, p->linesize, width, height);
+choose_rct_params(f, sc, planes, p->linesize, width, height);
} else {
sc->slice_rct_by_coef = 1;
sc->slice_rct_ry_coef = 1;
@@ -1057,7 +1054,7 @@ retry:
if (f->key_frame)
ff_ffv1_clear_slice_state(f, sc);
if (f->version > 2) {
-encode_slice_header(f, fs, sc);
+encode_slice_header(f, sc);
}
if (f->ac == AC_GOLOMB_RICE) {
sc->ac_byte_count = f->version > 2 || (!x && !y) ?
ff_rac_terminate(&sc->c, f->version > 2) : 0;
@@ -1072,26 +1069,26 @@ retry:
const int cx= x >> f->chroma_h_shift;
const int cy= y >> f->chroma_v_shift;
-ret = encode_plane(f, fs, sc, p->data[0] + ps*x + y*p->linesize[0
Re: [FFmpeg-devel] [PATCH 0/2] Interpret a degenerate SAR as 1/1.
Hi, Il 30/07/24 22:54, michael at niedermayer.cc (Michael Niedermayer) ha scritto: Why does playback fail ? > 1/1 and unspecified are different things, 0/0 would be unspecified where does 20480/0 turn into 20480/1 ? or did i misunderstand this? It seems that denominator 0 is replaced with 1 here: https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/262168b04e6807fce6a78507c14cfc166ba72845:/libavcodec/h264_ps.c#l552 Considering the other replies I would guess that the intent is to prevent a division by zero from happening, but the side effect is that an invalid SAR is silently converted to a valid one (even if quite extreme). I am not sure why that in turn causes the playback problems. I noticed that the same problem can be reproduced on any other H.264 file simply by forcing the broken 20480/0 SAR in ff_h2645_decode_common_vui_params(). After a few more experiments, it seems that ffmpeg is indeed able to handle an unspecified SAR, but it doesn't like it to be represented as x/0, only 0/x. I'll send a revised patch which replaces x/0 with 1/0, hopefully addressing your concern. Thanks, Giovanni. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] avcodec/h2645_vui: Interpret a degenerate SAR as unspecified.
The specification says that if either the numerator or the
denominator is zero then the SAR is to be intended unspecified.
Internally ffmpeg represents an unspecified SAR as 0/1, while
fractions with a zero denominator are not handled properly;
so we bridge the gap by replacing x/0 with 0/1.
Signed-off-by: Giovanni Mascellani
---
libavcodec/h2645_vui.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/h2645_vui.c b/libavcodec/h2645_vui.c
index e5c7bf46f9..c8df733399 100644
--- a/libavcodec/h2645_vui.c
+++ b/libavcodec/h2645_vui.c
@@ -46,6 +46,8 @@ void ff_h2645_decode_common_vui_params(GetBitContext *gb,
H2645VUI *vui, void *l
else if (vui->aspect_ratio_idc == EXTENDED_SAR) {
vui->sar.num = get_bits(gb, 16);
vui->sar.den = get_bits(gb, 16);
+if (vui->sar.den == 0)
+vui->sar = (AVRational){ 0, 1 };
} else
av_log(logctx, AV_LOG_WARNING,
"Unknown SAR index: %u.\n", vui->aspect_ratio_idc);
--
2.45.2
___
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 v4 3/4] lavc/vp9dsp: R-V V mc tap h v
I'm a bit confused because the calculation here goes up to 32 bits and then returns to 8 bits. It seems that the vmax and vnclipu instructions can't be removed by using round-related instructions？ Rémi Denis-Courmont 于2024年7月29日周一 23:21写道： > Le tiistaina 23. heinäkuuta 2024, 11.51.48 EEST u...@foxmail.com a écrit : > > From: sunyuechi > > > > C908 X60 > > vp9_avg_8tap_smooth_4h_8bpp_c : 12.7 11.2 > > vp9_avg_8tap_smooth_4h_8bpp_rvv_i32:4.74.2 > > vp9_avg_8tap_smooth_4v_8bpp_c : 29.7 12.5 > > vp9_avg_8tap_smooth_4v_8bpp_rvv_i32:4.74.2 > > vp9_avg_8tap_smooth_8h_8bpp_c : 48.7 42.2 > > vp9_avg_8tap_smooth_8h_8bpp_rvv_i32:9.58.5 > > vp9_avg_8tap_smooth_8v_8bpp_c : 49.7 45.5 > > vp9_avg_8tap_smooth_8v_8bpp_rvv_i32:9.58.5 > > vp9_avg_8tap_smooth_16h_8bpp_c : 192.0 166.5 > > vp9_avg_8tap_smooth_16h_8bpp_rvv_i32 : 21.7 19.5 > > vp9_avg_8tap_smooth_16v_8bpp_c : 191.2 175.2 > > vp9_avg_8tap_smooth_16v_8bpp_rvv_i32 : 21.2 19.0 > > vp9_avg_8tap_smooth_32h_8bpp_c : 780.2 663.2 > > vp9_avg_8tap_smooth_32h_8bpp_rvv_i32 : 68.2 60.5 > > vp9_avg_8tap_smooth_32v_8bpp_c : 770.0 685.7 > > vp9_avg_8tap_smooth_32v_8bpp_rvv_i32 : 67.0 59.5 > > vp9_avg_8tap_smooth_64h_8bpp_c : 3116.2 2648.2 > > vp9_avg_8tap_smooth_64h_8bpp_rvv_i32 : 270.7 120.7 > > vp9_avg_8tap_smooth_64v_8bpp_c : 3058.5 2731.7 > > vp9_avg_8tap_smooth_64v_8bpp_rvv_i32 : 266.5 119.0 > > vp9_put_8tap_smooth_4h_8bpp_c : 11.09.7 > > vp9_put_8tap_smooth_4h_8bpp_rvv_i32:4.23.7 > > vp9_put_8tap_smooth_4v_8bpp_c : 11.7 10.5 > > vp9_put_8tap_smooth_4v_8bpp_rvv_i32:4.03.7 > > vp9_put_8tap_smooth_8h_8bpp_c : 42.0 37.5 > > vp9_put_8tap_smooth_8h_8bpp_rvv_i32:8.57.7 > > vp9_put_8tap_smooth_8v_8bpp_c : 43.5 38.5 > > vp9_put_8tap_smooth_8v_8bpp_rvv_i32:8.77.7 > > vp9_put_8tap_smooth_16h_8bpp_c : 181.7 147.2 > > vp9_put_8tap_smooth_16h_8bpp_rvv_i32 : 20.0 18.0 > > vp9_put_8tap_smooth_16v_8bpp_c : 168.5 149.7 > > vp9_put_8tap_smooth_16v_8bpp_rvv_i32 : 19.7 17.5 > > vp9_put_8tap_smooth_32h_8bpp_c : 675.0 586.5 > > vp9_put_8tap_smooth_32h_8bpp_rvv_i32 : 65.2 58.0 > > vp9_put_8tap_smooth_32v_8bpp_c : 664.7 591.2 > > vp9_put_8tap_smooth_32v_8bpp_rvv_i32 : 64.0 57.0 > > vp9_put_8tap_smooth_64h_8bpp_c : 2696.2 2339.0 > > vp9_put_8tap_smooth_64h_8bpp_rvv_i32 : 259.7 115.7 > > vp9_put_8tap_smooth_64v_8bpp_c : 2691.0 2348.5 > > vp9_put_8tap_smooth_64v_8bpp_rvv_i32 : 255.5 114.0 > > --- > > libavcodec/riscv/vp9_mc_rvv.S | 193 + > > libavcodec/riscv/vp9dsp.h | 72 > > libavcodec/riscv/vp9dsp_init.c | 38 ++- > > 3 files changed, 278 insertions(+), 25 deletions(-) > > > > diff --git a/libavcodec/riscv/vp9_mc_rvv.S > b/libavcodec/riscv/vp9_mc_rvv.S > > index 5241562531..6a4be7b9bd 100644 > > --- a/libavcodec/riscv/vp9_mc_rvv.S > > +++ b/libavcodec/riscv/vp9_mc_rvv.S > > @@ -36,6 +36,18 @@ > > .endif > > .endm > > > > +.macro vsetvlstatic16 len > > +.ifc \len,4 > > +vsetvli zero, zero, e16, mf2, ta, ma > > +.elseif \len == 8 > > +vsetvli zero, zero, e16, m1, ta, ma > > +.elseif \len == 16 > > +vsetvli zero, zero, e16, m2, ta, ma > > +.else > > +vsetvli zero, zero, e16, m4, ta, ma > > +.endif > > +.endm > > + > > .macro copy_avg len > > func ff_vp9_avg\len\()_rvv, zve32x > > csrwi vxrm, 0 > > @@ -181,8 +193,189 @@ func ff_\op\()_vp9_bilin_64hv_rvv, zve32x > > endfunc > > .endm > > > > +.equ ff_vp9_subpel_filters_smooth, ff_vp9_subpel_filters > > +.equ ff_vp9_subpel_filters_regular, ff_vp9_subpel_filters + 16*8*2 > > +.equ ff_vp9_subpel_filters_sharp, ff_vp9_subpel_filters + 16*8*2*2 > > + > > +.macro epel_filter name, type, regtype, arg > > +lla \regtype\()2, ff_vp9_subpel_filters_\name > > +.ifc \type,v > > +slli\regtype\()0, a6, 4 > > +.else > > +slli\regtype\()0, a5, 4 > > +.endif > > +add \regtype\()0, \regtype\()0, \regtype\()2 > > +lh \regtype\()1, 2(\regtype\()0) > > +lh \regtype\()2, 4(\regtype\()0) > > +lh
Re: [FFmpeg-devel] [PATCH 1/4] swscale/yuv2rgb: prepare YUV2RGBFUNC macro for multi-planar rgb
On Tue, Jul 30, 2024 at 03:05:22PM +0200, Ramiro Polla wrote:
> On Tue, Jul 23, 2024 at 2:46 PM Ramiro Polla wrote:
> > This will be used in the upcoming yuv42{0,2}p -> gbrp unscaled
> > colorspace converters.
>
> ping on this patchset.
Maybe you can add benchmarks to things changing performance
and, also put a note in commit messages for changes which
change the output
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"
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 33/39] lavc: convert frame threading to the receive_frame() pattern
Quoting Michael Niedermayer (2024-07-24 20:44:50) > On Tue, Jul 16, 2024 at 07:11:48PM +0200, Anton Khirnov wrote: > > Reorganize the code such that the frame threading code does not call the > > decoders directly, but instead calls back into the generic decoding > > code. This avoids duplicating the logic that wraps the decoder > > invocation and allows receive_frame()-based decoders to use frame > > threading. > > > > Further work by Timo Rothenpieler . > > --- > > libavcodec/avcodec.c | 9 +- > > libavcodec/avcodec_internal.h | 25 +-- > > libavcodec/decode.c | 40 +++-- > > libavcodec/internal.h | 7 + > > libavcodec/pthread_frame.c| 278 +- > > 5 files changed, 235 insertions(+), 124 deletions(-) > > this (frm your recive_frame branch) breaks: Then I will need to reintroduce some form of patch 28 - ideally its second iteration split into 3 patches, as then the ownership semantics of slice_damaged is much simpler. -- Anton Khirnov ___ 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] Check codec_whitelist before reinitializing AVCtx.priv_data.
Quoting Dale Curtis (2024-07-31 01:14:13)
> I realized there are a couple more allocations that can be skipped here
> when a codec is not on the allow list. Here's the updated patch.
>
> - dale
>
> On Mon, Jul 29, 2024 at 10:19 AM Dale Curtis
> wrote:
>
> > This ensures that if a codec isn't on codec_whitelist, its VUI
> > information can still be populated during find_stream_info()
> > via parsers.
> >
> > Signed-off-by: Dale Curtis
> > ---
> > libavcodec/avcodec.c | 12 ++--
> > 1 file changed, 6 insertions(+), 6 deletions(-)
> >
> >
>
> From f87042d77d13c4c45f4b800146dc16347c1007d4 Mon Sep 17 00:00:00 2001
> From: Dale Curtis
> Date: Tue, 30 Jul 2024 23:12:21 +
> Subject: [PATCH] Check codec_whitelist before reinitializing AVCtx.priv_data.
>
> This ensures that if a codec isn't on codec_whitelist, its VUI
> information can still be populated during find_stream_info()
> via parsers.
Can you elaborate on this?
>
> Signed-off-by: Dale Curtis
> ---
> libavcodec/avcodec.c | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/avcodec.c b/libavcodec/avcodec.c
> index 214dca4566..1f9b3eb360 100644
> --- a/libavcodec/avcodec.c
> +++ b/libavcodec/avcodec.c
> @@ -174,6 +174,11 @@ int attribute_align_arg avcodec_open2(AVCodecContext
> *avctx, const AVCodec *code
> if (avctx->extradata_size < 0 || avctx->extradata_size >=
> FF_MAX_EXTRADATA_SIZE)
> return AVERROR(EINVAL);
>
> +if (avctx->codec_whitelist && av_match_list(codec->name,
> avctx->codec_whitelist, ',') <= 0) {
> +av_log(avctx, AV_LOG_ERROR, "Codec (%s) not on whitelist \'%s\'\n",
> codec->name, avctx->codec_whitelist);
> +return AVERROR(EINVAL);
> +}
I think this will break the case where the whitelist is provided in the
options dictionary, as it's not applied yet at this point.
--
Anton Khirnov
___
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 01/22] avutil/dovi_meta: document static vs dynamic ext blocks
On Sun, 28 Jul 2024 12:25:06 +0200 Niklas Haas wrote:
> From: Niklas Haas
>
> ---
> libavutil/dovi_meta.h | 28 +++-
> 1 file changed, 15 insertions(+), 13 deletions(-)
>
> diff --git a/libavutil/dovi_meta.h b/libavutil/dovi_meta.h
> index c942d0e133..5e8a1e43d7 100644
> --- a/libavutil/dovi_meta.h
> +++ b/libavutil/dovi_meta.h
> @@ -301,26 +301,28 @@ typedef struct AVDOVIDmLevel255 {
> } AVDOVIDmLevel255;
>
> /**
> - * Dolby Vision metadata extension block.
> + * Dolby Vision metadata extension block. Dynamic extension blocks may change
> + * from frame to frame, while static blocks are constant throughout the
> entire
> + * sequence.
> *
> * @note sizeof(AVDOVIDmData) is not part of the public API.
> */
> typedef struct AVDOVIDmData {
> uint8_t level; /* [1, 255] */
> union {
> -AVDOVIDmLevel1 l1;
> -AVDOVIDmLevel2 l2; /* may appear multiple times */
> -AVDOVIDmLevel3 l3;
> -AVDOVIDmLevel4 l4;
> -AVDOVIDmLevel5 l5;
> -AVDOVIDmLevel6 l6;
> +AVDOVIDmLevel1 l1; /* dynamic */
> +AVDOVIDmLevel2 l2; /* dynamic, may appear multiple times */
> +AVDOVIDmLevel3 l3; /* dynamic */
> +AVDOVIDmLevel4 l4; /* dynamic */
> +AVDOVIDmLevel5 l5; /* dynamic */
> +AVDOVIDmLevel6 l6; /* static */
> /* level 7 is currently unused */
> -AVDOVIDmLevel8 l8; /* may appear multiple times */
> -AVDOVIDmLevel9 l9;
> -AVDOVIDmLevel10 l10; /* may appear multiple times */
> -AVDOVIDmLevel11 l11;
> -AVDOVIDmLevel254 l254;
> -AVDOVIDmLevel255 l255;
> +AVDOVIDmLevel8 l8; /* dynamic, may appear multiple times */
> +AVDOVIDmLevel9 l9; /* dynamic */
> +AVDOVIDmLevel10 l10; /* static, may appear multiple times */
> +AVDOVIDmLevel11 l11; /* dynamic */
> +AVDOVIDmLevel254 l254; /* static */
> +AVDOVIDmLevel255 l255; /* static */
> };
> } AVDOVIDmData;
>
> --
> 2.45.2
>
Ping for review. Code passes DV bitstream validator, so will consider merging
soon if there are no objections.
___
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 17/39] lavc/ffv1: always use the main context values of ac
On Wed, Jul 31, 2024 at 10:33:09AM +0200, Anton Khirnov wrote: > It cannot change between slices. > --- > libavcodec/ffv1.c | 6 +++--- > libavcodec/ffv1dec.c | 19 +-- > libavcodec/ffv1dec_template.c | 14 -- > libavcodec/ffv1enc.c | 11 ++- > libavcodec/ffv1enc_template.c | 12 +++- > 5 files changed, 33 insertions(+), 29 deletions(-) probably ok assuming benchmarks favor this thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB While the State exists there can be no freedom; when there is freedom there will be no State. -- Vladimir Lenin signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 22/39] lavc/ffv1enc: stop using per-slice FFV1Context
On Wed, Jul 31, 2024 at 10:50:11AM +0200, Anton Khirnov wrote: > All remaining accesses to them are for fields that have the same value > in the main encoder context. > --- > libavcodec/ffv1enc.c | 55 +-- > libavcodec/ffv1enc_template.c | 29 +- > 2 files changed, 41 insertions(+), 43 deletions(-) fine if benchmarks dont disfavour this [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Some people wanted to paint the bikeshed green, some blue and some pink. People argued and fought, when they finally agreed, only rust was left. 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] avutil/frame: use the maximum compile time supported alignment for strides
This puts lavu frame buffer allocator helpers in sync with lavc's decoder frame
buffer allocator's STRIDE_ALIGN define.
Remove the comment about av_cpu_max_align() while at it as using it is not
ideal when CPU flags can be changed mid process.
Should fix ticket #6.
Signed-off-by: James Almer
---
libavutil/frame.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavutil/frame.c b/libavutil/frame.c
index 673a9afb3b..5cbfc6a48b 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -166,6 +166,8 @@ void av_frame_free(AVFrame **frame)
av_freep(frame);
}
+#define ALIGN (HAVE_SIMD_ALIGN_64 ? 64 : 32)
+
static int get_video_buffer(AVFrame *frame, int align)
{
const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(frame->format);
@@ -182,7 +184,7 @@ static int get_video_buffer(AVFrame *frame, int align)
if (!frame->linesize[0]) {
if (align <= 0)
-align = 32; /* STRIDE_ALIGN. Should be av_cpu_max_align() */
+align = ALIGN;
for (int i = 1; i <= align; i += i) {
ret = av_image_fill_linesizes(frame->linesize, frame->format,
--
2.45.2
___
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 33/39] lavc: convert frame threading to the receive_frame() pattern
On Wed, Jul 31, 2024 at 01:26:23PM +0200, Anton Khirnov wrote: > Quoting Michael Niedermayer (2024-07-24 20:44:50) > > On Tue, Jul 16, 2024 at 07:11:48PM +0200, Anton Khirnov wrote: > > > Reorganize the code such that the frame threading code does not call the > > > decoders directly, but instead calls back into the generic decoding > > > code. This avoids duplicating the logic that wraps the decoder > > > invocation and allows receive_frame()-based decoders to use frame > > > threading. > > > > > > Further work by Timo Rothenpieler . > > > --- > > > libavcodec/avcodec.c | 9 +- > > > libavcodec/avcodec_internal.h | 25 +-- > > > libavcodec/decode.c | 40 +++-- > > > libavcodec/internal.h | 7 + > > > libavcodec/pthread_frame.c| 278 +- > > > 5 files changed, 235 insertions(+), 124 deletions(-) > > > > this (frm your recive_frame branch) breaks: > > Then I will need to reintroduce some form of patch 28 - ideally its > second iteration split into 3 patches, as then the ownership semantics > of slice_damaged is much simpler. simple is good race is bad Some more advanced EC code would be cool, if such a path would stay possible I mean something that could maybe do a 2nd pass and fill in damaged slices using both past and future non-damaged slices (i mean not just for ffv1 but all codecs) so the codec itself would do simply EC itself not depending on much surrounding state. Bit it then could export side data about what areas are damaged and have something in a 2nd pass go over these areas and fill them in with more advanaced stuff thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Any man who breaks a law that conscience tells him is unjust and willingly accepts the penalty by staying in jail in order to arouse the conscience of the community on the injustice of the law is at that moment expressing the very highest respect for law. - Martin Luther King Jr 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] avutil/hwcontext_vaapi: use the correct type for VASurfaceAttribExternalBuffers.buffers
Should fix ticket #5.
Signed-off-by: James Almer
---
Untested.
libavutil/hwcontext_vaapi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 4cb25dd032..15fd84aa40 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -1225,7 +1225,7 @@ static int vaapi_map_from_drm(AVHWFramesContext *src_fc,
AVFrame *dst,
if (!use_prime2 || vas != VA_STATUS_SUCCESS) {
int k;
-unsigned long buffer_handle;
+uintptr_t buffer_handle;
VASurfaceAttribExternalBuffers buffer_desc;
VASurfaceAttrib buffer_attrs[2] = {
{
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] lavc/vp8dsp: R-V V 256 bilin,epel
Le tiistaina 30. heinäkuuta 2024, 20.57.28 EEST flow gg a écrit : > From my understanding, moving from supporting only 128b to adding 256b > versions can simultaneously improve LMUL and solve some issues related to > insufficient vector registers (vvc, vp9). To the contrary, if vectors are too short to process a macroblock in a single round, then there should be a loop with maximum LMUL, and the code should be the same for all vector length. That is just normal textbook RVV coding style. There should *not* be vector length specialisation since the code can be shared. > If we continue to support 512, 1024, ..., it almost exclusively improves > LMUL. I don't think so. Even more so than 256-bit hardware, 512-bit and 1024-bit hardware really _needs_ to short-circuit vector processing based on VL and not simply follow LMUL. > Therefore, 256b is the most worthwhile addition, and we can skip > adding 512b, 1024b, etc. > > Additionally, even though longer hardware will continually be developed, > the most used will probably still be 128b and 256b. I wouldn't be so sure. Realistically, lower-end SoCs decode video with DSPs. So video decoder vector optimisations are mainly for the server side, and that's exactly where larger vector sizes are most likely (e.g. AVX-512). > If someone complains that FFmpeg's RVV doesn't support 1024b well, it can > be said that it's not just RISC-V that lacks good support. > However, if the 256b performance is not good, then it seems like an issue > with RISC-V. :) > > I think maybe we can give some preference to the two smallest lengths? As I wrote, I am not necessarily against specialising for 256-bit as such. I am against: 1) specialising functions that do not really need to be specialised, 2) adding tons of boilerplate (notably in the C code) for it. -- 雷米‧德尼-库尔蒙 http://www.remlab.net/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/aacps_tablegen_template: don't redefine CONFIG_HARDCODED_TABLES
Fixes relevant warnings when compiling with --enable-hardcoded-tables Signed-off-by: James Almer --- libavcodec/aacps_tablegen_template.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavcodec/aacps_tablegen_template.c b/libavcodec/aacps_tablegen_template.c index e70edf884b..e05887b9b1 100644 --- a/libavcodec/aacps_tablegen_template.c +++ b/libavcodec/aacps_tablegen_template.c @@ -22,6 +22,8 @@ #include #define BUILD_TABLES +#include "config.h" +#undef CONFIG_HARDCODED_TABLES #define CONFIG_HARDCODED_TABLES 0 #include "aac_defines.h" -- 2.45.2 ___ 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] lavu/riscv: fix return type
---
libavutil/riscv/intmath.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavutil/riscv/intmath.h b/libavutil/riscv/intmath.h
index 24f165eef1..a09248f903 100644
--- a/libavutil/riscv/intmath.h
+++ b/libavutil/riscv/intmath.h
@@ -84,8 +84,8 @@ static av_always_inline av_const float av_clipf_rvf(float a,
float min,
#if defined (__riscv_d) || defined (__riscv_zdinx)
#define av_clipd av_clipd_rvd
-static av_always_inline av_const float av_clipd_rvd(double a, double min,
-double max)
+static av_always_inline av_const double av_clipd_rvd(double a, double min,
+ double max)
{
return fmin(fmax(a, min), max);
}
--
2.45.2
___
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 1/1] lavfi/vf_gopromax_opencl: add GoPor Max 360 video filter
On 2024/07/31 5:44, Michael Niedermayer wrote: On Mon, Jul 29, 2024 at 01:30:34AM +0900, TADANO Tokumei wrote: On 2024/07/28 18:26, Michael Niedermayer wrote: On Sun, Jul 28, 2024 at 01:42:09AM +0900, TADANO Tokumei wrote: On 2024/07/27 13:30, TADANO Tokumei wrote: Add an OpenCL filter for filtering GoPro Max native .360 files into standard equirectangular or youtube equiangular cubemap (eac) projection. The .360 file contains separated two video streams. This filter combine two streams into single stream with standard format. --- doc/filters.texi | 78 +++ libavfilter/Makefile | 2 + libavfilter/allfilters.c | 1 + libavfilter/opencl/gopromax.cl | 280 libavfilter/opencl_source.h | 1 + libavfilter/vf_gopromax_opencl.c | 351 +++ 6 files changed, 713 insertions(+) create mode 100644 libavfilter/opencl/gopromax.cl create mode 100644 libavfilter/vf_gopromax_opencl.c The patchwork failed, but it was caused by opencl.c (not by this patch): In file included from ./libavutil/common.h:48:0, from ./libavutil/avutil.h:301, from ./libavutil/opt.h:31, from libavdevice/sdl2.c:31: ./config.h:335:0: warning: 'HAVE_PTHREAD_SETNAME_NP' redefined #define HAVE_PTHREAD_SETNAME_NP 0 In file included from /usr/include/SDL2/SDL_stdinc.h:31:0, from /usr/include/SDL2/SDL_main.h:25, from /usr/include/SDL2/SDL.h:32, from libavdevice/sdl2.c:26: /usr/include/SDL2/SDL_config.h:186:0: note: this is the location of the previous definition #define HAVE_PTHREAD_SETNAME_NP 1 In file included from libavfilter/opencl.h:31:0, from libavfilter/opencl.c:26: ./libavutil/hwcontext_opencl.h:25:10: fatal error: CL/cl.h: No such file or directory #include ^ compilation terminated. make: *** [libavfilter/opencl.o] Error 1 with this patch it fails here on ubuntu: /usr/bin/ld: libavfilter/libavfilter.a(opencl.o): undefined reference to symbol 'clBuildProgram@@OPENCL_1.0' /usr/bin/ld: /usr/local/cuda/targets/x86_64-linux/lib/libOpenCL.so.1: error adding symbols: DSO missing from command line thx I tested on Ubuntu 22.04, and it works fine. My failure was on a 20.04 thx Did you try v3 patch? Anyway, your OpenCL library seems to be Nvidia's proprietary one. I'm not sure, but I guess the library has some incompatibility like: https://github.com/OpenKinect/libfreenect2/issues/804#issuecomment-286515571 [...] ___ 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 1/4] lavc/vp8dsp: R-V V 256 bilin,epel
Thank you for the detailed explanation. One more question: I understand that assembly code needs to be further broken down, but what's the issue with adding this code to the init section of the C code here? I think this C code is just mimicking the init section of the C code in x86. Rémi Denis-Courmont 于2024年7月31日周三 23:06写道： > Le tiistaina 30. heinäkuuta 2024, 20.57.28 EEST flow gg a écrit : > > From my understanding, moving from supporting only 128b to adding 256b > > versions can simultaneously improve LMUL and solve some issues related to > > insufficient vector registers (vvc, vp9). > > To the contrary, if vectors are too short to process a macroblock in a > single > round, then there should be a loop with maximum LMUL, and the code should > be > the same for all vector length. That is just normal textbook RVV coding > style. > There should *not* be vector length specialisation since the code can be > shared. > > > If we continue to support 512, 1024, ..., it almost exclusively improves > > LMUL. > > I don't think so. Even more so than 256-bit hardware, 512-bit and 1024-bit > hardware really _needs_ to short-circuit vector processing based on VL and > not > simply follow LMUL. > > > Therefore, 256b is the most worthwhile addition, and we can skip > > adding 512b, 1024b, etc. > > > > Additionally, even though longer hardware will continually be developed, > > the most used will probably still be 128b and 256b. > > I wouldn't be so sure. Realistically, lower-end SoCs decode video with > DSPs. > So video decoder vector optimisations are mainly for the server side, and > that's exactly where larger vector sizes are most likely (e.g. AVX-512). > > > If someone complains that FFmpeg's RVV doesn't support 1024b well, it can > > be said that it's not just RISC-V that lacks good support. > > However, if the 256b performance is not good, then it seems like an issue > > with RISC-V. :) > > > > I think maybe we can give some preference to the two smallest lengths? > > As I wrote, I am not necessarily against specialising for 256-bit as such. > I > am against: > 1) specialising functions that do not really need to be specialised, > 2) adding tons of boilerplate (notably in the C code) for it. > > -- > 雷米‧德尼-库尔蒙 > http://www.remlab.net/ > > > > ___ > 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] lavc/h264dsp: R-V V idct4_add8 (all depth)
This is really just a wrapper for idct4_add16intra, which is in turm mostly
a wrapper for idct4_add and idct4_dc_add.
For benchmarks refer to the later two.
---
libavcodec/riscv/h264dsp_init.c | 14 ++--
libavcodec/riscv/h264idct_rvv.S | 59 +
2 files changed, 63 insertions(+), 10 deletions(-)
diff --git a/libavcodec/riscv/h264dsp_init.c b/libavcodec/riscv/h264dsp_init.c
index e892c335a6..6b81587003 100644
--- a/libavcodec/riscv/h264dsp_init.c
+++ b/libavcodec/riscv/h264dsp_init.c
@@ -53,6 +53,9 @@ void ff_h264_idct_add16intra_##depth##_rvv(uint8_t *d, const
int *soffset, \
int16_t *s, int stride, \
const uint8_t nnzc[5 * 8]); \
void ff_h264_idct8_add4_##depth##_rvv(uint8_t *d, const int *soffset, \
+ int16_t *s, int stride, \
+ const uint8_t nnzc[5 * 8]); \
+void ff_h264_idct4_add8_##depth##_rvv(uint8_t **d, const int *soffset, \
int16_t *s, int stride, \
const uint8_t nnzc[5 * 8]);
@@ -104,6 +107,8 @@ av_cold void ff_h264dsp_init_riscv(H264DSPContext *dsp,
const int bit_depth,
dsp->h264_idct_add16intra = ff_h264_idct_add16intra_8_rvv;
# if __riscv_xlen == 64
dsp->h264_idct8_add4 = ff_h264_idct8_add4_8_rvv;
+if (chroma_format_idc <= 1)
+dsp->h264_idct_add8 = ff_h264_idct4_add8_8_rvv;
# endif
}
if (flags & AV_CPU_FLAG_RVV_I64) {
@@ -123,10 +128,13 @@ av_cold void ff_h264dsp_init_riscv(H264DSPContext *dsp,
const int bit_depth,
if (zvl128b && (flags & AV_CPU_FLAG_RVB)) { \
dsp->h264_idct_dc_add = ff_h264_idct4_dc_add_##depth##_rvv; \
dsp->h264_idct8_dc_add = ff_h264_idct8_dc_add_##depth##_rvv; \
+dsp->h264_idct_add16 = ff_h264_idct_add16_##depth##_rvv; \
+dsp->h264_idct_add16intra = \
+ff_h264_idct_add16intra_##depth##_rvv; \
if (__riscv_xlen == 64) { \
-dsp->h264_idct_add16 = ff_h264_idct_add16_##depth##_rvv; \
-dsp->h264_idct_add16intra = \
-ff_h264_idct_add16intra_##depth##_rvv; \
+if (chroma_format_idc <= 1) \
+dsp->h264_idct_add8 = \
+ff_h264_idct4_add8_##depth##_rvv; \
} \
} \
if (__riscv_xlen == 64 && (flags & AV_CPU_FLAG_RVB)) \
diff --git a/libavcodec/riscv/h264idct_rvv.S b/libavcodec/riscv/h264idct_rvv.S
index f823346c8d..70b7cfac4d 100644
--- a/libavcodec/riscv/h264idct_rvv.S
+++ b/libavcodec/riscv/h264idct_rvv.S
@@ -57,7 +57,7 @@ endfunc
func ff_h264_idct_add_8_rvv, zve32x
lpad0
csrwi vxrm, 0
-.Lidct_add4_8_rvv:
+.Lidct4_add_8_rvv:
vsetivlizero, 4, e16, mf2, ta, ma
addit1, a1, 1 * 4 * 2
vle16.v v0, (a1)
@@ -111,7 +111,7 @@ endfunc
func ff_h264_idct_add_16_rvv, zve32x
csrwi vxrm, 0
-.Lidct_add4_16_rvv:
+.Lidct4_add_16_rvv:
vsetivlizero, 4, e32, m1, ta, ma
addit1, a1, 1 * 4 * 4
vle32.v v0, (a1)
@@ -543,8 +543,12 @@ endfunc
.endr
const ff_h264_scan8
-.byte 014, 015, 024, 025, 016, 017, 026, 027
-.byte 034, 035, 044, 045, 036, 037, 046, 047
+.byte014, 015, 024, 025, 016, 017, 026, 027
+.byte034, 035, 044, 045, 036, 037, 046, 047
+.byte064, 065, 074, 075, 066, 067, 076, 077
+.byte 0104, 0105, 0114, 0115, 0106, 0107, 0116, 0117
+.byte 0134, 0135, 0144, 0145, 0136, 0137, 0146, 0147
+.byte 0154, 0155, 0164, 0165, 0156, 0157, 0166, 0167
endconst
.macro idct4_adds type, depth
@@ -554,8 +558,11 @@ func ff_h264_idct_add\type\()_\depth\()_rvv, zve32x, b
.endif
csrwi vxrm, 0
lla t0, ff_h264_scan8
-li t1, 32 * (\depth / 8)
vsetivli zero, 16, e8, m1, ta, ma
+.ifc \type, 16intra
+.Lidct4_add4_\depth\()_rvv:
+.endif
+li t1, 32 * (\depth / 8)
vle8.vv8, (t0)
.if \depth == 8
vlse16.v v16, (a2), t1
@@ -587,7 +594,7 @@ func ff_h264_idct_add\type\()_\depth\()_rvv, zve32x, b
mv t5, a1
mv a1, a2
mv a2, a3
-li a3, 16
+csrra3, vl
mv a7, ra
1:
andit0, a4, 1
@@ -603,7 +610,7 @@ func ff_h264_idct_add\type\()_\depth\()_rvv, zve32x, b
.else
beqzt0, 2f # if (nnzc[scan8[i]])
.endif
-jal .Lidct_add4_\depth\()_rvv
+jal .Lidct4_add_\depth\()_rvv
j 3f
2:
.ifnc \type, 16
@@ -702,6 +709,38 @@ func ff_h264_idct8_add4_\depth\()_rvv, zve32x, b
addisp, sp, 48
ret
endfunc
+
+func
Re: [FFmpeg-devel] [PATCH v4 3/4] lavc/vp9dsp: R-V V mc tap h v
Le keskiviikkona 31. heinäkuuta 2024, 13.36.00 EEST flow gg a écrit : > I'm a bit confused because the calculation here goes up to 32 bits and then > returns to 8 bits. It seems that the vmax and vnclipu instructions can't be > removed by using round-related instructions？ You seem to be adding 64 then dividing by 128. That's rounding up. -- 雷米‧德尼-库尔蒙 http://www.remlab.net/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/7] avcodec/utils: apply the same alignment to YUV410 as we do to YUV420 when motion estimation is used
On Mon, Jul 15, 2024 at 03:59:12PM +0200, Michael Niedermayer wrote:
> On Tue, Jun 18, 2024 at 07:28:18PM +0200, Andreas Rheinhardt wrote:
> > Michael Niedermayer:
> > > The snow encoder uses block based motion estimation which can read out of
> > > array if
> > > insufficient alignment is used
> > >
> > > Fixes: out of array access
> > > Fixes:
> > > 68963/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-4979988435632128
> > > Fixes:
> > > 68969/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-6239933667803136.fuzz
> > >
> > > Found-by: continuous fuzzing process
> > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > Signed-off-by: Michael Niedermayer
> > > ---
> > > libavcodec/utils.c | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> > > index 337c00e789a..7914f799041 100644
> > > --- a/libavcodec/utils.c
> > > +++ b/libavcodec/utils.c
> > > @@ -259,6 +259,9 @@ void avcodec_align_dimensions2(AVCodecContext *s, int
> > > *width, int *height,
> > > if (s->codec_id == AV_CODEC_ID_SVQ1) {
> > > w_align = 64;
> > > h_align = 64;
> > > +} else if (s->codec_id == AV_CODEC_ID_SNOW) {
> > > +w_align = 16;
> > > +h_align = 16;
> > > }
> > > break;
> > > case AV_PIX_FMT_RGB555:
> >
> > avcodec_align_dimensions2() is for decoders and happens to be used by
> > ff_encode_alloc_frame(), too. But decoders should not be required to add
> > more padding because the decoder needs more. Instead the encoder should
> > add more padding itself (by using more than 2 * EDGE_WIDTH).
>
> If you have verified that the decoder alignment is sufficient and 4:1:0 does
> not
> need the alignment that 4:2:0 has for snow, then yes i can mess with some
> EDGE_WIDTH uses in snow to fix the encoder crash
>
> Again the snow decoder for 4:2:0 has 16x16 alignment, 4:1:0 has not
> and its identical in the encoders
> This is why it crashes, the patch corrects this difference.
> I do not think thats a great differernce to have
>
> If we keep the 4:2:0 and 4:1:0 difference in alignment then
> what should i do about the encoder ?
> adjust EDGE_WIDTH for 4:1:0 only ? because 4:2:0 has the buffer dimensions
> aligned correctly
> so it doesnt need it bumped up?
>
> That would result in 4:2:0 having the alignment from
> avcodec_align_dimensions2() for
> decoder and encoder
> and for 4:1:0 we would achieve something comparable with EDGE_WIDTH encoder
> side only
> and hope the decoder doesnt need it
>
> This just doesnt sound like a step in the right direction
> Also this as a security fix should be simple
Will apply the original patch with a note that its not the ideal solution
i dont want to leave this issue open while noone seems working on it
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
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/6] avcodec/cbs: sei_3d_reference_displays_info uses length 0 elements
Fixes:
70458/clusterfuzz-testcase-minimized-ffmpeg_BSF_TRACE_HEADERS_fuzzer-5259339779080192
Fixes: Assertion width > 0 && width <= 32 failed at libavcodec/cbs.c:608
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/cbs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
index b26e39eab4d..dcbc86a5f7d 100644
--- a/libavcodec/cbs.c
+++ b/libavcodec/cbs.c
@@ -605,7 +605,7 @@ static av_always_inline int
cbs_read_unsigned(CodedBitstreamContext *ctx,
CBS_TRACE_READ_START();
-av_assert0(width > 0 && width <= 32);
+av_assert0(width >= 0 && width <= 32);
if (get_bits_left(gbc) < width) {
av_log(ctx->log_ctx, AV_LOG_ERROR, "Invalid value at "
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/6] avcodec/aac/aacdec_usac: Dont leave type at a invalid value
Fixes: Assertion 0 failed at libavcodec/aac/aacdec_usac.c:1646 Fixes: 70541/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_LATM_fuzzer-5190889543106560 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/aac/aacdec_usac.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavcodec/aac/aacdec_usac.c b/libavcodec/aac/aacdec_usac.c index 1b79d19a30f..82db65eb0d0 100644 --- a/libavcodec/aac/aacdec_usac.c +++ b/libavcodec/aac/aacdec_usac.c @@ -265,6 +265,7 @@ static int decode_usac_extension(AACDecContext *ac, AACUsacElemConfig *e, /* No configuration needed - fallthrough (len should be 0) */ default: skip_bits(gb, 8*ext_config_len); +e->ext.type = ID_EXT_ELE_FILL; break; }; -- 2.45.2 ___ 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 3/6] avformat/iamf_parse: Check for 0 samples
Fixes: division by zero
Fixes:
70561/clusterfuzz-testcase-minimized-ffmpeg_IO_DEMUXER_fuzzer-6199435013455872
Fixes:
70565/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5783790316748800
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/iamf_parse.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/iamf_parse.c b/libavformat/iamf_parse.c
index cdfd5f75fef..e007d6a7af2 100644
--- a/libavformat/iamf_parse.c
+++ b/libavformat/iamf_parse.c
@@ -252,7 +252,7 @@ static int codec_config_obu(void *s, IAMFContext *c,
AVIOContext *pb, int len)
if (ret < 0)
goto fail;
-if ((codec_config->nb_samples > INT_MAX) ||
+if ((codec_config->nb_samples > INT_MAX) || codec_config->nb_samples <= 0
||
(-codec_config->audio_roll_distance > INT_MAX /
codec_config->nb_samples)) {
ret = AVERROR_INVALIDDATA;
goto fail;
--
2.45.2
___
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/6] avcodec/aac/aacdec_usac: Clean ics2->max_sfb when first SCE fails
Fixes: out of array access
Fixes:
70734/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_LATM_fuzzer-4741427068731392
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/aac/aacdec_usac.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavcodec/aac/aacdec_usac.c b/libavcodec/aac/aacdec_usac.c
index 82db65eb0d0..2938e693874 100644
--- a/libavcodec/aac/aacdec_usac.c
+++ b/libavcodec/aac/aacdec_usac.c
@@ -918,8 +918,10 @@ static int decode_usac_stereo_info(AACDecContext *ac,
AACUSACConfig *usac,
}
ret = setup_sce(ac, sce1, usac);
-if (ret < 0)
+if (ret < 0) {
+ics2->max_sfb = 0;
return ret;
+}
ret = setup_sce(ac, sce2, usac);
if (ret < 0)
--
2.45.2
___
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 5/6] avcodec/utils: apply the same alignment to YUV410 as we do to YUV420 for snow
The snow encoder uses block based motion estimation which can read out of array
if
insufficient alignment is used
It may be better to only apply this for the encoder, as it would safe a few
bytes of memory
for the decoder. Until then, this fixes the issue in a simple way.
Fixes: out of array access
Fixes:
68963/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-4979988435632128
Fixes:
68969/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-6239933667803136.fuzz
Fixed:
70497/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-5751882631413760
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/utils.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 337c00e789a..7914f799041 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -259,6 +259,9 @@ void avcodec_align_dimensions2(AVCodecContext *s, int
*width, int *height,
if (s->codec_id == AV_CODEC_ID_SVQ1) {
w_align = 64;
h_align = 64;
+} else if (s->codec_id == AV_CODEC_ID_SNOW) {
+w_align = 16;
+h_align = 16;
}
break;
case AV_PIX_FMT_RGB555:
--
2.45.2
___
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 6/6] avcodec/snow: Fix off by 1 error in run_buffer
Fixes: out of array access
Fixes:
70741/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-5703668010647552
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/snow.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/snow.c b/libavcodec/snow.c
index 0285362d439..af6214d0778 100644
--- a/libavcodec/snow.c
+++ b/libavcodec/snow.c
@@ -428,7 +428,7 @@ av_cold int ff_snow_common_init(AVCodecContext *avctx){
!FF_ALLOCZ_TYPED_ARRAY(s->spatial_dwt_buffer, width * height) ||
//FIXME this does not belong here
!FF_ALLOCZ_TYPED_ARRAY(s->temp_dwt_buffer, width) ||
!FF_ALLOCZ_TYPED_ARRAY(s->temp_idwt_buffer,width) ||
-!FF_ALLOCZ_TYPED_ARRAY(s->run_buffer, ((width + 1) >> 1) * ((height +
1) >> 1)))
+!FF_ALLOCZ_TYPED_ARRAY(s->run_buffer, ((width + 1) >> 1) * ((height +
1) >> 1) + 1))
return AVERROR(ENOMEM);
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] [PATCHv2] lavc/h264dsp: R-V V idct4_add8 (all depths)
These are really just wrappers for idct4_add16intra functions, which are in
turn mostly wrappers for idct4_add and idct4_dc_add functions.
For benchmarks refer to the later two sets.
---
libavcodec/riscv/h264dsp_init.c | 24 ++--
libavcodec/riscv/h264idct_rvv.S | 97 +
2 files changed, 107 insertions(+), 14 deletions(-)
diff --git a/libavcodec/riscv/h264dsp_init.c b/libavcodec/riscv/h264dsp_init.c
index 671330d664..7f787d8f57 100644
--- a/libavcodec/riscv/h264dsp_init.c
+++ b/libavcodec/riscv/h264dsp_init.c
@@ -54,7 +54,13 @@ void ff_h264_idct_add16intra_##depth##_rvv(uint8_t *d, const
int *soffset, \
const uint8_t nnzc[5 * 8]); \
void ff_h264_idct8_add4_##depth##_rvv(uint8_t *d, const int *soffset, \
int16_t *s, int stride, \
- const uint8_t nnzc[5 * 8]);
+ const uint8_t nnzc[5 * 8]); \
+void ff_h264_idct4_add8_##depth##_rvv(uint8_t **d, const int *soffset, \
+ int16_t *s, int stride, \
+ const uint8_t nnzc[5 * 8]); \
+void ff_h264_idct4_add8_422_##depth##_rvv(uint8_t **d, const int *soffset, \
+ int16_t *s, int stride, \
+ const uint8_t nnzc[5 * 8]);
IDCT_DEPTH(8)
IDCT_DEPTH(9)
@@ -104,6 +110,10 @@ av_cold void ff_h264dsp_init_riscv(H264DSPContext *dsp,
const int bit_depth,
dsp->h264_idct_add16intra = ff_h264_idct_add16intra_8_rvv;
# if __riscv_xlen == 64
dsp->h264_idct8_add4 = ff_h264_idct8_add4_8_rvv;
+if (chroma_format_idc <= 1)
+dsp->h264_idct_add8 = ff_h264_idct4_add8_8_rvv;
+else
+dsp->h264_idct_add8 = ff_h264_idct4_add8_422_8_rvv;
# endif
}
if (flags & AV_CPU_FLAG_RVV_I64) {
@@ -123,10 +133,16 @@ av_cold void ff_h264dsp_init_riscv(H264DSPContext *dsp,
const int bit_depth,
if (zvl128b && (flags & AV_CPU_FLAG_RVB)) { \
dsp->h264_idct_dc_add = ff_h264_idct4_dc_add_##depth##_rvv; \
dsp->h264_idct8_dc_add = ff_h264_idct8_dc_add_##depth##_rvv; \
+dsp->h264_idct_add16 = ff_h264_idct_add16_##depth##_rvv; \
+dsp->h264_idct_add16intra = \
+ff_h264_idct_add16intra_##depth##_rvv; \
if (__riscv_xlen == 64) { \
-dsp->h264_idct_add16 = ff_h264_idct_add16_##depth##_rvv; \
-dsp->h264_idct_add16intra = \
-ff_h264_idct_add16intra_##depth##_rvv; \
+if (chroma_format_idc <= 1) \
+dsp->h264_idct_add8 = \
+ff_h264_idct4_add8_##depth##_rvv; \
+else \
+dsp->h264_idct_add8 = \
+ff_h264_idct4_add8_422_##depth##_rvv; \
} \
} \
if (__riscv_xlen == 64 && (flags & AV_CPU_FLAG_RVB)) \
diff --git a/libavcodec/riscv/h264idct_rvv.S b/libavcodec/riscv/h264idct_rvv.S
index f823346c8d..d2f77a5b47 100644
--- a/libavcodec/riscv/h264idct_rvv.S
+++ b/libavcodec/riscv/h264idct_rvv.S
@@ -57,7 +57,7 @@ endfunc
func ff_h264_idct_add_8_rvv, zve32x
lpad0
csrwi vxrm, 0
-.Lidct_add4_8_rvv:
+.Lidct4_add_8_rvv:
vsetivlizero, 4, e16, mf2, ta, ma
addit1, a1, 1 * 4 * 2
vle16.v v0, (a1)
@@ -111,7 +111,7 @@ endfunc
func ff_h264_idct_add_16_rvv, zve32x
csrwi vxrm, 0
-.Lidct_add4_16_rvv:
+.Lidct4_add_16_rvv:
vsetivlizero, 4, e32, m1, ta, ma
addit1, a1, 1 * 4 * 4
vle32.v v0, (a1)
@@ -543,19 +543,26 @@ endfunc
.endr
const ff_h264_scan8
-.byte 014, 015, 024, 025, 016, 017, 026, 027
-.byte 034, 035, 044, 045, 036, 037, 046, 047
+.byte014, 015, 024, 025, 016, 017, 026, 027
+.byte034, 035, 044, 045, 036, 037, 046, 047
+.byte064, 065, 074, 075, 066, 067, 076, 077
+.byte 0104, 0105, 0114, 0115, 0106, 0107, 0116, 0117
+.byte 0134, 0135, 0144, 0145, 0136, 0137, 0146, 0147
+.byte 0154, 0155, 0164, 0165, 0156, 0157, 0166, 0167
endconst
-.macro idct4_adds type, depth
+.macro idct4_add16 type, depth
func ff_h264_idct_add\type\()_\depth\()_rvv, zve32x, b
.if \depth == 8
lpad0
.endif
csrwi vxrm, 0
lla t0, ff_h264_scan8
-li t1, 32 * (\depth / 8)
vsetivli zero, 16, e8, m1, ta, ma
+.ifc \type, 16intra
+.Lidct4_add4_\depth\()_rvv:
+.endif
+li t1, 32 * (\depth / 8)
vle8.vv8, (t0)
.if \depth == 8
vlse16.v v16, (a2), t1
@@ -587,7 +594,7 @@ func ff_h264_idct_add\type\()_\depth\()_rvv, zve
Re: [FFmpeg-devel] [PATCH 6/6] avcodec/snow: Fix off by 1 error in run_buffer
On Wed, Jul 31, 2024 at 09:54:10PM +0200, Michael Niedermayer wrote: > Fixes: out of array access > Fixes: > 70741/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-5703668010647552 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/snow.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) I intend to apply this and the other snow patch (which was on the ML since a while with a different commit message) very soon because they affect upcoming point releases [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- Plato 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] Check codec_whitelist before reinitializing AVCtx.priv_data.
On Wed, Jul 31, 2024 at 4:32 AM Anton Khirnov wrote:
> Quoting Dale Curtis (2024-07-31 01:14:13)
> > I realized there are a couple more allocations that can be skipped here
> > when a codec is not on the allow list. Here's the updated patch.
> >
> > - dale
> >
> > On Mon, Jul 29, 2024 at 10:19 AM Dale Curtis
> > wrote:
> >
> > > This ensures that if a codec isn't on codec_whitelist, its VUI
> > > information can still be populated during find_stream_info()
> > > via parsers.
> > >
> > > Signed-off-by: Dale Curtis
> > > ---
> > > libavcodec/avcodec.c | 12 ++--
> > > 1 file changed, 6 insertions(+), 6 deletions(-)
> > >
> > >
> >
> > From f87042d77d13c4c45f4b800146dc16347c1007d4 Mon Sep 17 00:00:00 2001
> > From: Dale Curtis
> > Date: Tue, 30 Jul 2024 23:12:21 +
> > Subject: [PATCH] Check codec_whitelist before reinitializing
> AVCtx.priv_data.
> >
> > This ensures that if a codec isn't on codec_whitelist, its VUI
> > information can still be populated during find_stream_info()
> > via parsers.
>
> Can you elaborate on this?
>
The current code reinitializes the private data structures then checks the
whitelist. If the private data section had already been filled out, it ends
up being overwritten causing find_stream_info to drop side channel data.
> >
> > Signed-off-by: Dale Curtis
> > ---
> > libavcodec/avcodec.c | 11 +--
> > 1 file changed, 5 insertions(+), 6 deletions(-)
> >
> > diff --git a/libavcodec/avcodec.c b/libavcodec/avcodec.c
> > index 214dca4566..1f9b3eb360 100644
> > --- a/libavcodec/avcodec.c
> > +++ b/libavcodec/avcodec.c
> > @@ -174,6 +174,11 @@ int attribute_align_arg
> avcodec_open2(AVCodecContext *avctx, const AVCodec *code
> > if (avctx->extradata_size < 0 || avctx->extradata_size >=
> FF_MAX_EXTRADATA_SIZE)
> > return AVERROR(EINVAL);
> >
> > +if (avctx->codec_whitelist && av_match_list(codec->name,
> avctx->codec_whitelist, ',') <= 0) {
> > +av_log(avctx, AV_LOG_ERROR, "Codec (%s) not on whitelist
> \'%s\'\n", codec->name, avctx->codec_whitelist);
> > +return AVERROR(EINVAL);
> > +}
>
> I think this will break the case where the whitelist is provided in the
> options dictionary, as it's not applied yet at this point.
>
I just copied the existing code a few lines up, so it seems ancillary to
this patch, but I can fix it in this one too if you want.
>
> --
> Anton Khirnov
> ___
> 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] Check codec_whitelist before reinitializing AVCtx.priv_data.
On Wed, Jul 31, 2024 at 2:10 PM Dale Curtis wrote:
> On Wed, Jul 31, 2024 at 4:32 AM Anton Khirnov wrote:
>
>> Quoting Dale Curtis (2024-07-31 01:14:13)
>> > I realized there are a couple more allocations that can be skipped here
>> > when a codec is not on the allow list. Here's the updated patch.
>> >
>> > - dale
>> >
>> > On Mon, Jul 29, 2024 at 10:19 AM Dale Curtis
>> > wrote:
>> >
>> > > This ensures that if a codec isn't on codec_whitelist, its VUI
>> > > information can still be populated during find_stream_info()
>> > > via parsers.
>> > >
>> > > Signed-off-by: Dale Curtis
>> > > ---
>> > > libavcodec/avcodec.c | 12 ++--
>> > > 1 file changed, 6 insertions(+), 6 deletions(-)
>> > >
>> > >
>> >
>> > From f87042d77d13c4c45f4b800146dc16347c1007d4 Mon Sep 17 00:00:00 2001
>> > From: Dale Curtis
>> > Date: Tue, 30 Jul 2024 23:12:21 +
>> > Subject: [PATCH] Check codec_whitelist before reinitializing
>> AVCtx.priv_data.
>> >
>> > This ensures that if a codec isn't on codec_whitelist, its VUI
>> > information can still be populated during find_stream_info()
>> > via parsers.
>>
>> Can you elaborate on this?
>>
>
> The current code reinitializes the private data structures then checks the
> whitelist. If the private data section had already been filled out, it ends
> up being overwritten causing find_stream_info to drop side channel data.
>
>
>> >
>> > Signed-off-by: Dale Curtis
>> > ---
>> > libavcodec/avcodec.c | 11 +--
>> > 1 file changed, 5 insertions(+), 6 deletions(-)
>> >
>> > diff --git a/libavcodec/avcodec.c b/libavcodec/avcodec.c
>> > index 214dca4566..1f9b3eb360 100644
>> > --- a/libavcodec/avcodec.c
>> > +++ b/libavcodec/avcodec.c
>> > @@ -174,6 +174,11 @@ int attribute_align_arg
>> avcodec_open2(AVCodecContext *avctx, const AVCodec *code
>> > if (avctx->extradata_size < 0 || avctx->extradata_size >=
>> FF_MAX_EXTRADATA_SIZE)
>> > return AVERROR(EINVAL);
>> >
>> > +if (avctx->codec_whitelist && av_match_list(codec->name,
>> avctx->codec_whitelist, ',') <= 0) {
>> > +av_log(avctx, AV_LOG_ERROR, "Codec (%s) not on whitelist
>> \'%s\'\n", codec->name, avctx->codec_whitelist);
>> > +return AVERROR(EINVAL);
>> > +}
>>
>> I think this will break the case where the whitelist is provided in the
>> options dictionary, as it's not applied yet at this point.
>>
>
> I just copied the existing code a few lines up, so it seems ancillary to
> this patch, but I can fix it in this one too if you want.
>
Nevermind, I see what you're saying -- yes this does break that case.
Thanks for catching. I'll send a fix shortly.
>
>
>>
>> --
>> Anton Khirnov
>> ___
>> 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 1/6] avcodec/cbs: sei_3d_reference_displays_info uses length 0 elements
On 7/31/2024 4:54 PM, Michael Niedermayer wrote:
Fixes:
70458/clusterfuzz-testcase-minimized-ffmpeg_BSF_TRACE_HEADERS_fuzzer-5259339779080192
Fixes: Assertion width > 0 && width <= 32 failed at libavcodec/cbs.c:608
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/cbs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
index b26e39eab4d..dcbc86a5f7d 100644
--- a/libavcodec/cbs.c
+++ b/libavcodec/cbs.c
@@ -605,7 +605,7 @@ static av_always_inline int
cbs_read_unsigned(CodedBitstreamContext *ctx,
CBS_TRACE_READ_START();
-av_assert0(width > 0 && width <= 32);
+av_assert0(width >= 0 && width <= 32);
No, sei_3d_reference_displays_info should instead not attempt to read
from the bitstream when width is 0.
I'll send a patch for this later.
if (get_bits_left(gbc) < width) {
av_log(ctx->log_ctx, AV_LOG_ERROR, "Invalid value at "
___
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 3/6] avformat/iamf_parse: Check for 0 samples
On 7/31/2024 4:54 PM, Michael Niedermayer wrote:
Fixes: division by zero
Fixes:
70561/clusterfuzz-testcase-minimized-ffmpeg_IO_DEMUXER_fuzzer-6199435013455872
Fixes:
70565/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5783790316748800
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/iamf_parse.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/iamf_parse.c b/libavformat/iamf_parse.c
index cdfd5f75fef..e007d6a7af2 100644
--- a/libavformat/iamf_parse.c
+++ b/libavformat/iamf_parse.c
@@ -252,7 +252,7 @@ static int codec_config_obu(void *s, IAMFContext *c,
AVIOContext *pb, int len)
if (ret < 0)
goto fail;
-if ((codec_config->nb_samples > INT_MAX) ||
+if ((codec_config->nb_samples > INT_MAX) || codec_config->nb_samples <= 0
||
(-codec_config->audio_roll_distance > INT_MAX /
codec_config->nb_samples)) {
ret = AVERROR_INVALIDDATA;
goto fail;
LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Check codec_whitelist before reinitializing AVCtx.priv_data.
On Wed, Jul 31, 2024 at 2:29 PM Dale Curtis wrote:
> On Wed, Jul 31, 2024 at 2:10 PM Dale Curtis
> wrote:
>
>> On Wed, Jul 31, 2024 at 4:32 AM Anton Khirnov wrote:
>>
>>> Quoting Dale Curtis (2024-07-31 01:14:13)
>>> > I realized there are a couple more allocations that can be skipped here
>>> > when a codec is not on the allow list. Here's the updated patch.
>>> >
>>> > - dale
>>> >
>>> > On Mon, Jul 29, 2024 at 10:19 AM Dale Curtis
>>> > wrote:
>>> >
>>> > > This ensures that if a codec isn't on codec_whitelist, its VUI
>>> > > information can still be populated during find_stream_info()
>>> > > via parsers.
>>> > >
>>> > > Signed-off-by: Dale Curtis
>>> > > ---
>>> > > libavcodec/avcodec.c | 12 ++--
>>> > > 1 file changed, 6 insertions(+), 6 deletions(-)
>>> > >
>>> > >
>>> >
>>> > From f87042d77d13c4c45f4b800146dc16347c1007d4 Mon Sep 17 00:00:00 2001
>>> > From: Dale Curtis
>>> > Date: Tue, 30 Jul 2024 23:12:21 +
>>> > Subject: [PATCH] Check codec_whitelist before reinitializing
>>> AVCtx.priv_data.
>>> >
>>> > This ensures that if a codec isn't on codec_whitelist, its VUI
>>> > information can still be populated during find_stream_info()
>>> > via parsers.
>>>
>>> Can you elaborate on this?
>>>
>>
>> The current code reinitializes the private data structures then checks
>> the whitelist. If the private data section had already been filled out, it
>> ends up being overwritten causing find_stream_info to drop side channel
>> data.
>>
>>
>>> >
>>> > Signed-off-by: Dale Curtis
>>> > ---
>>> > libavcodec/avcodec.c | 11 +--
>>> > 1 file changed, 5 insertions(+), 6 deletions(-)
>>> >
>>> > diff --git a/libavcodec/avcodec.c b/libavcodec/avcodec.c
>>> > index 214dca4566..1f9b3eb360 100644
>>> > --- a/libavcodec/avcodec.c
>>> > +++ b/libavcodec/avcodec.c
>>> > @@ -174,6 +174,11 @@ int attribute_align_arg
>>> avcodec_open2(AVCodecContext *avctx, const AVCodec *code
>>> > if (avctx->extradata_size < 0 || avctx->extradata_size >=
>>> FF_MAX_EXTRADATA_SIZE)
>>> > return AVERROR(EINVAL);
>>> >
>>> > +if (avctx->codec_whitelist && av_match_list(codec->name,
>>> avctx->codec_whitelist, ',') <= 0) {
>>> > +av_log(avctx, AV_LOG_ERROR, "Codec (%s) not on whitelist
>>> \'%s\'\n", codec->name, avctx->codec_whitelist);
>>> > +return AVERROR(EINVAL);
>>> > +}
>>>
>>> I think this will break the case where the whitelist is provided in the
>>> options dictionary, as it's not applied yet at this point.
>>>
>>
>> I just copied the existing code a few lines up, so it seems ancillary to
>> this patch, but I can fix it in this one too if you want.
>>
>
> Nevermind, I see what you're saying -- yes this does break that case.
> Thanks for catching. I'll send a fix shortly.
>
Fixed. Thanks.
>
>
>>
>>
>>>
>>> --
>>> Anton Khirnov
>>> ___
>>> 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".
>>>
>>
no_reinit_v3.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/mov: add support for multiple decryption keys
On Mon, 13 Nov 2023 at 09:40, Adrien Guinet wrote:
>
> This commit introduces new options to support more than one decryption
> keys:
> * add a decryption_keys option to MOV, that supports a dictionnary of
> KID=>key (in hex), using AV_OPT_TYPE_DICT
> * add the corresponding cenc_decryption_keys option to DASH
> ---
> doc/demuxers.texi | 12 +++-
> libavformat/dashdec.c | 6 +-
> libavformat/isom.h | 5 +-
> libavformat/mov.c | 80 ++
> tests/fate/mov.mak | 12
> tests/ref/fate/mov-3elist-encrypted-kid| 57 +++
> tests/ref/fate/mov-frag-encrypted-kid | 57 +++
> tests/ref/fate/mov-tenc-only-encrypted-kid | 57 +++
> 8 files changed, 269 insertions(+), 17 deletions(-)
> create mode 100644 tests/ref/fate/mov-3elist-encrypted-kid
> create mode 100644 tests/ref/fate/mov-frag-encrypted-kid
> create mode 100644 tests/ref/fate/mov-tenc-only-encrypted-kid
>
> diff --git a/doc/demuxers.texi b/doc/demuxers.texi
> index ca1563abb0..9d0ab6025c 100644
> --- a/doc/demuxers.texi
> +++ b/doc/demuxers.texi
> @@ -281,7 +281,11 @@ This demuxer accepts the following option:
> @table @option
>
> @item cenc_decryption_key
> -16-byte key, in hex, to decrypt files encrypted using ISO Common Encryption
> (CENC/AES-128 CTR; ISO/IEC 23001-7).
> +Default 16-byte key, in hex, to decrypt files encrypted using ISO Common
> Encryption (CENC/AES-128 CTR; ISO/IEC 23001-7).
> +
> +@item cenc_decryption_keys
> +Dictionary of 16-byte key ID => 16-byte key, both in hex, to decrypt files
> encrypted using ISO Common Encryption
> +(CENC/AES-128 CTR; ISO/IEC 23001-7).
>
> @end table
>
> @@ -769,7 +773,11 @@ Fixed key used for handling Audible AAX/AAX+ files. It
> has been pre-set so shoul
> specify.
>
> @item decryption_key
> -16-byte key, in hex, to decrypt files encrypted using ISO Common Encryption
> (CENC/AES-128 CTR; ISO/IEC 23001-7).
> +Default 16-byte key, in hex, to decrypt files encrypted using ISO Common
> Encryption (CENC/AES-128 CTR; ISO/IEC 23001-7).
> +
> +@item decryption_keys
> +Dictionary of 16-byte key ID => 16-byte key, both in hex, to decrypt files
> encrypted using ISO Common Encryption
> +(CENC/AES-128 CTR; ISO/IEC 23001-7).
>
> @item max_stts_delta
> Very high sample deltas written in a trak's stts box may occasionally be
> intended but usually they are written in
> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> index 1215407f3c..091deac854 100644
> --- a/libavformat/dashdec.c
> +++ b/libavformat/dashdec.c
> @@ -153,6 +153,7 @@ typedef struct DASHContext {
> AVDictionary *avio_opts;
> int max_url_size;
> char *cenc_decryption_key;
> +char *cenc_decryption_keys;
>
> /* Flags for init section*/
> int is_init_section_common_video;
> @@ -1903,6 +1904,8 @@ static int reopen_demux_for_component(AVFormatContext
> *s, struct representation
>
> if (c->cenc_decryption_key)
> av_dict_set(&in_fmt_opts, "decryption_key", c->cenc_decryption_key,
> 0);
> +if (c->cenc_decryption_keys)
> +av_dict_set(&in_fmt_opts, "decryption_keys",
> c->cenc_decryption_keys, 0);
>
> // provide additional information from mpd if available
> ret = avformat_open_input(&pls->ctx, "", in_fmt, &in_fmt_opts);
> //pls->init_section->url
> @@ -2344,7 +2347,8 @@ static const AVOption dash_options[] = {
> OFFSET(allowed_extensions), AV_OPT_TYPE_STRING,
> {.str = "aac,m4a,m4s,m4v,mov,mp4,webm,ts"},
> INT_MIN, INT_MAX, FLAGS},
> -{ "cenc_decryption_key", "Media decryption key (hex)",
> OFFSET(cenc_decryption_key), AV_OPT_TYPE_STRING, {.str = NULL}, INT_MIN,
> INT_MAX, .flags = FLAGS },
> +{ "cenc_decryption_key", "Media default decryption key (hex)",
> OFFSET(cenc_decryption_key), AV_OPT_TYPE_STRING, {.str = NULL}, INT_MIN,
> INT_MAX, .flags = FLAGS },
> +{ "cenc_decryption_keys", "Media decryption keys by KID (hex)",
> OFFSET(cenc_decryption_keys), AV_OPT_TYPE_STRING, {.str = NULL}, INT_MIN,
> INT_MAX, .flags = FLAGS },
> {NULL}
> };
>
> diff --git a/libavformat/isom.h b/libavformat/isom.h
> index 3d375d7a46..83bacb96a1 100644
> --- a/libavformat/isom.h
> +++ b/libavformat/isom.h
> @@ -312,8 +312,8 @@ typedef struct MOVContext {
> void *audible_iv;
> int audible_iv_size;
> struct AVAES *aes_decrypt;
> -uint8_t *decryption_key;
> -int decryption_key_len;
> +uint8_t *decryption_default_key;
> +int decryption_default_key_len;
> int enable_drefs;
> int32_t movie_display_matrix[3][3]; ///< display matrix from mvhd
> int have_read_mfra_size;
> @@ -328,6 +328,7 @@ typedef struct MOVContext {
> } *avif_info;
> int avif_info_size;
> int interleaved_read;
> +AVDictionary* decryption_keys;
> } MOVContext;
>
> int ff_mp4_read_descr_len(AVIOContext *pb);
> diff --git a/libav
Re: [FFmpeg-devel] [PATCH v2 02/17] avcodec: add avcodec_get_supported_config()
Niklas Haas:
> From: Niklas Haas
>
> This replaces the myriad of existing lists in AVCodec by a unified API
> call, allowing us to (ultimately) trim down the sizeof(AVCodec) quite
> substantially, while also making this more trivially extensible.
>
> In addition to the already covered lists, add two new entries for color
> space and color range, mirroring the newly added negotiable fields in
> libavfilter.
>
> I decided to drop the explicit length field from the API proposed by
> Andreas Rheinhardt, because having it in place ended up complicating
> both the codec side and the client side implementations, while also
> being strictly less flexible (it's trivial to recover a length given
> a terminator, but requires allocation to add a terminator given
> a length). Using a terminator also presents less of a porting challenge
> for existing users of the current API.
>
> Once the deprecation period passes for the existing public fields, the
> rough plan is to move the commonly used fields (such as
> pix_fmt/sample_fmt) into FFCodec, possibly as a union of audio and video
> configuration types, and then implement the rarely used fields with
> custom callbacks.
> ---
> doc/APIchanges | 5 +++
> libavcodec/avcodec.c| 75 +
> libavcodec/avcodec.h| 27 +
> libavcodec/codec.h | 19 --
> libavcodec/codec_internal.h | 24
> libavcodec/version.h| 4 +-
> 6 files changed, 148 insertions(+), 6 deletions(-)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 0a39b6d7ab8..fdeae67159d 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -2,6 +2,11 @@ The last version increases of all libraries were on
> 2024-03-07
>
> API changes, most recent first:
>
> +2024-04-xx - xx - lavc 59.6.100 - avcodec.h
> + Add avcodec_get_supported_config() and enum AVCodecConfig; deprecate
> + AVCodec.pix_fmts, AVCodec.sample_fmts, AVCodec.supported_framerates,
> + AVCodec.supported_samplerates and AVCodec.ch_layouts.
> +
> 2024-04-03 - xx - lavu 59.13.100 - pixfmt.h
>Add AVCOL_SPC_IPT_C2, AVCOL_SPC_YCGCO_RE and AVCOL_SPC_YCGCO_RO
>to map new matrix coefficients defined by H.273 v3.
> diff --git a/libavcodec/avcodec.c b/libavcodec/avcodec.c
> index 525fe516bd2..96728546d6c 100644
> --- a/libavcodec/avcodec.c
> +++ b/libavcodec/avcodec.c
> @@ -700,3 +700,78 @@ int attribute_align_arg
> avcodec_receive_frame(AVCodecContext *avctx, AVFrame *fr
> return ff_decode_receive_frame(avctx, frame);
> return ff_encode_receive_frame(avctx, frame);
> }
> +
> +#define WRAP_CONFIG(allowed_type, field)\
> +do {\
> +if (codec->type != (allowed_type)) \
> +return AVERROR(EINVAL); \
> +*out_configs = (field); \
> +return 0; \
> +} while (0)
> +
> +static const enum AVColorRange color_range_jpeg[] = {
> +AVCOL_RANGE_JPEG, AVCOL_RANGE_UNSPECIFIED
> +};
> +
> +static const enum AVColorRange color_range_mpeg[] = {
> +AVCOL_RANGE_MPEG, AVCOL_RANGE_UNSPECIFIED
> +};
> +
> +static const enum AVColorRange color_range_all[] = {
> +AVCOL_RANGE_MPEG, AVCOL_RANGE_JPEG, AVCOL_RANGE_UNSPECIFIED
> +};
> +
> +static const enum AVColorRange *color_range_table[] = {
> +[AVCOL_RANGE_MPEG] = color_range_mpeg,
> +[AVCOL_RANGE_JPEG] = color_range_jpeg,
> +[AVCOL_RANGE_MPEG | AVCOL_RANGE_JPEG] = color_range_all,
> +};
> +
> +int ff_default_get_supported_config(const AVCodecContext *avctx,
> +const AVCodec *codec,
> +enum AVCodecConfig config,
> +unsigned flags,
> +const void **out_configs)
> +{
> +switch (config) {
> +FF_DISABLE_DEPRECATION_WARNINGS
> +case AV_CODEC_CONFIG_PIX_FORMAT:
> +WRAP_CONFIG(AVMEDIA_TYPE_VIDEO, codec->pix_fmts);
> +case AV_CODEC_CONFIG_FRAME_RATE:
> +WRAP_CONFIG(AVMEDIA_TYPE_VIDEO, codec->supported_framerates);
> +case AV_CODEC_CONFIG_SAMPLE_RATE:
> +WRAP_CONFIG(AVMEDIA_TYPE_AUDIO, codec->supported_samplerates);
> +case AV_CODEC_CONFIG_SAMPLE_FORMAT:
> +WRAP_CONFIG(AVMEDIA_TYPE_AUDIO, codec->sample_fmts);
> +case AV_CODEC_CONFIG_CHANNEL_LAYOUT:
> +WRAP_CONFIG(AVMEDIA_TYPE_AUDIO, codec->ch_layouts);
> +FF_ENABLE_DEPRECATION_WARNINGS
> +
> +case AV_CODEC_CONFIG_COLOR_RANGE:
> +if (codec->type != AVMEDIA_TYPE_VIDEO)
> +return AVERROR(EINVAL);
> +*out_configs = color_range_table[ffcodec(codec)->color_ranges];
> +return 0;
> +
> +case AV_CODEC_CONFIG_COLOR_SPACE:
> +*out_configs = NULL;
> +return 0;
> +default:
> +return AVERROR(EINVAL);
> +}
> +}
> +
> +int avcodec_get_supported_config(const AVCodecContext *avctx, const AVCodec
> *codec,
> +
[FFmpeg-devel] [PATCH v5 1/3] This commit adds support for CAP and CPF markers. Decoder will exit when encountering an illegal codestream.
Signed-off-by: Osamu Watanabe
---
libavcodec/jpeg2000.h| 8 +++
libavcodec/jpeg2000dec.c | 128 ++-
libavcodec/jpeg2000dec.h | 7 +++
3 files changed, 142 insertions(+), 1 deletion(-)
diff --git a/libavcodec/jpeg2000.h b/libavcodec/jpeg2000.h
index d004c08f10..4bdc38df7c 100644
--- a/libavcodec/jpeg2000.h
+++ b/libavcodec/jpeg2000.h
@@ -37,12 +37,14 @@
enum Jpeg2000Markers {
JPEG2000_SOC = 0xff4f, // start of codestream
+JPEG2000_CAP = 0xff50, // extended capabilities
JPEG2000_SIZ = 0xff51, // image and tile size
JPEG2000_COD, // coding style default
JPEG2000_COC, // coding style component
JPEG2000_TLM = 0xff55, // tile-part length, main header
JPEG2000_PLM = 0xff57, // packet length, main header
JPEG2000_PLT, // packet length, tile-part header
+JPEG2000_CPF, // corresponding profile
JPEG2000_QCD = 0xff5c, // quantization default
JPEG2000_QCC, // quantization component
JPEG2000_RGN, // region of interest
@@ -58,6 +60,12 @@ enum Jpeg2000Markers {
JPEG2000_EOC = 0xffd9, // end of codestream
};
+enum JPEG2000_Ccap15_b14_15_params {
+HTJ2K_HTONLY = 0, // HTONLY, bit 14 and 15 are 0
+HTJ2K_HTDECLARED, // HTDECLARED, bit 14 = 1 and bit 15 = 0
+HTJ2K_MIXED = 3, // MIXED, bit 14 and 15 are 1
+};
+
#define JPEG2000_SOP_FIXED_BYTES 0xFF910004
#define JPEG2000_SOP_BYTE_LENGTH 6
diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index 091931b1ff..a1f82389fa 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -408,6 +408,73 @@ static int get_siz(Jpeg2000DecoderContext *s)
s->avctx->bits_per_raw_sample = s->precision;
return 0;
}
+/* get extended capabilities (CAP) marker segment */
+static int get_cap(Jpeg2000DecoderContext *s, Jpeg2000CodingStyle *c)
+{
+uint32_t Pcap;
+uint16_t Ccap_i[32] = { 0 };
+uint16_t Ccap_15;
+uint8_t P;
+
+if (bytestream2_get_bytes_left(&s->g) < 6) {
+av_log(s->avctx, AV_LOG_ERROR, "Insufficient space for CAP\n");
+return AVERROR_INVALIDDATA;
+}
+
+Pcap = bytestream2_get_be32u(&s->g);
+s->isHT = (Pcap >> (31 - (15 - 1))) & 1;
+for (int i = 0; i < 32; i++) {
+if ((Pcap >> (31 - i)) & 1)
+Ccap_i[i] = bytestream2_get_be16u(&s->g);
+}
+Ccap_15 = Ccap_i[14];
+if (s->isHT == 1) {
+av_log(s->avctx, AV_LOG_INFO, "This is an HTJ2K codestream.\n");
+// Bits 14-15
+switch ((Ccap_15 >> 14) & 0x3) {
+case 0x3:
+s->Ccap15_b14_15 = HTJ2K_MIXED;
+break;
+case 0x1:
+s->Ccap15_b14_15 = HTJ2K_HTDECLARED;
+break;
+case 0x0:
+s->Ccap15_b14_15 = HTJ2K_HTONLY;
+break;
+default:
+av_log(s->avctx, AV_LOG_ERROR, "Unknown CCap value.\n");
+return AVERROR(EINVAL);
+break;
+}
+// Bit 13
+if ((Ccap_15 >> 13) & 1) {
+av_log(s->avctx, AV_LOG_ERROR, "MULTIHT set is not supported.\n");
+return AVERROR_PATCHWELCOME;
+}
+// Bit 12
+s->Ccap15_b12 = (Ccap_15 >> 12) & 1;
+// Bit 11
+s->Ccap15_b11 = (Ccap_15 >> 11) & 1;
+// Bit 5
+s->Ccap15_b05 = (Ccap_15 >> 5) & 1;
+// Bit 0-4
+P = Ccap_15 & 0x1F;
+if (!P)
+s->HT_MAGB = 8;
+else if (P < 20)
+s->HT_MAGB = P + 8;
+else if (P < 31)
+s->HT_MAGB = 4 * (P - 19) + 27;
+else
+s->HT_MAGB = 74;
+
+if (s->HT_MAGB > 31) {
+av_log(s->avctx, AV_LOG_ERROR, "Available internal precision is
exceeded (MAGB> 31).\n");
+return AVERROR_PATCHWELCOME;
+}
+}
+return 0;
+}
/* get common part for COD and COC segments */
static int get_cox(Jpeg2000DecoderContext *s, Jpeg2000CodingStyle *c)
@@ -802,6 +869,15 @@ static int read_crg(Jpeg2000DecoderContext *s, int n)
bytestream2_skip(&s->g, n - 2);
return 0;
}
+
+static int read_cpf(Jpeg2000DecoderContext *s, int n)
+{
+if (bytestream2_get_bytes_left(&s->g) < (n - 2))
+return AVERROR_INVALIDDATA;
+bytestream2_skip(&s->g, n - 2);
+return 0;
+}
+
/* Tile-part lengths: see ISO 15444-1:2002, section A.7.1
* Used to know the number of tile parts and lengths.
* There may be multiple TLMs in the header.
@@ -965,6 +1041,14 @@ static int init_tile(Jpeg2000DecoderContext *s, int
tileno)
comp->roi_shift = s->roi_shift[compno];
if (!codsty->init)
return AVERROR_INVALIDDATA;
+if (s->isHT && (!s->Ccap15_b05) && (!codsty->transform)) {
+av_log(s->avctx, AV_LOG_ERROR, "Transformation = 0 (lossy DWT) is
found in HTREV HT set\n");
+return AVERROR_INVALIDDATA;
+}
+if (s->isHT
[FFmpeg-devel] [PATCH v5 2/3] This commit adds support for placeholder pass parsing.
Signed-off-by: Osamu Watanabe
---
libavcodec/jpeg2000.h | 2 +
libavcodec/jpeg2000dec.c | 352 +
libavcodec/jpeg2000htdec.c | 90 +-
3 files changed, 326 insertions(+), 118 deletions(-)
diff --git a/libavcodec/jpeg2000.h b/libavcodec/jpeg2000.h
index 4bdc38df7c..93221d90ca 100644
--- a/libavcodec/jpeg2000.h
+++ b/libavcodec/jpeg2000.h
@@ -200,6 +200,8 @@ typedef struct Jpeg2000Cblk {
/* specific to HT code-blocks */
int zbp;
int pass_lengths[2];
+uint8_t modes; // copy of SPcod/SPcoc field to parse HT-MIXED mode
+uint8_t ht_plhd; // are we looking for HT placeholder passes?
} Jpeg2000Cblk; // code block
typedef struct Jpeg2000Prec {
diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index a1f82389fa..00ff9bea6f 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -54,6 +54,15 @@
#define HAD_COC 0x01
#define HAD_QCC 0x02
+// Values of flag for placeholder passes
+enum HT_PLHD_STATUS {
+HT_PLHD_OFF,
+HT_PLHD_ON
+};
+
+#define HT_MIXED 0x80 // bit 7 of SPcod/SPcoc
+
+
/* get_bits functions for JPEG2000 packet bitstream
* It is a get_bit function with a bit-stuffing routine. If the value of the
* byte is 0xFF, the next byte includes an extra zero bit stuffed into the MSB.
@@ -1160,100 +1169,293 @@ static int
jpeg2000_decode_packet(Jpeg2000DecoderContext *s, Jpeg2000Tile *tile,
int incl, newpasses, llen;
void *tmp;
-if (cblk->npasses)
-incl = get_bits(s, 1);
-else
+if (!cblk->incl) {
+incl = 0;
+cblk->modes = codsty->cblk_style;
+if (cblk->modes >= JPEG2000_CTSY_HTJ2K_F)
+cblk->ht_plhd = HT_PLHD_ON;
+if (layno > 0)
+incl = tag_tree_decode(s, prec->cblkincl + cblkno, 0 + 1)
== 0;
incl = tag_tree_decode(s, prec->cblkincl + cblkno, layno + 1)
== layno;
-if (!incl)
-continue;
-else if (incl < 0)
-return incl;
-
-if (!cblk->npasses) {
-int zbp = tag_tree_decode(s, prec->zerobits + cblkno, 100);
-int v = expn[bandno] + numgbits - 1 - zbp;
-if (v < 0 || v > 30) {
-av_log(s->avctx, AV_LOG_ERROR,
- "nonzerobits %d invalid or unsupported\n", v);
-return AVERROR_INVALIDDATA;
+if (incl) {
+int zbp = tag_tree_decode(s, prec->zerobits + cblkno, 100);
+int v = expn[bandno] + numgbits - 1 - (zbp -
tile->comp->roi_shift);
+if (v < 0 || v > 30) {
+av_log(s->avctx, AV_LOG_ERROR,
+ "nonzerobits %d invalid or unsupported\n", v);
+return AVERROR_INVALIDDATA;
+}
+cblk->incl = 1;
+cblk->nonzerobits = v;
+cblk->zbp = zbp;
+cblk->lblock = 3;
}
-cblk->zbp = zbp;
-cblk->nonzerobits = v;
-}
-if ((newpasses = getnpasses(s)) < 0)
-return newpasses;
-av_assert2(newpasses > 0);
-if (cblk->npasses + newpasses >= JPEG2000_MAX_PASSES) {
-avpriv_request_sample(s->avctx, "Too many passes");
-return AVERROR_PATCHWELCOME;
-}
-if ((llen = getlblockinc(s)) < 0)
-return llen;
-if (cblk->lblock + llen + av_log2(newpasses) > 16) {
-avpriv_request_sample(s->avctx,
- "Block with length beyond 16 bits");
-return AVERROR_PATCHWELCOME;
+} else {
+incl = get_bits(s, 1);
}
-cblk->lblock += llen;
-
-cblk->nb_lengthinc = 0;
-cblk->nb_terminationsinc = 0;
-av_free(cblk->lengthinc);
-cblk->lengthinc = av_calloc(newpasses, sizeof(*cblk->lengthinc));
-if (!cblk->lengthinc)
-return AVERROR(ENOMEM);
-tmp = av_realloc_array(cblk->data_start, cblk->nb_terminations +
newpasses + 1, sizeof(*cblk->data_start));
-if (!tmp)
-return AVERROR(ENOMEM);
-cblk->data_start = tmp;
-do {
-int newpasses1 = 0;
+if (incl) {
+uint8_t bypass_term_threshold = 0;
+uint8_t bits_to_read = 0;
+uint32_t segment_bytes = 0;
+int32_t segment_passes = 0;
+uint8_t next_segment_passes = 0;
+int32_t href_passes, pass_bound;
+uint32_t tmp_length = 0;
+int32_t newpasses_copy, npasses_copy;
+
+if ((newpasses = getnpasses(s
[FFmpeg-devel] [PATCH v5 3/3] This commit fixes wrong treatment of MAGBP value in Ccap15 and bugs in HT block decoding.
Signed-off-by: Osamu Watanabe
---
libavcodec/jpeg2000dec.c | 11 +--
libavcodec/jpeg2000htdec.c | 136 ++---
libavcodec/jpeg2000htdec.h | 2 +-
3 files changed, 89 insertions(+), 60 deletions(-)
diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index 00ff9bea6f..6653fc1ab4 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -391,6 +391,9 @@ static int get_siz(Jpeg2000DecoderContext *s)
} else if (ncomponents == 1 && s->precision == 8) {
s->avctx->pix_fmt = AV_PIX_FMT_GRAY8;
i = 0;
+} else if (ncomponents == 1 && s->precision == 12) {
+s->avctx->pix_fmt = AV_PIX_FMT_GRAY16LE;
+i = 0;
}
}
@@ -2204,7 +2207,7 @@ static inline int tile_codeblocks(const
Jpeg2000DecoderContext *s, Jpeg2000Tile
Jpeg2000Band *band = rlevel->band + bandno;
int cblkno = 0, bandpos;
/* See Rec. ITU-T T.800, Equation E-2 */
-int magp = quantsty->expn[subbandno] + quantsty->nguardbits -
1;
+int M_b = quantsty->expn[subbandno] + quantsty->nguardbits - 1;
bandpos = bandno + (reslevelno > 0);
@@ -2212,8 +2215,8 @@ static inline int tile_codeblocks(const
Jpeg2000DecoderContext *s, Jpeg2000Tile
band->coord[1][0] == band->coord[1][1])
continue;
-if ((codsty->cblk_style & JPEG2000_CTSY_HTJ2K_F) && magp >=
31) {
-avpriv_request_sample(s->avctx, "JPEG2000_CTSY_HTJ2K_F and
magp >= 31");
+if ((codsty->cblk_style & JPEG2000_CTSY_HTJ2K_F) && M_b >= 31)
{
+avpriv_request_sample(s->avctx, "JPEG2000_CTSY_HTJ2K_F and
M_b >= 31");
return AVERROR_PATCHWELCOME;
}
@@ -2234,7 +2237,7 @@ static inline int tile_codeblocks(const
Jpeg2000DecoderContext *s, Jpeg2000Tile
ret = ff_jpeg2000_decode_htj2k(s, codsty, &t1,
cblk,
cblk->coord[0][1] -
cblk->coord[0][0],
cblk->coord[1][1] -
cblk->coord[1][0],
- magp,
comp->roi_shift);
+ M_b,
comp->roi_shift);
else
ret = decode_cblk(s, codsty, &t1, cblk,
cblk->coord[0][1] -
cblk->coord[0][0],
diff --git a/libavcodec/jpeg2000htdec.c b/libavcodec/jpeg2000htdec.c
index 9b473e11d3..0296792a6a 100644
--- a/libavcodec/jpeg2000htdec.c
+++ b/libavcodec/jpeg2000htdec.c
@@ -122,7 +122,7 @@ static void jpeg2000_init_mel(StateVars *s, uint32_t Pcup)
static void jpeg2000_init_mag_ref(StateVars *s, uint32_t Lref)
{
-s->pos = Lref - 2;
+s->pos = Lref - 1;
s->bits = 0;
s->last = 0xFF;
s->tmp = 0;
@@ -145,9 +145,10 @@ static void jpeg2000_init_mel_decoder(MelDecoderState
*mel_state)
static int jpeg2000_bitbuf_refill_backwards(StateVars *buffer, const uint8_t
*array)
{
uint64_t tmp = 0;
-int32_t position = buffer->pos - 4;
uint32_t new_bits = 32;
+buffer->last = array[buffer->pos + 1];
+
if (buffer->bits_left >= 32)
return 0; // enough data, no need to pull in more bits
@@ -157,9 +158,24 @@ static int jpeg2000_bitbuf_refill_backwards(StateVars
*buffer, const uint8_t *ar
* the bottom most bits.
*/
-for(int i = FFMAX(0, position + 1); i <= buffer->pos + 1; i++)
-tmp = 256*tmp + array[i];
-
+if (buffer->pos >= 3) { // Common case; we have at least 4 bytes available
+ tmp = array[buffer->pos - 3];
+ tmp = (tmp << 8) | array[buffer->pos - 2];
+ tmp = (tmp << 8) | array[buffer->pos - 1];
+ tmp = (tmp << 8) | array[buffer->pos];
+ tmp = (tmp << 8) | buffer->last; // For stuffing bit detection
+ buffer->pos -= 4;
+} else {
+if (buffer->pos >= 2)
+tmp = array[buffer->pos - 2];
+if (buffer->pos >= 1)
+tmp = (tmp << 8) | array[buffer->pos - 1];
+if (buffer->pos >= 0)
+tmp = (tmp << 8) | array[buffer->pos];
+buffer->pos = 0;
+tmp = (tmp << 8) | buffer->last; // For stuffing bit detection
+}
+// Now remove any stuffing bits, shifting things down as we go
if ((tmp & 0x7FFF00) > 0x7F8F00) {
tmp &= 0x7F;
new_bits--;
@@ -176,13 +192,11 @@ static int jpeg2000_bitbuf_refill_backwards(StateVars
*buffer, const uint8_t *ar
tmp = (tmp & 0x007FFF) + ((tmp & 0xFF) >> 1);
new_bits--;
}
-
-tmp >>= 8; // Remove temporary byte loaded
+tmp >>= 8; // Shifts away the extra byte we imported
/* Add bits to the MSB of the bit buffer */
bu
Re: [FFmpeg-devel] [PATCH v4 1/3] avcodec/jpeg2000dec: Add support for CAP and CPF markers
According to the suggestions for v4, I have posted the patch set v5. It is confirmed that the decoder with v5 passes all the conformance testing defined in ISO/IEC 15444-4. Best, Osamu > On Jul 31, 2024, at 6:39, Michael Niedermayer wrote: > > On Tue, Jul 30, 2024 at 10:22:37PM +0200, Tomas Hardin wrote: >> fre 2024-07-26 klockan 23:29 +0200 skrev Michael Niedermayer: >>> On Thu, Jul 25, 2024 at 05:06:04PM -0700, Pierre-Anthony Lemieux >>> wrote: On Thu, Jul 25, 2024 at 2:17?AM Tomas Hardin wrote: > > son 2024-07-21 klockan 14:07 +0900 skrev Pierre-Anthony Lemieux: >> On Sat, Jul 20, 2024 at 5:12?PM Tomas Hardin >> wrote: >>> >>> tor 2024-07-18 klockan 23:10 +0900 skrev Pierre-Anthony >>> Lemieux: On Mon, Jul 15, 2024 at 10:33?PM Tomas Hardin wrote: > > fre 2024-07-12 klockan 12:51 -0700 skrev Pierre-Anthony > Lemieux: >> On Thu, Jul 11, 2024 at 10:28?PM Tomas Hardin >> >> wrote: >>> +if (s->in_tile_headers == 1 && s->isHT && (!s- > Ccap15_b11)) +av_log(s->avctx, AV_LOG_WARNING, "COD marker is found in HOMOGENEOUS HT set\n"); >>> >>> How bad is this and the other markers being present >>> in this >>> case? >> >> At the very least, it means that signaling is >> inconsistent >> within >> the >> codestream since the standard states that: >> """ >> The HOMOGENEOUS set is the set of HTJ2K codestreams >> where: >> ? none of the functional marker segments, e.g., COD, >> COC, >> RGN, >> QCD, >> QCC, and POC, are present in any >> tile-part header; and >> ? no PPT marker segment is present. >> """ >> >> The point of signalling that a codestream is >> "HOMOGENEOUS" is >> to >> allow >> decoders to configure themselves solely based on >> information >> retrieved >> entirely from the main header. >> >> Since, AFAIK, FFMPEG does not rely on the HOMOGENEOUS >> to >> short- >> circuit >> configuration, incorrect HOMOGENEOUS signalling will >> likely >> not >> impact >> FFMPEG. > > It could happen that information in tile headers > contradict > information > in the main header, right? In such a case it sounds like > we > can't > be > sure which decode is the correct one. Per the spec, the decoder uses the COD information in tile- parts over the COD information in the header. The issue here is that a decoder, upon seeing HOMOGENEOUS, simply does not bother with looking for COD information in tile-parts, thereby missing critical information. >>> >>> So it is actually perfectly legal? Then it seems this patch >>> is >>> wrong >> >> What is not "illegal": the HOMOGENEOUS flag being equal to true >> *and* >> having COD marker segments in tile-parts. >> >> This is what the patch detects. >> >> FFMPEG can decode such illegal codestream. Other decoders might >> not. >> >> The question is: what should FFMPEG do? Should FFMPEG exit or >> warn >> and continue. > > If the spec allows it but it's perhaps unadviced then warning > about it > seems reasonable (I totally messed up my double negative. Repeat below. Sorry for the confusion.) What is "illegal": the HOMOGENEOUS flag being equal to true *and* having COD marker segments in tile-parts. This is what the patch detects. FFMPEG can decode such illegal codestream. Other decoders might not. The question is: what should FFMPEG do? Should FFMPEG exit or warn and continue. >>> >>> Does such a codestream actually exist ? I mean is this just a >>> hypothetical case >>> or something existing ? >> >> This is more to stem the stream before anything happens because we were >> lax with parsing > > If such files dont exist then being picky makes sense > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > You can kill me, but you cannot change the truth. > ___ > 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.
[FFmpeg-devel] [PATCH 1/2] avformat/mov: ensure the IAMF track is the first
Fixes crashes when muxing video tracks alongside IAMF ones.
Signed-off-by: James Almer
---
libavformat/movenc.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index ae49582a1a..87ec368d52 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -7536,6 +7536,7 @@ static int mov_init_iamf_track(AVFormatContext *s)
if (!track->iamf)
return AVERROR(ENOMEM);
+track->first_iamf_idx = INT_MAX;
for (int i = 0; i < s->nb_stream_groups; i++) {
const AVStreamGroup *stg = s->stream_groups[i];
switch(stg->type) {
@@ -7558,6 +7559,11 @@ static int mov_init_iamf_track(AVFormatContext *s)
return ret;
}
+if (track->first_iamf_idx != 0) {
+av_log(s, AV_LOG_ERROR, "The IMAF track must be the first track\n");
+return AVERROR(EINVAL);;
+}
+
track->tag = MKTAG('i','a','m','f');
ret = avio_open_dyn_buf(&track->iamf_buf);
@@ -7830,8 +7836,11 @@ static int mov_init(AVFormatContext *s)
for (int j = 0, i = 0; j < s->nb_streams; j++) {
AVStream *st = s->streams[j];
-if (st != st->priv_data)
+if (st != st->priv_data) {
+if (!i)
+i++; // IAMF track is the first one
continue;
+}
st->priv_data = &mov->tracks[i++];
}
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] fate/mov: add an IAMF+video muxing test
Signed-off-by: James Almer --- tests/fate/mov.mak | 11 + tests/ref/fate/mov-mp4-iamf-5_1_4-h264 | 568 + 2 files changed, 579 insertions(+) create mode 100644 tests/ref/fate/mov-mp4-iamf-5_1_4-h264 diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak index d12980815f..a7ea503844 100644 --- a/tests/fate/mov.mak +++ b/tests/fate/mov.mak @@ -262,6 +262,17 @@ fate-mov-mp4-iamf-ambisonic_1: CMD = transcode wav $(SRC) mp4 "-auto_conversion_ -streamid 0:0 -streamid 1:1 -streamid 2:2 -streamid 3:3 -map [MONO0] -map [MONO1] -map [MONO2] -map [MONO3] -c:a flac -t 1" "-c:a copy -map 0" \ "-show_entries stream_group=index,id,nb_streams,type:stream_group_components:stream_group_disposition:stream_group_tags:stream_group_stream=index,id:stream_group_stream_disposition" +FATE_MOV_FFMPEG_FFPROBE_SAMPLES-$(call TRANSCODE, FLAC, MOV, WAV_DEMUXER PCM_S16LE_DECODER ARESAMPLE_FILTER H264_PARSER) += fate-mov-mp4-iamf-5_1_4-h264 +fate-mov-mp4-iamf-5_1_4-h264: tests/data/asynth-44100-10.wav tests/data/filtergraphs/iamf_5_1_4 tests/data/streamgroups/audio_element-5_1_4 tests/data/streamgroups/mix_presentation-5_1_4 +fate-mov-mp4-iamf-5_1_4-h264: SRC = $(TARGET_PATH)/tests/data/asynth-44100-10.wav +fate-mov-mp4-iamf-5_1_4-h264: CMD = transcode wav $(SRC) mp4 "-auto_conversion_filters \ + -/filter_complex $(TARGET_PATH)/tests/data/filtergraphs/iamf_5_1_4 \ + -/stream_group $(TARGET_PATH)/tests/data/streamgroups/audio_element-5_1_4 \ + -/stream_group $(TARGET_PATH)/tests/data/streamgroups/mix_presentation-5_1_4 \ + -streamid 0:0 -streamid 1:1 -streamid 2:2 -streamid 3:3 -streamid 4:4 -streamid 5:5 -streamid 6:6 -map [FRONT] -map [BACK] -map [CENTER] -map [LFE] -map [TOP_FRONT] -map [TOP_BACK] -map 1:v:0 -c:a flac -c:v copy -t 1" "-c:a copy -c:v copy -map 0" \ + "-show_entries stream_group=index,id,nb_streams,type:stream_group_components:stream_group_disposition:stream_group_tags:stream_group_stream=index,id:stream_group_stream_disposition" \ + "-i $(TARGET_SAMPLES)/h264/intra_refresh.h264" + FATE_FFMPEG += $(FATE_MOV_FFMPEG-yes) FATE_FFMPEG_FFPROBE += $(FATE_MOV_FFMPEG_FFPROBE-yes) diff --git a/tests/ref/fate/mov-mp4-iamf-5_1_4-h264 b/tests/ref/fate/mov-mp4-iamf-5_1_4-h264 new file mode 100644 index 00..53a0b28832 --- /dev/null +++ b/tests/ref/fate/mov-mp4-iamf-5_1_4-h264 @@ -0,0 +1,568 @@ +5a29ac3ccba1d2860b80a2b662b29266 *tests/data/fate/mov-mp4-iamf-5_1_4-h264.mp4 +126671 tests/data/fate/mov-mp4-iamf-5_1_4-h264.mp4 +#extradata 0: 34, 0xafa70d5e +#extradata 1: 34, 0xafa70d5e +#extradata 2: 34, 0xaf7b0d5c +#extradata 3: 34, 0xaf7b0d5c +#extradata 4: 34, 0xafa70d5e +#extradata 5: 34, 0xafa70d5e +#extradata 6: 189, 0x738b56ad +#tb 0: 1/44100 +#media_type 0: audio +#codec_id 0: flac +#sample_rate 0: 44100 +#channel_layout_name 0: stereo +#tb 1: 1/44100 +#media_type 1: audio +#codec_id 1: flac +#sample_rate 1: 44100 +#channel_layout_name 1: stereo +#tb 2: 1/44100 +#media_type 2: audio +#codec_id 2: flac +#sample_rate 2: 44100 +#channel_layout_name 2: mono +#tb 3: 1/44100 +#media_type 3: audio +#codec_id 3: flac +#sample_rate 3: 44100 +#channel_layout_name 3: mono +#tb 4: 1/44100 +#media_type 4: audio +#codec_id 4: flac +#sample_rate 4: 44100 +#channel_layout_name 4: stereo +#tb 5: 1/44100 +#media_type 5: audio +#codec_id 5: flac +#sample_rate 5: 44100 +#channel_layout_name 5: stereo +#tb 6: 1/120 +#media_type 6: video +#codec_id 6: h264 +#dimensions 6: 320x240 +#sar 6: 0/1 +0, 0, 0, 4608, 1399, 0x6e89566e +1, 0, 0, 4608, 1399, 0x6e89566e +2, 0, 0, 4608, 1396, 0x0dcb5677 +3, 0, 0, 4608, 1396, 0x0dcb5677 +4, 0, 0, 4608, 1399, 0x6e89566e +5, 0, 0, 4608, 1399, 0x6e89566e +6, 0, 0,48000, 3299, 0xac71660d +6, 48000, 48000,48000, 131, 0x3c963e3d, F=0x0 +6, 96000, 96000,48000, 3398, 0x5bdd9447, F=0x0 +0, 4608, 4608, 4608, 1442, 0x6c3c5b13 +1, 4608, 4608, 4608, 1442, 0x6c3c5b13 +2, 4608, 4608, 4608, 1439, 0xc46b5ac5 +3, 4608, 4608, 4608, 1439, 0xc46b5ac5 +4, 4608, 4608, 4608, 1442, 0x6c3c5b13 +5, 4608, 4608, 4608, 1442, 0x6c3c5b13 +6, 144000, 144000,48000, 147, 0xc50d446d, F=0x0 +6, 192000, 192000,48000, 3702, 0xaca23a84, F=0x0 +6, 24, 24,48000, 148, 0xe9144a44, F=0x0 +0, 9216, 9216, 4608, 1380, 0xc497571b +1, 9216, 9216, 4608, 1380, 0xc497571b +2, 9216, 9216, 4608, 1377, 0x5b2a55fe +3, 9216, 9216, 4608, 1377, 0x5b2a55fe +4, 9216, 9216, 4608, 1380, 0xc497571b +5, 9216, 9216, 4608, 1380, 0xc497571b +6,
[FFmpeg-devel] [PATCH v6 1/3] avcodec/jpeg2000dec: Add support for CAP and CPF markers
This commit adds support for CAP and CPF markers. Decoder will exit when
encountering an illegal codestream.
It is confirmed that the decoder passes all the test cases in FATE and
ISO/IEC 15444-4.
The subject was wrong in the v5 set of patches. The v6 corrects it.
Signed-off-by: Osamu Watanabe
---
libavcodec/jpeg2000.h| 8 +++
libavcodec/jpeg2000dec.c | 128 ++-
libavcodec/jpeg2000dec.h | 7 +++
3 files changed, 142 insertions(+), 1 deletion(-)
diff --git a/libavcodec/jpeg2000.h b/libavcodec/jpeg2000.h
index d004c08f10..4bdc38df7c 100644
--- a/libavcodec/jpeg2000.h
+++ b/libavcodec/jpeg2000.h
@@ -37,12 +37,14 @@
enum Jpeg2000Markers {
JPEG2000_SOC = 0xff4f, // start of codestream
+JPEG2000_CAP = 0xff50, // extended capabilities
JPEG2000_SIZ = 0xff51, // image and tile size
JPEG2000_COD, // coding style default
JPEG2000_COC, // coding style component
JPEG2000_TLM = 0xff55, // tile-part length, main header
JPEG2000_PLM = 0xff57, // packet length, main header
JPEG2000_PLT, // packet length, tile-part header
+JPEG2000_CPF, // corresponding profile
JPEG2000_QCD = 0xff5c, // quantization default
JPEG2000_QCC, // quantization component
JPEG2000_RGN, // region of interest
@@ -58,6 +60,12 @@ enum Jpeg2000Markers {
JPEG2000_EOC = 0xffd9, // end of codestream
};
+enum JPEG2000_Ccap15_b14_15_params {
+HTJ2K_HTONLY = 0, // HTONLY, bit 14 and 15 are 0
+HTJ2K_HTDECLARED, // HTDECLARED, bit 14 = 1 and bit 15 = 0
+HTJ2K_MIXED = 3, // MIXED, bit 14 and 15 are 1
+};
+
#define JPEG2000_SOP_FIXED_BYTES 0xFF910004
#define JPEG2000_SOP_BYTE_LENGTH 6
diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index 091931b1ff..a1f82389fa 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -408,6 +408,73 @@ static int get_siz(Jpeg2000DecoderContext *s)
s->avctx->bits_per_raw_sample = s->precision;
return 0;
}
+/* get extended capabilities (CAP) marker segment */
+static int get_cap(Jpeg2000DecoderContext *s, Jpeg2000CodingStyle *c)
+{
+uint32_t Pcap;
+uint16_t Ccap_i[32] = { 0 };
+uint16_t Ccap_15;
+uint8_t P;
+
+if (bytestream2_get_bytes_left(&s->g) < 6) {
+av_log(s->avctx, AV_LOG_ERROR, "Insufficient space for CAP\n");
+return AVERROR_INVALIDDATA;
+}
+
+Pcap = bytestream2_get_be32u(&s->g);
+s->isHT = (Pcap >> (31 - (15 - 1))) & 1;
+for (int i = 0; i < 32; i++) {
+if ((Pcap >> (31 - i)) & 1)
+Ccap_i[i] = bytestream2_get_be16u(&s->g);
+}
+Ccap_15 = Ccap_i[14];
+if (s->isHT == 1) {
+av_log(s->avctx, AV_LOG_INFO, "This is an HTJ2K codestream.\n");
+// Bits 14-15
+switch ((Ccap_15 >> 14) & 0x3) {
+case 0x3:
+s->Ccap15_b14_15 = HTJ2K_MIXED;
+break;
+case 0x1:
+s->Ccap15_b14_15 = HTJ2K_HTDECLARED;
+break;
+case 0x0:
+s->Ccap15_b14_15 = HTJ2K_HTONLY;
+break;
+default:
+av_log(s->avctx, AV_LOG_ERROR, "Unknown CCap value.\n");
+return AVERROR(EINVAL);
+break;
+}
+// Bit 13
+if ((Ccap_15 >> 13) & 1) {
+av_log(s->avctx, AV_LOG_ERROR, "MULTIHT set is not supported.\n");
+return AVERROR_PATCHWELCOME;
+}
+// Bit 12
+s->Ccap15_b12 = (Ccap_15 >> 12) & 1;
+// Bit 11
+s->Ccap15_b11 = (Ccap_15 >> 11) & 1;
+// Bit 5
+s->Ccap15_b05 = (Ccap_15 >> 5) & 1;
+// Bit 0-4
+P = Ccap_15 & 0x1F;
+if (!P)
+s->HT_MAGB = 8;
+else if (P < 20)
+s->HT_MAGB = P + 8;
+else if (P < 31)
+s->HT_MAGB = 4 * (P - 19) + 27;
+else
+s->HT_MAGB = 74;
+
+if (s->HT_MAGB > 31) {
+av_log(s->avctx, AV_LOG_ERROR, "Available internal precision is
exceeded (MAGB> 31).\n");
+return AVERROR_PATCHWELCOME;
+}
+}
+return 0;
+}
/* get common part for COD and COC segments */
static int get_cox(Jpeg2000DecoderContext *s, Jpeg2000CodingStyle *c)
@@ -802,6 +869,15 @@ static int read_crg(Jpeg2000DecoderContext *s, int n)
bytestream2_skip(&s->g, n - 2);
return 0;
}
+
+static int read_cpf(Jpeg2000DecoderContext *s, int n)
+{
+if (bytestream2_get_bytes_left(&s->g) < (n - 2))
+return AVERROR_INVALIDDATA;
+bytestream2_skip(&s->g, n - 2);
+return 0;
+}
+
/* Tile-part lengths: see ISO 15444-1:2002, section A.7.1
* Used to know the number of tile parts and lengths.
* There may be multiple TLMs in the header.
@@ -965,6 +1041,14 @@ static int init_tile(Jpeg2000DecoderContext *s, int
tileno)
comp->roi_shift = s->roi_shift[compno];
if (!codsty->init)
return A
[FFmpeg-devel] [PATCH v6 3/3] avcodec/jpeg2000dec: Fix HT decoding
This commit fixes wrong treatment of MAGBP value in Ccap15 and bugs in HT block
decoding.
Signed-off-by: Osamu Watanabe
---
libavcodec/jpeg2000dec.c | 11 +--
libavcodec/jpeg2000htdec.c | 136 ++---
libavcodec/jpeg2000htdec.h | 2 +-
3 files changed, 89 insertions(+), 60 deletions(-)
diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index 00ff9bea6f..6653fc1ab4 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -391,6 +391,9 @@ static int get_siz(Jpeg2000DecoderContext *s)
} else if (ncomponents == 1 && s->precision == 8) {
s->avctx->pix_fmt = AV_PIX_FMT_GRAY8;
i = 0;
+} else if (ncomponents == 1 && s->precision == 12) {
+s->avctx->pix_fmt = AV_PIX_FMT_GRAY16LE;
+i = 0;
}
}
@@ -2204,7 +2207,7 @@ static inline int tile_codeblocks(const
Jpeg2000DecoderContext *s, Jpeg2000Tile
Jpeg2000Band *band = rlevel->band + bandno;
int cblkno = 0, bandpos;
/* See Rec. ITU-T T.800, Equation E-2 */
-int magp = quantsty->expn[subbandno] + quantsty->nguardbits -
1;
+int M_b = quantsty->expn[subbandno] + quantsty->nguardbits - 1;
bandpos = bandno + (reslevelno > 0);
@@ -2212,8 +2215,8 @@ static inline int tile_codeblocks(const
Jpeg2000DecoderContext *s, Jpeg2000Tile
band->coord[1][0] == band->coord[1][1])
continue;
-if ((codsty->cblk_style & JPEG2000_CTSY_HTJ2K_F) && magp >=
31) {
-avpriv_request_sample(s->avctx, "JPEG2000_CTSY_HTJ2K_F and
magp >= 31");
+if ((codsty->cblk_style & JPEG2000_CTSY_HTJ2K_F) && M_b >= 31)
{
+avpriv_request_sample(s->avctx, "JPEG2000_CTSY_HTJ2K_F and
M_b >= 31");
return AVERROR_PATCHWELCOME;
}
@@ -2234,7 +2237,7 @@ static inline int tile_codeblocks(const
Jpeg2000DecoderContext *s, Jpeg2000Tile
ret = ff_jpeg2000_decode_htj2k(s, codsty, &t1,
cblk,
cblk->coord[0][1] -
cblk->coord[0][0],
cblk->coord[1][1] -
cblk->coord[1][0],
- magp,
comp->roi_shift);
+ M_b,
comp->roi_shift);
else
ret = decode_cblk(s, codsty, &t1, cblk,
cblk->coord[0][1] -
cblk->coord[0][0],
diff --git a/libavcodec/jpeg2000htdec.c b/libavcodec/jpeg2000htdec.c
index 9b473e11d3..0296792a6a 100644
--- a/libavcodec/jpeg2000htdec.c
+++ b/libavcodec/jpeg2000htdec.c
@@ -122,7 +122,7 @@ static void jpeg2000_init_mel(StateVars *s, uint32_t Pcup)
static void jpeg2000_init_mag_ref(StateVars *s, uint32_t Lref)
{
-s->pos = Lref - 2;
+s->pos = Lref - 1;
s->bits = 0;
s->last = 0xFF;
s->tmp = 0;
@@ -145,9 +145,10 @@ static void jpeg2000_init_mel_decoder(MelDecoderState
*mel_state)
static int jpeg2000_bitbuf_refill_backwards(StateVars *buffer, const uint8_t
*array)
{
uint64_t tmp = 0;
-int32_t position = buffer->pos - 4;
uint32_t new_bits = 32;
+buffer->last = array[buffer->pos + 1];
+
if (buffer->bits_left >= 32)
return 0; // enough data, no need to pull in more bits
@@ -157,9 +158,24 @@ static int jpeg2000_bitbuf_refill_backwards(StateVars
*buffer, const uint8_t *ar
* the bottom most bits.
*/
-for(int i = FFMAX(0, position + 1); i <= buffer->pos + 1; i++)
-tmp = 256*tmp + array[i];
-
+if (buffer->pos >= 3) { // Common case; we have at least 4 bytes available
+ tmp = array[buffer->pos - 3];
+ tmp = (tmp << 8) | array[buffer->pos - 2];
+ tmp = (tmp << 8) | array[buffer->pos - 1];
+ tmp = (tmp << 8) | array[buffer->pos];
+ tmp = (tmp << 8) | buffer->last; // For stuffing bit detection
+ buffer->pos -= 4;
+} else {
+if (buffer->pos >= 2)
+tmp = array[buffer->pos - 2];
+if (buffer->pos >= 1)
+tmp = (tmp << 8) | array[buffer->pos - 1];
+if (buffer->pos >= 0)
+tmp = (tmp << 8) | array[buffer->pos];
+buffer->pos = 0;
+tmp = (tmp << 8) | buffer->last; // For stuffing bit detection
+}
+// Now remove any stuffing bits, shifting things down as we go
if ((tmp & 0x7FFF00) > 0x7F8F00) {
tmp &= 0x7F;
new_bits--;
@@ -176,13 +192,11 @@ static int jpeg2000_bitbuf_refill_backwards(StateVars
*buffer, const uint8_t *ar
tmp = (tmp & 0x007FFF) + ((tmp & 0xFF) >> 1);
new_bits--;
}
-
-tmp >>= 8; // Remove temporary byte loaded
+tmp >>= 8; // Shift
[FFmpeg-devel] [PATCH v6 2/3] avcodec/jpeg2000dec: Add support for placeholder passes
This commit adds support for placeholder pass parsing.
Signed-off-by: Osamu Watanabe
---
libavcodec/jpeg2000.h | 2 +
libavcodec/jpeg2000dec.c | 352 +
libavcodec/jpeg2000htdec.c | 90 +-
3 files changed, 326 insertions(+), 118 deletions(-)
diff --git a/libavcodec/jpeg2000.h b/libavcodec/jpeg2000.h
index 4bdc38df7c..93221d90ca 100644
--- a/libavcodec/jpeg2000.h
+++ b/libavcodec/jpeg2000.h
@@ -200,6 +200,8 @@ typedef struct Jpeg2000Cblk {
/* specific to HT code-blocks */
int zbp;
int pass_lengths[2];
+uint8_t modes; // copy of SPcod/SPcoc field to parse HT-MIXED mode
+uint8_t ht_plhd; // are we looking for HT placeholder passes?
} Jpeg2000Cblk; // code block
typedef struct Jpeg2000Prec {
diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index a1f82389fa..00ff9bea6f 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -54,6 +54,15 @@
#define HAD_COC 0x01
#define HAD_QCC 0x02
+// Values of flag for placeholder passes
+enum HT_PLHD_STATUS {
+HT_PLHD_OFF,
+HT_PLHD_ON
+};
+
+#define HT_MIXED 0x80 // bit 7 of SPcod/SPcoc
+
+
/* get_bits functions for JPEG2000 packet bitstream
* It is a get_bit function with a bit-stuffing routine. If the value of the
* byte is 0xFF, the next byte includes an extra zero bit stuffed into the MSB.
@@ -1160,100 +1169,293 @@ static int
jpeg2000_decode_packet(Jpeg2000DecoderContext *s, Jpeg2000Tile *tile,
int incl, newpasses, llen;
void *tmp;
-if (cblk->npasses)
-incl = get_bits(s, 1);
-else
+if (!cblk->incl) {
+incl = 0;
+cblk->modes = codsty->cblk_style;
+if (cblk->modes >= JPEG2000_CTSY_HTJ2K_F)
+cblk->ht_plhd = HT_PLHD_ON;
+if (layno > 0)
+incl = tag_tree_decode(s, prec->cblkincl + cblkno, 0 + 1)
== 0;
incl = tag_tree_decode(s, prec->cblkincl + cblkno, layno + 1)
== layno;
-if (!incl)
-continue;
-else if (incl < 0)
-return incl;
-
-if (!cblk->npasses) {
-int zbp = tag_tree_decode(s, prec->zerobits + cblkno, 100);
-int v = expn[bandno] + numgbits - 1 - zbp;
-if (v < 0 || v > 30) {
-av_log(s->avctx, AV_LOG_ERROR,
- "nonzerobits %d invalid or unsupported\n", v);
-return AVERROR_INVALIDDATA;
+if (incl) {
+int zbp = tag_tree_decode(s, prec->zerobits + cblkno, 100);
+int v = expn[bandno] + numgbits - 1 - (zbp -
tile->comp->roi_shift);
+if (v < 0 || v > 30) {
+av_log(s->avctx, AV_LOG_ERROR,
+ "nonzerobits %d invalid or unsupported\n", v);
+return AVERROR_INVALIDDATA;
+}
+cblk->incl = 1;
+cblk->nonzerobits = v;
+cblk->zbp = zbp;
+cblk->lblock = 3;
}
-cblk->zbp = zbp;
-cblk->nonzerobits = v;
-}
-if ((newpasses = getnpasses(s)) < 0)
-return newpasses;
-av_assert2(newpasses > 0);
-if (cblk->npasses + newpasses >= JPEG2000_MAX_PASSES) {
-avpriv_request_sample(s->avctx, "Too many passes");
-return AVERROR_PATCHWELCOME;
-}
-if ((llen = getlblockinc(s)) < 0)
-return llen;
-if (cblk->lblock + llen + av_log2(newpasses) > 16) {
-avpriv_request_sample(s->avctx,
- "Block with length beyond 16 bits");
-return AVERROR_PATCHWELCOME;
+} else {
+incl = get_bits(s, 1);
}
-cblk->lblock += llen;
-
-cblk->nb_lengthinc = 0;
-cblk->nb_terminationsinc = 0;
-av_free(cblk->lengthinc);
-cblk->lengthinc = av_calloc(newpasses, sizeof(*cblk->lengthinc));
-if (!cblk->lengthinc)
-return AVERROR(ENOMEM);
-tmp = av_realloc_array(cblk->data_start, cblk->nb_terminations +
newpasses + 1, sizeof(*cblk->data_start));
-if (!tmp)
-return AVERROR(ENOMEM);
-cblk->data_start = tmp;
-do {
-int newpasses1 = 0;
+if (incl) {
+uint8_t bypass_term_threshold = 0;
+uint8_t bits_to_read = 0;
+uint32_t segment_bytes = 0;
+int32_t segment_passes = 0;
+uint8_t next_segment_passes = 0;
+int32_t href_passes, pass_bound;
+uint32_t tmp_length = 0;
+int32_t newpasses_copy, npasse
Re: [FFmpeg-devel] [PATCH v4 1/3] avcodec/jpeg2000dec: Add support for CAP and CPF markers
I found that the subject for this v5 set of patches was wrong. I have posted the v6 with the correction. > On Aug 1, 2024, at 10:58, WATANABE Osamu > wrote: > > According to the suggestions for v4, I have posted the patch set v5. > > It is confirmed that the decoder with v5 passes all the conformance testing > defined in ISO/IEC 15444-4. > > Best, > Osamu > > >> On Jul 31, 2024, at 6:39, Michael Niedermayer wrote: >> >> On Tue, Jul 30, 2024 at 10:22:37PM +0200, Tomas Hardin wrote: >>> fre 2024-07-26 klockan 23:29 +0200 skrev Michael Niedermayer: On Thu, Jul 25, 2024 at 05:06:04PM -0700, Pierre-Anthony Lemieux wrote: > On Thu, Jul 25, 2024 at 2:17?AM Tomas Hardin > wrote: >> >> son 2024-07-21 klockan 14:07 +0900 skrev Pierre-Anthony Lemieux: >>> On Sat, Jul 20, 2024 at 5:12?PM Tomas Hardin >>> wrote: tor 2024-07-18 klockan 23:10 +0900 skrev Pierre-Anthony Lemieux: > On Mon, Jul 15, 2024 at 10:33?PM Tomas Hardin > > wrote: >> >> fre 2024-07-12 klockan 12:51 -0700 skrev Pierre-Anthony >> Lemieux: >>> On Thu, Jul 11, 2024 at 10:28?PM Tomas Hardin >>> >>> wrote: > +if (s->in_tile_headers == 1 && s->isHT > && > (!s- >> Ccap15_b11)) > +av_log(s->avctx, AV_LOG_WARNING, > "COD > marker > is > found in HOMOGENEOUS HT set\n"); How bad is this and the other markers being present in this case? >>> >>> At the very least, it means that signaling is >>> inconsistent >>> within >>> the >>> codestream since the standard states that: >>> """ >>> The HOMOGENEOUS set is the set of HTJ2K codestreams >>> where: >>> ? none of the functional marker segments, e.g., COD, >>> COC, >>> RGN, >>> QCD, >>> QCC, and POC, are present in any >>> tile-part header; and >>> ? no PPT marker segment is present. >>> """ >>> >>> The point of signalling that a codestream is >>> "HOMOGENEOUS" is >>> to >>> allow >>> decoders to configure themselves solely based on >>> information >>> retrieved >>> entirely from the main header. >>> >>> Since, AFAIK, FFMPEG does not rely on the HOMOGENEOUS >>> to >>> short- >>> circuit >>> configuration, incorrect HOMOGENEOUS signalling will >>> likely >>> not >>> impact >>> FFMPEG. >> >> It could happen that information in tile headers >> contradict >> information >> in the main header, right? In such a case it sounds like >> we >> can't >> be >> sure which decode is the correct one. > > Per the spec, the decoder uses the COD information in tile- > parts > over > the COD information in the header. > > The issue here is that a decoder, upon seeing HOMOGENEOUS, > simply > does > not bother with looking for COD information in tile-parts, > thereby > missing critical information. So it is actually perfectly legal? Then it seems this patch is wrong >>> >>> What is not "illegal": the HOMOGENEOUS flag being equal to true >>> *and* >>> having COD marker segments in tile-parts. >>> >>> This is what the patch detects. >>> >>> FFMPEG can decode such illegal codestream. Other decoders might >>> not. >>> >>> The question is: what should FFMPEG do? Should FFMPEG exit or >>> warn >>> and continue. >> >> If the spec allows it but it's perhaps unadviced then warning >> about it >> seems reasonable > > (I totally messed up my double negative. Repeat below. Sorry for > the confusion.) > > What is "illegal": the HOMOGENEOUS flag being equal to true *and* > having COD marker segments in tile-parts. > > This is what the patch detects. > > FFMPEG can decode such illegal codestream. Other decoders might > not. > > The question is: what should FFMPEG do? Should FFMPEG exit or warn > and continue. Does such a codestream actually exist ? I mean is this just a hypothetical case or something existing ? >>> >>> This is more to stem the stream before anything happens because we were >>> lax with parsing >> >> If such files dont exist then being picky makes sense >> >> thx >> >> [...] >> -- >> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB >> >> You can kill me, but you cannot change the truth. >> __
Re: [FFmpeg-devel] [PATCH v2] libavformat/tls_mbedtls: Changes the return code handling of mbedtls_x509_crt_parse_file
Hi, good day, I think something is wrong with this v2 patch, it is showing as corrupt in the patchwork system. See here: https://patchwork.ffmpeg.org/project/ffmpeg/patch/69b8a7a5-3826-4aef-88e1-2984d61a5...@skybound.link/ By chance did you modify the .patch file directly? ___ 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".
