[FFmpeg-devel] [PATCH] lavc/vp9: set update_map to 0 when segmentation.enabled is 0

2024-02-28 Thread llyyr
segmentation.update_map is never reset to 0 on a new frame, and retains
the value from the previous frame. This bugs out a bunch of hwaccel
drivers when segmentation.enabled is 0 but update_map isn't because
they don't ignore values behind switches. We also do this for vp8* so
this commit is just mirroring the vp8 logic.

This fixes an issue with certain samples** that causes blocky
artifacts with vaapi and d3d11va (as far as known hwaccel drivers go).
Mesa worked around*** this by ignoring this field if
segmentation.enabled is 0, but d3d11va still doesn't work.

* https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/libavcodec/vp8.c#l811
** https://github.com/mpv-player/mpv/issues/13533
*** https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27816

Signed-off-by: llyyr 
---
 libavcodec/vp9.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index 855936cdc1c7..4a628625131e 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -717,6 +717,8 @@ static int decode_frame_header(AVCodecContext *avctx,
 s->s.h.segmentation.feat[i].skip_enabled = get_bits1(&s->gb);
 }
 }
+} else {
+s->s.h.segmentation.update_map = 0;
 }
 
 // set qmul[] based on Y/UV, AC/DC and segmentation Q idx deltas

base-commit: d263fce2b209e86a5a1e8f1b6aa33430ecc2c187
-- 
2.43.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


[FFmpeg-devel] [PATCH 2/2] lavc/qsvenc: add support for oneVPL string API

2024-02-28 Thread Xiang, Haihao
From: "Mandava, Mounika" 

A new option -qsv_params  is added, where  is a :-separated
list of key=value parameters.

Example:
$ ffmpeg -y -f lavfi -i testsrc -vf "format=nv12" -c:v h264_qsv -qsv_params
"TargetUsage=1:GopPicSize=30:GopRefDist=2:TargetKbps=5000" -f null -

Signed-off-by: Mounika Mandava 
Signed-off-by: Haihao Xiang 
---
 Changelog   |  1 +
 configure   |  2 ++
 doc/encoders.texi   | 14 ++
 libavcodec/qsvenc.c | 62 +
 libavcodec/qsvenc.h |  8 +-
 5 files changed, 86 insertions(+), 1 deletion(-)

diff --git a/Changelog b/Changelog
index 610ee61dd6..b137d089d8 100644
--- a/Changelog
+++ b/Changelog
@@ -27,6 +27,7 @@ version :
 - a C11-compliant compiler is now required; note that this requirement
   will be bumped to C17 in the near future, so consider updating your
   build environment if it lacks C17 support
+- qsv_params option added for QSV encoders
 
 version 6.1:
 - libaribcaption decoder
diff --git a/configure b/configure
index bb5e630bad..046c481f63 100755
--- a/configure
+++ b/configure
@@ -2431,6 +2431,7 @@ TYPES_LIST="
 struct_sockaddr_storage
 struct_stat_st_mtim_tv_nsec
 struct_v4l2_frmivalenum_discrete
+struct_mfxConfigInterface
 "
 
 HAVE_LIST="
@@ -6828,6 +6829,7 @@ elif enabled libvpl; then
 check_pkg_config libmfx "vpl >= 2.6" "mfxvideo.h mfxdispatcher.h" MFXLoad 
|| \
 die "ERROR: libvpl >= 2.6 not found"
 add_cflags -DMFX_DEPRECATED_OFF
+check_type "vpl/mfxdefs.h vpl/mfxvideo.h" "struct mfxConfigInterface"
 fi
 
 if enabled libmfx; then
diff --git a/doc/encoders.texi b/doc/encoders.texi
index 9f477d7c53..cbd3b538cf 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -3485,6 +3485,20 @@ Change these value to reset qsv codec's bitrate control 
configuration.
 @item @var{pic_timing_sei}
 Supported in h264_qsv and hevc_qsv.
 Change this value to reset qsv codec's pic_timing_sei configuration.
+
+@item @var{qsv_params}
+Set QSV encoder parameters as a colon-separated list of key-value pairs.
+
+The @option{qsv_params} should be formatted as 
@code{key1=value1:key2=value2:...}.
+
+These parameters are passed directly to the underlying Intel Quick Sync Video 
(QSV) encoder using the MFXSetParameter function.
+
+Example:
+@example
+ffmpeg -i input.mp4 -c:v h264_qsv -qsv_params 
"CodingOption1=1:CodingOption2=2" output.mp4
+@end example
+
+This option allows fine-grained control over various encoder-specific settings 
provided by the QSV encoder.
 @end table
 
 @subsection H264 options
diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 27e0e7ee71..0189c219d2 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -31,6 +31,7 @@
 #include "libavutil/hwcontext_qsv.h"
 #include "libavutil/mem.h"
 #include "libavutil/log.h"
+#include "libavutil/dict.h"
 #include "libavutil/time.h"
 #include "libavutil/imgutils.h"
 
@@ -1609,6 +1610,11 @@ int ff_qsv_enc_init(AVCodecContext *avctx, QSVEncContext 
*q)
 int opaque_alloc = 0;
 int ret;
 void *tmp;
+#if HAVE_STRUCT_MFXCONFIGINTERFACE
+mfxExtBuffer ext_buf;
+mfxConfigInterface *iface = NULL;
+const AVDictionaryEntry *param = NULL;
+#endif
 
 q->param.AsyncDepth = q->async_depth;
 
@@ -1703,6 +1709,58 @@ int ff_qsv_enc_init(AVCodecContext *avctx, QSVEncContext 
*q)
 q->param.ExtParam= q->extparam;
 q->param.NumExtParam = q->nb_extparam;
 
