[FFmpeg-devel] [PATCH v2] lavc/videotoolboxenc: Add spatial_aq option
From: Dennis Sädtler
Added in macOS 15 "Sequoia".
Signed-off-by: Dennis Sädtler
---
Fixed line-endings, otherwise identical to v1.
libavcodec/videotoolboxenc.c | 12
1 file changed, 12 insertions(+)
diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
index da7b291b03..fb2de7b960 100644
--- a/libavcodec/videotoolboxenc.c
+++ b/libavcodec/videotoolboxenc.c
@@ -121,6 +121,7 @@ static struct{
CFStringRef kVTCompressionPropertyKey_PrioritizeEncodingSpeedOverQuality;
CFStringRef kVTCompressionPropertyKey_ConstantBitRate;
CFStringRef kVTCompressionPropertyKey_EncoderID;
+CFStringRef kVTCompressionPropertyKey_SpatialAdaptiveQPLevel;
CFStringRef
kVTVideoEncoderSpecification_EnableHardwareAcceleratedVideoEncoder;
CFStringRef
kVTVideoEncoderSpecification_RequireHardwareAcceleratedVideoEncoder;
@@ -208,6 +209,7 @@ static void loadVTEncSymbols(void){
"ReferenceBufferCount");
GET_SYM(kVTCompressionPropertyKey_MaxAllowedFrameQP, "MaxAllowedFrameQP");
GET_SYM(kVTCompressionPropertyKey_MinAllowedFrameQP, "MinAllowedFrameQP");
+GET_SYM(kVTCompressionPropertyKey_SpatialAdaptiveQPLevel,
"SpatialAdaptiveQPLevel");
}
#define H264_PROFILE_CONSTRAINED_HIGH (AV_PROFILE_H264_HIGH |
AV_PROFILE_H264_CONSTRAINED)
@@ -279,6 +281,7 @@ typedef struct VTEncContext {
int max_slice_bytes;
int power_efficient;
int max_ref_frames;
+int spatialaq;
} VTEncContext;
static void vtenc_free_buf_node(BufNode *info)
@@ -1599,6 +1602,13 @@ static int vtenc_create_encoder(AVCodecContext *avctx,
}
}
+if (vtctx->spatialaq >= 0) {
+set_encoder_int_property_or_log(avctx,
+
compat_keys.kVTCompressionPropertyKey_SpatialAdaptiveQPLevel,
+"spatialaq",
+vtctx->spatialaq ?
kVTQPModulationLevel_Default : kVTQPModulationLevel_Disable);
+}
+
status = VTCompressionSessionPrepareToEncodeFrames(vtctx->session);
if (status) {
av_log(avctx, AV_LOG_ERROR, "Error: cannot prepare encoder: %d\n",
status);
@@ -2891,6 +2901,8 @@ static const enum AVPixelFormat prores_pix_fmts[] = {
{ .i64 = -1 }, -1, 1, VE }, \
{ "power_efficient", "Set to 1 to enable more power-efficient encoding if
supported.", \
OFFSET(power_efficient), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 1, VE }, \
+{ "spatial_aq", "Set to 1 to enable spatial AQ if supported.", \
+OFFSET(spatialaq), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 1, VE }, \
{ "max_ref_frames", \
"Sets the maximum number of reference frames. This only has an effect
when the value is less than the maximum allowed by the profile/level.", \
OFFSET(max_ref_frames), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, VE
},
--
2.39.1.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".
Re: [FFmpeg-devel] [PATCH] lavc/videotoolboxenc: Add spatial_aq option
On Mon, 16 Dec 2024 at 03:17, Michael Niedermayer wrote: > This patch is corrupted by line breaks > > please make sure your editor and MUA dont break lines of patches > or use git send-email Seems Thunderbird broke it, will resubmit in a bit. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/6] Add more FATE tests for fragmented MP4
On 12/16/2024 12:46 PM, Tomas Härdin wrote: From f6d28d84413f2f674cfac86d4ed0868e8afb604b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tomas=20H=C3=A4rdin?= Date: Mon, 16 Dec 2024 16:15:47 +0100 Subject: [PATCH 5/6] Add more FATE tests for fragmented MP4 This tests the number of seeks performed when probing fmp4 with and without sidx Also add tests for the duration, which should be 10 minutes in both cases Use the same reference for both probe tests --- tests/fate/mov.mak| 9 +++ tests/ref/fate/mov-mfra | 1 + tests/ref/fate/mov-mfra-probe | 51 +++ tests/ref/fate/mov-sidx | 1 + 4 files changed, 62 insertions(+) create mode 100644 tests/ref/fate/mov-mfra create mode 100644 tests/ref/fate/mov-mfra-probe create mode 100644 tests/ref/fate/mov-sidx diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak index ca13ebfd44..3087a11cbc 100644 --- a/tests/fate/mov.mak +++ b/tests/fate/mov.mak @@ -284,6 +284,15 @@ fate-mov-mp4-iamf-ambisonic_1: CMD = transcode wav $(SRC) mp4 "-auto_conversion_ -streamid 0:0 -streamid 1:1 -streamid 2:2 -streamid 3:3 -map [MONO0] -map [MONO1] -map [MONO2] -map [MONO3] -c:a flac -t 1" "-c:a copy -map 0" \ "-show_entries stream_group=index,id,nb_streams,type:stream_group_components:stream_group_disposition:stream_group_tags:stream_group_stream=index,id:stream_group_stream_disposition" +FATE_MOV_FFPROBE-$(call ALLYES, MOV_DEMUXER FILE_PROTOCOL) += fate-mov-mfra fate-mov-sidx fate-mov-mfra-probe fate-mov-sidx-probe +fate-mov-mfra fate-mov-mfra-probe: SRC = $(TARGET_SAMPLES)/mov/frags-mfra.mp4 +fate-mov-sidx fate-mov-sidx-probe: SRC = $(TARGET_SAMPLES)/mov/frags-sidx.mp4 +fate-mov-mfra fate-mov-sidx: CMD = run ffprobe -loglevel debug -i $(SRC) 2>&1 | grep Statistics | sed -e "s/.*bytes read, //" +# share REF between both probe tests +# we want the same behavior regardless of whether sidx is present or not +fate-mov-mfra-probe fate-mov-sidx-probe: REF = tests/ref/fate/mov-mfra-probe This is not working. It complains about missing the reference file. Just remove the line altogether and let fate-mov-sidx-probe have its own reference file in the tree, even if it's the same. We do it for many other tests. Git compresses it anyway. +fate-mov-mfra-probe fate-mov-sidx-probe: CMD = run ffprobe -show_streams -i $(SRC) + FATE_FFMPEG += $(FATE_MOV_FFMPEG-yes) FATE_FFMPEG_FFPROBE += $(FATE_MOV_FFMPEG_FFPROBE-yes) diff --git a/tests/ref/fate/mov-mfra b/tests/ref/fate/mov-mfra new file mode 100644 index 00..299d3159ab --- /dev/null +++ b/tests/ref/fate/mov-mfra @@ -0,0 +1 @@ +6 seeks diff --git a/tests/ref/fate/mov-mfra-probe b/tests/ref/fate/mov-mfra-probe new file mode 100644 index 00..c07f72e0ec --- /dev/null +++ b/tests/ref/fate/mov-mfra-probe @@ -0,0 +1,51 @@ +[STREAM] +index=0 +codec_name=pcm_s16le +codec_long_name=PCM signed 16-bit little-endian +profile=unknown +codec_type=audio +codec_tag_string=ipcm +codec_tag=0x6d637069 +sample_fmt=s16 +sample_rate=44100 +channels=1 +channel_layout=unknown +bits_per_sample=16 +initial_padding=0 +id=0x1 +r_frame_rate=0/0 +avg_frame_rate=0/0 +time_base=1/44100 +start_pts=0 +start_time=0.00 +duration_ts=2646 +duration=600.00 +bit_rate=705600 +max_bit_rate=N/A +bits_per_raw_sample=N/A +nb_frames=31744 +nb_read_frames=N/A +nb_read_packets=N/A +DISPOSITION:default=1 +DISPOSITION:dub=0 +DISPOSITION:original=0 +DISPOSITION:comment=0 +DISPOSITION:lyrics=0 +DISPOSITION:karaoke=0 +DISPOSITION:forced=0 +DISPOSITION:hearing_impaired=0 +DISPOSITION:visual_impaired=0 +DISPOSITION:clean_effects=0 +DISPOSITION:attached_pic=0 +DISPOSITION:timed_thumbnails=0 +DISPOSITION:non_diegetic=0 +DISPOSITION:captions=0 +DISPOSITION:descriptions=0 +DISPOSITION:metadata=0 +DISPOSITION:dependent=0 +DISPOSITION:still_image=0 +DISPOSITION:multilayer=0 +TAG:language=und +TAG:handler_name=SoundHandler +TAG:vendor_id=[0][0][0][0] +[/STREAM] diff --git a/tests/ref/fate/mov-sidx b/tests/ref/fate/mov-sidx new file mode 100644 index 00..d24055e37b --- /dev/null +++ b/tests/ref/fate/mov-sidx @@ -0,0 +1 @@ +3 seeks -- 2.39.2 OpenPGP_signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] libavcodec/v4l2_buffers.c: set AVFrame interlaced flags
On 12/15/24 22:25, James Almer wrote:
On 12/15/2024 1:14 AM, Scott Theisen wrote:
Originally from:
https://github.com/MythTV/mythtv/commit/669955c6cb29196b4b5120451b5b998d67a65749
---
libavcodec/v4l2_buffers.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
index 23474ee143..56a8f0825c 100644
--- a/libavcodec/v4l2_buffers.c
+++ b/libavcodec/v4l2_buffers.c
@@ -210,6 +210,43 @@ static enum AVColorTransferCharacteristic
v4l2_get_color_trc(V4L2Buffer *buf)
return AVCOL_TRC_UNSPECIFIED;
}
+static void v4l2_get_interlacing(AVFrame *frame, V4L2Buffer *buf)
+{
+ enum v4l2_field field;
+ field = V4L2_TYPE_IS_MULTIPLANAR(buf->buf.type) ?
+ buf->context->format.fmt.pix_mp.field :
+ buf->context->format.fmt.pix.field;
+
+ if (field == V4L2_FIELD_INTERLACED || field ==
V4L2_FIELD_INTERLACED_TB) {
+ frame->flags |= AV_FRAME_FLAG_INTERLACED;
+ frame->flags |= AV_FRAME_FLAG_TOP_FIELD_FIRST;
+#if FF_API_INTERLACED_FRAME
+FF_DISABLE_DEPRECATION_WARNINGS
+ frame->interlaced_frame = 1;
+ frame->top_field_first = 1;
No need to set these two fields. It's done by the generic code.
OK, I'll remove those lines. Although it is not clear to me when those
will be set after libavcodec/pthread_frame.c calls
ff_decode_receive_frame_internal().
Regards,
Scott Theisen
___
ffmpeg-devel mailing list
ffmpeg-devel@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] libavcodec/v4l2_buffers.c: set AVFrame interlaced flags
On 12/16/2024 5:54 PM, Scott Theisen wrote:
On 12/16/24 15:25, James Almer wrote:
On 12/16/2024 5:05 PM, Scott Theisen wrote:
On 12/15/24 22:25, James Almer wrote:
On 12/15/2024 1:14 AM, Scott Theisen wrote:
Originally from:
https://github.com/MythTV/mythtv/
commit/669955c6cb29196b4b5120451b5b998d67a65749
---
libavcodec/v4l2_buffers.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
index 23474ee143..56a8f0825c 100644
--- a/libavcodec/v4l2_buffers.c
+++ b/libavcodec/v4l2_buffers.c
@@ -210,6 +210,43 @@ static enum AVColorTransferCharacteristic
v4l2_get_color_trc(V4L2Buffer *buf)
return AVCOL_TRC_UNSPECIFIED;
}
+static void v4l2_get_interlacing(AVFrame *frame, V4L2Buffer *buf)
+{
+ enum v4l2_field field;
+ field = V4L2_TYPE_IS_MULTIPLANAR(buf->buf.type) ?
+ buf->context->format.fmt.pix_mp.field :
+ buf->context->format.fmt.pix.field;
+
+ if (field == V4L2_FIELD_INTERLACED || field ==
V4L2_FIELD_INTERLACED_TB) {
+ frame->flags |= AV_FRAME_FLAG_INTERLACED;
+ frame->flags |= AV_FRAME_FLAG_TOP_FIELD_FIRST;
+#if FF_API_INTERLACED_FRAME
+FF_DISABLE_DEPRECATION_WARNINGS
+ frame->interlaced_frame = 1;
+ frame->top_field_first = 1;
No need to set these two fields. It's done by the generic code.
OK, I'll remove those lines. Although it is not clear to me when
those will be set after libavcodec/pthread_frame.c calls
ff_decode_receive_frame_internal().
They are set in decode_receive_frame_internal(), libavcodec/decode.c,
not too long before the frame is ultimately returned to the caller.
I saw that decode_receive_frame_internal() calls
ff_decode_receive_frame_internal() and then sets the flags, but
ff_decode_receive_frame_internal() is called directly in libavcodec/
pthread_frame.c.
It is not clear to me what calls decode_receive_frame_internal() to set
the flags after the call to ff_decode_receive_frame_internal() in
libavcodec/pthread_frame.c. However, if it is called at some point to
set the flags and it works, it works, so it is not really that
important, just that is was not obvious to me when it would be called.
It's a bit convoluted, but the contexts that are processed in
pthread_frame.c are workers and internal. All those frames are in the
end passed to the main thread and returned to the caller, a process that
will go through decode_receive_frame_internal().
OpenPGP_signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] libavcodec/v4l2_buffers.c: set AVFrame interlaced flags
On 12/16/2024 5:05 PM, Scott Theisen wrote:
On 12/15/24 22:25, James Almer wrote:
On 12/15/2024 1:14 AM, Scott Theisen wrote:
Originally from:
https://github.com/MythTV/mythtv/
commit/669955c6cb29196b4b5120451b5b998d67a65749
---
libavcodec/v4l2_buffers.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
index 23474ee143..56a8f0825c 100644
--- a/libavcodec/v4l2_buffers.c
+++ b/libavcodec/v4l2_buffers.c
@@ -210,6 +210,43 @@ static enum AVColorTransferCharacteristic
v4l2_get_color_trc(V4L2Buffer *buf)
return AVCOL_TRC_UNSPECIFIED;
}
+static void v4l2_get_interlacing(AVFrame *frame, V4L2Buffer *buf)
+{
+ enum v4l2_field field;
+ field = V4L2_TYPE_IS_MULTIPLANAR(buf->buf.type) ?
+ buf->context->format.fmt.pix_mp.field :
+ buf->context->format.fmt.pix.field;
+
+ if (field == V4L2_FIELD_INTERLACED || field ==
V4L2_FIELD_INTERLACED_TB) {
+ frame->flags |= AV_FRAME_FLAG_INTERLACED;
+ frame->flags |= AV_FRAME_FLAG_TOP_FIELD_FIRST;
+#if FF_API_INTERLACED_FRAME
+FF_DISABLE_DEPRECATION_WARNINGS
+ frame->interlaced_frame = 1;
+ frame->top_field_first = 1;
No need to set these two fields. It's done by the generic code.
OK, I'll remove those lines. Although it is not clear to me when those
will be set after libavcodec/pthread_frame.c calls
ff_decode_receive_frame_internal().
They are set in decode_receive_frame_internal(), libavcodec/decode.c,
not too long before the frame is ultimately returned to the caller.
OpenPGP_signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] libavcodec/v4l2_buffers.c: set AVFrame interlaced flags
On 12/16/24 15:25, James Almer wrote:
On 12/16/2024 5:05 PM, Scott Theisen wrote:
On 12/15/24 22:25, James Almer wrote:
On 12/15/2024 1:14 AM, Scott Theisen wrote:
Originally from:
https://github.com/MythTV/mythtv/
commit/669955c6cb29196b4b5120451b5b998d67a65749
---
libavcodec/v4l2_buffers.c | 38
++
1 file changed, 38 insertions(+)
diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
index 23474ee143..56a8f0825c 100644
--- a/libavcodec/v4l2_buffers.c
+++ b/libavcodec/v4l2_buffers.c
@@ -210,6 +210,43 @@ static enum AVColorTransferCharacteristic
v4l2_get_color_trc(V4L2Buffer *buf)
return AVCOL_TRC_UNSPECIFIED;
}
+static void v4l2_get_interlacing(AVFrame *frame, V4L2Buffer *buf)
+{
+ enum v4l2_field field;
+ field = V4L2_TYPE_IS_MULTIPLANAR(buf->buf.type) ?
+ buf->context->format.fmt.pix_mp.field :
+ buf->context->format.fmt.pix.field;
+
+ if (field == V4L2_FIELD_INTERLACED || field ==
V4L2_FIELD_INTERLACED_TB) {
+ frame->flags |= AV_FRAME_FLAG_INTERLACED;
+ frame->flags |= AV_FRAME_FLAG_TOP_FIELD_FIRST;
+#if FF_API_INTERLACED_FRAME
+FF_DISABLE_DEPRECATION_WARNINGS
+ frame->interlaced_frame = 1;
+ frame->top_field_first = 1;
No need to set these two fields. It's done by the generic code.
OK, I'll remove those lines. Although it is not clear to me when
those will be set after libavcodec/pthread_frame.c calls
ff_decode_receive_frame_internal().
They are set in decode_receive_frame_internal(), libavcodec/decode.c,
not too long before the frame is ultimately returned to the caller.
I saw that decode_receive_frame_internal() calls
ff_decode_receive_frame_internal() and then sets the flags, but
ff_decode_receive_frame_internal() is called directly in
libavcodec/pthread_frame.c.
It is not clear to me what calls decode_receive_frame_internal() to set
the flags after the call to ff_decode_receive_frame_internal() in
libavcodec/pthread_frame.c. However, if it is called at some point to
set the flags and it works, it works, so it is not really that
important, just that is was not obvious to me when it would be called.
Regards,
Scott Theisen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] configure: Include quotes around pkg_version
Since $pkg_version includes spaces, builds can fail in some MSYS environments.
Build passing with quotes:
https://github.com/JoeSchiff/pyav-ffmpeg/actions/runs/12358403929
Build failing without quotes:
https://github.com/JoeSchiff/pyav-ffmpeg/actions/runs/12360472377
Signed-off-by: Joe Schiffler
---
configure | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index bf55ba67fa..bb1263a8ce 100755
--- a/configure
+++ b/configure
@@ -1521,7 +1521,7 @@ test_pkg_config(){
funcs="$4"
shift 4
disable $name
-test_cmd $pkg_config --exists --print-errors $pkg_version || return
+test_cmd $pkg_config --exists --print-errors "$pkg_version" || return
pkg_cflags=$($pkg_config --cflags $pkg_config_flags $pkg)
pkg_libs=$($pkg_config --libs $pkg_config_flags $pkg)
pkg_incdir=$($pkg_config --variable=includedir $pkg_config_flags $pkg)
@@ -1541,7 +1541,7 @@ test_pkg_config_cpp(){
cond="$4"
shift 4
disable $name
-test_cmd $pkg_config --exists --print-errors $pkg_version || return
+test_cmd $pkg_config --exists --print-errors "$pkg_version" || return
pkg_cflags=$($pkg_config --cflags $pkg_config_flags $pkg)
pkg_incdir=$($pkg_config --variable=includedir $pkg_config_flags $pkg)
pkg_incflags=$($pkg_config --cflags-only-I $pkg_config_flags $pkg)
--
2.43.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] avcodec/frame: add AV_FRAME_FLAG_LOSSLESS
Quoting Marton Balint (2024-12-16 09:47:39) > > > On Mon, 16 Dec 2024, Anton Khirnov wrote: > > > Quoting Marton Balint (2024-12-15 01:02:42) > >> Signed-off-by: Marton Balint > >> --- > >> doc/APIchanges | 3 +++ > >> libavcodec/version.h | 2 +- > >> libavutil/frame.h| 4 > >> 3 files changed, 8 insertions(+), 1 deletion(-) > >> > >> diff --git a/doc/APIchanges b/doc/APIchanges > >> index 3a75b803a9..bfba0946d3 100644 > >> --- a/doc/APIchanges > >> +++ b/doc/APIchanges > >> @@ -2,6 +2,9 @@ The last version increases of all libraries were on > >> 2024-03-07 > >> > >> API changes, most recent first: > >> > >> +2024-12-xx - xx - lavc 61.27.100 - frame.h > >> + Add AV_FRAME_FLAG_LOSSLESS. > > > > I feel ambivalent about this. This is really a decoder property, and > > attaching it to frames allows it propagate far away to places where it > > makes no sense (the same holds for other existing AVFrame fields, but > > I'd prefer for them to be removed). > > The way this flag is set in patch 2 in the series kind of shows why this > is a per-frame property, directly originated from the bitstream of codecs > supporting both lossy and lossless encoding. The encoder for such codecs > is allowed to decide on a frame-by-frame basis if it will use lossy or > lossless encoding. I realize this can change per-frame, my point is that it's a per-frame property of the decoding process, not of the decoded frame itself. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] avcodec/frame: add AV_FRAME_FLAG_LOSSLESS
Hi On Mon, Dec 16, 2024 at 10:05:35AM +0100, Anton Khirnov wrote: > Quoting Marton Balint (2024-12-16 09:47:39) > > > > > > On Mon, 16 Dec 2024, Anton Khirnov wrote: > > > > > Quoting Marton Balint (2024-12-15 01:02:42) > > >> Signed-off-by: Marton Balint > > >> --- > > >> doc/APIchanges | 3 +++ > > >> libavcodec/version.h | 2 +- > > >> libavutil/frame.h| 4 > > >> 3 files changed, 8 insertions(+), 1 deletion(-) > > >> > > >> diff --git a/doc/APIchanges b/doc/APIchanges > > >> index 3a75b803a9..bfba0946d3 100644 > > >> --- a/doc/APIchanges > > >> +++ b/doc/APIchanges > > >> @@ -2,6 +2,9 @@ The last version increases of all libraries were on > > >> 2024-03-07 > > >> > > >> API changes, most recent first: > > >> > > >> +2024-12-xx - xx - lavc 61.27.100 - frame.h > > >> + Add AV_FRAME_FLAG_LOSSLESS. > > > > > > I feel ambivalent about this. This is really a decoder property, and > > > attaching it to frames allows it propagate far away to places where it > > > makes no sense (the same holds for other existing AVFrame fields, but > > > I'd prefer for them to be removed). > > > > The way this flag is set in patch 2 in the series kind of shows why this > > is a per-frame property, directly originated from the bitstream of codecs > > supporting both lossy and lossless encoding. The encoder for such codecs > > is allowed to decide on a frame-by-frame basis if it will use lossy or > > lossless encoding. > > I realize this can change per-frame, my point is that it's a per-frame > property of the decoding process, > not of the decoded frame itself. Thats not really true If you take a lossless decoded frame and a lossy decoded frame i mean just the 2d array of RGB samples you can tell them apart not only do they have different artifacts and statistics but fundamentally you will not be able to produce a lossy representation from a lossless 2d array of samples. (Because that would make the lossy compression lossless) Also there is a human user interrest in this. "is what i see here lossless?" There may even be a legal interrest in such things when a video is evidence Furthermore a encoder trying to preserve lossless frames needs to know what is lossless. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "Nothing to hide" only works if the folks in power share the values of you and everyone you know entirely and always will -- Tom Scott 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 14/14] avformat/rtmpproto: reserve enough space for statusmsg
On 16.12.2024 23:26, Michael Niedermayer wrote:
On Mon, Dec 16, 2024 at 08:44:54PM +0100, Timo Rothenpieler wrote:
On 15.12.2024 23:43, Michael Niedermayer wrote:
Hi
On Thu, Dec 12, 2024 at 08:55:39PM +0100, Timo Rothenpieler wrote:
---
libavformat/rtmpproto.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/rtmpproto.c b/libavformat/rtmpproto.c
index a56fec759f..a5e877cc55 100644
--- a/libavformat/rtmpproto.c
+++ b/libavformat/rtmpproto.c
@@ -2004,7 +2004,7 @@ static int send_invoke_response(URLContext *s, RTMPPacket
*pkt)
pp = spkt.data;
ff_amf_write_string(&pp, "onFCPublish");
} else if (!strcmp(command, "publish")) {
-char statusmsg[128];
+char statusmsg[160];
can you explain why this is enough and an example why the 128 was not
(not important but if you have that info it would make the comit message
more informative)
It's basically just the max size of the buffer that's written to it, plus
the size of the other stuff in the format string, plus a bit of padding.
would this merrit a
#define STATUS_MSG_MAX_SIZE 160 //the max size of the buffer that's written to
it, plus the size of the other stuff in the format string, plus a bit of
padding.
Seems a bit silly, but it could totaly be sizeof(buf) + 32.
___
ffmpeg-devel mailing list
ffmpeg-devel@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 14/14] avformat/rtmpproto: reserve enough space for statusmsg
On Mon, Dec 16, 2024 at 08:44:54PM +0100, Timo Rothenpieler wrote:
> On 15.12.2024 23:43, Michael Niedermayer wrote:
> > Hi
> >
> > On Thu, Dec 12, 2024 at 08:55:39PM +0100, Timo Rothenpieler wrote:
> > > ---
> > > libavformat/rtmpproto.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/libavformat/rtmpproto.c b/libavformat/rtmpproto.c
> > > index a56fec759f..a5e877cc55 100644
> > > --- a/libavformat/rtmpproto.c
> > > +++ b/libavformat/rtmpproto.c
> > > @@ -2004,7 +2004,7 @@ static int send_invoke_response(URLContext *s,
> > > RTMPPacket *pkt)
> > > pp = spkt.data;
> > > ff_amf_write_string(&pp, "onFCPublish");
> > > } else if (!strcmp(command, "publish")) {
> > > -char statusmsg[128];
> > > +char statusmsg[160];
> >
> > can you explain why this is enough and an example why the 128 was not
> > (not important but if you have that info it would make the comit message
> > more informative)
>
> It's basically just the max size of the buffer that's written to it, plus
> the size of the other stuff in the format string, plus a bit of padding.
would this merrit a
#define STATUS_MSG_MAX_SIZE 160 //the max size of the buffer that's written to
it, plus the size of the other stuff in the format string, plus a bit of
padding.
?
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Any man who breaks a law that conscience tells him is unjust and willingly
accepts the penalty by staying in jail in order to arouse the conscience of
the community on the injustice of the law is at that moment expressing the
very highest respect for law. - Martin Luther King Jr
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 0/3] Make fate tests succeed with zlib-ng
On 12/16/24 7:20 AM, Michael Niedermayer wrote: Hi On Sat, Dec 14, 2024 at 11:09:00AM +0100, Anton Khirnov wrote: Quoting Alexander Strasser via ffmpeg-devel (2024-12-01 21:13:56) This is a fixed up version of the series I sent before. This worked for me on Ubuntu 20.04 but probably will break with older zlib versions as Hendrik pointed out in the previous thread. Either we must update zlib on affected FATE clients or add more .alt files to them as well. We could also go the further the "no_file_checksums" as was demonstrated by James' series. I still prefer this way because it's simpler and retains the value of the tests. [...] We should not be testing for bitexact output from code that is not under our control and does not guarantee bitexactness. This is a odd statement, why is there "code that is not under our control" as a condition ? As far as I understand the issue in this case is that we do not have an internal zlib encoder, we just call zlib to encode for example PNG files. Even if two different versions/editions/etc. of zlib produce correct DEFLATEd blobs that decode to the same bits, that doesn't mean the blobs themselves are guaranteed to match bit-for-bit. However, we're comparing the checksums of what are essentially gzipped files, which can be thrown off by differences in the zlib encoder. Those minor differences are outside of our control as it's an external library. Essentially, we shouldn't be having FATE failures depend on the specific behavior of whatever zlib we link to, provided it's correct. DEFLATE promises certain things about its encodes, but one of the things DEFLATE does not promise is that the same uncompressed data always encodes to the same compressed data. When we check the CRC of e.g. PNG files, we erroneously assume this, and we just basically never got called on it because nearly every system uses a recent version of stock zlib. Anton is basically saying that if we want to compare the CRC of zlib output, trying to compile a list of different zlib versions and making reference files of each one doesn't really solve the underlying problem, and it's kind of hacky. Solutions I can think of to this problem that solve it forever would be to (a): not compare the checksums of encoded files with zlib chunks OR (b): have some sort of tool that decodes relevant zlib chunks and then run a checksum on its output However, (b) is much more complicated and probably not worth the effort. - Leo Izen (Traneptora) ___ ffmpeg-devel mailing list ffmpeg-devel@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] swscale/slice: fix init of 32 bpc planes
Hi On Mon, Dec 16, 2024 at 11:40:50AM +0100, Niklas Haas wrote: > On Mon, 16 Dec 2024 01:50:20 +0100 Michael Niedermayer > wrote: > > Hi Niklas > > > > On Wed, Dec 11, 2024 at 09:25:12AM +0100, Niklas Haas wrote: > > > From: Niklas Haas > > > > > > In input.c and output.c and many other places, swscale follows the rule > > > of using > > > 15-bit intermediate if output bpc is <= 8, and 19-bit (inside int32_t) > > > intermediate otherwise. See e.g. the comments on hyScale() on > > > swscale_internal.h. These are also the coefficients that > > > yuv2gbrpf32_full_X_c() > > > is using. > > > > > > In contrast to this, the plane init code in slice.c (function fill_ones) > > > is > > > assuming that we use 35-bit intermediates (inside 64-bit integers) for > > > this > > > case, seemingly added by commit b4967fc71c63eae8cd96f9c46cd3e1fbd705bbf9 > > > with > > > no further justification. > > > > > > This causes a mismatch whenever the implicitly initialized plane contents > > > leak > > > out to the output, e.g. when converting from grayscale to RGB. > > > > > > Fixes: ticket #10716 > > > Signed-off-by: Niklas Haas > > > Sponsored-by: Sovereign Tech Fund > > > --- > > > libswscale/slice.c | 6 +- > > > 1 file changed, 1 insertion(+), 5 deletions(-) > > > > ultimately 32bit on teh input or output side require more than 32bit > > internally to maintain precission. > > > > if this patch makes it all match up, its ok for now but 18bit dont seem > > enough for 32bit data > > What exactly is the design goal here? As a point of reference, here is how > many Make the user happy :) > bits you need to represent a signal to within an error that is substantially > below the threshold of human perception in all but the most extreme synthetic > test setups: > > - HDR before linearization: 14 bits > - HDR after linearization: 35 bits > - SDR before linearization: 12 bits > - SDR after linearization: 26 bits > > If we relax this to the threshold that is required for visual transparency in > (non-static) video playback, we get: > > - HDR before linearization: 12 bits > - HDR after linearization: 30 bits > - SDR before linearization: 10 bits > - SDR after linearization: 22 bits what about image material from scientific instruments ? The question here is not if a human can see it with unadjusted contrast, but the existing precission should still be preserved thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB z(9) = an object that transcends all computable functions describable in finite terms. - ChatGPT in 2024 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] libavcodec/v4l2: use libdrm
On 12/15/24 22:15, Zhao Zhili wrote:
On Dec 15, 2024, at 12:14, Scott Theisen wrote:
Based on patches by Lukas Rusak from
https://github.com/lrusak/FFmpeg/commits/v4l2-drmprime-v4
libavcodec: v4l2m2m: output AVDRMFrameDescriptor
https://github.com/lrusak/FFmpeg/commit/2cb8052ac65a56d8a3f347a1e6f12d4449a5a614
libavcodec: v4l2m2m: depends on libdrm
https://github.com/lrusak/FFmpeg/commit/ab4cf3e6fb37cffdebccca52e36a7b2deb7e729f
libavcodec: v4l2m2m: set format_modifier to DRM_FORMAT_MOD_LINEAR
https://github.com/lrusak/FFmpeg/commit/9438a6efa29c7c7ec80c39c9b013b9a12d7b5f33
libavcodec: v4l2m2m: only mmap the buffer when it is output type and drm prime
is used
https://github.com/lrusak/FFmpeg/commit/093656607863e47630de2d1cfcf0ac8e4b93a69e
libavcodec: v4l2m2m: allow using software pixel formats
https://github.com/lrusak/FFmpeg/commit/8405b573e83838e6b2fea99825fbef32ee9f7767
libavcodec: v4l2m2m: implement hwcontext
https://github.com/lrusak/FFmpeg/commit/b2c1f1eb39b54bf034497a7f2a7f23855d0a7cde
libavcodec: v4l2m2m: implement flush
https://github.com/lrusak/FFmpeg/commit/e793ef82727d6d6f55c40844463d476e7e84efad
Originally added to MythTV in:
FFmpeg: Patch FFmpeg for V4L2 codecs DRM PRIME support
https://github.com/MythTV/mythtv/commit/cc7572f9b26189ad5d5d504c05f08e53e4e61b54
FFmpeg: Re-apply v4l2 memory to memory DRM_PRIME support
https://github.com/MythTV/mythtv/commit/1c942720591b5b7820abe9ed0d805afabbdffe3c
modified in:
V4L2 Codecs: Fix lockup when seeking
https://github.com/MythTV/mythtv/commit/fdc0645aba9a9ad373888bd62ebcbc83a3feb7e5
v4l2_buffers: Add some libdrm ifdef's
https://github.com/MythTV/mythtv/commit/336df1067abfa4fe7cf611541e5b6f3561fc81a2
NB: libavcodec/v4l2_m2m_dec.c: v4l2_decode_init(): I'm returning -1
since I don't know what error code I should use.
Note also Lucas Rusak's v5 series:
closer diff to current state, otherwise unchanged
libavcodec: v4l2m2m: output AVDRMFrameDescriptor
https://github.com/lrusak/FFmpeg/commit/c6b85ed30f06ea99513b13cc768a922ebe4d68c2
new option:
libavcodec: v4l2m2m: add option to specify pixel format used by the decoder
https://github.com/lrusak/FFmpeg/commit/ffc4419f456c00ab71cf93f792b0473c6de14e64
additional code vs v4
libavcodec: v4l2m2m: implement flush
https://github.com/lrusak/FFmpeg/commit/8595d06d4909bbec0aa14625fcfc869c6bcef696
---
configure | 1 +
libavcodec/v4l2_buffers.c | 206 +++---
libavcodec/v4l2_buffers.h | 4 +
libavcodec/v4l2_context.c | 43 +++-
libavcodec/v4l2_context.h | 2 +
libavcodec/v4l2_m2m.h | 5 +
libavcodec/v4l2_m2m_dec.c | 62
7 files changed, 305 insertions(+), 18 deletions(-)
diff --git a/configure b/configure
index bf55ba67fa..5f02cf3b51 100755
--- a/configure
+++ b/configure
@@ -3770,6 +3770,7 @@ sndio_indev_deps="sndio"
sndio_outdev_deps="sndio"
v4l2_indev_deps_any="linux_videodev2_h sys_videoio_h"
v4l2_indev_suggest="libv4l2"
+v4l2_outdev_deps="libdrm"
Why v4l2_outdev when the patch is for libavcodec?
Lukas Rusak appears to have only submitted up to v3 of his patches in 2018.
This appears to be from a comment in
https://patchwork.ffmpeg.org/project/ffmpeg/patch/4bbeff66-6123-9296-5775-96d75809e...@jkqxz.net/
However, with the `#if CONFIG_LIBDRM`s added by Mark Kendall for MythTV,
I don't think it is a hard dependency.
...
diff --git a/libavcodec/v4l2_m2m_dec.c b/libavcodec/v4l2_m2m_dec.c
index aa2d759e1e..cfeee7f2fb 100644
--- a/libavcodec/v4l2_m2m_dec.c
+++ b/libavcodec/v4l2_m2m_dec.c
@@ -23,12 +23,17 @@
#include
#include
+
+#include "libavutil/hwcontext.h"
+#include "libavutil/hwcontext_drm.h"
#include "libavutil/pixfmt.h"
#include "libavutil/pixdesc.h"
#include "libavutil/opt.h"
#include "libavcodec/avcodec.h"
#include "codec_internal.h"
#include "libavcodec/decode.h"
+#include "libavcodec/internal.h"
+#include "libavcodec/hwconfig.h"
#include "v4l2_context.h"
#include "v4l2_m2m.h"
@@ -205,7 +210,44 @@ static av_cold int v4l2_decode_init(AVCodecContext *avctx)
capture->av_codec_id = AV_CODEC_ID_RAWVIDEO;
capture->av_pix_fmt = avctx->pix_fmt;
+/* the client requests the codec to generate DRM frames:
+ * - data[0] will therefore point to the returned AVDRMFrameDescriptor
+ * check the ff_v4l2_buffer_to_avframe conversion function.
+ * - the DRM frame format is passed in the DRM frame descriptor layer.
+ * check the v4l2_get_drm_frame function.
+ */
+{
+const enum AVPixelFormat *pix_fmts = NULL;
+int num_pix_fmts = 0;
+ret = avcodec_get_supported_config(avctx, NULL, AV_CODEC_CONFIG_PIX_FORMAT,
+ 0, (const void **) &pix_fmts,
&num_pix_fmts);
I don’t think here is the meant use case for avcodec_get_supported_config.
Specify available pixel format directly in pix_fmts.
+if (ret < 0)
+return ret;
+if (pix_fmts == NULL || num_pix_fmts < 1)
+return -1;
There is no which error code to use iss
Re: [FFmpeg-devel] [PATCH v2 0/3] Make fate tests succeed with zlib-ng
Hi On Mon, Dec 16, 2024 at 05:39:22PM -0500, Leo Izen wrote: [...] > Essentially, we shouldn't be having FATE failures agree > depend on the specific > behavior of whatever zlib we link to, provided it's correct. > DEFLATE > promises certain things about its encodes, but one of the things DEFLATE > does not promise is that the same uncompressed data always encodes to the > same compressed data. When we check the CRC of e.g. PNG files, we > erroneously assume this, and we just basically never got called on it > because nearly every system uses a recent version of stock zlib. > > Anton is basically saying that if we want to compare the CRC of zlib output, > trying to compile a list of different zlib versions and making reference > files of each one doesn't really solve the underlying problem, and it's kind > of hacky. > > Solutions I can think of to this problem that solve it forever would be to > (a): not compare the checksums of encoded files with zlib chunks > OR > (b): have some sort of tool that decodes relevant zlib chunks and then run a > checksum on its output (c): implement enough of zlib ourselfs, so it can encode to a valid output (d): Find a input that encodes identically with all existing zlib variants (e): Find a input that encodes to max 2 variants and store 2 checksums I dont think (e) is the best solution, but if it works for all cases, my point is, that it is a valid solution thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Does the universe only have a finite lifespan? No, its going to go on forever, its just that you wont like living in it. -- Hiranya Peiri 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 14/14] avformat/rtmpproto: reserve enough space for statusmsg
On Mon, Dec 16, 2024 at 11:29:11PM +0100, Timo Rothenpieler wrote:
> On 16.12.2024 23:26, Michael Niedermayer wrote:
> > On Mon, Dec 16, 2024 at 08:44:54PM +0100, Timo Rothenpieler wrote:
> > > On 15.12.2024 23:43, Michael Niedermayer wrote:
> > > > Hi
> > > >
> > > > On Thu, Dec 12, 2024 at 08:55:39PM +0100, Timo Rothenpieler wrote:
> > > > > ---
> > > > >libavformat/rtmpproto.c | 2 +-
> > > > >1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/libavformat/rtmpproto.c b/libavformat/rtmpproto.c
> > > > > index a56fec759f..a5e877cc55 100644
> > > > > --- a/libavformat/rtmpproto.c
> > > > > +++ b/libavformat/rtmpproto.c
> > > > > @@ -2004,7 +2004,7 @@ static int send_invoke_response(URLContext *s,
> > > > > RTMPPacket *pkt)
> > > > >pp = spkt.data;
> > > > >ff_amf_write_string(&pp, "onFCPublish");
> > > > >} else if (!strcmp(command, "publish")) {
> > > > > -char statusmsg[128];
> > > > > +char statusmsg[160];
> > > >
> > > > can you explain why this is enough and an example why the 128 was not
> > > > (not important but if you have that info it would make the comit message
> > > > more informative)
> > >
> > > It's basically just the max size of the buffer that's written to it, plus
> > > the size of the other stuff in the format string, plus a bit of padding.
> >
> > would this merrit a
> > #define STATUS_MSG_MAX_SIZE 160 //the max size of the buffer that's written
> > to it, plus the size of the other stuff in the format string, plus a bit of
> > padding.
>
> Seems a bit silly, but it could totaly be sizeof(buf) + 32.
ok
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.
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] swscale: use 16-bit intermediate precision for RGB/XYZ conversion
Hi On Mon, Dec 16, 2024 at 02:56:07PM +0100, Niklas Haas wrote: > From: Niklas Haas > > The current logic uses 12-bit linear light math, which is woefully > insufficient > and leads to nasty postarization artifacts. This patch simply switches the > internal logic to 16-bit precision. > > This raises the memory requirement of these tables from 32 kB to 272 kB. > > Fixes: ticket 4829 > Signed-off-by: Niklas Haas > Sponsored-by: Sovereign Tech Fund > --- > libswscale/swscale.c | 16 > libswscale/swscale_internal.h | 8 > libswscale/utils.c| 19 --- > 3 files changed, 24 insertions(+), 19 deletions(-) breaks fate TESTfilter-pixdesc-xyz12be --- ./tests/ref/fate/filter-pixdesc-xyz12be 2024-11-29 20:32:49.757718063 +0100 +++ tests/data/fate/filter-pixdesc-xyz12be 2024-12-17 00:34:49.832342280 +0100 @@ -1 +1 @@ -pixdesc-xyz12be 4ec824668b9753e26c1bccffca866e27 +pixdesc-xyz12be 1508a33dea936c45d9ee13f7743af00d Test filter-pixdesc-xyz12be failed. Look at tests/data/fate/filter-pixdesc-xyz12be.err for details. make: *** [tests/Makefile:311: fate-filter-pixdesc-xyz12be] Error 1 thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway 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] d3d12va_encode_hevc: use base to init VPS/SPS/PPS
>From: ffmpeg-devel On Behalf Of Tong >Wu >To: FFmpeg development discussions and patches de...@ffmpeg.org> >Subject: Re: [FFmpeg-devel] [PATCH] d3d12va_encode_hevc: use base to init >VPS/SPS/PPS > >>From: ffmpeg-devel On Behalf Of Tong >>Wu >>To: ffmpeg-devel@ffmpeg.org >>Subject: [FFmpeg-devel] [PATCH] d3d12va_encode_hevc: use base to init >>VPS/SPS/PPS >> >>Patch attached. >> >>Tong > >Ping. Will apply if there's no more comment on this patch > Applied, thx ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/6] lavf/mov: Read duration when parsing mfra
Hopefully I got the calls to mov_switch_root() right.
mov_read_default() just ends up calling mov_read_moof() twice on the
first moof
/Tomas
From bbcff7581177b25b03e0f53ebb4732b7f10f0616 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Mon, 16 Dec 2024 15:25:44 +0100
Subject: [PATCH 2/6] lavf/mov: Read duration when parsing mfra
Without this mov files with mfra do not have the correct duration set.
Without sidx present we must read the last fragment header, which this patch does.
---
libavformat/mov.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index cfcd64b7db..98a05e8411 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1800,6 +1800,8 @@ static void fix_frag_index_entries(MOVFragmentIndex *frag_index, int index,
}
}
+static int mov_switch_root(AVFormatContext *s, int64_t target, int index);
+
static int mov_read_moof(MOVContext *c, AVIOContext *pb, MOVAtom atom)
{
// Set by mov_read_tfhd(). mov_read_trun() will reject files missing tfhd.
@@ -1814,6 +1816,15 @@ static int mov_read_moof(MOVContext *c, AVIOContext *pb, MOVAtom atom)
if ((ret = mov_read_mfra(c, pb)) < 0) {
av_log(c->fc, AV_LOG_VERBOSE, "found a moof box but failed to "
"read the mfra (may be a live ismv)\n");
+} else if (c->frag_index.nb_items > 0) {
+// switch to the last fragment so that duration gets set during probe
+// we don't get here during probing if sidx is present
+int ret = mov_switch_root(c->fc, -1, c->frag_index.nb_items-1);
+if (ret < 0)
+return ret;
+// switch back to this moof, seeking to the start of it
+// this causes mov_read_default() to call us again
+return mov_switch_root(c->fc, -1, 0);
}
} else {
av_log(c->fc, AV_LOG_VERBOSE, "found a moof box but stream is not "
--
2.39.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 4/6] lavf/mov: Do not set bit_rate unless all fragment headers have been read
Without this we get a bogus bitrate whenever we rely on mfra
With this patch we could potentially drop -use_mfra_for
/Tomas
From 7484bb3b83e23b152e1cabb7b00bdceff0a217e2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Mon, 16 Dec 2024 16:15:10 +0100
Subject: [PATCH 4/6] lavf/mov: Do not set bit_rate unless all fragment headers
have been read
---
libavformat/mov.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 58481747e4..7ab4a4b233 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -10521,7 +10521,7 @@ static int mov_read_header(AVFormatContext *s)
AVIOContext *pb = s->pb;
int j, err;
MOVAtom atom = { AV_RL32("root") };
-int i;
+int i, all_headers_read;
if (mov->decryption_key_len != 0 && mov->decryption_key_len != AES_CTR_KEY_SIZE) {
av_log(s, AV_LOG_ERROR, "Invalid decryption key len %d expected %d\n",
@@ -10651,7 +10651,17 @@ static int mov_read_header(AVFormatContext *s)
}
}
-if (mov->trex_data || mov->use_mfra_for > 0) {
+// if we have fragments, check that all of them have been parsed, especially trun
+// if not then sc->data_size will be incorrect and therefore bit_rate
+all_headers_read = 1;
+for (i = 0; i < mov->frag_index.nb_items; i++) {
+if (!mov->frag_index.item[i].headers_read) {
+all_headers_read = 0;
+break;
+}
+}
+
+if ((mov->trex_data || mov->use_mfra_for > 0) && all_headers_read) {
for (i = 0; i < s->nb_streams; i++) {
AVStream *st = s->streams[i];
MOVStreamContext *sc = st->priv_data;
--
2.39.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 6/6] lavf/movenc: Write version 0 (32-bit) traf if possible
From 2698fc4b53e482adfe09781d90aa936a567524aa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Mon, 16 Dec 2024 14:15:12 +0100
Subject: [PATCH 6/6] lavf/movenc: Write version 0 (32-bit) traf if possible
This results in smaller files.
Update fate-movenc accordingly.
---
libavformat/movenc.c | 22 +--
tests/ref/fate/movenc | 90 +--
2 files changed, 63 insertions(+), 49 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 76dce9e6e5..e314789831 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -5754,19 +5754,33 @@ static int mov_write_moof_tag(AVIOContext *pb, MOVMuxContext *mov, int tracks,
static int mov_write_tfra_tag(AVIOContext *pb, MOVTrack *track)
{
int64_t pos = avio_tell(pb);
-int i;
+int i, version = 0;
+
+// figure out if we can get away with writing version 0 traf
+for (i = 0; i < track->nb_frag_info; i++) {
+if (track->frag_info[i].time >= UINT32_MAX ||
+track->frag_info[i].offset + track->data_offset >= UINT32_MAX) {
+version = 1;
+break;
+}
+}
avio_wb32(pb, 0); /* size placeholder */
ffio_wfourcc(pb, "tfra");
-avio_w8(pb, 1); /* version */
+avio_w8(pb, version); /* version */
avio_wb24(pb, 0);
avio_wb32(pb, track->track_id);
avio_wb32(pb, 0); /* length of traf/trun/sample num */
avio_wb32(pb, track->nb_frag_info);
for (i = 0; i < track->nb_frag_info; i++) {
-avio_wb64(pb, track->frag_info[i].time);
-avio_wb64(pb, track->frag_info[i].offset + track->data_offset);
+if (version) {
+avio_wb64(pb, track->frag_info[i].time);
+avio_wb64(pb, track->frag_info[i].offset + track->data_offset);
+} else {
+avio_wb32(pb, track->frag_info[i].time);
+avio_wb32(pb, track->frag_info[i].offset + track->data_offset);
+}
avio_w8(pb, 1); /* traf number */
avio_w8(pb, 1); /* trun number */
avio_w8(pb, 1); /* sample number */
diff --git a/tests/ref/fate/movenc b/tests/ref/fate/movenc
index 5c12aeb29f..00f28ff19d 100644
--- a/tests/ref/fate/movenc
+++ b/tests/ref/fate/movenc
@@ -1,113 +1,113 @@
write_data len 36, time nopts, type header atom ftyp
write_data len 2429, time nopts, type header atom -
write_data len 788, time 100, type sync atom moof
-write_data len 110, time nopts, type trailer atom -
-6f06e338c71468d56580df40ff265066 3363 non-empty-moov
+write_data len 94, time nopts, type trailer atom -
+57f2641b843f925b10d22258bb8d50d2 3347 non-empty-moov
write_data len 36, time nopts, type header atom ftyp
write_data len 2761, time nopts, type header atom -
write_data len 908, time 97, type sync atom moof
-write_data len 110, time nopts, type trailer atom -
-9d260d424e9de4626163fd25ccce5bab 3815 non-empty-moov-elst
+write_data len 94, time nopts, type trailer atom -
+44488b769213b195d98e20abebf9fd02 3799 non-empty-moov-elst
write_data len 36, time nopts, type header atom ftyp
write_data len 2669, time nopts, type header atom -
write_data len 908, time 100, type sync atom moof
-write_data len 110, time nopts, type trailer atom -
-e106084014ed245ed7c4a30f1d11a3ac 3723 non-empty-moov-no-elst
+write_data len 94, time nopts, type trailer atom -
+fdcee49342d605bd133be9765d60cbfe 3707 non-empty-moov-no-elst
write_data len 24, time nopts, type header atom ftyp
write_data len 1171, time nopts, type header atom -
write_data len 728, time 0, type sync atom moof
write_data len 828, time nopts, type unknown atom -
write_data len 728, time 99, type sync atom moof
write_data len 812, time nopts, type unknown atom -
-write_data len 148, time nopts, type trailer atom -
-d2df24d323f4a8896441cd91203ac5f8 4439 ismv
+write_data len 116, time nopts, type trailer atom -
+930ffc74124ac367932fdd3a2582d09e 4407 ismv
write_data len 36, time nopts, type header atom ftyp
write_data len 1123, time nopts, type header atom -
write_data len 796, time 0, type sync atom moof
write_data len 788, time 100, type sync atom moof
-write_data len 148, time nopts, type trailer atom -
-08f4b3ad3a3ea224b2ee731476b9056b 2891 empty-moov
+write_data len 116, time nopts, type trailer atom -
+834a4d0b6269951b6577ccde6cef63eb 2859 empty-moov
write_data len 36, time nopts, type header atom ftyp
write_data len 1123, time nopts, type header atom -
write_data len 1068, time 0, type sync atom moof
write_data len 908, time 100, type sync atom moof
-write_data len 148, time nopts, type trailer atom -
-d7a2dcb43eb0f95f92669f55fc7adeba 3283 empty-moov-no-elst
+write_data len 116, time nopts, type trailer atom -
+3e2f75d3b03abab012df9faae2fe1321 3251 empty-moov-no-elst
write_data len 36, time nopts, type header atom ftyp
write_data len 1123, time nopts, type header atom -
write_data len 900, time -3, type sync atom moof
write_data len 908, time 97, type sync atom moof
-writ
[FFmpeg-devel] [PATCH 1/6] lavf/mov: Always try to parse mfra if file contains moof boxes
Updated patchset. Patches 1-2 could maybe be squashed
The end result of these patches is that fragmented files probe much
faster over HTTP. The final patch is just a small optimization to
movenc
/Tomas
From 357be61ac65149b826769c07a7a3dbb7af7164db Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Wed, 11 Dec 2024 13:42:36 +0100
Subject: [PATCH 1/6] lavf/mov: Always try to parse mfra if file contains moof
boxes
If the demuxer succeeds it will set c->frag_index.complete which will enable mov_read_default() to stop earlier.
This is useful for reducing the number of seeks in fragmented MP4 files.
---
libavformat/mov.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 3820983a5d..cfcd64b7db 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1805,7 +1805,7 @@ static int mov_read_moof(MOVContext *c, AVIOContext *pb, MOVAtom atom)
// Set by mov_read_tfhd(). mov_read_trun() will reject files missing tfhd.
c->fragment.found_tfhd = 0;
-if (!c->has_looked_for_mfra && c->use_mfra_for > 0) {
+if (!c->has_looked_for_mfra) {
c->has_looked_for_mfra = 1;
if (pb->seekable & AVIO_SEEKABLE_NORMAL) {
int ret;
--
2.39.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/6] lavf/mov: Parse and verify the whole mfro box
This avoid a seek on some files that might accidentally have a
seemingly valid mfra offset
/Tomas
From 23f1ddc8ae4064f6d03efd54fb9da5ca9fc450ae Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Wed, 11 Dec 2024 14:56:31 +0100
Subject: [PATCH 3/6] lavf/mov: Parse and verify the whole mfro box
---
libavformat/mov.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 98a05e8411..58481747e4 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -10028,11 +10028,31 @@ static int mov_read_mfra(MOVContext *c, AVIOContext *f)
int64_t stream_size = avio_size(f);
int64_t original_pos = avio_tell(f);
int64_t seek_ret;
+uint32_t mfro_size, mfro_version, mfro_flags;
int ret = -1;
-if ((seek_ret = avio_seek(f, stream_size - 4, SEEK_SET)) < 0) {
+
+// be picky with the mfro box so we don't perform unnecessary seeks
+if ((seek_ret = avio_seek(f, stream_size - 16, SEEK_SET)) < 0) {
ret = seek_ret;
goto fail;
}
+if ((mfro_size = avio_rb32(f)) != 16) {
+av_log(c->fc, AV_LOG_DEBUG, "incorrect mfro size: %u\n", mfro_size);
+goto fail;
+}
+if (avio_rb32(f) != MKBETAG('m', 'f', 'r', 'o')) {
+av_log(c->fc, AV_LOG_DEBUG, "no mfro box\n");
+goto fail;
+}
+if ((mfro_version = avio_r8(f)) != 0) {
+av_log(c->fc, AV_LOG_DEBUG, "unsupported mfro version: %u\n", mfro_version);
+goto fail;
+}
+if ((mfro_flags = avio_rb24(f)) != 0) {
+av_log(c->fc, AV_LOG_DEBUG, "incorrect mfro flags: %x\n", mfro_flags);
+goto fail;
+}
+
c->mfra_size = avio_rb32(f);
c->have_read_mfra_size = 1;
if (!c->mfra_size || c->mfra_size > stream_size) {
--
2.39.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 0/3] Make fate tests succeed with zlib-ng
Hi On Sat, Dec 14, 2024 at 11:09:00AM +0100, Anton Khirnov wrote: > Quoting Alexander Strasser via ffmpeg-devel (2024-12-01 21:13:56) > > This is a fixed up version of the series I sent before. > > > > This worked for me on Ubuntu 20.04 but probably will break > > with older zlib versions as Hendrik pointed out in the > > previous thread. Either we must update zlib on affected > > FATE clients or add more .alt files to them as well. > > > > We could also go the further the "no_file_checksums" as > > was demonstrated by James' series. > > > > I still prefer this way because it's simpler and retains > > the value of the tests. > [...] > > We should not be testing for bitexact output from code that is not under > our control and does not guarantee bitexactness. This is a odd statement, why is there "code that is not under our control" as a condition ? Without that you would have this: "We should not be testing for bitexact output from code that does not guarantee bitexactness." (which is a much cleaner statement) Does that mean that you want to have tests for bitexact output from code that does not guarantee bitexactness, as long as it is under our control ? IMHO We should fully test our code to the maximum it can be reliably&reproducably tested exceptions can be anything that has real world cost (maintaince burden, maintainer happyness or (time, space, memory)) But tests should not be rejected based on some condition that has no real world benefit Thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] swscale: use 16-bit intermediate precision for RGB/XYZ conversion
From: Niklas Haas
The current logic uses 12-bit linear light math, which is woefully insufficient
and leads to nasty postarization artifacts. This patch simply switches the
internal logic to 16-bit precision.
This raises the memory requirement of these tables from 32 kB to 272 kB.
Fixes: ticket 4829
Signed-off-by: Niklas Haas
Sponsored-by: Sovereign Tech Fund
---
libswscale/swscale.c | 16
libswscale/swscale_internal.h | 8
libswscale/utils.c| 19 ---
3 files changed, 24 insertions(+), 19 deletions(-)
diff --git a/libswscale/swscale.c b/libswscale/swscale.c
index 96634acfd6..da3a082905 100644
--- a/libswscale/swscale.c
+++ b/libswscale/swscale.c
@@ -773,10 +773,10 @@ void ff_xyz12Torgb48(const SwsInternal *c, uint8_t *dst,
int dst_stride,
c->xyz2rgb_matrix[2][1] * y +
c->xyz2rgb_matrix[2][2] * z >> 12;
-// limit values to 12-bit depth
-r = av_clip_uintp2(r, 12);
-g = av_clip_uintp2(g, 12);
-b = av_clip_uintp2(b, 12);
+// limit values to 16-bit depth
+r = av_clip_uint16(r);
+g = av_clip_uint16(g);
+b = av_clip_uint16(b);
// convert from sRGBlinear to RGB and scale from 12bit to 16bit
if (desc->flags & AV_PIX_FMT_FLAG_BE) {
@@ -832,10 +832,10 @@ void ff_rgb48Toxyz12(const SwsInternal *c, uint8_t *dst,
int dst_stride,
c->rgb2xyz_matrix[2][1] * g +
c->rgb2xyz_matrix[2][2] * b >> 12;
-// limit values to 12-bit depth
-x = av_clip_uintp2(x, 12);
-y = av_clip_uintp2(y, 12);
-z = av_clip_uintp2(z, 12);
+// limit values to 16-bit depth
+x = av_clip_uint16(x);
+y = av_clip_uint16(y);
+z = av_clip_uint16(z);
// convert from XYZlinear to X'Y'Z' and scale from 12bit to 16bit
if (desc->flags & AV_PIX_FMT_FLAG_BE) {
diff --git a/libswscale/swscale_internal.h b/libswscale/swscale_internal.h
index 768e394560..5acd277b50 100644
--- a/libswscale/swscale_internal.h
+++ b/libswscale/swscale_internal.h
@@ -547,10 +547,10 @@ struct SwsInternal {
/* pre defined color-spaces gamma */
#define XYZ_GAMMA (2.6f)
#define RGB_GAMMA (2.2f)
-int16_t *xyzgamma;
-int16_t *rgbgamma;
-int16_t *xyzgammainv;
-int16_t *rgbgammainv;
+uint16_t *xyzgamma;
+uint16_t *rgbgamma;
+uint16_t *xyzgammainv;
+uint16_t *rgbgammainv;
int16_t xyz2rgb_matrix[3][4];
int16_t rgb2xyz_matrix[3][4];
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 4dedbfc394..937e19f651 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -948,7 +948,8 @@ static void fill_xyztables(SwsInternal *c)
{1689, 1464, 739},
{ 871, 2929, 296},
{ 79, 488, 3891} };
-static int16_t xyzgamma_tab[4096], rgbgamma_tab[4096],
xyzgammainv_tab[4096], rgbgammainv_tab[4096];
+static uint16_t xyzgamma_tab[4096], rgbgammainv_tab[4096];
+static uint16_t rgbgamma_tab[65536], xyzgammainv_tab[65536];
memcpy(c->xyz2rgb_matrix, xyz2rgb_matrix, sizeof(c->xyz2rgb_matrix));
memcpy(c->rgb2xyz_matrix, rgb2xyz_matrix, sizeof(c->rgb2xyz_matrix));
@@ -957,15 +958,19 @@ static void fill_xyztables(SwsInternal *c)
c->xyzgammainv = xyzgammainv_tab;
c->rgbgammainv = rgbgammainv_tab;
-if (rgbgamma_tab[4095])
+if (xyzgamma_tab[4095])
return;
-/* set gamma vectors */
+/* set input gamma vectors */
for (i = 0; i < 4096; i++) {
-xyzgamma_tab[i] = lrint(pow(i / 4095.0, xyzgamma) * 4095.0);
-rgbgamma_tab[i] = lrint(pow(i / 4095.0, rgbgamma) * 4095.0);
-xyzgammainv_tab[i] = lrint(pow(i / 4095.0, xyzgammainv) * 4095.0);
-rgbgammainv_tab[i] = lrint(pow(i / 4095.0, rgbgammainv) * 4095.0);
+xyzgamma_tab[i] = lrint(pow(i / 4095.0, xyzgamma) * 65535.0);
+rgbgammainv_tab[i] = lrint(pow(i / 4095.0, rgbgammainv) * 65535.0);
+}
+
+/* set output gamma vectors */
+for (i = 0; i < 65536; i++) {
+rgbgamma_tab[i] = lrint(pow(i / 65535.0, rgbgamma) * 4095.0);
+xyzgammainv_tab[i] = lrint(pow(i / 65535.0, xyzgammainv) * 4095.0);
}
}
--
2.47.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avfilter/vf_scale: remove systematic PAL8 hack
From: Niklas Haas
This is not a good way of generating a PAL8 output. For starters, it totally
mangles the image quality, due to essentially generating BRG8 output instead.
It also drops the input alpha channel, if present. Secondly, we already have
a better way of generating PAL8 content: vf_palettegen/paletteuse.
In the long term, it would be a better idea for us to incorporate a
palettization filter as in internal sws pass when the user requests a palette
format as output. But for now, simply remove this hack.
Fixes: ticket #
Signed-off-by: Niklas Haas
Sponsored-by: Sovereign Tech Fund
---
libavfilter/vf_scale.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index d86e50f79b..fba5cc34d8 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -470,7 +470,7 @@ static int query_formats(const AVFilterContext *ctx,
formats = NULL;
while ((desc = av_pix_fmt_desc_next(desc))) {
pix_fmt = av_pix_fmt_desc_get_id(desc);
-if (sws_test_format(pix_fmt, 1) || pix_fmt == AV_PIX_FMT_PAL8) {
+if (sws_test_format(pix_fmt, 1)) {
if ((ret = ff_add_format(&formats, pix_fmt)) < 0)
return ret;
}
@@ -845,11 +845,6 @@ scale:
return 0;
}
-if (out->format == AV_PIX_FMT_PAL8) {
-out->format = AV_PIX_FMT_BGR8;
-avpriv_set_systematic_pal2((uint32_t*) out->data[1], out->format);
-}
-
ret = sws_scale_frame(scale->sws, out, in);
av_frame_free(&in);
out->flags = flags_orig;
--
2.47.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/bit_depth_template: Remove empty macro INIT_CLIP
From: Zhao Zhili
---
libavcodec/bit_depth_template.c | 3 ---
libavcodec/h264pred_template.c | 3 ---
libavcodec/h264qpel_template.c | 9 -
libavcodec/mips/h264qpel_mmi.c | 2 --
4 files changed, 17 deletions(-)
diff --git a/libavcodec/bit_depth_template.c b/libavcodec/bit_depth_template.c
index d44d47ea45..ca5037148a 100644
--- a/libavcodec/bit_depth_template.c
+++ b/libavcodec/bit_depth_template.c
@@ -30,7 +30,6 @@
# undef pixel4
# undef dctcoef
# undef idctin
-# undef INIT_CLIP
# undef no_rnd_avg_pixel4
# undef rnd_avg_pixel4
# undef AV_RN2P
@@ -64,7 +63,6 @@
# define idctin int16_t
#endif
-# define INIT_CLIP
# define no_rnd_avg_pixel4 no_rnd_avg64
# definernd_avg_pixel4rnd_avg64
# define AV_RN2P AV_RN32
@@ -84,7 +82,6 @@
# define dctcoef int16_t
# define idctin int16_t
-# define INIT_CLIP
# define no_rnd_avg_pixel4 no_rnd_avg32
# definernd_avg_pixel4rnd_avg32
# define AV_RN2P AV_RN16
diff --git a/libavcodec/h264pred_template.c b/libavcodec/h264pred_template.c
index b5bc942a5e..98b28d0afb 100644
--- a/libavcodec/h264pred_template.c
+++ b/libavcodec/h264pred_template.c
@@ -414,7 +414,6 @@ static inline void FUNCC(pred16x16_plane_compat)(uint8_t
*_src,
{
int i, j, k;
int a;
- INIT_CLIP
pixel *src = (pixel*)_src;
int stride = _stride>>(sizeof(pixel)-1);
const pixel * const src0 = src +7-stride;
@@ -748,7 +747,6 @@ static void FUNCC(pred8x8_plane)(uint8_t *_src, ptrdiff_t
_stride)
{
int j, k;
int a;
- INIT_CLIP
pixel *src = (pixel*)_src;
int stride = _stride>>(sizeof(pixel)-1);
const pixel * const src0 = src +3-stride;
@@ -784,7 +782,6 @@ static void FUNCC(pred8x16_plane)(uint8_t *_src, ptrdiff_t
_stride)
{
int j, k;
int a;
- INIT_CLIP
pixel *src = (pixel*)_src;
int stride = _stride>>(sizeof(pixel)-1);
const pixel * const src0 = src +3-stride;
diff --git a/libavcodec/h264qpel_template.c b/libavcodec/h264qpel_template.c
index f7fabe4aaa..324a0889e9 100644
--- a/libavcodec/h264qpel_template.c
+++ b/libavcodec/h264qpel_template.c
@@ -78,7 +78,6 @@ static inline void FUNC(copy_block16)(uint8_t *dst, const
uint8_t *restrict src,
static av_unused void FUNC(OPNAME ## h264_qpel2_h_lowpass)(uint8_t *p_dst,
const uint8_t *restrict p_src, int dstStride, int srcStride)\
{\
const int h=2;\
-INIT_CLIP\
int i;\
pixel *dst = (pixel*)p_dst;\
const pixel *restrict src = (const pixel*)p_src;\
@@ -96,7 +95,6 @@ static av_unused void FUNC(OPNAME ##
h264_qpel2_h_lowpass)(uint8_t *p_dst, const
static av_unused void FUNC(OPNAME ## h264_qpel2_v_lowpass)(uint8_t *_dst,
const uint8_t *restrict _src, int dstStride, int srcStride)\
{\
const int w=2;\
-INIT_CLIP\
int i;\
pixel *dst = (pixel*)_dst;\
const pixel *restrict src = (const pixel*)_src;\
@@ -123,7 +121,6 @@ static av_unused void FUNC(OPNAME ##
h264_qpel2_hv_lowpass)(uint8_t *_dst, pixel
const int h=2;\
const int w=2;\
const int pad = (BIT_DEPTH == 10) ? (-10 * ((1
Re: [FFmpeg-devel] [PATCH 5/6] Add more FATE tests for fragmented MP4
mån 2024-12-16 klockan 16:27 +0100 skrev Tomas Härdin: > Two reference files. One with sidx+mfra, the other with only mfra Forgot the FATE refs. Updated patch attached /Tomas From f6d28d84413f2f674cfac86d4ed0868e8afb604b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tomas=20H=C3=A4rdin?= Date: Mon, 16 Dec 2024 16:15:47 +0100 Subject: [PATCH 5/6] Add more FATE tests for fragmented MP4 This tests the number of seeks performed when probing fmp4 with and without sidx Also add tests for the duration, which should be 10 minutes in both cases Use the same reference for both probe tests --- tests/fate/mov.mak| 9 +++ tests/ref/fate/mov-mfra | 1 + tests/ref/fate/mov-mfra-probe | 51 +++ tests/ref/fate/mov-sidx | 1 + 4 files changed, 62 insertions(+) create mode 100644 tests/ref/fate/mov-mfra create mode 100644 tests/ref/fate/mov-mfra-probe create mode 100644 tests/ref/fate/mov-sidx diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak index ca13ebfd44..3087a11cbc 100644 --- a/tests/fate/mov.mak +++ b/tests/fate/mov.mak @@ -284,6 +284,15 @@ fate-mov-mp4-iamf-ambisonic_1: CMD = transcode wav $(SRC) mp4 "-auto_conversion_ -streamid 0:0 -streamid 1:1 -streamid 2:2 -streamid 3:3 -map [MONO0] -map [MONO1] -map [MONO2] -map [MONO3] -c:a flac -t 1" "-c:a copy -map 0" \ "-show_entries stream_group=index,id,nb_streams,type:stream_group_components:stream_group_disposition:stream_group_tags:stream_group_stream=index,id:stream_group_stream_disposition" +FATE_MOV_FFPROBE-$(call ALLYES, MOV_DEMUXER FILE_PROTOCOL) += fate-mov-mfra fate-mov-sidx fate-mov-mfra-probe fate-mov-sidx-probe +fate-mov-mfra fate-mov-mfra-probe: SRC = $(TARGET_SAMPLES)/mov/frags-mfra.mp4 +fate-mov-sidx fate-mov-sidx-probe: SRC = $(TARGET_SAMPLES)/mov/frags-sidx.mp4 +fate-mov-mfra fate-mov-sidx: CMD = run ffprobe -loglevel debug -i $(SRC) 2>&1 | grep Statistics | sed -e "s/.*bytes read, //" +# share REF between both probe tests +# we want the same behavior regardless of whether sidx is present or not +fate-mov-mfra-probe fate-mov-sidx-probe: REF = tests/ref/fate/mov-mfra-probe +fate-mov-mfra-probe fate-mov-sidx-probe: CMD = run ffprobe -show_streams -i $(SRC) + FATE_FFMPEG += $(FATE_MOV_FFMPEG-yes) FATE_FFMPEG_FFPROBE += $(FATE_MOV_FFMPEG_FFPROBE-yes) diff --git a/tests/ref/fate/mov-mfra b/tests/ref/fate/mov-mfra new file mode 100644 index 00..299d3159ab --- /dev/null +++ b/tests/ref/fate/mov-mfra @@ -0,0 +1 @@ +6 seeks diff --git a/tests/ref/fate/mov-mfra-probe b/tests/ref/fate/mov-mfra-probe new file mode 100644 index 00..c07f72e0ec --- /dev/null +++ b/tests/ref/fate/mov-mfra-probe @@ -0,0 +1,51 @@ +[STREAM] +index=0 +codec_name=pcm_s16le +codec_long_name=PCM signed 16-bit little-endian +profile=unknown +codec_type=audio +codec_tag_string=ipcm +codec_tag=0x6d637069 +sample_fmt=s16 +sample_rate=44100 +channels=1 +channel_layout=unknown +bits_per_sample=16 +initial_padding=0 +id=0x1 +r_frame_rate=0/0 +avg_frame_rate=0/0 +time_base=1/44100 +start_pts=0 +start_time=0.00 +duration_ts=2646 +duration=600.00 +bit_rate=705600 +max_bit_rate=N/A +bits_per_raw_sample=N/A +nb_frames=31744 +nb_read_frames=N/A +nb_read_packets=N/A +DISPOSITION:default=1 +DISPOSITION:dub=0 +DISPOSITION:original=0 +DISPOSITION:comment=0 +DISPOSITION:lyrics=0 +DISPOSITION:karaoke=0 +DISPOSITION:forced=0 +DISPOSITION:hearing_impaired=0 +DISPOSITION:visual_impaired=0 +DISPOSITION:clean_effects=0 +DISPOSITION:attached_pic=0 +DISPOSITION:timed_thumbnails=0 +DISPOSITION:non_diegetic=0 +DISPOSITION:captions=0 +DISPOSITION:descriptions=0 +DISPOSITION:metadata=0 +DISPOSITION:dependent=0 +DISPOSITION:still_image=0 +DISPOSITION:multilayer=0 +TAG:language=und +TAG:handler_name=SoundHandler +TAG:vendor_id=[0][0][0][0] +[/STREAM] diff --git a/tests/ref/fate/mov-sidx b/tests/ref/fate/mov-sidx new file mode 100644 index 00..d24055e37b --- /dev/null +++ b/tests/ref/fate/mov-sidx @@ -0,0 +1 @@ +3 seeks -- 2.39.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] avcodec/frame: add AV_FRAME_FLAG_LOSSLESS
Quoting Marton Balint (2024-12-15 01:02:42) > Signed-off-by: Marton Balint > --- > doc/APIchanges | 3 +++ > libavcodec/version.h | 2 +- > libavutil/frame.h| 4 > 3 files changed, 8 insertions(+), 1 deletion(-) > > diff --git a/doc/APIchanges b/doc/APIchanges > index 3a75b803a9..bfba0946d3 100644 > --- a/doc/APIchanges > +++ b/doc/APIchanges > @@ -2,6 +2,9 @@ The last version increases of all libraries were on 2024-03-07 > > API changes, most recent first: > > +2024-12-xx - xx - lavc 61.27.100 - frame.h > + Add AV_FRAME_FLAG_LOSSLESS. I feel ambivalent about this. This is really a decoder property, and attaching it to frames allows it propagate far away to places where it makes no sense (the same holds for other existing AVFrame fields, but I'd prefer for them to be removed). -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: CC election
Hi all, the vote has been started. If you are in the GA (the tools/general_assembly.pl script lists your name), you should have received an email by now. If you did not, complain in this thread. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] avcodec/frame: add AV_FRAME_FLAG_LOSSLESS
On Mon, 16 Dec 2024, Anton Khirnov wrote: Quoting Marton Balint (2024-12-15 01:02:42) Signed-off-by: Marton Balint --- doc/APIchanges | 3 +++ libavcodec/version.h | 2 +- libavutil/frame.h| 4 3 files changed, 8 insertions(+), 1 deletion(-) diff --git a/doc/APIchanges b/doc/APIchanges index 3a75b803a9..bfba0946d3 100644 --- a/doc/APIchanges +++ b/doc/APIchanges @@ -2,6 +2,9 @@ The last version increases of all libraries were on 2024-03-07 API changes, most recent first: +2024-12-xx - xx - lavc 61.27.100 - frame.h + Add AV_FRAME_FLAG_LOSSLESS. I feel ambivalent about this. This is really a decoder property, and attaching it to frames allows it propagate far away to places where it makes no sense (the same holds for other existing AVFrame fields, but I'd prefer for them to be removed). The way this flag is set in patch 2 in the series kind of shows why this is a per-frame property, directly originated from the bitstream of codecs supporting both lossy and lossless encoding. The encoder for such codecs is allowed to decide on a frame-by-frame basis if it will use lossy or lossless encoding. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] configure: add iso_writer golomb dependency
since commit fce0622d0b1f69a85fe8ce61e1189dd57a8b0fcc, libavformat/hevc.c depends on golomb vlc tables. --- i often build with --disable-all and only turn on the components that i am working on. this dependency would otherwise go unnoticed since many codecs drag in golomb. configure | 1 + 1 file changed, 1 insertion(+) diff --git a/configure b/configure index bf55ba67fa..751506cd6a 100755 --- a/configure +++ b/configure @@ -2880,6 +2880,7 @@ h264parse_select="golomb" h264_sei_select="atsc_a53 golomb" hevcparse_select="golomb" hevc_sei_select="atsc_a53 golomb" +iso_writer_select="golomb" frame_thread_encoder_deps="encoders threads" iamfdec_deps="iamf" iamfdec_select="iso_media mpeg4audio" -- 2.45.2 -- Peter (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] avcodec/frame: add AV_FRAME_FLAG_LOSSLESS
On Mon, 16 Dec 2024, Anton Khirnov wrote: Quoting Marton Balint (2024-12-16 09:47:39) On Mon, 16 Dec 2024, Anton Khirnov wrote: Quoting Marton Balint (2024-12-15 01:02:42) Signed-off-by: Marton Balint --- doc/APIchanges | 3 +++ libavcodec/version.h | 2 +- libavutil/frame.h| 4 3 files changed, 8 insertions(+), 1 deletion(-) diff --git a/doc/APIchanges b/doc/APIchanges index 3a75b803a9..bfba0946d3 100644 --- a/doc/APIchanges +++ b/doc/APIchanges @@ -2,6 +2,9 @@ The last version increases of all libraries were on 2024-03-07 API changes, most recent first: +2024-12-xx - xx - lavc 61.27.100 - frame.h + Add AV_FRAME_FLAG_LOSSLESS. I feel ambivalent about this. This is really a decoder property, and attaching it to frames allows it propagate far away to places where it makes no sense (the same holds for other existing AVFrame fields, but I'd prefer for them to be removed). The way this flag is set in patch 2 in the series kind of shows why this is a per-frame property, directly originated from the bitstream of codecs supporting both lossy and lossless encoding. The encoder for such codecs is allowed to decide on a frame-by-frame basis if it will use lossy or lossless encoding. I realize this can change per-frame, my point is that it's a per-frame property of the decoding process, not of the decoded frame itself. As you said yourself, we have similar fields already in AVFrame (keyframe, pict_type, decoder_error_flags). I guess we could return those in a struct alongside with AVFrame when decoding, but that would complicate stuff in a lot of places having to deal with two structs, so I am not sure that it's worth doing just for the somewhat "cleaner" AVFrame... 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] swscale/slice: fix init of 32 bpc planes
On Mon, 16 Dec 2024 01:50:20 +0100 Michael Niedermayer wrote: > Hi Niklas > > On Wed, Dec 11, 2024 at 09:25:12AM +0100, Niklas Haas wrote: > > From: Niklas Haas > > > > In input.c and output.c and many other places, swscale follows the rule of > > using > > 15-bit intermediate if output bpc is <= 8, and 19-bit (inside int32_t) > > intermediate otherwise. See e.g. the comments on hyScale() on > > swscale_internal.h. These are also the coefficients that > > yuv2gbrpf32_full_X_c() > > is using. > > > > In contrast to this, the plane init code in slice.c (function fill_ones) is > > assuming that we use 35-bit intermediates (inside 64-bit integers) for this > > case, seemingly added by commit b4967fc71c63eae8cd96f9c46cd3e1fbd705bbf9 > > with > > no further justification. > > > > This causes a mismatch whenever the implicitly initialized plane contents > > leak > > out to the output, e.g. when converting from grayscale to RGB. > > > > Fixes: ticket #10716 > > Signed-off-by: Niklas Haas > > Sponsored-by: Sovereign Tech Fund > > --- > > libswscale/slice.c | 6 +- > > 1 file changed, 1 insertion(+), 5 deletions(-) > > ultimately 32bit on teh input or output side require more than 32bit > internally to maintain precission. > > if this patch makes it all match up, its ok for now but 18bit dont seem > enough for 32bit data What exactly is the design goal here? As a point of reference, here is how many bits you need to represent a signal to within an error that is substantially below the threshold of human perception in all but the most extreme synthetic test setups: - HDR before linearization: 14 bits - HDR after linearization: 35 bits - SDR before linearization: 12 bits - SDR after linearization: 26 bits If we relax this to the threshold that is required for visual transparency in (non-static) video playback, we get: - HDR before linearization: 12 bits - HDR after linearization: 30 bits - SDR before linearization: 10 bits - SDR after linearization: 22 bits Given that swscale currently does not linearize input data except in the case of XYZ (which I want to handle differently in the near future), it's safe to say that 18 bits of precision is more than enough to faithfully represent any sort of non-synthetic data, as will as to capture the dynamic range of any camera that currently exists. If we instead want to be able to losslessy roundtrip the input data *exactly*, then the only solution would be to also switch to a floating point internal format, rather than upping the bit depth. Even 64 bits fixed point is by far not enough to accurately round-trip a 32f input. The only case that can be made for a 64-bit integer format is if we want to start linearizing HDR input images, and for some reason determine that 64-bit fixed point math is faster than 32-bit floating point math, which would be the most obvious candidate of intermediate format for linearized content. > > thx > > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > What is money laundering? Its paying someone and not telling the government. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 00/17] swscale: add color management subsystem
Changes since v1: - Rewrote swscale/csputils slightly (mostly cosmetic, improved comments) - Fixed the semantics of the new vf_scale options to correspond to the documented behavior. - Moved the PQ metadata override to a later commit - Simplified the ff_q_equal() logic ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 14/17] swscale/lut3d: add 3DLUT dispatch system
From: Niklas Haas
This is a lightweight wrapper around the underlying color management system,
whose job it is merely to manage the 3DLUT state and apply them to the frame
data. This is where we might add platform-specific optimizations in the future.
I also plan on adding support for more pixel formats in the future. In
particular, we could support YUV or XYZ input formats directly using only
negligible additional code in the 3DLUT setup functions. This would eliminate
the major source of slowdown, which is currently the roundtrip to RGBA64.
---
libswscale/Makefile | 1 +
libswscale/lut3d.c | 290
libswscale/lut3d.h | 98 +++
3 files changed, 389 insertions(+)
create mode 100644 libswscale/lut3d.c
create mode 100644 libswscale/lut3d.h
diff --git a/libswscale/Makefile b/libswscale/Makefile
index c4e45d494e..267952d870 100644
--- a/libswscale/Makefile
+++ b/libswscale/Makefile
@@ -14,6 +14,7 @@ OBJS = alphablend.o \
graph.o \
half2float.o \
input.o \
+ lut3d.o \
options.o\
output.o \
rgb2rgb.o\
diff --git a/libswscale/lut3d.c b/libswscale/lut3d.c
new file mode 100644
index 00..db8e5f6f84
--- /dev/null
+++ b/libswscale/lut3d.c
@@ -0,0 +1,290 @@
+/*
+ * Copyright (C) 2024 Niklas Haas
+ *
+ * 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
+#include
+
+#include "libavutil/attributes.h"
+#include "libavutil/avassert.h"
+#include "libavutil/mem.h"
+
+#include "cms.h"
+#include "csputils.h"
+#include "lut3d.h"
+
+SwsLut3D *sws_lut3d_alloc(void)
+{
+SwsLut3D *lut3d = av_malloc(sizeof(*lut3d));
+if (!lut3d)
+return NULL;
+
+lut3d->dynamic = false;
+return lut3d;
+}
+
+void sws_lut3d_free(SwsLut3D **plut3d)
+{
+av_freep(plut3d);
+}
+
+bool sws_lut3d_test_fmt(enum AVPixelFormat fmt, int output)
+{
+return fmt == AV_PIX_FMT_RGBA64;
+}
+
+enum AVPixelFormat sws_lut3d_pick_pixfmt(SwsFormat fmt, int output)
+{
+return AV_PIX_FMT_RGBA64;
+}
+
+/**
+ * v0 and v1 are 'black' and 'white'
+ * v2 and v3 are closest RGB/CMY vertices
+ * x >= y >= z are relative weights
+ */
+static av_always_inline
+v3u16_t barycentric(int shift, int x, int y, int z,
+v3u16_t v0, v3u16_t v1, v3u16_t v2, v3u16_t v3)
+{
+const int a = (1 << shift) - x;
+const int b = x - y;
+const int c = y - z;
+const int d = z;
+av_assert2(x >= y);
+av_assert2(y >= z);
+
+return (v3u16_t) {
+(a * v0.x + b * v1.x + c * v2.x + d * v3.x) >> shift,
+(a * v0.y + b * v1.y + c * v2.y + d * v3.y) >> shift,
+(a * v0.z + b * v1.z + c * v2.z + d * v3.z) >> shift,
+};
+}
+
+static av_always_inline
+v3u16_t tetrahedral(const SwsLut3D *lut3d, int Rx, int Gx, int Bx,
+int Rf, int Gf, int Bf)
+{
+const int shift = 16 - INPUT_LUT_BITS;
+const int Rn = FFMIN(Rx + 1, INPUT_LUT_SIZE - 1);
+const int Gn = FFMIN(Gx + 1, INPUT_LUT_SIZE - 1);
+const int Bn = FFMIN(Bx + 1, INPUT_LUT_SIZE - 1);
+
+const v3u16_t c000 = lut3d->input[Bx][Gx][Rx];
+const v3u16_t c111 = lut3d->input[Bn][Gn][Rn];
+if (Rf > Gf) {
+if (Gf > Bf) {
+const v3u16_t c100 = lut3d->input[Bx][Gx][Rn];
+const v3u16_t c110 = lut3d->input[Bx][Gn][Rn];
+return barycentric(shift, Rf, Gf, Bf, c000, c100, c110, c111);
+} else if (Rf > Bf) {
+const v3u16_t c100 = lut3d->input[Bx][Gx][Rn];
+const v3u16_t c101 = lut3d->input[Bn][Gx][Rn];
+return barycentric(shift, Rf, Bf, Gf, c000, c100, c101, c111);
+} else {
+const v3u16_t c001 = lut3d->input[Bn][Gx][Rx];
+const v3u16_t c101 = lut3d->input[Bn][Gx][Rn];
+return barycentric(shift, Bf, Rf, Gf, c000, c001, c101, c111);
+}
+} else {
+if (Bf > Gf) {
+const v3u16_t c001 = lut3d->input[Bn][Gx][Rx];
+
[FFmpeg-devel] [PATCH v2 02/17] swscale/utils: add HDR metadata to SwsFormat
From: Niklas Haas
Only add the condensed values that we actually care about. Group them into
a new struct to make it easier to discard or replace this metadata.
Define a special comparison function that does not choke on undefined/unknown
metadata.
---
libswscale/swscale.c | 7 ---
libswscale/utils.c | 28 +++---
libswscale/utils.h | 48 +++-
3 files changed, 63 insertions(+), 20 deletions(-)
diff --git a/libswscale/swscale.c b/libswscale/swscale.c
index 96634acfd6..931834a374 100644
--- a/libswscale/swscale.c
+++ b/libswscale/swscale.c
@@ -1442,7 +1442,8 @@ int sws_frame_setup(SwsContext *ctx, const AVFrame *dst,
const AVFrame *src)
}
/* TODO: remove once implemented */
-if ((dst_fmt.prim != src_fmt.prim || dst_fmt.trc != src_fmt.trc) &&
+if ((dst_fmt.color.prim != src_fmt.color.prim ||
+ dst_fmt.color.trc != src_fmt.color.trc) &&
!s->color_conversion_warned)
{
av_log(ctx, AV_LOG_WARNING, "Conversions between different
primaries / "
@@ -1487,9 +1488,9 @@ int sws_frame_setup(SwsContext *ctx, const AVFrame *dst,
const AVFrame *src)
" fmt:%s csp:%s prim:%s trc:%s\n",
err_msg, av_err2str(ret),
av_get_pix_fmt_name(src_fmt.format),
av_color_space_name(src_fmt.csp),
- av_color_primaries_name(src_fmt.prim),
av_color_transfer_name(src_fmt.trc),
+ av_color_primaries_name(src_fmt.color.prim),
av_color_transfer_name(src_fmt.color.trc),
av_get_pix_fmt_name(dst_fmt.format),
av_color_space_name(dst_fmt.csp),
- av_color_primaries_name(dst_fmt.prim),
av_color_transfer_name(dst_fmt.trc));
+ av_color_primaries_name(dst_fmt.color.prim),
av_color_transfer_name(dst_fmt.color.trc));
for (int i = 0; i < FF_ARRAY_ELEMS(s->graph); i++)
sws_graph_free(&s->graph[i]);
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 43805b9679..428cf1c7f5 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -2659,11 +2659,13 @@ SwsFormat ff_fmt_from_frame(const AVFrame *frame, int
field)
.height = frame->height,
.format = frame->format,
.range = frame->color_range,
-.prim = frame->color_primaries,
-.trc= frame->color_trc,
.csp= frame->colorspace,
.loc= frame->chroma_location,
.desc = desc,
+.color = {
+.prim = frame->color_primaries,
+.trc = frame->color_trc,
+},
};
av_assert1(fmt.width > 0);
@@ -2676,12 +2678,14 @@ SwsFormat ff_fmt_from_frame(const AVFrame *frame, int
field)
fmt.range = AVCOL_RANGE_JPEG;
} else if (desc->flags & AV_PIX_FMT_FLAG_XYZ) {
fmt.csp = AVCOL_SPC_UNSPECIFIED;
-fmt.prim = AVCOL_PRI_SMPTE428;
-fmt.trc = AVCOL_TRC_SMPTE428;
+fmt.color = (SwsColor) {
+.prim = AVCOL_PRI_SMPTE428,
+.trc = AVCOL_TRC_SMPTE428,
+};
} else if (desc->nb_components < 3) {
/* Grayscale formats */
-fmt.prim = AVCOL_PRI_UNSPECIFIED;
-fmt.csp = AVCOL_SPC_UNSPECIFIED;
+fmt.color.prim = AVCOL_PRI_UNSPECIFIED;
+fmt.csp= AVCOL_SPC_UNSPECIFIED;
if (desc->flags & AV_PIX_FMT_FLAG_FLOAT)
fmt.range = AVCOL_RANGE_UNSPECIFIED;
else
@@ -2756,12 +2760,12 @@ static int test_loc(enum AVChromaLocation loc)
int ff_test_fmt(const SwsFormat *fmt, int output)
{
-return fmt->width > 0 && fmt->height > 0&&
- sws_test_format(fmt->format, output) &&
- sws_test_colorspace(fmt->csp,output) &&
- sws_test_primaries (fmt->prim, output) &&
- sws_test_transfer (fmt->trc,output) &&
- test_range (fmt->range) &&
+return fmt->width > 0 && fmt->height > 0&&
+ sws_test_format(fmt->format, output) &&
+ sws_test_colorspace(fmt->csp,output) &&
+ sws_test_primaries (fmt->color.prim, output) &&
+ sws_test_transfer (fmt->color.trc, output) &&
+ test_range (fmt->range) &&
test_loc (fmt->loc);
}
diff --git a/libswscale/utils.h b/libswscale/utils.h
index 4d204ef6cc..52b1e67644 100644
--- a/libswscale/utils.h
+++ b/libswscale/utils.h
@@ -21,26 +21,55 @@
#ifndef SWSCALE_UTILS_H
#define SWSCALE_UTILS_H
+#include "libavutil/csp.h"
#include "libavutil/pixdesc.h"
#include "swscale.h"
+/* Like av_cmp_q but considers x/0 == y/0 */
+static inline int ff_q_equal(const AVRational a, const AVRational b)
+{
+return (!a.den && !b.den) || !av_cmp_q(a, b);
+}
+
+static inline int ff_cie_xy_equal(const AVCIExy a, const AVCIExy b)
+{
+return ff_q_equal(a.x, b.x) && ff_q_equal(a.y, b.y);
+}
+
+static inline int ff_prim_equ
[FFmpeg-devel] [PATCH v2 01/17] swscale/utils: check for supported color transfers
From: Niklas Haas
We will use the av_csp_itu_eotf() functions to decode these internally, so
check this function to see if it succeeds.
---
libswscale/utils.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 32f90e366e..43805b9679 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -41,6 +41,7 @@
#include "libavutil/attributes.h"
#include "libavutil/avassert.h"
#include "libavutil/cpu.h"
+#include "libavutil/csp.h"
#include "libavutil/emms.h"
#include "libavutil/imgutils.h"
#include "libavutil/intreadwrite.h"
@@ -2738,8 +2739,9 @@ int sws_test_primaries(enum AVColorPrimaries prim, int
output)
int sws_test_transfer(enum AVColorTransferCharacteristic trc, int output)
{
-return trc > AVCOL_TRC_RESERVED0 && trc < AVCOL_TRC_NB &&
- trc != AVCOL_TRC_RESERVED;
+av_csp_eotf_function eotf = output ? av_csp_itu_eotf_inv(trc)
+ : av_csp_itu_eotf(trc);
+return trc == AVCOL_TRC_UNSPECIFIED || eotf != NULL;
}
static int test_range(enum AVColorRange range)
--
2.47.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 03/17] swscale/utils: set static/implied HDR metadata
From: Niklas Haas
Provide default values for the fields added in the previous commit.
---
libswscale/utils.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 428cf1c7f5..2d8fc10beb 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -2654,6 +2654,8 @@ int ff_range_add(RangeList *rl, unsigned int start,
unsigned int len)
SwsFormat ff_fmt_from_frame(const AVFrame *frame, int field)
{
const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(frame->format);
+const AVColorPrimariesDesc *primaries;
+
SwsFormat fmt = {
.width = frame->width,
.height = frame->height,
@@ -2710,6 +2712,21 @@ SwsFormat ff_fmt_from_frame(const AVFrame *frame, int
field)
fmt.interlaced = 1;
}
+/* Set luminance and gamut information */
+fmt.color.min_luma = av_make_q(0, 1);
+switch (fmt.color.trc) {
+case AVCOL_TRC_SMPTE2084:
+fmt.color.max_luma = av_make_q(1, 1); break;
+case AVCOL_TRC_ARIB_STD_B67:
+fmt.color.max_luma = av_make_q( 1000, 1); break; /* HLG reference
display */
+default:
+fmt.color.max_luma = av_make_q( 203, 1); break; /* SDR reference
brightness */
+}
+
+primaries = av_csp_primaries_desc_from_id(fmt.color.prim);
+if (primaries)
+fmt.color.gamut = primaries->prim;
+
return fmt;
}
--
2.47.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 04/17] swscale/utils: read HDR mastering metadata from AVFrame
From: Niklas Haas
---
libswscale/utils.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 2d8fc10beb..3d3fcadacc 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -46,6 +46,7 @@
#include "libavutil/imgutils.h"
#include "libavutil/intreadwrite.h"
#include "libavutil/libm.h"
+#include "libavutil/mastering_display_metadata.h"
#include "libavutil/mathematics.h"
#include "libavutil/mem.h"
#include "libavutil/opt.h"
@@ -2655,6 +2656,7 @@ SwsFormat ff_fmt_from_frame(const AVFrame *frame, int
field)
{
const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(frame->format);
const AVColorPrimariesDesc *primaries;
+AVFrameSideData *sd;
SwsFormat fmt = {
.width = frame->width,
@@ -2727,6 +2729,26 @@ SwsFormat ff_fmt_from_frame(const AVFrame *frame, int
field)
if (primaries)
fmt.color.gamut = primaries->prim;
+if ((sd = av_frame_get_side_data(frame,
AV_FRAME_DATA_MASTERING_DISPLAY_METADATA))) {
+const AVMasteringDisplayMetadata *mdm = (const
AVMasteringDisplayMetadata *) sd->data;
+if (mdm->has_luminance) {
+fmt.color.min_luma = mdm->min_luminance;
+fmt.color.max_luma = mdm->max_luminance;
+}
+
+if (mdm->has_primaries) {
+/* Ignore mastering display white point as it has no bearance on
+ * the underlying content */
+fmt.color.gamut.r = (AVCIExy) { mdm->display_primaries[0][0],
mdm->display_primaries[0][1] };
+fmt.color.gamut.g = (AVCIExy) { mdm->display_primaries[1][0],
mdm->display_primaries[1][1] };
+fmt.color.gamut.b = (AVCIExy) { mdm->display_primaries[2][0],
mdm->display_primaries[2][1] };
+}
+}
+
+/* PQ is always scaled down to absolute zero, so ignore mastering metadata
*/
+if (fmt.color.trc == AVCOL_TRC_SMPTE2084)
+fmt.color.min_luma = av_make_q(0, 1);
+
return fmt;
}
--
2.47.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 13/17] swscale/cms: add color management subsystem
From: Niklas Haas
The underlying color mapping logic was ported as straightforwardly as possible
from libplacebo, although the API and glue code has been very heavily
refactored / rewritten. In particular, the generalization of gamut mapping
methods is replaced by a single ICC intent selection, and constants have been
hard-coded.
To minimize the amount of overall operations, this gamut mapping LUT now embeds
a direct end-to-end transformation to the output color space; something that
libplacebo does in shaders, but which is prohibitively expensive in software.
In order to preserve compatibility with dynamic tone mapping without severely
regressing performance, we add the ability to generate a pair of "split" LUTS,
one for encoding the input and output to the perceptual color space, and a
third to embed the tone mapping operation. Additionally, this intermediate
space could be used for additional subjective effect (e.g. changing
saturation or brightness).
The big downside of the new approach is that generating a static color mapping
LUT is now fairly slow, as the chromaticity lobe peaks have to be recomputed
for every single RGB value, since correlated RGB colors are not necessarily
aligned in ICh space. Generating a split 3DLUT significantly alleviates this
problem because the expensive step is done as part of the IPT input LUT, which
can share the same hue peak calculation at least for all input intensities.
---
libswscale/Makefile | 1 +
libswscale/cms.c| 766
libswscale/cms.h| 105 ++
3 files changed, 872 insertions(+)
create mode 100644 libswscale/cms.c
create mode 100644 libswscale/cms.h
diff --git a/libswscale/Makefile b/libswscale/Makefile
index 08036634b7..c4e45d494e 100644
--- a/libswscale/Makefile
+++ b/libswscale/Makefile
@@ -6,6 +6,7 @@ HEADERS = swscale.h
\
version_major.h \
OBJS = alphablend.o \
+ cms.o\
csputils.o \
hscale.o \
hscale_fast_bilinear.o \
diff --git a/libswscale/cms.c b/libswscale/cms.c
new file mode 100644
index 00..7793a19b87
--- /dev/null
+++ b/libswscale/cms.c
@@ -0,0 +1,766 @@
+/*
+ * Copyright (C) 2024 Niklas Haas
+ *
+ * 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
+#include
+
+#include "libavutil/attributes.h"
+#include "libavutil/avassert.h"
+#include "libavutil/csp.h"
+#include "libavutil/slicethread.h"
+
+#include "cms.h"
+#include "csputils.h"
+#include "libswscale/swscale.h"
+#include "utils.h"
+
+bool sws_color_map_noop(const SwsColorMap *map)
+{
+/* If the encoding space is different, we must go through a conversion */
+if (map->src.prim != map->dst.prim || map->src.trc != map->dst.trc)
+return false;
+
+/* If the black point changes, we have to perform black point compensation
*/
+if (av_cmp_q(map->src.min_luma, map->dst.min_luma))
+return false;
+
+switch (map->intent) {
+case SWS_INTENT_ABSOLUTE_COLORIMETRIC:
+case SWS_INTENT_RELATIVE_COLORIMETRIC:
+return ff_prim_superset(&map->dst.gamut, &map->src.gamut) &&
+ av_cmp_q(map->src.max_luma, map->dst.max_luma) <= 0;
+case SWS_INTENT_PERCEPTUAL:
+case SWS_INTENT_SATURATION:
+return ff_prim_equal(&map->dst.gamut, &map->src.gamut) &&
+ !av_cmp_q(map->src.max_luma, map->dst.max_luma);
+default:
+av_assert0(!"Invalid gamut mapping intent?");
+return true;
+}
+}
+
+/* Approximation of gamut hull at a given intensity level */
+static const float hull(float I)
+{
+return ((I - 6.0f) * I + 9.0f) * I;
+}
+
+/* For some minimal type safety, and code cleanliness */
+typedef struct RGB {
+float R, G, B; /* nits */
+} RGB;
+
+typedef struct IPT {
+float I, P, T;
+} IPT;
+
+typedef struct ICh {
+float I, C, h;
+} ICh;
+
+static av_always_inline ICh ipt2ich(IPT c)
+{
+return (ICh) {
+.I = c.I,
+.C = sqrtf(c.P * c.P + c.T * c.T),
+.h = atan2f(c.T,
[FFmpeg-devel] [PATCH v2 08/17] swscale: add ICC intent enum and option
From: Niklas Haas
This setting can be used to infuence the type of tone and gamut mapping used
internally when color space conversions are required. As discussed at VDD'24,
the default was set to relative colorimetric clipping, which is approximately
associative, surjective and idempotent. As such, it roundtrips well, although
it is strictly speaking not associative on out-of-gamut colors.
---
doc/APIchanges| 3 +++
doc/filters.texi | 31 +++
libswscale/graph.c| 11 ++-
libswscale/options.c | 6 ++
libswscale/swscale.h | 13 +
libswscale/swscale_internal.h | 2 +-
libswscale/version.h | 2 +-
libswscale/x86/output.asm | 2 +-
8 files changed, 62 insertions(+), 8 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 5c7e82d84f..7f5b3ef3d3 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,9 @@ The last version increases of all libraries were on 2024-03-07
API changes, most recent first:
+2024-12-xx - xx - lsws 8.13.100 - swscale.h
+ Add enum SwsIntent and SwsContext.intent.
+
2024-12-15 - xx - lavc 61.27.100 packet.h
Add av_container_fifo_alloc_avpacket().
diff --git a/doc/filters.texi b/doc/filters.texi
index 900baf2f45..9068a8a4e7 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -21071,7 +21071,38 @@ Set libswscale input parameters for scaling algorithms
that need them. See
complete documentation. If not explicitly specified the filter applies
empty parameters.
+@item intent
+Set the ICC rendering intent to use when transforming between different color
+spaces. It accepts the following values:
+@table @samp
+@item perceptual
+Use a perceptually guided tone and gamut mapping curve. The exact details of
+the mapping used may change at any time and should not be relied on as stable.
+This intent is recommended for final viewing of image/video content in typical
+viewing settings.
+
+@item relative_colorimetric
+Statically clip out-of-gamut colors using a colorimetric clipping curve which
+attempts to find the colorimetrically least dissimilar in-gamut color. This
+intent performs white point adaptation and black point adaptation. This is
+the default. This intent is recommended wherever faithful color reproduction
+is of the utmost importance, even at the cost of clipping.
+
+@item absolute_colorimetric
+Hard clip out-of-gamut colors with no attempt at white or black point
+reproduction. This intent will reproduce in-gamut colors 1:1 on the output
+display as they would appear on the reference display, assuming the output
+display is appropriately calibrated.
+
+@item saturation
+Performs saturation mapping - that is, stretches the input color volume
+directly onto the output color volume, in non-linear fashion that preserves the
+original signal appearance as much as possible. This intent is recommended for
+signal content evaluation, as it will not lead to any clipping. It is roughly
+analogous to not performing any color mapping, although it still takes into
+account the mastering display primaries and any differences in encoding TRC.
+@end table
@item size, s
Set the video size. For the syntax of this option, check the
diff --git a/libswscale/graph.c b/libswscale/graph.c
index fbad1fe8c3..bf2f54b979 100644
--- a/libswscale/graph.c
+++ b/libswscale/graph.c
@@ -570,15 +570,16 @@ void sws_graph_free(SwsGraph **pgraph)
/* Tests only options relevant to SwsGraph */
static int opts_equal(const SwsContext *c1, const SwsContext *c2)
{
-return c1->flags == c2->flags &&
- c1->threads == c2->threads &&
- c1->dither == c2->dither &&
- c1->alpha_blend == c2->alpha_blend &&
- c1->gamma_flag == c2->gamma_flag &&
+return c1->flags == c2->flags &&
+ c1->threads == c2->threads &&
+ c1->dither== c2->dither&&
+ c1->alpha_blend == c2->alpha_blend &&
+ c1->gamma_flag== c2->gamma_flag&&
c1->src_h_chr_pos == c2->src_h_chr_pos &&
c1->src_v_chr_pos == c2->src_v_chr_pos &&
c1->dst_h_chr_pos == c2->dst_h_chr_pos &&
c1->dst_v_chr_pos == c2->dst_v_chr_pos &&
+ c1->intent== c2->intent&&
!memcmp(c1->scaler_params, c2->scaler_params,
sizeof(c1->scaler_params));
}
diff --git a/libswscale/options.c b/libswscale/options.c
index 5eef26de06..08d369e620 100644
--- a/libswscale/options.c
+++ b/libswscale/options.c
@@ -84,6 +84,12 @@ static const AVOption swscale_options[] = {
{ "threads", "number of threads", OFFSET(threads),
AV_OPT_TYPE_INT, {.i64 = 1 }, .flags = VE, .unit = "threads", .max = INT_MAX
},
{ "auto","automatic selection", 0,
AV_OPT_TYPE_CONST, {.i64 = 0 }, .flags = VE, .unit = "threads" },
+{
[FFmpeg-devel] [PATCH v2 16/17] swscale/graph: allow dynamically updating HDR metadata
From: Niklas Haas
Without triggering a full graph reinit.
---
libswscale/graph.c | 21 -
libswscale/graph.h | 12 +---
libswscale/utils.h | 6 ++
3 files changed, 35 insertions(+), 4 deletions(-)
diff --git a/libswscale/graph.c b/libswscale/graph.c
index 7160458a5f..f390e53d24 100644
--- a/libswscale/graph.c
+++ b/libswscale/graph.c
@@ -475,6 +475,14 @@ static void free_lut3d(void *priv)
sws_lut3d_free(&lut);
}
+static void setup_lut3d(const SwsImg *out, const SwsImg *in, const SwsPass
*pass)
+{
+SwsLut3D *lut = pass->priv;
+
+/* Update dynamic frame metadata from the original source frame */
+sws_lut3d_update(lut, &pass->graph->src.color);
+}
+
static void run_lut3d(const SwsImg *out_base, const SwsImg *in_base,
int y, int h, const SwsPass *pass)
{
@@ -543,6 +551,7 @@ static int adapt_colors(SwsGraph *graph, SwsFormat src,
SwsFormat dst,
sws_lut3d_free(&lut);
return AVERROR(ENOMEM);
}
+pass->setup = setup_lut3d;
pass->free = free_lut3d;
*output = pass;
@@ -678,16 +687,26 @@ static int opts_equal(const SwsContext *c1, const
SwsContext *c2)
int sws_graph_reinit(SwsContext *ctx, const SwsFormat *dst, const SwsFormat
*src,
int field, SwsGraph **out_graph)
{
-const SwsGraph *graph = *out_graph;
+SwsGraph *graph = *out_graph;
if (graph && ff_fmt_equal(&graph->src, src) &&
ff_fmt_equal(&graph->dst, dst) &&
opts_equal(ctx, &graph->opts_copy))
+{
+sws_graph_update_metadata(graph, &src->color);
return 0;
+}
sws_graph_free(out_graph);
return sws_graph_create(ctx, dst, src, field, out_graph);
}
+void sws_graph_update_metadata(SwsGraph *graph, const SwsColor *color)
+{
+if (!color)
+return;
+
+ff_color_update_dynamic(&graph->src.color, color);
+}
void sws_graph_run(SwsGraph *graph, uint8_t *const out_data[4],
const int out_linesize[4],
diff --git a/libswscale/graph.h b/libswscale/graph.h
index 989695043d..758060ca12 100644
--- a/libswscale/graph.h
+++ b/libswscale/graph.h
@@ -134,9 +134,15 @@ int sws_graph_create(SwsContext *ctx, const SwsFormat
*dst, const SwsFormat *src
void sws_graph_free(SwsGraph **graph);
/**
- * Wrapper around sws_graph_create that does nothing if the format is
- * unchanged. Must be called after changing any of the fields in `ctx`, or else
- * they will have no effect.
+ * Update dynamic per-frame HDR metadata without requiring a full reinit.
+ */
+void sws_graph_update_metadata(SwsGraph *graph, const SwsColor *color);
+
+/**
+ * Wrapper around sws_graph_create() that reuses the existing graph if the
+ * format is compatible. This will also update dynamic per-frame metadata.
+ * Must be called after changing any of the fields in `ctx`, or else they will
+ * have no effect.
*/
int sws_graph_reinit(SwsContext *ctx, const SwsFormat *dst, const SwsFormat
*src,
int field, SwsGraph **graph);
diff --git a/libswscale/utils.h b/libswscale/utils.h
index 45adbad820..9c72628253 100644
--- a/libswscale/utils.h
+++ b/libswscale/utils.h
@@ -60,6 +60,12 @@ typedef struct SwsColor {
AVRational frame_avg;/* per-frame/scene average luminance, or 0 */
} SwsColor;
+static inline void ff_color_update_dynamic(SwsColor *dst, const SwsColor *src)
+{
+dst->frame_peak = src->frame_peak;
+dst->frame_avg = src->frame_avg;
+}
+
/* Subset of AVFrame parameters that uniquely determine pixel representation */
typedef struct SwsFormat {
int width, height;
--
2.47.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 15/17] swscale/graph: add color mapping pass
From: Niklas Haas
This leverages the previously introduced color management subsystem in order
to adapt between transfer functions and color spaces, as well as for HDR tone
mapping.
Take special care to handle grayscale formats without a colorspace
gracefully.
---
libswscale/graph.c | 95 +-
1 file changed, 93 insertions(+), 2 deletions(-)
diff --git a/libswscale/graph.c b/libswscale/graph.c
index bf2f54b979..7160458a5f 100644
--- a/libswscale/graph.c
+++ b/libswscale/graph.c
@@ -30,6 +30,8 @@
#include "libswscale/swscale.h"
#include "libswscale/utils.h"
+#include "cms.h"
+#include "lut3d.h"
#include "swscale_internal.h"
#include "graph.h"
@@ -463,6 +465,89 @@ static int add_legacy_sws_pass(SwsGraph *graph, SwsFormat
src, SwsFormat dst,
return 0;
}
+/**
+ * Gamut and tone mapping *
+ **/
+
+static void free_lut3d(void *priv)
+{
+SwsLut3D *lut = priv;
+sws_lut3d_free(&lut);
+}
+
+static void run_lut3d(const SwsImg *out_base, const SwsImg *in_base,
+ int y, int h, const SwsPass *pass)
+{
+SwsLut3D *lut = pass->priv;
+const SwsImg in = shift_img(in_base, y);
+const SwsImg out = shift_img(out_base, y);
+
+sws_lut3d_apply(lut, in.data[0], in.linesize[0], out.data[0],
+out.linesize[0], pass->width, h);
+}
+
+static int adapt_colors(SwsGraph *graph, SwsFormat src, SwsFormat dst,
+SwsPass *input, SwsPass **output)
+{
+enum AVPixelFormat fmt_in, fmt_out;
+SwsColorMap map = {0};
+SwsLut3D *lut;
+SwsPass *pass;
+int ret;
+
+/**
+ * Grayspace does not really have primaries, so just force the use of
+ * the equivalent other primary set to avoid a conversion. Technically,
+ * this does affect the weights used for the Grayscale conversion, but
+ * in practise, that should give the expected results more often than not.
+ */
+if (isGray(dst.format)) {
+dst.color = src.color;
+} else if (isGray(src.format)) {
+src.color = dst.color;
+}
+
+/* Fully infer color spaces before color mapping logic */
+graph->incomplete |= ff_infer_colors(&src.color, &dst.color);
+
+map.intent = graph->ctx->intent;
+map.src= src.color;
+map.dst= dst.color;
+
+if (sws_color_map_noop(&map))
+return 0;
+
+lut = sws_lut3d_alloc();
+if (!lut)
+return AVERROR(ENOMEM);
+
+fmt_in = sws_lut3d_pick_pixfmt(src, 0);
+fmt_out = sws_lut3d_pick_pixfmt(dst, 1);
+if (fmt_in != src.format) {
+SwsFormat tmp = src;
+tmp.format = fmt_in;
+ret = add_legacy_sws_pass(graph, src, tmp, input, &input);
+if (ret < 0)
+return ret;
+}
+
+ret = sws_lut3d_generate(lut, fmt_in, fmt_out, &map);
+if (ret < 0) {
+sws_lut3d_free(&lut);
+return ret;
+}
+
+pass = pass_add(graph, lut, fmt_out, src.width, src.height,
+input, 1, run_lut3d);
+if (!pass) {
+sws_lut3d_free(&lut);
+return AVERROR(ENOMEM);
+}
+pass->free = free_lut3d;
+
+*output = pass;
+return 0;
+}
/***
* Main filter graph construction code *
@@ -470,11 +555,17 @@ static int add_legacy_sws_pass(SwsGraph *graph, SwsFormat
src, SwsFormat dst,
static int init_passes(SwsGraph *graph)
{
-const SwsFormat src = graph->src;
-const SwsFormat dst = graph->dst;
+SwsFormat src = graph->src;
+SwsFormat dst = graph->dst;
SwsPass *pass = NULL; /* read from main input image */
int ret;
+ret = adapt_colors(graph, src, dst, pass, &pass);
+if (ret < 0)
+return ret;
+src.format = pass ? pass->format : src.format;
+src.color = dst.color;
+
if (!ff_fmt_equal(&src, &dst)) {
ret = add_legacy_sws_pass(graph, src, dst, pass, &pass);
if (ret < 0)
--
2.47.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 17/17] swscale: remove primaries/trc change warning
From: Niklas Haas
This is now supported when using the new API.
---
libswscale/swscale.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/libswscale/swscale.c b/libswscale/swscale.c
index 931834a374..4e06870fa4 100644
--- a/libswscale/swscale.c
+++ b/libswscale/swscale.c
@@ -1441,17 +1441,6 @@ int sws_frame_setup(SwsContext *ctx, const AVFrame *dst,
const AVFrame *src)
goto fail;
}
-/* TODO: remove once implemented */
-if ((dst_fmt.color.prim != src_fmt.color.prim ||
- dst_fmt.color.trc != src_fmt.color.trc) &&
-!s->color_conversion_warned)
-{
-av_log(ctx, AV_LOG_WARNING, "Conversions between different
primaries / "
- "transfer functions are not currently implemented, expect "
- "wrong results.\n");
-s->color_conversion_warned = 1;
-}
-
if (!ff_test_fmt(&src_fmt, 0)) {
err_msg = "Unsupported input";
ret = AVERROR(ENOTSUP);
--
2.47.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 12/17] swscale/csputils: add internal colorspace math helpers
From: Niklas Haas
Logic is, for the most part, a straight port of similar logic in
liplacebo's colorspace.c, with some general edits and refactors.
---
libswscale/Makefile | 1 +
libswscale/csputils.c | 418 ++
libswscale/csputils.h | 114
3 files changed, 533 insertions(+)
create mode 100644 libswscale/csputils.c
create mode 100644 libswscale/csputils.h
diff --git a/libswscale/Makefile b/libswscale/Makefile
index 81f32f4dd7..08036634b7 100644
--- a/libswscale/Makefile
+++ b/libswscale/Makefile
@@ -6,6 +6,7 @@ HEADERS = swscale.h
\
version_major.h \
OBJS = alphablend.o \
+ csputils.o \
hscale.o \
hscale_fast_bilinear.o \
gamma.o \
diff --git a/libswscale/csputils.c b/libswscale/csputils.c
new file mode 100644
index 00..9546b26fe1
--- /dev/null
+++ b/libswscale/csputils.c
@@ -0,0 +1,418 @@
+/*
+ * Copyright (C) 2024 Niklas Haas
+ *
+ * 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/csp.h"
+
+#include "csputils.h"
+#include "utils.h"
+
+void ff_sws_matrix3x3_mul(SwsMatrix3x3 *a, const SwsMatrix3x3 *b)
+{
+float a00 = a->m[0][0], a01 = a->m[0][1], a02 = a->m[0][2],
+ a10 = a->m[1][0], a11 = a->m[1][1], a12 = a->m[1][2],
+ a20 = a->m[2][0], a21 = a->m[2][1], a22 = a->m[2][2];
+
+for (int i = 0; i < 3; i++) {
+a->m[0][i] = a00 * b->m[0][i] + a01 * b->m[1][i] + a02 * b->m[2][i];
+a->m[1][i] = a10 * b->m[0][i] + a11 * b->m[1][i] + a12 * b->m[2][i];
+a->m[2][i] = a20 * b->m[0][i] + a21 * b->m[1][i] + a22 * b->m[2][i];
+}
+}
+
+void ff_sws_matrix3x3_rmul(const SwsMatrix3x3 *a, SwsMatrix3x3 *b)
+{
+float b00 = b->m[0][0], b01 = b->m[0][1], b02 = b->m[0][2],
+ b10 = b->m[1][0], b11 = b->m[1][1], b12 = b->m[1][2],
+ b20 = b->m[2][0], b21 = b->m[2][1], b22 = b->m[2][2];
+
+for (int i = 0; i < 3; i++) {
+b->m[i][0] = a->m[i][0] * b00 + a->m[i][1] * b10 + a->m[i][2] * b20;
+b->m[i][1] = a->m[i][0] * b01 + a->m[i][1] * b11 + a->m[i][2] * b21;
+b->m[i][2] = a->m[i][0] * b02 + a->m[i][1] * b12 + a->m[i][2] * b22;
+}
+}
+
+void ff_sws_matrix3x3_invert(SwsMatrix3x3 *mat)
+{
+double m00 = mat->m[0][0], m01 = mat->m[0][1], m02 = mat->m[0][2],
+ m10 = mat->m[1][0], m11 = mat->m[1][1], m12 = mat->m[1][2],
+ m20 = mat->m[2][0], m21 = mat->m[2][1], m22 = mat->m[2][2];
+
+// calculate the adjoint
+double a00 = (m11 * m22 - m21 * m12);
+double a01 = -(m01 * m22 - m21 * m02);
+double a02 = (m01 * m12 - m11 * m02);
+double a10 = -(m10 * m22 - m20 * m12);
+double a11 = (m00 * m22 - m20 * m02);
+double a12 = -(m00 * m12 - m10 * m02);
+double a20 = (m10 * m21 - m20 * m11);
+double a21 = -(m00 * m21 - m20 * m01);
+double a22 = (m00 * m11 - m10 * m01);
+
+// calculate the determinant (as inverse == 1/det * adjoint,
+// adjoint * m == identity * det, so this calculates the det)
+double det = m00 * a00 + m10 * a01 + m20 * a02;
+det = 1.0 / det;
+
+mat->m[0][0] = det * a00;
+mat->m[0][1] = det * a01;
+mat->m[0][2] = det * a02;
+mat->m[1][0] = det * a10;
+mat->m[1][1] = det * a11;
+mat->m[1][2] = det * a12;
+mat->m[2][0] = det * a20;
+mat->m[2][1] = det * a21;
+mat->m[2][2] = det * a22;
+}
+
+void ff_sws_matrix3x3_apply(const SwsMatrix3x3 *mat, float vec[3])
+{
+float x = vec[0], y = vec[1], z = vec[2];
+
+for (int i = 0; i < 3; i++)
+vec[i] = mat->m[i][0] * x + mat->m[i][1] * y + mat->m[i][2] * z;
+}
+
+/* Recovers (X / Y) from a CIE xy value. */
+static inline AVRational cie_X(AVCIExy xy)
+{
+return av_div_q(xy.x, xy.y);
+}
+
+/* Recovers (Z / Y) from a CIE xy value. */
+static inline AVRational cie_Z(AVCIExy xy)
+{
+return av_div_q(av_sub_q(av_sub_q(av_make_q(1, 1), xy.x), xy.y), xy.y);
+}
+
+SwsMatrix3x3 ff_sws_rgb2xyz(const AVColorPrimariesDesc *desc)
+{
+SwsMatrix3x
[FFmpeg-devel] [PATCH v2 05/17] swscale/utils: read dynamic HDR10+ metadata from AVFrame
From: Niklas Haas
Logic ported from libplacebo's AVFrame helpers. The basic idea is to use the
provided MaxRGB/MaxSCL values to infer what the actual luminance would have
been, which HDR10+ metadata does not provide directly. It's worth pointing out
that this gives us an *upper* bound on the true maximum luminance, so any
error in the estimation cannot result in clipping.
---
libswscale/utils.c | 50 ++
1 file changed, 50 insertions(+)
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 3d3fcadacc..b097ec51b2 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -43,6 +43,7 @@
#include "libavutil/cpu.h"
#include "libavutil/csp.h"
#include "libavutil/emms.h"
+#include "libavutil/hdr_dynamic_metadata.h"
#include "libavutil/imgutils.h"
#include "libavutil/intreadwrite.h"
#include "libavutil/libm.h"
@@ -2745,6 +2746,55 @@ SwsFormat ff_fmt_from_frame(const AVFrame *frame, int
field)
}
}
+if ((sd = av_frame_get_side_data(frame, AV_FRAME_DATA_DYNAMIC_HDR_PLUS))) {
+const AVDynamicHDRPlus *dhp = (const AVDynamicHDRPlus *) sd->data;
+const AVHDRPlusColorTransformParams *pars = &dhp->params[0];
+const AVRational nits = av_make_q(1, 1);
+AVRational maxrgb = pars->maxscl[0];
+
+if (!dhp->num_windows || dhp->application_version > 1)
+goto skip_hdr10;
+
+/* Maximum of MaxSCL components */
+if (av_cmp_q(pars->maxscl[1], maxrgb) > 0)
+maxrgb = pars->maxscl[1];
+if (av_cmp_q(pars->maxscl[2], maxrgb) > 0)
+maxrgb = pars->maxscl[2];
+
+if (maxrgb.num > 0) {
+/* Estimate true luminance from MaxSCL */
+const AVLumaCoefficients *luma =
av_csp_luma_coeffs_from_avcsp(fmt.csp);
+if (!luma)
+goto skip_hdr10;
+fmt.color.frame_peak = av_add_q(av_mul_q(luma->cr,
pars->maxscl[0]),
+ av_add_q(av_mul_q(luma->cg,
pars->maxscl[1]),
+av_mul_q(luma->cb,
pars->maxscl[2])));
+/* Scale the scene average brightness by the ratio between the
+ * maximum luminance and the MaxRGB values */
+fmt.color.frame_avg = av_mul_q(pars->average_maxrgb,
+ av_div_q(fmt.color.frame_peak,
maxrgb));
+} else {
+/**
+ * Calculate largest value from histogram to use as fallback for
+ * clips with missing MaxSCL information. Note that this may end
+ * up picking the "reserved" value at the 5% percentile, which in
+ * practice appears to track the brightest pixel in the scene.
+ */
+for (int i = 0; i < pars->num_distribution_maxrgb_percentiles;
i++) {
+const AVRational pct = pars->distribution_maxrgb[i].percentile;
+if (av_cmp_q(pct, maxrgb) > 0)
+maxrgb = pct;
+fmt.color.frame_peak = maxrgb;
+fmt.color.frame_avg = pars->average_maxrgb;
+}
+}
+
+/* Rescale to nits */
+fmt.color.frame_peak = av_mul_q(nits, fmt.color.frame_peak);
+fmt.color.frame_avg = av_mul_q(nits, fmt.color.frame_avg);
+}
+skip_hdr10:
+
/* PQ is always scaled down to absolute zero, so ignore mastering metadata
*/
if (fmt.color.trc == AVCOL_TRC_SMPTE2084)
fmt.color.min_luma = av_make_q(0, 1);
--
2.47.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 09/17] avfilter/vf_scale: add colorspace and transfer property options
From: Niklas Haas
In the long run, it would be ideal if we could add these to the avfilter
negotiation as well, but for now, this is a good start.
---
doc/filters.texi | 56
libavfilter/vf_scale.c | 73 +-
2 files changed, 128 insertions(+), 1 deletion(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 9068a8a4e7..b926b865ae 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -21189,6 +21189,62 @@ is used by default. Possible values:
@item bottom
@end table
+@item in_primaries
+@item out_primaries
+Set in/output RGB primaries.
+
+This allows the autodetected value to be overridden as well as allows forcing
+a specific value used for the output and encoder. Possible values:
+
+@table @samp
+@item auto
+Choose automatically. This is the default.
+
+@item bt709
+@item bt470m
+@item bt470bg
+@item smpte170m
+@item smpte240m
+@item film
+@item bt2020
+@item smpte428
+@item smpte431
+@item smpte432
+@item jedec-p22
+@item ebu3213
+@end table
+
+@item in_transfer
+@item out_transfer
+Set in/output transfer response curve (TRC).
+
+This allows the autodetected value to be overridden as well as allows forcing
+a specific value used for the output and encoder. Possible values:
+
+@table @samp
+@item auto
+Choose automatically. This is the default.
+
+@item bt709
+@item bt470m
+@item gamma22
+@item bt470bg
+@item gamma28
+@item smpte170m
+@item smpte240m
+@item linear
+@item iec61966-2-1
+@item srgb
+@item iec61966-2-4
+@item xvycc
+@item bt1361e
+@item bt2020-10
+@item bt2020-12
+@item smpte2084
+@item smpte428
+@item arib-std-b67
+@end table
+
@item force_original_aspect_ratio
Enable decreasing or increasing output video width or height if necessary to
keep the original aspect ratio. Possible values:
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index d86e50f79b..d4236f4b6c 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -160,7 +160,10 @@ typedef struct ScaleContext {
int in_color_matrix;
int out_color_matrix;
-
+int in_primaries;
+int out_primaries;
+int in_transfer;
+int out_transfer;
int in_range;
int out_range;
@@ -387,6 +390,30 @@ static av_cold int init(AVFilterContext *ctx)
if (ret < 0)
return ret;
+if (scale->in_primaries != -1 && !sws_test_primaries(scale->in_primaries,
0)) {
+av_log(ctx, AV_LOG_ERROR, "Unsupported input primaries '%s'\n",
+ av_color_primaries_name(scale->in_primaries));
+return AVERROR(EINVAL);
+}
+
+if (scale->out_primaries != -1 &&
!sws_test_primaries(scale->out_primaries, 1)) {
+av_log(ctx, AV_LOG_ERROR, "Unsupported output primaries '%s'\n",
+ av_color_primaries_name(scale->out_primaries));
+return AVERROR(EINVAL);
+}
+
+if (scale->in_transfer != -1 && !sws_test_transfer(scale->in_transfer, 0))
{
+av_log(ctx, AV_LOG_ERROR, "Unsupported input transfer '%s'\n",
+ av_color_transfer_name(scale->in_transfer));
+return AVERROR(EINVAL);
+}
+
+if (scale->out_transfer != -1 && !sws_test_transfer(scale->out_transfer,
1)) {
+av_log(ctx, AV_LOG_ERROR, "Unsupported output transfer '%s'\n",
+ av_color_transfer_name(scale->out_transfer));
+return AVERROR(EINVAL);
+}
+
if (scale->in_color_matrix != -1 &&
!sws_test_colorspace(scale->in_color_matrix, 0)) {
av_log(ctx, AV_LOG_ERROR, "Unsupported input color matrix '%s'\n",
av_color_space_name(scale->in_color_matrix));
@@ -815,6 +842,10 @@ scale:
if (scale->in_color_matrix != -1)
in->colorspace = scale->in_color_matrix;
+if (scale->in_primaries != -1)
+in->color_primaries = scale->in_primaries;
+if (scale->in_transfer != -1)
+in->color_trc = scale->in_transfer;
if (scale->in_range != AVCOL_RANGE_UNSPECIFIED)
in->color_range = scale->in_range;
in->chroma_location = scale->in_chroma_loc;
@@ -832,6 +863,10 @@ scale:
out->colorspace = outlink->colorspace;
if (scale->out_chroma_loc != AVCHROMA_LOC_UNSPECIFIED)
out->chroma_location = scale->out_chroma_loc;
+if (scale->out_primaries != -1)
+out->color_primaries = scale->out_primaries;
+if (scale->out_transfer != -1)
+out->color_trc = scale->out_transfer;
av_reduce(&out->sample_aspect_ratio.num, &out->sample_aspect_ratio.den,
(int64_t)in->sample_aspect_ratio.num * outlink->h * link->w,
@@ -1084,6 +1119,42 @@ static const AVOption scale_options[] = {
{"top", NULL, 0, AV_OPT_TYPE_CONST, {.i64=AVCHROMA_LOC_TOP},
0, 0, FLAGS, .unit = "chroma_loc"},
{"bottomleft",NULL, 0, AV_OPT_TYPE_CONST,
{.i64=AVCHROMA_LOC_BOTTOMLEFT}, 0, 0, FLAGS, .unit = "chroma_loc"},
{"bottom",NULL, 0, AV_OPT_TYPE_CONST,
{.i64=AVCHROMA_LOC_BOTTOM}, 0, 0, FLAGS, .unit = "chroma_loc"},
+
[FFmpeg-devel] [PATCH v2 07/17] swscale/utils: fix XYZ primaries tagging
From: Niklas Haas
Swscale currently handles XYZ by embedding a forced conversion to
BT.709 RGB with a hardcoded matrix. This is not ideal, but to preserve the
status quo and avoid any unexpected changes in behavior, this patch merely
fixes the inferred primaries tag to match the reality.
In the future, I would like to handle XYZ properly, via direct conversion
to the target colorspace (or possibly simply by using a more fitting
RGB intermediate like SMPTE428), but for now just keep the status quo.
---
libswscale/utils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libswscale/utils.c b/libswscale/utils.c
index adbfda10a5..01c21c74d8 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -2684,7 +2684,7 @@ SwsFormat ff_fmt_from_frame(const AVFrame *frame, int
field)
} else if (desc->flags & AV_PIX_FMT_FLAG_XYZ) {
fmt.csp = AVCOL_SPC_UNSPECIFIED;
fmt.color = (SwsColor) {
-.prim = AVCOL_PRI_SMPTE428,
+.prim = AVCOL_PRI_BT709, /* swscale currently hard-codes this XYZ
matrix */
.trc = AVCOL_TRC_SMPTE428,
};
} else if (desc->nb_components < 3) {
--
2.47.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 10/17] avfilter/vf_scale: make options alignment consistent (cosmetic)
From: Niklas Haas
---
libavfilter/vf_scale.c | 48 +-
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index d4236f4b6c..77697f3f6a 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -1091,34 +1091,34 @@ static const AVOption scale_options[] = {
{ "s", "set video size", OFFSET(size_str),
AV_OPT_TYPE_STRING, {.str = NULL}, 0, .flags = FLAGS },
{ "in_color_matrix", "set input YCbCr type", OFFSET(in_color_matrix),
AV_OPT_TYPE_INT, { .i64 = -1 }, -1, AVCOL_SPC_NB-1, .flags = FLAGS, .unit =
"color" },
{ "out_color_matrix", "set output YCbCr type", OFFSET(out_color_matrix),
AV_OPT_TYPE_INT, { .i64 = AVCOL_SPC_UNSPECIFIED }, 0, AVCOL_SPC_NB-1, .flags =
FLAGS, .unit = "color"},
-{ "auto",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = -1 },
0, 0, FLAGS, .unit = "color" },
-{ "bt601", NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
AVCOL_SPC_BT470BG }, 0, 0, FLAGS, .unit = "color" },
-{ "bt470", NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
AVCOL_SPC_BT470BG }, 0, 0, FLAGS, .unit = "color" },
-{ "smpte170m", NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
AVCOL_SPC_BT470BG }, 0, 0, FLAGS, .unit = "color" },
-{ "bt709", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AVCOL_SPC_BT709
},0, 0, FLAGS, .unit = "color" },
-{ "fcc", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AVCOL_SPC_FCC },
0, 0, FLAGS, .unit = "color" },
-{ "smpte240m", NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
AVCOL_SPC_SMPTE240M },0, 0, FLAGS, .unit = "color" },
-{ "bt2020", NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
AVCOL_SPC_BT2020_NCL }, 0, 0, FLAGS, .unit = "color" },
+{ "auto",NULL, 0, AV_OPT_TYPE_CONST, {.i64=-1},
0, 0, FLAGS, .unit = "color" },
+{ "bt601", NULL, 0, AV_OPT_TYPE_CONST, {.i64=AVCOL_SPC_BT470BG},
0, 0, FLAGS, .unit = "color" },
+{ "bt470", NULL, 0, AV_OPT_TYPE_CONST, {.i64=AVCOL_SPC_BT470BG},
0, 0, FLAGS, .unit = "color" },
+{ "smpte170m", NULL, 0, AV_OPT_TYPE_CONST, {.i64=AVCOL_SPC_BT470BG},
0, 0, FLAGS, .unit = "color" },
+{ "bt709", NULL, 0, AV_OPT_TYPE_CONST, {.i64=AVCOL_SPC_BT709},
0, 0, FLAGS, .unit = "color" },
+{ "fcc", NULL, 0, AV_OPT_TYPE_CONST, {.i64=AVCOL_SPC_FCC},
0, 0, FLAGS, .unit = "color" },
+{ "smpte240m", NULL, 0, AV_OPT_TYPE_CONST,
{.i64=AVCOL_SPC_SMPTE240M}, 0, 0, FLAGS, .unit = "color" },
+{ "bt2020", NULL, 0, AV_OPT_TYPE_CONST,
{.i64=AVCOL_SPC_BT2020_NCL}, 0, 0, FLAGS, .unit = "color" },
{ "in_range", "set input color range", OFFSET( in_range),
AV_OPT_TYPE_INT, {.i64 = AVCOL_RANGE_UNSPECIFIED }, 0, 2, FLAGS, .unit =
"range" },
{ "out_range", "set output color range", OFFSET(out_range),
AV_OPT_TYPE_INT, {.i64 = AVCOL_RANGE_UNSPECIFIED }, 0, 2, FLAGS, .unit =
"range" },
-{ "auto", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = AVCOL_RANGE_UNSPECIFIED },
0, 0, FLAGS, .unit = "range" },
-{ "unknown", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = AVCOL_RANGE_UNSPECIFIED
}, 0, 0, FLAGS, .unit = "range" },
-{ "full", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = AVCOL_RANGE_JPEG}, 0, 0,
FLAGS, .unit = "range" },
-{ "limited",NULL, 0, AV_OPT_TYPE_CONST, {.i64 = AVCOL_RANGE_MPEG}, 0, 0,
FLAGS, .unit = "range" },
-{ "jpeg", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = AVCOL_RANGE_JPEG}, 0, 0,
FLAGS, .unit = "range" },
-{ "mpeg", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = AVCOL_RANGE_MPEG}, 0, 0,
FLAGS, .unit = "range" },
-{ "tv", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = AVCOL_RANGE_MPEG}, 0, 0,
FLAGS, .unit = "range" },
-{ "pc", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = AVCOL_RANGE_JPEG}, 0, 0,
FLAGS, .unit = "range" },
+{ "auto",NULL, 0, AV_OPT_TYPE_CONST,
{.i64=AVCOL_RANGE_UNSPECIFIED }, 0, 0, FLAGS, .unit = "range" },
+{ "unknown", NULL, 0, AV_OPT_TYPE_CONST,
{.i64=AVCOL_RANGE_UNSPECIFIED }, 0, 0, FLAGS, .unit = "range" },
+{ "full",NULL, 0, AV_OPT_TYPE_CONST, {.i64=AVCOL_RANGE_JPEG},
0, 0, FLAGS, .unit = "range" },
+{ "limited", NULL, 0, AV_OPT_TYPE_CONST, {.i64=AVCOL_RANGE_MPEG},
0, 0, FLAGS, .unit = "range" },
+{ "jpeg",NULL, 0, AV_OPT_TYPE_CONST, {.i64=AVCOL_RANGE_JPEG},
0, 0, FLAGS, .unit = "range" },
+{ "mpeg",NULL, 0, AV_OPT_TYPE_CONST, {.i64=AVCOL_RANGE_MPEG},
0, 0, FLAGS, .unit = "range" },
+{ "tv", NULL, 0, AV_OPT_TYPE_CONST, {.i64=AVCOL_RANGE_MPEG},
0, 0, FLAGS, .unit = "range" },
+{ "pc", NULL, 0, AV_OPT_TYPE_CONST, {.i64=AVCOL_RANGE_JPEG},
0, 0, FLAGS, .unit = "range" },
{ "in_chroma_loc", "set input chroma sample location",
OFFSET(in_chroma_loc), AV_OPT_TYPE_INT,
[FFmpeg-devel] [PATCH v2 06/17] swscale/utils: add helper function to infer colorspace metadata
From: Niklas Haas
Logic is loosely on equivalent decisions in libplacebo. The basic idea is to try
and be a bit conservative by treating AVCOL_*_UNSPECIFIED as a no-op, unless the
other primaries set are non-standard / wide-gamut or HDR. This helps avoid
unintended or unexpected colorspace conversions, while forcing it in cases where
we are almost certain it is needed. The major departure from libplacebo
semantics
is that we no default to a 1000:1 contrast ration for SDR displays, instead
modelling
them as idealized devices with an infinite contrast ratio.
In either case, setting SWS_STRICT overrides this behavior in favor of always
requiring explicit colorspace metadata.
---
libswscale/utils.c | 66 ++
libswscale/utils.h | 3 +++
2 files changed, 69 insertions(+)
diff --git a/libswscale/utils.c b/libswscale/utils.c
index b097ec51b2..adbfda10a5 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -2802,6 +2802,72 @@ skip_hdr10:
return fmt;
}
+static int infer_prim_ref(SwsColor *csp, const SwsColor *ref)
+{
+if (csp->prim != AVCOL_PRI_UNSPECIFIED)
+return 0;
+
+/* Re-use the reference gamut only for "safe", similar primaries */
+switch (ref->prim) {
+case AVCOL_PRI_BT709:
+case AVCOL_PRI_BT470M:
+case AVCOL_PRI_BT470BG:
+case AVCOL_PRI_SMPTE170M:
+case AVCOL_PRI_SMPTE240M:
+csp->prim = ref->prim;
+csp->gamut = ref->gamut;
+break;
+default:
+csp->prim = AVCOL_PRI_BT709;
+csp->gamut = av_csp_primaries_desc_from_id(csp->prim)->prim;
+break;
+}
+
+return 1;
+}
+
+static int infer_trc_ref(SwsColor *csp, const SwsColor *ref)
+{
+if (csp->trc != AVCOL_TRC_UNSPECIFIED)
+return 0;
+
+/* Pick a suitable SDR transfer function, to try and minimize conversions
*/
+switch (ref->trc) {
+case AVCOL_TRC_UNSPECIFIED:
+/* HDR curves, never default to these */
+case AVCOL_TRC_SMPTE2084:
+case AVCOL_TRC_ARIB_STD_B67:
+csp->trc = AVCOL_TRC_BT709;
+csp->min_luma = av_make_q(0, 1);
+csp->max_luma = av_make_q(203, 1);
+break;
+default:
+csp->trc = ref->trc;
+csp->min_luma = ref->min_luma;
+csp->max_luma = ref->max_luma;
+break;
+}
+
+return 1;
+}
+
+int ff_infer_colors(SwsColor *src, SwsColor *dst)
+{
+int incomplete = 0;
+
+incomplete |= infer_prim_ref(dst, src);
+incomplete |= infer_prim_ref(src, dst);
+av_assert0(src->prim != AVCOL_PRI_UNSPECIFIED);
+av_assert0(dst->prim != AVCOL_PRI_UNSPECIFIED);
+
+incomplete |= infer_trc_ref(dst, src);
+incomplete |= infer_trc_ref(src, dst);
+av_assert0(src->trc != AVCOL_TRC_UNSPECIFIED);
+av_assert0(dst->trc != AVCOL_TRC_UNSPECIFIED);
+
+return incomplete;
+}
+
int sws_test_format(enum AVPixelFormat format, int output)
{
return output ? sws_isSupportedOutput(format) :
sws_isSupportedInput(format);
diff --git a/libswscale/utils.h b/libswscale/utils.h
index 52b1e67644..45adbad820 100644
--- a/libswscale/utils.h
+++ b/libswscale/utils.h
@@ -112,4 +112,7 @@ static inline int ff_fmt_align(enum AVPixelFormat fmt)
int ff_test_fmt(const SwsFormat *fmt, int output);
+/* Returns 1 if the formats are incomplete, 0 otherwise */
+int ff_infer_colors(SwsColor *src, SwsColor *dst);
+
#endif /* SWSCALE_UTILS_H */
--
2.47.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 11/17] avfilter/vf_scale: strip metadata when changing colorspace
From: Niklas Haas
This is no longer relevant after a change in color space.
---
libavfilter/vf_scale.c | 12
1 file changed, 12 insertions(+)
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index 77697f3f6a..566bf11cda 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -868,6 +868,18 @@ scale:
if (scale->out_transfer != -1)
out->color_trc = scale->out_transfer;
+if (in->color_primaries != out->color_primaries ||
+in->color_trc != out->color_trc)
+{
+av_frame_remove_side_data(out,
AV_FRAME_DATA_MASTERING_DISPLAY_METADATA);
+av_frame_remove_side_data(out, AV_FRAME_DATA_DYNAMIC_HDR_PLUS);
+av_frame_remove_side_data(out, AV_FRAME_DATA_DYNAMIC_HDR_VIVID);
+av_frame_remove_side_data(out, AV_FRAME_DATA_CONTENT_LIGHT_LEVEL);
+av_frame_remove_side_data(out, AV_FRAME_DATA_ICC_PROFILE);
+av_frame_remove_side_data(out, AV_FRAME_DATA_DOVI_METADATA);
+av_frame_remove_side_data(out, AV_FRAME_DATA_DOVI_RPU_BUFFER);
+}
+
av_reduce(&out->sample_aspect_ratio.num, &out->sample_aspect_ratio.den,
(int64_t)in->sample_aspect_ratio.num * outlink->h * link->w,
(int64_t)in->sample_aspect_ratio.den * outlink->w * link->h,
--
2.47.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] swscale/utils: fix sws_getCachedContext check
From: Niklas Haas
This logic was inverted, but || was not replaced by &&.
Fixes: ed5dd675624c83d9c69b406ce30e4e09f29970e3
Fixes: ticket #11353
---
libswscale/utils.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 32f90e366e..4dedbfc394 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -2548,14 +2548,14 @@ SwsContext *sws_getCachedContext(SwsContext *prev, int
srcW,
if (!param)
param = default_param;
-if (prev && (prev->src_w== srcW ||
- prev->src_h== srcH ||
- prev->src_format == srcFormat ||
- prev->dst_w== dstW ||
- prev->dst_h== dstH ||
- prev->dst_format == dstFormat ||
- prev->flags== flags ||
- prev->scaler_params[0] == param[0] ||
+if (prev && (prev->src_w== srcW &&
+ prev->src_h== srcH &&
+ prev->src_format == srcFormat &&
+ prev->dst_w== dstW &&
+ prev->dst_h== dstH &&
+ prev->dst_format == dstFormat &&
+ prev->flags== flags &&
+ prev->scaler_params[0] == param[0] &&
prev->scaler_params[1] == param[1])) {
return prev;
}
--
2.47.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avutil/vulkan_glslang: Fix build failure
From: Zhao Zhili compile_only was added since glslang 13.1.0. --- libavutil/vulkan_glslang.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavutil/vulkan_glslang.c b/libavutil/vulkan_glslang.c index 9e1b8f4d8d..9e7a33223b 100644 --- a/libavutil/vulkan_glslang.c +++ b/libavutil/vulkan_glslang.c @@ -192,7 +192,9 @@ static int glslc_shader_compile(FFVulkanContext *s, FFVkSPIRVCompiler *ctx, .optimize_size = 0, .disassemble = 0, .validate = 1, +#if ((GLSLANG_VERSION_MAJOR) >= 14) .compile_only = 0, +#endif }; #endif -- 2.46.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/4] checkasm/sw_scale: add assertion for hscale assumption
From: Niklas Haas
This code only checks hcScale. In practice this is not an issue because
the function pointers should always be identical to hyScale for the same
filter size.
Add an assertion just to make sure this assumption never regresses.
Signed-off-by: Niklas Haas
Sponsored-by: Sovereign Tech Fund
---
tests/checkasm/sw_scale.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/checkasm/sw_scale.c b/tests/checkasm/sw_scale.c
index 350f2b73d4..3d229775d7 100644
--- a/tests/checkasm/sw_scale.c
+++ b/tests/checkasm/sw_scale.c
@@ -346,6 +346,7 @@ static void check_hscale(void)
memcpy(filterAvx2, filter, sizeof(uint16_t) * (SRC_PIXELS *
MAX_FILTER_WIDTH + MAX_FILTER_WIDTH));
ff_shuffle_filter_coefficients(c, filterPosAvx, width,
filterAvx2, sws->dst_w);
+av_assert0(c->hyScale == c->hcScale);
if (check_func(c->hcScale, "hscale_%d_to_%d__fs_%d_dstW_%d",
c->srcBpc, c->dstBpc + 1, width, sws->dst_w)) {
memset(dst0, 0, SRC_PIXELS * sizeof(dst0[0]));
memset(dst1, 0, SRC_PIXELS * sizeof(dst1[0]));
--
2.47.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/4] checkasm/sw_rgb: add tests for yuv2packed{1, 2, X}
From: Niklas Haas
---
tests/checkasm/sw_rgb.c | 316
1 file changed, 316 insertions(+)
diff --git a/tests/checkasm/sw_rgb.c b/tests/checkasm/sw_rgb.c
index 05370c1e41..3b2dffc423 100644
--- a/tests/checkasm/sw_rgb.c
+++ b/tests/checkasm/sw_rgb.c
@@ -453,6 +453,306 @@ static void check_rgb_to_uv(SwsContext *sws)
}
}
+static const int packed_rgb_fmts[] = {
+AV_PIX_FMT_RGB24,
+AV_PIX_FMT_BGR24,
+AV_PIX_FMT_ARGB,
+AV_PIX_FMT_RGBA,
+AV_PIX_FMT_ABGR,
+AV_PIX_FMT_BGRA,
+AV_PIX_FMT_RGB48BE,
+AV_PIX_FMT_RGB48LE,
+AV_PIX_FMT_RGB565BE,
+AV_PIX_FMT_RGB565LE,
+AV_PIX_FMT_RGB555BE,
+AV_PIX_FMT_RGB555LE,
+AV_PIX_FMT_BGR565BE,
+AV_PIX_FMT_BGR565LE,
+AV_PIX_FMT_BGR555BE,
+AV_PIX_FMT_BGR555LE,
+AV_PIX_FMT_RGB444LE,
+AV_PIX_FMT_RGB444BE,
+AV_PIX_FMT_BGR444LE,
+AV_PIX_FMT_BGR444BE,
+AV_PIX_FMT_BGR48BE,
+AV_PIX_FMT_BGR48LE,
+AV_PIX_FMT_RGBA64BE,
+AV_PIX_FMT_RGBA64LE,
+AV_PIX_FMT_BGRA64BE,
+AV_PIX_FMT_BGRA64LE,
+AV_PIX_FMT_RGB8,
+AV_PIX_FMT_BGR8,
+AV_PIX_FMT_RGB4,
+AV_PIX_FMT_BGR4,
+AV_PIX_FMT_RGB4_BYTE,
+AV_PIX_FMT_BGR4_BYTE,
+};
+
+#define INPUT_SIZE 512
+
+static void check_yuv2packed1(SwsContext *sws)
+{
+SwsInternal *c = sws_internal(sws);
+static const int alpha_values[] = {0, 2048, 4096};
+
+declare_func_emms(AV_CPU_FLAG_MMX | AV_CPU_FLAG_MMXEXT,
+ void, SwsInternal *c, const int16_t *lumSrc,
+ const int16_t *chrUSrc[2], const int16_t *chrVSrc[2],
+ const int16_t *alpSrc, uint8_t *dest,
+ int dstW, int uvalpha, int y);
+
+const int16_t *luma;
+const int16_t *chru[2];
+const int16_t *chrv[2];
+const int16_t *alpha;
+
+LOCAL_ALIGNED_8(int32_t, src_y, [INPUT_SIZE]);
+LOCAL_ALIGNED_8(int32_t, src_u, [INPUT_SIZE]);
+LOCAL_ALIGNED_8(int32_t, src_v, [INPUT_SIZE]);
+LOCAL_ALIGNED_8(int32_t, src_a, [INPUT_SIZE]);
+
+LOCAL_ALIGNED_8(uint8_t, dst0, [INPUT_SIZE * sizeof(int32_t[4])]);
+LOCAL_ALIGNED_8(uint8_t, dst1, [INPUT_SIZE * sizeof(int32_t[4])]);
+
+randomize_buffers((uint8_t*)src_y, INPUT_SIZE * sizeof(int32_t));
+randomize_buffers((uint8_t*)src_u, INPUT_SIZE * sizeof(int32_t));
+randomize_buffers((uint8_t*)src_v, INPUT_SIZE * sizeof(int32_t));
+randomize_buffers((uint8_t*)src_a, INPUT_SIZE * sizeof(int32_t));
+
+/* Limit to 14 bit input range */
+for (int i = 0; i < INPUT_SIZE; i++) {
+src_y[i] &= 0x3FFF3FFF;
+src_a[i] &= 0x3FFF3FFF;
+src_u[i] &= 0x3FFF3FFF;
+src_v[i] &= 0x3FFF3FFF;
+src_u[i + INPUT_SIZE] &= 0x3FFF3FFF;
+src_v[i + INPUT_SIZE] &= 0x3FFF3FFF;
+}
+
+luma = (int16_t *)src_y;
+alpha = (int16_t *)src_a;
+for (int i = 0; i < 2; i++) {
+chru[i] = (int16_t *)(src_u + i*INPUT_SIZE);
+chrv[i] = (int16_t *)(src_v + i*INPUT_SIZE);
+}
+
+for (int fmi = 0; fmi < FF_ARRAY_ELEMS(packed_rgb_fmts); fmi++) {
+const AVPixFmtDescriptor *desc =
av_pix_fmt_desc_get(packed_rgb_fmts[fmi]);
+int line_size = INPUT_SIZE * desc->comp[0].step;
+if (desc->flags & AV_PIX_FMT_FLAG_BITSTREAM)
+line_size = AV_CEIL_RSHIFT(line_size, 3);
+
+sws->dst_format = packed_rgb_fmts[fmi];
+sws->dither = SWS_DITHER_NONE;
+
+/* This sets the yuv2rgb tables */
+sws_setColorspaceDetails(sws, c->srcColorspaceTable, sws->src_range,
+ c->dstColorspaceTable, sws->dst_range,
+ c->brightness, c->contrast, c->saturation);
+
+ff_sws_init_scale(c);
+
+for (int ai = 0; ai < FF_ARRAY_ELEMS(alpha_values); ai++) {
+const int chr_alpha = alpha_values[ai];
+if (check_func(c->yuv2packed1, "yuv2%s_1_%d_%d", desc->name,
chr_alpha, INPUT_SIZE)) {
+memset(dst0, 0xFF, INPUT_SIZE * sizeof(int32_t[4]));
+memset(dst1, 0xFF, INPUT_SIZE * sizeof(int32_t[4]));
+
+call_ref(c, luma, chru, chrv, alpha, dst0, INPUT_SIZE,
chr_alpha, 0);
+call_new(c, luma, chru, chrv, alpha, dst1, INPUT_SIZE,
chr_alpha, 0);
+
+if (memcmp(dst0, dst1, line_size))
+fail();
+
+bench_new(c, luma, chru, chrv, alpha, dst1, INPUT_SIZE,
chr_alpha, 0);
+}
+}
+}
+}
+
+static void check_yuv2packed2(SwsContext *sws)
+{
+SwsInternal *c = sws_internal(sws);
+static const int alpha_values[] = {0, 2048, 4096};
+
+declare_func_emms(AV_CPU_FLAG_MMX | AV_CPU_FLAG_MMXEXT,
+ void, SwsInternal *c, const int16_t *lumSrc[2],
+ const int16_t *chrUSrc[2], const int16_t *chrVSrc[2],
+ const int16_t *alpSrc[2], uint8_t *dest,
+ int dstW, int yalpha, int uvalpha, int y);
+
[FFmpeg-devel] [PATCH 2/4] checkasm/sw_scale: add test for yuv2nv12cX
From: Niklas Haas
Mirroring yuv2yuvX.
---
tests/checkasm/sw_scale.c | 74 +++
1 file changed, 74 insertions(+)
diff --git a/tests/checkasm/sw_scale.c b/tests/checkasm/sw_scale.c
index 3d229775d7..11c9174a6b 100644
--- a/tests/checkasm/sw_scale.c
+++ b/tests/checkasm/sw_scale.c
@@ -256,6 +256,77 @@ static void check_yuv2yuvX(int accurate)
#undef FILTER_SIZES
}
+static void check_yuv2nv12cX(int accurate)
+{
+SwsContext *sws;
+SwsInternal *c;
+#define LARGEST_FILTER 16
+const int filter_sizes[] = {2, 4, 8, 16};
+#define LARGEST_INPUT_SIZE 512
+static const int input_sizes[] = {8, 24, 128, 144, 256, 512};
+const char *accurate_str = (accurate) ? "accurate" : "approximate";
+
+declare_func_emms(AV_CPU_FLAG_MMX, void, enum AVPixelFormat dstFormat,
+ const uint8_t *chrDither, const int16_t *chrFilter,
+ int chrFilterSize, const int16_t **chrUSrc,
+ const int16_t **chrVSrc, uint8_t *dest, int dstW);
+
+const int16_t *srcU[LARGEST_FILTER], *srcV[LARGEST_FILTER];
+LOCAL_ALIGNED_16(int16_t, srcU_pixels, [LARGEST_FILTER *
LARGEST_INPUT_SIZE]);
+LOCAL_ALIGNED_16(int16_t, srcV_pixels, [LARGEST_FILTER *
LARGEST_INPUT_SIZE]);
+LOCAL_ALIGNED_16(int16_t, filter_coeff, [LARGEST_FILTER]);
+LOCAL_ALIGNED_16(uint8_t, dst0, [LARGEST_INPUT_SIZE * 2]);
+LOCAL_ALIGNED_16(uint8_t, dst1, [LARGEST_INPUT_SIZE * 2]);
+LOCAL_ALIGNED_16(uint8_t, dither, [LARGEST_INPUT_SIZE]);
+uint8_t d_val = rnd();
+memset(dither, d_val, LARGEST_INPUT_SIZE);
+randomize_buffers((uint8_t*)srcU_pixels, LARGEST_FILTER *
LARGEST_INPUT_SIZE * sizeof(int16_t));
+randomize_buffers((uint8_t*)srcV_pixels, LARGEST_FILTER *
LARGEST_INPUT_SIZE * sizeof(int16_t));
+for (int i = 0; i < LARGEST_FILTER; i++) {
+srcU[i] = &srcU_pixels[i * LARGEST_INPUT_SIZE];
+srcV[i] = &srcV_pixels[i * LARGEST_INPUT_SIZE];
+}
+
+sws = sws_alloc_context();
+sws->dst_format = AV_PIX_FMT_NV12;
+if (accurate)
+sws->flags |= SWS_ACCURATE_RND;
+if (sws_init_context(sws, NULL, NULL) < 0)
+fail();
+
+c = sws_internal(sws);
+ff_sws_init_scale(c);
+for (int isi = 0; isi < FF_ARRAY_ELEMS(input_sizes); isi++){
+const int dstW = input_sizes[isi];
+for (int fsi = 0; fsi < FF_ARRAY_ELEMS(filter_sizes); fsi++) {
+const int filter_size = filter_sizes[fsi];
+for (int i = 0; i < filter_size; i++)
+filter_coeff[i] = -((1 << 12) / (filter_size - 1));
+filter_coeff[rnd() % filter_size] = (1 << 13) - 1;
+
+if (check_func(c->yuv2nv12cX, "yuv2nv12cX_%d_%d_%s", filter_size,
dstW, accurate_str)){
+memset(dst0, 0, LARGEST_INPUT_SIZE * sizeof(dst0[0]));
+memset(dst1, 0, LARGEST_INPUT_SIZE * sizeof(dst1[0]));
+
+call_ref(sws->dst_format, dither, &filter_coeff[0],
filter_size, srcU, srcV, dst0, dstW);
+call_new(sws->dst_format, dither, &filter_coeff[0],
filter_size, srcU, srcV, dst1, dstW);
+
+if (cmp_off_by_n(dst0, dst1, dstW * 2 * sizeof(dst0[0]),
accurate ? 0 : 2)) {
+fail();
+printf("failed: yuv2nv12wX_%d_%d_%s\n", filter_size, dstW,
accurate_str);
+show_differences(dst0, dst1, dstW * 2 * sizeof(dst0[0]));
+}
+if (dstW == LARGEST_INPUT_SIZE)
+bench_new(sws->dst_format, dither, &filter_coeff[0],
filter_size, srcU, srcV, dst1, dstW);
+
+}
+}
+}
+sws_freeContext(sws);
+}
+#undef LARGEST_FILTER
+#undef LARGEST_INPUT_SIZE
+
#undef SRC_PIXELS
#define SRC_PIXELS 512
@@ -373,4 +444,7 @@ void checkasm_check_sw_scale(void)
check_yuv2yuvX(0);
check_yuv2yuvX(1);
report("yuv2yuvX");
+check_yuv2nv12cX(0);
+check_yuv2nv12cX(1);
+report("yuv2nv12cX");
}
--
2.47.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 4/4] checkasm/sw_rgb: add alpToYV12 check
From: Niklas Haas
Mirroring lumToYV12 and chrToYV12.
---
tests/checkasm/sw_rgb.c | 47 +
1 file changed, 47 insertions(+)
diff --git a/tests/checkasm/sw_rgb.c b/tests/checkasm/sw_rgb.c
index 3b2dffc423..5450a7953d 100644
--- a/tests/checkasm/sw_rgb.c
+++ b/tests/checkasm/sw_rgb.c
@@ -453,6 +453,50 @@ static void check_rgb_to_uv(SwsContext *sws)
}
}
+static void check_rgba_to_a(SwsContext *sws)
+{
+SwsInternal *ctx = sws_internal(sws);
+
+LOCAL_ALIGNED_16(uint8_t, src, [MAX_LINE_SIZE * 4]);
+LOCAL_ALIGNED_32(uint8_t, dst0_y, [MAX_LINE_SIZE * 2]);
+LOCAL_ALIGNED_32(uint8_t, dst1_y, [MAX_LINE_SIZE * 2]);
+
+declare_func(void, uint8_t *dst, const uint8_t *src1,
+ const uint8_t *src2, const uint8_t *src3, int width,
+ uint32_t *rgb2yuv, void *opq);
+
+randomize_buffers(src, MAX_LINE_SIZE * 4);
+
+for (int i = 0; i < FF_ARRAY_ELEMS(rgb_formats); i++) {
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(rgb_formats[i]);
+if (desc->nb_components < 4)
+continue;
+
+sws->src_format = rgb_formats[i];
+ff_sws_init_scale(ctx);
+
+for (int j = 0; j < FF_ARRAY_ELEMS(input_sizes); j++) {
+int w = input_sizes[j];
+
+if (check_func(ctx->alpToYV12, "%s_to_y_%d", desc->name, w)) {
+memset(dst0_y, 0xFA, MAX_LINE_SIZE * 2);
+memset(dst1_y, 0xFA, MAX_LINE_SIZE * 2);
+
+call_ref(dst0_y, NULL, NULL, src, w, ctx->input_rgb2yuv_table,
NULL);
+call_new(dst1_y, NULL, NULL, src, w, ctx->input_rgb2yuv_table,
NULL);
+
+if (memcmp(dst0_y, dst1_y, w * 2))
+fail();
+
+// only bench native endian formats
+if (sws->src_format == AV_PIX_FMT_RGB32 || sws->src_format ==
AV_PIX_FMT_RGB32_1)
+bench_new(dst1_y, NULL, NULL, src, w,
ctx->input_rgb2yuv_table, NULL);
+}
+}
+}
+}
+
+
static const int packed_rgb_fmts[] = {
AV_PIX_FMT_RGB24,
AV_PIX_FMT_BGR24,
@@ -795,6 +839,9 @@ void checkasm_check_sw_rgb(void)
check_rgb_to_uv(sws);
report("rgb_to_uv");
+check_rgba_to_a(sws);
+report("rgba_to_a");
+
check_rgb24toyv12(sws);
report("rgb24toyv12");
--
2.47.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/6] lavf/mov: Always try to parse mfra if file contains moof boxes
mån 2024-12-16 klockan 16:23 +0100 skrev Tomas Härdin: > Updated patchset. Patches 1-2 could maybe be squashed > > The end result of these patches is that fragmented files probe much > faster over HTTP. The final patch is just a small optimization to > movenc Darn, this breaks fate-vc1-ism. But it is broken also with - use_mfra_for in master, so this is indicative of some other deeper problem /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] libavcodec/sanm: SMUSH codec48 decoder
Adds a decoder for the SMUSH codec48 video encoding, as is used by
the LucasArts game "Mysteries of the Sith".
Signed-off-by: Manuel Lauss
---
libavcodec/sanm.c | 223 ++
1 file changed, 223 insertions(+)
diff --git a/libavcodec/sanm.c b/libavcodec/sanm.c
index 8bcffb1e90..a278ef24b1 100644
--- a/libavcodec/sanm.c
+++ b/libavcodec/sanm.c
@@ -995,6 +995,227 @@ static int old_codec47(SANMVideoContext *ctx, int top,
return 0;
}
+// scale 4x4 input block to an 8x8 output block
+static void c48_4to8(uint8_t *dst, const uint8_t *src, const uint16_t w)
+{
+uint16_t p;
+// dst is always at least 16bit aligned
+for (int i = 0; i < 4; i++) {
+for (int j = 0; j < 8; j += 2) {
+p = *src++;
+p = (p << 8) | p;
+*((uint16_t *)(dst + w * 0 + j)) = p;
+*((uint16_t *)(dst + w * 1 + j)) = p;
+}
+dst += w * 2;
+}
+}
+
+static int codec48_block(SANMVideoContext *ctx, uint8_t *dst, uint8_t *db,
+ const uint16_t w)
+{
+uint8_t opc, sb[16];
+int i, j, k, l;
+int16_t mvofs;
+uint32_t ofs;
+
+if (bytestream2_get_bytes_left(&ctx->gb) < 1)
+return 1;
+
+opc = bytestream2_get_byteu(&ctx->gb);
+switch (opc) {
+case 0xFF:// 1x1 -> 8x8 block scale
+if (bytestream2_get_bytes_left(&ctx->gb) < 1)
+return 1;
+
+opc = bytestream2_get_byteu(&ctx->gb);
+for (i = 0; i < 16; i++)
+sb[i] = opc;
+c48_4to8(dst, sb, w);
+break;
+case 0xFE:// 1x 8x8 copy from deltabuf, 16bit mv from source
+if (bytestream2_get_bytes_left(&ctx->gb) < 2)
+return 1;
+mvofs = bytestream2_get_le16(&ctx->gb);
+for (i = 0; i < 8; i++) {
+ofs = w * i;
+for (k = 0; k < 8; k++)
+*(dst + ofs + k) = *(db + ofs + k + mvofs);
+}
+break;
+case 0xFD:// 2x2 -> 8x8 block scale
+if (bytestream2_get_bytes_left(&ctx->gb) < 4)
+return 1;
+sb[ 5] = bytestream2_get_byteu(&ctx->gb);
+sb[ 7] = bytestream2_get_byteu(&ctx->gb);
+sb[13] = bytestream2_get_byteu(&ctx->gb);
+sb[15] = bytestream2_get_byteu(&ctx->gb);
+
+sb[0] = sb[1] = sb[4] = sb[5];
+sb[2] = sb[3] = sb[6] = sb[7];
+sb[8] = sb[9] = sb[12] = sb[13];
+sb[10] = sb[11] = sb[14] = sb[15];
+c48_4to8(dst, sb, w);
+break;
+case 0xFC:// 4x copy 4x4 block, per-block c37_mv from source
+if (bytestream2_get_bytes_left(&ctx->gb) < 4)
+return 1;
+for (i = 0; i < 8; i += 4) {
+for (k = 0; k < 8; k += 4) {
+opc = bytestream2_get_byteu(&ctx->gb);
+mvofs = c37_mv[opc * 2] + (c37_mv[opc * 2 + 1] * w);
+for (j = 0; j < 4; j++) {
+ofs = (w * (j + i)) + k;
+for (l = 0; l < 4; l++)
+*(dst + ofs + l) = *(db + ofs + l + mvofs);
+}
+}
+}
+break;
+case 0xFB:// Copy 4x 4x4 blocks, per-block mv from source
+if (bytestream2_get_bytes_left(&ctx->gb) < 8)
+return 1;
+for (i = 0; i < 8; i += 4) {
+for (k = 0; k < 8; k += 4) {
+mvofs = bytestream2_get_le16(&ctx->gb);
+for (j = 0; j < 4; j++) {
+ofs = (w * (j + i)) + k;
+for (l = 0; l < 4; l++)
+*(dst + ofs + l) = *(db + ofs + l + mvofs);
+}
+}
+}
+break;
+case 0xFA:// scale 4x4 input block to 8x8 dest block
+if (bytestream2_get_bytes_left(&ctx->gb) < 16)
+return 1;
+bytestream2_get_bufferu(&ctx->gb, sb, 16);
+c48_4to8(dst, sb, w);
+break;
+case 0xF9:// 16x 2x2 copy from delta, per-block c37_mv from source
+if (bytestream2_get_bytes_left(&ctx->gb) < 16)
+return 1;
+for (i = 0; i < 8; i += 2) {
+for (j = 0; j < 8; j += 2) {
+ofs = (w * i) + j;
+opc = bytestream2_get_byteu(&ctx->gb);
+mvofs = c37_mv[opc * 2] + (c37_mv[opc * 2 + 1] * w);
+for (l = 0; l < 2; l++) {
+*(dst + ofs + l + 0) = *(db + ofs + l + 0 + mvofs);
+*(dst + ofs + l + w) = *(db + ofs + l + w + mvofs);
+}
+}
+}
+break;
+case 0xF8:// 16x 2x2 blocks copy, 16bit mv from source
+if (bytestream2_get_bytes_left(&ctx->gb) < 32)
+return 1;
+for (i = 0; i < 8; i += 2) {
+for (j = 0; j < 8; j += 2) {
+ofs = w * i + j;
+mvofs = bytestream2_get_le16(&ctx->gb);
+for (l = 0; l < 2; l++) {
+*(dst + ofs + l + 0) = *(db + ofs + l + 0 + mvofs);
+
Re: [FFmpeg-devel] [PATCH 14/14] avformat/rtmpproto: reserve enough space for statusmsg
On 15.12.2024 23:43, Michael Niedermayer wrote:
Hi
On Thu, Dec 12, 2024 at 08:55:39PM +0100, Timo Rothenpieler wrote:
---
libavformat/rtmpproto.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/rtmpproto.c b/libavformat/rtmpproto.c
index a56fec759f..a5e877cc55 100644
--- a/libavformat/rtmpproto.c
+++ b/libavformat/rtmpproto.c
@@ -2004,7 +2004,7 @@ static int send_invoke_response(URLContext *s, RTMPPacket
*pkt)
pp = spkt.data;
ff_amf_write_string(&pp, "onFCPublish");
} else if (!strcmp(command, "publish")) {
-char statusmsg[128];
+char statusmsg[160];
can you explain why this is enough and an example why the 128 was not
(not important but if you have that info it would make the comit message
more informative)
It's basically just the max size of the buffer that's written to it,
plus the size of the other stuff in the format string, plus a bit of
padding.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] lavc/riscv: vset macro for simplify if-else
From: sunyuechi --- libavcodec/riscv/h26x/asm.S | 78 + 1 file changed, 18 insertions(+), 60 deletions(-) diff --git a/libavcodec/riscv/h26x/asm.S b/libavcodec/riscv/h26x/asm.S index d37b459f66..d99690d9a0 100644 --- a/libavcodec/riscv/h26x/asm.S +++ b/libavcodec/riscv/h26x/asm.S @@ -20,88 +20,46 @@ #include "libavutil/riscv/asm.S" -.macro vsetvlstatic8 w, vlen +.macro vsetvlstatic w, vlen, en, mn1, mn2, mn3, mn4, mn5, mn6 .if \w == 2 && \vlen == 128 -vsetivlizero, \w, e8, mf8, ta, ma +vsetivlizero, \w, \en, \mn1, ta, ma .elseif \w <= 4 && \vlen == 128 -vsetivlizero, \w, e8, mf4, ta, ma +vsetivlizero, \w, \en, \mn2, ta, ma .elseif \w <= 8 && \vlen == 128 -vsetivlizero, \w, e8, mf2, ta, ma +vsetivlizero, \w, \en, \mn3, ta, ma .elseif \w <= 16 && \vlen == 128 -vsetivlizero, \w, e8, m1, ta, ma +vsetivlizero, \w, \en, \mn4, ta, ma .elseif \w <= 32 && \vlen == 128 li t0, \w -vsetvli zero, t0, e8, m2, ta, ma +vsetvli zero, t0, \en, \mn5, ta, ma .elseif \w <= 4 && \vlen == 256 -vsetivlizero, \w, e8, mf8, ta, ma +vsetivlizero, \w, \en, \mn1, ta, ma .elseif \w <= 8 && \vlen == 256 -vsetivlizero, \w, e8, mf4, ta, ma +vsetivlizero, \w, \en, \mn2, ta, ma .elseif \w <= 16 && \vlen == 256 -vsetivlizero, \w, e8, mf2, ta, ma +vsetivlizero, \w, \en, \mn3, ta, ma .elseif \w <= 32 && \vlen == 256 li t0, \w -vsetvli zero, t0, e8, m1, ta, ma +vsetvli zero, t0, \en, \mn4, ta, ma .elseif \w <= 64 && \vlen == 256 li t0, \w -vsetvli zero, t0, e8, m2, ta, ma +vsetvli zero, t0, \en, \mn5, ta, ma .else li t0, \w -vsetvli zero, t0, e8, m4, ta, ma +vsetvli zero, t0, \en, \mn6, ta, ma .endif .endm +.macro vsetvlstatic8 w, vlen +vsetvlstatic \w, \vlen, e8, mf8, mf4, mf2, m1, m2, m4 +.endm + .macro vsetvlstatic16 w, vlen -.if \w == 2 && \vlen == 128 -vsetivlizero, \w, e16, mf4, ta, ma -.elseif \w <= 4 && \vlen == 128 -vsetivlizero, \w, e16, mf2, ta, ma -.elseif \w <= 8 && \vlen == 128 -vsetivlizero, \w, e16, m1, ta, ma -.elseif \w <= 16 && \vlen == 128 -vsetivlizero, \w, e16, m2, ta, ma -.elseif \w <= 32 && \vlen == 128 -li t0, \w -vsetvli zero, t0, e16, m4, ta, ma -.elseif \w <= 4 && \vlen == 256 -vsetivlizero, \w, e16, mf4, ta, ma -.elseif \w <= 8 && \vlen == 256 -vsetivlizero, \w, e16, mf2, ta, ma -.elseif \w <= 16 && \vlen == 256 -vsetivlizero, \w, e16, m1, ta, ma -.elseif \w <= 32 && \vlen == 256 -li t0, \w -vsetvli zero, t0, e16, m2, ta, ma -.elseif \w <= 64 && \vlen == 256 -li t0, \w -vsetvli zero, t0, e16, m4, ta, ma -.else -li t0, \w -vsetvli zero, t0, e16, m8, ta, ma -.endif +vsetvlstatic \w, \vlen, e16, mf4, mf2, m1, m2, m4, m8 .endm .macro vsetvlstatic32 w, vlen -.if \w == 2 -vsetivlizero, \w, e32, mf2, ta, ma -.elseif \w <= 4 && \vlen == 128 -vsetivlizero, \w, e32, m1, ta, ma -.elseif \w <= 8 && \vlen == 128 -vsetivlizero, \w, e32, m2, ta, ma -.elseif \w <= 16 && \vlen == 128 -vsetivlizero, \w, e32, m4, ta, ma -.elseif \w <= 4 && \vlen == 256 -vsetivlizero, \w, e32, mf2, ta, ma -.elseif \w <= 8 && \vlen == 256 -vsetivlizero, \w, e32, m1, ta, ma -.elseif \w <= 16 && \vlen == 256 -vsetivlizero, \w, e32, m2, ta, ma -.elseif \w <= 32 && \vlen == 256 -li t0, \w -vsetvli zero, t0, e32, m4, ta, ma -.else -li t0, \w -vsetvli zero, t0, e32, m8, ta, ma -.endif +vsetvlstatic \w, \vlen, e32, mf2, m1, m2, m4, m8, m8 .endm .macro POW2_JMP_TABLE id, vlen -- 2.47.1
[FFmpeg-devel] [PATCH v1] avcodec/h264_mb: Fix tmp buffer overlap in mc_part_weighted
When decoding a bitstream with weighted-bipred enabled, the results on ARM and x86 platforms may differ. The reason for the inconsistency is that the value of STRIDE_ALIGN differs between platforms. And STRIDE_ALIGN is set to the buffer stride of temporary buffers for U and V components in mc_part_weighted. If the buffer stride is 32 or 64 (as on x86 platforms), the U and V pixels can be interleaved row by row without overlapping, resulting in correct output. However, on ARM platforms where the stride is 16, the V component will overwrite part of the U component's pixels, leading to incorrect predicted pixels. Fixes: ticket 11357 Signed-off-by: Bin Peng --- libavcodec/h264_mb.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/h264_mb.c b/libavcodec/h264_mb.c index 4e94136313..b480cd312b 100644 --- a/libavcodec/h264_mb.c +++ b/libavcodec/h264_mb.c @@ -407,8 +407,8 @@ static av_always_inline void mc_part_weighted(const H264Context *h, H264SliceCon /* don't optimize for luma-only case, since B-frames usually * use implicit weights => chroma too. */ uint8_t *tmp_cb = sl->bipred_scratchpad; -uint8_t *tmp_cr = sl->bipred_scratchpad + (16 << pixel_shift); -uint8_t *tmp_y = sl->bipred_scratchpad + 16 * sl->mb_uvlinesize; +uint8_t *tmp_cr = sl->bipred_scratchpad + (16 * sl->mb_uvlinesize); +uint8_t *tmp_y = sl->bipred_scratchpad + (32 * sl->mb_uvlinesize); int refn0 = sl->ref_cache[0][scan8[n]]; int refn1 = sl->ref_cache[1][scan8[n]]; -- 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] avfilter/vf_scale: remove systematic PAL8 hack
Hi On Mon, Dec 16, 2024 at 02:57:53PM +0100, Niklas Haas wrote: > From: Niklas Haas > > This is not a good way of generating a PAL8 output. of course not but this breaks fate and features thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "You are 36 times more likely to die in a bathtub than at the hands of a terrorist. Also, you are 2.5 times more likely to become a president and 2 times more likely to become an astronaut, than to die in a terrorist attack." -- Thoughty2 signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2_2 1/6] Update R-V V vvc_mc vset to support more lengths
Thank you, Yuechi. Applied. On Sun, Dec 15, 2024 at 11:57 PM flow gg wrote: > Resolved the conflict (because #elif ARCH_WASM was newly added in master). > > 于2024年12月15日周日 23:56写道： > >> From: sunyuechi >> >> --- >> libavcodec/riscv/vvc/vvc_mc_rvv.S | 46 +++ >> 1 file changed, 23 insertions(+), 23 deletions(-) >> >> diff --git a/libavcodec/riscv/vvc/vvc_mc_rvv.S >> b/libavcodec/riscv/vvc/vvc_mc_rvv.S >> index 45f4750f82..18532616d9 100644 >> --- a/libavcodec/riscv/vvc/vvc_mc_rvv.S >> +++ b/libavcodec/riscv/vvc/vvc_mc_rvv.S >> @@ -23,25 +23,25 @@ >> .macro vsetvlstatic8 w, vlen >> .if \w == 2 && \vlen == 128 >> vsetivlizero, \w, e8, mf8, ta, ma >> -.elseif \w == 4 && \vlen == 128 >> +.elseif \w <= 4 && \vlen == 128 >> vsetivlizero, \w, e8, mf4, ta, ma >> -.elseif \w == 8 && \vlen == 128 >> +.elseif \w <= 8 && \vlen == 128 >> vsetivlizero, \w, e8, mf2, ta, ma >> -.elseif \w == 16 && \vlen == 128 >> +.elseif \w <= 16 && \vlen == 128 >> vsetivlizero, \w, e8, m1, ta, ma >> -.elseif \w == 32 && \vlen == 128 >> +.elseif \w <= 32 && \vlen == 128 >> li t0, \w >> vsetvli zero, t0, e8, m2, ta, ma >> .elseif \w <= 4 && \vlen == 256 >> vsetivlizero, \w, e8, mf8, ta, ma >> -.elseif \w == 8 && \vlen == 256 >> +.elseif \w <= 8 && \vlen == 256 >> vsetivlizero, \w, e8, mf4, ta, ma >> -.elseif \w == 16 && \vlen == 256 >> +.elseif \w <= 16 && \vlen == 256 >> vsetivlizero, \w, e8, mf2, ta, ma >> -.elseif \w == 32 && \vlen == 256 >> +.elseif \w <= 32 && \vlen == 256 >> li t0, \w >> vsetvli zero, t0, e8, m1, ta, ma >> -.elseif \w == 64 && \vlen == 256 >> +.elseif \w <= 64 && \vlen == 256 >> li t0, \w >> vsetvli zero, t0, e8, m2, ta, ma >> .else >> @@ -53,25 +53,25 @@ >> .macro vsetvlstatic16 w, vlen >> .if \w == 2 && \vlen == 128 >> vsetivlizero, \w, e16, mf4, ta, ma >> -.elseif \w == 4 && \vlen == 128 >> +.elseif \w <= 4 && \vlen == 128 >> vsetivlizero, \w, e16, mf2, ta, ma >> -.elseif \w == 8 && \vlen == 128 >> +.elseif \w <= 8 && \vlen == 128 >> vsetivlizero, \w, e16, m1, ta, ma >> -.elseif \w == 16 && \vlen == 128 >> +.elseif \w <= 16 && \vlen == 128 >> vsetivlizero, \w, e16, m2, ta, ma >> -.elseif \w == 32 && \vlen == 128 >> +.elseif \w <= 32 && \vlen == 128 >> li t0, \w >> vsetvli zero, t0, e16, m4, ta, ma >> .elseif \w <= 4 && \vlen == 256 >> vsetivlizero, \w, e16, mf4, ta, ma >> -.elseif \w == 8 && \vlen == 256 >> +.elseif \w <= 8 && \vlen == 256 >> vsetivlizero, \w, e16, mf2, ta, ma >> -.elseif \w == 16 && \vlen == 256 >> +.elseif \w <= 16 && \vlen == 256 >> vsetivlizero, \w, e16, m1, ta, ma >> -.elseif \w == 32 && \vlen == 256 >> +.elseif \w <= 32 && \vlen == 256 >> li t0, \w >> vsetvli zero, t0, e16, m2, ta, ma >> -.elseif \w == 64 && \vlen == 256 >> +.elseif \w <= 64 && \vlen == 256 >> li t0, \w >> vsetvli zero, t0, e16, m4, ta, ma >> .else >> @@ -83,19 +83,19 @@ >> .macro vsetvlstatic32 w, vlen >> .if \w == 2 >> vsetivlizero, \w, e32, mf2, ta, ma >> -.elseif \w == 4 && \vlen == 128 >> +.elseif \w <= 4 && \vlen == 128 >> vsetivlizero, \w, e32, m1, ta, ma >> -.elseif \w == 8 && \vlen == 128 >> +.elseif \w <= 8 && \vlen == 128 >> vsetivlizero, \w, e32, m2, ta, ma >> -.elseif \w == 16 && \vlen == 128 >> +.elseif \w <= 16 && \vlen == 128 >> vsetivlizero, \w, e32, m4, ta, ma >> -.elseif \w == 4 && \vlen == 256 >> +.elseif \w <= 4 && \vlen == 256 >> vsetivlizero, \w, e32, mf2, ta, ma >> -.elseif \w == 8 && \vlen == 256 >> +.elseif \w <= 8 && \vlen == 256 >> vsetivlizero, \w, e32, m1, ta, ma >> -.elseif \w == 16 && \vlen == 256 >> +.elseif \w <= 16 && \vlen == 256 >> vsetivlizero, \w, e32, m2, ta, ma >> -.elseif \w == 32 && \vlen == 256 >> +.elseif \w <= 32 && \vlen == 256 >> li t0, \w >>
Re: [FFmpeg-devel] [PATCH v2 0/3] Make fate tests succeed with zlib-ng
On Tue, Dec 17, 2024 at 4:02 AM Leo Izen wrote: > On 12/16/24 5:50 PM, Michael Niedermayer wrote: > > > > (c): implement enough of zlib ourselfs, so it can encode to a valid output > > A reimplementation of zlib that does nothing except for fixing FATE > failures that shouldn't be failing anyway sounds like a security > vulnerability waiting to happen. Stock maddler's zlib still has > vulnerabilities occur and there's the whole world's eyes on it. This > sounds like a bad idea. I think the keyword from "implement enough of zlib ourselfs" is "enough", in this case for uncompressed data. IIRC it's just 5 bytes + uncompressed data for each chunk, which should be pretty simple. I also don't think we should aim to reimplement zlib. ___ ffmpeg-devel mailing list ffmpeg-devel@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] SCaLE booth
Le sunnuntaina 15. joulukuuta 2024, 22.17.27 EET Alexander Strasser via ffmpeg- devel a écrit : > Hi Rémi! > > On 2024-11-19 19:10 +0200, Rémi Denis-Courmont wrote: > > I plan to solicit an FFmpeg booth at SCaLE 22x to be held early next > > March. > > Booths for open-source communities are free and include 5 full conference > > passes. The exhibition area is open, and needs to be manned, on Friday > > afternoon (14-18), Saturday (10-18) and Sunday morning (10-14). > > > > If anyone is interested in participating, please contact me off list. > > Please note that: > > 1) Although I don't expect any issue, this is not confirmed yet. > > 2) SCaLE will not sponsor anyone. If you need sponsorship, please check > > with FFmpeg's treasurer (who is not me). > > Sounds cool! > > Did you ask for a both? In my experience, the conference organizers will sort those out in January, so not yet. But having said that, if I don't get any volunteer other than me, I won't apply for one anyway (or I will, but on behalf of VideoLAN, not FFmpeg). Two people is the bare functional minimum, 3-4 is best. -- 雷米‧德尼-库尔蒙 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 v2] avutil/vulkan_glslang: Fix build failure
From: Zhao Zhili compile_only isn't available until 13.1.0. Let default initialization set it to zero, so the code works with version before and after 13.1.0. --- libavutil/vulkan_glslang.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavutil/vulkan_glslang.c b/libavutil/vulkan_glslang.c index 9e1b8f4d8d..d116b35ec5 100644 --- a/libavutil/vulkan_glslang.c +++ b/libavutil/vulkan_glslang.c @@ -192,7 +192,7 @@ static int glslc_shader_compile(FFVulkanContext *s, FFVkSPIRVCompiler *ctx, .optimize_size = 0, .disassemble = 0, .validate = 1, -.compile_only = 0, +/* .compile_only = 0, */ }; #endif -- 2.46.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil/vulkan_glslang: Fix build failure
> On Dec 17, 2024, at 11:04, Lynne via ffmpeg-devel > wrote: > > On 17/12/2024 11:42, Zhao Zhili wrote: >>> On Dec 17, 2024, at 09:12, Lynne via ffmpeg-devel >>> wrote: >>> >>> On 16/12/2024 20:55, Zhao Zhili wrote: From: Zhao Zhili compile_only was added since glslang 13.1.0. --- libavutil/vulkan_glslang.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavutil/vulkan_glslang.c b/libavutil/vulkan_glslang.c index 9e1b8f4d8d..9e7a33223b 100644 --- a/libavutil/vulkan_glslang.c +++ b/libavutil/vulkan_glslang.c @@ -192,7 +192,9 @@ static int glslc_shader_compile(FFVulkanContext *s, FFVkSPIRVCompiler *ctx, .optimize_size = 0, .disassemble = 0, .validate = 1, +#if ((GLSLANG_VERSION_MAJOR) >= 14) .compile_only = 0, +#endif }; #endif >>> >>> >>> The changelog reads: >>> Release 13.1.1 Initialize compile_only field in C interface >> That’s for a variable inside the implementation of >> glslang_program_SPIRV_generate() >> https://github.com/KhronosGroup/glslang/commit/fd1f96d2020496760290e5cef5d68ae83e5dd5c4 >> While we are using glslang_program_SPIRV_generate_with_options(). >> We can’t just check less than 13.1.1, as the compile_only was added since >> 13.1.0. But we can >> just remove “.compile_only = 0”, and let default initialization kick in. >> Keep the explicit initialize of >> compile_only is for clarity. I can remove it if you prefer clean and less >> conditional compile. >>> >>> It's initialized to 0 in the new version. >>> https://github.com/KhronosGroup/glslang/commit/fd1f96d2020496760290e5cef5d68ae83e5dd5c4 >>> >>> Shouldn't this check for the version being **less than** 13.1.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". >>> > > Ah, I see. > We should just keep it as-is. We'll never be using compile-only without > linking. Patch v2: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-December/337583.html > > Besides, the plan is to switch to Slang as soon as its viable and rm -rf all > glslang/shaderc compilation code. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2_2 6/6] lavc/vvc_mc R-V V sad
Le sunnuntaina 15. joulukuuta 2024, 17.56.34 EET uk7b-at-foxmail@ffmpeg.org a écrit : > From: sunyuechi > > k230 banana_f3 > sad_8x16_c: 387.7 ( 1.00x)394.9 ( 1.00x) > sad_8x16_rvv_i32: 109.7 ( 3.53x)103.5 ( 3.82x) > sad_16x8_c: 378.2 ( 1.00x)384.7 ( 1.00x) > sad_16x8_rvv_i32:82.0 ( 4.61x)61.7 ( 6.24x) > sad_16x16_c:748.7 ( 1.00x)759.7 ( 1.00x) > sad_16x16_rvv_i32: 128.5 ( 5.83x)113.7 ( 6.68x) > --- > libavcodec/riscv/vvc/Makefile | 3 +- > libavcodec/riscv/vvc/vvc_sad_rvv.S | 61 ++ > libavcodec/riscv/vvc/vvcdsp_init.c | 7 > 3 files changed, 70 insertions(+), 1 deletion(-) > create mode 100644 libavcodec/riscv/vvc/vvc_sad_rvv.S > > diff --git a/libavcodec/riscv/vvc/Makefile b/libavcodec/riscv/vvc/Makefile > index 582b051579..6b9c618b33 100644 > --- a/libavcodec/riscv/vvc/Makefile > +++ b/libavcodec/riscv/vvc/Makefile > @@ -1,2 +1,3 @@ > OBJS-$(CONFIG_VVC_DECODER) += riscv/vvc/vvcdsp_init.o > -RVV-OBJS-$(CONFIG_VVC_DECODER) += riscv/vvc/vvc_mc_rvv.o > +RVV-OBJS-$(CONFIG_VVC_DECODER) += riscv/vvc/vvc_mc_rvv.o \ > + riscv/vvc/vvc_sad_rvv.o > diff --git a/libavcodec/riscv/vvc/vvc_sad_rvv.S > b/libavcodec/riscv/vvc/vvc_sad_rvv.S new file mode 100644 > index 00..341167be1f > --- /dev/null > +++ b/libavcodec/riscv/vvc/vvc_sad_rvv.S > @@ -0,0 +1,61 @@ > +/* > + * Copyright (c) 2024 Institue of Software Chinese Academy of Sciences > (ISCAS). + * > + * 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 "libavcodec/riscv/h26x/asm.S" > + > +.macro func_sad vlen > +func ff_vvc_sad_rvv_\vlen, zve32x, zbb, zba > +lpad0 > +slli t2, a3, 7 // dy * 128 > +lit1, 4*128+4 > +add t3, t2, a2 // dy * 128 + dx > +sub t1, t1, t2 > +sub t1, t1, a2 > +sh1adda0, t3, a0 > +sh1adda1, t1, a1 > +lit3, 16 > +beq a4, t3, SADVSET\vlen\()16 > +.irp w,8,16 > +SADVSET\vlen\w: > +vsetvlstatic32\w, \vlen > +vmv.v.i v0, 0 > +vmv.s.x v24, zero > +vsetvlstatic16\w, \vlen > +SAD\vlen\w: > +addi a5, a5, -2 > +vle16.v v8, (a0) > +vle16.v v16, (a1) > +vsub.vv v8, v8, v16 Don't clobber v8 here. > +vneg.vv16, v8 Use vsub.vv here to avoid the sequential dependency. > +addi a0, a0, 2 * 128 * 2 > +vmax.vv v8, v8, v16 > +vwaddu.wv v0, v0, v8 > +addi a1, a1, 2 * 128 * 2 > +bnez a5, SAD\vlen\w > +vsetvlstatic32\w, \vlen > +vredsum.vsv24, v0, v24 Are you sure this does not require tail-undisturbed mode? I think you're setting tail-agnostic mode up. > +vmv.x.s a0, v24 > +ret > +.endr > +endfunc > +.endm > + > +func_sad 256 > +func_sad 128 > diff --git a/libavcodec/riscv/vvc/vvcdsp_init.c > b/libavcodec/riscv/vvc/vvcdsp_init.c index 2fe93029aa..1b228cc9f5 100644 > --- a/libavcodec/riscv/vvc/vvcdsp_init.c > +++ b/libavcodec/riscv/vvc/vvcdsp_init.c > @@ -59,6 +59,9 @@ DMVR_PROTOTYPES(8, rvv_256) > c->inter.dmvr[1][1] = ff_vvc_dmvr_hv_##bd##_##opt; \ > } while (0) > > +int ff_vvc_sad_rvv_128(const int16_t *src0, const int16_t *src1, int dx, > int dy, int block_w, int block_h); +int ff_vvc_sad_rvv_256(const int16_t > *src0, const int16_t *src1, int dx, int dy, int block_w, int block_h); + > #define PUT_PIXELS_PROTOTYPES2(bd, opt) > \ void bf(ff_vvc_put_pixels, bd, opt)(int16_t *dst, > \ const uint8_t *_src, const ptrdiff_t _src_stride, >\ @@ -97,6 +100,8 @@ void > ff_vvc_dsp_init_riscv(VVCDSPContext *const c, const int bd) FUNCS(LUMA, > rvv_256); > FUNCS(CHROMA, rvv_256); > break; > +case 10
Re: [FFmpeg-devel] [PATCH] avutil/vulkan_glslang: Fix build failure
On 16/12/2024 20:55, Zhao Zhili wrote: From: Zhao Zhili compile_only was added since glslang 13.1.0. --- libavutil/vulkan_glslang.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavutil/vulkan_glslang.c b/libavutil/vulkan_glslang.c index 9e1b8f4d8d..9e7a33223b 100644 --- a/libavutil/vulkan_glslang.c +++ b/libavutil/vulkan_glslang.c @@ -192,7 +192,9 @@ static int glslc_shader_compile(FFVulkanContext *s, FFVkSPIRVCompiler *ctx, .optimize_size = 0, .disassemble = 0, .validate = 1, +#if ((GLSLANG_VERSION_MAJOR) >= 14) .compile_only = 0, +#endif }; #endif The changelog reads: > Release 13.1.1 >Initialize compile_only field in C interface It's initialized to 0 in the new version. https://github.com/KhronosGroup/glslang/commit/fd1f96d2020496760290e5cef5d68ae83e5dd5c4 Shouldn't this check for the version being **less than** 13.1.1? OpenPGP_0xA2FEA5F03F034464.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 0/3] Make fate tests succeed with zlib-ng
On Sat, Dec 14, 2024 at 6:39 PM Alexander Strasser via ffmpeg-devel wrote: > On 2024-12-14 11:09 +0100, Anton Khirnov wrote: > > Quoting Alexander Strasser via ffmpeg-devel (2024-12-01 21:13:56) > > > This is a fixed up version of the series I sent before. IMO there would be no need to revert and then add the fixes. It would be preferable to have a new commit that does all of it at once, and maybe reference the reverted commit. But I don't think this patchset is the best approach. > > > This worked for me on Ubuntu 20.04 but probably will break > > > with older zlib versions as Hendrik pointed out in the > > > previous thread. Either we must update zlib on affected > > > FATE clients or add more .alt files to them as well. > > > > > > We could also go the further the "no_file_checksums" as > > > was demonstrated by James' series. > > > > > > I still prefer this way because it's simpler and retains > > > the value of the tests. > > > > This seems like a hack to me. > > Depends on what you precisely mean by hack. > It is a way to accommodate for shortcomings in older, but > still widely used zlib versions. > > > > We should not be testing for bitexact output from code that is not under > > our control and does not guarantee bitexactness. I agree with Anton. > Ideally! > > OTOH we also indirectly test that other code like C std lib functions > work as expected. > > In this case short of bugs in zlib/zlib-ng I do not see why the output > should differ with compression level 0. Maybe I'm missing something > I didn't look that deep into how zlib exactly works. The difference in the png tests comes from a bugfix in zlib itself: https://github.com/madler/zlib/commit/8ba393e7 I think the best approach would be Michael's "(c): implement enough of zlib ourselfs, so it can encode to a valid output" from another reply in this thread. We already have a partial zlib wrapper. It could be extended to write our own uncompressed data when compression_level is 0. It should be fairly straightforward and involve wrappers around deflate() and compress2(). Unfortunately I don't have time to look into this at the moment. Ramiro ___ ffmpeg-devel mailing list ffmpeg-devel@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/hevcdec: remove hevc prefix for x86 asm files
---
libavcodec/x86/Makefile | 8
libavcodec/x86/hevc/Makefile | 12
.../x86/{hevc_add_res.asm => hevc/add_res.asm} | 0
.../x86/{hevc_deblock.asm => hevc/deblock.asm} | 0
libavcodec/x86/{hevcdsp_init.c => hevc/dsp_init.c} | 0
libavcodec/x86/{hevc_idct.asm => hevc/idct.asm} | 0
libavcodec/x86/{hevc_mc.asm => hevc/mc.asm} | 0
libavcodec/x86/{hevc_sao.asm => hevc/sao.asm}| 0
.../x86/{hevc_sao_10bit.asm => hevc/sao_10bit.asm} | 0
9 files changed, 12 insertions(+), 8 deletions(-)
create mode 100644 libavcodec/x86/hevc/Makefile
rename libavcodec/x86/{hevc_add_res.asm => hevc/add_res.asm} (100%)
rename libavcodec/x86/{hevc_deblock.asm => hevc/deblock.asm} (100%)
rename libavcodec/x86/{hevcdsp_init.c => hevc/dsp_init.c} (100%)
rename libavcodec/x86/{hevc_idct.asm => hevc/idct.asm} (100%)
rename libavcodec/x86/{hevc_mc.asm => hevc/mc.asm} (100%)
rename libavcodec/x86/{hevc_sao.asm => hevc/sao.asm} (100%)
rename libavcodec/x86/{hevc_sao_10bit.asm => hevc/sao_10bit.asm} (100%)
diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
index 331183f450..5d53515381 100644
--- a/libavcodec/x86/Makefile
+++ b/libavcodec/x86/Makefile
@@ -54,7 +54,6 @@ OBJS-$(CONFIG_FLAC_DECODER)+= x86/flacdsp_init.o
OBJS-$(CONFIG_FLAC_ENCODER)+= x86/flacencdsp_init.o
OBJS-$(CONFIG_OPUS_DECODER)+= x86/opusdsp_init.o
OBJS-$(CONFIG_OPUS_ENCODER)+= x86/celt_pvq_init.o
-OBJS-$(CONFIG_HEVC_DECODER)+= x86/hevcdsp_init.o
x86/h26x/h2656dsp.o
OBJS-$(CONFIG_JPEG2000_DECODER)+= x86/jpeg2000dsp_init.o
OBJS-$(CONFIG_LSCR_DECODER)+= x86/pngdsp_init.o
OBJS-$(CONFIG_MLP_DECODER) += x86/mlpdsp_init.o
@@ -162,13 +161,6 @@ X86ASM-OBJS-$(CONFIG_FLAC_DECODER) += x86/flacdsp.o
ifdef CONFIG_GPL
X86ASM-OBJS-$(CONFIG_FLAC_ENCODER) += x86/flac_dsp_gpl.o
endif
-X86ASM-OBJS-$(CONFIG_HEVC_DECODER) += x86/hevc_add_res.o\
- x86/hevc_deblock.o\
- x86/hevc_idct.o \
- x86/hevc_mc.o \
- x86/h26x/h2656_inter.o\
- x86/hevc_sao.o\
- x86/hevc_sao_10bit.o
X86ASM-OBJS-$(CONFIG_JPEG2000_DECODER) += x86/jpeg2000dsp.o
X86ASM-OBJS-$(CONFIG_LSCR_DECODER) += x86/pngdsp.o
X86ASM-OBJS-$(CONFIG_MLP_DECODER) += x86/mlpdsp.o
diff --git a/libavcodec/x86/hevc/Makefile b/libavcodec/x86/hevc/Makefile
new file mode 100644
index 00..8f1c88c569
--- /dev/null
+++ b/libavcodec/x86/hevc/Makefile
@@ -0,0 +1,12 @@
+clean::
+ $(RM) $(CLEANSUFFIXES:%=libavcodec/x86/hevc/%)
$(CLEANSUFFIXES:%=libavcodec/x86/h26x/%)
+
+OBJS-$(CONFIG_HEVC_DECODER) += x86/hevc/dsp_init.o \
+ x86/h26x/h2656dsp.o
+X86ASM-OBJS-$(CONFIG_HEVC_DECODER) += x86/hevc/add_res.o \
+ x86/hevc/deblock.o \
+ x86/hevc/idct.o \
+ x86/hevc/mc.o\
+ x86/hevc/sao.o \
+ x86/hevc/sao_10bit.o \
+ x86/h26x/h2656_inter.o
diff --git a/libavcodec/x86/hevc_add_res.asm b/libavcodec/x86/hevc/add_res.asm
similarity index 100%
rename from libavcodec/x86/hevc_add_res.asm
rename to libavcodec/x86/hevc/add_res.asm
diff --git a/libavcodec/x86/hevc_deblock.asm b/libavcodec/x86/hevc/deblock.asm
similarity index 100%
rename from libavcodec/x86/hevc_deblock.asm
rename to libavcodec/x86/hevc/deblock.asm
diff --git a/libavcodec/x86/hevcdsp_init.c b/libavcodec/x86/hevc/dsp_init.c
similarity index 100%
rename from libavcodec/x86/hevcdsp_init.c
rename to libavcodec/x86/hevc/dsp_init.c
diff --git a/libavcodec/x86/hevc_idct.asm b/libavcodec/x86/hevc/idct.asm
similarity index 100%
rename from libavcodec/x86/hevc_idct.asm
rename to libavcodec/x86/hevc/idct.asm
diff --git a/libavcodec/x86/hevc_mc.asm b/libavcodec/x86/hevc/mc.asm
similarity index 100%
rename from libavcodec/x86/hevc_mc.asm
rename to libavcodec/x86/hevc/mc.asm
diff --git a/libavcodec/x86/hevc_sao.asm b/libavcodec/x86/hevc/sao.asm
similarity index 100%
rename from libavcodec/x86/hevc_sao.asm
rename to libavcodec/x86/hevc/sao.asm
diff --git a/libavcodec/x86/hevc_sao_10bit.asm
b/libavcodec/x86/hevc/sao_10bit.asm
similarity index 100%
rename from libavcodec/x86/hevc_sao_10bit.asm
rename to libavcodec/x86/hevc/sao_10bit.asm
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listi
[FFmpeg-devel] [PATCH 1/2] avcodec/vvcdec: remove vvc prefix for x86 and riscv
---
libavcodec/riscv/vvc/Makefile | 6 +++---
libavcodec/riscv/vvc/{vvcdsp_init.c => dsp_init.c} | 0
libavcodec/riscv/vvc/{vvc_mc_rvv.S => mc.S}| 0
libavcodec/riscv/vvc/{vvc_sad_rvv.S => sad.S} | 0
libavcodec/x86/vvc/Makefile| 12 ++--
libavcodec/x86/vvc/{vvc_alf.asm => alf.asm}| 0
libavcodec/x86/vvc/{vvc_dmvr.asm => dmvr.asm} | 0
libavcodec/x86/vvc/{vvcdsp_init.c => dsp_init.c} | 0
libavcodec/x86/vvc/{vvc_mc.asm => mc.asm} | 0
libavcodec/x86/vvc/{vvc_of.asm => of.asm} | 0
libavcodec/x86/vvc/{vvc_sad.asm => sad.asm}| 0
11 files changed, 9 insertions(+), 9 deletions(-)
rename libavcodec/riscv/vvc/{vvcdsp_init.c => dsp_init.c} (100%)
rename libavcodec/riscv/vvc/{vvc_mc_rvv.S => mc.S} (100%)
rename libavcodec/riscv/vvc/{vvc_sad_rvv.S => sad.S} (100%)
rename libavcodec/x86/vvc/{vvc_alf.asm => alf.asm} (100%)
rename libavcodec/x86/vvc/{vvc_dmvr.asm => dmvr.asm} (100%)
rename libavcodec/x86/vvc/{vvcdsp_init.c => dsp_init.c} (100%)
rename libavcodec/x86/vvc/{vvc_mc.asm => mc.asm} (100%)
rename libavcodec/x86/vvc/{vvc_of.asm => of.asm} (100%)
rename libavcodec/x86/vvc/{vvc_sad.asm => sad.asm} (100%)
diff --git a/libavcodec/riscv/vvc/Makefile b/libavcodec/riscv/vvc/Makefile
index 6b9c618b33..58b895e137 100644
--- a/libavcodec/riscv/vvc/Makefile
+++ b/libavcodec/riscv/vvc/Makefile
@@ -1,3 +1,3 @@
-OBJS-$(CONFIG_VVC_DECODER) += riscv/vvc/vvcdsp_init.o
-RVV-OBJS-$(CONFIG_VVC_DECODER) += riscv/vvc/vvc_mc_rvv.o \
- riscv/vvc/vvc_sad_rvv.o
+OBJS-$(CONFIG_VVC_DECODER) += riscv/vvc/dsp_init.o
+RVV-OBJS-$(CONFIG_VVC_DECODER) += riscv/vvc/mc.o \
+ riscv/vvc/sad.o
diff --git a/libavcodec/riscv/vvc/vvcdsp_init.c
b/libavcodec/riscv/vvc/dsp_init.c
similarity index 100%
rename from libavcodec/riscv/vvc/vvcdsp_init.c
rename to libavcodec/riscv/vvc/dsp_init.c
diff --git a/libavcodec/riscv/vvc/vvc_mc_rvv.S b/libavcodec/riscv/vvc/mc.S
similarity index 100%
rename from libavcodec/riscv/vvc/vvc_mc_rvv.S
rename to libavcodec/riscv/vvc/mc.S
diff --git a/libavcodec/riscv/vvc/vvc_sad_rvv.S b/libavcodec/riscv/vvc/sad.S
similarity index 100%
rename from libavcodec/riscv/vvc/vvc_sad_rvv.S
rename to libavcodec/riscv/vvc/sad.S
diff --git a/libavcodec/x86/vvc/Makefile b/libavcodec/x86/vvc/Makefile
index aa59aa59cf..86a6c8ba7c 100644
--- a/libavcodec/x86/vvc/Makefile
+++ b/libavcodec/x86/vvc/Makefile
@@ -1,11 +1,11 @@
clean::
$(RM) $(CLEANSUFFIXES:%=libavcodec/x86/vvc/%)
$(CLEANSUFFIXES:%=libavcodec/x86/h26x/%)
-OBJS-$(CONFIG_VVC_DECODER) += x86/vvc/vvcdsp_init.o \
+OBJS-$(CONFIG_VVC_DECODER) += x86/vvc/dsp_init.o\
x86/h26x/h2656dsp.o
-X86ASM-OBJS-$(CONFIG_VVC_DECODER) += x86/vvc/vvc_alf.o \
- x86/vvc/vvc_dmvr.o \
- x86/vvc/vvc_mc.o \
- x86/vvc/vvc_of.o \
- x86/vvc/vvc_sad.o \
+X86ASM-OBJS-$(CONFIG_VVC_DECODER) += x86/vvc/alf.o \
+ x86/vvc/dmvr.o\
+ x86/vvc/mc.o \
+ x86/vvc/of.o \
+ x86/vvc/sad.o \
x86/h26x/h2656_inter.o
diff --git a/libavcodec/x86/vvc/vvc_alf.asm b/libavcodec/x86/vvc/alf.asm
similarity index 100%
rename from libavcodec/x86/vvc/vvc_alf.asm
rename to libavcodec/x86/vvc/alf.asm
diff --git a/libavcodec/x86/vvc/vvc_dmvr.asm b/libavcodec/x86/vvc/dmvr.asm
similarity index 100%
rename from libavcodec/x86/vvc/vvc_dmvr.asm
rename to libavcodec/x86/vvc/dmvr.asm
diff --git a/libavcodec/x86/vvc/vvcdsp_init.c b/libavcodec/x86/vvc/dsp_init.c
similarity index 100%
rename from libavcodec/x86/vvc/vvcdsp_init.c
rename to libavcodec/x86/vvc/dsp_init.c
diff --git a/libavcodec/x86/vvc/vvc_mc.asm b/libavcodec/x86/vvc/mc.asm
similarity index 100%
rename from libavcodec/x86/vvc/vvc_mc.asm
rename to libavcodec/x86/vvc/mc.asm
diff --git a/libavcodec/x86/vvc/vvc_of.asm b/libavcodec/x86/vvc/of.asm
similarity index 100%
rename from libavcodec/x86/vvc/vvc_of.asm
rename to libavcodec/x86/vvc/of.asm
diff --git a/libavcodec/x86/vvc/vvc_sad.asm b/libavcodec/x86/vvc/sad.asm
similarity index 100%
rename from libavcodec/x86/vvc/vvc_sad.asm
rename to libavcodec/x86/vvc/sad.asm
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil/vulkan_glslang: Fix build failure
> On Dec 17, 2024, at 09:12, Lynne via ffmpeg-devel > wrote: > > On 16/12/2024 20:55, Zhao Zhili wrote: >> From: Zhao Zhili >> compile_only was added since glslang 13.1.0. >> --- >> libavutil/vulkan_glslang.c | 2 ++ >> 1 file changed, 2 insertions(+) >> diff --git a/libavutil/vulkan_glslang.c b/libavutil/vulkan_glslang.c >> index 9e1b8f4d8d..9e7a33223b 100644 >> --- a/libavutil/vulkan_glslang.c >> +++ b/libavutil/vulkan_glslang.c >> @@ -192,7 +192,9 @@ static int glslc_shader_compile(FFVulkanContext *s, >> FFVkSPIRVCompiler *ctx, >> .optimize_size = 0, >> .disassemble = 0, >> .validate = 1, >> +#if ((GLSLANG_VERSION_MAJOR) >= 14) >> .compile_only = 0, >> +#endif >> }; >> #endif >> > > > The changelog reads: > > > Release 13.1.1 > >Initialize compile_only field in C interface That’s for a variable inside the implementation of glslang_program_SPIRV_generate() https://github.com/KhronosGroup/glslang/commit/fd1f96d2020496760290e5cef5d68ae83e5dd5c4 While we are using glslang_program_SPIRV_generate_with_options(). We can’t just check less than 13.1.1, as the compile_only was added since 13.1.0. But we can just remove “.compile_only = 0”, and let default initialization kick in. Keep the explicit initialize of compile_only is for clarity. I can remove it if you prefer clean and less conditional compile. > > It's initialized to 0 in the new version. > https://github.com/KhronosGroup/glslang/commit/fd1f96d2020496760290e5cef5d68ae83e5dd5c4 > > Shouldn't this check for the version being **less than** 13.1.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 mailing list ffmpeg-devel@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 0/3] Make fate tests succeed with zlib-ng
On 12/16/24 5:50 PM, Michael Niedermayer wrote: (c): implement enough of zlib ourselfs, so it can encode to a valid output A reimplementation of zlib that does nothing except for fixing FATE failures that shouldn't be failing anyway sounds like a security vulnerability waiting to happen. Stock maddler's zlib still has vulnerabilities occur and there's the whole world's eyes on it. This sounds like a bad idea. Also this sounds like solving an XY problem, if differing zlib implementations are causing fate to fail, maybe we should not depend on a specific zlib implementation rather than NIH'ing our own. (d): Find a input that encodes identically with all existing zlib variants Doesn't fix the problem, which is that need to be aware of all the known variants and create hacks to work with them instead of doing something more future proof. (e): Find a input that encodes to max 2 variants and store 2 checksums Doesn't fix the problem, which is that need to be aware of all the known variants and create hacks to work with them instead of doing something more future proof. I dont think (e) is the best solution, but if it works for all cases, my point is, that it is a valid solution It really isn't, because it doesn't work in all cases. It works for a specific list of known cases. This is not the same thing. - Leo Izen (Traneptora) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil/vulkan_glslang: Fix build failure
On 17/12/2024 11:42, Zhao Zhili wrote: On Dec 17, 2024, at 09:12, Lynne via ffmpeg-devel wrote: On 16/12/2024 20:55, Zhao Zhili wrote: From: Zhao Zhili compile_only was added since glslang 13.1.0. --- libavutil/vulkan_glslang.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavutil/vulkan_glslang.c b/libavutil/vulkan_glslang.c index 9e1b8f4d8d..9e7a33223b 100644 --- a/libavutil/vulkan_glslang.c +++ b/libavutil/vulkan_glslang.c @@ -192,7 +192,9 @@ static int glslc_shader_compile(FFVulkanContext *s, FFVkSPIRVCompiler *ctx, .optimize_size = 0, .disassemble = 0, .validate = 1, +#if ((GLSLANG_VERSION_MAJOR) >= 14) .compile_only = 0, +#endif }; #endif The changelog reads: Release 13.1.1 Initialize compile_only field in C interface That’s for a variable inside the implementation of glslang_program_SPIRV_generate() https://github.com/KhronosGroup/glslang/commit/fd1f96d2020496760290e5cef5d68ae83e5dd5c4 While we are using glslang_program_SPIRV_generate_with_options(). We can’t just check less than 13.1.1, as the compile_only was added since 13.1.0. But we can just remove “.compile_only = 0”, and let default initialization kick in. Keep the explicit initialize of compile_only is for clarity. I can remove it if you prefer clean and less conditional compile. It's initialized to 0 in the new version. https://github.com/KhronosGroup/glslang/commit/fd1f96d2020496760290e5cef5d68ae83e5dd5c4 Shouldn't this check for the version being **less than** 13.1.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". Ah, I see. We should just keep it as-is. We'll never be using compile-only without linking. Besides, the plan is to switch to Slang as soon as its viable and rm -rf all glslang/shaderc compilation code. OpenPGP_0xA2FEA5F03F034464.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil/vulkan_glslang: Fix build failure
On 17/12/2024 12:04, Lynne via ffmpeg-devel wrote: On 17/12/2024 11:42, Zhao Zhili wrote: On Dec 17, 2024, at 09:12, Lynne via ffmpeg-devel de...@ffmpeg.org> wrote: On 16/12/2024 20:55, Zhao Zhili wrote: From: Zhao Zhili compile_only was added since glslang 13.1.0. --- libavutil/vulkan_glslang.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavutil/vulkan_glslang.c b/libavutil/vulkan_glslang.c index 9e1b8f4d8d..9e7a33223b 100644 --- a/libavutil/vulkan_glslang.c +++ b/libavutil/vulkan_glslang.c @@ -192,7 +192,9 @@ static int glslc_shader_compile(FFVulkanContext *s, FFVkSPIRVCompiler *ctx, .optimize_size = 0, .disassemble = 0, .validate = 1, +#if ((GLSLANG_VERSION_MAJOR) >= 14) .compile_only = 0, +#endif }; #endif The changelog reads: Release 13.1.1 Initialize compile_only field in C interface That’s for a variable inside the implementation of glslang_program_SPIRV_generate() https://github.com/KhronosGroup/glslang/commit/ fd1f96d2020496760290e5cef5d68ae83e5dd5c4 While we are using glslang_program_SPIRV_generate_with_options(). We can’t just check less than 13.1.1, as the compile_only was added since 13.1.0. But we can just remove “.compile_only = 0”, and let default initialization kick in. Keep the explicit initialize of compile_only is for clarity. I can remove it if you prefer clean and less conditional compile. It's initialized to 0 in the new version. https://github.com/KhronosGroup/glslang/commit/ fd1f96d2020496760290e5cef5d68ae83e5dd5c4 Shouldn't this check for the version being **less than** 13.1.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". Ah, I see. We should just keep it as-is. We'll never be using compile-only without linking. Besides, the plan is to switch to Slang as soon as its viable and rm -rf all glslang/shaderc compilation code. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". *by that I mean just omitting the setting and using default 0-initialization. Could you send a patch to comment the line out, something like: /* .compile_only = 0, */ OpenPGP_0xA2FEA5F03F034464.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
