Re: [FFmpeg-devel] [PATCH] configure: enable warnings for shadowed variables
Hi, Le 8 septembre 2024 19:57:38 GMT+03:00, Timo Rothenpieler a écrit : > >Well, the reality is, that without printing all these warnings, nobody will >ever fix them. >Unless someone sits down and spends potentially multiple days if not weeks of >work to fix all the current ones. > >If we print all the warnings instead, it can get fixed gradually. I can only agree with Zhao and Andreas here. If you want to turn a warning flag on, you have to eliminate the warnings first. Otherwise you're just drowning the existing and typically more serious warnings in a sea of new warnings. The result is obvious: people will just ignore *all* warnigns then, and that's worse. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/avcodec: remove usage of __typeof__()
Le 8 septembre 2024 22:22:01 GMT+03:00, James Almer a écrit
:
>It's non-standard C.
The description is a little bit misleading. `typeof` is standard C (as of last
year). Sure, technically `__typeof__` is not standard but this is easily
misinterpreted.
Also TBH, this change seems highly error prone.
>
>Signed-off-by: James Almer
>---
> libavcodec/avcodec.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
>diff --git a/libavcodec/avcodec.c b/libavcodec/avcodec.c
>index cb89236549..78153d12f1 100644
>--- a/libavcodec/avcodec.c
>+++ b/libavcodec/avcodec.c
>@@ -708,9 +708,9 @@ int attribute_align_arg
>avcodec_receive_frame(AVCodecContext *avctx, AVFrame *fr
> return ff_encode_receive_frame(avctx, frame);
> }
>
>-#define WRAP_CONFIG(allowed_type, field, terminator)\
>+#define WRAP_CONFIG(allowed_type, field, field_type, terminator)\
> do {\
>-static const __typeof__(*(field)) end = terminator; \
>+static const field_type end = terminator; \
> if (codec->type != (allowed_type)) \
> return AVERROR(EINVAL); \
> *out_configs = (field); \
>@@ -753,15 +753,15 @@ int ff_default_get_supported_config(const AVCodecContext
>*avctx,
> switch (config) {
> FF_DISABLE_DEPRECATION_WARNINGS
> case AV_CODEC_CONFIG_PIX_FORMAT:
>-WRAP_CONFIG(AVMEDIA_TYPE_VIDEO, codec->pix_fmts, AV_PIX_FMT_NONE);
>+WRAP_CONFIG(AVMEDIA_TYPE_VIDEO, codec->pix_fmts, enum AVPixelFormat,
>AV_PIX_FMT_NONE);
> case AV_CODEC_CONFIG_FRAME_RATE:
>-WRAP_CONFIG(AVMEDIA_TYPE_VIDEO, codec->supported_framerates,
>(AVRational){0});
>+WRAP_CONFIG(AVMEDIA_TYPE_VIDEO, codec->supported_framerates,
>AVRational, (AVRational){0});
> case AV_CODEC_CONFIG_SAMPLE_RATE:
>-WRAP_CONFIG(AVMEDIA_TYPE_AUDIO, codec->supported_samplerates, 0);
>+WRAP_CONFIG(AVMEDIA_TYPE_AUDIO, codec->supported_samplerates, int, 0);
> case AV_CODEC_CONFIG_SAMPLE_FORMAT:
>-WRAP_CONFIG(AVMEDIA_TYPE_AUDIO, codec->sample_fmts,
>AV_SAMPLE_FMT_NONE);
>+WRAP_CONFIG(AVMEDIA_TYPE_AUDIO, codec->sample_fmts, enum
>AVSampleFormat, AV_SAMPLE_FMT_NONE);
> case AV_CODEC_CONFIG_CHANNEL_LAYOUT:
>-WRAP_CONFIG(AVMEDIA_TYPE_AUDIO, codec->ch_layouts,
>(AVChannelLayout){0});
>+WRAP_CONFIG(AVMEDIA_TYPE_AUDIO, codec->ch_layouts, AVChannelLayout,
>(AVChannelLayout){0});
> FF_ENABLE_DEPRECATION_WARNINGS
>
> case AV_CODEC_CONFIG_COLOR_RANGE:
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v1 1/5] tests/fate/seek: check seek opertation with mov demuxer and file protocol
fix error at fate-seek-* when configure with --disable-everything --samples=fate-suite/ --enable-demuxer=mov Signed-off-by: Steven Liu --- tests/fate/seek.mak | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tests/fate/seek.mak b/tests/fate/seek.mak index dfc2fa6a96..8751ffa86d 100644 --- a/tests/fate/seek.mak +++ b/tests/fate/seek.mak @@ -183,10 +183,10 @@ FATE_SEEK += $(FATE_SEEK_LAVF_IMAGE2PIPE) FATE_SEEK_EXTRA-$(CONFIG_MP3_DEMUXER) += fate-seek-extra-mp3 FATE_SEEK_EXTRA-$(call ALLYES, CACHE_PROTOCOL PIPE_PROTOCOL MP3_DEMUXER) += fate-seek-cache-pipe FATE_SEEK_EXTRA-$(CONFIG_MATROSKA_DEMUXER) += fate-seek-mkv-codec-delay -FATE_SEEK_EXTRA-$(CONFIG_MOV_DEMUXER) += fate-seek-extra-mp4 -FATE_SEEK_EXTRA-$(CONFIG_MOV_DEMUXER) += fate-seek-empty-edit-mp4 -FATE_SEEK_EXTRA-$(CONFIG_MOV_DEMUXER) += fate-seek-test-iibbibb-mp4 -FATE_SEEK_EXTRA-$(CONFIG_MOV_DEMUXER) += fate-seek-test-iibbibb-neg-ctts-mp4 +FATE_SEEK_EXTRA-$(call ALLYES, MOV_DEMUXER FILE_PROTOCOL) += fate-seek-extra-mp4 +FATE_SEEK_EXTRA-$(call ALLYES, MOV_DEMUXER FILE_PROTOCOL) += fate-seek-empty-edit-mp4 +FATE_SEEK_EXTRA-$(call ALLYES, MOV_DEMUXER FILE_PROTOCOL) += fate-seek-test-iibbibb-mp4 +FATE_SEEK_EXTRA-$(call ALLYES, MOV_DEMUXER FILE_PROTOCOL) += fate-seek-test-iibbibb-neg-ctts-mp4 fate-seek-extra-mp3: CMD = run libavformat/tests/seek$(EXESUF) $(TARGET_SAMPLES)/gapless/gapless.mp3 -fastseek 1 fate-seek-extra-mp4: CMD = run libavformat/tests/seek$(EXESUF) $(TARGET_SAMPLES)/mov/buck480p30_na.mp4 -duration 180 -frames 4 -- 2.45.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v1 2/5] tests/fate/cbs: refine depend prerequisites for cbs-h264-discard test
add h264_metadata and file protocol for cbs-h264-discard test Signed-off-by: Steven Liu --- tests/fate/cbs.mak | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/fate/cbs.mak b/tests/fate/cbs.mak index 802b0351a3..368385982c 100644 --- a/tests/fate/cbs.mak +++ b/tests/fate/cbs.mak @@ -88,7 +88,7 @@ FATE_CBS_DISCARD_TYPES = \ $(foreach N,$(FATE_CBS_DISCARD_TYPES),$(eval $(call FATE_CBS_DISCARD_TEST,h264,$(N),h264/interlaced_crop.mp4,h264))) -FATE_CBS_H264-$(call ALLYES, MOV_DEMUXER, H264_MUXER, H264_PARSER, FILTER_UNITS_BSF) += $(FATE_CBS_h264_DISCARD) +FATE_CBS_H264-$(call ALLYES, MOV_DEMUXER H264_MUXER H264_PARSER FILTER_UNITS_BSF H264_METADATA_BSF FILE_PROTOCOL) += $(FATE_CBS_h264_DISCARD) FATE_H264_REDUNDANT_PPS-$(call REMUX, H264, MOV_DEMUXER H264_REDUNDANT_PPS_BSF \ -- 2.45.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v1 4/5] tests/fate/cbs: refine depend prerequisites for cbs-hevc-discard test
add h264_metadata_bsf and file protocol for cbs-hevc-discard test cases Signed-off-by: Steven Liu --- tests/fate/cbs.mak | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/fate/cbs.mak b/tests/fate/cbs.mak index 368385982c..4c30c5ec6c 100644 --- a/tests/fate/cbs.mak +++ b/tests/fate/cbs.mak @@ -159,7 +159,7 @@ FATE_CBS_HEVC-$(call FATE_CBS_DEPS, HEVC, HEVC, HEVC, HEVC, HEVC) = $(FATE_CBS_h $(foreach N,$(FATE_CBS_DISCARD_TYPES),$(eval $(call FATE_CBS_DISCARD_TEST,hevc,$(N),hevc-conformance/WPP_A_ericsson_MAIN10_2.bit,hevc))) -FATE_CBS_HEVC-$(call ALLYES, HEVC_DEMUXER, HEVC_MUXER, HEVC_PARSER, FILTER_UNITS_BSF) += $(FATE_CBS_hevc_DISCARD) +FATE_CBS_HEVC-$(call ALLYES, HEVC_DEMUXER HEVC_MUXER HEVC_PARSER FILTER_UNITS_BSF HEVC_METADATA_BSF FILE_PROTOCOL) += $(FATE_CBS_hevc_DISCARD) FATE_SAMPLES_AVCONV += $(FATE_CBS_HEVC-yes) fate-cbs-hevc: $(FATE_CBS_HEVC-yes) -- 2.45.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v1 3/5] tests/fate/demux: refine depend prerequisites for fate-mov-mp3-demux
fix fate error when --disable-everything --samples=fate-suite/ --enable-demuxer=mov Signed-off-by: Steven Liu --- tests/fate/demux.mak | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/fate/demux.mak b/tests/fate/demux.mak index d9b9045f0b..e0d1fccc8f 100644 --- a/tests/fate/demux.mak +++ b/tests/fate/demux.mak @@ -76,7 +76,7 @@ fate-mkv-1242: CMD = framecrc -i $(TARGET_SAMPLES)/mkv/1242-small.mkv -c copy -f FATE_SAMPLES_DEMUX-$(CONFIG_MLV_DEMUXER) += fate-mlv-demux fate-mlv-demux: CMD = crc -i $(TARGET_SAMPLES)/mlv/M19-0333-cut.MLV -c copy -FATE_SAMPLES_DEMUX-$(CONFIG_MOV_DEMUXER) += fate-mov-mp3-demux +FATE_SAMPLES_DEMUX-$(call ALLYES, MOV_DEMUXER FRAMECRC_MUXER FILE_PROTOCOL PIPE_PROTOCOL) += fate-mov-mp3-demux fate-mov-mp3-demux: CMD = framecrc -i $(TARGET_SAMPLES)/mpegaudio/packed_maindata.mp3.mp4 -c copy FATE_FFPROBE_DEMUX-$(call ALLYES, MPEGTS_DEMUXER ARESAMPLE_FILTER) += fate-ts-opus-demux -- 2.45.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v1 5/5] tests/fate/cbs: make cbs-vvc test depends prerequisites correct
the VVC test cases cbs-vvc should prerequisites
VVC{demuxer, parser, metadata_bsf, muser}
Signed-off-by: Steven Liu
---
tests/fate/cbs.mak | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/fate/cbs.mak b/tests/fate/cbs.mak
index 4c30c5ec6c..dfd9e7d93c 100644
--- a/tests/fate/cbs.mak
+++ b/tests/fate/cbs.mak
@@ -5,7 +5,7 @@
fate-cbs: fate-cbs-av1 fate-cbs-h264 fate-cbs-hevc fate-cbs-mpeg2 fate-cbs-vp9
fate-cbs-vvc
FATE_CBS_DEPS = $(call ALLYES, $(1)_DEMUXER $(2)_PARSER $(3)_METADATA_BSF
$(4)_DECODER $(5)_MUXER)
-FATE_CBS_NO_DEC_DEPS = $(call ALLYES, $(1)_DEMUXER $(2)_PARSER
$(3)_METADATA_BSF $(4)_MUXER)
+FATE_CBS_NO_DEC_DEPS = $(call ALLYES, $(1)_DEMUXER $(1)_PARSER
$(1)_METADATA_BSF $(1)_MUXER)
define FATE_CBS_TEST
# (codec, test_name, sample_file, output_format)
@@ -197,7 +197,7 @@ FATE_CBS_VVC_SAMPLES =\
$(foreach N,$(FATE_CBS_VVC_SAMPLES),$(eval $(call
FATE_CBS_NO_DEC_TEST,vvc,$(basename $(N)),vvc-conformance/$(N),vvc)))
-FATE_CBS_VVC-$(call FATE_CBS_NO_DEC_DEPS, HEVC, HEVC, HEVC, HEVC) =
$(FATE_CBS_vvc)
+FATE_CBS_VVC-$(call FATE_CBS_NO_DEC_DEPS, VVC) = $(FATE_CBS_vvc)
FATE_SAMPLES_AVCONV += $(FATE_CBS_VVC-yes)
fate-cbs-vvc: $(FATE_CBS_VVC-yes)
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil/cpu_internal: Provide ff_getauxval() wrapper for getauxvaul()
On Sat, 24 Aug 2024, Brad Smith wrote: avutil/cpu_internal: Provide ff_getauxval() wrapper for getauxvaul() Initially used for getauxval() but will be used to add support for other API. Signed-off-by: Brad Smith --- libavutil/aarch64/cpu.c | 4 ++-- libavutil/arm/cpu.c | 2 +- libavutil/cpu.c | 14 ++ libavutil/cpu_internal.h | 2 ++ libavutil/loongarch/cpu.c | 2 +- libavutil/mips/cpu.c | 2 +- libavutil/riscv/cpu.c | 2 +- 7 files changed, 22 insertions(+), 6 deletions(-) LGTM, this looks reasonable to me. // Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] fftools/opt_common: add missing newline after printing codecs
This solves
ffmpeg -help bsf=trace_headers =>
Supported codecs: av1 h264 hevc vvc mjpeg mpeg2video vp8 vp9
---
fftools/opt_common.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fftools/opt_common.c b/fftools/opt_common.c
index f44fc4c97c..021ed75272 100644
--- a/fftools/opt_common.c
+++ b/fftools/opt_common.c
@@ -572,6 +572,7 @@ static void show_help_bsf(const char *name)
printf(" %s", avcodec_descriptor_get(*id)->name);
id++;
}
+printf("\n");
}
if (bsf->priv_class)
show_help_children(bsf->priv_class, AV_OPT_FLAG_BSF_PARAM);
--
2.45.2.753.g447d99e1c3b
___
ffmpeg-devel mailing list
ffmpeg-devel@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/cpu_internal: Provide ff_getauxval() wrapper for getauxvaul()
On Sat, Aug 24, 2024 at 3:30 PM Brad Smith wrote: > avutil/cpu_internal: Provide ff_getauxval() wrapper for getauxvaul() > > Initially used for getauxval() but will be used to add support for > other API. I'm curious, what other API do you have in mind? Is ff_getauxval() going to simulate getauxval() on other platforms? If that's the case, wouldn't it be better to create a function to get hardware capabilities instead (which may use getauxval or other API under the hood)? ___ ffmpeg-devel mailing list ffmpeg-devel@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/cpu_internal: Provide ff_getauxval() wrapper for getauxvaul()
On 2024-09-09 5:23 a.m., Ramiro Polla wrote: On Sat, Aug 24, 2024 at 3:30 PM Brad Smith wrote: avutil/cpu_internal: Provide ff_getauxval() wrapper for getauxvaul() Initially used for getauxval() but will be used to add support for other API. I'm curious, what other API do you have in mind? Is ff_getauxval() going to simulate getauxval() on other platforms? If that's the case, wouldn't it be better to create a function to get hardware capabilities instead (which may use getauxval or other API under the hood)? elf_aux_info() for FreeBSD / OpenBSD. It would probably make sense to move the /proc/self/auxv fallback path for Linux there too. No, it will not. ___ ffmpeg-devel mailing list ffmpeg-devel@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/cpu_internal: Provide ff_getauxval() wrapper for getauxvaul()
On Mon, Sep 9, 2024 at 11:34 AM Brad Smith wrote: > On 2024-09-09 5:23 a.m., Ramiro Polla wrote: > > On Sat, Aug 24, 2024 at 3:30 PM Brad Smith > wrote: > > avutil/cpu_internal: Provide ff_getauxval() wrapper for getauxvaul() > > Initially used for getauxval() but will be used to add support for > other API. > > I'm curious, what other API do you have in mind? Is ff_getauxval() > going to simulate getauxval() on other platforms? If that's the case, > wouldn't it be better to create a function to get hardware > capabilities instead (which may use getauxval or other API under the > hood)? > > elf_aux_info() for FreeBSD / OpenBSD. Perhaps add this to the commit message as well? Either way the patch looks good to me too. Thanks! > It would probably make sense > to move the /proc/self/auxv fallback path for Linux there too. Yes, that makes sense to me. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fftools/opt_common: add missing newline after printing codecs
Quoting Lynne via ffmpeg-devel (2024-09-09 10:34:21) > This solves > ffmpeg -help bsf=trace_headers => > > Supported codecs: av1 h264 hevc vvc mjpeg mpeg2video vp8 vp9 > --- > fftools/opt_common.c | 1 + > 1 file changed, 1 insertion(+) Looks ok -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/avcodec: remove usage of __typeof__()
Quoting Rémi Denis-Courmont (2024-09-09 09:41:59) > > > Le 8 septembre 2024 22:22:01 GMT+03:00, James Almer a > écrit : > >It's non-standard C. > > The description is a little bit misleading. `typeof` is standard C (as of > last year). Sure, technically `__typeof__` is not standard but this is easily > misinterpreted. AFAIK C23 is still in draft stage. Not to mention we use C11, where typeof is indeed not standard. -- 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] configure: enable warnings for shadowed variables
Quoting Rémi Denis-Courmont (2024-09-09 09:32:07) > Hi, > > Le 8 septembre 2024 19:57:38 GMT+03:00, Timo Rothenpieler > a écrit : > > > >Well, the reality is, that without printing all these warnings, nobody will > >ever fix them. > >Unless someone sits down and spends potentially multiple days if not weeks > >of work to fix all the current ones. > > > > >If we print all the warnings instead, it can get fixed gradually. > > I can only agree with Zhao and Andreas here. If you want to turn a warning > flag on, you have to eliminate the warnings first. > > Otherwise you're just drowning the existing and typically more serious > warnings in a sea of new warnings. The result is obvious: people will just > ignore *all* warnigns then, and that's worse. +1 -- 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] avutil/cpu_internal: Provide ff_getauxval() wrapper for getauxvaul()
On 2024-09-09 5:55 a.m., Ramiro Polla wrote: On Mon, Sep 9, 2024 at 11:34 AM Brad Smith wrote: On 2024-09-09 5:23 a.m., Ramiro Polla wrote: On Sat, Aug 24, 2024 at 3:30 PM Brad Smith wrote: avutil/cpu_internal: Provide ff_getauxval() wrapper for getauxvaul() Initially used for getauxval() but will be used to add support for other API. I'm curious, what other API do you have in mind? Is ff_getauxval() going to simulate getauxval() on other platforms? If that's the case, wouldn't it be better to create a function to get hardware capabilities instead (which may use getauxval or other API under the hood)? elf_aux_info() for FreeBSD / OpenBSD. Perhaps add this to the commit message as well? Will do so. Either way the patch looks good to me too. Thanks! It would probably make sense to move the /proc/self/auxv fallback path for Linux there too. Yes, that makes sense to me. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@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/cpu_internal: Provide ff_getauxval() wrapper for getauxvaul()
Le 9 septembre 2024 12:23:18 GMT+03:00, Ramiro Polla a écrit : >On Sat, Aug 24, 2024 at 3:30 PM Brad Smith > wrote: >> avutil/cpu_internal: Provide ff_getauxval() wrapper for getauxvaul() >> >> Initially used for getauxval() but will be used to add support for >> other API. > >I'm curious, what other API do you have in mind? FreeBSD's auxillary vector access helper is more generic than glibc's, allowing data of any size, rather than just longs. That's all. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 01/60] fftools/ffmpeg_opt: fix variable shadowing
Quoting Marvin Scholz (2024-09-08 19:14:10) > --- > fftools/ffmpeg_opt.c | 6 ++ > 1 file changed, 2 insertions(+), 4 deletions(-) Ok -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 02/60] fftools/opt_common: fix variable shadowing
Quoting Marvin Scholz (2024-09-08 19:43:27)
> ---
> fftools/opt_common.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/fftools/opt_common.c b/fftools/opt_common.c
> index 9d2d5184a0..059f7a53d2 100644
> --- a/fftools/opt_common.c
> +++ b/fftools/opt_common.c
> @@ -553,15 +553,15 @@ static void show_help_filter(const char *name)
> }
> #endif
>
> -static void show_help_bsf(const char *name)
> +static void show_help_bsf(const char *bsf_name)
> {
> -const AVBitStreamFilter *bsf = av_bsf_get_by_name(name);
> +const AVBitStreamFilter *bsf = av_bsf_get_by_name(bsf_name);
>
> -if (!name) {
> +if (!bsf_name) {
> av_log(NULL, AV_LOG_ERROR, "No bitstream filter name specified.\n");
> return;
> } else if (!bsf) {
> -av_log(NULL, AV_LOG_ERROR, "Unknown bit stream filter '%s'.\n",
> name);
> +av_log(NULL, AV_LOG_ERROR, "Unknown bit stream filter '%s'.\n",
> bsf_name);
What does this fix? I don't see any other instance of 'name' in this
function.
> return;
> }
>
> @@ -1205,10 +1205,10 @@ int init_report(const char *env, FILE **file)
>
> report_file = fopen(filename.str, "w");
> if (!report_file) {
> -int ret = AVERROR(errno);
> +int err = AVERROR(errno);
> av_log(NULL, AV_LOG_ERROR, "Failed to open report \"%s\": %s\n",
> filename.str, strerror(errno));
> -return ret;
> +return err;
Might as well use the outer ret.
--
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 04/60] lavfi/vf_ssim360: use av_err2str to simplify code
Quoting Marvin Scholz (2024-09-08 19:50:46) > No need to explicitly specify the buffer here as it is only ever passed > to av_log, so av_err2str can be used. > --- > libavfilter/vf_ssim360.c | 5 + > 1 file changed, 1 insertion(+), 4 deletions(-) Looks ok. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 05/60] lavfi/vf_ssim360: fix variable shadowing
Quoting Marvin Scholz (2024-09-08 19:54:47) > --- > libavfilter/vf_ssim360.c | 18 +- > 1 file changed, 9 insertions(+), 9 deletions(-) Looks ok. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 06/60] fftools/cmdutils: fix variable shadowing
Quoting Marvin Scholz (2024-09-08 19:58:16) > --- > fftools/cmdutils.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Ok -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 07/60] lavfi/vf_psnr: use av_err2str to simplify code
Quoting Marvin Scholz (2024-09-08 20:01:15) > No need to explicitly specify the buffer here as it is only > ever passed to av_log, so av_err2str can be used. > --- > libavfilter/vf_psnr.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) Looks fine -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 08/60] lavfi/vf_vmafmotion: use av_err2str to simplify code
Quoting Marvin Scholz (2024-09-08 20:02:34) > No need to explicitly specify the buffer here as it is only > ever passed to av_log, so av_err2str can be used. > --- > libavfilter/vf_vmafmotion.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) Possibly ok -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 09/60] lavfi/vf_vmafmotion: fix variable shadowing
Quoting Marvin Scholz (2024-09-08 20:05:57) > --- > libavfilter/vf_vmafmotion.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) Likely ok -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 10/60] lavfi/vf_vmafmotion: narrow variable scopes
Quoting Marvin Scholz (2024-09-08 20:12:15) > --- > libavfilter/vf_vmafmotion.c | 53 + > 1 file changed, 24 insertions(+), 29 deletions(-) Looks good. -- 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] lavf/tls_mbedtls: restrict TLSv1.3 verification workaround to affected version
Quoting sfan5 (2024-09-04 18:55:37) > From 57b37df52c7d528a1ce926cd7a7d75f62f6b46c6 Mon Sep 17 00:00:00 2001 > From: sfan5 > Date: Wed, 4 Sep 2024 17:56:05 +0200 > Subject: [PATCH] lavf/tls_mbedtls: restrict TLSv1.3 verification workaround to > affected version > > Now that mbedTLS 3.6.1 is released we know that only 3.6.0 contains this > regression. > > ref: c28e5b597ecc34188427347ad8d773bf9a0176cd > Signed-off-by: sfan5 > --- > libavformat/tls_mbedtls.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/libavformat/tls_mbedtls.c b/libavformat/tls_mbedtls.c > index 567b95b129..6dd807d5b6 100644 > --- a/libavformat/tls_mbedtls.c > +++ b/libavformat/tls_mbedtls.c > @@ -269,8 +269,8 @@ static int tls_open(URLContext *h, const char *uri, int > flags, AVDictionary **op > goto fail; > } > > -#ifdef MBEDTLS_SSL_PROTO_TLS1_3 > -// mbedTLS does not allow disabling certificate verification with > TLSv1.3 (yes, really). > +#if defined(MBEDTLS_SSL_PROTO_TLS1_3) && MBEDTLS_VERSION_NUMBER == 0x0306 Should this not be a runtime check, or is 3.6.1 ABI-incompatible with 3.6.0? -- 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] lavfi/avfiltergraph: fix leak on error
Quoting Marvin Scholz (2024-09-05 03:13:13) > Introduced in eddffbedb3443d5a4fe642de6e35b9e6a35cfda7 > > Fixes: CID1618897 Resource leak > --- > libavfilter/avfiltergraph.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) Thanks, pushed. -- 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 6/6] avcodec/hevc: ff_hevc_(qpel/epel)_filters are signed type
Quoting Zhao Zhili (2024-09-07 19:13:40) > From: Zhao Zhili > > --- > libavcodec/hevc/dsp_template.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/libavcodec/hevc/dsp_template.c b/libavcodec/hevc/dsp_template.c > index aebccd1a0c..a0f79c2673 100644 > --- a/libavcodec/hevc/dsp_template.c > +++ b/libavcodec/hevc/dsp_template.c > @@ -302,8 +302,8 @@ IDCT_DC(32) > > > #define ff_hevc_pel_filters ff_hevc_qpel_filters > #define DECL_HV_FILTER(f) \ > -const uint8_t *hf = ff_hevc_ ## f ## _filters[mx]; \ > -const uint8_t *vf = ff_hevc_ ## f ## _filters[my]; > +const int8_t *hf = ff_hevc_ ## f ## _filters[mx]; \ > +const int8_t *vf = ff_hevc_ ## f ## _filters[my]; Looks ok, though I wonder why are these then used as intptr_t. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] lavc: add Vulkan video encoding base code
This commit adds the common Vulkan video encoding framework.
It makes full use of the asynchronous features of our new common
hardware encoding code, and of Vulkan.
The code is able to handle anything from H264 to AV1 and MJPEG.
---
configure | 2 +
libavcodec/Makefile| 2 +-
libavcodec/vulkan_encode.c | 979 +
libavcodec/vulkan_encode.h | 243 +
4 files changed, 1225 insertions(+), 1 deletion(-)
create mode 100644 libavcodec/vulkan_encode.c
create mode 100644 libavcodec/vulkan_encode.h
diff --git a/configure b/configure
index a8e67d230c..6cfb736a86 100755
--- a/configure
+++ b/configure
@@ -2638,6 +2638,7 @@ CONFIG_EXTRA="
vp3dsp
vp56dsp
vp8dsp
+vulkan_encode
wma_freqs
wmv2dsp
"
@@ -3299,6 +3300,7 @@ qsvdec_select="qsv"
qsvenc_select="qsv"
qsvvpp_select="qsv"
vaapi_encode_deps="vaapi"
+vulkan_encode_deps="vulkan"
v4l2_m2m_deps="linux_videodev2_h sem_timedwait"
bilateral_cuda_filter_deps="ffnvcodec"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 27ef4638ce..ff6a3c4efc 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1282,7 +1282,7 @@ SKIPHEADERS-$(CONFIG_QSVENC) += qsvenc.h
SKIPHEADERS-$(CONFIG_VAAPI)+= vaapi_decode.h vaapi_hevc.h
vaapi_encode.h
SKIPHEADERS-$(CONFIG_VDPAU)+= vdpau.h vdpau_internal.h
SKIPHEADERS-$(CONFIG_VIDEOTOOLBOX) += videotoolbox.h vt_internal.h
-SKIPHEADERS-$(CONFIG_VULKAN) += vulkan.h vulkan_video.h
vulkan_decode.h
+SKIPHEADERS-$(CONFIG_VULKAN) += vulkan.h vulkan_video.h
vulkan_encode.h vulkan_decode.h
SKIPHEADERS-$(CONFIG_V4L2_M2M) += v4l2_buffers.h v4l2_context.h
v4l2_m2m.h
SKIPHEADERS-$(CONFIG_ZLIB) += zlib_wrapper.h
diff --git a/libavcodec/vulkan_encode.c b/libavcodec/vulkan_encode.c
new file mode 100644
index 00..5e87d4c073
--- /dev/null
+++ b/libavcodec/vulkan_encode.c
@@ -0,0 +1,979 @@
+/*
+ * 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/mem.h"
+#include "libavutil/avassert.h"
+#include "vulkan_encode.h"
+#include "config.h"
+
+#include "libavutil/vulkan_loader.h"
+
+const AVCodecHWConfigInternal *const ff_vulkan_encode_hw_configs[] = {
+HW_CONFIG_ENCODER_FRAMES(VULKAN, VULKAN),
+NULL,
+};
+
+av_cold void ff_vulkan_encode_uninit(FFVulkanEncodeContext *ctx)
+{
+FFVulkanContext *s = &ctx->s;
+FFVulkanFunctions *vk = &s->vkfn;
+
+/* Wait on and free execution pool */
+ff_vk_exec_pool_free(s, &ctx->enc_pool);
+
+/* Destroy the session params */
+if (ctx->session_params)
+vk->DestroyVideoSessionParametersKHR(s->hwctx->act_dev,
+ ctx->session_params,
+ s->hwctx->alloc);
+
+ff_hw_base_encode_close(&ctx->base);
+
+av_buffer_pool_uninit(&ctx->buf_pool);
+
+ff_vk_video_common_uninit(s, &ctx->common);
+
+ff_vk_uninit(s);
+}
+
+static int vulkan_encode_init(AVCodecContext *avctx, FFHWBaseEncodePicture
*pic)
+{
+int err;
+FFVulkanEncodeContext *ctx = avctx->priv_data;
+FFVulkanEncodePicture *vp = pic->priv;
+
+AVFrame *f = pic->input_image;
+AVHWFramesContext *hwfc = (AVHWFramesContext *)f->hw_frames_ctx->data;
+AVVulkanFramesContext *vkfc = hwfc->hwctx;
+AVVkFrame *vkf = (AVVkFrame *)f->data[0];
+
+if (ctx->codec->picture_priv_data_size > 0) {
+pic->codec_priv = av_mallocz(ctx->codec->picture_priv_data_size);
+if (!pic->codec_priv)
+return AVERROR(ENOMEM);
+}
+
+/* Input image view */
+err = ff_vk_create_view(&ctx->s, &ctx->common,
+&vp->in.view, &vp->in.aspect,
+vkf, vkfc->format[0], 0);
+if (err < 0)
+return err;
+
+/* Reference view */
+if (!ctx->common.layered_dpb) {
+AVFrame *rf = pic->recon_image;
+AVVkFrame *rvkf = (AVVkFrame *)rf->data[0];
+err = ff_vk_create_view(&ctx->s, &ctx->common,
+&vp->dpb.view, &vp->dpb.aspect,
+rvkf, ctx->pic_format, 1);
+if (err < 0)
+return err;
+} else {
+vp->dpb.view = ctx->com
[FFmpeg-devel] [PATCH 2/2] lavc: add h264_vulkan hardware encoder
This commit adds the first Vulkan hardware encoder.
Currently, P, and **B**-frames are supported. This marks the
first implementation to support both.
The encoder has feature-parity with VAAPI.
---
configure |1 +
libavcodec/Makefile |3 +
libavcodec/allcodecs.c |1 +
libavcodec/vulkan_encode_h264.c | 1687 +++
4 files changed, 1692 insertions(+)
create mode 100644 libavcodec/vulkan_encode_h264.c
diff --git a/configure b/configure
index 6cfb736a86..ebb8be73ad 100755
--- a/configure
+++ b/configure
@@ -3366,6 +3366,7 @@ h264_qsv_encoder_select="atsc_a53 qsvenc"
h264_rkmpp_decoder_deps="rkmpp"
h264_rkmpp_decoder_select="h264_mp4toannexb_bsf"
h264_vaapi_encoder_select="atsc_a53 cbs_h264 vaapi_encode"
+h264_vulkan_encoder_select="cbs_h264 vulkan_encode"
h264_v4l2m2m_decoder_deps="v4l2_m2m h264_v4l2_m2m"
h264_v4l2m2m_decoder_select="h264_mp4toannexb_bsf"
h264_v4l2m2m_encoder_deps="v4l2_m2m h264_v4l2_m2m"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index ff6a3c4efc..d4eefa28a2 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -429,6 +429,9 @@ OBJS-$(CONFIG_H264_VAAPI_ENCODER) +=
vaapi_encode_h264.o h264_levels.o \
OBJS-$(CONFIG_H264_VIDEOTOOLBOX_ENCODER) += videotoolboxenc.o
OBJS-$(CONFIG_H264_V4L2M2M_DECODER)+= v4l2_m2m_dec.o
OBJS-$(CONFIG_H264_V4L2M2M_ENCODER)+= v4l2_m2m_enc.o
+OBJS-$(CONFIG_H264_VULKAN_ENCODER) += vulkan_encode.o vulkan_encode_h264.o
\
+ hw_base_encode.o
hw_base_encode_h264.o \
+ h264_levels.o h2645data.o
OBJS-$(CONFIG_HAP_DECODER) += hapdec.o hap.o
OBJS-$(CONFIG_HAP_ENCODER) += hapenc.o hap.o
OBJS-$(CONFIG_HCA_DECODER) += hcadec.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index d773ac36c2..cfd929b81f 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -850,6 +850,7 @@ extern const FFCodec ff_h264_qsv_encoder;
extern const FFCodec ff_h264_v4l2m2m_encoder;
extern const FFCodec ff_h264_vaapi_encoder;
extern const FFCodec ff_h264_videotoolbox_encoder;
+extern const FFCodec ff_h264_vulkan_encoder;
extern const FFCodec ff_hevc_amf_encoder;
extern const FFCodec ff_hevc_cuvid_decoder;
extern const FFCodec ff_hevc_d3d12va_encoder;
diff --git a/libavcodec/vulkan_encode_h264.c b/libavcodec/vulkan_encode_h264.c
new file mode 100644
index 00..529ac8aed2
--- /dev/null
+++ b/libavcodec/vulkan_encode_h264.c
@@ -0,0 +1,1687 @@
+/*
+ * 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/opt.h"
+#include "libavutil/mem.h"
+
+#include "cbs.h"
+#include "cbs_h264.h"
+#include "atsc_a53.h"
+
+#include "h264_levels.h"
+#include "h2645data.h"
+#include "codec_internal.h"
+#include "version.h"
+#include "hw_base_encode_h264.h"
+
+#include "vulkan_encode.h"
+
+enum UnitElems {
+UNIT_AUD= 1 << 0,
+UNIT_SEI_TIMING = 1 << 1,
+UNIT_SEI_IDENTIFIER = 1 << 2,
+UNIT_SEI_RECOVERY = 1 << 3,
+UNIT_SEI_A53_CC = 1 << 4,
+};
+
+const FFVulkanEncodeDescriptor ff_vk_enc_h264_desc = {
+.codec_id = AV_CODEC_ID_H264,
+.encode_extension = FF_VK_EXT_VIDEO_ENCODE_H264,
+.encode_op= VK_VIDEO_CODEC_OPERATION_ENCODE_H264_BIT_KHR,
+.ext_props = {
+.extensionName = VK_STD_VULKAN_VIDEO_CODEC_H264_ENCODE_EXTENSION_NAME,
+.specVersion = VK_STD_VULKAN_VIDEO_CODEC_H264_ENCODE_SPEC_VERSION,
+},
+};
+
+/* Random (version 4) ISO 11578 UUID. */
+static const uint8_t vulkan_encode_h264_sei_identifier_uuid[16] = {
+0x03, 0xfd, 0xf2, 0x0a, 0x5d, 0x4c, 0x05, 0x48,
+0x20, 0x98, 0xca, 0x6b, 0x0c, 0x95, 0x30, 0x1c,
+};
+
+typedef struct VulkanEncodeH264Picture {
+int frame_num;
+int64_t last_idr_frame;
+uint16_t idr_pic_id;
+int primary_pic_type;
+int slice_type;
+int pic_order_cnt;
+
+enum UnitElems units_needed;
+
+VkVideoEncodeH264RateControlInfoKHR vkrc_info;
+VkVideoEncodeH264RateControlLayerInfoKHR vkrc_layer_info;
+
+StdVideoEncodeH264WeightTable slice_wt;
+StdVideoEncodeH264SliceHeader slice_hdr;
+VkVideoEncodeH264NaluSliceInfoKHR vkslice;
+
+StdVideoEncodeH264Pictu
Re: [FFmpeg-devel] [PATCH v3] libavcodec: implementation of DNxUncompressed decoder
Quoting Martin Schitter (2024-09-08 20:41:38) > As suggested by Zhao Zhili, here is a squash rebased 3rd attempt. > > I'm still unsure about my solution of adding the codec_id entries and > increasing the lead-position value, as criticized by Andreas Rheinhard, > but I don't see any other way to make it better. I think you're misunderstanding the meaning of AV_CODEC_ID_LEAD - it's not in any way special, it's just the ID of a codec called "LEAD MCMP". You should add your new codec ID immediately after it. -- 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 02/60] fftools/opt_common: fix variable shadowing
On 9 Sep 2024, at 12:10, Anton Khirnov wrote:
> Quoting Marvin Scholz (2024-09-08 19:43:27)
>> ---
>> fftools/opt_common.c | 12 ++--
>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/fftools/opt_common.c b/fftools/opt_common.c
>> index 9d2d5184a0..059f7a53d2 100644
>> --- a/fftools/opt_common.c
>> +++ b/fftools/opt_common.c
>> @@ -553,15 +553,15 @@ static void show_help_filter(const char *name)
>> }
>> #endif
>>
>> -static void show_help_bsf(const char *name)
>> +static void show_help_bsf(const char *bsf_name)
>> {
>> -const AVBitStreamFilter *bsf = av_bsf_get_by_name(name);
>> +const AVBitStreamFilter *bsf = av_bsf_get_by_name(bsf_name);
>>
>> -if (!name) {
>> +if (!bsf_name) {
>> av_log(NULL, AV_LOG_ERROR, "No bitstream filter name specified.\n");
>> return;
>> } else if (!bsf) {
>> -av_log(NULL, AV_LOG_ERROR, "Unknown bit stream filter '%s'.\n",
>> name);
>> +av_log(NULL, AV_LOG_ERROR, "Unknown bit stream filter '%s'.\n",
>> bsf_name);
>
> What does this fix? I don't see any other instance of 'name' in this
> function.
See the GET_CODEC_NAME definition:
const char *name = avcodec_descriptor_get(id)->name;
>
>> return;
>> }
>>
>> @@ -1205,10 +1205,10 @@ int init_report(const char *env, FILE **file)
>>
>> report_file = fopen(filename.str, "w");
>> if (!report_file) {
>> -int ret = AVERROR(errno);
>> +int err = AVERROR(errno);
>> av_log(NULL, AV_LOG_ERROR, "Failed to open report \"%s\": %s\n",
>> filename.str, strerror(errno));
>> -return ret;
>> +return err;
>
> Might as well use the outer ret.
Ok.
>
> --
> Anton Khirnov
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@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] aarch64: Implement support for elf_aux_info(3) on FreeBSD and OpenBSD
aarch64: Implement support for elf_aux_info(3) on FreeBSD and OpenBSD
FreeBSD 12.0+, OpenBSD -current and what will be OpenBSD 7.6 support
elf_aux_info(3).
Signed-off-by: Brad Smith
---
configure | 2 ++
libavutil/aarch64/cpu.c | 2 +-
libavutil/cpu.c | 9 -
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index a8e67d230c..d3bd46f382 100755
--- a/configure
+++ b/configure
@@ -2367,6 +2367,7 @@ SYSTEM_FUNCS="
clock_gettime
closesocket
CommandLineToArgvW
+elf_aux_info
fcntl
getaddrinfo
getauxval
@@ -6579,6 +6580,7 @@ check_func_headers mach/mach_time.h mach_absolute_time
check_func_headers stdlib.h getenv
check_func_headers sys/stat.h lstat
check_func_headers sys/auxv.h getauxval
+check_func_headers sys/auxv.h elf_aux_info
check_func_headers sys/sysctl.h sysctlbyname
check_func_headers windows.h GetModuleHandle
diff --git a/libavutil/aarch64/cpu.c b/libavutil/aarch64/cpu.c
index 084c81e999..7631d13de0 100644
--- a/libavutil/aarch64/cpu.c
+++ b/libavutil/aarch64/cpu.c
@@ -20,7 +20,7 @@
#include "libavutil/cpu_internal.h"
#include "config.h"
-#if (defined(__linux__) || defined(__ANDROID__)) && HAVE_GETAUXVAL
+#if HAVE_GETAUXVAL || HAVE_ELF_AUX_INFO
#include
#include
diff --git a/libavutil/cpu.c b/libavutil/cpu.c
index 61c1cf3faf..df00bd541f 100644
--- a/libavutil/cpu.c
+++ b/libavutil/cpu.c
@@ -49,7 +49,7 @@
#include
#endif
-#if HAVE_GETAUXVAL
+#if HAVE_GETAUXVAL || HAVE_ELF_AUX_INFO
#include
#endif
@@ -292,6 +292,13 @@ unsigned long ff_getauxval(unsigned long type)
{
#if HAVE_GETAUXVAL
return getauxval(type);
+#elif HAVE_ELF_AUX_INFO
+unsigned long aux = 0;
+int ret = elf_aux_info(type, &aux, sizeof(aux));
+if (ret != 0) {
+errno = ret;
+}
+return aux;
#else
errno = ENOSYS;
return 0;
--
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 v3] libavcodec: implementation of DNxUncompressed decoder
Quoting Martin Schitter (2024-09-08 20:41:38)
> diff --git a/libavcodec/dnxucdec.c b/libavcodec/dnxucdec.c
> new file mode 100644
> index 000..455c374
> --- /dev/null
> +++ b/libavcodec/dnxucdec.c
> @@ -0,0 +1,495 @@
> +/*
> + * Avid DNxUncomressed / SMPTE RDD 50 demuxer
This says it's a demuxer, while it's implemented as a decoder.
I'm also wondering if this shouldn't be handled as demuxer exporting
raw video, at least in some of cases if not all.
> + * Copyright (c) 2024 Martin Schitter
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> + */
> +
> +/*
> + This partial implementation of a decoder for DNxUncompressed video data
> + is based on reverse engineering of output generated by DaVinci Resolve 19
> + because the SMPTE RDD 50 specification is unfortunately not freely
> accessible.
> +
> + It's therefor limited by the present export capabilities of Resolve (YUV444
> + variants, YUV422 16bit, and alpha support is missing). But also some ffmpeg
> + shortcomings are affecting the range of available formats (no YUV half and
> + float pixel formats and filters are provided by ffmpeg until now and RGB
> half
> + content always requires an alpha plane).
> +
> + A wide range of DNxUncompressed formats are nevertheless already supported:
> +
> + - YUV 4:2:2 8-/10-/12-bit
> + - RGB 8-/10-/12-bit/half/float
> +
> +*/
> +
> +#include "avcodec.h"
> +#include "codec_internal.h"
> +#include "decode.h"
> +#include "libavutil/imgutils.h"
> +#include "thread.h"
> +
> +typedef struct DNxUcParseContext {
> +uint32_t fourcc_tag;
> +uint32_t width;
> +uint32_t height;
> +uint32_t nr_bytes;
> +} DNxUcParseContext;
Parser should be in its own file, as it can be enabled or disabled
independently from the encoder.
> +
> +/*
> +DNxUncompressed frame data comes wrapped in simple metadata
> +and fourcc markers:
> +
> +[0-4] number of raw data (37 bytes header + frame data)
> +[4-7] fourcc 'pack'
> +[8-11] unknown value (allways: 0x15)
> +[12-15] fourcc 'sinf'
> +[16-19] frame width / line packing size
> +[20-23] frame hight / nr of lines
> +[24-27] fourcc pixel format indicator
> +[28]unknown value (alpha?)
> +[29-32] nr of bytes in frame data + 8
> +[33-36] fourcc 'sdat'
> +[37-..] frame data
> +*/
> +
> +static int dnxuc_parse(AVCodecParserContext *s,
> +AVCodecContext *avctx,
> +const uint8_t **poutbuf, int *poutbuf_size,
> +const uint8_t *buf, int buf_size){
Opening brace of a function body should be on its own line.
> +
> +char fourcc_buf[5];
> +const int HEADER_SIZE = 37;
> +
> +DNxUcParseContext *pc;
> +pc = (DNxUcParseContext *) s->priv_data;
> +
> +if (!buf_size) {
> +return 0;
> +} else if ( buf_size < 37 /* check metadata structure expectations */
> +|| MKTAG('p','a','c','k') != *(uint32_t*) (buf+4)
> +|| MKTAG('s','i','n','f') != *(uint32_t*) (buf+12)
> +|| MKTAG('s','d','a','t') != *(uint32_t*) (buf+33)){
> +av_log(0, AV_LOG_ERROR, "can't read DNxUncompressed
> metadata.\n");
av_log() should always get a proper logging context, avctx in this case
> +*poutbuf_size = 0;
> +return buf_size;
> +}
> +
> +pc->fourcc_tag = *(uint32_t*)(buf+24);
> +pc->width = *(uint32_t*)(buf+16);
> +pc->height = *(uint32_t*)(buf+20);
> +pc->nr_bytes = *(uint32_t*)(buf+29) - 8;
Use AV_RL32()
> +
> +if (!avctx->codec_tag) {
> +av_fourcc_make_string(fourcc_buf, pc->fourcc_tag);
> +av_log(0, AV_LOG_INFO, "dnxuc_parser: '%s' %dx%d %dbpp %d\n",
> +fourcc_buf,
> +pc->width, pc->height,
> +(pc->nr_bytes*8)/(pc->width*pc->height),
> +pc->nr_bytes);
> +avctx->codec_tag = pc->fourcc_tag;
> +}
> +
> +if (pc->nr_bytes != buf_size - HEADER_SIZE){
> +av_log(avctx, AV_LOG_ERROR, "Insufficient size of data.\n");
> +*poutbuf_size = 0;
> +return buf_size;
> +}
> +
> +*poutbuf = buf + HEADER_SIZE;
> +*poutbuf_size = pc->nr_bytes;
> +
> +return buf_size;
> +}
> +
> +static av_cold int dnxuc_decode_init(AVCodecContext *avctx){
> +return 0;
> +}
> +
> +
> +static int pass_thoug
[FFmpeg-devel] [PATCH] avdevice/dshow: fix unused variable warning
The acaps variable was used outside of the #if DSHOWDEBUG block with
a1c4929f, but it is no longer used outside of the block since f125c504.
---
libavdevice/dshow.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c
index 84db151577..6e97304850 100644
--- a/libavdevice/dshow.c
+++ b/libavdevice/dshow.c
@@ -985,8 +985,8 @@ dshow_cycle_formats(AVFormatContext *avctx, enum
dshowDeviceType devtype,
}
} else {
WAVEFORMATEX *fx;
-AUDIO_STREAM_CONFIG_CAPS *acaps = caps;
#if DSHOWDEBUG
+AUDIO_STREAM_CONFIG_CAPS *acaps = caps;
ff_print_AUDIO_STREAM_CONFIG_CAPS(acaps);
#endif
if (IsEqualGUID(&type->formattype, &FORMAT_WaveFormatEx)) {
--
2.30.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] aarch64: Implement support for elf_aux_info(3) on FreeBSD and OpenBSD
On Mon, 9 Sep 2024, Brad Smith wrote: aarch64: Implement support for elf_aux_info(3) on FreeBSD and OpenBSD FreeBSD 12.0+, OpenBSD -current and what will be OpenBSD 7.6 support elf_aux_info(3). Signed-off-by: Brad Smith --- configure | 2 ++ libavutil/aarch64/cpu.c | 2 +- libavutil/cpu.c | 9 - 3 files changed, 11 insertions(+), 2 deletions(-) LGTM, thanks. (I guess the same change as in aarch64/cpu.c also could be done in other architectures' cpu.c?) // Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 02/60] fftools/opt_common: fix variable shadowing
Quoting epira...@gmail.com (2024-09-09 12:48:42)
>
>
> On 9 Sep 2024, at 12:10, Anton Khirnov wrote:
>
> > Quoting Marvin Scholz (2024-09-08 19:43:27)
> >> ---
> >> fftools/opt_common.c | 12 ++--
> >> 1 file changed, 6 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/fftools/opt_common.c b/fftools/opt_common.c
> >> index 9d2d5184a0..059f7a53d2 100644
> >> --- a/fftools/opt_common.c
> >> +++ b/fftools/opt_common.c
> >> @@ -553,15 +553,15 @@ static void show_help_filter(const char *name)
> >> }
> >> #endif
> >>
> >> -static void show_help_bsf(const char *name)
> >> +static void show_help_bsf(const char *bsf_name)
> >> {
> >> -const AVBitStreamFilter *bsf = av_bsf_get_by_name(name);
> >> +const AVBitStreamFilter *bsf = av_bsf_get_by_name(bsf_name);
> >>
> >> -if (!name) {
> >> +if (!bsf_name) {
> >> av_log(NULL, AV_LOG_ERROR, "No bitstream filter name
> >> specified.\n");
> >> return;
> >> } else if (!bsf) {
> >> -av_log(NULL, AV_LOG_ERROR, "Unknown bit stream filter '%s'.\n",
> >> name);
> >> +av_log(NULL, AV_LOG_ERROR, "Unknown bit stream filter '%s'.\n",
> >> bsf_name);
> >
> > What does this fix? I don't see any other instance of 'name' in this
> > function.
>
> See the GET_CODEC_NAME definition:
>
> const char *name = avcodec_descriptor_get(id)->name;
Does not exist in master after 377652da19bd1e5b9d81c22a4fce0a78a62b5853
--
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] fftools/opt_common: add missing newline after printing codecs
On 09/09/2024 11:57, Anton Khirnov wrote: Quoting Lynne via ffmpeg-devel (2024-09-09 10:34:21) This solves ffmpeg -help bsf=trace_headers => Supported codecs: av1 h264 hevc vvc mjpeg mpeg2video vp8 vp9 --- fftools/opt_common.c | 1 + 1 file changed, 1 insertion(+) Looks ok Pushed, thanks 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] aarch64: Implement support for elf_aux_info(3) on FreeBSD and OpenBSD
On 2024-09-09 7:00 a.m., Martin Storsjö wrote: On Mon, 9 Sep 2024, Brad Smith wrote: aarch64: Implement support for elf_aux_info(3) on FreeBSD and OpenBSD FreeBSD 12.0+, OpenBSD -current and what will be OpenBSD 7.6 support elf_aux_info(3). Signed-off-by: Brad Smith --- configure | 2 ++ libavutil/aarch64/cpu.c | 2 +- libavutil/cpu.c | 9 - 3 files changed, 11 insertions(+), 2 deletions(-) LGTM, thanks. (I guess the same change as in aarch64/cpu.c also could be done in other architectures' cpu.c?) // Martin I was looking at ppc for ppc64. Adding some sort of /proc/self/auxv fallback to ff_getauxval() and then re-writting all that to use ff_getauxval() and have support for FreeBSD/powerpc64 and OpenBSD/powerpc64. FFmpeg is the only project I have come across so far that does not use getauxval() on ppc64. ___ ffmpeg-devel mailing list ffmpeg-devel@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] aarch64: Implement support for elf_aux_info(3) on FreeBSD and OpenBSD
On Mon, Sep 9, 2024 at 1:01 PM Martin Storsjö wrote: > On Mon, 9 Sep 2024, Brad Smith wrote: > > > aarch64: Implement support for elf_aux_info(3) on FreeBSD and OpenBSD > > > > FreeBSD 12.0+, OpenBSD -current and what will be OpenBSD 7.6 support > > elf_aux_info(3). > > > > Signed-off-by: Brad Smith > > --- > > configure | 2 ++ > > libavutil/aarch64/cpu.c | 2 +- > > libavutil/cpu.c | 9 - > > 3 files changed, 11 insertions(+), 2 deletions(-) > > LGTM, thanks. (I guess the same change as in aarch64/cpu.c also could be > done in other architectures' cpu.c?) I agree. These are the cases I still see in the codebase: libavutil/mips/cpu.c: libavutil/arm/cpu.c: #if defined __linux__ || defined __ANDROID__ libavutil/loongarch/cpu.c: #if defined __linux__ In general we should avoid using system #ifdefs, relying instead on features that can be properly detected by configure. (This comment in unrelated to the patch) ___ ffmpeg-devel mailing list ffmpeg-devel@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] aarch64: Implement support for elf_aux_info(3) on FreeBSD and OpenBSD
On Mon, Sep 9, 2024 at 1:06 PM Brad Smith wrote: > On 2024-09-09 7:00 a.m., Martin Storsjö wrote: > > On Mon, 9 Sep 2024, Brad Smith wrote: > > > >> aarch64: Implement support for elf_aux_info(3) on FreeBSD and OpenBSD > >> > >> FreeBSD 12.0+, OpenBSD -current and what will be OpenBSD 7.6 support > >> elf_aux_info(3). > >> > >> Signed-off-by: Brad Smith > >> --- > >> configure | 2 ++ > >> libavutil/aarch64/cpu.c | 2 +- > >> libavutil/cpu.c | 9 - > >> 3 files changed, 11 insertions(+), 2 deletions(-) > > > > LGTM, thanks. (I guess the same change as in aarch64/cpu.c also could > > be done in other architectures' cpu.c?) > > I was looking at ppc for ppc64. Adding some sort of /proc/self/auxv > fallback to ff_getauxval() and then > re-writting all that to use ff_getauxval() and have support for > FreeBSD/powerpc64 and OpenBSD/powerpc64. > FFmpeg is the only project I have come across so far that does not use > getauxval() on ppc64. Patches welcome :). Do you have such a system for testing? ___ ffmpeg-devel mailing list ffmpeg-devel@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] aarch64: Implement support for elf_aux_info(3) on FreeBSD and OpenBSD
On 2024-09-09 7:11 a.m., Ramiro Polla wrote: On Mon, Sep 9, 2024 at 1:06 PM Brad Smith wrote: On 2024-09-09 7:00 a.m., Martin Storsjö wrote: On Mon, 9 Sep 2024, Brad Smith wrote: aarch64: Implement support for elf_aux_info(3) on FreeBSD and OpenBSD FreeBSD 12.0+, OpenBSD -current and what will be OpenBSD 7.6 support elf_aux_info(3). Signed-off-by: Brad Smith --- configure | 2 ++ libavutil/aarch64/cpu.c | 2 +- libavutil/cpu.c | 9 - 3 files changed, 11 insertions(+), 2 deletions(-) LGTM, thanks. (I guess the same change as in aarch64/cpu.c also could be done in other architectures' cpu.c?) I was looking at ppc for ppc64. Adding some sort of /proc/self/auxv fallback to ff_getauxval() and then re-writting all that to use ff_getauxval() and have support for FreeBSD/powerpc64 and OpenBSD/powerpc64. FFmpeg is the only project I have come across so far that does not use getauxval() on ppc64. Patches welcome :). Do you have such a system for testing? I have a Linux ppc64 VM so I can test that part. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] configure: enable warnings for shadowed variables
On 09/09/2024 12:02, Anton Khirnov wrote: Quoting Rémi Denis-Courmont (2024-09-09 09:32:07) Hi, Le 8 septembre 2024 19:57:38 GMT+03:00, Timo Rothenpieler a écrit : Well, the reality is, that without printing all these warnings, nobody will ever fix them. Unless someone sits down and spends potentially multiple days if not weeks of work to fix all the current ones. If we print all the warnings instead, it can get fixed gradually. I can only agree with Zhao and Andreas here. If you want to turn a warning flag on, you have to eliminate the warnings first. Otherwise you're just drowning the existing and typically more serious warnings in a sea of new warnings. The result is obvious: people will just ignore *all* warnigns then, and that's worse. +1 I don't have time to fix 1000+ warnings, so this is just blocked then. Great. ___ ffmpeg-devel mailing list ffmpeg-devel@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] Changelog: elaborate on what YUVJ is
Not all changelog readers may be familiar with it. --- Changelog | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Changelog b/Changelog index 7237648f95..b6f91d7c8c 100644 --- a/Changelog +++ b/Changelog @@ -19,7 +19,8 @@ version : - Cropping metadata parsing and writing in Matroska and MP4/MOV de/muxers - Intel QSV-accelerated VVC decoding - MediaCodec AAC/AMR-NB/AMR-WB/MP3 decoding -- YUV colorspace negotiation for codecs and filters, obsoleting YUVJ +- YUV colorspace negotiation for codecs and filters, obsoleting the + YUVJ pixel format version 7.0: -- 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 09/13] avformat: add an LCEVC stream group
Quoting James Almer (2024-09-08 15:26:51)
> On 9/6/2024 8:44 AM, Anton Khirnov wrote:
> > Quoting James Almer (2024-08-31 18:31:10)
> >> +typedef struct AVStreamGroupLCEVC {
> >> +const AVClass *av_class;
> >> +
> >> +/**
> >> + * Width of the final stream for presentation.
> >> + */
> >> +int width;
> >> +/**
> >> + * Height of the final image for presentation.
> >> + */
> >> +int height;
> >
> > What's the point of exporting these separately when they are the same as
> > the enhancement AVStream's dimensions?
>
> The enhancement stream is of data type, so width/height are undefined in
> it. Hence including these here.
Why not define them then? Seems simpler and more straightforward to me.
--
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 13/13] fftools/ffmpeg_demux: merge streams in a LCEVC stream group
Quoting James Almer (2024-09-06 16:05:33) > On 9/6/2024 10:33 AM, Anton Khirnov wrote: > > This is not the the only place where you're adding a check for discard, > > Because it's the only code i don't want to trigger for non-standalone > output packets. ??? > > > and I strongly dislike that 'discard' now does not mean 'discard' > > anymore. > > No, the packet is discarded in the end, and never makes anywhere on its > own unless it's used by an output. That's a bit too many qualifiers for my taste. With current code, discard means this: * discard=1: stream is not processed in any way * discard=0: stream is processed If you want to add more possible states, do so explicitly. That is probably best achieved by changing it to a mask (called something like 'used'), with values like USED_DIRECT and USED_LCEVC (I'm not convinced it is useful to introduce generic notions like "streamgroup bistream filters" until there is more than one user for them). > > Furthermore, I really dislike how invasive such an obscure feature is. > > Ideally, lavf would export the LCEVC stream payload as packet side data > in the video's stream, but that's apparently only possible with mov/mp4 > and maybe matroska, not TS. Hence a Stream Group is used and everything > left to the caller. > > That said, is this so invasive? This patch adds > DemuxStreamGroup/InputStreamGroup, cleanly initializes them like we > already do with DemuxStream/InputStream, and then factorizes the bsf > packet loop so it can be used for the stream bsf and the group bsf. > The only truly big change is making libavformat output streams that are > not strictly used by an output, which is achieved by making > AVStream->discard not be set, and keep relying on DemuxStream->discard > to know what stream is disabled or not. You are introducing a bunch of new core concepts that do not apply to anything except LCEVC, and rewriting a lot of core demuxing code around them. So yes, that looks invasive to me. -- 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 6/6] avcodec/hevc: ff_hevc_(qpel/epel)_filters are signed type
> On Sep 9, 2024, at 18:35, Anton Khirnov wrote:
>
> Quoting Zhao Zhili (2024-09-07 19:13:40)
>> From: Zhao Zhili
>>
>> ---
>> libavcodec/hevc/dsp_template.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavcodec/hevc/dsp_template.c b/libavcodec/hevc/dsp_template.c
>> index aebccd1a0c..a0f79c2673 100644
>> --- a/libavcodec/hevc/dsp_template.c
>> +++ b/libavcodec/hevc/dsp_template.c
>> @@ -302,8 +302,8 @@ IDCT_DC(32)
>>
>> #define ff_hevc_pel_filters ff_hevc_qpel_filters
>> #define DECL_HV_FILTER(f) \
>> -const uint8_t *hf = ff_hevc_ ## f ## _filters[mx]; \
>> -const uint8_t *vf = ff_hevc_ ## f ## _filters[my];
>> +const int8_t *hf = ff_hevc_ ## f ## _filters[mx]; \
>> +const int8_t *vf = ff_hevc_ ## f ## _filters[my];
>
> Looks ok, though I wonder why are these then used as intptr_t.
They are accessed as const int8_t * in h256_inter_template.c. For example
static void
put_hevc_pel_pixels_8(int16_t *dst, const uint8_t *src, ptrdiff_t srcstride,
int height, intptr_t mx, intptr_t my, int width) {
const uint8_t *hf = ff_hevc_qpel_filters[mx];
const uint8_t *vf = ff_hevc_qpel_filters[my];
put_pixels_8(dst, src, srcstride, height, hf, vf, width);
}
I experienced a lot of headaches with these macro.
>
> --
> Anton Khirnov
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@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, v2] avcodec/amfenc: Fixes the color information in the output.
> Apologies for missing this prior to merge, but you can't safely make these > assumptions about primaries and TRC just based on the input bit depth. Just > because it's 8-bit content doesn't mean it will be BT.709 and likewise for > 10-bit and BT.2020+SMPTE 2084 PQ. > > Why doesn't amfenc_hevc (and amfenc_av1) use the values from avctx like > amfenc_h264 does? Current hardware color space converter does not support transfer characteristics other than this: (BT709 for 8-bit output and BT2084 for 10-bit output) so for RGB input we need them hard-coded. If conversion is done before AMF encoder, the encoder can accept any value as it is just fields in VUI header. So, we will come with a separate patch which would reflect this 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".
Re: [FFmpeg-devel] [PATCH] avcodec/amfenc: Fix HEVC/AV1 colorspace assumptions
> -if (color_depth == AMF_COLOR_BIT_DEPTH_8) {
> -/// Color Transfer Characteristics (AMF matches ISO/IEC)
> -AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_OUTPUT_TRANSFER_CHARACTERISTIC,
AMF_COLOR_TRANSFER_CHARACTERISTIC_BT709);
> -/// Color Primaries (AMF matches ISO/IEC)
> -AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_OUTPUT_COLOR_PRIMARIES, AMF_COLOR_PRIMARIES_BT709);
> -} else {
> -AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_OUTPUT_TRANSFER_CHARACTERISTIC,
AMF_COLOR_TRANSFER_CHARACTERISTIC_SMPTE2084);
> -AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_OUTPUT_COLOR_PRIMARIES, AMF_COLOR_PRIMARIES_BT2020);
> -}
> +/// Color Transfer Characteristics (AMF matches ISO/IEC)
> +AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_OUTPUT_TRANSFER_CHARACTERISTIC,
(amf_int64)avctx->color_trc);
> +/// Color Primaries (AMF matches ISO/IEC)
> +AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_OUTPUT_COLOR_PRIMARIES,
(amf_int64)avctx->color_primaries);
> -if (color_depth == AMF_COLOR_BIT_DEPTH_8) {
> -/// Color Transfer Characteristics (AMF matches ISO/IEC)
> -AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_HEVC_OUTPUT_TRANSFER_CHARACTERISTIC,
AMF_COLOR_TRANSFER_CHARACTERISTIC_BT709);
> -/// Color Primaries (AMF matches ISO/IEC)
> -AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_HEVC_OUTPUT_COLOR_PRIMARIES, AMF_COLOR_PRIMARIES_BT709);
> -} else {
> -AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_HEVC_OUTPUT_TRANSFER_CHARACTERISTIC,
AMF_COLOR_TRANSFER_CHARACTERISTIC_SMPTE2084);
> -AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_HEVC_OUTPUT_COLOR_PRIMARIES, AMF_COLOR_PRIMARIES_BT2020);
> -}
> +/// Color Transfer Characteristics (AMF matches ISO/IEC)
> +AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_HEVC_OUTPUT_TRANSFER_CHARACTERISTIC,
(amf_int64)avctx->color_trc);
> +/// Color Primaries (AMF matches ISO/IEC)
> +AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_HEVC_OUTPUT_COLOR_PRIMARIES,
(amf_int64)avctx->color_primaries);
Current hardware color space converter does not support transfer
characteristics other than this:
(BT709 for 8-bit output and BT2084 for 10-bit output) so for RGB input
we need them hard-coded. If conversion is done before AMF encoder, the
encoder can accept any value as it is just fields in VUI header.
So, we will come with a separate patch which would reflect this logic.
I also answered the same on your comment to my patch:
avcodec/amfenc: Fixes the color information in the output.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] compat: drop gcc, suncc, and pthreads stdatomic emulation
Since we now require a C11-compliant compiler, there should be no
supported configurations where any of these is used.
---
compat/atomics/gcc/stdatomic.h | 173 -
compat/atomics/pthread/stdatomic.c | 39 --
compat/atomics/pthread/stdatomic.h | 197 -
compat/atomics/suncc/stdatomic.h | 186 ---
configure | 19 +--
5 files changed, 1 insertion(+), 613 deletions(-)
delete mode 100644 compat/atomics/gcc/stdatomic.h
delete mode 100644 compat/atomics/pthread/stdatomic.c
delete mode 100644 compat/atomics/pthread/stdatomic.h
delete mode 100644 compat/atomics/suncc/stdatomic.h
diff --git a/compat/atomics/gcc/stdatomic.h b/compat/atomics/gcc/stdatomic.h
deleted file mode 100644
index e13ed0e068..00
--- a/compat/atomics/gcc/stdatomic.h
+++ /dev/null
@@ -1,173 +0,0 @@
-/*
- * 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
- */
-
-/*
- * based on vlc_atomic.h from VLC
- * Copyright (C) 2010 Rémi Denis-Courmont
- */
-
-#ifndef COMPAT_ATOMICS_GCC_STDATOMIC_H
-#define COMPAT_ATOMICS_GCC_STDATOMIC_H
-
-#include
-#include
-
-#define ATOMIC_FLAG_INIT 0
-
-#define ATOMIC_VAR_INIT(value) (value)
-
-#define atomic_init(obj, value) \
-do {\
-*(obj) = (value); \
-} while(0)
-
-#define kill_dependency(y) ((void)0)
-
-#define atomic_thread_fence(order) \
-__sync_synchronize()
-
-#define atomic_signal_fence(order) \
-((void)0)
-
-#define atomic_is_lock_free(obj) 0
-
-typedef _Bool atomic_flag;
-typedef _Bool atomic_bool;
-typedef char atomic_char;
-typedef signed char atomic_schar;
-typedef unsigned char atomic_uchar;
-typedef short atomic_short;
-typedef unsigned short atomic_ushort;
-typedef int atomic_int;
-typedef unsigned int atomic_uint;
-typedef long atomic_long;
-typedef unsigned long atomic_ulong;
-typedef long long atomic_llong;
-typedef unsigned long long atomic_ullong;
-typedef wchar_t atomic_wchar_t;
-typedef int_least8_t atomic_int_least8_t;
-typedef uint_least8_t atomic_uint_least8_t;
-typedef int_least16_t atomic_int_least16_t;
-typedef uint_least16_t atomic_uint_least16_t;
-typedef int_least32_t atomic_int_least32_t;
-typedef uint_least32_t atomic_uint_least32_t;
-typedef int_least64_t atomic_int_least64_t;
-typedef uint_least64_t atomic_uint_least64_t;
-typedef int_fast8_t atomic_int_fast8_t;
-typedef uint_fast8_t atomic_uint_fast8_t;
-typedef int_fast16_t atomic_int_fast16_t;
-typedef uint_fast16_t atomic_uint_fast16_t;
-typedef int_fast32_t atomic_int_fast32_t;
-typedef uint_fast32_t atomic_uint_fast32_t;
-typedef int_fast64_t atomic_int_fast64_t;
-typedef uint_fast64_t atomic_uint_fast64_t;
-typedef intptr_t atomic_intptr_t;
-typedef uintptr_t atomic_uintptr_t;
-typedefsize_t atomic_size_t;
-typedef ptrdiff_t atomic_ptrdiff_t;
-typedef intmax_t atomic_intmax_t;
-typedef uintmax_t atomic_uintmax_t;
-
-#define atomic_store(object, desired) \
-do {\
-*(object) = (desired); \
-__sync_synchronize(); \
-} while (0)
-
-#define atomic_store_explicit(object, desired, order) \
-atomic_store(object, desired)
-
-#define atomic_load(object) \
-(__sync_synchronize(), *(object))
-
-#define atomic_load_explicit(object, order) \
-atomic_load(object)
-
-#define atomic_exchange(object, desired)\
-({ \
-__typeof__(object) _obj = (object); \
-__typeof__(*object) _old; \
-do \
-_old = atomic_load(_obj); \
-while (!__sync_bool_compare_and_swap(_obj, _old, (desired))); \
-_old; \
-})
-
-#define atomic_exchange_explicit(object, desired, order) \
-atomic_exchange(object, desired)
[FFmpeg-devel] [PATCH 2/2] compat: add a fallback implementation of C23 stdbit.h
From: Rémi Denis-Courmont
Header contents taken from VLC commit 7a970a33329c9836d169727ddbaf49a33240d587.
Signed-off-by: Anton Khirnov
---
I will use this in my pending MV-HEVC set.
Could also be used to replace parts of intmath.h/common.h
---
compat/stdbit/stdbit.h | 594 +
configure | 4 +
2 files changed, 598 insertions(+)
create mode 100644 compat/stdbit/stdbit.h
diff --git a/compat/stdbit/stdbit.h b/compat/stdbit/stdbit.h
new file mode 100644
index 00..b6a2c7e945
--- /dev/null
+++ b/compat/stdbit/stdbit.h
@@ -0,0 +1,594 @@
+/*
+ * Copyright (C) 2023 Rémi Denis-Courmont
+ *
+ * This program 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.
+ *
+ * This program 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 this program; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin Street, Fifth Floor, Boston MA 02110-1301, USA.
+ */
+
+#ifndef __STDC_VERSION_STDBIT_H__
+#define __STDC_VERSION_STDBIT_H__ 202311L
+
+#include
+#include /* CHAR_BIT */
+
+#define __STDC_ENDIAN_LITTLE__ 1234
+#define __STDC_ENDIAN_BIG__4321
+
+#ifdef __BYTE_ORDER__
+# if (__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__)
+# define __STDC_ENDIAN_NATIVE__ __STDC_ENDIAN_LITTLE__
+# elif (__BYTE_ORDER__ == __ORDER_BIG_ENDIAN__)
+# define __STDC_ENDIAN_NATIVE__ __STDC_ENDIAN_BIG__
+# else
+# define __STDC_ENDIAN_NATIVE__ 3412
+# endif
+#else
+# error Not implemented.
+#endif
+
+#define __stdbit_generic_type_func(func, value) \
+_Generic (value, \
+unsigned long long: stdc_##func##_ull((unsigned long long)(value)), \
+unsigned long: stdc_##func##_ul((unsigned long)(value)), \
+unsigned int: stdc_##func##_ui((unsigned int)(value)), \
+unsigned short: stdc_##func##_us((unsigned short)(value)), \
+unsigned char: stdc_##func##_uc((unsigned char)(value)))
+
+#if defined (__GNUC__) || defined (__clang__)
+static inline unsigned int stdc_leading_zeros_ull(unsigned long long value)
+{
+return value ? __builtin_clzll(value) : (CHAR_BIT * sizeof (value));
+}
+
+static inline unsigned int stdc_leading_zeros_ul(unsigned long value)
+{
+return value ? __builtin_clzl(value) : (CHAR_BIT * sizeof (value));
+}
+
+static inline unsigned int stdc_leading_zeros_ui(unsigned int value)
+{
+return value ? __builtin_clz(value) : (CHAR_BIT * sizeof (value));
+}
+
+static inline unsigned int stdc_leading_zeros_us(unsigned short value)
+{
+return stdc_leading_zeros_ui(value)
+ - CHAR_BIT * (sizeof (int) - sizeof (value));
+}
+
+static inline unsigned int stdc_leading_zeros_uc(unsigned char value)
+{
+return stdc_leading_zeros_ui(value) - (CHAR_BIT * (sizeof (int) - 1));
+}
+#else
+static inline unsigned int __stdc_leading_zeros(unsigned long long value,
+unsigned int size)
+{
+unsigned int zeros = size * CHAR_BIT;
+
+while (value != 0) {
+value >>= 1;
+zeros--;
+}
+
+return zeros;
+}
+
+static inline unsigned int stdc_leading_zeros_ull(unsigned long long value)
+{
+return __stdc_leading_zeros(value, sizeof (value));
+}
+
+static inline unsigned int stdc_leading_zeros_ul(unsigned long value)
+{
+return __stdc_leading_zeros(value, sizeof (value));
+}
+
+static inline unsigned int stdc_leading_zeros_ui(unsigned int value)
+{
+return __stdc_leading_zeros(value, sizeof (value));
+}
+
+static inline unsigned int stdc_leading_zeros_us(unsigned short value)
+{
+return __stdc_leading_zeros(value, sizeof (value));
+}
+
+static inline unsigned int stdc_leading_zeros_uc(unsigned char value)
+{
+return __stdc_leading_zeros(value, sizeof (value));
+}
+#endif
+
+#define stdc_leading_zeros(value) \
+__stdbit_generic_type_func(leading_zeros, value)
+
+static inline unsigned int stdc_leading_ones_ull(unsigned long long value)
+{
+return stdc_leading_zeros_ull(~value);
+}
+
+static inline unsigned int stdc_leading_ones_ul(unsigned long value)
+{
+return stdc_leading_zeros_ul(~value);
+}
+
+static inline unsigned int stdc_leading_ones_ui(unsigned int value)
+{
+return stdc_leading_zeros_ui(~value);
+}
+
+static inline unsigned int stdc_leading_ones_us(unsigned short value)
+{
+return stdc_leading_zeros_us(~value);
+}
+
+static inline unsigned int stdc_leading_ones_uc(unsigned char value)
+{
+return stdc_leading_zeros_uc(~value);
+}
+
+#define stdc_leading_ones(value) \
+__stdbit_generic_type_func(
[FFmpeg-devel] [PATCH] libavutil/ppc: Make use of getauxval() and elf_aux_info() on ppc
libavutil/ppc: Make use of getauxval() and elf_aux_info() on ppc
Modern Linux has getauxval() and FreeBSD/OpenBSD ppc have elf_aux_info().
Signed-off-by: Brad Smith
---
libavutil/ppc/cpu.c | 16
1 file changed, 16 insertions(+)
diff --git a/libavutil/ppc/cpu.c b/libavutil/ppc/cpu.c
index 2b13cda662..6dc1961e7a 100644
--- a/libavutil/ppc/cpu.c
+++ b/libavutil/ppc/cpu.c
@@ -20,6 +20,8 @@
#ifdef __APPLE__
#include
+#elif HAVE_GETAUXVAL || HAVE_ELF_AUX_INFO
+#include
#elif defined(__linux__)
#include
#include
@@ -56,6 +58,20 @@ int ff_get_cpu_flags_ppc(void)
if (result == VECTORTYPE_ALTIVEC)
return AV_CPU_FLAG_ALTIVEC;
return 0;
+#elif HAVE_GETAUXVAL || HAVE_ELF_AUX_INFO
+int flags = 0;
+
+unsigned long hwcap = ff_getauxval(AT_HWCAP);
+unsigned long hwcap2 = ff_getauxval(AT_HWCAP2);
+
+if (hwcap & PPC_FEATURE_HAS_ALTIVEC)
+ flags |= AV_CPU_FLAG_ALTIVEC;
+if (hwcap & PPC_FEATURE_HAS_VSX)
+ flags |= AV_CPU_FLAG_VSX;
+if (hwcap2 & PPC_FEATURE2_ARCH_2_07)
+ flags |= AV_CPU_FLAG_POWER8;
+
+return flags;
#elif defined(__APPLE__) || defined(__NetBSD__) || defined(__OpenBSD__)
#if defined(__NetBSD__) || defined(__OpenBSD__)
int sels[2] = {CTL_MACHDEP, CPU_ALTIVEC};
--
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, v2] avcodec/amfenc: increase precision of Sleep() on Windows
> > > I took a look at this using AMD's AMF EncoderLatency sample and found > that > > setting the QUERY_TIMEOUT option to 50 ms (as is default for the new AMF > > HQ and HQLL usage values) results in latency that is better than the > > current AMF code in FFmpeg *and* this patch without having to touch > > the process's timer precision. > > > > Here are the results from QUERY_TIMEOUT=0, amf_sleep(1), 1ms timer > period: > > Encoder: AMFVideoEncoderVCE_AVC > > Total : Frames = 500 Duration = 1157.16ms FPS = 432.09frames > > Latency: First,Min,Max = 7.12ms, 1.53ms, 3.73ms > > Latency: Average = 1.99ms > > > > and the results from QUERY_TIMEOUT=50, default timer period: > > Encoder: AMFVideoEncoderVCE_AVC > > Total : Frames = 500 Duration = 933.03ms FPS = 535.89frames > > Latency: First,Min,Max = 5.80ms, 1.49ms, 2.50ms > > Latency: Average = 1.58ms > > > > This seems to clearly demonstrate that QUERY_TIMEOUT is a better approach > > than adjusting timer resolution. It avoids process-wide effects *and* > > it even performs better on top of that. > > > > > > Cameron > Thanks everyone and Cameron, TIMEOUT might be a possible solution. Need some time for evaluating the performance impact of using it. The problem is that FFmpeg calls SubmitInput and QueryOutput from the same thread and if B-frames and/or look-ahead enabled, initially not enough input submitted and QueryOutput will wait till timeout value. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] configure: enable warnings for shadowed variables
On Mon, Sep 9, 2024 at 1:23 PM Timo Rothenpieler wrote: > On 09/09/2024 12:02, Anton Khirnov wrote: > > Quoting Rémi Denis-Courmont (2024-09-09 09:32:07) > >> Hi, > >> > >> Le 8 septembre 2024 19:57:38 GMT+03:00, Timo Rothenpieler < > t...@rothenpieler.org> a écrit : > >>> > >>> Well, the reality is, that without printing all these warnings, nobody > will ever fix them. > >>> Unless someone sits down and spends potentially multiple days if not > weeks of work to fix all the current ones. > >> > >>> > >>> If we print all the warnings instead, it can get fixed gradually. > >> > >> I can only agree with Zhao and Andreas here. If you want to turn a > warning flag on, you have to eliminate the warnings first. > >> > >> Otherwise you're just drowning the existing and typically more serious > warnings in a sea of new warnings. The result is obvious: people will just > ignore *all* warnigns then, and that's worse. > > > > +1 > > > > I don't have time to fix 1000+ warnings, so this is just blocked then. > Maybe this could be a task to be sponsored with the STF funds? -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC/PATCH] MV-HEVC decoding
Thanks for the patch set! Ran some initial tests and here are some findings: 1. Tested using the HTM ref SW encoded bitstreams; the HTM encoded 2 layer MV-HEVC elementary streams are decoded by both the HTM decoder and ffmpeg, and both resulted in the same decoded pixels for both views. 2. Tested with the iPhone captured sample videos (some samples are available from https://blog.frame.io/2024/02/01/how-to-capture-and-view-vision-pro-spatial-video/). To decode using the HTM decoder, converted the .mov file to .hevc elementary stream (using "ffmpeg -view_ids -1 -i sample.mov -vcodec copy sample.hevc"). The iPhone captured MV-HEVC seems to be non-conformant as for the very first AU we have the following NAL units: prefix SEI (layer ID 0), CRA (layer ID 0), prefix SEI (layer ID 0), CRA (layer ID 1). Based on Section 7.4.2.4.4 of the HEVC spec, a prefix SEI with layer ID 0 indicates a new AU, so the bitstream is not conformant for the 2 layer case. The reference HTM decoder seems to be tolerant to this and correctly decodes the "non-conformant" elementary stream, but ffmpeg does not. However, ffmpeg does decode the .mov container file correctly as each AU is correctly passed to the decoder as a video sample. Aside from this con-conformance issue, both the HTM decoder and ffmpeg seem to produce pixel exact views. For the view by view comparison, I had to manually skip some initial frames output by the HTM decoder, as ffmpeg did not output some of the first few views/frames. 3. When ffmpeg skips some of the decoded views for output, I think it makes sense to skip both views of an AU (when both views are being output)? Currently one view from an AU can be skipped without skipping its corresponding other view. To avoid some of the views from being skipped, I had to use the "-vsync 0" option for my tests. When I use this option, I see the following warning: "Application provided invalid, non monotonically increasing dts to muxer in stream 0: 1 >= 1". This seems due to both views of an AU having the same DTS, which is expected. 4. Ran ffmpeg with the "-vf showinfo" option and the side data seems to indicate correct info for the views. I tested both cases where the base layer corresponds to either left or right view, and both cases seem to result in correct side data. BR, Danny ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4] libavdevice/decklink: extend available actions on signal loss
On Tue, 11 Jun 2024, Michael Riedl wrote:
Deprecate the option 'draw_bars' in favor of the new option
'signal_loss_action',
which controls the behavior when the input signal is not available
(including the behavior previously available through draw_bars).
The default behavior remains unchanged to be backwards compatible.
The new option is more flexible for extending now and in the future.
The new value 'repeat' repeats the last video frame.
This is useful for very short dropouts and was not available before.
Sorry it took this long, but I finally checked the patch and applied a
slightly simplifed version.
Thanks,
Marton
Signed-off-by: Michael Riedl
---
doc/indevs.texi | 16
libavdevice/decklink_common.h | 1 +
libavdevice/decklink_common_c.h | 7 +++
libavdevice/decklink_dec.cpp| 34 -
libavdevice/decklink_dec_c.c| 6 +-
5 files changed, 58 insertions(+), 6 deletions(-)
diff --git a/doc/indevs.texi b/doc/indevs.texi
index 734fc65752..cdf44a6638 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -396,6 +396,22 @@ Defaults to @samp{audio}.
@item draw_bars
If set to @samp{true}, color bars are drawn in the event of a signal loss.
Defaults to @samp{true}.
+This option is deprecated, please use the @code{signal_loss_action} option.
+
+@item signal_loss_action
+Sets the action to take in the event of a signal loss. Accepts one of the
+following values:
+
+@table @option
+@item 1, none
+Do nothing on signal loss. This usually results in black frames.
+@item 2, bars
+Draw color bars on signal loss. Only supported for 8-bit input signals.
+@item 3, repeat
+Repeat the last video frame on signal loss.
+@end table
+
+Defaults to @samp{bars}.
@item queue_size
Sets maximum input buffer size in bytes. If the buffering reaches this value,
diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
index c54a635876..6b32dc2d09 100644
--- a/libavdevice/decklink_common.h
+++ b/libavdevice/decklink_common.h
@@ -147,6 +147,7 @@ struct decklink_ctx {
DecklinkPtsSource video_pts_source;
int draw_bars;
BMDPixelFormat raw_format;
+DecklinkSignalLossAction signal_loss_action;
int frames_preroll;
int frames_buffer;
diff --git a/libavdevice/decklink_common_c.h b/libavdevice/decklink_common_c.h
index 9c55d89149..53d2c583e7 100644
--- a/libavdevice/decklink_common_c.h
+++ b/libavdevice/decklink_common_c.h
@@ -37,6 +37,12 @@ typedef enum DecklinkPtsSource {
PTS_SRC_NB
} DecklinkPtsSource;
+typedef enum DecklinkSignalLossAction {
+SIGNAL_LOSS_NONE= 1,
+SIGNAL_LOSS_REPEAT = 2,
+SIGNAL_LOSS_BARS= 3
+} DecklinkSignalLossAction;
+
struct decklink_cctx {
const AVClass *cclass;
@@ -68,6 +74,7 @@ struct decklink_cctx {
int64_t timestamp_align;
int timing_offset;
int wait_for_tc;
+DecklinkSignalLossAction signal_loss_action;
};
#endif /* AVDEVICE_DECKLINK_COMMON_C_H */
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 671573853b..d057366378 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -593,6 +593,7 @@ private:
int no_video;
int64_t initial_video_pts;
int64_t initial_audio_pts;
+IDeckLinkVideoInputFrame* last_video_frame;
};
decklink_input_callback::decklink_input_callback(AVFormatContext *_avctx) :
_refs(1)
@@ -602,10 +603,13 @@
decklink_input_callback::decklink_input_callback(AVFormatContext *_avctx) : _ref
ctx = (struct decklink_ctx *)cctx->ctx;
no_video = 0;
initial_audio_pts = initial_video_pts = AV_NOPTS_VALUE;
+last_video_frame = nullptr;
}
decklink_input_callback::~decklink_input_callback()
{
+if (last_video_frame)
+last_video_frame->Release();
}
ULONG decklink_input_callback::AddRef(void)
@@ -730,6 +734,7 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
BMDTimeValue frameDuration;
int64_t wallclock = 0, abs_wallclock = 0;
struct decklink_cctx *cctx = (struct decklink_cctx *) avctx->priv_data;
+IDeckLinkVideoInputFrame *currentVideoFrame = videoFrame; // video frame
that holds frameBytes
if (ctx->autodetect) {
if (videoFrame && !(videoFrame->GetFlags() & bmdFrameHasNoInputSource)
&&
@@ -773,7 +778,7 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
ctx->video_st->time_base.den);
if (videoFrame->GetFlags() & bmdFrameHasNoInputSource) {
-if (ctx->draw_bars && videoFrame->GetPixelFormat() ==
bmdFormat8BitYUV) {
+if (ctx->signal_loss_action == SIGNAL_LOSS_BARS &&
videoFrame->GetPixelFormat() == bmdFormat8BitYUV) {
unsigned bars[8] = {
0xEA80EA80, 0xD292D210, 0xA910A9A5, 0x90229035,
0x6ADD6ACA, 0x51EF515A, 0x286D28EF, 0x10801080 };
@@ -785,6 +790,9 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
for (int x = 0; x < width; x
Re: [FFmpeg-devel] [PATCH v3] libavcodec: implementation of DNxUncompressed decoder
On Sun, 8 Sep 2024, Martin Schitter wrote:
As suggested by Zhao Zhili, here is a squash rebased 3rd attempt.
I'm still unsure about my solution of adding the codec_id entries and
increasing the lead-position value, as criticized by Andreas Rheinhard,
but I don't see any other way to make it better.
martin
---
Changelog | 1 +
doc/general_contents.texi | 1 +
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c| 1 +
libavcodec/codec_desc.c | 7 +
libavcodec/codec_id.h | 1 +
libavcodec/dnxucdec.c | 495 ++
libavcodec/parsers.c | 1 +
libavcodec/version.c | 2 +-
libavcodec/version.h | 2 +-
libavformat/mxf.c | 1 +
libavformat/mxfdec.c | 21 ++
12 files changed, 532 insertions(+), 2 deletions(-)
create mode 100644 libavcodec/dnxucdec.c
You should split this patch to at least 3 parts for easier review. Adding
the codec ID and description, adding MXF demux support, and adding the
decoder/parser.
There is a note saying that the specs are not freely accessible, that is
not the case as far as I see:
https://pub.smpte.org/doc/rdd50/20190730-pub/
So maybe you want to check your work based on the specs?
Thanks,
Marton
diff --git a/Changelog b/Changelog
index 583de26..fbda69e 100644
--- a/Changelog
+++ b/Changelog
@@ -19,6 +19,7 @@ version :
- Cropping metadata parsing and writing in Matroska and MP4/MOV de/muxers
- Intel QSV-accelerated VVC decoding
- MediaCodec AAC/AMR-NB/AMR-WB/MP3 decoding
+- DNxUncompressed (SMPTE RDD 50) decoder
version 7.0:
diff --git a/doc/general_contents.texi b/doc/general_contents.texi
index e7cf4f8..1593124 100644
--- a/doc/general_contents.texi
+++ b/doc/general_contents.texi
@@ -619,6 +619,7 @@ library:
@item raw DFPWM @tab X @tab X
@item raw Dirac @tab X @tab X
@item raw DNxHD @tab X @tab X
+@itme raw DNxUncompressed @tab @tab X
@item raw DTS @tab X @tab X
@item raw DTS-HD@tab @tab X
@item raw E-AC-3@tab X @tab X
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 75ae377..cfa8fba 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -325,6 +325,7 @@ OBJS-$(CONFIG_DFPWM_DECODER) += dfpwmdec.o
OBJS-$(CONFIG_DFPWM_ENCODER) += dfpwmenc.o
OBJS-$(CONFIG_DNXHD_DECODER) += dnxhddec.o dnxhddata.o
OBJS-$(CONFIG_DNXHD_ENCODER) += dnxhdenc.o dnxhddata.o
+OBJS-$(CONFIG_DNXUC_DECODER) += dnxucdec.o
OBJS-$(CONFIG_DOLBY_E_DECODER) += dolby_e.o dolby_e_parse.o kbdwin.o
OBJS-$(CONFIG_DPX_DECODER) += dpx.o
OBJS-$(CONFIG_DPX_ENCODER) += dpxenc.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 563afde..ea8f2a4 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -93,6 +93,7 @@ extern const FFCodec ff_dfa_decoder;
extern const FFCodec ff_dirac_decoder;
extern const FFCodec ff_dnxhd_encoder;
extern const FFCodec ff_dnxhd_decoder;
+extern const FFCodec ff_dnxuc_decoder;
extern const FFCodec ff_dpx_encoder;
extern const FFCodec ff_dpx_decoder;
extern const FFCodec ff_dsicinvideo_decoder;
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index a28ef68..2b83ea2 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1952,6 +1952,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
.long_name = NULL_IF_CONFIG_SMALL("vMix Video"),
.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY,
},
+{
+.id= AV_CODEC_ID_DNXUC,
+.type = AVMEDIA_TYPE_VIDEO,
+.name = "dnxuc",
+.long_name = NULL_IF_CONFIG_SMALL("DNxUncompressed / SMPTE RDD 50"),
+.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
+},
{
.id= AV_CODEC_ID_LEAD,
.type = AVMEDIA_TYPE_VIDEO,
diff --git a/libavcodec/codec_id.h b/libavcodec/codec_id.h
index 0ab1e34..27b229b 100644
--- a/libavcodec/codec_id.h
+++ b/libavcodec/codec_id.h
@@ -321,6 +321,7 @@ enum AVCodecID {
AV_CODEC_ID_EVC,
AV_CODEC_ID_RTV1,
AV_CODEC_ID_VMIX,
+AV_CODEC_ID_DNXUC,
AV_CODEC_ID_LEAD,
/* various PCM "codecs" */
diff --git a/libavcodec/dnxucdec.c b/libavcodec/dnxucdec.c
new file mode 100644
index 000..455c374
--- /dev/null
+++ b/libavcodec/dnxucdec.c
@@ -0,0 +1,495 @@
+/*
+ * Avid DNxUncomressed / SMPTE RDD 50 demuxer
+ * Copyright (c) 2024 Martin Schitter
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR
Re: [FFmpeg-devel] [PATCH, v2] avcodec/amfenc: increase precision of Sleep() on Windows
On Mon, Sep 9, 2024 at 11:05 AM Araz wrote:
>>
>> > I took a look at this using AMD's AMF EncoderLatency sample and found that
>> > setting the QUERY_TIMEOUT option to 50 ms (as is default for the new AMF
>> > HQ and HQLL usage values) results in latency that is better than the
>> > current AMF code in FFmpeg *and* this patch without having to touch
>> > the process's timer precision.
>> >
>> > Here are the results from QUERY_TIMEOUT=0, amf_sleep(1), 1ms timer period:
>> > Encoder: AMFVideoEncoderVCE_AVC
>> > Total : Frames = 500 Duration = 1157.16ms FPS = 432.09frames
>> > Latency: First,Min,Max = 7.12ms, 1.53ms, 3.73ms
>> > Latency: Average = 1.99ms
>> >
>> > and the results from QUERY_TIMEOUT=50, default timer period:
>> > Encoder: AMFVideoEncoderVCE_AVC
>> > Total : Frames = 500 Duration = 933.03ms FPS = 535.89frames
>> > Latency: First,Min,Max = 5.80ms, 1.49ms, 2.50ms
>> > Latency: Average = 1.58ms
>> >
>> > This seems to clearly demonstrate that QUERY_TIMEOUT is a better approach
>> > than adjusting timer resolution. It avoids process-wide effects *and*
>> > it even performs better on top of that.
>> >
>> >
>> > Cameron
>
>
> Thanks everyone and Cameron,
> TIMEOUT might be a possible solution.
> Need some time for evaluating the performance impact of using it.
> The problem is that FFmpeg calls SubmitInput and QueryOutput
> from the same thread and if B-frames and/or look-ahead enabled, initially
> not enough input submitted and QueryOutput will wait till timeout value.
Ah I see, I guess we can just replace the fixed 1 ms sleep with a fixed
1 ms QUERY_TIMEOUT. We won't get the full power gains of waking exactly
once per frame when encoding is complete, but it should solve the issue
of having to wait a full 15.6ms to realize output data is available.
How about something like this?
diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
index 41eaef9758..555cdcde85 100644
--- a/libavcodec/amfenc.c
+++ b/libavcodec/amfenc.c
@@ -861,7 +861,12 @@ int ff_amf_receive_packet(AVCodecContext *avctx,
AVPacket *avpkt)
if (query_output_data_flag == 0) {
if (res_resubmit == AMF_INPUT_FULL || ctx->delayed_drain
|| (ctx->eof && res_query != AMF_EOF) || (ctx->hwsurfaces_in_queue >=
ctx->hwsurfaces_in_queue_max)) {
block_and_wait = 1;
-av_usleep(1000);
+
+// Only sleep if the driver doesn't support waiting
in QueryOutput()
+// or if we already have output data so we will skip
calling it.
+if (!ctx->query_timeout_supported || avpkt->data ||
avpkt->buf) {
+av_usleep(1000);
+}
}
}
} while (block_and_wait);
diff --git a/libavcodec/amfenc.h b/libavcodec/amfenc.h
index d985d01bb1..a634c133c6 100644
--- a/libavcodec/amfenc.h
+++ b/libavcodec/amfenc.h
@@ -68,6 +68,7 @@ typedef struct AmfContext {
int hwsurfaces_in_queue;
int hwsurfaces_in_queue_max;
+int query_timeout_supported;
// helpers to handle async calls
int delayed_drain;
diff --git a/libavcodec/amfenc_av1.c b/libavcodec/amfenc_av1.c
index 2a7a782063..f3058c5b96 100644
--- a/libavcodec/amfenc_av1.c
+++ b/libavcodec/amfenc_av1.c
@@ -467,6 +467,11 @@ FF_ENABLE_DEPRECATION_WARNINGS
}
}
+// Wait inside QueryOutput() if supported by the driver
+AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_QUERY_TIMEOUT, 1);
+res = ctx->encoder->pVtbl->GetProperty(ctx->encoder,
AMF_VIDEO_ENCODER_AV1_QUERY_TIMEOUT, &var);
+ctx->query_timeout_supported = res == AMF_OK && var.int64Value;
+
// init encoder
res = ctx->encoder->pVtbl->Init(ctx->encoder, ctx->format,
avctx->width, avctx->height);
AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_BUG,
"encoder->Init() failed with error %d\n", res);
diff --git a/libavcodec/amfenc_h264.c b/libavcodec/amfenc_h264.c
index 8edd39c633..6d7c5808ee 100644
--- a/libavcodec/amfenc_h264.c
+++ b/libavcodec/amfenc_h264.c
@@ -482,6 +482,11 @@ FF_ENABLE_DEPRECATION_WARNINGS
AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_REF_B_PIC_DELTA_QP, ctx->ref_b_frame_delta_qp);
}
+// Wait inside QueryOutput() if supported by the driver
+AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_QUERY_TIMEOUT, 1);
+res = ctx->encoder->pVtbl->GetProperty(ctx->encoder,
AMF_VIDEO_ENCODER_QUERY_TIMEOUT, &var);
+ctx->query_timeout_supported = res == AMF_OK && var.int64Value;
+
// Initialize Encoder
res = ctx->encoder->pVtbl->Init(ctx->encoder, ctx->format,
avctx->width, avctx->height);
AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_BUG,
"encoder->Init() failed with error %d\n", res);
diff --git a/libavcodec/amfenc_hevc.c b/libavcodec/amfenc_hevc.c
index 4898824f3a..4457990247 100644
--- a/libavcodec/amfenc_hevc.c
+++ b/libavcodec/amfenc_hevc.c
@@ -429,6 +429,11 @@ FF_ENABLE_DEPRECATION_WARNING
Re: [FFmpeg-devel] [PATCH, v2] avcodec/amfenc: increase precision of Sleep() on Windows
On Mon, Sep 9, 2024 at 6:48 PM Cameron Gutman wrote: > > On Mon, Sep 9, 2024 at 11:05 AM Araz wrote: > >> > >> > I took a look at this using AMD's AMF EncoderLatency sample and found > >> > that > >> > setting the QUERY_TIMEOUT option to 50 ms (as is default for the new AMF > >> > HQ and HQLL usage values) results in latency that is better than the > >> > current AMF code in FFmpeg *and* this patch without having to touch > >> > the process's timer precision. > >> > > >> > Here are the results from QUERY_TIMEOUT=0, amf_sleep(1), 1ms timer > >> > period: > >> > Encoder: AMFVideoEncoderVCE_AVC > >> > Total : Frames = 500 Duration = 1157.16ms FPS = 432.09frames > >> > Latency: First,Min,Max = 7.12ms, 1.53ms, 3.73ms > >> > Latency: Average = 1.99ms > >> > > >> > and the results from QUERY_TIMEOUT=50, default timer period: > >> > Encoder: AMFVideoEncoderVCE_AVC > >> > Total : Frames = 500 Duration = 933.03ms FPS = 535.89frames > >> > Latency: First,Min,Max = 5.80ms, 1.49ms, 2.50ms > >> > Latency: Average = 1.58ms > >> > > >> > This seems to clearly demonstrate that QUERY_TIMEOUT is a better approach > >> > than adjusting timer resolution. It avoids process-wide effects *and* > >> > it even performs better on top of that. > >> > > >> > > >> > Cameron > > > > > > Thanks everyone and Cameron, > > TIMEOUT might be a possible solution. > > Need some time for evaluating the performance impact of using it. > > The problem is that FFmpeg calls SubmitInput and QueryOutput > > from the same thread and if B-frames and/or look-ahead enabled, initially > > not enough input submitted and QueryOutput will wait till timeout value. > > Ah I see, I guess we can just replace the fixed 1 ms sleep with a fixed > 1 ms QUERY_TIMEOUT. We won't get the full power gains of waking exactly > once per frame when encoding is complete, but it should solve the issue > of having to wait a full 15.6ms to realize output data is available. > > How about something like this? > Ugh, email client mangled it. Let's try that again. patch.diff Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/amfenc: Fix AV1 HDR metadata for delayed surfaces
AMF_VIDEO_ENCODER_AV1_INPUT_HDR_METADATA was set above in the normal input case but forgotten for the same in the delayed surface codepath. Signed-off-by: Cameron Gutman --- libavcodec/amfenc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c index 41eaef9758..a47aea6108 100644 --- a/libavcodec/amfenc.c +++ b/libavcodec/amfenc.c @@ -832,6 +832,8 @@ int ff_amf_receive_packet(AVCodecContext *avctx, AVPacket *avpkt) AMF_ASSIGN_PROPERTY_INTERFACE(res, ctx->encoder, AMF_VIDEO_ENCODER_INPUT_HDR_METADATA, hdrmeta_buffer); break; case AV_CODEC_ID_HEVC: AMF_ASSIGN_PROPERTY_INTERFACE(res, ctx->encoder, AMF_VIDEO_ENCODER_HEVC_INPUT_HDR_METADATA, hdrmeta_buffer); break; +case AV_CODEC_ID_AV1: +AMF_ASSIGN_PROPERTY_INTERFACE(res, ctx->encoder, AMF_VIDEO_ENCODER_AV1_INPUT_HDR_METADATA, hdrmeta_buffer); break; } hdrmeta_buffer->pVtbl->Release(hdrmeta_buffer); } -- 2.43.0.windows.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4, v2] avcodec/amfenc: Fixes the color information in the output.
On Mon, Sep 9, 2024 at 9:24 AM Araz wrote: > > > Apologies for missing this prior to merge, but you can't safely make these > > assumptions about primaries and TRC just based on the input bit depth. Just > > because it's 8-bit content doesn't mean it will be BT.709 and likewise for > > 10-bit and BT.2020+SMPTE 2084 PQ. > > > > Why doesn't amfenc_hevc (and amfenc_av1) use the values from avctx like > > amfenc_h264 does? > > Current hardware color space converter does not support transfer > characteristics other than this: > (BT709 for 8-bit output and BT2084 for 10-bit output) so for RGB input > we need them hard-coded. If conversion is done before AMF encoder, the > encoder can accept any value as it is just fields in VUI header. Thanks for the clarification. My use case is in that second category where I've already done the color conversion and just needed the proper VUI values set in the encoded bitstream. > So, we will come with a separate patch which would reflect this logic. Feel free to send it my way once it's ready. I'd be happy to test for you. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v4 1/2] avcodec/jpeg2000dec: Fix FF_DWT97_INT to pass the conformance testing defined in ISO/IEC 15444-4
This commit fixes the problem described below on the integer version of the
inverse 9-7 DWT processing (FF_DWT97_INT,
https://trac.ffmpeg.org/ticket/10123), which is activated with `-flags
+bitexact`.
I went through the code path for 9-7 transform (integer) and improved precision
to match conformance codestream. As a result, the encoded codestream size is
slightly larger for a given Q value. For example, `-flags +bitexact -i lena.pnm
-q: 20 -format j2k -y tmp.j2c` gives 13K (HEAD) and 19K (with this patch)`
- Problem
- The tests for the following codestreams were failed with `-flags +bitexact`.
- p0_04.j2k, p0_05.j2k, p0_09.j2k, p1_02.j2k, p1_03.j2k, p1_06.j2k.
- ds0_ht_04_b11.j2k, ds0_ht_04_b12.j2k, ds0_ht_05_b11.j2k,
ds0_ht_05_b12.j2k, ds0_ht_09_b11.j2k, ds1_ht_02_b11.j2k, ds1_ht_02_b12.j2k,
ds1_ht_03_b11.j2k, ds1_ht_03_b12.j2k, ds1_ht_06_b11.j2k.
- These failure comes from the insufficient precision of the fixed-point
implementation of the 9-7 DWT.
Signed-off-by: Osamu Watanabe
---
libavcodec/jpeg2000.c| 6 ++
libavcodec/jpeg2000dec.c | 2 +-
libavcodec/jpeg2000dwt.c | 43 +++-
3 files changed, 28 insertions(+), 23 deletions(-)
diff --git a/libavcodec/jpeg2000.c b/libavcodec/jpeg2000.c
index d6ffb02319..f1a7d55ae1 100644
--- a/libavcodec/jpeg2000.c
+++ b/libavcodec/jpeg2000.c
@@ -260,9 +260,7 @@ static void init_band_stepsize(AVCodecContext *avctx,
band->f_stepsize *= F_LFTG_X * F_LFTG_X * 4;
break;
}
-if (codsty->transform == FF_DWT97) {
-band->f_stepsize *= pow(F_LFTG_K, 2*(codsty->nreslevels2decode -
reslevelno) + lband - 2);
-}
+band->f_stepsize *= pow(F_LFTG_K, 2*(codsty->nreslevels2decode -
reslevelno) + lband - 2);
}
if (band->f_stepsize > (INT_MAX >> 15)) {
@@ -270,7 +268,7 @@ static void init_band_stepsize(AVCodecContext *avctx,
av_log(avctx, AV_LOG_ERROR, "stepsize out of range\n");
}
-band->i_stepsize = band->f_stepsize * (1 << 15);
+band->i_stepsize = lrint(band->f_stepsize * (1 << 15) + 0.5f);
/* FIXME: In OpenJPEG code stepsize = stepsize * 0.5. Why?
* If not set output of entropic decoder is not correct. */
diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index 2e09b279dc..f68e41ed6a 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -2136,7 +2136,7 @@ static void dequantization_int_97(int x, int y,
Jpeg2000Cblk *cblk,
int32_t *datap = &comp->i_data[(comp->coord[0][1] - comp->coord[0][0])
* (y + j) + x];
int *src = t1->data + j*t1->stride;
for (i = 0; i < w; ++i)
-datap[i] = (src[i] * (int64_t)band->i_stepsize + (1<<15)) >> 16;
+datap[i] = (int32_t)(src[i] * (int64_t)band->i_stepsize + (1 <<
14)) >> 15;
}
}
diff --git a/libavcodec/jpeg2000dwt.c b/libavcodec/jpeg2000dwt.c
index 34e33553f7..d24f15d39b 100644
--- a/libavcodec/jpeg2000dwt.c
+++ b/libavcodec/jpeg2000dwt.c
@@ -39,12 +39,12 @@
/* Lifting parameters in integer format.
* Computed as param = (float param) * (1 << 16) */
-#define I_LFTG_ALPHA 103949ll
-#define I_LFTG_BETA 3472ll
-#define I_LFTG_GAMMA 57862ll
-#define I_LFTG_DELTA 29066ll
-#define I_LFTG_K 80621ll
-#define I_LFTG_X 53274ll
+#define I_LFTG_ALPHA_PRIME 38413ll // = 103949 - 65536, (= alpha - 1.0)
+#define I_LFTG_BETA 3472ll
+#define I_LFTG_GAMMA 57862ll
+#define I_LFTG_DELTA 29066ll
+#define I_LFTG_K 80621ll
+#define I_LFTG_X 53274ll
#define I_PRESHIFT 8
static inline void extend53(int *p, int i0, int i1)
@@ -234,8 +234,11 @@ static void sd_1d97_int(int *p, int i0, int i1)
extend97_int(p, i0, i1);
i0++; i1++;
-for (i = (i0>>1) - 2; i < (i1>>1) + 1; i++)
-p[2 * i + 1] -= (I_LFTG_ALPHA * (p[2 * i] + p[2 * i + 2]) + (1 <<
15)) >> 16;
+for (i = (i0>>1) - 2; i < (i1>>1) + 1; i++) {
+const int64_t sum = p[2 * i] + p[2 * i + 2];
+p[2 * i + 1] -= sum;
+p[2 * i + 1] -= (I_LFTG_ALPHA_PRIME * sum + (1 << 15)) >> 16;
+}
for (i = (i0>>1) - 1; i < (i1>>1) + 1; i++)
p[2 * i] -= (I_LFTG_BETA * (p[2 * i - 1] + p[2 * i + 1]) + (1 <<
15)) >> 16;
for (i = (i0>>1) - 1; i < (i1>>1); i++)
@@ -276,7 +279,7 @@ static void dwt_encode97_int(DWTContext *s, int *t)
// copy back and deinterleave
for (i = mv; i < lv; i+=2, j++)
-t[w*j + lp] = ((l[i] * I_LFTG_X) + (1 << 15)) >> 16;
+t[w*j + lp] = l[i];
for (i = 1-mv; i < lv; i+=2, j++)
t[w*j + lp] = l[i];
}
@@ -293,7 +296,7 @@ static void dwt_encode97_int(DWTContext *s, int *t)
// copy back and deinterleave
for (i = mh; i < lh; i+=2, j++)
-t[w*lp + j] = ((l[i] * I_LFTG_X) + (1 << 15)) >> 16;
+t[w*lp + j] = l[i];
for (
[FFmpeg-devel] [PATCH v4 2/2] fate/jpeg2000: Update refs for the conformance testing defined in ISO/IEC 15444-4
Signed-off-by: Osamu Watanabe --- tests/ref/fate/j2k-dwt | 59 tests/ref/fate/jpeg2000-dcinema | 4 +- tests/ref/fate/jpeg2000dec-p0_04 | 2 +- tests/ref/fate/jpeg2000dec-p0_05 | 2 +- tests/ref/fate/jpeg2000dec-p0_09 | 2 +- tests/ref/vsynth/vsynth1-jpeg2000-97 | 8 ++-- tests/ref/vsynth/vsynth2-jpeg2000-97 | 8 ++-- tests/ref/vsynth/vsynth3-jpeg2000-97 | 8 ++-- tests/ref/vsynth/vsynth_lena-jpeg2000-97 | 8 ++-- 9 files changed, 21 insertions(+), 80 deletions(-) diff --git a/tests/ref/fate/j2k-dwt b/tests/ref/fate/j2k-dwt index 42415f00f9..a2ffc9a050 100644 --- a/tests/ref/fate/j2k-dwt +++ b/tests/ref/fate/j2k-dwt @@ -1,60 +1 @@ 5/3i, decomp:15 border 151 170 140 183 milli-err2:0 -9/7i, decomp:15 border 151 170 140 183 milli-err2: 544 -9/7f, decomp:15 border 151 170 140 183 err2: 0.000 -5/3i, decomp:21 border 173 201 81 189 milli-err2:0 -9/7i, decomp:21 border 173 201 81 189 milli-err2: 592 -9/7f, decomp:21 border 173 201 81 189 err2: 0.000 -5/3i, decomp:22 border 213 227 76 245 milli-err2:0 -9/7i, decomp:22 border 213 227 76 245 milli-err2: 533 -9/7f, decomp:22 border 213 227 76 245 err2: 0.000 -5/3i, decomp:13 border 134 157 184 203 milli-err2:0 -9/7i, decomp:13 border 134 157 184 203 milli-err2: 535 -9/7f, decomp:13 border 134 157 184 203 err2: 0.000 -5/3i, decomp: 1 border 204 237 6 106 milli-err2:0 -9/7i, decomp: 1 border 204 237 6 106 milli-err2: 219 -9/7f, decomp: 1 border 204 237 6 106 err2: 0.000 -5/3i, decomp:28 border 76 211 13 210 milli-err2:0 -9/7i, decomp:28 border 76 211 13 210 milli-err2: 791 -9/7f, decomp:28 border 76 211 13 210 err2: 0.000 -5/3i, decomp:21 border 76 99 43 123 milli-err2:0 -9/7i, decomp:21 border 76 99 43 123 milli-err2: 686 -9/7f, decomp:21 border 76 99 43 123 err2: 0.000 -5/3i, decomp:15 border 192 243 174 204 milli-err2:0 -9/7i, decomp:15 border 192 243 174 204 milli-err2: 476 -9/7f, decomp:15 border 192 243 174 204 err2: 0.000 -5/3i, decomp:21 border 17 68 93 204 milli-err2:0 -9/7i, decomp:21 border 17 68 93 204 milli-err2: 633 -9/7f, decomp:21 border 17 68 93 204 err2: 0.000 -5/3i, decomp:11 border 142 168 82 174 milli-err2:0 -9/7i, decomp:11 border 142 168 82 174 milli-err2: 696 -9/7f, decomp:11 border 142 168 82 174 err2: 0.000 -5/3i, decomp:23 border 142 209 171 235 milli-err2:0 -9/7i, decomp:23 border 142 209 171 235 milli-err2: 626 -9/7f, decomp:23 border 142 209 171 235 err2: 0.000 -5/3i, decomp:30 border 37 185 79 245 milli-err2:0 -9/7i, decomp:30 border 37 185 79 245 milli-err2: 953 -9/7f, decomp:30 border 37 185 79 245 err2: 0.000 -5/3i, decomp: 5 border 129 236 30 243 milli-err2:0 -9/7i, decomp: 5 border 129 236 30 243 milli-err2: 620 -9/7f, decomp: 5 border 129 236 30 243 err2: 0.000 -5/3i, decomp:10 border 5 160 146 247 milli-err2:0 -9/7i, decomp:10 border 5 160 146 247 milli-err2: 797 -9/7f, decomp:10 border 5 160 146 247 err2: 0.000 -5/3i, decomp: 5 border 104 162 6 47 milli-err2:0 -9/7i, decomp: 5 border 104 162 6 47 milli-err2: 603 -9/7f, decomp: 5 border 104 162 6 47 err2: 0.000 -5/3i, decomp:24 border 78 250 102 218 milli-err2:0 -9/7i, decomp:24 border 78 250 102 218 milli-err2: 836 -9/7f, decomp:24 border 78 250 102 218 err2: 0.000 -5/3i, decomp:28 border 86 98 56 79 milli-err2:0 -9/7i, decomp:28 border 86 98 56 79 milli-err2: 597 -9/7f, decomp:28 border 86 98 56 79 err2: 0.000 -5/3i, decomp: 6 border 95 238 197 214 milli-err2:0 -9/7i, decomp: 6 border 95 238 197 214 milli-err2: 478 -9/7f, decomp: 6 border 95 238 197 214 err2: 0.000 -5/3i, decomp:17 border 77 169 93 165 milli-err2:0 -9/7i, decomp:17 border 77 169 93 165 milli-err2: 616 -9/7f, decomp:17 border 77 169 93 165 err2: 0.000 -5/3i, decomp:22 border 178 187 7 119 milli-err2:0 -9/7i, decomp:22 border 178 187 7 119 milli-err2: 392 -9/7f, decomp:22 border 178 187 7 119 err2: 0.000 diff --git a/tests/ref/fate/jpeg2000-dcinema b/tests/ref/fate/jpeg2000-dcinema index cdf8cd4fc6..217b8c8377 100644 --- a/tests/ref/fate/jpeg2000-dcinema +++ b/tests/ref/fate/jpeg2000-dcinema @@ -3,5 +3,5 @@ #codec_id 0: rawvideo #dimensions 0: 1920x1080 #sar 0: 1/1 -0, 0, 0,1, 12441600, 0xfcf6a127 -0, 1, 1,1, 12441600, 0x577b6a64 +0, 0, 0,1, 12441600, 0x9c79568e +0, 1, 1,1, 12441600, 0xd9634
[FFmpeg-devel] [PATCH 1/3] lavc/hevcdec: remove a duplicate variable
In hls_decode_entry_wpp(), self_id is always identical to thread.
---
libavcodec/hevc/hevcdec.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c
index c8c425fd71..993349b678 100644
--- a/libavcodec/hevc/hevcdec.c
+++ b/libavcodec/hevc/hevcdec.c
@@ -2587,9 +2587,9 @@ static int hls_decode_entry(HEVCContext *s, GetBitContext
*gb)
}
static int hls_decode_entry_wpp(AVCodecContext *avctx, void *hevc_lclist,
-int job, int self_id)
+int job, int thread)
{
-HEVCLocalContext *lc = &((HEVCLocalContext*)hevc_lclist)[self_id];
+HEVCLocalContext *lc = &((HEVCLocalContext*)hevc_lclist)[thread];
const HEVCContext *const s = lc->parent;
const HEVCLayerContext *const l = &s->layers[s->cur_layer];
const HEVCPPS *const pps = s->pps;
@@ -2599,7 +2599,6 @@ static int hls_decode_entry_wpp(AVCodecContext *avctx,
void *hevc_lclist,
int ctb_row = job;
int ctb_addr_rs = s->sh.slice_ctb_addr_rs + ctb_row * ((sps->width +
ctb_size - 1) >> sps->log2_ctb_size);
int ctb_addr_ts = pps->ctb_addr_rs_to_ts[ctb_addr_rs];
-int thread = ctb_row % avctx->thread_count;
const uint8_t *data = s->data + s->sh.offset[ctb_row];
const size_t data_size = s->sh.size[ctb_row];
--
2.43.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/3] lavc/hevcdec: set per-CTB filter parameters for WPP
Fixes #10887
---
libavcodec/hevc/hevcdec.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c
index 993349b678..df68e0b626 100644
--- a/libavcodec/hevc/hevcdec.c
+++ b/libavcodec/hevc/hevcdec.c
@@ -2629,6 +2629,11 @@ static int hls_decode_entry_wpp(AVCodecContext *avctx,
void *hevc_lclist,
goto error;
hls_sao_param(lc, l, pps, sps,
x_ctb >> sps->log2_ctb_size, y_ctb >>
sps->log2_ctb_size);
+
+l->deblock[ctb_addr_rs].beta_offset = s->sh.beta_offset;
+l->deblock[ctb_addr_rs].tc_offset = s->sh.tc_offset;
+l->filter_slice_edges[ctb_addr_rs] =
s->sh.slice_loop_filter_across_slices_enabled_flag;
+
more_data = hls_coding_quadtree(lc, l, pps, sps, x_ctb, y_ctb,
sps->log2_ctb_size, 0);
if (more_data < 0) {
--
2.43.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/3] tests/fate/hevc: add a periodic intra refresh decode test
Would trigger #10887 before it was fixed, sample cut from the one attached to the bug. --- Please put https://ups.khirnov.net/3dc9efb9d882bbbf05876bfa67d5257fb0ee93065b43dc5512539ac3dfe91208/pir.hevc to hevc/pir.hevc --- tests/fate/hevc.mak | 3 +++ tests/ref/fate/hevc-pir | 15 +++ 2 files changed, 18 insertions(+) create mode 100644 tests/ref/fate/hevc-pir diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak index 720603c112..88aeb9cebd 100644 --- a/tests/fate/hevc.mak +++ b/tests/fate/hevc.mak @@ -258,6 +258,9 @@ FATE_HEVC-$(call FRAMECRC, HEVC, HEVC) += fate-hevc-cabac-tudepth fate-hevc-small422chroma: CMD = framecrc -i $(TARGET_SAMPLES)/hevc/food.hevc -pix_fmt yuv422p10le -vf scale FATE_HEVC-$(call FRAMECRC, HEVC, HEVC, HEVC_PARSER SCALE_FILTER) += fate-hevc-small422chroma +fate-hevc-pir: CMD = framecrc -i $(TARGET_SAMPLES)/hevc/pir.hevc +FATE_HEVC-$(call FRAMECRC, HEVC, HEVC) += fate-hevc-pir + FATE_SAMPLES_AVCONV += $(FATE_HEVC-yes) FATE_SAMPLES_FFPROBE += $(FATE_HEVC_FFPROBE-yes) diff --git a/tests/ref/fate/hevc-pir b/tests/ref/fate/hevc-pir new file mode 100644 index 00..ff9a51ec4c --- /dev/null +++ b/tests/ref/fate/hevc-pir @@ -0,0 +1,15 @@ +#tb 0: 1/50 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 1920x1080 +#sar 0: 1/1 +0, 0, 0,1, 3110400, 0x7f744ab9 +0, 1, 1,1, 3110400, 0x5f077ff0 +0, 2, 2,1, 3110400, 0x25932fe2 +0, 3, 3,1, 3110400, 0x5b2cd739 +0, 4, 4,1, 3110400, 0xbbfe65ec +0, 5, 5,1, 3110400, 0xb53eab5f +0, 6, 6,1, 3110400, 0x9f318977 +0, 7, 7,1, 3110400, 0x205cc30c +0, 8, 8,1, 3110400, 0x06ea7dfc +0, 9, 9,1, 3110400, 0x7597691a -- 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 3/3] tests/fate/hevc: add a periodic intra refresh decode test
Quoting Anton Khirnov (2024-09-10 08:39:47) > Please put > https://ups.khirnov.net/3dc9efb9d882bbbf05876bfa67d5257fb0ee93065b43dc5512539ac3dfe91208/pir.hevc > to hevc/pir.hevc Ccing samples-request -- 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".