+#if HAVE_STRUCT_MFXCONFIGINTERFACE
+ret = MFXVideoCORE_GetHandle(q->session, MFX_HANDLE_CONFIG_INTERFACE, 
(mfxHDL *)(&iface));
+if (ret < 0)
+return ff_qsv_print_error(avctx, ret,
+  "Error getting mfx config interface handle");
+
+while ((param = av_dict_get(q->qsv_params, "", param, 
AV_DICT_IGNORE_SUFFIX))) {
+const char *param_key = param->key;
+const char *param_value = param->value;
+mfxExtBuffer *new_ext_buf;
+void *tmp;
+
+av_log(avctx, AV_LOG_VERBOSE, "Parameter key: %s, value: %s\n", 
param_key, param_value);
+
+// Set encoding parameters using MFXSetParameter
+for (int i = 0; i < 2; i++) {
+ret = iface->SetParameter(iface, (mfxU8*)param_key, 
(mfxU8*)param_value, MFX_STRUCTURE_TYPE_VIDEO_PARAM, &q->param, &ext_buf);
+if (ret == MFX_ERR_NONE) {
+break;
+} else if (i == 0 && ret == MFX_ERR_MORE_EXTBUFFER) {
+tmp = av_realloc_array(q->extparam_str, q->nb_extparam_str + 
1, sizeof(*q->extparam_str));
+if (!tmp)
+return AVERROR(ENOMEM);
+q->extparam_str = tmp;
+
+tmp = av_realloc_array(q->extparam, q->nb_extparam + 1, 
sizeof(*q->extparam));
+if (!tmp)
+return AVERROR(ENOMEM);
+q->extparam = tmp;
+
+new_ext_buf = (mfxExtBuffer*)av_mallocz(ext_buf.BufferSz);
+if (!new_ext_buf)
+return AVERRO

[FFmpeg-devel] [PATCH 1/2] lavc/qsvenc: always allocate the array to store mfxExtBuffer points

2024-02-28 Thread Xiang, Haihao
From: Haihao Xiang 

This allows us to append mfxExtBuffer per user's settings

Signed-off-by: Haihao Xiang 
---
 libavcodec/qsvenc.c | 44 +---
 libavcodec/qsvenc.h |  1 +
 2 files changed, 26 insertions(+), 19 deletions(-)

diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index c63b72e384..27e0e7ee71 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -1608,6 +1608,7 @@ int ff_qsv_enc_init(AVCodecContext *avctx, QSVEncContext 
*q)
 int iopattern = 0;
 int opaque_alloc = 0;
 int ret;
+void *tmp;
 
 q->param.AsyncDepth = q->async_depth;
 
@@ -1668,35 +1669,40 @@ int ff_qsv_enc_init(AVCodecContext *avctx, 
QSVEncContext *q)
 if (ret < 0)
 return ret;
 
+tmp = av_realloc_array(q->extparam, q->nb_extparam_internal, 
sizeof(*q->extparam));
+if (!tmp)
+return AVERROR(ENOMEM);
+
+q->extparam = tmp;
+q->nb_extparam = q->nb_extparam_internal;
+memcpy(q->extparam, q->extparam_internal, q->nb_extparam * 
sizeof(*q->extparam));
+
 if (avctx->hwaccel_context) {
 AVQSVContext *qsv = avctx->hwaccel_context;
 int i, j;
 
-q->extparam = av_calloc(qsv->nb_ext_buffers + q->nb_extparam_internal,
-sizeof(*q->extparam));
-if (!q->extparam)
-return AVERROR(ENOMEM);
-
-q->param.ExtParam = q->extparam;
-for (i = 0; i < qsv->nb_ext_buffers; i++)
-q->param.ExtParam[i] = qsv->ext_buffers[i];
-q->param.NumExtParam = qsv->nb_ext_buffers;
-
-for (i = 0; i < q->nb_extparam_internal; i++) {
-for (j = 0; j < qsv->nb_ext_buffers; j++) {
-if (qsv->ext_buffers[j]->BufferId == 
q->extparam_internal[i]->BufferId)
+for (i = 0; i < qsv->nb_ext_buffers; i++) {
+for (j = 0; j < q->nb_extparam_internal; j++) {
+if (qsv->ext_buffers[i]->BufferId == 
q->extparam_internal[j]->BufferId) {
+q->extparam[j] = qsv->ext_buffers[i];
 break;
+}
 }
-if (j < qsv->nb_ext_buffers)
-continue;
 
-q->param.ExtParam[q->param.NumExtParam++] = 
q->extparam_internal[i];
+if (j == q->nb_extparam_internal) {
+tmp = av_realloc_array(q->extparam, q->nb_extparam + 1, 
sizeof(*q->extparam));
+if (!tmp)
+return AVERROR(ENOMEM);
+
+q->extparam = tmp;
+q->extparam[q->nb_extparam++] = qsv->ext_buffers[i];
+}
 }
-} else {
-q->param.ExtParam= q->extparam_internal;
-q->param.NumExtParam = q->nb_extparam_internal;
 }
 
+q->param.ExtParam= q->extparam;
+q->param.NumExtParam = q->nb_extparam;
+
 ret = MFXVideoENCODE_Query(q->session, &q->param, &q->param);
 if (ret == MFX_WRN_PARTIAL_ACCELERATION) {
 av_log(avctx, AV_LOG_WARNING, "Encoder will work with partial HW 
acceleration\n");
diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h
index c71bf2ed50..f2f0687bfe 100644
--- a/libavcodec/qsvenc.h
+++ b/libavcodec/qsvenc.h
@@ -196,6 +196,7 @@ typedef struct QSVEncContext {
 int nb_extparam_internal;
 
 mfxExtBuffer **extparam;
+int nb_extparam;
 
 AVFifo *async_fifo;
 
-- 
2.34.1

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

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


[FFmpeg-devel] [PATCH v6 7/9] avutil/hwcontext_d3d12va: add Flags for resource creation

2024-02-28 Thread tong1 . wu-at-intel . com
From: Tong Wu 

Flags field is added to support diffferent resource creation.

Signed-off-by: Tong Wu 
---
 doc/APIchanges| 3 +++
 libavutil/hwcontext_d3d12va.c | 2 +-
 libavutil/hwcontext_d3d12va.h | 8 
 libavutil/version.h   | 2 +-
 4 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 10f6667e9e..66c2408883 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,9 @@ The last version increases of all libraries were on 2023-02-09
 
 API changes, most recent first:
 
+2024-01-xx - xx - lavu 58.40.100 - hwcontext_d3d12va.h
+ Add AVD3D12VAFramesContext.flags
+
 2024-02-26 - xx - lavf 60.22.101 - avformat.h
   AV_DISPOSITION_DEPENDENT may now also be used for video streams
   intended to be merged with other video streams for presentation.
diff --git a/libavutil/hwcontext_d3d12va.c b/libavutil/hwcontext_d3d12va.c
index 3acd5ac43a..b9984a4151 100644
--- a/libavutil/hwcontext_d3d12va.c
+++ b/libavutil/hwcontext_d3d12va.c
@@ -237,7 +237,7 @@ static AVBufferRef *d3d12va_pool_alloc(void *opaque, size_t 
size)
 .Format   = hwctx->format,
 .SampleDesc   = {.Count = 1, .Quality = 0 },
 .Layout   = D3D12_TEXTURE_LAYOUT_UNKNOWN,
-.Flags= D3D12_RESOURCE_FLAG_NONE,
+.Flags= hwctx->flags,
 };
 
 frame = av_mallocz(sizeof(AVD3D12VAFrame));
diff --git a/libavutil/hwcontext_d3d12va.h b/libavutil/hwcontext_d3d12va.h
index ff06e6f2ef..608dbac97f 100644
--- a/libavutil/hwcontext_d3d12va.h
+++ b/libavutil/hwcontext_d3d12va.h
@@ -129,6 +129,14 @@ typedef struct AVD3D12VAFramesContext {
  * If unset, will be automatically set.
  */
 DXGI_FORMAT format;
+
+/**
+ * This field is used to specify options for working with resources.
+ * If unset, this will be D3D12_RESOURCE_FLAG_NONE.
+ *
+ * @see: 
https://learn.microsoft.com/en-us/windows/win32/api/d3d12/ne-d3d12-d3d12_resource_flags.
+ */
+D3D12_RESOURCE_FLAGS flags;
 } AVD3D12VAFramesContext;
 
 #endif /* AVUTIL_HWCONTEXT_D3D12VA_H */
diff --git a/libavutil/version.h b/libavutil/version.h
index 9f45af93df..3fbc292a68 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
  */
 
 #define LIBAVUTIL_VERSION_MAJOR  58
-#define LIBAVUTIL_VERSION_MINOR  39
+#define LIBAVUTIL_VERSION_MINOR  40
 #define LIBAVUTIL_VERSION_MICRO 100
 
 #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
-- 
2.41.0.windows.1

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

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


[FFmpeg-devel] [PATCH v6 8/9] avcodec: add D3D12VA hardware HEVC encoder

2024-02-28 Thread tong1 . wu-at-intel . com
From: Tong Wu 

This implementation is based on D3D12 Video Encoding Spec:
https://microsoft.github.io/DirectX-Specs/d3d/D3D12VideoEncoding.html

Sample command line for transcoding:
ffmpeg.exe -hwaccel d3d12va -hwaccel_output_format d3d12 -i input.mp4
-c:v hevc_d3d12va output.mp4

Signed-off-by: Tong Wu 
---
 configure|6 +
 libavcodec/Makefile  |4 +-
 libavcodec/allcodecs.c   |1 +
 libavcodec/d3d12va_encode.c  | 1554 ++
 libavcodec/d3d12va_encode.h  |  321 ++
 libavcodec/d3d12va_encode_hevc.c |  957 ++
 6 files changed, 2842 insertions(+), 1 deletion(-)
 create mode 100644 libavcodec/d3d12va_encode.c
 create mode 100644 libavcodec/d3d12va_encode.h
 create mode 100644 libavcodec/d3d12va_encode_hevc.c

diff --git a/configure b/configure
index bb5e630bad..e1e302a005 100755
--- a/configure
+++ b/configure
@@ -2566,6 +2566,7 @@ CONFIG_EXTRA="
 tpeldsp
 vaapi_1
 vaapi_encode
+d3d12va_encode
 vc1dsp
 videodsp
 vp3dsp
@@ -3210,6 +3211,7 @@ wmv3_vaapi_hwaccel_select="vc1_vaapi_hwaccel"
 wmv3_vdpau_hwaccel_select="vc1_vdpau_hwaccel"
 
 # hardware-accelerated codecs
+d3d12va_encode_deps="d3d12va ID3D12VideoEncoder d3d12_encoder_feature"
 mediafoundation_deps="mftransform_h MFCreateAlignedMemoryBuffer"
 omx_deps="libdl pthreads"
 omx_rpi_select="omx"
@@ -3277,6 +3279,7 @@ h264_v4l2m2m_encoder_deps="v4l2_m2m h264_v4l2_m2m"
 hevc_amf_encoder_deps="amf"
 hevc_cuvid_decoder_deps="cuvid"
 hevc_cuvid_decoder_select="hevc_mp4toannexb_bsf"
+hevc_d3d12va_encoder_select="cbs_h265 d3d12va_encode"
 hevc_mediacodec_decoder_deps="mediacodec"
 hevc_mediacodec_decoder_select="hevc_mp4toannexb_bsf hevc_parser"
 hevc_mediacodec_encoder_deps="mediacodec"
@@ -6620,6 +6623,9 @@ check_type "windows.h d3d11.h" "ID3D11VideoDecoder"
 check_type "windows.h d3d11.h" "ID3D11VideoContext"
 check_type "windows.h d3d12.h" "ID3D12Device"
 check_type "windows.h d3d12video.h" "ID3D12VideoDecoder"
+check_type "windows.h d3d12video.h" "ID3D12VideoEncoder"
+test_code cc "windows.h d3d12video.h" "D3D12_FEATURE_VIDEO feature = 
D3D12_FEATURE_VIDEO_ENCODER_CODEC" && \
+test_code cc "windows.h d3d12video.h" 
"D3D12_FEATURE_DATA_VIDEO_ENCODER_RESOURCE_REQUIREMENTS req" && enable 
d3d12_encoder_feature
 check_type "windows.h" "DPI_AWARENESS_CONTEXT" -D_WIN32_WINNT=0x0A00
 check_type "d3d9.h dxva2api.h" DXVA2_ConfigPictureDecode -D_WIN32_WINNT=0x0602
 check_func_headers mfapi.h MFCreateAlignedMemoryBuffer -lmfplat
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index c1b3dff055..965aaba80e 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -86,6 +86,7 @@ OBJS-$(CONFIG_CBS_MPEG2)   += cbs_mpeg2.o
 OBJS-$(CONFIG_CBS_VP8) += cbs_vp8.o vp8data.o
 OBJS-$(CONFIG_CBS_VP9) += cbs_vp9.o
 OBJS-$(CONFIG_CRYSTALHD)   += crystalhd.o
+OBJS-$(CONFIG_D3D12VA_ENCODE)  += d3d12va_encode.o hw_base_encode.o
 OBJS-$(CONFIG_DEFLATE_WRAPPER) += zlib_wrapper.o
 OBJS-$(CONFIG_DOVI_RPU)+= dovi_rpu.o
 OBJS-$(CONFIG_ERROR_RESILIENCE)+= error_resilience.o
@@ -437,6 +438,7 @@ OBJS-$(CONFIG_HEVC_DECODER)+= hevcdec.o 
hevc_mvs.o \
   h274.o
 OBJS-$(CONFIG_HEVC_AMF_ENCODER)+= amfenc_hevc.o
 OBJS-$(CONFIG_HEVC_CUVID_DECODER)  += cuviddec.o
+OBJS-$(CONFIG_HEVC_D3D12VA_ENCODER)+= d3d12va_encode_hevc.o
 OBJS-$(CONFIG_HEVC_MEDIACODEC_DECODER) += mediacodecdec.o
 OBJS-$(CONFIG_HEVC_MEDIACODEC_ENCODER) += mediacodecenc.o
 OBJS-$(CONFIG_HEVC_MF_ENCODER) += mfenc.o mf_utils.o
@@ -1267,7 +1269,7 @@ SKIPHEADERS+= %_tablegen.h
  \
 
 SKIPHEADERS-$(CONFIG_AMF)  += amfenc.h
 SKIPHEADERS-$(CONFIG_D3D11VA)  += d3d11va.h dxva2_internal.h
-SKIPHEADERS-$(CONFIG_D3D12VA)  += d3d12va_decode.h
+SKIPHEADERS-$(CONFIG_D3D12VA)  += d3d12va_decode.h d3d12va_encode.h
 SKIPHEADERS-$(CONFIG_DXVA2)+= dxva2.h dxva2_internal.h
 SKIPHEADERS-$(CONFIG_JNI)  += ffjni.h
 SKIPHEADERS-$(CONFIG_LCMS2)+= fflcms2.h
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index ef8c3a6d7d..9a34974141 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -865,6 +865,7 @@ extern const FFCodec ff_h264_vaapi_encoder;
 extern const FFCodec ff_h264_videotoolbox_encoder;
 extern const FFCodec ff_hevc_amf_encoder;
 extern const FFCodec ff_hevc_cuvid_decoder;
+extern const FFCodec ff_hevc_d3d12va_encoder;
 extern const FFCodec ff_hevc_mediacodec_decoder;
 extern const FFCodec ff_hevc_mediacodec_encoder;
 extern const FFCodec ff_hevc_mf_encoder;
diff --git a/libavcodec/d3d12va_encode.c b/libavcodec/d3d12va_encode.c
new file mode 100644
index 00..2b8078a8dd
--- /dev/null
+++ b/libavcodec/d3d12va_encode.c
@@ -0,0 +1,1554 @@
+/*
+ * Direct3D 12 HW acceleration video encoder
+ *
+ * Cop

[FFmpeg-devel] [PATCH v6 9/9] Changelog: add D3D12VA HEVC encoder changelog

2024-02-28 Thread tong1 . wu-at-intel . com
From: Tong Wu 

Signed-off-by: Tong Wu 
---
 Changelog | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Changelog b/Changelog
index 610ee61dd6..8669b4cdd8 100644
--- a/Changelog
+++ b/Changelog
@@ -27,6 +27,7 @@ version :
 - a C11-compliant compiler is now required; note that this requirement
   will be bumped to C17 in the near future, so consider updating your
   build environment if it lacks C17 support
+- D3D12VA HEVC encoder
 
 version 6.1:
 - libaribcaption decoder
-- 
2.41.0.windows.1

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

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


[FFmpeg-devel] [PATCH v6 6/9] avcodec/vaapi_encode: extract a free funtion to base layer

2024-02-28 Thread tong1 . wu-at-intel . com
From: Tong Wu 

Signed-off-by: Tong Wu 
---
 libavcodec/hw_base_encode.c | 11 +++
 libavcodec/hw_base_encode.h |  2 ++
 libavcodec/vaapi_encode.c   |  6 +-
 3 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/libavcodec/hw_base_encode.c b/libavcodec/hw_base_encode.c
index 2aef29b561..a937e17f55 100644
--- a/libavcodec/hw_base_encode.c
+++ b/libavcodec/hw_base_encode.c
@@ -750,6 +750,17 @@ fail:
 return err;
 }
 
+int ff_hw_base_encode_free(AVCodecContext *avctx, HWBaseEncodePicture *pic)
+{
+av_frame_free(&pic->input_image);
+av_frame_free(&pic->recon_image);
+
+av_buffer_unref(&pic->opaque_ref);
+av_freep(&pic->priv_data);
+
+return 0;
+}
+
 int ff_hw_base_encode_init(AVCodecContext *avctx)
 {
 HWBaseEncodeContext *ctx = avctx->priv_data;
diff --git a/libavcodec/hw_base_encode.h b/libavcodec/hw_base_encode.h
index 383bc68280..1ed1895566 100644
--- a/libavcodec/hw_base_encode.h
+++ b/libavcodec/hw_base_encode.h
@@ -239,6 +239,8 @@ int ff_hw_base_init_gop_structure(AVCodecContext *avctx, 
uint32_t ref_l0, uint32
 
 int ff_hw_base_get_recon_format(AVCodecContext *avctx, const void *hwconfig, 
enum AVPixelFormat *fmt);
 
+int ff_hw_base_encode_free(AVCodecContext *avctx, HWBaseEncodePicture *pic);
+
 int ff_hw_base_encode_init(AVCodecContext *avctx);
 
 int ff_hw_base_encode_close(AVCodecContext *avctx);
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 8503742430..b79b15fb4c 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -874,17 +874,13 @@ static int vaapi_encode_free(AVCodecContext *avctx,
 av_freep(&pic->slices[i].codec_slice_params);
 }
 
-av_frame_free(&base_pic->input_image);
-av_frame_free(&base_pic->recon_image);
-
-av_buffer_unref(&base_pic->opaque_ref);
+ff_hw_base_encode_free(avctx, base_pic);
 
 av_freep(&pic->param_buffers);
 av_freep(&pic->slices);
 // Output buffer should already be destroyed.
 av_assert0(pic->output_buffer == VA_INVALID_ID);
 
-av_freep(&base_pic->priv_data);
 av_freep(&pic->codec_picture_params);
 av_freep(&pic->roi);
 
-- 
2.41.0.windows.1

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

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


[FFmpeg-devel] [PATCH v6 5/9] avcodec/vaapi_encode: extract a get_recon_format function to base layer

2024-02-28 Thread tong1 . wu-at-intel . com
From: Tong Wu 

Get constraints and set recon frame format can be shared with other HW
encoder such as D3D12. Extract this part as a new function to base
layer.

Signed-off-by: Tong Wu 
---
 libavcodec/hw_base_encode.c | 58 +
 libavcodec/hw_base_encode.h |  2 ++
 libavcodec/vaapi_encode.c   | 51 ++--
 3 files changed, 63 insertions(+), 48 deletions(-)

diff --git a/libavcodec/hw_base_encode.c b/libavcodec/hw_base_encode.c
index 2db75e98c3..2aef29b561 100644
--- a/libavcodec/hw_base_encode.c
+++ b/libavcodec/hw_base_encode.c
@@ -692,6 +692,64 @@ int ff_hw_base_init_gop_structure(AVCodecContext *avctx, 
uint32_t ref_l0, uint32
 return 0;
 }
 
+int ff_hw_base_get_recon_format(AVCodecContext *avctx, const void *hwconfig, 
enum AVPixelFormat *fmt)
+{
+HWBaseEncodeContext *ctx = avctx->priv_data;
+AVHWFramesConstraints *constraints = NULL;
+enum AVPixelFormat recon_format;
+int err, i;
+
+constraints = av_hwdevice_get_hwframe_constraints(ctx->device_ref,
+  hwconfig);
+if (!constraints) {
+err = AVERROR(ENOMEM);
+goto fail;
+}
+
+// Probably we can use the input surface format as the surface format
+// of the reconstructed frames.  If not, we just pick the first (only?)
+// format in the valid list and hope that it all works.
+recon_format = AV_PIX_FMT_NONE;
+if (constraints->valid_sw_formats) {
+for (i = 0; constraints->valid_sw_formats[i] != AV_PIX_FMT_NONE; i++) {
+if (ctx->input_frames->sw_format ==
+constraints->valid_sw_formats[i]) {
+recon_format = ctx->input_frames->sw_format;
+break;
+}
+}
+if (recon_format == AV_PIX_FMT_NONE) {
+// No match.  Just use the first in the supported list and
+// hope for the best.
+recon_format = constraints->valid_sw_formats[0];
+}
+} else {
+// No idea what to use; copy input format.
+recon_format = ctx->input_frames->sw_format;
+}
+av_log(avctx, AV_LOG_DEBUG, "Using %s as format of "
+   "reconstructed frames.\n", av_get_pix_fmt_name(recon_format));
+
+if (ctx->surface_width  < constraints->min_width  ||
+ctx->surface_height < constraints->min_height ||
+ctx->surface_width  > constraints->max_width ||
+ctx->surface_height > constraints->max_height) {
+av_log(avctx, AV_LOG_ERROR, "Hardware does not support encoding at "
+   "size %dx%d (constraints: width %d-%d height %d-%d).\n",
+   ctx->surface_width, ctx->surface_height,
+   constraints->min_width,  constraints->max_width,
+   constraints->min_height, constraints->max_height);
+err = AVERROR(EINVAL);
+goto fail;
+}
+
+*fmt = recon_format;
+err = 0;
+fail:
+av_hwframe_constraints_free(&constraints);
+return err;
+}
+
 int ff_hw_base_encode_init(AVCodecContext *avctx)
 {
 HWBaseEncodeContext *ctx = avctx->priv_data;
diff --git a/libavcodec/hw_base_encode.h b/libavcodec/hw_base_encode.h
index 764385ab5a..383bc68280 100644
--- a/libavcodec/hw_base_encode.h
+++ b/libavcodec/hw_base_encode.h
@@ -237,6 +237,8 @@ int ff_hw_base_encode_receive_packet(AVCodecContext *avctx, 
AVPacket *pkt);
 int ff_hw_base_init_gop_structure(AVCodecContext *avctx, uint32_t ref_l0, 
uint32_t ref_l1,
   int flags, int prediction_pre_only);
 
+int ff_hw_base_get_recon_format(AVCodecContext *avctx, const void *hwconfig, 
enum AVPixelFormat *fmt);
+
 int ff_hw_base_encode_init(AVCodecContext *avctx);
 
 int ff_hw_base_encode_close(AVCodecContext *avctx);
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 0f72fe5cb3..8503742430 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -2022,9 +2022,8 @@ static av_cold int 
vaapi_encode_create_recon_frames(AVCodecContext *avctx)
 HWBaseEncodeContext *base_ctx = avctx->priv_data;
 VAAPIEncodeContext   *ctx = avctx->priv_data;
 AVVAAPIHWConfig *hwconfig = NULL;
-AVHWFramesConstraints *constraints = NULL;
 enum AVPixelFormat recon_format;
-int err, i;
+int err;
 
 hwconfig = av_hwdevice_hwconfig_alloc(base_ctx->device_ref);
 if (!hwconfig) {
@@ -2033,52 +2032,9 @@ static av_cold int 
vaapi_encode_create_recon_frames(AVCodecContext *avctx)
 }
 hwconfig->config_id = ctx->va_config;
 
-constraints = av_hwdevice_get_hwframe_constraints(base_ctx->device_ref,
-  hwconfig);
-if (!constraints) {
-err = AVERROR(ENOMEM);
-goto fail;
-}
-
-// Probably we can use the input surface format as the surface format
-// of the reconstructed frames.  If not, we just pick the first (only?)
-// format in the valid list and hope that it all works.

[FFmpeg-devel] [PATCH v6 4/9] avcodec/vaapi_encode: extract gop configuration to base layer

2024-02-28 Thread tong1 . wu-at-intel . com
From: Tong Wu 

Signed-off-by: Tong Wu 
---
 libavcodec/hw_base_encode.c | 54 +
 libavcodec/hw_base_encode.h |  3 +++
 libavcodec/vaapi_encode.c   | 52 +++
 3 files changed, 61 insertions(+), 48 deletions(-)

diff --git a/libavcodec/hw_base_encode.c b/libavcodec/hw_base_encode.c
index 799a817f7c..2db75e98c3 100644
--- a/libavcodec/hw_base_encode.c
+++ b/libavcodec/hw_base_encode.c
@@ -638,6 +638,60 @@ end:
 return 0;
 }
 
+int ff_hw_base_init_gop_structure(AVCodecContext *avctx, uint32_t ref_l0, 
uint32_t ref_l1,
+  int flags, int prediction_pre_only)
+{
+HWBaseEncodeContext *ctx = avctx->priv_data;
+
+if (flags & FLAG_INTRA_ONLY || avctx->gop_size <= 1) {
+av_log(avctx, AV_LOG_VERBOSE, "Using intra frames only.\n");
+ctx->gop_size = 1;
+} else if (ref_l0 < 1) {
+av_log(avctx, AV_LOG_ERROR, "Driver does not support any "
+   "reference frames.\n");
+return AVERROR(EINVAL);
+} else if (!(flags & FLAG_B_PICTURES) || ref_l1 < 1 ||
+   avctx->max_b_frames < 1 || prediction_pre_only) {
+if (ctx->p_to_gpb)
+   av_log(avctx, AV_LOG_VERBOSE, "Using intra and B-frames "
+  "(supported references: %d / %d).\n",
+  ref_l0, ref_l1);
+else
+av_log(avctx, AV_LOG_VERBOSE, "Using intra and P-frames "
+   "(supported references: %d / %d).\n", ref_l0, ref_l1);
+ctx->gop_size = avctx->gop_size;
+ctx->p_per_i  = INT_MAX;
+ctx->b_per_p  = 0;
+} else {
+   if (ctx->p_to_gpb)
+   av_log(avctx, AV_LOG_VERBOSE, "Using intra and B-frames "
+  "(supported references: %d / %d).\n",
+  ref_l0, ref_l1);
+   else
+   av_log(avctx, AV_LOG_VERBOSE, "Using intra, P- and B-frames "
+  "(supported references: %d / %d).\n", ref_l0, ref_l1);
+ctx->gop_size = avctx->gop_size;
+ctx->p_per_i  = INT_MAX;
+ctx->b_per_p  = avctx->max_b_frames;
+if (flags & FLAG_B_PICTURE_REFERENCES) {
+ctx->max_b_depth = FFMIN(ctx->desired_b_depth,
+ av_log2(ctx->b_per_p) + 1);
+} else {
+ctx->max_b_depth = 1;
+}
+}
+
+if (flags & FLAG_NON_IDR_KEY_PICTURES) {
+ctx->closed_gop  = !!(avctx->flags & AV_CODEC_FLAG_CLOSED_GOP);
+ctx->gop_per_idr = ctx->idr_interval + 1;
+} else {
+ctx->closed_gop  = 1;
+ctx->gop_per_idr = 1;
+}
+
+return 0;
+}
+
 int ff_hw_base_encode_init(AVCodecContext *avctx)
 {
 HWBaseEncodeContext *ctx = avctx->priv_data;
diff --git a/libavcodec/hw_base_encode.h b/libavcodec/hw_base_encode.h
index 014e56a04c..764385ab5a 100644
--- a/libavcodec/hw_base_encode.h
+++ b/libavcodec/hw_base_encode.h
@@ -234,6 +234,9 @@ int ff_hw_base_encode_set_output_property(AVCodecContext 
*avctx, HWBaseEncodePic
 
 int ff_hw_base_encode_receive_packet(AVCodecContext *avctx, AVPacket *pkt);
 
+int ff_hw_base_init_gop_structure(AVCodecContext *avctx, uint32_t ref_l0, 
uint32_t ref_l1,
+  int flags, int prediction_pre_only);
+
 int ff_hw_base_encode_init(AVCodecContext *avctx);
 
 int ff_hw_base_encode_close(AVCodecContext *avctx);
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 6da8c8a157..0f72fe5cb3 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -1567,7 +1567,7 @@ static av_cold int 
vaapi_encode_init_gop_structure(AVCodecContext *avctx)
 VAStatus vas;
 VAConfigAttrib attr = { VAConfigAttribEncMaxRefFrames };
 uint32_t ref_l0, ref_l1;
-int prediction_pre_only;
+int prediction_pre_only, err;
 
 vas = vaGetConfigAttributes(ctx->hwctx->display,
 ctx->va_profile,
@@ -1631,53 +1631,9 @@ static av_cold int 
vaapi_encode_init_gop_structure(AVCodecContext *avctx)
 }
 #endif
 
-if (ctx->codec->flags & FLAG_INTRA_ONLY ||
-avctx->gop_size <= 1) {
-av_log(avctx, AV_LOG_VERBOSE, "Using intra frames only.\n");
-base_ctx->gop_size = 1;
-} else if (ref_l0 < 1) {
-av_log(avctx, AV_LOG_ERROR, "Driver does not support any "
-   "reference frames.\n");
-return AVERROR(EINVAL);
-} else if (!(ctx->codec->flags & FLAG_B_PICTURES) ||
-   ref_l1 < 1 || avctx->max_b_frames < 1 ||
-   prediction_pre_only) {
-if (base_ctx->p_to_gpb)
-   av_log(avctx, AV_LOG_VERBOSE, "Using intra and B-frames "
-  "(supported references: %d / %d).\n",
-  ref_l0, ref_l1);
-else
-av_log(avctx, AV_LOG_VERBOSE, "Using intra and P-frames "
-   "(supported references: %d / %d).\n", ref_l0, ref_l1);
-base_ctx->gop_size = avctx->gop_size;
-base_ctx->p_per_i  = INT_MAX;
-base

[FFmpeg-devel] [PATCH v6 3/9] avcodec/vaapi_encode: extract set_output_property to base layer

2024-02-28 Thread tong1 . wu-at-intel . com
From: Tong Wu 

Signed-off-by: Tong Wu 
---
 libavcodec/hw_base_encode.c | 40 +
 libavcodec/hw_base_encode.h |  3 +++
 libavcodec/vaapi_encode.c   | 44 ++---
 3 files changed, 45 insertions(+), 42 deletions(-)

diff --git a/libavcodec/hw_base_encode.c b/libavcodec/hw_base_encode.c
index 204b80bc8c..799a817f7c 100644
--- a/libavcodec/hw_base_encode.c
+++ b/libavcodec/hw_base_encode.c
@@ -490,6 +490,46 @@ fail:
 return err;
 }
 
+int ff_hw_base_encode_set_output_property(AVCodecContext *avctx,
+  HWBaseEncodePicture *pic,
+  AVPacket *pkt, int flag_no_delay)
+{
+HWBaseEncodeContext *ctx = avctx->priv_data;
+
+if (pic->type == PICTURE_TYPE_IDR)
+pkt->flags |= AV_PKT_FLAG_KEY;
+
+pkt->pts = pic->pts;
+pkt->duration = pic->duration;
+
+// for no-delay encoders this is handled in generic codec
+if (avctx->codec->capabilities & AV_CODEC_CAP_DELAY &&
+avctx->flags & AV_CODEC_FLAG_COPY_OPAQUE) {
+pkt->opaque  = pic->opaque;
+pkt->opaque_ref  = pic->opaque_ref;
+pic->opaque_ref = NULL;
+}
+
+if (flag_no_delay) {
+pkt->dts = pkt->pts;
+return 0;
+}
+
+if (ctx->output_delay == 0) {
+pkt->dts = pkt->pts;
+} else if (pic->encode_order < ctx->decode_delay) {
+if (ctx->ts_ring[pic->encode_order] < INT64_MIN + ctx->dts_pts_diff)
+pkt->dts = INT64_MIN;
+else
+pkt->dts = ctx->ts_ring[pic->encode_order] - ctx->dts_pts_diff;
+} else {
+pkt->dts = ctx->ts_ring[(pic->encode_order - ctx->decode_delay) %
+(3 * ctx->output_delay + ctx->async_depth)];
+}
+
+return 0;
+}
+
 int ff_hw_base_encode_receive_packet(AVCodecContext *avctx, AVPacket *pkt)
 {
 HWBaseEncodeContext *ctx = avctx->priv_data;
diff --git a/libavcodec/hw_base_encode.h b/libavcodec/hw_base_encode.h
index 15be66f9e7..014e56a04c 100644
--- a/libavcodec/hw_base_encode.h
+++ b/libavcodec/hw_base_encode.h
@@ -229,6 +229,9 @@ typedef struct HWBaseEncodeContext {
 AVPacket*tail_pkt;
 } HWBaseEncodeContext;
 
+int ff_hw_base_encode_set_output_property(AVCodecContext *avctx, 
HWBaseEncodePicture *pic,
+  AVPacket *pkt, int flag_no_delay);
+
 int ff_hw_base_encode_receive_packet(AVCodecContext *avctx, AVPacket *pkt);
 
 int ff_hw_base_encode_init(AVCodecContext *avctx);
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 586d3ce860..6da8c8a157 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -657,47 +657,6 @@ fail_at_end:
 return err;
 }
 
-static int vaapi_encode_set_output_property(AVCodecContext *avctx,
-HWBaseEncodePicture *pic,
-AVPacket *pkt)
-{
-HWBaseEncodeContext *base_ctx = avctx->priv_data;
-VAAPIEncodeContext *ctx = avctx->priv_data;
-
-if (pic->type == PICTURE_TYPE_IDR)
-pkt->flags |= AV_PKT_FLAG_KEY;
-
-pkt->pts = pic->pts;
-pkt->duration = pic->duration;
-
-// for no-delay encoders this is handled in generic codec
-if (avctx->codec->capabilities & AV_CODEC_CAP_DELAY &&
-avctx->flags & AV_CODEC_FLAG_COPY_OPAQUE) {
-pkt->opaque = pic->opaque;
-pkt->opaque_ref = pic->opaque_ref;
-pic->opaque_ref = NULL;
-}
-
-if (ctx->codec->flags & FLAG_TIMESTAMP_NO_DELAY) {
-pkt->dts = pkt->pts;
-return 0;
-}
-
-if (base_ctx->output_delay == 0) {
-pkt->dts = pkt->pts;
-} else if (pic->encode_order < base_ctx->decode_delay) {
-if (base_ctx->ts_ring[pic->encode_order] < INT64_MIN + 
base_ctx->dts_pts_diff)
-pkt->dts = INT64_MIN;
-else
-pkt->dts = base_ctx->ts_ring[pic->encode_order] - 
base_ctx->dts_pts_diff;
-} else {
-pkt->dts = base_ctx->ts_ring[(pic->encode_order - 
base_ctx->decode_delay) %
- (3 * base_ctx->output_delay + 
base_ctx->async_depth)];
-}
-
-return 0;
-}
-
 static int vaapi_encode_get_coded_buffer_size(AVCodecContext *avctx, 
VABufferID buf_id)
 {
 VAAPIEncodeContext *ctx = avctx->priv_data;
@@ -849,7 +808,8 @@ static int vaapi_encode_output(AVCodecContext *avctx,
 av_log(avctx, AV_LOG_DEBUG, "Output read for pic %"PRId64"/%"PRId64".\n",
base_pic->display_order, base_pic->encode_order);
 
-vaapi_encode_set_output_property(avctx, (HWBaseEncodePicture*)base_pic, 
pkt_ptr);
+ff_hw_base_encode_set_output_property(avctx, 
(HWBaseEncodePicture*)base_pic, pkt_ptr,
+  ctx->codec->flags & 
FLAG_TIMESTAMP_NO_DELAY);
 
 end:
 ff_refstruct_unref(&pic->output_buffer_ref);
-- 
2.41.0.windows.1

___
ffmpeg-devel ma

[FFmpeg-devel] [PATCH v6 1/9] avcodec/vaapi_encode: move pic->input_surface initialization to encode_alloc

2024-02-28 Thread tong1 . wu-at-intel . com
From: Tong Wu 

When allocating the VAAPIEncodePicture, pic->input_surface can be
initialized right in the place. This movement simplifies the send_frame
logic and is the preparation for moving vaapi_encode_send_frame to the base 
layer.

Signed-off-by: Tong Wu 
---
 libavcodec/vaapi_encode.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 808b79c0c7..bd29dbf0b4 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -878,7 +878,8 @@ static int vaapi_encode_discard(AVCodecContext *avctx,
 return 0;
 }
 
-static VAAPIEncodePicture *vaapi_encode_alloc(AVCodecContext *avctx)
+static VAAPIEncodePicture *vaapi_encode_alloc(AVCodecContext *avctx,
+  const AVFrame *frame)
 {
 VAAPIEncodeContext *ctx = avctx->priv_data;
 VAAPIEncodePicture *pic;
@@ -895,7 +896,7 @@ static VAAPIEncodePicture 
*vaapi_encode_alloc(AVCodecContext *avctx)
 }
 }
 
-pic->input_surface = VA_INVALID_ID;
+pic->input_surface = (VASurfaceID)(uintptr_t)frame->data[3];
 pic->recon_surface = VA_INVALID_ID;
 pic->output_buffer = VA_INVALID_ID;
 
@@ -1331,7 +1332,7 @@ static int vaapi_encode_send_frame(AVCodecContext *avctx, 
AVFrame *frame)
 if (err < 0)
 return err;
 
-pic = vaapi_encode_alloc(avctx);
+pic = vaapi_encode_alloc(avctx, frame);
 if (!pic)
 return AVERROR(ENOMEM);
 
@@ -1344,7 +1345,6 @@ static int vaapi_encode_send_frame(AVCodecContext *avctx, 
AVFrame *frame)
 if (ctx->input_order == 0 || frame->pict_type == AV_PICTURE_TYPE_I)
 pic->force_idr = 1;
 
-pic->input_surface = (VASurfaceID)(uintptr_t)frame->data[3];
 pic->pts = frame->pts;
 pic->duration = frame->duration;
 
-- 
2.41.0.windows.1

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

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


[FFmpeg-devel] [PATCH v1 2/2] lavc/vaapi_encode_h265: Set general_*_constriaint flags with profile

2024-02-28 Thread fei . w . wang-at-intel . com
From: Fei Wang 

According to Table A.2 in spec.

Signed-off-by: Fei Wang 
---
 libavcodec/vaapi_encode_h265.c | 181 +++--
 1 file changed, 128 insertions(+), 53 deletions(-)

diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index 43755e2188..7c9916eac8 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -258,6 +258,129 @@ fail:
 return err;
 }
 
+static int vaapi_encode_h265_init_ptl(AVCodecContext *avctx)
+{
+VAAPIEncodeContext  *ctx = avctx->priv_data;
+VAAPIEncodeH265Context *priv = avctx->priv_data;
+H265RawVPS  *vps = &priv->raw_vps;
+H265RawProfileTierLevel *ptl = &vps->profile_tier_level;
+
+ptl->general_profile_space = 0;
+ptl->general_profile_idc   = avctx->profile;
+ptl->general_tier_flag = priv->tier;
+
+ptl->general_profile_compatibility_flag[ptl->general_profile_idc] = 1;
+
+if (ptl->general_profile_compatibility_flag[1])
+ptl->general_profile_compatibility_flag[2] = 1;
+if (ptl->general_profile_compatibility_flag[3]) {
+ptl->general_profile_compatibility_flag[1] = 1;
+ptl->general_profile_compatibility_flag[2] = 1;
+}
+
+ptl->general_progressive_source_flag= 1;
+ptl->general_interlaced_source_flag = 0;
+ptl->general_non_packed_constraint_flag = 1;
+ptl->general_frame_only_constraint_flag = 1;
+
+if (avctx->profile >= 4) {
+ptl->general_intra_constraint_flag= ctx->gop_size == 1;
+ptl->general_one_picture_only_constraint_flag = 0;
+ptl->general_lower_bit_rate_constraint_flag   = 1;
+
+switch (ctx->va_profile) {
+#if VA_CHECK_VERSION(1, 2, 0)
+case VAProfileHEVCMain12:
+// Main 12
+ptl->general_max_14bit_constraint_flag  = 0;
+ptl->general_max_12bit_constraint_flag  = 1;
+ptl->general_max_10bit_constraint_flag  = 0;
+ptl->general_max_8bit_constraint_flag   = 0;
+ptl->general_max_422chroma_constraint_flag  = 1;
+ptl->general_max_420chroma_constraint_flag  = 1;
+ptl->general_max_monochrome_constraint_flag = 0;
+break;
+case VAProfileHEVCMain422_10:
+// Main 4:2:2 10
+ptl->general_max_14bit_constraint_flag  = 0;
+ptl->general_max_12bit_constraint_flag  = 1;
+ptl->general_max_10bit_constraint_flag  = 1;
+ptl->general_max_8bit_constraint_flag   = 0;
+ptl->general_max_422chroma_constraint_flag  = 1;
+ptl->general_max_420chroma_constraint_flag  = 0;
+ptl->general_max_monochrome_constraint_flag = 0;
+break;
+case VAProfileHEVCMain422_12:
+// Main 4:2:2 12
+ptl->general_max_14bit_constraint_flag  = 0;
+ptl->general_max_12bit_constraint_flag  = 1;
+ptl->general_max_10bit_constraint_flag  = 0;
+ptl->general_max_8bit_constraint_flag   = 0;
+ptl->general_max_422chroma_constraint_flag  = 1;
+ptl->general_max_420chroma_constraint_flag  = 0;
+ptl->general_max_monochrome_constraint_flag = 0;
+break;
+case VAProfileHEVCMain444:
+// Main 4:4:4
+ptl->general_max_14bit_constraint_flag  = 0;
+ptl->general_max_12bit_constraint_flag  = 1;
+ptl->general_max_10bit_constraint_flag  = 1;
+ptl->general_max_8bit_constraint_flag   = 1;
+ptl->general_max_422chroma_constraint_flag  = 0;
+ptl->general_max_420chroma_constraint_flag  = 0;
+ptl->general_max_monochrome_constraint_flag = 0;
+break;
+case VAProfileHEVCMain444_10:
+// Main 4:4:4 10
+ptl->general_max_14bit_constraint_flag  = 0;
+ptl->general_max_12bit_constraint_flag  = 1;
+ptl->general_max_10bit_constraint_flag  = 1;
+ptl->general_max_8bit_constraint_flag   = 0;
+ptl->general_max_422chroma_constraint_flag  = 0;
+ptl->general_max_420chroma_constraint_flag  = 0;
+ptl->general_max_monochrome_constraint_flag = 0;
+break;
+case VAProfileHEVCMain444_12:
+// Main 4:4:4 12
+ptl->general_max_14bit_constraint_flag  = 0;
+ptl->general_max_12bit_constraint_flag  = 1;
+ptl->general_max_10bit_constraint_flag  = 0;
+ptl->general_max_8bit_constraint_flag   = 0;
+ptl->general_max_422chroma_constraint_flag  = 0;
+ptl->general_max_420chroma_constraint_flag  = 0;
+ptl->general_max_monochrome_constraint_flag = 0;
+break;
+#endif
+default:
+av_log(avctx, AV_LOG_ERROR, "Unknown profile to init PTL.\n");
+return AVERROR(EINVAL);
+  

[FFmpeg-devel] [PATCH v1 1/2] lavc/vaapi_encode_h265: Map HEVC AV REXT profile to VA REXT profile

2024-02-28 Thread fei . w . wang-at-intel . com
From: Fei Wang 

Signed-off-by: Fei Wang 
---
 libavcodec/vaapi_encode_h265.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index c4aabbf5ed..43755e2188 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -1305,12 +1305,12 @@ static av_cold int 
vaapi_encode_h265_configure(AVCodecContext *avctx)
 
 static const VAAPIEncodeProfile vaapi_encode_h265_profiles[] = {
 { AV_PROFILE_HEVC_MAIN, 8, 3, 1, 1, VAProfileHEVCMain   },
-{ AV_PROFILE_HEVC_REXT, 8, 3, 1, 1, VAProfileHEVCMain   },
 #if VA_CHECK_VERSION(0, 37, 0)
 { AV_PROFILE_HEVC_MAIN_10, 10, 3, 1, 1, VAProfileHEVCMain10 },
-{ AV_PROFILE_HEVC_REXT,10, 3, 1, 1, VAProfileHEVCMain10 },
 #endif
 #if VA_CHECK_VERSION(1, 2, 0)
+{ AV_PROFILE_HEVC_REXT, 8, 3, 1, 1, VAProfileHEVCMain12 },
+{ AV_PROFILE_HEVC_REXT,10, 3, 1, 1, VAProfileHEVCMain12 },
 { AV_PROFILE_HEVC_REXT,12, 3, 1, 1, VAProfileHEVCMain12 },
 { AV_PROFILE_HEVC_REXT, 8, 3, 1, 0, VAProfileHEVCMain422_10 },
 { AV_PROFILE_HEVC_REXT,10, 3, 1, 0, VAProfileHEVCMain422_10 },
-- 
2.25.1

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

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


Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio

2024-02-28 Thread Vittorio Giovara
On Wed, Feb 28, 2024 at 11:13 PM Lynne  wrote:

> Feb 28, 2024, 14:29 by mich...@niedermayer.cc:
>
> > On Wed, Feb 28, 2024 at 01:56:10PM +0100, J. Dekker wrote:
> >
> >> This was an experimental/research codec of which ffmpeg is the only
> >> encoder and decoder,
> >>
> >
> >
> >> development has stalled
> >>
> >
> > Thats not true, there was private dicussion making sonic the most
> > advanced audio codec in FFmpeg a few months ago.
> > Iam not saying that will happen, i am just saying there was a
> > discussion about it. And that iam in principle interrested in
> > working on this. Its possible i will not have enough time ...
> >
>
> I would strongly prefer for it to be kept around as well.
>
> Otherwise it creates precedence to throw out codecs if they're
> not popular enough, and we're known for being able to play
> most formats ever created.
>

IMO there is a big difference between a game codec and an experimental
codec that hasn't come out of ffmpeg
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


[FFmpeg-devel] [PATCH] avcodec/x86/fpel: Remove remnants of MMX

2024-02-28 Thread Andreas Rheinhardt
Since 7cad4dba505f9ad0adf013dd5bdf02a57249eecc
averaging functions only exist for MMXEXT and SSE2.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/x86/fpel.asm | 23 ---
 1 file changed, 23 deletions(-)

diff --git a/libavcodec/x86/fpel.asm b/libavcodec/x86/fpel.asm
index 278d1410fc..b07b789074 100644
--- a/libavcodec/x86/fpel.asm
+++ b/libavcodec/x86/fpel.asm
@@ -25,16 +25,6 @@
 
 SECTION .text
 
-%macro PAVGB_MMX 4
-LOAD   %3, %1
-por%3, %2
-pxor   %2, %1
-pand   %2, %4
-psrlq  %2, 1
-psubb  %3, %2
-SWAP   %2, %3
-%endmacro
-
 ; void ff_put/avg_pixels(uint8_t *block, const uint8_t *pixels,
 ;ptrdiff_t line_size, int h)
 %macro OP_PIXELS 2
@@ -49,12 +39,6 @@ SECTION .text
 %endif
 cglobal %1_pixels%2, 4,5,4
 lea  r4, [r2*3]
-%ifidn %1, avg
-%if notcpuflag(mmxext)
-pcmpeqd  m6, m6
-paddbm6, m6
-%endif
-%endif
 .loop:
 %assign %%i 0
 %rep LEN/mmsize
@@ -63,17 +47,10 @@ cglobal %1_pixels%2, 4,5,4
 LOAD m2, [r1+r2*2 + %%i]
 LOAD m3, [r1+r4 + %%i]
 %ifidn %1, avg
-%if notcpuflag(mmxext)
-PAVGB_MMX[r0 + %%i], m0, m4, m6
-PAVGB_MMX[r0+r2 + %%i], m1, m5, m6
-PAVGB_MMX[r0+r2*2 + %%i], m2, m4, m6
-PAVGB_MMX[r0+r4 + %%i], m3, m5, m6
-%else
 pavgbm0, [r0 + %%i]
 pavgbm1, [r0+r2 + %%i]
 pavgbm2, [r0+r2*2 + %%i]
 pavgbm3, [r0+r4 + %%i]
-%endif
 %endif
 SAVE   [r0 + %%i], m0
 SAVE[r0+r2 + %%i], m1
-- 
2.40.1

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

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


Re: [FFmpeg-devel] [PATCH 2/2] swresample/resample: rework resample_one function to work the same way as the others

2024-02-28 Thread Marton Balint




On Wed, 28 Feb 2024, Michael Niedermayer wrote:


On Tue, Feb 27, 2024 at 09:50:49PM +0100, Marton Balint wrote:



On Tue, 27 Feb 2024, Michael Niedermayer wrote:


On Tue, Feb 27, 2024 at 10:48:10AM +0100, Marton Balint wrote:

Signed-off-by: Marton Balint 
---
 libswresample/resample.c  | 29 +++--
 libswresample/resample.h  |  4 ++--
 libswresample/resample_template.c | 14 --
 3 files changed, 21 insertions(+), 26 deletions(-)


what effect does this have on speed ?


For the following command line

time ./ffprobe -f lavfi \
"sine=440:r=8000:d=86400:samples_per_frame=2048,aresample=24000:filter_size=1:phase_shift=0"
 \
-show_packets >/dev/null

Before the patch:

real0m3,916s
user0m3,812s
sys 0m0,104s

After the patch:

real0m3,597s
user0m3,457s
sys 0m0,140s

So it actually speed things up.


is resample_one used in both cases ?


Sure. The patch does not change the conditions when resample_one is used.

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

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


Re: [FFmpeg-devel] [PATCH 4/4] avformat/wavdec: dynamically set max_size by default

2024-02-28 Thread Marton Balint




On Thu, 29 Feb 2024, Andreas Rheinhardt wrote:


Marton Balint:

The wav demuxer by default tried to demux 4096-byte packets which caused
packets with very few number of samples for files with high channel count.
This caused a significant overhead especially since the latest ffmpeg.c
threading changes.

So let's use a similar approach for selecting audio frame size which is already
used in the PCM demuxer, which is to read 25 times per second but at most 1024
samples.


1024 samples seems to be quite small, in particular for files with few
channels (like stereo).


1024 is kind of a historical default. Also having multiples of 1024 is 
beneficial for some codecs which encode this many samples per frame.


In any case, I am not against somewhat increasing this, but it should be 
done for both PCM and WAV, it can be a separate patch and discussion.


Regards,
Marton

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

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


Re: [FFmpeg-devel] [PATCH 4/4] avformat/wavdec: dynamically set max_size by default

2024-02-28 Thread Andreas Rheinhardt
Marton Balint:
> The wav demuxer by default tried to demux 4096-byte packets which caused
> packets with very few number of samples for files with high channel count.
> This caused a significant overhead especially since the latest ffmpeg.c
> threading changes.
> 
> So let's use a similar approach for selecting audio frame size which is 
> already
> used in the PCM demuxer, which is to read 25 times per second but at most 1024
> samples.

1024 samples seems to be quite small, in particular for files with few
channels (like stereo).

- Andreas

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

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


Re: [FFmpeg-devel] [PATCH 2/2] swresample/resample: rework resample_one function to work the same way as the others

2024-02-28 Thread Michael Niedermayer
On Tue, Feb 27, 2024 at 09:50:49PM +0100, Marton Balint wrote:
> 
> 
> On Tue, 27 Feb 2024, Michael Niedermayer wrote:
> 
> > On Tue, Feb 27, 2024 at 10:48:10AM +0100, Marton Balint wrote:
> > > Signed-off-by: Marton Balint 
> > > ---
> > >  libswresample/resample.c  | 29 +++--
> > >  libswresample/resample.h  |  4 ++--
> > >  libswresample/resample_template.c | 14 --
> > >  3 files changed, 21 insertions(+), 26 deletions(-)
> > 
> > what effect does this have on speed ?
> 
> For the following command line
> 
> time ./ffprobe -f lavfi \
> "sine=440:r=8000:d=86400:samples_per_frame=2048,aresample=24000:filter_size=1:phase_shift=0"
>  \
> -show_packets >/dev/null
> 
> Before the patch:
> 
> real  0m3,916s
> user  0m3,812s
> sys   0m0,104s
> 
> After the patch:
> 
> real0m3,597s
> user0m3,457s
> sys 0m0,140s
> 
> So it actually speed things up.

is resample_one used in both cases ?

thx

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

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 


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

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


Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio

2024-02-28 Thread Lynne
Feb 28, 2024, 14:29 by mich...@niedermayer.cc:

> On Wed, Feb 28, 2024 at 01:56:10PM +0100, J. Dekker wrote:
>
>> This was an experimental/research codec of which ffmpeg is the only
>> encoder and decoder,
>>
>
>
>> development has stalled
>>
>
> Thats not true, there was private dicussion making sonic the most
> advanced audio codec in FFmpeg a few months ago.
> Iam not saying that will happen, i am just saying there was a
> discussion about it. And that iam in principle interrested in
> working on this. Its possible i will not have enough time ...
>

I would strongly prefer for it to be kept around as well.

Otherwise it creates precedence to throw out codecs if they're
not popular enough, and we're known for being able to play
most formats ever created.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


Re: [FFmpeg-devel] [PATCH 1/3] lavc/vp8dsp: R-V V put_bilin_h

2024-02-28 Thread Rémi Denis-Courmont
Le lauantaina 24. helmikuuta 2024, 10.31.36 EET flow gg a écrit :
> Okay, Thanks for clarifying.
> 
> I have used many fractional multipliers, mostly not for correctness, but
> often for performance improvements (though I don't know why),
> and there are no obvious downsides, How about leaving this code?

In this case, it does not affect the baseline requirements. It will be 
problematic if performance ends up worse on other future designs, but we can 
cross that bridge if and then.

-- 
レミ・デニ-クールモン
http://www.remlab.net/



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

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


Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio

2024-02-28 Thread Rémi Denis-Courmont
Le keskiviikkona 28. helmikuuta 2024, 19.55.11 EET James Almer a écrit :
> > The last commit which actually changed the codec was
> > 6026a5ad4f135476c7a1f51f8cfa7f4cc2ca0283 by you in 2013 which is over 10
> > years ago. For an experimental codec I think it's pretty safe to say
> > that development has stalled.
> > 
> > Keeping the codec around based on 'what if?'s doesn't seem
> > reasonable. Besides, if you do make sonic the most advanced audio codec
> > in FFmpeg there's nothing which says you couldn't re-add it at a later
> > date when it's being actively developed again.
> 
> Does it hurt keeping it around?

Considering the sheer number of audio codecs in libavcodec, the difference is 
peanuts. But in principle, any dead code is an extra maintenance burden, 
whether it be reported security vulnerabilities that "need" to be fixed to 
appease Linux distros and corporate freeloaders, or to update the internal 
interfaces.

> If it can at some point be developed
> again, then removing the codec id to re-add it later will be a bit dirty.

Slightly, but the chance of that seem almost zero. Also compared to moving 
stuff in and out of staging like the kernel does, or between good, bad and ugly 
like a certain competing OSS framework does, it's pretty much nothing. People 
are not going to ditch FFmpeg on the basis of misusing the VCS over that 
hypothetical.

-- 
雷米‧德尼-库尔蒙
http://www.remlab.net/



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

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


[FFmpeg-devel] [PATCH] avcodec/proresenc_kostya: Remove bug similarity text

2024-02-28 Thread Michael Niedermayer
According to kostya, it is not based on Wassermans encoder

CC: Kostya Shishkov 
CC: Anatoliy Wasserman 

Signed-off-by: Michael Niedermayer 
---
 libavcodec/proresenc_kostya.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c
index 45385213ac..90cc87e388 100644
--- a/libavcodec/proresenc_kostya.c
+++ b/libavcodec/proresenc_kostya.c
@@ -4,9 +4,6 @@
  * Copyright (c) 2011 Anatoliy Wasserman
  * Copyright (c) 2012 Konstantin Shishkov
  *
- * This encoder appears to be based on Anatoliy Wassermans considering
- * similarities in the bugs.
- *
  * This file is part of FFmpeg.
  *
  * FFmpeg is free software; you can redistribute it and/or
-- 
2.17.1

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

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


[FFmpeg-devel] [PATCH 4/4] fftools/ffmpeg_demux, sync_queue: Constify a bit

2024-02-28 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 fftools/ffmpeg_demux.c | 2 +-
 fftools/sync_queue.c   | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/fftools/ffmpeg_demux.c b/fftools/ffmpeg_demux.c
index d5a3dbc1d2..29f4a26224 100644
--- a/fftools/ffmpeg_demux.c
+++ b/fftools/ffmpeg_demux.c
@@ -161,7 +161,7 @@ InputStream *ist_find_unused(enum AVMediaType type)
 
 static void report_new_stream(Demuxer *d, const AVPacket *pkt)
 {
-AVStream *st = d->f.ctx->streams[pkt->stream_index];
+const AVStream *st = d->f.ctx->streams[pkt->stream_index];
 
 if (pkt->stream_index < d->nb_streams_warn)
 return;
diff --git a/fftools/sync_queue.c b/fftools/sync_queue.c
index bc107ba4fe..0e35b5b1cb 100644
--- a/fftools/sync_queue.c
+++ b/fftools/sync_queue.c
@@ -319,7 +319,7 @@ static int overflow_heartbeat(SyncQueue *sq, int stream_idx)
 /* signal a fake timestamp for all streams that prevent tail_ts from being 
output */
 tail_ts++;
 for (unsigned int i = 0; i < sq->nb_streams; i++) {
-SyncQueueStream *st1 = &sq->streams[i];
+const SyncQueueStream *st1 = &sq->streams[i];
 int64_t ts;
 
 if (st == st1 || st1->finished ||
@@ -524,8 +524,8 @@ fail:
 static int receive_for_stream(SyncQueue *sq, unsigned int stream_idx,
   SyncQueueFrame frame)
 {
-SyncQueueStream *st_head = sq->head_stream >= 0 ?
-   &sq->streams[sq->head_stream] : NULL;
+const SyncQueueStream *st_head = sq->head_stream >= 0 ?
+ &sq->streams[sq->head_stream] : NULL;
 SyncQueueStream *st;
 
 av_assert0(stream_idx < sq->nb_streams);
-- 
2.40.1

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

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


[FFmpeg-devel] [PATCH 3/4] swresample/swresample: Constify swr_convert()

2024-02-28 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 doc/APIchanges | 3 +++
 libswresample/swresample.c | 7 ---
 libswresample/swresample.h | 4 ++--
 libswresample/version.h| 2 +-
 4 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 2fca5b7ea8..7d34d12c62 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,9 @@ The last version increases of all libraries were on 2023-02-09
 
 API changes, most recent first:
 
+2024-02-28 - xx - swr   4.14.100 - swresample.h
+  swr_convert() now accepts arrays of const pointers (to input and output).
+
 2024-02-28 - xx - lavu 58.xx.100 - timestamp.h
   av_ts_make_time_string() now accepts a pointer to const AVRational.
 
diff --git a/libswresample/swresample.c b/libswresample/swresample.c
index 1cf83a803f..6948892d76 100644
--- a/libswresample/swresample.c
+++ b/libswresample/swresample.c
@@ -563,7 +563,8 @@ static void copy(AudioData *out, AudioData *in,
 memcpy(out->ch[0], in->ch[0], count*out->ch_count*out->bps);
 }
 
-static void fill_audiodata(AudioData *out, uint8_t *in_arg [SWR_CH_MAX]){
+static void fill_audiodata(AudioData *out, uint8_t *const in_arg [SWR_CH_MAX])
+{
 int i;
 if(!in_arg){
 memset(out->ch, 0, sizeof(out->ch));
@@ -835,8 +836,8 @@ int swr_is_initialized(struct SwrContext *s) {
 }
 
 int attribute_align_arg swr_convert(struct SwrContext *s,
-  uint8_t **out_arg, int out_count,
-const uint8_t **in_arg,  int in_count)
+  uint8_t * const *out_arg, int 
out_count,
+const uint8_t * const *in_arg,  int 
in_count)
 {
 AudioData * in= &s->in;
 AudioData *out= &s->out;
diff --git a/libswresample/swresample.h b/libswresample/swresample.h
index d4dcaebdcf..78495a0d4c 100644
--- a/libswresample/swresample.h
+++ b/libswresample/swresample.h
@@ -340,8 +340,8 @@ void swr_close(struct SwrContext *s);
  *
  * @return number of samples output per channel, negative value on error
  */
-int swr_convert(struct SwrContext *s, uint8_t **out, int out_count,
-const uint8_t **in , int in_count);
+int swr_convert(struct SwrContext *s, uint8_t * const *out, int out_count,
+const uint8_t * const *in , int in_count);
 
 /**
  * Convert the next timestamp from input to output
diff --git a/libswresample/version.h b/libswresample/version.h
index 46a4e2fc62..dfaf6f8c42 100644
--- a/libswresample/version.h
+++ b/libswresample/version.h
@@ -30,7 +30,7 @@
 
 #include "version_major.h"
 
-#define LIBSWRESAMPLE_VERSION_MINOR  13
+#define LIBSWRESAMPLE_VERSION_MINOR  14
 #define LIBSWRESAMPLE_VERSION_MICRO 100
 
 #define LIBSWRESAMPLE_VERSION_INT  AV_VERSION_INT(LIBSWRESAMPLE_VERSION_MAJOR, 
\
-- 
2.40.1

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

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


[FFmpeg-devel] [PATCH 2/4] avutil/timestamp: Constify av_ts_make_time_string()

2024-02-28 Thread Andreas Rheinhardt
(Actually, the time base should be passed by value.)

Signed-off-by: Andreas Rheinhardt 
---
 doc/APIchanges| 3 +++
 libavutil/timestamp.h | 3 ++-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 055e6848a3..2fca5b7ea8 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,9 @@ The last version increases of all libraries were on 2023-02-09
 
 API changes, most recent first:
 
+2024-02-28 - xx - lavu 58.xx.100 - timestamp.h
+  av_ts_make_time_string() now accepts a pointer to const AVRational.
+
 2024-02-28 - xx - lavf 60.xx.100 - avio.h
   avio_print_string_array() now accepts an array of const pointers.
 
diff --git a/libavutil/timestamp.h b/libavutil/timestamp.h
index 9ae64da8a1..2b37781eba 100644
--- a/libavutil/timestamp.h
+++ b/libavutil/timestamp.h
@@ -62,7 +62,8 @@ static inline char *av_ts_make_string(char *buf, int64_t ts)
  * @param tb the timebase of the timestamp
  * @return the buffer in input
  */
-static inline char *av_ts_make_time_string(char *buf, int64_t ts, AVRational 
*tb)
+static inline char *av_ts_make_time_string(char *buf, int64_t ts,
+   const AVRational *tb)
 {
 if (ts == AV_NOPTS_VALUE) snprintf(buf, AV_TS_MAX_STRING_SIZE, "NOPTS");
 else  snprintf(buf, AV_TS_MAX_STRING_SIZE, "%.6g", 
av_q2d(*tb) * ts);
-- 
2.40.1

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

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


[FFmpeg-devel] [PATCH 1/4] avformat/avio: Make avio_print_string_array() accept const pointers

2024-02-28 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 doc/APIchanges| 3 +++
 libavformat/avio.h| 2 +-
 libavformat/aviobuf.c | 2 +-
 3 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 10f6667e9e..055e6848a3 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,9 @@ The last version increases of all libraries were on 2023-02-09
 
 API changes, most recent first:
 
+2024-02-28 - xx - lavf 60.xx.100 - avio.h
+  avio_print_string_array() now accepts an array of const pointers.
+
 2024-02-26 - xx - lavf 60.22.101 - avformat.h
   AV_DISPOSITION_DEPENDENT may now also be used for video streams
   intended to be merged with other video streams for presentation.
diff --git a/libavformat/avio.h b/libavformat/avio.h
index 887a397c37..43bce60ffd 100644
--- a/libavformat/avio.h
+++ b/libavformat/avio.h
@@ -544,7 +544,7 @@ int avio_printf(AVIOContext *s, const char *fmt, ...) 
av_printf_format(2, 3);
  * Usually you don't need to use this function directly but its macro wrapper,
  * avio_print.
  */
-void avio_print_string_array(AVIOContext *s, const char *strings[]);
+void avio_print_string_array(AVIOContext *s, const char * const strings[]);
 
 /**
  * Write strings (const char *) to the context.
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 76780bc852..d80b8527bb 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -1400,7 +1400,7 @@ int avio_printf(AVIOContext *s, const char *fmt, ...)
 return ret;
 }
 
-void avio_print_string_array(AVIOContext *s, const char *strings[])
+void avio_print_string_array(AVIOContext *s, const char *const strings[])
 {
 for(; *strings; strings++)
 avio_write(s, (const unsigned char *)*strings, strlen(*strings));
-- 
2.40.1

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

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


Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio

2024-02-28 Thread Jean-Baptiste Kempf



On Wed, 28 Feb 2024, at 18:55, James Almer wrote:
> On 2/28/2024 10:31 AM, J. Dekker wrote:
>> 
>> Michael Niedermayer  writes:
>> 
>>> [[PGP Signed Part:Undecided]]
>>> On Wed, Feb 28, 2024 at 01:56:10PM +0100, J. Dekker wrote:
 This was an experimental/research codec of which ffmpeg is the only
 encoder and decoder,
>>>
>>>
 development has stalled
>>>
>>> Thats not true, there was private dicussion making sonic the most
>>> advanced audio codec in FFmpeg a few months ago.
>>> Iam not saying that will happen, i am just saying there was a
>>> discussion about it. And that iam in principle interrested in
>>> working on this. Its possible i will not have enough time ...
>>>
>> 
>> The last commit which actually changed the codec was
>> 6026a5ad4f135476c7a1f51f8cfa7f4cc2ca0283 by you in 2013 which is over 10
>> years ago. For an experimental codec I think it's pretty safe to say
>> that development has stalled.
>> 
>> Keeping the codec around based on 'what if?'s doesn't seem
>> reasonable. Besides, if you do make sonic the most advanced audio codec
>> in FFmpeg there's nothing which says you couldn't re-add it at a later
>> date when it's being actively developed again.
>
> Does it hurt keeping it around? If it can at some point be developed 
> again, then removing the codec id to re-add it later will be a bit dirty.
>
> IMO, just disable both modules by default during configure, or tag the 
> encoder as experimental to prevent new streams to be created unless 
> explicitly requested knowing that it's an unfinished format.

+1

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


[FFmpeg-devel] [PATCH] avcodec/x86/rv40dsp, simple_idct: Remove remnants of MMX

2024-02-28 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/x86/rv40dsp.asm | 10 --
 libavcodec/x86/simple_idct.asm | 36 --
 2 files changed, 46 deletions(-)

diff --git a/libavcodec/x86/rv40dsp.asm b/libavcodec/x86/rv40dsp.asm
index e02ad2c63f..e3c37dd297 100644
--- a/libavcodec/x86/rv40dsp.asm
+++ b/libavcodec/x86/rv40dsp.asm
@@ -401,15 +401,6 @@ FILTER_SSSE3  avg
 
 
 %macro MAIN_LOOP   2
-%if mmsize == 8
-RV40_WCORE %2, r0, r1, r2
-%if %1 == 16
-RV40_WCORE %2, r0 + 8, r1 + 8, r2 + 8
-%endif
-
-; Prepare for next loop
-addr6, r5
-%else
 %ifidn %1, 8
 RV40_WCORE %2, r0, r1, r2, r5
 ; Prepare 2 next lines
@@ -419,7 +410,6 @@ FILTER_SSSE3  avg
 ; Prepare single next line
 addr6, r5
 %endif
-%endif
 
 %endmacro
 
diff --git a/libavcodec/x86/simple_idct.asm b/libavcodec/x86/simple_idct.asm
index 4139b6dab5..c79519372a 100644
--- a/libavcodec/x86/simple_idct.asm
+++ b/libavcodec/x86/simple_idct.asm
@@ -783,62 +783,26 @@ SECTION .text
 %macro PUT_PIXELS_CLAMPED_HALF 1
 mova m0, [blockq+mmsize*0+%1]
 mova m1, [blockq+mmsize*2+%1]
-%if mmsize == 8
-mova m2, [blockq+mmsize*4+%1]
-mova m3, [blockq+mmsize*6+%1]
-%endif
 packuswb m0, [blockq+mmsize*1+%1]
 packuswb m1, [blockq+mmsize*3+%1]
-%if mmsize == 8
-packuswb m2, [blockq+mmsize*5+%1]
-packuswb m3, [blockq+mmsize*7+%1]
-movq   [pixelsq], m0
-movq[lsizeq+pixelsq], m1
-movq  [2*lsizeq+pixelsq], m2
-movq   [lsize3q+pixelsq], m3
-%else
 movq   [pixelsq], m0
 movhps  [lsizeq+pixelsq], m0
 movq  [2*lsizeq+pixelsq], m1
 movhps [lsize3q+pixelsq], m1
-%endif
 %endmacro
 
 %macro ADD_PIXELS_CLAMPED 1
 mova   m0, [blockq+mmsize*0+%1]
 mova   m1, [blockq+mmsize*1+%1]
-%if mmsize == 8
-mova   m5, [blockq+mmsize*2+%1]
-mova   m6, [blockq+mmsize*3+%1]
-%endif
 movq   m2, [pixelsq]
 movq   m3, [pixelsq+lsizeq]
-%if mmsize == 8
-mova   m7, m2
-punpcklbw  m2, m4
-punpckhbw  m7, m4
-paddsw m0, m2
-paddsw m1, m7
-mova   m7, m3
-punpcklbw  m3, m4
-punpckhbw  m7, m4
-paddsw m5, m3
-paddsw m6, m7
-%else
 punpcklbw  m2, m4
 punpcklbw  m3, m4
 paddsw m0, m2
 paddsw m1, m3
-%endif
 packuswb   m0, m1
-%if mmsize == 8
-packuswb   m5, m6
-movq   [pixelsq], m0
-movq   [pixelsq+lsizeq], m5
-%else
 movq   [pixelsq], m0
 movhps [pixelsq+lsizeq], m0
-%endif
 %endmacro
 
 INIT_MMX mmx
-- 
2.40.1

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

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


Re: [FFmpeg-devel] [PATCH v6 12/13] avcodec/libx264: add support for writing out CLL and MDCV

2024-02-28 Thread Jan Ekström
On Wed, Feb 28, 2024 at 1:39 AM Jan Ekström  wrote:
>
> On Wed, Feb 28, 2024 at 12:24 AM Andreas Rheinhardt
>  wrote:
> >
> > Jan Ekström:
> > > Both of these two structures were first available with X264_BUILD
> > > 163, so make relevant functionality conditional on the version
> > > being at least such.
> > >
> > > Keep handle_side_data available in all cases as this way X264_init
> > > does not require additional version based conditions within it.
> > >
> > > Finally, add a FATE test which verifies that pass-through of the
> > > MDCV/CLL side data is working during encoding.
> > > ---
> > >  configure|  2 +
> > >  libavcodec/libx264.c | 79 
> > >  tests/fate/enc_external.mak  |  5 +++
> > >  tests/ref/fate/libx264-hdr10 | 15 +++
> > >  4 files changed, 101 insertions(+)
> > >  create mode 100644 tests/ref/fate/libx264-hdr10
> > >
> > > diff --git a/configure b/configure
> > > index bb5e630bad..f48cf46ffe 100755
> > > --- a/configure
> > > +++ b/configure
> > > @@ -2527,6 +2527,7 @@ CONFIG_EXTRA="
> > >  jpegtables
> > >  lgplv3
> > >  libx262
> > > +libx264_hdr10
> > >  llauddsp
> > >  llviddsp
> > >  llvidencdsp
> > > @@ -6927,6 +6928,7 @@ enabled libx264   && require_pkg_config 
> > > libx264 x264 "stdint.h x264.h" x
> > >   require_cpp_condition libx264 x264.h 
> > > "X264_BUILD >= 122" && {
> > >   [ "$toolchain" != "msvc" ] ||
> > >   require_cpp_condition libx264 x264.h 
> > > "X264_BUILD >= 158"; } &&
> > > + check_cpp_condition libx264_hdr10 x264.h 
> > > "X264_BUILD >= 163" &&
> >
> > Why don't you just check X264_BUILD in libx264.c instead of adding this
> > to configure?
> >
>
> Most likely due to months ago it feeling like a cleaner option for
> whatever reason (less magical numbers). Although in theory you can get
> a similar named define by checking it within the module, yes.
>

Finally remembered what the actual reason was while modifying the
commit to see if I could move to a simple X264_BUILD check.

The FATE test added requires this newer version, and not just any
enabled libx264. So the define from configure is utilized for that.
Not sure you can utilize simple x264.h checks for X264_BUILD >= 163
for that :) .

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 2/2] avcodec: remove sonic lossy/lossless audio

2024-02-28 Thread James Almer

On 2/28/2024 10:31 AM, J. Dekker wrote:


Michael Niedermayer  writes:


[[PGP Signed Part:Undecided]]
On Wed, Feb 28, 2024 at 01:56:10PM +0100, J. Dekker wrote:

This was an experimental/research codec of which ffmpeg is the only
encoder and decoder,




development has stalled


Thats not true, there was private dicussion making sonic the most
advanced audio codec in FFmpeg a few months ago.
Iam not saying that will happen, i am just saying there was a
discussion about it. And that iam in principle interrested in
working on this. Its possible i will not have enough time ...



The last commit which actually changed the codec was
6026a5ad4f135476c7a1f51f8cfa7f4cc2ca0283 by you in 2013 which is over 10
years ago. For an experimental codec I think it's pretty safe to say
that development has stalled.

Keeping the codec around based on 'what if?'s doesn't seem
reasonable. Besides, if you do make sonic the most advanced audio codec
in FFmpeg there's nothing which says you couldn't re-add it at a later
date when it's being actively developed again.


Does it hurt keeping it around? If it can at some point be developed 
again, then removing the codec id to re-add it later will be a bit dirty.


IMO, just disable both modules by default during configure, or tag the 
encoder as experimental to prevent new streams to be created unless 
explicitly requested knowing that it's an unfinished format.

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

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


Re: [FFmpeg-devel] [PATCH 1/3] lavc/vp9dsp: R-V V ipred vert

2024-02-28 Thread flow gg
Found some problems.. I'll come back to modify this later. (to prevent
wasting time on this now)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


[FFmpeg-devel] [PATCH 3/3] avcodec/avcodec: Downgrade multi-member comment to non-Doxygen comment

2024-02-28 Thread Andrew Sayers
Doxygen only associates this comment with "pts_correction_num_faulty_pts",
causing it to display incorrectly.

Signed-off-by: Andrew Sayers 
---
 libavcodec/avcodec.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 58c581a5c0..8aa1356b8c 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1827,7 +1827,7 @@ typedef struct AVCodecContext {
  */
 const struct AVCodecDescriptor *codec_descriptor;
 
-/**
+/*
  * Current statistics for PTS correction.
  * - decoding: maintained and used by libavcodec, not intended to be used 
by user apps
  * - encoding: unused
-- 
2.43.0

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

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


[FFmpeg-devel] [PATCH 2/3] avcodec/ivi: Make comments more Doxygen-friendly

2024-02-28 Thread Andrew Sayers
Doxygen eats the newline in the first comment, making it harder to read.
Join the lines and add a comma, so source and documentation are equally 
readable.

Doxygen only associates the second comment with cust_dec.
The comments for cust_dec and cust_tab make perfect sense without it,
so downgrade it to a non-doxygen "//" comment.

The third comment was missed by the command in the previous commit,
because it (correctly but uniquely) doesn't have a trailing comma.

Signed-off-by: Andrew Sayers 
---
 libavcodec/ivi.h | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/libavcodec/ivi.h b/libavcodec/ivi.h
index ec54f65f30..afc3ec2a75 100644
--- a/libavcodec/ivi.h
+++ b/libavcodec/ivi.h
@@ -61,18 +61,17 @@ typedef struct IVIHuffDesc {
  *  macroblock/block huffman table descriptor
  */
 typedef struct IVIHuffTab {
-int32_t tab_sel;///< index of one of the predefined tables
-/// or "7" for custom one
+int32_t tab_sel;///< index of one of the predefined tables, or "7" 
for custom one
 VLC *tab;   ///< pointer to the table associated with tab_sel
 
-/// the following are used only when tab_sel == 7
+// the following are used only when tab_sel == 7
 IVIHuffDesc cust_desc;  ///< custom Huffman codebook descriptor
 VLC cust_tab;   ///< vlc table for custom codebook
 } IVIHuffTab;
 
 enum {
 IVI_MB_HUFF   = 0,  ///< Huffman table is used for coding macroblocks
-IVI_BLK_HUFF  = 1   /// Huffman table is used for coding blocks
+IVI_BLK_HUFF  = 1   ///< Huffman table is used for coding blocks
 };
 
 
-- 
2.43.0

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

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


[FFmpeg-devel] [PATCH 1/3] all: Fix /// comments that should be ///

2024-02-28 Thread Andrew Sayers
Actual command: sed -i -e "s/\([;,] *\)<* *\/\/\/ *<* */\1\/\/\/< /" $( git 
grep -l "[;,] */// " )

Signed-off-by: Andrew Sayers 
---
 libavcodec/avcodec.h |  8 
 libavcodec/bsf/noise.c   | 24 
 libavcodec/ivi.h | 10 +-
 libavfilter/vf_deshake.c |  2 +-
 libavformat/rmdec.c  |  4 ++--
 5 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 43859251cc..58c581a5c0 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1832,10 +1832,10 @@ typedef struct AVCodecContext {
  * - decoding: maintained and used by libavcodec, not intended to be used 
by user apps
  * - encoding: unused
  */
-int64_t pts_correction_num_faulty_pts; /// Number of incorrect PTS values 
so far
-int64_t pts_correction_num_faulty_dts; /// Number of incorrect DTS values 
so far
-int64_t pts_correction_last_pts;   /// PTS of the last frame
-int64_t pts_correction_last_dts;   /// DTS of the last frame
+int64_t pts_correction_num_faulty_pts; ///< Number of incorrect PTS values 
so far
+int64_t pts_correction_num_faulty_dts; ///< Number of incorrect DTS values 
so far
+int64_t pts_correction_last_pts;   ///< PTS of the last frame
+int64_t pts_correction_last_dts;   ///< DTS of the last frame
 
 /**
  * Character encoding of the input subtitles file.
diff --git a/libavcodec/bsf/noise.c b/libavcodec/bsf/noise.c
index 7bdaa3c1db..3a0f388dd6 100644
--- a/libavcodec/bsf/noise.c
+++ b/libavcodec/bsf/noise.c
@@ -28,18 +28,18 @@
 #include "libavutil/eval.h"
 
 static const char *const var_names[] = {
-"n",   /// packet index, starting from zero
-"tb",  /// timebase
-"pts", /// packet presentation timestamp
-"dts", /// packet decoding timestamp
-"nopts",   /// AV_NOPTS_VALUE
-"startpts",/// first seen non-AV_NOPTS_VALUE packet 
timestamp
-"startdts",/// first seen non-AV_NOPTS_VALUE packet 
timestamp
-"duration", "d",   /// packet duration
-"pos", /// original position of packet in its 
source
-"size",/// packet size
-"key" ,/// packet keyframe flag
-"state",   /// random-ish state
+"n",   ///< packet index, starting from zero
+"tb",  ///< timebase
+"pts", ///< packet presentation timestamp
+"dts", ///< packet decoding timestamp
+"nopts",   ///< AV_NOPTS_VALUE
+"startpts",///< first seen non-AV_NOPTS_VALUE packet 
timestamp
+"startdts",///< first seen non-AV_NOPTS_VALUE packet 
timestamp
+"duration", "d",   ///< packet duration
+"pos", ///< original position of packet in its 
source
+"size",///< packet size
+"key" ,///< packet keyframe flag
+"state",   ///< random-ish state
 NULL
 };
 
diff --git a/libavcodec/ivi.h b/libavcodec/ivi.h
index 06cd4d95ff..ec54f65f30 100644
--- a/libavcodec/ivi.h
+++ b/libavcodec/ivi.h
@@ -61,17 +61,17 @@ typedef struct IVIHuffDesc {
  *  macroblock/block huffman table descriptor
  */
 typedef struct IVIHuffTab {
-int32_t tab_sel;/// index of one of the predefined tables
+int32_t tab_sel;///< index of one of the predefined tables
 /// or "7" for custom one
-VLC *tab;   /// pointer to the table associated with tab_sel
+VLC *tab;   ///< pointer to the table associated with tab_sel
 
 /// the following are used only when tab_sel == 7
-IVIHuffDesc cust_desc;  /// custom Huffman codebook descriptor
-VLC cust_tab;   /// vlc table for custom codebook
+IVIHuffDesc cust_desc;  ///< custom Huffman codebook descriptor
+VLC cust_tab;   ///< vlc table for custom codebook
 } IVIHuffTab;
 
 enum {
-IVI_MB_HUFF   = 0,  /// Huffman table is used for coding macroblocks
+IVI_MB_HUFF   = 0,  ///< Huffman table is used for coding macroblocks
 IVI_BLK_HUFF  = 1   /// Huffman table is used for coding blocks
 };
 
diff --git a/libavfilter/vf_deshake.c b/libavfilter/vf_deshake.c
index 00e7472f67..107b78a7d1 100644
--- a/libavfilter/vf_deshake.c
+++ b/libavfilter/vf_deshake.c
@@ -88,7 +88,7 @@ typedef struct Transform {
 
 typedef struct DeshakeContext {
 const AVClass *class;
-int counts[2*MAX_R+1][2*MAX_R+1]; /// < Scratch buffer for motion search
+int counts[2*MAX_R+1][2*MAX_R+1]; ///< Scratch buffer for motion search
 double *angles;///< Scratch buffer for block angles
 uns

[FFmpeg-devel] [PATCH 0/3] Fix /// comments that should be ///

2024-02-28 Thread Andrew Sayers
This is the first in a planned series of patch series aimed at
fixing documentation issues, especially doxygen rendering.
I hope to post more as time allows in the coming days.

The first patch reflects the output of a `sed` command,
further patches fix edge cases not covered by `sed`.
Splitting commits this way allows merge conflicts
to be resolved by throwing the old commit away,
then running the command in the commit message.

Andrew Sayers (3):
  all: Fix /// comments that should be ///<
  avcodec/ivi: Make comments more Doxygen-friendly
  avcodec/avcodec: Downgrade multi-member comment to non-Doxygen comment

 libavcodec/avcodec.h | 10 +-
 libavcodec/bsf/noise.c   | 24 
 libavcodec/ivi.h | 15 +++
 libavfilter/vf_deshake.c |  2 +-
 libavformat/rmdec.c  |  4 ++--
 5 files changed, 27 insertions(+), 28 deletions(-)


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

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


Re: [FFmpeg-devel] [PATCH 3/6] avcodec/vvc/vvc_intra: Move utils out of svq1enc.c

2024-02-28 Thread Andreas Rheinhardt
Andreas Rheinhardt:
> Otherwise vvc_intra.o gets pulled in by the vvc_mc checkasm
> test and it in turn pulls vvc_ctu.o and then the rest of vvcdec
> and lavc in. Besides being bad size-wise this also has the downside
> that it pulls in avpriv_(cga|vga16)_font from libavutil which are
> marked as being imported from another library when building
> libavcodec as a DLL and this breaks checkasm because it links
> both lavc and lavu statically.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---

Fixed the commit title locally.

- Andreas

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

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


[FFmpeg-devel] [PATCH 6/6] tests/checkasm: Improve included headers

2024-02-28 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 tests/checkasm/exrdsp.c | 2 +-
 tests/checkasm/h264dsp.c| 2 --
 tests/checkasm/h264pred.c   | 2 +-
 tests/checkasm/hevc_sao.c   | 2 --
 tests/checkasm/utvideodsp.c | 1 -
 tests/checkasm/vp8dsp.c | 1 -
 tests/checkasm/vvc_mc.c | 4 +---
 7 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/tests/checkasm/exrdsp.c b/tests/checkasm/exrdsp.c
index 2a5febb9d3..8af2f13109 100644
--- a/tests/checkasm/exrdsp.c
+++ b/tests/checkasm/exrdsp.c
@@ -21,7 +21,7 @@
 #include 
 
 #include "checkasm.h"
-#include "libavcodec/avcodec.h"
+#include "libavcodec/defs.h"
 #include "libavcodec/exrdsp.h"
 #include "libavutil/intreadwrite.h"
 #include "libavutil/mem_internal.h"
diff --git a/tests/checkasm/h264dsp.c b/tests/checkasm/h264dsp.c
index 3c95f9d74d..0f484e3f43 100644
--- a/tests/checkasm/h264dsp.c
+++ b/tests/checkasm/h264dsp.c
@@ -20,12 +20,10 @@
 
 #include 
 #include "checkasm.h"
-#include "libavcodec/avcodec.h"
 #include "libavcodec/h264dsp.h"
 #include "libavcodec/h264data.h"
 #include "libavcodec/h264_parse.h"
 #include "libavutil/common.h"
-#include "libavutil/internal.h"
 #include "libavutil/intreadwrite.h"
 #include "libavutil/mem_internal.h"
 
diff --git a/tests/checkasm/h264pred.c b/tests/checkasm/h264pred.c
index a3077f6946..53e1cdb219 100644
--- a/tests/checkasm/h264pred.c
+++ b/tests/checkasm/h264pred.c
@@ -20,7 +20,7 @@
 
 #include 
 #include "checkasm.h"
-#include "libavcodec/avcodec.h"
+#include "libavcodec/codec_id.h"
 #include "libavcodec/h264pred.h"
 #include "libavutil/common.h"
 #include "libavutil/internal.h"
diff --git a/tests/checkasm/hevc_sao.c b/tests/checkasm/hevc_sao.c
index da3f710537..d05af9ac72 100644
--- a/tests/checkasm/hevc_sao.c
+++ b/tests/checkasm/hevc_sao.c
@@ -23,8 +23,6 @@
 #include "libavutil/intreadwrite.h"
 #include "libavutil/mem_internal.h"
 
-#include "libavcodec/avcodec.h"
-
 #include "libavcodec/hevcdsp.h"
 
 #include "checkasm.h"
diff --git a/tests/checkasm/utvideodsp.c b/tests/checkasm/utvideodsp.c
index bdede6107b..2463c96603 100644
--- a/tests/checkasm/utvideodsp.c
+++ b/tests/checkasm/utvideodsp.c
@@ -21,7 +21,6 @@
 #include 
 
 #include "checkasm.h"
-#include "libavcodec/avcodec.h"
 #include "libavcodec/utvideodsp.h"
 #include "libavutil/intreadwrite.h"
 #include "libavutil/mem_internal.h"
diff --git a/tests/checkasm/vp8dsp.c b/tests/checkasm/vp8dsp.c
index 87b03d71d5..4cd0f8ac4f 100644
--- a/tests/checkasm/vp8dsp.c
+++ b/tests/checkasm/vp8dsp.c
@@ -20,7 +20,6 @@
 
 #include 
 
-#include "libavcodec/avcodec.h"
 #include "libavcodec/vp8dsp.h"
 
 #include "libavutil/common.h"
diff --git a/tests/checkasm/vvc_mc.c b/tests/checkasm/vvc_mc.c
index ce34965b7d..d102e2ac9a 100644
--- a/tests/checkasm/vvc_mc.c
+++ b/tests/checkasm/vvc_mc.c
@@ -22,13 +22,11 @@
 #include 
 
 #include "checkasm.h"
-#include "libavcodec/avcodec.h"
 #include "libavcodec/vvc/vvc_ctu.h"
 #include "libavcodec/vvc/vvc_data.h"
+#include "libavcodec/vvc/vvcdsp.h"
 
 #include "libavutil/common.h"
-#include "libavutil/internal.h"
-#include "libavutil/internal.h"
 #include "libavutil/intreadwrite.h"
 #include "libavutil/mem_internal.h"
 
-- 
2.40.1

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

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


[FFmpeg-devel] [PATCH 5/6] checkasm/vvc_mc: Don't use declare_func_emms

2024-02-28 Thread Andreas Rheinhardt
There is no MMX DSP code for VVC, so one can use the stricter
declare_func which also tests that we are not in MMX mode
at the end of this function.

Signed-off-by: Andreas Rheinhardt 
---
 tests/checkasm/vvc_mc.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/tests/checkasm/vvc_mc.c b/tests/checkasm/vvc_mc.c
index 8adb00573f..ce34965b7d 100644
--- a/tests/checkasm/vvc_mc.c
+++ b/tests/checkasm/vvc_mc.c
@@ -74,7 +74,7 @@ static void check_put_vvc_luma(void)
 LOCAL_ALIGNED_32(uint8_t, src1, [SRC_BUF_SIZE]);
 VVCDSPContext c;
 
-declare_func_emms(AV_CPU_FLAG_MMX | AV_CPU_FLAG_MMXEXT, void, int16_t 
*dst, const uint8_t *src, const ptrdiff_t src_stride,
+declare_func(void, int16_t *dst, const uint8_t *src, const ptrdiff_t 
src_stride,
 const int height, const int8_t *hf, const int8_t *vf, const int width);
 
 for (int bit_depth = 8; bit_depth <= 12; bit_depth += 2) {
@@ -122,7 +122,7 @@ static void check_put_vvc_luma_uni(void)
 LOCAL_ALIGNED_32(uint8_t, src1, [SRC_BUF_SIZE]);
 
 VVCDSPContext c;
-declare_func_emms(AV_CPU_FLAG_MMX | AV_CPU_FLAG_MMXEXT, void, uint8_t 
*dst, ptrdiff_t dststride,
+declare_func(void, uint8_t *dst, ptrdiff_t dststride,
 uint8_t *src, ptrdiff_t srcstride,  int height, const int8_t *hf, 
const int8_t *vf, int width);
 
 for (int bit_depth = 8; bit_depth <= 12; bit_depth += 2) {
@@ -172,7 +172,7 @@ static void check_put_vvc_chroma(void)
 LOCAL_ALIGNED_32(uint8_t, src1, [SRC_BUF_SIZE]);
 VVCDSPContext c;
 
-declare_func_emms(AV_CPU_FLAG_MMX | AV_CPU_FLAG_MMXEXT, void, int16_t 
*dst, const uint8_t *src, const ptrdiff_t src_stride,
+declare_func(void, int16_t *dst, const uint8_t *src, const ptrdiff_t 
src_stride,
 const int height, const int8_t *hf, const int8_t *vf, const int width);
 
 for (int bit_depth = 8; bit_depth <= 12; bit_depth += 2) {
@@ -220,7 +220,7 @@ static void check_put_vvc_chroma_uni(void)
 LOCAL_ALIGNED_32(uint8_t, src1, [SRC_BUF_SIZE]);
 
 VVCDSPContext c;
-declare_func_emms(AV_CPU_FLAG_MMX | AV_CPU_FLAG_MMXEXT, void, uint8_t 
*dst, ptrdiff_t dststride,
+declare_func(void, uint8_t *dst, ptrdiff_t dststride,
 uint8_t *src, ptrdiff_t srcstride,  int height, const int8_t *hf, 
const int8_t *vf, int width);
 
 for (int bit_depth = 8; bit_depth <= 12; bit_depth += 2) {
@@ -282,7 +282,7 @@ static void check_avg(void)
 for (int h = 2; h <= MAX_CTU_SIZE; h *= 2) {
 for (int w = 2; w <= MAX_CTU_SIZE; w *= 2) {
 {
-   declare_func_emms(AV_CPU_FLAG_MMX | AV_CPU_FLAG_MMXEXT, 
void, uint8_t *dst, ptrdiff_t dst_stride,
+   declare_func(void, uint8_t *dst, ptrdiff_t dst_stride,
 const int16_t *src0, const int16_t *src1, int width, 
int height);
 if (check_func(c.inter.avg, "avg_%d_%dx%d", bit_depth, w, 
h)) {
 memset(dst0, 0, AVG_DST_BUF_SIZE);
@@ -296,7 +296,7 @@ static void check_avg(void)
 }
 }
 {
-declare_func_emms(AV_CPU_FLAG_MMX | AV_CPU_FLAG_MMXEXT, 
void, uint8_t *dst, ptrdiff_t dst_stride,
+declare_func(void, uint8_t *dst, ptrdiff_t dst_stride,
 const int16_t *src0, const int16_t *src1, int width, 
int height,
 int denom, int w0, int w1, int o0, int o1);
 {
-- 
2.40.1

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

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


[FFmpeg-devel] [PATCH 4/6] avcodec/vvc/vvc_mvs: Add proper header include

2024-02-28 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
TODO: Make checkheader also test subfolders.

 libavcodec/vvc/vvc_mvs.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/vvc/vvc_mvs.h b/libavcodec/vvc/vvc_mvs.h
index a546a324c2..78ad17c303 100644
--- a/libavcodec/vvc/vvc_mvs.h
+++ b/libavcodec/vvc/vvc_mvs.h
@@ -23,7 +23,7 @@
 #ifndef AVCODEC_VVC_VVC_MVS_H
 #define AVCODEC_VVC_VVC_MVS_H
 
-#include "vvcdec.h"
+#include "vvc_ctu.h"
 
 void ff_vvc_round_mv(Mv *mv, int lshift, int rshift);
 void ff_vvc_clip_mv(Mv *mv);
-- 
2.40.1

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

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


[FFmpeg-devel] [PATCH 3/6] avcodec/vvc/vvc_intra: Move utils out of svq1enc.c

2024-02-28 Thread Andreas Rheinhardt
Otherwise vvc_intra.o gets pulled in by the vvc_mc checkasm
test and it in turn pulls vvc_ctu.o and then the rest of vvcdec
and lavc in. Besides being bad size-wise this also has the downside
that it pulls in avpriv_(cga|vga16)_font from libavutil which are
marked as being imported from another library when building
libavcodec as a DLL and this breaks checkasm because it links
both lavc and lavu statically.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/vvc/Makefile  |   1 +
 libavcodec/vvc/vvc_intra.c   | 187 --
 libavcodec/vvc/vvc_intra_utils.c | 218 +++
 3 files changed, 219 insertions(+), 187 deletions(-)
 create mode 100644 libavcodec/vvc/vvc_intra_utils.c

diff --git a/libavcodec/vvc/Makefile b/libavcodec/vvc/Makefile
index dc484e5fb9..2a0055d494 100644
--- a/libavcodec/vvc/Makefile
+++ b/libavcodec/vvc/Makefile
@@ -9,6 +9,7 @@ OBJS-$(CONFIG_VVC_DECODER)  +=  vvc/vvcdec.o
\
 vvc/vvc_filter.o\
 vvc/vvc_inter.o \
 vvc/vvc_intra.o \
+vvc/vvc_intra_utils.o   \
 vvc/vvc_itx_1d.o\
 vvc/vvc_mvs.o   \
 vvc/vvc_ps.o\
diff --git a/libavcodec/vvc/vvc_intra.c b/libavcodec/vvc/vvc_intra.c
index 58dd492478..6d976320f8 100644
--- a/libavcodec/vvc/vvc_intra.c
+++ b/libavcodec/vvc/vvc_intra.c
@@ -26,7 +26,6 @@
 #include "vvc_inter.h"
 #include "vvc_intra.h"
 #include "vvc_itx_1d.h"
-#include "vvc_mvs.h"
 
 static int is_cclm(enum IntraPredMode mode)
 {
@@ -694,189 +693,3 @@ int ff_vvc_reconstruct(VVCLocalContext *lc, const int rs, 
const int rx, const in
 return ret;
 }
 
-int ff_vvc_get_mip_size_id(const int w, const int h)
-{
-if (w == 4 && h == 4)
-return 0;
-if ((w == 4 || h == 4) || (w == 8 && h == 8))
-return 1;
-return 2;
-}
-
-int ff_vvc_nscale_derive(const int w, const int h, const int mode)
-{
-int side_size, nscale;
-av_assert0(mode < INTRA_LT_CCLM && !(mode > INTRA_HORZ && mode < 
INTRA_VERT));
-if (mode == INTRA_PLANAR || mode == INTRA_DC ||
-mode == INTRA_HORZ || mode == INTRA_VERT) {
-nscale = (av_log2(w) + av_log2(h) - 2) >> 2;
-} else {
-const int intra_pred_angle = ff_vvc_intra_pred_angle_derive(mode);
-const int inv_angle= 
ff_vvc_intra_inv_angle_derive(intra_pred_angle);
-if (mode >= INTRA_VERT)
-side_size = h;
-if (mode <= INTRA_HORZ)
-side_size = w;
-nscale = FFMIN(2, av_log2(side_size) - av_log2(3 * inv_angle - 2) + 8);
-}
-return nscale;
-}
-
-int ff_vvc_need_pdpc(const int w, const int h, const uint8_t bdpcm_flag, const 
int mode, const int ref_idx)
-{
-av_assert0(mode < INTRA_LT_CCLM);
-if ((w >= 4 && h >= 4) && !ref_idx && !bdpcm_flag) {
-int nscale;
-if (mode == INTRA_PLANAR || mode == INTRA_DC ||
-mode == INTRA_HORZ || mode == INTRA_VERT)
-return 1;
-if (mode > INTRA_HORZ && mode < INTRA_VERT)
-return 0;
-nscale = ff_vvc_nscale_derive(w, h, mode);
-return nscale >= 0;
-
-}
-return 0;
-}
-
-static const ReconstructedArea* get_reconstructed_area(const VVCLocalContext 
*lc, const int x, const int y, const int c_idx)
-{
-const int ch_type = c_idx > 0;
-for (int i = lc->num_ras[ch_type] - 1; i >= 0; i--) {
-const ReconstructedArea* a = &lc->ras[ch_type][i];
-const int r = (a->x + a->w);
-const int b = (a->y + a->h);
-if (a->x <= x && x < r && a->y <= y && y < b)
-return a;
-
-//it's too far away, no need check it;
-if (x >= r && y >= b)
-break;
-}
-return NULL;
-}
-
-int ff_vvc_get_top_available(const VVCLocalContext *lc, const int x, const int 
y, int target_size, const int c_idx)
-{
-const VVCFrameContext *fc = lc->fc;
-const VVCSPS *sps = fc->ps.sps;
-const int hs = sps->hshift[c_idx];
-const int vs = sps->vshift[c_idx];
-const int log2_ctb_size_v   = sps->ctb_log2_size_y - vs;
-const int end_of_ctb_x  = ((lc->cu->x0 >> sps->ctb_log2_size_y) + 1) 
<< sps->ctb_log2_size_y;
-const int y0b   = av_mod_uintp2(y, log2_ctb_size_v);
-const int max_x = FFMIN(fc->ps.pps->width, end_of_ctb_x) >> hs;
-const ReconstructedArea *a;
-int px = x;
-
-if (!y0b) {
-if (!lc->ctb_up_flag)
-return 0;
-target_size = FFMIN(target_size, (lc->end_of_tiles_x >> hs) - x);
-if (sps->r->sps_entropy_coding_sync_enabled_flag)
-target_size = FFMIN(target_size, (end_of_ctb_x >> hs) - x);
-return target_size;
-}
-
-target_size = FFMAX(0, FFMIN(target_size, max_x

[FFmpeg-devel] [PATCH 2/6] avcodec/svq1enc: Move initializing DSP out of svq1enc.c

2024-02-28 Thread Andreas Rheinhardt
Otherwise svq1enc.o gets pulled in by the svq1encdsp checkasm
test and it in turn pulls the rest of lavc in.
Besides being bad size-wise this also has the downside that
it pulls in avpriv_(cga|vga16)_font from libavutil which are
marked as being imported from another library when building
libavcodec as a DLL and this breaks checkasm because it links
both lavc and lavu statically.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/svq1enc.c| 23 ---
 libavcodec/svq1encdsp.h | 26 +-
 2 files changed, 25 insertions(+), 24 deletions(-)

diff --git a/libavcodec/svq1enc.c b/libavcodec/svq1enc.c
index 5675ae5218..77dbf07275 100644
--- a/libavcodec/svq1enc.c
+++ b/libavcodec/svq1enc.c
@@ -137,16 +137,6 @@ static void svq1_write_header(SVQ1EncContext *s, 
PutBitContext *pb, int frame_ty
 #define QUALITY_THRESHOLD100
 #define THRESHOLD_MULTIPLIER 0.6
 
-static int ssd_int8_vs_int16_c(const int8_t *pix1, const int16_t *pix2,
-   intptr_t size)
-{
-int score = 0, i;
-
-for (i = 0; i < size; i++)
-score += (pix1[i] - pix2[i]) * (pix1[i] - pix2[i]);
-return score;
-}
-
 static int encode_block(SVQ1EncContext *s, uint8_t *src, uint8_t *ref,
 uint8_t *decoded, int stride, unsigned level,
 int threshold, int lambda, int intra)
@@ -760,16 +750,3 @@ const FFCodec ff_svq1_encoder = {
  AV_PIX_FMT_NONE },
 .caps_internal  = FF_CODEC_CAP_INIT_CLEANUP,
 };
-
-void ff_svq1enc_init(SVQ1EncDSPContext *c)
-{
-c->ssd_int8_vs_int16 = ssd_int8_vs_int16_c;
-
-#if ARCH_PPC
-ff_svq1enc_init_ppc(c);
-#elif ARCH_RISCV
-ff_svq1enc_init_riscv(c);
-#elif ARCH_X86
-ff_svq1enc_init_x86(c);
-#endif
-}
diff --git a/libavcodec/svq1encdsp.h b/libavcodec/svq1encdsp.h
index 5dfa35cc62..751b5eed86 100644
--- a/libavcodec/svq1encdsp.h
+++ b/libavcodec/svq1encdsp.h
@@ -23,14 +23,38 @@
 
 #include 
 
+#include "config.h"
+
 typedef struct SVQ1EncDSPContext {
 int (*ssd_int8_vs_int16)(const int8_t *pix1, const int16_t *pix2,
  intptr_t size);
 } SVQ1EncDSPContext;
 
-void ff_svq1enc_init(SVQ1EncDSPContext *c);
 void ff_svq1enc_init_ppc(SVQ1EncDSPContext *c);
 void ff_svq1enc_init_riscv(SVQ1EncDSPContext *c);
 void ff_svq1enc_init_x86(SVQ1EncDSPContext *c);
 
+static int ssd_int8_vs_int16_c(const int8_t *pix1, const int16_t *pix2,
+   intptr_t size)
+{
+int score = 0;
+
+for (intptr_t i = 0; i < size; i++)
+score += (pix1[i] - pix2[i]) * (pix1[i] - pix2[i]);
+return score;
+}
+
+static inline void ff_svq1enc_init(SVQ1EncDSPContext *c)
+{
+c->ssd_int8_vs_int16 = ssd_int8_vs_int16_c;
+
+#if ARCH_PPC
+ff_svq1enc_init_ppc(c);
+#elif ARCH_RISCV
+ff_svq1enc_init_riscv(c);
+#elif ARCH_X86
+ff_svq1enc_init_x86(c);
+#endif
+}
+
 #endif /* AVCODEC_SVQ1ENCDSP_H */
-- 
2.40.1

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

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


[FFmpeg-devel] [PATCH 1/6] avcodec/aacenc: Move initializing DSP out of aacenc.c

2024-02-28 Thread Andreas Rheinhardt
Otherwise aacenc.o gets pulled in by the aacencdsp checkasm
test and it in turn pulls the rest of lavc in.
Besides being bad size-wise this also has the downside that
it pulls in avpriv_(cga|vga16)_font from libavutil which are
marked as being imported from another library when building
libavcodec as a DLL and this breaks checkasm because it links
both lavc and lavu statically.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/aaccoder.c | 26 +--
 libavcodec/aaccoder_trellis.h |  2 +-
 libavcodec/aaccoder_twoloop.h |  2 +-
 libavcodec/aacenc.c   | 21 +++--
 libavcodec/aacenc.h   |  9 +---
 libavcodec/aacenc_is.c|  6 +--
 libavcodec/aacenc_ltp.c   |  4 +-
 libavcodec/aacenc_pred.c  |  6 +--
 libavcodec/aacenc_utils.h | 24 ---
 libavcodec/aacencdsp.h| 72 +++
 libavcodec/mips/aaccoder_mips.c   |  1 +
 libavcodec/riscv/aacencdsp_init.c |  5 +--
 libavcodec/x86/aacencdsp_init.c   |  5 +--
 tests/checkasm/aacencdsp.c| 10 ++---
 14 files changed, 112 insertions(+), 81 deletions(-)
 create mode 100644 libavcodec/aacencdsp.h

diff --git a/libavcodec/aaccoder.c b/libavcodec/aaccoder.c
index 6291c16123..4ce54ca886 100644
--- a/libavcodec/aaccoder.c
+++ b/libavcodec/aaccoder.c
@@ -108,10 +108,10 @@ static av_always_inline float 
quantize_and_encode_band_cost_template(
 return cost * lambda;
 }
 if (!scaled) {
-s->abs_pow34(s->scoefs, in, size);
+s->aacdsp.abs_pow34(s->scoefs, in, size);
 scaled = s->scoefs;
 }
-s->quant_bands(s->qcoefs, in, scaled, size, !BT_UNSIGNED, 
aac_cb_maxval[cb], Q34, ROUNDING);
+s->aacdsp.quant_bands(s->qcoefs, in, scaled, size, !BT_UNSIGNED, 
aac_cb_maxval[cb], Q34, ROUNDING);
 if (BT_UNSIGNED) {
 off = 0;
 } else {
@@ -311,7 +311,7 @@ static void encode_window_bands_info(AACEncContext *s, 
SingleChannelElement *sce
 float next_minrd = INFINITY;
 int next_mincb = 0;
 
-s->abs_pow34(s->scoefs, sce->coeffs, 1024);
+s->aacdsp.abs_pow34(s->scoefs, sce->coeffs, 1024);
 start = win*128;
 for (cb = 0; cb < CB_TOT_ALL; cb++) {
 path[0][cb].cost = 0.0f;
@@ -522,7 +522,7 @@ static void search_for_quantizers_anmr(AVCodecContext 
*avctx, AACEncContext *s,
 }
 }
 idx = 1;
-s->abs_pow34(s->scoefs, sce->coeffs, 1024);
+s->aacdsp.abs_pow34(s->scoefs, sce->coeffs, 1024);
 for (w = 0; w < sce->ics.num_windows; w += sce->ics.group_len[w]) {
 start = w*128;
 for (g = 0; g < sce->ics.num_swb; g++) {
@@ -668,7 +668,7 @@ static void search_for_quantizers_fast(AVCodecContext 
*avctx, AACEncContext *s,
 
 if (!allz)
 return;
-s->abs_pow34(s->scoefs, sce->coeffs, 1024);
+s->aacdsp.abs_pow34(s->scoefs, sce->coeffs, 1024);
 ff_quantize_band_cost_cache_init(s);
 
 for (w = 0; w < sce->ics.num_windows; w += sce->ics.group_len[w]) {
@@ -874,8 +874,8 @@ static void search_for_pns(AACEncContext *s, AVCodecContext 
*avctx, SingleChanne
 s->fdsp->vector_fmul_scalar(PNS, PNS, scale, 
sce->ics.swb_sizes[g]);
 pns_senergy = s->fdsp->scalarproduct_float(PNS, PNS, 
sce->ics.swb_sizes[g]);
 pns_energy += pns_senergy;
-s->abs_pow34(NOR34, &sce->coeffs[start_c], 
sce->ics.swb_sizes[g]);
-s->abs_pow34(PNS34, PNS, sce->ics.swb_sizes[g]);
+s->aacdsp.abs_pow34(NOR34, &sce->coeffs[start_c], 
sce->ics.swb_sizes[g]);
+s->aacdsp.abs_pow34(PNS34, PNS, sce->ics.swb_sizes[g]);
 dist1 += quantize_band_cost(s, &sce->coeffs[start_c],
 NOR34,
 sce->ics.swb_sizes[g],
@@ -1012,8 +1012,8 @@ static void search_for_ms(AACEncContext *s, 
ChannelElement *cpe)
 S[i] =  M[i]
   - sce1->coeffs[start+(w+w2)*128+i];
 }
-s->abs_pow34(M34, M, sce0->ics.swb_sizes[g]);
-s->abs_pow34(S34, S, sce0->ics.swb_sizes[g]);
+s->aacdsp.abs_pow34(M34, M, sce0->ics.swb_sizes[g]);
+s->aacdsp.abs_pow34(S34, S, sce0->ics.swb_sizes[g]);
 for (i = 0; i < sce0->ics.swb_sizes[g]; i++ ) {
 Mmax = FFMAX(Mmax, M34[i]);
 Smax = FFMAX(Smax, S34[i]);
@@ -1056,10 +1056,10 @@ static void search_for_ms(AACEncContext *s, 
ChannelElement *cpe)
   - sce1->coeffs[start+(w+w2)*128+i];
 }
 
-s->abs_pow34(L34, sce0->coeffs+start+(w+w2)*128, 
sce0->ics.swb_sizes[g]);
-s->abs_pow34(R34, sce1->coeffs+start+(w+w2)*128, 
sce0->ics.swb_sizes[g]);
-s->abs_pow34(M34, M, 
sce0->ics.swb_sizes[g]);
- 

[FFmpeg-devel] [PATCH] avcodec/bsf/mp3_header_decompress: Remove BSF

2024-02-28 Thread Andreas Rheinhardt
This BSF is supposed to be used in conjunction with mp3_header_compress,
which has been removed more than ten years ago in commit
c6080d89009056530119ab794ad02e4d515c7754. It mangled the headers
by removing the CRC field as well as fields that are supposed
to stay constant for the entirety of a stream (which are put into
extradata). This made these files unplayable; they need to be
decompressed with the BSF first (which does not happen automatically).
Even in this case the CRC does not get restored.

I am not aware that such compressed files exist at all; therefore
this commit removes the BSF completely.

Signed-off-by: Andreas Rheinhardt 
---
 doc/bitstream_filters.texi |   4 -
 libavcodec/Makefile|   1 -
 libavcodec/bitstream_filters.c |   1 -
 libavcodec/bsf/Makefile|   1 -
 libavcodec/bsf/mp3_header_decompress.c | 130 -
 5 files changed, 137 deletions(-)
 delete mode 100644 libavcodec/bsf/mp3_header_decompress.c

diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index d5bac105ff..e06de1a73a 100644
--- a/doc/bitstream_filters.texi
+++ b/doc/bitstream_filters.texi
@@ -528,10 +528,6 @@ metadata header from each subtitle packet.
 
 See also the @ref{text2movsub} filter.
 
-@section mp3decomp
-
-Decompress non-standard compressed MP3 audio headers.
-
 @section mpeg2_metadata
 
 Modify metadata embedded in an MPEG-2 stream.
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 09ae5270b3..f28a6568de 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1240,7 +1240,6 @@ OBJS-$(CONFIG_EXTRACT_EXTRADATA_BSF)  += av1_parse.o 
h2645_parse.o
 OBJS-$(CONFIG_H264_METADATA_BSF)  += h264_levels.o h2645data.o
 OBJS-$(CONFIG_HAPQA_EXTRACT_BSF)  += hap.o
 OBJS-$(CONFIG_HEVC_METADATA_BSF)  += h265_profile_level.o h2645data.o
-OBJS-$(CONFIG_MP3_HEADER_DECOMPRESS_BSF)  += mpegaudiotabs.o
 OBJS-$(CONFIG_REMOVE_EXTRADATA_BSF)   += av1_parse.o
 OBJS-$(CONFIG_TRUEHD_CORE_BSF)+= mlp_parse.o mlp.o
 
diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c
index 1bae113d92..12860c332b 100644
--- a/libavcodec/bitstream_filters.c
+++ b/libavcodec/bitstream_filters.c
@@ -46,7 +46,6 @@ extern const FFBitStreamFilter ff_imx_dump_header_bsf;
 extern const FFBitStreamFilter ff_media100_to_mjpegb_bsf;
 extern const FFBitStreamFilter ff_mjpeg2jpeg_bsf;
 extern const FFBitStreamFilter ff_mjpega_dump_header_bsf;
-extern const FFBitStreamFilter ff_mp3_header_decompress_bsf;
 extern const FFBitStreamFilter ff_mpeg2_metadata_bsf;
 extern const FFBitStreamFilter ff_mpeg4_unpack_bframes_bsf;
 extern const FFBitStreamFilter ff_mov2textsub_bsf;
diff --git a/libavcodec/bsf/Makefile b/libavcodec/bsf/Makefile
index 62609eb24e..fb70ad0c21 100644
--- a/libavcodec/bsf/Makefile
+++ b/libavcodec/bsf/Makefile
@@ -25,7 +25,6 @@ OBJS-$(CONFIG_MEDIA100_TO_MJPEGB_BSF) += 
bsf/media100_to_mjpegb.o
 OBJS-$(CONFIG_MJPEG2JPEG_BSF) += bsf/mjpeg2jpeg.o
 OBJS-$(CONFIG_MJPEGA_DUMP_HEADER_BSF) += bsf/mjpega_dump_header.o
 OBJS-$(CONFIG_MOV2TEXTSUB_BSF)+= bsf/movsub.o
-OBJS-$(CONFIG_MP3_HEADER_DECOMPRESS_BSF)  += bsf/mp3_header_decompress.o
 OBJS-$(CONFIG_MPEG2_METADATA_BSF) += bsf/mpeg2_metadata.o
 OBJS-$(CONFIG_MPEG4_UNPACK_BFRAMES_BSF)   += bsf/mpeg4_unpack_bframes.o
 OBJS-$(CONFIG_NOISE_BSF)  += bsf/noise.o
diff --git a/libavcodec/bsf/mp3_header_decompress.c 
b/libavcodec/bsf/mp3_header_decompress.c
deleted file mode 100644
index a177029fe0..00
--- a/libavcodec/bsf/mp3_header_decompress.c
+++ /dev/null
@@ -1,130 +0,0 @@
-/*
- * copyright (c) 2006 Michael Niedermayer 
- *
- * 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 "libavutil/common.h"
-#include "libavutil/intreadwrite.h"
-#include "bsf.h"
-#include "bsf_internal.h"
-#include "defs.h"
-#include "mpegaudiodecheader.h"
-#include "mpegaudiodata.h"
-
-
-static int mp3_header_decompress(AVBSFContext *ctx, AVPacket *out)
-{
-AVPacket *in;
-uint32_t header;
-int sample_rate= ctx->par_in->sample_rate;
-int sample_rate_index=0;
-int lsf, mpeg25, bitrate_index, frame_size, ret;
-uint8_t *buf;
-int buf_size;
-
-ret = ff_bsf_get_

Re: [FFmpeg-devel] [PATCH 1/4] avcodec/aom_film_grain: add AOM film grain synthesis

2024-02-28 Thread Niklas Haas
On Wed, 28 Feb 2024 16:45:50 +0100 Andreas Rheinhardt 
 wrote:
> I don't think this should be duplicated for every bitdepth.

To clarify, you think the bit depth should be just treated as a runtime
parameter instead of this being a template at all? How would you suggest
to handle the diference in pixel size between 8-bit and 10/12-bit?

Maybe a middle ground would be to compile this template only twice, once
for HBD and once for 8-bit, with the HBD code-path taking the bitdepth
as an extra parameter.

(That's actually what dav1d does internally)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


Re: [FFmpeg-devel] [PATCH 1/2] MAINTAINERS: remove inactive developer

2024-02-28 Thread Vittorio Giovara
On Wed, Feb 28, 2024 at 1:56 PM J. Dekker  wrote:

> Inactive since 2007.
>
> Signed-off-by: J. Dekker 
> ---
>  MAINTAINERS | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
>
lgtm
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio

2024-02-28 Thread J. Dekker

Vittorio Giovara  writes:

> On Wed, Feb 28, 2024 at 2:38 PM J. Dekker  wrote:
>
>>
>> Michael Niedermayer  writes:
>>
>> > [[PGP Signed Part:Undecided]]
>> > On Wed, Feb 28, 2024 at 01:56:10PM +0100, J. Dekker wrote:
>> >> This was an experimental/research codec of which ffmpeg is the only
>> >> encoder and decoder,
>> >
>> >
>> >> development has stalled
>> >
>> > Thats not true, there was private dicussion making sonic the most
>> > advanced audio codec in FFmpeg a few months ago.
>> > Iam not saying that will happen, i am just saying there was a
>> > discussion about it. And that iam in principle interrested in
>> > working on this. Its possible i will not have enough time ...
>> >
>>
>> The last commit which actually changed the codec was
>> 6026a5ad4f135476c7a1f51f8cfa7f4cc2ca0283 by you in 2013 which is over 10
>> years ago. For an experimental codec I think it's pretty safe to say
>> that development has stalled.
>>
>> Keeping the codec around based on 'what if?'s doesn't seem
>> reasonable. Besides, if you do make sonic the most advanced audio codec
>> in FFmpeg there's nothing which says you couldn't re-add it at a later
>> date when it's being actively developed again.
>>
>
> +1
>
> but please do the deprecation dance as suggested

As mentioned on IRC the suggestion was to leave the codec IDs as-is so
that they can still be identified even if we cannot decode them. So
there is no need to deprecate anything here, public API is left
untouched and codec removed as if it were disabled at compile time. Will
post an updated patch.

-- 
jd
___
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] avcodec: remove sonic lossy/lossless audio

2024-02-28 Thread Vittorio Giovara
On Wed, Feb 28, 2024 at 2:38 PM J. Dekker  wrote:

>
> Michael Niedermayer  writes:
>
> > [[PGP Signed Part:Undecided]]
> > On Wed, Feb 28, 2024 at 01:56:10PM +0100, J. Dekker wrote:
> >> This was an experimental/research codec of which ffmpeg is the only
> >> encoder and decoder,
> >
> >
> >> development has stalled
> >
> > Thats not true, there was private dicussion making sonic the most
> > advanced audio codec in FFmpeg a few months ago.
> > Iam not saying that will happen, i am just saying there was a
> > discussion about it. And that iam in principle interrested in
> > working on this. Its possible i will not have enough time ...
> >
>
> The last commit which actually changed the codec was
> 6026a5ad4f135476c7a1f51f8cfa7f4cc2ca0283 by you in 2013 which is over 10
> years ago. For an experimental codec I think it's pretty safe to say
> that development has stalled.
>
> Keeping the codec around based on 'what if?'s doesn't seem
> reasonable. Besides, if you do make sonic the most advanced audio codec
> in FFmpeg there's nothing which says you couldn't re-add it at a later
> date when it's being actively developed again.
>

+1

but please do the deprecation dance as suggested
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio

2024-02-28 Thread Nicolas George
J. Dekker (12024-02-28):
> Keeping the codec around based on 'what if?'s doesn't seem
> reasonable.

Spending your efforts on it, even if it is just to remove it, is a waste
of your time.

-- 
  Nicolas George
___
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] avcodec: remove sonic lossy/lossless audio

2024-02-28 Thread J. Dekker


Michael Niedermayer  writes:

> [[PGP Signed Part:Undecided]]
> On Wed, Feb 28, 2024 at 01:56:10PM +0100, J. Dekker wrote:
>> This was an experimental/research codec of which ffmpeg is the only
>> encoder and decoder,
>
>
>> development has stalled
>
> Thats not true, there was private dicussion making sonic the most
> advanced audio codec in FFmpeg a few months ago.
> Iam not saying that will happen, i am just saying there was a
> discussion about it. And that iam in principle interrested in
> working on this. Its possible i will not have enough time ...
>

The last commit which actually changed the codec was
6026a5ad4f135476c7a1f51f8cfa7f4cc2ca0283 by you in 2013 which is over 10
years ago. For an experimental codec I think it's pretty safe to say
that development has stalled.

Keeping the codec around based on 'what if?'s doesn't seem
reasonable. Besides, if you do make sonic the most advanced audio codec
in FFmpeg there's nothing which says you couldn't re-add it at a later
date when it's being actively developed again.

-- 
jd

___
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] avcodec: remove sonic lossy/lossless audio

2024-02-28 Thread Michael Niedermayer
On Wed, Feb 28, 2024 at 01:56:10PM +0100, J. Dekker wrote:
> This was an experimental/research codec of which ffmpeg is the only
> encoder and decoder,


> development has stalled

Thats not true, there was private dicussion making sonic the most
advanced audio codec in FFmpeg a few months ago.
Iam not saying that will happen, i am just saying there was a
discussion about it. And that iam in principle interrested in
working on this. Its possible i will not have enough time ...

thx

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

Democracy is the form of government in which you can choose your dictator


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 2/2] doc/ffprobe.xsd: add and

2024-02-28 Thread Niklas Haas
On Wed, 28 Feb 2024 14:23:50 +0100 Niklas Haas  wrote:
> +  
> +
> +   minOccurs="0" maxOccurs="unbounded"/>
> +
> +  

Typo, should be "piece". Fixed locally.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


[FFmpeg-devel] [PATCH 2/2] doc/ffprobe.xsd: add and

2024-02-28 Thread Niklas Haas
From: Niklas Haas 

Originally introduced for dovi side data printing, but not properly
reflected in the xsd.
---
 doc/ffprobe.xsd | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/doc/ffprobe.xsd b/doc/ffprobe.xsd
index 5d17b5d9b90..49771dd1482 100644
--- a/doc/ffprobe.xsd
+++ b/doc/ffprobe.xsd
@@ -162,6 +162,7 @@
   
 
   
+  
   
 
 
@@ -185,6 +186,31 @@
 
   
 
+  
+
+  
+
+  
+
+  
+
+  
+  
+
+  
+
+  
+
+  
+
+  
+
+  
+
+  
+
+  
+
   
 
 
-- 
2.43.2

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

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


[FFmpeg-devel] [PATCH 1/2] doc/ffprobe.xsd: add frameSideDatumType entry

2024-02-28 Thread Niklas Haas
From: Niklas Haas 

Frame-level side data attributes are printed with the same key/value
structure as packet-level side data attributes, but this is not
reflected in the XSD.
---
 doc/ffprobe.xsd | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/doc/ffprobe.xsd b/doc/ffprobe.xsd
index 23d97ed11ab..5d17b5d9b90 100644
--- a/doc/ffprobe.xsd
+++ b/doc/ffprobe.xsd
@@ -162,6 +162,7 @@
   
 
   
+  
 
 
 
@@ -169,6 +170,11 @@
 
   
 
+  
+
+
+  
+
   
 
   
-- 
2.43.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 2/2] avcodec: remove sonic lossy/lossless audio

2024-02-28 Thread Andreas Rheinhardt
J. Dekker:
> This was an experimental/research codec of which ffmpeg is the only
> encoder and decoder, development has stalled and these files don't exist
> in the wild.
> 
> Signed-off-by: J. Dekker 
> ---
>  Changelog   |1 +
>  configure   |3 -
>  libavcodec/Makefile |3 -
>  libavcodec/allcodecs.c  |3 -
>  libavcodec/codec_desc.c |   14 -
>  libavcodec/sonic.c  | 1125 ---
>  6 files changed, 1 insertion(+), 1148 deletions(-)
>  delete mode 100644 libavcodec/sonic.c
> 
> diff --git a/Changelog b/Changelog
> index 610ee61dd6..e2096f249a 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -27,6 +27,7 @@ version :
>  - a C11-compliant compiler is now required; note that this requirement
>will be bumped to C17 in the near future, so consider updating your
>build environment if it lacks C17 support
> +- sonic lossy/lossless audio codec removed
>  
>  version 6.1:
>  - libaribcaption decoder
> diff --git a/configure b/configure
> index bb5e630bad..e639a5e2b7 100755
> --- a/configure
> +++ b/configure
> @@ -2991,9 +2991,6 @@ sipr_decoder_select="lsp"
>  smvjpeg_decoder_select="mjpeg_decoder"
>  snow_decoder_select="dwt h264qpel rangecoder videodsp"
>  snow_encoder_select="dwt h264qpel hpeldsp me_cmp mpegvideoenc rangecoder 
> videodsp"
> -sonic_decoder_select="golomb rangecoder"
> -sonic_encoder_select="golomb rangecoder"
> -sonic_ls_encoder_select="golomb rangecoder"
>  sp5x_decoder_select="mjpeg_decoder"
>  speedhq_decoder_select="blockdsp idctdsp"
>  speedhq_encoder_select="mpegvideoenc"
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 09ae5270b3..3fc716ee68 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -687,9 +687,6 @@ OBJS-$(CONFIG_SNOW_DECODER)+= snowdec.o 
> snow.o snow_dwt.o
>  OBJS-$(CONFIG_SNOW_ENCODER)+= snowenc.o snow.o snow_dwt.o
>  \
>h263.o h263data.o ituh263enc.o
>  OBJS-$(CONFIG_SOL_DPCM_DECODER)+= dpcm.o
> -OBJS-$(CONFIG_SONIC_DECODER)   += sonic.o
> -OBJS-$(CONFIG_SONIC_ENCODER)   += sonic.o
> -OBJS-$(CONFIG_SONIC_LS_ENCODER)+= sonic.o
>  OBJS-$(CONFIG_SPEEDHQ_DECODER) += speedhqdec.o speedhq.o mpeg12.o \
>mpeg12data.o
>  OBJS-$(CONFIG_SPEEDHQ_ENCODER) += speedhq.o mpeg12data.o mpeg12enc.o 
> speedhqenc.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index ef8c3a6d7d..e0a4a5421d 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -535,9 +535,6 @@ extern const FFCodec ff_shorten_decoder;
>  extern const FFCodec ff_sipr_decoder;
>  extern const FFCodec ff_siren_decoder;
>  extern const FFCodec ff_smackaud_decoder;
> -extern const FFCodec ff_sonic_encoder;
> -extern const FFCodec ff_sonic_decoder;
> -extern const FFCodec ff_sonic_ls_encoder;
>  extern const FFCodec ff_tak_decoder;
>  extern const FFCodec ff_truehd_encoder;
>  extern const FFCodec ff_truehd_decoder;
> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> index 033344304c..9b456616be 100644
> --- a/libavcodec/codec_desc.c
> +++ b/libavcodec/codec_desc.c
> @@ -3175,20 +3175,6 @@ static const AVCodecDescriptor codec_descriptors[] = {
>  .long_name = NULL_IF_CONFIG_SMALL("Wave synthesis pseudo-codec"),
>  .props = AV_CODEC_PROP_INTRA_ONLY,
>  },
> -{
> -.id= AV_CODEC_ID_SONIC,
> -.type  = AVMEDIA_TYPE_AUDIO,
> -.name  = "sonic",
> -.long_name = NULL_IF_CONFIG_SMALL("Sonic"),
> -.props = AV_CODEC_PROP_INTRA_ONLY,
> -},
> -{
> -.id= AV_CODEC_ID_SONIC_LS,
> -.type  = AVMEDIA_TYPE_AUDIO,
> -.name  = "sonicls",
> -.long_name = NULL_IF_CONFIG_SMALL("Sonic lossless"),
> -.props = AV_CODEC_PROP_INTRA_ONLY,
> -},
>  {
>  .id= AV_CODEC_ID_EVRC,
>  .type  = AVMEDIA_TYPE_AUDIO,

You can't remove the codec descriptors as long as the codec id exists
(every codec id should have a codec descriptor, even if there is no codec).
Should the codec id be deprecated, too?

- Andreas

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

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


Re: [FFmpeg-devel] [REFUND-REQUEST] FOSDEM 2024

2024-02-28 Thread Michael Niedermayer
On Fri, Feb 23, 2024 at 09:19:26PM +0100, Stefano Sabatini wrote:
> Il ven 23 feb 2024, 11:00 J. Dekker  ha scritto:
> 
> > Hi,
> >
> > I attended FOSDEM for ffmpeg and would like to request travel
> > reimbursement.
> >
> > Flight | 162,46 EUR
> > ===
> > Total  | 162,46 EUR
> >
> 
> Looks good on my side, but keep in mind you can also ask accomodation

LGTM

thx

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

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


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

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


[FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio

2024-02-28 Thread J. Dekker
This was an experimental/research codec of which ffmpeg is the only
encoder and decoder, development has stalled and these files don't exist
in the wild.

Signed-off-by: J. Dekker 
---
 Changelog   |1 +
 configure   |3 -
 libavcodec/Makefile |3 -
 libavcodec/allcodecs.c  |3 -
 libavcodec/codec_desc.c |   14 -
 libavcodec/sonic.c  | 1125 ---
 6 files changed, 1 insertion(+), 1148 deletions(-)
 delete mode 100644 libavcodec/sonic.c

diff --git a/Changelog b/Changelog
index 610ee61dd6..e2096f249a 100644
--- a/Changelog
+++ b/Changelog
@@ -27,6 +27,7 @@ version :
 - a C11-compliant compiler is now required; note that this requirement
   will be bumped to C17 in the near future, so consider updating your
   build environment if it lacks C17 support
+- sonic lossy/lossless audio codec removed
 
 version 6.1:
 - libaribcaption decoder
diff --git a/configure b/configure
index bb5e630bad..e639a5e2b7 100755
--- a/configure
+++ b/configure
@@ -2991,9 +2991,6 @@ sipr_decoder_select="lsp"
 smvjpeg_decoder_select="mjpeg_decoder"
 snow_decoder_select="dwt h264qpel rangecoder videodsp"
 snow_encoder_select="dwt h264qpel hpeldsp me_cmp mpegvideoenc rangecoder 
videodsp"
-sonic_decoder_select="golomb rangecoder"
-sonic_encoder_select="golomb rangecoder"
-sonic_ls_encoder_select="golomb rangecoder"
 sp5x_decoder_select="mjpeg_decoder"
 speedhq_decoder_select="blockdsp idctdsp"
 speedhq_encoder_select="mpegvideoenc"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 09ae5270b3..3fc716ee68 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -687,9 +687,6 @@ OBJS-$(CONFIG_SNOW_DECODER)+= snowdec.o snow.o 
snow_dwt.o
 OBJS-$(CONFIG_SNOW_ENCODER)+= snowenc.o snow.o snow_dwt.o  
   \
   h263.o h263data.o ituh263enc.o
 OBJS-$(CONFIG_SOL_DPCM_DECODER)+= dpcm.o
-OBJS-$(CONFIG_SONIC_DECODER)   += sonic.o
-OBJS-$(CONFIG_SONIC_ENCODER)   += sonic.o
-OBJS-$(CONFIG_SONIC_LS_ENCODER)+= sonic.o
 OBJS-$(CONFIG_SPEEDHQ_DECODER) += speedhqdec.o speedhq.o mpeg12.o \
   mpeg12data.o
 OBJS-$(CONFIG_SPEEDHQ_ENCODER) += speedhq.o mpeg12data.o mpeg12enc.o 
speedhqenc.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index ef8c3a6d7d..e0a4a5421d 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -535,9 +535,6 @@ extern const FFCodec ff_shorten_decoder;
 extern const FFCodec ff_sipr_decoder;
 extern const FFCodec ff_siren_decoder;
 extern const FFCodec ff_smackaud_decoder;
-extern const FFCodec ff_sonic_encoder;
-extern const FFCodec ff_sonic_decoder;
-extern const FFCodec ff_sonic_ls_encoder;
 extern const FFCodec ff_tak_decoder;
 extern const FFCodec ff_truehd_encoder;
 extern const FFCodec ff_truehd_decoder;
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 033344304c..9b456616be 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -3175,20 +3175,6 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .long_name = NULL_IF_CONFIG_SMALL("Wave synthesis pseudo-codec"),
 .props = AV_CODEC_PROP_INTRA_ONLY,
 },
-{
-.id= AV_CODEC_ID_SONIC,
-.type  = AVMEDIA_TYPE_AUDIO,
-.name  = "sonic",
-.long_name = NULL_IF_CONFIG_SMALL("Sonic"),
-.props = AV_CODEC_PROP_INTRA_ONLY,
-},
-{
-.id= AV_CODEC_ID_SONIC_LS,
-.type  = AVMEDIA_TYPE_AUDIO,
-.name  = "sonicls",
-.long_name = NULL_IF_CONFIG_SMALL("Sonic lossless"),
-.props = AV_CODEC_PROP_INTRA_ONLY,
-},
 {
 .id= AV_CODEC_ID_EVRC,
 .type  = AVMEDIA_TYPE_AUDIO,
diff --git a/libavcodec/sonic.c b/libavcodec/sonic.c
deleted file mode 100644
index 0544fecf46..00
--- a/libavcodec/sonic.c
+++ /dev/null
@@ -1,1125 +0,0 @@
-/*
- * Simple free lossless/lossy audio codec
- * Copyright (c) 2004 Alex Beregszaszi
- *
- * 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 "config_components.h"
-
-#include "avcodec.h"
-#include "codec_internal.h"
-#include "decode.h"
-#include "encode.h"

[FFmpeg-devel] [PATCH 1/2] MAINTAINERS: remove inactive developer

2024-02-28 Thread J. Dekker
Inactive since 2007.

Signed-off-by: J. Dekker 
---
 MAINTAINERS | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index cc7f564f48..ace58f02a1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -148,7 +148,6 @@ Codecs:
   cinepak.c Roberto Togni
   cinepakenc.c  Rl / Aetey G.T. AB
   ccaption_dec.cAnshul Maheshwari, Aman Gupta
-  cljr  Alex Beregszaszi
   cpia.cStephan Hilb
   cscd.cReimar Doeffinger
   cuviddec.cTimo Rothenpieler
@@ -230,13 +229,12 @@ Codecs:
   rv10.cMichael Niedermayer
   smc.c Mike Melanson
   snow* Michael Niedermayer, Loren Merritt
-  sonic.c   Alex Beregszaszi
   speedhq.c Steinar H. Gunderson
   srt*  Aurelien Jacobs
   sunrast.c Ivo van Poorten
   svq3.cMichael Niedermayer
   truemotion1*  Mike Melanson
-  tta.c Alex Beregszaszi, Jaikrishnan Menon
+  tta.c Jaikrishnan Menon
   txd.c Ivo van Poorten
   v4l2_*Jorge Ramirez-Ortiz
   vc2*  Rostislav Pehlivanov
@@ -446,7 +444,6 @@ Muxers/Demuxers:
   spdif*Anssi Hannula
   srtdec.c  Aurelien Jacobs
   swf.c Baptiste Coudurier
-  tta.c Alex Beregszaszi
   txd.c Ivo van Poorten
   voc.c Aurelien Jacobs
   wav.c Michael Niedermayer
@@ -493,7 +490,7 @@ Mac OS X / PowerPC  Romain Dolbeau, 
Guillaume Poirier
 Amiga / PowerPC Colin Ward
 Linux / PowerPC Lauri Kasanen
 RISC-V  Rémi Denis-Courmont
-Windows MinGW   Alex Beregszaszi, Ramiro Polla
+Windows MinGW   Ramiro Polla
 Windows Cygwin  Victor Paesa
 Windows MSVCHendrik Leppkes
 ADI/Blackfin DSPMarc Hoffman
-- 
2.43.2

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

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


Re: [FFmpeg-devel] [PATCH v2 1/2] avdevice: deprecate opengl outdev

2024-02-28 Thread J. Dekker


Anton Khirnov  writes:

> Quoting Lynne (2024-02-21 13:32:19)
>> Feb 21, 2024, 12:34 by j...@itanimul.li:
>> 
>> > Signed-off-by: J. Dekker 
>> > ---
>> >  doc/outdevs.texi|  2 +-
>> >  libavdevice/opengl_enc.c| 11 +++
>> >  libavdevice/version_major.h |  2 ++
>> >  3 files changed, 14 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/doc/outdevs.texi b/doc/outdevs.texi
>> > index f0484bbf8f..941429a8c8 100644
>> > --- a/doc/outdevs.texi
>> > +++ b/doc/outdevs.texi
>> > @@ -302,7 +302,7 @@ ffmpeg -re -i INPUT -c:v rawvideo -pix_fmt bgra -f
>> > fbdev /dev/fb0
>> >  See also @url{http://linux-fbdev.sourceforge.net/}, and fbset(1).
>> >
>> 
>> We have removed demuxers and decoders before without a deprecation period.
>> I think we should do the same here, as it is just a muxer.
>
> In the last thread some people really wanted to have it deprecated
> first.
>
> While I'd also prefer to remove it outright, I'd prefer even more to not
> have this bikeshud to death.

No reason to delay this further. Pushed.

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

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


Re: [FFmpeg-devel] [PATCH v4] avcodec/aarch64/hevc: add luma deblock NEON

2024-02-28 Thread J. Dekker

Martin Storsjö  writes:

> On Wed, 28 Feb 2024, J. Dekker wrote:
>
>>
>> Martin Storsjö  writes:
>>
>>> On Wed, 28 Feb 2024, J. Dekker wrote:
>>>

 Martin Storsjö  writes:

> On Tue, 27 Feb 2024, J. Dekker wrote:
>
>> Benched using single-threaded full decode on an Ampere Altra.
>>
>> Bpp Before  After  Speedup
>> 8   73,3s   65,2s  1.124x
>> 10  114,2s  104,0s 1.098x
>> 12  125,8s  115,7s 1.087x
>>
>> Signed-off-by: J. Dekker 
>> ---
>>
>> Slightly improved 12bit version.
>>
>> libavcodec/aarch64/hevcdsp_deblock_neon.S | 417 ++
>> libavcodec/aarch64/hevcdsp_init_aarch64.c |  18 +
>> 2 files changed, 435 insertions(+)
>>
>> diff --git a/libavcodec/aarch64/hevcdsp_deblock_neon.S
>> b/libavcodec/aarch64/hevcdsp_deblock_neon.S
>> index 8227f65649..581056a91e 100644
>> --- a/libavcodec/aarch64/hevcdsp_deblock_neon.S
>> +++ b/libavcodec/aarch64/hevcdsp_deblock_neon.S
>> @@ -181,3 +181,420 @@ hevc_h_loop_filter_chroma 12
>> hevc_v_loop_filter_chroma 8
>> hevc_v_loop_filter_chroma 10
>> hevc_v_loop_filter_chroma 12
>> +
>> +.macro hevc_loop_filter_luma_body bitdepth
>> +function hevc_loop_filter_luma_body_\bitdepth\()_neon, export=0
>> +.if \bitdepth > 8
>> + lsl w2, w2, #(\bitdepth - 8) // beta <<= BIT_DEPTH - 8
>> +.else
>> +uxtlv0.8h, v0.8b
>> +uxtlv1.8h, v1.8b
>> +uxtlv2.8h, v2.8b
>> +uxtlv3.8h, v3.8b
>> +uxtlv4.8h, v4.8b
>> +uxtlv5.8h, v5.8b
>> +uxtlv6.8h, v6.8b
>> +uxtlv7.8h, v7.8b
>> +.endif
>> +ldr w7, [x3] // tc[0]
>> +ldr w8, [x3, #4] // tc[1]
>> +dup v18.4h, w7
>> +dup v19.4h, w8
>> +trn1v18.2d, v18.2d, v19.2d
>> +.if \bitdepth > 8
>> +shl v18.8h, v18.8h, #(\bitdepth - 8)
>> +.endif
>> +dup v27.8h, w2 // beta
>> +// tc25
>> +shl v19.8h, v18.8h, #2 // * 4
>> +add v19.8h, v19.8h, v18.8h // (tc * 5)
>> +srshr   v19.8h, v19.8h, #1 // (tc * 5 + 1) >> 1
>> +sshrv17.8h, v27.8h, #2 // beta2
>> +
>> +// beta_2 check
>> +// dp0  = abs(P2  - 2 * P1  + P0)
>> +add v22.8h, v3.8h, v1.8h
>> +shl v23.8h, v2.8h, #1
>> +sabdv30.8h, v22.8h, v23.8h
>> +// dq0  = abs(Q2  - 2 * Q1  + Q0)
>> +add v21.8h, v6.8h, v4.8h
>> +shl v26.8h, v5.8h, #1
>> +sabdv31.8h, v21.8h, v26.8h
>> +// d0   = dp0 + dq0
>> +add v20.8h, v30.8h, v31.8h
>> +shl v25.8h, v20.8h, #1
>> +// (d0 << 1) < beta_2
>> +cmgtv23.8h, v17.8h, v25.8h
>> +
>> +// beta check
>> +// d0 + d3 < beta
>> +mov x9, #0x
>> +dup v24.2d, x9
>> +and v25.16b, v24.16b, v20.16b
>> +addpv25.8h, v25.8h, v25.8h // 1+0 0+1 1+0 0+1
>> +addpv25.4h, v25.4h, v25.4h // 1+0+0+1 1+0+0+1
>> + cmgt v25.4h, v27.4h, v25.4h // lower/upper mask in h[0/1]
>> +mov w9, v25.s[0]
>
> I don't quite understand what this sequence does and/or how our data is
> laid
> out in our registers - we have d0 on input in v20, where's d3? An doesn't
> the
> "and" throw away half of the input elements here?
>
> I see some similar patterns with the masking and handling below as well -
> I get
> a feeling that I don't quite understand the algorithm here, and/or the
> data
> layout.

 We have d0, d1, d2, d3 for both 4 line blocks in v20, mask out d1/d2 and
 use pair-wise adds to move our data around and calculate d0+d3
 together. The first addp just moves elements around, the second addp
 adds d0 + 0 + 0 + d3.
>>>
>>> Right, I guess this is the bit that was surprising. I would have expected to
>>> have e.g. all the d0 values for e.g. the 8 individual pixels in one SIMD
>>> register, and all the d3 values for all pixels in another SIMD register.
>>>
>>> So as we're operating on 8 pixels in parallel, each of those 8 pixels have
>>> their own d0/d3 values, right? Or is this a case where we have just one
>>> d0/d3
>>> value for a range of pixels?
>>
>> Yes, d0/d1/d2/d3 are per 4 lines of 8 pixels, it's because d0 and d3 are
>> calculated within their own line, d0 from line 0, d3 from line 3. Maybe
>> it's more confusing since we are doing both halves of the f

Re: [FFmpeg-devel] [PATCH v4] avcodec/aarch64/hevc: add luma deblock NEON

2024-02-28 Thread Martin Storsjö

On Wed, 28 Feb 2024, J. Dekker wrote:



Martin Storsjö  writes:


On Wed, 28 Feb 2024, J. Dekker wrote:



Martin Storsjö  writes:


On Tue, 27 Feb 2024, J. Dekker wrote:


Benched using single-threaded full decode on an Ampere Altra.

Bpp Before  After  Speedup
8   73,3s   65,2s  1.124x
10  114,2s  104,0s 1.098x
12  125,8s  115,7s 1.087x

Signed-off-by: J. Dekker 
---

Slightly improved 12bit version.

libavcodec/aarch64/hevcdsp_deblock_neon.S | 417 ++
libavcodec/aarch64/hevcdsp_init_aarch64.c |  18 +
2 files changed, 435 insertions(+)

diff --git a/libavcodec/aarch64/hevcdsp_deblock_neon.S 
b/libavcodec/aarch64/hevcdsp_deblock_neon.S
index 8227f65649..581056a91e 100644
--- a/libavcodec/aarch64/hevcdsp_deblock_neon.S
+++ b/libavcodec/aarch64/hevcdsp_deblock_neon.S
@@ -181,3 +181,420 @@ hevc_h_loop_filter_chroma 12
hevc_v_loop_filter_chroma 8
hevc_v_loop_filter_chroma 10
hevc_v_loop_filter_chroma 12
+
+.macro hevc_loop_filter_luma_body bitdepth
+function hevc_loop_filter_luma_body_\bitdepth\()_neon, export=0
+.if \bitdepth > 8
+lsl w2, w2, #(\bitdepth - 8) // beta <<= BIT_DEPTH - 8
+.else
+uxtlv0.8h, v0.8b
+uxtlv1.8h, v1.8b
+uxtlv2.8h, v2.8b
+uxtlv3.8h, v3.8b
+uxtlv4.8h, v4.8b
+uxtlv5.8h, v5.8b
+uxtlv6.8h, v6.8b
+uxtlv7.8h, v7.8b
+.endif
+ldr w7, [x3] // tc[0]
+ldr w8, [x3, #4] // tc[1]
+dup v18.4h, w7
+dup v19.4h, w8
+trn1v18.2d, v18.2d, v19.2d
+.if \bitdepth > 8
+shl v18.8h, v18.8h, #(\bitdepth - 8)
+.endif
+dup v27.8h, w2 // beta
+// tc25
+shl v19.8h, v18.8h, #2 // * 4
+add v19.8h, v19.8h, v18.8h // (tc * 5)
+srshr   v19.8h, v19.8h, #1 // (tc * 5 + 1) >> 1
+sshrv17.8h, v27.8h, #2 // beta2
+
+// beta_2 check
+// dp0  = abs(P2  - 2 * P1  + P0)
+add v22.8h, v3.8h, v1.8h
+shl v23.8h, v2.8h, #1
+sabdv30.8h, v22.8h, v23.8h
+// dq0  = abs(Q2  - 2 * Q1  + Q0)
+add v21.8h, v6.8h, v4.8h
+shl v26.8h, v5.8h, #1
+sabdv31.8h, v21.8h, v26.8h
+// d0   = dp0 + dq0
+add v20.8h, v30.8h, v31.8h
+shl v25.8h, v20.8h, #1
+// (d0 << 1) < beta_2
+cmgtv23.8h, v17.8h, v25.8h
+
+// beta check
+// d0 + d3 < beta
+mov x9, #0x
+dup v24.2d, x9
+and v25.16b, v24.16b, v20.16b
+addpv25.8h, v25.8h, v25.8h // 1+0 0+1 1+0 0+1
+addpv25.4h, v25.4h, v25.4h // 1+0+0+1 1+0+0+1
+cmgtv25.4h, v27.4h, v25.4h // lower/upper mask in h[0/1]
+mov w9, v25.s[0]


I don't quite understand what this sequence does and/or how our data is laid
out in our registers - we have d0 on input in v20, where's d3? An doesn't the
"and" throw away half of the input elements here?

I see some similar patterns with the masking and handling below as well - I get
a feeling that I don't quite understand the algorithm here, and/or the data
layout.


We have d0, d1, d2, d3 for both 4 line blocks in v20, mask out d1/d2 and
use pair-wise adds to move our data around and calculate d0+d3
together. The first addp just moves elements around, the second addp
adds d0 + 0 + 0 + d3.


Right, I guess this is the bit that was surprising. I would have expected to
have e.g. all the d0 values for e.g. the 8 individual pixels in one SIMD
register, and all the d3 values for all pixels in another SIMD register.

So as we're operating on 8 pixels in parallel, each of those 8 pixels have
their own d0/d3 values, right? Or is this a case where we have just one d0/d3
value for a range of pixels?


Yes, d0/d1/d2/d3 are per 4 lines of 8 pixels, it's because d0 and d3 are
calculated within their own line, d0 from line 0, d3 from line 3. Maybe
it's more confusing since we are doing both halves of the filter at the
same time? v20 contains d0 d1 d2 d3 d0 d1 d2 d3, where the second d0 is
distinct from the first.

But essentially we're doing the same operation across the entire 8
lines, the filter just makes an overall skip decision for each block of
4 lines based on the sum of the result from line 0 and 3.


Ah, right, I see. I guess this makes sense then. Thanks!

Thus, no further objections to it; the optimizing of loading/storing can 
be done separately.


// 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 subj

Re: [FFmpeg-devel] [PATCH] avcodec/intrax8: Fix assert

2024-02-28 Thread Andreas Rheinhardt
Andreas Rheinhardt:
> Commit 900ce6f8c3526f27173057bb955f54f4f4f41246 replaced
> IntraX8Context.ac_vlc by IntraX8Context.ac_vlc_table,
> but forgot to update an av_assert2()*.
> cf7ed01938a4d8b2ccd28f1fadacd79103e54eed then
> replaced this with a check for j_ac_vlc[mode],
> but this makes no sense as j_ac_vlc is of type
> const VLCElem [2][2][8][].
> 
> Worse yet, mode can be up to three and then
> j_ac_vlc[mode] is undefined behaviour. This happened
> during the wmv8-x8intra FATE test.
> 
> *: Since 84f16bb5e68dc47eca4dc96b3391c58471cd7328
> config.h was no longer auto-included in avassert.h
> and this disabled av_assert1() and av_assert2()
> in files where config.h has not been included before
> the inclusion of avassert.h.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/intrax8.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/intrax8.c b/libavcodec/intrax8.c
> index b6aacb170a..948391599f 100644
> --- a/libavcodec/intrax8.c
> +++ b/libavcodec/intrax8.c
> @@ -103,7 +103,7 @@ static inline void x8_select_ac_table(IntraX8Context 
> *const w, int mode)
>  table_index   = get_bits(w->gb, 3);
>  // 2 modes use same tables
>  w->j_ac_vlc_table[mode] = j_ac_vlc[w->quant < 13][mode >> 
> 1][table_index];
> -av_assert2(j_ac_vlc[mode]);
> +av_assert2(w->j_ac_vlc_table[mode]);
>  }
>  
>  static inline int x8_get_orient_vlc(IntraX8Context *w)

Will apply this patch tomorrow unless there are objections.

- Andreas

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

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


Re: [FFmpeg-devel] [PATCH v4] avcodec/aarch64/hevc: add luma deblock NEON

2024-02-28 Thread J. Dekker

Martin Storsjö  writes:

> On Wed, 28 Feb 2024, J. Dekker wrote:
>
>>
>> Martin Storsjö  writes:
>>
>>> On Tue, 27 Feb 2024, J. Dekker wrote:
>>>
 Benched using single-threaded full decode on an Ampere Altra.

 Bpp Before  After  Speedup
 8   73,3s   65,2s  1.124x
 10  114,2s  104,0s 1.098x
 12  125,8s  115,7s 1.087x

 Signed-off-by: J. Dekker 
 ---

 Slightly improved 12bit version.

 libavcodec/aarch64/hevcdsp_deblock_neon.S | 417 ++
 libavcodec/aarch64/hevcdsp_init_aarch64.c |  18 +
 2 files changed, 435 insertions(+)

 diff --git a/libavcodec/aarch64/hevcdsp_deblock_neon.S 
 b/libavcodec/aarch64/hevcdsp_deblock_neon.S
 index 8227f65649..581056a91e 100644
 --- a/libavcodec/aarch64/hevcdsp_deblock_neon.S
 +++ b/libavcodec/aarch64/hevcdsp_deblock_neon.S
 @@ -181,3 +181,420 @@ hevc_h_loop_filter_chroma 12
 hevc_v_loop_filter_chroma 8
 hevc_v_loop_filter_chroma 10
 hevc_v_loop_filter_chroma 12
 +
 +.macro hevc_loop_filter_luma_body bitdepth
 +function hevc_loop_filter_luma_body_\bitdepth\()_neon, export=0
 +.if \bitdepth > 8
 +lsl w2, w2, #(\bitdepth - 8) // beta <<= BIT_DEPTH - 8
 +.else
 +uxtlv0.8h, v0.8b
 +uxtlv1.8h, v1.8b
 +uxtlv2.8h, v2.8b
 +uxtlv3.8h, v3.8b
 +uxtlv4.8h, v4.8b
 +uxtlv5.8h, v5.8b
 +uxtlv6.8h, v6.8b
 +uxtlv7.8h, v7.8b
 +.endif
 +ldr w7, [x3] // tc[0]
 +ldr w8, [x3, #4] // tc[1]
 +dup v18.4h, w7
 +dup v19.4h, w8
 +trn1v18.2d, v18.2d, v19.2d
 +.if \bitdepth > 8
 +shl v18.8h, v18.8h, #(\bitdepth - 8)
 +.endif
 +dup v27.8h, w2 // beta
 +// tc25
 +shl v19.8h, v18.8h, #2 // * 4
 +add v19.8h, v19.8h, v18.8h // (tc * 5)
 +srshr   v19.8h, v19.8h, #1 // (tc * 5 + 1) >> 1
 +sshrv17.8h, v27.8h, #2 // beta2
 +
 +// beta_2 check
 +// dp0  = abs(P2  - 2 * P1  + P0)
 +add v22.8h, v3.8h, v1.8h
 +shl v23.8h, v2.8h, #1
 +sabdv30.8h, v22.8h, v23.8h
 +// dq0  = abs(Q2  - 2 * Q1  + Q0)
 +add v21.8h, v6.8h, v4.8h
 +shl v26.8h, v5.8h, #1
 +sabdv31.8h, v21.8h, v26.8h
 +// d0   = dp0 + dq0
 +add v20.8h, v30.8h, v31.8h
 +shl v25.8h, v20.8h, #1
 +// (d0 << 1) < beta_2
 +cmgtv23.8h, v17.8h, v25.8h
 +
 +// beta check
 +// d0 + d3 < beta
 +mov x9, #0x
 +dup v24.2d, x9
 +and v25.16b, v24.16b, v20.16b
 +addpv25.8h, v25.8h, v25.8h // 1+0 0+1 1+0 0+1
 +addpv25.4h, v25.4h, v25.4h // 1+0+0+1 1+0+0+1
 +cmgtv25.4h, v27.4h, v25.4h // lower/upper mask in 
 h[0/1]
 +mov w9, v25.s[0]
>>>
>>> I don't quite understand what this sequence does and/or how our data is laid
>>> out in our registers - we have d0 on input in v20, where's d3? An doesn't 
>>> the
>>> "and" throw away half of the input elements here?
>>>
>>> I see some similar patterns with the masking and handling below as well - I 
>>> get
>>> a feeling that I don't quite understand the algorithm here, and/or the data
>>> layout.
>>
>> We have d0, d1, d2, d3 for both 4 line blocks in v20, mask out d1/d2 and
>> use pair-wise adds to move our data around and calculate d0+d3
>> together. The first addp just moves elements around, the second addp
>> adds d0 + 0 + 0 + d3.
>
> Right, I guess this is the bit that was surprising. I would have expected to
> have e.g. all the d0 values for e.g. the 8 individual pixels in one SIMD
> register, and all the d3 values for all pixels in another SIMD register.
>
> So as we're operating on 8 pixels in parallel, each of those 8 pixels have
> their own d0/d3 values, right? Or is this a case where we have just one d0/d3
> value for a range of pixels?

Yes, d0/d1/d2/d3 are per 4 lines of 8 pixels, it's because d0 and d3 are
calculated within their own line, d0 from line 0, d3 from line 3. Maybe
it's more confusing since we are doing both halves of the filter at the
same time? v20 contains d0 d1 d2 d3 d0 d1 d2 d3, where the second d0 is
distinct from the first.

But essentially we're doing the same operation across the entire 8
lines, the filter just makes an overall skip decision for each block of
4 lines based on the sum

Re: [FFmpeg-devel] [PATCH v4] avcodec/aarch64/hevc: add luma deblock NEON

2024-02-28 Thread Martin Storsjö

On Wed, 28 Feb 2024, J. Dekker wrote:



Martin Storsjö  writes:


On Tue, 27 Feb 2024, J. Dekker wrote:


Benched using single-threaded full decode on an Ampere Altra.

Bpp Before  After  Speedup
8   73,3s   65,2s  1.124x
10  114,2s  104,0s 1.098x
12  125,8s  115,7s 1.087x

Signed-off-by: J. Dekker 
---

Slightly improved 12bit version.

libavcodec/aarch64/hevcdsp_deblock_neon.S | 417 ++
libavcodec/aarch64/hevcdsp_init_aarch64.c |  18 +
2 files changed, 435 insertions(+)

diff --git a/libavcodec/aarch64/hevcdsp_deblock_neon.S 
b/libavcodec/aarch64/hevcdsp_deblock_neon.S
index 8227f65649..581056a91e 100644
--- a/libavcodec/aarch64/hevcdsp_deblock_neon.S
+++ b/libavcodec/aarch64/hevcdsp_deblock_neon.S
@@ -181,3 +181,420 @@ hevc_h_loop_filter_chroma 12
hevc_v_loop_filter_chroma 8
hevc_v_loop_filter_chroma 10
hevc_v_loop_filter_chroma 12
+
+.macro hevc_loop_filter_luma_body bitdepth
+function hevc_loop_filter_luma_body_\bitdepth\()_neon, export=0
+.if \bitdepth > 8
+lsl w2, w2, #(\bitdepth - 8) // beta <<= BIT_DEPTH - 8
+.else
+uxtlv0.8h, v0.8b
+uxtlv1.8h, v1.8b
+uxtlv2.8h, v2.8b
+uxtlv3.8h, v3.8b
+uxtlv4.8h, v4.8b
+uxtlv5.8h, v5.8b
+uxtlv6.8h, v6.8b
+uxtlv7.8h, v7.8b
+.endif
+ldr w7, [x3] // tc[0]
+ldr w8, [x3, #4] // tc[1]
+dup v18.4h, w7
+dup v19.4h, w8
+trn1v18.2d, v18.2d, v19.2d
+.if \bitdepth > 8
+shl v18.8h, v18.8h, #(\bitdepth - 8)
+.endif
+dup v27.8h, w2 // beta
+// tc25
+shl v19.8h, v18.8h, #2 // * 4
+add v19.8h, v19.8h, v18.8h // (tc * 5)
+srshr   v19.8h, v19.8h, #1 // (tc * 5 + 1) >> 1
+sshrv17.8h, v27.8h, #2 // beta2
+
+// beta_2 check
+// dp0  = abs(P2  - 2 * P1  + P0)
+add v22.8h, v3.8h, v1.8h
+shl v23.8h, v2.8h, #1
+sabdv30.8h, v22.8h, v23.8h
+// dq0  = abs(Q2  - 2 * Q1  + Q0)
+add v21.8h, v6.8h, v4.8h
+shl v26.8h, v5.8h, #1
+sabdv31.8h, v21.8h, v26.8h
+// d0   = dp0 + dq0
+add v20.8h, v30.8h, v31.8h
+shl v25.8h, v20.8h, #1
+// (d0 << 1) < beta_2
+cmgtv23.8h, v17.8h, v25.8h
+
+// beta check
+// d0 + d3 < beta
+mov x9, #0x
+dup v24.2d, x9
+and v25.16b, v24.16b, v20.16b
+addpv25.8h, v25.8h, v25.8h // 1+0 0+1 1+0 0+1
+addpv25.4h, v25.4h, v25.4h // 1+0+0+1 1+0+0+1
+cmgtv25.4h, v27.4h, v25.4h // lower/upper mask in h[0/1]
+mov w9, v25.s[0]


I don't quite understand what this sequence does and/or how our data is laid
out in our registers - we have d0 on input in v20, where's d3? An doesn't the
"and" throw away half of the input elements here?

I see some similar patterns with the masking and handling below as well - I get
a feeling that I don't quite understand the algorithm here, and/or the data
layout.


We have d0, d1, d2, d3 for both 4 line blocks in v20, mask out d1/d2 and
use pair-wise adds to move our data around and calculate d0+d3
together. The first addp just moves elements around, the second addp
adds d0 + 0 + 0 + d3.


Right, I guess this is the bit that was surprising. I would have expected 
to have e.g. all the d0 values for e.g. the 8 individual pixels in one 
SIMD register, and all the d3 values for all pixels in another SIMD 
register.


So as we're operating on 8 pixels in parallel, each of those 8 pixels have 
their own d0/d3 values, right? Or is this a case where we have just one 
d0/d3 value for a range of pixels?


// 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] avcodec/aarch64/hevc: add luma deblock NEON

2024-02-28 Thread J. Dekker

Martin Storsjö  writes:

> On Tue, 27 Feb 2024, J. Dekker wrote:
>
>> Benched using single-threaded full decode on an Ampere Altra.
>>
>> Bpp Before  After  Speedup
>> 8   73,3s   65,2s  1.124x
>> 10  114,2s  104,0s 1.098x
>> 12  125,8s  115,7s 1.087x
>>
>> Signed-off-by: J. Dekker 
>> ---
>>
>> Slightly improved 12bit version.
>>
>> libavcodec/aarch64/hevcdsp_deblock_neon.S | 417 ++
>> libavcodec/aarch64/hevcdsp_init_aarch64.c |  18 +
>> 2 files changed, 435 insertions(+)
>>
>> diff --git a/libavcodec/aarch64/hevcdsp_deblock_neon.S 
>> b/libavcodec/aarch64/hevcdsp_deblock_neon.S
>> index 8227f65649..581056a91e 100644
>> --- a/libavcodec/aarch64/hevcdsp_deblock_neon.S
>> +++ b/libavcodec/aarch64/hevcdsp_deblock_neon.S
>> @@ -181,3 +181,420 @@ hevc_h_loop_filter_chroma 12
>> hevc_v_loop_filter_chroma 8
>> hevc_v_loop_filter_chroma 10
>> hevc_v_loop_filter_chroma 12
>> +
>> +.macro hevc_loop_filter_luma_body bitdepth
>> +function hevc_loop_filter_luma_body_\bitdepth\()_neon, export=0
>> +.if \bitdepth > 8
>> +lsl w2, w2, #(\bitdepth - 8) // beta <<= BIT_DEPTH - 8
>> +.else
>> +uxtlv0.8h, v0.8b
>> +uxtlv1.8h, v1.8b
>> +uxtlv2.8h, v2.8b
>> +uxtlv3.8h, v3.8b
>> +uxtlv4.8h, v4.8b
>> +uxtlv5.8h, v5.8b
>> +uxtlv6.8h, v6.8b
>> +uxtlv7.8h, v7.8b
>> +.endif
>> +ldr w7, [x3] // tc[0]
>> +ldr w8, [x3, #4] // tc[1]
>> +dup v18.4h, w7
>> +dup v19.4h, w8
>> +trn1v18.2d, v18.2d, v19.2d
>> +.if \bitdepth > 8
>> +shl v18.8h, v18.8h, #(\bitdepth - 8)
>> +.endif
>> +dup v27.8h, w2 // beta
>> +// tc25
>> +shl v19.8h, v18.8h, #2 // * 4
>> +add v19.8h, v19.8h, v18.8h // (tc * 5)
>> +srshr   v19.8h, v19.8h, #1 // (tc * 5 + 1) >> 1
>> +sshrv17.8h, v27.8h, #2 // beta2
>> +
>> +// beta_2 check
>> +// dp0  = abs(P2  - 2 * P1  + P0)
>> +add v22.8h, v3.8h, v1.8h
>> +shl v23.8h, v2.8h, #1
>> +sabdv30.8h, v22.8h, v23.8h
>> +// dq0  = abs(Q2  - 2 * Q1  + Q0)
>> +add v21.8h, v6.8h, v4.8h
>> +shl v26.8h, v5.8h, #1
>> +sabdv31.8h, v21.8h, v26.8h
>> +// d0   = dp0 + dq0
>> +add v20.8h, v30.8h, v31.8h
>> +shl v25.8h, v20.8h, #1
>> +// (d0 << 1) < beta_2
>> +cmgtv23.8h, v17.8h, v25.8h
>> +
>> +// beta check
>> +// d0 + d3 < beta
>> +mov x9, #0x
>> +dup v24.2d, x9
>> +and v25.16b, v24.16b, v20.16b
>> +addpv25.8h, v25.8h, v25.8h // 1+0 0+1 1+0 0+1
>> +addpv25.4h, v25.4h, v25.4h // 1+0+0+1 1+0+0+1
>> +cmgtv25.4h, v27.4h, v25.4h // lower/upper mask in h[0/1]
>> +mov w9, v25.s[0]
>
> I don't quite understand what this sequence does and/or how our data is laid
> out in our registers - we have d0 on input in v20, where's d3? An doesn't the
> "and" throw away half of the input elements here?
>
> I see some similar patterns with the masking and handling below as well - I 
> get
> a feeling that I don't quite understand the algorithm here, and/or the data
> layout.

We have d0, d1, d2, d3 for both 4 line blocks in v20, mask out d1/d2 and
use pair-wise adds to move our data around and calculate d0+d3
together. The first addp just moves elements around, the second addp
adds d0 + 0 + 0 + d3.

The we can check d0+d3 < beta and use the fact that the compare returns
either 0 or -1 and sign-extend to half the register width for a
mask. This allows us to calculate both 4 line block masks at the same
time in NEON registers.

>> +.if \bitdepth > 8
>> +ld1 {v0.8h}, [x0], x1
>> +ld1 {v1.8h}, [x0], x1
>> +ld1 {v2.8h}, [x0], x1
>> +ld1 {v3.8h}, [x0], x1
>> +ld1 {v4.8h}, [x0], x1
>> +ld1 {v5.8h}, [x0], x1
>> +ld1 {v6.8h}, [x0], x1
>> +ld1 {v7.8h}, [x0]
>> +mov w14, #((1 << \bitdepth) - 1)
>
> For loads like these, we can generally save a bit by using two alternating
> registers for loading, with a double stride - see e.g. the vp9 loop filter
> implementations. But that's a micro optimization.
>
> Other than that, this mostly looks reasaonble.

Will fix on push if no other comments.

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

To unsubscribe, visit link above, or email
ffmpeg-