Re: [FFmpeg-devel] [PATCH] Update the Changelog for 7.0

2024-04-03 Thread Vittorio Giovara
On Thu, Apr 4, 2024 at 1:28 AM Jean-Baptiste Kempf  wrote:

> On Wed, 3 Apr 2024, at 23:18, Jean-Baptiste Kempf wrote:
> > As attached.
>
> Updated version attached (v2).
>

lgtm with AV1 capitalized
-- 
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".


Re: [FFmpeg-devel] [PATCH] Update the Changelog for 7.0

2024-04-03 Thread Jean-Baptiste Kempf
On Wed, 3 Apr 2024, at 23:18, Jean-Baptiste Kempf wrote:
> As attached.

Updated version attached (v2).


-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
https://jbkempf.com/From 96f2b0ee578901ebcf00795950dd78d8e924643c Mon Sep 17 00:00:00 2001
From: Jean-Baptiste Kempf 
Date: Wed, 3 Apr 2024 23:12:54 +0200
Subject: [PATCH] Update the Changelog for 7.0

---
 Changelog | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/Changelog b/Changelog
index fcc9f7cfba..bf034e9e70 100644
--- a/Changelog
+++ b/Changelog
@@ -21,7 +21,7 @@ version 7.0:
 - qrencode filter and qrencodesrc source
 - quirc filter
 - lavu/eval: introduce randomi() function in expressions
-- VVC decoder
+- VVC decoder (experimental)
 - fsync filter
 - Raw Captions with Time (RCWT) closed caption muxer
 - ffmpeg CLI -bsf option may now be used for input as well as output
@@ -42,6 +42,15 @@ version 7.0:
 - ffplay with hwaccel decoding support (depends on vulkan renderer via libplacebo)
 - dnn filter libtorch backend
 - Android content URIs protocol
+- AOMedia Film Grain Synthesis 1 (AFGS1)
+- RISC-V optimizations for AAC, FLAC, JPEG-2000,LPC, RV4.0, SVQ, VC1, VP8 and more
+- Loongarch optimizations for HEVC decoding
+- Important AArch64 optimizations for HEVC
+- IAMF support inside MP4/ISOBMFF
+- Support for HEIF/AVIF still images and tiled still images
+- Dolby Vision profile 10 support in av1
+- Support for Ambient Viewing Environment metadata in MP4/ISOBMFF
+- HDR10 metadata passthrough when encoding with libx264, libx265 and SVT-AV1
 
 
 version 6.1:
-- 
2.43.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".


Re: [FFmpeg-devel] 7.0 release

2024-04-03 Thread Jean-Baptiste Kempf
Hello,

On Thu, 4 Apr 2024, at 00:57, Michael Niedermayer wrote:
> I will try to make the 7.0 release from the release branch in the next 48h
> (with some luck but easy possible it will get delayed)

Please consider pulling in the Changelog modifications I suggested on the 
mailing list and on IRC, since this is pretty trivial.

jbk

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
https://jbkempf.com/
___
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] Update the Changelog for 7.0

2024-04-03 Thread Anton Khirnov
Quoting Jean-Baptiste Kempf (2024-04-03 23:18:27)
> +- DV profile 10 support in av1

DV is Digital Video.

-- 
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] 7.0 Name

2024-04-03 Thread RaDSL via ffmpeg-devel


On 4/3/2024 6:42 AM, Niklas Haas wrote:

On Mon, 01 Apr 2024 19:42:29 -0400 Sean McGovern  wrote:

Hi,

On Mon, Apr 1, 2024, 18:00 Lynne  wrote:


Apr 1, 2024, 22:01 bymich...@niedermayer.cc:


Hi all

I think we didnt decide on a name for 7.0 yet

Previously suggested names:
Darwin,
De broglie,
Dijkstra,
Galois,
Gauss,
Jacobi,
Jemison
Johnson
Leavitt
Maxwell,
Mellin,
Perelman,
Poincaré,
Ramanujan,
Sagan,
Ting
Viterbi,
Voltaire,
de Sitter,

Please reply with what you prefer or add more to the list.
If we end in a tie, previously suggested names will be favoured
I will vote last so that i can resolve a tie if one occurs.


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


Not sure if I am allowed to pick, my choice is Dijkstra.

+1


-- Sean McGovern

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


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

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


[FFmpeg-devel] [PATCH 6/6] avcodec/huffyuvenc: Avoid code duplication

2024-04-03 Thread Andreas Rheinhardt
This also fixes misindentated code.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/huffyuvenc.c | 146 
 1 file changed, 43 insertions(+), 103 deletions(-)

diff --git a/libavcodec/huffyuvenc.c b/libavcodec/huffyuvenc.c
index fd6b01de81..d822793406 100644
--- a/libavcodec/huffyuvenc.c
+++ b/libavcodec/huffyuvenc.c
@@ -499,7 +499,7 @@ static int encode_422_bitstream(HYuvEncContext *s, int 
offset, int count)
 
 static int encode_plane_bitstream(HYuvEncContext *s, int width, int plane)
 {
-int i, count = width/2;
+int count = width/2;
 
 if (put_bytes_left(&s->pb, 0) < count * s->bps / 2) {
 av_log(s->avctx, AV_LOG_ERROR, "encoded frame too large\n");
@@ -546,112 +546,52 @@ static int encode_plane_bitstream(HYuvEncContext *s, int 
width, int plane)
 put_bits(&s->pb, s->len[plane][y1>>2], s->bits[plane][y1>>2]);\
 put_bits(&s->pb, 2, y1&3);
 
-if (s->bps <= 8) {
-if (s->flags & AV_CODEC_FLAG_PASS1) {
-for (i = 0; i < count; i++) {
-LOAD2;
-STAT2;
-}
-if (width&1) {
-LOADEND;
-STATEND;
-}
-}
-if (s->avctx->flags2 & AV_CODEC_FLAG2_NO_OUTPUT)
-return 0;
+#define ENCODE_PLANE(LOAD, LOADEND, WRITE, WRITEEND, STAT, STATEND)   \
+do {  \
+if (s->flags & AV_CODEC_FLAG_PASS1) { \
+for (int i = 0; i < count; i++) { \
+LOAD; \
+STAT; \
+} \
+if (width & 1) {  \
+LOADEND;  \
+STATEND;  \
+} \
+} \
+if (s->avctx->flags2 & AV_CODEC_FLAG2_NO_OUTPUT)  \
+return 0; \
+  \
+if (s->context) { \
+for (int i = 0; i < count; i++) { \
+LOAD; \
+STAT; \
+WRITE;\
+} \
+if (width & 1) {  \
+LOADEND;  \
+STATEND;  \
+WRITEEND; \
+} \
+} else {  \
+for (int i = 0; i < count; i++) { \
+LOAD; \
+WRITE;\
+} \
+if (width & 1) {  \
+LOADEND;  \
+WRITEEND; \
+} \
+} \
+} while (0)
 
-if (s->context) {
-for (i = 0; i < count; i++) {
-LOAD2;
-STAT2;
-WRITE2;
-}
-if (width&1) {
-LOADEND;
-STATEND;
-WRITEEND;
-}
-} else {
-for (i = 0; i < count; i++) {
-LOAD2;
-WRITE2;
-}
-if (width&1) {
-LOADEND;
-WRITEEND;
-}
-}
+if (s->bps <= 8) {
+ENCODE_PLANE(LOAD2, LOADEND, WRITE2, WRITEEND, STAT2, STATEND);
 } else if (s->bps <= 14) {
 int mask = s->n - 1;
-if (s->flags & AV_CODEC_FLAG_PASS1) {
-for (i = 0; i < count; i++) {
-LOAD2_14;
-STAT2;
-}
-if (width&1) {
-LOADEND_14;
-STATEND;
-}
-}
-if (s->avctx->flags2 & AV_CODEC_FLAG2_NO_OUTPUT)
-return 0;
-
-if (s->context) {
-for (i = 0; i < count; i++) {
-LOAD2_14;
-STAT2;
-WRITE2;
-}
-   

[FFmpeg-devel] [PATCH 5/6] avcodec/huffyuvenc: Avoid duplicate variables

2024-04-03 Thread Andreas Rheinhardt
Also simplify assigningfake strides.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/huffyuvenc.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/libavcodec/huffyuvenc.c b/libavcodec/huffyuvenc.c
index 152f94cefb..fd6b01de81 100644
--- a/libavcodec/huffyuvenc.c
+++ b/libavcodec/huffyuvenc.c
@@ -755,16 +755,15 @@ static inline int encode_bgra_bitstream(HYuvEncContext 
*s, int count, int planes
 }
 
 static int encode_frame(AVCodecContext *avctx, AVPacket *pkt,
-const AVFrame *pict, int *got_packet)
+const AVFrame *p, int *got_packet)
 {
 HYuvEncContext *s = avctx->priv_data;
 const int width = avctx->width;
 const int width2 = avctx->width >> 1;
 const int height = avctx->height;
-const int fake_ystride = s->interlaced ? pict->linesize[0]*2  : 
pict->linesize[0];
-const int fake_ustride = s->interlaced ? pict->linesize[1]*2  : 
pict->linesize[1];
-const int fake_vstride = s->interlaced ? pict->linesize[2]*2  : 
pict->linesize[2];
-const AVFrame * const p = pict;
+const int fake_ystride = (1 + s->interlaced) * p->linesize[0];
+const int fake_ustride = (1 + s->interlaced) * p->linesize[1];
+const int fake_vstride = (1 + s->interlaced) * p->linesize[2];
 int i, j, size = 0, ret;
 
 if ((ret = ff_alloc_packet(avctx, pkt, width * height * 3 * 4 + 
FF_INPUT_BUFFER_MIN_SIZE)) < 0)
-- 
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 4/6] avcodec/huffyuv: Return proper error code

2024-04-03 Thread Andreas Rheinhardt
Also forward said error code in the encoder.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/huffyuv.c| 3 ++-
 libavcodec/huffyuvenc.c | 6 +++---
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/libavcodec/huffyuv.c b/libavcodec/huffyuv.c
index 723ab6b92b..f22c5ebc59 100644
--- a/libavcodec/huffyuv.c
+++ b/libavcodec/huffyuv.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 
+#include "libavutil/error.h"
 #include "libavutil/log.h"
 #include "libavutil/macros.h"
 
@@ -48,7 +49,7 @@ int ff_huffyuv_generate_bits_table(uint32_t *dst, const 
uint8_t *len_table, int
 for (int i = FF_ARRAY_ELEMS(lens) - 1; i > 0; i--) {
 if ((lens[i] + codes[i]) & 1) {
 av_log(NULL, AV_LOG_ERROR, "Error generating huffman table\n");
-return -1;
+return AVERROR_INVALIDDATA;
 }
 codes[i - 1] = (lens[i] + codes[i]) >> 1;
 }
diff --git a/libavcodec/huffyuvenc.c b/libavcodec/huffyuvenc.c
index 4f709143a2..152f94cefb 100644
--- a/libavcodec/huffyuvenc.c
+++ b/libavcodec/huffyuvenc.c
@@ -232,9 +232,9 @@ static int store_huffman_tables(HYuvEncContext *s, uint8_t 
*buf)
 if ((ret = ff_huff_gen_len_table(s->len[i], s->stats[i], s->vlc_n, 0)) 
< 0)
 return ret;
 
-if (ff_huffyuv_generate_bits_table(s->bits[i], s->len[i], s->vlc_n) < 
0) {
-return -1;
-}
+ret = ff_huffyuv_generate_bits_table(s->bits[i], s->len[i], s->vlc_n);
+if (ret < 0)
+return ret;
 
 size += store_table(s, s->len[i], 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".


[FFmpeg-devel] [PATCH 3/6] avcodec/huffyuv(dec|enc): Use union for temp/temp16

2024-04-03 Thread Andreas Rheinhardt
These pointers already point to the same buffers, so using
a union is possible and avoids the overhead of syncing the
pointers (and saves some memory).

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/huffyuvdec.c | 11 +--
 libavcodec/huffyuvenc.c | 11 +--
 2 files changed, 10 insertions(+), 12 deletions(-)

diff --git a/libavcodec/huffyuvdec.c b/libavcodec/huffyuvdec.c
index e390380867..12ecfcb933 100644
--- a/libavcodec/huffyuvdec.c
+++ b/libavcodec/huffyuvdec.c
@@ -70,8 +70,10 @@ typedef struct HYuvDecContext {
 int context;
 int last_slice_end;
 
-uint8_t *temp[3];
-uint16_t *temp16[3];///< identical to temp but 16bit 
type
+union {
+uint8_t  *temp[3];
+uint16_t *temp16[3];
+};
 uint8_t len[4][MAX_VLC_N];
 uint32_t bits[4][MAX_VLC_N];
 uint32_t pix_bgr_map[1temp[i]);
-s->temp16[i] = NULL;
-}
 
 av_freep(&s->bitstream_buffer);
 
@@ -607,7 +607,6 @@ static av_cold int decode_init(AVCodecContext *avctx)
 s->temp[i] = av_malloc(4 * avctx->width + 16);
 if (!s->temp[i])
 return AVERROR(ENOMEM);
-s->temp16[i] = (uint16_t*)s->temp[i];
 }
 
 return 0;
diff --git a/libavcodec/huffyuvenc.c b/libavcodec/huffyuvenc.c
index 8329666fc0..4f709143a2 100644
--- a/libavcodec/huffyuvenc.c
+++ b/libavcodec/huffyuvenc.c
@@ -65,8 +65,10 @@ typedef struct HYuvEncContext {
 int context;
 int picture_number;
 
-uint8_t *temp[3];
-uint16_t *temp16[3];///< identical to temp but 16bit 
type
+union {
+uint8_t  *temp[3];
+uint16_t *temp16[3];
+};
 uint64_t stats[4][MAX_VLC_N];
 uint8_t len[4][MAX_VLC_N];
 uint32_t bits[4][MAX_VLC_N];
@@ -436,7 +438,6 @@ static av_cold int encode_init(AVCodecContext *avctx)
 s->temp[i] = av_malloc(4 * avctx->width + 16);
 if (!s->temp[i])
 return AVERROR(ENOMEM);
-s->temp16[i] = (uint16_t*)s->temp[i];
 }
 
 return 0;
@@ -1040,10 +1041,8 @@ static av_cold int encode_end(AVCodecContext *avctx)
 
 av_freep(&avctx->stats_out);
 
-for (int i = 0; i < 3; i++) {
+for (int i = 0; i < 3; i++)
 av_freep(&s->temp[i]);
-s->temp16[i] = NULL;
-}
 
 return 0;
 }
-- 
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 2/6] avcodec/huffyuv: Inline common alloc/free functions in their callers

2024-04-03 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/huffyuv.c| 28 ++--
 libavcodec/huffyuv.h|  2 --
 libavcodec/huffyuvdec.c | 14 +++---
 libavcodec/huffyuvenc.c | 18 --
 4 files changed, 25 insertions(+), 37 deletions(-)

diff --git a/libavcodec/huffyuv.c b/libavcodec/huffyuv.c
index aaba313bf1..723ab6b92b 100644
--- a/libavcodec/huffyuv.c
+++ b/libavcodec/huffyuv.c
@@ -28,12 +28,11 @@
  * huffyuv codec for libavcodec.
  */
 
+#include 
 #include 
 
-#include "libavutil/attributes.h"
-#include "libavutil/error.h"
 #include "libavutil/log.h"
-#include "libavutil/mem.h"
+#include "libavutil/macros.h"
 
 #include "huffyuv.h"
 
@@ -59,26 +58,3 @@ int ff_huffyuv_generate_bits_table(uint32_t *dst, const 
uint8_t *len_table, int
 }
 return 0;
 }
-
-av_cold int ff_huffyuv_alloc_temp(uint8_t *temp[3], uint16_t *temp16[3], int 
width)
-{
-int i;
-
-for (i=0; i<3; i++) {
-temp[i] = av_malloc(4 * width + 16);
-if (!temp[i])
-return AVERROR(ENOMEM);
-temp16[i] = (uint16_t*)temp[i];
-}
-return 0;
-}
-
-av_cold void ff_huffyuv_common_end(uint8_t *temp[3], uint16_t *temp16[3])
-{
-int i;
-
-for(i = 0; i < 3; i++) {
-av_freep(&temp[i]);
-temp16[i] = NULL;
-}
-}
diff --git a/libavcodec/huffyuv.h b/libavcodec/huffyuv.h
index 22a766611e..62866b7a48 100644
--- a/libavcodec/huffyuv.h
+++ b/libavcodec/huffyuv.h
@@ -55,8 +55,6 @@ typedef enum Predictor {
 MEDIAN,
 } Predictor;
 
-void ff_huffyuv_common_end(uint8_t *temp[3], uint16_t *temp16[3]);
-int  ff_huffyuv_alloc_temp(uint8_t *temp[3], uint16_t *temp16[3], int width);
 int ff_huffyuv_generate_bits_table(uint32_t *dst, const uint8_t *len_table, 
int n);
 
 #endif /* AVCODEC_HUFFYUV_H */
diff --git a/libavcodec/huffyuvdec.c b/libavcodec/huffyuvdec.c
index 29e5419d91..e390380867 100644
--- a/libavcodec/huffyuvdec.c
+++ b/libavcodec/huffyuvdec.c
@@ -323,7 +323,11 @@ static av_cold int decode_end(AVCodecContext *avctx)
 HYuvDecContext *s = avctx->priv_data;
 int i;
 
-ff_huffyuv_common_end(s->temp, s->temp16);
+for (int i = 0; i < 3; i++) {
+av_freep(&s->temp[i]);
+s->temp16[i] = NULL;
+}
+
 av_freep(&s->bitstream_buffer);
 
 for (i = 0; i < 8; i++)
@@ -599,8 +603,12 @@ static av_cold int decode_init(AVCodecContext *avctx)
 return AVERROR_INVALIDDATA;
 }
 
-if ((ret = ff_huffyuv_alloc_temp(s->temp, s->temp16, avctx->width)) < 0)
-return ret;
+for (int i = 0; i < 3; i++) {
+s->temp[i] = av_malloc(4 * avctx->width + 16);
+if (!s->temp[i])
+return AVERROR(ENOMEM);
+s->temp16[i] = (uint16_t*)s->temp[i];
+}
 
 return 0;
 }
diff --git a/libavcodec/huffyuvenc.c b/libavcodec/huffyuvenc.c
index 0222565245..8329666fc0 100644
--- a/libavcodec/huffyuvenc.c
+++ b/libavcodec/huffyuvenc.c
@@ -430,12 +430,15 @@ static av_cold int encode_init(AVCodecContext *avctx)
 s->stats[i][j]= 0;
 }
 
-ret = ff_huffyuv_alloc_temp(s->temp, s->temp16, avctx->width);
-if (ret < 0)
-return ret;
-
 s->picture_number=0;
 
+for (int i = 0; i < 3; i++) {
+s->temp[i] = av_malloc(4 * avctx->width + 16);
+if (!s->temp[i])
+return AVERROR(ENOMEM);
+s->temp16[i] = (uint16_t*)s->temp[i];
+}
+
 return 0;
 }
 static int encode_422_bitstream(HYuvEncContext *s, int offset, int count)
@@ -1035,10 +1038,13 @@ static av_cold int encode_end(AVCodecContext *avctx)
 {
 HYuvEncContext *s = avctx->priv_data;
 
-ff_huffyuv_common_end(s->temp, s->temp16);
-
 av_freep(&avctx->stats_out);
 
+for (int i = 0; i < 3; i++) {
+av_freep(&s->temp[i]);
+s->temp16[i] = NULL;
+}
+
 return 0;
 }
 
-- 
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 1/6] avcodec/huffyuvdec: Don't zero unnecessarily

2024-04-03 Thread Andreas Rheinhardt
A decoder's private data has already been zeroed (apart from options)
before init is called.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/huffyuvdec.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/libavcodec/huffyuvdec.c b/libavcodec/huffyuvdec.c
index 3bed27be21..29e5419d91 100644
--- a/libavcodec/huffyuvdec.c
+++ b/libavcodec/huffyuvdec.c
@@ -346,7 +346,6 @@ static av_cold int decode_init(AVCodecContext *avctx)
 ff_bswapdsp_init(&s->bdsp);
 ff_huffyuvdsp_init(&s->hdsp, avctx->pix_fmt);
 ff_llviddsp_init(&s->llviddsp);
-memset(s->vlc, 0, 4 * sizeof(VLC));
 
 s->interlaced = avctx->height > 288;
 s->bgr32  = 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".


Re: [FFmpeg-devel] [PATCH 2/2] swscale/ppc/swscale_ppc_template: Reindent after the previous commit

2024-04-03 Thread Lynne
Apr 4, 2024, 04:58 by andreas.rheinha...@outlook.com:

> Signed-off-by: Andreas Rheinhardt 
> ---
>  libswscale/ppc/swscale_ppc_template.c | 107 +-
>  1 file changed, 53 insertions(+), 54 deletions(-)
>
> diff --git a/libswscale/ppc/swscale_ppc_template.c 
> b/libswscale/ppc/swscale_ppc_template.c
> index e9abd33cbf..3c2addd4a4 100644
> --- a/libswscale/ppc/swscale_ppc_template.c
> +++ b/libswscale/ppc/swscale_ppc_template.c
> @@ -101,70 +101,69 @@ static void FUNC(hScale_real)(SwsContext *c, int16_t 
> *dst, int dstW,
>  const uint8_t *src, const int16_t *filter,
>  const int32_t *filterPos, int filterSize)
>  {
> -register int i;
>  LOCAL_ALIGNED(16, int, tempo, [4]);
>  
> -switch (filterSize) {
> -case 4:
> -for (i = 0; i < dstW; i++) {
> -register int srcPos = filterPos[i];
> -
> -vector unsigned char src_vF = unaligned_load(srcPos, src);
> -vector signed short src_v, filter_v;
> -vector signed int val_vEven, val_s;
> -src_v = // vec_unpackh sign-extends...
> -(vector signed short)(VEC_MERGEH((vector unsigned 
> char)vzero, src_vF));
> -// now put our elements in the even slots
> -src_v = vec_mergeh(src_v, (vector signed short)vzero);
> -GET_VF4(i, filter_v, filter);
> -val_vEven = vec_mule(src_v, filter_v);
> -val_s = vec_sums(val_vEven, vzero);
> -vec_st(val_s, 0, tempo);
> -dst[i] = FFMIN(tempo[3] >> 7, (1 << 15) - 1);
> -}
> +switch (filterSize) {
> +case 4:
> +for (register int i = 0; i < dstW; i++) {
> +register int srcPos = filterPos[i];
> +
> +vector unsigned char src_vF = unaligned_load(srcPos, src);
> +vector signed short src_v, filter_v;
> +vector signed int val_vEven, val_s;
> +src_v = // vec_unpackh sign-extends...
> +(vector signed short)(VEC_MERGEH((vector unsigned 
> char)vzero, src_vF));
> +// now put our elements in the even slots
> +src_v = vec_mergeh(src_v, (vector signed short)vzero);
> +GET_VF4(i, filter_v, filter);
> +val_vEven = vec_mule(src_v, filter_v);
> +val_s = vec_sums(val_vEven, vzero);
> +vec_st(val_s, 0, tempo);
> +dst[i] = FFMIN(tempo[3] >> 7, (1 << 15) - 1);
> +}
>  break;
> -case 8:
> -for (i = 0; i < dstW; i++) {
> -register int srcPos = filterPos[i];
> -vector unsigned char src_vF, av_unused src_v0, av_unused 
> src_v1;
> -vector unsigned char av_unused permS;
> -vector signed short src_v, filter_v;
> -vector signed int val_v, val_s;
> -FIRST_LOAD(src_v0, srcPos, src, permS);
> -LOAD_SRCV8(srcPos, 0, src, permS, src_v0, src_v1, src_vF);
> -src_v = // vec_unpackh sign-extends...
> -(vector signed short)(VEC_MERGEH((vector unsigned 
> char)vzero, src_vF));
> -filter_v = vec_ld(i << 4, filter);
> -val_v = vec_msums(src_v, filter_v, (vector signed int)vzero);
> -val_s = vec_sums(val_v, vzero);
> -vec_st(val_s, 0, tempo);
> -dst[i] = FFMIN(tempo[3] >> 7, (1 << 15) - 1);
> -}
> +case 8:
> +for (register int i = 0; i < dstW; i++) {
> +register int srcPos = filterPos[i];
> +vector unsigned char src_vF, av_unused src_v0, av_unused src_v1;
> +vector unsigned char av_unused permS;
> +vector signed short src_v, filter_v;
> +vector signed int val_v, val_s;
> +FIRST_LOAD(src_v0, srcPos, src, permS);
> +LOAD_SRCV8(srcPos, 0, src, permS, src_v0, src_v1, src_vF);
> +src_v = // vec_unpackh sign-extends...
> +(vector signed short)(VEC_MERGEH((vector unsigned 
> char)vzero, src_vF));
> +filter_v = vec_ld(i << 4, filter);
> +val_v = vec_msums(src_v, filter_v, (vector signed int)vzero);
> +val_s = vec_sums(val_v, vzero);
> +vec_st(val_s, 0, tempo);
> +dst[i] = FFMIN(tempo[3] >> 7, (1 << 15) - 1);
> +}
>  break;
>  
> -case 16:
> -for (i = 0; i < dstW; i++) {
> -register int srcPos = filterPos[i];
> +case 16:
> +for (register int i = 0; i < dstW; i++) {
> +register int srcPos = filterPos[i];
>  
> -vector unsigned char src_vF = unaligned_load(srcPos, src);
> -vector signed short src_vA = // vec_unpackh sign-extends...
> - (vector signed 
> short)(VEC_MERGEH((vector unsigned char)vzero, src_vF));
> -vector signed sho

Re: [FFmpeg-devel] [PATCH] avcodec/vvc/vvc_inter_template: Fix left shift of negative number

2024-04-03 Thread Nuo Mi
On Thu, Apr 4, 2024 at 10:00 AM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:

> Affected the vvc-conformance-WP_A_3 FATE test.
>
> Applied.
Thank you, Andreas.
___
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 00/16] avcodec/vvcdec: support subpicture

2024-04-03 Thread James Almer

On 4/4/2024 12:12 AM, Nuo Mi wrote:

On Thu, Apr 4, 2024 at 10:09 AM James Almer  wrote:


On 4/3/2024 11:05 PM, Nuo Mi wrote:

On Tue, Apr 2, 2024 at 11:24 PM James Almer  wrote:


On 4/2/2024 10:01 AM, Nuo Mi wrote:

On Wed, Mar 27, 2024 at 9:01 PM Nuo Mi  wrote:


Changes since v1:
add v2-0004-avcodec-vvcdec-fix-uninitialized-last-element-of-.patch to
address
the clang-usan and clang-asan failures reported by Frank



pushed.


I added a test for this using SUBPIC_C_ERICSSON_1.bit
Also, i disabled the tests for OPI_B_3.bit and VPS_A_3.bit as they rely
on a non-implemented feature. And while they still output a frame or two
as is, it's not the case on all systems.


Thank you.



There's not a lot of VVC bitstreams currently in the FATE suite, so if
you know of any that will increase the coverage (See for example



http://coverage.ffmpeg.org/index.vvc_intra.c.5d0b519a39871515a1754ee8847b6d69.html#l678
,


where vvc_predict_ibc() is never run), then please make a test for it
and I'll upload the sample.


Sure. Tracked with https://github.com/ffvvc/FFmpeg/issues/206


FWIW i added a test to cover vvc_predict_ibc() and other functions in
vvc_intra.c, using IBC_B_Tencent_2.bit


Thank  you,
We'll establish the gcov environments on GitHub and incorporate additional
clips from the conformance test into FATE
Achieving 100% coverage might be challenging, but we can aim for 95% and
cover all important branches at the very least.


I don't think 100% is possible because of the error paths. Also, once 
hwaccel is introduced eventually, that will also remain uncovered. But 
yes, 95% or so should be doable.

___
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 00/16] avcodec/vvcdec: support subpicture

2024-04-03 Thread Nuo Mi
On Thu, Apr 4, 2024 at 10:09 AM James Almer  wrote:

> On 4/3/2024 11:05 PM, Nuo Mi wrote:
> > On Tue, Apr 2, 2024 at 11:24 PM James Almer  wrote:
> >
> >> On 4/2/2024 10:01 AM, Nuo Mi wrote:
> >>> On Wed, Mar 27, 2024 at 9:01 PM Nuo Mi  wrote:
> >>>
>  Changes since v1:
>  add v2-0004-avcodec-vvcdec-fix-uninitialized-last-element-of-.patch to
>  address
>  the clang-usan and clang-asan failures reported by Frank
> >>>
> >>>
> >>> pushed.
> >>
> >> I added a test for this using SUBPIC_C_ERICSSON_1.bit
> >> Also, i disabled the tests for OPI_B_3.bit and VPS_A_3.bit as they rely
> >> on a non-implemented feature. And while they still output a frame or two
> >> as is, it's not the case on all systems.
> >>
> > Thank you.
> >
> >>
> >> There's not a lot of VVC bitstreams currently in the FATE suite, so if
> >> you know of any that will increase the coverage (See for example
> >>
> >>
> http://coverage.ffmpeg.org/index.vvc_intra.c.5d0b519a39871515a1754ee8847b6d69.html#l678
> ,
> >>
> >> where vvc_predict_ibc() is never run), then please make a test for it
> >> and I'll upload the sample.
> >>
> > Sure. Tracked with https://github.com/ffvvc/FFmpeg/issues/206
>
> FWIW i added a test to cover vvc_predict_ibc() and other functions in
> vvc_intra.c, using IBC_B_Tencent_2.bit
>
Thank  you,
We'll establish the gcov environments on GitHub and incorporate additional
clips from the conformance test into FATE
Achieving 100% coverage might be challenging, but we can aim for 95% and
cover all important branches at the very least.

___

> 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 v2 2/2] avcodec/vvc: Rename vvc_?foo->foo

2024-04-03 Thread Nuo Mi
>
>
>
> rename to libavcodec/vvc/dec.h
> index aa3d715524..4dacefc06a 100644
> --- a/libavcodec/vvc/vvcdec.h
> +++ b/libavcodec/vvc/dec.h
> @@ -21,14 +21,14 @@
>   * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301 USA
>   */
>
> -#ifndef AVCODEC_VVC_VVCDEC_H
> -#define AVCODEC_VVC_VVCDEC_H
> +#ifndef AVCODEC_VVC_DEC_H
> +#define AVCODEC_VVC_DEC_H
>
👍, pretty neat
___
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] swscale/ppc/swscale_ppc_template: Reindent after the previous commit

2024-04-03 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 libswscale/ppc/swscale_ppc_template.c | 107 +-
 1 file changed, 53 insertions(+), 54 deletions(-)

diff --git a/libswscale/ppc/swscale_ppc_template.c 
b/libswscale/ppc/swscale_ppc_template.c
index e9abd33cbf..3c2addd4a4 100644
--- a/libswscale/ppc/swscale_ppc_template.c
+++ b/libswscale/ppc/swscale_ppc_template.c
@@ -101,70 +101,69 @@ static void FUNC(hScale_real)(SwsContext *c, int16_t 
*dst, int dstW,
 const uint8_t *src, const int16_t *filter,
 const int32_t *filterPos, int filterSize)
 {
-register int i;
 LOCAL_ALIGNED(16, int, tempo, [4]);
 
-switch (filterSize) {
-case 4:
-for (i = 0; i < dstW; i++) {
-register int srcPos = filterPos[i];
-
-vector unsigned char src_vF = unaligned_load(srcPos, src);
-vector signed short src_v, filter_v;
-vector signed int val_vEven, val_s;
-src_v = // vec_unpackh sign-extends...
-(vector signed short)(VEC_MERGEH((vector unsigned 
char)vzero, src_vF));
-// now put our elements in the even slots
-src_v = vec_mergeh(src_v, (vector signed short)vzero);
-GET_VF4(i, filter_v, filter);
-val_vEven = vec_mule(src_v, filter_v);
-val_s = vec_sums(val_vEven, vzero);
-vec_st(val_s, 0, tempo);
-dst[i] = FFMIN(tempo[3] >> 7, (1 << 15) - 1);
-}
+switch (filterSize) {
+case 4:
+for (register int i = 0; i < dstW; i++) {
+register int srcPos = filterPos[i];
+
+vector unsigned char src_vF = unaligned_load(srcPos, src);
+vector signed short src_v, filter_v;
+vector signed int val_vEven, val_s;
+src_v = // vec_unpackh sign-extends...
+(vector signed short)(VEC_MERGEH((vector unsigned 
char)vzero, src_vF));
+// now put our elements in the even slots
+src_v = vec_mergeh(src_v, (vector signed short)vzero);
+GET_VF4(i, filter_v, filter);
+val_vEven = vec_mule(src_v, filter_v);
+val_s = vec_sums(val_vEven, vzero);
+vec_st(val_s, 0, tempo);
+dst[i] = FFMIN(tempo[3] >> 7, (1 << 15) - 1);
+}
 break;
-case 8:
-for (i = 0; i < dstW; i++) {
-register int srcPos = filterPos[i];
-vector unsigned char src_vF, av_unused src_v0, av_unused 
src_v1;
-vector unsigned char av_unused permS;
-vector signed short src_v, filter_v;
-vector signed int val_v, val_s;
-FIRST_LOAD(src_v0, srcPos, src, permS);
-LOAD_SRCV8(srcPos, 0, src, permS, src_v0, src_v1, src_vF);
-src_v = // vec_unpackh sign-extends...
-(vector signed short)(VEC_MERGEH((vector unsigned 
char)vzero, src_vF));
-filter_v = vec_ld(i << 4, filter);
-val_v = vec_msums(src_v, filter_v, (vector signed int)vzero);
-val_s = vec_sums(val_v, vzero);
-vec_st(val_s, 0, tempo);
-dst[i] = FFMIN(tempo[3] >> 7, (1 << 15) - 1);
-}
+case 8:
+for (register int i = 0; i < dstW; i++) {
+register int srcPos = filterPos[i];
+vector unsigned char src_vF, av_unused src_v0, av_unused src_v1;
+vector unsigned char av_unused permS;
+vector signed short src_v, filter_v;
+vector signed int val_v, val_s;
+FIRST_LOAD(src_v0, srcPos, src, permS);
+LOAD_SRCV8(srcPos, 0, src, permS, src_v0, src_v1, src_vF);
+src_v = // vec_unpackh sign-extends...
+(vector signed short)(VEC_MERGEH((vector unsigned 
char)vzero, src_vF));
+filter_v = vec_ld(i << 4, filter);
+val_v = vec_msums(src_v, filter_v, (vector signed int)vzero);
+val_s = vec_sums(val_v, vzero);
+vec_st(val_s, 0, tempo);
+dst[i] = FFMIN(tempo[3] >> 7, (1 << 15) - 1);
+}
 break;
 
-case 16:
-for (i = 0; i < dstW; i++) {
-register int srcPos = filterPos[i];
+case 16:
+for (register int i = 0; i < dstW; i++) {
+register int srcPos = filterPos[i];
 
-vector unsigned char src_vF = unaligned_load(srcPos, src);
-vector signed short src_vA = // vec_unpackh sign-extends...
- (vector signed 
short)(VEC_MERGEH((vector unsigned char)vzero, src_vF));
-vector signed short src_vB = // vec_unpackh sign-extends...
- (vector signed 
short)(VEC_MERGEL((vector unsigned char)vzero, src_vF));
-vector 

[FFmpeg-devel] [PATCH 1/2] swscale/ppc/swscale_ppc_template: Remove code not passing checkasm

2024-04-03 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 libswscale/ppc/swscale_ppc_template.c | 62 ---
 1 file changed, 9 insertions(+), 53 deletions(-)

diff --git a/libswscale/ppc/swscale_ppc_template.c 
b/libswscale/ppc/swscale_ppc_template.c
index 84641f3a8b..e9abd33cbf 100644
--- a/libswscale/ppc/swscale_ppc_template.c
+++ b/libswscale/ppc/swscale_ppc_template.c
@@ -104,16 +104,6 @@ static void FUNC(hScale_real)(SwsContext *c, int16_t *dst, 
int dstW,
 register int i;
 LOCAL_ALIGNED(16, int, tempo, [4]);
 
-if (filterSize % 4) {
-for (i = 0; i < dstW; i++) {
-register int j;
-register int srcPos = filterPos[i];
-register int val= 0;
-for (j = 0; j < filterSize; j++)
-val += ((int)src[srcPos + j]) * filter[filterSize * i + j];
-dst[i] = FFMIN(val >> 7, (1 << 15) - 1);
-}
-} else
 switch (filterSize) {
 case 4:
 for (i = 0; i < dstW; i++) {
@@ -175,48 +165,14 @@ static void FUNC(hScale_real)(SwsContext *c, int16_t 
*dst, int dstW,
 break;
 
 default:
-for (i = 0; i < dstW; i++) {
-register int j, av_unused offset = i * 2 * filterSize;
-register int srcPos = filterPos[i];
-
-vector signed int val_s, val_v = (vector signed int)vzero;
-vector signed short av_unused filter_v0R;
-vector unsigned char av_unused permF, av_unused src_v0, 
av_unused permS;
-FIRST_LOAD(filter_v0R, offset, filter, permF);
-FIRST_LOAD(src_v0, srcPos, src, permS);
-
-for (j = 0; j < filterSize - 15; j += 16) {
-vector unsigned char av_unused src_v1, src_vF;
-vector signed short av_unused filter_v1R, av_unused 
filter_v2R,
-filter_v0, filter_v1, src_vA, src_vB;
-vector signed int val_acc;
-LOAD_SRCV(srcPos, j, src, permS, src_v0, src_v1, src_vF);
-src_vA = // vec_unpackh sign-extends...
- (vector signed 
short)(VEC_MERGEH((vector unsigned char)vzero, src_vF));
-src_vB = // vec_unpackh sign-extends...
- (vector signed 
short)(VEC_MERGEL((vector unsigned char)vzero, src_vF));
-GET_VFD(i, j, filter, filter_v0R, filter_v1R, permF, 
filter_v0, 0);
-GET_VFD(i, j, filter, filter_v1R, filter_v2R, permF, 
filter_v1, 16);
-
-val_acc = vec_msums(src_vA, filter_v0, val_v);
-val_v = vec_msums(src_vB, filter_v1, val_acc);
-UPDATE_PTR(filter_v2R, filter_v0R, src_v1, src_v0);
-}
-
-if (j < filterSize - 7) {
-// loading src_v0 is useless, it's already done above
-vector unsigned char av_unused src_v1, src_vF;
-vector signed short src_v, av_unused filter_v1R, filter_v;
-LOAD_SRCV8(srcPos, j, src, permS, src_v0, src_v1, src_vF);
-src_v = // vec_unpackh sign-extends...
-(vector signed short)(VEC_MERGEH((vector unsigned 
char)vzero, src_vF));
-GET_VFD(i, j, filter, filter_v0R, filter_v1R, permF, 
filter_v, 0);
-val_v = vec_msums(src_v, filter_v, val_v);
-}
-val_s = vec_sums(val_v, vzero);
-
-VEC_ST(val_s, 0, tempo);
-dst[i] = FFMIN(tempo[3] >> 7, (1 << 15) - 1);
-}
+for (register int i = 0; i < dstW; i++) {
+register int j;
+register int srcPos = filterPos[i];
+register int val= 0;
+for (j = 0; j < filterSize; j++)
+val += ((int)src[srcPos + j]) * filter[filterSize * i + j];
+dst[i] = FFMIN(val >> 7, (1 << 15) - 1);
+}
+break;
 }
 }
-- 
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 v2 2/2] avcodec/vvc: Rename vvc_?foo->foo

2024-04-03 Thread Andreas Rheinhardt
A namespace is unnecessary here given that all these files
are already in the vvc subfolder.

Signed-off-by: Andreas Rheinhardt 
---
Now also fixing the header inclusion guards.

 libavcodec/vvc/Makefile   | 28 +--
 libavcodec/vvc/{vvc_cabac.c => cabac.c}   |  6 ++--
 libavcodec/vvc/{vvc_cabac.h => cabac.h}   |  8 +++---
 libavcodec/vvc/{vvc_ctu.c => ctu.c}   |  8 +++---
 libavcodec/vvc/{vvc_ctu.h => ctu.h}   |  8 +++---
 libavcodec/vvc/{vvc_data.c => data.c} |  2 +-
 libavcodec/vvc/{vvc_data.h => data.h} |  6 ++--
 libavcodec/vvc/{vvcdec.c => dec.c}| 10 +++
 libavcodec/vvc/{vvcdec.h => dec.h}| 10 +++
 libavcodec/vvc/{vvcdsp.c => dsp.c}| 12 
 libavcodec/vvc/{vvcdsp.h => dsp.h}|  6 ++--
 .../vvc/{vvcdsp_template.c => dsp_template.c} | 10 +++
 libavcodec/vvc/{vvc_filter.c => filter.c} |  8 +++---
 libavcodec/vvc/{vvc_filter.h => filter.h} |  8 +++---
 ...vc_filter_template.c => filter_template.c} |  0
 libavcodec/vvc/{vvc_inter.c => inter.c}   |  8 +++---
 libavcodec/vvc/{vvc_inter.h => inter.h}   |  8 +++---
 ...{vvc_inter_template.c => inter_template.c} |  0
 libavcodec/vvc/{vvc_intra.c => intra.c}   |  8 +++---
 libavcodec/vvc/{vvc_intra.h => intra.h}   |  8 +++---
 ...{vvc_intra_template.c => intra_template.c} |  2 +-
 .../vvc/{vvc_intra_utils.c => intra_utils.c}  |  8 +++---
 libavcodec/vvc/{vvc_itx_1d.c => itx_1d.c} |  4 +--
 libavcodec/vvc/{vvc_itx_1d.h => itx_1d.h} |  6 ++--
 libavcodec/vvc/{vvc_mvs.c => mvs.c}   |  8 +++---
 libavcodec/vvc/{vvc_mvs.h => mvs.h}   |  8 +++---
 libavcodec/vvc/{vvc_ps.c => ps.c} |  6 ++--
 libavcodec/vvc/{vvc_ps.h => ps.h} |  6 ++--
 libavcodec/vvc/{vvc_refs.c => refs.c} |  2 +-
 libavcodec/vvc/{vvc_refs.h => refs.h} |  8 +++---
 libavcodec/vvc/{vvc_thread.c => thread.c} | 12 
 libavcodec/vvc/{vvc_thread.h => thread.h} |  8 +++---
 libavcodec/x86/vvc/vvcdsp_init.c  |  7 ++---
 tests/checkasm/vvc_mc.c   |  6 ++--
 34 files changed, 126 insertions(+), 127 deletions(-)
 rename libavcodec/vvc/{vvc_cabac.c => cabac.c} (99%)
 rename libavcodec/vvc/{vvc_cabac.h => cabac.h} (98%)
 rename libavcodec/vvc/{vvc_ctu.c => ctu.c} (99%)
 rename libavcodec/vvc/{vvc_ctu.h => ctu.h} (99%)
 rename libavcodec/vvc/{vvc_data.c => data.c} (99%)
 rename libavcodec/vvc/{vvc_data.h => data.h} (97%)
 rename libavcodec/vvc/{vvcdec.c => dec.c} (99%)
 rename libavcodec/vvc/{vvcdec.h => dec.h} (98%)
 rename libavcodec/vvc/{vvcdsp.c => dsp.c} (96%)
 rename libavcodec/vvc/{vvcdsp.h => dsp.h} (98%)
 rename libavcodec/vvc/{vvcdsp_template.c => dsp_template.c} (96%)
 rename libavcodec/vvc/{vvc_filter.c => filter.c} (99%)
 rename libavcodec/vvc/{vvc_filter.h => filter.h} (94%)
 rename libavcodec/vvc/{vvc_filter_template.c => filter_template.c} (100%)
 rename libavcodec/vvc/{vvc_inter.c => inter.c} (99%)
 rename libavcodec/vvc/{vvc_inter.h => inter.h} (90%)
 rename libavcodec/vvc/{vvc_inter_template.c => inter_template.c} (100%)
 rename libavcodec/vvc/{vvc_intra.c => intra.c} (99%)
 rename libavcodec/vvc/{vvc_intra.h => intra.h} (93%)
 rename libavcodec/vvc/{vvc_intra_template.c => intra_template.c} (99%)
 rename libavcodec/vvc/{vvc_intra_utils.c => intra_utils.c} (98%)
 rename libavcodec/vvc/{vvc_itx_1d.c => itx_1d.c} (99%)
 rename libavcodec/vvc/{vvc_itx_1d.h => itx_1d.h} (94%)
 rename libavcodec/vvc/{vvc_mvs.c => mvs.c} (99%)
 rename libavcodec/vvc/{vvc_mvs.h => mvs.h} (95%)
 rename libavcodec/vvc/{vvc_ps.c => ps.c} (99%)
 rename libavcodec/vvc/{vvc_ps.h => ps.h} (99%)
 rename libavcodec/vvc/{vvc_refs.c => refs.c} (99%)
 rename libavcodec/vvc/{vvc_refs.h => refs.h} (94%)
 rename libavcodec/vvc/{vvc_thread.c => thread.c} (99%)
 rename libavcodec/vvc/{vvc_thread.h => thread.h} (90%)

diff --git a/libavcodec/vvc/Makefile b/libavcodec/vvc/Makefile
index 2a0055d494..6a28d32bc2 100644
--- a/libavcodec/vvc/Makefile
+++ b/libavcodec/vvc/Makefile
@@ -1,17 +1,17 @@
 clean::
$(RM) $(CLEANSUFFIXES:%=libavcodec/vvc/%)
 
-OBJS-$(CONFIG_VVC_DECODER)  +=  vvc/vvcdec.o\
-vvc/vvcdsp.o\
-vvc/vvc_cabac.o \
-vvc/vvc_ctu.o   \
-vvc/vvc_data.o  \
-vvc/vvc_filter.o\
-vvc/vvc_inter.o \
-vvc/vvc_intra.o \
-vvc/vvc_intra_utils.o   \
-vvc/vvc_itx_1d.o\
-vvc/vvc_mvs.o   \
-vvc/vvc_ps.o\
-  

[FFmpeg-devel] [PATCH 2/2] avcodec/vvc: Rename vvc_?foo->foo

2024-04-03 Thread Andreas Rheinhardt
A namespace is unnecessary here given that all these files
are already in the vvc subfolder.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/vvc/Makefile   | 28 +--
 libavcodec/vvc/{vvc_cabac.c => cabac.c}   |  6 ++--
 libavcodec/vvc/{vvc_cabac.h => cabac.h}   |  2 +-
 libavcodec/vvc/{vvc_ctu.c => ctu.c}   |  8 +++---
 libavcodec/vvc/{vvc_ctu.h => ctu.h}   |  2 +-
 libavcodec/vvc/{vvc_data.c => data.c} |  2 +-
 libavcodec/vvc/{vvc_data.h => data.h} |  0
 libavcodec/vvc/{vvcdec.c => dec.c}| 10 +++
 libavcodec/vvc/{vvcdec.h => dec.h}|  4 +--
 libavcodec/vvc/{vvcdsp.c => dsp.c}| 12 
 libavcodec/vvc/{vvcdsp.h => dsp.h}|  0
 .../vvc/{vvcdsp_template.c => dsp_template.c} | 10 +++
 libavcodec/vvc/{vvc_filter.c => filter.c} |  8 +++---
 libavcodec/vvc/{vvc_filter.h => filter.h} |  2 +-
 ...vc_filter_template.c => filter_template.c} |  0
 libavcodec/vvc/{vvc_inter.c => inter.c}   |  8 +++---
 libavcodec/vvc/{vvc_inter.h => inter.h}   |  2 +-
 ...{vvc_inter_template.c => inter_template.c} |  0
 libavcodec/vvc/{vvc_intra.c => intra.c}   |  8 +++---
 libavcodec/vvc/{vvc_intra.h => intra.h}   |  2 +-
 ...{vvc_intra_template.c => intra_template.c} |  2 +-
 .../vvc/{vvc_intra_utils.c => intra_utils.c}  |  8 +++---
 libavcodec/vvc/{vvc_itx_1d.c => itx_1d.c} |  4 +--
 libavcodec/vvc/{vvc_itx_1d.h => itx_1d.h} |  0
 libavcodec/vvc/{vvc_mvs.c => mvs.c}   |  8 +++---
 libavcodec/vvc/{vvc_mvs.h => mvs.h}   |  2 +-
 libavcodec/vvc/{vvc_ps.c => ps.c} |  6 ++--
 libavcodec/vvc/{vvc_ps.h => ps.h} |  0
 libavcodec/vvc/{vvc_refs.c => refs.c} |  2 +-
 libavcodec/vvc/{vvc_refs.h => refs.h} |  2 +-
 libavcodec/vvc/{vvc_thread.c => thread.c} | 12 
 libavcodec/vvc/{vvc_thread.h => thread.h} |  2 +-
 libavcodec/x86/vvc/vvcdsp_init.c  |  7 ++---
 tests/checkasm/vvc_mc.c   |  6 ++--
 34 files changed, 87 insertions(+), 88 deletions(-)
 rename libavcodec/vvc/{vvc_cabac.c => cabac.c} (99%)
 rename libavcodec/vvc/{vvc_cabac.h => cabac.h} (99%)
 rename libavcodec/vvc/{vvc_ctu.c => ctu.c} (99%)
 rename libavcodec/vvc/{vvc_ctu.h => ctu.h} (99%)
 rename libavcodec/vvc/{vvc_data.c => data.c} (99%)
 rename libavcodec/vvc/{vvc_data.h => data.h} (100%)
 rename libavcodec/vvc/{vvcdec.c => dec.c} (99%)
 rename libavcodec/vvc/{vvcdec.h => dec.h} (99%)
 rename libavcodec/vvc/{vvcdsp.c => dsp.c} (96%)
 rename libavcodec/vvc/{vvcdsp.h => dsp.h} (100%)
 rename libavcodec/vvc/{vvcdsp_template.c => dsp_template.c} (96%)
 rename libavcodec/vvc/{vvc_filter.c => filter.c} (99%)
 rename libavcodec/vvc/{vvc_filter.h => filter.h} (99%)
 rename libavcodec/vvc/{vvc_filter_template.c => filter_template.c} (100%)
 rename libavcodec/vvc/{vvc_inter.c => inter.c} (99%)
 rename libavcodec/vvc/{vvc_inter.h => inter.h} (98%)
 rename libavcodec/vvc/{vvc_inter_template.c => inter_template.c} (100%)
 rename libavcodec/vvc/{vvc_intra.c => intra.c} (99%)
 rename libavcodec/vvc/{vvc_intra.h => intra.h} (98%)
 rename libavcodec/vvc/{vvc_intra_template.c => intra_template.c} (99%)
 rename libavcodec/vvc/{vvc_intra_utils.c => intra_utils.c} (98%)
 rename libavcodec/vvc/{vvc_itx_1d.c => itx_1d.c} (99%)
 rename libavcodec/vvc/{vvc_itx_1d.h => itx_1d.h} (100%)
 rename libavcodec/vvc/{vvc_mvs.c => mvs.c} (99%)
 rename libavcodec/vvc/{vvc_mvs.h => mvs.h} (99%)
 rename libavcodec/vvc/{vvc_ps.c => ps.c} (99%)
 rename libavcodec/vvc/{vvc_ps.h => ps.h} (100%)
 rename libavcodec/vvc/{vvc_refs.c => refs.c} (99%)
 rename libavcodec/vvc/{vvc_refs.h => refs.h} (99%)
 rename libavcodec/vvc/{vvc_thread.c => thread.c} (99%)
 rename libavcodec/vvc/{vvc_thread.h => thread.h} (98%)

diff --git a/libavcodec/vvc/Makefile b/libavcodec/vvc/Makefile
index 2a0055d494..6a28d32bc2 100644
--- a/libavcodec/vvc/Makefile
+++ b/libavcodec/vvc/Makefile
@@ -1,17 +1,17 @@
 clean::
$(RM) $(CLEANSUFFIXES:%=libavcodec/vvc/%)
 
-OBJS-$(CONFIG_VVC_DECODER)  +=  vvc/vvcdec.o\
-vvc/vvcdsp.o\
-vvc/vvc_cabac.o \
-vvc/vvc_ctu.o   \
-vvc/vvc_data.o  \
-vvc/vvc_filter.o\
-vvc/vvc_inter.o \
-vvc/vvc_intra.o \
-vvc/vvc_intra_utils.o   \
-vvc/vvc_itx_1d.o\
-vvc/vvc_mvs.o   \
-vvc/vvc_ps.o\
-vvc/vvc_refs.o  \
-vvc/vvc_thread.o   

Re: [FFmpeg-devel] [PATCH v2 00/16] avcodec/vvcdec: support subpicture

2024-04-03 Thread James Almer

On 4/3/2024 11:05 PM, Nuo Mi wrote:

On Tue, Apr 2, 2024 at 11:24 PM James Almer  wrote:


On 4/2/2024 10:01 AM, Nuo Mi wrote:

On Wed, Mar 27, 2024 at 9:01 PM Nuo Mi  wrote:


Changes since v1:
add v2-0004-avcodec-vvcdec-fix-uninitialized-last-element-of-.patch to
address
the clang-usan and clang-asan failures reported by Frank



pushed.


I added a test for this using SUBPIC_C_ERICSSON_1.bit
Also, i disabled the tests for OPI_B_3.bit and VPS_A_3.bit as they rely
on a non-implemented feature. And while they still output a frame or two
as is, it's not the case on all systems.


Thank you.



There's not a lot of VVC bitstreams currently in the FATE suite, so if
you know of any that will increase the coverage (See for example

http://coverage.ffmpeg.org/index.vvc_intra.c.5d0b519a39871515a1754ee8847b6d69.html#l678,

where vvc_predict_ibc() is never run), then please make a test for it
and I'll upload the sample.


Sure. Tracked with https://github.com/ffvvc/FFmpeg/issues/206


FWIW i added a test to cover vvc_predict_ibc() and other functions in 
vvc_intra.c, using IBC_B_Tencent_2.bit

___
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/httpauth: add SHA-256 Digest Authorization [update]

2024-04-03 Thread 정지우 | Eugene
 add SHA-256 Digest Authorization for RFC7616 using avutil/hash.h
- make_digest_auth_sha() : A1hash-> a1_hash and A2hash -> a2_hash
- combine with lint fix patch

Signed-off-by: Eugene-bitsensing 
---
 libavformat/httpauth.c | 130 ++---
 libavformat/httpauth.h |   8 +++
 2 files changed, 130 insertions(+), 8 deletions(-)

diff --git a/libavformat/httpauth.c b/libavformat/httpauth.c
index 9780928357..6069523bca 100644
--- a/libavformat/httpauth.c
+++ b/libavformat/httpauth.c
@@ -25,6 +25,7 @@
 #include "internal.h"
 #include "libavutil/random_seed.h"
 #include "libavutil/md5.h"
+#include "libavutil/hash.h"
 #include "urldecode.h"
 
 static void handle_basic_params(HTTPAuthState *state, const char *key,
@@ -143,7 +144,7 @@ static char *make_digest_auth(HTTPAuthState *state, const 
char *username,
 char cnonce[17];
 char nc[9];
 int i;
-char A1hash[33], A2hash[33], response[33];
+char a1_hash[33], a2_hash[33], response[33];
 struct AVMD5 *md5ctx;
 uint8_t hash[16];
 char *authstr;
@@ -163,14 +164,14 @@ static char *make_digest_auth(HTTPAuthState *state, const 
char *username,
 av_md5_init(md5ctx);
 update_md5_strings(md5ctx, username, ":", state->realm, ":", password, 
NULL);
 av_md5_final(md5ctx, hash);
-ff_data_to_hex(A1hash, hash, 16, 1);
+ff_data_to_hex(a1_hash, hash, 16, 1);
 
 if (!strcmp(digest->algorithm, "") || !strcmp(digest->algorithm, "MD5")) {
 } else if (!strcmp(digest->algorithm, "MD5-sess")) {
 av_md5_init(md5ctx);
-update_md5_strings(md5ctx, A1hash, ":", digest->nonce, ":", cnonce, 
NULL);
+update_md5_strings(md5ctx, a1_hash, ":", digest->nonce, ":", cnonce, 
NULL);
 av_md5_final(md5ctx, hash);
-ff_data_to_hex(A1hash, hash, 16, 1);
+ff_data_to_hex(a1_hash, hash, 16, 1);
 } else {
 /* Unsupported algorithm */
 av_free(md5ctx);
@@ -180,14 +181,14 @@ static char *make_digest_auth(HTTPAuthState *state, const 
char *username,
 av_md5_init(md5ctx);
 update_md5_strings(md5ctx, method, ":", uri, NULL);
 av_md5_final(md5ctx, hash);
-ff_data_to_hex(A2hash, hash, 16, 1);
+ff_data_to_hex(a2_hash, hash, 16, 1);
 
 av_md5_init(md5ctx);
-update_md5_strings(md5ctx, A1hash, ":", digest->nonce, NULL);
+update_md5_strings(md5ctx, a1_hash, ":", digest->nonce, NULL);
 if (!strcmp(digest->qop, "auth") || !strcmp(digest->qop, "auth-int")) {
 update_md5_strings(md5ctx, ":", nc, ":", cnonce, ":", digest->qop, 
NULL);
 }
-update_md5_strings(md5ctx, ":", A2hash, NULL);
+update_md5_strings(md5ctx, ":", a2_hash, NULL);
 av_md5_final(md5ctx, hash);
 ff_data_to_hex(response, hash, 16, 1);
 
@@ -236,6 +237,114 @@ static char *make_digest_auth(HTTPAuthState *state, const 
char *username,
 return authstr;
 }
 
+/**
+ * Generate a digest reply SHA-256, according to RFC 7616.
+ * TODO : support other RFC 7616 Algorithm 
+ */
+static char *make_digest_auth_sha(HTTPAuthState *state, const char *username,
+  const char *password, const char *uri,
+  const char *method, const char *algorithm)
+{
+DigestParams *digest = &state->digest_params;
+int len;
+uint32_t cnonce_buf[2];
+char cnonce[17];
+char nc[9];
+int i;
+char a1_hash[65], a2_hash[65], response[65];
+struct AVHashContext *hashctx;
+uint8_t hash[64];
+char *authstr;
+
+digest->nc++;
+snprintf(nc, sizeof(nc), "%08x", digest->nc);
+
+/* Generate a client nonce. */
+for (i = 0; i < 2; i++)
+cnonce_buf[i] = av_get_random_seed();
+ff_data_to_hex(cnonce, (const uint8_t *)cnonce_buf, sizeof(cnonce_buf), 1);
+
+/* Allocate a hash context based on the provided algorithm */
+int ret = av_hash_alloc(&hashctx, algorithm);
+if (ret < 0) {
+return NULL;
+}
+
+/* Initialize the hash context */
+av_hash_init(hashctx);
+
+/* Update the hash context with A1 data */
+av_hash_update(hashctx, (const uint8_t *)username, strlen(username));
+av_hash_update(hashctx, (const uint8_t *)":", 1);
+av_hash_update(hashctx, (const uint8_t *)state->realm, 
strlen(state->realm));
+av_hash_update(hashctx, (const uint8_t *)":", 1);
+av_hash_update(hashctx, (const uint8_t *)password, strlen(password));
+av_hash_final(hashctx, hash);
+ff_data_to_hex(a1_hash, hash, av_hash_get_size(hashctx), 1);
+
+/* Initialize the hash context for A2 */
+av_hash_init(hashctx);
+av_hash_update(hashctx, (const uint8_t *)method, strlen(method));
+av_hash_update(hashctx, (const uint8_t *)":", 1);
+av_hash_update(hashctx, (const uint8_t *)uri, strlen(uri));
+av_hash_final(hashctx, hash);
+ff_data_to_hex(a2_hash, hash, av_hash_get_size(hashctx), 1);
+
+/* Initialize the hash context for response */
+av_hash_init(hashctx);
+av_hash_update(hashctx, (const uint8_t *)a1_hash, s

Re: [FFmpeg-devel] [PATCH v2 00/16] avcodec/vvcdec: support subpicture

2024-04-03 Thread Nuo Mi
On Tue, Apr 2, 2024 at 11:24 PM James Almer  wrote:

> On 4/2/2024 10:01 AM, Nuo Mi wrote:
> > On Wed, Mar 27, 2024 at 9:01 PM Nuo Mi  wrote:
> >
> >> Changes since v1:
> >> add v2-0004-avcodec-vvcdec-fix-uninitialized-last-element-of-.patch to
> >> address
> >> the clang-usan and clang-asan failures reported by Frank
> >
> >
> > pushed.
>
> I added a test for this using SUBPIC_C_ERICSSON_1.bit
> Also, i disabled the tests for OPI_B_3.bit and VPS_A_3.bit as they rely
> on a non-implemented feature. And while they still output a frame or two
> as is, it's not the case on all systems.
>
Thank you.

>
> There's not a lot of VVC bitstreams currently in the FATE suite, so if
> you know of any that will increase the coverage (See for example
>
> http://coverage.ffmpeg.org/index.vvc_intra.c.5d0b519a39871515a1754ee8847b6d69.html#l678,
>
> where vvc_predict_ibc() is never run), then please make a test for it
> and I'll upload the sample.
>
Sure. Tracked with https://github.com/ffvvc/FFmpeg/issues/206

> ___
> 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/vvc/vvc_inter_template: Fix left shift of negative number

2024-04-03 Thread Andreas Rheinhardt
Affected the vvc-conformance-WP_A_3 FATE test.

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

diff --git a/libavcodec/vvc/vvc_inter_template.c 
b/libavcodec/vvc/vvc_inter_template.c
index e5cff079fb..e2fbfd4fc0 100644
--- a/libavcodec/vvc/vvc_inter_template.c
+++ b/libavcodec/vvc/vvc_inter_template.c
@@ -46,7 +46,7 @@ static void FUNC(w_avg)(uint8_t *_dst, const ptrdiff_t 
_dst_stride,
 pixel *dst  = (pixel*)_dst;
 const ptrdiff_t dst_stride  = _dst_stride / sizeof(pixel);
 const int shift = denom + FFMAX(3, 15 - BIT_DEPTH);
-const int offset= (((o0 + o1) << (BIT_DEPTH - 8)) + 1) << 
(shift - 1);
+const int offset= ((o0 + o1) * (1 << (BIT_DEPTH - 8)) + 1) * 
(1 << (shift - 1));
 
 for (int y = 0; y < height; y++) {
 for (int x = 0; x < width; x++)
-- 
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] avcodec/lossless_videoencdsp: Don't presume alignment in diff_bytes

2024-04-03 Thread Andreas Rheinhardt
The alignment of all the parameters in diff_bytes can be
anything the despite the documentation claiming otherwise.
8ecd38312210d48ec9e50d78fc223d60e71a30ed was based around
said documentation and is therefore insufficient to fix
e.g. the misaligned loads that happen in the huffyuvbgra
and huffyuvbgr24 vsynth FATE-tests.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/lossless_videoencdsp.c | 10 --
 libavcodec/lossless_videoencdsp.h |  4 ++--
 2 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/libavcodec/lossless_videoencdsp.c 
b/libavcodec/lossless_videoencdsp.c
index 8d03a5b5c6..0a3a4ec509 100644
--- a/libavcodec/lossless_videoencdsp.c
+++ b/libavcodec/lossless_videoencdsp.c
@@ -25,13 +25,11 @@
 #if HAVE_FAST_64BIT
 typedef uint64_t uint_native;
 #define READ   AV_RN64
-#define READA  AV_RN64A
-#define WRITEA AV_WN64A
+#define WRITE  AV_WN64
 #else
 typedef uint32_t uint_native;
 #define READ   AV_RN32
-#define READA  AV_RN32A
-#define WRITEA AV_WN32A
+#define WRITE  AV_WN32
 #endif
 // 0x7f7f7f7f or 0x7f7f7f7f7f7f7f7f or whatever, depending on the cpu's native 
arithmetic size
 #define pb_7f (~(uint_native)0 / 255 * 0x7f)
@@ -56,9 +54,9 @@ static void diff_bytes_c(uint8_t *dst, const uint8_t *src1, 
const uint8_t *src2,
 } else
 #endif
 for (i = 0; i <= w - (int) sizeof(uint_native); i += sizeof(uint_native)) {
-uint_native a = READA(src1 + i);
+uint_native a = READ(src1 + i);
 uint_native b = READ(src2 + i);
-WRITEA(dst + i, ((a | pb_80) - (b & pb_7f)) ^ ((a ^ b ^ pb_80) & 
pb_80));
+WRITE(dst + i, ((a | pb_80) - (b & pb_7f)) ^ ((a ^ b ^ pb_80) & 
pb_80));
 }
 for (; i < w; i++)
 dst[i + 0] = src1[i + 0] - src2[i + 0];
diff --git a/libavcodec/lossless_videoencdsp.h 
b/libavcodec/lossless_videoencdsp.h
index 07fff584af..7fd0ad32c7 100644
--- a/libavcodec/lossless_videoencdsp.h
+++ b/libavcodec/lossless_videoencdsp.h
@@ -23,8 +23,8 @@
 #include 
 
 typedef struct LLVidEncDSPContext {
-void (*diff_bytes)(uint8_t *dst /* align 16 */,
-   const uint8_t *src1 /* align 16 */,
+void (*diff_bytes)(uint8_t *dst /* align 1 */,
+   const uint8_t *src1 /* align 1 */,
const uint8_t *src2 /* align 1 */,
intptr_t w);
 /**
-- 
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] avcodec/ppc/h264dsp: Fix left shifts of negative numbers

2024-04-03 Thread Andreas Rheinhardt
PPC equivalent of c756b3fca240df75ffa28e75f2eb34834c10294d.

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

diff --git a/libavcodec/ppc/h264dsp.c b/libavcodec/ppc/h264dsp.c
index f50f2553a2..0650768d7b 100644
--- a/libavcodec/ppc/h264dsp.c
+++ b/libavcodec/ppc/h264dsp.c
@@ -663,7 +663,7 @@ void weight_h264_W_altivec(uint8_t *block, int stride, int 
height,
 DECLARE_ALIGNED(16, int32_t, temp)[4];
 LOAD_ZERO;
 
-offset <<= log2_denom;
+offset *= 1 << log2_denom;
 if(log2_denom) offset += 1<<(log2_denom-1);
 temp[0] = log2_denom;
 temp[1] = weight;
@@ -712,7 +712,7 @@ void biweight_h264_W_altivec(uint8_t *dst, uint8_t *src, 
int stride, int height,
 DECLARE_ALIGNED(16, int32_t, temp)[4];
 LOAD_ZERO;
 
-offset = ((offset + 1) | 1) << log2_denom;
+offset = ((offset + 1) | 1) * (1 << log2_denom);
 temp[0] = log2_denom+1;
 temp[1] = weights;
 temp[2] = weightd;
-- 
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] 7.0 release

2024-04-03 Thread Michael Niedermayer
Hi

I will try to make the 7.0 release from the release branch in the next 48h
(with some luck but easy possible it will get delayed)
i will not try to fix any issues marked as blocking 7.0 on trac, IIRC
ATM there is one. Given that 7.0 is behind shedule it seems better to
fix them for 7.0.1. But iam happy to wait if people want that one fixed
before.

thx

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides


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 5/5] avformat/pcm: Use 64bit in bitrate computation

2024-04-03 Thread Michael Niedermayer
Fixes: signed integer overflow: 65792 * 65312 cannot be represented in type 
'int'
Fixes: 
67819/clusterfuzz-testcase-minimized-ffmpeg_dem_WADY_fuzzer-5236100912185344

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

diff --git a/libavformat/pcm.c b/libavformat/pcm.c
index 051e86dd464..a774dbc3726 100644
--- a/libavformat/pcm.c
+++ b/libavformat/pcm.c
@@ -41,7 +41,7 @@ int ff_pcm_default_packet_size(AVCodecParameters *par)
 /* Don't trust the codecpar bitrate if we can calculate it ourselves */
 if (bits_per_sample > 0 && par->sample_rate > 0 && 
par->ch_layout.nb_channels > 0)
 if ((int64_t)par->sample_rate * par->ch_layout.nb_channels < INT64_MAX 
/ bits_per_sample)
-bitrate = bits_per_sample * par->sample_rate * 
par->ch_layout.nb_channels;
+bitrate = bits_per_sample * (int64_t)par->sample_rate * 
par->ch_layout.nb_channels;
 
 if (bitrate > 0) {
 nb_samples = av_clip64(bitrate / 8 / PCM_DEMUX_TARGET_FPS / 
par->block_align, 1, max_samples);
-- 
2.17.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 4/5] avformat/mxfdec: Check index_edit_rate

2024-04-03 Thread Michael Niedermayer
Fixes: Assertion b >=0 failed at libavutil/mathematics.c:62
Fixes: 
67811/clusterfuzz-testcase-minimized-ffmpeg_dem_MXF_fuzzer-5108429687422976

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

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 04de4c1d5e3..233d614f783 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -1264,6 +1264,9 @@ static int mxf_read_index_table_segment(void *arg, 
AVIOContext *pb, int tag, int
 case 0x3F0B:
 segment->index_edit_rate.num = avio_rb32(pb);
 segment->index_edit_rate.den = avio_rb32(pb);
+if (segment->index_edit_rate.num <= 0 ||
+segment->index_edit_rate.den <= 0)
+return AVERROR_INVALIDDATA;
 av_log(NULL, AV_LOG_TRACE, "IndexEditRate %d/%d\n", 
segment->index_edit_rate.num,
 segment->index_edit_rate.den);
 break;
-- 
2.17.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 3/5] swscale/utils: Fix xInc overflow

2024-04-03 Thread Michael Niedermayer
Fixes: signed integer overflow: 2 * 1073741824 cannot be represented in type 
'int'
Fixes: 67802/clusterfuzz-testcase-minimized-ffmpeg_SWS_fuzzer-6249515855183872

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libswscale/utils.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libswscale/utils.c b/libswscale/utils.c
index d34c8d1641e..df14eb016ce 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -593,7 +593,7 @@ static av_cold int initFilter(int16_t **outFilter, int32_t 
**filterPos,
 filter[i * filterSize + j] = coeff;
 xx++;
 }
-xDstInSrc += 2 * xInc;
+xDstInSrc += 2LL * xInc;
 }
 }
 
-- 
2.17.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 2/5] avformat/iamf_parse: Check sound_system

2024-04-03 Thread Michael Niedermayer
Fixes: index 13 out of bounds for type 'const struct IAMFSoundSystemMap [13]'
Fixes: 
67796/clusterfuzz-testcase-minimized-ffmpeg_dem_IAMF_fuzzer-4554553191104512

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

diff --git a/libavformat/iamf_parse.c b/libavformat/iamf_parse.c
index 3867adb1172..f8074c2de1c 100644
--- a/libavformat/iamf_parse.c
+++ b/libavformat/iamf_parse.c
@@ -934,6 +934,10 @@ static int mix_presentation_obu(void *s, IAMFContext *c, 
AVIOContext *pb, int le
 if (submix_layout->layout_type == 2) {
 int sound_system;
 sound_system = (byte >> 2) & 0xF;
+if (sound_system >= FF_ARRAY_ELEMS(ff_iamf_sound_system_map)) {
+ret = AVERROR_INVALIDDATA;
+goto fail;
+}
 av_channel_layout_copy(&submix_layout->sound_system, 
&ff_iamf_sound_system_map[sound_system].layout);
 }
 
-- 
2.17.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 1/5] avcodec/wavarc: fix signed integer overflow in block type 6/19

2024-04-03 Thread Michael Niedermayer
Fixes: signed integer overflow: -2088796289 + -91276551 cannot be represented 
in type 'int'
Fixes: 
67772/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WAVARC_fuzzer-6533568953122816

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/wavarc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/wavarc.c b/libavcodec/wavarc.c
index 7083494cd81..b4b26958e6f 100644
--- a/libavcodec/wavarc.c
+++ b/libavcodec/wavarc.c
@@ -647,7 +647,7 @@ static int decode_5elp(AVCodecContext *avctx,
 for (int o = 0; o < order; o++)
 sum += s->filter[ch][o] * (unsigned)samples[n + 70 - o - 
1];
 
-samples[n + 70] += ac_out[n] + (sum >> 4);
+samples[n + 70] += ac_out[n] + (unsigned)(sum >> 4);
 }
 
 for (int n = 0; n < 70; n++)
-- 
2.17.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 v2 4/4] configure: Remove libva 1.x support

2024-04-03 Thread Mark Thompson

libva 2.0 was released in 2017 and the 2.x versions are included in all
supported distributions nowadays.  Various features no longer need any
configure check after this command, including all codecs except AV1.
Note that the libva version is the API version plus one, so this is
removing support for VAAPI 0.x and requiring VAAPI 1.x.
---
Fixed some filter checks and added a note about the version numbering.

 configure | 25 ++---
 1 file changed, 6 insertions(+), 19 deletions(-)

diff --git a/configure b/configure
index 29cc8773fd..0253553caf 100755
--- a/configure
+++ b/configure
@@ -2622,7 +2622,6 @@ CONFIG_EXTRA="
 texturedsp
 texturedspenc
 tpeldsp
-vaapi_1
 vaapi_encode
 vc1dsp
 videodsp
@@ -3185,7 +3184,7 @@ hevc_dxva2_hwaccel_deps="dxva2 DXVA_PicParams_HEVC"
 hevc_dxva2_hwaccel_select="hevc_decoder"
 hevc_nvdec_hwaccel_deps="nvdec"
 hevc_nvdec_hwaccel_select="hevc_decoder"
-hevc_vaapi_hwaccel_deps="vaapi VAPictureParameterBufferHEVC"
+hevc_vaapi_hwaccel_deps="vaapi"
 hevc_vaapi_hwaccel_select="hevc_decoder"
 hevc_vdpau_hwaccel_deps="vdpau VdpPictureInfoHEVC"
 hevc_vdpau_hwaccel_select="hevc_decoder"
@@ -3257,7 +3256,7 @@ vp9_dxva2_hwaccel_deps="dxva2 DXVA_PicParams_VP9"
 vp9_dxva2_hwaccel_select="vp9_decoder"
 vp9_nvdec_hwaccel_deps="nvdec"
 vp9_nvdec_hwaccel_select="vp9_decoder"
-vp9_vaapi_hwaccel_deps="vaapi VADecPictureParameterBufferVP9_bit_depth"
+vp9_vaapi_hwaccel_deps="vaapi"
 vp9_vaapi_hwaccel_select="vp9_decoder"
 vp9_vdpau_hwaccel_deps="vdpau VdpPictureInfoVP9"
 vp9_vdpau_hwaccel_select="vp9_decoder"
@@ -3349,7 +3348,6 @@ hevc_qsv_decoder_select="hevc_mp4toannexb_bsf qsvdec"
 hevc_qsv_encoder_select="hevcparse qsvenc"
 hevc_rkmpp_decoder_deps="rkmpp"
 hevc_rkmpp_decoder_select="hevc_mp4toannexb_bsf"
-hevc_vaapi_encoder_deps="VAEncPictureParameterBufferHEVC"
 hevc_vaapi_encoder_select="atsc_a53 cbs_h265 vaapi_encode"
 hevc_v4l2m2m_decoder_deps="v4l2_m2m hevc_v4l2_m2m"
 hevc_v4l2m2m_decoder_select="hevc_mp4toannexb_bsf"
@@ -3358,7 +3356,6 @@ mjpeg_cuvid_decoder_deps="cuvid"
 mjpeg_qsv_decoder_select="qsvdec"
 mjpeg_qsv_encoder_deps="libmfx"
 mjpeg_qsv_encoder_select="qsvenc"
-mjpeg_vaapi_encoder_deps="VAEncPictureParameterBufferJPEG"
 mjpeg_vaapi_encoder_select="cbs_jpeg jpegtables vaapi_encode"
 mp3_mf_encoder_deps="mediafoundation"
 mpeg1_cuvid_decoder_deps="cuvid"
@@ -3386,7 +3383,6 @@ vp8_mediacodec_decoder_deps="mediacodec"
 vp8_mediacodec_encoder_deps="mediacodec"
 vp8_qsv_decoder_select="qsvdec"
 vp8_rkmpp_decoder_deps="rkmpp"
-vp8_vaapi_encoder_deps="VAEncPictureParameterBufferVP8"
 vp8_vaapi_encoder_select="vaapi_encode"
 vp8_v4l2m2m_decoder_deps="v4l2_m2m vp8_v4l2_m2m"
 vp8_v4l2m2m_encoder_deps="v4l2_m2m vp8_v4l2_m2m"
@@ -3395,7 +3391,6 @@ vp9_mediacodec_decoder_deps="mediacodec"
 vp9_mediacodec_encoder_deps="mediacodec"
 vp9_qsv_decoder_select="qsvdec"
 vp9_rkmpp_decoder_deps="rkmpp"
-vp9_vaapi_encoder_deps="VAEncPictureParameterBufferVP9"
 vp9_vaapi_encoder_select="vaapi_encode"
 vp9_qsv_encoder_deps="libmfx MFX_CODEC_VP9"
 vp9_qsv_encoder_select="qsvenc"
@@ -3942,9 +3937,9 @@ xfade_vulkan_filter_deps="vulkan spirv_compiler"
 yadif_cuda_filter_deps="ffnvcodec"
 yadif_cuda_filter_deps_any="cuda_nvcc cuda_llvm"
 yadif_videotoolbox_filter_deps="metal corevideo videotoolbox"
-hstack_vaapi_filter_deps="vaapi_1"
-vstack_vaapi_filter_deps="vaapi_1"
-xstack_vaapi_filter_deps="vaapi_1"
+hstack_vaapi_filter_deps="vaapi"
+vstack_vaapi_filter_deps="vaapi"
+xstack_vaapi_filter_deps="vaapi"
 hstack_qsv_filter_deps="libmfx"
 hstack_qsv_filter_select="qsvvpp"
 vstack_qsv_filter_deps="libmfx"
@@ -7238,7 +7233,7 @@ enabled libdrm &&
 check_pkg_config libdrm_getfb2 libdrm "xf86drmMode.h" drmModeGetFB2

 enabled vaapi &&
-check_pkg_config vaapi "libva >= 0.35.0" "va/va.h" vaInitialize
+check_pkg_config vaapi "libva >= 1.0.0" "va/va.h" vaInitialize

 if enabled vaapi; then
 case $target_os in
@@ -7254,18 +7249,10 @@ if enabled vaapi; then
 check_pkg_config vaapi_x11 "libva-x11" "va/va_x11.h" vaGetDisplay
 fi

-check_cpp_condition vaapi_1 "va/va.h" "VA_CHECK_VERSION(1, 0, 0)"
-
-check_type "va/va.h va/va_dec_hevc.h" "VAPictureParameterBufferHEVC"
-check_struct "va/va.h" "VADecPictureParameterBufferVP9" bit_depth
 check_struct "va/va.h" "VADecPictureParameterBufferAV1" bit_depth_idx
 check_type   "va/va.h va/va_vpp.h" 
"VAProcFilterParameterBufferHDRToneMapping"
 check_struct "va/va.h va/va_vpp.h" "VAProcPipelineCaps" rotation_flags
 check_struct "va/va.h va/va_vpp.h" "VAProcPipelineCaps" blend_flags
-check_type "va/va.h va/va_enc_hevc.h" "VAEncPictureParameterBufferHEVC"
-check_type "va/va.h va/va_enc_jpeg.h" "VAEncPictureParameterBufferJPEG"
-check_type "va/va.h va/va_enc_vp8.h"  "VAEncPictureParameterBufferVP8"
-check_type "va/va.h va/va_enc_vp9.h"  "VAEncPictureParameterBufferVP9"
 check_type "va/va.h va/va_enc_av1.h"  "VAEncPictureParameterBufferAV1"
 fi

--
2.43.0
_

[FFmpeg-devel] [PATCH v2 3/4] lavfi: Remove libva 1.x support

2024-04-03 Thread Mark Thompson

libva 2.0 was released in 2017 and the 2.x versions are included in all
supported distributions nowadays.
---
No change.

 libavfilter/vaapi_vpp.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/libavfilter/vaapi_vpp.c b/libavfilter/vaapi_vpp.c
index ace1153a23..21d74f8112 100644
--- a/libavfilter/vaapi_vpp.c
+++ b/libavfilter/vaapi_vpp.c
@@ -672,15 +672,12 @@ int ff_vaapi_vpp_render_pictures(AVFilterContext *avctx,
 goto fail_after_render;
 }

-if (CONFIG_VAAPI_1 || ctx->hwctx->driver_quirks &
-AV_VAAPI_DRIVER_QUIRK_RENDER_PARAM_BUFFERS) {
-for (int i = 0; i < cout && params_ids[i] != VA_INVALID_ID; i++) {
-vas = vaDestroyBuffer(ctx->hwctx->display, params_ids[i]);
-if (vas != VA_STATUS_SUCCESS) {
-av_log(avctx, AV_LOG_ERROR, "Failed to free parameter buffer: "
-   "%d (%s).\n", vas, vaErrorStr(vas));
-// And ignore.
-}
+for (int i = 0; i < cout && params_ids[i] != VA_INVALID_ID; i++) {
+vas = vaDestroyBuffer(ctx->hwctx->display, params_ids[i]);
+if (vas != VA_STATUS_SUCCESS) {
+av_log(avctx, AV_LOG_ERROR, "Failed to free parameter buffer: "
+   "%d (%s).\n", vas, vaErrorStr(vas));
+// And ignore.
 }
 }

--
2.43.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 v2 2/4] lavc: Remove libva 1.x support

2024-04-03 Thread Mark Thompson

libva 2.0 was released in 2017 and the 2.x versions are included in all
supported distributions nowadays.
---
Now removing lots of VA_CHECK_VERSION as well.

 libavcodec/vaapi_decode.c  | 16 +--
 libavcodec/vaapi_encode.c  | 77 ++
 libavcodec/vaapi_encode.h  |  9 
 libavcodec/vaapi_encode_h264.c | 18 
 libavcodec/vaapi_encode_h265.c |  2 -
 5 files changed, 14 insertions(+), 108 deletions(-)

diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
index 5665639dd7..1f923a414a 100644
--- a/libavcodec/vaapi_decode.c
+++ b/libavcodec/vaapi_decode.c
@@ -191,16 +191,10 @@ int ff_vaapi_decode_issue(AVCodecContext *avctx,
 av_log(avctx, AV_LOG_ERROR, "Failed to end picture decode "
"issue: %d (%s).\n", vas, vaErrorStr(vas));
 err = AVERROR(EIO);
-if (CONFIG_VAAPI_1 || ctx->hwctx->driver_quirks &
-AV_VAAPI_DRIVER_QUIRK_RENDER_PARAM_BUFFERS)
-goto fail;
-else
-goto fail_at_end;
+goto fail;
 }

-if (CONFIG_VAAPI_1 || ctx->hwctx->driver_quirks &
-AV_VAAPI_DRIVER_QUIRK_RENDER_PARAM_BUFFERS)
-ff_vaapi_decode_destroy_buffers(avctx, pic);
+ff_vaapi_decode_destroy_buffers(avctx, pic);

 err = 0;
 goto exit;
@@ -406,12 +400,10 @@ static const struct {
H264ConstrainedBaseline),
 MAP(H264,H264_MAIN,   H264Main),
 MAP(H264,H264_HIGH,   H264High),
-#if VA_CHECK_VERSION(0, 37, 0)
 MAP(HEVC,HEVC_MAIN,   HEVCMain),
 MAP(HEVC,HEVC_MAIN_10,HEVCMain10  ),
 MAP(HEVC,HEVC_MAIN_STILL_PICTURE,
   HEVCMain),
-#endif
 #if VA_CHECK_VERSION(1, 2, 0) && CONFIG_HEVC_VAAPI_HWACCEL
 MAP(HEVC,HEVC_REXT,   None,
  ff_vaapi_parse_hevc_rext_scc_profile ),
@@ -429,14 +421,10 @@ static const struct {
 MAP(VC1, VC1_COMPLEX, VC1Advanced ),
 MAP(VC1, VC1_ADVANCED,VC1Advanced ),
 MAP(VP8, UNKNOWN,   VP8Version0_3 ),
-#if VA_CHECK_VERSION(0, 38, 0)
 MAP(VP9, VP9_0,   VP9Profile0 ),
-#endif
-#if VA_CHECK_VERSION(0, 39, 0)
 MAP(VP9, VP9_1,   VP9Profile1 ),
 MAP(VP9, VP9_2,   VP9Profile2 ),
 MAP(VP9, VP9_3,   VP9Profile3 ),
-#endif
 #if VA_CHECK_VERSION(1, 8, 0)
 MAP(AV1, AV1_MAIN,AV1Profile0),
 MAP(AV1, AV1_HIGH,AV1Profile1),
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index f54b2579ec..2f02a7a2e1 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -530,7 +530,6 @@ static int vaapi_encode_issue(AVCodecContext *avctx,
 }
 }

-#if VA_CHECK_VERSION(1, 0, 0)
 sd = av_frame_get_side_data(pic->input_image,
 AV_FRAME_DATA_REGIONS_OF_INTEREST);
 if (sd && ctx->roi_allowed) {
@@ -593,7 +592,6 @@ static int vaapi_encode_issue(AVCodecContext *avctx,
 if (err < 0)
 goto fail;
 }
-#endif

 vas = vaBeginPicture(ctx->hwctx->display, ctx->va_context,
  pic->input_surface);
@@ -618,26 +616,17 @@ static int vaapi_encode_issue(AVCodecContext *avctx,
 av_log(avctx, AV_LOG_ERROR, "Failed to end picture encode issue: "
"%d (%s).\n", vas, vaErrorStr(vas));
 err = AVERROR(EIO);
-// vaRenderPicture() has been called here, so we should not destroy
-// the parameter buffers unless separate destruction is required.
-if (CONFIG_VAAPI_1 || ctx->hwctx->driver_quirks &
-AV_VAAPI_DRIVER_QUIRK_RENDER_PARAM_BUFFERS)
-goto fail;
-else
-goto fail_at_end;
-}
-
-if (CONFIG_VAAPI_1 || ctx->hwctx->driver_quirks &
-AV_VAAPI_DRIVER_QUIRK_RENDER_PARAM_BUFFERS) {
-for (i = 0; i < pic->nb_param_buffers; i++) {
-vas = vaDestroyBuffer(ctx->hwctx->display,
-  pic->param_buffers[i]);
-if (vas != VA_STATUS_SUCCESS) {
-av_log(avctx, AV_LOG_ERROR, "Failed to destroy "
-   "param buffer %#x: %d (%s).\n",
-   pic->param_buffers[i], vas, vaErrorStr(vas));
-// And ignore.
-}
+goto fail;
+}
+
+for (i = 0; i < pic->nb_param_buffers; i++) {
+vas = vaDestroyBuffer(ctx->hwctx->display,
+  pic->param_buffers[i]);
+if (vas != VA_STATUS_SUCCESS) {
+av_log(avctx, AV_LOG_ERROR, "Failed to destroy "
+   "param buffer %#x: %d (%s).\n",
+   pic->param_buffers[i], vas, vaErrorStr(vas));
+// And ignore.
 }
 }

@@ -1530,25 +1519,19 @@ static const VAAPIEncodeRTFormat 
vaapi_encode_rt_formats[] = {
 { "YUV444",VA_RT_FORMAT_YUV444,8, 3, 0,

Re: [FFmpeg-devel] [PATCH 1/7] avcodec/wavpack: Fix leak and segfault on reallocation error

2024-04-03 Thread Andreas Rheinhardt
Andreas Rheinhardt:
> av_realloc_f() frees the buffer it is given on allocation
> failure. But in this case, the buffer is an array of
> ownership pointers, causing leaks on error. Furthermore,
> the count of pointers is unchanged on error and the codec's
> close function uses it to free said ownership pointers,
> causing a NPD.
> This is a regression since 46412a8935e4632b2460988bfce4152c7dccce22.
> 
> Fix this by switching to av_realloc_array().
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
> Actually, one only needs one WavpackFrameContext at a time, given
> that this decoder does not do proper slice threading.
> Alternatively, one could implement proper slice threading.
> 
>  libavcodec/wavpack.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/wavpack.c b/libavcodec/wavpack.c
> index 7e60a1456a..36bd4662e8 100644
> --- a/libavcodec/wavpack.c
> +++ b/libavcodec/wavpack.c
> @@ -973,9 +973,11 @@ static inline int wv_unpack_mono(WavpackFrameContext *s, 
> GetBitContext *gb,
>  
>  static av_cold int wv_alloc_frame_context(WavpackContext *c)
>  {
> -c->fdec = av_realloc_f(c->fdec, c->fdec_num + 1, sizeof(*c->fdec));
> -if (!c->fdec)
> +WavpackFrameContext **fdec = av_realloc_array(c->fdec, c->fdec_num + 1, 
> sizeof(*c->fdec));
> +
> +if (!fdec)
>  return -1;
> +c->fdec = fdec;
>  
>  c->fdec[c->fdec_num] = av_mallocz(sizeof(**c->fdec));
>  if (!c->fdec[c->fdec_num])

Will apply this patchset tomorrow unless there are objections.

- Andreas

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

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


[FFmpeg-devel] [PATCH v2 1/4] lavu: Remove libva 1.x support

2024-04-03 Thread Mark Thompson

libva 2.0 was released in 2017 and the 2.x versions are included in all
supported distributions nowadays.
---
The other two quirk cases are very old and could probably be removed?  That 
could then deprecate the quirks system as well.

 libavutil/hwcontext_vaapi.c | 22 --
 1 file changed, 22 deletions(-)

diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 56d03aa4cd..84bcb78087 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -372,14 +372,6 @@ static const struct {
 const char *match_string;
 unsigned int quirks;
 } vaapi_driver_quirks_table[] = {
-#if !VA_CHECK_VERSION(1, 0, 0)
-// The i965 driver did not conform before version 2.0.
-{
-"Intel i965 (Quick Sync)",
-"i965",
-AV_VAAPI_DRIVER_QUIRK_RENDER_PARAM_BUFFERS,
-},
-#endif
 {
 "Intel iHD",
 "ubit",
@@ -1413,7 +1405,6 @@ fail:
 }
 #endif

-#if VA_CHECK_VERSION(0, 36, 0)
 typedef struct VAAPIDRMImageBufferMapping {
 VAImage  image;
 VABufferInfo buffer_info;
@@ -1573,7 +1564,6 @@ fail:
 av_freep(&mapping);
 return err;
 }
-#endif

 static int vaapi_map_to_drm(AVHWFramesContext *hwfc, AVFrame *dst,
 const AVFrame *src, int flags)
@@ -1584,10 +1574,7 @@ static int vaapi_map_to_drm(AVHWFramesContext *hwfc, 
AVFrame *dst,
 if (err != AVERROR(ENOSYS))
 return err;
 #endif
-#if VA_CHECK_VERSION(0, 36, 0)
 return vaapi_map_to_drm_abh(hwfc, dst, src, flags);
-#endif
-return AVERROR(ENOSYS);
 }

 #endif /* CONFIG_LIBDRM */
@@ -1637,7 +1624,6 @@ static void vaapi_device_free(AVHWDeviceContext *ctx)
 av_freep(&priv);
 }

-#if CONFIG_VAAPI_1
 static void vaapi_device_log_error(void *context, const char *message)
 {
 AVHWDeviceContext *ctx = context;
@@ -1651,7 +1637,6 @@ static void vaapi_device_log_info(void *context, const 
char *message)

 av_log(ctx, AV_LOG_VERBOSE, "libva: %s", message);
 }
-#endif

 static int vaapi_device_connect(AVHWDeviceContext *ctx,
 VADisplay display)
@@ -1660,10 +1645,8 @@ static int vaapi_device_connect(AVHWDeviceContext *ctx,
 int major, minor;
 VAStatus vas;

-#if CONFIG_VAAPI_1
 vaSetErrorCallback(display, &vaapi_device_log_error, ctx);
 vaSetInfoCallback (display, &vaapi_device_log_info,  ctx);
-#endif

 hwctx->display = display;

@@ -1907,7 +1890,6 @@ static int vaapi_device_create(AVHWDeviceContext *ctx, 
const char *device,

 ent = av_dict_get(opts, "driver", NULL, 0);
 if (ent) {
-#if VA_CHECK_VERSION(0, 38, 0)
 VAStatus vas;
 vas = vaSetDriverName(display, ent->value);
 if (vas != VA_STATUS_SUCCESS) {
@@ -1916,10 +1898,6 @@ static int vaapi_device_create(AVHWDeviceContext *ctx, 
const char *device,
 vaTerminate(display);
 return AVERROR_EXTERNAL;
 }
-#else
-av_log(ctx, AV_LOG_WARNING, "Driver name setting is not "
-   "supported with this VAAPI version.\n");
-#endif
 }

 return vaapi_device_connect(ctx, display);
--
2.43.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".


Re: [FFmpeg-devel] [PATCH 0/3] avcodec/h264dec: Fix dropped frames when draining

2024-04-03 Thread arch1t3cht

On 28/03/2024 02:56, arch1t3cht wrote:

Fix one or more frames being dropped when starting decoding at a SEI
recovery point that is very close to the end of the stream
(specifically, which is less than 2 * has_b_frames frames before the
end of the stream in decoding order). One case of this was reported
in ticket #10936.

Tested for regressions using FATE. If necessary I can also try to add
a test for the previously broken behavior.

There's now a bit of code duplication between
h264_select_output_frame and send_next_delayed_frame (or, rather,
there was already some code duplication and this patch
adds a bit more). But this probably cannot be avoided without a larger
refactor to, say, also call h264_select_output_frame in
send_next_delayed_frame instead of manually selecting a frame, which
I don't feel confident enough to do myself.

arch1t3cht (3):
   avcodec/h264dec: Properly mark frames as recovered when draining
   avcodec/h264dec: Handle non-recovered frames when draining
   avcodec/h264dec: Reindent after the previous commit

  libavcodec/h264dec.c | 44 ++--
  1 file changed, 26 insertions(+), 18 deletions(-)


Can I bump this? It's my first time sending a patch here so let me know
if I did something wrong.

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

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


Re: [FFmpeg-devel] [PATCH 1/4] lavu: Remove libva 1.x support

2024-04-03 Thread Michael Niedermayer
On Wed, Apr 03, 2024 at 08:44:29PM +0100, Mark Thompson wrote:
> libva 2.0 was released in 2017 and the 2.x versions are included in all
> supported distributions nowadays.

on ubuntu mingw

make
CC  libavdevice/version.o
AR  libavdevice/libavdevice.a
CC  libavfilter/vaapi_vpp.o
In file included from src/libavfilter/vaapi_vpp.c:26:0:
src/libavfilter/vaapi_vpp.h:22:10: fatal error: va/va.h: No such file or 
directory
 #include 
  ^
compilation terminated.
src/ffbuild/common.mak:81: recipe for target 'libavfilter/vaapi_vpp.o' failed
make: *** [libavfilter/vaapi_vpp.o] Error 1

thx

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

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable


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] Update the Changelog for 7.0

2024-04-03 Thread Jean-Baptiste Kempf
As attached.

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
https://jbkempf.com/From bc5a37d34d9a634388e425d894aa1219a32d8394 Mon Sep 17 00:00:00 2001
From: Jean-Baptiste Kempf 
Date: Wed, 3 Apr 2024 23:12:54 +0200
Subject: [PATCH] Update the Changelog for 7.0

---
 Changelog | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/Changelog b/Changelog
index fcc9f7cfba..499a4a37de 100644
--- a/Changelog
+++ b/Changelog
@@ -21,7 +21,7 @@ version 7.0:
 - qrencode filter and qrencodesrc source
 - quirc filter
 - lavu/eval: introduce randomi() function in expressions
-- VVC decoder
+- VVC decoder (experimental)
 - fsync filter
 - Raw Captions with Time (RCWT) closed caption muxer
 - ffmpeg CLI -bsf option may now be used for input as well as output
@@ -42,6 +42,15 @@ version 7.0:
 - ffplay with hwaccel decoding support (depends on vulkan renderer via libplacebo)
 - dnn filter libtorch backend
 - Android content URIs protocol
+- AOMedia Film Grain Synthesis 1 (AFGS1)
+- RISC-V optimizations for AAC, FLAC, JPEG-2000,LPC, RV4.0, SVQ, VC1, VP8 and more
+- Loongarch optimizations for HEVC decoding
+- More ARM optimizations for HEVC
+- IAMF support inside MP4/ISOBMFF
+- Support for HEIF/AVIF still images and tiled still images
+- DV profile 10 support in av1
+- Support for Ambient Viewing Environment metadata in MP4/ISOBMFF
+- Display metadata support in libx265, libx264 and libaom encoders
 
 
 version 6.1:
-- 
2.43.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".


Re: [FFmpeg-devel] [PATCH 1/4] lavc/vp9dsp: R-V V ipred dc

2024-04-03 Thread Rémi Denis-Courmont
Le torstaina 28. maaliskuuta 2024, 4.44.33 EEST flow gg a écrit :
> I don't quite understand, I think here 8x8 because zve64x is not suitable
> for sharing, it shares between dc16x16 and dc32x32, there isn't much common
> code, it would require adding 3 if-else statements and function parameters,
> it feels okay not to extract too.

I agree that we can't realistically share code between the different block 
sizes. My point was that the code after getdc is lengthy (after expansion) and 
fixed for a given block size, so *that* code could be shared and jumped as 
common function tail.

-- 
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/4] lavu: Remove libva 1.x support

2024-04-03 Thread Mark Thompson

On 03/04/2024 21:09, Rémi Denis-Courmont wrote:

Le keskiviikkona 3. huhtikuuta 2024, 22.44.29 EEST Mark Thompson a écrit :

libva 2.0 was released in 2017 and the 2.x versions are included in all
supported distributions nowadays.
---
   libavutil/hwcontext_vaapi.c | 4 
   1 file changed, 4 deletions(-)

diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 56d03aa4cd..bc82ab31e6 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -1637,7 +1637,6 @@ static void vaapi_device_free(AVHWDeviceContext *ctx)
   av_freep(&priv);
   }

-#if CONFIG_VAAPI_1


IMO, it wouldn't hurt to clarify in the change description that CONFIG_VAAPI_1
actually corresponded to libva 2.x. No objections to the code changes though.


Fair, the library major version being the API major version plus one is a 
slightly bizarre feature.  I've added some words to that effect locally.

Thanks,

- Mark
___
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] configure: Only enable iamfdec, iamfenc when needed

2024-04-03 Thread James Almer

On 4/3/2024 4:46 PM, Andreas Rheinhardt wrote:

Since 591e27d1e7b21b66f81c53f381356c5e6f1f0451 they would
always be compiled even when nothing uses them; for shared
builds the default linker behaviour is to include them
even when not needed.

Signed-off-by: Andreas Rheinhardt 
---
  configure | 9 +
  1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/configure b/configure
index a393f6ea65..29cc8773fd 100755
--- a/configure
+++ b/configure
@@ -3595,8 +3595,8 @@ gxf_muxer_select="pcm_rechunk_bsf"
  hds_muxer_select="flv_muxer"
  hls_demuxer_select="aac_demuxer ac3_demuxer adts_header ac3_parser eac3_demuxer 
mov_demuxer mpegts_demuxer"
  hls_muxer_select="mov_muxer mpegts_muxer"
-iamf_demuxer_deps="iamfdec"
-iamf_muxer_deps="iamfenc"
+iamf_demuxer_select="iamfdec"
+iamf_muxer_select="iamfenc"
  image2_alias_pix_demuxer_select="image2_demuxer"
  image2_brender_pix_demuxer_select="image2_demuxer"
  imf_demuxer_deps="libxml2"
@@ -3612,8 +3612,9 @@ matroska_muxer_select="mpeg4audio riffenc 
aac_adtstoasc_bsf pgs_frame_merge_bsf
  mlp_demuxer_select="mlp_parser"
  mmf_muxer_select="riffenc"
  mov_demuxer_select="iso_media riffdec"
-mov_demuxer_suggest="zlib"
+mov_demuxer_suggest="iamfdec zlib"
  mov_muxer_select="iso_media riffenc rtpenc_chain vp9_superframe_bsf 
aac_adtstoasc_bsf ac3_parser"
+mov_muxer_suggest="iamfenc"
  mp3_demuxer_select="mpegaudio_parser"
  mp3_muxer_select="mpegaudioheader"
  mp4_muxer_select="mov_muxer"
@@ -4084,7 +4085,7 @@ enable asm
  enable debug
  enable doc
  enable faan faandct faanidct
-enable iamf iamfdec iamfenc
+enable iamf
  enable large_tests
  enable optimizations
  enable ptx_compression


LGTM. 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 1/4] lavu: Remove libva 1.x support

2024-04-03 Thread Rémi Denis-Courmont
Le keskiviikkona 3. huhtikuuta 2024, 22.44.29 EEST Mark Thompson a écrit :
> libva 2.0 was released in 2017 and the 2.x versions are included in all
> supported distributions nowadays.
> ---
>   libavutil/hwcontext_vaapi.c | 4 
>   1 file changed, 4 deletions(-)
> 
> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> index 56d03aa4cd..bc82ab31e6 100644
> --- a/libavutil/hwcontext_vaapi.c
> +++ b/libavutil/hwcontext_vaapi.c
> @@ -1637,7 +1637,6 @@ static void vaapi_device_free(AVHWDeviceContext *ctx)
>   av_freep(&priv);
>   }
> 
> -#if CONFIG_VAAPI_1

IMO, it wouldn't hurt to clarify in the change description that CONFIG_VAAPI_1 
actually corresponded to libva 2.x. No objections to the code changes though.


-- 
レミ・デニ-クールモン
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] configure: Fix iamfdec dependencies

2024-04-03 Thread James Almer

On 4/3/2024 4:35 PM, Andreas Rheinhardt wrote:

Signed-off-by: Andreas Rheinhardt 
---
  configure | 1 +
  1 file changed, 1 insertion(+)

diff --git a/configure b/configure
index 71386c3920..a393f6ea65 100755
--- a/configure
+++ b/configure
@@ -2854,6 +2854,7 @@ hevcparse_select="golomb"
  hevc_sei_select="atsc_a53 golomb"
  frame_thread_encoder_deps="encoders threads"
  iamfdec_deps="iamf"
+iamfdec_select="iso_media mpeg4audio"
  iamfenc_deps="iamf"
  inflate_wrapper_deps="zlib"
  intrax8_select="blockdsp wmv2dsp"


LGTM. Please backport it too.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


Re: [FFmpeg-devel] [PATCH v4 0/4] Fix some active sequences in subtitles

2024-04-03 Thread Oneric
On Mon, 19 Feb 2024 Oneric wrote:
>   avcodec/webvttdec: honour bidi marks
>   avcodec/{ass,webvttdec}: fix handling of backslashes
>   avcodec/{ass,webvttdec}: more portable curly brace escapes
>   avocdec/ass: simplify linebreaks
>
>  libavcodec/ass.c   | 47 +++---
>  libavcodec/webvttdec.c |  4 ++--
>  tests/ref/fate/sub-webvtt  |  2 +-
>  tests/ref/fate/sub-webvtt2 |  2 +-
>  4 files changed, 33 insertions(+), 22 deletions(-)

On Tue, Mar 26, 2024 at 11:01:40 -0500, Marth64 wrote:
> Ping on this set authored by Oneric as well.

ping again


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 2/2] configure: Only enable iamfdec, iamfenc when needed

2024-04-03 Thread Andreas Rheinhardt
Since 591e27d1e7b21b66f81c53f381356c5e6f1f0451 they would
always be compiled even when nothing uses them; for shared
builds the default linker behaviour is to include them
even when not needed.

Signed-off-by: Andreas Rheinhardt 
---
 configure | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/configure b/configure
index a393f6ea65..29cc8773fd 100755
--- a/configure
+++ b/configure
@@ -3595,8 +3595,8 @@ gxf_muxer_select="pcm_rechunk_bsf"
 hds_muxer_select="flv_muxer"
 hls_demuxer_select="aac_demuxer ac3_demuxer adts_header ac3_parser 
eac3_demuxer mov_demuxer mpegts_demuxer"
 hls_muxer_select="mov_muxer mpegts_muxer"
-iamf_demuxer_deps="iamfdec"
-iamf_muxer_deps="iamfenc"
+iamf_demuxer_select="iamfdec"
+iamf_muxer_select="iamfenc"
 image2_alias_pix_demuxer_select="image2_demuxer"
 image2_brender_pix_demuxer_select="image2_demuxer"
 imf_demuxer_deps="libxml2"
@@ -3612,8 +3612,9 @@ matroska_muxer_select="mpeg4audio riffenc 
aac_adtstoasc_bsf pgs_frame_merge_bsf
 mlp_demuxer_select="mlp_parser"
 mmf_muxer_select="riffenc"
 mov_demuxer_select="iso_media riffdec"
-mov_demuxer_suggest="zlib"
+mov_demuxer_suggest="iamfdec zlib"
 mov_muxer_select="iso_media riffenc rtpenc_chain vp9_superframe_bsf 
aac_adtstoasc_bsf ac3_parser"
+mov_muxer_suggest="iamfenc"
 mp3_demuxer_select="mpegaudio_parser"
 mp3_muxer_select="mpegaudioheader"
 mp4_muxer_select="mov_muxer"
@@ -4084,7 +4085,7 @@ enable asm
 enable debug
 enable doc
 enable faan faandct faanidct
-enable iamf iamfdec iamfenc
+enable iamf
 enable large_tests
 enable optimizations
 enable ptx_compression
-- 
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 4/4] configure: Remove libva 1.x support

2024-04-03 Thread Mark Thompson

libva 2.0 was released in 2017 and the 2.x versions are included in all
supported distributions nowadays.  Various features no longer need any
configure check after this command, including all codecs except AV1.
---
 configure | 22 +++---
 1 file changed, 3 insertions(+), 19 deletions(-)

diff --git a/configure b/configure
index 71386c3920..9adada002f 100755
--- a/configure
+++ b/configure
@@ -2622,7 +2622,6 @@ CONFIG_EXTRA="
 texturedsp
 texturedspenc
 tpeldsp
-vaapi_1
 vaapi_encode
 vc1dsp
 videodsp
@@ -3184,7 +3183,7 @@ hevc_dxva2_hwaccel_deps="dxva2 DXVA_PicParams_HEVC"
 hevc_dxva2_hwaccel_select="hevc_decoder"
 hevc_nvdec_hwaccel_deps="nvdec"
 hevc_nvdec_hwaccel_select="hevc_decoder"
-hevc_vaapi_hwaccel_deps="vaapi VAPictureParameterBufferHEVC"
+hevc_vaapi_hwaccel_deps="vaapi"
 hevc_vaapi_hwaccel_select="hevc_decoder"
 hevc_vdpau_hwaccel_deps="vdpau VdpPictureInfoHEVC"
 hevc_vdpau_hwaccel_select="hevc_decoder"
@@ -3256,7 +3255,7 @@ vp9_dxva2_hwaccel_deps="dxva2 DXVA_PicParams_VP9"
 vp9_dxva2_hwaccel_select="vp9_decoder"
 vp9_nvdec_hwaccel_deps="nvdec"
 vp9_nvdec_hwaccel_select="vp9_decoder"
-vp9_vaapi_hwaccel_deps="vaapi VADecPictureParameterBufferVP9_bit_depth"
+vp9_vaapi_hwaccel_deps="vaapi"
 vp9_vaapi_hwaccel_select="vp9_decoder"
 vp9_vdpau_hwaccel_deps="vdpau VdpPictureInfoVP9"
 vp9_vdpau_hwaccel_select="vp9_decoder"
@@ -3348,7 +3347,6 @@ hevc_qsv_decoder_select="hevc_mp4toannexb_bsf qsvdec"
 hevc_qsv_encoder_select="hevcparse qsvenc"
 hevc_rkmpp_decoder_deps="rkmpp"
 hevc_rkmpp_decoder_select="hevc_mp4toannexb_bsf"
-hevc_vaapi_encoder_deps="VAEncPictureParameterBufferHEVC"
 hevc_vaapi_encoder_select="atsc_a53 cbs_h265 vaapi_encode"
 hevc_v4l2m2m_decoder_deps="v4l2_m2m hevc_v4l2_m2m"
 hevc_v4l2m2m_decoder_select="hevc_mp4toannexb_bsf"
@@ -3357,7 +3355,6 @@ mjpeg_cuvid_decoder_deps="cuvid"
 mjpeg_qsv_decoder_select="qsvdec"
 mjpeg_qsv_encoder_deps="libmfx"
 mjpeg_qsv_encoder_select="qsvenc"
-mjpeg_vaapi_encoder_deps="VAEncPictureParameterBufferJPEG"
 mjpeg_vaapi_encoder_select="cbs_jpeg jpegtables vaapi_encode"
 mp3_mf_encoder_deps="mediafoundation"
 mpeg1_cuvid_decoder_deps="cuvid"
@@ -3385,7 +3382,6 @@ vp8_mediacodec_decoder_deps="mediacodec"
 vp8_mediacodec_encoder_deps="mediacodec"
 vp8_qsv_decoder_select="qsvdec"
 vp8_rkmpp_decoder_deps="rkmpp"
-vp8_vaapi_encoder_deps="VAEncPictureParameterBufferVP8"
 vp8_vaapi_encoder_select="vaapi_encode"
 vp8_v4l2m2m_decoder_deps="v4l2_m2m vp8_v4l2_m2m"
 vp8_v4l2m2m_encoder_deps="v4l2_m2m vp8_v4l2_m2m"
@@ -3394,7 +3390,6 @@ vp9_mediacodec_decoder_deps="mediacodec"
 vp9_mediacodec_encoder_deps="mediacodec"
 vp9_qsv_decoder_select="qsvdec"
 vp9_rkmpp_decoder_deps="rkmpp"
-vp9_vaapi_encoder_deps="VAEncPictureParameterBufferVP9"
 vp9_vaapi_encoder_select="vaapi_encode"
 vp9_qsv_encoder_deps="libmfx MFX_CODEC_VP9"
 vp9_qsv_encoder_select="qsvenc"
@@ -3940,9 +3935,6 @@ xfade_vulkan_filter_deps="vulkan spirv_compiler"
 yadif_cuda_filter_deps="ffnvcodec"
 yadif_cuda_filter_deps_any="cuda_nvcc cuda_llvm"
 yadif_videotoolbox_filter_deps="metal corevideo videotoolbox"
-hstack_vaapi_filter_deps="vaapi_1"
-vstack_vaapi_filter_deps="vaapi_1"
-xstack_vaapi_filter_deps="vaapi_1"
 hstack_qsv_filter_deps="libmfx"
 hstack_qsv_filter_select="qsvvpp"
 vstack_qsv_filter_deps="libmfx"
@@ -7236,7 +7228,7 @@ enabled libdrm &&
 check_pkg_config libdrm_getfb2 libdrm "xf86drmMode.h" drmModeGetFB2

 enabled vaapi &&
-check_pkg_config vaapi "libva >= 0.35.0" "va/va.h" vaInitialize
+check_pkg_config vaapi "libva >= 1.0.0" "va/va.h" vaInitialize

 if enabled vaapi; then
 case $target_os in
@@ -7252,18 +7244,10 @@ if enabled vaapi; then
 check_pkg_config vaapi_x11 "libva-x11" "va/va_x11.h" vaGetDisplay
 fi

-check_cpp_condition vaapi_1 "va/va.h" "VA_CHECK_VERSION(1, 0, 0)"
-
-check_type "va/va.h va/va_dec_hevc.h" "VAPictureParameterBufferHEVC"
-check_struct "va/va.h" "VADecPictureParameterBufferVP9" bit_depth
 check_struct "va/va.h" "VADecPictureParameterBufferAV1" bit_depth_idx
 check_type   "va/va.h va/va_vpp.h" 
"VAProcFilterParameterBufferHDRToneMapping"
 check_struct "va/va.h va/va_vpp.h" "VAProcPipelineCaps" rotation_flags
 check_struct "va/va.h va/va_vpp.h" "VAProcPipelineCaps" blend_flags
-check_type "va/va.h va/va_enc_hevc.h" "VAEncPictureParameterBufferHEVC"
-check_type "va/va.h va/va_enc_jpeg.h" "VAEncPictureParameterBufferJPEG"
-check_type "va/va.h va/va_enc_vp8.h"  "VAEncPictureParameterBufferVP8"
-check_type "va/va.h va/va_enc_vp9.h"  "VAEncPictureParameterBufferVP9"
 check_type "va/va.h va/va_enc_av1.h"  "VAEncPictureParameterBufferAV1"
 fi

--
2.43.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 3/4] lavfi: Remove libva 1.x support

2024-04-03 Thread Mark Thompson

libva 2.0 was released in 2017 and the 2.x versions are included in all
supported distributions nowadays.
---
 libavfilter/vaapi_vpp.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/libavfilter/vaapi_vpp.c b/libavfilter/vaapi_vpp.c
index ace1153a23..21d74f8112 100644
--- a/libavfilter/vaapi_vpp.c
+++ b/libavfilter/vaapi_vpp.c
@@ -672,15 +672,12 @@ int ff_vaapi_vpp_render_pictures(AVFilterContext *avctx,
 goto fail_after_render;
 }

-if (CONFIG_VAAPI_1 || ctx->hwctx->driver_quirks &
-AV_VAAPI_DRIVER_QUIRK_RENDER_PARAM_BUFFERS) {
-for (int i = 0; i < cout && params_ids[i] != VA_INVALID_ID; i++) {
-vas = vaDestroyBuffer(ctx->hwctx->display, params_ids[i]);
-if (vas != VA_STATUS_SUCCESS) {
-av_log(avctx, AV_LOG_ERROR, "Failed to free parameter buffer: "
-   "%d (%s).\n", vas, vaErrorStr(vas));
-// And ignore.
-}
+for (int i = 0; i < cout && params_ids[i] != VA_INVALID_ID; i++) {
+vas = vaDestroyBuffer(ctx->hwctx->display, params_ids[i]);
+if (vas != VA_STATUS_SUCCESS) {
+av_log(avctx, AV_LOG_ERROR, "Failed to free parameter buffer: "
+   "%d (%s).\n", vas, vaErrorStr(vas));
+// And ignore.
 }
 }

--
2.43.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 2/4] lavc: Remove libva 1.x support

2024-04-03 Thread Mark Thompson

libva 2.0 was released in 2017 and the 2.x versions are included in all
supported distributions nowadays.
---
 libavcodec/vaapi_decode.c  | 10 ++
 libavcodec/vaapi_encode.c  | 31 +++
 libavcodec/vaapi_encode_h264.c | 18 --
 3 files changed, 13 insertions(+), 46 deletions(-)

diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
index 5665639dd7..4e8910ed25 100644
--- a/libavcodec/vaapi_decode.c
+++ b/libavcodec/vaapi_decode.c
@@ -191,16 +191,10 @@ int ff_vaapi_decode_issue(AVCodecContext *avctx,
 av_log(avctx, AV_LOG_ERROR, "Failed to end picture decode "
"issue: %d (%s).\n", vas, vaErrorStr(vas));
 err = AVERROR(EIO);
-if (CONFIG_VAAPI_1 || ctx->hwctx->driver_quirks &
-AV_VAAPI_DRIVER_QUIRK_RENDER_PARAM_BUFFERS)
-goto fail;
-else
-goto fail_at_end;
+goto fail;
 }

-if (CONFIG_VAAPI_1 || ctx->hwctx->driver_quirks &
-AV_VAAPI_DRIVER_QUIRK_RENDER_PARAM_BUFFERS)
-ff_vaapi_decode_destroy_buffers(avctx, pic);
+ff_vaapi_decode_destroy_buffers(avctx, pic);

 err = 0;
 goto exit;
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index f54b2579ec..0e19281ed4 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -618,26 +618,17 @@ static int vaapi_encode_issue(AVCodecContext *avctx,
 av_log(avctx, AV_LOG_ERROR, "Failed to end picture encode issue: "
"%d (%s).\n", vas, vaErrorStr(vas));
 err = AVERROR(EIO);
-// vaRenderPicture() has been called here, so we should not destroy
-// the parameter buffers unless separate destruction is required.
-if (CONFIG_VAAPI_1 || ctx->hwctx->driver_quirks &
-AV_VAAPI_DRIVER_QUIRK_RENDER_PARAM_BUFFERS)
-goto fail;
-else
-goto fail_at_end;
-}
-
-if (CONFIG_VAAPI_1 || ctx->hwctx->driver_quirks &
-AV_VAAPI_DRIVER_QUIRK_RENDER_PARAM_BUFFERS) {
-for (i = 0; i < pic->nb_param_buffers; i++) {
-vas = vaDestroyBuffer(ctx->hwctx->display,
-  pic->param_buffers[i]);
-if (vas != VA_STATUS_SUCCESS) {
-av_log(avctx, AV_LOG_ERROR, "Failed to destroy "
-   "param buffer %#x: %d (%s).\n",
-   pic->param_buffers[i], vas, vaErrorStr(vas));
-// And ignore.
-}
+goto fail;
+}
+
+for (i = 0; i < pic->nb_param_buffers; i++) {
+vas = vaDestroyBuffer(ctx->hwctx->display,
+  pic->param_buffers[i]);
+if (vas != VA_STATUS_SUCCESS) {
+av_log(avctx, AV_LOG_ERROR, "Failed to destroy "
+   "param buffer %#x: %d (%s).\n",
+   pic->param_buffers[i], vas, vaErrorStr(vas));
+// And ignore.
 }
 }

diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index bf51df0f51..4f4191e23b 100644
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcodec/vaapi_encode_h264.c
@@ -106,7 +106,6 @@ typedef struct VAAPIEncodeH264Context {

 int aud_needed;
 int sei_needed;
-int sei_cbr_workaround_needed;
 } VAAPIEncodeH264Context;


@@ -271,19 +270,6 @@ static int 
vaapi_encode_h264_write_extra_header(AVCodecContext *avctx,

 *type = VAEncPackedHeaderRawData;
 return 0;
-
-#if !CONFIG_VAAPI_1
-} else if (priv->sei_cbr_workaround_needed) {
-// Insert a zero-length header using the old SEI type.  This is
-// required to avoid triggering broken behaviour on Intel platforms
-// in CBR mode where an invalid SEI message is generated by the
-// driver and inserted into the stream.
-*data_len = 0;
-*type = VAEncPackedHeaderH264_SEI;
-priv->sei_cbr_workaround_needed = 0;
-return 0;
-#endif
-
 } else {
 return AVERROR_EOF;
 }
@@ -681,10 +667,6 @@ static int 
vaapi_encode_h264_init_picture_params(AVCodecContext *avctx,

 if (priv->sei & SEI_IDENTIFIER && pic->encode_order == 0)
 priv->sei_needed |= SEI_IDENTIFIER;
-#if !CONFIG_VAAPI_1
-if (ctx->va_rc_mode == VA_RC_CBR)
-priv->sei_cbr_workaround_needed = 1;
-#endif

 if (priv->sei & SEI_TIMING) {
 priv->sei_pic_timing = (H264RawSEIPicTiming) {
--
2.43.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 1/4] lavu: Remove libva 1.x support

2024-04-03 Thread Mark Thompson

libva 2.0 was released in 2017 and the 2.x versions are included in all
supported distributions nowadays.
---
 libavutil/hwcontext_vaapi.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 56d03aa4cd..bc82ab31e6 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -1637,7 +1637,6 @@ static void vaapi_device_free(AVHWDeviceContext *ctx)
 av_freep(&priv);
 }

-#if CONFIG_VAAPI_1
 static void vaapi_device_log_error(void *context, const char *message)
 {
 AVHWDeviceContext *ctx = context;
@@ -1651,7 +1650,6 @@ static void vaapi_device_log_info(void *context, const 
char *message)

 av_log(ctx, AV_LOG_VERBOSE, "libva: %s", message);
 }
-#endif

 static int vaapi_device_connect(AVHWDeviceContext *ctx,
 VADisplay display)
@@ -1660,10 +1658,8 @@ static int vaapi_device_connect(AVHWDeviceContext *ctx,
 int major, minor;
 VAStatus vas;

-#if CONFIG_VAAPI_1
 vaSetErrorCallback(display, &vaapi_device_log_error, ctx);
 vaSetInfoCallback (display, &vaapi_device_log_info,  ctx);
-#endif

 hwctx->display = display;

--
2.43.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".


Re: [FFmpeg-devel] [EXT] Re: Query from Reuters on XZ, open source, and Microsoft

2024-04-03 Thread Kieran Kunhya via ffmpeg-devel
Hi Raphael,

Answers in my own personal capacity, not the views of my employer, nor the
views of anyone else in FFmpeg.

On Wed, Apr 3, 2024 at 8:26 PM Satter, Raphael (Reuters) <
raphael.sat...@thomsonreuters.com> wrote:

> Dear Kieran & co.,
>
>
>
> Thank you I’ve had a chance to see the talk. It’s a marker of how
> invisible even critical open source projects can be that I wasn’t aware of
> FFmpeg’s role in powering the likes of YouTube and Netflix.
>
>
>
> A few questions I had:
>
>
>
>- How much did Microsoft end up paying for the one-time fix?
>
>
Microsoft did not pay for any fix. There was no actual fix, a command line
option had changed between FFmpeg versions and a volunteer on our bug
tracker pointed this out.

A company which has several FFmpeg developers on its payroll asked
Microsoft (a separate team in private) for a support contract in light of
the fact FFmpeg is used in critical Microsoft products. Instead of
proposing a support contract, Microsoft said a few thousand dollars was
potentially available. This amount is too small to support any developer or
maintenance.


>- What’s the solution here? Your talk mentioned paying developers,
>getting an SLA, or hiring them as consultants … but why would companies
>bother when they can just free ride? I asked the same question to CISA’s
>Jack Cable when he told me that  companies need to “contribute back and
>help build the sustainable open source ecosystem that we get so much value
>from.” Sure, they “need” to do it, but who will punish them if they don’t?
>
>
The Linux Kernel has full time developers hired by big corporations to work
solely on the Linux kernel and to maintain sections of it. However, one can
argue Linux is the exception in open source that proves the rule that
corporations will be free riders.


>- Any other thoughts you might have on this episode – or others you
>think I should speak to – would be greatly appreciated.
>
>
The Demuxed video covers the rest of my thoughts. Microsoft are not the
only company with this attitude.

Regards,
Kieran Kunhya


>
>-
>
> Raphael
>
>
>
> *From:* Kieran Kunhya 
> *Sent:* Wednesday, April 3, 2024 12:39 PM
> *To:* FFmpeg development discussions and patches 
> *Cc:* Satter, Raphael (Reuters) 
> *Subject:* [EXT] Re: [FFmpeg-devel] Query from Reuters on XZ, open
> source, and Microsoft
>
>
>
> *External Email:* Use caution with links and attachments.
>
>
>
> Hi Raphael,
>
>
>
> I was the author of the tweet and I gave a short talk about this topic at
> Demuxed at a video conference last year:
> https://m.youtube.com/watch?v=OIyOEuQQsCQ&t=930s
> 
>
>
>
> That said this is a community project and it would be best to continue the
> discussion on this mailing list unless agreed otherwise.
>
>
>
> Regards,
>
> Kieran Kunhya
>
>
>
> On Wed, 3 Apr 2024, 16:52 Satter, Raphael (Reuters) via ffmpeg-devel, <
> ffmpeg-devel@ffmpeg.org> wrote:
>
> Dear FFMPEG community,
>
> This is Raphael Satter, a journalist with Reuters. I saw your thread on X
> about your experience with Microsoft in the context of the XZ story and
> would love to follow up with a few questions.
>
> Is there a good person to talk to? I’m reachable using the details below
> or on Signal/WhatsApp at +1 202 430 9389.
>
> Raphael
>
> 💻 raphael.sat...@tr.com
> 🌎 raphaelsatter.com
> 
> 📰 reuters.com/authors/raphael-satter
>
> Thomson Reuters
> 1333 H Street NW
> Washington, DC 20005
>
> ☎️ +1 202 843-6302
>
> ___
> 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] doc/developer: (security) researchers should be credited

2024-04-03 Thread Michael Niedermayer
On Wed, Apr 03, 2024 at 10:07:56AM +0200, Tomas Härdin wrote:
> ons 2024-04-03 klockan 02:13 +0200 skrev Michael Niedermayer:
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  doc/developer.texi | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/doc/developer.texi b/doc/developer.texi
> > index c86bb5820cc..63835dfa06c 100644
> > --- a/doc/developer.texi
> > +++ b/doc/developer.texi
> > @@ -390,6 +390,10 @@ If you apply a patch, send an
> >  answer to ffmpeg-devel (or wherever you got the patch from) saying
> > that
> >  you applied the patch.
> >  
> > +@subheading Credit any researchers
> > +If a commit/patch fixes an issues found by some researcher, always
> > credit the
> > +researcher in the commit message for finding/reporting the issue.
> 
> Sounds reasonable.

will apply

thx

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

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus


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] configure: Fix iamfdec dependencies

2024-04-03 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 configure | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configure b/configure
index 71386c3920..a393f6ea65 100755
--- a/configure
+++ b/configure
@@ -2854,6 +2854,7 @@ hevcparse_select="golomb"
 hevc_sei_select="atsc_a53 golomb"
 frame_thread_encoder_deps="encoders threads"
 iamfdec_deps="iamf"
+iamfdec_select="iso_media mpeg4audio"
 iamfenc_deps="iamf"
 inflate_wrapper_deps="zlib"
 intrax8_select="blockdsp wmv2dsp"
-- 
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] [EXT] Re: Query from Reuters on XZ, open source, and Microsoft

2024-04-03 Thread Satter, Raphael (Reuters) via ffmpeg-devel
Dear Kieran & co.,

Thank you I’ve had a chance to see the talk. It’s a marker of how invisible 
even critical open source projects can be that I wasn’t aware of FFmpeg’s role 
in powering the likes of YouTube and Netflix.

A few questions I had:


  *   How much did Microsoft end up paying for the one-time fix?
  *   What’s the solution here? Your talk mentioned paying developers, getting 
an SLA, or hiring them as consultants … but why would companies bother when 
they can just free ride? I asked the same question to CISA’s Jack Cable when he 
told me that  companies need to “contribute back and help build the sustainable 
open source ecosystem that we get so much value from.” Sure, they “need” to do 
it, but who will punish them if they don’t?
  *   Any other thoughts you might have on this episode – or others you think I 
should speak to – would be greatly appreciated.

Raphael

From: Kieran Kunhya 
Sent: Wednesday, April 3, 2024 12:39 PM
To: FFmpeg development discussions and patches 
Cc: Satter, Raphael (Reuters) 
Subject: [EXT] Re: [FFmpeg-devel] Query from Reuters on XZ, open source, and 
Microsoft

External Email: Use caution with links and attachments.

Hi Raphael,

I was the author of the tweet and I gave a short talk about this topic at 
Demuxed at a video conference last year: 
https://m.youtube.com/watch?v=OIyOEuQQsCQ&t=930s

That said this is a community project and it would be best to continue the 
discussion on this mailing list unless agreed otherwise.

Regards,
Kieran Kunhya

On Wed, 3 Apr 2024, 16:52 Satter, Raphael (Reuters) via ffmpeg-devel, 
mailto:ffmpeg-devel@ffmpeg.org>> wrote:
Dear FFMPEG community,

This is Raphael Satter, a journalist with Reuters. I saw your thread on X about 
your experience with Microsoft in the context of the XZ story and would love to 
follow up with a few questions.

Is there a good person to talk to? I’m reachable using the details below or on 
Signal/WhatsApp at +1 202 430 9389.

Raphael

💻 raphael.sat...@tr.com
🌎 
raphaelsatter.com
📰 reuters.com/authors/raphael-satter

Thomson Reuters
1333 H Street NW
Washington, DC 20005

☎️ +1 202 843-6302

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with 
subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


Re: [FFmpeg-devel] [PATCH 1/3] lavu/hwcontext_vaapi: Add a new quirk

2024-04-03 Thread Mark Thompson

On 28/03/2024 02:17, Xiang, Haihao wrote:

From: Haihao Xiang 

libva2 doesn't require a fixed surface-array any more, but some
driver/hardware combinations which rely on this are still used. To
reduce the impact to users, add a quirk for the driver/hardware
combination which supports dynamic surface pool.

Signed-off-by: Haihao Xiang 
---
  libavutil/hwcontext_vaapi.c | 7 +++
  libavutil/hwcontext_vaapi.h | 6 ++
  2 files changed, 13 insertions(+)

diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 56d03aa4cd..dae5dd4a11 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -390,6 +390,13 @@ static const struct {
  "Splitted-Desktop Systems VDPAU backend for VA-API",
  AV_VAAPI_DRIVER_QUIRK_SURFACE_ATTRIBUTES,
  },
+#if CONFIG_VAAPI_1
+{
+"New Intel iHD",
+"Intel iHD driver for Intel(R) Gen Graphics",
+AV_VAAPI_DRIVER_QUIRK_DYNAMIC_SURFACE_POOL,
+},
+#endif
  };
  
  static int vaapi_device_init(AVHWDeviceContext *hwdev)

diff --git a/libavutil/hwcontext_vaapi.h b/libavutil/hwcontext_vaapi.h
index 0b2e071cb3..07014fd526 100644
--- a/libavutil/hwcontext_vaapi.h
+++ b/libavutil/hwcontext_vaapi.h
@@ -58,6 +58,12 @@ enum {
   * and the results of the vaQuerySurfaceAttributes() call will be faked.
   */
  AV_VAAPI_DRIVER_QUIRK_SURFACE_ATTRIBUTES = (1 << 3),
+
+/**
+ * The driver (and the underlying HW) supports dynamic surface pool.
+ * The vaCreateContext() call doesn't require a fixed surface-array.
+ */
+AV_VAAPI_DRIVER_QUIRK_DYNAMIC_SURFACE_POOL = (1 << 4),
  };
  
  /**


I do not think a vendor-specific quirk like this is a reasonable answer, but I 
can see that your company is invested in making sure that your current driver 
doesn't hit this problem.

Given that, I give up on arguing for trying to preserve compatibility here.  
Let's just use dynamic pools unconditionally and see if anything breaks.

Is there any reason not to drop support for libva < 2.0 at the same time?  
(Making CONFIG_VAAPI_1 always true.)  It is of similar age to C17, which we are 
intending to require soon as well.

Thanks,

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

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


Re: [FFmpeg-devel] [PATCH 1/4] avutil/pix{desc, fmt}: add new matrix coefficients from H.273 v3

2024-04-03 Thread Jan Ekström
On Tue, Apr 2, 2024 at 8:58 PM Jan Ekström  wrote:
>
> On Mon, Apr 1, 2024 at 2:34 PM Jan Ekström  wrote:
> >
> > On Fri, Mar 29, 2024 at 8:32 PM Jan Ekström  wrote:
> > >
> > > On Fri, Mar 29, 2024 at 2:33 AM Jan Ekström  wrote:
> > > >
> > > > * SMPTE ST 2128 IPT-C2 defines the coefficients utilized in DoVi
> > > >   Profile 5. Profile 5 can thus now be represented in VUI as
> > > >   {AVCOL_RANGE_JPEG, AVCOL_PRI_BT2020, AVCOL_TRC_SMPTE2084,
> > > >AVCOL_SPC_IPT_C2, AVCHROMA_LOC_LEFT} (although other chroma
> > > >   sample locations are allowed). AVCOL_TRC_SMPTE2084 should in
> > > >   this case be interpreted as 'PQ with reshaping'.
> > > > * YCgCo-Re and YCgCo-Ro define the bitexact YCgCo-R, where the
> > > >   number of bits added to a source RGB bit depth is 2 (i.e., even)
> > > >   and 1 (i.e., odd), respectively.
> > > > ---
> > > >  doc/APIchanges  | 4 
> > > >  libavutil/pixdesc.c | 3 +++
> > > >  libavutil/pixfmt.h  | 3 +++
> > > >  libavutil/version.h | 2 +-
> > > >  4 files changed, 11 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/doc/APIchanges b/doc/APIchanges
> > > > index aa102b4925..296d87d8fb 100644
> > > > --- a/doc/APIchanges
> > > > +++ b/doc/APIchanges
> > > > @@ -2,6 +2,10 @@ The last version increases of all libraries were on 
> > > > 2024-03-07
> > > >
> > > >  API changes, most recent first:
> > > >
> > > > +2024-03-27 - xx - lavu 59.11.100 - pixfmt.h
> > > > +  Add AVCOL_SPC_IPT_C2, AVCOL_SPC_YCGCO_RE and AVCOL_SPC_YCGCO_RO
> > > > +  to map new matrix coefficients defined by H.273 v3.
> > > > +
> > > >  2024-03-27 - xx - lavu 59.10.100 - frame.h
> > > >Add AVSideDataDescriptor, enum AVSideDataProps, and
> > > >av_frame_side_data_desc().
> > > > diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
> > > > index 9c708520b1..1c0bcf2232 100644
> > > > --- a/libavutil/pixdesc.c
> > > > +++ b/libavutil/pixdesc.c
> > > > @@ -2854,6 +2854,9 @@ static const char * const color_space_names[] = {
> > > >  [AVCOL_SPC_CHROMA_DERIVED_NCL] = "chroma-derived-nc",
> > > >  [AVCOL_SPC_CHROMA_DERIVED_CL] = "chroma-derived-c",
> > > >  [AVCOL_SPC_ICTCP] = "ictcp",
> > > > +[AVCOL_SPC_IPT_C2] = "ipt-c2",
> > > > +[AVCOL_SPC_YCGCO_RE] = "ycgco-re",
> > > > +[AVCOL_SPC_YCGCO_RO] = "ycgco-ro",
> > > >  };
> > > >
> > > >  static const char * const chroma_location_names[] = {
> > > > diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
> > > > index 4aa20e4e58..430118d3e1 100644
> > > > --- a/libavutil/pixfmt.h
> > > > +++ b/libavutil/pixfmt.h
> > > > @@ -623,6 +623,9 @@ enum AVColorSpace {
> > > >  AVCOL_SPC_CHROMA_DERIVED_NCL = 12, ///< Chromaticity-derived 
> > > > non-constant luminance system
> > > >  AVCOL_SPC_CHROMA_DERIVED_CL = 13, ///< Chromaticity-derived 
> > > > constant luminance system
> > > >  AVCOL_SPC_ICTCP   = 14, ///< ITU-R BT.2100-0, ICtCp
> > > > +AVCOL_SPC_IPT_C2  = 15, ///< SMPTE ST 2128
> > > > +AVCOL_SPC_YCGCO_RE= 16, ///< YCgCo-R, even addition of bits
> > > > +AVCOL_SPC_YCGCO_RO= 17, ///< YCgCo-R, odd addition of bits
> > > >  AVCOL_SPC_NB///< Not part of ABI
> > > >  };
> > >
> > > To aid in review as for whatever reason the 2023-09 H.273 v3 is not
> > > yet publicly available (even though H.274 is from the same September
> > > period), you can first of all see the summary in
> > > https://www.itu.int/itu-t/workprog/wp_item.aspx?isn=18689 .
> > >
> > > The latest related drafts from JVET-Experts
> > > (https://jvet-experts.org/doc_end_user/all_meeting.php being the
> > > index) are:
> > > - CICP/H.273: JVET-AD1003 v2 from
> > > https://jvet-experts.org/doc_end_user/current_document.php?id=12970
> > > - H.265: JVET-AF1006 from
> > > https://jvet-experts.org/doc_end_user/current_document.php?id=13584
> > > - H.264: JVET-AE1016 from
> > > https://jvet-experts.org/doc_end_user/current_document.php?id=13269
> > >
> > > Given that H.273 v3 got registered for AAP on 2023-07-21 and that the
> > > H.265 text is clearly from after the last call period of 2023-09-01 to
> > > 2023-09-28, I would consider them all matching being a pretty good
> > > indicator that the value 15 got utilized for IPT-C2, and 16+17 for
> > > YCgCo-R.
> >
> > Ping for this set.
>
> Got an LGTM from James for the set on IRC, so unless there are
> objections I will apply this tomorrow.

Applied set as:
29561c8e2d4ccecaa93afcaed73678e3f6011b0a
06c53efd233340762535957ad765ed4d9aafcddd
23d1b50175a6d07a0e2301ead347e4812c8c5dc8
16128f3c5595012719db7ae7851964d5a961c160

Small differences were that avutil got minor bumps so it went from
59.11 to 59.13, and after asking on IRC whether new values for
AVOptions should get a micro bump, I added those to avcodec and
avfilter. Additionally, a slight modification to a comment was made as
other comments also not only mentioned the spec but the format name as
well:

diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index 430118d3e1..a7f50e1690

Re: [FFmpeg-devel] [PATCH] avformat/mxfdec: Check that edit_unit_byte_count is not negative

2024-04-03 Thread Marton Balint



On Wed, 3 Apr 2024, Tomas Härdin wrote:


mån 2024-04-01 klockan 18:22 +0200 skrev Marton Balint:



On Mon, 1 Apr 2024, Michael Niedermayer wrote:

> Signed-off-by: Michael Niedermayer 
> ---
> libavformat/mxfdec.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c

> index e484db052ef..37446963369 100644
> --- a/libavformat/mxfdec.c
> +++ b/libavformat/mxfdec.c
> @@ -1245,9 +1245,13 @@ static int
> mxf_read_index_entry_array(AVIOContext *pb, MXFIndexTableSegment
> *seg
> static int mxf_read_index_table_segment(void *arg, AVIOContext *pb,
> int tag, int size, UID uid, int64_t klv_offset)
> {
>     MXFIndexTableSegment *segment = arg;
> +    int tmp;
>     switch(tag) {
>     case 0x3F05:
> -    segment->edit_unit_byte_count = avio_rb32(pb);

Why not simply make segment->edit_unit_byte_count unsigned?


This might run afoul with various calcultions. Speaking of,
mxf_edit_unit_absolute_offset() does not check for multiplication
overflows..


Michael's earlier patch fixed that, and the fix should work for both 
signed and unsigned.


Regards,
Marton
___
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/vvc: Error if SPS ID is duplicated within CVS

2024-04-03 Thread Frank Plowman
Key line from the spec is:

"All SPS NAL units with a particular value of sps_seq_parameter_set_id
in a CVS shall have the same content."

Prior to this patch, the VVC decoder's behaviour on encountering a
duplicated SPS ID (within the entire bitstream, not restricted to
a CVS) was simply to replace the entry in the SPS lookup table with the
new data.  Illegal bitstreams with multiple SPSs in the same CVS sharing
an ID but differing elsewhere could cause all manner of issues.

The patch tracks which SPS IDs have been used in the given CVS using the
new sps_id_used field of VVCParamSets.  If it encounters an SPS with an
ID already in use and whose content differs from the previous SPS, it
throws an AVERROR_INVALIDDATA.
---
 libavcodec/vvc/vvc_ps.c | 29 +
 libavcodec/vvc/vvc_ps.h |  1 +
 2 files changed, 22 insertions(+), 8 deletions(-)

diff --git a/libavcodec/vvc/vvc_ps.c b/libavcodec/vvc/vvc_ps.c
index 301fa16400..7a8daaa6ad 100644
--- a/libavcodec/vvc/vvc_ps.c
+++ b/libavcodec/vvc/vvc_ps.c
@@ -219,14 +219,23 @@ fail:
 return NULL;
 }
 
-static int decode_sps(VVCParamSets *ps, const H266RawSPS *rsps, void *log_ctx)
+static int decode_sps(VVCParamSets *ps, const H266RawSPS *rsps, void *log_ctx, 
int is_clvss)
 {
 const int sps_id= rsps->sps_seq_parameter_set_id;
 const VVCSPS *old_sps   = ps->sps_list[sps_id];
 const VVCSPS *sps;
 
-if (old_sps && old_sps->r == rsps)
-return 0;
+if (is_clvss) {
+for (int sps_id = 0; sps_id < VVC_MAX_SPS_COUNT; ++sps_id)
+ps->sps_id_used[sps_id] = 0;
+}
+
+if (old_sps)
+if (old_sps->r == rsps || !memcmp(old_sps->r, rsps, 
sizeof(*old_sps->r)))
+return 0;
+else if (ps->sps_id_used[sps_id])
+return AVERROR_INVALIDDATA;
+
 
 sps = sps_alloc(rsps, log_ctx);
 if (!sps)
@@ -234,6 +243,7 @@ static int decode_sps(VVCParamSets *ps, const H266RawSPS 
*rsps, void *log_ctx)
 
 ff_refstruct_unref(&ps->sps_list[sps_id]);
 ps->sps_list[sps_id] = sps;
+ps->sps_id_used[sps_id] = 1;
 
 return 0;
 }
@@ -610,7 +620,7 @@ static int decode_pps(VVCParamSets *ps, const H266RawPPS 
*rpps)
 return ret;
 }
 
-static int decode_ps(VVCParamSets *ps, const CodedBitstreamH266Context *h266, 
void *log_ctx)
+static int decode_ps(VVCParamSets *ps, const CodedBitstreamH266Context *h266, 
void *log_ctx, int is_clvss)
 {
 const H266RawPictureHeader *ph = h266->ph;
 const H266RawPPS *rpps;
@@ -628,7 +638,7 @@ static int decode_ps(VVCParamSets *ps, const 
CodedBitstreamH266Context *h266, vo
 if (!rsps)
 return AVERROR_INVALIDDATA;
 
-ret = decode_sps(ps, rsps, log_ctx);
+ret = decode_sps(ps, rsps, log_ctx, is_clvss);
 if (ret < 0)
 return ret;
 
@@ -867,13 +877,16 @@ int ff_vvc_decode_frame_ps(VVCFrameParamSets *fps, struct 
VVCContext *s)
 int ret = 0;
 VVCParamSets *ps= &s->ps;
 const CodedBitstreamH266Context *h266   = s->cbc->priv_data;
+int is_clvss;
 
-ret = decode_ps(ps, h266, s->avctx);
+decode_recovery_flag(s);
+is_clvss = IS_CLVSS(s);
+
+ret = decode_ps(ps, h266, s->avctx, is_clvss);
 if (ret < 0)
 return ret;
 
-decode_recovery_flag(s);
-ret = decode_frame_ps(fps, ps, h266, s->poc_tid0, IS_CLVSS(s));
+ret = decode_frame_ps(fps, ps, h266, s->poc_tid0, is_clvss);
 decode_recovery_poc(s, &fps->ph);
 return ret;
 }
diff --git a/libavcodec/vvc/vvc_ps.h b/libavcodec/vvc/vvc_ps.h
index f60d8b81c6..b293043de8 100644
--- a/libavcodec/vvc/vvc_ps.h
+++ b/libavcodec/vvc/vvc_ps.h
@@ -210,6 +210,7 @@ typedef struct VVCLMCS {
 
 typedef struct VVCParamSets {
 const VVCSPS*sps_list[VVC_MAX_SPS_COUNT];   ///< RefStruct 
reference
+  intsps_id_used[VVC_MAX_SPS_COUNT];
 const VVCPPS*pps_list[VVC_MAX_PPS_COUNT];   ///< RefStruct 
reference
 const VVCALF*alf_list[VVC_MAX_ALF_COUNT];   ///< RefStruct 
reference
 const H266RawAPS*lmcs_list[VVC_MAX_LMCS_COUNT]; ///< RefStruct 
reference
-- 
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".


Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add YUV color space metadata to AVCodec

2024-04-03 Thread Niklas Haas
On Sun, 24 Mar 2024 14:04:37 +0100 Andreas Rheinhardt 
 wrote:
> Niklas Haas:
> > On Mon, 05 Feb 2024 19:04:30 +0100 Andreas Rheinhardt 
> >  wrote:
> >> This presumes the relevant states to be a cartesian product. Which need
> >> not be true. A callback would be better; this would also allow to base
> >> the list on other values already set in an AVCodecContext. And if this
> >> were extended, it would also allow to remove init_static_data one day.
> >> It is furthermore quite wasteful to store color_ranges in a list,
> >> although there are only very few states for it.
> > 
> > There is also the consideration to be made that using a callback is
> > inconsistent with the established design. Consider that framerates,
> > pix_fmts, samplerates, sample fmts and channel layouts are all currently
> > provided as static arrays in AVCodec. There is a natural symmetry
> > between these items and the ones I intend to add (yuv matrix, range,
> > chroma location, primaries and gamma) - all of them are descriptive of
> > the way data is encoded, and are therefore also (or should be)
> > negotiable filter link properties.
> > 
> > If we add a new callback API, should we then extend it to also include
> > all of the existing items from the above list? Is there a reason that
> > yuv range supports needs to be more dynamic than the others?
> > 
> 
> It should support everything; and I'd like to remove the other (public)
> static lists, too (after the necessary deprecations).
> 
> > Food for thought: mjpeg is not the only codec that puts restrictions on
> > the format support based on the strictness level. For example,
> > yuv4mpegpipe_muxer errors out with a strictness warning if you use
> > a non-standard pixel format. And arguably, in this case, this is
> > **preferred** behavior over "silently" inserting a scale filter to
> > convert to a supported format, as the whole point of y4m2 is to
> > encapsulate raw data as-is.
> > 
> > Should we:
> > 
> > 1. Add a new dynamic callback that can query lists for all of the above
> >in a way dependent on the strictness level, and use it as
> >a replacement for the static lists currently in AVCodec?
> > 
> > 2. Continue with the status quo of having these lists be static, plus
> >dynamic checks at open() time, and continue using the "convenience
> >hack" of having ffmpeg_tools automatically restrict limited range mjpeg?
> > 
> 
> I really want this convenience hack removed.
> 
> > It is not immediately obvious to me that an automatic conversion to
> > a supported format is *necessarily* preferred to erroring out unless the
> > user specifies a lower strictness level.
> 
> I agree. (In fact, on default strictness, the current code inserts a
> scale filter even if one explicitly adds "-color_range tv".)
> 
> > 
> > As for an API, I think that rather than having an AVCodecContext-aware
> > callback at all, I would just make callbacks that directly ingest the
> > strictness level in AVCodec. That makes it far less of a black box about
> > which fields of the AVCodecContext are relevant here.
> > 
> > i.e.
> > 
> > struct AVCodec {
> > const enum AVColorRange (*get_color_ranges)(int strictness);
> > const enum AVColorSpace (*get_color_spaces)(int strictness);
> > // ditto for the other parameters?
> > }
> 
> Your callbacks would hardcode that the only thing that matters is
> strictness. And it would be very expensive, because these fields would
> be in every AVCodec, even though only a minority of AVCodecs (namely
> video encoders) would use them. (supported_framerates is even only set
> by two encoders. What a waste.) Adding an API like
> 
> int avcodec_get_supported_config(const AVCodecContext *avctx, const
> AVCodec *codec, void **supported_configs, unsigned *num_configs, enum
> AVCodecConfigs desired_config,
> unsigned flags, void *logctx);
> (enum AVCodecConfigs would contain a value for pix fmts, sample fmts etc.)

Having an extra `logctx` here seems redundant and inconsistent with
other avctx-taking functions, which log to the provided `avctx`.

> 
> allows to keep the details hidden and therefore use a compact way to
> store it.
> 
> - Andreas
> 
> ___
> 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/libdav1d: Don't cast const away unnecessarily

2024-04-03 Thread Andreas Rheinhardt
Possible since c89f6ae6899e0f3ffb4f51da1f1776ab16f5b3a0.

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

diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1d.c
index f022a4ad05..93c77ed9c6 100644
--- a/libavcodec/libdav1d.c
+++ b/libavcodec/libdav1d.c
@@ -385,7 +385,7 @@ static int libdav1d_receive_frame(AVCodecContext *c, 
AVFrame *frame)
 {
 Libdav1dContext *dav1d = c->priv_data;
 Dav1dPicture pic = { 0 }, *p = &pic;
-AVPacket *pkt;
+const AVPacket *pkt;
 #if FF_DAV1D_VERSION_AT_LEAST(5,1)
 enum Dav1dEventFlags event_flags = 0;
 #endif
@@ -439,7 +439,7 @@ static int libdav1d_receive_frame(AVCodecContext *c, 
AVFrame *frame)
   INT_MAX);
 ff_set_sar(c, frame->sample_aspect_ratio);
 
-pkt = (AVPacket *)p->m.user_data.data;
+pkt = (const AVPacket *)p->m.user_data.data;
 
 // match timestamps and packet size
 res = ff_decode_frame_props_from_pkt(c, frame, pkt);
-- 
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] [PATCH] configure: Add missing libdav1d/av1 decoders->dovi_rpu dependency

2024-04-03 Thread James Almer

On 4/3/2024 3:00 PM, Andreas Rheinhardt wrote:

Signed-off-by: Andreas Rheinhardt 
---
  configure | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index 1c5b4f3fa4..71386c3920 100755
--- a/configure
+++ b/configure
@@ -2898,7 +2898,7 @@ asv1_encoder_select="aandcttables bswapdsp fdctdsp 
pixblockdsp"
  asv2_decoder_select="blockdsp bswapdsp idctdsp"
  asv2_encoder_select="aandcttables bswapdsp fdctdsp pixblockdsp"
  atrac1_decoder_select="sinewin"
-av1_decoder_select="cbs_av1 atsc_a53"
+av1_decoder_select="atsc_a53 cbs_av1 dovi_rpu"
  bink_decoder_select="blockdsp hpeldsp"
  binkaudio_dct_decoder_select="wma_freqs"
  binkaudio_rdft_decoder_select="wma_freqs"
@@ -3487,7 +3487,7 @@ libcelt_decoder_deps="libcelt"
  libcodec2_decoder_deps="libcodec2"
  libcodec2_encoder_deps="libcodec2"
  libdav1d_decoder_deps="libdav1d"
-libdav1d_decoder_select="atsc_a53"
+libdav1d_decoder_select="atsc_a53 dovi_rpu"
  libdavs2_decoder_deps="libdavs2"
  libdavs2_decoder_select="avs2_parser"
  libfdk_aac_decoder_deps="libfdk_aac"


LGTM. If this also applies to 7.0 then please backport it.
___
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] configure: Add missing libdav1d/av1 decoders->dovi_rpu dependency

2024-04-03 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 configure | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index 1c5b4f3fa4..71386c3920 100755
--- a/configure
+++ b/configure
@@ -2898,7 +2898,7 @@ asv1_encoder_select="aandcttables bswapdsp fdctdsp 
pixblockdsp"
 asv2_decoder_select="blockdsp bswapdsp idctdsp"
 asv2_encoder_select="aandcttables bswapdsp fdctdsp pixblockdsp"
 atrac1_decoder_select="sinewin"
-av1_decoder_select="cbs_av1 atsc_a53"
+av1_decoder_select="atsc_a53 cbs_av1 dovi_rpu"
 bink_decoder_select="blockdsp hpeldsp"
 binkaudio_dct_decoder_select="wma_freqs"
 binkaudio_rdft_decoder_select="wma_freqs"
@@ -3487,7 +3487,7 @@ libcelt_decoder_deps="libcelt"
 libcodec2_decoder_deps="libcodec2"
 libcodec2_encoder_deps="libcodec2"
 libdav1d_decoder_deps="libdav1d"
-libdav1d_decoder_select="atsc_a53"
+libdav1d_decoder_select="atsc_a53 dovi_rpu"
 libdavs2_decoder_deps="libdavs2"
 libdavs2_decoder_select="avs2_parser"
 libfdk_aac_decoder_deps="libfdk_aac"
-- 
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] [EXT] Re: Query from Reuters on XZ, open source, and Microsoft

2024-04-03 Thread Satter, Raphael (Reuters) via ffmpeg-devel
Thanks Kieran, much appreciated. I’ll have a look at the video and drop a few 
additional questions into the mailing list.

Sent from Outlook for iOS

From: Kieran Kunhya 
Sent: Wednesday, April 3, 2024 12:38:39 PM
To: FFmpeg development discussions and patches 
Cc: Satter, Raphael (Reuters) 
Subject: [EXT] Re: [FFmpeg-devel] Query from Reuters on XZ, open source, and 
Microsoft

External Email: Use caution with links and attachments.

Hi Raphael,

I was the author of the tweet and I gave a short talk about this topic at 
Demuxed at a video conference last year: 
https://m.youtube.com/watch?v=OIyOEuQQsCQ&t=930s

That said this is a community project and it would be best to continue the 
discussion on this mailing list unless agreed otherwise.

Regards,
Kieran Kunhya

On Wed, 3 Apr 2024, 16:52 Satter, Raphael (Reuters) via ffmpeg-devel, 
mailto:ffmpeg-devel@ffmpeg.org>> wrote:
Dear FFMPEG community,

This is Raphael Satter, a journalist with Reuters. I saw your thread on X about 
your experience with Microsoft in the context of the XZ story and would love to 
follow up with a few questions.

Is there a good person to talk to? I’m reachable using the details below or on 
Signal/WhatsApp at +1 202 430 9389.

Raphael

💻 raphael.sat...@tr.com
🌎 
raphaelsatter.com
📰 reuters.com/authors/raphael-satter

Thomson Reuters
1333 H Street NW
Washington, DC 20005

☎️ +1 202 843-6302

___
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] Query from Reuters on XZ, open source, and Microsoft

2024-04-03 Thread Kieran Kunhya via ffmpeg-devel
Hi Raphael,

I was the author of the tweet and I gave a short talk about this topic at
Demuxed at a video conference last year:
https://m.youtube.com/watch?v=OIyOEuQQsCQ&t=930s

That said this is a community project and it would be best to continue the
discussion on this mailing list unless agreed otherwise.

Regards,
Kieran Kunhya

On Wed, 3 Apr 2024, 16:52 Satter, Raphael (Reuters) via ffmpeg-devel, <
ffmpeg-devel@ffmpeg.org> wrote:

> Dear FFMPEG community,
>
> This is Raphael Satter, a journalist with Reuters. I saw your thread on X
> about your experience with Microsoft in the context of the XZ story and
> would love to follow up with a few questions.
>
> Is there a good person to talk to? I’m reachable using the details below
> or on Signal/WhatsApp at +1 202 430 9389.
>
> Raphael
>
> 💻 raphael.sat...@tr.com
> 🌎 raphaelsatter.com
> 📰 reuters.com/authors/raphael-satter
>
> Thomson Reuters
> 1333 H Street NW
> Washington, DC 20005
>
> ☎️ +1 202 843-6302
>
> ___
> 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] Query from Reuters on XZ, open source, and Microsoft

2024-04-03 Thread Satter, Raphael (Reuters) via ffmpeg-devel
Dear FFMPEG community,

This is Raphael Satter, a journalist with Reuters. I saw your thread on X about 
your experience with Microsoft in the context of the XZ story and would love to 
follow up with a few questions.

Is there a good person to talk to? I’m reachable using the details below or on 
Signal/WhatsApp at +1 202 430 9389.

Raphael

💻 raphael.sat...@tr.com
🌎 raphaelsatter.com
📰 reuters.com/authors/raphael-satter

Thomson Reuters
1333 H Street NW
Washington, DC 20005

☎️ +1 202 843-6302

___
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 10/10] avformat/movenc: warn if dovi cfg ignored

2024-04-03 Thread Niklas Haas
From: Niklas Haas 

Since this is guarded behind strict unofficial, we should warn if the
user feeds a dolby vision stream to this muxer, as it will otherwise
result in a broken file.
---
 libavformat/movenc.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 15b65dcf96d..0f819214be9 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -2528,16 +2528,21 @@ static int mov_write_video_tag(AVFormatContext *s, 
AVIOContext *pb, MOVMuxContex
 const AVPacketSideData *spherical_mapping = 
av_packet_side_data_get(track->st->codecpar->coded_side_data,
 
track->st->codecpar->nb_coded_side_data,
 
AV_PKT_DATA_SPHERICAL);
-const AVPacketSideData *dovi = 
av_packet_side_data_get(track->st->codecpar->coded_side_data,
-   
track->st->codecpar->nb_coded_side_data,
-   
AV_PKT_DATA_DOVI_CONF);
-
 if (stereo_3d)
 mov_write_st3d_tag(s, pb, (AVStereo3D*)stereo_3d->data);
 if (spherical_mapping)
 mov_write_sv3d_tag(mov->fc, pb, 
(AVSphericalMapping*)spherical_mapping->data);
-if (dovi)
+}
+
+if (track->mode == MODE_MP4) {
+const AVPacketSideData *dovi = 
av_packet_side_data_get(track->st->codecpar->coded_side_data,
+   
track->st->codecpar->nb_coded_side_data,
+   
AV_PKT_DATA_DOVI_CONF);
+if (dovi && mov->fc->strict_std_compliance <= 
FF_COMPLIANCE_UNOFFICIAL) {
 mov_write_dvcc_dvvc_tag(s, pb, (AVDOVIDecoderConfigurationRecord 
*)dovi->data);
+} else if (dovi) {
+av_log(mov->fc, AV_LOG_WARNING, "Not writing 'dvcC'/'dvvC' box. 
Requires -strict unofficial.\n");
+}
 }
 
 if (track->par->sample_aspect_ratio.den && 
track->par->sample_aspect_ratio.num) {
-- 
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 08/10] avcodec/libaomenc: implement dolby vision coding

2024-04-03 Thread Niklas Haas
From: Niklas Haas 

---
 libavcodec/libaomenc.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
index d660afab4ec..6bc46ec6e28 100644
--- a/libavcodec/libaomenc.c
+++ b/libavcodec/libaomenc.c
@@ -43,6 +43,7 @@
 #include "avcodec.h"
 #include "bsf.h"
 #include "codec_internal.h"
+#include "dovi_rpu.h"
 #include "encode.h"
 #include "internal.h"
 #include "libaom.h"
@@ -70,6 +71,7 @@ struct FrameListData {
 typedef struct AOMEncoderContext {
 AVClass *class;
 AVBSFContext *bsf;
+DOVIContext dovi;
 struct aom_codec_ctx encoder;
 struct aom_image rawimg;
 struct aom_fixed_buf twopass_stats;
@@ -437,6 +439,7 @@ static av_cold int aom_free(AVCodecContext *avctx)
 av_freep(&avctx->stats_out);
 free_frame_list(ctx->coded_frame_list);
 av_bsf_free(&ctx->bsf);
+ff_dovi_ctx_unref(&ctx->dovi);
 return 0;
 }
 
@@ -1023,6 +1026,10 @@ static av_cold int aom_init(AVCodecContext *avctx,
 if (!cpb_props)
 return AVERROR(ENOMEM);
 
+ctx->dovi.logctx = avctx;
+if ((res = ff_dovi_configure(&ctx->dovi, avctx)) < 0)
+return res;
+
 if (avctx->flags & AV_CODEC_FLAG_GLOBAL_HEADER) {
 const AVBitStreamFilter *filter = 
av_bsf_get_by_name("extract_extradata");
 int ret;
@@ -1282,6 +1289,7 @@ static int aom_encode(AVCodecContext *avctx, AVPacket 
*pkt,
 unsigned long duration = 0;
 int res, coded_size;
 aom_enc_frame_flags_t flags = 0;
+AVFrameSideData *sd;
 
 if (frame) {
 rawimg  = &ctx->rawimg;
@@ -1319,6 +1327,24 @@ FF_ENABLE_DEPRECATION_WARNINGS
 break;
 }
 
+sd = av_frame_get_side_data(frame, AV_FRAME_DATA_DOVI_METADATA);
+if (ctx->dovi.cfg.dv_profile && sd) {
+const AVDOVIMetadata *metadata = (const AVDOVIMetadata *)sd->data;
+uint8_t *t35;
+int size;
+if ((res = ff_dovi_rpu_generate(&ctx->dovi, metadata, &t35, 
&size)) < 0)
+return res;
+res = aom_img_add_metadata(rawimg, OBU_METADATA_TYPE_ITUT_T35,
+   t35, size, AOM_MIF_ANY_FRAME);
+av_free(t35);
+if (res != AOM_CODEC_OK)
+return AVERROR(ENOMEM);
+} else if (ctx->dovi.cfg.dv_profile) {
+av_log(avctx, AV_LOG_ERROR, "Dolby Vision enabled, but received 
frame "
+   "without AV_FRAME_DATA_DOVI_METADATA");
+return AVERROR_INVALIDDATA;
+}
+
 if (frame->pict_type == AV_PICTURE_TYPE_I)
 flags |= AOM_EFLAG_FORCE_KF;
 }
-- 
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 09/10] avcodec/libx265: implement dolby vision coding

2024-04-03 Thread Niklas Haas
From: Niklas Haas 

libx265 supports these natively, we just need to attach the generated
NALs to the x265picture, as well as setting the appropriate DV profile.
---
 libavcodec/libx265.c | 36 
 1 file changed, 36 insertions(+)

diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index 40ddce60306..b525b4ed59f 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -36,6 +36,7 @@
 #include "libavutil/pixdesc.h"
 #include "avcodec.h"
 #include "codec_internal.h"
+#include "dovi_rpu.h"
 #include "encode.h"
 #include "packet_internal.h"
 #include "atsc_a53.h"
@@ -78,6 +79,8 @@ typedef struct libx265Context {
  * encounter a frame with ROI side data.
  */
 int roi_warned;
+
+DOVIContext dovi;
 } libx265Context;
 
 static int is_keyframe(NalUnitType naltype)
@@ -143,6 +146,8 @@ static av_cold int libx265_encode_close(AVCodecContext 
*avctx)
 if (ctx->encoder)
 ctx->api->encoder_close(ctx->encoder);
 
+ff_dovi_ctx_unref(&ctx->dovi);
+
 return 0;
 }
 
@@ -529,6 +534,14 @@ FF_ENABLE_DEPRECATION_WARNINGS
 }
 }
 
+#if X265_BUILD >= 167
+ctx->dovi.logctx = avctx;
+if ((ret = ff_dovi_configure(&ctx->dovi, avctx)) < 0)
+return ret;
+ctx->params->dolbyProfile = ctx->dovi.cfg.dv_profile * 10 +
+ctx->dovi.cfg.dv_bl_signal_compatibility_id;
+#endif
+
 ctx->encoder = ctx->api->encoder_open(ctx->params);
 if (!ctx->encoder) {
 av_log(avctx, AV_LOG_ERROR, "Cannot open libx265 encoder.\n");
@@ -632,6 +645,10 @@ static void free_picture(libx265Context *ctx, x265_picture 
*pic)
 for (int i = 0; i < sei->numPayloads; i++)
 av_free(sei->payloads[i].payload);
 
+#if X265_BUILD >= 167
+av_free(pic->rpu.payload);
+#endif
+
 if (pic->userData) {
 int idx = (int)(intptr_t)pic->userData - 1;
 rd_release(ctx, idx);
@@ -663,6 +680,7 @@ static int libx265_encode_frame(AVCodecContext *avctx, 
AVPacket *pkt,
 sei->numPayloads = 0;
 
 if (pic) {
+AVFrameSideData *sd;
 ReorderedData *rd;
 int rd_idx;
 
@@ -763,6 +781,24 @@ static int libx265_encode_frame(AVCodecContext *avctx, 
AVPacket *pkt,
 sei->numPayloads++;
 }
 }
+
+#if X265_BUILD >= 167
+sd = av_frame_get_side_data(pic, AV_FRAME_DATA_DOVI_METADATA);
+if (ctx->dovi.cfg.dv_profile && sd) {
+const AVDOVIMetadata *metadata = (const AVDOVIMetadata *)sd->data;
+ret = ff_dovi_rpu_generate(&ctx->dovi, metadata, 
&x265pic.rpu.payload,
+   &x265pic.rpu.payloadSize);
+if (ret < 0) {
+free_picture(ctx, &x265pic);
+return ret;
+}
+} else if (ctx->dovi.cfg.dv_profile) {
+av_log(avctx, AV_LOG_ERROR, "Dolby Vision enabled, but received 
frame "
+   "without AV_FRAME_DATA_DOVI_METADATA");
+free_picture(ctx, &x265pic);
+return AVERROR_INVALIDDATA;
+}
+#endif
 }
 
 ret = ctx->api->encoder_encode(ctx->encoder, &nal, &nnal,
-- 
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 07/10] avcodec/dovi_rpu: add ff_dovi_rpu_generate()

2024-04-03 Thread Niklas Haas
From: Niklas Haas 

This function takes a decoded AVDOVIMetadata struct and turns it back
into a binary RPU. Verified using existing tools, and matches the
bitstream in official reference files.

I decided to just roll the EMDF and NAL encapsulation into this function
because the end user will need to do it otherwise anyways.
---
 libavcodec/dovi_rpu.c | 542 ++
 libavcodec/dovi_rpu.h |  20 +-
 2 files changed, 560 insertions(+), 2 deletions(-)

diff --git a/libavcodec/dovi_rpu.c b/libavcodec/dovi_rpu.c
index b4e8d0cdea4..89353ccd1e4 100644
--- a/libavcodec/dovi_rpu.c
+++ b/libavcodec/dovi_rpu.c
@@ -29,6 +29,9 @@
 #include "dovi_rpu.h"
 #include "golomb.h"
 #include "get_bits.h"
+#include "itut35.h"
+#include "put_bits.h"
+#include "put_golomb.h"
 #include "refstruct.h"
 
 enum {
@@ -358,6 +361,42 @@ static inline int64_t get_se_coef(GetBitContext *gb, const 
AVDOVIRpuDataHeader *
 return 0; /* unreachable */
 }
 
+static inline void put_ue_coef(PutBitContext *pb, const AVDOVIRpuDataHeader 
*hdr,
+   uint64_t coef)
+{
+union { uint32_t u32; float f32; } fpart;
+
+switch (hdr->coef_data_type) {
+case RPU_COEFF_FIXED:
+set_ue_golomb(pb, coef >> hdr->coef_log2_denom);
+put_bits64(pb, hdr->coef_log2_denom,
+   coef & ((1LL << hdr->coef_log2_denom) - 1));
+break;
+case RPU_COEFF_FLOAT:
+fpart.f32 = coef / (float) (1LL << hdr->coef_log2_denom);
+put_bits64(pb, hdr->coef_log2_denom, fpart.u32);
+break;
+}
+}
+
+static inline void put_se_coef(PutBitContext *pb, const AVDOVIRpuDataHeader 
*hdr,
+   uint64_t coef)
+{
+union { uint32_t u32; float f32; } fpart;
+
+switch (hdr->coef_data_type) {
+case RPU_COEFF_FIXED:
+set_se_golomb(pb, coef >> hdr->coef_log2_denom);
+put_bits64(pb, hdr->coef_log2_denom,
+   coef & ((1LL << hdr->coef_log2_denom) - 1));
+break;
+case RPU_COEFF_FLOAT:
+fpart.f32 = coef / (float) (1LL << hdr->coef_log2_denom);
+put_bits64(pb, hdr->coef_log2_denom, fpart.u32);
+break;
+}
+}
+
 static inline unsigned get_variable_bits(GetBitContext *gb, int n)
 {
 unsigned int value = get_bits(gb, n);
@@ -885,3 +924,506 @@ fail:
 ff_dovi_ctx_unref(s); /* don't leak potentially invalid state */
 return AVERROR_INVALIDDATA;
 }
+
+static int av_q2den(AVRational q, int den)
+{
+if (q.den == den)
+return q.num;
+q = av_mul_q(q, av_make_q(den, 1));
+return (q.num + (q.den >> 1)) / q.den;
+}
+
+static void generate_ext_v1(PutBitContext *pb, const AVDOVIDmData *dm)
+{
+int ext_block_length, start_pos, pad_bits;
+
+switch (dm->level) {
+case 1:   ext_block_length = 5;  break;
+case 2:   ext_block_length = 11; break;
+case 4:   ext_block_length = 3;  break;
+case 5:   ext_block_length = 7;  break;
+case 6:   ext_block_length = 8;  break;
+case 255: ext_block_length = 6;  break;
+default: return;
+}
+
+set_ue_golomb(pb, ext_block_length);
+put_bits(pb, 8, dm->level);
+start_pos = put_bits_count(pb);
+
+switch (dm->level) {
+case 1:
+put_bits(pb, 12, dm->l1.min_pq);
+put_bits(pb, 12, dm->l1.max_pq);
+put_bits(pb, 12, dm->l1.avg_pq);
+break;
+case 2:
+put_bits(pb, 12, dm->l2.target_max_pq);
+put_bits(pb, 12, dm->l2.trim_slope);
+put_bits(pb, 12, dm->l2.trim_offset);
+put_bits(pb, 12, dm->l2.trim_power);
+put_bits(pb, 12, dm->l2.trim_chroma_weight);
+put_bits(pb, 12, dm->l2.trim_saturation_gain);
+put_bits(pb, 13, dm->l2.ms_weight + 8192);
+break;
+case 4:
+put_bits(pb, 12, dm->l4.anchor_pq);
+put_bits(pb, 12, dm->l4.anchor_power);
+break;
+case 5:
+put_bits(pb, 13, dm->l5.left_offset);
+put_bits(pb, 13, dm->l5.right_offset);
+put_bits(pb, 13, dm->l5.top_offset);
+put_bits(pb, 13, dm->l5.bottom_offset);
+break;
+case 6:
+put_bits(pb, 16, dm->l6.max_luminance);
+put_bits(pb, 16, dm->l6.min_luminance);
+put_bits(pb, 16, dm->l6.max_cll);
+put_bits(pb, 16, dm->l6.max_fall);
+break;
+case 255:
+put_bits(pb, 8, dm->l255.dm_run_mode);
+put_bits(pb, 8, dm->l255.dm_run_version);
+for (int i = 0; i < 4; i++)
+put_bits(pb, 8, dm->l255.dm_debug[i]);
+break;
+}
+
+pad_bits = ext_block_length * 8 - (put_bits_count(pb) - start_pos);
+av_assert1(pad_bits >= 0);
+put_bits(pb, pad_bits, 0);
+}
+
+static void put_cie_xy(PutBitContext *pb, AVCIExy xy)
+{
+const int denom = 32767;
+put_sbits(pb, 16, av_q2den(xy.x, denom));
+put_sbits(pb, 16, av_q2den(xy.y, denom));
+}
+
+#define ANY6(arr) (arr[0] || arr[1] || arr[2] || arr[3] || arr[4] || arr[5])
+#define ANY_XY(xy) (xy.x.num || xy.y.num)
+#define ANY_C

[FFmpeg-devel] [PATCH 06/10] avcodec/dovi_rpu: add ff_dovi_configure()

2024-04-03 Thread Niklas Haas
From: Niklas Haas 

We need to set up the configuration struct appropriately based on the
codec type, colorspace metadata, and presence/absence of an EL (though,
we currently don't support an EL).

When present, we use the signalled RPU data header to help infer (and
validate) the right values.
---
 libavcodec/dovi_rpu.c | 176 ++
 libavcodec/dovi_rpu.h |  14 +++-
 2 files changed, 189 insertions(+), 1 deletion(-)

diff --git a/libavcodec/dovi_rpu.c b/libavcodec/dovi_rpu.c
index 4da711d763e..b4e8d0cdea4 100644
--- a/libavcodec/dovi_rpu.c
+++ b/libavcodec/dovi_rpu.c
@@ -144,6 +144,182 @@ static int guess_hevc_profile(const AVDOVIRpuDataHeader 
*hdr)
 return 0; /* unknown */
 }
 
+static struct {
+uint64_t pps; // maximum pixels per second
+int width; // maximum width
+int main; // maximum bitrate in main tier
+int high; // maximum bitrate in high tier
+} dv_levels[] = {
+ [1] = {1280*720*24,1280,  20,  50},
+ [2] = {1280*720*30,1280,  20,  50},
+ [3] = {1920*1080*24,   1920,  20,  70},
+ [4] = {1920*1080*30,   2560,  20,  70},
+ [5] = {1920*1080*60,   3840,  20,  70},
+ [6] = {3840*2160*24,   3840,  25, 130},
+ [7] = {3840*2160*30,   3840,  25, 130},
+ [8] = {3840*2160*48,   3840,  40, 130},
+ [9] = {3840*2160*60,   3840,  40, 130},
+[10] = {3840*2160*120,  3840,  60, 240},
+[11] = {3840*2160*120,  7680,  60, 240},
+[12] = {7680*4320*60,   7680, 120, 450},
+[13] = {7680*4320*120u, 7680, 240, 800},
+};
+
+int ff_dovi_configure(DOVIContext *s, AVCodecContext *avctx)
+{
+AVDOVIDecoderConfigurationRecord *cfg;
+const AVDOVIRpuDataHeader *hdr = NULL;
+const AVFrameSideData *sd;
+int dv_profile, dv_level, bl_compat_id;
+size_t cfg_size;
+uint64_t pps;
+
+if (!avctx->dolbyvision)
+goto skip;
+
+sd = av_frame_side_data_get(avctx->decoded_side_data,
+avctx->nb_decoded_side_data, 
AV_FRAME_DATA_DOVI_METADATA);
+
+if (sd)
+hdr = av_dovi_get_header((const AVDOVIMetadata *) sd->data);
+
+if (avctx->dolbyvision == FF_DOLBYVISION_AUTO && !hdr)
+goto skip;
+
+switch (avctx->codec_id) {
+case AV_CODEC_ID_AV1:  dv_profile = 10; break;
+case AV_CODEC_ID_H264: dv_profile = 9;  break;
+case AV_CODEC_ID_HEVC: dv_profile = hdr ? guess_hevc_profile(hdr) : 8; 
break;
+default:
+/* No other encoder should be calling this! */
+av_assert0(0);
+return AVERROR_BUG;
+}
+
+if (avctx->strict_std_compliance > FF_COMPLIANCE_UNOFFICIAL) {
+if (dv_profile == 9) {
+if (avctx->pix_fmt != AV_PIX_FMT_YUV420P)
+dv_profile = 0;
+} else {
+if (avctx->pix_fmt != AV_PIX_FMT_YUV420P10)
+dv_profile = 0;
+}
+}
+
+switch (dv_profile) {
+case 0: /* None */
+bl_compat_id = -1;
+break;
+case 4: /* HEVC with enhancement layer */
+case 7:
+if (avctx->dolbyvision > 0) {
+av_log(s->logctx, AV_LOG_ERROR, "Coding of Dolby Vision 
enhancement "
+   "layers is currently unsupported.");
+return AVERROR_PATCHWELCOME;
+} else {
+goto skip;
+}
+case 5: /* HEVC with proprietary IPTPQc2 */
+bl_compat_id = 0;
+break;
+case 10:
+/* FIXME: check for proper H.273 tags once those are added */
+if (hdr && hdr->bl_video_full_range_flag) {
+/* AV1 with proprietary IPTPQc2 */
+bl_compat_id = 0;
+break;
+}
+/* fall through */
+case 8: /* HEVC (or AV1) with BL compatibility */
+if (avctx->colorspace == AVCOL_SPC_BT2020_NCL &&
+avctx->color_primaries == AVCOL_PRI_BT2020 &&
+avctx->color_trc == AVCOL_TRC_SMPTE2084) {
+bl_compat_id = 1;
+} else if (avctx->colorspace == AVCOL_SPC_BT2020_NCL &&
+   avctx->color_primaries == AVCOL_PRI_BT2020 &&
+   avctx->color_trc == AVCOL_TRC_ARIB_STD_B67) {
+bl_compat_id = 4;
+} else if (avctx->colorspace == AVCOL_SPC_BT709 &&
+   avctx->color_primaries == AVCOL_PRI_BT709 &&
+   avctx->color_trc == AVCOL_TRC_BT709) {
+bl_compat_id = 2;
+} else {
+/* Not a valid colorspace combination */
+bl_compat_id = -1;
+}
+}
+
+if (!dv_profile || bl_compat_id < 0) {
+if (avctx->dolbyvision > 0) {
+av_log(s->logctx, AV_LOG_ERROR, "Dolby Vision enabled, but could "
+   "not determine profile and compaatibility mode. 
Double-check "
+   "colorspace and format settings for compatibility?\n");
+return AVERROR(EINVAL);
+}
+goto skip;
+}
+
+pps = avctx->width * avctx->height;
+if (avctx->framerate.num) {
+pps = pps * avctx->framerate.num 

[FFmpeg-devel] [PATCH 05/10] avcodec/dovi_rpu: clarify semantics of guess_profile()

2024-04-03 Thread Niklas Haas
From: Niklas Haas 

This is based on HEVC only, H.264/AV1 use their own (hopefully correctly
signalled) profiles.
---
 libavcodec/dovi_rpu.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libavcodec/dovi_rpu.c b/libavcodec/dovi_rpu.c
index 267e52ceb66..4da711d763e 100644
--- a/libavcodec/dovi_rpu.c
+++ b/libavcodec/dovi_rpu.c
@@ -121,7 +121,8 @@ int ff_dovi_attach_side_data(DOVIContext *s, AVFrame *frame)
 return 0;
 }
 
-static int guess_profile(const AVDOVIRpuDataHeader *hdr)
+/* Note: Only works for HEVC */
+static int guess_hevc_profile(const AVDOVIRpuDataHeader *hdr)
 {
 switch (hdr->vdr_rpu_profile) {
 case 0:
@@ -510,7 +511,7 @@ int ff_dovi_rpu_parse(DOVIContext *s, const uint8_t *rpu, 
size_t rpu_size,
 use_prev_vdr_rpu = get_bits1(gb);
 use_nlq = (hdr->rpu_format & 0x700) == 0 && !hdr->disable_residual_flag;
 
-profile = s->cfg.dv_profile ? s->cfg.dv_profile : guess_profile(hdr);
+profile = s->cfg.dv_profile ? s->cfg.dv_profile : guess_hevc_profile(hdr);
 if (profile == 5 && use_nlq) {
 av_log(s->logctx, AV_LOG_ERROR, "Profile 5 RPUs should not use NLQ\n");
 goto fail;
-- 
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 04/10] avcodec/dovi_rpu: clarify error on missing RPU VDR

2024-04-03 Thread Niklas Haas
From: Niklas Haas 

The code was written under the misguided assumption that these fields
would only be present when the value changes, however this does not
match the actual patent specification, which says that streams are
required to either always signal this metadata, or never signal it.

That said, the specification does not really clarify what the defaults
of these fields should be in the event that this metadata is missing, so
without any sample file or other reference I don't wish to hazard
a guess at how to interpret these fields.

Fix the current behavior by making sure we always throw this error, even
for files that have the vdr sequence info in one frame but are missing
it in the next frame.
---
 libavcodec/dovi_rpu.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/libavcodec/dovi_rpu.c b/libavcodec/dovi_rpu.c
index bfb7b9fe661..267e52ceb66 100644
--- a/libavcodec/dovi_rpu.c
+++ b/libavcodec/dovi_rpu.c
@@ -499,11 +499,11 @@ int ff_dovi_rpu_parse(DOVIContext *s, const uint8_t *rpu, 
size_t rpu_size,
 hdr->el_spatial_resampling_filter_flag = get_bits1(gb);
 hdr->disable_residual_flag = get_bits1(gb);
 }
-}
-
-if (!hdr->bl_bit_depth) {
-av_log(s->logctx, AV_LOG_ERROR, "Missing RPU VDR sequence info?\n");
-goto fail;
+} else {
+/* lack of documentation/samples */
+avpriv_request_sample(s->logctx, "Missing RPU VDR sequence info\n");
+ff_dovi_ctx_unref(s);
+return AVERROR_PATCHWELCOME;
 }
 
 vdr_dm_metadata_present = get_bits1(gb);
-- 
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 03/10] avcodec/dovi_rpu: properly replace context header

2024-04-03 Thread Niklas Haas
From: Niklas Haas 

This was never set in ff_dovi_ctx_replace(), leading to possibly
out-of-date when copying from a sub-thread to the main thread.
---
 libavcodec/dovi_rpu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/dovi_rpu.c b/libavcodec/dovi_rpu.c
index d95c7e03af9..bfb7b9fe661 100644
--- a/libavcodec/dovi_rpu.c
+++ b/libavcodec/dovi_rpu.c
@@ -75,6 +75,7 @@ void ff_dovi_ctx_replace(DOVIContext *s, const DOVIContext 
*s0)
 {
 s->logctx = s0->logctx;
 s->cfg = s0->cfg;
+s->header = s0->header;
 s->mapping = s0->mapping;
 s->color = s0->color;
 for (int i = 0; i <= DOVI_MAX_DM_ID; i++)
-- 
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 02/10] avcodec/dovi_rpu: store entire config record

2024-04-03 Thread Niklas Haas
From: Niklas Haas 

And make it public.

For encoding, users may also be interested in the configured level and
compatibility ID. So generalize the dv_profile field and just expose the
whole configuration record.

This makes the already rather reductive ff_dovi_update_cfg() function
almost wholly redundant, since users can just directly assign
DOVIContext.cfg.
---
 libavcodec/av1dec.c   |  6 +++---
 libavcodec/dovi_rpu.c | 16 
 libavcodec/dovi_rpu.h | 21 -
 libavcodec/hevcdec.c  | 13 ++---
 libavcodec/libdav1d.c |  6 +++---
 5 files changed, 28 insertions(+), 34 deletions(-)

diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
index 824725c031f..4c1405df779 100644
--- a/libavcodec/av1dec.c
+++ b/libavcodec/av1dec.c
@@ -888,10 +888,10 @@ static av_cold int av1_decode_init(AVCodecContext *avctx)
 }
 
 s->dovi.logctx = avctx;
-s->dovi.dv_profile = 10; // default for AV1
+s->dovi.cfg.dv_profile = 10; // default for AV1
 sd = ff_get_coded_side_data(avctx, AV_PKT_DATA_DOVI_CONF);
-if (sd && sd->size > 0)
-ff_dovi_update_cfg(&s->dovi, (AVDOVIDecoderConfigurationRecord *) 
sd->data);
+if (sd && sd->size >= sizeof(s->dovi.cfg))
+s->dovi.cfg = *(AVDOVIDecoderConfigurationRecord *) sd->data;
 
 return ret;
 }
diff --git a/libavcodec/dovi_rpu.c b/libavcodec/dovi_rpu.c
index 9f7a6b00664..d95c7e03af9 100644
--- a/libavcodec/dovi_rpu.c
+++ b/libavcodec/dovi_rpu.c
@@ -64,7 +64,7 @@ void ff_dovi_ctx_flush(DOVIContext *s)
 
 *s = (DOVIContext) {
 .logctx = s->logctx,
-.dv_profile = s->dv_profile,
+.cfg = s->cfg,
 /* preserve temporary buffer */
 .rpu_buf = s->rpu_buf,
 .rpu_buf_sz = s->rpu_buf_sz,
@@ -74,22 +74,14 @@ void ff_dovi_ctx_flush(DOVIContext *s)
 void ff_dovi_ctx_replace(DOVIContext *s, const DOVIContext *s0)
 {
 s->logctx = s0->logctx;
+s->cfg = s0->cfg;
 s->mapping = s0->mapping;
 s->color = s0->color;
-s->dv_profile = s0->dv_profile;
 for (int i = 0; i <= DOVI_MAX_DM_ID; i++)
 ff_refstruct_replace(&s->vdr[i], s0->vdr[i]);
 ff_refstruct_replace(&s->ext_blocks, s0->ext_blocks);
 }
 
-void ff_dovi_update_cfg(DOVIContext *s, const AVDOVIDecoderConfigurationRecord 
*cfg)
-{
-if (!cfg)
-return;
-
-s->dv_profile = cfg->dv_profile;
-}
-
 int ff_dovi_attach_side_data(DOVIContext *s, AVFrame *frame)
 {
 AVFrameSideData *sd;
@@ -392,7 +384,7 @@ int ff_dovi_rpu_parse(DOVIContext *s, const uint8_t *rpu, 
size_t rpu_size,
 goto fail;
 
 /* Container */
-if (s->dv_profile == 10 /* dav1.10 */) {
+if (s->cfg.dv_profile == 10 /* dav1.10 */) {
 /* DV inside AV1 re-uses an EMDF container skeleton, but with fixed
  * values - so we can effectively treat this as a magic byte sequence.
  *
@@ -517,7 +509,7 @@ int ff_dovi_rpu_parse(DOVIContext *s, const uint8_t *rpu, 
size_t rpu_size,
 use_prev_vdr_rpu = get_bits1(gb);
 use_nlq = (hdr->rpu_format & 0x700) == 0 && !hdr->disable_residual_flag;
 
-profile = s->dv_profile ? s->dv_profile : guess_profile(hdr);
+profile = s->cfg.dv_profile ? s->cfg.dv_profile : guess_profile(hdr);
 if (profile == 5 && use_nlq) {
 av_log(s->logctx, AV_LOG_ERROR, "Profile 5 RPUs should not use NLQ\n");
 goto fail;
diff --git a/libavcodec/dovi_rpu.h b/libavcodec/dovi_rpu.h
index 9f26f332ceb..9a68e45bf1b 100644
--- a/libavcodec/dovi_rpu.h
+++ b/libavcodec/dovi_rpu.h
@@ -31,6 +31,16 @@
 typedef struct DOVIContext {
 void *logctx;
 
+/**
+ * Currently active dolby vision configuration, or {0} for none.
+ * Set by the user when decoding.
+ *
+ * Note: sizeof(cfg) is not part of the libavutil ABI, so users should
+ * never pass &cfg to any other library calls. This is included merely as
+ * a way to look up the values of fields known at compile time.
+ */
+AVDOVIDecoderConfigurationRecord cfg;
+
 /**
  * Currently active RPU data header, updates on every dovi_rpu_parse().
  */
@@ -56,7 +66,6 @@ typedef struct DOVIContext {
 struct DOVIVdr *vdr[DOVI_MAX_DM_ID+1]; ///< RefStruct references
 uint8_t *rpu_buf; ///< temporary buffer
 unsigned rpu_buf_sz;
-uint8_t dv_profile;
 
 } DOVIContext;
 
@@ -68,17 +77,11 @@ void ff_dovi_ctx_replace(DOVIContext *s, const DOVIContext 
*s0);
 void ff_dovi_ctx_unref(DOVIContext *s);
 
 /**
- * Partially reset the internal state. Resets per-frame state while preserving
- * fields parsed from the configuration record.
+ * Partially reset the internal state. Resets per-frame state, but preserves
+ * the stream-wide configuration record.
  */
 void ff_dovi_ctx_flush(DOVIContext *s);
 
-/**
- * Read the contents of an AVDOVIDecoderConfigurationRecord (usually provided
- * by stream side data) and update internal state accordingly.
- */
-void ff_dovi_update_cfg(DOVIContext *s, const AVDOVIDecoderConfigurationRecord 
*cfg);
-
 /**
  * Parse the c

[FFmpeg-devel] [PATCH 01/10] avcodec: add dolbyvision option

2024-04-03 Thread Niklas Haas
From: Niklas Haas 

Tri-state yes/no/auto option. Allows users to set `dolbyvision` to `no`
to suppress coding dolby vision even when supported by the target codec.
---
 doc/APIchanges |  3 +++
 doc/codecs.texi| 12 
 libavcodec/avcodec.h   | 11 +++
 libavcodec/options_table.h |  2 ++
 libavcodec/version.h   |  2 +-
 5 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 7eda1321cb0..a4484ceb670 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,9 @@ The last version increases of all libraries were on 2024-03-07
 
 API changes, most recent first:
 
+2024-03-23 - f17e18d2922 - lavc 61.6.100 - avcodec.h
+  Add AVCodecContext.dolbyvision option.
+
 2024-04-xx - xx - lavu 59.12.100 - dovi_meta.h
   Add AVDOVIMetadata.ext_block_{offset,size}, AVDOVIMetadata.num_ext_blocks,
   AVDOVIDmData and AVDOVIDmLevel{1..6,8..11,254..255}, av_dovi_get_ext()
diff --git a/doc/codecs.texi b/doc/codecs.texi
index 6bdeb664e72..7203adc0489 100644
--- a/doc/codecs.texi
+++ b/doc/codecs.texi
@@ -1018,6 +1018,18 @@ Note: The required alignment depends on if 
@code{AV_CODEC_FLAG_UNALIGNED} is set
 CPU. @code{AV_CODEC_FLAG_UNALIGNED} cannot be changed from the command line. 
Also hardware
 decoders will not apply left/top Cropping.
 
+@item dolbyvision @var{integer} (@emph{encoding,video})
+Whether to encode Dolby Vision metadata when transcoding.
+Possible values:
+@table @samp
+@item auto
+Enable when coded frames contain Dolby Vision side data (default)
+@item yes/on
+Enable always, error out when frames do not contain metadata
+@item no/off
+Disable always, strip any tagged metadata
+@end table
+
 
 @end table
 
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 83dc487251c..f54f758608d 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -2075,6 +2075,17 @@ typedef struct AVCodecContext {
  */
 AVFrameSideData  **decoded_side_data;
 int nb_decoded_side_data;
+
+/**
+ * Video encoding only. Whether to mark the coded stream as Dolby Vision.
+ * If set to FF_DOLBYVISION_AUTO, this will be enabled only if
+ * decoded_side_data contains a valid RPU.
+ *
+ * If enabled, sending frames without AV_FRAME_DATA_DOVI_METADATA is
+ * considered an error.
+ */
+int dolbyvision;
+#define FF_DOLBYVISION_AUTO -1
 } AVCodecContext;
 
 /**
diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
index 7a2ef3474e7..d92269d2ff7 100644
--- a/libavcodec/options_table.h
+++ b/libavcodec/options_table.h
@@ -407,6 +407,8 @@ static const AVOption avcodec_options[] = {
 {"mastering_display_metadata",  .default_val.i64 = 
AV_PKT_DATA_MASTERING_DISPLAY_METADATA,  .type = AV_OPT_TYPE_CONST, .flags = 
A|D, .unit = "side_data_pkt" },
 {"content_light_level", .default_val.i64 = 
AV_PKT_DATA_CONTENT_LIGHT_LEVEL, .type = AV_OPT_TYPE_CONST, .flags = 
A|D, .unit = "side_data_pkt" },
 {"icc_profile", .default_val.i64 = 
AV_PKT_DATA_ICC_PROFILE, .type = AV_OPT_TYPE_CONST, .flags = 
A|D, .unit = "side_data_pkt" },
+{"dolbyvision", "flag stream as Dolby Vision", OFFSET(dolbyvision), 
AV_OPT_TYPE_INT, {.i64 = FF_DOLBYVISION_AUTO }, -1, 1, V|E, .unit = 
"dolbyvision" },
+{"auto", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_DOLBYVISION_AUTO }, .flags = 
V|E, .unit = "dolbyvision" },
 {NULL},
 };
 
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 7aa95fc3f1c..da54f878874 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
 
 #include "version_major.h"
 
-#define LIBAVCODEC_VERSION_MINOR   5
+#define LIBAVCODEC_VERSION_MINOR   6
 #define LIBAVCODEC_VERSION_MICRO 100
 
 #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
-- 
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".


Re: [FFmpeg-devel] [PATCH] avcodec/vvcdec: move vvcdec.{c, h} to the top directory

2024-04-03 Thread Andreas Rheinhardt
Anton Khirnov:
> Quoting James Almer (2024-04-03 16:46:14)
>> On 4/3/2024 5:35 AM, Anton Khirnov wrote:
>>> Quoting James Almer (2024-04-02 21:28:28)
 On 4/2/2024 4:25 PM, Andreas Rheinhardt wrote:
> James Almer:
>> As it's the main file declaring the AVCodec.
>
> And why is that supposed to be an advantage?

 It's not, it's a cosmetic change. Makes it easier to find at least one
 file containing the core code in the base directory.
 And I'd like to do the same for other big modules with 3+ source files.
 hevc, h264, vp9, etc.
>>>
>>> I dislike this.
>>
>> Any particular reason why? I'd really like to get some consistency in 
>> the lavc folder.
> 
> So would I, but it seems inconsistent to me to have everything
> foo-related in a directory, except this one special file.
> 
> If we have a directory for codec X, it seems most consistent to me to
> put EVERYTHING in that directory.
> 

+1.

- Andreas

___
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/httpauth: add SHA-256 Digest Authorization (Combined)

2024-04-03 Thread Andreas Rheinhardt
정지우 | Eugene:
> - add SHA-256 Digest Authorization for RFC7616 using avutil/hash.h
> - make_digest_auth_sha() : A1hash-> a1_hash and A2hash -> a2_hash
> - combine with lint fix patch 
> (Please ignore previous patch requests that were requested by mistake): 
> [FFmpeg-devel] [PATCH] fix typo(1),style(1),nit(4) issue
> 
> Signed-off-by: Eugene-bitsensing 
> ---
>  libavformat/httpauth.c| 130 +-
>  libavformat/httpauth.h|   8 +
>  ...h-add-SHA-256-Digest-Authorization-Com.eml | 224 ++
>  3 files changed, 354 insertions(+), 8 deletions(-)
>  create mode 100644 
> outputfolder/0001-avformat-httpauth-add-SHA-256-Digest-Authorization-Com.eml

You should not try to commit the eml file corresponding to your patch.

- Andreas

___
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/10] avcodec/libvpxenc: Avoid unused-variable warning if VP9 enc is disabled

2024-04-03 Thread Andreas Rheinhardt
Anton Khirnov:
> Quoting Andreas Rheinhardt (2024-03-31 07:30:26)
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>>  libavcodec/libvpxenc.c | 7 ---
>>  1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
>> index 635cdf7a0e..bcbdc4981e 100644
>> --- a/libavcodec/libvpxenc.c
>> +++ b/libavcodec/libvpxenc.c
>> @@ -49,6 +49,9 @@
>>  #include "libavutil/opt.h"
>>  #include "libavutil/pixdesc.h"
>>  
>> +#define IS_VP9(avctx) (CONFIG_LIBVPX_VP9_ENCODER && avctx->codec_id == 
>> AV_CODEC_ID_VP9)
>> +#define IS_VP8(avctx) (CONFIG_LIBVPX_VP8_ENCODER && avctx->codec_id == 
>> AV_CODEC_ID_VP8)
>> +
>>  /**
>>   * Portion of struct vpx_codec_cx_pkt from vpx_encoder.h.
>>   * One encoded frame returned from the library.
>> @@ -359,8 +362,7 @@ static int frame_data_submit(AVCodecContext *avctx, 
>> AVFifo *fifo,
>>  FrameData fd = { .pts = frame->pts };
>>  int ret;
>>  
>> -#if CONFIG_LIBVPX_VP9_ENCODER
>> -if (avctx->codec_id == AV_CODEC_ID_VP9 &&
>> +if (IS_VP9(avctx) &&
> 
> Weren't we moving towards getting rid of our dependency on DCE?
> I recall some discussions about this in recent years, though I don't
> remember if there was a consensus.
> 

This patch does not add any dependency on DCE, because the code block
currently #if'ed away does not contain anything that would cause a
linking failure with a compiler not performing DCE.

- Andreas

___
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/vvcdec: move vvcdec.{c, h} to the top directory

2024-04-03 Thread Anton Khirnov
Quoting James Almer (2024-04-03 16:46:14)
> On 4/3/2024 5:35 AM, Anton Khirnov wrote:
> > Quoting James Almer (2024-04-02 21:28:28)
> >> On 4/2/2024 4:25 PM, Andreas Rheinhardt wrote:
> >>> James Almer:
>  As it's the main file declaring the AVCodec.
> >>>
> >>> And why is that supposed to be an advantage?
> >>
> >> It's not, it's a cosmetic change. Makes it easier to find at least one
> >> file containing the core code in the base directory.
> >> And I'd like to do the same for other big modules with 3+ source files.
> >> hevc, h264, vp9, etc.
> > 
> > I dislike this.
> 
> Any particular reason why? I'd really like to get some consistency in 
> the lavc folder.

So would I, but it seems inconsistent to me to have everything
foo-related in a directory, except this one special file.

If we have a directory for codec X, it seems most consistent to me to
put EVERYTHING in that directory.

-- 
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] avcodec/vvcdec: move vvcdec.{c, h} to the top directory

2024-04-03 Thread James Almer

On 4/3/2024 5:35 AM, Anton Khirnov wrote:

Quoting James Almer (2024-04-02 21:28:28)

On 4/2/2024 4:25 PM, Andreas Rheinhardt wrote:

James Almer:

As it's the main file declaring the AVCodec.


And why is that supposed to be an advantage?


It's not, it's a cosmetic change. Makes it easier to find at least one
file containing the core code in the base directory.
And I'd like to do the same for other big modules with 3+ source files.
hevc, h264, vp9, etc.


I dislike this.


Any particular reason why? I'd really like to get some consistency in 
the lavc folder. bsfs are currently all in their own folder, but 
decoders, encoders and hwaccels are in the top directory alongside all 
the generic code, save for vvc and a h26x shared folder. And then 
there's the arch folders.


My idea was something like

libavcodec/foodec.{c,h}
libavcodec/fooenc.{c,h}
libavcodec/foo/foo_$bar.{c,h}
libavcodec/foo/$arch/foo*.{asm,c,h}



Though I would be in favor of removing the vvc prefix from the file
names, as it's redundant with dirname.


I wouldn't oppose.
___
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] [GASPP PATCH] Implicitly start out in the text section for armasm

2024-04-03 Thread Martin Storsjö
This fixes assembling files starting with bare symbol declarations,
without explicitly switching to .text first.
---
 gas-preprocessor.pl | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gas-preprocessor.pl b/gas-preprocessor.pl
index 2880858..b66181a 100755
--- a/gas-preprocessor.pl
+++ b/gas-preprocessor.pl
@@ -289,6 +289,9 @@ my %aarch64_req_alias;
 if ($force_thumb) {
 parse_line(".thumb\n");
 }
+if ($as_type eq "armasm") {
+parse_line(".text\n");
+}
 
 # pass 1: parse .macro
 # note that the handling of arguments is probably overly permissive vs. gas
-- 
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] 7.0 Name

2024-04-03 Thread Niklas Haas
On Mon, 01 Apr 2024 19:42:29 -0400 Sean McGovern  wrote:
> Hi,
> 
> On Mon, Apr 1, 2024, 18:00 Lynne  wrote:
> 
> > Apr 1, 2024, 22:01 by mich...@niedermayer.cc:
> >
> > > Hi all
> > >
> > > I think we didnt decide on a name for 7.0 yet
> > >
> > > Previously suggested names:
> > > Darwin,
> > > De broglie,
> > > Dijkstra,
> > > Galois,
> > > Gauss,
> > > Jacobi,
> > > Jemison
> > > Johnson
> > > Leavitt
> > > Maxwell,
> > > Mellin,
> > > Perelman,
> > > Poincaré,
> > > Ramanujan,
> > > Sagan,
> > > Ting
> > > Viterbi,
> > > Voltaire,
> > > de Sitter,
> > >
> > > Please reply with what you prefer or add more to the list.
> > > If we end in a tie, previously suggested names will be favoured
> > > I will vote last so that i can resolve a tie if one occurs.
> > >
> >
> > Voltaire
> > ___
> > 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".
> >
> 
> Not sure if I am allowed to pick, my choice is Dijkstra.

+1

> 
> -- Sean McGovern
> 
> >
> ___
> 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] configure: Separate subsystem for Immersive Audio Model

2024-04-03 Thread James Almer

On 4/3/2024 1:01 AM, Eugene Zemtsov via ffmpeg-devel wrote:

From: Eugene Zemtsov 

This change allows users to link ffmpeg as a library without
support for Immersive Audio Model by specifying --disable-iamf.
It helps to save on binary size in cases where it's important.

Signed-off-by: Eugene Zemtsov 
---
  configure |  7 ++-
  libavformat/mov.c | 15 ++-
  2 files changed, 20 insertions(+), 2 deletions(-)


Amended it to also include movenc and applied it. 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] lavc/vvc: Only read split_cu_flag if a split is allowed

2024-04-03 Thread Nuo Mi
On Wed, Apr 3, 2024 at 5:59 PM Frank Plowman  wrote:

> On 02/04/2024 22:48, Frank Plowman wrote:
> > Add a check to ensure some split is possible before reading the
> > split_cu_flag.  This is present in the spec, in VVCv3 section 7.3.11.4.
> > Its omission could lead to infinite loops and ultimately crashing due to
> > stack overflow.
> > ---
> >   libavcodec/vvc/vvc_ctu.c | 7 ++-
> >   1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/vvc/vvc_ctu.c b/libavcodec/vvc/vvc_ctu.c
> > index 8ba12c8d9f..32d8bc8f5c 100644
> > --- a/libavcodec/vvc/vvc_ctu.c
> > +++ b/libavcodec/vvc/vvc_ctu.c
> > @@ -2095,6 +2095,7 @@ static int hls_coding_tree(VVCLocalContext *lc,
> >   const int ch_type   = tree_type_curr ==
> DUAL_TREE_CHROMA;
> >   int ret;
> >   VVCAllowedSplit allowed;
> > +int split_cu_flag;
> >
> >   if (pps->r->pps_cu_qp_delta_enabled_flag && qg_on_y && cb_sub_div
> <= sh->cu_qp_delta_subdiv) {
> >   lc->parse.is_cu_qp_delta_coded = 0;
> > @@ -2109,7 +2110,11 @@ static int hls_coding_tree(VVCLocalContext *lc,
> >
> >   can_split(lc, x0, y0, cb_width, cb_height, mtt_depth,
> depth_offset, part_idx,
> >   last_split_mode, tree_type_curr, mode_type_curr, &allowed);
> > -if (ff_vvc_split_cu_flag(lc, x0, y0, cb_width, cb_height, ch_type,
> &allowed)) {
> > +if (allowed.btv || allowed.bth || allowed.ttv || allowed.tth ||
> allowed.qt)
> > +split_cu_flag = ff_vvc_split_cu_flag(lc, x0, y0, cb_width,
> cb_height, ch_type, &allowed);
> > +else
> > +split_cu_flag = 0;
> > +if (split_cu_flag) {
> >   VVCSplitMode split  = ff_vvc_split_mode(lc, x0, y0,
> cb_width, cb_height, cqt_depth, mtt_depth, ch_type, &allowed);
> >   VVCModeType mode_type   = mode_type_decode(lc, x0, y0,
> cb_width, cb_height, split, ch_type, mode_type_curr);
> >
>
> Retracting this patch as I missed that this logic is in fact
> implemented, just elsewhere.  There is still a bug here, but it seems
> the condition to trigger it is more complex that I thought.  Should have
> an alternative patch soon.
>
Hi Frank,
Thanks for your patch.
Please forward the clip to me as well. I'll use it to test your patch
during the review.

> ___
> 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 7/7 v6] avcodec/hevcdec: export global side data in AVCodecContext

2024-04-03 Thread James Almer
Signed-off-by: James Almer 
---
 libavcodec/avcodec.h   |   2 +-
 libavcodec/h2645_sei.c | 215 +
 libavcodec/h2645_sei.h |   2 +
 libavcodec/hevcdec.c   |   4 +
 libavcodec/pthread_frame.c |  14 ++-
 5 files changed, 143 insertions(+), 94 deletions(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 83dc487251..968009a192 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -2071,7 +2071,7 @@ typedef struct AVCodecContext {
  * - encoding: may be set by user before calling avcodec_open2() for
  * encoder configuration. Afterwards owned and freed by the
  * encoder.
- * - decoding: unused
+ * - decoding: may be set by libavcodec in avcodec_open2().
  */
 AVFrameSideData  **decoded_side_data;
 int nb_decoded_side_data;
diff --git a/libavcodec/h2645_sei.c b/libavcodec/h2645_sei.c
index f0f107f73b..1dcdbe7ffb 100644
--- a/libavcodec/h2645_sei.c
+++ b/libavcodec/h2645_sei.c
@@ -529,6 +529,120 @@ static int is_frame_packing_type_valid(SEIFpaType type, 
enum AVCodecID codec_id)
type >= SEI_FPA_TYPE_SIDE_BY_SIDE;
 }
 
+static int h2645_sei_to_side_data(AVCodecContext *avctx, H2645SEI *sei,
+  AVFrameSideData ***sd, int *nb_sd)
+{
+int ret;
+
+for (unsigned i = 0; i < sei->unregistered.nb_buf_ref; i++) {
+H2645SEIUnregistered *unreg = &sei->unregistered;
+
+if (unreg->buf_ref[i]) {
+AVFrameSideData *entry = av_frame_side_data_add(sd, nb_sd,
+AV_FRAME_DATA_SEI_UNREGISTERED,
+&unreg->buf_ref[i], 0);
+if (!entry)
+av_buffer_unref(&unreg->buf_ref[i]);
+}
+}
+sei->unregistered.nb_buf_ref = 0;
+
+if (sei->ambient_viewing_environment.present) {
+H2645SEIAmbientViewingEnvironment *env =
+&sei->ambient_viewing_environment;
+AVBufferRef *buf;
+size_t size;
+
+AVAmbientViewingEnvironment *dst_env =
+av_ambient_viewing_environment_alloc(&size);
+if (!dst_env)
+return AVERROR(ENOMEM);
+
+buf = av_buffer_create((uint8_t *)dst_env, size, NULL, NULL, 0);
+if (!buf) {
+av_free(dst_env);
+return AVERROR(ENOMEM);
+}
+
+ret = ff_frame_new_side_data_from_buf_ext(avctx, sd, nb_sd,
+  
AV_FRAME_DATA_AMBIENT_VIEWING_ENVIRONMENT, &buf);
+
+if (ret < 0)
+return ret;
+
+dst_env->ambient_illuminance = av_make_q(env->ambient_illuminance, 
1);
+dst_env->ambient_light_x = av_make_q(env->ambient_light_x, 
5);
+dst_env->ambient_light_y = av_make_q(env->ambient_light_y, 
5);
+}
+
+if (sei->mastering_display.present) {
+// HEVC uses a g,b,r ordering, which we convert to a more natural r,g,b
+const int mapping[3] = {2, 0, 1};
+const int chroma_den = 5;
+const int luma_den = 1;
+int i;
+AVMasteringDisplayMetadata *metadata;
+
+ret = ff_decode_mastering_display_new_ext(avctx, sd, nb_sd, &metadata);
+if (ret < 0)
+return ret;
+
+if (metadata) {
+for (i = 0; i < 3; i++) {
+const int j = mapping[i];
+metadata->display_primaries[i][0].num = 
sei->mastering_display.display_primaries[j][0];
+metadata->display_primaries[i][0].den = chroma_den;
+metadata->display_primaries[i][1].num = 
sei->mastering_display.display_primaries[j][1];
+metadata->display_primaries[i][1].den = chroma_den;
+}
+metadata->white_point[0].num = 
sei->mastering_display.white_point[0];
+metadata->white_point[0].den = chroma_den;
+metadata->white_point[1].num = 
sei->mastering_display.white_point[1];
+metadata->white_point[1].den = chroma_den;
+
+metadata->max_luminance.num = sei->mastering_display.max_luminance;
+metadata->max_luminance.den = luma_den;
+metadata->min_luminance.num = sei->mastering_display.min_luminance;
+metadata->min_luminance.den = luma_den;
+metadata->has_luminance = 1;
+metadata->has_primaries = 1;
+
+av_log(avctx, AV_LOG_DEBUG, "Mastering Display Metadata:\n");
+av_log(avctx, AV_LOG_DEBUG,
+   "r(%5.4f,%5.4f) g(%5.4f,%5.4f) b(%5.4f %5.4f) wp(%5.4f, 
%5.4f)\n",
+   av_q2d(metadata->display_primaries[0][0]),
+   av_q2d(metadata->display_primaries[0][1]),
+   av_q2d(metadata->display_primaries[1][0]),
+   av_q2d(metadata->display_primaries[1][1]),
+   av_q2d(metadata->display_primaries[2][0]),
+   av_q2d(metadata->display_primaries[2][1]),
+  

Re: [FFmpeg-devel] [PATCH 7/7 v5] avcodec/hevcdec: export global side data in AVCodecContext

2024-04-03 Thread James Almer

On 4/3/2024 5:32 AM, Anton Khirnov wrote:

Quoting James Almer (2024-03-28 17:52:50)

diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index fd356bd190..a693e12670 100644
--- a/libavcodec/pthread_frame.c
+++ b/libavcodec/pthread_frame.c
@@ -334,6 +334,15 @@ FF_ENABLE_DEPRECATION_WARNINGS
  if (for_user) {
  if (codec->update_thread_context_for_user)
  err = codec->update_thread_context_for_user(dst, src);
+
+av_frame_side_data_free(&dst->decoded_side_data, 
&dst->nb_decoded_side_data);
+for (int i = 0; i < src->nb_decoded_side_data; i++) {
+int ret = av_frame_side_data_clone(&dst->decoded_side_data,
+   &dst->nb_decoded_side_data,
+   src->decoded_side_data[i], 0);
+if (ret < 0)
+return ret;
+}


Seems wasteful to do this for every frame, when it only needs to be done
once. Is there a reason not to put this code in init_thread()?


Hadn't thought about it. Will try that.
___
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] lavc/vvc: Only read split_cu_flag if a split is allowed

2024-04-03 Thread Frank Plowman

On 02/04/2024 22:48, Frank Plowman wrote:

Add a check to ensure some split is possible before reading the
split_cu_flag.  This is present in the spec, in VVCv3 section 7.3.11.4.
Its omission could lead to infinite loops and ultimately crashing due to
stack overflow.
---
  libavcodec/vvc/vvc_ctu.c | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/libavcodec/vvc/vvc_ctu.c b/libavcodec/vvc/vvc_ctu.c
index 8ba12c8d9f..32d8bc8f5c 100644
--- a/libavcodec/vvc/vvc_ctu.c
+++ b/libavcodec/vvc/vvc_ctu.c
@@ -2095,6 +2095,7 @@ static int hls_coding_tree(VVCLocalContext *lc,
  const int ch_type   = tree_type_curr == DUAL_TREE_CHROMA;
  int ret;
  VVCAllowedSplit allowed;
+int split_cu_flag;
  
  if (pps->r->pps_cu_qp_delta_enabled_flag && qg_on_y && cb_sub_div <= sh->cu_qp_delta_subdiv) {

  lc->parse.is_cu_qp_delta_coded = 0;
@@ -2109,7 +2110,11 @@ static int hls_coding_tree(VVCLocalContext *lc,
  
  can_split(lc, x0, y0, cb_width, cb_height, mtt_depth, depth_offset, part_idx,

  last_split_mode, tree_type_curr, mode_type_curr, &allowed);
-if (ff_vvc_split_cu_flag(lc, x0, y0, cb_width, cb_height, ch_type, 
&allowed)) {
+if (allowed.btv || allowed.bth || allowed.ttv || allowed.tth || allowed.qt)
+split_cu_flag = ff_vvc_split_cu_flag(lc, x0, y0, cb_width, cb_height, 
ch_type, &allowed);
+else
+split_cu_flag = 0;
+if (split_cu_flag) {
  VVCSplitMode split  = ff_vvc_split_mode(lc, x0, y0, cb_width, 
cb_height, cqt_depth, mtt_depth, ch_type, &allowed);
  VVCModeType mode_type   = mode_type_decode(lc, x0, y0, cb_width, 
cb_height, split, ch_type, mode_type_curr);
  


Retracting this patch as I missed that this logic is in fact 
implemented, just elsewhere.  There is still a bug here, but it seems 
the condition to trigger it is more complex that I thought.  Should have 
an alternative patch soon.

___
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/httpauth: add SHA-256 Digest Authorization (Combined)

2024-04-03 Thread 정지우 | Eugene
- add SHA-256 Digest Authorization for RFC7616 using avutil/hash.h
- make_digest_auth_sha() : A1hash-> a1_hash and A2hash -> a2_hash
- combine with lint fix patch 
(Please ignore previous patch requests that were requested by mistake): 
[FFmpeg-devel] [PATCH] fix typo(1),style(1),nit(4) issue

Signed-off-by: Eugene-bitsensing 
---
 libavformat/httpauth.c| 130 +-
 libavformat/httpauth.h|   8 +
 ...h-add-SHA-256-Digest-Authorization-Com.eml | 224 ++
 3 files changed, 354 insertions(+), 8 deletions(-)
 create mode 100644 
outputfolder/0001-avformat-httpauth-add-SHA-256-Digest-Authorization-Com.eml

diff --git a/libavformat/httpauth.c b/libavformat/httpauth.c
index 9780928357..6069523bca 100644
--- a/libavformat/httpauth.c
+++ b/libavformat/httpauth.c
@@ -25,6 +25,7 @@
 #include "internal.h"
 #include "libavutil/random_seed.h"
 #include "libavutil/md5.h"
+#include "libavutil/hash.h"
 #include "urldecode.h"
 
 static void handle_basic_params(HTTPAuthState *state, const char *key,
@@ -143,7 +144,7 @@ static char *make_digest_auth(HTTPAuthState *state, const 
char *username,
 char cnonce[17];
 char nc[9];
 int i;
-char A1hash[33], A2hash[33], response[33];
+char a1_hash[33], a2_hash[33], response[33];
 struct AVMD5 *md5ctx;
 uint8_t hash[16];
 char *authstr;
@@ -163,14 +164,14 @@ static char *make_digest_auth(HTTPAuthState *state, const 
char *username,
 av_md5_init(md5ctx);
 update_md5_strings(md5ctx, username, ":", state->realm, ":", password, 
NULL);
 av_md5_final(md5ctx, hash);
-ff_data_to_hex(A1hash, hash, 16, 1);
+ff_data_to_hex(a1_hash, hash, 16, 1);
 
 if (!strcmp(digest->algorithm, "") || !strcmp(digest->algorithm, "MD5")) {
 } else if (!strcmp(digest->algorithm, "MD5-sess")) {
 av_md5_init(md5ctx);
-update_md5_strings(md5ctx, A1hash, ":", digest->nonce, ":", cnonce, 
NULL);
+update_md5_strings(md5ctx, a1_hash, ":", digest->nonce, ":", cnonce, 
NULL);
 av_md5_final(md5ctx, hash);
-ff_data_to_hex(A1hash, hash, 16, 1);
+ff_data_to_hex(a1_hash, hash, 16, 1);
 } else {
 /* Unsupported algorithm */
 av_free(md5ctx);
@@ -180,14 +181,14 @@ static char *make_digest_auth(HTTPAuthState *state, const 
char *username,
 av_md5_init(md5ctx);
 update_md5_strings(md5ctx, method, ":", uri, NULL);
 av_md5_final(md5ctx, hash);
-ff_data_to_hex(A2hash, hash, 16, 1);
+ff_data_to_hex(a2_hash, hash, 16, 1);
 
 av_md5_init(md5ctx);
-update_md5_strings(md5ctx, A1hash, ":", digest->nonce, NULL);
+update_md5_strings(md5ctx, a1_hash, ":", digest->nonce, NULL);
 if (!strcmp(digest->qop, "auth") || !strcmp(digest->qop, "auth-int")) {
 update_md5_strings(md5ctx, ":", nc, ":", cnonce, ":", digest->qop, 
NULL);
 }
-update_md5_strings(md5ctx, ":", A2hash, NULL);
+update_md5_strings(md5ctx, ":", a2_hash, NULL);
 av_md5_final(md5ctx, hash);
 ff_data_to_hex(response, hash, 16, 1);
 
@@ -236,6 +237,114 @@ static char *make_digest_auth(HTTPAuthState *state, const 
char *username,
 return authstr;
 }
 
+/**
+ * Generate a digest reply SHA-256, according to RFC 7616.
+ * TODO : support other RFC 7616 Algorithm 
+ */
+static char *make_digest_auth_sha(HTTPAuthState *state, const char *username,
+  const char *password, const char *uri,
+  const char *method, const char *algorithm)
+{
+DigestParams *digest = &state->digest_params;
+int len;
+uint32_t cnonce_buf[2];
+char cnonce[17];
+char nc[9];
+int i;
+char a1_hash[65], a2_hash[65], response[65];
+struct AVHashContext *hashctx;
+uint8_t hash[64];
+char *authstr;
+
+digest->nc++;
+snprintf(nc, sizeof(nc), "%08x", digest->nc);
+
+/* Generate a client nonce. */
+for (i = 0; i < 2; i++)
+cnonce_buf[i] = av_get_random_seed();
+ff_data_to_hex(cnonce, (const uint8_t *)cnonce_buf, sizeof(cnonce_buf), 1);
+
+/* Allocate a hash context based on the provided algorithm */
+int ret = av_hash_alloc(&hashctx, algorithm);
+if (ret < 0) {
+return NULL;
+}
+
+/* Initialize the hash context */
+av_hash_init(hashctx);
+
+/* Update the hash context with A1 data */
+av_hash_update(hashctx, (const uint8_t *)username, strlen(username));
+av_hash_update(hashctx, (const uint8_t *)":", 1);
+av_hash_update(hashctx, (const uint8_t *)state->realm, 
strlen(state->realm));
+av_hash_update(hashctx, (const uint8_t *)":", 1);
+av_hash_update(hashctx, (const uint8_t *)password, strlen(password));
+av_hash_final(hashctx, hash);
+ff_data_to_hex(a1_hash, hash, av_hash_get_size(hashctx), 1);
+
+/* Initialize the hash context for A2 */
+av_hash_init(hashctx);
+av_hash_update(hashctx, (const uint8_t *)method, strlen(method));
+av_hash_update(hashctx, (const uint8_t 

Re: [FFmpeg-devel] [PATCH] fix typo(1),style(1),nit(4) issue

2024-04-03 Thread Hendrik Leppkes
On Wed, Apr 3, 2024 at 10:50 AM 정지우 | Eugene  wrote:
>
> - typo(1) : Line 242 : RFIC7616 ->RFC7616
> - style(1) : make_digest_auth() , make_digest_auth_sha() : A1hash-> a1_hash 
> and A2hash -> a2_hash
> - nit(3) : httpauth.c: Line 245,265,389:
> - nit(1) : httpauth.h: Line 85
>
> Signed-off-by: Eugene-bitsensing 
>
> @@ -386,7 +386,7 @@ char *ff_http_auth_create_response(HTTPAuthState *state, 
> const char *auth,
>  if ((password = strchr(username, ':'))) {
>  *password++ = 0;
>  /* add digest algorithm SHA-256 */
> -if (!strcmp(state->digest_params.algorithm, "SHA-256")) {
> +if (!strcmp(state->digest_params.algorithm, "SHA256")) {

This is not a "nit", "SHA-256" with a dash is how RFC 7616 specifies
the algorithm token to be spelled.

>  authstr = make_digest_auth_sha(state, username, password, 
> path, method,"SHA256");
>  } else {
>  authstr = make_digest_auth(state, username, password, path, 
> method);

- Hendrik
___
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/hevc_ps: fix the problem of memcmp losing effectiveness

2024-04-03 Thread Anton Khirnov
Quoting Andreas Rheinhardt (2024-03-29 16:58:48)
> This does not change that I consider it crazy to remove the parameter
> sets referencing a parameter set that is removed.

What's crazy about it? A PPS is parsed for a given SPS. If the SPS is
gone, then the PPS must be either removed or re-parsed with the new SPS.
The latter would be far more complex and AFAIK is not actually needed
for anything.

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

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


[FFmpeg-devel] [PATCH] fix typo(1),style(1),nit(4) issue

2024-04-03 Thread 정지우 | Eugene
- typo(1) : Line 242 : RFIC7616 ->RFC7616
- style(1) : make_digest_auth() , make_digest_auth_sha() : A1hash-> a1_hash and 
A2hash -> a2_hash
- nit(3) : httpauth.c: Line 245,265,389:
- nit(1) : httpauth.h: Line 85

Signed-off-by: Eugene-bitsensing 
---
 libavformat/httpauth.c | 34 +-
 libavformat/httpauth.h |  4 ++--
 2 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/libavformat/httpauth.c b/libavformat/httpauth.c
index 8391b6f32f..6069523bca 100644
--- a/libavformat/httpauth.c
+++ b/libavformat/httpauth.c
@@ -144,7 +144,7 @@ static char *make_digest_auth(HTTPAuthState *state, const 
char *username,
 char cnonce[17];
 char nc[9];
 int i;
-char A1hash[33], A2hash[33], response[33];
+char a1_hash[33], a2_hash[33], response[33];
 struct AVMD5 *md5ctx;
 uint8_t hash[16];
 char *authstr;
@@ -164,14 +164,14 @@ static char *make_digest_auth(HTTPAuthState *state, const 
char *username,
 av_md5_init(md5ctx);
 update_md5_strings(md5ctx, username, ":", state->realm, ":", password, 
NULL);
 av_md5_final(md5ctx, hash);
-ff_data_to_hex(A1hash, hash, 16, 1);
+ff_data_to_hex(a1_hash, hash, 16, 1);
 
 if (!strcmp(digest->algorithm, "") || !strcmp(digest->algorithm, "MD5")) {
 } else if (!strcmp(digest->algorithm, "MD5-sess")) {
 av_md5_init(md5ctx);
-update_md5_strings(md5ctx, A1hash, ":", digest->nonce, ":", cnonce, 
NULL);
+update_md5_strings(md5ctx, a1_hash, ":", digest->nonce, ":", cnonce, 
NULL);
 av_md5_final(md5ctx, hash);
-ff_data_to_hex(A1hash, hash, 16, 1);
+ff_data_to_hex(a1_hash, hash, 16, 1);
 } else {
 /* Unsupported algorithm */
 av_free(md5ctx);
@@ -181,14 +181,14 @@ static char *make_digest_auth(HTTPAuthState *state, const 
char *username,
 av_md5_init(md5ctx);
 update_md5_strings(md5ctx, method, ":", uri, NULL);
 av_md5_final(md5ctx, hash);
-ff_data_to_hex(A2hash, hash, 16, 1);
+ff_data_to_hex(a2_hash, hash, 16, 1);
 
 av_md5_init(md5ctx);
-update_md5_strings(md5ctx, A1hash, ":", digest->nonce, NULL);
+update_md5_strings(md5ctx, a1_hash, ":", digest->nonce, NULL);
 if (!strcmp(digest->qop, "auth") || !strcmp(digest->qop, "auth-int")) {
 update_md5_strings(md5ctx, ":", nc, ":", cnonce, ":", digest->qop, 
NULL);
 }
-update_md5_strings(md5ctx, ":", A2hash, NULL);
+update_md5_strings(md5ctx, ":", a2_hash, NULL);
 av_md5_final(md5ctx, hash);
 ff_data_to_hex(response, hash, 16, 1);
 
@@ -239,11 +239,11 @@ static char *make_digest_auth(HTTPAuthState *state, const 
char *username,
 
 /**
  * Generate a digest reply SHA-256, according to RFC 7616.
- * TODO : support other RFIC 7616 Algorithm 
+ * TODO : support other RFC 7616 Algorithm 
  */
 static char *make_digest_auth_sha(HTTPAuthState *state, const char *username,
-  const char *password, const char *uri,
-  const char *method, const char *algorithm)
+  const char *password, const char *uri,
+  const char *method, const char *algorithm)
 {
 DigestParams *digest = &state->digest_params;
 int len;
@@ -251,7 +251,7 @@ static char *make_digest_auth_sha(HTTPAuthState *state, 
const char *username,
 char cnonce[17];
 char nc[9];
 int i;
-char A1hash[65], A2hash[65], response[65];
+char a1_hash[65], a2_hash[65], response[65];
 struct AVHashContext *hashctx;
 uint8_t hash[64];
 char *authstr;
@@ -262,7 +262,7 @@ static char *make_digest_auth_sha(HTTPAuthState *state, 
const char *username,
 /* Generate a client nonce. */
 for (i = 0; i < 2; i++)
 cnonce_buf[i] = av_get_random_seed();
-ff_data_to_hex(cnonce, (const uint8_t*) cnonce_buf, sizeof(cnonce_buf), 1);
+ff_data_to_hex(cnonce, (const uint8_t *)cnonce_buf, sizeof(cnonce_buf), 1);
 
 /* Allocate a hash context based on the provided algorithm */
 int ret = av_hash_alloc(&hashctx, algorithm);
@@ -280,7 +280,7 @@ static char *make_digest_auth_sha(HTTPAuthState *state, 
const char *username,
 av_hash_update(hashctx, (const uint8_t *)":", 1);
 av_hash_update(hashctx, (const uint8_t *)password, strlen(password));
 av_hash_final(hashctx, hash);
-ff_data_to_hex(A1hash, hash, av_hash_get_size(hashctx), 1);
+ff_data_to_hex(a1_hash, hash, av_hash_get_size(hashctx), 1);
 
 /* Initialize the hash context for A2 */
 av_hash_init(hashctx);
@@ -288,11 +288,11 @@ static char *make_digest_auth_sha(HTTPAuthState *state, 
const char *username,
 av_hash_update(hashctx, (const uint8_t *)":", 1);
 av_hash_update(hashctx, (const uint8_t *)uri, strlen(uri));
 av_hash_final(hashctx, hash);
-ff_data_to_hex(A2hash, hash, av_hash_get_size(hashctx), 1);
+ff_data_to_hex(a2_hash, hash, av_hash_get_size(hashctx), 1);
 
 /* Initialize the hash context for response */
 a

Re: [FFmpeg-devel] [PATCH 01/10] avcodec/libvpxenc: Avoid unused-variable warning if VP9 enc is disabled

2024-04-03 Thread Anton Khirnov
Quoting Andreas Rheinhardt (2024-03-31 07:30:26)
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/libvpxenc.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> index 635cdf7a0e..bcbdc4981e 100644
> --- a/libavcodec/libvpxenc.c
> +++ b/libavcodec/libvpxenc.c
> @@ -49,6 +49,9 @@
>  #include "libavutil/opt.h"
>  #include "libavutil/pixdesc.h"
>  
> +#define IS_VP9(avctx) (CONFIG_LIBVPX_VP9_ENCODER && avctx->codec_id == 
> AV_CODEC_ID_VP9)
> +#define IS_VP8(avctx) (CONFIG_LIBVPX_VP8_ENCODER && avctx->codec_id == 
> AV_CODEC_ID_VP8)
> +
>  /**
>   * Portion of struct vpx_codec_cx_pkt from vpx_encoder.h.
>   * One encoded frame returned from the library.
> @@ -359,8 +362,7 @@ static int frame_data_submit(AVCodecContext *avctx, 
> AVFifo *fifo,
>  FrameData fd = { .pts = frame->pts };
>  int ret;
>  
> -#if CONFIG_LIBVPX_VP9_ENCODER
> -if (avctx->codec_id == AV_CODEC_ID_VP9 &&
> +if (IS_VP9(avctx) &&

Weren't we moving towards getting rid of our dependency on DCE?
I recall some discussions about this in recent years, though I don't
remember if there was a consensus.

-- 
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] avcodec/vvcdec: move vvcdec.{c, h} to the top directory

2024-04-03 Thread Anton Khirnov
Quoting James Almer (2024-04-02 21:28:28)
> On 4/2/2024 4:25 PM, Andreas Rheinhardt wrote:
> > James Almer:
> >> As it's the main file declaring the AVCodec.
> > 
> > And why is that supposed to be an advantage?
> 
> It's not, it's a cosmetic change. Makes it easier to find at least one 
> file containing the core code in the base directory.
> And I'd like to do the same for other big modules with 3+ source files. 
> hevc, h264, vp9, etc.

I dislike this.

Though I would be in favor of removing the vvc prefix from the file
names, as it's redundant with dirname.

-- 
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 7/7 v5] avcodec/hevcdec: export global side data in AVCodecContext

2024-04-03 Thread Anton Khirnov
Quoting James Almer (2024-03-28 17:52:50)
> diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
> index fd356bd190..a693e12670 100644
> --- a/libavcodec/pthread_frame.c
> +++ b/libavcodec/pthread_frame.c
> @@ -334,6 +334,15 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  if (for_user) {
>  if (codec->update_thread_context_for_user)
>  err = codec->update_thread_context_for_user(dst, src);
> +
> +av_frame_side_data_free(&dst->decoded_side_data, 
> &dst->nb_decoded_side_data);
> +for (int i = 0; i < src->nb_decoded_side_data; i++) {
> +int ret = av_frame_side_data_clone(&dst->decoded_side_data,
> +   &dst->nb_decoded_side_data,
> +   src->decoded_side_data[i], 0);
> +if (ret < 0)
> +return ret;
> +}

Seems wasteful to do this for every frame, when it only needs to be done
once. Is there a reason not to put this code in init_thread()?

-- 
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] avformat/mxfdec: Check that edit_unit_byte_count is not negative

2024-04-03 Thread Tomas Härdin
mån 2024-04-01 klockan 18:22 +0200 skrev Marton Balint:
> 
> 
> On Mon, 1 Apr 2024, Michael Niedermayer wrote:
> 
> > Signed-off-by: Michael Niedermayer 
> > ---
> > libavformat/mxfdec.c | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > index e484db052ef..37446963369 100644
> > --- a/libavformat/mxfdec.c
> > +++ b/libavformat/mxfdec.c
> > @@ -1245,9 +1245,13 @@ static int
> > mxf_read_index_entry_array(AVIOContext *pb, MXFIndexTableSegment
> > *seg
> > static int mxf_read_index_table_segment(void *arg, AVIOContext *pb,
> > int tag, int size, UID uid, int64_t klv_offset)
> > {
> >     MXFIndexTableSegment *segment = arg;
> > +    int tmp;
> >     switch(tag) {
> >     case 0x3F05:
> > -    segment->edit_unit_byte_count = avio_rb32(pb);
> 
> Why not simply make segment->edit_unit_byte_count unsigned?

This might run afoul with various calcultions. Speaking of,
mxf_edit_unit_absolute_offset() does not check for multiplication
overflows..

/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".


Re: [FFmpeg-devel] Request: Memory cache to avoid write lags to storage.

2024-04-03 Thread Tomas Härdin
tis 2024-04-02 klockan 16:49 +0900 skrev texrayk-sup--- via ffmpeg-
devel:
> This feature caches data in memory that is scheduled to be written to
> storage.

This list isn't for feature requests.

> When data writing cannot keep up due to storage lag or other reasons,
> The data is cached in ffmpeg memory space up to the memory capacity
> specified by this option.
> Memory Size (M,G, or Specify % of Available capacity)
> eg. If the available capacity is 10GB and specify 80%, up to 8GB will
> be used.

This is the job of your operating system.

/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".


Re: [FFmpeg-devel] [PATCH] doc/developer: (security) researchers should be credited

2024-04-03 Thread Tomas Härdin
ons 2024-04-03 klockan 02:13 +0200 skrev Michael Niedermayer:
> Signed-off-by: Michael Niedermayer 
> ---
>  doc/developer.texi | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/doc/developer.texi b/doc/developer.texi
> index c86bb5820cc..63835dfa06c 100644
> --- a/doc/developer.texi
> +++ b/doc/developer.texi
> @@ -390,6 +390,10 @@ If you apply a patch, send an
>  answer to ffmpeg-devel (or wherever you got the patch from) saying
> that
>  you applied the patch.
>  
> +@subheading Credit any researchers
> +If a commit/patch fixes an issues found by some researcher, always
> credit the
> +researcher in the commit message for finding/reporting the issue.

Sounds reasonable.

/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".


Re: [FFmpeg-devel] [PATCH] [v4] avcodec/vaapi_encode: add customized surface alignment

2024-04-03 Thread Araz
> On Mon, Apr 1, 2024 at 9:33 PM Mark Thompson  wrote:
> It is not necessary to copy exactly the same field layout.
> Are you sure that there is never a meaningful non-power-of-two-bytes case?
> Given that this is defining new public API to libavutil we don't want to
be artificially constrained to precisely what happens to be needed in this
case.
If you think copying the field is not preferred,  any other ways in your
mind? How to use the VA interface to query the surface alignment data?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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