Re: [FFmpeg-devel] [PATCH 07/11] doc/examples/vaapi_encode: Try to check fwrite() for failure

[Rémi Denis-Courmont]

Le 1 juillet 2024 02:12:46 GMT+03:00, Michael Niedermayer 
 a écrit :
>Fixes: CID1604548 Unused value
>
>Sponsored-by: Sovereign Tech Fund
>Signed-off-by: Michael Niedermayer 
>---
> doc/examples/vaapi_encode.c | 4 
> 1 file changed, 4 insertions(+)
>
>diff --git a/doc/examples/vaapi_encode.c b/doc/examples/vaapi_encode.c
>index d5f472f6dd8..805db7e5fd8 100644
>--- a/doc/examples/vaapi_encode.c
>+++ b/doc/examples/vaapi_encode.c
>@@ -88,6 +88,10 @@ static int encode_write(AVCodecContext *avctx, AVFrame 
>*frame, FILE *fout)
> enc_pkt->stream_index = 0;
> ret = fwrite(enc_pkt->data, enc_pkt->size, 1, fout);
> av_packet_unref(enc_pkt);
>+if (ret != enc_pkt->size) {
>+ret = AVERROR(EIO);

Err, shouldn't that pass errno rather than blindly (and wrongly) assume that 
it's EIO? What if the error is ENOSPC?

>+break;
>+}
> }
> 
> end:
___
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/vaapi_{decode, av1}: Fix memory leak in fail codepath

[fei . w . wang-at-intel . com]

From: Fei Wang 

Signed-off-by: Fei Wang 
---
 libavcodec/vaapi_av1.c| 9 +
 libavcodec/vaapi_decode.c | 5 +++--
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/libavcodec/vaapi_av1.c b/libavcodec/vaapi_av1.c
index fe0852318d..5451b6055b 100644
--- a/libavcodec/vaapi_av1.c
+++ b/libavcodec/vaapi_av1.c
@@ -404,14 +404,15 @@ static int vaapi_av1_decode_slice(AVCodecContext *avctx,
 
 nb_params = s->tg_end - s->tg_start + 1;
 if (ctx->nb_slice_params < nb_params) {
-ctx->slice_params = av_realloc_array(ctx->slice_params,
- nb_params,
- sizeof(*ctx->slice_params));
-if (!ctx->slice_params) {
+VASliceParameterBufferAV1 *tmp = av_realloc_array(ctx->slice_params,
+  nb_params,
+  
sizeof(*ctx->slice_params));
+if (!tmp) {
 ctx->nb_slice_params = 0;
 err = AVERROR(ENOMEM);
 goto fail;
 }
+ctx->slice_params= tmp;
 ctx->nb_slice_params = nb_params;
 }
 
diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
index 7c91d50f7b..a59194340f 100644
--- a/libavcodec/vaapi_decode.c
+++ b/libavcodec/vaapi_decode.c
@@ -74,13 +74,14 @@ int ff_vaapi_decode_make_slice_buffer(AVCodecContext *avctx,
 
 av_assert0(pic->nb_slices <= pic->slices_allocated);
 if (pic->nb_slices == pic->slices_allocated) {
-pic->slice_buffers =
+VABufferID *tmp =
 av_realloc_array(pic->slice_buffers,
  pic->slices_allocated ? pic->slices_allocated * 2 
: 64,
  2 * sizeof(*pic->slice_buffers));
-if (!pic->slice_buffers)
+if (!tmp)
 return AVERROR(ENOMEM);
 
+pic->slice_buffers= tmp;
 pic->slices_allocated = pic->slices_allocated ? pic->slices_allocated 
* 2 : 64;
 }
 av_assert0(pic->nb_slices + 1 <= pic->slices_allocated);
-- 
2.34.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avcodec/decode: use avcodec_get_hw_config()

[Anton Khirnov]

Quoting Kacper Michajłow (2024-06-02 03:38:18)
> Fixes libavcodec/decode.c:1035:61: runtime error: member access within
> null pointer of type 'const struct AVCodecHWConfigInternal'.
> 
> This can happen when hwaccel fails to initialize and hw_configs[i] is
> NULL.

How? All this should be runtime-constant.

-- 
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 v2] avcodec/mpegvideo_enc: Add check for av_packet_new_side_data()

[Anton Khirnov]

Quoting Jiasheng Jiang (2024-06-10 16:18:11)
> Add check for av_packet_new_side_data() to avoid null pointer
> dereference if allocation fails.
> 
> Fixes: bdc1220eeb ("h263enc: Add an option for outputting info about MBs as 
> side data")
> Signed-off-by: Jiasheng Jiang 
> ---
> Changelog:
> 
> v1 -> v2: Wrap lines in the body of the commit message.
> ---
>  libavcodec/mpegvideo_enc.c | 2 ++
>  1 file changed, 2 insertions(+)

Looks ok, will push soonish.

-- 
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/11] MAINTAINERS: Add Timo Rothenpieler to server admins

[Anton Khirnov]

Quoting Michael Niedermayer (2024-07-01 01:12:40)
> Signed-off-by: Michael Niedermayer 
> ---
>  MAINTAINERS | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a82fa58c69f..57f437cd40e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -34,8 +34,8 @@ Miscellaneous Areas
>  ===
>  
>  documentation   Stefano Sabatini, Mike Melanson, 
> Timothy Gu, Gyan Doshi
> -project server day to day operationsÁrpád Gereöffy, Michael Niedermayer, 
> Reimar Doeffinger, Alexander Strasser, Nikolay Aleksandrov
> -project server emergencies  Árpád Gereöffy, Reimar Doeffinger, 
> Alexander Strasser, Nikolay Aleksandrov
> +project server day to day operationsÁrpád Gereöffy, Michael Niedermayer, 
> Reimar Doeffinger, Alexander Strasser, Nikolay Aleksandrov, Timo Rothenpieler
> +project server emergencies  Árpád Gereöffy, Reimar Doeffinger, 
> Alexander Strasser, Nikolay Aleksandrov, Timo Rothenpieler

Those lists are getting rather long. Are all these people really active?
If not, the lists should be trimmed down.

-- 
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 08/11] fftools/ffmpeg: Check read() for failure

[Anton Khirnov]

Quoting Michael Niedermayer (2024-07-01 01:12:47)
> Fixes: CID1591932 Ignoring number of bytes read
> Untested, this needs a windows machine
> 
> Sponsored-by: Sovereign Tech Fund
> Signed-off-by: Michael Niedermayer 
> ---
>  fftools/ffmpeg.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)

Looks ok.

-- 
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 v2 2/4] avfilter/af_volumedetect.c: Added functions for int/float and planar/packed

[Anton Khirnov]

Quoting Yigithan Yigit (2024-06-28 22:15:21)
> ---
>  libavfilter/af_volumedetect.c | 58 +++
>  1 file changed, 58 insertions(+)
> 
> diff --git a/libavfilter/af_volumedetect.c b/libavfilter/af_volumedetect.c
> index 327801a7f9..61c00e0248 100644
> --- a/libavfilter/af_volumedetect.c
> +++ b/libavfilter/af_volumedetect.c
> @@ -43,6 +43,64 @@ static inline double logdb(uint64_t v)
>  return -log10(d) * 10;
>  }
>  
> +static void process_float_planar_samples(VolDetectContext *vd, AVFrame 
> *samples)
> +{
> +int plane, i;
> +int nb_channels = samples->ch_layout.nb_channels;
> +int nb_samples  = samples->nb_samples;
> +float *audio_data;
> +for (plane = 0; plane < nb_channels; plane++) {
> +audio_data = (float *)samples->extended_data[plane];
> +for (i = 0; i < nb_samples; i++) {
> +update_float_stats(vd, &audio_data[i]);
> +}
> +}
> +}
> +
> +static void process_float_packed_samples(VolDetectContext *vd, AVFrame 
> *samples)
> +{
> +int i, j;
> +int nb_channels = samples->ch_layout.nb_channels;
> +int nb_samples  = samples->nb_samples;
> +float *audio_data;
> +for (i = 0; i < nb_samples; i++) {
> +audio_data = (float *)samples->extended_data[0];
> +for (j = 0; j < nb_channels; j++) {
> +   update_float_stats(vd, &audio_data[i * nb_channels + j]);
> +}
> +}
> +}
> +
> +static void process_int_planar_samples(VolDetectContext *vd, AVFrame 
> *samples)
> +{
> +int plane, i;
> +int nb_channels = samples->ch_layout.nb_channels;
> +int nb_samples  = samples->nb_samples;
> +int16_t *pcm;
> +for (plane = 0; plane < nb_channels; plane++) {
> +pcm = (int16_t *)samples->extended_data[plane];
> +for (i = 0; i < nb_samples; i++) {
> +vd->histogram[pcm[i] + 0x8000]++;
> +vd->nb_samples++;
> +}
> +}
> +}
> +
> +static void process_int_packed_samples(VolDetectContext *vd, AVFrame 
> *samples)
> +{
> +int i, j;
> +int nb_channels = samples->ch_layout.nb_channels;
> +int nb_samples  = samples->nb_samples;
> +int16_t *pcm;
> +for (i = 0; i < nb_samples; i++) {
> +pcm = (int16_t *)samples->extended_data[0];
> +for (j = 0; j < nb_channels; j++) {
> +vd->histogram[pcm[i * nb_channels + j] + 0x8000]++;
> +vd->nb_samples++;
> +}
> +}
> +}

This looks in need of some templating.

-- 
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 v2] libswscale/x86/yuv2rgb: Add missing EMMS

[Ramiro Polla]

On Wed, Jun 26, 2024 at 8:55 PM Ramiro Polla  wrote:
> On Wed, Jun 26, 2024 at 8:03 PM Mario Hros  wrote:
> > Previous rewrite from inline assembly into nasm (commit e934194) missed the 
> > required EMMS instruction to bring the x87 FPU back into usable state.
> > This needs to be done for 8-byte MMX or Extended MMX only.
>
> Sorry I didn't catch this thread earlier. I sent a patch to outright
> remove the mmx/mmxext code (thread "swscale/yuv2rgb/x86: remove
> mmx/mmxext yuv2rgb functions"):
> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2024-June/329785.html
>
> The C code should be faster in most cases, or have very similar
> performance to the mmx/mmxext code. Is this not the case for you?

Mario, ping? If there are no more comments I'll go ahead and push the
patch that removes mmx/mmxext.
___
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 01/13] avcodec/h261enc: Use LUT to write motion vector differences

[Andreas Rheinhardt]

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/h261enc.c | 33 +++--
 1 file changed, 19 insertions(+), 14 deletions(-)

diff --git a/libavcodec/h261enc.c b/libavcodec/h261enc.c
index a901c32e42..d3d724bef6 100644
--- a/libavcodec/h261enc.c
+++ b/libavcodec/h261enc.c
@@ -39,6 +39,7 @@
 #define H261_MAX_RUN   26
 #define H261_MAX_LEVEL 15
 #define H261_ESC_LEN   (6 + 6 + 8)
