[FFmpeg-devel] [PATCH v12 0/9] DNxUncompressed decoder
This is a reworked 11th version of my DNxUncompressed decoder contribution. I added many new pixel formats and swscale input support variants for all those payload types that do not need any format specific unpacking. Most pixel format variants found in the specification are now supported. Unfortunately I don't have samples to test all of them. At least all export options supported by DaVinci Resolve should work. Combined Components and mixed RGB + Alpha content is still not supported. Please check the code and merge it. Martin Martin Schitter (9): avutil/swscale: add PIX_FMT_YUV444 and input support avutil/swscale: add YUV444_16 and UYVY_16 pixel format and input support avutil/swscale: add YUV444F16 and UYVYF16 pixel format and input support avutil/swscale: add YUV444F32 and UYVYF32 pixel format and input support libavcodec/dnxucdec: DNxUncompressed decoder doc: DNxUncompressed Changelog and doc entries tests: Fate sample tests for DNxUncompressed avformat/mxfdec: Workaround for RGB pc/video level detection. swscale/input: color subsampling input support for RGBF32 Changelog | 2 + doc/general_contents.texi | 1 + libavcodec/Makefile | 1 + libavcodec/allcodecs.c | 1 + libavcodec/dnxucdec.c | 338 +++ libavformat/mxfdec.c| 51 +++- libavutil/pixdesc.c | 153 libavutil/pixfmt.h | 22 ++ libswscale/input.c | 348 libswscale/utils.c | 15 +- tests/Makefile | 1 + tests/fate/dnxuc.mak| 40 tests/ref/fate/dnxuc-cb-rgb-10 | 8 + tests/ref/fate/dnxuc-cb-rgb-12 | 8 + tests/ref/fate/dnxuc-cb-rgb-8 | 8 + tests/ref/fate/dnxuc-cb-rgb-float | 8 + tests/ref/fate/dnxuc-cb-rgb-half| 8 + tests/ref/fate/dnxuc-cb-yuv422-10 | 8 + tests/ref/fate/dnxuc-cb-yuv422-12 | 8 + tests/ref/fate/dnxuc-cb-yuv422-8| 8 + tests/ref/fate/dnxuc-ramp-rgb-10| 8 + tests/ref/fate/dnxuc-ramp-rgb-12| 8 + tests/ref/fate/dnxuc-ramp-rgb-8 | 8 + tests/ref/fate/dnxuc-ramp-rgb-float | 8 + tests/ref/fate/dnxuc-ramp-rgb-half | 8 + tests/ref/fate/dnxuc-ramp-yuv422-10 | 8 + tests/ref/fate/dnxuc-ramp-yuv422-12 | 8 + tests/ref/fate/dnxuc-ramp-yuv422-8 | 8 + tests/ref/fate/imgutils | 26 +++ tests/ref/fate/mxf-probe-j2k| 2 +- tests/ref/fate/sws-pixdesc-query| 40 31 files changed, 1157 insertions(+), 12 deletions(-) create mode 100644 libavcodec/dnxucdec.c create mode 100644 tests/fate/dnxuc.mak create mode 100644 tests/ref/fate/dnxuc-cb-rgb-10 create mode 100644 tests/ref/fate/dnxuc-cb-rgb-12 create mode 100644 tests/ref/fate/dnxuc-cb-rgb-8 create mode 100644 tests/ref/fate/dnxuc-cb-rgb-float create mode 100644 tests/ref/fate/dnxuc-cb-rgb-half create mode 100644 tests/ref/fate/dnxuc-cb-yuv422-10 create mode 100644 tests/ref/fate/dnxuc-cb-yuv422-12 create mode 100644 tests/ref/fate/dnxuc-cb-yuv422-8 create mode 100644 tests/ref/fate/dnxuc-ramp-rgb-10 create mode 100644 tests/ref/fate/dnxuc-ramp-rgb-12 create mode 100644 tests/ref/fate/dnxuc-ramp-rgb-8 create mode 100644 tests/ref/fate/dnxuc-ramp-rgb-float create mode 100644 tests/ref/fate/dnxuc-ramp-rgb-half create mode 100644 tests/ref/fate/dnxuc-ramp-yuv422-10 create mode 100644 tests/ref/fate/dnxuc-ramp-yuv422-12 create mode 100644 tests/ref/fate/dnxuc-ramp-yuv422-8 -- 2.45.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v12 2/9] avutil/swscale: add YUV444_16 and UYVY_16 pixel format and input support
---
libavutil/pixdesc.c | 46
libavutil/pixfmt.h | 8 +++
libswscale/input.c | 90
libswscale/utils.c | 4 ++
tests/ref/fate/imgutils | 8 +++
tests/ref/fate/sws-pixdesc-query | 14 +
6 files changed, 170 insertions(+)
diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index c6a9b85..96b9fbe 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -492,6 +492,29 @@ static const AVPixFmtDescriptor
av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
{ 0, 4, 2, 0, 8 },/* V */
},
},
+[AV_PIX_FMT_UYVY422_16LE] = {
+.name = "uyvy422_16le",
+.nb_components = 3,
+.log2_chroma_w = 1,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 4, 2, 0, 16 },/* Y */
+{ 0, 8, 0, 0, 16 },/* U */
+{ 0, 8, 4, 0, 16 },/* V */
+},
+},
+[AV_PIX_FMT_UYVY422_16BE] = {
+.name = "uyvy422_16be",
+.nb_components = 3,
+.log2_chroma_w = 1,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 4, 2, 0, 16 },/* Y */
+{ 0, 8, 0, 0, 16 },/* U */
+{ 0, 8, 4, 0, 16 },/* V */
+},
+.flags = AV_PIX_FMT_FLAG_BE,
+},
[AV_PIX_FMT_UYYVYY411] = {
.name = "uyyvyy411",
.nb_components = 3,
@@ -1667,6 +1690,29 @@ static const AVPixFmtDescriptor
av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
},
.flags = AV_PIX_FMT_FLAG_BE | AV_PIX_FMT_FLAG_PLANAR,
},
+[AV_PIX_FMT_YUV444_16LE] = {
+.name = "yuv444_16le",
+.nb_components = 3,
+.log2_chroma_w = 0,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 6, 0, 0, 16 },/* Y */
+{ 0, 6, 2, 0, 16 },/* U */
+{ 0, 6, 4, 0, 16 },/* V */
+},
+},
+[AV_PIX_FMT_YUV444_16BE] = {
+.name = "yuv444_16be",
+.nb_components = 3,
+.log2_chroma_w = 0,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 6, 0, 0, 16 },/* Y */
+{ 0, 6, 2, 0, 16 },/* U */
+{ 0, 6, 4, 0, 16 },/* V */
+},
+.flags = AV_PIX_FMT_FLAG_BE,
+},
[AV_PIX_FMT_YUV444P10LE] = {
.name = "yuv444p10le",
.nb_components = 3,
diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index 0c7f909..fde8dbb 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -458,6 +458,11 @@ enum AVPixelFormat {
AV_PIX_FMT_RGB96LE, ///< packed RGBA 32:32:32, 96bpp, RGBRGB...,
little-endian
AV_PIX_FMT_YUV444, ///< packed YUV 4:4:4, 24bpp (1 Cr & Cb sample per
1x1 Y), YUVYUV...
+AV_PIX_FMT_YUV444_16BE, ///< packed YUV 4:4:4, 48bpp (1 Cr & Cb sample
per 1x1 Y), YUVYUV..., big-endian
+AV_PIX_FMT_YUV444_16LE, ///< packed YUV 4:4:4, 48bpp (1 Cr & Cb sample
per 1x1 Y), YUVYUV..., little-endian
+
+AV_PIX_FMT_UYVY422_16BE, ///< packed UYVU 4:2:2, 32bpp, Cb Y0 Cr Y1,
big-endian
+AV_PIX_FMT_UYVY422_16LE, ///< packed UYVU 4:2:2, 32bpp, Cb Y0 Cr Y1,
little-endian
AV_PIX_FMT_NB ///< number of pixel formats, DO NOT USE THIS if you
want to link with shared libav* because the number of formats might differ
between versions
};
@@ -509,6 +514,7 @@ enum AVPixelFormat {
#define AV_PIX_FMT_YUV420P16 AV_PIX_FMT_NE(YUV420P16BE, YUV420P16LE)
#define AV_PIX_FMT_YUV422P16 AV_PIX_FMT_NE(YUV422P16BE, YUV422P16LE)
#define AV_PIX_FMT_YUV444P16 AV_PIX_FMT_NE(YUV444P16BE, YUV444P16LE)
+#define AV_PIX_FMT_YUV444_16 AV_PIX_FMT_NE(YUV444_16BE, YUV444_16LE)
#define AV_PIX_FMT_GBRP9 AV_PIX_FMT_NE(GBRP9BE ,GBRP9LE)
#define AV_PIX_FMT_GBRP10AV_PIX_FMT_NE(GBRP10BE,GBRP10LE)
@@ -542,6 +548,8 @@ enum AVPixelFormat {
#define AV_PIX_FMT_YUVA422P16 AV_PIX_FMT_NE(YUVA422P16BE, YUVA422P16LE)
#define AV_PIX_FMT_YUVA444P16 AV_PIX_FMT_NE(YUVA444P16BE, YUVA444P16LE)
+#define AV_PIX_FMT_UYVY422_16 AV_PIX_FMT_NE(UYVY422_16BE, UYVY422_16LE)
+
#define AV_PIX_FMT_XYZ12 AV_PIX_FMT_NE(XYZ12BE, XYZ12LE)
#define AV_PIX_FMT_NV20 AV_PIX_FMT_NE(NV20BE, NV20LE)
#define AV_PIX_FMT_AYUV64 AV_PIX_FMT_NE(AYUV64BE, AYUV64LE)
diff --git a/libswscale/input.c b/libswscale/input.c
index 79376b9..e23b59e 100644
--- a/libswscale/input.c
+++ b/libswscale/input.c
@@ -805,6 +805,39 @@ static void vyuToUV_c(uint8_t *dstU, uint8_t *dstV, const
uint8_t *unused0, cons
}
}
+static void read_yuv444_16le_Y_c(uint8_t *dst, const uint8_t *src, const
uint8_t *unused0,
+ const uint8_t *unused1, int width, uint32_t
*unused2, void *opq)
+{
+int i;
+for (i = 0; i < width; i++)
+AV_WN16(dst + i * 2, AV_RL16(src + i * 6));
+}
+
+static void read_yuv444_16le_UV_c(uint8_t *dstU, uint8_t *dstV, const uint8_t
*unused0, const uint8_t *src,
+ const uint8_t *
[FFmpeg-devel] [PATCH v12 1/9] avutil/swscale: add PIX_FMT_YUV444 and input support
---
libavutil/pixdesc.c | 11 +++
libavutil/pixfmt.h | 2 ++
libswscale/input.c | 22 ++
libswscale/utils.c | 1 +
tests/ref/fate/imgutils | 2 ++
tests/ref/fate/sws-pixdesc-query | 2 ++
6 files changed, 40 insertions(+)
diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index e15105e..c6a9b85 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -346,6 +346,17 @@ static const AVPixFmtDescriptor
av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
},
.flags = AV_PIX_FMT_FLAG_PLANAR,
},
+[AV_PIX_FMT_YUV444] = {
+.name = "yuv444",
+.nb_components = 3,
+.log2_chroma_w = 0,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 3, 0, 0, 8 },/* Y */
+{ 0, 3, 1, 0, 8 },/* U */
+{ 0, 3, 2, 0, 8 },/* V */
+},
+},
[AV_PIX_FMT_YUV444P] = {
.name = "yuv444p",
.nb_components = 3,
diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index 0dc4abc..0c7f909 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -457,6 +457,8 @@ enum AVPixelFormat {
AV_PIX_FMT_RGB96BE, ///< packed RGBA 32:32:32, 96bpp, RGBRGB...,
big-endian
AV_PIX_FMT_RGB96LE, ///< packed RGBA 32:32:32, 96bpp, RGBRGB...,
little-endian
+AV_PIX_FMT_YUV444, ///< packed YUV 4:4:4, 24bpp (1 Cr & Cb sample per
1x1 Y), YUVYUV...
+
AV_PIX_FMT_NB ///< number of pixel formats, DO NOT USE THIS if you
want to link with shared libav* because the number of formats might differ
between versions
};
diff --git a/libswscale/input.c b/libswscale/input.c
index bb5e31a..79376b9 100644
--- a/libswscale/input.c
+++ b/libswscale/input.c
@@ -771,6 +771,22 @@ static void read_uyva_UV_c(uint8_t *dstU, uint8_t *dstV,
const uint8_t *unused0,
}
}
+static void yuv444ToY_c(uint8_t *dst, const uint8_t *src, const uint8_t
*unused0, const uint8_t *unused1, int width,
+ uint32_t *unused2, void *opq)
+{
+for (int i = 0; i < width; i++)
+dst[i] = src[i * 3];
+}
+
+static void yuv444ToUV_c(uint8_t *dstU, uint8_t *dstV, const uint8_t *unused0,
const uint8_t *src,
+ const uint8_t *unused1, int width, uint32_t *unused2,
void *opq)
+{
+for (int i = 0; i < width; i++) {
+dstU[i] = src[i * 3 + 1];
+dstV[i] = src[i * 3 + 2];
+}
+}
+
static void vyuToY_c(uint8_t *dst, const uint8_t *src, const uint8_t *unused0,
const uint8_t *unused1, int width,
uint32_t *unused2, void *opq)
{
@@ -1562,6 +1578,9 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c,
case AV_PIX_FMT_VYU444:
*chrToYV12 = vyuToUV_c;
break;
+case AV_PIX_FMT_YUV444:
+*chrToYV12 = yuv444ToUV_c;
+break;
case AV_PIX_FMT_NV12:
case AV_PIX_FMT_NV16:
case AV_PIX_FMT_NV24:
@@ -2164,6 +2183,9 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c,
case AV_PIX_FMT_VYU444:
*lumToYV12 = vyuToY_c;
break;
+case AV_PIX_FMT_YUV444:
+*lumToYV12 = yuv444ToY_c;
+break;
case AV_PIX_FMT_BGR24:
*lumToYV12 = bgr24ToY_c;
break;
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 9b23df4..36d9738 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -73,6 +73,7 @@ static const FormatEntry format_entries[] = {
[AV_PIX_FMT_BGR24] = { 1, 1 },
[AV_PIX_FMT_YUV422P] = { 1, 1 },
[AV_PIX_FMT_YUV444P] = { 1, 1 },
+[AV_PIX_FMT_YUV444] = { 1, 0 },
[AV_PIX_FMT_YUV410P] = { 1, 1 },
[AV_PIX_FMT_YUV411P] = { 1, 1 },
[AV_PIX_FMT_GRAY8] = { 1, 1 },
diff --git a/tests/ref/fate/imgutils b/tests/ref/fate/imgutils
index 8639baa..62a52be 100644
--- a/tests/ref/fate/imgutils
+++ b/tests/ref/fate/imgutils
@@ -280,6 +280,7 @@ rgba128be planes: 1, linesizes: 1024 0 0 0,
plane_sizes: 49152 0
rgba128le planes: 1, linesizes: 1024 0 0 0, plane_sizes: 49152
0 0 0, plane_offsets: 0 0 0, total_size: 49152
rgb96be planes: 1, linesizes: 768 0 0 0, plane_sizes: 36864
0 0 0, plane_offsets: 0 0 0, total_size: 36864
rgb96le planes: 1, linesizes: 768 0 0 0, plane_sizes: 36864
0 0 0, plane_offsets: 0 0 0, total_size: 36864
+yuv444 planes: 1, linesizes: 192 0 0 0, plane_sizes: 9216
0 0 0, plane_offsets: 0 0 0, total_size: 9216
image_fill_black tests
yuv420p total_size: 4608, black_unknown_crc: 0xd00f6cc6,
black_tv_crc: 0xd00f6cc6, black_pc_crc: 0x234969af
@@ -507,3 +508,4 @@ rgba128be total_size: 49152, black_unknown_crc:
0x59ef499b, black_tv_cr
rgba128le total_size: 49152, black_unknown_crc: 0x59ef499b,
black_tv_crc: 0x59ef499b, black_pc_crc: 0x59ef499b
rgb96be total_size: 36
[FFmpeg-devel] [PATCH v12 3/9] avutil/swscale: add YUV444F16 and UYVYF16 pixel format and input support
---
libavutil/pixdesc.c | 48
libavutil/pixfmt.h | 6 ++
libswscale/input.c | 99
libswscale/utils.c | 4 ++
tests/ref/fate/imgutils | 8 +++
tests/ref/fate/sws-pixdesc-query | 14 +
6 files changed, 179 insertions(+)
diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index 96b9fbe..609f07a 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -515,6 +515,30 @@ static const AVPixFmtDescriptor
av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
},
.flags = AV_PIX_FMT_FLAG_BE,
},
+[AV_PIX_FMT_UYVY422F16LE] = {
+.name = "uyvy422f16le",
+.nb_components = 3,
+.log2_chroma_w = 1,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 4, 2, 0, 16 },/* Y */
+{ 0, 8, 0, 0, 16 },/* U */
+{ 0, 8, 4, 0, 16 },/* V */
+},
+.flags = AV_PIX_FMT_FLAG_FLOAT,
+},
+[AV_PIX_FMT_UYVY422F16BE] = {
+.name = "uyvy422f16be",
+.nb_components = 3,
+.log2_chroma_w = 1,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 4, 2, 0, 16 },/* Y */
+{ 0, 8, 0, 0, 16 },/* U */
+{ 0, 8, 4, 0, 16 },/* V */
+},
+.flags = AV_PIX_FMT_FLAG_BE | AV_PIX_FMT_FLAG_FLOAT,
+},
[AV_PIX_FMT_UYYVYY411] = {
.name = "uyyvyy411",
.nb_components = 3,
@@ -1713,6 +1737,30 @@ static const AVPixFmtDescriptor
av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
},
.flags = AV_PIX_FMT_FLAG_BE,
},
+[AV_PIX_FMT_YUV444F16LE] = {
+.name = "yuv444f16le",
+.nb_components = 3,
+.log2_chroma_w = 0,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 6, 0, 0, 16 },/* Y */
+{ 0, 6, 2, 0, 16 },/* U */
+{ 0, 6, 4, 0, 16 },/* V */
+},
+.flags = AV_PIX_FMT_FLAG_FLOAT,
+},
+[AV_PIX_FMT_YUV444F16BE] = {
+.name = "yuv444f16be",
+.nb_components = 3,
+.log2_chroma_w = 0,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 6, 0, 0, 16 },/* Y */
+{ 0, 6, 2, 0, 16 },/* U */
+{ 0, 6, 4, 0, 16 },/* V */
+},
+.flags = AV_PIX_FMT_FLAG_BE | AV_PIX_FMT_FLAG_FLOAT,
+},
[AV_PIX_FMT_YUV444P10LE] = {
.name = "yuv444p10le",
.nb_components = 3,
diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index fde8dbb..67f568f 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -460,9 +460,13 @@ enum AVPixelFormat {
AV_PIX_FMT_YUV444, ///< packed YUV 4:4:4, 24bpp (1 Cr & Cb sample per
1x1 Y), YUVYUV...
AV_PIX_FMT_YUV444_16BE, ///< packed YUV 4:4:4, 48bpp (1 Cr & Cb sample
per 1x1 Y), YUVYUV..., big-endian
AV_PIX_FMT_YUV444_16LE, ///< packed YUV 4:4:4, 48bpp (1 Cr & Cb sample
per 1x1 Y), YUVYUV..., little-endian
+AV_PIX_FMT_YUV444F16BE, ///< IEEE-754 half precision packed YUV 4:4:4,
48bpp (1 Cr & Cb sample per 1x1 Y), YUVYUV..., big-endian
+AV_PIX_FMT_YUV444F16LE, ///< IEEE-754 half precision packed YUV 4:4:4,
48bpp (1 Cr & Cb sample per 1x1 Y), YUVYUV..., little-endian
AV_PIX_FMT_UYVY422_16BE, ///< packed UYVU 4:2:2, 32bpp, Cb Y0 Cr Y1,
big-endian
AV_PIX_FMT_UYVY422_16LE, ///< packed UYVU 4:2:2, 32bpp, Cb Y0 Cr Y1,
little-endian
+AV_PIX_FMT_UYVY422F16BE, ///< IEEE-754 half precision packed UYVU 4:2:2,
32bpp, Cb Y0 Cr Y1, big-endian
+AV_PIX_FMT_UYVY422F16LE, ///< IEEE-754 half precision packed UYVU 4:2:2,
32bpp, Cb Y0 Cr Y1, little-endian
AV_PIX_FMT_NB ///< number of pixel formats, DO NOT USE THIS if you
want to link with shared libav* because the number of formats might differ
between versions
};
@@ -515,6 +519,7 @@ enum AVPixelFormat {
#define AV_PIX_FMT_YUV422P16 AV_PIX_FMT_NE(YUV422P16BE, YUV422P16LE)
#define AV_PIX_FMT_YUV444P16 AV_PIX_FMT_NE(YUV444P16BE, YUV444P16LE)
#define AV_PIX_FMT_YUV444_16 AV_PIX_FMT_NE(YUV444_16BE, YUV444_16LE)
+#define AV_PIX_FMT_YUV444F16 AV_PIX_FMT_NE(YUV444F16BE, YUV444F16LE)
#define AV_PIX_FMT_GBRP9 AV_PIX_FMT_NE(GBRP9BE ,GBRP9LE)
#define AV_PIX_FMT_GBRP10AV_PIX_FMT_NE(GBRP10BE,GBRP10LE)
@@ -549,6 +554,7 @@ enum AVPixelFormat {
#define AV_PIX_FMT_YUVA444P16 AV_PIX_FMT_NE(YUVA444P16BE, YUVA444P16LE)
#define AV_PIX_FMT_UYVY422_16 AV_PIX_FMT_NE(UYVY422_16BE, UYVY422_16LE)
+#define AV_PIX_FMT_UYVY422F16 AV_PIX_FMT_NE(UYVY422F16BE, UYVY422F16LE)
#define AV_PIX_FMT_XYZ12 AV_PIX_FMT_NE(XYZ12BE, XYZ12LE)
#define AV_PIX_FMT_NV20 AV_PIX_FMT_NE(NV20BE, NV20LE)
diff --git a/libswscale/input.c b/libswscale/input.c
index e23b59e..685b2ea 100644
--- a/libswscale/input.c
+++ b/libswscale/input.c
@@ -838,6 +838,44 @@ static void read_yuv444_16be_UV_c(uint8_t *dstU, uint8_t
*dstV, const uint8_t *u
}
}
+static void read_yuv4
[FFmpeg-devel] [PATCH v12 4/9] avutil/swscale: add YUV444F32 and UYVYF32 pixel format and input support
---
libavutil/pixdesc.c | 48 +++
libavutil/pixfmt.h | 6 ++
libswscale/input.c | 100 +++
libswscale/utils.c | 6 +-
tests/ref/fate/imgutils | 8 +++
tests/ref/fate/sws-pixdesc-query | 10
6 files changed, 177 insertions(+), 1 deletion(-)
diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index 609f07a..f69c9b2 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -539,6 +539,30 @@ static const AVPixFmtDescriptor
av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
},
.flags = AV_PIX_FMT_FLAG_BE | AV_PIX_FMT_FLAG_FLOAT,
},
+[AV_PIX_FMT_UYVY422F32LE] = {
+.name = "uyvy422f32le",
+.nb_components = 3,
+.log2_chroma_w = 1,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 8, 4, 0, 32 },/* Y */
+{ 0, 16, 0, 0, 32 },/* U */
+{ 0, 16, 8, 0, 32 },/* V */
+},
+.flags = AV_PIX_FMT_FLAG_FLOAT,
+},
+[AV_PIX_FMT_UYVY422F32BE] = {
+.name = "uyvy422f32be",
+.nb_components = 3,
+.log2_chroma_w = 1,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 8, 4, 0, 32 },/* Y */
+{ 0, 16, 0, 0, 32 },/* U */
+{ 0, 16, 8, 0, 32 },/* V */
+},
+.flags = AV_PIX_FMT_FLAG_BE | AV_PIX_FMT_FLAG_FLOAT,
+},
[AV_PIX_FMT_UYYVYY411] = {
.name = "uyyvyy411",
.nb_components = 3,
@@ -1761,6 +1785,30 @@ static const AVPixFmtDescriptor
av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
},
.flags = AV_PIX_FMT_FLAG_BE | AV_PIX_FMT_FLAG_FLOAT,
},
+[AV_PIX_FMT_YUV444F32LE] = {
+.name = "yuv444f32le",
+.nb_components = 3,
+.log2_chroma_w = 0,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 12, 0, 0, 32 },/* Y */
+{ 0, 12, 4, 0, 32 },/* U */
+{ 0, 12, 8, 0, 32 },/* V */
+},
+.flags = AV_PIX_FMT_FLAG_FLOAT,
+},
+[AV_PIX_FMT_YUV444F32BE] = {
+.name = "yuv444f32be",
+.nb_components = 3,
+.log2_chroma_w = 0,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 12, 0, 0, 32 },/* Y */
+{ 0, 12, 4, 0, 32 },/* U */
+{ 0, 12, 8, 0, 32 },/* V */
+},
+.flags = AV_PIX_FMT_FLAG_BE | AV_PIX_FMT_FLAG_FLOAT,
+},
[AV_PIX_FMT_YUV444P10LE] = {
.name = "yuv444p10le",
.nb_components = 3,
diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index 67f568f..b946b8d 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -462,11 +462,15 @@ enum AVPixelFormat {
AV_PIX_FMT_YUV444_16LE, ///< packed YUV 4:4:4, 48bpp (1 Cr & Cb sample
per 1x1 Y), YUVYUV..., little-endian
AV_PIX_FMT_YUV444F16BE, ///< IEEE-754 half precision packed YUV 4:4:4,
48bpp (1 Cr & Cb sample per 1x1 Y), YUVYUV..., big-endian
AV_PIX_FMT_YUV444F16LE, ///< IEEE-754 half precision packed YUV 4:4:4,
48bpp (1 Cr & Cb sample per 1x1 Y), YUVYUV..., little-endian
+AV_PIX_FMT_YUV444F32BE, ///< IEEE-754 single precision packed YUV 4:4:4,
96bpp (1 Cr & Cb sample per 1x1 Y), YUVYUV..., big-endian
+AV_PIX_FMT_YUV444F32LE, ///< IEEE-754 single precision packed YUV 4:4:4,
96bpp (1 Cr & Cb sample per 1x1 Y), YUVYUV..., little-endian
AV_PIX_FMT_UYVY422_16BE, ///< packed UYVU 4:2:2, 32bpp, Cb Y0 Cr Y1,
big-endian
AV_PIX_FMT_UYVY422_16LE, ///< packed UYVU 4:2:2, 32bpp, Cb Y0 Cr Y1,
little-endian
AV_PIX_FMT_UYVY422F16BE, ///< IEEE-754 half precision packed UYVU 4:2:2,
32bpp, Cb Y0 Cr Y1, big-endian
AV_PIX_FMT_UYVY422F16LE, ///< IEEE-754 half precision packed UYVU 4:2:2,
32bpp, Cb Y0 Cr Y1, little-endian
+AV_PIX_FMT_UYVY422F32BE, ///< IEEE-754 single precision packed UYVU 4:2:2,
64bpp, Cb Y0 Cr Y1, big-endian
+AV_PIX_FMT_UYVY422F32LE, ///< IEEE-754 single precision packed UYVU 4:2:2,
64bpp, Cb Y0 Cr Y1, little-endian
AV_PIX_FMT_NB ///< number of pixel formats, DO NOT USE THIS if you
want to link with shared libav* because the number of formats might differ
between versions
};
@@ -520,6 +524,7 @@ enum AVPixelFormat {
#define AV_PIX_FMT_YUV444P16 AV_PIX_FMT_NE(YUV444P16BE, YUV444P16LE)
#define AV_PIX_FMT_YUV444_16 AV_PIX_FMT_NE(YUV444_16BE, YUV444_16LE)
#define AV_PIX_FMT_YUV444F16 AV_PIX_FMT_NE(YUV444F16BE, YUV444F16LE)
+#define AV_PIX_FMT_YUV444F32 AV_PIX_FMT_NE(YUV444F32BE, YUV444F32LE)
#define AV_PIX_FMT_GBRP9 AV_PIX_FMT_NE(GBRP9BE ,GBRP9LE)
#define AV_PIX_FMT_GBRP10AV_PIX_FMT_NE(GBRP10BE,GBRP10LE)
@@ -555,6 +560,7 @@ enum AVPixelFormat {
#define AV_PIX_FMT_UYVY422_16 AV_PIX_FMT_NE(UYVY422_16BE, UYVY422_16LE)
#define AV_PIX_FMT_UYVY422F16 AV_PIX_FMT_NE(UYVY422F16BE, UYVY422F16LE)
+#define AV_PIX_FMT_UYVY422F32 AV_PIX_FMT_NE(UYVY422F32BE, UYVY422F32LE)
#define AV_PIX_FMT_X
[FFmpeg-devel] [PATCH v12 6/9] doc: DNxUncompressed Changelog and doc entries
--- Changelog | 2 ++ doc/general_contents.texi | 1 + 2 files changed, 3 insertions(+) diff --git a/Changelog b/Changelog index 7963e09..75b8e15 100644 --- a/Changelog +++ b/Changelog @@ -3,6 +3,8 @@ releases are sorted from youngest to oldest. version : - yasm support dropped, users need to use nasm +- DNxUncompressed (SMPTE RDD 50) decoder + version 7.1: - Raw Captions with Time (RCWT) closed caption demuxer diff --git a/doc/general_contents.texi b/doc/general_contents.texi index 5980ac6..76e1d34 100644 --- a/doc/general_contents.texi +++ b/doc/general_contents.texi @@ -632,6 +632,7 @@ library: @item raw DFPWM @tab X @tab X @item raw Dirac @tab X @tab X @item raw DNxHD @tab X @tab X +@item raw DNxUncompressed @tab @tab X @item raw DTS @tab X @tab X @item raw DTS-HD@tab @tab X @item raw E-AC-3@tab X @tab X -- 2.45.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v12 8/9] avformat/mxfdec: Workaround for RGB pc/video level detection.
In case of RGB content wrapped in MXF containers we can not use
CDCIDescriptor fields for the video level detection.
The corresponding information in RGBA Descriptors uses a significant
differnt structure. As a workaround we pick the first found channel
depth info value of the RGBALayout array and us it instead of the
more general CDCI component_depth.
---
libavformat/mxfdec.c | 51 +---
tests/ref/fate/mxf-probe-j2k | 2 +-
2 files changed, 42 insertions(+), 11 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 27e8e0c..eb51585 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -212,6 +212,9 @@ typedef struct MXFDescriptor {
unsigned int component_depth;
unsigned int black_ref_level;
unsigned int white_ref_level;
+uint32_t component_max_ref;
+uint32_t component_min_ref;
+uint8_t red_component_depth;
unsigned int color_range;
unsigned int horiz_subsampling;
unsigned int vert_subsampling;
@@ -1316,6 +1319,9 @@ static void mxf_read_pixel_layout(AVIOContext *pb,
MXFDescriptor *descriptor)
value = avio_r8(pb);
av_log(NULL, AV_LOG_TRACE, "pixel layout: code %#x\n", code);
+if (code == 'R')
+descriptor->red_component_depth = value;
+
if (ofs <= 14) {
layout[ofs++] = code;
layout[ofs++] = value;
@@ -1424,6 +1430,12 @@ static int mxf_read_generic_descriptor(void *arg,
AVIOContext *pb, int tag, int
case 0x3401:
mxf_read_pixel_layout(pb, descriptor);
break;
+case 0x3406:
+descriptor->component_max_ref = avio_rb32(pb);
+break;
+case 0x3407:
+descriptor->component_min_ref = avio_rb32(pb);
+break;
default:
/* Private uid used by SONY C0023S01.mxf */
if (IS_KLV_KEY(uid, mxf_sony_mpeg4_extradata)) {
@@ -2511,19 +2523,38 @@ static int mxf_add_metadata_stream(MXFContext *mxf,
MXFTrack *track)
static enum AVColorRange mxf_get_color_range(MXFContext *mxf, MXFDescriptor
*descriptor)
{
-if (descriptor->black_ref_level || descriptor->white_ref_level ||
descriptor->color_range) {
+unsigned int depth, black_ref_level, white_ref_level;
+
+// The red channel component depth value of the
+// RGBALayout array is used as component_depth indicator
+// for the pc/tv level detection in case of RGB content
+// and their RGBA Descriptors instead of CDCI entries.
+
+if (descriptor->red_component_depth) { // RGBA Descriptor
+depth = descriptor->red_component_depth;
+black_ref_level = descriptor->component_min_ref;
+white_ref_level = descriptor->component_max_ref;
+} else { // CDCI Descriptor
+depth = descriptor->component_depth;
+black_ref_level = descriptor->black_ref_level;
+white_ref_level = descriptor->white_ref_level;
+}
+
+if (black_ref_level || white_ref_level) {
/* CDCI range metadata */
-if (!descriptor->component_depth)
+if (!depth)
return AVCOL_RANGE_UNSPECIFIED;
-if (descriptor->black_ref_level == 0 && descriptor->component_depth <
31 &&
-descriptor->white_ref_level == ((1color_range== (1color_range== ((1red_component_depth ||
+ descriptor->color_range== (1 << descriptor->component_depth)
||
+ descriptor->color_range== ((1 << descriptor->component_depth)
- 1)))
return AVCOL_RANGE_JPEG;
-if (descriptor->component_depth >= 8 && descriptor->component_depth <
31 &&
-descriptor->black_ref_level == (1 <<(descriptor->component_depth
- 4)) &&
-descriptor->white_ref_level == (235<<(descriptor->component_depth
- 8)) &&
-descriptor->color_range == ((14<<(descriptor->component_depth
- 4)) + 1))
+if (depth >= 8 && depth < 31 &&
+black_ref_level == (1 << (depth - 4)) &&
+white_ref_level == (235 << (depth - 8)) &&
+( descriptor->red_component_depth ||
+descriptor->color_range == ((14 <<
(descriptor->component_depth - 4))) + 1))
return AVCOL_RANGE_MPEG;
avpriv_request_sample(mxf->fc, "Unrecognized CDCI color range (color
diff range %d, b %d, w %d, depth %d)",
descriptor->color_range,
descriptor->black_ref_level,
diff --git a/tests/ref/fate/mxf-probe-j2k b/tests/ref/fate/mxf-probe-j2k
index f1dadf4..6287980 100644
--- a/tests/ref/fate/mxf-probe-j2k
+++ b/tests/ref/fate/mxf-probe-j2k
@@ -16,7 +16,7 @@ sample_aspect_ratio=1:1
display_aspect_ratio=16:9
pix_fmt=rgb48
level=-99
-color_range=unknown
+color_range=pc
color_space=unknown
color_t
[FFmpeg-devel] [PATCH v12 5/9] libavcodec/dnxucdec: DNxUncompressed decoder
---
libavcodec/Makefile| 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/dnxucdec.c | 338 +
3 files changed, 340 insertions(+)
create mode 100644 libavcodec/dnxucdec.c
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index dd5d0de..e13b127 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -328,6 +328,7 @@ OBJS-$(CONFIG_DFPWM_DECODER) += dfpwmdec.o
OBJS-$(CONFIG_DFPWM_ENCODER) += dfpwmenc.o
OBJS-$(CONFIG_DNXHD_DECODER) += dnxhddec.o dnxhddata.o
OBJS-$(CONFIG_DNXHD_ENCODER) += dnxhdenc.o dnxhddata.o
+OBJS-$(CONFIG_DNXUC_DECODER) += dnxucdec.o
OBJS-$(CONFIG_DOLBY_E_DECODER) += dolby_e.o dolby_e_parse.o kbdwin.o
OBJS-$(CONFIG_DPX_DECODER) += dpx.o
OBJS-$(CONFIG_DPX_ENCODER) += dpxenc.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index c7e5f99..ccca2ad 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -93,6 +93,7 @@ extern const FFCodec ff_dfa_decoder;
extern const FFCodec ff_dirac_decoder;
extern const FFCodec ff_dnxhd_encoder;
extern const FFCodec ff_dnxhd_decoder;
+extern const FFCodec ff_dnxuc_decoder;
extern const FFCodec ff_dpx_encoder;
extern const FFCodec ff_dpx_decoder;
extern const FFCodec ff_dsicinvideo_decoder;
diff --git a/libavcodec/dnxucdec.c b/libavcodec/dnxucdec.c
new file mode 100644
index 000..9d5847d
--- /dev/null
+++ b/libavcodec/dnxucdec.c
@@ -0,0 +1,338 @@
+/*
+ * Avid DNxUncomressed / SMPTE RDD 50 decoder
+ * Copyright (c) 2024 Martin Schitter
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/*
+ This decoder for DNxUncompressed video data is mostly based on
+ reverse engineering of output generated by DaVinci Resolve 19
+ but was later also checked against the SMPTE RDD 50 specification.
+
+ Not all DNxUncompressed pixel format variants are supported,
+ but at least an elementary base set is already usable:
+
+ - YUV 4:2:2 8/10/12/16bit/half/float (16bit untested)
+YUV 4:4:4 8/16bit/half/float (all untested!)
+ - RGB 8/10/12/16bit/half/float (16bit untested)
+Alpha/Y 8/16bit (all untested!)
+
+TODO: Compositions of multiple components aren't supportet until now.
+TODO: This also hinders Image+Alpha use in one file.
+
+*/
+
+#include "avcodec.h"
+#include "codec_internal.h"
+#include "decode.h"
+#include "libavutil/imgutils.h"
+#include "libavutil/intreadwrite.h"
+#include "thread.h"
+
+static int pass_through(AVCodecContext *avctx, AVFrame *frame, const AVPacket
*avpkt)
+{
+/* there is no need to copy as the data already match
+ * a known pixel format */
+
+frame->buf[0] = av_buffer_ref(avpkt->buf);
+
+if (!frame->buf[0]) {
+return AVERROR(ENOMEM);
+}
+
+return av_image_fill_arrays(frame->data, frame->linesize, avpkt->data,
+ avctx->pix_fmt, avctx->width, avctx->height, 1);
+}
+
+/// Unpack 10bit value
+static av_always_inline
+uint16_t get10(uint8_t *line_data, uint32_t pos, int msb_bytes)
+{
+return (line_data[pos] << 2) |
+((line_data[msb_bytes + (pos >> 2)] >> ((pos & 0x3u) << 1)) & 0x3u);
+}
+
+/// Unpack 12bit value
+static av_always_inline
+uint16_t get12(uint8_t *line_data, uint32_t pos, int msb_bytes)
+{
+return (line_data[pos] << 4) |
+((line_data[msb_bytes + (pos >> 1)] >> ((pos & 0x1u) << 2)) & 0xfu);
+}
+
+static int unpack_rg10(AVCodecContext *avctx, AVFrame *frame, const AVPacket
*pkt)
+{
+uint8_t *data = &pkt->data[0];
+int lw = frame->width;
+int msb_bytes = lw * 3;
+int line_offset = lw * 3 + (lw * 3 + 3) / 4;
+int pos = 0, pos_in = 0;
+for(int y = 0; y < frame->height; y++){
+for(int x = 0; x < lw; x++){
+AV_WL16(&frame->data[2][pos], get10(data, pos_in++, msb_bytes));
// r
+AV_WL16(&frame->data[0][pos], get10(data, pos_in++, msb_bytes));
// g
+AV_WL16(&frame->data[1][pos], get10(data, pos_in++, msb_bytes));
// b
+pos += 2;
+}
+data += line_offset;
+pos_in = 0;
+}
+return pkt->size;
+}
+
+static int unpack_y410(AVCodecContext *avctx, AVFrame *frame, const AVPacket
*pkt)
+{
+uint8_t *data =
[FFmpeg-devel] [PATCH v12 7/9] tests: Fate sample tests for DNxUncompressed
--- tests/Makefile | 1 + tests/fate/dnxuc.mak| 40 + tests/ref/fate/dnxuc-cb-rgb-10 | 8 ++ tests/ref/fate/dnxuc-cb-rgb-12 | 8 ++ tests/ref/fate/dnxuc-cb-rgb-8 | 8 ++ tests/ref/fate/dnxuc-cb-rgb-float | 8 ++ tests/ref/fate/dnxuc-cb-rgb-half| 8 ++ tests/ref/fate/dnxuc-cb-yuv422-10 | 8 ++ tests/ref/fate/dnxuc-cb-yuv422-12 | 8 ++ tests/ref/fate/dnxuc-cb-yuv422-8| 8 ++ tests/ref/fate/dnxuc-ramp-rgb-10| 8 ++ tests/ref/fate/dnxuc-ramp-rgb-12| 8 ++ tests/ref/fate/dnxuc-ramp-rgb-8 | 8 ++ tests/ref/fate/dnxuc-ramp-rgb-float | 8 ++ tests/ref/fate/dnxuc-ramp-rgb-half | 8 ++ tests/ref/fate/dnxuc-ramp-yuv422-10 | 8 ++ tests/ref/fate/dnxuc-ramp-yuv422-12 | 8 ++ tests/ref/fate/dnxuc-ramp-yuv422-8 | 8 ++ 18 files changed, 169 insertions(+) create mode 100644 tests/fate/dnxuc.mak create mode 100644 tests/ref/fate/dnxuc-cb-rgb-10 create mode 100644 tests/ref/fate/dnxuc-cb-rgb-12 create mode 100644 tests/ref/fate/dnxuc-cb-rgb-8 create mode 100644 tests/ref/fate/dnxuc-cb-rgb-float create mode 100644 tests/ref/fate/dnxuc-cb-rgb-half create mode 100644 tests/ref/fate/dnxuc-cb-yuv422-10 create mode 100644 tests/ref/fate/dnxuc-cb-yuv422-12 create mode 100644 tests/ref/fate/dnxuc-cb-yuv422-8 create mode 100644 tests/ref/fate/dnxuc-ramp-rgb-10 create mode 100644 tests/ref/fate/dnxuc-ramp-rgb-12 create mode 100644 tests/ref/fate/dnxuc-ramp-rgb-8 create mode 100644 tests/ref/fate/dnxuc-ramp-rgb-float create mode 100644 tests/ref/fate/dnxuc-ramp-rgb-half create mode 100644 tests/ref/fate/dnxuc-ramp-yuv422-10 create mode 100644 tests/ref/fate/dnxuc-ramp-yuv422-12 create mode 100644 tests/ref/fate/dnxuc-ramp-yuv422-8 diff --git a/tests/Makefile b/tests/Makefile index 9b70145..e073915 100644 --- a/tests/Makefile +++ b/tests/Makefile @@ -172,6 +172,7 @@ include $(SRC_PATH)/tests/fate/dca.mak include $(SRC_PATH)/tests/fate/demux.mak include $(SRC_PATH)/tests/fate/dfa.mak include $(SRC_PATH)/tests/fate/dnxhd.mak +include $(SRC_PATH)/tests/fate/dnxuc.mak include $(SRC_PATH)/tests/fate/dpcm.mak include $(SRC_PATH)/tests/fate/dvvideo.mak include $(SRC_PATH)/tests/fate/ea.mak diff --git a/tests/fate/dnxuc.mak b/tests/fate/dnxuc.mak new file mode 100644 index 000..80ff0e9 --- /dev/null +++ b/tests/fate/dnxuc.mak @@ -0,0 +1,40 @@ +FATE_DNXUC_CB = fate-dnxuc-cb-rgb-8 \ +fate-dnxuc-cb-rgb-10 \ +fate-dnxuc-cb-rgb-12 \ +fate-dnxuc-cb-rgb-half \ +fate-dnxuc-cb-rgb-float \ +fate-dnxuc-cb-yuv422-8 \ +fate-dnxuc-cb-yuv422-10 \ +fate-dnxuc-cb-yuv422-12 + +FATE_DNXUC_RAMP = fate-dnxuc-ramp-rgb-8 \ +fate-dnxuc-ramp-rgb-10 \ +fate-dnxuc-ramp-rgb-12 \ +fate-dnxuc-ramp-rgb-half \ +fate-dnxuc-ramp-rgb-float \ +fate-dnxuc-ramp-yuv422-8 \ +fate-dnxuc-ramp-yuv422-10 \ +fate-dnxuc-ramp-yuv422-12 + +FATE_DNXUC-$(call FRAMECRC, MXF, DNXUC) += $(FATE_DNXUC_CB) $(FATE_DNXUC_RAMP) + +FATE_SAMPLES_FFMPEG += $(FATE_DNXUC-yes) +fate-dnxuc: $(FATE_DNXUC-yes) + +fate-dnxuc-cb-rgb-8: CMD = framecrc -flags +bitexact -i $(TARGET_SAMPLES)/dnxuc/cb_rgb_8.mxf +fate-dnxuc-cb-rgb-10: CMD = framecrc -flags +bitexact -i $(TARGET_SAMPLES)/dnxuc/cb_rgb_10.mxf +fate-dnxuc-cb-rgb-12: CMD = framecrc -flags +bitexact -i $(TARGET_SAMPLES)/dnxuc/cb_rgb_12.mxf +fate-dnxuc-cb-rgb-half: CMD = framecrc -flags +bitexact -i $(TARGET_SAMPLES)/dnxuc/cb_rgb_half.mxf +fate-dnxuc-cb-rgb-float: CMD = framecrc -flags +bitexact -i $(TARGET_SAMPLES)/dnxuc/cb_rgb_float.mxf +fate-dnxuc-cb-yuv422-8: CMD = framecrc -flags +bitexact -i $(TARGET_SAMPLES)/dnxuc/cb_yuv422_8.mxf +fate-dnxuc-cb-yuv422-10: CMD = framecrc -flags +bitexact -i $(TARGET_SAMPLES)/dnxuc/cb_yuv422_10.mxf +fate-dnxuc-cb-yuv422-12: CMD = framecrc -flags +bitexact -i $(TARGET_SAMPLES)/dnxuc/cb_yuv422_12.mxf + +fate-dnxuc-ramp-rgb-8: CMD = framecrc -flags +bitexact -i $(TARGET_SAMPLES)/dnxuc/ramp_rgb_8.mxf +fate-dnxuc-ramp-rgb-10: CMD = framecrc -flags +bitexact -i $(TARGET_SAMPLES)/dnxuc/ramp_rgb_10.mxf +fate-dnxuc-ramp-rgb-12: CMD = framecrc -flags +bitexact -i $(TARGET_SAMPLES)/dnxuc/ramp_rgb_12.mxf +fate-dnxuc-ramp-rgb-half: CMD = framecrc -flags +bitexact -i $(TARGET_SAMPLES)/dnxuc/ramp_rgb_half.mxf +fate-dnxuc-ramp-rgb-float: CMD = framecrc -flags +bitexact -i $(TARGET_SAMPLES)/dnxuc/ramp_rgb_float.mxf +fate-dnxuc-ramp-yuv422-8: CMD = framecrc -flags +bitexact -i $(TARGET_SAMPLES)/dnxuc/ramp_yuv422_8.mxf +fate-dnxuc-ramp-yuv422-10: CMD = framecrc -flags +bitexact -i $(TARGET_SAMPLES)/dnxuc/ramp_yuv422_10.mxf +fate-dnxuc-ramp-yuv422-12: CMD = framecrc -flags +bitexact -i $(TARGET_SAMPLES)/dnxuc/ramp_yuv422_12.mxf diff --git a/tests/ref/fate/dnxu
[FFmpeg-devel] [PATCH v12 9/9] swscale/input: color subsampling input support for RGBF32
---
libswscale/input.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/libswscale/input.c b/libswscale/input.c
index f9d7c39..ba7e3c4 100644
--- a/libswscale/input.c
+++ b/libswscale/input.c
@@ -1447,6 +1447,30 @@ static av_always_inline void planar_rgbf32_to_y(uint8_t
*_dst, const uint8_t *_s
}
}
+static av_always_inline void rgbf32_to_uv_half_c(uint8_t *_dstU, uint8_t
*_dstV, const uint8_t *unused1,
+ const uint8_t *_src, const
uint8_t *unused2,
+ int width, int is_be, int32_t
*rgb2yuv)
+{
+int i;
+const float *src = (const float *)_src;
+uint16_t *dstU = (uint16_t *)_dstU;
+uint16_t *dstV = (uint16_t *)_dstV;
+int32_t ru = rgb2yuv[RU_IDX], gu = rgb2yuv[GU_IDX], bu = rgb2yuv[BU_IDX];
+int32_t rv = rgb2yuv[RV_IDX], gv = rgb2yuv[GV_IDX], bv = rgb2yuv[BV_IDX];
+
+for (i = 0; i < width; i++) {
+int r = (lrintf(av_clipf(65535.0f * rdpx(&src[6*i]), 0.0f, 65535.0f)) +
+ lrintf(av_clipf(65535.0f * rdpx(&src[6*i+3]), 0.0f,
65535.0f))) >> 1;
+int g = (lrintf(av_clipf(65535.0f * rdpx(&src[6*i+1]), 0.0f,
65535.0f)) +
+ lrintf(av_clipf(65535.0f * rdpx(&src[6*i+4]), 0.0f,
65535.0f))) >> 1;
+int b = (lrintf(av_clipf(65535.0f * rdpx(&src[6*i+2]), 0.0f,
65535.0f)) +
+ lrintf(av_clipf(65535.0f * rdpx(&src[6*i+5]), 0.0f,
65535.0f))) >> 1;
+
+dstU[i] = (ru*r + gu*g + bu*b + (0x10001 << (RGB2YUV_SHIFT - 1))) >>
RGB2YUV_SHIFT;
+dstV[i] = (rv*r + gv*g + bv*b + (0x10001 << (RGB2YUV_SHIFT - 1))) >>
RGB2YUV_SHIFT;
+}
+}
+
static av_always_inline void rgbf32_to_uv_c(uint8_t *_dstU, uint8_t *_dstV,
const uint8_t *unused1,
const uint8_t *_src, const uint8_t
*unused2,
int width, int is_be, int32_t
*rgb2yuv)
@@ -1574,6 +1598,13 @@ static void rgbf32##endian_name##_to_uv_c(uint8_t *dstU,
uint8_t *dstV,
{
\
rgbf32_to_uv_c(dstU, dstV, unused1, src, unused2, w, endian, rgb2yuv);
\
}
\
+static void rgbf32##endian_name##_to_uv_half_c(uint8_t *dstU, uint8_t *dstV,
\
+ const uint8_t *unused1,
\
+ const uint8_t *src, const
uint8_t *unused2, \
+ int w, uint32_t *rgb2yuv, void
*opq) \
+{
\
+rgbf32_to_uv_half_c(dstU, dstV, unused1, src, unused2, w, endian,
rgb2yuv); \
+}
\
static void grayf32##endian_name##ToY16_c(uint8_t *dst, const uint8_t *src,
\
const uint8_t *unused1, const
uint8_t *unused2, \
int width, uint32_t *unused, void
*opq) \
@@ -2138,6 +2169,12 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c,
case AV_PIX_FMT_RGBF16LE:
*chrToYV12 = rgbf16leToUV_half_c;
break;
+case AV_PIX_FMT_RGBF32BE:
+*chrToYV12 = rgbf32be_to_uv_half_c;
+break;
+case AV_PIX_FMT_RGBF32LE:
+*chrToYV12 = rgbf32le_to_uv_half_c;
+break;
}
} else {
switch (srcFormat) {
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v12 5/9] libavcodec/dnxucdec: DNxUncompressed decoder
On 21.10.24 22:44, James Almer wrote:
That's not good...
[...]
Whenever and however I change it, there will allways be somebody who
doesn't like it. !:(
This time I spend a lot of time to modify the code as close as possible
to requests asked by one previous reviewer, who insisted, that for any
format that isn't already supported by a simple raw data pass though, I
have to add a fitting pixel format and the necessary input routines.
In this version I did exactly follow this advice to finally get accepted.
Only for those six formats, which need anyway some further processing,
because of a very uncommon bitpacking stucture used by DNxUncompressed
for 10 and 12bit formats, I still used some already available similar
planar formats.
I personally still think it would wise to support just a minimal but
carefully and systematically chosen set of internal pixel formats for
lossless and efficient processing and avoid all other very similar
combinatorial possibilities, but those other reviewer strictly denied
this view.
+ break;
+ case MKTAG('y','4','0','8'):
+ ret = fmt_frame(avctx, frame, avpkt, AV_PIX_FMT_YUV444,
24, pass_through);
Y408 is mapped to AV_PIX_FMT_AYUV.
yes -- but "AYUV" is something different than "YUV"
+ break;
+ case MKTAG('y','2','1','0'):
+ ret = fmt_frame(avctx, frame, avpkt,
AV_PIX_FMT_YUV422P10LE, 20, unpack_y210);
Y210 has no pixel format, and it's packed, not planar, so definitely not
AV_PIX_FMT_YUV422P10LE.
I just put here the final pixel format, which it will have after
preprocessing, as an argument for this kind of input. The actual
transformation resp. bit reassembling is happening in `unpack_y210()`.
+ break;
+ case MKTAG('y','4','1','0'):
+ ret = fmt_frame(avctx, frame, avpkt,
AV_PIX_FMT_YUV444P10LE, 20, unpack_y410);
Y410 is mapped to AV_PIX_FMT_XV30LE.
no -- in case of the 10 and 12 bit variants I utilize 16bit aligned
planar storage, because ignoring byte and 32bit boundaries for more
dense storage and optimized pixel data locality isn't always useful.
+ break;
+ case MKTAG('y','2','1','2'):
+ ret = fmt_frame(avctx, frame, avpkt,
AV_PIX_FMT_YUV422P12LE, 24, unpack_y212);
AV_PIX_FMT_Y212?
detto...
+ break;
+ case MKTAG('y','4','1','2'):
+ ret = fmt_frame(avctx, frame, avpkt,
AV_PIX_FMT_YUV444P12LE, 24, unpack_y412);
This one is probably AV_PIX_FMT_XV36, and definitely not planar.
detto...
+ break;
+ case MKTAG('y','2','1','6'):
+ ret = fmt_frame(avctx, frame, avpkt,
AV_PIX_FMT_UYVY422_16LE, 32, pass_through);
The order of y216 appears to be YUYV, not UYVY. https://
learn.microsoft.com/en-us/windows/win32/medfound/10-bit-and-16-bit-yuv-
video-formats
Please also read the SMPTE RDD 50 specification as well!
(https://pub.smpte.org/doc/rdd50/20190730-pub/rdd50-2019.pdf)
But in fact I would even more suggest looking at the well structured
system of vulkan pixel formats!
I simply had to implement all this additional pixel formats, because the
byte order of already defined varaints were indeed different. And you
can't simply ignore this fact, if you want to handle the raw data stream
without any other kind of local modification.
Martin
___
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 v12 5/9] libavcodec/dnxucdec: DNxUncompressed decoder
On 10/21/2024 5:44 PM, James Almer wrote:
On 10/21/2024 4:57 PM, Martin Schitter wrote:
+ break;
+ case MKTAG('y','2','1','0'):
+ ret = fmt_frame(avctx, frame, avpkt,
AV_PIX_FMT_YUV422P10LE, 20, unpack_y210);
Y210 has no pixel format, and it's packed, not planar, so definitely not
AV_PIX_FMT_YUV422P10LE.
Nevermind, there's AV_PIX_FMT_Y210.
OpenPGP_signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v12 3/9] avutil/swscale: add YUV444F16 and UYVYF16 pixel format and input support
On Tue, Oct 22, 2024 at 12:30:42AM +0200, Michael Niedermayer wrote:
> On Mon, Oct 21, 2024 at 09:57:16PM +0200, Martin Schitter wrote:
> > ---
> > libavutil/pixdesc.c | 48
> > libavutil/pixfmt.h | 6 ++
> > libswscale/input.c | 99
> > libswscale/utils.c | 4 ++
> > tests/ref/fate/imgutils | 8 +++
> > tests/ref/fate/sws-pixdesc-query | 14 +
> > 6 files changed, 179 insertions(+)
> [...]
>
> > diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
> > index fde8dbb..67f568f 100644
> > --- a/libavutil/pixfmt.h
> > +++ b/libavutil/pixfmt.h
> > @@ -460,9 +460,13 @@ enum AVPixelFormat {
> > AV_PIX_FMT_YUV444, ///< packed YUV 4:4:4, 24bpp (1 Cr & Cb sample
> > per 1x1 Y), YUVYUV...
> > AV_PIX_FMT_YUV444_16BE, ///< packed YUV 4:4:4, 48bpp (1 Cr & Cb
> > sample per 1x1 Y), YUVYUV..., big-endian
> > AV_PIX_FMT_YUV444_16LE, ///< packed YUV 4:4:4, 48bpp (1 Cr & Cb
> > sample per 1x1 Y), YUVYUV..., little-endian
> > +AV_PIX_FMT_YUV444F16BE, ///< IEEE-754 half precision packed YUV
> > 4:4:4, 48bpp (1 Cr & Cb sample per 1x1 Y), YUVYUV..., big-endian
> > +AV_PIX_FMT_YUV444F16LE, ///< IEEE-754 half precision packed YUV
> > 4:4:4, 48bpp (1 Cr & Cb sample per 1x1 Y), YUVYUV..., little-endian
> >
> > AV_PIX_FMT_UYVY422_16BE, ///< packed UYVU 4:2:2, 32bpp, Cb Y0 Cr Y1,
> > big-endian
> > AV_PIX_FMT_UYVY422_16LE, ///< packed UYVU 4:2:2, 32bpp, Cb Y0 Cr Y1,
> > little-endian
>
> adding them in the middle will change the numbers of the following and break
> ABI
> sadly
I see you added these in the previous patch of the series, i guess its ok then
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v12 3/9] avutil/swscale: add YUV444F16 and UYVYF16 pixel format and input support
On 22.10.24 00:30, Michael Niedermayer wrote: adding them in the middle will change the numbers of the following and break ABI sadly you have to add them at the end If you apply the whole patch set, they are all as one group at the end! I just did my best to not increase the utterly chaotic unstructured order of this list even further by grouping at least these new additions in a more useful manner. Martin ___ 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 v12 3/9] avutil/swscale: add YUV444F16 and UYVYF16 pixel format and input support
On 22.10.24 00:32, Michael Niedermayer wrote: I see you added these in the previous patch of the series, i guess its ok then exactly! :) ___ 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] libavfilter: integral images and minkowski pooling for SSIM - ping
On Mon, Oct 21, 2024 at 07:32:20PM +0200, AndreaMastroberti wrote: > --- > doc/filters.texi | 14 +++ > libavfilter/ssim.h| 6 + > libavfilter/version.h | 4 +- > libavfilter/vf_ssim.c | 277 -- > 4 files changed, 291 insertions(+), 10 deletions(-) > > diff --git a/doc/filters.texi b/doc/filters.texi > index 2eb4a380fb..df5c3a9305 100644 > --- a/doc/filters.texi > +++ b/doc/filters.texi > @@ -22848,6 +22848,20 @@ The description of the accepted parameters follows. > If specified the filter will use the named file to save the SSIM of > each individual frame. When filename equals "-" the data is sent to > standard output. > + first column whitespace is corrupted Applying: libavfilter: integral images and minkowski pooling for SSIM - ping error: corrupt patch at line 13 Patch failed at 0001 libavfilter: integral images and minkowski pooling for SSIM - ping [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- Plato signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v12 5/9] libavcodec/dnxucdec: DNxUncompressed decoder
On 10/21/2024 8:40 PM, martin schitter wrote:
On 21.10.24 22:44, James Almer wrote:
That's not good...
[...]
Whenever and however I change it, there will allways be somebody who
doesn't like it. !:(
My point is, it's not a good idea to commit code that's not tested.
Assuming that's what you meant.
This time I spend a lot of time to modify the code as close as possible
to requests asked by one previous reviewer, who insisted, that for any
format that isn't already supported by a simple raw data pass though, I
have to add a fitting pixel format and the necessary input routines.
In this version I did exactly follow this advice to finally get accepted.
Only for those six formats, which need anyway some further processing,
because of a very uncommon bitpacking stucture used by DNxUncompressed
for 10 and 12bit formats, I still used some already available similar
planar formats.
I personally still think it would wise to support just a minimal but
carefully and systematically chosen set of internal pixel formats for
lossless and efficient processing and avoid all other very similar
combinatorial possibilities, but those other reviewer strictly denied
this view.
Yes, i agree. But what gets committed should be know to work.
+ break;
+ case MKTAG('y','4','0','8'):
+ ret = fmt_frame(avctx, frame, avpkt, AV_PIX_FMT_YUV444,
24, pass_through);
Y408 is mapped to AV_PIX_FMT_AYUV.
yes -- but "AYUV" is something different than "YUV"
+ break;
+ case MKTAG('y','2','1','0'):
+ ret = fmt_frame(avctx, frame, avpkt,
AV_PIX_FMT_YUV422P10LE, 20, unpack_y210);
Y210 has no pixel format, and it's packed, not planar, so definitely
not AV_PIX_FMT_YUV422P10LE.
I just put here the final pixel format, which it will have after
preprocessing, as an argument for this kind of input. The actual
transformation resp. bit reassembling is happening in `unpack_y210()`.
+ break;
+ case MKTAG('y','4','1','0'):
+ ret = fmt_frame(avctx, frame, avpkt,
AV_PIX_FMT_YUV444P10LE, 20, unpack_y410);
Y410 is mapped to AV_PIX_FMT_XV30LE.
no -- in case of the 10 and 12 bit variants I utilize 16bit aligned
planar storage, because ignoring byte and 32bit boundaries for more
dense storage and optimized pixel data locality isn't always useful.
+ break;
+ case MKTAG('y','2','1','2'):
+ ret = fmt_frame(avctx, frame, avpkt,
AV_PIX_FMT_YUV422P12LE, 24, unpack_y212);
AV_PIX_FMT_Y212?
detto...
+ break;
+ case MKTAG('y','4','1','2'):
+ ret = fmt_frame(avctx, frame, avpkt,
AV_PIX_FMT_YUV444P12LE, 24, unpack_y412);
This one is probably AV_PIX_FMT_XV36, and definitely not planar.
detto...
+ break;
+ case MKTAG('y','2','1','6'):
+ ret = fmt_frame(avctx, frame, avpkt,
AV_PIX_FMT_UYVY422_16LE, 32, pass_through);
The order of y216 appears to be YUYV, not UYVY. https://
learn.microsoft.com/en-us/windows/win32/medfound/10-bit-and-16-bit-
yuv- video-formats
Please also read the SMPTE RDD 50 specification as well!
(https://pub.smpte.org/doc/rdd50/20190730-pub/rdd50-2019.pdf)
But in fact I would even more suggest looking at the well structured
system of vulkan pixel formats!
I simply had to implement all this additional pixel formats, because the
byte order of already defined varaints were indeed different. And you
can't simply ignore this fact, if you want to handle the raw data stream
without any other kind of local modification.
Ok, looks like that spec defined some crazy packing and reused existing
naming schemes. Great.
If you're going to unpack these MSB and LSB blocks so the output may be
something that can be used by an AVPixFmtDescriptor, then might as well
not add so many new pixel formats that will see no other use and instead
rely on existing, widely supported ones. As in:
+case MKTAG('y','2','1','6'):
+ret = fmt_frame(avctx, frame, avpkt, AV_PIX_FMT_UYVY422_16LE, 32,
pass_through);
+break;
You could unpack this into AV_PIX_FMT_YUV422P16LE.
+case MKTAG('y','4','0','8'):
+ret = fmt_frame(avctx, frame, avpkt, AV_PIX_FMT_YUV444, 24,
pass_through);
+break;
You could rearrange this into AV_PIX_FMT_VYU444, or unpack into
AV_PIX_FMT_YUV444P.
+case MKTAG('y','4','1','6'):
+ret = fmt_frame(avctx, frame, avpkt, AV_PIX_FMT_YUV444_16LE, 48,
pass_through);
+break;
You could unpack this into AV_PIX_FMT_YUV444P16LE, or rearrange it into
AV_PIX_FMT_AYUV64 (setting the alpha channel to opaque).
The float ones are ok since we have no YUV float formats. But in any
case, I'd like to hear what others think.
Thanks for your work.
OpenPGP_signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.or
Re: [FFmpeg-devel] [PATCH v12 3/9] avutil/swscale: add YUV444F16 and UYVYF16 pixel format and input support
On Mon, Oct 21, 2024 at 09:57:16PM +0200, Martin Schitter wrote:
> ---
> libavutil/pixdesc.c | 48
> libavutil/pixfmt.h | 6 ++
> libswscale/input.c | 99
> libswscale/utils.c | 4 ++
> tests/ref/fate/imgutils | 8 +++
> tests/ref/fate/sws-pixdesc-query | 14 +
> 6 files changed, 179 insertions(+)
[...]
> diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
> index fde8dbb..67f568f 100644
> --- a/libavutil/pixfmt.h
> +++ b/libavutil/pixfmt.h
> @@ -460,9 +460,13 @@ enum AVPixelFormat {
> AV_PIX_FMT_YUV444, ///< packed YUV 4:4:4, 24bpp (1 Cr & Cb sample
> per 1x1 Y), YUVYUV...
> AV_PIX_FMT_YUV444_16BE, ///< packed YUV 4:4:4, 48bpp (1 Cr & Cb sample
> per 1x1 Y), YUVYUV..., big-endian
> AV_PIX_FMT_YUV444_16LE, ///< packed YUV 4:4:4, 48bpp (1 Cr & Cb sample
> per 1x1 Y), YUVYUV..., little-endian
> +AV_PIX_FMT_YUV444F16BE, ///< IEEE-754 half precision packed YUV 4:4:4,
> 48bpp (1 Cr & Cb sample per 1x1 Y), YUVYUV..., big-endian
> +AV_PIX_FMT_YUV444F16LE, ///< IEEE-754 half precision packed YUV 4:4:4,
> 48bpp (1 Cr & Cb sample per 1x1 Y), YUVYUV..., little-endian
>
> AV_PIX_FMT_UYVY422_16BE, ///< packed UYVU 4:2:2, 32bpp, Cb Y0 Cr Y1,
> big-endian
> AV_PIX_FMT_UYVY422_16LE, ///< packed UYVU 4:2:2, 32bpp, Cb Y0 Cr Y1,
> little-endian
adding them in the middle will change the numbers of the following and break ABI
sadly
you have to add them at the end
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v12 5/9] libavcodec/dnxucdec: DNxUncompressed decoder
On 21.10.24 23:50, James Almer wrote:
On 10/21/2024 5:44 PM, James Almer wrote:
On 10/21/2024 4:57 PM, Martin Schitter wrote:
+ break;
+ case MKTAG('y','2','1','0'):
+ ret = fmt_frame(avctx, frame, avpkt,
AV_PIX_FMT_YUV422P10LE, 20, unpack_y210);
Y210 has no pixel format, and it's packed, not planar, so definitely
not AV_PIX_FMT_YUV422P10LE.
Nevermind, there's AV_PIX_FMT_Y210.
Although both entities share a very similar FOURCC code, they are very
different bit structures in practice!
Sure, both of them refer 'somehow' to 10bit 4:2:2 YUV data and can be
lossless converted in both directions, but that's all they have in common.
But in fact I could have converted the DNxUncompressed 10 and 12 bit
formats to any packed format as well. I just choose the planar variant,
because byte ordering changes are easier to handle in this arrangement
and there were more systematically ordered variants of this kind already
defined. At the beginning I hopped, that this would make the reuse of
already defined pixformats more easily and also enable a more
consistent code layout for all the required RGB / YUV422 / YUV444
variants...
Searching the chaotic list of already defined pixel formats is another
topic, where I better keep quiet, because I could otherwise hurt somebody...
Martin
___
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] fate/vvc: Add a sample which lose frames before 5c66a3
> On Sep 18, 2024, at 14:56, Zhao Zhili wrote: > > From: Zhao Zhili > > --- > sample: > 8054b4b8e62c0171476b40206d044590 Hierarchical.bit > https://drive.google.com/file/d/1U5WGWeSsMFiEkhsl_vL4NiMma-LLh02t/view?usp=sharing > > Put Hierarchical.bit under $(TARGET_SAMPLES)/vvc Ping. > > tests/fate/vvc.mak| 3 ++- > tests/ref/fate/vvc-output-ref | 35 +++ > 2 files changed, 37 insertions(+), 1 deletion(-) > create mode 100644 tests/ref/fate/vvc-output-ref > > diff --git a/tests/fate/vvc.mak b/tests/fate/vvc.mak > index 5335460263..fb176b7745 100644 > --- a/tests/fate/vvc.mak > +++ b/tests/fate/vvc.mak > @@ -42,8 +42,9 @@ $(VVC_TESTS_8BIT): SCALE_OPTS := -pix_fmt yuv420p > $(VVC_TESTS_10BIT): SCALE_OPTS := -pix_fmt yuv420p10le -vf scale > $(VVC_TESTS_444_10BIT): SCALE_OPTS := -pix_fmt yuv444p10le -vf scale > fate-vvc-conformance-%: CMD = framecrc -c:v vvc -i > $(TARGET_SAMPLES)/vvc-conformance/$(subst fate-vvc-conformance-,,$(@)).bit > $(SCALE_OPTS) > +fate-vvc-output-ref: CMD = framecrc -c:v vvc -i > $(TARGET_SAMPLES)/vvc/Hierarchical.bit $(SCALE_OPTS) > > -FATE_VVC-$(call FRAMECRC, VVC, VVC, VVC_PARSER) += $(VVC_TESTS_8BIT) > +FATE_VVC-$(call FRAMECRC, VVC, VVC, VVC_PARSER) += $(VVC_TESTS_8BIT) > fate-vvc-output-ref > FATE_VVC-$(call FRAMECRC, VVC, VVC, VVC_PARSER SCALE_FILTER) +=\ > $(VVC_TESTS_10BIT) \ > $(VVC_TESTS_444_10BIT) \ > diff --git a/tests/ref/fate/vvc-output-ref b/tests/ref/fate/vvc-output-ref > new file mode 100644 > index 00..0797305b9a > --- /dev/null > +++ b/tests/ref/fate/vvc-output-ref > @@ -0,0 +1,35 @@ > +#tb 0: 1/25 > +#media_type 0: video > +#codec_id 0: rawvideo > +#dimensions 0: 480x320 > +#sar 0: 0/1 > +0, 0, 0,1, 230400, 0x3293f7f1 > +0, 1, 1,1, 230400, 0xe2570fa4 > +0, 2, 2,1, 230400, 0xecd608fb > +0, 3, 3,1, 230400, 0xea46f9f4 > +0, 4, 4,1, 230400, 0xb715d24a > +0, 5, 5,1, 230400, 0x69faaf46 > +0, 6, 6,1, 230400, 0xf9a362db > +0, 7, 7,1, 230400, 0x2dcd19ca > +0, 8, 8,1, 230400, 0xf8fda185 > +0, 9, 9,1, 230400, 0x48a35bfd > +0, 10, 10,1, 230400, 0x27efe832 > +0, 11, 11,1, 230400, 0x74279617 > +0, 12, 12,1, 230400, 0x91935248 > +0, 13, 13,1, 230400, 0x29b621e6 > +0, 14, 14,1, 230400, 0x89b1ec0b > +0, 15, 15,1, 230400, 0x898fdba1 > +0, 16, 16,1, 230400, 0xc6d18e6f > +0, 17, 17,1, 230400, 0xedff651b > +0, 18, 18,1, 230400, 0x677e2260 > +0, 19, 19,1, 230400, 0x930918ef > +0, 20, 20,1, 230400, 0x70da2c30 > +0, 21, 21,1, 230400, 0x699a3b9d > +0, 22, 22,1, 230400, 0xff3b1b3a > +0, 23, 23,1, 230400, 0xca11d9a5 > +0, 24, 24,1, 230400, 0x904394e0 > +0, 25, 25,1, 230400, 0x392e5445 > +0, 26, 26,1, 230400, 0x6191f4d8 > +0, 27, 27,1, 230400, 0xa7d7be12 > +0, 28, 28,1, 230400, 0xbb29752c > +0, 29, 29,1, 230400, 0x14ff297e > -- > 2.42.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fftools/ffplay: use swapchain_colorspace_hint to get better HDR support
> On Sep 25, 2024, at 22:45, Zhao Zhili wrote:
>
> From: Zhao Zhili
>
> For example, the default surface configuration on macOS is:
> VK_FORMAT_A2B10G10R10_UNORM_PACK32 + VK_COLOR_SPACE_PASS_THROUGH_EXT
>
> With HDR10 content and swapchain_colorspace_hint, the surface
> configuration updated to:
> VK_FORMAT_A2B10G10R10_UNORM_PACK32 + VK_COLOR_SPACE_HDR10_ST2084_EXT
> ---
> fftools/ffplay_renderer.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/fftools/ffplay_renderer.c b/fftools/ffplay_renderer.c
> index f272cb46f1..618149e7b2 100644
> --- a/fftools/ffplay_renderer.c
> +++ b/fftools/ffplay_renderer.c
> @@ -697,6 +697,7 @@ static int display(VkRenderer *renderer, AVFrame *frame)
> struct pl_frame target = {0};
> RendererContext *ctx = (RendererContext *) renderer;
> int ret = 0;
> +struct pl_color_space hint = {0};
>
> ret = convert_frame(renderer, frame);
> if (ret < 0)
> @@ -709,6 +710,8 @@ static int display(VkRenderer *renderer, AVFrame *frame)
> return AVERROR_EXTERNAL;
> }
>
> +pl_color_space_from_avframe(&hint, frame);
> +pl_swapchain_colorspace_hint(ctx->swapchain, &hint);
> if (!pl_swapchain_start_frame(ctx->swapchain, &swap_frame)) {
> av_log(NULL, AV_LOG_ERROR, "start frame failed\n");
> ret = AVERROR_EXTERNAL;
> --
> 2.46.0
Will apply this week.
___
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/2] fate/pixfmts: test conversion of high bitdepth formats
Signed-off-by: James Almer
---
tests/fate-run.sh | 13 +++
tests/fate/pixfmt.mak | 60 +--
tests/ref/fate/pixfmt-gbrp10be| 2 ++
tests/ref/fate/pixfmt-gbrp10le| 2 ++
tests/ref/fate/pixfmt-gbrp12be| 2 ++
tests/ref/fate/pixfmt-gbrp12le| 2 ++
tests/ref/fate/pixfmt-gray10be| 2 ++
tests/ref/fate/pixfmt-gray10le| 2 ++
tests/ref/fate/pixfmt-gray12be| 2 ++
tests/ref/fate/pixfmt-gray12le| 2 ++
tests/ref/fate/pixfmt-p010be | 2 ++
tests/ref/fate/pixfmt-p010le | 2 ++
tests/ref/fate/pixfmt-p012be | 2 ++
tests/ref/fate/pixfmt-p012le | 2 ++
tests/ref/fate/pixfmt-p210be | 2 ++
tests/ref/fate/pixfmt-p210le | 2 ++
tests/ref/fate/pixfmt-p212be | 2 ++
tests/ref/fate/pixfmt-p212le | 2 ++
tests/ref/fate/pixfmt-p410be | 2 ++
tests/ref/fate/pixfmt-p410le | 2 ++
tests/ref/fate/pixfmt-p412be | 2 ++
tests/ref/fate/pixfmt-p412le | 2 ++
tests/ref/fate/pixfmt-v30xle | 2 ++
tests/ref/fate/pixfmt-x2bgr10le | 2 ++
tests/ref/fate/pixfmt-x2rgb10le | 2 ++
tests/ref/fate/pixfmt-xv30le | 2 ++
tests/ref/fate/pixfmt-xv36be | 2 ++
tests/ref/fate/pixfmt-xv36le | 2 ++
tests/ref/fate/pixfmt-y210le | 2 ++
tests/ref/fate/pixfmt-y212le | 2 ++
tests/ref/fate/pixfmt-yuv420p10be | 2 ++
tests/ref/fate/pixfmt-yuv420p10le | 2 ++
tests/ref/fate/pixfmt-yuv420p12be | 2 ++
tests/ref/fate/pixfmt-yuv420p12le | 2 ++
tests/ref/fate/pixfmt-yuv422p10be | 2 ++
tests/ref/fate/pixfmt-yuv422p10le | 2 ++
tests/ref/fate/pixfmt-yuv422p12be | 2 ++
tests/ref/fate/pixfmt-yuv422p12le | 2 ++
tests/ref/fate/pixfmt-yuv440p10be | 2 ++
tests/ref/fate/pixfmt-yuv440p10le | 2 ++
tests/ref/fate/pixfmt-yuv440p12be | 2 ++
tests/ref/fate/pixfmt-yuv440p12le | 2 ++
tests/ref/fate/pixfmt-yuv444p10be | 2 ++
tests/ref/fate/pixfmt-yuv444p10le | 2 ++
tests/ref/fate/pixfmt-yuv444p12be | 2 ++
tests/ref/fate/pixfmt-yuv444p12le | 2 ++
46 files changed, 159 insertions(+), 2 deletions(-)
create mode 100644 tests/ref/fate/pixfmt-gbrp10be
create mode 100644 tests/ref/fate/pixfmt-gbrp10le
create mode 100644 tests/ref/fate/pixfmt-gbrp12be
create mode 100644 tests/ref/fate/pixfmt-gbrp12le
create mode 100644 tests/ref/fate/pixfmt-gray10be
create mode 100644 tests/ref/fate/pixfmt-gray10le
create mode 100644 tests/ref/fate/pixfmt-gray12be
create mode 100644 tests/ref/fate/pixfmt-gray12le
create mode 100644 tests/ref/fate/pixfmt-p010be
create mode 100644 tests/ref/fate/pixfmt-p010le
create mode 100644 tests/ref/fate/pixfmt-p012be
create mode 100644 tests/ref/fate/pixfmt-p012le
create mode 100644 tests/ref/fate/pixfmt-p210be
create mode 100644 tests/ref/fate/pixfmt-p210le
create mode 100644 tests/ref/fate/pixfmt-p212be
create mode 100644 tests/ref/fate/pixfmt-p212le
create mode 100644 tests/ref/fate/pixfmt-p410be
create mode 100644 tests/ref/fate/pixfmt-p410le
create mode 100644 tests/ref/fate/pixfmt-p412be
create mode 100644 tests/ref/fate/pixfmt-p412le
create mode 100644 tests/ref/fate/pixfmt-v30xle
create mode 100644 tests/ref/fate/pixfmt-x2bgr10le
create mode 100644 tests/ref/fate/pixfmt-x2rgb10le
create mode 100644 tests/ref/fate/pixfmt-xv30le
create mode 100644 tests/ref/fate/pixfmt-xv36be
create mode 100644 tests/ref/fate/pixfmt-xv36le
create mode 100644 tests/ref/fate/pixfmt-y210le
create mode 100644 tests/ref/fate/pixfmt-y212le
create mode 100644 tests/ref/fate/pixfmt-yuv420p10be
create mode 100644 tests/ref/fate/pixfmt-yuv420p10le
create mode 100644 tests/ref/fate/pixfmt-yuv420p12be
create mode 100644 tests/ref/fate/pixfmt-yuv420p12le
create mode 100644 tests/ref/fate/pixfmt-yuv422p10be
create mode 100644 tests/ref/fate/pixfmt-yuv422p10le
create mode 100644 tests/ref/fate/pixfmt-yuv422p12be
create mode 100644 tests/ref/fate/pixfmt-yuv422p12le
create mode 100644 tests/ref/fate/pixfmt-yuv440p10be
create mode 100644 tests/ref/fate/pixfmt-yuv440p10le
create mode 100644 tests/ref/fate/pixfmt-yuv440p12be
create mode 100644 tests/ref/fate/pixfmt-yuv440p12le
create mode 100644 tests/ref/fate/pixfmt-yuv444p10be
create mode 100644 tests/ref/fate/pixfmt-yuv444p10le
create mode 100644 tests/ref/fate/pixfmt-yuv444p12be
create mode 100644 tests/ref/fate/pixfmt-yuv444p12le
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index f8d67de25a..551e126271 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -503,6 +503,19 @@ pixfmt_conversion(){
$ENC_OPTS -f rawvideo -s 352x288 -pix_fmt yuv444p -color_range
mpeg
}
+pixfmt_conversion_hbd(){
+depth=$1
+conversion="${test#pixfmt-}"
+outdir="tests/data/pixfmt"
+raw_dst="$outdir/$conversion.out.yuv"
+file=${outdir}/${conversion}.yuv
+cleanfiles="$cleanfiles $raw_dst $file"
+run_avconv $DEC_OPTS -auto_conversion_filters -lavfi
yuvtestsrc=s=352x288,format=yuv420p$depth \
+ $ENC_OPTS -f rawvideo -t 1
[FFmpeg-devel] [PATCH 2/2] swscale/swscale_unscaled: fix shift values in planarToP01xWrapper
The current calculation was a no-op, setting the entire array to 0.
Use the shift value from the dest descriptor, as the source one is planar with
no shifts whatsoever.
Signed-off-by: James Almer
---
libswscale/swscale_unscaled.c | 17 +++--
1 file changed, 3 insertions(+), 14 deletions(-)
diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
index a7fdb438a6..5e963ced15 100644
--- a/libswscale/swscale_unscaled.c
+++ b/libswscale/swscale_unscaled.c
@@ -268,23 +268,12 @@ static int planarToP01xWrapper(SwsContext *c, const
uint8_t *const src8[],
int srcSliceH, uint8_t *const dstParam8[],
const int dstStride[])
{
-const AVPixFmtDescriptor *src_format = av_pix_fmt_desc_get(c->srcFormat);
const AVPixFmtDescriptor *dst_format = av_pix_fmt_desc_get(c->dstFormat);
const uint16_t **src = (const uint16_t**)src8;
uint16_t *dstY = (uint16_t*)(dstParam8[0] + dstStride[0] * srcSliceY);
uint16_t *dstUV = (uint16_t*)(dstParam8[1] + dstStride[1] * srcSliceY / 2);
int x, y;
-/* Calculate net shift required for values. */
-const int shift[3] = {
-dst_format->comp[0].depth + dst_format->comp[0].shift -
-src_format->comp[0].depth - src_format->comp[0].shift,
-dst_format->comp[1].depth + dst_format->comp[1].shift -
-src_format->comp[1].depth - src_format->comp[1].shift,
-dst_format->comp[2].depth + dst_format->comp[2].shift -
-src_format->comp[2].depth - src_format->comp[2].shift,
-};
-
av_assert0(!(srcStride[0] % 2 || srcStride[1] % 2 || srcStride[2] % 2 ||
dstStride[0] % 2 || dstStride[1] % 2));
@@ -292,7 +281,7 @@ static int planarToP01xWrapper(SwsContext *c, const uint8_t
*const src8[],
uint16_t *tdstY = dstY;
const uint16_t *tsrc0 = src[0];
for (x = c->srcW; x > 0; x--) {
-*tdstY++ = *tsrc0++ << shift[0];
+*tdstY++ = *tsrc0++ << dst_format->comp[0].shift;
}
src[0] += srcStride[0] / 2;
dstY += dstStride[0] / 2;
@@ -302,8 +291,8 @@ static int planarToP01xWrapper(SwsContext *c, const uint8_t
*const src8[],
const uint16_t *tsrc1 = src[1];
const uint16_t *tsrc2 = src[2];
for (x = c->srcW / 2; x > 0; x--) {
-*tdstUV++ = *tsrc1++ << shift[1];
-*tdstUV++ = *tsrc2++ << shift[2];
+*tdstUV++ = *tsrc1++ << dst_format->comp[1].shift;
+*tdstUV++ = *tsrc2++ << dst_format->comp[2].shift;
}
src[1] += srcStride[1] / 2;
src[2] += srcStride[2] / 2;
--
2.47.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] libavfilter: integral images and minkowski pooling for SSIM - ping
---
doc/filters.texi | 14 +++
libavfilter/ssim.h| 6 +
libavfilter/version.h | 4 +-
libavfilter/vf_ssim.c | 277 --
4 files changed, 291 insertions(+), 10 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 2eb4a380fb..df5c3a9305 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -22848,6 +22848,20 @@ The description of the accepted parameters follows.
If specified the filter will use the named file to save the SSIM of
each individual frame. When filename equals "-" the data is sent to
standard output.
+
+@item int_img
+If set to @code{1}, uses integral images to compute SSIM.
+
+@item window
+Sets the size of the widows over which SSIM is computed. Allowed values are
@code{8} for an 8x8 window
+and @code{16} for a 16x16 window.
+
+@item stride
+Sets the stride between windows. Allowed values are @code{4} and @code{8}.
+
+@item pool
+Sets the pooling method. Allowed values are @code{avg}, the arithmetic
average; @code{mink3} for Minkowski
+norm-3 and @code{mink4} for Minkwoski norm-4.
@end table
The file printed if @var{stats_file} is selected, contains a sequence of
diff --git a/libavfilter/ssim.h b/libavfilter/ssim.h
index a6a41aabe6..1eeabeb6ce 100644
--- a/libavfilter/ssim.h
+++ b/libavfilter/ssim.h
@@ -24,6 +24,12 @@
#include
#include
+typedef enum {
+AVG,
+MINK_3,
+MINK_4
+} PoolMethod;
+
typedef struct SSIMDSPContext {
void (*ssim_4x4_line)(const uint8_t *buf, ptrdiff_t buf_stride,
const uint8_t *ref, ptrdiff_t ref_stride,
diff --git a/libavfilter/version.h b/libavfilter/version.h
index d8cd8a2cfb..7e0eb9af97 100644
--- a/libavfilter/version.h
+++ b/libavfilter/version.h
@@ -31,8 +31,8 @@
#include "version_major.h"
-#define LIBAVFILTER_VERSION_MINOR 2
-#define LIBAVFILTER_VERSION_MICRO 102
+#define LIBAVFILTER_VERSION_MINOR 3
+#define LIBAVFILTER_VERSION_MICRO 100
#define LIBAVFILTER_VERSION_INT AV_VERSION_INT(LIBAVFILTER_VERSION_MAJOR, \
diff --git a/libavfilter/vf_ssim.c b/libavfilter/vf_ssim.c
index 97bffcf70c..c4f874818b 100644
--- a/libavfilter/vf_ssim.c
+++ b/libavfilter/vf_ssim.c
@@ -44,6 +44,7 @@
#include "filters.h"
#include "framesync.h"
#include "ssim.h"
+#include
typedef struct SSIMContext {
const AVClass *class;
@@ -63,8 +64,15 @@ typedef struct SSIMContext {
int **temp;
int is_rgb;
double **score;
+uint64_t **i1[4], **i2[4], **s1[4], **s2[4], **i12[4];
+int int_img;
+int win_size;
+int stride;
+PoolMethod pool;
int (*ssim_plane)(AVFilterContext *ctx, void *arg,
int jobnr, int nb_jobs);
+int (*ssim_plane_int)(AVFilterContext *ctx, void *arg,
+ int jobnr, int nb_jobs);
SSIMDSPContext dsp;
} SSIMContext;
@@ -74,6 +82,13 @@ typedef struct SSIMContext {
static const AVOption ssim_options[] = {
{"stats_file", "Set file where to store per-frame difference information",
OFFSET(stats_file_str), AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0, FLAGS },
{"f", "Set file where to store per-frame difference information",
OFFSET(stats_file_str), AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0, FLAGS },
+{ "int_img", "Compute SSIM using integral images", OFFSET(int_img),
AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, FLAGS },
+{ "window", "Window size", OFFSET(win_size), AV_OPT_TYPE_INT, { .i64 = 8
}, 8, 16, FLAGS },
+{ "stride", "Stride length", OFFSET(stride), AV_OPT_TYPE_INT, { .i64 = 4
}, 4, 8, FLAGS },
+{ "pool", "Pooling method", OFFSET(pool), AV_OPT_TYPE_INT, {.i64 = AVG},
0, 2, FLAGS, "pool" },
+{ "avg", "Average pooling", 0, AV_OPT_TYPE_CONST, {.i64 = AVG}, 0,
0, FLAGS, "pool" },
+{ "mink3", "Minkowski norm 3", 0, AV_OPT_TYPE_CONST, {.i64 =
MINK_3}, 0, 0, FLAGS, "pool" },
+{ "mink4", "Minkowski norm 4", 0, AV_OPT_TYPE_CONST, {.i64 =
MINK_4}, 0, 0, FLAGS, "pool" },
{ NULL }
};
@@ -159,6 +174,8 @@ static void ssim_4x4xn_8bit(const uint8_t *main, ptrdiff_t
main_stride,
}
}
+
+
static float ssim_end1x(int64_t s1, int64_t s2, int64_t ss, int64_t s12, int
max)
{
int64_t ssim_c1 = (int64_t)(.01*.01*max*max*64 + .5);
@@ -191,6 +208,28 @@ static float ssim_end1(int s1, int s2, int ss, int s12)
/ ((float)(fs1 * fs1 + fs2 * fs2 + ssim_c1) * (float)(vars + ssim_c2));
}
+static float ssim_end1w(int s1, int s2, int ss, int s12, int win_size)
+{
+double ws = (double)win_size * win_size;
+double ssim_c1 = 0.01 * 0.01 * 255 * 255 * ws;
+double ssim_c2 = 0.03 * 0.03 * 255 * 255 * ws * (ws - 1);
+
+double fs1 = (double)s1;
+double fs2 = (double)s2;
+double fss = (double)ss;
+double fs12 = (double)s12;
+
+double vars = fss * ws - fs1 * fs1 - fs2 * fs2;
+double covar = fs12 * ws - fs1 * fs2;
+
+double num = (2 * fs1 * fs2 + ssim_c1) * (2 * covar + ssim_c2);
+double den = (fs1 * fs1 + fs2 * fs2 + ssim_c1) * (vars + ssim_c2);
+
+double ssim = num / den;
+
+return ssim;
Re: [FFmpeg-devel] [PATCH] fate/ffmpeg: add samples dependency to fate-ffmpeg-spec-disposition
On Mon, Oct 7, 2024 at 2:05 AM Emily via ffmpeg-devel wrote: > > From: Emily > > --- > In the NixOS FFmpeg package, we run `make check` without downloading > the entire FATE suite. The FFmpeg 7.1 update broke this, seemingly > because of an undeclared FATE sample dependency. > > This package is my best‐guess attempt at fixing that based on the > other commits and files that I read. I didn’t see any existing > commit or patch for this, so I’m sending it upstream in case it > is of any use. It should be backported to the 7.1 branch if applied; > let me know if there’s anything special I need to do for that. > > I’m not particularly familiar with FFmpeg’s build system or > `git send-email`, so apologies if I messed anything up here. > Just noticed that this patch already existed thanks to Anton mentioning it on IRC today. The change seems exactly the same that I posted my patch for as this issue was reported on IRC on Sunday, so that wise you can consider this an LGTM from me. Will just do final checks and apply this one to master and release/7.1, as it precedes mine :) . Jan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/5] libavcodec/ffv1: Support storing LSB raw
Le 16/10/2024 à 22:53, Michael Niedermayer a écrit : what are you testing? the new code is faster than the old code. There is something not right here, the range coder based implementation i posted now is 5% faster then the range coder based one i posted earlier today thats overall speed meassured with "time ./ffmpeg" if you see no difference there is something fishy I tested your latest "8/8" and "5/5" patches, I don't see a big difference on ~50 frames. ~20% but the "bitfield" version is ~27%. I wonder if it is due to the fact that you test with 1 frame only. i simply tested this: ./ffmpeg -i rawsamples/16/01.dpx -threads 1 -c:v ffv1 -context 1 -coder 1 -strict -2 -level 4 -rawlsb 4 -y /tmp/speedtest4.nut I use this command too except -threads 1, I use all threads. GCC 11, Ubuntu on Windows. It uses 1 thread as the speed with more threads was very unstable between runs and we want to know how fast ffv1 is not how multithreading behaves Less unstable with more frames :). Maybe the impact is different between using 1 thread only and all threads, but at the end we want to have the best speed compared to compression when all threads are used, not with only one thread. I tested with 1 thread on 1 frame, FFmpeg + master + put_rac_raw/get_rac_raw from a previous patch + the latest patch sent (8/8 Oct 16) - 0m9.754s without -strict -2 -level 4 -rawlsb 4 - 0m8.542s with -strict -2 -level 4 -rawlsb 4 Worse, only 13% improvement instead of 25% from bitfield patch. can this content be downloaded somewhere ? Not publicly (I try to have something publicly available). Jérôme ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] tests/fate-run: Fix pixdesc failure
From: Zhao Zhili
-u and -q doesn't work together for diff on macOS.
---
tests/fate-run.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index f8d67de25a..c371bd1c3c 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -519,7 +519,7 @@ pixdesc(){
$FLAGS $ENC_OPTS -vf "scale,format=$pix_fmt,pixdesctest" -vcodec
rawvideo -frames:v 5 \
"-pix_fmt $pix_fmt" -f nut md5:$md5file2
-diff -u -q $md5file1 $md5file2 || return
+diff -q $md5file1 $md5file2 || return
printf '%-20s' $label
cat $md5file1
}
--
2.46.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] tests/fate-run: Fix pixdesc failure
On 10/21/2024 2:03 PM, Zhao Zhili wrote:
From: Zhao Zhili
-u and -q doesn't work together for diff on macOS.
Lovely.
---
tests/fate-run.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index f8d67de25a..c371bd1c3c 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -519,7 +519,7 @@ pixdesc(){
$FLAGS $ENC_OPTS -vf "scale,format=$pix_fmt,pixdesctest" -vcodec
rawvideo -frames:v 5 \
"-pix_fmt $pix_fmt" -f nut md5:$md5file2
-diff -u -q $md5file1 $md5file2 || return
+diff -q $md5file1 $md5file2 || return
printf '%-20s' $label
cat $md5file1
}
LGTM
OpenPGP_signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] swscale/swscale_unscaled: fix shift values in planarToP01xWrapper
On 10/21/2024 10:26 AM, James Almer wrote: The current calculation was a no-op, setting the entire array to 0. Use the shift value from the dest descriptor, as the source one is planar with no shifts whatsoever. Disregard this patch, i tested i wrong. OpenPGP_signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fate/ffmpeg: add samples dependency to fate-ffmpeg-spec-disposition
On Mon, Oct 21, 2024 at 9:05 PM Jan Ekström wrote: > > On Mon, Oct 7, 2024 at 2:05 AM Emily via ffmpeg-devel > wrote: > > > > From: Emily > > > > --- > > In the NixOS FFmpeg package, we run `make check` without downloading > > the entire FATE suite. The FFmpeg 7.1 update broke this, seemingly > > because of an undeclared FATE sample dependency. > > > > This package is my best‐guess attempt at fixing that based on the > > other commits and files that I read. I didn’t see any existing > > commit or patch for this, so I’m sending it upstream in case it > > is of any use. It should be backported to the 7.1 branch if applied; > > let me know if there’s anything special I need to do for that. > > > > I’m not particularly familiar with FFmpeg’s build system or > > `git send-email`, so apologies if I messed anything up here. > > > > Just noticed that this patch already existed thanks to Anton > mentioning it on IRC today. > > The change seems exactly the same that I posted my patch for as this > issue was reported on IRC on Sunday, so that wise you can consider > this an LGTM from me. > > Will just do final checks and apply this one to master and > release/7.1, as it precedes mine :) . Verified that the diff indeed matches, applied this patch with a minor addition in the commit message as 3565903c638fb77d600d2983701b12300e695a5d to master and as 9fbbd924f2863312b41303a48705b252b7ee1193 to release/7.1. Thanks for contributing this fix and sorry it took a while for it to get noticed :) . Jan ___ 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] fate/ffmpeg: add samples requirement to fate-ffmpeg-spec-disposition
On Sun, Oct 20, 2024 at 11:33 PM Jan Ekström wrote: > > This tests utilizes an MPEG-TS sample from FATE suite, yet is > marked as not requiring samples. > > This fixes running `make fate` without SAMPLES being set. > > Reported-by: Sebastian Ramacher > --- Superceded by the earlier patch sent by Emily which is now applied to both master and release/7.1. Jan ___ 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] Add support for LJ92 compressed MLV files
ffmpeg has existing support for MLV raw video files; libavformat/mlvdec.c.
Since this was added, MLV has been extended to support LJ92 compressed
image data. These patches build on lossless DNG support in 7.2-dev to
enable handling LJ92 MLV via existing libavcodec/mjpegdec.c code.
I can provide MLV sample files if desired, being raw video these tend to be
large.
Thanks to JEEB and Lynne for help via IRC.
From 94ce8688af3a2c748de4021687b5d45a0a6b7be2 Mon Sep 17 00:00:00 2001
From: stephen-e <33672591+reticulatedpi...@users.noreply.github.com>
Date: Mon, 21 Oct 2024 16:35:49 +0100
Subject: [PATCH 2/2] avformat/mlvdec: add LJ92 support
MLV files can contain LJ92 compressed raw video data.
MJPEG codec can be used to handle these.
---
libavformat/mlvdec.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/libavformat/mlvdec.c b/libavformat/mlvdec.c
index 1a6d38f37c..2eb21a3aab 100644
--- a/libavformat/mlvdec.c
+++ b/libavformat/mlvdec.c
@@ -44,8 +44,9 @@
#define MLV_AUDIO_CLASS_WAV 1
-#define MLV_CLASS_FLAG_DELTA 0x40
#define MLV_CLASS_FLAG_LZMA 0x80
+#define MLV_CLASS_FLAG_DELTA 0x40
+#define MLV_CLASS_FLAG_LJ92 0x20
typedef struct {
AVIOContext *pb[101];
@@ -298,9 +299,12 @@ static int read_header(AVFormatContext *avctx)
if ((mlv->class[0] & (MLV_CLASS_FLAG_DELTA|MLV_CLASS_FLAG_LZMA)))
avpriv_request_sample(avctx, "compression");
vst->codecpar->codec_type = AVMEDIA_TYPE_VIDEO;
-switch (mlv->class[0] & ~(MLV_CLASS_FLAG_DELTA|MLV_CLASS_FLAG_LZMA)) {
+switch (mlv->class[0] & ~(MLV_CLASS_FLAG_DELTA|MLV_CLASS_FLAG_LZMA|MLV_CLASS_FLAG_LJ92)) {
case MLV_VIDEO_CLASS_RAW:
-vst->codecpar->codec_id = AV_CODEC_ID_RAWVIDEO;
+if (mlv->class[0] & MLV_CLASS_FLAG_LJ92)
+vst->codecpar->codec_id = AV_CODEC_ID_MJPEG;
+else
+vst->codecpar->codec_id = AV_CODEC_ID_RAWVIDEO;
break;
case MLV_VIDEO_CLASS_YUV:
vst->codecpar->format = AV_PIX_FMT_YUV420P;
--
2.45.2
From bda19449cce6ae028ef751f0f4f21da63214ab3f Mon Sep 17 00:00:00 2001
From: stephen-e <33672591+reticulatedpi...@users.noreply.github.com>
Date: Mon, 21 Oct 2024 16:32:01 +0100
Subject: [PATCH 1/2] avcodec/mjpegdec: set bayer flag based on pix_fmt
dng_decode_jpeg() does this directly in tiff.c,
this change allows signalling via the pixel format
(to support LJ92 compressed raw video in MLV containers,
which is the next commit).
---
libavcodec/mjpegdec.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 86ec58713c..9c990f3e03 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -409,6 +409,15 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
return AVERROR_PATCHWELCOME;
}
+// If the given pixel format is Bayer, set the flag (this makes LJ92 MLV files work)
+s->pix_desc = av_pix_fmt_desc_get(s->avctx->pix_fmt);
+if (!s->pix_desc) {
+av_log(s->avctx, AV_LOG_ERROR, "Could not get a pixel format descriptor.\n");
+return AVERROR_BUG;
+}
+if (s->pix_desc->flags & AV_PIX_FMT_FLAG_BAYER)
+s->bayer = 1;
+
if (s->bayer) {
if (nb_components == 2) {
/* Bayer images embedded in DNGs can contain 2 interleaved components and the
@@ -718,12 +727,6 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
s->avctx->pix_fmt = AV_PIX_FMT_GRAY16;
}
-s->pix_desc = av_pix_fmt_desc_get(s->avctx->pix_fmt);
-if (!s->pix_desc) {
-av_log(s->avctx, AV_LOG_ERROR, "Could not get a pixel format descriptor.\n");
-return AVERROR_BUG;
-}
-
if (s->avctx->pix_fmt == s->hwaccel_sw_pix_fmt && !size_change) {
s->avctx->pix_fmt = s->hwaccel_pix_fmt;
} else {
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v12 5/9] libavcodec/dnxucdec: DNxUncompressed decoder
On 22.10.24 00:31, James Almer wrote:
On 10/21/2024 8:40 PM, martin schitter wrote:
On 21.10.24 22:44, James Almer wrote:
That's not good...
[...]
Whenever and however I change it, there will allways be somebody who
doesn't like it. !:(
My point is, it's not a good idea to commit code that's not tested.
Assuming that's what you meant.
Yes -- I also don't like to publish untested code.
Unfortunately I do not have access to any software, which could produce
the needed samples. But I was looking at least for very similar code
structures -- e.g. RGB / YUV 4:4:4 similarities.
But I definitely will not work on more complex feature suport (like the
combined components etc.) without real world samples.
All the possible output variants of DaVinci resolve are tested and work!
There still some unpleasant color deviations noticeable in some cases,
but that's mainly caused elsewhere.
I personally still think it would wise to support just a minimal but
carefully and systematically chosen set of internal pixel formats for
lossless and efficient processing and avoid all other very similar
combinatorial possibilities, but those other reviewer strictly denied
this view.
Yes, i agree. But what gets committed should be know to work.
I hope, that's the case!
+ break;
+ case MKTAG('y','2','1','6'):
+ ret = fmt_frame(avctx, frame, avpkt,
AV_PIX_FMT_UYVY422_16LE, 32, pass_through);
The order of y216 appears to be YUYV, not UYVY. https://
learn.microsoft.com/en-us/windows/win32/medfound/10-bit-and-16-bit-
yuv- video-formats
Please also read the SMPTE RDD 50 specification as well!
(https://pub.smpte.org/doc/rdd50/20190730-pub/rdd50-2019.pdf)
But in fact I would even more suggest looking at the well structured
system of vulkan pixel formats!
I simply had to implement all this additional pixel formats, because
the byte order of already defined varaints were indeed different. And
you can't simply ignore this fact, if you want to handle the raw data
stream without any other kind of local modification.
Ok, looks like that spec defined some crazy packing and reused existing
naming schemes. Great.
Yes -- this super dense bit packing looks really crazy in case of an
otherwise extremely bloated "uncompressed" and not just "lossless"
format. But it's still more are less the only option to export all these
different pixel formats (especially the more advanced floating point
ones) together with additional audio, TC etc. out of popular closed
source solutions until now.
and btw.: FOURCC is naturally case-sensitive ;)
If you're going to unpack these MSB and LSB blocks so the output may be
something that can be used by an AVPixFmtDescriptor, then might as well
not add so many new pixel formats that will see no other use and instead
rely on existing, widely supported ones. As in:
+ case MKTAG('y','2','1','6'):
+ ret = fmt_frame(avctx, frame, avpkt,
AV_PIX_FMT_UYVY422_16LE, 32, pass_through);
+ break;
You could unpack this into AV_PIX_FMT_YUV422P16LE.
This was exactly my suggestion in the version v10 of these patch series,
but others didn't like it.
+ case MKTAG('y','4','0','8'):
+ ret = fmt_frame(avctx, frame, avpkt, AV_PIX_FMT_YUV444,
24, pass_through);
+ break;
You could rearrange this into AV_PIX_FMT_VYU444, or unpack into
AV_PIX_FMT_YUV444P.
I know -- it's trivial to choose this way, but there has to be some
common agreement or docu, how it should be done, otherwise we run circles.
You could unpack this into AV_PIX_FMT_YUV444P16LE, or rearrange it into
AV_PIX_FMT_AYUV64 (setting the alpha channel to opaque).
detto
The float ones are ok since we have no YUV float formats. But in any
case, I'd like to hear what others think.
I'm also interested, how others think about this topic.
In case of the Float variants I'm not really happy about this actual
implementation, because the imported data gets modified in a lossy
manner by the 16bit integer conversion in this case. This doesn't make
any visible difference in practice, but it simply shouldn't happen
nowadays high-end workflows.
I really hope to work around this issue by an additional vulkan
implementation in the long run.
Thanks for your work.
___
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 v12 5/9] libavcodec/dnxucdec: DNxUncompressed decoder
On 10/21/2024 10:02 PM, martin schitter wrote:
On 22.10.24 00:31, James Almer wrote:
On 10/21/2024 8:40 PM, martin schitter wrote:
On 21.10.24 22:44, James Almer wrote:
That's not good...
[...]
Whenever and however I change it, there will allways be somebody who
doesn't like it. !:(
My point is, it's not a good idea to commit code that's not tested.
Assuming that's what you meant.
Yes -- I also don't like to publish untested code.
Unfortunately I do not have access to any software, which could produce
the needed samples. But I was looking at least for very similar code
structures -- e.g. RGB / YUV 4:4:4 similarities.
But I definitely will not work on more complex feature suport (like the
combined components etc.) without real world samples.
All the possible output variants of DaVinci resolve are tested and work!
There still some unpleasant color deviations noticeable in some cases,
but that's mainly caused elsewhere.
I personally still think it would wise to support just a minimal but
carefully and systematically chosen set of internal pixel formats for
lossless and efficient processing and avoid all other very similar
combinatorial possibilities, but those other reviewer strictly denied
this view.
Yes, i agree. But what gets committed should be know to work.
I hope, that's the case!
+ break;
+ case MKTAG('y','2','1','6'):
+ ret = fmt_frame(avctx, frame, avpkt,
AV_PIX_FMT_UYVY422_16LE, 32, pass_through);
The order of y216 appears to be YUYV, not UYVY. https://
learn.microsoft.com/en-us/windows/win32/medfound/10-bit-and-16-bit-
yuv- video-formats
Please also read the SMPTE RDD 50 specification as well!
(https://pub.smpte.org/doc/rdd50/20190730-pub/rdd50-2019.pdf)
But in fact I would even more suggest looking at the well structured
system of vulkan pixel formats!
I simply had to implement all this additional pixel formats, because
the byte order of already defined varaints were indeed different. And
you can't simply ignore this fact, if you want to handle the raw data
stream without any other kind of local modification.
Ok, looks like that spec defined some crazy packing and reused
existing naming schemes. Great.
Yes -- this super dense bit packing looks really crazy in case of an
otherwise extremely bloated "uncompressed" and not just "lossless"
format. But it's still more are less the only option to export all these
different pixel formats (especially the more advanced floating point
ones) together with additional audio, TC etc. out of popular closed
source solutions until now.
and btw.: FOURCC is naturally case-sensitive ;)
If you're going to unpack these MSB and LSB blocks so the output may
be something that can be used by an AVPixFmtDescriptor, then might as
well not add so many new pixel formats that will see no other use and
instead rely on existing, widely supported ones. As in:
+ case MKTAG('y','2','1','6'):
+ ret = fmt_frame(avctx, frame, avpkt,
AV_PIX_FMT_UYVY422_16LE, 32, pass_through);
+ break;
You could unpack this into AV_PIX_FMT_YUV422P16LE.
This was exactly my suggestion in the version v10 of these patch series,
but others didn't like it.
+ case MKTAG('y','4','0','8'):
+ ret = fmt_frame(avctx, frame, avpkt, AV_PIX_FMT_YUV444,
24, pass_through);
+ break;
You could rearrange this into AV_PIX_FMT_VYU444, or unpack into
AV_PIX_FMT_YUV444P.
I know -- it's trivial to choose this way, but there has to be some
common agreement or docu, how it should be done, otherwise we run circles.
I didn't participate in earlier rounds, but at least my opinion is that
we shouldn't add new pixel formats if they are only used for a single
codec and have no RIFF or ISOBMFF mapping.
fwiw, YUV444 is fine as a name if we end up adding it, but i dislike
UYVY422_16 and YUV444_16.
Unfortunately we can't use Y216 (Would need to match existing Y210 and
Y212, which are ordered YUYV), or Y416 (ISOBMFF mapped it to AYUV64).
You could unpack this into AV_PIX_FMT_YUV444P16LE, or rearrange it
into AV_PIX_FMT_AYUV64 (setting the alpha channel to opaque).
detto
The float ones are ok since we have no YUV float formats. But in any
case, I'd like to hear what others think.
I'm also interested, how others think about this topic.
In case of the Float variants I'm not really happy about this actual
implementation, because the imported data gets modified in a lossy
manner by the 16bit integer conversion in this case. This doesn't make
any visible difference in practice, but it simply shouldn't happen
nowadays high-end workflows.
I really hope to work around this issue by an additional vulkan
implementation in the long run.
Thanks for your work.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ff
[FFmpeg-devel] [PATCH 1/5] avutil: add hwcontext_amf.
Adds hwcontext_amf, which allows to use shared AMF
context for the encoder, decoder and AMF-based filters,
without copy to the host memory.
It will also allow you to use some optimisations in
the interaction of components (for example, SAV) and make a more
manageable and optimal setup for using GPU devices with AMF
in the case of a fully AMF pipeline.
It will be a significant performance uplift when full AMF pipeline
with filters is used.
We also plan to add Compression artefact removal filter in near feature.
v2: cleanup header files
v3: an unnecessary class has been removed.
---
libavutil/Makefile | 4 +
libavutil/hwcontext.c | 4 +
libavutil/hwcontext.h | 1 +
libavutil/hwcontext_amf.c | 546 +
libavutil/hwcontext_amf.h | 45 +++
libavutil/hwcontext_amf_internal.h | 44 +++
libavutil/hwcontext_internal.h | 1 +
libavutil/pixdesc.c| 4 +
libavutil/pixfmt.h | 5 +
9 files changed, 654 insertions(+)
create mode 100644 libavutil/hwcontext_amf.c
create mode 100644 libavutil/hwcontext_amf.h
create mode 100644 libavutil/hwcontext_amf_internal.h
diff --git a/libavutil/Makefile b/libavutil/Makefile
index 847878d7a4..2992b53277 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -46,6 +46,7 @@ HEADERS = adler32.h
\
hwcontext_d3d12va.h \
hwcontext_drm.h \
hwcontext_dxva2.h \
+ hwcontext_amf.h \
hwcontext_qsv.h \
hwcontext_mediacodec.h\
hwcontext_opencl.h\
@@ -196,6 +197,7 @@ OBJS-$(CONFIG_CUDA) += hwcontext_cuda.o
OBJS-$(CONFIG_D3D11VA) += hwcontext_d3d11va.o
OBJS-$(CONFIG_D3D12VA) += hwcontext_d3d12va.o
OBJS-$(CONFIG_DXVA2)+= hwcontext_dxva2.o
+OBJS-$(CONFIG_AMF) += hwcontext_amf.o
OBJS-$(CONFIG_LIBDRM) += hwcontext_drm.o
OBJS-$(CONFIG_MACOS_KPERF) += macos_kperf.o
OBJS-$(CONFIG_MEDIACODEC) += hwcontext_mediacodec.o
@@ -220,6 +222,8 @@ SKIPHEADERS-$(CONFIG_CUDA) +=
hwcontext_cuda_internal.h \
SKIPHEADERS-$(CONFIG_D3D11VA) += hwcontext_d3d11va.h
SKIPHEADERS-$(CONFIG_D3D12VA) += hwcontext_d3d12va.h
SKIPHEADERS-$(CONFIG_DXVA2)+= hwcontext_dxva2.h
+SKIPHEADERS-$(CONFIG_AMF) += hwcontext_amf.h \
+ hwcontext_amf_internal
SKIPHEADERS-$(CONFIG_QSV) += hwcontext_qsv.h
SKIPHEADERS-$(CONFIG_OPENCL) += hwcontext_opencl.h
SKIPHEADERS-$(CONFIG_VAAPI)+= hwcontext_vaapi.h
diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
index fa99a0d8a4..f06d49c45c 100644
--- a/libavutil/hwcontext.c
+++ b/libavutil/hwcontext.c
@@ -65,6 +65,9 @@ static const HWContextType * const hw_table[] = {
#endif
#if CONFIG_VULKAN
&ff_hwcontext_type_vulkan,
+#endif
+#if CONFIG_AMF
+&ff_hwcontext_type_amf,
#endif
NULL,
};
@@ -82,6 +85,7 @@ static const char *const hw_type_names[] = {
[AV_HWDEVICE_TYPE_VIDEOTOOLBOX] = "videotoolbox",
[AV_HWDEVICE_TYPE_MEDIACODEC] = "mediacodec",
[AV_HWDEVICE_TYPE_VULKAN] = "vulkan",
+[AV_HWDEVICE_TYPE_AMF] = "amf",
};
typedef struct FFHWDeviceContext {
diff --git a/libavutil/hwcontext.h b/libavutil/hwcontext.h
index bac30debae..96042ba197 100644
--- a/libavutil/hwcontext.h
+++ b/libavutil/hwcontext.h
@@ -38,6 +38,7 @@ enum AVHWDeviceType {
AV_HWDEVICE_TYPE_MEDIACODEC,
AV_HWDEVICE_TYPE_VULKAN,
AV_HWDEVICE_TYPE_D3D12VA,
+AV_HWDEVICE_TYPE_AMF,
};
/**
diff --git a/libavutil/hwcontext_amf.c b/libavutil/hwcontext_amf.c
new file mode 100644
index 00..2491e968ae
--- /dev/null
+++ b/libavutil/hwcontext_amf.c
@@ -0,0 +1,546 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
[FFmpeg-devel] [PATCH 2/5] avcodec: add amfdec.
From: Evgeny Pavlov Added AMF based h264, hevc, av1 decoders. Co-authored-by: Dmitrii Ovchinnikov v2: added encoder reinitialisation v3: use AMF_SURFACE_UNKNOWN to int decoder(ctx->output_format before) --- configure | 3 + libavcodec/Makefile| 7 +- libavcodec/allcodecs.c | 3 + libavcodec/amfdec.c| 624 + libavcodec/amfdec.h| 61 5 files changed, 696 insertions(+), 2 deletions(-) create mode 100644 libavcodec/amfdec.c create mode 100644 libavcodec/amfdec.h diff --git a/configure b/configure index 9f508a2527..3c92fb6a04 100755 --- a/configure +++ b/configure @@ -3343,6 +3343,7 @@ amrnb_mediacodec_decoder_select="amr_parser" amrwb_mediacodec_decoder_deps="mediacodec" amrwb_mediacodec_decoder_select="amr_parser" av1_amf_encoder_deps="amf" +av1_amf_decoder_deps="amf" av1_cuvid_decoder_deps="cuvid CUVIDAV1PICPARAMS" av1_mediacodec_decoder_deps="mediacodec" av1_mediacodec_encoder_deps="mediacodec" @@ -3358,6 +3359,7 @@ av1_vaapi_encoder_select="cbs_av1 vaapi_encode" h263_v4l2m2m_decoder_deps="v4l2_m2m h263_v4l2_m2m" h263_v4l2m2m_encoder_deps="v4l2_m2m h263_v4l2_m2m" h264_amf_encoder_deps="amf" +h264_amf_decoder_deps="amf" h264_cuvid_decoder_deps="cuvid" h264_cuvid_decoder_select="h264_mp4toannexb_bsf" h264_mediacodec_decoder_deps="mediacodec" @@ -3379,6 +3381,7 @@ h264_v4l2m2m_decoder_deps="v4l2_m2m h264_v4l2_m2m" h264_v4l2m2m_decoder_select="h264_mp4toannexb_bsf" h264_v4l2m2m_encoder_deps="v4l2_m2m h264_v4l2_m2m" hevc_amf_encoder_deps="amf" +hevc_amf_decoder_deps="amf" hevc_cuvid_decoder_deps="cuvid" hevc_cuvid_decoder_select="hevc_mp4toannexb_bsf" hevc_d3d12va_encoder_select="cbs_h265 d3d12va_encode" diff --git a/libavcodec/Makefile b/libavcodec/Makefile index dd5d0de898..a651e366f5 100644 --- a/libavcodec/Makefile +++ b/libavcodec/Makefile @@ -75,7 +75,7 @@ include $(SRC_PATH)/libavcodec/vulkan/Makefile OBJS-$(CONFIG_AANDCTTABLES)+= aandcttab.o OBJS-$(CONFIG_AC3DSP) += ac3dsp.o ac3.o ac3tab.o OBJS-$(CONFIG_ADTS_HEADER) += adts_header.o mpeg4audio_sample_rates.o -OBJS-$(CONFIG_AMF) += amfenc.o +OBJS-$(CONFIG_AMF) += amfenc.o amfdec.o OBJS-$(CONFIG_AUDIO_FRAME_QUEUE) += audio_frame_queue.o OBJS-$(CONFIG_ATSC_A53)+= atsc_a53.o OBJS-$(CONFIG_AUDIODSP)+= audiodsp.o @@ -172,6 +172,7 @@ OBJS-$(CONFIG_TEXTUREDSPENC) += texturedspenc.o OBJS-$(CONFIG_TPELDSP) += tpeldsp.o OBJS-$(CONFIG_VAAPI_ENCODE)+= vaapi_encode.o hw_base_encode.o OBJS-$(CONFIG_AV1_AMF_ENCODER) += amfenc_av1.o +OBJS-$(CONFIG_AV1_AMF_DECODER) += amfdec.o OBJS-$(CONFIG_VC1DSP) += vc1dsp.o OBJS-$(CONFIG_VIDEODSP)+= videodsp.o OBJS-$(CONFIG_VP3DSP) += vp3dsp.o @@ -417,6 +418,7 @@ OBJS-$(CONFIG_H264_DECODER)+= h264dec.o h264_cabac.o h264_cavlc.o \ h264_refs.o \ h264_slice.o h264data.o h274.o OBJS-$(CONFIG_H264_AMF_ENCODER)+= amfenc_h264.o +OBJS-$(CONFIG_H264_AMF_DECODER)+= amfdec.o OBJS-$(CONFIG_H264_CUVID_DECODER) += cuviddec.o OBJS-$(CONFIG_H264_MEDIACODEC_DECODER) += mediacodecdec.o OBJS-$(CONFIG_H264_MEDIACODEC_ENCODER) += mediacodecenc.o @@ -443,6 +445,7 @@ OBJS-$(CONFIG_HDR_DECODER) += hdrdec.o OBJS-$(CONFIG_HDR_ENCODER) += hdrenc.o OBJS-$(CONFIG_HEVC_DECODER)+= aom_film_grain.o h274.o container_fifo.o OBJS-$(CONFIG_HEVC_AMF_ENCODER)+= amfenc_hevc.o +OBJS-$(CONFIG_HEVC_AMF_DECODER)+= amfdec.o OBJS-$(CONFIG_HEVC_CUVID_DECODER) += cuviddec.o OBJS-$(CONFIG_HEVC_D3D12VA_ENCODER)+= d3d12va_encode_hevc.o h265_profile_level.o \ h2645data.o @@ -1278,7 +1281,7 @@ SKIPHEADERS+= %_tablegen.h \ bitstream_template.h \ $(ARCH)/vpx_arith.h \ -SKIPHEADERS-$(CONFIG_AMF) += amfenc.h +SKIPHEADERS-$(CONFIG_AMF) += amfenc.h amfdec.h SKIPHEADERS-$(CONFIG_D3D11VA) += d3d11va.h dxva2_internal.h SKIPHEADERS-$(CONFIG_D3D12VA) += d3d12va_decode.h d3d12va_encode.h SKIPHEADERS-$(CONFIG_DXVA2)+= dxva2.h dxva2_internal.h diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c index c7e5f9910c..8266b56d22 100644 --- a/libavcodec/allcodecs.c +++ b/libavcodec/allcodecs.c @@ -840,11 +840,13 @@ extern const FFCodec ff_av1_nvenc_encoder; extern const FFCodec ff_av1_qsv_decoder; extern const FFCodec ff_av1_qsv_encoder; extern const FFCodec ff_av1_amf_encoder; +extern const FFCodec ff_av1_amf_decoder; extern const FFCodec ff_av1_mf_encoder; extern const FFCodec ff_av1_vaapi_encoder; extern const FFCodec f
[FFmpeg-devel] [PATCH 3/5] avfilter/scale_amf: Add AMF VPP & super resolution filters
From: Evgeny Pavlov
This commit adds two AMF filters: vpp_amf & sr_amf.
Both filters are using AMF hardware acceleration.
vpp_amf supports simple scaling algorithms & color conversion.
sr_amf supports advanced scaling algorithms such as FSR & can
be used for upscaling only.
---
configure | 1 +
libavfilter/Makefile| 2 +
libavfilter/allfilters.c| 2 +
libavfilter/vf_amf_common.c | 512
libavfilter/vf_amf_common.h | 73 +
libavfilter/vf_sr_amf.c | 189 +
libavfilter/vf_vpp_amf.c| 264 +++
7 files changed, 1043 insertions(+)
create mode 100644 libavfilter/vf_amf_common.c
create mode 100644 libavfilter/vf_amf_common.h
create mode 100644 libavfilter/vf_sr_amf.c
create mode 100644 libavfilter/vf_vpp_amf.c
diff --git a/configure b/configure
index 3c92fb6a04..19a6f0ceda 100755
--- a/configure
+++ b/configure
@@ -3949,6 +3949,7 @@ rubberband_filter_deps="librubberband"
sab_filter_deps="gpl swscale"
scale2ref_filter_deps="swscale"
scale_filter_deps="swscale"
+scale_amf_filter_deps="amf"
scale_qsv_filter_deps="libmfx"
scale_qsv_filter_select="qsvvpp"
scdet_filter_select="scene_sad"
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 4d9681768b..979a8876a8 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -504,6 +504,7 @@ OBJS-$(CONFIG_SITI_FILTER) += vf_siti.o
OBJS-$(CONFIG_SPLIT_FILTER) += split.o
OBJS-$(CONFIG_SPP_FILTER)+= vf_spp.o qp_table.o
OBJS-$(CONFIG_SR_FILTER) += vf_sr.o
+OBJS-$(CONFIG_SR_AMF_FILTER) += vf_sr_amf.o scale_eval.o
vf_amf_common.o
OBJS-$(CONFIG_SSIM_FILTER) += vf_ssim.o framesync.o
OBJS-$(CONFIG_SSIM360_FILTER)+= vf_ssim360.o framesync.o
OBJS-$(CONFIG_STEREO3D_FILTER) += vf_stereo3d.o
@@ -557,6 +558,7 @@ OBJS-$(CONFIG_VIDSTABTRANSFORM_FILTER) +=
vidstabutils.o vf_vidstabtransfo
OBJS-$(CONFIG_VIF_FILTER)+= vf_vif.o framesync.o
OBJS-$(CONFIG_VIGNETTE_FILTER) += vf_vignette.o
OBJS-$(CONFIG_VMAFMOTION_FILTER) += vf_vmafmotion.o framesync.o
+OBJS-$(CONFIG_VPP_AMF_FILTER)+= vf_vpp_amf.o scale_eval.o
vf_amf_common.o
OBJS-$(CONFIG_VPP_QSV_FILTER)+= vf_vpp_qsv.o
OBJS-$(CONFIG_VSTACK_FILTER) += vf_stack.o framesync.o
OBJS-$(CONFIG_W3FDIF_FILTER) += vf_w3fdif.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 9819f0f95b..7929444371 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -431,6 +431,8 @@ extern const AVFilter ff_vf_roberts_opencl;
extern const AVFilter ff_vf_rotate;
extern const AVFilter ff_vf_sab;
extern const AVFilter ff_vf_scale;
+extern const AVFilter ff_vf_vpp_amf;
+extern const AVFilter ff_vf_sr_amf;
extern const AVFilter ff_vf_scale_cuda;
extern const AVFilter ff_vf_scale_npp;
extern const AVFilter ff_vf_scale_qsv;
diff --git a/libavfilter/vf_amf_common.c b/libavfilter/vf_amf_common.c
new file mode 100644
index 00..d519e50cfb
--- /dev/null
+++ b/libavfilter/vf_amf_common.c
@@ -0,0 +1,512 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "vf_amf_common.h"
+
+#include "libavutil/avassert.h"
+#include "avfilter.h"
+#include "avfilter_internal.h"
+#include "formats.h"
+#include "libavutil/mem.h"
+#include "libavutil/imgutils.h"
+
+#include "libavutil/hwcontext_amf.h"
+#include "libavutil/hwcontext_amf_internal.h"
+#include "AMF/components/ColorSpace.h"
+#include "scale_eval.h"
+
+#if CONFIG_DXVA2
+#include
+#endif
+
+#if CONFIG_D3D11VA
+#include
+#endif
+
+int amf_filter_init(AVFilterContext *avctx)
+{
+AMFFilterContext *ctx = avctx->priv;
+
+if (!strcmp(ctx->format_str, "same")) {
+ctx->format = AV_PIX_FMT_NONE;
+} else {
+ctx->format = av_get_pix_fmt(ctx->format_str);
+if (ctx->format == AV_PIX_FMT_NONE) {
+av_log(avctx, AV_LOG_ERROR, "Unrecognized pixel format: %s\n",
ctx->format_str);
+return AVERROR(EINVAL);
+}
+}
+
+return 0;
+}
+
+void amf_filter_uninit(AVFilterContext *avctx)
+{
+AMFFilterContext
[FFmpeg-devel] [PATCH 5/5] avcodec/amfenc: redesign to use hwcontext_amf.
Co-authored-by: Evgeny Pavlov
v3: cleanup code
---
libavcodec/amfenc.c | 520 +--
libavcodec/amfenc.h | 29 +--
libavcodec/amfenc_av1.c | 8 +-
libavcodec/amfenc_h264.c | 6 +-
libavcodec/amfenc_hevc.c | 6 +-
5 files changed, 132 insertions(+), 437 deletions(-)
diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
index 225fb9df27..8632cb53c1 100644
--- a/libavcodec/amfenc.c
+++ b/libavcodec/amfenc.c
@@ -22,6 +22,8 @@
#include "libavutil/avassert.h"
#include "libavutil/imgutils.h"
#include "libavutil/hwcontext.h"
+#include "libavutil/hwcontext_amf.h"
+#include "libavutil/hwcontext_amf_internal.h"
#if CONFIG_D3D11VA
#include "libavutil/hwcontext_d3d11va.h"
#endif
@@ -112,288 +114,18 @@ const enum AVPixelFormat ff_amf_pix_fmts[] = {
AV_PIX_FMT_DXVA2_VLD,
#endif
AV_PIX_FMT_P010,
+AV_PIX_FMT_AMF_SURFACE,
AV_PIX_FMT_NONE
};
-typedef struct FormatMap {
-enum AVPixelFormat av_format;
-enum AMF_SURFACE_FORMAT amf_format;
-} FormatMap;
-
-static const FormatMap format_map[] =
-{
-{ AV_PIX_FMT_NONE, AMF_SURFACE_UNKNOWN },
-{ AV_PIX_FMT_NV12, AMF_SURFACE_NV12 },
-{ AV_PIX_FMT_P010, AMF_SURFACE_P010 },
-{ AV_PIX_FMT_BGR0, AMF_SURFACE_BGRA },
-{ AV_PIX_FMT_RGB0, AMF_SURFACE_RGBA },
-{ AV_PIX_FMT_GRAY8, AMF_SURFACE_GRAY8 },
-{ AV_PIX_FMT_YUV420P,AMF_SURFACE_YUV420P },
-{ AV_PIX_FMT_YUYV422,AMF_SURFACE_YUY2 },
-};
-
-static enum AMF_SURFACE_FORMAT amf_av_to_amf_format(enum AVPixelFormat fmt)
-{
-int i;
-for (i = 0; i < amf_countof(format_map); i++) {
-if (format_map[i].av_format == fmt) {
-return format_map[i].amf_format;
-}
-}
-return AMF_SURFACE_UNKNOWN;
-}
-
-static void AMF_CDECL_CALL AMFTraceWriter_Write(AMFTraceWriter *pThis,
-const wchar_t *scope, const wchar_t *message)
-{
-AmfTraceWriter *tracer = (AmfTraceWriter*)pThis;
-av_log(tracer->avctx, AV_LOG_DEBUG, "%ls: %ls", scope, message); // \n is
provided from AMF
-}
-
-static void AMF_CDECL_CALL AMFTraceWriter_Flush(AMFTraceWriter *pThis)
-{
-}
-
-static AMFTraceWriterVtbl tracer_vtbl =
-{
-.Write = AMFTraceWriter_Write,
-.Flush = AMFTraceWriter_Flush,
-};
-
-static int amf_load_library(AVCodecContext *avctx)
-{
-AmfContext*ctx = avctx->priv_data;
-AMFInit_Fn init_fun;
-AMFQueryVersion_Fn version_fun;
-AMF_RESULT res;
-
-ctx->delayed_frame = av_frame_alloc();
-if (!ctx->delayed_frame) {
-return AVERROR(ENOMEM);
-}
-// hardcoded to current HW queue size - will auto-realloc if too small
-ctx->timestamp_list = av_fifo_alloc2(avctx->max_b_frames + 16,
sizeof(int64_t),
- AV_FIFO_FLAG_AUTO_GROW);
-if (!ctx->timestamp_list) {
-return AVERROR(ENOMEM);
-}
-ctx->dts_delay = 0;
-
-
-ctx->library = dlopen(AMF_DLL_NAMEA, RTLD_NOW | RTLD_LOCAL);
-AMF_RETURN_IF_FALSE(ctx, ctx->library != NULL,
-AVERROR_UNKNOWN, "DLL %s failed to open\n", AMF_DLL_NAMEA);
-
-init_fun = (AMFInit_Fn)dlsym(ctx->library, AMF_INIT_FUNCTION_NAME);
-AMF_RETURN_IF_FALSE(ctx, init_fun != NULL, AVERROR_UNKNOWN, "DLL %s failed
to find function %s\n", AMF_DLL_NAMEA, AMF_INIT_FUNCTION_NAME);
-
-version_fun = (AMFQueryVersion_Fn)dlsym(ctx->library,
AMF_QUERY_VERSION_FUNCTION_NAME);
-AMF_RETURN_IF_FALSE(ctx, version_fun != NULL, AVERROR_UNKNOWN, "DLL %s
failed to find function %s\n", AMF_DLL_NAMEA, AMF_QUERY_VERSION_FUNCTION_NAME);
-
-res = version_fun(&ctx->version);
-AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "%s failed with
error %d\n", AMF_QUERY_VERSION_FUNCTION_NAME, res);
-res = init_fun(AMF_FULL_VERSION, &ctx->factory);
-AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "%s failed with
error %d\n", AMF_INIT_FUNCTION_NAME, res);
-res = ctx->factory->pVtbl->GetTrace(ctx->factory, &ctx->trace);
-AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "GetTrace()
failed with error %d\n", res);
-res = ctx->factory->pVtbl->GetDebug(ctx->factory, &ctx->debug);
-AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "GetDebug()
failed with error %d\n", res);
-return 0;
-}
-
-#if CONFIG_D3D11VA
-static int amf_init_from_d3d11_device(AVCodecContext *avctx,
AVD3D11VADeviceContext *hwctx)
-{
-AmfContext *ctx = avctx->priv_data;
-AMF_RESULT res;
-
-res = ctx->context->pVtbl->InitDX11(ctx->context, hwctx->device,
AMF_DX11_1);
-if (res != AMF_OK) {
-if (res == AMF_NOT_SUPPORTED)
-av_log(avctx, AV_LOG_ERROR, "AMF via D3D11 is not supported on the
given device.\n");
-else
-av_log(avctx, AV_LOG_ERROR, "AMF failed to initialise on the given
D3D11 device: %d.\n", res);
-return AVERROR(ENODEV);
-}
-
-return 0;
-}
-#endif
-
-#if CONFIG_DXVA2
-static int amf_init_from_dxva2_device(AVCodecCo
[FFmpeg-devel] [PATCH 4/5] doc/filters: Add documentation for AMF filters
From: Evgeny Pavlov
Signed-off-by: Evgeny Pavlov
---
doc/filters.texi | 238 +++
1 file changed, 238 insertions(+)
diff --git a/doc/filters.texi b/doc/filters.texi
index 428986a1e9..7d75ebfa3e 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -22827,6 +22827,76 @@ input upscaled using bicubic upscaling with proper
scale factor.
To get full functionality (such as async execution), please use the
@ref{dnn_processing} filter.
+@anchor{sr_amf}
+@section sr_amf
+
+Upscale (size increasing) for the input video using AMD Advanced Media
Framework library for hardware acceleration.
+Use advanced algorithms for upscaling with higher output quality.
+Setting the output width and height works in the same way as for the
@ref{scale} filter.
+
+The filter accepts the following options:
+@table @option
+@item w
+@item h
+Set the output video dimension expression. Default value is the input
dimension.
+
+Allows for the same expressions as the @ref{scale} filter.
+
+@item algorithm
+Sets the algorithm used for scaling:
+
+@table @var
+@item bilinear
+Bilinear
+
+@item bicubic
+Bicubic
+
+@item sr1-0
+Video SR1.0
+This is a default value
+
+@item point
+Point
+
+@item sr1-1
+Video SR1.1
+
+@end table
+
+@item sharpness
+Control hq scaler sharpening. The value is a float in the range of [0.0, 2.0]
+
+@item format
+Controls the output pixel format. By default, or if none is specified, the
input
+pixel format is used.
+
+@item keep-ratio
+Force the scaler to keep the aspect ratio of the input image when the output
size has a different aspect ratio.
+Default value is false.
+
+@item fill
+Specifies whether the output image outside the region of interest,
+which does not fill the entire output surface should be filled with a solid
color.
+
+@end table
+
+@subsection Examples
+
+@itemize
+@item
+Scale input to 720p, keeping aspect ratio and ensuring the output is yuv420p.
+@example
+sr_amf=-2:720:format=yuv420p
+@end example
+
+@item
+Upscale to 4K with algorithm video SR1.1.
+@example
+sr_amf=4096:2160:algorithm=sr1-1
+@end example
+@end itemize
+
@section ssim
Obtain the SSIM (Structural SImilarity Metric) between two input videos.
@@ -25565,6 +25635,174 @@ Example:
ffmpeg -i ref.mpg -vf vmafmotion -f null -
@end example
+@anchor{vpp_amf}
+@section vpp_amf
+
+Scale (resize) and convert colorspace, transfer characteristics or color
primaries for the input video, using AMD Advanced Media Framework library for
hardware acceleration.
+Setting the output width and height works in the same way as for the
@ref{scale} filter.
+
+The filter accepts the following options:
+@table @option
+@item w
+@item h
+Set the output video dimension expression. Default value is the input
dimension.
+
+Allows for the same expressions as the @ref{scale} filter.
+
+@item scale_type
+Sets the algorithm used for scaling:
+
+@table @var
+@item bilinear
+Bilinear
+
+This is the default.
+
+@item bicubic
+Bicubic
+
+@end table
+
+@item format
+Controls the output pixel format. By default, or if none is specified, the
input
+pixel format is used.
+
+
+@item force_original_aspect_ratio
+@item force_divisible_by
+Work the same as the identical @ref{scale} filter options.
+
+@anchor{color_profile}
+@item color_profile
+Specify all color properties at once.
+
+The accepted values are:
+@table @samp
+@item bt601
+BT.601
+
+@item bt709
+BT.709
+
+@item bt2020
+BT.2020
+
+@end table
+
+@anchor{trc}
+@item trc
+Specify output transfer characteristics.
+
+The accepted values are:
+@table @samp
+@item bt709
+BT.709
+
+@item gamma22
+Constant gamma of 2.2
+
+@item gamma28
+Constant gamma of 2.8
+
+@item smpte170m
+SMPTE-170M
+
+@item smpte240m
+SMPTE-240M
+
+@item linear
+Linear
+
+@item log
+LOG
+
+@item log-sqrt
+LOG_SQRT
+
+@item iec61966-2-4
+iec61966-2-4
+
+@item bt1361-ecg
+BT1361_ECG
+
+@item iec61966-2-1
+iec61966-2-1
+
+@item bt2020-10
+BT.2020 for 10-bits content
+
+@item bt2020-12
+BT.2020 for 12-bits content
+
+@item smpte2084
+SMPTE2084
+
+@item smpte428
+SMPTE428
+
+@item arib-std-b67
+ARIB_STD_B67
+
+@end table
+
+@anchor{primaries}
+@item primaries
+Specify output color primaries.
+
+The accepted values are:
+@table @samp
+@item bt709
+BT.709
+
+@item bt470m
+BT.470M
+
+@item bt470bg
+BT.470BG or BT.601-6 625
+
+@item smpte170m
+SMPTE-170M or BT.601-6 525
+
+@item smpte240m
+SMPTE-240M
+
+@item film
+film
+
+@item bt2020
+BT.2020
+
+@item smpte428
+SMPTE-428
+
+@item smpte431
+SMPTE-431
+
+@item smpte432
+SMPTE-432
+
+@item jedec-p22
+JEDEC P22 phosphors
+
+@end table
+@end table
+
+@subsection Examples
+
+@itemize
+@item
+Scale input to 720p, keeping aspect ratio and ensuring the output is yuv420p.
+@example
+vpp_amf=-2:720:format=yuv420p
+@end example
+
+@item
+Upscale to 4K and change color profile to bt2020.
+@example
+vpp_amf=4096:2160:color_profile=bt2020
+@end example
+@end itemize
+
@anchor{vstack}
@section vstack
Stack input videos vertically.
--
2.38.1.windows.1
Re: [FFmpeg-devel] [PATCH v12 5/9] libavcodec/dnxucdec: DNxUncompressed decoder
On 10/21/2024 8:51 PM, James Almer wrote: On 10/21/2024 10:02 PM, martin schitter wrote: I know -- it's trivial to choose this way, but there has to be some common agreement or docu, how it should be done, otherwise we run circles. I didn't participate in earlier rounds, but at least my opinion is that we shouldn't add new pixel formats if they are only used for a single codec and have no RIFF or ISOBMFF mapping. hwaccels like Vulkan/VAAPI/QSV/D3DVA/VideoToolbox defining them is also an argument in favor to add and map them. OpenPGP_signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v12 5/9] libavcodec/dnxucdec: DNxUncompressed decoder
On 10/21/2024 4:57 PM, Martin Schitter wrote:
---
libavcodec/Makefile| 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/dnxucdec.c | 338 +
3 files changed, 340 insertions(+)
create mode 100644 libavcodec/dnxucdec.c
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index dd5d0de..e13b127 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -328,6 +328,7 @@ OBJS-$(CONFIG_DFPWM_DECODER) += dfpwmdec.o
OBJS-$(CONFIG_DFPWM_ENCODER) += dfpwmenc.o
OBJS-$(CONFIG_DNXHD_DECODER) += dnxhddec.o dnxhddata.o
OBJS-$(CONFIG_DNXHD_ENCODER) += dnxhdenc.o dnxhddata.o
+OBJS-$(CONFIG_DNXUC_DECODER) += dnxucdec.o
OBJS-$(CONFIG_DOLBY_E_DECODER) += dolby_e.o dolby_e_parse.o kbdwin.o
OBJS-$(CONFIG_DPX_DECODER) += dpx.o
OBJS-$(CONFIG_DPX_ENCODER) += dpxenc.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index c7e5f99..ccca2ad 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -93,6 +93,7 @@ extern const FFCodec ff_dfa_decoder;
extern const FFCodec ff_dirac_decoder;
extern const FFCodec ff_dnxhd_encoder;
extern const FFCodec ff_dnxhd_decoder;
+extern const FFCodec ff_dnxuc_decoder;
extern const FFCodec ff_dpx_encoder;
extern const FFCodec ff_dpx_decoder;
extern const FFCodec ff_dsicinvideo_decoder;
diff --git a/libavcodec/dnxucdec.c b/libavcodec/dnxucdec.c
new file mode 100644
index 000..9d5847d
--- /dev/null
+++ b/libavcodec/dnxucdec.c
@@ -0,0 +1,338 @@
+/*
+ * Avid DNxUncomressed / SMPTE RDD 50 decoder
+ * Copyright (c) 2024 Martin Schitter
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/*
+ This decoder for DNxUncompressed video data is mostly based on
+ reverse engineering of output generated by DaVinci Resolve 19
+ but was later also checked against the SMPTE RDD 50 specification.
+
+ Not all DNxUncompressed pixel format variants are supported,
+ but at least an elementary base set is already usable:
+
+ - YUV 4:2:2 8/10/12/16bit/half/float (16bit untested)
+YUV 4:4:4 8/16bit/half/float (all untested!)
+ - RGB 8/10/12/16bit/half/float (16bit untested)
+Alpha/Y 8/16bit (all untested!)
That's not good...
[...]
+static int dnxuc_decode_frame(AVCodecContext *avctx, AVFrame *frame,
+ int *got_frame, AVPacket *avpkt)
+{
+char fourcc_buf[AV_FOURCC_MAX_STRING_SIZE];
+int ret;
+
+av_fourcc_make_string(fourcc_buf, avctx->codec_tag);
+if ((avctx->width % 2) && ((fourcc_buf[0] == 'y' && fourcc_buf[1] == '2')
+ ||(fourcc_buf[1] == 'y' && fourcc_buf[2] ==
'2'))){
+av_log(avctx, AV_LOG_ERROR,
+"Image width must be a multiple of 2 for YUV 4:2:2
DNxUncompressed!\n");
+return AVERROR_INVALIDDATA;
+}
+
+switch (avctx->codec_tag) {
+case MKTAG('y','2','0','8'):
+ret = fmt_frame(avctx, frame, avpkt, AV_PIX_FMT_UYVY422, 16,
pass_through);
+break;
+case MKTAG('y','4','0','8'):
+ret = fmt_frame(avctx, frame, avpkt, AV_PIX_FMT_YUV444, 24,
pass_through);
Y408 is mapped to AV_PIX_FMT_AYUV.
+break;
+case MKTAG('y','2','1','0'):
+ret = fmt_frame(avctx, frame, avpkt, AV_PIX_FMT_YUV422P10LE, 20,
unpack_y210);
Y210 has no pixel format, and it's packed, not planar, so definitely not
AV_PIX_FMT_YUV422P10LE.
+break;
+case MKTAG('y','4','1','0'):
+ret = fmt_frame(avctx, frame, avpkt, AV_PIX_FMT_YUV444P10LE, 20,
unpack_y410);
Y410 is mapped to AV_PIX_FMT_XV30LE.
+break;
+case MKTAG('y','2','1','2'):
+ret = fmt_frame(avctx, frame, avpkt, AV_PIX_FMT_YUV422P12LE, 24,
unpack_y212);
AV_PIX_FMT_Y212?
+break;
+case MKTAG('y','4','1','2'):
+ret = fmt_frame(avctx, frame, avpkt, AV_PIX_FMT_YUV444P12LE, 24,
unpack_y412);
This one is probably AV_PIX_FMT_XV36, and definitely not planar.
+break;
+case MKTAG('y','2','1','6'):
+ret = fmt_frame(avctx, frame, avpkt, AV_PIX_FMT_UYVY422_16LE, 32,
pass_through);
The order of y216 appears to be YUYV, not UY
Re: [FFmpeg-devel] RFC: new packed pixel formats (machine vision)
Ping.
Is the below a viable scheme or are there concerns to consider in this
initial design stage?
Thanks and all the best,
Dee
On Tue, Oct 15, 2024 at 8:55 AM Diederick C. Niehorster
wrote:
>
> Hi All,
>
> I want to pick up a discussion i started last week
> (https://ffmpeg.org/pipermail/ffmpeg-devel/2024-October/334585.html)
> in a new thread, with the relevant information nicely organized. This
> is about adding pixel formats common in machine vision to ffmpeg
> (though i understand some formats may also be used by cinema cameras),
> and supporting them as input formats in swscale so that it becomes
> easy to use ffmpeg for machine vision purposes (I already have such
> software, it will be open-sourced in good time, but right now there is
> a proprietary conversion layer from Basler i need to replace (e.g. by
> this proposal)).
>
> Example formats are 10 and 12 bit Bayer formats, where the 10 bit
> cannot be represented in AVPixFmtDescriptors as currently as effective
> bit depth for the red and blue channels is 2.5 bits, but component
> depths should be integers. Other example formats are 10bit gray
> formats where multiple values are packed without padding over multiple
> bytes (e.g. 4 10-bit pixels packed into 5 bytes, so not aligned to 16
> or 32 bits).
>
> See
> https://www.1stvision.com/cameras/IDS/IDS-manuals/en/basics-monochrome-pixel-formats.html
> for a diagram of the Mono10p and
> https://www.1stvision.com/cameras/IDS/IDS-manuals/en/basics-raw-bayer-pixel-formats.html
> for diagrams of the packed and not packed bayer formats.
>
> Here a proposal for how these new formats could be encoded into
> AVPixFmtDescriptor, so that these can then be used in ffmpeg/swscale.
> I have taken care that none of the existing pixel formats or any code
> dealing with them would be affected, although new code would be needed
> to handle these new formats (av_read_image_line2, av_write_image_line2
> and functions printing info about AVPixFmtDescriptors, plus swscale of
> course--i commit to do a full audit to ensure nothing else is missed).
>
> First, two new flags are needed (usages are shown below in the example
> new pixel formats). I propose:
> - AV_PIX_FMT_FLAG_DEPTH_INT16_RATIONAL which indicates that the value
> in the component depths (ints) represent a 16 bit numerator and
> denominator packed into the int. That should be able to store any
> value that could ever be possible and importantly allows for the
> fractional bit depths needed for the bayer formats.
> - AV_PIX_FMT_FLAG_BITPACKED_UNALIGNED which indicates formats that are
> bit-wise packed in a way that is not aligned on 1, 2 or 4 bytes (e.g.
> 4 10-bit values in 5 bytes). This flag is needed because
> AV_PIX_FMT_FLAG_BITSTREAM
> formats are aligned to 8 or 32 bits, and this kind of unaligned
> packing needs special handling ( see below).
>
> Using these flags, here are some example new pixel formats:
> [AV_PIX_FMT_BAYER_RGGB10] = {
> .name = "bayer_rggb10",
> .nb_components = 3,
> .log2_chroma_w = 0,
> .log2_chroma_h = 0,
> .comp = {
> { 0, 2, 0, 0, 655364 }, /* 2.5: 10/4 (10<<16 + 4) */
> { 0, 2, 0, 0, 655362 }, /* 5: 10/2 */
> { 0, 2, 0, 0, 655364 }, /* 2.5: 10/4 */
> },
> .flags = AV_PIX_FMT_FLAG_RGB | AV_PIX_FMT_FLAG_BAYER |
> AV_PIX_FMT_FLAG_DEPTH_INT16_RATIONAL,
> },
> [AV_PIX_FMT_BAYER_RGGB12] = {
> .name = "bayer_rggb12",
> .nb_components = 3,
> .log2_chroma_w = 0,
> .log2_chroma_h = 0,
> .comp = {
> { 0, 2, 0, 0, 3 },
> { 0, 2, 0, 0, 6 },
> { 0, 2, 0, 0, 3 },
> },
> .flags = AV_PIX_FMT_FLAG_RGB | AV_PIX_FMT_FLAG_BAYER,
> },
> [AV_PIX_FMT_BAYER_GRAY10P] = {
> .name = "gray10p",
> .nb_components = 1,
> .log2_chroma_w = 0,
> .log2_chroma_h = 0,
> .comp = {
> { 0, 2, 0, 0, 10 }, /* Y */
> },
> .flags = AV_PIX_FMT_FLAG_BITPACKED_UNALIGNED,
> },
> [AV_PIX_FMT_BAYER_RGGB10P] = {
> .name = "bayer_rggb10p",
> .nb_components = 3,
> .log2_chroma_w = 0,
> .log2_chroma_h = 0,
> .comp = {
> { 0, 2, 0, 0, 655364 }, /* 2.5: 10/4 (10<<16 + 2) */
> { 0, 2, 0, 0, 655362 }, /* 5: 10/2 */
> { 0, 2, 0, 0, 655364 }, /* 2.5: 10/4 */
> },
> .flags = AV_PIX_FMT_FLAG_RGB | AV_PIX_FMT_FLAG_BAYER |
> AV_PIX_FMT_FLAG_DEPTH_INT16_RATIONAL |
> AV_PIX_FMT_FLAG_BITPACKED_UNALIGNED,
> },
> [AV_PIX_FMT_BAYER_RGGB12P] = {
> .name = "bayer_rggb12p",
> .nb_components = 3,
> .log2_chroma_w = 0,
> .log2_chroma_h = 0,
> .comp = {
> { 0, 2, 0, 0, 3 },
> { 0, 2, 0, 0, 6 },
> { 0, 2, 0, 0, 3 },
> },
> .flags = AV_PIX_FMT_FLAG_RGB | AV_PIX_FMT_FLAG_BAYER |
> AV_PIX_FMT_FLAG_BITPACKED_UNALIGNED,
>