+#define MV_TAB_OFFSET  32
 
 static struct VLCLUT {
 uint8_t len;
@@ -47,6 +48,7 @@ static struct VLCLUT {
 
 static uint8_t uni_h261_rl_len [64 * 128];
 static uint8_t uni_h261_rl_len_last[64 * 128];
+static uint8_t h261_mv_codes[64][2];
 
 typedef struct H261EncContext {
 MpegEncContext s;
@@ -140,20 +142,8 @@ void ff_h261_reorder_mb_index(MpegEncContext *s)
 
 static void h261_encode_motion(PutBitContext *pb, int val)
 {
-int sign, code;
-if (val == 0) {
-// Corresponds to ff_h261_mv_tab[0]
-put_bits(pb, 1, 1);
-} else {
-if (val > 15)
-val -= 32;
-if (val < -16)
-val += 32;
-sign = val < 0;
-code = sign ? -val : val;
-put_bits(pb, ff_h261_mv_tab[code][1], ff_h261_mv_tab[code][0]);
-put_bits(pb, 1, sign);
-}
+put_bits(pb, h261_mv_codes[MV_TAB_OFFSET + val][1],
+ h261_mv_codes[MV_TAB_OFFSET + val][0]);
 }
 
 static inline int get_cbp(MpegEncContext *s, int16_t block[6][64])
@@ -323,6 +313,7 @@ void ff_h261_encode_mb(MpegEncContext *s, int16_t 
block[6][64],
 
 static av_cold void h261_encode_init_static(void)
 {
+uint8_t (*const mv_codes)[2] = h261_mv_codes + MV_TAB_OFFSET;
 memset(uni_h261_rl_len,  H261_ESC_LEN, sizeof(uni_h261_rl_len));
 memset(uni_h261_rl_len_last, H261_ESC_LEN + 2 /* EOB */, 
sizeof(uni_h261_rl_len_last));
 
@@ -341,6 +332,20 @@ static av_cold void h261_encode_init_static(void)
 uni_h261_rl_len_last[UNI_AC_ENC_INDEX(run, 64 + level)] = len + 2;
 uni_h261_rl_len_last[UNI_AC_ENC_INDEX(run, 64 - level)] = len + 2;
 }
+
+for (size_t i = 1;; i++) {
+// sign-one MV codes; diff -16..-1, 16..31
+mv_codes[32 - i][0] = mv_codes[-i][0] = (ff_h261_mv_tab[i][0] << 1) | 
1 /* sign */;
+mv_codes[32 - i][1] = mv_codes[-i][1] = ff_h261_mv_tab[i][1] + 1;
+if (i == 16)
+break;
+// sign-zero MV codes: diff -31..-17, 1..15
+mv_codes[i][0] = mv_codes[i - 32][0] = ff_h261_mv_tab[i][0] << 1;
+mv_codes[i][1] = mv_codes[i - 32][1] = ff_h261_mv_tab[i][1] + 1;
+}
+// MV code for difference zero; has no sign
+mv_codes[0][0] = 1;
+mv_codes[0][1] = 1;
 }
 
 av_cold int ff_h261_encode_init(MpegEncContext *s)
-- 
2.40.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH 02/13] avcodec/mpeg12dec: Move resetting last_dc to decoder

[Andreas Rheinhardt]

Only the MPEG-1/2, MSMPEG4V1, MPEG-4 and RV.10 decoders use last_dc
at all. Of these, RV.10 only uses it for intra frames; it does not
need these predictors reset in ff_mpv_reconstruct_mb(). MSMPEG4V1
has h263_pred set, so that last_dc is already not reset in
ff_mpv_reconstruct_mb() (instead it is reset at the beginning
of every line). MPEG-4 also has h263_pred set (and uses last_dc only
for the intra-only studio profile and needs them reset to sligthly
different values anyway).

So only the MPEG-1/2 decoders need these values reset. So move
resetting them there. This avoids resetting them unnecessarily
for FLV1, H.261, H.263I, RV.10, RV.20 and H.263(+)
(for the latter it depends upon whether h263_aic is in use).

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpeg12dec.c   | 2 ++
 libavcodec/mpv_reconstruct_mb_template.c | 2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index bb0a769e49..a15318e1bc 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -712,6 +712,7 @@ static int mpeg_decode_mb(MpegEncContext *s, int16_t 
block[12][64])
 }
 
 s->mb_intra = 0;
+s->last_dc[0] = s->last_dc[1] = s->last_dc[2] = 128 << 
s->intra_dc_precision;
 if (HAS_CBP(mb_type)) {
 s->bdsp.clear_blocks(s->block[0]);
 
@@ -1630,6 +1631,7 @@ static int mpeg_decode_slice(MpegEncContext *s, int mb_y,
 s->mb_intra = 0;
 for (i = 0; i < 12; i++)
 s->block_last_index[i] = -1;
+s->last_dc[0] = s->last_dc[1] = s->last_dc[2] = 128 << 
s->intra_dc_precision;
 if (s->picture_structure == PICT_FRAME)
 s->mv_type = MV_TYPE_16X16;
 else
diff --git a/libavcodec/mpv_reconstruct_mb_template.c 
b/libavcodec/mpv_reconstruct_mb_template.c
index dca982ae0f..4db85afef6 100644
--- a/libavcodec/mpv_reconstruct_mb_template.c
+++ b/libavcodec/mpv_reconstruct_mb_template.c
@@ -66,7 +66,7 @@ void mpv_reconstruct_mb_internal(MpegEncContext *s, int16_t 
block[12][64],
 if (is_mpeg12 != DEFINITELY_MPEG12_H261 && (s->h263_pred || 
s->h263_aic)) {
 if (s->mbintra_table[mb_xy])
 ff_clean_intra_table_entries(s);
-} else {
+} else if (IS_ENCODER) {
 s->last_dc[0] =
 s->last_dc[1] =
 s->last_dc[2] = 128 << s->intra_dc_precision;
-- 
2.40.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH 03/13] avcodec/mpeg12enc: Move resetting last_dc to encoder

[Andreas Rheinhardt]

The MPEG-1/2 encoders are the only non-intra-only mpegvideo
encoders that want last_dc reset when encoding non-intra macroblocks.
Therefore move resetting it to mpeg12enc.c.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpeg12enc.c   | 2 ++
 libavcodec/mpv_reconstruct_mb_template.c | 4 
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/libavcodec/mpeg12enc.c b/libavcodec/mpeg12enc.c
index e35c916b61..72b2caab7e 100644
--- a/libavcodec/mpeg12enc.c
+++ b/libavcodec/mpeg12enc.c
@@ -1067,6 +1067,8 @@ static av_always_inline void 
mpeg1_encode_mb_internal(MpegEncContext *s,
 void ff_mpeg1_encode_mb(MpegEncContext *s, int16_t block[8][64],
 int motion_x, int motion_y)
 {
+if (!s->mb_intra)
+s->last_dc[0] = s->last_dc[1] = s->last_dc[2] = 128 << 
s->intra_dc_precision;
 if (s->chroma_format == CHROMA_420)
 mpeg1_encode_mb_internal(s, block, motion_x, motion_y, 6, 1);
 else
diff --git a/libavcodec/mpv_reconstruct_mb_template.c 
b/libavcodec/mpv_reconstruct_mb_template.c
index 4db85afef6..f1cb0d7989 100644
--- a/libavcodec/mpv_reconstruct_mb_template.c
+++ b/libavcodec/mpv_reconstruct_mb_template.c
@@ -66,10 +66,6 @@ void mpv_reconstruct_mb_internal(MpegEncContext *s, int16_t 
block[12][64],
 if (is_mpeg12 != DEFINITELY_MPEG12_H261 && (s->h263_pred || 
s->h263_aic)) {
 if (s->mbintra_table[mb_xy])
 ff_clean_intra_table_entries(s);
-} else if (IS_ENCODER) {
-s->last_dc[0] =
-s->last_dc[1] =
-s->last_dc[2] = 128 << s->intra_dc_precision;
 }
 } else if (is_mpeg12 != DEFINITELY_MPEG12_H261 && (s->h263_pred || 
s->h263_aic))
 s->mbintra_table[mb_xy] = 1;
-- 
2.40.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH 04/13] avcodec/h263dec: Clean intra tables in decoder, not ff_mpv_reconstruct_mb

[Andreas Rheinhardt]

This is a more appropriate place than a function designed
to reconstruct a macroblock. It furthermore limits these checks
to the codecs that actually need it (and removes it from e.g.
RV10 and RV20 -- the latter actually uses these buffers, but
only for intra-frames, so they don't need to be cleaned
manually).

This furthermore means that ff_mpv_reconstruct_mb() and therefore
also the error-resilience code no longer needs block_index set.
This fixes a crash caused by 65d5ccb808ec93de46a2458ea8cc082ce4460f34
when ff_mpv_reconstruct_mb() is called by VC-1 code without
block_index being initialized properly (VC-1 uses and initializes
block_index itself normally).

Fixes: 
69814/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VC1_fuzzer-4868081575329792
Fixes: heap-buffer-overflow

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/h263dec.c | 9 +
 libavcodec/mpv_reconstruct_mb_template.c | 2 +-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
index 0c23012584..3e9da23d3a 100644
--- a/libavcodec/h263dec.c
+++ b/libavcodec/h263dec.c
@@ -271,6 +271,15 @@ static int decode_slice(MpegEncContext *s)
 ff_tlog(NULL, "Decoding MB at %dx%d\n", s->mb_x, s->mb_y);
 ret = s->decode_mb(s, s->block);
 
+if (s->h263_pred || s->h263_aic) {
+int mb_xy = s->mb_y * s->mb_stride + s->mb_x;
+if (!s->mb_intra) {
+if (s->mbintra_table[mb_xy])
+ff_clean_intra_table_entries(s);
+} else
+s->mbintra_table[mb_xy] = 1;
+}
+
 if (s->pict_type != AV_PICTURE_TYPE_B)
 ff_h263_update_motion_val(s);
 
diff --git a/libavcodec/mpv_reconstruct_mb_template.c 
b/libavcodec/mpv_reconstruct_mb_template.c
index f1cb0d7989..981c837642 100644
--- a/libavcodec/mpv_reconstruct_mb_template.c
+++ b/libavcodec/mpv_reconstruct_mb_template.c
@@ -61,6 +61,7 @@ void mpv_reconstruct_mb_internal(MpegEncContext *s, int16_t 
block[12][64],
 
 s->cur_pic.qscale_table[mb_xy] = s->qscale;
 
+#if IS_ENCODER
 /* update DC predictors for P macroblocks */
 if (!s->mb_intra) {
 if (is_mpeg12 != DEFINITELY_MPEG12_H261 && (s->h263_pred || 
s->h263_aic)) {
@@ -70,7 +71,6 @@ void mpv_reconstruct_mb_internal(MpegEncContext *s, int16_t 
block[12][64],
 } else if (is_mpeg12 != DEFINITELY_MPEG12_H261 && (s->h263_pred || 
s->h263_aic))
 s->mbintra_table[mb_xy] = 1;
 
-#if IS_ENCODER
 if ((s->avctx->flags & AV_CODEC_FLAG_PSNR) || s->frame_skip_threshold || 
s->frame_skip_factor ||
 !((s->intra_only || s->pict_type == AV_PICTURE_TYPE_B) &&
   s->avctx->mb_decision != FF_MB_DECISION_RD))  // FIXME precalc
-- 
2.40.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH 05/13] avcodec/mpegvideo_enc: Don't reset intra buffers in mpv_reconstruct_mb()

[Andreas Rheinhardt]

It is not part of reconstructing the macroblock.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpegvideo_enc.c   | 11 ---
 libavcodec/mpv_reconstruct_mb_template.c |  9 -
 2 files changed, 4 insertions(+), 16 deletions(-)

diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index 620ca08869..31c5dd4736 100644
--- a/libavcodec/mpegvideo_enc.c
+++ b/libavcodec/mpegvideo_enc.c
@@ -3188,12 +3188,7 @@ static int encode_thread(AVCodecContext *c, void *arg){
 s->mv[0][0][1] = 0;
 encode_mb_hq(s, &backup_s, &best_s, pb, pb2, tex_pb,
  &dmin, &next_block, 0, 0);
-if(s->h263_pred || s->h263_aic){
-if(best_s.mb_intra)
-s->mbintra_table[mb_x + mb_y*s->mb_stride]=1;
-else
-ff_clean_intra_table_entries(s); //old mode?
-}
+s->mbintra_table[xy] = 1;
 }
 
 if ((s->mpv_flags & FF_MPV_FLAG_QP_RD) && dmin < INT_MAX) {
@@ -3340,6 +3335,7 @@ static int encode_thread(AVCodecContext *c, void *arg){
 s->mb_intra= 1;
 motion_x= s->mv[0][0][0] = 0;
 motion_y= s->mv[0][0][1] = 0;
+s->mbintra_table[xy] = 1;
 break;
 case CANDIDATE_MB_TYPE_INTER:
 s->mv_dir = MV_DIR_FORWARD;
@@ -3454,7 +3450,8 @@ static int encode_thread(AVCodecContext *c, void *arg){
 if(s->mb_intra /* && I,P,S_TYPE */){
 s->p_mv_table[xy][0]=0;
 s->p_mv_table[xy][1]=0;
-}
+} else if ((s->h263_pred || s->h263_aic) && s->mbintra_table[xy])
+ff_clean_intra_table_entries(s);
 
 if (s->avctx->flags & AV_CODEC_FLAG_PSNR) {
 int w= 16;
diff --git a/libavcodec/mpv_reconstruct_mb_template.c 
b/libavcodec/mpv_reconstruct_mb_template.c
index 981c837642..ae7a9e34ce 100644
--- a/libavcodec/mpv_reconstruct_mb_template.c
+++ b/libavcodec/mpv_reconstruct_mb_template.c
@@ -62,15 +62,6 @@ void mpv_reconstruct_mb_internal(MpegEncContext *s, int16_t 
block[12][64],
 s->cur_pic.qscale_table[mb_xy] = s->qscale;
 
 #if IS_ENCODER
-/* update DC predictors for P macroblocks */
-if (!s->mb_intra) {
-if (is_mpeg12 != DEFINITELY_MPEG12_H261 && (s->h263_pred || 
s->h263_aic)) {
-if (s->mbintra_table[mb_xy])
-ff_clean_intra_table_entries(s);
-}
-} else if (is_mpeg12 != DEFINITELY_MPEG12_H261 && (s->h263_pred || 
s->h263_aic))
-s->mbintra_table[mb_xy] = 1;
-
 if ((s->avctx->flags & AV_CODEC_FLAG_PSNR) || s->frame_skip_threshold || 
s->frame_skip_factor ||
 !((s->intra_only || s->pict_type == AV_PICTURE_TYPE_B) &&
   s->avctx->mb_decision != FF_MB_DECISION_RD))  // FIXME precalc
-- 
2.40.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH 06/13] avcodec/mpv_reconstruct_mb_template: Merge template into its users

[Andreas Rheinhardt]

A large part of this template is decoder-only. This makes
the complexity of the IS_ENCODER-checks not worth it.
So simply merge the template into both its users.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpegvideo_dec.c   | 218 +-
 libavcodec/mpegvideo_enc.c   |  81 ++-
 libavcodec/mpv_reconstruct_mb_template.c | 272 ---
 3 files changed, 294 insertions(+), 277 deletions(-)
 delete mode 100644 libavcodec/mpv_reconstruct_mb_template.c

diff --git a/libavcodec/mpegvideo_dec.c b/libavcodec/mpegvideo_dec.c
index 1cab108935..d50283 100644
--- a/libavcodec/mpegvideo_dec.c
+++ b/libavcodec/mpegvideo_dec.c
@@ -904,11 +904,225 @@ static inline void add_dct(MpegEncContext *s,
 }
 }
 
-#define IS_ENCODER 0
-#include "mpv_reconstruct_mb_template.c"
+/* put block[] to dest[] */
+static inline void put_dct(MpegEncContext *s,
+   int16_t *block, int i, uint8_t *dest, int 
line_size, int qscale)
+{
+s->dct_unquantize_intra(s, block, i, qscale);
+s->idsp.idct_put(dest, line_size, block);
+}
+
+static inline void add_dequant_dct(MpegEncContext *s,
+   int16_t *block, int i, uint8_t *dest, int 
line_size, int qscale)
+{
+if (s->block_last_index[i] >= 0) {
+s->dct_unquantize_inter(s, block, i, qscale);
+
+s->idsp.idct_add(dest, line_size, block);
+}
+}
+
+#define NOT_MPEG12_H2610
+#define MAY_BE_MPEG12_H261 1
+#define DEFINITELY_MPEG12_H261 2
+
+/* generic function called after a macroblock has been parsed by the decoder.
+
+   Important variables used:
+   s->mb_intra : true if intra macroblock
+   s->mv_dir   : motion vector direction
+   s->mv_type  : motion vector type
+   s->mv   : motion vector
+   s->interlaced_dct : true if interlaced dct used (mpeg2)
+ */
+static av_always_inline
+void mpv_reconstruct_mb_internal(MpegEncContext *s, int16_t block[12][64],
+ int lowres_flag, int is_mpeg12)
+{
+#define IS_MPEG12_H261(s) (is_mpeg12 == MAY_BE_MPEG12_H261 ? ((s)->out_format 
<= FMT_H261) : is_mpeg12)
+{
+uint8_t *dest_y = s->dest[0], *dest_cb = s->dest[1], *dest_cr = 
s->dest[2];
+int dct_linesize, dct_offset;
+const int linesize   = s->cur_pic.linesize[0]; //not s->linesize as 
this would be wrong for field pics
+const int uvlinesize = s->cur_pic.linesize[1];
+const int block_size = lowres_flag ? 8 >> s->avctx->lowres : 8;
+
+dct_linesize = linesize << s->interlaced_dct;
+dct_offset   = s->interlaced_dct ? linesize : linesize * block_size;
+
+if (!s->mb_intra) {
+/* motion handling */
+if (HAVE_THREADS && is_mpeg12 != DEFINITELY_MPEG12_H261 &&
+s->avctx->active_thread_type & FF_THREAD_FRAME) {
+if (s->mv_dir & MV_DIR_FORWARD) {
+ff_thread_progress_await(&s->last_pic.ptr->progress,
+ lowest_referenced_row(s, 0));
+}
+if (s->mv_dir & MV_DIR_BACKWARD) {
+ff_thread_progress_await(&s->next_pic.ptr->progress,
+ lowest_referenced_row(s, 1));
+}
+}
+
+if (lowres_flag) {
+const h264_chroma_mc_func *op_pix = 
s->h264chroma.put_h264_chroma_pixels_tab;
+
+if (s->mv_dir & MV_DIR_FORWARD) {
+MPV_motion_lowres(s, dest_y, dest_cb, dest_cr, 0, 
s->last_pic.data, op_pix);
+op_pix = s->h264chroma.avg_h264_chroma_pixels_tab;
+}
+if (s->mv_dir & MV_DIR_BACKWARD) {
+MPV_motion_lowres(s, dest_y, dest_cb, dest_cr, 1, 
s->next_pic.data, op_pix);
+}
+} else {
+const op_pixels_func (*op_pix)[4];
+const qpel_mc_func (*op_qpix)[16];
+
+if ((is_mpeg12 == DEFINITELY_MPEG12_H261 || !s->no_rounding) 
|| s->pict_type == AV_PICTURE_TYPE_B) {
+op_pix = s->hdsp.put_pixels_tab;
+op_qpix = s->qdsp.put_qpel_pixels_tab;
+} else {
+op_pix = s->hdsp.put_no_rnd_pixels_tab;
+op_qpix = s->qdsp.put_no_rnd_qpel_pixels_tab;
+}
+if (s->mv_dir & MV_DIR_FORWARD) {
+ff_mpv_motion(s, dest_y, dest_cb, dest_cr, 0, 
s->last_pic.data, op_pix, op_qpix);
+op_pix  = s->hdsp.avg_pixels_tab;
+op_qpix = s->qdsp.avg_qpel_pixels_tab;
+}
+if (s->mv_dir & MV_DIR_BACKWARD) {
+ff_mpv_motion(s, dest_y, dest_cb, dest_cr, 1, 
s->next_pic.data, op_pix, op_qpix);
+}
+}
+
+/* skip dequant / idct if we are really late ;) */
+if (s->avctx->skip_idct) {
+if(  (s->avctx->skip_id

[FFmpeg-devel] [PATCH 07/13] avcodec/mpegvideo_{dec, enc}: Reindent after the previous commit

[Andreas Rheinhardt]

Signed-off-by: Andreas Rheinhardt 
---
Could be squashed into the preceding commit.

 libavcodec/mpegvideo_dec.c | 318 ++---
 libavcodec/mpegvideo_enc.c |  70 
 2 files changed, 193 insertions(+), 195 deletions(-)

diff --git a/libavcodec/mpegvideo_dec.c b/libavcodec/mpegvideo_dec.c
index d50283..78fa10c11d 100644
--- a/libavcodec/mpegvideo_dec.c
+++ b/libavcodec/mpegvideo_dec.c
@@ -940,167 +940,165 @@ void mpv_reconstruct_mb_internal(MpegEncContext *s, 
int16_t block[12][64],
  int lowres_flag, int is_mpeg12)
 {
 #define IS_MPEG12_H261(s) (is_mpeg12 == MAY_BE_MPEG12_H261 ? ((s)->out_format 
<= FMT_H261) : is_mpeg12)
-{
-uint8_t *dest_y = s->dest[0], *dest_cb = s->dest[1], *dest_cr = 
s->dest[2];
-int dct_linesize, dct_offset;
-const int linesize   = s->cur_pic.linesize[0]; //not s->linesize as 
this would be wrong for field pics
-const int uvlinesize = s->cur_pic.linesize[1];
-const int block_size = lowres_flag ? 8 >> s->avctx->lowres : 8;
-
-dct_linesize = linesize << s->interlaced_dct;
-dct_offset   = s->interlaced_dct ? linesize : linesize * block_size;
-
-if (!s->mb_intra) {
-/* motion handling */
-if (HAVE_THREADS && is_mpeg12 != DEFINITELY_MPEG12_H261 &&
-s->avctx->active_thread_type & FF_THREAD_FRAME) {
-if (s->mv_dir & MV_DIR_FORWARD) {
-ff_thread_progress_await(&s->last_pic.ptr->progress,
- lowest_referenced_row(s, 0));
-}
-if (s->mv_dir & MV_DIR_BACKWARD) {
-ff_thread_progress_await(&s->next_pic.ptr->progress,
- lowest_referenced_row(s, 1));
-}
+uint8_t *dest_y = s->dest[0], *dest_cb = s->dest[1], *dest_cr = s->dest[2];
+int dct_linesize, dct_offset;
+const int linesize   = s->cur_pic.linesize[0]; //not s->linesize as this 
would be wrong for field pics
+const int uvlinesize = s->cur_pic.linesize[1];
+const int block_size = lowres_flag ? 8 >> s->avctx->lowres : 8;
+
+dct_linesize = linesize << s->interlaced_dct;
+dct_offset   = s->interlaced_dct ? linesize : linesize * block_size;
+
+if (!s->mb_intra) {
+/* motion handling */
+if (HAVE_THREADS && is_mpeg12 != DEFINITELY_MPEG12_H261 &&
+s->avctx->active_thread_type & FF_THREAD_FRAME) {
+if (s->mv_dir & MV_DIR_FORWARD) {
+ff_thread_progress_await(&s->last_pic.ptr->progress,
+ lowest_referenced_row(s, 0));
+}
+if (s->mv_dir & MV_DIR_BACKWARD) {
+ff_thread_progress_await(&s->next_pic.ptr->progress,
+ lowest_referenced_row(s, 1));
 }
+}
 
-if (lowres_flag) {
-const h264_chroma_mc_func *op_pix = 
s->h264chroma.put_h264_chroma_pixels_tab;
+if (lowres_flag) {
+const h264_chroma_mc_func *op_pix = 
s->h264chroma.put_h264_chroma_pixels_tab;
 
-if (s->mv_dir & MV_DIR_FORWARD) {
-MPV_motion_lowres(s, dest_y, dest_cb, dest_cr, 0, 
s->last_pic.data, op_pix);
-op_pix = s->h264chroma.avg_h264_chroma_pixels_tab;
-}
-if (s->mv_dir & MV_DIR_BACKWARD) {
-MPV_motion_lowres(s, dest_y, dest_cb, dest_cr, 1, 
s->next_pic.data, op_pix);
-}
-} else {
-const op_pixels_func (*op_pix)[4];
-const qpel_mc_func (*op_qpix)[16];
-
-if ((is_mpeg12 == DEFINITELY_MPEG12_H261 || !s->no_rounding) 
|| s->pict_type == AV_PICTURE_TYPE_B) {
-op_pix = s->hdsp.put_pixels_tab;
-op_qpix = s->qdsp.put_qpel_pixels_tab;
-} else {
-op_pix = s->hdsp.put_no_rnd_pixels_tab;
-op_qpix = s->qdsp.put_no_rnd_qpel_pixels_tab;
-}
-if (s->mv_dir & MV_DIR_FORWARD) {
-ff_mpv_motion(s, dest_y, dest_cb, dest_cr, 0, 
s->last_pic.data, op_pix, op_qpix);
-op_pix  = s->hdsp.avg_pixels_tab;
-op_qpix = s->qdsp.avg_qpel_pixels_tab;
-}
-if (s->mv_dir & MV_DIR_BACKWARD) {
-ff_mpv_motion(s, dest_y, dest_cb, dest_cr, 1, 
s->next_pic.data, op_pix, op_qpix);
-}
+if (s->mv_dir & MV_DIR_FORWARD) {
+MPV_motion_lowres(s, dest_y, dest_cb, dest_cr, 0, 
s->last_pic.data, op_pix);
+op_pix = s->h264chroma.avg_h264_chroma_pixels_tab;
+}
+if (s->mv_dir & MV_DIR_BACKWARD) {
+MPV_motion_lowres(s, dest_y, dest_cb, dest_cr, 1, 
s->next_pic.data, op_pix);
 }
+} else {

[FFmpeg-devel] [PATCH 08/13] avcodec/mpegvideo_enc: Don't set qscale_table value prematurely

[Andreas Rheinhardt]

When there are multiple candidates for macroblock type, the encoder
tries them all. In order to do so, it copies the keeps several sets
of states containing the variables that get modified when encoding
the macroblock and in the end uses the best of these.

Yet one variable was set, but not included in this state:
The current macroblock's qscale value in the current picture's
qscale_table. This may currently be set multiple times in
mpv_reconstruct_mb(), yet it is read when adaptive_quant is true.
Currently, the value read can be the value set by the last attempt
to write the current macroblock and not the initial value.

Fix this by only setting the qscale_table value in one place
outside of mpv_reconstruct_mb() (where it does not belong at all).

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpegvideo_enc.c  |  8 ++-
 tests/ref/seek/vsynth_lena-mpeg4-adap   | 28 -
 tests/ref/vsynth/vsynth1-mpeg4-adap |  8 +++
 tests/ref/vsynth/vsynth2-mpeg4-adap |  8 +++
 tests/ref/vsynth/vsynth3-mpeg4-adap |  8 +++
 tests/ref/vsynth/vsynth_lena-mpeg4-adap |  8 +++
 6 files changed, 32 insertions(+), 36 deletions(-)

diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index 99e31be463..48d26f37cd 100644
--- a/libavcodec/mpegvideo_enc.c
+++ b/libavcodec/mpegvideo_enc.c
@@ -1105,10 +1105,6 @@ static inline void add_dequant_dct(MpegEncContext *s,
  */
 static void mpv_reconstruct_mb(MpegEncContext *s, int16_t block[12][64])
 {
-const int mb_xy = s->mb_y * s->mb_stride + s->mb_x;
-
-s->cur_pic.qscale_table[mb_xy] = s->qscale;
-
 if (s->avctx->debug & FF_DEBUG_DCT_COEFF) {
/* print DCT coefficients */
av_log(s->avctx, AV_LOG_DEBUG, "DCT coeffs of MB at %dx%d:\n", s->mb_x, 
s->mb_y);
@@ -3365,8 +3361,6 @@ static int encode_thread(AVCodecContext *c, void *arg){
 }
 }
 
-s->cur_pic.qscale_table[xy] = best_s.qscale;
-
 copy_context_after_encode(s, &best_s);
 
 pb_bits_count= put_bits_count(&s->pb);
@@ -3521,6 +3515,8 @@ static int encode_thread(AVCodecContext *c, void *arg){
 mpv_reconstruct_mb(s, s->block);
 }
 
+s->cur_pic.qscale_table[xy] = s->qscale;
+
 /* clean the MV table in IPS frames for direct mode in B-frames */
 if(s->mb_intra /* && I,P,S_TYPE */){
 s->p_mv_table[xy][0]=0;
diff --git a/tests/ref/seek/vsynth_lena-mpeg4-adap 
b/tests/ref/seek/vsynth_lena-mpeg4-adap
index fe841ef973..491651 100644
--- a/tests/ref/seek/vsynth_lena-mpeg4-adap
+++ b/tests/ref/seek/vsynth_lena-mpeg4-adap
@@ -2,45 +2,45 @@ ret: 0 st: 0 flags:1 dts: 0.00 pts: NOPTSpos: 
  5652 size:  6855
 ret: 0 st:-1 flags:0  ts:-1.00
 ret: 0 st: 0 flags:1 dts: 0.00 pts: NOPTSpos:   5652 size:  
6855
 ret: 0 st:-1 flags:1  ts: 1.894167
-ret: 0 st: 0 flags:1 dts: 1.84 pts: NOPTSpos: 161318 size: 
19176
+ret: 0 st: 0 flags:1 dts: 1.84 pts: NOPTSpos: 161352 size: 
19191
 ret: 0 st: 0 flags:0  ts: 0.80
-ret: 0 st: 0 flags:1 dts: 0.88 pts: NOPTSpos:  75056 size: 
19178
+ret: 0 st: 0 flags:1 dts: 0.88 pts: NOPTSpos:  75104 size: 
19178
 ret:-1 st: 0 flags:1  ts:-0.32
 ret:-1 st:-1 flags:0  ts: 2.576668
 ret: 0 st:-1 flags:1  ts: 1.470835
-ret: 0 st: 0 flags:1 dts: 1.36 pts: NOPTSpos: 118696 size: 
20018
+ret: 0 st: 0 flags:1 dts: 1.36 pts: NOPTSpos: 118586 size: 
20060
 ret: 0 st: 0 flags:0  ts: 0.36
-ret: 0 st: 0 flags:1 dts: 0.40 pts: NOPTSpos:  35800 size: 
17261
+ret: 0 st: 0 flags:1 dts: 0.40 pts: NOPTSpos:  35840 size: 
17261
 ret:-1 st: 0 flags:1  ts:-0.76
 ret:-1 st:-1 flags:0  ts: 2.153336
 ret: 0 st:-1 flags:1  ts: 1.047503
-ret: 0 st: 0 flags:1 dts: 0.88 pts: NOPTSpos:  75056 size: 
19178
+ret: 0 st: 0 flags:1 dts: 0.88 pts: NOPTSpos:  75104 size: 
19178
 ret: 0 st: 0 flags:0  ts:-0.04
 ret: 0 st: 0 flags:1 dts: 0.00 pts: NOPTSpos:   5652 size:  
6855
 ret: 0 st: 0 flags:1  ts: 2.84
-ret: 0 st: 0 flags:1 dts: 1.84 pts: NOPTSpos: 161318 size: 
19176
+ret: 0 st: 0 flags:1 dts: 1.84 pts: NOPTSpos: 161352 size: 
19191
 ret: 0 st:-1 flags:0  ts: 1.730004
-ret: 0 st: 0 flags:1 dts: 1.84 pts: NOPTSpos: 161318 size: 
19176
+ret: 0 st: 0 flags:1 dts: 1.84 pts: NOPTSpos: 161352 size: 
19191
 ret: 0 st:-1 flags:1  ts: 0.624171
-ret: 0 st: 0 flags:1 dts: 0.40 pts: NOPTSpos:  35800 size: 
17261
+ret: 0 st: 0 flags:1 dts: 0.40 pts: NOPTSpos:  35840 size: 
17261
 ret: 0 st: 0 flags:0  ts:-0.48
 ret: 0 st: 0 flags:1 dts: 0.00 pts

[FFmpeg-devel] [PATCH 10/13] avcodec/motion_est: Avoid branches for put(_no_rnd) selection

[Andreas Rheinhardt]

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/motion_est.c | 25 +
 1 file changed, 5 insertions(+), 20 deletions(-)

diff --git a/libavcodec/motion_est.c b/libavcodec/motion_est.c
index 554fc9780e..b9576e61bf 100644
--- a/libavcodec/motion_est.c
+++ b/libavcodec/motion_est.c
@@ -661,18 +661,12 @@ static inline int h263_mv4_search(MpegEncContext *s, int 
mx, int my, int shift)
 const uint8_t *ref = c->ref[block][0] + (mx4>>2) + 
(my4>>2)*stride;
 dxy = ((my4 & 3) << 2) | (mx4 & 3);
 
-if(s->no_rounding)
-s->qdsp.put_no_rnd_qpel_pixels_tab[1][dxy](dest_y, ref, 
stride);
-else
-s->qdsp.put_qpel_pixels_tab[1][dxy](dest_y, ref, stride);
+c->qpel_put[1][dxy](dest_y, ref, stride);
 }else{
 const uint8_t *ref = c->ref[block][0] + (mx4>>1) + 
(my4>>1)*stride;
 dxy = ((my4 & 1) << 1) | (mx4 & 1);
 
-if(s->no_rounding)
-s->hdsp.put_no_rnd_pixels_tab[1][dxy](dest_y, ref, 
stride, h);
-else
-s->hdsp.put_pixels_tab   [1][dxy](dest_y, ref, 
stride, h);
+c->hpel_put[1][dxy](dest_y, ref, stride, h);
 }
 dmin_sum+= (mv_penalty[mx4-pred_x4] + 
mv_penalty[my4-pred_y4])*c->mb_penalty_factor;
 }else
@@ -713,13 +707,8 @@ static inline int h263_mv4_search(MpegEncContext *s, int 
mx, int my, int shift)
 
 offset= (s->mb_x*8 + (mx>>1)) + (s->mb_y*8 + (my>>1))*s->uvlinesize;
 
-if(s->no_rounding){
-s->hdsp.put_no_rnd_pixels_tab[1][dxy](c->scratchpad, 
s->last_pic.data[1] + offset, s->uvlinesize, 8);
-s->hdsp.put_no_rnd_pixels_tab[1][dxy](c->scratchpad + 8, 
s->last_pic.data[2] + offset, s->uvlinesize, 8);
-}else{
-s->hdsp.put_pixels_tab   [1][dxy](c->scratchpad, 
s->last_pic.data[1] + offset, s->uvlinesize, 8);
-s->hdsp.put_pixels_tab   [1][dxy](c->scratchpad + 8, 
s->last_pic.data[2] + offset, s->uvlinesize, 8);
-}
+c->hpel_put[1][dxy](c->scratchpad, s->last_pic.data[1] + offset, 
s->uvlinesize, 8);
+c->hpel_put[1][dxy](c->scratchpad + 8, s->last_pic.data[2] + offset, 
s->uvlinesize, 8);
 
 dmin_sum += c->mb_cmp[1](s, s->new_pic->data[1] + s->mb_x * 8 + 
s->mb_y * 8 * s->uvlinesize, c->scratchpad, s->uvlinesize, 8);
 dmin_sum += c->mb_cmp[1](s, s->new_pic->data[2] + s->mb_x * 8 + 
s->mb_y * 8 * s->uvlinesize, c->scratchpad + 8, s->uvlinesize, 8);
@@ -825,11 +814,7 @@ static int interlaced_search(MpegEncContext *s, int 
ref_index,
 const uint8_t *ref = c->ref[field_select+ref_index][0] + 
(mx_i>>1) + (my_i>>1)*stride;
 dxy = ((my_i & 1) << 1) | (mx_i & 1);
 
-if(s->no_rounding){
-s->hdsp.put_no_rnd_pixels_tab[size][dxy](c->scratchpad, 
ref, stride, h);
-}else{
-s->hdsp.put_pixels_tab   [size][dxy](c->scratchpad, 
ref, stride, h);
-}
+c->hpel_put[size][dxy](c->scratchpad, ref, stride, h);
 dmin = c->mb_cmp[size](s, c->src[block][0], c->scratchpad, 
stride, h);
 dmin+= (mv_penalty[mx_i-c->pred_x] + 
mv_penalty[my_i-c->pred_y] + 1)*c->mb_penalty_factor;
 }else
-- 
2.40.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH 09/13] avcodec/mpegvideo_enc: Add AV_CODEC_CAP_DR1

[Andreas Rheinhardt]

The mpegvideo-based encoders do one uncommon thing with
the packet's data given by ff_alloc_packet(): They potentially
reallocate it. But this only affects the internal buffer
and is not user-facing at all, so one can nevertheless
use the AV_CODEC_CAP_DR1 for them.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/flvenc.c| 2 +-
 libavcodec/h261enc.c   | 2 +-
 libavcodec/ituh263enc.c| 5 +++--
 libavcodec/mjpegenc.c  | 5 +++--
 libavcodec/mpeg12enc.c | 6 --
 libavcodec/mpeg4videoenc.c | 3 ++-
 libavcodec/msmpeg4enc.c| 6 +++---
 libavcodec/rv10enc.c   | 2 +-
 libavcodec/rv20enc.c   | 2 +-
 libavcodec/speedhqenc.c| 2 +-
 libavcodec/wmv2enc.c   | 2 +-
 11 files changed, 21 insertions(+), 16 deletions(-)

diff --git a/libavcodec/flvenc.c b/libavcodec/flvenc.c
index 6a96cb0f2f..97323ac655 100644
--- a/libavcodec/flvenc.c
+++ b/libavcodec/flvenc.c
@@ -98,6 +98,7 @@ const FFCodec ff_flv_encoder = {
 .p.type = AVMEDIA_TYPE_VIDEO,
 .p.id   = AV_CODEC_ID_FLV1,
 .p.priv_class   = &ff_mpv_enc_class,
+.p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
 .priv_data_size = sizeof(MpegEncContext),
 .init   = ff_mpv_encode_init,
 FF_CODEC_ENCODE_CB(ff_mpv_encode_picture),
@@ -105,5 +106,4 @@ const FFCodec ff_flv_encoder = {
 .caps_internal  = FF_CODEC_CAP_INIT_CLEANUP,
 .p.pix_fmts = (const enum AVPixelFormat[]) { AV_PIX_FMT_YUV420P,
  AV_PIX_FMT_NONE},
-.p.capabilities = AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
 };
diff --git a/libavcodec/h261enc.c b/libavcodec/h261enc.c
index d3d724bef6..e0ff1a03da 100644
--- a/libavcodec/h261enc.c
+++ b/libavcodec/h261enc.c
@@ -383,6 +383,7 @@ const FFCodec ff_h261_encoder = {
 .p.type = AVMEDIA_TYPE_VIDEO,
 .p.id   = AV_CODEC_ID_H261,
 .p.priv_class   = &ff_mpv_enc_class,
+.p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
 .priv_data_size = sizeof(H261EncContext),
 .init   = ff_mpv_encode_init,
 FF_CODEC_ENCODE_CB(ff_mpv_encode_picture),
@@ -390,5 +391,4 @@ const FFCodec ff_h261_encoder = {
 .caps_internal  = FF_CODEC_CAP_INIT_CLEANUP,
 .p.pix_fmts = (const enum AVPixelFormat[]) { AV_PIX_FMT_YUV420P,
  AV_PIX_FMT_NONE },
-.p.capabilities = AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
 };
diff --git a/libavcodec/ituh263enc.c b/libavcodec/ituh263enc.c
index 3982b1e675..ad2d1a044f 100644
--- a/libavcodec/ituh263enc.c
+++ b/libavcodec/ituh263enc.c
@@ -921,7 +921,7 @@ const FFCodec ff_h263_encoder = {
 .p.id   = AV_CODEC_ID_H263,
 .p.pix_fmts = (const enum AVPixelFormat[]){AV_PIX_FMT_YUV420P, 
AV_PIX_FMT_NONE},
 .p.priv_class   = &h263_class,
-.p.capabilities = AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
+.p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
 .caps_internal  = FF_CODEC_CAP_INIT_CLEANUP,
 .priv_data_size = sizeof(MpegEncContext),
 .init   = ff_mpv_encode_init,
@@ -952,7 +952,8 @@ const FFCodec ff_h263p_encoder = {
 .p.id   = AV_CODEC_ID_H263P,
 .p.pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUV420P, 
AV_PIX_FMT_NONE },
 .p.priv_class   = &h263p_class,
-.p.capabilities = AV_CODEC_CAP_SLICE_THREADS | 
AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
+.p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_SLICE_THREADS |
+  AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
 .caps_internal  = FF_CODEC_CAP_INIT_CLEANUP,
 .priv_data_size = sizeof(MpegEncContext),
 .init   = ff_mpv_encode_init,
diff --git a/libavcodec/mjpegenc.c b/libavcodec/mjpegenc.c
index 9d4c3a4f41..c4f72743ca 100644
--- a/libavcodec/mjpegenc.c
+++ b/libavcodec/mjpegenc.c
@@ -649,7 +649,8 @@ const FFCodec ff_mjpeg_encoder = {
 .init   = ff_mpv_encode_init,
 FF_CODEC_ENCODE_CB(ff_mpv_encode_picture),
 .close  = mjpeg_encode_close,
-.p.capabilities = AV_CODEC_CAP_SLICE_THREADS | AV_CODEC_CAP_FRAME_THREADS |
+.p.capabilities = AV_CODEC_CAP_DR1 |
+  AV_CODEC_CAP_SLICE_THREADS | AV_CODEC_CAP_FRAME_THREADS |
   AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
 .caps_internal  = FF_CODEC_CAP_INIT_CLEANUP | FF_CODEC_CAP_ICC_PROFILES,
 .p.pix_fmts = (const enum AVPixelFormat[]) {
@@ -675,6 +676,7 @@ const FFCodec ff_amv_encoder = {
 CODEC_LONG_NAME("AMV Video"),
 .p.type = AVMEDIA_TYPE_VIDEO,
 .p.id   = AV_CODEC_ID_AMV,
+.p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
 .priv_data_size = sizeof(MJPEGEncContext),
 .init   = ff_mpv_encode_init,
 FF_CODEC_ENCODE_CB(amv_encode_picture),
@@ -684,6 +686,5 @@ const FFCodec ff_amv_encoder = {
 AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_NONE
 },
 .p.priv_class   = &amv_class,
- 

[FFmpeg-devel] [PATCH 11/13] avcodec/mpegvideo_dec: Use picture-dimensions in ff_print_debug_info()

[Andreas Rheinhardt]

It will allow to avoid the special case for VC-1 field pictures.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpegvideo_dec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/mpegvideo_dec.c b/libavcodec/mpegvideo_dec.c
index 78fa10c11d..5d8e9a36ec 100644
--- a/libavcodec/mpegvideo_dec.c
+++ b/libavcodec/mpegvideo_dec.c
@@ -404,7 +404,7 @@ void ff_print_debug_info(const MpegEncContext *s, const 
MPVPicture *p, AVFrame *
 {
 ff_print_debug_info2(s->avctx, pict, p->mb_type,
  p->qscale_table, p->motion_val,
- s->mb_width, s->mb_height, s->mb_stride, 
s->quarter_sample);
+ p->mb_width, p->mb_height, p->mb_stride, 
s->quarter_sample);
 }
 
 int ff_mpv_export_qp_table(const MpegEncContext *s, AVFrame *f,
-- 
2.40.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH 12/13] avcodec/vc1dec: Reenable debug-info output for field pictures

[Andreas Rheinhardt]

Effectively reverts c59b5e3d1e0121ea23b5b326529f5bdca44cf982.
This is possible now that ff_print_debug_info2() uses
the MPVPicture dimensions.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/vc1dec.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/libavcodec/vc1dec.c b/libavcodec/vc1dec.c
index 4b31860c3f..2cd87e5de4 100644
--- a/libavcodec/vc1dec.c
+++ b/libavcodec/vc1dec.c
@@ -1365,14 +1365,12 @@ image:
 if (s->pict_type == AV_PICTURE_TYPE_B || s->low_delay) {
 if ((ret = av_frame_ref(pict, s->cur_pic.ptr->f)) < 0)
 goto err;
-if (!v->field_mode)
-ff_print_debug_info(s, s->cur_pic.ptr, pict);
+ff_print_debug_info(s, s->cur_pic.ptr, pict);
 *got_frame = 1;
 } else if (s->last_pic.ptr) {
 if ((ret = av_frame_ref(pict, s->last_pic.ptr->f)) < 0)
 goto err;
-if (!v->field_mode)
-ff_print_debug_info(s, s->last_pic.ptr, pict);
+ff_print_debug_info(s, s->last_pic.ptr, pict);
 *got_frame = 1;
 }
 }
-- 
2.40.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH 13/13] avcodec/h261dec: Remove dead check

[Andreas Rheinhardt]

H.261 does not have non-reference frames.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/h261dec.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libavcodec/h261dec.c b/libavcodec/h261dec.c
index cabca33c8d..50ac53167d 100644
--- a/libavcodec/h261dec.c
+++ b/libavcodec/h261dec.c
@@ -587,8 +587,7 @@ static int h261_decode_frame(AVCodecContext *avctx, AVFrame 
*pict,
 return ret;
 }
 
-if ((avctx->skip_frame >= AVDISCARD_NONREF && s->pict_type == 
AV_PICTURE_TYPE_B) ||
-(avctx->skip_frame >= AVDISCARD_NONKEY && s->pict_type != 
AV_PICTURE_TYPE_I) ||
+if ((avctx->skip_frame >= AVDISCARD_NONKEY && s->pict_type != 
AV_PICTURE_TYPE_I) ||
  avctx->skip_frame >= AVDISCARD_ALL)
 return buf_size;
 
-- 
2.40.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/mpeg_er: Don't set block_index unnecessarily

[Andreas Rheinhardt]

Michael Niedermayer:
> On Thu, Jun 20, 2024 at 05:01:08PM +, Andreas Rheinhardt wrote:
>> ffmpeg | branch: master | Andreas Rheinhardt 
>>  | Wed Jun 12 08:37:53 2024 +0200| 
>> [65d5ccb808ec93de46a2458ea8cc082ce4460f34] | committer: Andreas Rheinhardt
>>
>> avcodec/mpeg_er: Don't set block_index unnecessarily
>>
>> ff_init_block_index() sets MpegEncContext.dest and
>> MpegEncContext.block_index. The latter is unused by
>> ff_mpv_reconstruct_mb() (which is what this code is
>> preparatory for) and dest is overwritten a few lines below.
>> So don't initialize block_index at all.
>>
>> Signed-off-by: Andreas Rheinhardt 
>>
>>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=65d5ccb808ec93de46a2458ea8cc082ce4460f34
>> ---
>>
>>  libavcodec/mpeg_er.c | 4 
>>  1 file changed, 4 deletions(-)
>>
>> diff --git a/libavcodec/mpeg_er.c b/libavcodec/mpeg_er.c
>> index e7b3197bb1..fe7dcd7efb 100644
>> --- a/libavcodec/mpeg_er.c
>> +++ b/libavcodec/mpeg_er.c
>> @@ -76,10 +76,6 @@ static void mpeg_er_decode_mb(void *opaque, int ref, int 
>> mv_dir, int mv_type,
>>  s->mcsel  = 0;
>>  memcpy(s->mv, mv, sizeof(*mv));
>>  
>> -ff_init_block_index(s);
>> -ff_update_block_index(s, s->avctx->bits_per_raw_sample,
>> -  s->avctx->lowres, s->chroma_x_shift);
>> -
>>  s->bdsp.clear_blocks(s->block[0]);
>>  if (!s->chroma_y_shift)
>>  s->bdsp.clear_blocks(s->block[6]);
> 
> It seems not unnneccesary
> 
> Running: 
> 69814/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VC1_fuzzer-4868081575329792
> =
> ==2146502==ERROR: AddressSanitizer: heap-buffer-overflow on address 
> 0x62509c80 at pc 0x0049b63f bp 0x7ffdecbf28c0 sp 0x7ffdecbf2088
> WRITE of size 64 at 0x62509c80 thread T0
> #0 0x49b63e in __asan_memset 
> /b/swarming/w/ir/cache/builder/src/third_party/llvm/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cc:26:3
> #1 0xe85598 in ff_clean_intra_table_entries 
> ffmpeg/libavcodec/mpegvideo.c:809:5
> #2 0xe9b926 in mpv_reconstruct_mb_internal 
> ffmpeg/libavcodec/mpv_reconstruct_mb_template.c:68:17
> #3 0xe9b926 in ff_mpv_reconstruct_mb ffmpeg/libavcodec/mpegvideo_dec.c:935
> #4 0xb1f790 in guess_mv ffmpeg/libavcodec/error_resilience.c:456:17
> #5 0xb0f9b5 in ff_er_frame_end ffmpeg/libavcodec/error_resilience.c:1224:9
> #6 0x63e595 in vc1_decode_frame ffmpeg/libavcodec/vc1dec.c:1341:13
> #7 0x4fe53f in decode_simple_internal ffmpeg/libavcodec/decode.c:429:20
> #8 0x4fe53f in decode_simple_receive_frame ffmpeg/libavcodec/decode.c:600
> #9 0x4fe53f in decode_receive_frame_internal 
> ffmpeg/libavcodec/decode.c:631
> #10 0x4fcf6d in avcodec_send_packet ffmpeg/libavcodec/decode.c:721:15
> #11 0x4d1da7 in LLVMFuzzerTestOneInput 
> ffmpeg/tools/target_dec_fuzzer.c:533:25
> #12 0x166259d in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, 
> unsigned long) Fuzzer/build/../FuzzerLoop.cpp:495:13
> #13 0x1657172 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, 
> unsigned long) Fuzzer/build/../FuzzerDriver.cpp:273:6
> #14 0x165c371 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned 
> char const*, unsigned long)) Fuzzer/build/../FuzzerDriver.cpp:690:9
> #15 0x1656e50 in main Fuzzer/build/../FuzzerMain.cpp:20:10
> #16 0x7fd643b76082 in __libc_start_main 
> (/lib/x86_64-linux-gnu/libc.so.6+0x24082)
> #17 0x423f6d in _start (ffmpeg/tools/target_dec_vc1_fuzzer+0x423f6d)
> 
> Address 0x62509c80 is a wild pointer.
> SUMMARY: AddressSanitizer: heap-buffer-overflow 
> /b/swarming/w/ir/cache/builder/src/third_party/llvm/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cc:26:3
>  in __asan_memset
> Shadow bytes around the buggy address:
>   0x0c4a7fff9340: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c4a7fff9350: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c4a7fff9360: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c4a7fff9370: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c4a7fff9380: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> =>0x0c4a7fff9390:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c4a7fff93a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c4a7fff93b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c4a7fff93c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c4a7fff93d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c4a7fff93e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> Shadow byte legend (one shadow byte represents 8 application bytes):
>   Addressable:   00
>   Partially addressable: 01 02 03 04 05 06 07
>   Heap left redzone:   fa
>   Freed heap region:   fd
>   Stack left redzone:  f1
>   Stack mid redzone:   f2
>   Stack right redzone: f3
>   Stack after return:  f5
>   Stack use after scope:   f8
>   Global redzone:  f9
>   Global init order:   f6
> 

Re: [FFmpeg-devel] [PATCH 02/11] avcodec/vvc/dec: Check ff_init_cabac_decoder() for failure

[Nuo Mi]

On Mon, Jul 1, 2024 at 7:13 AM Michael Niedermayer 
wrote:

> Fixes: signed integer overflow: 1107820800 + 1107820800 cannot be
> represented in type 'int'
> Fixes: left shift of 1091059712 by 6 places cannot be represented in type
> 'int'
> Fixes:
> 69910/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VVC_fuzzer-5162839971528704
>
LGTM

>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by
> :
> Michael Niedermayer 
> ---
>  libavcodec/vvc/dec.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/vvc/dec.c b/libavcodec/vvc/dec.c
> index a6b601b778c..563f6fcf082 100644
> --- a/libavcodec/vvc/dec.c
> +++ b/libavcodec/vvc/dec.c
> @@ -476,13 +476,14 @@ static int slices_realloc(VVCFrameContext *fc)
>  return 0;
>  }
>
> -static void ep_init_cabac_decoder(SliceContext *sc, const int index,
> +static int ep_init_cabac_decoder(SliceContext *sc, const int index,
>  const H2645NAL *nal, GetBitContext *gb, const CodedBitstreamUnit
> *unit)
>  {
>  const H266RawSlice *slice = unit->content_ref;
>  const H266RawSliceHeader *rsh = sc->sh.r;
>  EntryPoint *ep= sc->eps + index;
>  int size;
> +int ret;
>
>  if (index < rsh->num_entry_points) {
>  int skipped = 0;
> @@ -501,8 +502,11 @@ static void ep_init_cabac_decoder(SliceContext *sc,
> const int index,
>  size = get_bits_left(gb) / 8;
>  }
>  av_assert0(gb->buffer + get_bits_count(gb) / 8 + size <=
> gb->buffer_end);
> -ff_init_cabac_decoder (&ep->cc, gb->buffer + get_bits_count(gb) / 8,
> size);
> +ret = ff_init_cabac_decoder (&ep->cc, gb->buffer + get_bits_count(gb)
> / 8, size);
> +if (ret < 0)
> +return ret;
>  skip_bits(gb, size * 8);
> +return 0;
>  }
>
>  static int slice_init_entry_points(SliceContext *sc,
> @@ -538,7 +542,9 @@ static int slice_init_entry_points(SliceContext *sc,
>  fc->tab.slice_idx[rs] = sc->slice_idx;
>  }
>
> -ep_init_cabac_decoder(sc, i, nal, &gb, unit);
> +ret = ep_init_cabac_decoder(sc, i, nal, &gb, unit);
> +if (ret < 0)
> +return ret;
>
>  if (i + 1 < sc->nb_eps)
>  ctu_addr = sh->entry_point_start_ctu[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 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 06/13] avcodec/mpv_reconstruct_mb_template: Merge template into its users

[Rémi Denis-Courmont]

Le 1 juillet 2024 15:16:03 GMT+03:00, Andreas Rheinhardt 
 a écrit :
>A large part of this template is decoder-only. This makes
>the complexity of the IS_ENCODER-checks not worth it.
>So simply merge the template into both its users.
>
>Signed-off-by: Andreas Rheinhardt 
>---
> libavcodec/mpegvideo_dec.c   | 218 +-
> libavcodec/mpegvideo_enc.c   |  81 ++-
> libavcodec/mpv_reconstruct_mb_template.c | 272 ---
> 3 files changed, 294 insertions(+), 277 deletions(-)
> delete mode 100644 libavcodec/mpv_reconstruct_mb_template.c
>
>diff --git a/libavcodec/mpegvideo_dec.c b/libavcodec/mpegvideo_dec.c
>index 1cab108935..d50283 100644
>--- a/libavcodec/mpegvideo_dec.c
>+++ b/libavcodec/mpegvideo_dec.c
>@@ -904,11 +904,225 @@ static inline void add_dct(MpegEncContext *s,
> }
> }
> 
>-#define IS_ENCODER 0
>-#include "mpv_reconstruct_mb_template.c"
>+/* put block[] to dest[] */
>+static inline void put_dct(MpegEncContext *s,
>+   int16_t *block, int i, uint8_t *dest, int 
>line_size, int qscale)
>+{
>+s->dct_unquantize_intra(s, block, i, qscale);
>+s->idsp.idct_put(dest, line_size, block);
>+}

BTW, shouldn't the put/add be folded into the more specific callback, as most 
other decoder DSP functions seems to work?

(No objections either way.)

>+
>+static inline void add_dequant_dct(MpegEncContext *s,
>+   int16_t *block, int i, uint8_t *dest, int 
>line_size, int qscale)
>+{
>+if (s->block_last_index[i] >= 0) {
>+s->dct_unquantize_inter(s, block, i, qscale);
>+
>+s->idsp.idct_add(dest, line_size, block);
>+}
>+}
>+
>+#define NOT_MPEG12_H2610
>+#define MAY_BE_MPEG12_H261 1
>+#define DEFINITELY_MPEG12_H261 2
>+
>+/* generic function called after a macroblock has been parsed by the decoder.
>+
>+   Important variables used:
>+   s->mb_intra : true if intra macroblock
>+   s->mv_dir   : motion vector direction
>+   s->mv_type  : motion vector type
>+   s->mv   : motion vector
>+   s->interlaced_dct : true if interlaced dct used (mpeg2)
>+ */
>+static av_always_inline
>+void mpv_reconstruct_mb_internal(MpegEncContext *s, int16_t block[12][64],
>+ int lowres_flag, int is_mpeg12)
>+{
>+#define IS_MPEG12_H261(s) (is_mpeg12 == MAY_BE_MPEG12_H261 ? ((s)->out_format 
><= FMT_H261) : is_mpeg12)
>+{
>+uint8_t *dest_y = s->dest[0], *dest_cb = s->dest[1], *dest_cr = 
>s->dest[2];
>+int dct_linesize, dct_offset;
>+const int linesize   = s->cur_pic.linesize[0]; //not s->linesize as 
>this would be wrong for field pics
>+const int uvlinesize = s->cur_pic.linesize[1];
>+const int block_size = lowres_flag ? 8 >> s->avctx->lowres : 8;
>+
>+dct_linesize = linesize << s->interlaced_dct;
>+dct_offset   = s->interlaced_dct ? linesize : linesize * block_size;
>+
>+if (!s->mb_intra) {
>+/* motion handling */
>+if (HAVE_THREADS && is_mpeg12 != DEFINITELY_MPEG12_H261 &&
>+s->avctx->active_thread_type & FF_THREAD_FRAME) {
>+if (s->mv_dir & MV_DIR_FORWARD) {
>+ff_thread_progress_await(&s->last_pic.ptr->progress,
>+ lowest_referenced_row(s, 0));
>+}
>+if (s->mv_dir & MV_DIR_BACKWARD) {
>+ff_thread_progress_await(&s->next_pic.ptr->progress,
>+ lowest_referenced_row(s, 1));
>+}
>+}
>+
>+if (lowres_flag) {
>+const h264_chroma_mc_func *op_pix = 
>s->h264chroma.put_h264_chroma_pixels_tab;
>+
>+if (s->mv_dir & MV_DIR_FORWARD) {
>+MPV_motion_lowres(s, dest_y, dest_cb, dest_cr, 0, 
>s->last_pic.data, op_pix);
>+op_pix = s->h264chroma.avg_h264_chroma_pixels_tab;
>+}
>+if (s->mv_dir & MV_DIR_BACKWARD) {
>+MPV_motion_lowres(s, dest_y, dest_cb, dest_cr, 1, 
>s->next_pic.data, op_pix);
>+}
>+} else {
>+const op_pixels_func (*op_pix)[4];
>+const qpel_mc_func (*op_qpix)[16];
>+
>+if ((is_mpeg12 == DEFINITELY_MPEG12_H261 || !s->no_rounding) 
>|| s->pict_type == AV_PICTURE_TYPE_B) {
>+op_pix = s->hdsp.put_pixels_tab;
>+op_qpix = s->qdsp.put_qpel_pixels_tab;
>+} else {
>+op_pix = s->hdsp.put_no_rnd_pixels_tab;
>+op_qpix = s->qdsp.put_no_rnd_qpel_pixels_tab;
>+}
>+if (s->mv_dir & MV_DIR_FORWARD) {
>+ff_mpv_motion(s, dest_y, dest_cb, dest_cr, 0, 
>s->last_pic.data, op_pix, op_qpix);
>+op_pix  = s->hdsp.avg_pixels_tab;
>+op_qpix = s->qdsp.avg_qpel_pixels_tab;
>+

Re: [FFmpeg-devel] [PATCH] avutil/executor: Fix missing check before using mutex

[Nuo Mi]

On Sun, Jun 30, 2024 at 6:45 PM Zhao Zhili  wrote:

> From: Zhao Zhili 
>
> ---
> The code can be simplified by always creating mutex/cond. I'm not sure
> it worth the overhead. Please note !HAVE_THREADS don't have the same
> problem since it has mock implementation of ff_mutex_lock/unlock.
>
Hi Zhili,
Thank you for the patch.
Do we really need this? The lock/unlock/signal functions will return an
error if the lock and condition variables are not initialized.

>
>  libavutil/executor.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/libavutil/executor.c b/libavutil/executor.c
> index fb20104b58..89058fab2f 100644
> --- a/libavutil/executor.c
> +++ b/libavutil/executor.c
> @@ -194,14 +194,17 @@ void av_executor_execute(AVExecutor *e, AVTask *t)
>  AVTaskCallbacks *cb = &e->cb;
>  AVTask **prev;
>
> -ff_mutex_lock(&e->lock);
> +if (e->thread_count)
> +ff_mutex_lock(&e->lock);
>  if (t) {
>  for (prev = &e->tasks; *prev && cb->priority_higher(*prev, t);
> prev = &(*prev)->next)
>  /* nothing */;
>  add_task(prev, t);
>  }
> -ff_cond_signal(&e->cond);
> -ff_mutex_unlock(&e->lock);
> +if (e->thread_count) {
> +ff_cond_signal(&e->cond);
> +ff_mutex_unlock(&e->lock);
> +}
>
>  if (!e->thread_count || !HAVE_THREADS) {
>  // We are running in a single-threaded environment, so we must
> handle all tasks ourselves
> --
> 2.42.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 2/2] lavc/h264dsp: R-V V 8-bit luma loop filter

[flow gg]

The loop filter horizontal in vp8 also has this issue ..

Rémi Denis-Courmont  于2024年6月30日周日 17:04写道：

> T-Head C908 (cycles):
> h264_h_loop_filter_luma_8bpp_c:   297.5
> h264_h_loop_filter_luma_8bpp_rvv_i32: 374.7
> h264_v_loop_filter_luma_8bpp_c:   862.7
> h264_v_loop_filter_luma_8bpp_rvv_i32: 200.7
>
> Performance in the horizontal scenario seems worse than scalar. x86
> SSE2 and AVX optimisations are similarly affected. This is presumably
> caused by unlucky inputs from checkasm, such that the C code
> short-circuits almost all filter calculations.
> ---
>  libavcodec/riscv/Makefile   |   1 +
>  libavcodec/riscv/h264dsp_init.c |  13 ++-
>  libavcodec/riscv/h264dsp_rvv.S  | 136 
>  3 files changed, 149 insertions(+), 1 deletion(-)
>  create mode 100644 libavcodec/riscv/h264dsp_rvv.S
>
> diff --git a/libavcodec/riscv/Makefile b/libavcodec/riscv/Makefile
> index c180223141..a1510e8c6e 100644
> --- a/libavcodec/riscv/Makefile
> +++ b/libavcodec/riscv/Makefile
> @@ -31,6 +31,7 @@ RVV-OBJS-$(CONFIG_H263DSP) += riscv/h263dsp_rvv.o
>  OBJS-$(CONFIG_H264CHROMA) += riscv/h264_chroma_init_riscv.o
>  RVV-OBJS-$(CONFIG_H264CHROMA) += riscv/h264_mc_chroma.o
>  OBJS-$(CONFIG_H264DSP) += riscv/h264dsp_init.o
> +RVV-OBJS-$(CONFIG_H264DSP) += riscv/h264dsp_rvv.o
>  OBJS-$(CONFIG_HUFFYUV_DECODER) += riscv/huffyuvdsp_init.o
>  RVV-OBJS-$(CONFIG_HUFFYUV_DECODER) += riscv/huffyuvdsp_rvv.o
>  OBJS-$(CONFIG_IDCTDSP) += riscv/idctdsp_init.o
> diff --git a/libavcodec/riscv/h264dsp_init.c
> b/libavcodec/riscv/h264dsp_init.c
> index dbbf3db400..0d4d541992 100644
> --- a/libavcodec/riscv/h264dsp_init.c
> +++ b/libavcodec/riscv/h264dsp_init.c
> @@ -24,8 +24,14 @@
>
>  #include "libavutil/attributes.h"
>  #include "libavutil/cpu.h"
> +#include "libavutil/riscv/cpu.h"
>  #include "libavcodec/h264dsp.h"
>
> +void ff_h264_v_loop_filter_luma_8_rvv(uint8_t *pix, ptrdiff_t stride,
> +  int alpha, int beta, int8_t *tc0);
> +void ff_h264_h_loop_filter_luma_8_rvv(uint8_t *pix, ptrdiff_t stride,
> +  int alpha, int beta, int8_t *tc0);
> +
>  extern int ff_startcode_find_candidate_rvb(const uint8_t *, int);
>  extern int ff_startcode_find_candidate_rvv(const uint8_t *, int);
>
> @@ -38,8 +44,13 @@ av_cold void ff_h264dsp_init_riscv(H264DSPContext *dsp,
> const int bit_depth,
>  if (flags & AV_CPU_FLAG_RVB_BASIC)
>  dsp->startcode_find_candidate = ff_startcode_find_candidate_rvb;
>  # if HAVE_RVV
> -if (flags & AV_CPU_FLAG_RVV_I32)
> +if (flags & AV_CPU_FLAG_RVV_I32) {
> +if (bit_depth == 8 && ff_rv_vlen_least(128)) {
> +dsp->h264_v_loop_filter_luma =
> ff_h264_v_loop_filter_luma_8_rvv;
> +dsp->h264_h_loop_filter_luma =
> ff_h264_h_loop_filter_luma_8_rvv;
> +}
>  dsp->startcode_find_candidate = ff_startcode_find_candidate_rvv;
> +}
>  # endif
>  #endif
>  }
> diff --git a/libavcodec/riscv/h264dsp_rvv.S
> b/libavcodec/riscv/h264dsp_rvv.S
> new file mode 100644
> index 00..ea9dfb1a7e
> --- /dev/null
> +++ b/libavcodec/riscv/h264dsp_rvv.S
> @@ -0,0 +1,136 @@
> +/*
> + * Copyright © 2024 Rémi Denis-Courmont.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions are
> met:
> + *
> + * 1. Redistributions of source code must retain the above copyright
> notice,
> + *this list of conditions and the following disclaimer.
> + *
> + * 2. Redistributions in binary form must reproduce the above copyright
> notice,
> + *this list of conditions and the following disclaimer in the
> documentation
> + *and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> "AS IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
> THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
> PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS
> BE
> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
> BUSINESS
> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
> THE
> + * POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +#include "libavutil/riscv/asm.S"
> +
> +.variant_cc ff_h264_loop_filter_luma_8_rvv
> +func ff_h264_loop_filter_luma_8_rvv, zve32x
> +# p2: v8, p1: v9, p0: v10, q0: v11, q1: v12, q2: v13
> +# alpha: a2, beta: a3
> +csrwivxrm, 0
> +vid.vv0
> +vaaddu.vvv14, v10, v11 # (p0 + q0 + 1) / 2
> +vsrl.vi 

[FFmpeg-devel] [RFC] av_rescale() coverity

[Michael Niedermayer]

Hi all

coverity seems to have started to do a new thing. Namely if theres a
return statement it assumes it can independant of everything occurr

an example would be av_rescale() which on overflow returns INT64_MIN

also with the right flags av_rescale() will pass INT64_MIN and INT64_MAX through
from the input

So coverity since a few days seems to treat every av_rescale() call as if it 
returns
INT64_MIN and INT64_MAX. coverity doesnt care if that return statement is 
reachable or
if the flags even include the execution path.

An example is this:
AVRational time_base_q = AV_TIME_BASE_Q;
int64_t next_dts = av_rescale_q(ds->next_dts, time_base_q, 
av_inv_q(ist->framerate));
ds->next_dts = av_rescale_q(next_dts + 1, av_inv_q(ist->framerate), 
time_base_q);

Here coverity as a initial statement claims next_dts is INT64_MAX
and next_dts + 1 would overflow


8. function_return: Function av_rescale_q(ds->next_dts, time_base_q, 
av_inv_q(ist->framerate)) returns 9223372036854775807.
9. known_value_assign: next_dts = av_rescale_q(ds->next_dts, 
time_base_q, av_inv_q(ist->framerate)), its value is now 9223372036854775807.
331int64_t next_dts = av_rescale_q(ds->next_dts, time_base_q, 
av_inv_q(ist->framerate));

CID 1604545: (#1 of 1): Overflowed constant (INTEGER_OVERFLOW)
10. overflow_const: Expression next_dts + 1LL, which is equal to 
-9223372036854775808, where next_dts is known to be equal to 
9223372036854775807, overflows the type that receives it, a signed integer 64 
bits wide.


another example is this:

#define AV_TIME_BASE100
pts = av_rescale(ds->dts, 100, AV_TIME_BASE);

coverity hallucinates pts as a tainted negative number here nothing says 
anything about
the input ds->dts (and thats what would matter)

In the past coverity provided a detailed list of steps on how a
case is reached. One could then check these assumtions and mark things
as false positive when one assumtion is wrong. (coverity was most of the time
wrong)

Now coverity just hallucinates claims out of the blue without any
explanation how that can happen.

Iam a bit at a loss how to deal with this and also why exactly this
new behavior appeared.

Has anyone changed any setting or anything in coverity ?

The number of issues shot up to over 400 on the 22th june
"194 new defect(s) introduced to FFmpeg/FFmpeg found with Coverity Scan."

before this i thought iam mostly done with my coverity work.
now truth is, the STF text speaks about 673 issues at the time and not
what appears after the work started, but it makes me a bit sad if i categorize
~700+ issues and then fix the ones that are bugs just to find coverity
hallucinate 200 new issues a month that ill have to leave open for future
efforts.

I did not expect that years of ignoring coverity accumulate 673 issues and
then suddenly the rate of new issues to shoot up like this. I kind of expected
that i can fix all new issues appearing during the work with insignificant 
extra effort

thx

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH v5] lavc/vvc_mc: R-V V avg w_avg

[uk7b]

From: sunyuechi 

  C908   X60
avg_8_2x2_c:1.21.0
avg_8_2x2_rvv_i32  :1.01.0
avg_8_2x4_c:2.02.0
avg_8_2x4_rvv_i32  :1.51.2
avg_8_2x8_c:3.74.0
avg_8_2x8_rvv_i32  :2.02.0
avg_8_2x16_c   :7.27.7
avg_8_2x16_rvv_i32 :3.23.0
avg_8_2x32_c   :   14.5   15.2
avg_8_2x32_rvv_i32 :5.75.0
avg_8_2x64_c   :   50.0   45.2
avg_8_2x64_rvv_i32 :   41.5   32.5
avg_8_2x128_c  :  101.5   84.2
avg_8_2x128_rvv_i32:   89.5   73.2
avg_8_4x2_c:2.02.0
avg_8_4x2_rvv_i32  :1.01.0
avg_8_4x4_c:3.53.5
avg_8_4x4_rvv_i32  :1.51.2
avg_8_4x8_c:6.77.0
avg_8_4x8_rvv_i32  :2.01.7
avg_8_4x16_c   :   13.2   14.0
avg_8_4x16_rvv_i32 :3.23.0
avg_8_4x32_c   :   26.2   27.7
avg_8_4x32_rvv_i32 :5.75.0
avg_8_4x64_c   :   75.0   66.0
avg_8_4x64_rvv_i32 :   40.2   33.0
avg_8_4x128_c  :  144.5  128.0
avg_8_4x128_rvv_i32:   89.5   78.7
avg_8_8x2_c:3.23.5
avg_8_8x2_rvv_i32  :1.21.0
avg_8_8x4_c:6.56.7
avg_8_8x4_rvv_i32  :1.51.5
avg_8_8x8_c:   12.7   13.2
avg_8_8x8_rvv_i32  :2.21.7
avg_8_8x16_c   :   25.2   26.5
avg_8_8x16_rvv_i32 :3.72.7
avg_8_8x32_c   :   50.2   52.7
avg_8_8x32_rvv_i32 :6.55.0
avg_8_8x64_c   :  120.2  117.7
avg_8_8x64_rvv_i32 :   45.2   39.2
avg_8_8x128_c  :  223.0  233.5
avg_8_8x128_rvv_i32:   80.0   73.2
avg_8_16x2_c   :6.26.5
avg_8_16x2_rvv_i32 :1.51.0
avg_8_16x4_c   :   12.5   12.7
avg_8_16x4_rvv_i32 :2.01.2
avg_8_16x8_c   :   24.7   26.0
avg_8_16x8_rvv_i32 :3.22.0
avg_8_16x16_c  :   49.0   51.2
avg_8_16x16_rvv_i32:5.73.2
avg_8_16x32_c  :   97.7  102.5
avg_8_16x32_rvv_i32:   10.75.7
avg_8_16x64_c  :  220.5  214.2
avg_8_16x64_rvv_i32:   48.2   39.5
avg_8_16x128_c :  436.2  428.0
avg_8_16x128_rvv_i32   :   97.2   77.0
avg_8_32x2_c   :   12.2   12.7
avg_8_32x2_rvv_i32 :2.01.2
avg_8_32x4_c   :   24.5   25.5
avg_8_32x4_rvv_i32 :3.21.7
avg_8_32x8_c   :   48.5   50.7
avg_8_32x8_rvv_i32 :5.72.7
avg_8_32x16_c  :   96.5  101.2
avg_8_32x16_rvv_i32:   10.25.0
avg_8_32x32_c  :  192.5  202.2
avg_8_32x32_rvv_i32:   20.09.5
avg_8_32x64_c  :  405.7  404.5
avg_8_32x64_rvv_i32:   72.5   40.2
avg_8_32x128_c :  821.0  832.2
avg_8_32x128_rvv_i32   :  136.2   75.7
avg_8_64x2_c   :   24.0   25.2
avg_8_64x2_rvv_i32 :3.21.7
avg_8_64x4_c   :   48.5   51.0
avg_8_64x4_rvv_i32   

Re: [FFmpeg-devel] [PATCH v5] lavc/vvc_mc: R-V V avg w_avg

[flow gg]

> I am not sure what is_w means or serves here. If you need special cases,
this
> feels a bit out of place for this macro.

It is a special case added to merge the vset of avg and w_avg, how about
giving it a default value so that it doesn't affect the use of other
functions?

> I am not sure if I get it, but it seems like this could be a normal vector
> processing loop without specialisation for the vector length, at (almost)
no
> performance cost.
>
> Can we use a regular loop here instead of repeating the same code?

Okay, updated it

> t0 is a link register, so the branch predictor will treat this a return,
but
> it seems to be a tail call instead.

Will this cause any issues? It will execute at a label, and after
executing, there is a ret at the label.

> For named labels, it is preferable to use func (perhaps with
.variant_cc), to
> get all properties right.

This macro is used in func. I assume it already has the properties of func?

> Could t4 be added in 16-bit mode so we don't need to switch vtype?
> (Also same below)

No, it is 32-bit :(

 于2024年7月1日周一 21:39写道：

> From: sunyuechi 
>
>   C908   X60
> avg_8_2x2_c:1.21.0
> avg_8_2x2_rvv_i32  :1.01.0
> avg_8_2x4_c:2.02.0
> avg_8_2x4_rvv_i32  :1.51.2
> avg_8_2x8_c:3.74.0
> avg_8_2x8_rvv_i32  :2.02.0
> avg_8_2x16_c   :7.27.7
> avg_8_2x16_rvv_i32 :3.23.0
> avg_8_2x32_c   :   14.5   15.2
> avg_8_2x32_rvv_i32 :5.75.0
> avg_8_2x64_c   :   50.0   45.2
> avg_8_2x64_rvv_i32 :   41.5   32.5
> avg_8_2x128_c  :  101.5   84.2
> avg_8_2x128_rvv_i32:   89.5   73.2
> avg_8_4x2_c:2.02.0
> avg_8_4x2_rvv_i32  :1.01.0
> avg_8_4x4_c:3.53.5
> avg_8_4x4_rvv_i32  :1.51.2
> avg_8_4x8_c:6.77.0
> avg_8_4x8_rvv_i32  :2.01.7
> avg_8_4x16_c   :   13.2   14.0
> avg_8_4x16_rvv_i32 :3.23.0
> avg_8_4x32_c   :   26.2   27.7
> avg_8_4x32_rvv_i32 :5.75.0
> avg_8_4x64_c   :   75.0   66.0
> avg_8_4x64_rvv_i32 :   40.2   33.0
> avg_8_4x128_c  :  144.5  128.0
> avg_8_4x128_rvv_i32:   89.5   78.7
> avg_8_8x2_c:3.23.5
> avg_8_8x2_rvv_i32  :1.21.0
> avg_8_8x4_c:6.56.7
> avg_8_8x4_rvv_i32  :1.51.5
> avg_8_8x8_c:   12.7   13.2
> avg_8_8x8_rvv_i32  :2.21.7
> avg_8_8x16_c   :   25.2   26.5
> avg_8_8x16_rvv_i32 :3.72.7
> avg_8_8x32_c   :   50.2   52.7
> avg_8_8x32_rvv_i32 :6.55.0
> avg_8_8x64_c   :  120.2  117.7
> avg_8_8x64_rvv_i32 :   45.2   39.2
> avg_8_8x128_c  :  223.0  233.5
> avg_8_8x128_rvv_i32:   80.0   73.2
> avg_8_16x2_c   :6.26.5
> avg_8_16x2_rvv_i32 :1.51.0
> avg_8_16x4_c   :   12.5   12.7
> avg_8_16x4_rvv_i32 :2.01.2
> avg_8_16x8_c   :   24.7   26.0
> avg_8_16x8_rvv_i32 :3.22.0
> avg_8_16x16_c  :   49.0   51.2
> avg_8_16x16_rvv_i32:5.73.2
> avg_8_16x32_c  :   97.7  102.5
> avg_8_16x32_rvv_i32:   10.75.7
> avg_8_16x64_c  :  220.5  214.2
> avg_8_16x64_rvv_i32:   48.2   39.5
> avg_8_16x128_c :  436.2  428.0
> avg_8_16x128_rvv_i32

Re: [FFmpeg-devel] [PATCH] avutil/executor: Fix missing check before using mutex

[Zhao Zhili]

> On Jul 1, 2024, at 21:14, Nuo Mi  wrote:
> 
> On Sun, Jun 30, 2024 at 6:45 PM Zhao Zhili  wrote:
> 
>> From: Zhao Zhili 
>> 
>> ---
>> The code can be simplified by always creating mutex/cond. I'm not sure
>> it worth the overhead. Please note !HAVE_THREADS don't have the same
>> problem since it has mock implementation of ff_mutex_lock/unlock.
>> 
> Hi Zhili,
> Thank you for the patch.
> Do we really need this? The lock/unlock/signal functions will return an
> error if the lock and condition variables are not initialized.

We have strict check in libavutil/thread.h, e.g.,

static inline int strict_pthread_mutex_lock(pthread_mutex_t *mutex)
{
ASSERT_PTHREAD(pthread_mutex_lock, mutex);
}

The strict check is enabled when configure --assert-level=2.

> 
>> 
>> libavutil/executor.c | 9 ++---
>> 1 file changed, 6 insertions(+), 3 deletions(-)
>> 
>> diff --git a/libavutil/executor.c b/libavutil/executor.c
>> index fb20104b58..89058fab2f 100644
>> --- a/libavutil/executor.c
>> +++ b/libavutil/executor.c
>> @@ -194,14 +194,17 @@ void av_executor_execute(AVExecutor *e, AVTask *t)
>> AVTaskCallbacks *cb = &e->cb;
>> AVTask **prev;
>> 
>> -ff_mutex_lock(&e->lock);
>> +if (e->thread_count)
>> +ff_mutex_lock(&e->lock);
>> if (t) {
>> for (prev = &e->tasks; *prev && cb->priority_higher(*prev, t);
>> prev = &(*prev)->next)
>> /* nothing */;
>> add_task(prev, t);
>> }
>> -ff_cond_signal(&e->cond);
>> -ff_mutex_unlock(&e->lock);
>> +if (e->thread_count) {
>> +ff_cond_signal(&e->cond);
>> +ff_mutex_unlock(&e->lock);
>> +}
>> 
>> if (!e->thread_count || !HAVE_THREADS) {
>> // We are running in a single-threaded environment, so we must
>> handle all tasks ourselves
>> --
>> 2.42.0
>> 
>> ___
>> 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 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/11] MAINTAINERS: Add Timo Rothenpieler to server admins

[Michael Niedermayer]

On Mon, Jul 01, 2024 at 01:07:12PM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-07-01 01:12:40)
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  MAINTAINERS | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index a82fa58c69f..57f437cd40e 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -34,8 +34,8 @@ Miscellaneous Areas
> >  ===
> >  
> >  documentation   Stefano Sabatini, Mike Melanson, 
> > Timothy Gu, Gyan Doshi
> > -project server day to day operationsÁrpád Gereöffy, Michael 
> > Niedermayer, Reimar Doeffinger, Alexander Strasser, Nikolay Aleksandrov
> > -project server emergencies  Árpád Gereöffy, Reimar Doeffinger, 
> > Alexander Strasser, Nikolay Aleksandrov
> > +project server day to day operationsÁrpád Gereöffy, Michael 
> > Niedermayer, Reimar Doeffinger, Alexander Strasser, Nikolay Aleksandrov, 
> > Timo Rothenpieler
> > +project server emergencies  Árpád Gereöffy, Reimar Doeffinger, 
> > Alexander Strasser, Nikolay Aleksandrov, Timo Rothenpieler
> 
> Those lists are getting rather long. Are all these people really active?
> If not, the lists should be trimmed down.

Reimar fixed an issue with the SSL certs less than 2 months ago
Alexander reviewed a patch to our apache configuration half a year ago
Nikolay updated the VM patchwork runs on to Ubuntu 22.04 less than a month ago
Timo setup a fatebeta.service systemd serivce yesterday
Arpad runs one of our name server slaves, he is IIRC not activly maintaining 
the main server currently

thx

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

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein


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] avutil/executor: Fix missing check before using mutex

[Nuo Mi]

On Mon, Jul 1, 2024 at 10:00 PM Zhao Zhili  wrote:

>
>
> > On Jul 1, 2024, at 21:14, Nuo Mi  wrote:
> >
> > On Sun, Jun 30, 2024 at 6:45 PM Zhao Zhili 
> wrote:
> >
> >> From: Zhao Zhili 
> >>
> >> ---
> >> The code can be simplified by always creating mutex/cond. I'm not sure
> >> it worth the overhead. Please note !HAVE_THREADS don't have the same
> >> problem since it has mock implementation of ff_mutex_lock/unlock.
> >>
> > Hi Zhili,
> > Thank you for the patch.
> > Do we really need this? The lock/unlock/signal functions will return an
> > error if the lock and condition variables are not initialized.
>
> We have strict check in libavutil/thread.h, e.g.,
>
> static inline int strict_pthread_mutex_lock(pthread_mutex_t *mutex)
> {
> ASSERT_PTHREAD(pthread_mutex_lock, mutex);
> }
>
> The strict check is enabled when configure --assert-level=2.
>
LGTM.
Thank you.

>
> >
> >>
> >> libavutil/executor.c | 9 ++---
> >> 1 file changed, 6 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/libavutil/executor.c b/libavutil/executor.c
> >> index fb20104b58..89058fab2f 100644
> >> --- a/libavutil/executor.c
> >> +++ b/libavutil/executor.c
> >> @@ -194,14 +194,17 @@ void av_executor_execute(AVExecutor *e, AVTask *t)
> >> AVTaskCallbacks *cb = &e->cb;
> >> AVTask **prev;
> >>
> >> -ff_mutex_lock(&e->lock);
> >> +if (e->thread_count)
> >> +ff_mutex_lock(&e->lock);
> >> if (t) {
> >> for (prev = &e->tasks; *prev && cb->priority_higher(*prev, t);
> >> prev = &(*prev)->next)
> >> /* nothing */;
> >> add_task(prev, t);
> >> }
> >> -ff_cond_signal(&e->cond);
> >> -ff_mutex_unlock(&e->lock);
> >> +if (e->thread_count) {
> >> +ff_cond_signal(&e->cond);
> >> +ff_mutex_unlock(&e->lock);
> >> +}
> >>
> >> if (!e->thread_count || !HAVE_THREADS) {
> >> // We are running in a single-threaded environment, so we must
> >> handle all tasks ourselves
> >> --
> >> 2.42.0
> >>
> >> ___
> >> 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 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] avdevice/v4l2: add limited support for multiplanar API

[Anton Khirnov]

Quoting Ramiro Polla (2024-06-28 13:47:13)
> On Thu, Jun 27, 2024 at 6:06 PM Anton Khirnov  wrote:
> > Quoting Ramiro Polla (2024-06-27 16:13:24)
> > > Is anyone fundamentally opposed to this approach to implement limited
> > > support for multiplanar API? I figure it could still be useful even
> > > when full multiplanar API support is implemented, because multiple
> > > memory buffers per packet will likely mean memcpy()s, which can be
> > > avoided if the plane count is one.
> >
> > Ideally this should be turned into a lavfi source, then multiple planes
> > can be exported individually.
> 
> Good idea. Is there any kind of roadmap on how this conversion from
> input device to source filter should take place, or is this something
> that still lacks consensus?

AFAIK there is a wide consensus that this is something that should be
done in general, though of course that does not directly translate into
volunteers actually doing the conversion.

> I assume we want to keep the functionality from the command line (so
> that "-i /dev/video0" would still use the lavfi source internally
> somehow). Would the code be shared between libraries, or would it be
> moved to lavfi and a wrapper written in lavd instead?

V4L2 is trickier than most devices, since it can also produce compressed
video. So at least that part of the functionaity will have to stay as a
demuxer.

-- 
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 v5] lavc/vvc_mc: R-V V avg w_avg

[Rémi Denis-Courmont]

Le maanantaina 1. heinäkuuta 2024, 16.40.29 EEST flow gg a écrit :
> > I am not sure what is_w means or serves here. If you need special cases,
> > this feels a bit out of place for this macro.
> 
> It is a special case added to merge the vset of avg and w_avg, how about
> giving it a default value so that it doesn't affect the use of other
> functions?

The original idea of having macros around vset(i)vli was to abstract away 
calculating LMUL from VL, SEW and VLEN, and by extension, calculate VTYPE from 
VL, SEW, TA, MA and VLEN. I just don't really see room for an extra parameter 
here and it is unclear what it does.

If there is a sound design reason why it's there, it should be commented 
better IMO. Otherwise it should not be there.

> > t0 is a link register, so the branch predictor will treat this a return,
> > but it seems to be a tail call instead.
> 
> Will this cause any issues? It will execute at a label, and after
> executing, there is a ret at the label.

Yes. Tail calls should incur no Return Address Stack action. But this incurs a 
pop, as per the "Unconditional Jumps" terminology in the RV32I spec.

-- 
Rémi Denis-Courmont
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/2] lavc/vc1dsp: fuse multiply-adds in R-V V inv_trans_4

[Rémi Denis-Courmont]

T-Head C908 (cycles):before   after
vc1dsp.vc1_inv_trans_4x4_rvv_i32: 128.0   120.0
vc1dsp.vc1_inv_trans_4x8_rvv_i32: 244.0   240.0
vc1dsp.vc1_inv_trans_8x4_rvv_i32: 239.2   235.2

-- 
レミ・デニ-クールモン
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 2/2] lavc/vc1dsp: fuse multiply-adds in R-V V inv_trans_8

[Rémi Denis-Courmont]

T-Head C908 (cycles) before  after
vc1dsp.vc1_inv_trans_4x8_rvv_i32: 240.0  228.0
vc1dsp.vc1_inv_trans_8x4_rvv_i32: 235.2  224.2
vc1dsp.vc1_inv_trans_8x8_rvv_i32: 340.7  327.2

-- 
Rémi Denis-Courmont
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] ffmpeg: Carry streamid as metadata key 'id'

[Anton Khirnov]

Quoting Tomas Härdin (2024-04-16 16:12:13)
> tis 2024-04-16 klockan 09:52 -0300 skrev James Almer:
> > On Tue, Apr 16, 2024 at 9:38 AM Anton Khirnov 
> > wrote:
> > 
> > > Quoting Tomas Härdin (2024-04-12 11:40:47)
> > > > This idea could be extended to other fields not presently
> > > > considered to
> > > > be metadata, that would be handy to treat as such.
> > > > 
> > > > I use the key "id" because ffprobe outputs id= for streamid.
> > > > Another
> > > > option could be to collect these types of metadata that go into
> > > > AVStream fields under a namespace like FFMPEG: or AVSTREAM: or
> > > > something, then delete all of them using AV_DICT_IGNORE_SUFFIX
> > > > near the
> > > > end of of_open() since they're for internal ffmpeg use.
> > > > 
> > > > The FATE change is just because av_dict() changes the order of
> > > > things
> > > > when elements are deleted.
> > > > 
> > > > /Tomas
> > > > 
> > > > From 7799f1b2eb8ab02e58118565f3e889fbe0d568a7 Mon Sep 17 00:00:00
> > > > 2001
> > > > From: =?UTF-8?q?Tomas=20H=C3=A4rdin?= 
> > > > Date: Fri, 12 Apr 2024 10:34:12 +0200
> > > > Subject: [PATCH] ffmpeg: Carry streamid as metadata key 'id'
> > > > 
> > > > This allows using -map_metadata and -metadata to copy/set
> > > > streamids
> > > (PIDs).
> > > 
> > > I dislike this patch, metadata is the wrong place for such
> > > information.
> 
> Seems like a matter of taste to me, but maybe I'm missing something

It's not just a matter of taste - it's happened several times already
that people (ab)used metadata to carry structured information and then
it turned out it was a bad idea and we had to change it to a real API.

Metadata really should only be used for unstructured user-facing
information like title/author/etc.. It's a terrible mechanism for other
usecases, because it's an implicit API hidden from the compiler, with no
type information, stability guarantees, deprecation mechanisms, etc. Not
to mention it forces users to parse and serialize strings, which is a
massive pain and a constant source of bugs, especially in C.

> In the very common case where users want to copy PIDs from inputs to
> outputs, implementing -map_streamid seems a bit silly. Consider also
> the case where the user wants to copy codec and bitrate from some
> source stream, such as when filtering audio. It would be nice if such
> operations were handled by a common mechanism. Call it -map_params
> perhaps

How long until ffmpeg CLI options are turing complete?

-- 
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] ffmpeg: Carry streamid as metadata key 'id'

[Tomas Härdin]

mån 2024-07-01 klockan 16:51 +0200 skrev Anton Khirnov:
> Quoting Tomas Härdin (2024-04-16 16:12:13)
> > tis 2024-04-16 klockan 09:52 -0300 skrev James Almer:
> > > On Tue, Apr 16, 2024 at 9:38 AM Anton Khirnov 
> > > wrote:
> > > 
> > > > Quoting Tomas Härdin (2024-04-12 11:40:47)
> > > > > This idea could be extended to other fields not presently
> > > > > considered to
> > > > > be metadata, that would be handy to treat as such.
> > > > > 
> > > > > I use the key "id" because ffprobe outputs id= for streamid.
> > > > > Another
> > > > > option could be to collect these types of metadata that go
> > > > > into
> > > > > AVStream fields under a namespace like FFMPEG: or AVSTREAM:
> > > > > or
> > > > > something, then delete all of them using
> > > > > AV_DICT_IGNORE_SUFFIX
> > > > > near the
> > > > > end of of_open() since they're for internal ffmpeg use.
> > > > > 
> > > > > The FATE change is just because av_dict() changes the order
> > > > > of
> > > > > things
> > > > > when elements are deleted.
> > > > > 
> > > > > /Tomas
> > > > > 
> > > > > From 7799f1b2eb8ab02e58118565f3e889fbe0d568a7 Mon Sep 17
> > > > > 00:00:00
> > > > > 2001
> > > > > From: =?UTF-8?q?Tomas=20H=C3=A4rdin?= 
> > > > > Date: Fri, 12 Apr 2024 10:34:12 +0200
> > > > > Subject: [PATCH] ffmpeg: Carry streamid as metadata key 'id'
> > > > > 
> > > > > This allows using -map_metadata and -metadata to copy/set
> > > > > streamids
> > > > (PIDs).
> > > > 
> > > > I dislike this patch, metadata is the wrong place for such
> > > > information.
> > 
> > Seems like a matter of taste to me, but maybe I'm missing something
> 
> It's not just a matter of taste - it's happened several times already
> that people (ab)used metadata to carry structured information and
> then
> it turned out it was a bad idea and we had to change it to a real
> API.
> 
> Metadata really should only be used for unstructured user-facing
> information like title/author/etc.. It's a terrible mechanism for
> other
> usecases, because it's an implicit API hidden from the compiler, with
> no
> type information, stability guarantees, deprecation mechanisms, etc.
> Not
> to mention it forces users to parse and serialize strings, which is a
> massive pain and a constant source of bugs, especially in C.
> 
> > In the very common case where users want to copy PIDs from inputs
> > to
> > outputs, implementing -map_streamid seems a bit silly. Consider
> > also
> > the case where the user wants to copy codec and bitrate from some
> > source stream, such as when filtering audio. It would be nice if
> > such
> > operations were handled by a common mechanism. Call it -map_params
> > perhaps
> 
> How long until ffmpeg CLI options are turing complete?

*cough* lavu/eval.* *cough*

But yeah there's probably no way to make everyone happy with something
like this. In practice plenty of users maintain their own forks to
cover their own obscure use-cases

/Tomas

___
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] lavc/h264dsp: R-V V 8-bit MBAFF loop filter

[Rémi Denis-Courmont]

Performance is (unfortunately) the same as with non-MBAFF, since the
hardware under test does not short-circuit vector tail calculations.
(IMO, a generic solution or work-around should be agreed on, rather
than bespoke approaches all over the place.)
---
 libavcodec/riscv/h264dsp_init.c |  4 
 libavcodec/riscv/h264dsp_rvv.S  | 14 ++
 2 files changed, 18 insertions(+)

diff --git a/libavcodec/riscv/h264dsp_init.c b/libavcodec/riscv/h264dsp_init.c
index 0d4d541992..ab412a9924 100644
--- a/libavcodec/riscv/h264dsp_init.c
+++ b/libavcodec/riscv/h264dsp_init.c
@@ -31,6 +31,8 @@ void ff_h264_v_loop_filter_luma_8_rvv(uint8_t *pix, ptrdiff_t 
stride,
   int alpha, int beta, int8_t *tc0);
 void ff_h264_h_loop_filter_luma_8_rvv(uint8_t *pix, ptrdiff_t stride,
   int alpha, int beta, int8_t *tc0);
+void ff_h264_h_loop_filter_luma_mbaff_8_rvv(uint8_t *pix, ptrdiff_t stride,
+int alpha, int beta, int8_t *tc0);
 
 extern int ff_startcode_find_candidate_rvb(const uint8_t *, int);
 extern int ff_startcode_find_candidate_rvv(const uint8_t *, int);
@@ -48,6 +50,8 @@ av_cold void ff_h264dsp_init_riscv(H264DSPContext *dsp, const 
int bit_depth,
 if (bit_depth == 8 && ff_rv_vlen_least(128)) {
 dsp->h264_v_loop_filter_luma = ff_h264_v_loop_filter_luma_8_rvv;
 dsp->h264_h_loop_filter_luma = ff_h264_h_loop_filter_luma_8_rvv;
+dsp->h264_h_loop_filter_luma_mbaff =
+ff_h264_h_loop_filter_luma_mbaff_8_rvv;
 }
 dsp->startcode_find_candidate = ff_startcode_find_candidate_rvv;
 }
diff --git a/libavcodec/riscv/h264dsp_rvv.S b/libavcodec/riscv/h264dsp_rvv.S
index 77bf40db1f..008f33d4b8 100644
--- a/libavcodec/riscv/h264dsp_rvv.S
+++ b/libavcodec/riscv/h264dsp_rvv.S
@@ -138,3 +138,17 @@ func ff_h264_h_loop_filter_luma_8_rvv, zve32x
 vssseg6e8.v v8, (a0), a1
 ret
 endfunc
+
+func ff_h264_h_loop_filter_luma_mbaff_8_rvv, zve32x
+vsetivlizero, 4, e16, m1, ta, ma
+vle8.v  v4, (a4)
+li  t0, 0x0101
+vzext.vf2   v6, v4
+addia0, a0, -3
+vmul.vx v6, v6, t0# tc_orig
+vsetivlizero, 8, e8, m1, ta, ma
+vlsseg6e8.v v8, (a0), a1
+jal t0, ff_h264_loop_filter_luma_8_rvv
+vssseg6e8.v v8, (a0), a1
+ret
+endfunc
-- 
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] [PATCHv2 1/2] lavc/h264dsp: R-V V 8-bit luma loop filter

[Rémi Denis-Courmont]

T-Head C908 (cycles):
h264_h_loop_filter_luma_8bpp_c:   297.5
h264_h_loop_filter_luma_8bpp_rvv_i32: 369.2
h264_v_loop_filter_luma_8bpp_c:   862.7
h264_v_loop_filter_luma_8bpp_rvv_i32: 199.7

Performance in the horizontal scenario seems worse than scalar. x86
SSE2 and AVX optimisations are similarly affected. This is presumably
caused by unlucky inputs from checkasm, such that the C code
short-circuits almost all filter calculations.

Changes since version 1:
1) Multiplies rather than shuffles to extend the TC array.
2) Get rid of the weird MBAFF macros (as a consequence of (1)).

---
 libavcodec/riscv/Makefile   |   1 +
 libavcodec/riscv/h264dsp_init.c |  13 ++-
 libavcodec/riscv/h264dsp_rvv.S  | 140 
 3 files changed, 153 insertions(+), 1 deletion(-)
 create mode 100644 libavcodec/riscv/h264dsp_rvv.S

diff --git a/libavcodec/riscv/Makefile b/libavcodec/riscv/Makefile
index c180223141..a1510e8c6e 100644
--- a/libavcodec/riscv/Makefile
+++ b/libavcodec/riscv/Makefile
@@ -31,6 +31,7 @@ RVV-OBJS-$(CONFIG_H263DSP) += riscv/h263dsp_rvv.o
 OBJS-$(CONFIG_H264CHROMA) += riscv/h264_chroma_init_riscv.o
 RVV-OBJS-$(CONFIG_H264CHROMA) += riscv/h264_mc_chroma.o
 OBJS-$(CONFIG_H264DSP) += riscv/h264dsp_init.o
+RVV-OBJS-$(CONFIG_H264DSP) += riscv/h264dsp_rvv.o
 OBJS-$(CONFIG_HUFFYUV_DECODER) += riscv/huffyuvdsp_init.o
 RVV-OBJS-$(CONFIG_HUFFYUV_DECODER) += riscv/huffyuvdsp_rvv.o
 OBJS-$(CONFIG_IDCTDSP) += riscv/idctdsp_init.o
diff --git a/libavcodec/riscv/h264dsp_init.c b/libavcodec/riscv/h264dsp_init.c
index dbbf3db400..0d4d541992 100644
--- a/libavcodec/riscv/h264dsp_init.c
+++ b/libavcodec/riscv/h264dsp_init.c
@@ -24,8 +24,14 @@
 
 #include "libavutil/attributes.h"
 #include "libavutil/cpu.h"
+#include "libavutil/riscv/cpu.h"
 #include "libavcodec/h264dsp.h"
 
+void ff_h264_v_loop_filter_luma_8_rvv(uint8_t *pix, ptrdiff_t stride,
+  int alpha, int beta, int8_t *tc0);
+void ff_h264_h_loop_filter_luma_8_rvv(uint8_t *pix, ptrdiff_t stride,
+  int alpha, int beta, int8_t *tc0);
+
 extern int ff_startcode_find_candidate_rvb(const uint8_t *, int);
 extern int ff_startcode_find_candidate_rvv(const uint8_t *, int);
 
@@ -38,8 +44,13 @@ av_cold void ff_h264dsp_init_riscv(H264DSPContext *dsp, 
const int bit_depth,
 if (flags & AV_CPU_FLAG_RVB_BASIC)
 dsp->startcode_find_candidate = ff_startcode_find_candidate_rvb;
 # if HAVE_RVV
-if (flags & AV_CPU_FLAG_RVV_I32)
+if (flags & AV_CPU_FLAG_RVV_I32) {
+if (bit_depth == 8 && ff_rv_vlen_least(128)) {
+dsp->h264_v_loop_filter_luma = ff_h264_v_loop_filter_luma_8_rvv;
+dsp->h264_h_loop_filter_luma = ff_h264_h_loop_filter_luma_8_rvv;
+}
 dsp->startcode_find_candidate = ff_startcode_find_candidate_rvv;
+}
 # endif
 #endif
 }
diff --git a/libavcodec/riscv/h264dsp_rvv.S b/libavcodec/riscv/h264dsp_rvv.S
new file mode 100644
index 00..77bf40db1f
--- /dev/null
+++ b/libavcodec/riscv/h264dsp_rvv.S
@@ -0,0 +1,140 @@
+/*
+ * Copyright © 2024 Rémi Denis-Courmont.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright notice,
+ *this list of conditions and the following disclaimer.
+ *
+ * 2. Redistributions in binary form must reproduce the above copyright notice,
+ *this list of conditions and the following disclaimer in the documentation
+ *and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include "libavutil/riscv/asm.S"
+
+.variant_cc ff_h264_loop_filter_luma_8_rvv
+func ff_h264_loop_filter_luma_8_rvv, zve32x
+# p2: v8, p1: v9, p0: v10, q0: v11, q1: v12, q2: v13
+# alpha: a2, beta: a3, tc_orig: v6
+csrwivxrm, 0
+vaaddu.vvv14, v10, v11 # (p0 + q0 + 1) / 2
+vwsubu.vvv16, v9, v12
+vwaddu.vvv18, v8, v14
+vwaddu.vvv20, v13, v14
+vnsra.wi v24, v16, 2   # (p1 - q1) / 4
+vnsrl.wi v14, v18, 1
+vnsrl.wi v15

Re: [FFmpeg-devel] [PATCH, v2] avformat/mov: get heif image rotation from irot box

[James Almer]

On 5/27/2024 12:22 PM, Hacene Bouaroua wrote:

parse irot box to get the transformative heif item rotation angle.

Signed-off-by: Hacene Bouaroua 
---
  libavformat/avformat.h |  5 +
  libavformat/isom.h |  1 +
  libavformat/mov.c  | 25 +
  3 files changed, 31 insertions(+)

diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 8afdcd9fd0..615650ddcb 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1077,6 +1077,11 @@ typedef struct AVStreamGroupTileGrid {
   * final image before presentation.
   */
  int height;
+/**
+ * the angle which the reconstructed image is initially rotated
+ * (in anti-clockwise direction) in units of degrees.
+ */
+int rotation;


This should probably be an AVRational (With range [-180.0, 180.0]), so 
you can easily pass av_q2d(rotation) to av_display_rotation_set().



  } AVStreamGroupTileGrid;
  
  enum AVStreamGroupParamsType {

diff --git a/libavformat/isom.h b/libavformat/isom.h
index c0a5788e08..757e3f8738 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -277,6 +277,7 @@ typedef struct HEIFItem {
  int64_t extent_offset;
  int width;
  int height;
+int rotation;
  int type;
  int is_idat_relative;
  } HEIFItem;
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 45eca74d1d..5f04e68f88 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -8398,6 +8398,27 @@ static int mov_read_ispe(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
  return 0;
  }
  
+static int mov_read_irot(MOVContext *c, AVIOContext *pb, MOVAtom atom)

+{
+uint32_t angle;
+
+angle = avio_r8(pb);


avio_r8(pb) & 0x3. The upper bits are reserved.


+
+av_log(c->fc, AV_LOG_TRACE, "irot: item_id %d, angle %u\n",
+   c->cur_item_id, angle);
+
+for (int i = 0; i < c->nb_heif_item; i++) {
+if (c->heif_item[i].item_id == c->cur_item_id) {
+// angle * 90 specifies the angle (in anti-clockwise direction)
+// in units of degrees.
+c->heif_item[i].rotation  = angle * 90; > +break;
+}
+}
+
+return 0;
+}
+
  static int mov_read_iprp(MOVContext *c, AVIOContext *pb, MOVAtom atom)
  {
  typedef struct MOVAtoms {
@@ -8615,6 +8636,7 @@ static const MOVParseTableEntry mov_default_parse_table[] 
= {
  { MKTAG('i','d','a','t'), mov_read_idat },
  { MKTAG('i','r','e','f'), mov_read_iref },
  { MKTAG('i','s','p','e'), mov_read_ispe },
+{ MKTAG('i','r','o','t'), mov_read_irot },
  { MKTAG('i','p','r','p'), mov_read_iprp },
  { MKTAG('i','i','n','f'), mov_read_iinf },
  { MKTAG('a','m','v','e'), mov_read_amve }, /* ambient viewing environment box 
*/
@@ -9315,6 +9337,9 @@ static int read_image_grid(AVFormatContext *s, const 
HEIFGrid *grid,
  tile_grid->width  = (flags & 1) ? avio_rb32(s->pb) : avio_rb16(s->pb);
  tile_grid->height = (flags & 1) ? avio_rb32(s->pb) : avio_rb16(s->pb);
  
+/* rotation */

+tile_grid->rotation = item->rotation;
+
  av_log(c->fc, AV_LOG_TRACE, "grid: grid_rows %d grid_cols %d output_width %d 
output_height %d\n",
 tile_rows, tile_cols, tile_grid->width, tile_grid->height);
  

___
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 v5] lavc/vvc_mc: R-V V avg w_avg

[uk7b]

From: sunyuechi 

  C908   X60
avg_8_2x2_c:1.21.0
avg_8_2x2_rvv_i32  :1.01.0
avg_8_2x4_c:2.02.0
avg_8_2x4_rvv_i32  :1.51.2
avg_8_2x8_c:3.74.0
avg_8_2x8_rvv_i32  :2.02.0
avg_8_2x16_c   :7.27.7
avg_8_2x16_rvv_i32 :3.23.0
avg_8_2x32_c   :   14.5   15.2
avg_8_2x32_rvv_i32 :5.75.0
avg_8_2x64_c   :   50.0   45.2
avg_8_2x64_rvv_i32 :   41.5   32.5
avg_8_2x128_c  :  101.5   84.2
avg_8_2x128_rvv_i32:   89.5   73.2
avg_8_4x2_c:2.02.0
avg_8_4x2_rvv_i32  :1.01.0
avg_8_4x4_c:3.53.5
avg_8_4x4_rvv_i32  :1.51.2
avg_8_4x8_c:6.77.0
avg_8_4x8_rvv_i32  :2.01.7
avg_8_4x16_c   :   13.2   14.0
avg_8_4x16_rvv_i32 :3.23.0
avg_8_4x32_c   :   26.2   27.7
avg_8_4x32_rvv_i32 :5.75.0
avg_8_4x64_c   :   75.0   66.0
avg_8_4x64_rvv_i32 :   40.2   33.0
avg_8_4x128_c  :  144.5  128.0
avg_8_4x128_rvv_i32:   89.5   78.7
avg_8_8x2_c:3.23.5
avg_8_8x2_rvv_i32  :1.21.0
avg_8_8x4_c:6.56.7
avg_8_8x4_rvv_i32  :1.51.5
avg_8_8x8_c:   12.7   13.2
avg_8_8x8_rvv_i32  :2.21.7
avg_8_8x16_c   :   25.2   26.5
avg_8_8x16_rvv_i32 :3.72.7
avg_8_8x32_c   :   50.2   52.7
avg_8_8x32_rvv_i32 :6.55.0
avg_8_8x64_c   :  120.2  117.7
avg_8_8x64_rvv_i32 :   45.2   39.2
avg_8_8x128_c  :  223.0  233.5
avg_8_8x128_rvv_i32:   80.0   73.2
avg_8_16x2_c   :6.26.5
avg_8_16x2_rvv_i32 :1.51.0
avg_8_16x4_c   :   12.5   12.7
avg_8_16x4_rvv_i32 :2.01.2
avg_8_16x8_c   :   24.7   26.0
avg_8_16x8_rvv_i32 :3.22.0
avg_8_16x16_c  :   49.0   51.2
avg_8_16x16_rvv_i32:5.73.2
avg_8_16x32_c  :   97.7  102.5
avg_8_16x32_rvv_i32:   10.75.7
avg_8_16x64_c  :  220.5  214.2
avg_8_16x64_rvv_i32:   48.2   39.5
avg_8_16x128_c :  436.2  428.0
avg_8_16x128_rvv_i32   :   97.2   77.0
avg_8_32x2_c   :   12.2   12.7
avg_8_32x2_rvv_i32 :2.01.2
avg_8_32x4_c   :   24.5   25.5
avg_8_32x4_rvv_i32 :3.21.7
avg_8_32x8_c   :   48.5   50.7
avg_8_32x8_rvv_i32 :5.72.7
avg_8_32x16_c  :   96.5  101.2
avg_8_32x16_rvv_i32:   10.25.0
avg_8_32x32_c  :  192.5  202.2
avg_8_32x32_rvv_i32:   20.09.5
avg_8_32x64_c  :  405.7  404.5
avg_8_32x64_rvv_i32:   72.5   40.2
avg_8_32x128_c :  821.0  832.2
avg_8_32x128_rvv_i32   :  136.2   75.7
avg_8_64x2_c   :   24.0   25.2
avg_8_64x2_rvv_i32 :3.21.7
avg_8_64x4_c   :   48.5   51.0
avg_8_64x4_rvv_i32   

Re: [FFmpeg-devel] [PATCH v5] lavc/vvc_mc: R-V V avg w_avg

[flow gg]

I reviewed it again, the purpose of is_w is to limit lmul to a maximum of
1/4 of vlen, to prevent vector register shortage, which can also be
considered as vset limiting lmul. I renamed it to quarter_len_limit.

t0 is changed to t1.

 于2024年7月2日周二 00:07写道：

> From: sunyuechi 
>
>   C908   X60
> avg_8_2x2_c:1.21.0
> avg_8_2x2_rvv_i32  :1.01.0
> avg_8_2x4_c:2.02.0
> avg_8_2x4_rvv_i32  :1.51.2
> avg_8_2x8_c:3.74.0
> avg_8_2x8_rvv_i32  :2.02.0
> avg_8_2x16_c   :7.27.7
> avg_8_2x16_rvv_i32 :3.23.0
> avg_8_2x32_c   :   14.5   15.2
> avg_8_2x32_rvv_i32 :5.75.0
> avg_8_2x64_c   :   50.0   45.2
> avg_8_2x64_rvv_i32 :   41.5   32.5
> avg_8_2x128_c  :  101.5   84.2
> avg_8_2x128_rvv_i32:   89.5   73.2
> avg_8_4x2_c:2.02.0
> avg_8_4x2_rvv_i32  :1.01.0
> avg_8_4x4_c:3.53.5
> avg_8_4x4_rvv_i32  :1.51.2
> avg_8_4x8_c:6.77.0
> avg_8_4x8_rvv_i32  :2.01.7
> avg_8_4x16_c   :   13.2   14.0
> avg_8_4x16_rvv_i32 :3.23.0
> avg_8_4x32_c   :   26.2   27.7
> avg_8_4x32_rvv_i32 :5.75.0
> avg_8_4x64_c   :   75.0   66.0
> avg_8_4x64_rvv_i32 :   40.2   33.0
> avg_8_4x128_c  :  144.5  128.0
> avg_8_4x128_rvv_i32:   89.5   78.7
> avg_8_8x2_c:3.23.5
> avg_8_8x2_rvv_i32  :1.21.0
> avg_8_8x4_c:6.56.7
> avg_8_8x4_rvv_i32  :1.51.5
> avg_8_8x8_c:   12.7   13.2
> avg_8_8x8_rvv_i32  :2.21.7
> avg_8_8x16_c   :   25.2   26.5
> avg_8_8x16_rvv_i32 :3.72.7
> avg_8_8x32_c   :   50.2   52.7
> avg_8_8x32_rvv_i32 :6.55.0
> avg_8_8x64_c   :  120.2  117.7
> avg_8_8x64_rvv_i32 :   45.2   39.2
> avg_8_8x128_c  :  223.0  233.5
> avg_8_8x128_rvv_i32:   80.0   73.2
> avg_8_16x2_c   :6.26.5
> avg_8_16x2_rvv_i32 :1.51.0
> avg_8_16x4_c   :   12.5   12.7
> avg_8_16x4_rvv_i32 :2.01.2
> avg_8_16x8_c   :   24.7   26.0
> avg_8_16x8_rvv_i32 :3.22.0
> avg_8_16x16_c  :   49.0   51.2
> avg_8_16x16_rvv_i32:5.73.2
> avg_8_16x32_c  :   97.7  102.5
> avg_8_16x32_rvv_i32:   10.75.7
> avg_8_16x64_c  :  220.5  214.2
> avg_8_16x64_rvv_i32:   48.2   39.5
> avg_8_16x128_c :  436.2  428.0
> avg_8_16x128_rvv_i32   :   97.2   77.0
> avg_8_32x2_c   :   12.2   12.7
> avg_8_32x2_rvv_i32 :2.01.2
> avg_8_32x4_c   :   24.5   25.5
> avg_8_32x4_rvv_i32 :3.21.7
> avg_8_32x8_c   :   48.5   50.7
> avg_8_32x8_rvv_i32 :5.72.7
> avg_8_32x16_c  :   96.5  101.2
> avg_8_32x16_rvv_i32:   10.25.0
> avg_8_32x32_c  :  192.5  202.2
> avg_8_32x32_rvv_i32:   20.09.5
> avg_8_32x64_c  :  405.7  404.5
> avg_8_32x64_rvv_i32 

Re: [FFmpeg-devel] [FFmpeg-cvslog] checkasm: add tests for yuv2rgb

[Ramiro Polla]

On Fri, Jun 28, 2024 at 2:50 PM Ramiro Polla  wrote:
>
> ffmpeg | branch: master | Ramiro Polla  | Sun Jun 16 
> 22:40:13 2024 +0200| [1fb77347c8d96f4feff8f9328b40e6ee71191ac1] | committer: 
> Ramiro Polla
>
> checkasm: add tests for yuv2rgb
>
> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=1fb77347c8d96f4feff8f9328b40e6ee71191ac1
> ---
>
>  tests/checkasm/Makefile |   2 +-
>  tests/checkasm/checkasm.c   |   1 +
>  tests/checkasm/checkasm.h   |   1 +
>  tests/checkasm/sw_yuv2rgb.c | 211 
> 
>  tests/fate/checkasm.mak |   1 +
>  5 files changed, 215 insertions(+), 1 deletion(-)

fate-checkasm-sw_yuv2rgb is failing on loongarch after this commit and
that makes patchwork unhappy. Could someone have a look?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: Fix segfault with intra-only

[Josh Allmann]

On Thu, 20 Jun 2024 at 17:39, Josh Allmann  wrote:
>
> In intra-only mode, frameIntervalP is 0, which means the frame
> data array is smaller than the number of surfaces. This causes a
> crash when closing the encoder.
>
> Fix this by making sure the frame data array is at least as big as
> the number of surfaces.
> ---
>  libavcodec/nvenc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
> index a9945355ba..93e87b21db 100644
> --- a/libavcodec/nvenc.c
> +++ b/libavcodec/nvenc.c
> @@ -1021,7 +1021,7 @@ static av_cold int nvenc_recalc_surfaces(AVCodecContext 
> *avctx)
>
>  // Output in the worst case will only start when the surface buffer is 
> completely full.
>  // Hence we need to keep at least the max amount of surfaces plus the 
> max reorder delay around.
> -ctx->frame_data_array_nb = ctx->nb_surfaces + 
> ctx->encode_config.frameIntervalP - 1;
> +ctx->frame_data_array_nb = FFMAX(ctx->nb_surfaces, ctx->nb_surfaces + 
> ctx->encode_config.frameIntervalP - 1);
>
>  return 0;
>  }
> --
> 2.39.2
>

Hello,

Ping for review. This patch fixes an easily triggered crash with nvenc
in intra-only mode, eg

ffmpeg -i  -c:v h264_nvenc -g 0 

Josh
___
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] [RFC] [PATCH 1/4] lavc/h264_loopfilter: expose tc0_table (for checkasm)

[Rémi Denis-Courmont]

---
 libavcodec/h264_loopfilter.c | 50 ++--
 libavcodec/h264dsp.h |  2 ++
 2 files changed, 27 insertions(+), 25 deletions(-)

diff --git a/libavcodec/h264_loopfilter.c b/libavcodec/h264_loopfilter.c
index c164a289b7..9481882dd0 100644
--- a/libavcodec/h264_loopfilter.c
+++ b/libavcodec/h264_loopfilter.c
@@ -66,7 +66,7 @@ static const uint8_t beta_table[52*3] = {
 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18,
 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18,
 };
-static const uint8_t tc0_table[52*3][4] = {
+const int8_t ff_h264_tc0_table[52*3][4] = {
 {-1, 0, 0, 0 }, {-1, 0, 0, 0 }, {-1, 0, 0, 0 }, {-1, 0, 0, 0 }, {-1, 0, 0, 
0 }, {-1, 0, 0, 0 },
 {-1, 0, 0, 0 }, {-1, 0, 0, 0 }, {-1, 0, 0, 0 }, {-1, 0, 0, 0 }, {-1, 0, 0, 
0 }, {-1, 0, 0, 0 },
 {-1, 0, 0, 0 }, {-1, 0, 0, 0 }, {-1, 0, 0, 0 }, {-1, 0, 0, 0 }, {-1, 0, 0, 
0 }, {-1, 0, 0, 0 },
@@ -109,10 +109,10 @@ static av_always_inline void filter_mb_edgev(uint8_t 
*pix, int stride,
 
 if( bS[0] < 4 || !intra ) {
 int8_t tc[4];
-tc[0] = tc0_table[index_a][bS[0]];
-tc[1] = tc0_table[index_a][bS[1]];
-tc[2] = tc0_table[index_a][bS[2]];
-tc[3] = tc0_table[index_a][bS[3]];
+tc[0] = ff_h264_tc0_table[index_a][bS[0]];
+tc[1] = ff_h264_tc0_table[index_a][bS[1]];
+tc[2] = ff_h264_tc0_table[index_a][bS[2]];
+tc[3] = ff_h264_tc0_table[index_a][bS[3]];
 h->h264dsp.h264_h_loop_filter_luma(pix, stride, alpha, beta, tc);
 } else {
 h->h264dsp.h264_h_loop_filter_luma_intra(pix, stride, alpha, beta);
@@ -131,10 +131,10 @@ static av_always_inline void filter_mb_edgecv(uint8_t 
*pix, int stride,
 
 if( bS[0] < 4 || !intra ) {
 int8_t tc[4];
-tc[0] = tc0_table[index_a][bS[0]]+1;
-tc[1] = tc0_table[index_a][bS[1]]+1;
-tc[2] = tc0_table[index_a][bS[2]]+1;
-tc[3] = tc0_table[index_a][bS[3]]+1;
+tc[0] = ff_h264_tc0_table[index_a][bS[0]]+1;
+tc[1] = ff_h264_tc0_table[index_a][bS[1]]+1;
+tc[2] = ff_h264_tc0_table[index_a][bS[2]]+1;
+tc[3] = ff_h264_tc0_table[index_a][bS[3]]+1;
 h->h264dsp.h264_h_loop_filter_chroma(pix, stride, alpha, beta, tc);
 } else {
 h->h264dsp.h264_h_loop_filter_chroma_intra(pix, stride, alpha, beta);
@@ -154,10 +154,10 @@ static av_always_inline void filter_mb_mbaff_edgev(const 
H264Context *h, uint8_t
 
 if( bS[0] < 4 || !intra ) {
 int8_t tc[4];
-tc[0] = tc0_table[index_a][bS[0*bsi]];
-tc[1] = tc0_table[index_a][bS[1*bsi]];
-tc[2] = tc0_table[index_a][bS[2*bsi]];
-tc[3] = tc0_table[index_a][bS[3*bsi]];
+tc[0] = ff_h264_tc0_table[index_a][bS[0*bsi]];
+tc[1] = ff_h264_tc0_table[index_a][bS[1*bsi]];
+tc[2] = ff_h264_tc0_table[index_a][bS[2*bsi]];
+tc[3] = ff_h264_tc0_table[index_a][bS[3*bsi]];
 h->h264dsp.h264_h_loop_filter_luma_mbaff(pix, stride, alpha, beta, tc);
 } else {
 h->h264dsp.h264_h_loop_filter_luma_mbaff_intra(pix, stride, alpha, 
beta);
@@ -177,10 +177,10 @@ static av_always_inline void filter_mb_mbaff_edgecv(const 
H264Context *h,
 
 if( bS[0] < 4 || !intra ) {
 int8_t tc[4];
-tc[0] = tc0_table[index_a][bS[0*bsi]] + 1;
-tc[1] = tc0_table[index_a][bS[1*bsi]] + 1;
-tc[2] = tc0_table[index_a][bS[2*bsi]] + 1;
-tc[3] = tc0_table[index_a][bS[3*bsi]] + 1;
+tc[0] = ff_h264_tc0_table[index_a][bS[0*bsi]] + 1;
+tc[1] = ff_h264_tc0_table[index_a][bS[1*bsi]] + 1;
+tc[2] = ff_h264_tc0_table[index_a][bS[2*bsi]] + 1;
+tc[3] = ff_h264_tc0_table[index_a][bS[3*bsi]] + 1;
 h->h264dsp.h264_h_loop_filter_chroma_mbaff(pix, stride, alpha, beta, 
tc);
 } else {
 h->h264dsp.h264_h_loop_filter_chroma_mbaff_intra(pix, stride, alpha, 
beta);
@@ -199,10 +199,10 @@ static av_always_inline void filter_mb_edgeh(uint8_t 
*pix, int stride,
 
 if( bS[0] < 4 || !intra ) {
 int8_t tc[4];
-tc[0] = tc0_table[index_a][bS[0]];
-tc[1] = tc0_table[index_a][bS[1]];
-tc[2] = tc0_table[index_a][bS[2]];
-tc[3] = tc0_table[index_a][bS[3]];
+tc[0] = ff_h264_tc0_table[index_a][bS[0]];
+tc[1] = ff_h264_tc0_table[index_a][bS[1]];
+tc[2] = ff_h264_tc0_table[index_a][bS[2]];
+tc[3] = ff_h264_tc0_table[index_a][bS[3]];
 h->h264dsp.h264_v_loop_filter_luma(pix, stride, alpha, beta, tc);
 } else {
 h->h264dsp.h264_v_loop_filter_luma_intra(pix, stride, alpha, beta);
@@ -221,10 +221,10 @@ static av_always_inline void filter_mb_edgech(uint8_t 
*pix, int stride,
 
 if( bS[0] < 4 || !intra ) {
 int8_t tc[4];
-tc[0] = tc0_table[index_a][bS[0]]+1;
-tc[1] = tc0_table[index_a][bS[1]]+1;
-tc[2] = tc0_table[index_a][bS[2]]+1;
-tc[3] = tc0_table[index_a][bS[3]]+1;
+tc[0] = ff_h264_tc0_table[index_a][bS[0]]+1;
+tc[1] = 

[FFmpeg-devel] [PATCH 2/4] lavc/h264_loopfilter: align TC and bS tables

[Rémi Denis-Courmont]

---
 libavcodec/h264_loopfilter.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavcodec/h264_loopfilter.c b/libavcodec/h264_loopfilter.c
index 9481882dd0..96f572c1d2 100644
--- a/libavcodec/h264_loopfilter.c
+++ b/libavcodec/h264_loopfilter.c
@@ -66,7 +66,7 @@ static const uint8_t beta_table[52*3] = {
 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18,
 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18,
 };
-const int8_t ff_h264_tc0_table[52*3][4] = {
+const DECLARE_ALIGNED_4(int8_t, ff_h264_tc0_table)[52*3][4] = {
 {-1, 0, 0, 0 }, {-1, 0, 0, 0 }, {-1, 0, 0, 0 }, {-1, 0, 0, 0 }, {-1, 0, 0, 
0 }, {-1, 0, 0, 0 },
 {-1, 0, 0, 0 }, {-1, 0, 0, 0 }, {-1, 0, 0, 0 }, {-1, 0, 0, 0 }, {-1, 0, 0, 
0 }, {-1, 0, 0, 0 },
 {-1, 0, 0, 0 }, {-1, 0, 0, 0 }, {-1, 0, 0, 0 }, {-1, 0, 0, 0 }, {-1, 0, 0, 
0 }, {-1, 0, 0, 0 },
@@ -266,8 +266,8 @@ static av_always_inline void 
h264_filter_mb_fast_internal(const H264Context *h,
 qpc1 = (qpc + qpc1 + 1) >> 1;
 
 if( IS_INTRA(mb_type) ) {
-static const int16_t bS4[4] = {4,4,4,4};
-static const int16_t bS3[4] = {3,3,3,3};
+static const DECLARE_ALIGNED_8(int16_t, bS4)[4] = {4,4,4,4};
+static const DECLARE_ALIGNED_8(int16_t, bS3)[4] = {3,3,3,3};
 const int16_t *bSH = FIELD_PICTURE(h) ? bS3 : bS4;
 if(left_type)
 filter_mb_edgev( &img_y[4*0

[FFmpeg-devel] [PATCH 3/4] WIP: lavc/h264dsp: take over looking up TC values

[Rémi Denis-Courmont]

This moves the look-up of TC values from bS from the generic C loop
filter code to the DSP functions. This (potentially) eliminates a
round-trip to the stack for the looked-up values.

This is work-in-progress. 8 functions need to be updated and this
only updates one of them. Also updating the platform-specific
optimisations is left as an exercise for a future version, as is
updating checkasm.
---
 libavcodec/h264_loopfilter.c  | 8 ++--
 libavcodec/h264dsp.h  | 4 +++-
 libavcodec/h264dsp_template.c | 9 +++--
 3 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/libavcodec/h264_loopfilter.c b/libavcodec/h264_loopfilter.c
index 96f572c1d2..8fca08811c 100644
--- a/libavcodec/h264_loopfilter.c
+++ b/libavcodec/h264_loopfilter.c
@@ -108,12 +108,8 @@ static av_always_inline void filter_mb_edgev(uint8_t *pix, 
int stride,
 if (alpha ==0 || beta == 0) return;
 
 if( bS[0] < 4 || !intra ) {
-int8_t tc[4];
-tc[0] = ff_h264_tc0_table[index_a][bS[0]];
-tc[1] = ff_h264_tc0_table[index_a][bS[1]];
-tc[2] = ff_h264_tc0_table[index_a][bS[2]];
-tc[3] = ff_h264_tc0_table[index_a][bS[3]];
-h->h264dsp.h264_h_loop_filter_luma(pix, stride, alpha, beta, tc);
+const int8_t *tc = ff_h264_tc0_table[index_a];
+h->h264dsp.h264_h_loop_filter_luma(pix, stride, alpha, beta, tc, bS);
 } else {
 h->h264dsp.h264_h_loop_filter_luma_intra(pix, stride, alpha, beta);
 }
diff --git a/libavcodec/h264dsp.h b/libavcodec/h264dsp.h
index 13371c59ea..f37ff5414c 100644
--- a/libavcodec/h264dsp.h
+++ b/libavcodec/h264dsp.h
@@ -48,7 +48,9 @@ typedef struct H264DSPContext {
 void (*h264_v_loop_filter_luma)(uint8_t *pix /*align 16*/, ptrdiff_t 
stride,
 int alpha, int beta, int8_t *tc0);
 void (*h264_h_loop_filter_luma)(uint8_t *pix /*align 4 */, ptrdiff_t 
stride,
-int alpha, int beta, int8_t *tc0);
+int alpha, int beta,
+const int8_t tc0[4] /*align 4*/,
+const int16_t bs[4] /*align 8*/);
 void (*h264_h_loop_filter_luma_mbaff)(uint8_t *pix /*align 16*/, ptrdiff_t 
stride,
   int alpha, int beta, int8_t *tc0);
 /* v/h_loop_filter_luma_intra: align 16 */
diff --git a/libavcodec/h264dsp_template.c b/libavcodec/h264dsp_template.c
index fe23a2cff1..4d4e34cf81 100644
--- a/libavcodec/h264dsp_template.c
+++ b/libavcodec/h264dsp_template.c
@@ -153,9 +153,14 @@ static void FUNCC(h264_v_loop_filter_luma)(uint8_t *pix, 
ptrdiff_t stride, int a
 {
 FUNCC(h264_loop_filter_luma)(pix, stride, sizeof(pixel), 4, alpha, beta, 
tc0);
 }
-static void FUNCC(h264_h_loop_filter_luma)(uint8_t *pix, ptrdiff_t stride, int 
alpha, int beta, int8_t *tc0)
+static void FUNCC(h264_h_loop_filter_luma)(uint8_t *pix, ptrdiff_t stride, int 
alpha, int beta, const int8_t tc0[4], const int16_t bS[4])
 {
-FUNCC(h264_loop_filter_luma)(pix, sizeof(pixel), stride, 4, alpha, beta, 
tc0);
+int8_t tc[4];
+
+for (size_t i = 0; i < 4; i++)
+tc[i] = tc0[bS[i]];
+
+FUNCC(h264_loop_filter_luma)(pix, sizeof(pixel), stride, 4, alpha, beta, 
tc);
 }
 static void FUNCC(h264_h_loop_filter_luma_mbaff)(uint8_t *pix, ptrdiff_t 
stride, int alpha, int beta, int8_t *tc0)
 {
-- 
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/4] lavc/h264dsp: update R-V V intra luma loop filter

[Rémi Denis-Courmont]

Note that the performance reported by checkasm is slightly worse.
This is expected since the assembler is now doing more work.
---
 libavcodec/riscv/h264dsp_init.c | 3 ++-
 libavcodec/riscv/h264dsp_rvv.S  | 6 --
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/libavcodec/riscv/h264dsp_init.c b/libavcodec/riscv/h264dsp_init.c
index ab412a9924..9650cae66b 100644
--- a/libavcodec/riscv/h264dsp_init.c
+++ b/libavcodec/riscv/h264dsp_init.c
@@ -30,7 +30,8 @@
 void ff_h264_v_loop_filter_luma_8_rvv(uint8_t *pix, ptrdiff_t stride,
   int alpha, int beta, int8_t *tc0);
 void ff_h264_h_loop_filter_luma_8_rvv(uint8_t *pix, ptrdiff_t stride,
-  int alpha, int beta, int8_t *tc0);
+  int alpha, int beta, const int8_t *tc0,
+  const int16_t *bS);
 void ff_h264_h_loop_filter_luma_mbaff_8_rvv(uint8_t *pix, ptrdiff_t stride,
 int alpha, int beta, int8_t *tc0);
 
diff --git a/libavcodec/riscv/h264dsp_rvv.S b/libavcodec/riscv/h264dsp_rvv.S
index 96a8a0a8a3..6bc5406ba3 100644
--- a/libavcodec/riscv/h264dsp_rvv.S
+++ b/libavcodec/riscv/h264dsp_rvv.S
@@ -126,9 +126,11 @@ func ff_h264_v_loop_filter_luma_8_rvv, zve32x
 endfunc
 
 func ff_h264_h_loop_filter_luma_8_rvv, zve32x
-vsetivlizero, 4, e32, m1, ta, ma
-vle8.v  v4, (a4)
+vsetivlizero, 4, e8, mf4, ta, ma
+vle16.v v8, (a5)
 li  t0, 0x01010101
+vluxei16.v  v4, (a4), v8
+vsetivlizero, 4, e32, m1, ta, ma
 vzext.vf4   v6, v4
 addia0, a0, -3
 vmul.vx v6, v6, t0
-- 
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] avdevice/v4l2: add limited support for multiplanar API

[Ramiro Polla]

On Fri, Jun 28, 2024 at 2:54 PM Ramiro Polla  wrote:
> I'll apply this after the weekend if there are no objections.

I realized this patch would have caused a regression on buffers with
corrupted data or an unexpected size.

New patch attached. Alexander, Stephen, since you worked on this
before, could you check that this patch indeed doesn't cause this
regression? I'll apply in a few days if there are no comments.
From 957ec47689e4f4e37a25bd8739a3ec2548284436 Mon Sep 17 00:00:00 2001
From: Ramiro Polla 
Date: Thu, 20 Jun 2024 17:40:39 +0200
Subject: [PATCH v2] avdevice/v4l2: add limited support for multiplanar API

This commit adds support for V4L2's multiplanar API, but only when the
number of planes is 1.

Adding full support for the multiplanar API would require a device that
actually uses more than 1 plane, which I have not found yet.
---
 libavdevice/v4l2.c | 91 --
 1 file changed, 64 insertions(+), 27 deletions(-)

diff --git a/libavdevice/v4l2.c b/libavdevice/v4l2.c
index 74f43ef6a9..42d4b97c8f 100644
--- a/libavdevice/v4l2.c
+++ b/libavdevice/v4l2.c
@@ -92,6 +92,9 @@ struct video_data {
 TimeFilter *timefilter;
 int64_t last_time_m;
 
+int multiplanar;
+enum v4l2_buf_type buf_type;
+
 int buffers;
 atomic_int buffers_queued;
 void **buf_start;
@@ -182,7 +185,13 @@ static int device_open(AVFormatContext *ctx, const char* device_path)
 av_log(ctx, AV_LOG_VERBOSE, "fd:%d capabilities:%x\n",
fd, cap.capabilities);
 
-if (!(cap.capabilities & V4L2_CAP_VIDEO_CAPTURE)) {
+if (cap.capabilities & V4L2_CAP_VIDEO_CAPTURE) {
+s->multiplanar = 0;
+s->buf_type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+} else if (cap.capabilities & V4L2_CAP_VIDEO_CAPTURE_MPLANE) {
+s->multiplanar = 1;
+s->buf_type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
+} else {
 av_log(ctx, AV_LOG_ERROR, "Not a video capture device.\n");
 err = AVERROR(ENODEV);
 goto fail;
@@ -206,7 +215,7 @@ static int device_init(AVFormatContext *ctx, int *width, int *height,
uint32_t pixelformat)
 {
 struct video_data *s = ctx->priv_data;
-struct v4l2_format fmt = { .type = V4L2_BUF_TYPE_VIDEO_CAPTURE };
+struct v4l2_format fmt = { .type = s->buf_type };
 int res = 0;
 
 fmt.fmt.pix.width = *width;
@@ -288,7 +297,7 @@ static void list_framesizes(AVFormatContext *ctx, uint32_t pixelformat)
 static void list_formats(AVFormatContext *ctx, int type)
 {
 const struct video_data *s = ctx->priv_data;
-struct v4l2_fmtdesc vfd = { .type = V4L2_BUF_TYPE_VIDEO_CAPTURE };
+struct v4l2_fmtdesc vfd = { .type = s->buf_type };
 
 while(!v4l2_ioctl(s->fd, VIDIOC_ENUM_FMT, &vfd)) {
 enum AVCodecID codec_id = ff_fmt_v4l2codec(vfd.pixelformat);
@@ -352,7 +361,7 @@ static int mmap_init(AVFormatContext *ctx)
 int i, res;
 struct video_data *s = ctx->priv_data;
 struct v4l2_requestbuffers req = {
-.type   = V4L2_BUF_TYPE_VIDEO_CAPTURE,
+.type   = s->buf_type,
 .count  = desired_video_buffers,
 .memory = V4L2_MEMORY_MMAP
 };
@@ -381,10 +390,14 @@ static int mmap_init(AVFormatContext *ctx)
 }
 
 for (i = 0; i < req.count; i++) {
+unsigned int buf_length, buf_offset;
+struct v4l2_plane planes[VIDEO_MAX_PLANES];
 struct v4l2_buffer buf = {
-.type   = V4L2_BUF_TYPE_VIDEO_CAPTURE,
+.type   = s->buf_type,
 .index  = i,
-.memory = V4L2_MEMORY_MMAP
+.memory = V4L2_MEMORY_MMAP,
+.m.planes = s->multiplanar ? planes : NULL,
+.length   = s->multiplanar ? VIDEO_MAX_PLANES : 0,
 };
 if (v4l2_ioctl(s->fd, VIDIOC_QUERYBUF, &buf) < 0) {
 res = AVERROR(errno);
@@ -392,16 +405,28 @@ static int mmap_init(AVFormatContext *ctx)
 return res;
 }
 
-s->buf_len[i] = buf.length;
+if (s->multiplanar) {
+if (buf.length != 1) {
+av_log(ctx, AV_LOG_ERROR, "multiplanar only supported when buf.length == 1\n");
+return AVERROR_PATCHWELCOME;
+}
+buf_length = buf.m.planes[0].length;
+buf_offset = buf.m.planes[0].m.mem_offset;
+} else {
+buf_length = buf.length;
+buf_offset = buf.m.offset;
+}
+
+s->buf_len[i] = buf_length;
 if (s->frame_size > 0 && s->buf_len[i] < s->frame_size) {
 av_log(ctx, AV_LOG_ERROR,
"buf_len[%d] = %d < expected frame size %d\n",
i, s->buf_len[i], s->frame_size);
 return AVERROR(ENOMEM);
 }
-s->buf_start[i] = v4l2_mmap(NULL, buf.length,
+s->buf_start[i] = v4l2_mmap(NULL, buf_length,
PROT_READ | PROT_WRITE, MAP_SHARED,
-   s->fd, buf.m.offset);
+   s->

Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: Fix segfault with intra-only

[Timo Rothenpieler]

On 01.07.2024 18:52, Josh Allmann wrote:

On Thu, 20 Jun 2024 at 17:39, Josh Allmann  wrote:


In intra-only mode, frameIntervalP is 0, which means the frame
data array is smaller than the number of surfaces. This causes a
crash when closing the encoder.

Fix this by making sure the frame data array is at least as big as
the number of surfaces.
---
  libavcodec/nvenc.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index a9945355ba..93e87b21db 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -1021,7 +1021,7 @@ static av_cold int nvenc_recalc_surfaces(AVCodecContext 
*avctx)

  // Output in the worst case will only start when the surface buffer is 
completely full.
  // Hence we need to keep at least the max amount of surfaces plus the max 
reorder delay around.
-ctx->frame_data_array_nb = ctx->nb_surfaces + 
ctx->encode_config.frameIntervalP - 1;
+ctx->frame_data_array_nb = FFMAX(ctx->nb_surfaces, ctx->nb_surfaces + 
ctx->encode_config.frameIntervalP - 1);

  return 0;
  }
--
2.39.2



Hello,

Ping for review. This patch fixes an easily triggered crash with nvenc
in intra-only mode, eg

ffmpeg -i  -c:v h264_nvenc -g 0 

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


It's the wrong fix for the crash, but definitely a sensible change in 
itself.
Will amend with the actual fix (using the right size when deallocating 
that array) but keep this change as well, since it makes sense.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: Fix segfault with intra-only

[Dennis Mungai]

On Mon, 1 Jul 2024 at 21:01, Timo Rothenpieler 
wrote:

> On 01.07.2024 18:52, Josh Allmann wrote:
> > On Thu, 20 Jun 2024 at 17:39, Josh Allmann 
> wrote:
> >>
> >> In intra-only mode, frameIntervalP is 0, which means the frame
> >> data array is smaller than the number of surfaces. This causes a
> >> crash when closing the encoder.
> >>
> >> Fix this by making sure the frame data array is at least as big as
> >> the number of surfaces.
> >> ---
> >>   libavcodec/nvenc.c | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
> >> index a9945355ba..93e87b21db 100644
> >> --- a/libavcodec/nvenc.c
> >> +++ b/libavcodec/nvenc.c
> >> @@ -1021,7 +1021,7 @@ static av_cold int
> nvenc_recalc_surfaces(AVCodecContext *avctx)
> >>
> >>   // Output in the worst case will only start when the surface
> buffer is completely full.
> >>   // Hence we need to keep at least the max amount of surfaces plus
> the max reorder delay around.
> >> -ctx->frame_data_array_nb = ctx->nb_surfaces +
> ctx->encode_config.frameIntervalP - 1;
> >> +ctx->frame_data_array_nb = FFMAX(ctx->nb_surfaces,
> ctx->nb_surfaces + ctx->encode_config.frameIntervalP - 1);
> >>
> >>   return 0;
> >>   }
> >> --
> >> 2.39.2
> >>
> >
> > Hello,
> >
> > Ping for review. This patch fixes an easily triggered crash with nvenc
> > in intra-only mode, eg
> >
> > ffmpeg -i  -c:v h264_nvenc -g 0 
> >
> > Josh
>

Can this also be back-ported to FFmpeg 7.x upon merging?
___
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] [RFC] av_rescale() coverity

[Michael Niedermayer]

On Mon, Jul 01, 2024 at 03:39:23PM +0200, Michael Niedermayer wrote:
> Hi all
> 
> coverity seems to have started to do a new thing. Namely if theres a
> return statement it assumes it can independant of everything occurr
> 
> an example would be av_rescale() which on overflow returns INT64_MIN
> 
> also with the right flags av_rescale() will pass INT64_MIN and INT64_MAX 
> through
> from the input
> 
> So coverity since a few days seems to treat every av_rescale() call as if it 
> returns
> INT64_MIN and INT64_MAX. coverity doesnt care if that return statement is 
> reachable or
> if the flags even include the execution path.
> 
> An example is this:
> AVRational time_base_q = AV_TIME_BASE_Q;
> int64_t next_dts = av_rescale_q(ds->next_dts, time_base_q, 
> av_inv_q(ist->framerate));
> ds->next_dts = av_rescale_q(next_dts + 1, 
> av_inv_q(ist->framerate), time_base_q);
> 
> Here coverity as a initial statement claims next_dts is INT64_MAX
> and next_dts + 1 would overflow
> 
> 
> 8. function_return: Function av_rescale_q(ds->next_dts, time_base_q, 
> av_inv_q(ist->framerate)) returns 9223372036854775807.
> 9. known_value_assign: next_dts = av_rescale_q(ds->next_dts, 
> time_base_q, av_inv_q(ist->framerate)), its value is now 9223372036854775807.
> 331int64_t next_dts = av_rescale_q(ds->next_dts, time_base_q, 
> av_inv_q(ist->framerate));
> 
> CID 1604545: (#1 of 1): Overflowed constant (INTEGER_OVERFLOW)
> 10. overflow_const: Expression next_dts + 1LL, which is equal to 
> -9223372036854775808, where next_dts is known to be equal to 
> 9223372036854775807, overflows the type that receives it, a signed integer 64 
> bits wide.
> 
> 
> another example is this:
> 
> #define AV_TIME_BASE100
> pts = av_rescale(ds->dts, 100, AV_TIME_BASE);
> 
> coverity hallucinates pts as a tainted negative number here nothing says 
> anything about
> the input ds->dts (and thats what would matter)
> 
> In the past coverity provided a detailed list of steps on how a
> case is reached. One could then check these assumtions and mark things
> as false positive when one assumtion is wrong. (coverity was most of the time
> wrong)
> 
> Now coverity just hallucinates claims out of the blue without any
> explanation how that can happen.
> 
> Iam a bit at a loss how to deal with this and also why exactly this
> new behavior appeared.
> 
> Has anyone changed any setting or anything in coverity ?
> 
> The number of issues shot up to over 400 on the 22th june
> "194 new defect(s) introduced to FFmpeg/FFmpeg found with Coverity Scan."
> 
> before this i thought iam mostly done with my coverity work.
> now truth is, the STF text speaks about 673 issues at the time and not
> what appears after the work started, but it makes me a bit sad if i categorize
> ~700+ issues and then fix the ones that are bugs just to find coverity
> hallucinate 200 new issues a month that ill have to leave open for future
> efforts.
> 
> I did not expect that years of ignoring coverity accumulate 673 issues and
> then suddenly the rate of new issues to shoot up like this. I kind of expected
> that i can fix all new issues appearing during the work with insignificant 
> extra effort

I will try to adjust the modelling file we use and see if that reduces the
av_rescale() hallucinations

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin


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] [RFC] av_rescale() coverity

[Timo Rothenpieler]

On 01.07.2024 15:39, Michael Niedermayer wrote:

Hi all

coverity seems to have started to do a new thing. Namely if theres a
return statement it assumes it can independant of everything occurr

an example would be av_rescale() which on overflow returns INT64_MIN

also with the right flags av_rescale() will pass INT64_MIN and INT64_MAX through
from the input

So coverity since a few days seems to treat every av_rescale() call as if it 
returns
INT64_MIN and INT64_MAX. coverity doesnt care if that return statement is 
reachable or
if the flags even include the execution path.

An example is this:
 AVRational time_base_q = AV_TIME_BASE_Q;
 int64_t next_dts = av_rescale_q(ds->next_dts, time_base_q, 
av_inv_q(ist->framerate));
 ds->next_dts = av_rescale_q(next_dts + 1, 
av_inv_q(ist->framerate), time_base_q);

Here coverity as a initial statement claims next_dts is INT64_MAX
and next_dts + 1 would overflow


 8. function_return: Function av_rescale_q(ds->next_dts, time_base_q, 
av_inv_q(ist->framerate)) returns 9223372036854775807.
 9. known_value_assign: next_dts = av_rescale_q(ds->next_dts, 
time_base_q, av_inv_q(ist->framerate)), its value is now 9223372036854775807.
 331int64_t next_dts = av_rescale_q(ds->next_dts, time_base_q, 
av_inv_q(ist->framerate));

 CID 1604545: (#1 of 1): Overflowed constant (INTEGER_OVERFLOW)
 10. overflow_const: Expression next_dts + 1LL, which is equal to 
-9223372036854775808, where next_dts is known to be equal to 
9223372036854775807, overflows the type that receives it, a signed integer 64 
bits wide.


another example is this:

 #define AV_TIME_BASE100
 pts = av_rescale(ds->dts, 100, AV_TIME_BASE);

coverity hallucinates pts as a tainted negative number here nothing says 
anything about
the input ds->dts (and thats what would matter)

In the past coverity provided a detailed list of steps on how a
case is reached. One could then check these assumtions and mark things
as false positive when one assumtion is wrong. (coverity was most of the time
wrong)

Now coverity just hallucinates claims out of the blue without any
explanation how that can happen.

Iam a bit at a loss how to deal with this and also why exactly this
new behavior appeared.

Has anyone changed any setting or anything in coverity ?

The number of issues shot up to over 400 on the 22th june
"194 new defect(s) introduced to FFmpeg/FFmpeg found with Coverity Scan."


Do you mean May?
Cause that's when I enabled also giving a Windows-Build to Coverity:
https://github.com/FFmpeg/FFmpeg-Coverity/commit/3116e6960406f01f96d934516216bb3b402122fc

Before that, only Linux was analyzed.


before this i thought iam mostly done with my coverity work.
now truth is, the STF text speaks about 673 issues at the time and not
what appears after the work started, but it makes me a bit sad if i categorize
~700+ issues and then fix the ones that are bugs just to find coverity
hallucinate 200 new issues a month that ill have to leave open for future
efforts.

I did not expect that years of ignoring coverity accumulate 673 issues and
then suddenly the rate of new issues to shoot up like this. I kind of expected
that i can fix all new issues appearing during the work with insignificant 
extra effort

thx


___
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] avcodec/mjpegdec: remove unused parameter from ff_mjpeg_decode_frame_from_buf

[James Almer]

Signed-off-by: James Almer 
---
 libavcodec/mjpegdec.c | 4 ++--
 libavcodec/mjpegdec.h | 2 +-
 libavcodec/sp5xdec.c  | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 7daec649bc..ace25af90e 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -2368,7 +2368,7 @@ static void reset_icc_profile(MJpegDecodeContext *s)
 }
 
 int ff_mjpeg_decode_frame_from_buf(AVCodecContext *avctx, AVFrame *frame,
-   int *got_frame, const AVPacket *avpkt,
+   int *got_frame,
const uint8_t *buf, const int buf_size)
 {
 MJpegDecodeContext *s = avctx->priv_data;
@@ -2926,7 +2926,7 @@ int ff_mjpeg_decode_frame(AVCodecContext *avctx, AVFrame 
*frame, int *got_frame,
   AVPacket *avpkt)
 {
 return ff_mjpeg_decode_frame_from_buf(avctx, frame, got_frame,
-  avpkt, avpkt->data, avpkt->size);
+  avpkt->data, avpkt->size);
 }
 
 
diff --git a/libavcodec/mjpegdec.h b/libavcodec/mjpegdec.h
index 13c524d597..6c34761cde 100644
--- a/libavcodec/mjpegdec.h
+++ b/libavcodec/mjpegdec.h
@@ -176,7 +176,7 @@ int ff_mjpeg_decode_frame(AVCodecContext *avctx,
   AVPacket *avpkt);
 int ff_mjpeg_decode_frame_from_buf(AVCodecContext *avctx,
AVFrame *frame, int *got_frame,
-   const AVPacket *avpkt, const uint8_t *buf, 
int buf_size);
+   const uint8_t *buf, int buf_size);
 int ff_mjpeg_decode_dqt(MJpegDecodeContext *s);
 int ff_mjpeg_decode_dht(MJpegDecodeContext *s);
 int ff_mjpeg_decode_sof(MJpegDecodeContext *s);
diff --git a/libavcodec/sp5xdec.c b/libavcodec/sp5xdec.c
index 8dda5b6152..6b9723b4c2 100644
--- a/libavcodec/sp5xdec.c
+++ b/libavcodec/sp5xdec.c
@@ -86,7 +86,7 @@ static int sp5x_decode_frame(AVCodecContext *avctx,
 recoded[j++] = 0xD9;
 
 ret = ff_mjpeg_decode_frame_from_buf(avctx, frame, got_frame,
- avpkt, recoded, j);
+ recoded, j);
 
 av_free(recoded);
 
-- 
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 1/4] lavc/h263dsp: add DCT dequantisation functions

[Rémi Denis-Courmont]

Note that optimised implementations of these functions will be taken
into actual use only if MpegEncContext.dct_unquantize_h263_{inter,intra}
are *not* overloaded by existing optimisations.
---
 libavcodec/h263dsp.c | 25 +
 libavcodec/h263dsp.h |  4 
 2 files changed, 29 insertions(+)

diff --git a/libavcodec/h263dsp.c b/libavcodec/h263dsp.c
index 6a13353499..dc146bf821 100644
--- a/libavcodec/h263dsp.c
+++ b/libavcodec/h263dsp.c
@@ -19,10 +19,33 @@
 #include 
 
 #include "libavutil/attributes.h"
+#include "libavutil/avassert.h"
 #include "libavutil/common.h"
 #include "config.h"
 #include "h263dsp.h"
 
+static void h263_dct_unquantize_inter_c(int16_t *block, ptrdiff_t len,
+int qmul, int qadd)
+{
+for (ptrdiff_t i = 0; i <= len; i++) {
+int level = block[i];
+
+if (level) {
+if (level < 0)
+level = level * qmul - qadd;
+else
+level = level * qmul + qadd;
+block[i] = level;
+}
+}
+}
+
+static void h263_dct_unquantize_intra_c(int16_t *block, ptrdiff_t len,
+int qmul, int qadd)
+{
+h263_dct_unquantize_inter_c(block + 1, len - 1, qmul, qadd);
+}
+
 const uint8_t ff_h263_loop_filter_strength[32] = {
 0, 1, 1, 2, 2, 3, 3,  4,  4,  4,  5,  5,  6,  6,  7, 7,
 7, 8, 8, 8, 9, 9, 9, 10, 10, 10, 11, 11, 11, 12, 12, 12
@@ -116,6 +139,8 @@ static void h263_v_loop_filter_c(uint8_t *src, int stride, 
int qscale)
 
 av_cold void ff_h263dsp_init(H263DSPContext *ctx)
 {
+ctx->h263_dct_unquantize_intra = h263_dct_unquantize_intra_c;
+ctx->h263_dct_unquantize_inter = h263_dct_unquantize_inter_c;
 ctx->h263_h_loop_filter = h263_h_loop_filter_c;
 ctx->h263_v_loop_filter = h263_v_loop_filter_c;
 
diff --git a/libavcodec/h263dsp.h b/libavcodec/h263dsp.h
index 2dccd23392..d26498f491 100644
--- a/libavcodec/h263dsp.h
+++ b/libavcodec/h263dsp.h
@@ -24,6 +24,10 @@
 extern const uint8_t ff_h263_loop_filter_strength[32];
 
 typedef struct H263DSPContext {
+void (*h263_dct_unquantize_intra)(int16_t *block /* align 16 */,
+  ptrdiff_t len, int mul, int add);
+void (*h263_dct_unquantize_inter)(int16_t *block /* align 16 */,
+  ptrdiff_t len, int mul, int add);
 void (*h263_h_loop_filter)(uint8_t *src, int stride, int qscale);
 void (*h263_v_loop_filter)(uint8_t *src, int stride, int qscale);
 } H263DSPContext;
-- 
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/4] lavc/mpegvideo: use H263DSP dequant function

[Rémi Denis-Courmont]

---
 configure  |  4 ++--
 libavcodec/mpegvideo.c | 40 +---
 2 files changed, 11 insertions(+), 33 deletions(-)

diff --git a/configure b/configure
index fed4c44cd1..42b9a72d5a 100755
--- a/configure
+++ b/configure
@@ -2954,8 +2954,8 @@ ftr_decoder_select="adts_header"
 g2m_decoder_deps="zlib"
 g2m_decoder_select="blockdsp idctdsp jpegtables"
 g729_decoder_select="audiodsp"
-h261_decoder_select="mpegvideodec"
-h261_encoder_select="mpegvideoenc"
+h261_decoder_select="h263dsp mpegvideodec"
+h261_encoder_select="h263dsp mpegvideoenc"
 h263_decoder_select="h263_parser h263dsp mpegvideodec qpeldsp"
 h263_encoder_select="h263dsp mpegvideoenc"
 h263i_decoder_select="h263_decoder"
diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
index b9a0469335..c9094d1cce 100644
--- a/libavcodec/mpegvideo.c
+++ b/libavcodec/mpegvideo.c
@@ -202,13 +202,11 @@ static void dct_unquantize_mpeg2_inter_c(MpegEncContext 
*s,
 static void dct_unquantize_h263_intra_c(MpegEncContext *s,
   int16_t *block, int n, int qscale)
 {
-int i, level, qmul, qadd;
-int nCoeffs;
+int qmul = qscale << 1;
+int qadd, nCoeffs;
 
 av_assert2(s->block_last_index[n]>=0 || s->h263_aic);
 
-qmul = qscale << 1;
-
 if (!s->h263_aic) {
 block[0] *= n < 4 ? s->y_dc_scale : s->c_dc_scale;
 qadd = (qscale - 1) | 1;
@@ -220,43 +218,20 @@ static void dct_unquantize_h263_intra_c(MpegEncContext *s,
 else
 nCoeffs= s->intra_scantable.raster_end[ s->block_last_index[n] ];
 
-for(i=1; i<=nCoeffs; i++) {
-level = block[i];
-if (level) {
-if (level < 0) {
-level = level * qmul - qadd;
-} else {
-level = level * qmul + qadd;
-}
-block[i] = level;
-}
-}
+s->h263dsp.h263_dct_unquantize_intra(block, nCoeffs, qmul, qadd);
 }
 
 static void dct_unquantize_h263_inter_c(MpegEncContext *s,
   int16_t *block, int n, int qscale)
 {
-int i, level, qmul, qadd;
+int qmul = qscale << 1;
+int qadd = (qscale - 1) | 1;
 int nCoeffs;
 
 av_assert2(s->block_last_index[n]>=0);
 
-qadd = (qscale - 1) | 1;
-qmul = qscale << 1;
-
 nCoeffs= s->inter_scantable.raster_end[ s->block_last_index[n] ];
-
-for(i=0; i<=nCoeffs; i++) {
-level = block[i];
-if (level) {
-if (level < 0) {
-level = level * qmul - qadd;
-} else {
-level = level * qmul + qadd;
-}
-block[i] = level;
-}
-}
+s->h263dsp.h263_dct_unquantize_inter(block, nCoeffs, qmul, qadd);
 }
 
 
@@ -276,6 +251,9 @@ static void gray8(uint8_t *dst, const uint8_t *src, 
ptrdiff_t linesize, int h)
 static av_cold void dsp_init(MpegEncContext *s)
 {
 ff_blockdsp_init(&s->bdsp);
+#if CONFIG_H263DSP
+ff_h263dsp_init(&s->h263dsp);
+#endif
 ff_hpeldsp_init(&s->hdsp, s->avctx->flags);
 ff_videodsp_init(&s->vdsp, s->avctx->bits_per_raw_sample);
 
-- 
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/4] checkasm/h263dsp: test dct_unquantize_{intra, inter}

[Rémi Denis-Courmont]

---
 tests/checkasm/h263dsp.c | 57 +++-
 1 file changed, 56 insertions(+), 1 deletion(-)

diff --git a/tests/checkasm/h263dsp.c b/tests/checkasm/h263dsp.c
index 2d0957a90b..26020211dc 100644
--- a/tests/checkasm/h263dsp.c
+++ b/tests/checkasm/h263dsp.c
@@ -18,13 +18,65 @@
  * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
  */
 
+#include 
 #include 
 
 #include "checkasm.h"
 
-#include "libavcodec/h263dsp.h"
+#include "libavutil/avassert.h"
 #include "libavutil/mem.h"
 #include "libavutil/mem_internal.h"
+#include "libavcodec/h263dsp.h"
+#include "libavcodec/mpegvideodata.h"
+
+static uint_fast8_t mpeg_qscale_rnd(void)
+{
+int n = rnd(), q = (n >> 1) & 31;
+
+if (n & 1)
+return ff_mpeg2_non_linear_qscale[q];
+else
+return q << 1;
+}
+
+typedef void (*unquantizer)(int16_t *, ptrdiff_t, int, int);
+
+static void check_dct_unquantize(unquantizer func, bool inter)
+{
+const char *name = inter ? "inter" : "intra";
+#define LEN 64
+LOCAL_ALIGNED_16(int16_t, block0, [LEN]);
+LOCAL_ALIGNED_16(int16_t, block1, [LEN]);
+size_t len = rnd() % LEN;
+const int qscale = mpeg_qscale_rnd();
+const int qmul = qscale << 1;
+const int qadd = (rnd() & 1) ? (qscale - 1) | 1 : 0;
+
+declare_func(void, int16_t *, ptrdiff_t, int, int);
+
+for (size_t i = 0; i < LEN; i++) {
+int r = rnd();
+
+block1[i] = block0[i] = (r & 1) ? (r >> 1) : 0;
+}
+
+if (check_func(func, "h263dsp.dct_unquantize_%s", name)) {
+call_ref(block0, 0, qmul, qadd);
+call_new(block1, 0, qmul, qadd);
+
+if (memcmp(block0, block1, LEN * sizeof (int16_t)))
+fail();
+
+av_assert0(len < LEN);
+call_ref(block0, len, qmul, qadd);
+call_new(block1, len, qmul, qadd);
+
+if (memcmp(block0, block1, LEN * sizeof (int16_t)))
+fail();
+
+bench_new(block1, LEN, qmul, qadd);
+}
+}
 
 typedef void (*filter)(uint8_t *src, int stride, int qscale);
 
@@ -56,6 +108,9 @@ void checkasm_check_h263dsp(void)
 H263DSPContext ctx;
 
 ff_h263dsp_init(&ctx);
+check_dct_unquantize(ctx.h263_dct_unquantize_intra, false);
+check_dct_unquantize(ctx.h263_dct_unquantize_inter, true);
+report("dct_unquantize");
 check_loop_filter('h', ctx.h263_h_loop_filter);
 check_loop_filter('v', ctx.h263_v_loop_filter);
 report("loop_filter");
-- 
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/4] lavc/h263dsp: R-V V dct_unquantize_{intra, inter}

[Rémi Denis-Courmont]

T-Head C908:
h263dsp.dct_unquantize_inter_c:   3.7
h263dsp.dct_unquantize_inter_rvv_i32: 1.7
h263dsp.dct_unquantize_intra_c:   4.0
h263dsp.dct_unquantize_intra_rvv_i32: 1.5

SpacemiT X60:
h263dsp.dct_unquantize_inter_c:   3.5
h263dsp.dct_unquantize_inter_rvv_i32: 1.2
h263dsp.dct_unquantize_intra_c:   3.5
h263dsp.dct_unquantize_intra_rvv_i32: 1.2
---
 libavcodec/riscv/h263dsp_init.c | 15 ---
 libavcodec/riscv/h263dsp_rvv.S  | 27 +++
 2 files changed, 39 insertions(+), 3 deletions(-)

diff --git a/libavcodec/riscv/h263dsp_init.c b/libavcodec/riscv/h263dsp_init.c
index 21b536366c..78d537d1e1 100644
--- a/libavcodec/riscv/h263dsp_init.c
+++ b/libavcodec/riscv/h263dsp_init.c
@@ -25,6 +25,8 @@
 #include "libavutil/riscv/cpu.h"
 #include "libavcodec/h263dsp.h"
 
+void ff_h263_dct_unquantize_intra_rvv(int16_t *, ptrdiff_t len, int, int);
+void ff_h263_dct_unquantize_inter_rvv(int16_t *, ptrdiff_t len, int, int);
 void ff_h263_h_loop_filter_rvv(uint8_t *src, int stride, int q);
 void ff_h263_v_loop_filter_rvv(uint8_t *src, int stride, int q);
 
@@ -33,9 +35,16 @@ av_cold void ff_h263dsp_init_riscv(H263DSPContext *c)
 #if HAVE_RVV
 int flags = av_get_cpu_flags();
 
-if ((flags & AV_CPU_FLAG_RVV_I32) && ff_rv_vlen_least(128)) {
-c->h263_h_loop_filter = ff_h263_h_loop_filter_rvv;
-c->h263_v_loop_filter = ff_h263_v_loop_filter_rvv;
+if (flags & AV_CPU_FLAG_RVV_I32) {
+if (ff_rv_vlen_least(128) || (flags & AV_CPU_FLAG_RVB_ADDR)) {
+c->h263_dct_unquantize_intra = ff_h263_dct_unquantize_intra_rvv;
+c->h263_dct_unquantize_inter = ff_h263_dct_unquantize_inter_rvv;
+}
+
+if (ff_rv_vlen_least(128)) {
+c->h263_h_loop_filter = ff_h263_h_loop_filter_rvv;
+c->h263_v_loop_filter = ff_h263_v_loop_filter_rvv;
+}
 }
 #endif
 }
diff --git a/libavcodec/riscv/h263dsp_rvv.S b/libavcodec/riscv/h263dsp_rvv.S
index 97503d527c..f2b7eb9a87 100644
--- a/libavcodec/riscv/h263dsp_rvv.S
+++ b/libavcodec/riscv/h263dsp_rvv.S
@@ -20,6 +20,33 @@
 
 #include "libavutil/riscv/asm.S"
 
+func ff_h263_dct_unquantize_intra_rvv, zve32x
+addia0, a0, 2
+j   1f
+endfunc
+
+func ff_h263_dct_unquantize_inter_rvv, zve32x
+addia1, a1, 1
+1:
+vsetvli  t0, a1, e16, m8, ta, mu
+vle16.v  v8, (a0)
+#if defined(__riscv_v_min_vlen) && __riscv_v_min_vlen < 128
+sub  a1, a1, t0
+#endif
+vmv.v.x  v16, a3
+vmslt.vi v0, v8, 0
+vneg.v   v16, v16, v0.t
+vmsne.vi v0, v8, 0
+vmadd.vx v8, a2, v16, v0.t
+vse16.v  v8, (a0)
+#if defined(__riscv_v_min_vlen) && __riscv_v_min_vlen < 128
+sh1add   a0, t0, a0
+bnez a1, 1b
+#endif
+
+ret
+endfunc
+
 .option push
 .option norelax
 func ff_h263_h_loop_filter_rvv, zve32x
-- 
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] [RFC] av_rescale() coverity

[Michael Niedermayer]

On Mon, Jul 01, 2024 at 08:50:24PM +0200, Timo Rothenpieler wrote:
> On 01.07.2024 15:39, Michael Niedermayer wrote:
> > Hi all
> > 
> > coverity seems to have started to do a new thing. Namely if theres a
> > return statement it assumes it can independant of everything occurr
> > 
> > an example would be av_rescale() which on overflow returns INT64_MIN
> > 
> > also with the right flags av_rescale() will pass INT64_MIN and INT64_MAX 
> > through
> > from the input
> > 
> > So coverity since a few days seems to treat every av_rescale() call as if 
> > it returns
> > INT64_MIN and INT64_MAX. coverity doesnt care if that return statement is 
> > reachable or
> > if the flags even include the execution path.
> > 
> > An example is this:
> >  AVRational time_base_q = AV_TIME_BASE_Q;
> >  int64_t next_dts = av_rescale_q(ds->next_dts, time_base_q, 
> > av_inv_q(ist->framerate));
> >  ds->next_dts = av_rescale_q(next_dts + 1, 
> > av_inv_q(ist->framerate), time_base_q);
> > 
> > Here coverity as a initial statement claims next_dts is INT64_MAX
> > and next_dts + 1 would overflow
> > 
> > 
> >  8. function_return: Function av_rescale_q(ds->next_dts, time_base_q, 
> > av_inv_q(ist->framerate)) returns 9223372036854775807.
> >  9. known_value_assign: next_dts = av_rescale_q(ds->next_dts, 
> > time_base_q, av_inv_q(ist->framerate)), its value is now 
> > 9223372036854775807.
> >  331int64_t next_dts = av_rescale_q(ds->next_dts, 
> > time_base_q, av_inv_q(ist->framerate));
> > 
> >  CID 1604545: (#1 of 1): Overflowed constant (INTEGER_OVERFLOW)
> >  10. overflow_const: Expression next_dts + 1LL, which is equal to 
> > -9223372036854775808, where next_dts is known to be equal to 
> > 9223372036854775807, overflows the type that receives it, a signed integer 
> > 64 bits wide.
> > 
> > 
> > another example is this:
> > 
> >  #define AV_TIME_BASE100
> >  pts = av_rescale(ds->dts, 100, AV_TIME_BASE);
> > 
> > coverity hallucinates pts as a tainted negative number here nothing says 
> > anything about
> > the input ds->dts (and thats what would matter)
> > 
> > In the past coverity provided a detailed list of steps on how a
> > case is reached. One could then check these assumtions and mark things
> > as false positive when one assumtion is wrong. (coverity was most of the 
> > time
> > wrong)
> > 
> > Now coverity just hallucinates claims out of the blue without any
> > explanation how that can happen.
> > 
> > Iam a bit at a loss how to deal with this and also why exactly this
> > new behavior appeared.
> > 
> > Has anyone changed any setting or anything in coverity ?
> > 
> > The number of issues shot up to over 400 on the 22th june
> > "194 new defect(s) introduced to FFmpeg/FFmpeg found with Coverity Scan."
> 
> Do you mean May?
> Cause that's when I enabled also giving a Windows-Build to Coverity:
> https://github.com/FFmpeg/FFmpeg-Coverity/commit/3116e6960406f01f96d934516216bb3b402122fc
> 
> Before that, only Linux was analyzed.

no the 194 appeared in june

I did saw some other spike of issues appear month? earlier or so but these 
seemed
mostly old issues that where detected prior already.
and i dont see it in teh numbers coverity mails me

Only other spike i can find in the numbers was 11 feb 2024
103 new defect(s) introduced to FFmpeg/FFmpeg found with Coverity Scan.

thx

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

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] lavfi: add perlin noise generator

[Stefano Sabatini]

On date Sunday 2024-06-16 17:37:09 +0200, Stefano Sabatini wrote:
> On date Thursday 2024-06-13 16:45:48 +0100, Andrew Sayers wrote:
[...]
> Applied other fixes as well, thanks.

> From 7d9ffbdb8e419ca01e60604038d5534a3ca8ae0e Mon Sep 17 00:00:00 2001
> From: Stefano Sabatini 
> Date: Mon, 27 May 2024 11:19:08 +0200
> Subject: [PATCH] lavfi: add Perlin noise generator
> 
> ---
>  Changelog |   1 +
>  doc/filters.texi  | 100 +
>  libavfilter/Makefile  |   1 +
>  libavfilter/allfilters.c  |   1 +
>  libavfilter/perlin.c  | 224 ++
>  libavfilter/perlin.h  | 101 +
>  libavfilter/vsrc_perlin.c | 169 
>  7 files changed, 597 insertions(+)
>  create mode 100644 libavfilter/perlin.c
>  create mode 100644 libavfilter/perlin.h
>  create mode 100644 libavfilter/vsrc_perlin.c

Applied.
___
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 5/5] avfilter/vf_showinfo: don't use sizeof(AVSphericalMapping)

[Stefano Sabatini]

On date Wednesday 2024-06-26 11:10:14 -0300, James Almer wrote:
> It's not part of the libavutil ABI.
> 
> Signed-off-by: James Almer 
> ---
>  libavfilter/vf_showinfo.c | 5 -
>  1 file changed, 5 deletions(-)

All patches look good to me, thanks.
___
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/dvdvideodec: Do not EOF on WAIT events

[Stefano Sabatini]

On date Wednesday 2024-06-26 20:34:35 -0500, Marth64 wrote:
> A DVDNAV_WAIT event by itself should not warrant an
> EOF when navigating the program stream. Some discs
> have WAIT events in the middle of a title, causing
> playback to end prematurely prior to this fix.
> 
> Signed-off-by: Marth64 
> ---
>  libavformat/dvdvideodec.c | 17 -
>  1 file changed, 8 insertions(+), 9 deletions(-)

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] avformat/dvdvideodec: Fix duration logic with 1 chapter and validate chapter range

[Stefano Sabatini]

On date Wednesday 2024-06-26 22:05:46 -0500, Marth64 wrote:
> Chapters and duration are calculated together in dvdvideo demuxer.
> Previous chapter calculation logic treated extraction of 1 chapter
> using chapter_start and chapter_end switches incorrectly, returning
> the duration of the entire title instead of just the segment.
> 

> Fix the logic so that it calculates and returns the duration of the
> chapter segment instead. Additionally, validate that chapter_end
> exceeds chapter_start (except in the special case of 0).

What is the meaning of the 0 special case?

> 
> Signed-off-by: Marth64 
> ---
>  libavformat/dvdvideodec.c | 15 ---
>  1 file changed, 12 insertions(+), 3 deletions(-)

[...]

Looks good to me.
___
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/dvdvideodec: Fix duration logic with 1 chapter and validate chapter range

[Stefano Sabatini]

On date Monday 2024-07-01 22:49:42 +0200, Stefano Sabatini wrote:
> On date Wednesday 2024-06-26 22:05:46 -0500, Marth64 wrote:
> > Chapters and duration are calculated together in dvdvideo demuxer.
> > Previous chapter calculation logic treated extraction of 1 chapter
> > using chapter_start and chapter_end switches incorrectly, returning
> > the duration of the entire title instead of just the segment.
> > 
> 
> > Fix the logic so that it calculates and returns the duration of the
> > chapter segment instead. Additionally, validate that chapter_end
> > exceeds chapter_start (except in the special case of 0).
> 
> What is the meaning of the 0 special case?
> 
> > 
> > Signed-off-by: Marth64 
> > ---
> >  libavformat/dvdvideodec.c | 15 ---
> >  1 file changed, 12 insertions(+), 3 deletions(-)
> 
> [...]
> 
> Looks good to me.

Both patches applied.
___
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] [RFC] av_rescale() coverity

[Michael Niedermayer]

On Mon, Jul 01, 2024 at 10:19:31PM +0200, Michael Niedermayer wrote:
> On Mon, Jul 01, 2024 at 08:50:24PM +0200, Timo Rothenpieler wrote:
> > On 01.07.2024 15:39, Michael Niedermayer wrote:
> > > Hi all
> > > 
> > > coverity seems to have started to do a new thing. Namely if theres a
> > > return statement it assumes it can independant of everything occurr
> > > 
> > > an example would be av_rescale() which on overflow returns INT64_MIN
> > > 
> > > also with the right flags av_rescale() will pass INT64_MIN and INT64_MAX 
> > > through
> > > from the input
> > > 
> > > So coverity since a few days seems to treat every av_rescale() call as if 
> > > it returns
> > > INT64_MIN and INT64_MAX. coverity doesnt care if that return statement is 
> > > reachable or
> > > if the flags even include the execution path.
> > > 
> > > An example is this:
> > >  AVRational time_base_q = AV_TIME_BASE_Q;
> > >  int64_t next_dts = av_rescale_q(ds->next_dts, time_base_q, 
> > > av_inv_q(ist->framerate));
> > >  ds->next_dts = av_rescale_q(next_dts + 1, 
> > > av_inv_q(ist->framerate), time_base_q);
> > > 
> > > Here coverity as a initial statement claims next_dts is INT64_MAX
> > > and next_dts + 1 would overflow
> > > 
> > > 
> > >  8. function_return: Function av_rescale_q(ds->next_dts, time_base_q, 
> > > av_inv_q(ist->framerate)) returns 9223372036854775807.
> > >  9. known_value_assign: next_dts = av_rescale_q(ds->next_dts, 
> > > time_base_q, av_inv_q(ist->framerate)), its value is now 
> > > 9223372036854775807.
> > >  331int64_t next_dts = av_rescale_q(ds->next_dts, 
> > > time_base_q, av_inv_q(ist->framerate));
> > > 
> > >  CID 1604545: (#1 of 1): Overflowed constant (INTEGER_OVERFLOW)
> > >  10. overflow_const: Expression next_dts + 1LL, which is equal to 
> > > -9223372036854775808, where next_dts is known to be equal to 
> > > 9223372036854775807, overflows the type that receives it, a signed 
> > > integer 64 bits wide.
> > > 
> > > 
> > > another example is this:
> > > 
> > >  #define AV_TIME_BASE100
> > >  pts = av_rescale(ds->dts, 100, AV_TIME_BASE);
> > > 
> > > coverity hallucinates pts as a tainted negative number here nothing says 
> > > anything about
> > > the input ds->dts (and thats what would matter)
> > > 
> > > In the past coverity provided a detailed list of steps on how a
> > > case is reached. One could then check these assumtions and mark things
> > > as false positive when one assumtion is wrong. (coverity was most of the 
> > > time
> > > wrong)
> > > 
> > > Now coverity just hallucinates claims out of the blue without any
> > > explanation how that can happen.
> > > 
> > > Iam a bit at a loss how to deal with this and also why exactly this
> > > new behavior appeared.
> > > 
> > > Has anyone changed any setting or anything in coverity ?
> > > 
> > > The number of issues shot up to over 400 on the 22th june
> > > "194 new defect(s) introduced to FFmpeg/FFmpeg found with Coverity Scan."
> > 
> > Do you mean May?
> > Cause that's when I enabled also giving a Windows-Build to Coverity:
> > https://github.com/FFmpeg/FFmpeg-Coverity/commit/3116e6960406f01f96d934516216bb3b402122fc
> > 
> > Before that, only Linux was analyzed.
> 
> no the 194 appeared in june
> 
> I did saw some other spike of issues appear month? earlier or so but these 
> seemed
> mostly old issues that where detected prior already.
> and i dont see it in teh numbers coverity mails me
> 

> Only other spike i can find in the numbers was 11 feb 2024
> 103 new defect(s) introduced to FFmpeg/FFmpeg found with Coverity Scan.

The mail for the windows spike went to my old email address from gmx, was
misidentified as spam and deleted by gmx. gmx "recently" forced their broken
spam detection to be enabled even when explicitly disabled by the customer.
One has to download the mails from a specific folder on their IMAP server
within a month it seems. Which i didnt because i had their whole broken
spam detection disabled

Its not imprtant but if someone has all the coverity mails, a list of
new and fixed bugs on each run would be interresting

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] [RFC]] swscale modernization proposal

[Stefano Sabatini]

On date Monday 2024-06-24 16:44:33 +0200, Vittorio Giovara wrote:
> On Sun, Jun 23, 2024 at 7:57 PM James Almer  wrote:
> 
> > On 6/22/2024 7:19 PM, Vittorio Giovara wrote:
> > > Needless to say I support the plan of renaming the library so that it can
> > > be inline with the other libraries names, and the use of a separate
> > header
> > > since downstream applications will need to update a lot to use the new
> > > library (or the new apis in the existing library) and/or we could
> > provide a
> > > thin conversion layer when the new lib is finalized.
> >
> > I don't quite agree with renaming it. As Michael already pointed out,
> > the av prefix wouldn't fit a scaling library nor a resampling one, as
> > they only handle one or the other.
> >
> 
> by that reasoning we should ban all subtitles from all the libraries
> 
> av is a shorthand of multimedia and many people in the industry refer to
> ffmpeg libs as "libav*" so it feels a bit odd to push for preserving an
> alternative name
> 
> 
> > There's also the precedent of avresample, which was ultimately dropped
> > in favor of swresample, so trying to replace swscale with a new avscale
> > library will be both confusing and going against what was already
> > established.
> 
> 
> it's still 4 libraries vs 2... and swr/avr is shrouded in bad history that
> is not worth bringing up
> 

> I'd understand opposing a rename just for the sake of renaming, but this is
> essentially a new library, i see no value in preserving the old naming
> scheme, if not making downstream life worse :x

+1

av_ is a kind of prefix used by most FFmpeg libraries, so it's not
only about Audio/Video. Since the rewrite will probably break API
anyhow, we should move in the direction of making this more consistent
with the other FFmpeg libraries.
___
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/dvdvideodec: Fix duration logic with 1 chapter and validate chapter range

[Marth64]

>  What is the meaning of the 0 special case?
If chapter_end is 0, this means "end". So you can say, -chapter_start
5 -chapter_end 0  and demuxer will go from chapter 5 to end of title.
This is also in the public docs since initial demuxer merge.

Thank you!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avfilter/af_afade: fix opt_type for nb_samples/ns

[Stefano Sabatini]

On date Saturday 2024-06-22 15:20:52 +0200, Andreas Rheinhardt wrote:
> Andrew Sayers:
> > The actual value is an int64_t, and is accessed elsewhere as 
> > AV_OPT_TYPE_INT64.
> > 
> > Accessing it as INT will likely cause bugs on some 32-bit architectures.
> 
> Whether this works or not will depend upon endianness, not on whether
> the architecture is 32-bit (as long as int is 32bits, which is mostly
> true for 64-bit architectures).
>
> > ---
> >  libavfilter/af_afade.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/libavfilter/af_afade.c b/libavfilter/af_afade.c
> > index 3a45873460..c79271ec92 100644
> > --- a/libavfilter/af_afade.c
> > +++ b/libavfilter/af_afade.c
> > @@ -452,8 +452,8 @@ const AVFilter ff_af_afade = {
> >  #if CONFIG_ACROSSFADE_FILTER
> >  
> >  static const AVOption acrossfade_options[] = {
> > -{ "nb_samples",   "set number of samples for cross fade duration", 
> > OFFSET(nb_samples),   AV_OPT_TYPE_INT,{.i64 = 44100}, 1, INT32_MAX/10, 
> > FLAGS },
> > -{ "ns",   "set number of samples for cross fade duration", 
> > OFFSET(nb_samples),   AV_OPT_TYPE_INT,{.i64 = 44100}, 1, INT32_MAX/10, 
> > FLAGS },
> > +{ "nb_samples",   "set number of samples for cross fade duration", 
> > OFFSET(nb_samples),   AV_OPT_TYPE_INT64,  {.i64 = 44100}, 1, INT32_MAX/10, 
> > FLAGS },
> > +{ "ns",   "set number of samples for cross fade duration", 
> > OFFSET(nb_samples),   AV_OPT_TYPE_INT64,  {.i64 = 44100}, 1, INT32_MAX/10, 
> > FLAGS },
> >  { "duration", "set cross fade duration",   
> > OFFSET(duration), AV_OPT_TYPE_DURATION, {.i64 = 0 },  0, 6000, 
> > FLAGS },
> >  { "d","set cross fade duration",   
> > OFFSET(duration), AV_OPT_TYPE_DURATION, {.i64 = 0 },  0, 6000, 
> > FLAGS },
> >  { "overlap",  "overlap 1st stream end with 2nd stream start",  
> > OFFSET(overlap),  AV_OPT_TYPE_BOOL,   {.i64 = 1}, 0,  1, FLAGS },
> 
> LGTM. How did you find this?

LGTM as well, will apply after dropping the second sentence in the
commit log.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: Fix segfault with intra-only

[Timo Rothenpieler]

On 01.07.2024 20:05, Dennis Mungai wrote:

On Mon, 1 Jul 2024 at 21:01, Timo Rothenpieler 
wrote:


On 01.07.2024 18:52, Josh Allmann wrote:

On Thu, 20 Jun 2024 at 17:39, Josh Allmann 

wrote:


In intra-only mode, frameIntervalP is 0, which means the frame
data array is smaller than the number of surfaces. This causes a
crash when closing the encoder.

Fix this by making sure the frame data array is at least as big as
the number of surfaces.
---
   libavcodec/nvenc.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index a9945355ba..93e87b21db 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -1021,7 +1021,7 @@ static av_cold int

nvenc_recalc_surfaces(AVCodecContext *avctx)


   // Output in the worst case will only start when the surface

buffer is completely full.

   // Hence we need to keep at least the max amount of surfaces plus

the max reorder delay around.

-ctx->frame_data_array_nb = ctx->nb_surfaces +

ctx->encode_config.frameIntervalP - 1;

+ctx->frame_data_array_nb = FFMAX(ctx->nb_surfaces,

ctx->nb_surfaces + ctx->encode_config.frameIntervalP - 1);


   return 0;
   }
--
2.39.2



Hello,

Ping for review. This patch fixes an easily triggered crash with nvenc
in intra-only mode, eg

ffmpeg -i  -c:v h264_nvenc -g 0 

Josh




Can this also be back-ported to FFmpeg 7.x upon merging?


Already is, applies to 7.0 and 6.x
___
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] Development process for explaining contexts (was Re: [PATCH v6 1/4] doc: Explain what "context" means)

[Stefano Sabatini]

On date Sunday 2024-06-16 19:02:51 +0100, Andrew Sayers wrote:
> Meta note #1: I've replied in this thread but changed the subject line.
> That's because it needs to stay focussed on solving this thread's problem,
> but may be of more general interest.
> 
> Meta note #2: Stefano, I appreciate your feedback, but would rather wait
> for [1] to get sorted out, then formulate my thoughts while writing a new
> version.  That way I'll be more focussed on ways to improve things for 
> readers.
> 
> This thread started with what I thought was a trivia question[1] -
> what is a context?  It's short for "AVClass context structure", which is
> synonymous with "AVOptions-enabled struct".  It turned out to be more complex
> than that, so I wrote a little patch[3] explaining this piece of jargon.
> But it turned out to be more complex again, and so on until we got a 430-line
> document explaining things in voluminous detail.
> 
> Everyone agrees this isn't ideal, so here are some alternatives.
> This may also inspire thoughts about FFmpeg development in general.
> 
> # Alternative: Just give up
> 
> The argument: We tried something, learnt a lot, but couldn't find a solution
> we agreed on, so let's come back another day.
> 
> Obviously this is the easy way out, but essentially means leaving a critical
> bug in the documentation (misleads the reader about a fundamental concept).
> Even the most negative take on this document is that it's better than nothing,
> so I think we can rule this one out.
> 
> # Err on the side of under-communicating
> 
> The argument: this document is on the right tracks, but explains too many 
> things
> the reader can already be assumed to know.
> 
> This argument is more complex than it appears.  To take some silly examples,
> I'm not going to learn Mandarin just because FFmpeg users can't be assumed to
> speak English.  But I am willing to use American spelling because it's what
> more readers are used to.  This e-mail is plenty long enough already, so
> I'll stick to some high-level points about this argument.
> 
> The main risk of cutting documentation is that if someone can't follow a 
> single
> step, they're lost and don't even know how to express their problem.  Imagine
> teaching maths to children - you need to teach them what numbers are, then how
> to add them together, then multiplication, then finally exponents.  But if you
> say "we don't need to teach numbers because kids all watch Numberblocks now",
> you'll cover the majority of kids who could have worked it out anyway, and
> leave a minority who just give up and say "I guess I must be bad at maths".
> I'd argue it's better to write more, then get feedback from actual newbies and
> cut based on the evidence - we'll get it wrong either way, but at least this 
> way
> the newbies will know what they want us to cut.
> 
> Incidentally, there's a much stronger argument for *drafting* a long document,
> even if it gets cut down before it's committed.  FFmpeg has lots of 
> undocumented
> nuances that experts just know and newbies don't know to ask, and this thread 
> is
> full of instances where writing more detail helped tease out a 
> misunderstanding.
> [1] is a great example - I had finally written enough detail to uncover my
> assumption that all AVOptions could be set at any time, then that thread
> taught me to look for a flag that tells you the options for which that's true.
> 
> If you assume I'm not the only person who has been subtly misled that way,
> you could argue it's better to commit the long version.  That would give 
> readers
> more opportunities to confront their own wrong assumptions, instead of reading
> something that assumed they knew one thing, but let them keep believing 
> another.
> The obvious counterargument is that we should...
> 
> # Spread the information across multiple documents
> 
> The argument: this document puts too much information in one place.  We should
> instead focus on making small patches that put information people need to know
> where they need to know it.
> 
> This is where things get more interesting to a general audience.
> 
> If you have repo commit access, you're probably imagining a workflow like:
> write a bunch of little commits, send them out for review, then commit them
> when people stop replying.  Your access is evidence that you basically know 
> how
> things work, and also lets you make plans confident in the knowledge that
> anything you need committed will make it there in the end.
> 
> My workflow is nothing like that.  This thread has constantly reinforced that 
> I
> don't understand FFmpeg, so it's better for me not to have commit access.  But
> that means I can only work on one patch at once, because I will probably learn
> something that invalidates any other work I would have done.  It also means
> a single patch not getting interest is enough to sink the project altogether.
> I can put up with that when it's one big multi-faceted patch, because I can 
> work

Re: [FFmpeg-devel] [PATCH v3 0/3] s/RUNTIME/POST_INIT_SETTABLE/

[Stefano Sabatini]

On date Sunday 2024-06-16 18:08:28 +0100, Andrew Sayers wrote:

> AV_OPT_FLAG_POST_INIT_SETTABLE_PARAM is fine by me, here's a patch.
> I've added a "@deprecated" comment for the old name, but would this
> need to be queued up for 8.0?  Technically this is a backwards-incompatible
> change to the existing API, even though it doesn't change the ABI or generate
> warnings when compiling code.

Correct, but we can deprecate and keep the old symbols until the next
major bump.

[...]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v3 1/3] lavu/opt: Rename AV_OPT_FLAG_RUNTIME_PARAM to ...POST_INIT_SETTABLE_PARAM

[Stefano Sabatini]

On date Sunday 2024-06-16 18:08:29 +0100, Andrew Sayers wrote:
> The old name could be misread as the opposite of "AV_OPT_FLAG_READONLY" -
> some things can be set at runtime, others are read-only.  Clarify that
> this refers to options that can be set after the struct is initialized.
> ---
>  libavutil/opt.h | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/libavutil/opt.h b/libavutil/opt.h
> index 07e27a9208..e050d126ed 100644
> --- a/libavutil/opt.h
> +++ b/libavutil/opt.h
> @@ -53,6 +53,9 @@
>   * question is allowed to access the field. This allows us to extend the
>   * semantics of those fields without breaking API compatibility.
>   *
> + * Note: only options with the AV_OPT_FLAG_POST_INIT_SETTABLE_PARAM flag can 
> be
> + * modified after the struct is initialized.
> + *
>   * @section avoptions_scope Scope of AVOptions
>   *
>   * AVOptions is designed to support any set of multimedia configuration 
> options
> @@ -300,7 +303,12 @@ enum AVOptionType{
>  #define AV_OPT_FLAG_BSF_PARAM   (1 << 8)
>  
>  /**
> - * A generic parameter which can be set by the user at runtime.
> + * A generic parameter which can be set by the user after the struct is 
> initialized.
> + */
> +#define AV_OPT_FLAG_POST_INIT_SETTABLE_PARAM   (1 << 15)

This needs to be dropped at the next bump.

1. define in libavutil/version.h

#define FF_API_OPT_FLAG_RUNTIME_PARAM  (LIBAVUTIL_VERSION_MAJOR < 60)

2. ifdef to automatically drop this at the next bump

#if FF_API_OPT_FLAG_RUNTIME_PARAM
/**
 * A generic parameter which can be set by the user after the struct is 
initialized.
 * @deprecated Renamed to AV_OPT_FLAG_POST_INIT_SETTABLE_PARAM for clarity
  */
#define AV_OPT_FLAG_RUNTIME_PARAM   (1 << 15)
#endif

3. add a note to doc/APIchanges for the new symbol.
___
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/3] avformat/cafdec: sanity check channels and bps

[Michael Niedermayer]

On Sun, Jun 30, 2024 at 08:07:28PM -0300, James Almer wrote:
> On 6/29/2024 8:37 PM, Michael Niedermayer wrote:
> > On Wed, Jun 26, 2024 at 09:52:44PM -0300, James Almer wrote:
> > > On 3/22/2024 8:08 PM, Michael Niedermayer wrote:
> > > > Fixes: Timeout
> > > > Fixes: 
> > > > 67044/clusterfuzz-testcase-minimized-ffmpeg_dem_CAF_fuzzer-5791144363491328
> > > > 
> > > > Found-by: continuous fuzzing process 
> > > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > > Signed-off-by: Michael Niedermayer 
> > > > ---
> > > >libavformat/cafdec.c | 5 +
> > > >1 file changed, 5 insertions(+)
> > > > 
> > > > diff --git a/libavformat/cafdec.c b/libavformat/cafdec.c
> > > > index 426c56b9bd..334077efb5 100644
> > > > --- a/libavformat/cafdec.c
> > > > +++ b/libavformat/cafdec.c
> > > > @@ -33,6 +33,7 @@
> > > >#include "isom.h"
> > > >#include "mov_chan.h"
> > > >#include "libavcodec/flac.h"
> > > > +#include "libavcodec/internal.h"
> > > >#include "libavutil/intreadwrite.h"
> > > >#include "libavutil/intfloat.h"
> > > >#include "libavutil/dict.h"
> > > > @@ -87,6 +88,10 @@ static int read_desc_chunk(AVFormatContext *s)
> > > >st->codecpar->ch_layout.nb_channels = avio_rb32(pb);
> > > >st->codecpar->bits_per_coded_sample = avio_rb32(pb);
> > > > +if (st->codecpar->ch_layout.nb_channels > FF_SANE_NB_CHANNELS ||
> > > > +st->codecpar->bits_per_coded_sample > 64)
> > > 
> > > Where does the process take so long that oss-fuzz gets a timeout if these
> > > are unreasonably high? I don't see nb_channels used anywhere in here where
> > > that matters.
> > > Is it in the PCM decoder? Because that decoder is meant to handle any
> > > arbitrary amount of channels, so limiting it to whatever 
> > > FF_SANE_NB_CHANNELS
> > > is set to is not ok.
> > 
> > libavutil/channel_layout.c:627:17
> > or it will OOM before depending on how much memory is available
> 
> Does this fix the timeout?
> 
> > diff --git a/libavutil/channel_layout.c b/libavutil/channel_layout.c
> > index 2d6963b6df..a4fcd199e1 100644
> > --- a/libavutil/channel_layout.c
> > +++ b/libavutil/channel_layout.c
> > @@ -623,6 +623,8 @@ int av_channel_layout_describe_bprint(const 
> > AVChannelLayout *channel_layout,
> >  for (i = 0; i < channel_layout->nb_channels; i++) {
> >  enum AVChannel ch = 
> > av_channel_layout_channel_from_index(channel_layout, i);
> > 
> > +if (!av_bprint_is_complete(bp))
> > +break;
> >  if (i)
> >  av_bprintf(bp, "+");
> >  av_channel_name_bprint(bp, ch);
> 
> But this is not ok as it will affect the buffer len value
> av_channel_layout_describe() returns on success when truncation took place,
> so something else would have to be done.

This makes the testcase which is 108 bytes long take a bit more than 7 seconds
which is below the threshold for the timeout, but i would guess 30x on the 
channel
number would bring it well above

The next location it gets stuck on if the timeout threshold is reduced:

#0 0x4a5b41 in __sanitizer_print_stack_trace 
/b/swarming/w/ir/cache/builder/src/third_party/llvm/compiler-rt/lib/asan/asan_stack.cc:86:3
#1 0x2a30aae in fuzzer::Fuzzer::AlarmCallback() 
Fuzzer/build/../FuzzerLoop.cpp:248:7
#2 0x7fbe0815e41f  (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f)
#3 0x7fbe07c73e08  (/lib/x86_64-linux-gnu/libc.so.6+0xbbe08)
#4 0x49c747 in __asan_memcpy 
/b/swarming/w/ir/cache/builder/src/third_party/llvm/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cc:22:3
#5 0x2873f59 in av_channel_layout_copy 
ffmpeg/libavutil/channel_layout.c:452:9
#6 0x1895763 in avcodec_parameters_to_context 
ffmpeg/libavcodec/codec_par.c:235:15
#7 0x71923e in avformat_find_stream_info ffmpeg/libavformat/demux.c:2579:15
#8 0x4cd17b in LLVMFuzzerTestOneInput 
ffmpeg/tools/target_dem_fuzzer.c:207:11
#9 0x2a31b1d in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, 
unsigned long) Fuzzer/build/../FuzzerLoop.cpp:495:13
#10 0x2a266f2 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned 
long) Fuzzer/build/../FuzzerDriver.cpp:273:6
#11 0x2a2b8f1 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char 
const*, unsigned long)) Fuzzer/build/../FuzzerDriver.cpp:690:9
#12 0x2a263d0 in main Fuzzer/build/../FuzzerMain.cpp:20:10
#13 0x7fbe07bdc082 in __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x24082)
#14 0x42529d in _start (ffmpeg/tools/target_dem_caf_fuzzer+0x42529d)


> 
> > 
> > 
> > > 
> > > And is the bits_per_coded_sample > 64 check to prevent codec_id being
> > > AV_CODEC_ID_NONE? if so, how does that affect demuxing time?
> > > AV_CODEC_ID_NONE for that matter could happen for valid files with a codec
> > > we don't currently support.
> > 
> > We generally check read values for validity at the earliest,
> > bits_per_coded_sample of more than 64 seem not valid to me.
> 
> I agree the check i

[FFmpeg-devel] [PATCH v2] doc/examples/vaapi_encode: Try to check fwrite() for failure

[Michael Niedermayer]

Fixes: CID1604548 Unused value

Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer 
---
 doc/examples/vaapi_encode.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/doc/examples/vaapi_encode.c b/doc/examples/vaapi_encode.c
index d5f472f6dd8..ff3ebb1e2b8 100644
--- a/doc/examples/vaapi_encode.c
+++ b/doc/examples/vaapi_encode.c
@@ -88,6 +88,10 @@ static int encode_write(AVCodecContext *avctx, AVFrame 
*frame, FILE *fout)
 enc_pkt->stream_index = 0;
 ret = fwrite(enc_pkt->data, enc_pkt->size, 1, fout);
 av_packet_unref(enc_pkt);
+if (ret != enc_pkt->size) {
+ret = AVERROR(errno);
+break;
+}
 }
 
 end:
-- 
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 02/11] avcodec/vvc/dec: Check ff_init_cabac_decoder() for failure

[Michael Niedermayer]

On Mon, Jul 01, 2024 at 08:54:33PM +0800, Nuo Mi wrote:
> On Mon, Jul 1, 2024 at 7:13 AM Michael Niedermayer 
> wrote:
> 
> > Fixes: signed integer overflow: 1107820800 + 1107820800 cannot be
> > represented in type 'int'
> > Fixes: left shift of 1091059712 by 6 places cannot be represented in type
> > 'int'
> > Fixes:
> > 69910/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VVC_fuzzer-5162839971528704
> >
> LGTM

will apply

thx

[...]
-- 
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 1/3] avformat/cafdec: sanity check channels and bps

[James Almer]

On 7/1/2024 8:42 PM, Michael Niedermayer wrote:

On Sun, Jun 30, 2024 at 08:07:28PM -0300, James Almer wrote:

On 6/29/2024 8:37 PM, Michael Niedermayer wrote:

On Wed, Jun 26, 2024 at 09:52:44PM -0300, James Almer wrote:

On 3/22/2024 8:08 PM, Michael Niedermayer wrote:

Fixes: Timeout
Fixes: 
67044/clusterfuzz-testcase-minimized-ffmpeg_dem_CAF_fuzzer-5791144363491328

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

diff --git a/libavformat/cafdec.c b/libavformat/cafdec.c
index 426c56b9bd..334077efb5 100644
--- a/libavformat/cafdec.c
+++ b/libavformat/cafdec.c
@@ -33,6 +33,7 @@
#include "isom.h"
#include "mov_chan.h"
#include "libavcodec/flac.h"
+#include "libavcodec/internal.h"
#include "libavutil/intreadwrite.h"
#include "libavutil/intfloat.h"
#include "libavutil/dict.h"
@@ -87,6 +88,10 @@ static int read_desc_chunk(AVFormatContext *s)
st->codecpar->ch_layout.nb_channels = avio_rb32(pb);
st->codecpar->bits_per_coded_sample = avio_rb32(pb);
+if (st->codecpar->ch_layout.nb_channels > FF_SANE_NB_CHANNELS ||
+st->codecpar->bits_per_coded_sample > 64)


Where does the process take so long that oss-fuzz gets a timeout if these
are unreasonably high? I don't see nb_channels used anywhere in here where
that matters.
Is it in the PCM decoder? Because that decoder is meant to handle any
arbitrary amount of channels, so limiting it to whatever FF_SANE_NB_CHANNELS
is set to is not ok.


libavutil/channel_layout.c:627:17
or it will OOM before depending on how much memory is available


Does this fix the timeout?


diff --git a/libavutil/channel_layout.c b/libavutil/channel_layout.c
index 2d6963b6df..a4fcd199e1 100644
--- a/libavutil/channel_layout.c
+++ b/libavutil/channel_layout.c
@@ -623,6 +623,8 @@ int av_channel_layout_describe_bprint(const AVChannelLayout 
*channel_layout,
  for (i = 0; i < channel_layout->nb_channels; i++) {
  enum AVChannel ch = 
av_channel_layout_channel_from_index(channel_layout, i);

+if (!av_bprint_is_complete(bp))
+break;
  if (i)
  av_bprintf(bp, "+");
  av_channel_name_bprint(bp, ch);


But this is not ok as it will affect the buffer len value
av_channel_layout_describe() returns on success when truncation took place,
so something else would have to be done.


This makes the testcase which is 108 bytes long take a bit more than 7 seconds
which is below the threshold for the timeout, but i would guess 30x on the 
channel
number would bring it well above


If you try to process that file without the fuzzer, does it also take 7 
seconds before it stops? If not, then the fuzzer is having Valgrind 
levels of penalty hit, and i don't think adding dubious checks in our 
codebase just to appease it is correct.




The next location it gets stuck on if the timeout threshold is reduced:

 #0 0x4a5b41 in __sanitizer_print_stack_trace 
/b/swarming/w/ir/cache/builder/src/third_party/llvm/compiler-rt/lib/asan/asan_stack.cc:86:3
 #1 0x2a30aae in fuzzer::Fuzzer::AlarmCallback() 
Fuzzer/build/../FuzzerLoop.cpp:248:7
 #2 0x7fbe0815e41f  (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f)
 #3 0x7fbe07c73e08  (/lib/x86_64-linux-gnu/libc.so.6+0xbbe08)
 #4 0x49c747 in __asan_memcpy 
/b/swarming/w/ir/cache/builder/src/third_party/llvm/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cc:22:3
 #5 0x2873f59 in av_channel_layout_copy 
ffmpeg/libavutil/channel_layout.c:452:9
 #6 0x1895763 in avcodec_parameters_to_context 
ffmpeg/libavcodec/codec_par.c:235:15
 #7 0x71923e in avformat_find_stream_info ffmpeg/libavformat/demux.c:2579:15
 #8 0x4cd17b in LLVMFuzzerTestOneInput 
ffmpeg/tools/target_dem_fuzzer.c:207:11
 #9 0x2a31b1d in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, 
unsigned long) Fuzzer/build/../FuzzerLoop.cpp:495:13
 #10 0x2a266f2 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned 
long) Fuzzer/build/../FuzzerDriver.cpp:273:6
 #11 0x2a2b8f1 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char 
const*, unsigned long)) Fuzzer/build/../FuzzerDriver.cpp:690:9
 #12 0x2a263d0 in main Fuzzer/build/../FuzzerMain.cpp:20:10
 #13 0x7fbe07bdc082 in __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x24082)
 #14 0x42529d in _start (ffmpeg/tools/target_dem_caf_fuzzer+0x42529d)









And is the bits_per_coded_sample > 64 check to prevent codec_id being
AV_CODEC_ID_NONE? if so, how does that affect demuxing time?
AV_CODEC_ID_NONE for that matter could happen for valid files with a codec
we don't currently support.


We generally check read values for validity at the earliest,
bits_per_coded_sample of more than 64 seem not valid to me.


I agree the check is fine, but my point is that, assuming this is affecting
demuxing time, th

[FFmpeg-devel] [PATCH v3 0/5] avfilter/af_volumedetect.c: Add 32bit float audio

[Yigithan Yigit]

changes since v1:
- Defined callback and assigning to filter frame according to planar/packed and 
float/int.
- Fixed rounding same value 2 times
- Subnormal values are supported
- Replaced square division with ldexp

Yigithan Yigit (5):
  avfilter/af_volumedetect.c: Move logdb function
  avfilter/af_volumedetect.c: Add 32bit float audio support
  avfilter/af_volumedetect.c: Added functions for int/float and
planar/packed
  avfilter/af_volumedetect.c: reindent after last commit
  Replace division with ldexp

 libavfilter/af_volumedetect.c | 255 ++
 1 file changed, 198 insertions(+), 57 deletions(-)

--
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 v3 1/5] avfilter/af_volumedetect.c: Move logdb function

[Yigithan Yigit]

---
 libavfilter/af_volumedetect.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/libavfilter/af_volumedetect.c b/libavfilter/af_volumedetect.c
index 8b001d1cf2..327801a7f9 100644
--- a/libavfilter/af_volumedetect.c
+++ b/libavfilter/af_volumedetect.c
@@ -24,6 +24,8 @@
 #include "avfilter.h"
 #include "internal.h"
 
+#define MAX_DB 91
+
 typedef struct VolDetectContext {
 /**
  * Number of samples at each PCM value.
@@ -33,6 +35,14 @@ typedef struct VolDetectContext {
 uint64_t histogram[0x10001];
 } VolDetectContext;
 
+static inline double logdb(uint64_t v)
+{
+double d = v / (double)(0x8000 * 0x8000);
+if (!v)
+return MAX_DB;
+return -log10(d) * 10;
+}
+
 static int filter_frame(AVFilterLink *inlink, AVFrame *samples)
 {
 AVFilterContext *ctx = inlink->dst;
@@ -56,16 +66,6 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*samples)
 return ff_filter_frame(inlink->dst->outputs[0], samples);
 }
 
-#define MAX_DB 91
-
-static inline double logdb(uint64_t v)
-{
-double d = v / (double)(0x8000 * 0x8000);
-if (!v)
-return MAX_DB;
-return -log10(d) * 10;
-}
-
 static void print_stats(AVFilterContext *ctx)
 {
 VolDetectContext *vd = ctx->priv;
-- 
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 v3 2/5] avfilter/af_volumedetect.c: Add 32bit float audio support

[Yigithan Yigit]

---
 libavfilter/af_volumedetect.c | 139 ++
 1 file changed, 107 insertions(+), 32 deletions(-)

diff --git a/libavfilter/af_volumedetect.c b/libavfilter/af_volumedetect.c
index 327801a7f9..edd2d56f7a 100644
--- a/libavfilter/af_volumedetect.c
+++ b/libavfilter/af_volumedetect.c
@@ -1,5 +1,6 @@
 /*
  * Copyright (c) 2012 Nicolas George
+ * Copyright (c) 2024 Yigithan Yigit - 32 Bit Float Audio Support
  *
  * This file is part of FFmpeg.
  *
@@ -20,48 +21,62 @@
 
 #include "libavutil/channel_layout.h"
 #include "libavutil/avassert.h"
+#include "libavutil/mem.h"
 #include "audio.h"
 #include "avfilter.h"
 #include "internal.h"
 
+#define MAX_DB_FLT 1024
 #define MAX_DB 91
+#define HISTOGRAM_SIZE 0x1
+#define HISTOGRAM_SIZE_FLT (MAX_DB_FLT*2)
+
+typedef struct VolDetectContext VolDetectContext;
 
 typedef struct VolDetectContext {
-/**
- * Number of samples at each PCM value.
- * histogram[0x8000 + i] is the number of samples at value i.
- * The extra element is there for symmetry.
- */
-uint64_t histogram[0x10001];
+uint64_t* histogram; ///< for integer number of samples at each PCM value, 
for float number of samples at each dB
+uint64_t nb_samples; ///< number of samples
+double sum2; ///< sum of the squares of the samples
+double max;  ///< maximum sample value
+int is_float;///< true if the input is in floating point
+void (*process_samples)(VolDetectContext *vd, AVFrame *samples);
 } VolDetectContext;
 
-static inline double logdb(uint64_t v)
+static inline double logdb(double v, enum AVSampleFormat sample_fmt)
 {
-double d = v / (double)(0x8000 * 0x8000);
-if (!v)
-return MAX_DB;
-return -log10(d) * 10;
+if (sample_fmt == AV_SAMPLE_FMT_FLT) {
+if (!v)
+return MAX_DB_FLT;
+return -log10(v) * 10;
+} else {
+double d = v / (double)(0x8000 * 0x8000);
+if (!v)
+return MAX_DB;
+return -log10(d) * 10;
+}
+}
+
+static void update_float_stats(VolDetectContext *vd, float *audio_data)
+{
+double sample;
+int idx;
+if(!isfinite(*audio_data) || isnan(*audio_data))
+return;
+sample = fabsf(*audio_data);
+if (sample > vd->max)
+vd->max = sample;
+vd->sum2 += sample * sample;
+idx = (int)floorf(logdb(sample * sample, AV_SAMPLE_FMT_FLT)) + MAX_DB_FLT;
+vd->histogram[idx]++;
+vd->nb_samples++;
 }
 
 static int filter_frame(AVFilterLink *inlink, AVFrame *samples)
 {
 AVFilterContext *ctx = inlink->dst;
 VolDetectContext *vd = ctx->priv;
-int nb_samples  = samples->nb_samples;
-int nb_channels = samples->ch_layout.nb_channels;
-int nb_planes   = nb_channels;
-int plane, i;
-int16_t *pcm;
-
-if (!av_sample_fmt_is_planar(samples->format)) {
-nb_samples *= nb_channels;
-nb_planes = 1;
-}
-for (plane = 0; plane < nb_planes; plane++) {
-pcm = (int16_t *)samples->extended_data[plane];
-for (i = 0; i < nb_samples; i++)
-vd->histogram[pcm[i] + 0x8000]++;
-}
+
+vd->process_samples(vd, samples);
 
 return ff_filter_frame(inlink->dst->outputs[0], samples);
 }
@@ -73,6 +88,20 @@ static void print_stats(AVFilterContext *ctx)
 uint64_t nb_samples = 0, power = 0, nb_samples_shift = 0, sum = 0;
 uint64_t histdb[MAX_DB + 1] = { 0 };
 
+if (!vd->nb_samples)
+return;
+if (vd->is_float) {
+av_log(ctx, AV_LOG_INFO, "n_samples: %" PRId64 "\n", vd->nb_samples);
+av_log(ctx, AV_LOG_INFO, "mean_volume: %.1f dB\n", -logdb(vd->sum2 / 
vd->nb_samples, AV_SAMPLE_FMT_FLT));
+av_log(ctx, AV_LOG_INFO, "max_volume: %.1f dB\n", -2.0*logdb(vd->max, 
AV_SAMPLE_FMT_FLT));
+for (i = 0; i < HISTOGRAM_SIZE_FLT && !vd->histogram[i]; i++);
+for (; i >= 0 && sum < vd->nb_samples / 1000; i++) {
+if (!vd->histogram[i])
+continue;
+av_log(ctx, AV_LOG_INFO, "histogram_%ddb: %" PRId64 "\n", 
MAX_DB_FLT - i, vd->histogram[i]);
+sum += vd->histogram[i];
+}
+} else {
 for (i = 0; i < 0x1; i++)
 nb_samples += vd->histogram[i];
 av_log(ctx, AV_LOG_INFO, "n_samples: %"PRId64"\n", nb_samples);
@@ -92,26 +121,61 @@ static void print_stats(AVFilterContext *ctx)
 return;
 power = (power + nb_samples_shift / 2) / nb_samples_shift;
 av_assert0(power <= 0x8000 * 0x8000);
-av_log(ctx, AV_LOG_INFO, "mean_volume: %.1f dB\n", -logdb(power));
+av_log(ctx, AV_LOG_INFO, "mean_volume: %.1f dB\n", -logdb((double)power, 
AV_SAMPLE_FMT_S16));
 
 max_volume = 0x8000;
 while (max_volume > 0 && !vd->histogram[0x8000 + max_volume] &&
  !vd->histogram[0x8000 - max_volume])
 max_volume--;
-av_log(ctx, AV_LOG_INFO, "max_volume: %.1f dB\n", -logdb(max_volume * 
max_volume));
+av_log(ctx, AV_LOG_INFO, "max_volume: %.1f dB\n", 
-logdb((

[FFmpeg-devel] [PATCH v3 3/5] avfilter/af_volumedetect.c: Added functions for int/float and planar/packed

[Yigithan Yigit]

---
 libavfilter/af_volumedetect.c | 66 +++
 1 file changed, 66 insertions(+)

diff --git a/libavfilter/af_volumedetect.c b/libavfilter/af_volumedetect.c
index edd2d56f7a..778f0cac6c 100644
--- a/libavfilter/af_volumedetect.c
+++ b/libavfilter/af_volumedetect.c
@@ -71,6 +71,64 @@ static void update_float_stats(VolDetectContext *vd, float 
*audio_data)
 vd->nb_samples++;
 }
 
+static void process_float_planar_samples(VolDetectContext *vd, AVFrame 
*samples)
+{
+int plane, i;
+int nb_channels = samples->ch_layout.nb_channels;
+int nb_samples  = samples->nb_samples;
+float *audio_data;
+for (plane = 0; plane < nb_channels; plane++) {
+audio_data = (float *)samples->extended_data[plane];
+for (i = 0; i < nb_samples; i++) {
+update_float_stats(vd, &audio_data[i]);
+}
+}
+}
+
+static void process_float_packed_samples(VolDetectContext *vd, AVFrame 
*samples)
+{
+int i, j;
+int nb_channels = samples->ch_layout.nb_channels;
+int nb_samples  = samples->nb_samples;
+float *audio_data;
+for (i = 0; i < nb_samples; i++) {
+audio_data = (float *)samples->extended_data[0];
+for (j = 0; j < nb_channels; j++) {
+   update_float_stats(vd, &audio_data[i * nb_channels + j]);
+}
+}
+}
+
+static void process_int_planar_samples(VolDetectContext *vd, AVFrame *samples)
+{
+int plane, i;
+int nb_channels = samples->ch_layout.nb_channels;
+int nb_samples  = samples->nb_samples;
+int16_t *pcm;
+for (plane = 0; plane < nb_channels; plane++) {
+pcm = (int16_t *)samples->extended_data[plane];
+for (i = 0; i < nb_samples; i++) {
+vd->histogram[pcm[i] + 0x8000]++;
+vd->nb_samples++;
+}
+}
+}
+
+static void process_int_packed_samples(VolDetectContext *vd, AVFrame *samples)
+{
+int i, j;
+int nb_channels = samples->ch_layout.nb_channels;
+int nb_samples  = samples->nb_samples;
+int16_t *pcm;
+for (i = 0; i < nb_samples; i++) {
+pcm = (int16_t *)samples->extended_data[0];
+for (j = 0; j < nb_channels; j++) {
+vd->histogram[pcm[i * nb_channels + j] + 0x8000]++;
+vd->nb_samples++;
+}
+}
+}
+
 static int filter_frame(AVFilterLink *inlink, AVFrame *samples)
 {
 AVFilterContext *ctx = inlink->dst;
@@ -157,12 +215,20 @@ static int config_output(AVFilterLink *outlink)
 * The extra element is there for symmetry.
 */
 histogram_size = HISTOGRAM_SIZE + 1;
+if (av_sample_fmt_is_planar(outlink->format))
+ vd->process_samples = process_int_planar_samples;
+ else
+ vd->process_samples = process_int_packed_samples;
 } else {
 /*
 * The histogram is used to store the number of samples at each dB
 * instead of the number of samples at each PCM value.
 */
 histogram_size = HISTOGRAM_SIZE_FLT + 1;
+if (av_sample_fmt_is_planar(outlink->format))
+ vd->process_samples = process_float_planar_samples;
+ else
+ vd->process_samples = process_float_packed_samples;
 }
 vd->histogram = av_calloc(histogram_size, sizeof(uint64_t));
 if (!vd->histogram)
-- 
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 v3 4/5] avfilter/af_volumedetect.c: reindent after last commit

[Yigithan Yigit]

---
 libavfilter/af_volumedetect.c | 62 +--
 1 file changed, 31 insertions(+), 31 deletions(-)

diff --git a/libavfilter/af_volumedetect.c b/libavfilter/af_volumedetect.c
index 778f0cac6c..a53212015d 100644
--- a/libavfilter/af_volumedetect.c
+++ b/libavfilter/af_volumedetect.c
@@ -160,40 +160,40 @@ static void print_stats(AVFilterContext *ctx)
 sum += vd->histogram[i];
 }
 } else {
-for (i = 0; i < 0x1; i++)
-nb_samples += vd->histogram[i];
-av_log(ctx, AV_LOG_INFO, "n_samples: %"PRId64"\n", nb_samples);
-if (!nb_samples)
-return;
+for (i = 0; i < 0x1; i++)
+nb_samples += vd->histogram[i];
+av_log(ctx, AV_LOG_INFO, "n_samples: %"PRId64"\n", nb_samples);
+if (!nb_samples)
+return;
 
-/* If nb_samples > 1<<34, there is a risk of overflow in the
-   multiplication or the sum: shift all histogram values to avoid that.
-   The total number of samples must be recomputed to avoid rounding
-   errors. */
-shift = av_log2(nb_samples >> 33);
-for (i = 0; i < 0x1; i++) {
-nb_samples_shift += vd->histogram[i] >> shift;
-power += (i - 0x8000) * (i - 0x8000) * (vd->histogram[i] >> shift);
-}
-if (!nb_samples_shift)
-return;
-power = (power + nb_samples_shift / 2) / nb_samples_shift;
-av_assert0(power <= 0x8000 * 0x8000);
-av_log(ctx, AV_LOG_INFO, "mean_volume: %.1f dB\n", -logdb((double)power, 
AV_SAMPLE_FMT_S16));
+/* If nb_samples > 1<<34, there is a risk of overflow in the
+multiplication or the sum: shift all histogram values to avoid that.
+The total number of samples must be recomputed to avoid rounding
+errors. */
+shift = av_log2(nb_samples >> 33);
+for (i = 0; i < 0x1; i++) {
+nb_samples_shift += vd->histogram[i] >> shift;
+power += (i - 0x8000) * (i - 0x8000) * (vd->histogram[i] >> shift);
+}
+if (!nb_samples_shift)
+return;
+power = (power + nb_samples_shift / 2) / nb_samples_shift;
+av_assert0(power <= 0x8000 * 0x8000);
+av_log(ctx, AV_LOG_INFO, "mean_volume: %.1f dB\n", 
-logdb((double)power, AV_SAMPLE_FMT_S16));
 
-max_volume = 0x8000;
-while (max_volume > 0 && !vd->histogram[0x8000 + max_volume] &&
- !vd->histogram[0x8000 - max_volume])
-max_volume--;
-av_log(ctx, AV_LOG_INFO, "max_volume: %.1f dB\n", 
-logdb((double)(max_volume * max_volume), AV_SAMPLE_FMT_S16));
+max_volume = 0x8000;
+while (max_volume > 0 && !vd->histogram[0x8000 + max_volume] &&
+!vd->histogram[0x8000 - max_volume])
+max_volume--;
+av_log(ctx, AV_LOG_INFO, "max_volume: %.1f dB\n", 
-logdb((double)(max_volume * max_volume), AV_SAMPLE_FMT_S16));
 
-for (i = 0; i < 0x1; i++)
-histdb[(int)logdb((double)(i - 0x8000) * (i - 0x8000), 
AV_SAMPLE_FMT_S16)] += vd->histogram[i];
-for (i = 0; i <= MAX_DB && !histdb[i]; i++);
-for (; i <= MAX_DB && sum < nb_samples / 1000; i++) {
-av_log(ctx, AV_LOG_INFO, "histogram_%ddb: %"PRId64"\n", -i, histdb[i]);
-sum += histdb[i];
-}
+for (i = 0; i < 0x1; i++)
+histdb[(int)logdb((double)(i - 0x8000) * (i - 0x8000), 
AV_SAMPLE_FMT_S16)] += vd->histogram[i];
+for (i = 0; i <= MAX_DB && !histdb[i]; i++);
+for (; i <= MAX_DB && sum < nb_samples / 1000; i++) {
+av_log(ctx, AV_LOG_INFO, "histogram_%ddb: %"PRId64"\n", -i, 
histdb[i]);
+sum += histdb[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 v3 5/5] Replace division with ldexp

[Yigithan Yigit]

---
 libavfilter/af_volumedetect.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/af_volumedetect.c b/libavfilter/af_volumedetect.c
index a53212015d..856d5a295d 100644
--- a/libavfilter/af_volumedetect.c
+++ b/libavfilter/af_volumedetect.c
@@ -49,7 +49,7 @@ static inline double logdb(double v, enum AVSampleFormat 
sample_fmt)
 return MAX_DB_FLT;
 return -log10(v) * 10;
 } else {
-double d = v / (double)(0x8000 * 0x8000);
+double d = ldexp(v, -30);
 if (!v)
 return MAX_DB;
 return -log10(d) * 10;
-- 
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 v3] avformat/dvdvideodec: Fix incorrect padding cell trim logic

[Marth64]

When -trim option is used (by default), padding cells
at the beginning of the title are supposed to be ignored.
The current implementation does the ignoring after we
have locked on to the PGC navigation event stream,
but does not set the PGC/PG state properly.

This causes false positives and errors on some discs
due to a search for a program stream cell that
never succeeds. User would have to know to disable
the -trim option to work around the issue.

Simplify the logic and move it to the NAV packet
event handling, in turn implementing the behaviour
correctly and fixing the trim function for impacted discs.

Signed-off-by: Marth64 
---
 libavformat/dvdvideodec.c | 23 ++-
 1 file changed, 10 insertions(+), 13 deletions(-)

diff --git a/libavformat/dvdvideodec.c b/libavformat/dvdvideodec.c
index e7132725b7..f5b7dd33e5 100644
--- a/libavformat/dvdvideodec.c
+++ b/libavformat/dvdvideodec.c
@@ -624,7 +624,6 @@ static int dvdvideo_play_next_ps_block(AVFormatContext *s, 
DVDVideoPlaybackState
 dvdnav_vts_change_event_t *e_vts;
 dvdnav_cell_change_event_t *e_cell;
 int cur_title, cur_pgcn, cur_pgn, cur_angle, cur_title_unused, cur_ptt, 
cur_nb_angles;
-int is_cell_promising = 0;
 pci_t *e_pci;
 dsi_t *e_dsi;
 
@@ -706,23 +705,17 @@ static int dvdvideo_play_next_ps_block(AVFormatContext 
*s, DVDVideoPlaybackState
 continue;
 
 e_cell = (dvdnav_cell_change_event_t *) nav_buf;
-is_cell_promising = !c->opt_trim || 
dvdvideo_is_cell_promising(s, state->pgc, e_cell->cellN);
 
-av_log(s, AV_LOG_DEBUG, "new cell: prev=%d new=%d 
promising=%d\n",
-state->celln, e_cell->cellN, 
is_cell_promising);
+av_log(s, AV_LOG_DEBUG, "new cell: prev=%d new=%d\n", 
state->celln, e_cell->cellN);
 
 if (!state->in_ps && !state->in_pgc) {
 if (cur_title == c->opt_title&&
 (c->opt_pgc || cur_ptt == c->opt_chapter_start)  &&
 cur_pgcn == state->pgcn  &&
-cur_pgn == state->entry_pgn  &&
-is_cell_promising) {
+cur_pgn == state->entry_pgn) {
 
 state->in_pgc = 1;
 }
-
-if (c->opt_trim && !is_cell_promising)
-av_log(s, AV_LOG_INFO, "Skipping padding cell #%d\n", 
e_cell->cellN);
 } else if (state->celln >= e_cell->cellN || state->pgn > 
cur_pgn) {
 return AVERROR_EOF;
 }
@@ -766,6 +759,13 @@ static int dvdvideo_play_next_ps_block(AVFormatContext *s, 
DVDVideoPlaybackState
e_pci->pci_gi.nv_pck_lbn, state->vobu_duration, 
state->nav_pts);
 
 if (!state->in_ps) {
+if (c->opt_trim && !dvdvideo_is_cell_promising(s, 
state->pgc, state->celln)) {
+av_log(s, AV_LOG_INFO, "Skipping padding cell #%d\n", 
state->celln);
+
+i = 0;
+continue;
+}
+
 av_log(s, AV_LOG_DEBUG, "navigation: locked to program 
stream\n");
 
 state->in_ps = 1;
@@ -784,11 +784,8 @@ static int dvdvideo_play_next_ps_block(AVFormatContext *s, 
DVDVideoPlaybackState
 
 return nav_len;
 case DVDNAV_BLOCK_OK:
-if (!state->in_ps) {
-if (state->in_pgc)
-i = 0; /* necessary in case we are skipping junk cells 
at the beginning */
+if (!state->in_ps)
 continue;
-}
 
 if (nav_len != DVDVIDEO_BLOCK_SIZE) {
 av_log(s, AV_LOG_ERROR, "Invalid MPEG block size 
(expected=%d actual=%d)\n",
-- 
2.34.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v3 1/3] lavu/opt: Rename AV_OPT_FLAG_RUNTIME_PARAM to ...POST_INIT_SETTABLE_PARAM

[Zhao Zhili]

> 在 2024年7月2日，上午6:33，Stefano Sabatini  写道：
> 
> On date Sunday 2024-06-16 18:08:29 +0100, Andrew Sayers wrote:
>> The old name could be misread as the opposite of "AV_OPT_FLAG_READONLY" -
>> some things can be set at runtime, others are read-only.  Clarify that
>> this refers to options that can be set after the struct is initialized.

Let’s not bother the user again and again for little benefit. Add doc is fine, 
please don’t rename the flag.

>> ---
>> libavutil/opt.h | 10 +-
>> 1 file changed, 9 insertions(+), 1 deletion(-)
>> 
>> diff --git a/libavutil/opt.h b/libavutil/opt.h
>> index 07e27a9208..e050d126ed 100644
>> --- a/libavutil/opt.h
>> +++ b/libavutil/opt.h
>> @@ -53,6 +53,9 @@
>>  * question is allowed to access the field. This allows us to extend the
>>  * semantics of those fields without breaking API compatibility.
>>  *
>> + * Note: only options with the AV_OPT_FLAG_POST_INIT_SETTABLE_PARAM flag 
>> can be
>> + * modified after the struct is initialized.
>> + *
>>  * @section avoptions_scope Scope of AVOptions
>>  *
>>  * AVOptions is designed to support any set of multimedia configuration 
>> options
>> @@ -300,7 +303,12 @@ enum AVOptionType{
>> #define AV_OPT_FLAG_BSF_PARAM   (1 << 8)
>> 
>> /**
>> - * A generic parameter which can be set by the user at runtime.
>> + * A generic parameter which can be set by the user after the struct is 
>> initialized.
>> + */
>> +#define AV_OPT_FLAG_POST_INIT_SETTABLE_PARAM   (1 << 15)
> 
> This needs to be dropped at the next bump.
> 
> 1. define in libavutil/version.h
> 
> #define FF_API_OPT_FLAG_RUNTIME_PARAM  (LIBAVUTIL_VERSION_MAJOR < 60)
> 
> 2. ifdef to automatically drop this at the next bump
> 
> #if FF_API_OPT_FLAG_RUNTIME_PARAM
> /**
> * A generic parameter which can be set by the user after the struct is 
> initialized.
> * @deprecated Renamed to AV_OPT_FLAG_POST_INIT_SETTABLE_PARAM for clarity
>  */
> #define AV_OPT_FLAG_RUNTIME_PARAM   (1 << 15)
> #endif
> 
> 3. add a note to doc/APIchanges for the new symbol.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email

___
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] swresample/swresample: Rectify invalid function in the documentation

[marszuo]

From: Mars Zuo 

The function av_opt_set_channel_layout has been removed since
version 7.0, and the replacement is av_opt_set_chlayout.
The documentation needs to be updated accordingly.
---
 libswresample/swresample.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libswresample/swresample.h b/libswresample/swresample.h
index 217e5461bf..0e1929b3ed 100644
--- a/libswresample/swresample.h
+++ b/libswresample/swresample.h
@@ -49,8 +49,8 @@
  * matrix). This is using the swr_alloc() function.
  * @code
  * SwrContext *swr = swr_alloc();
- * av_opt_set_channel_layout(swr, "in_channel_layout",  AV_CH_LAYOUT_5POINT1, 
0);
- * av_opt_set_channel_layout(swr, "out_channel_layout", AV_CH_LAYOUT_STEREO,  
0);
+ * av_opt_set_chlayout(swr, "in_chlayout", 
&(AVChannelLayout)AV_CHANNEL_LAYOUT_5POINT1, 0);
+ * av_opt_set_chlayout(swr, "out_chlayout", 
&(AVChannelLayout)AV_CHANNEL_LAYOUT_STEREO, 0);
  * av_opt_set_int(swr, "in_sample_rate", 48000,0);
  * av_opt_set_int(swr, "out_sample_rate",44100,0);
  * av_opt_set_sample_fmt(swr, "in_sample_fmt",  AV_SAMPLE_FMT_FLTP, 0);
-- 
2.39.3 (Apple Git-146)

___
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] [RFC] av_rescale() coverity

[Vittorio Giovara]

On Mon, Jul 1, 2024 at 11:00 PM Michael Niedermayer 
wrote:

> On Mon, Jul 01, 2024 at 10:19:31PM +0200, Michael Niedermayer wrote:
> > On Mon, Jul 01, 2024 at 08:50:24PM +0200, Timo Rothenpieler wrote:
> > > On 01.07.2024 15:39, Michael Niedermayer wrote:
> > > > Hi all
> > > >
> > > > coverity seems to have started to do a new thing. Namely if theres a
> > > > return statement it assumes it can independant of everything occurr
> > > >
> > > > an example would be av_rescale() which on overflow returns INT64_MIN
> > > >
> > > > also with the right flags av_rescale() will pass INT64_MIN and
> INT64_MAX through
> > > > from the input
> > > >
> > > > So coverity since a few days seems to treat every av_rescale() call
> as if it returns
> > > > INT64_MIN and INT64_MAX. coverity doesnt care if that return
> statement is reachable or
> > > > if the flags even include the execution path.
> > > >
> > > > An example is this:
> > > >  AVRational time_base_q = AV_TIME_BASE_Q;
> > > >  int64_t next_dts = av_rescale_q(ds->next_dts,
> time_base_q, av_inv_q(ist->framerate));
> > > >  ds->next_dts = av_rescale_q(next_dts + 1,
> av_inv_q(ist->framerate), time_base_q);
> > > >
> > > > Here coverity as a initial statement claims next_dts is INT64_MAX
> > > > and next_dts + 1 would overflow
> > > >
> > > >
> > > >  8. function_return: Function av_rescale_q(ds->next_dts,
> time_base_q, av_inv_q(ist->framerate)) returns 9223372036854775807.
> > > >  9. known_value_assign: next_dts =
> av_rescale_q(ds->next_dts, time_base_q, av_inv_q(ist->framerate)), its
> value is now 9223372036854775807.
> > > >  331int64_t next_dts = av_rescale_q(ds->next_dts,
> time_base_q, av_inv_q(ist->framerate));
> > > >
> > > >  CID 1604545: (#1 of 1): Overflowed constant (INTEGER_OVERFLOW)
> > > >  10. overflow_const: Expression next_dts + 1LL, which is equal
> to -9223372036854775808, where next_dts is known to be equal to
> 9223372036854775807, overflows the type that receives it, a signed integer
> 64 bits wide.
> > > >
> > > >
> > > > another example is this:
> > > >
> > > >  #define AV_TIME_BASE100
> > > >  pts = av_rescale(ds->dts, 100, AV_TIME_BASE);
> > > >
> > > > coverity hallucinates pts as a tainted negative number here nothing
> says anything about
> > > > the input ds->dts (and thats what would matter)
> > > >
> > > > In the past coverity provided a detailed list of steps on how a
> > > > case is reached. One could then check these assumtions and mark
> things
> > > > as false positive when one assumtion is wrong. (coverity was most of
> the time
> > > > wrong)
> > > >
> > > > Now coverity just hallucinates claims out of the blue without any
> > > > explanation how that can happen.
> > > >
> > > > Iam a bit at a loss how to deal with this and also why exactly this
> > > > new behavior appeared.
> > > >
> > > > Has anyone changed any setting or anything in coverity ?
> > > >
> > > > The number of issues shot up to over 400 on the 22th june
> > > > "194 new defect(s) introduced to FFmpeg/FFmpeg found with Coverity
> Scan."
> > >
> > > Do you mean May?
> > > Cause that's when I enabled also giving a Windows-Build to Coverity:
> > >
> https://github.com/FFmpeg/FFmpeg-Coverity/commit/3116e6960406f01f96d934516216bb3b402122fc
> > >
> > > Before that, only Linux was analyzed.
> >
> > no the 194 appeared in june
> >
> > I did saw some other spike of issues appear month? earlier or so but
> these seemed
> > mostly old issues that where detected prior already.
> > and i dont see it in teh numbers coverity mails me
> >
>
> > Only other spike i can find in the numbers was 11 feb 2024
> > 103 new defect(s) introduced to FFmpeg/FFmpeg found with Coverity Scan.
>
> The mail for the windows spike went to my old email address from gmx, was
> misidentified as spam and deleted by gmx. gmx "recently" forced their
> broken
> spam detection to be enabled even when explicitly disabled by the customer.
> One has to download the mails from a specific folder on their IMAP server
> within a month it seems. Which i didnt because i had their whole broken
> spam detection disabled
>
> Its not imprtant but if someone has all the coverity mails, a list of
> new and fixed bugs on each run would be interresting
>
> thx


Have you tried getting in touch with coverity support about this new
behavior?
-- 
Vittorio
___
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] doc/filter: fix grammar in tiltandshift filter

[Gyan Doshi]

---
 doc/filters.texi | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 0ff7c142b6..c9c4f7cf6b 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -23546,13 +23546,13 @@ tile=3x2:nb_frames=5:padding=7:margin=2
 @end itemize
 
 @section tiltandshift
-Apply tilt-and-shift effet.
+Apply tilt-and-shift effect.
 
 What happens when you invert time and space?
 
 Normally a video is composed of several frames that represent a different
 instant of time and shows a scene that evolves in the space captured by the
-frame. This filter is the antipode of that concept, taking inspiration by
+frame. This filter is the antipode of that concept, taking inspiration from
 tilt and shift photography.
 
 A filtered frame contains the whole timeline of events composing the sequence,
@@ -23591,7 +23591,7 @@ How many columns should be inserted before end of 
filtering.
 
 @end table
 
-Normally the filter shifts and tils from the very first frame, and stops when
+Normally the filter shifts and tilts from the very first frame, and stops when
 the last one is received. However, before filtering starts, normal video may
 be preseved, so that the effect is slowly shifted in its place. Similarly,
 the last video frame may be reconstructed at the end. Alternatively it is
@@ -23599,7 +23599,7 @@ possible to just start and end with black.
 
 @table @samp
 @item none
-Filtering is starts immediately and ends when the last frame is received.
+Filtering starts immediately and ends when the last frame is received.
 
 @item frame
 The first frames or the very last frame are kept intact during processing.
-- 
2.44.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH] avformat/dvdvideodec: Don't add chapter markers for empty/dummy PTTs

[Marth64]

Some discs (usually same ones with padding cells), also have empty
padding PTTs / chapters to accompany them. This results, for example,
in an extra chapter marker that starts and ends at 0 (no duration).

Don't add these empty chapter markers.

Signed-off-by: Marth64 
---
 libavformat/dvdvideodec.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/libavformat/dvdvideodec.c b/libavformat/dvdvideodec.c
index f5b7dd33e5..0bf1a82ef9 100644
--- a/libavformat/dvdvideodec.c
+++ b/libavformat/dvdvideodec.c
@@ -874,6 +874,9 @@ static int dvdvideo_chapters_setup_simple(AVFormatContext 
*s)
 for (int i = chapter_start - 1; i < chapter_end; i++) {
 uint64_t time_effective = c->play_state.pgc_pg_times_est[i] - 
c->play_state.nav_pts;
 
+if (time_effective - time_prev == 0)
+continue;
+
 if (chapter_start != chapter_end &&
 !avpriv_new_chapter(s, i, DVDVIDEO_TIME_BASE_Q, time_prev, 
time_effective, NULL)) {
 
@@ -934,13 +937,16 @@ static int 
dvdvideo_chapters_setup_preindex(AVFormatContext *s)
 continue;
 }
 
-if (!avpriv_new_chapter(s, nb_chapters, DVDVIDEO_TIME_BASE_Q, 
cur_chapter_offset,
-cur_chapter_offset + cur_chapter_duration, 
NULL)) {
-ret = AVERROR(ENOMEM);
-goto end_close;
+if (cur_chapter_duration > 0) {
+if (!avpriv_new_chapter(s, nb_chapters, DVDVIDEO_TIME_BASE_Q, 
cur_chapter_offset,
+cur_chapter_offset + cur_chapter_duration, 
NULL)) {
+ret = AVERROR(ENOMEM);
+goto end_close;
+}
+
+nb_chapters++;
 }
 
-nb_chapters++;
 cur_chapter_offset += cur_chapter_duration;
 cur_chapter_duration = state.vobu_duration;
 last_ptt = state.ptt;
-- 
2.34.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v3 2/5] avfilter/af_volumedetect.c: Add 32bit float audio support

[Rémi Denis-Courmont]

Le 2 juillet 2024 04:33:51 GMT+03:00, Yigithan Yigit 
 a écrit :
>---
> libavfilter/af_volumedetect.c | 139 ++
> 1 file changed, 107 insertions(+), 32 deletions(-)

Did you try to compile this patch?

>
>diff --git a/libavfilter/af_volumedetect.c b/libavfilter/af_volumedetect.c
>index 327801a7f9..edd2d56f7a 100644
>--- a/libavfilter/af_volumedetect.c
>+++ b/libavfilter/af_volumedetect.c
>@@ -1,5 +1,6 @@
> /*
>  * Copyright (c) 2012 Nicolas George
>+ * Copyright (c) 2024 Yigithan Yigit - 32 Bit Float Audio Support
>  *
>  * This file is part of FFmpeg.
>  *
>@@ -20,48 +21,62 @@
> 
> #include "libavutil/channel_layout.h"
> #include "libavutil/avassert.h"
>+#include "libavutil/mem.h"
> #include "audio.h"
> #include "avfilter.h"
> #include "internal.h"
> 
>+#define MAX_DB_FLT 1024
> #define MAX_DB 91
>+#define HISTOGRAM_SIZE 0x1
>+#define HISTOGRAM_SIZE_FLT (MAX_DB_FLT*2)
>+
>+typedef struct VolDetectContext VolDetectContext;
> 
> typedef struct VolDetectContext {
>-/**
>- * Number of samples at each PCM value.
>- * histogram[0x8000 + i] is the number of samples at value i.
>- * The extra element is there for symmetry.
>- */
>-uint64_t histogram[0x10001];
>+uint64_t* histogram; ///< for integer number of samples at each PCM 
>value, for float number of samples at each dB
>+uint64_t nb_samples; ///< number of samples
>+double sum2; ///< sum of the squares of the samples
>+double max;  ///< maximum sample value
>+int is_float;///< true if the input is in floating point
>+void (*process_samples)(VolDetectContext *vd, AVFrame *samples);
> } VolDetectContext;
> 
>-static inline double logdb(uint64_t v)
>+static inline double logdb(double v, enum AVSampleFormat sample_fmt)
> {
>-double d = v / (double)(0x8000 * 0x8000);
>-if (!v)
>-return MAX_DB;
>-return -log10(d) * 10;
>+if (sample_fmt == AV_SAMPLE_FMT_FLT) {
>+if (!v)
>+return MAX_DB_FLT;
>+return -log10(v) * 10;
>+} else {
>+double d = v / (double)(0x8000 * 0x8000);
>+if (!v)
>+return MAX_DB;
>+return -log10(d) * 10;
>+}
>+}
>+
>+static void update_float_stats(VolDetectContext *vd, float *audio_data)
>+{
>+double sample;
>+int idx;
>+if(!isfinite(*audio_data) || isnan(*audio_data))
>+return;
>+sample = fabsf(*audio_data);
>+if (sample > vd->max)
>+vd->max = sample;
>+vd->sum2 += sample * sample;
>+idx = (int)floorf(logdb(sample * sample, AV_SAMPLE_FMT_FLT)) + MAX_DB_FLT;
>+vd->histogram[idx]++;
>+vd->nb_samples++;
> }
> 
> static int filter_frame(AVFilterLink *inlink, AVFrame *samples)
> {
> AVFilterContext *ctx = inlink->dst;
> VolDetectContext *vd = ctx->priv;
>-int nb_samples  = samples->nb_samples;
>-int nb_channels = samples->ch_layout.nb_channels;
>-int nb_planes   = nb_channels;
>-int plane, i;
>-int16_t *pcm;
>-
>-if (!av_sample_fmt_is_planar(samples->format)) {
>-nb_samples *= nb_channels;
>-nb_planes = 1;
>-}
>-for (plane = 0; plane < nb_planes; plane++) {
>-pcm = (int16_t *)samples->extended_data[plane];
>-for (i = 0; i < nb_samples; i++)
>-vd->histogram[pcm[i] + 0x8000]++;
>-}
>+
>+vd->process_samples(vd, samples);
> 
> return ff_filter_frame(inlink->dst->outputs[0], samples);
> }
>@@ -73,6 +88,20 @@ static void print_stats(AVFilterContext *ctx)
> uint64_t nb_samples = 0, power = 0, nb_samples_shift = 0, sum = 0;
> uint64_t histdb[MAX_DB + 1] = { 0 };
> 
>+if (!vd->nb_samples)
>+return;
>+if (vd->is_float) {
>+av_log(ctx, AV_LOG_INFO, "n_samples: %" PRId64 "\n", vd->nb_samples);
>+av_log(ctx, AV_LOG_INFO, "mean_volume: %.1f dB\n", -logdb(vd->sum2 / 
>vd->nb_samples, AV_SAMPLE_FMT_FLT));
>+av_log(ctx, AV_LOG_INFO, "max_volume: %.1f dB\n", -2.0*logdb(vd->max, 
>AV_SAMPLE_FMT_FLT));
>+for (i = 0; i < HISTOGRAM_SIZE_FLT && !vd->histogram[i]; i++);
>+for (; i >= 0 && sum < vd->nb_samples / 1000; i++) {
>+if (!vd->histogram[i])
>+continue;
>+av_log(ctx, AV_LOG_INFO, "histogram_%ddb: %" PRId64 "\n", 
>MAX_DB_FLT - i, vd->histogram[i]);
>+sum += vd->histogram[i];
>+}
>+} else {
> for (i = 0; i < 0x1; i++)
> nb_samples += vd->histogram[i];
> av_log(ctx, AV_LOG_INFO, "n_samples: %"PRId64"\n", nb_samples);
>@@ -92,26 +121,61 @@ static void print_stats(AVFilterContext *ctx)
> return;
> power = (power + nb_samples_shift / 2) / nb_samples_shift;
> av_assert0(power <= 0x8000 * 0x8000);
>-av_log(ctx, AV_LOG_INFO, "mean_volume: %.1f dB\n", -logdb(power));
>+av_log(ctx, AV_LOG_INFO, "mean_volume: %.1f dB\n", -logdb((double)power, 
>AV_SAMPLE_FMT_S16));
> 
> max_volume = 0x8000;
> while (max_volume > 0 && !vd->histogram[0x8000 + max_volume] &&
>

Re: [FFmpeg-devel] [PATCH v3 2/5] avfilter/af_volumedetect.c: Add 32bit float audio support

[Rémi Denis-Courmont]

Le 2 juillet 2024 08:46:53 GMT+03:00, "Rémi Denis-Courmont"  a 
écrit :
>
>
>Le 2 juillet 2024 04:33:51 GMT+03:00, Yigithan Yigit 
> a écrit :
>>---
>> libavfilter/af_volumedetect.c | 139 ++
>> 1 file changed, 107 insertions(+), 32 deletions(-)
>
>Did you try to compile this patch?

Nvmd misread.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v3 2/5] avfilter/af_volumedetect.c: Add 32bit float audio support

[Rémi Denis-Courmont]

Le 2 juillet 2024 04:33:51 GMT+03:00, Yigithan Yigit 
 a écrit :
>---
> libavfilter/af_volumedetect.c | 139 ++
> 1 file changed, 107 insertions(+), 32 deletions(-)
>
>diff --git a/libavfilter/af_volumedetect.c b/libavfilter/af_volumedetect.c
>index 327801a7f9..edd2d56f7a 100644
>--- a/libavfilter/af_volumedetect.c
>+++ b/libavfilter/af_volumedetect.c
>@@ -1,5 +1,6 @@
> /*
>  * Copyright (c) 2012 Nicolas George
>+ * Copyright (c) 2024 Yigithan Yigit - 32 Bit Float Audio Support
>  *
>  * This file is part of FFmpeg.
>  *
>@@ -20,48 +21,62 @@
> 
> #include "libavutil/channel_layout.h"
> #include "libavutil/avassert.h"
>+#include "libavutil/mem.h"
> #include "audio.h"
> #include "avfilter.h"
> #include "internal.h"
> 
>+#define MAX_DB_FLT 1024
> #define MAX_DB 91
>+#define HISTOGRAM_SIZE 0x1
>+#define HISTOGRAM_SIZE_FLT (MAX_DB_FLT*2)
>+
>+typedef struct VolDetectContext VolDetectContext;
> 
> typedef struct VolDetectContext {
>-/**
>- * Number of samples at each PCM value.
>- * histogram[0x8000 + i] is the number of samples at value i.
>- * The extra element is there for symmetry.
>- */
>-uint64_t histogram[0x10001];
>+uint64_t* histogram; ///< for integer number of samples at each PCM 
>value, for float number of samples at each dB
>+uint64_t nb_samples; ///< number of samples
>+double sum2; ///< sum of the squares of the samples
>+double max;  ///< maximum sample value
>+int is_float;///< true if the input is in floating point
>+void (*process_samples)(VolDetectContext *vd, AVFrame *samples);
> } VolDetectContext;
> 
>-static inline double logdb(uint64_t v)
>+static inline double logdb(double v, enum AVSampleFormat sample_fmt)
> {
>-double d = v / (double)(0x8000 * 0x8000);
>-if (!v)
>-return MAX_DB;
>-return -log10(d) * 10;
>+if (sample_fmt == AV_SAMPLE_FMT_FLT) {

There's no point in doing this. You've already up-converted to double precision 
and do all the calculations in double precision. Maybe that's fine or maybe 
not, but either way, this doesn't look sensible.

>+if (!v)
>+return MAX_DB_FLT;
>+return -log10(v) * 10;
>+} else {
>+double d = v / (double)(0x8000 * 0x8000);
>+if (!v)
>+return MAX_DB;
>+return -log10(d) * 10;
>+}
>+}
>+
>+static void update_float_stats(VolDetectContext *vd, float *audio_data)
>+{
>+double sample;
>+int idx;
>+if(!isfinite(*audio_data) || isnan(*audio_data))
>+return;
>+sample = fabsf(*audio_data);
>+if (sample > vd->max)
>+vd->max = sample;
>+vd->sum2 += sample * sample;
>+idx = (int)floorf(logdb(sample * sample, AV_SAMPLE_FMT_FLT)) + MAX_DB_FLT;
>+vd->histogram[idx]++;
>+vd->nb_samples++;
> }
> 
> static int filter_frame(AVFilterLink *inlink, AVFrame *samples)
> {
> AVFilterContext *ctx = inlink->dst;
> VolDetectContext *vd = ctx->priv;
>-int nb_samples  = samples->nb_samples;
>-int nb_channels = samples->ch_layout.nb_channels;
>-int nb_planes   = nb_channels;
>-int plane, i;
>-int16_t *pcm;
>-
>-if (!av_sample_fmt_is_planar(samples->format)) {
>-nb_samples *= nb_channels;
>-nb_planes = 1;
>-}
>-for (plane = 0; plane < nb_planes; plane++) {
>-pcm = (int16_t *)samples->extended_data[plane];
>-for (i = 0; i < nb_samples; i++)
>-vd->histogram[pcm[i] + 0x8000]++;
>-}
>+
>+vd->process_samples(vd, samples);
> 
> return ff_filter_frame(inlink->dst->outputs[0], samples);
> }
>@@ -73,6 +88,20 @@ static void print_stats(AVFilterContext *ctx)
> uint64_t nb_samples = 0, power = 0, nb_samples_shift = 0, sum = 0;
> uint64_t histdb[MAX_DB + 1] = { 0 };
> 
>+if (!vd->nb_samples)
>+return;
>+if (vd->is_float) {
>+av_log(ctx, AV_LOG_INFO, "n_samples: %" PRId64 "\n", vd->nb_samples);
>+av_log(ctx, AV_LOG_INFO, "mean_volume: %.1f dB\n", -logdb(vd->sum2 / 
>vd->nb_samples, AV_SAMPLE_FMT_FLT));
>+av_log(ctx, AV_LOG_INFO, "max_volume: %.1f dB\n", -2.0*logdb(vd->max, 
>AV_SAMPLE_FMT_FLT));
>+for (i = 0; i < HISTOGRAM_SIZE_FLT && !vd->histogram[i]; i++);
>+for (; i >= 0 && sum < vd->nb_samples / 1000; i++) {
>+if (!vd->histogram[i])
>+continue;
>+av_log(ctx, AV_LOG_INFO, "histogram_%ddb: %" PRId64 "\n", 
>MAX_DB_FLT - i, vd->histogram[i]);
>+sum += vd->histogram[i];
>+}
>+} else {
> for (i = 0; i < 0x1; i++)
> nb_samples += vd->histogram[i];
> av_log(ctx, AV_LOG_INFO, "n_samples: %"PRId64"\n", nb_samples);
>@@ -92,26 +121,61 @@ static void print_stats(AVFilterContext *ctx)
> return;
> power = (power + nb_samples_shift / 2) / nb_samples_shift;
> av_assert0(power <= 0x8000 * 0x8000);
>-av_log(ctx, AV_LOG_INFO, "mean_volume: %.1f dB\n", -logdb(power));
>+av_log(ctx, AV_LOG_INFO, 

[FFmpeg-devel] [PATCH] avformat/dvdvideodec: Remove redundant ret initializations

[Marth64]

Remove initializing ret = 0, in areas where ret is
only used to hold an error value, immediately returned,
and the function would otherwise return a literal 0.

Signed-off-by: Marth64 
---
 libavformat/dvdvideodec.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/libavformat/dvdvideodec.c b/libavformat/dvdvideodec.c
index f5b7dd33e5..a825e4c0bd 100644
--- a/libavformat/dvdvideodec.c
+++ b/libavformat/dvdvideodec.c
@@ -1056,7 +1056,7 @@ static int dvdvideo_video_stream_setup(AVFormatContext *s)
 {
 DVDVideoDemuxContext *c = s->priv_data;
 
-int ret = 0;
+int ret;
 DVDVideoVTSVideoStreamEntry entry = {0};
 video_attr_t video_attr;
 
@@ -1217,7 +1217,7 @@ static int dvdvideo_audio_stream_add_all(AVFormatContext 
*s)
 {
 DVDVideoDemuxContext *c = s->priv_data;
 
-int ret = 0;
+int ret;
 int nb_streams;
 
 if (c->opt_menu)
@@ -1324,7 +1324,7 @@ static int 
dvdvideo_subp_stream_add_internal(AVFormatContext *s, uint32_t offset
  subp_attr_t subp_attr,
  enum DVDVideoSubpictureViewport 
viewport)
 {
-int ret = 0;
+int ret;
 DVDVideoPGCSubtitleStreamEntry entry = {0};
 
 entry.viewport = viewport;
@@ -1361,7 +1361,7 @@ static int dvdvideo_subp_stream_add_all(AVFormatContext 
*s)
 
 
 for (int i = 0; i < nb_streams; i++) {
-int ret = 0;
+int ret;
 uint32_t subp_control;
 subp_attr_t subp_attr;
 video_attr_t video_attr;
@@ -1469,7 +1469,7 @@ static int dvdvideo_subdemux_open(AVFormatContext *s)
 {
 DVDVideoDemuxContext *c = s->priv_data;
 extern const FFInputFormat ff_mpegps_demuxer;
-int ret = 0;
+int ret;
 
 if (!(c->mpeg_buf = av_mallocz(DVDVIDEO_BLOCK_SIZE)))
 return AVERROR(ENOMEM);
@@ -1504,7 +1504,7 @@ static int dvdvideo_read_header(AVFormatContext *s)
 {
 DVDVideoDemuxContext *c = s->priv_data;
 
-int ret = 0;
+int ret;
 
 if (c->opt_menu) {
 if (c->opt_region   ||
-- 
2.34.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v3] avformat/dvdvideodec: Fix incorrect padding cell trim logic

[Marth64]

Gah. Screwed this one up again. See v4. (This will be the last time).
Sorry, this was a really frustrating one to fix/test.
___
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 v4] avformat/dvdvideodec: Fix incorrect padding cell trim logic

[Marth64]

When -trim option is used (by default), padding cells
at the beginning of the title are supposed to be ignored.
The current implementation does the ignoring after we
have locked on to the PGC navigation event stream,
but does not set the PGC/PG state properly.

This causes false positives and errors on some discs
due to a search for a program stream cell that
never succeeds. User would have to know to disable
the -trim option to work around the issue.

Simplify the logic and move it to the NAV packet
event handling, in turn implementing the behaviour
correctly and fixing the trim function for impacted discs.

Signed-off-by: Marth64 
---
 libavformat/dvdvideodec.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/libavformat/dvdvideodec.c b/libavformat/dvdvideodec.c
index e7132725b7..c694e8d00f 100644
--- a/libavformat/dvdvideodec.c
+++ b/libavformat/dvdvideodec.c
@@ -624,7 +624,6 @@ static int dvdvideo_play_next_ps_block(AVFormatContext *s, 
DVDVideoPlaybackState
 dvdnav_vts_change_event_t *e_vts;
 dvdnav_cell_change_event_t *e_cell;
 int cur_title, cur_pgcn, cur_pgn, cur_angle, cur_title_unused, cur_ptt, 
cur_nb_angles;
-int is_cell_promising = 0;
 pci_t *e_pci;
 dsi_t *e_dsi;
 
@@ -706,23 +705,17 @@ static int dvdvideo_play_next_ps_block(AVFormatContext 
*s, DVDVideoPlaybackState
 continue;
 
 e_cell = (dvdnav_cell_change_event_t *) nav_buf;
-is_cell_promising = !c->opt_trim || 
dvdvideo_is_cell_promising(s, state->pgc, e_cell->cellN);
 
-av_log(s, AV_LOG_DEBUG, "new cell: prev=%d new=%d 
promising=%d\n",
-state->celln, e_cell->cellN, 
is_cell_promising);
+av_log(s, AV_LOG_DEBUG, "new cell: prev=%d new=%d\n", 
state->celln, e_cell->cellN);
 
 if (!state->in_ps && !state->in_pgc) {
 if (cur_title == c->opt_title&&
 (c->opt_pgc || cur_ptt == c->opt_chapter_start)  &&
 cur_pgcn == state->pgcn  &&
-cur_pgn == state->entry_pgn  &&
-is_cell_promising) {
+cur_pgn == state->entry_pgn) {
 
 state->in_pgc = 1;
 }
-
-if (c->opt_trim && !is_cell_promising)
-av_log(s, AV_LOG_INFO, "Skipping padding cell #%d\n", 
e_cell->cellN);
 } else if (state->celln >= e_cell->cellN || state->pgn > 
cur_pgn) {
 return AVERROR_EOF;
 }
@@ -766,6 +759,13 @@ static int dvdvideo_play_next_ps_block(AVFormatContext *s, 
DVDVideoPlaybackState
e_pci->pci_gi.nv_pck_lbn, state->vobu_duration, 
state->nav_pts);
 
 if (!state->in_ps) {
+if (c->opt_trim && !dvdvideo_is_cell_promising(s, 
state->pgc, state->celln)) {
+av_log(s, AV_LOG_INFO, "Skipping padding cell #%d\n", 
state->celln);
+
+i = 0;
+continue;
+}
+
 av_log(s, AV_LOG_DEBUG, "navigation: locked to program 
stream\n");
 
 state->in_ps = 1;
-- 
2.34.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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