Re: [FFmpeg-devel] [PATCH v2 1/1] avcodec/libjxlenc: Add libjxl_animated encoder

[Leo Izen]

On 12/15/23 16:31, Zsolt Vadász via ffmpeg-devel wrote:

On Friday, December 15th, 2023 at 10:12 PM, Leo Izen  wrote:



On 12/15/23 11:40, Zsolt Vadász via ffmpeg-devel wrote:


On Friday, December 15th, 2023 at 12:20 AM, Leo Izen leo.i...@gmail.com wrote:


+ AVFrame *last;


I don't see the purpose of keeping this here.


The name is misleading, I should have named it `previous`, since it always 
contains the previous frame.
I did it this way so I could call JxlEncoderCloseInput when the callback 
received NULL.



This isn't needed to call JxlEncoderCloseInput, as it takes one
argument, which is JxlEncoder *.


Indeed, but according to the docs[0]:
"If the last frame or last box has been added, JxlEncoderCloseInput, 
JxlEncoderCloseFrames
and/or JxlEncoderCloseBoxes must be called before the next 
JxlEncoderProcessOutput call,
or the codestream won’t be encoded correctly."
When the encoder eventually receives NULL, there isn't anything left to add, 
unless I store the previous frame,
is there?


You can always call JxlEncoderProcessOutput at the start of the loop, 
rather than calling it after JxlEncoderAddImageFrame. (Except perhaps 
the first loop.)


If you do this, you'll process the frame that was added last loop, and 
then you can add another frame. If you receive NULL, you call 
JxlEncoderCloseInput at the start of the loop, before you call 
JxlEncoderProcessOutput. This saves you from having to store the AVFrame 
in memory. libjxl will have a copy of it in memory anyway for reference 
purposes so this allows us to reduce memory usage.




+
+ if(!ctx->last && !avctx->internal->draining) { > + ctx->last = 
av_frame_clone(frame);
+ *got_packet = 0;
+ return AVERROR(EAGAIN);


It looks like you're trying to emit one packet per image, rather than
one packet per encoded frame. This is fine, but you should not be
calling av_frame_clone, and there's no reason to use
avctx->internal->draining here. If you are doing this, you also have no
reason to cache ctx->last at all.


It's the opposite, I'm trying to emit a packet for each frame of the animation.



Libjxl provides no promise of doing this meaningfully, by the way. You
may end up with arbitrary subdivisions, not subdivisions on frame
boundaries.


Well that's one thing I didn't account for, a real pity. Do you recommend 
emitting a
single packet instead?


You can still accomplish what you're trying to do with libjxl but you 
need to finesse it a little bit. You need to (1) disable the container 
format, as its interaction with Frames is undefined, and you need to (2) 
loop calls to JxlEncoderProcessOutput until it returns JXL_ENC_SUCCESS.


The docs specify "This encodes the frames and/or boxes added so far" so 
it will end up flushing out the remaining frames if the container format 
is disabled.




+const FFCodec ff_libjxl_animated_encoder = {
+ .p.name = "libjxl_animated",
+ CODEC_LONG_NAME("libjxl Animated JPEG XL"),
+ .p.type = AVMEDIA_TYPE_VIDEO,
+ .p.id = AV_CODEC_ID_JPEGXL,
+ .priv_data_size = sizeof(LibJxlEncodeContext),
+ .init = libjxl_animated_encode_init,
+ FF_CODEC_ENCODE_CB(libjxl_animated_encode_frame),
+ .close = libjxl_encode_close,
+ .p.capabilities = AV_CODEC_CAP_OTHER_THREADS |
+ AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE |
+ AV_CODEC_CAP_DELAY,
+ .caps_internal = FF_CODEC_CAP_NOT_INIT_THREADSAFE |
+ FF_CODEC_CAP_AUTO_THREADS | FF_CODEC_CAP_INIT_CLEANUP |
+ FF_CODEC_CAP_ICC_PROFILES | FF_CODEC_CAP_EOF_FLUSH,


Why FF_CODEC_CAP_EOF_FLUSH?


So the encoder receives a NULL after the last frame has been submitted,
so JxlEncoderCloseInput can be called and the final frame properly emitted.



Ah, that makes sense, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


[0] 
https://libjxl.readthedocs.io/en/latest/api_encoder.html#_CPPv423JxlEncoderProcessOutputP10JxlEncoderPP7uint8_tP6size_t
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

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

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

Re: [FFmpeg-devel] [PATCH v2 1/1] avcodec/libjxlenc: Add libjxl_animated encoder

[Zsolt Vadász via ffmpeg-devel]

On Friday, December 15th, 2023 at 10:12 PM, Leo Izen  wrote:


> On 12/15/23 11:40, Zsolt Vadász via ffmpeg-devel wrote:
> 
> > On Friday, December 15th, 2023 at 12:20 AM, Leo Izen leo.i...@gmail.com 
> > wrote:
> > 
> > > > + AVFrame *last;
> > > 
> > > I don't see the purpose of keeping this here.
> > 
> > The name is misleading, I should have named it `previous`, since it always 
> > contains the previous frame.
> > I did it this way so I could call JxlEncoderCloseInput when the callback 
> > received NULL.
> 
> 
> This isn't needed to call JxlEncoderCloseInput, as it takes one
> argument, which is JxlEncoder *.

Indeed, but according to the docs[0]:
"If the last frame or last box has been added, JxlEncoderCloseInput, 
JxlEncoderCloseFrames
and/or JxlEncoderCloseBoxes must be called before the next 
JxlEncoderProcessOutput call,
or the codestream won’t be encoded correctly."
When the encoder eventually receives NULL, there isn't anything left to add, 
unless I store the previous frame,
is there?
> > > > +
> > > > + if(!ctx->last && !avctx->internal->draining) { > + ctx->last = 
> > > > av_frame_clone(frame);
> > > > + *got_packet = 0;
> > > > + return AVERROR(EAGAIN);
> > > 
> > > It looks like you're trying to emit one packet per image, rather than
> > > one packet per encoded frame. This is fine, but you should not be
> > > calling av_frame_clone, and there's no reason to use
> > > avctx->internal->draining here. If you are doing this, you also have no
> > > reason to cache ctx->last at all.
> > 
> > It's the opposite, I'm trying to emit a packet for each frame of the 
> > animation.
> 
> 
> Libjxl provides no promise of doing this meaningfully, by the way. You
> may end up with arbitrary subdivisions, not subdivisions on frame
> boundaries.
> 
Well that's one thing I didn't account for, a real pity. Do you recommend 
emitting a
single packet instead?
> > > > +const FFCodec ff_libjxl_animated_encoder = {
> > > > + .p.name = "libjxl_animated",
> > > > + CODEC_LONG_NAME("libjxl Animated JPEG XL"),
> > > > + .p.type = AVMEDIA_TYPE_VIDEO,
> > > > + .p.id = AV_CODEC_ID_JPEGXL,
> > > > + .priv_data_size = sizeof(LibJxlEncodeContext),
> > > > + .init = libjxl_animated_encode_init,
> > > > + FF_CODEC_ENCODE_CB(libjxl_animated_encode_frame),
> > > > + .close = libjxl_encode_close,
> > > > + .p.capabilities = AV_CODEC_CAP_OTHER_THREADS |
> > > > + AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE |
> > > > + AV_CODEC_CAP_DELAY,
> > > > + .caps_internal = FF_CODEC_CAP_NOT_INIT_THREADSAFE |
> > > > + FF_CODEC_CAP_AUTO_THREADS | FF_CODEC_CAP_INIT_CLEANUP |
> > > > + FF_CODEC_CAP_ICC_PROFILES | FF_CODEC_CAP_EOF_FLUSH,
> > > 
> > > Why FF_CODEC_CAP_EOF_FLUSH?
> > 
> > So the encoder receives a NULL after the last frame has been submitted,
> > so JxlEncoderCloseInput can be called and the final frame properly emitted.
> 
> 
> Ah, that makes sense, thanks.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[0] 
https://libjxl.readthedocs.io/en/latest/api_encoder.html#_CPPv423JxlEncoderProcessOutputP10JxlEncoderPP7uint8_tP6size_t
___
ffmpeg-devel mailing list
ffmpeg-devel@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/8] ffmpeg: add support for muxing AVStreamGroups

[James Almer]

Starting with IAMF support.

Signed-off-by: James Almer 
---
 doc/ffmpeg.texi   | 200 ++
 fftools/ffmpeg.h  |   2 +
 fftools/ffmpeg_mux_init.c | 342 ++
 fftools/ffmpeg_opt.c  |   2 +
 4 files changed, 546 insertions(+)

diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index c503963941..1fadb20686 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -623,6 +623,206 @@ Not all muxers support embedded thumbnails, and those who 
do, only support a few
 Creates a program with the specified @var{title}, @var{program_num} and adds 
the specified
 @var{stream}(s) to it.
 
+@item -stream_group 
type=@var{type}:st=@var{stream}[:st=@var{stream}][:stg=@var{stream_group}][:id=@var{stream_group_id}...]
 (@emph{output})
+
+Creates a stream group of the specified @var{type}, @var{stream_group_id} and 
adds the specified
+@var{stream}(s) and/or previously defined @var{stream_group}(s) to it.
+
+@var{type} can be one of the following:
+@table @option
+
+@item iamf_audio_element
+Groups @var{stream}s that belong to the same IAMF Audio Element
+
+For this group @var{type}, the following options are available
+@table @option
+@item audio_element_type
+The Audio Element type. The following values are supported:
+
+@table @option
+@item channel
+Scalable channel audio representation
+@item scene
+Ambisonics representation
+@end table
+
+@item demixing
+Demixing information used to reconstruct a scalable channel audio 
representation.
+This option must be separated from the rest with a ',', and takes the following
+key=value options
+
+@table @option
+@item parameter_id
+An identifier parameters blocks in frames may refer to
+@item dmixp_mode
+A pre-defined combination of demixing parameters
+@end table
+
+@item recon_gain
+Recon gain information used to reconstruct a scalable channel audio 
representation.
+This option must be separated from the rest with a ',', and takes the following
+key=value options
+
+@table @option
+@item parameter_id
+An identifier parameters blocks in frames may refer to
+@end table
+
+@item layer
+A layer defining a Channel Layout in the Audio Element.
+This option must be separated from the rest with a ','. Several ',' separated 
entries
+can be defined, and at least one must be set.
+
+It takes the following ":"-separated key=value options
+
+@table @option
+@item ch_layout
+The layer's channel layout
+@item flags
+The following flags are available:
+
+@table @option
+@item recon_gain
+Wether to signal if recon_gain is present as metadata in parameter blocks 
within frames
+@end table
+
+@item output_gain
+@item output_gain_flags
+Which channels output_gain applies to. The following flags are available:
+
+@table @option
+@item FL
+@item FR
+@item BL
+@item BR
+@item TFL
+@item TFR
+@end table
+
+@item ambisonics_mode
+The ambisonics mode. This has no effect if audio_element_type is set to 
channel.
+
+The following values are supported:
+
+@table @option
+@item mono
+Each ambisonics channel is coded as an individual mono stream in the group
+@end table
+
+@end table
+
+@item default_w
+Default weight value
+
+@end table
+
+@item iamf_mix_presentation
+Groups @var{stream}s that belong to all IAMF Audio Element the same
+IAMF Mix Presentation references
+
+For this group @var{type}, the following options are available
+
+@table @option
+@item submix
+A sub-mix within the Mix Presentation.
+This option must be separated from the rest with a ','. Several ',' separated 
entries
+can be defined, and at least one must be set.
+
+It takes the following ":"-separated key=value options
+
+@table @option
+@item parameter_id
+An identifier parameters blocks in frames may refer to, for post-processing 
the mixed
+audio signal to generate the audio signal for playback
+@item parameter_rate
+The sample rate duration fields in parameters blocks in frames that refer to 
this
+@var{parameter_id} are expressed as
+@item default_mix_gain
+Default mix gain value to apply when there are no parameter blocks sharing the 
same
+@var{parameter_id} for a given frame
+
+@item element
+References an Audio Element used in this Mix Presentation to generate the 
final output
+audio signal for playback.
+This option must be separated from the rest with a '|'. Several '|' separated 
entries
+can be defined, and at least one must be set.
+
+It takes the following ":"-separated key=value options:
+
+@table @option
+@item stg
+The @var{stream_group_id} for an Audio Element which this sub-mix refers to
+@item parameter_id
+An identifier parameters blocks in frames may refer to, for applying any 
processing to
+the referenced and rendered Audio Element before being summed with other 
processed Audio
+Elements
+@item parameter_rate
+The sample rate duration fields in parameters blocks in frames that refer to 
this
+@var{parameter_id} are expressed as
+@item default_mix_gain
+Default mix gain value to apply when there are no parameter blocks sharing the 
same

Re: [FFmpeg-devel] [PATCH v2 1/1] avcodec/libjxlenc: Add libjxl_animated encoder

[Leo Izen]

On 12/15/23 11:40, Zsolt Vadász via ffmpeg-devel wrote:

On Friday, December 15th, 2023 at 12:20 AM, Leo Izen  wrote:



+ AVFrame *last;



I don't see the purpose of keeping this here.



The name is misleading, I should have named it `previous`, since it always 
contains the previous frame.
I did it this way so I could call JxlEncoderCloseInput when the callback 
received NULL.


This isn't needed to call JxlEncoderCloseInput, as it takes one 
argument, which is JxlEncoder *.




+
+ if(!ctx->last && !avctx->internal->draining) { > + ctx->last = 
av_frame_clone(frame);
+ *got_packet = 0;
+ return AVERROR(EAGAIN);


It looks like you're trying to emit one packet per image, rather than
one packet per encoded frame. This is fine, but you should not be
calling av_frame_clone, and there's no reason to use
avctx->internal->draining here. If you are doing this, you also have no
reason to cache ctx->last at all.


It's the opposite, I'm trying to emit a packet for each frame of the animation.


Libjxl provides no promise of doing this meaningfully, by the way. You 
may end up with arbitrary subdivisions, not subdivisions on frame 
boundaries.



+const FFCodec ff_libjxl_animated_encoder = {
+ .p.name = "libjxl_animated",
+ CODEC_LONG_NAME("libjxl Animated JPEG XL"),
+ .p.type = AVMEDIA_TYPE_VIDEO,
+ .p.id = AV_CODEC_ID_JPEGXL,
+ .priv_data_size = sizeof(LibJxlEncodeContext),
+ .init = libjxl_animated_encode_init,
+ FF_CODEC_ENCODE_CB(libjxl_animated_encode_frame),
+ .close = libjxl_encode_close,
+ .p.capabilities = AV_CODEC_CAP_OTHER_THREADS |
+ AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE |
+ AV_CODEC_CAP_DELAY,
+ .caps_internal = FF_CODEC_CAP_NOT_INIT_THREADSAFE |
+ FF_CODEC_CAP_AUTO_THREADS | FF_CODEC_CAP_INIT_CLEANUP |
+ FF_CODEC_CAP_ICC_PROFILES | FF_CODEC_CAP_EOF_FLUSH,



Why FF_CODEC_CAP_EOF_FLUSH?


So the encoder receives a NULL after the last frame has been submitted,
so JxlEncoderCloseInput can be called and the final frame properly emitted.


Ah, that makes sense, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH v2] avcodec/libjxldec: emit proper PTS to decoded AVFrame

[Leo Izen]

If a sequence of JXL images is encapsulated in a container that has PTS
information, we should use the PTS information from the container. At
this time there is no container that does this, but if JPEG XL support
is ever added to NUT, AVTransport, or some other container, this commit
should allow the PTS information those containers provide to work as
expected.

Signed-off-by: Leo Izen 
---
 libavcodec/libjxldec.c | 57 +-
 1 file changed, 29 insertions(+), 28 deletions(-)

diff --git a/libavcodec/libjxldec.c b/libavcodec/libjxldec.c
index 002740d9c1..6e630fb1b0 100644
--- a/libavcodec/libjxldec.c
+++ b/libavcodec/libjxldec.c
@@ -54,10 +54,10 @@ typedef struct LibJxlDecodeContext {
 JxlDecoderStatus events;
 AVBufferRef *iccp;
 AVPacket *avpkt;
-int64_t pts;
+int64_t accumulated_pts;
 int64_t frame_duration;
 int prev_is_last;
-AVRational timebase;
+AVRational anim_timebase;
 AVFrame *frame;
 } LibJxlDecodeContext;
 
@@ -80,7 +80,6 @@ static int libjxl_init_jxl_decoder(AVCodecContext *avctx)
 memset(>basic_info, 0, sizeof(JxlBasicInfo));
 memset(>jxl_pixfmt, 0, sizeof(JxlPixelFormat));
 ctx->prev_is_last = 1;
-ctx->frame_duration = 1;
 
 return 0;
 }
@@ -104,7 +103,6 @@ static av_cold int libjxl_decode_init(AVCodecContext *avctx)
 }
 
 ctx->avpkt = avctx->internal->in_pkt;
-ctx->pts = 0;
 ctx->frame = av_frame_alloc();
 if (!ctx->frame)
 return AVERROR(ENOMEM);
@@ -370,12 +368,15 @@ static int libjxl_receive_frame(AVCodecContext *avctx, 
AVFrame *frame)
 
 while (1) {
 size_t remaining;
+JxlFrameHeader header;
 
 if (!pkt->size) {
 av_packet_unref(pkt);
 ret = ff_decode_get_packet(avctx, pkt);
 if (ret < 0 && ret != AVERROR_EOF)
 return ret;
+ctx->accumulated_pts = 0;
+ctx->frame_duration = 0;
 if (!pkt->size) {
 /* jret set by the last iteration of the loop */
 if (jret == JXL_DEC_NEED_MORE_INPUT) {
@@ -429,12 +430,8 @@ static int libjxl_receive_frame(AVCodecContext *avctx, 
AVFrame *frame)
 if ((ret = ff_set_dimensions(avctx, ctx->basic_info.xsize, 
ctx->basic_info.ysize)) < 0)
 return ret;
 if (ctx->basic_info.have_animation)
-ctx->timebase = 
av_make_q(ctx->basic_info.animation.tps_denominator,
-  
ctx->basic_info.animation.tps_numerator);
-else if (avctx->pkt_timebase.num)
-ctx->timebase = avctx->pkt_timebase;
-else
-ctx->timebase = AV_TIME_BASE_Q;
+ctx->anim_timebase = 
av_make_q(ctx->basic_info.animation.tps_denominator,
+   
ctx->basic_info.animation.tps_numerator);
 continue;
 case JXL_DEC_COLOR_ENCODING:
 av_log(avctx, AV_LOG_DEBUG, "COLOR_ENCODING event emitted\n");
@@ -462,23 +459,24 @@ static int libjxl_receive_frame(AVCodecContext *avctx, 
AVFrame *frame)
 #endif
 continue;
 case JXL_DEC_FRAME:
+/* Frame here refers to the Frame bundle, not a decoded picture */
 av_log(avctx, AV_LOG_DEBUG, "FRAME event emitted\n");
-if (!ctx->basic_info.have_animation || ctx->prev_is_last) {
+if (ctx->prev_is_last) {
+/*
+ * The last frame sent was tagged as "is_last" which
+ * means this is a new image file altogether.
+ */
 ctx->frame->pict_type = AV_PICTURE_TYPE_I;
 ctx->frame->flags |= AV_FRAME_FLAG_KEY;
 }
-if (ctx->basic_info.have_animation) {
-JxlFrameHeader header;
-if (JxlDecoderGetFrameHeader(ctx->decoder, ) != 
JXL_DEC_SUCCESS) {
-av_log(avctx, AV_LOG_ERROR, "Bad libjxl dec frame 
event\n");
-return AVERROR_EXTERNAL;
-}
-ctx->prev_is_last = header.is_last;
-ctx->frame_duration = header.duration;
-} else {
-ctx->prev_is_last = 1;
-ctx->frame_duration = 1;
+if (JxlDecoderGetFrameHeader(ctx->decoder, ) != 
JXL_DEC_SUCCESS) {
+av_log(avctx, AV_LOG_ERROR, "Bad libjxl dec frame event\n");
+return AVERROR_EXTERNAL;
 }
+ctx->prev_is_last = header.is_last;
+/* zero duration for animation means the frame is not presented */
+if (ctx->basic_info.have_animation && header.duration)
+ctx->frame_duration = header.duration;
 continue;
 case JXL_DEC_FULL_IMAGE:
 /* full image is one frame, even if animated */
@@ -490,14 +488,17 @@ static int libjxl_receive_frame(AVCodecContext *avctx, 
AVFrame *frame)
 /* 

[FFmpeg-devel] [PATCH v2] riscv: Tweak names of cpu flags, print flags in libavutil/tests/cpu

[Martin Storsjö]

The names of the cpu flags, when parsed from a string with
av_parse_cpu_caps, are parsed by the libavutil eval functions. These
interpret dashes as subtractions. Therefore, these previous cpu flag
names haven't been possible to set.

Use the official names for these extensions, as the previous ad-hoc
names wasn't parseable.

libavutil/tests/cpu tests that the cpu flags can be set, and prints
the detected flags.
---
 libavutil/cpu.c   | 12 ++--
 libavutil/tests/cpu.c | 10 ++
 2 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/libavutil/cpu.c b/libavutil/cpu.c
index 1e0607d581..f04068acda 100644
--- a/libavutil/cpu.c
+++ b/libavutil/cpu.c
@@ -186,12 +186,12 @@ int av_parse_cpu_caps(unsigned *flags, const char *s)
 { "rvi",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_RVI 
 },.unit = "flags" },
 { "rvf",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_RVF 
 },.unit = "flags" },
 { "rvd",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_RVD 
 },.unit = "flags" },
-{ "rvv-i32",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_RVV_I32 
}, .unit = "flags" },
-{ "rvv-f32",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_RVV_F32 
}, .unit = "flags" },
-{ "rvv-i64",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_RVV_I64 
}, .unit = "flags" },
-{ "rvv",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_RVV_F64 
}, .unit = "flags" },
-{ "rvb-addr",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_RVB_ADDR 
},   .unit = "flags" },
-{ "rvb-basic",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 
AV_CPU_FLAG_RVB_BASIC },   .unit = "flags" },
+{ "zve32x",   NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_RVV_I32 
 },.unit = "flags" },
+{ "zve32f",   NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_RVV_F32 
 },.unit = "flags" },
+{ "zve64x",   NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_RVV_I64 
 },.unit = "flags" },
+{ "zve64f",   NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_RVV_F64 
 },.unit = "flags" },
+{ "zba",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 
AV_CPU_FLAG_RVB_ADDR },.unit = "flags" },
+{ "zbb",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 
AV_CPU_FLAG_RVB_BASIC },   .unit = "flags" },
 #endif
 { NULL },
 };
diff --git a/libavutil/tests/cpu.c b/libavutil/tests/cpu.c
index 200f20388a..6b27bcdbad 100644
--- a/libavutil/tests/cpu.c
+++ b/libavutil/tests/cpu.c
@@ -84,6 +84,16 @@ static const struct {
 #elif ARCH_LOONGARCH
 { AV_CPU_FLAG_LSX,   "lsx"},
 { AV_CPU_FLAG_LASX,  "lasx"   },
+#elif ARCH_RISCV
+{ AV_CPU_FLAG_RVI,   "rvi"},
+{ AV_CPU_FLAG_RVF,   "rvf"},
+{ AV_CPU_FLAG_RVD,   "rvd"},
+{ AV_CPU_FLAG_RVB_ADDR,  "zba"},
+{ AV_CPU_FLAG_RVB_BASIC, "zbb"},
+{ AV_CPU_FLAG_RVV_I32,   "zve32x" },
+{ AV_CPU_FLAG_RVV_F32,   "zve32f" },
+{ AV_CPU_FLAG_RVV_I64,   "zve64x" },
+{ AV_CPU_FLAG_RVV_F64,   "zve64f" },
 #endif
 { 0 }
 };
-- 
2.34.1

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

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

Re: [FFmpeg-devel] [PATCH] Add new vf_tiltandshift filter

[Vittorio Giovara]

On Fri, Dec 15, 2023 at 12:34 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:

> > +static int list_add_frame(FrameList **list, size_t *size, AVFrame
> > *frame)
> > +{
> > +FrameList *element = av_mallocz(sizeof(FrameList));
>
> The overhead of this FrameList is unnecessary: You can simply use
> AVFrame.opaque as your next pointer.
>

Good tip! Attached an edited version, with all the other suggestions too.
-- 
Vittorio


0001-Add-new-vf_tiltandshift-filter.patch
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 v8 5/5] fate: add test for animated WebP

[Thilo Borgmann via ffmpeg-devel]

---
 tests/fate/image.mak |  3 +++
 tests/ref/fate/webp-anim | 22 ++
 2 files changed, 25 insertions(+)
 create mode 100644 tests/ref/fate/webp-anim

diff --git a/tests/fate/image.mak b/tests/fate/image.mak
index 400199c28a..2e0d1e8e3f 100644
--- a/tests/fate/image.mak
+++ b/tests/fate/image.mak
@@ -567,6 +567,9 @@ fate-webp-rgb-lossy-q80: CMD = framecrc -i 
$(TARGET_SAMPLES)/webp/rgb_q80.webp
 FATE_WEBP += fate-webp-rgba-lossy-q80
 fate-webp-rgba-lossy-q80: CMD = framecrc -i 
$(TARGET_SAMPLES)/webp/rgba_q80.webp
 
+FATE_WEBP += fate-webp-anim
+fate-webp-anim: CMD = framecrc -i 
$(TARGET_SAMPLES)/webp/130227-100431-6817p.webp
+
 FATE_WEBP-$(call DEMDEC, IMAGE2, WEBP) += $(FATE_WEBP)
 FATE_IMAGE_FRAMECRC += $(FATE_WEBP-yes)
 fate-webp: $(FATE_WEBP-yes)
diff --git a/tests/ref/fate/webp-anim b/tests/ref/fate/webp-anim
new file mode 100644
index 00..fe7a53a235
--- /dev/null
+++ b/tests/ref/fate/webp-anim
@@ -0,0 +1,22 @@
+#tb 0: 2/25
+#media_type 0: video
+#codec_id 0: rawvideo
+#dimensions 0: 100x70
+#sar 0: 0/1
+0,  0,  0,1,28000, 0x2023ba6e
+0,  1,  1,1,28000, 0x4292b778
+0,  2,  2,1,28000, 0x9772a187
+0,  3,  3,1,28000, 0x9599bb3b
+0,  4,  4,1,28000, 0xa1d6b949
+0,  5,  5,1,28000, 0x153bb9fc
+0,  6,  6,1,28000, 0x6ba8d83b
+0,  7,  7,1,28000, 0xed2a4316
+0,  8,  8,   12,28000, 0xe7994c44
+0, 21, 21,1,28000, 0x15ec2f76
+0, 22, 22,1,28000, 0x96522a6b
+0, 23, 23,1,28000, 0xbbae1e30
+0, 24, 24,1,28000, 0xa2baab83
+0, 25, 25,1,28000, 0x09f1aba0
+0, 26, 26,1,28000, 0x09f1aba0
+0, 27, 27,1,28000, 0xe761bbc0
+0, 28, 28,  125,28000, 0xe761bbc0
-- 
2.37.1 (Apple Git-137.1)

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

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

[FFmpeg-devel] [PATCH v8 3/5] avcodec/webp: make init_canvas_frame static

[Thilo Borgmann via ffmpeg-devel]

---
 libavcodec/webp.c | 142 +++---
 1 file changed, 70 insertions(+), 72 deletions(-)

diff --git a/libavcodec/webp.c b/libavcodec/webp.c
index 4f989b8f0a..a2e6e199a7 100644
--- a/libavcodec/webp.c
+++ b/libavcodec/webp.c
@@ -1378,7 +1378,76 @@ static int vp8_lossy_decode_frame(AVCodecContext *avctx, 
AVFrame *p,
 return ret;
 }
 
-int init_canvas_frame(WebPContext *s, int format, int key_frame);
+static int init_canvas_frame(WebPContext *s, int format, int key_frame)
+{
+AVFrame *canvas = s->canvas_frame.f;
+int height;
+int ret;
+
+// canvas is needed only for animation
+if (!(s->vp8x_flags & VP8X_FLAG_ANIMATION))
+return 0;
+
+// avoid init for non-key frames whose format and size did not change
+if (!key_frame &&
+canvas->data[0] &&
+canvas->format == format &&
+canvas->width  == s->canvas_width &&
+canvas->height == s->canvas_height)
+return 0;
+
+// canvas changes within IPPP sequences will lose thread sync
+// because of the ThreadFrame reallocation and will wait forever
+// so if frame-threading is used, forbid canvas changes and unlock
+// previous frames
+if (!key_frame && canvas->data[0]) {
+if (s->avctx->thread_count > 1) {
+av_log(s->avctx, AV_LOG_WARNING, "Canvas change detected. The 
output will be damaged. Use -threads 1 to try decoding with best effort.\n");
+// unlock previous frames that have sent an _await() call
+ff_thread_report_progress(>canvas_frame, INT_MAX, 0);
+return AVERROR_PATCHWELCOME;
+} else {
+// warn for damaged frames
+av_log(s->avctx, AV_LOG_WARNING, "Canvas change detected. The 
output will be damaged.\n");
+}
+}
+
+s->avctx->pix_fmt = format;
+canvas->format= format;
+canvas->width = s->canvas_width;
+canvas->height= s->canvas_height;
+
+// VP8 decoder changed the width and height in AVCodecContext.
+// Change it back to the canvas size.
+ret = ff_set_dimensions(s->avctx, s->canvas_width, s->canvas_height);
+if (ret < 0)
+return ret;
+
+ff_thread_release_ext_buffer(>canvas_frame);
+ret = ff_thread_get_ext_buffer(s->avctx, >canvas_frame, 
AV_GET_BUFFER_FLAG_REF);
+if (ret < 0)
+return ret;
+
+if (canvas->format == AV_PIX_FMT_ARGB) {
+height = canvas->height;
+memset(canvas->data[0], 0, height * canvas->linesize[0]);
+} else /* if (canvas->format == AV_PIX_FMT_YUVA420P) */ {
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(canvas->format);
+for (int comp = 0; comp < desc->nb_components; comp++) {
+int plane = desc->comp[comp].plane;
+
+if (comp == 1 || comp == 2)
+height = AV_CEIL_RSHIFT(canvas->height, desc->log2_chroma_h);
+else
+height = FFALIGN(canvas->height, 1 << desc->log2_chroma_h);
+
+memset(canvas->data[plane], s->transparent_yuva[plane],
+   height * canvas->linesize[plane]);
+}
+}
+
+return 0;
+}
 
 static int webp_decode_frame_common(AVCodecContext *avctx, uint8_t *data, int 
size,
 int *got_frame, int key_frame)
@@ -1617,77 +1686,6 @@ exif_end:
 return size;
 }
 
-int init_canvas_frame(WebPContext *s, int format, int key_frame)
-{
-AVFrame *canvas = s->canvas_frame.f;
-int height;
-int ret;
-
-// canvas is needed only for animation
-if (!(s->vp8x_flags & VP8X_FLAG_ANIMATION))
-return 0;
-
-// avoid init for non-key frames whose format and size did not change
-if (!key_frame &&
-canvas->data[0] &&
-canvas->format == format &&
-canvas->width  == s->canvas_width &&
-canvas->height == s->canvas_height)
-return 0;
-
-// canvas changes within IPPP sequences will loose thread sync
-// because of the ThreadFrame reallocation and will wait forever
-// so if frame-threading is used, forbid canvas changes and unlock
-// previous frames
-if (!key_frame && canvas->data[0]) {
-if (s->avctx->thread_count > 1) {
-av_log(s->avctx, AV_LOG_WARNING, "Canvas change detected. The 
output will be damaged. Use -threads 1 to try decoding with best effort.\n");
-// unlock previous frames that have sent an _await() call
-ff_thread_report_progress(>canvas_frame, INT_MAX, 0);
-return AVERROR_PATCHWELCOME;
-} else {
-// warn for damaged frames
-av_log(s->avctx, AV_LOG_WARNING, "Canvas change detected. The 
output will be damaged.\n");
-}
-}
-
-s->avctx->pix_fmt = format;
-canvas->format= format;
-canvas->width = s->canvas_width;
-canvas->height= s->canvas_height;
-
-// VP8 decoder changed the width and height in AVCodecContext.
-// Change it back to the 

[FFmpeg-devel] [PATCH v8 4/5] libavformat/webp: add WebP demuxer

[Thilo Borgmann via ffmpeg-devel]

From: Josef Zlomek 

Adds the demuxer of animated WebP files.
It supports non-animated, animated, truncated, and concatenated files.
Reading from a pipe (and other non-seekable inputs) is also supported.

The WebP demuxer splits the input stream into packets containing one frame.
It also marks the key frames properly.
The loop count is ignored by default (same behaviour as animated PNG and GIF),
it may be enabled by the option '-ignore_loop 0'.

The frame rate is set according to the frame delay in the ANMF chunk.
If the delay is too low, or the image is not animated, the default frame rate
is set to 10 fps, similarly to other WebP libraries and browsers.
The fate suite was updated accordingly.

Signed-off-by: Josef Zlomek 
---
 Changelog   |   1 +
 doc/demuxers.texi   |  28 ++
 libavformat/Makefile|   1 +
 libavformat/allformats.c|   1 +
 libavformat/version.h   |   2 +-
 libavformat/webpdec.c   | 383 
 tests/ref/fate/exif-image-webp  |   8 +-
 tests/ref/fate/webp-rgb-lena-lossless   |   2 +-
 tests/ref/fate/webp-rgb-lena-lossless-rgb24 |   2 +-
 tests/ref/fate/webp-rgb-lossless|   2 +-
 tests/ref/fate/webp-rgb-lossy-q80   |   2 +-
 tests/ref/fate/webp-rgba-lossless   |   2 +-
 tests/ref/fate/webp-rgba-lossy-q80  |   2 +-
 13 files changed, 425 insertions(+), 11 deletions(-)
 create mode 100644 libavformat/webpdec.c

diff --git a/Changelog b/Changelog
index 10dd6a977a..df37b4bd4e 100644
--- a/Changelog
+++ b/Changelog
@@ -48,6 +48,7 @@ version 6.1:
   variable-fields elements within the same parent element
 - ffprobe -output_format option added as an alias of -of
 - animated WebP decoder
+- animated WebP demuxer
 
 
 version 6.0:
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index e4c5b560a6..fcb9f9ee3c 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -943,4 +943,32 @@ which in turn, acts as a ceiling for the size of scripts 
that can be read.
 Default is 1 MiB.
 @end table
 
+@section webp
+
+Animated WebP demuxer.
+
+It accepts the following options:
+
+@table @option
+@item -min_delay @var{int}
+Set the minimum valid delay between frames in milliseconds.
+Range is 0 to 6. Default value is 10.
+
+@item -max_webp_delay @var{int}
+Set the maximum valid delay between frames in milliseconds.
+Range is 0 to 16777215. Default value is 16777215 (over four hours),
+the maximum value allowed by the specification.
+
+@item -default_delay @var{int}
+Set the default delay between frames in milliseconds.
+Range is 0 to 6. Default value is 100.
+
+@item -ignore_loop @var{bool}
+WebP files can contain information to loop a certain number of times
+(or infinitely). If @option{ignore_loop} is set to true, then the loop
+setting from the input will be ignored and looping will not occur.
+If set to false, then looping will occur and will cycle the number
+of times according to the WebP. Default value is true.
+@end table
+
 @c man end DEMUXERS
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 2db83aff81..e8e4307fb5 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -619,6 +619,7 @@ OBJS-$(CONFIG_WEBM_MUXER)+= matroskaenc.o 
matroska.o \
 av1.o avlanguage.o
 OBJS-$(CONFIG_WEBM_DASH_MANIFEST_MUXER)  += webmdashenc.o
 OBJS-$(CONFIG_WEBM_CHUNK_MUXER)  += webm_chunk.o
+OBJS-$(CONFIG_WEBP_DEMUXER)  += webpdec.o
 OBJS-$(CONFIG_WEBP_MUXER)+= webpenc.o
 OBJS-$(CONFIG_WEBVTT_DEMUXER)+= webvttdec.o subtitles.o
 OBJS-$(CONFIG_WEBVTT_MUXER)  += webvttenc.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index c8bb4e3866..51ad546361 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -503,6 +503,7 @@ extern const AVInputFormat  ff_webm_dash_manifest_demuxer;
 extern const FFOutputFormat ff_webm_dash_manifest_muxer;
 extern const FFOutputFormat ff_webm_chunk_muxer;
 extern const FFOutputFormat ff_webp_muxer;
+extern const AVInputFormat  ff_webp_demuxer;
 extern const AVInputFormat  ff_webvtt_demuxer;
 extern const FFOutputFormat ff_webvtt_muxer;
 extern const AVInputFormat  ff_wsaud_demuxer;
diff --git a/libavformat/version.h b/libavformat/version.h
index 6a80f3ac4e..be8ce01160 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -32,7 +32,7 @@
 #include "version_major.h"
 
 #define LIBAVFORMAT_VERSION_MINOR  18
-#define LIBAVFORMAT_VERSION_MICRO 100
+#define LIBAVFORMAT_VERSION_MICRO 101
 
 #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
LIBAVFORMAT_VERSION_MINOR, \
diff --git a/libavformat/webpdec.c b/libavformat/webpdec.c
new file mode 100644
index 00..73c55ee585
--- /dev/null
+++ b/libavformat/webpdec.c
@@ -0,0 +1,383 @@
+/*
+ 

[FFmpeg-devel] [PATCH v8 2/5] libavcodec/webp: add support for animated WebP decoding

[Thilo Borgmann via ffmpeg-devel]

From: Josef Zlomek 

Fixes: 4907

Adds support for decoding of animated WebP.

The WebP decoder adds the animation related features according to the specs:
https://developers.google.com/speed/webp/docs/riff_container#animation
The frames of the animation may be smaller than the image canvas.
Therefore, the frame is decoded to a temporary frame,
then it is blended into the canvas, the canvas is copied to the output frame,
and finally the frame is disposed from the canvas.

The output to AV_PIX_FMT_YUVA420P/AV_PIX_FMT_YUV420P is still supported.
The background color is specified only as BGRA in the WebP file
so it is converted to YUVA if YUV formats are output.

Signed-off-by: Josef Zlomek 
---
 Changelog   |   1 +
 libavcodec/codec_desc.c |   3 +-
 libavcodec/version.h|   2 +-
 libavcodec/webp.c   | 754 
 4 files changed, 696 insertions(+), 64 deletions(-)

diff --git a/Changelog b/Changelog
index 67ef92eb02..10dd6a977a 100644
--- a/Changelog
+++ b/Changelog
@@ -47,6 +47,7 @@ version 6.1:
 - ffprobe XML output schema changed to account for multiple
   variable-fields elements within the same parent element
 - ffprobe -output_format option added as an alias of -of
+- animated WebP decoder
 
 
 version 6.0:
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 033344304c..0f72769093 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1259,8 +1259,7 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .type  = AVMEDIA_TYPE_VIDEO,
 .name  = "webp",
 .long_name = NULL_IF_CONFIG_SMALL("WebP"),
-.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY |
- AV_CODEC_PROP_LOSSLESS,
+.props = AV_CODEC_PROP_LOSSY | AV_CODEC_PROP_LOSSLESS,
 .mime_types= MT("image/webp"),
 },
 {
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 1008fead27..36e14e6886 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -30,7 +30,7 @@
 #include "version_major.h"
 
 #define LIBAVCODEC_VERSION_MINOR  35
-#define LIBAVCODEC_VERSION_MICRO 100
+#define LIBAVCODEC_VERSION_MICRO 101
 
 #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
diff --git a/libavcodec/webp.c b/libavcodec/webp.c
index 4fd107aa0c..4f989b8f0a 100644
--- a/libavcodec/webp.c
+++ b/libavcodec/webp.c
@@ -35,12 +35,15 @@
  * Exif metadata
  * ICC profile
  *
+ * @author Josef Zlomek, Pexeso Inc. 
+ * Animation
+ *
  * Unimplemented:
- *   - Animation
  *   - XMP metadata
  */
 
 #include "libavutil/imgutils.h"
+#include "libavutil/colorspace.h"
 
 #define BITSTREAM_READER_LE
 #include "avcodec.h"
@@ -67,6 +70,14 @@
 #define NUM_SHORT_DISTANCES 120
 #define MAX_HUFFMAN_CODE_LENGTH 15
 
+#define ANMF_DISPOSAL_METHOD0x01
+#define ANMF_DISPOSAL_METHOD_UNCHANGED  0x00
+#define ANMF_DISPOSAL_METHOD_BACKGROUND 0x01
+
+#define ANMF_BLENDING_METHOD0x02
+#define ANMF_BLENDING_METHOD_ALPHA  0x00
+#define ANMF_BLENDING_METHOD_OVERWRITE  0x02
+
 static const uint16_t alphabet_sizes[HUFFMAN_CODES_PER_META_CODE] = {
 NUM_LITERAL_CODES + NUM_LENGTH_CODES,
 NUM_LITERAL_CODES, NUM_LITERAL_CODES, NUM_LITERAL_CODES,
@@ -191,9 +202,12 @@ typedef struct ImageContext {
 typedef struct WebPContext {
 VP8Context v;   /* VP8 Context used for lossy decoding 
*/
 GetBitContext gb;   /* bitstream reader for main image 
chunk */
+ThreadFrame canvas_frame;   /* ThreadFrame for canvas */
+AVFrame *frame; /* AVFrame for decoded frame */
 AVFrame *alpha_frame;   /* AVFrame for alpha data decompressed 
from VP8L */
 AVPacket *pkt;  /* AVPacket to be passed to the 
underlying VP8 decoder */
 AVCodecContext *avctx;  /* parent AVCodecContext */
+AVCodecContext *avctx_vp8;  /* wrapper context for VP8 decoder */
 int initialized;/* set once the VP8 context is 
initialized */
 int has_alpha;  /* has a separate alpha chunk */
 enum AlphaCompression alpha_compression; /* compression type for alpha 
chunk */
@@ -204,7 +218,22 @@ typedef struct WebPContext {
 int has_iccp;   /* set after an ICCP chunk has been 
processed */
 int width;  /* image width */
 int height; /* image height */
-int lossless;   /* indicates lossless or lossy */
+int vp8x_flags; /* global flags from VP8X chunk */
+int canvas_width;   /* canvas width */
+int canvas_height;  /* canvas height */
+int anmf_flags; /* frame flags from ANMF chunk */
+int pos_x;  /* frame position 

[FFmpeg-devel] [PATCH v8 0/5] webp: add support for animated WebP decoding

[Thilo Borgmann via ffmpeg-devel]

Still images fixed, includes FATE tests, VP8 decoder decoupled so there are no 
more data races, fixed more asserts, fixed ffprobe regression, removed 
unnecessary parser changes, put the whole animated sequence into one packet.

Patch 3/5 is still there for making changes in lavc/webp reviewable but shall 
be stashed when pushing.

-Thilo


Josef Zlomek (2):
  libavcodec/webp: add support for animated WebP decoding
  libavformat/webp: add WebP demuxer

Thilo Borgmann (3):
  avcodec/webp: remove unused definitions
  avcodec/webp: make init_canvas_frame static
  fate: add test for animated WebP

 Changelog   |   2 +
 doc/demuxers.texi   |  28 +
 libavcodec/codec_desc.c |   3 +-
 libavcodec/version.h|   2 +-
 libavcodec/webp.c   | 748 ++--
 libavformat/Makefile|   1 +
 libavformat/allformats.c|   1 +
 libavformat/version.h   |   2 +-
 libavformat/webpdec.c   | 383 ++
 tests/fate/image.mak|   3 +
 tests/ref/fate/exif-image-webp  |   8 +-
 tests/ref/fate/webp-anim|  22 +
 tests/ref/fate/webp-rgb-lena-lossless   |   2 +-
 tests/ref/fate/webp-rgb-lena-lossless-rgb24 |   2 +-
 tests/ref/fate/webp-rgb-lossless|   2 +-
 tests/ref/fate/webp-rgb-lossy-q80   |   2 +-
 tests/ref/fate/webp-rgba-lossless   |   2 +-
 tests/ref/fate/webp-rgba-lossy-q80  |   2 +-
 18 files changed, 1141 insertions(+), 74 deletions(-)
 create mode 100644 libavformat/webpdec.c
 create mode 100644 tests/ref/fate/webp-anim

-- 
2.37.1 (Apple Git-137.1)

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

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

[FFmpeg-devel] [PATCH v8 1/5] avcodec/webp: remove unused definitions

[Thilo Borgmann via ffmpeg-devel]

---
 libavcodec/webp.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/libavcodec/webp.c b/libavcodec/webp.c
index 54b3fde6dc..4fd107aa0c 100644
--- a/libavcodec/webp.c
+++ b/libavcodec/webp.c
@@ -59,8 +59,6 @@
 #define VP8X_FLAG_ALPHA 0x10
 #define VP8X_FLAG_ICC   0x20
 
-#define MAX_PALETTE_SIZE256
-#define MAX_CACHE_BITS  11
 #define NUM_CODE_LENGTH_CODES   19
 #define HUFFMAN_CODES_PER_META_CODE 5
 #define NUM_LITERAL_CODES   256
-- 
2.37.1 (Apple Git-137.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] riscv: vc1dsp: Don't check vlenb before checking the CPU flags

[Martin Storsjö]

On Fri, 15 Dec 2023, Rémi Denis-Courmont wrote:


Le 15 décembre 2023 17:39:48 GMT+02:00, "Martin Storsjö"  a 
écrit :

On Fri, 15 Dec 2023, Rémi Denis-Courmont wrote:


Le 15 décembre 2023 15:02:04 GMT+02:00, "Martin Storsjö"  a 
écrit :

We can't call ff_get_rv_vlenb() if we don't have RVV available
at all.

Due to the SIGILL signal handler in checkasm catching it, in an
unexpected place, this caused checkasm to hang instead of reporting
the issue.
---
libavcodec/riscv/vc1dsp_init.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/libavcodec/riscv/vc1dsp_init.c b/libavcodec/riscv/vc1dsp_init.c
index 0d22d28f4d..2bb7e7fe8f 100644
--- a/libavcodec/riscv/vc1dsp_init.c
+++ b/libavcodec/riscv/vc1dsp_init.c
@@ -35,15 +35,13 @@ av_cold void ff_vc1dsp_init_riscv(VC1DSPContext *dsp)
#if HAVE_RVV
int flags = av_get_cpu_flags();

-if (ff_get_rv_vlenb() >= 16) {
-if (flags & AV_CPU_FLAG_RVV_I64) {
-dsp->vc1_inv_trans_8x8_dc = ff_vc1_inv_trans_8x8_dc_rvv;
-dsp->vc1_inv_trans_8x4_dc = ff_vc1_inv_trans_8x4_dc_rvv;
-}
-if (flags & AV_CPU_FLAG_RVV_I32) {
-dsp->vc1_inv_trans_4x8_dc = ff_vc1_inv_trans_4x8_dc_rvv;
-dsp->vc1_inv_trans_4x4_dc = ff_vc1_inv_trans_4x4_dc_rvv;
-}
+if (flags & AV_CPU_FLAG_RVV_I64 && ff_get_rv_vlenb() >= 16) {
+dsp->vc1_inv_trans_8x8_dc = ff_vc1_inv_trans_8x8_dc_rvv;
+dsp->vc1_inv_trans_8x4_dc = ff_vc1_inv_trans_8x4_dc_rvv;
+}
+if (flags & AV_CPU_FLAG_RVV_I32 && ff_get_rv_vlenb() >= 16) {
+dsp->vc1_inv_trans_4x8_dc = ff_vc1_inv_trans_4x8_dc_rvv;
+dsp->vc1_inv_trans_4x4_dc = ff_vc1_inv_trans_4x4_dc_rvv;


I64 implies I32 so it is not necessary to check vlenb twice. That's what I was 
going for originally in my then review comments but then woopsie.


Sure, fixed.

FWIW I see that vc1_inv_trans_8x4_dc_rvv_i64 seems to fail the checkasm test 
most of the time as well.


Hmm, I didn't write those optimisations but I thought I tested them 
before pushing. Is this subtly dependent on the vector length, maybe? 
Currently only 128-bit hardware is commercially available but QEMU can 
also emulate 256, 512 and 1014.


Ah, yes, it succeeds with 128 bit vectors, but fails with 256 bit.

// 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] riscv: vc1dsp: Don't check vlenb before checking the CPU flags

[Rémi Denis-Courmont]

Le 15 décembre 2023 17:39:48 GMT+02:00, "Martin Storsjö"  a 
écrit :
>On Fri, 15 Dec 2023, Rémi Denis-Courmont wrote:
>
>> Le 15 décembre 2023 15:02:04 GMT+02:00, "Martin Storsjö"  
>> a écrit :
>>> We can't call ff_get_rv_vlenb() if we don't have RVV available
>>> at all.
>>> 
>>> Due to the SIGILL signal handler in checkasm catching it, in an
>>> unexpected place, this caused checkasm to hang instead of reporting
>>> the issue.
>>> ---
>>> libavcodec/riscv/vc1dsp_init.c | 16 +++-
>>> 1 file changed, 7 insertions(+), 9 deletions(-)
>>> 
>>> diff --git a/libavcodec/riscv/vc1dsp_init.c b/libavcodec/riscv/vc1dsp_init.c
>>> index 0d22d28f4d..2bb7e7fe8f 100644
>>> --- a/libavcodec/riscv/vc1dsp_init.c
>>> +++ b/libavcodec/riscv/vc1dsp_init.c
>>> @@ -35,15 +35,13 @@ av_cold void ff_vc1dsp_init_riscv(VC1DSPContext *dsp)
>>> #if HAVE_RVV
>>> int flags = av_get_cpu_flags();
>>> 
>>> -if (ff_get_rv_vlenb() >= 16) {
>>> -if (flags & AV_CPU_FLAG_RVV_I64) {
>>> -dsp->vc1_inv_trans_8x8_dc = ff_vc1_inv_trans_8x8_dc_rvv;
>>> -dsp->vc1_inv_trans_8x4_dc = ff_vc1_inv_trans_8x4_dc_rvv;
>>> -}
>>> -if (flags & AV_CPU_FLAG_RVV_I32) {
>>> -dsp->vc1_inv_trans_4x8_dc = ff_vc1_inv_trans_4x8_dc_rvv;
>>> -dsp->vc1_inv_trans_4x4_dc = ff_vc1_inv_trans_4x4_dc_rvv;
>>> -}
>>> +if (flags & AV_CPU_FLAG_RVV_I64 && ff_get_rv_vlenb() >= 16) {
>>> +dsp->vc1_inv_trans_8x8_dc = ff_vc1_inv_trans_8x8_dc_rvv;
>>> +dsp->vc1_inv_trans_8x4_dc = ff_vc1_inv_trans_8x4_dc_rvv;
>>> +}
>>> +if (flags & AV_CPU_FLAG_RVV_I32 && ff_get_rv_vlenb() >= 16) {
>>> +dsp->vc1_inv_trans_4x8_dc = ff_vc1_inv_trans_4x8_dc_rvv;
>>> +dsp->vc1_inv_trans_4x4_dc = ff_vc1_inv_trans_4x4_dc_rvv;
>> 
>> I64 implies I32 so it is not necessary to check vlenb twice. That's what I 
>> was going for originally in my then review comments but then woopsie.
>
>Sure, fixed.
>
>FWIW I see that vc1_inv_trans_8x4_dc_rvv_i64 seems to fail the checkasm test 
>most of the time as well.

Hmm, I didn't write those optimisations but I thought I tested them before 
pushing. Is this subtly dependent on the vector length, maybe?  Currently only 
128-bit hardware is commercially available but QEMU can also emulate 256, 512 
and 1014.

>
>// 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 mailing list
ffmpeg-devel@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] swr/swresample: avoid reapplication of firstpts

[Michael Niedermayer]

On Fri, Dec 15, 2023 at 12:30:46PM +0530, Gyan Doshi wrote:
> During a resampling operation where
> 
> 1) user has specified first_pts
> 2) SWR_FLAG_RESAMPLE is not set initially (directly or otherwise)
> 3) first_pts has been fulfilled (always using hard compensation)
> 
> then upon first encountering a delay where a soft compensation is
> required, swr_set_compensation will lead to another init of swr which
> will reset outpts to the specified firstpts thus leading to an output
> frame having its pts = firstpts. When the next input frame is received,
> swr will see a large delay and inject silence from firstpts to the
> current frame's pts. This can lead to severe desync and in worst case,
> loss of audio playback.
> 
> Parameter firstpts initialized to AV_NOPTS_VALUE in swr_alloc and then
> checked in swr_init to avoid resetting outpts, thus avoiding reapplication
> of firstpts.
> 
> Fixes #4131.
> ---
>  libswresample/options.c| 1 +
>  libswresample/swresample.c | 5 +++--
>  2 files changed, 4 insertions(+), 2 deletions(-)

LGTM

also can a fate test be added for this ?

thx

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

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras


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

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

Re: [FFmpeg-devel] [PATCH] Add new vf_tiltandshift filter

[Andreas Rheinhardt]

Vittorio Giovara:
> +#include "avfilter.h"
> +#include "formats.h"
> +#include "internal.h"
> +#include "video.h"
> +
> +#define TILT_NONE  -1
> +#define TILT_FRAME  0
> +#define TILT_BLACK  1

Why is this not an enum?

> +
> +typedef struct FrameList {
> +AVFrame *frame;
> +struct FrameList *next;
> +} FrameList;
> +
> +typedef struct TiltandshiftContext {
> +const AVClass *class;
> +
> +/* set when all input frames have been processed and we have to
> + * empty buffers, pad and then return */
> +int eof_recv;
> +
> +/* live or static sliding */
> +int tilt;
> +
> +/* initial or final actions to perform (pad/hold a 
> frame/black/nothing) */
> +int start;
> +int end;
> +
> +/* columns to hold or pad at the beginning or at the end 
> (respectively) */
> +int hold;
> +int pad;
> +
> +/* buffers for black columns */
> +uint8_t *black_buffers[4];
> +int black_linesizes[4];
> +
> +/* list containing all input frames */
> +size_t input_size;
> +FrameList *input;
> +FrameList *prev;
> +
> +const AVPixFmtDescriptor *desc;
> +} TiltandshiftContext;
> +
> +static int list_add_frame(FrameList **list, size_t *size, AVFrame 
> *frame)
> +{
> +FrameList *element = av_mallocz(sizeof(FrameList));

The overhead of this FrameList is unnecessary: You can simply use
AVFrame.opaque as your next pointer.

> +if (!element)
> +return AVERROR(ENOMEM);
> +
> +element->frame = frame;
> +
> +if (*list == NULL) {
> +*list = element;
> +} else {
> +FrameList *head = *list;
> +while (head->next)
> +head = head->next;
> +head->next = element;
> +}
> +
> +(*size)++;
> +return 0;
> +}
> +
> +static void list_remove_head(FrameList **list, size_t *size)
> +{
> +FrameList *head = *list;
> +if (head) {
> +av_frame_free(>frame);
> +*list = head->next;
> +av_freep();
> +}
> +
> +(*size)--;
> +}
> +
> +static const enum AVPixelFormat formats_supported[] = {
> +AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUV422P, AV_PIX_FMT_YUV444P,
> +AV_PIX_FMT_YUV410P,
> +AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVJ444P,
> +AV_PIX_FMT_YUVJ440P,
> +AV_PIX_FMT_NONE
> +};
> +
> +static int query_formats(AVFilterContext *ctx)
> +{
> +return ff_set_common_formats(ctx, 
> ff_make_format_list(formats_supported));

Unnecessary. Use FILTER_PIXFMTS_ARRAY.


> +
> +AVFilter ff_vf_tiltandshift = {

const AVFilter

> +.name  = "tiltandshift",
> +.description   = NULL_IF_CONFIG_SMALL("Generate a tilt-and-shift'd 
> video."),
> +.priv_size = sizeof(TiltandshiftContext),
> +.priv_class= _class,
> +.uninit= uninit,
> +FILTER_INPUTS(tiltandshift_inputs),
> +FILTER_OUTPUTS(tiltandshift_outputs),
> +FILTER_QUERY_FUNC(query_formats),
> +};

___
ffmpeg-devel mailing list
ffmpeg-devel@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] riscv: Tweak names of cpu flags, print flags in libavutil/tests/cpu

[Rémi Denis-Courmont]

Le 15 décembre 2023 18:39:28 GMT+02:00, "Martin Storsjö"  a 
écrit :
>On Fri, 15 Dec 2023, Rémi Denis-Courmont wrote:
>
>> Le 15 décembre 2023 15:05:10 GMT+02:00, "Martin Storsjö"  
>> a écrit :
>>> The names of the cpu flags are pased by the libavutil eval
>> 
>> PaSsed
>
>Actually, I meant "parsed"
>
>>> functions - names with dashes are parsed as a subtraction.
>>> Replace dashes with underscores.
>> 
>> My personal preference would be to use official extension names, doubly so 
>> if we switch to underscore separators (which matches official syntax), 
>> rather than the made-up FFmpeg names. But that's just my opinion.
>
>Sure - which are those names? Do you want to suggest a patch yourself?

On top of my head, those would be Zve32x Zve64x Zve32f Zve64d Zba and Zbb. 
Whatever shows up in the existing `func` macros' second parameter.


>
>// 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 mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v2 1/1] avcodec/libjxlenc: Add libjxl_animated encoder

[Zsolt Vadász via ffmpeg-devel]

On Friday, December 15th, 2023 at 12:20 AM, Leo Izen  wrote:


> > + AVFrame *last;
> 
> 
> I don't see the purpose of keeping this here.
> 

The name is misleading, I should have named it `previous`, since it always 
contains the previous frame.
I did it this way so I could call JxlEncoderCloseInput when the callback 
received NULL.
> > +
> > + if(!ctx->last && !avctx->internal->draining) { > + ctx->last = 
> > av_frame_clone(frame);
> > + *got_packet = 0;
> > + return AVERROR(EAGAIN);
> 
> It looks like you're trying to emit one packet per image, rather than
> one packet per encoded frame. This is fine, but you should not be
> calling av_frame_clone, and there's no reason to use
> avctx->internal->draining here. If you are doing this, you also have no
> 
> reason to cache ctx->last at all.

It's the opposite, I'm trying to emit a packet for each frame of the animation.
> > +const FFCodec ff_libjxl_animated_encoder = {
> > + .p.name = "libjxl_animated",
> > + CODEC_LONG_NAME("libjxl Animated JPEG XL"),
> > + .p.type = AVMEDIA_TYPE_VIDEO,
> > + .p.id = AV_CODEC_ID_JPEGXL,
> > + .priv_data_size = sizeof(LibJxlEncodeContext),
> > + .init = libjxl_animated_encode_init,
> > + FF_CODEC_ENCODE_CB(libjxl_animated_encode_frame),
> > + .close = libjxl_encode_close,
> > + .p.capabilities = AV_CODEC_CAP_OTHER_THREADS |
> > + AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE |
> > + AV_CODEC_CAP_DELAY,
> > + .caps_internal = FF_CODEC_CAP_NOT_INIT_THREADSAFE |
> > + FF_CODEC_CAP_AUTO_THREADS | FF_CODEC_CAP_INIT_CLEANUP |
> > + FF_CODEC_CAP_ICC_PROFILES | FF_CODEC_CAP_EOF_FLUSH,
> 
> 
> Why FF_CODEC_CAP_EOF_FLUSH?

So the encoder receives a NULL after the last frame has been submitted,
so JxlEncoderCloseInput can be called and the final frame properly emitted.
___
ffmpeg-devel mailing list
ffmpeg-devel@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] riscv: Tweak names of cpu flags, print flags in libavutil/tests/cpu

[Martin Storsjö]

On Fri, 15 Dec 2023, Rémi Denis-Courmont wrote:


Le 15 décembre 2023 15:05:10 GMT+02:00, "Martin Storsjö"  a 
écrit :

The names of the cpu flags are pased by the libavutil eval


PaSsed


Actually, I meant "parsed"


functions - names with dashes are parsed as a subtraction.
Replace dashes with underscores.


My personal preference would be to use official extension names, doubly 
so if we switch to underscore separators (which matches official 
syntax), rather than the made-up FFmpeg names. But that's just my 
opinion.


Sure - which are those names? Do you want to suggest a patch yourself?

// 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] riscv: Tweak names of cpu flags, print flags in libavutil/tests/cpu

[Rémi Denis-Courmont]

Le 15 décembre 2023 15:05:10 GMT+02:00, "Martin Storsjö"  a 
écrit :
>The names of the cpu flags are pased by the libavutil eval

PaSsed

>functions - names with dashes are parsed as a subtraction.
>Replace dashes with underscores.

My personal preference would be to use official extension names, doubly so if 
we switch to underscore separators (which matches official syntax), rather than 
the made-up FFmpeg names. But that's just my opinion.


>
>Add these cpu flags to libavutil/tests/cpu, so that the detected
>cpu flags also get printed when run, also as part of the
>fate-cpu test.
>---
> libavutil/cpu.c   | 10 +-
> libavutil/tests/cpu.c | 10 ++
> 2 files changed, 15 insertions(+), 5 deletions(-)
>
>diff --git a/libavutil/cpu.c b/libavutil/cpu.c
>index 1e0607d581..8c1acc5e72 100644
>--- a/libavutil/cpu.c
>+++ b/libavutil/cpu.c
>@@ -186,12 +186,12 @@ int av_parse_cpu_caps(unsigned *flags, const char *s)
> { "rvi",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_RVI
>   },.unit = "flags" },
> { "rvf",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_RVF
>   },.unit = "flags" },
> { "rvd",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_RVD
>   },.unit = "flags" },
>-{ "rvv-i32",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 
>AV_CPU_FLAG_RVV_I32 }, .unit = "flags" },
>-{ "rvv-f32",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 
>AV_CPU_FLAG_RVV_F32 }, .unit = "flags" },
>-{ "rvv-i64",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 
>AV_CPU_FLAG_RVV_I64 }, .unit = "flags" },
>+{ "rvv_i32",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 
>AV_CPU_FLAG_RVV_I32 }, .unit = "flags" },
>+{ "rvv_f32",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 
>AV_CPU_FLAG_RVV_F32 }, .unit = "flags" },
>+{ "rvv_i64",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 
>AV_CPU_FLAG_RVV_I64 }, .unit = "flags" },
> { "rvv",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 
> AV_CPU_FLAG_RVV_F64 }, .unit = "flags" },
>-{ "rvb-addr",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 
>AV_CPU_FLAG_RVB_ADDR },   .unit = "flags" },
>-{ "rvb-basic",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 
>AV_CPU_FLAG_RVB_BASIC },   .unit = "flags" },
>+{ "rvb_addr",NULL, 0, AV_OPT_TYPE_CONST,  { .i64 = 
>AV_CPU_FLAG_RVB_ADDR },   .unit = "flags" },
>+{ "rvb_basic",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 
>AV_CPU_FLAG_RVB_BASIC },   .unit = "flags" },
> #endif
> { NULL },
> };
>diff --git a/libavutil/tests/cpu.c b/libavutil/tests/cpu.c
>index 200f20388a..1cabd15b72 100644
>--- a/libavutil/tests/cpu.c
>+++ b/libavutil/tests/cpu.c
>@@ -84,6 +84,16 @@ static const struct {
> #elif ARCH_LOONGARCH
> { AV_CPU_FLAG_LSX,   "lsx"},
> { AV_CPU_FLAG_LASX,  "lasx"   },
>+#elif ARCH_RISCV
>+{ AV_CPU_FLAG_RVI,   "rvi"},
>+{ AV_CPU_FLAG_RVF,   "rvf"},
>+{ AV_CPU_FLAG_RVD,   "rvd"},
>+{ AV_CPU_FLAG_RVB_ADDR,  "rvb_addr"   },
>+{ AV_CPU_FLAG_RVB_BASIC, "rvb_basic"  },
>+{ AV_CPU_FLAG_RVV_I32,   "rvv_i32"},
>+{ AV_CPU_FLAG_RVV_F32,   "rvv_f32"},
>+{ AV_CPU_FLAG_RVV_I64,   "rvv_i64"},
>+{ AV_CPU_FLAG_RVV_F64,   "rvv"},
> #endif
> { 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] riscv: vc1dsp: Don't check vlenb before checking the CPU flags

[Martin Storsjö]

On Fri, 15 Dec 2023, Rémi Denis-Courmont wrote:


Le 15 décembre 2023 15:02:04 GMT+02:00, "Martin Storsjö"  a 
écrit :

We can't call ff_get_rv_vlenb() if we don't have RVV available
at all.

Due to the SIGILL signal handler in checkasm catching it, in an
unexpected place, this caused checkasm to hang instead of reporting
the issue.
---
libavcodec/riscv/vc1dsp_init.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/libavcodec/riscv/vc1dsp_init.c b/libavcodec/riscv/vc1dsp_init.c
index 0d22d28f4d..2bb7e7fe8f 100644
--- a/libavcodec/riscv/vc1dsp_init.c
+++ b/libavcodec/riscv/vc1dsp_init.c
@@ -35,15 +35,13 @@ av_cold void ff_vc1dsp_init_riscv(VC1DSPContext *dsp)
#if HAVE_RVV
int flags = av_get_cpu_flags();

-if (ff_get_rv_vlenb() >= 16) {
-if (flags & AV_CPU_FLAG_RVV_I64) {
-dsp->vc1_inv_trans_8x8_dc = ff_vc1_inv_trans_8x8_dc_rvv;
-dsp->vc1_inv_trans_8x4_dc = ff_vc1_inv_trans_8x4_dc_rvv;
-}
-if (flags & AV_CPU_FLAG_RVV_I32) {
-dsp->vc1_inv_trans_4x8_dc = ff_vc1_inv_trans_4x8_dc_rvv;
-dsp->vc1_inv_trans_4x4_dc = ff_vc1_inv_trans_4x4_dc_rvv;
-}
+if (flags & AV_CPU_FLAG_RVV_I64 && ff_get_rv_vlenb() >= 16) {
+dsp->vc1_inv_trans_8x8_dc = ff_vc1_inv_trans_8x8_dc_rvv;
+dsp->vc1_inv_trans_8x4_dc = ff_vc1_inv_trans_8x4_dc_rvv;
+}
+if (flags & AV_CPU_FLAG_RVV_I32 && ff_get_rv_vlenb() >= 16) {
+dsp->vc1_inv_trans_4x8_dc = ff_vc1_inv_trans_4x8_dc_rvv;
+dsp->vc1_inv_trans_4x4_dc = ff_vc1_inv_trans_4x4_dc_rvv;


I64 implies I32 so it is not necessary to check vlenb twice. That's what 
I was going for originally in my then review comments but then woopsie.


Sure, fixed.

FWIW I see that vc1_inv_trans_8x4_dc_rvv_i64 seems to fail the checkasm 
test most of the time as well.


// 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 v2] riscv: vc1dsp: Don't check vlenb before checking the CPU flags

[Martin Storsjö]

We can't call ff_get_rv_vlenb() if we don't have RVV available
at all.

Due to the SIGILL signal handler in checkasm catching it, in an
unexpected place, this caused checkasm to hang instead of reporting
the issue.
---
 libavcodec/riscv/vc1dsp_init.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/libavcodec/riscv/vc1dsp_init.c b/libavcodec/riscv/vc1dsp_init.c
index 0d22d28f4d..e47b644f80 100644
--- a/libavcodec/riscv/vc1dsp_init.c
+++ b/libavcodec/riscv/vc1dsp_init.c
@@ -35,15 +35,13 @@ av_cold void ff_vc1dsp_init_riscv(VC1DSPContext *dsp)
 #if HAVE_RVV
 int flags = av_get_cpu_flags();
 
-if (ff_get_rv_vlenb() >= 16) {
+if (flags & AV_CPU_FLAG_RVV_I32 && ff_get_rv_vlenb() >= 16) {
+dsp->vc1_inv_trans_4x8_dc = ff_vc1_inv_trans_4x8_dc_rvv;
+dsp->vc1_inv_trans_4x4_dc = ff_vc1_inv_trans_4x4_dc_rvv;
 if (flags & AV_CPU_FLAG_RVV_I64) {
 dsp->vc1_inv_trans_8x8_dc = ff_vc1_inv_trans_8x8_dc_rvv;
 dsp->vc1_inv_trans_8x4_dc = ff_vc1_inv_trans_8x4_dc_rvv;
 }
-if (flags & AV_CPU_FLAG_RVV_I32) {
-dsp->vc1_inv_trans_4x8_dc = ff_vc1_inv_trans_4x8_dc_rvv;
-dsp->vc1_inv_trans_4x4_dc = ff_vc1_inv_trans_4x4_dc_rvv;
-}
 }
 #endif
 }
-- 
2.34.1

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

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

Re: [FFmpeg-devel] [PATCH] riscv: vc1dsp: Don't check vlenb before checking the CPU flags

[Rémi Denis-Courmont]

Le 15 décembre 2023 15:02:04 GMT+02:00, "Martin Storsjö"  a 
écrit :
>We can't call ff_get_rv_vlenb() if we don't have RVV available
>at all.
>
>Due to the SIGILL signal handler in checkasm catching it, in an
>unexpected place, this caused checkasm to hang instead of reporting
>the issue.
>---
> libavcodec/riscv/vc1dsp_init.c | 16 +++-
> 1 file changed, 7 insertions(+), 9 deletions(-)
>
>diff --git a/libavcodec/riscv/vc1dsp_init.c b/libavcodec/riscv/vc1dsp_init.c
>index 0d22d28f4d..2bb7e7fe8f 100644
>--- a/libavcodec/riscv/vc1dsp_init.c
>+++ b/libavcodec/riscv/vc1dsp_init.c
>@@ -35,15 +35,13 @@ av_cold void ff_vc1dsp_init_riscv(VC1DSPContext *dsp)
> #if HAVE_RVV
> int flags = av_get_cpu_flags();
> 
>-if (ff_get_rv_vlenb() >= 16) {
>-if (flags & AV_CPU_FLAG_RVV_I64) {
>-dsp->vc1_inv_trans_8x8_dc = ff_vc1_inv_trans_8x8_dc_rvv;
>-dsp->vc1_inv_trans_8x4_dc = ff_vc1_inv_trans_8x4_dc_rvv;
>-}
>-if (flags & AV_CPU_FLAG_RVV_I32) {
>-dsp->vc1_inv_trans_4x8_dc = ff_vc1_inv_trans_4x8_dc_rvv;
>-dsp->vc1_inv_trans_4x4_dc = ff_vc1_inv_trans_4x4_dc_rvv;
>-}
>+if (flags & AV_CPU_FLAG_RVV_I64 && ff_get_rv_vlenb() >= 16) {
>+dsp->vc1_inv_trans_8x8_dc = ff_vc1_inv_trans_8x8_dc_rvv;
>+dsp->vc1_inv_trans_8x4_dc = ff_vc1_inv_trans_8x4_dc_rvv;
>+}
>+if (flags & AV_CPU_FLAG_RVV_I32 && ff_get_rv_vlenb() >= 16) {
>+dsp->vc1_inv_trans_4x8_dc = ff_vc1_inv_trans_4x8_dc_rvv;
>+dsp->vc1_inv_trans_4x4_dc = ff_vc1_inv_trans_4x4_dc_rvv;

I64 implies I32 so it is not necessary to check vlenb twice. That's what I was 
going for originally in my then review comments but then woopsie.

> }
> #endif
> }
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 1/2] avfilter: Add fsync filter

[Andreas Rheinhardt]

Thilo Borgmann via ffmpeg-devel:
> ---
>  Changelog|   1 +
>  MAINTAINERS  |   1 +
>  doc/filters.texi |  33 +
>  libavfilter/Makefile |   1 +
>  libavfilter/allfilters.c |   1 +
>  libavfilter/version.h|   2 +-
>  libavfilter/vf_fsync.c   | 304 +++
>  7 files changed, 342 insertions(+), 1 deletion(-)
>  create mode 100644 libavfilter/vf_fsync.c
> 
> diff --git a/Changelog b/Changelog
> index 67ef92eb02..a25278d227 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -9,6 +9,7 @@ version :
>  - aap filter
>  - demuxing, decoding, filtering, encoding, and muxing in the
>ffmpeg CLI now all run in parallel
> +- fsync filter
>  
>  version 6.1:
>  - libaribcaption decoder
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 39b37ee0c5..4257fcad98 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -343,6 +343,7 @@ Filters:
>vf_delogo.c   Jean Delvare (CC )
>vf_drawbox.c/drawgrid Andrey Utkin
>vf_extractplanes.cPaul B Mahol
> +  vf_fsync.cThilo Borgmann
>vf_histogram.cPaul B Mahol
>vf_hqx.c  Clément Bœsch
>vf_idet.c Pascal Massimino
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 6d00ba2c3f..9f19cba9df 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -14681,6 +14681,39 @@ option may cause flicker since the B-Frames have 
> often larger QP. Default is
>  
>  @end table
>  
> +@anchor{fsync}
> +@section fsync
> +
> +Synchronize video frames with an external mapping from a file.
> +
> +For each input PTS given in the map file it either drops or creates as many 
> frames as necessary to recreate the sequence of output frames given in the 
> map file.
> +
> +This filter is useful to recreate the output frames of a framerate 
> conversion by the @ref{fps} filter, recorded into a map file using the ffmpeg 
> option @code{-stats_mux_pre}, and do further processing to the corresponding 
> frames e.g. quality comparison.
> +
> +Each line of the map file must contain three items per input frame, the 
> input PTS (decimal), the output PTS (decimal) and the output TIMEBASE 
> (decimal/decimal), seperated by a space.
> +This file format corresponds to the output of 
> @code{-stats_mux_pre_fmt="@{ptsi@} @{pts@} @{tb@}"}.
> +
> +The filter assumes the map file is sorted by increasing input PTS.
> +
> +The filter accepts the following options:
> +@table @option
> +
> +@item file, f
> +The filename of the map file to be used.
> +@end table
> +
> +Example:
> +@example
> +# Convert a video to 25 fps and record a MAP_FILE file with the default 
> format of this filter
> +ffmpeg -i INPUT -vf fps=fps=25 -stats_mux_pre MAP_FILE -stats_mux_pre_fmt 
> "@{ptsi@} @{pts@} @{tb@}" OUTPUT
> +
> +# Sort MAP_FILE by increasing input PTS
> +sort -n MAP_FILE
> +
> +# Use INPUT, OUTPUT and the MAP_FILE from above to compare the corresponding 
> frames in INPUT and OUTPUT via SSIM
> +ffmpeg -i INPUT -i OUTPUT -filter_complex 
> '[0:v]fsync=file=MAP_FILE[ref];[1:v][ref]ssim' -f null -
> +@end example
> +
>  @section gblur
>  
>  Apply Gaussian blur filter.
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index 63725f91b4..612616dfb4 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -323,6 +323,7 @@ OBJS-$(CONFIG_FREEZEDETECT_FILTER)   += 
> vf_freezedetect.o
>  OBJS-$(CONFIG_FREEZEFRAMES_FILTER)   += vf_freezeframes.o
>  OBJS-$(CONFIG_FREI0R_FILTER) += vf_frei0r.o
>  OBJS-$(CONFIG_FSPP_FILTER)   += vf_fspp.o qp_table.o
> +OBJS-$(CONFIG_FSYNC_FILTER)  += vf_fsync.o
>  OBJS-$(CONFIG_GBLUR_FILTER)  += vf_gblur.o
>  OBJS-$(CONFIG_GBLUR_VULKAN_FILTER)   += vf_gblur_vulkan.o vulkan.o 
> vulkan_filter.o
>  OBJS-$(CONFIG_GEQ_FILTER)+= vf_geq.o
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index ed7c32be94..b32ffb2d71 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -299,6 +299,7 @@ extern const AVFilter ff_vf_freezedetect;
>  extern const AVFilter ff_vf_freezeframes;
>  extern const AVFilter ff_vf_frei0r;
>  extern const AVFilter ff_vf_fspp;
> +extern const AVFilter ff_vf_fsync;
>  extern const AVFilter ff_vf_gblur;
>  extern const AVFilter ff_vf_gblur_vulkan;
>  extern const AVFilter ff_vf_geq;
> diff --git a/libavfilter/version.h b/libavfilter/version.h
> index 7642b670d1..59330858bd 100644
> --- a/libavfilter/version.h
> +++ b/libavfilter/version.h
> @@ -31,7 +31,7 @@
>  
>  #include "version_major.h"
>  
> -#define LIBAVFILTER_VERSION_MINOR  14
> +#define LIBAVFILTER_VERSION_MINOR  15
>  #define LIBAVFILTER_VERSION_MICRO 100
>  
>  
> diff --git a/libavfilter/vf_fsync.c b/libavfilter/vf_fsync.c
> new file mode 100644
> index 00..3ce6f22d06
> --- /dev/null
> +++ 

Re: [FFmpeg-devel] [PATCH] riscv: Tweak names of cpu flags, print flags in libavutil/tests/cpu

[James Almer]

On 12/15/2023 10:05 AM, Martin Storsjö wrote:

The names of the cpu flags are pased by the libavutil eval
functions - names with dashes are parsed as a subtraction.
Replace dashes with underscores.

Add these cpu flags to libavutil/tests/cpu, so that the detected
cpu flags also get printed when run, also as part of the
fate-cpu test.
---
  libavutil/cpu.c   | 10 +-
  libavutil/tests/cpu.c | 10 ++
  2 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/libavutil/cpu.c b/libavutil/cpu.c
index 1e0607d581..8c1acc5e72 100644
--- a/libavutil/cpu.c
+++ b/libavutil/cpu.c
@@ -186,12 +186,12 @@ int av_parse_cpu_caps(unsigned *flags, const char *s)
  { "rvi",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_RVI  },
.unit = "flags" },
  { "rvf",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_RVF  },
.unit = "flags" },
  { "rvd",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_RVD  },
.unit = "flags" },
-{ "rvv-i32",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_RVV_I32 }, 
.unit = "flags" },
-{ "rvv-f32",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_RVV_F32 }, 
.unit = "flags" },
-{ "rvv-i64",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_RVV_I64 }, 
.unit = "flags" },
+{ "rvv_i32",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_RVV_I32 }, 
.unit = "flags" },
+{ "rvv_f32",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_RVV_F32 }, 
.unit = "flags" },
+{ "rvv_i64",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_RVV_I64 }, 
.unit = "flags" },
  { "rvv",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_RVV_F64 }, 
.unit = "flags" },
-{ "rvb-addr",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_RVB_ADDR },   
.unit = "flags" },
-{ "rvb-basic",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_RVB_BASIC },   
.unit = "flags" },
+{ "rvb_addr",NULL, 0, AV_OPT_TYPE_CONST,  { .i64 = AV_CPU_FLAG_RVB_ADDR },   
.unit = "flags" },
+{ "rvb_basic",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_RVB_BASIC },   
.unit = "flags" },


Use this change to add some vertical alignment while at it.


  #endif
  { NULL },
  };
diff --git a/libavutil/tests/cpu.c b/libavutil/tests/cpu.c
index 200f20388a..1cabd15b72 100644
--- a/libavutil/tests/cpu.c
+++ b/libavutil/tests/cpu.c
@@ -84,6 +84,16 @@ static const struct {
  #elif ARCH_LOONGARCH
  { AV_CPU_FLAG_LSX,   "lsx"},
  { AV_CPU_FLAG_LASX,  "lasx"   },
+#elif ARCH_RISCV
+{ AV_CPU_FLAG_RVI,   "rvi"},
+{ AV_CPU_FLAG_RVF,   "rvf"},
+{ AV_CPU_FLAG_RVD,   "rvd"},
+{ AV_CPU_FLAG_RVB_ADDR,  "rvb_addr"   },
+{ AV_CPU_FLAG_RVB_BASIC, "rvb_basic"  },
+{ AV_CPU_FLAG_RVV_I32,   "rvv_i32"},
+{ AV_CPU_FLAG_RVV_F32,   "rvv_f32"},
+{ AV_CPU_FLAG_RVV_I64,   "rvv_i64"},
+{ AV_CPU_FLAG_RVV_F64,   "rvv"},
  #endif
  { 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] riscv: Tweak names of cpu flags, print flags in libavutil/tests/cpu

[Martin Storsjö]

The names of the cpu flags are pased by the libavutil eval
functions - names with dashes are parsed as a subtraction.
Replace dashes with underscores.

Add these cpu flags to libavutil/tests/cpu, so that the detected
cpu flags also get printed when run, also as part of the
fate-cpu test.
---
 libavutil/cpu.c   | 10 +-
 libavutil/tests/cpu.c | 10 ++
 2 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/libavutil/cpu.c b/libavutil/cpu.c
index 1e0607d581..8c1acc5e72 100644
--- a/libavutil/cpu.c
+++ b/libavutil/cpu.c
@@ -186,12 +186,12 @@ int av_parse_cpu_caps(unsigned *flags, const char *s)
 { "rvi",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_RVI 
 },.unit = "flags" },
 { "rvf",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_RVF 
 },.unit = "flags" },
 { "rvd",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_RVD 
 },.unit = "flags" },
-{ "rvv-i32",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_RVV_I32 
}, .unit = "flags" },
-{ "rvv-f32",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_RVV_F32 
}, .unit = "flags" },
-{ "rvv-i64",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_RVV_I64 
}, .unit = "flags" },
+{ "rvv_i32",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_RVV_I32 
}, .unit = "flags" },
+{ "rvv_f32",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_RVV_F32 
}, .unit = "flags" },
+{ "rvv_i64",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_RVV_I64 
}, .unit = "flags" },
 { "rvv",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_RVV_F64 
}, .unit = "flags" },
-{ "rvb-addr",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_RVB_ADDR 
},   .unit = "flags" },
-{ "rvb-basic",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 
AV_CPU_FLAG_RVB_BASIC },   .unit = "flags" },
+{ "rvb_addr",NULL, 0, AV_OPT_TYPE_CONST,  { .i64 = 
AV_CPU_FLAG_RVB_ADDR },   .unit = "flags" },
+{ "rvb_basic",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 
AV_CPU_FLAG_RVB_BASIC },   .unit = "flags" },
 #endif
 { NULL },
 };
diff --git a/libavutil/tests/cpu.c b/libavutil/tests/cpu.c
index 200f20388a..1cabd15b72 100644
--- a/libavutil/tests/cpu.c
+++ b/libavutil/tests/cpu.c
@@ -84,6 +84,16 @@ static const struct {
 #elif ARCH_LOONGARCH
 { AV_CPU_FLAG_LSX,   "lsx"},
 { AV_CPU_FLAG_LASX,  "lasx"   },
+#elif ARCH_RISCV
+{ AV_CPU_FLAG_RVI,   "rvi"},
+{ AV_CPU_FLAG_RVF,   "rvf"},
+{ AV_CPU_FLAG_RVD,   "rvd"},
+{ AV_CPU_FLAG_RVB_ADDR,  "rvb_addr"   },
+{ AV_CPU_FLAG_RVB_BASIC, "rvb_basic"  },
+{ AV_CPU_FLAG_RVV_I32,   "rvv_i32"},
+{ AV_CPU_FLAG_RVV_F32,   "rvv_f32"},
+{ AV_CPU_FLAG_RVV_I64,   "rvv_i64"},
+{ AV_CPU_FLAG_RVV_F64,   "rvv"},
 #endif
 { 0 }
 };
-- 
2.34.1

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

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

[FFmpeg-devel] [PATCH] riscv: vc1dsp: Don't check vlenb before checking the CPU flags

[Martin Storsjö]

We can't call ff_get_rv_vlenb() if we don't have RVV available
at all.

Due to the SIGILL signal handler in checkasm catching it, in an
unexpected place, this caused checkasm to hang instead of reporting
the issue.
---
 libavcodec/riscv/vc1dsp_init.c | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/libavcodec/riscv/vc1dsp_init.c b/libavcodec/riscv/vc1dsp_init.c
index 0d22d28f4d..2bb7e7fe8f 100644
--- a/libavcodec/riscv/vc1dsp_init.c
+++ b/libavcodec/riscv/vc1dsp_init.c
@@ -35,15 +35,13 @@ av_cold void ff_vc1dsp_init_riscv(VC1DSPContext *dsp)
 #if HAVE_RVV
 int flags = av_get_cpu_flags();
 
-if (ff_get_rv_vlenb() >= 16) {
-if (flags & AV_CPU_FLAG_RVV_I64) {
-dsp->vc1_inv_trans_8x8_dc = ff_vc1_inv_trans_8x8_dc_rvv;
-dsp->vc1_inv_trans_8x4_dc = ff_vc1_inv_trans_8x4_dc_rvv;
-}
-if (flags & AV_CPU_FLAG_RVV_I32) {
-dsp->vc1_inv_trans_4x8_dc = ff_vc1_inv_trans_4x8_dc_rvv;
-dsp->vc1_inv_trans_4x4_dc = ff_vc1_inv_trans_4x4_dc_rvv;
-}
+if (flags & AV_CPU_FLAG_RVV_I64 && ff_get_rv_vlenb() >= 16) {
+dsp->vc1_inv_trans_8x8_dc = ff_vc1_inv_trans_8x8_dc_rvv;
+dsp->vc1_inv_trans_8x4_dc = ff_vc1_inv_trans_8x4_dc_rvv;
+}
+if (flags & AV_CPU_FLAG_RVV_I32 && ff_get_rv_vlenb() >= 16) {
+dsp->vc1_inv_trans_4x8_dc = ff_vc1_inv_trans_4x8_dc_rvv;
+dsp->vc1_inv_trans_4x4_dc = ff_vc1_inv_trans_4x4_dc_rvv;
 }
 #endif
 }
-- 
2.34.1

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

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

[FFmpeg-devel] [PATCH] configure: Add a --disable-version-tracking option

[Martin Storsjö]

This disables regenerating ffversion.h whenever the checked out
git commit changes, speeding up development rebuilds.

Whenever this option is set, force the version to be printed as
"unknown" rather than showing potentially stale information.
---
 Makefile  | 7 ++-
 configure | 4 
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 2fc3e538c1..dbc930270b 100644
--- a/Makefile
+++ b/Makefile
@@ -133,13 +133,18 @@ endif
$(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(OBJS-$*) $(FF_EXTRALIBS)
 
 VERSION_SH  = $(SRC_PATH)/ffbuild/version.sh
+ifeq ($(VERSION_TRACKING),yes)
 GIT_LOG = $(SRC_PATH)/.git/logs/HEAD
+endif
 
 .version: $(wildcard $(GIT_LOG)) $(VERSION_SH) ffbuild/config.mak
 .version: M=@
 
+ifneq ($(VERSION_TRACKING),yes)
+libavutil/ffversion.h .version: REVISION=unknown
+endif
 libavutil/ffversion.h .version:
-   $(M)$(VERSION_SH) $(SRC_PATH) libavutil/ffversion.h $(EXTRA_VERSION)
+   $(M)revision=$(REVISION) $(VERSION_SH) $(SRC_PATH) 
libavutil/ffversion.h $(EXTRA_VERSION)
$(Q)touch .version
 
 # force version.sh to run whenever version might have changed
diff --git a/configure b/configure
index 7d2ee66000..9911428213 100755
--- a/configure
+++ b/configure
@@ -504,6 +504,7 @@ Developer options (useful when working on FFmpeg itself):
   --enable-macos-kperf enable macOS kperf (private) API
   --disable-large-testsdisable tests that use a large amount of memory
   --disable-ptx-compression don't compress CUDA PTX code even when possible
+  --disable-version-tracking don't include the git/release version in the build
 
 NOTE: Object files are built at the place where configure is launched.
 EOF
@@ -2576,6 +2577,7 @@ CMDLINE_SELECT="
 optimizations
 rpath
 stripping
+version_tracking
 "
 
 PATHS_LIST="
@@ -3980,6 +3982,7 @@ enable $DOCUMENT_LIST
 enable $EXAMPLE_LIST
 enable $LIBRARY_LIST
 enable stripping
+enable version_tracking
 
 enable asm
 enable debug
@@ -8013,6 +8016,7 @@ SAMPLES:=${samples:-\$(FATE_SAMPLES)}
 NOREDZONE_FLAGS=$noredzone_flags
 LIBFUZZER_PATH=$libfuzzer_path
 IGNORE_TESTS=$ignore_tests
+VERSION_TRACKING=$version_tracking
 EOF
 
 map 'eval echo "${v}_FFLIBS=\$${v}_deps" >> ffbuild/config.mak' $LIBRARY_LIST
-- 
2.39.3 (Apple Git-145)

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

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

Re: [FFmpeg-devel] [PATCH v2 1/4] libavfiter/dnn_backend_openvino: Add multiple output support

[Guo, Yejun]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> wenbin.chen-at-intel@ffmpeg.org
> Sent: Tuesday, December 12, 2023 10:34 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH v2 1/4] libavfiter/dnn_backend_openvino:
> Add multiple output support
> 
> From: Wenbin Chen 
> 
> Add multiple output support to openvino backend. You can use '&' to split
> different output when you set output name using command line.
> 
> Signed-off-by: Wenbin Chen 
> ---
>  libavfilter/dnn/dnn_backend_common.c   |   7 -
>  libavfilter/dnn/dnn_backend_openvino.c | 216 +
>  libavfilter/vf_dnn_detect.c|  11 +-
>  3 files changed, 150 insertions(+), 84 deletions(-)
> 
> diff --git a/libavfilter/dnn/dnn_backend_common.c
> b/libavfilter/dnn/dnn_backend_common.c
> index 91a4a3c4bf..632832ec36 100644
> --- a/libavfilter/dnn/dnn_backend_common.c
> +++ b/libavfilter/dnn/dnn_backend_common.c

LGTM, will push tomorrow.
___
ffmpeg-devel mailing list
ffmpeg-devel@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] fftools/ffmpeg and libavdevice/sdl issue

[Alexander Strasser via ffmpeg-devel]

On 2023-12-14 01:47 +0100, Stefano Sabatini wrote:
> On date Wednesday 2023-12-13 10:08:45 +0100, Anton Khirnov wrote:
> > Quoting Zhao Zhili (2023-12-12 18:27:39)
> [...]
> > Honestly I don't see how this could be done in ffmpeg CLI without
> > disgusting hacks, but before that the question is:
>
> > why is there an SDL
> > "muxer" and why would anyone want to use it in ffmpeg CLI? What actual
> > use cases does it serve that cannot be better handled otherwise?
>
> As the author of the first sdl.c muxer, maybe I can answer to this
> question. It was done partly as an exercise and for fun, but also
> because this was useful extremely handy for testing (e.g. to display
> the output of a filterchain from ffmpeg, or to display a streamed
> video in realtime).

That is what I used it for countless times as well.

It has a lot of merit in handling compared to piping to a player,
where one needs to run 2 processes in one command line with all
the drawbacks that come with it.


> The final goal was (still is) to unify all the tools as very thin
> instances of the library. Even if this might be not practical, I think
> it is a good final design plan (e.g. ffprobe might be turned to a
> custom muxer, ffplay would be the realtime output of a filtergraph
> connected to a rendering device, ffmpeg would be a data filtergraph
> processor, and you can mix rendering and encoding if you add a movie
> sink to the game).

I agree to this perspective. Making most of the functionality
available through the FFmpeg libs and therefore available for
wider application of a broader audience seems valuable.

Such a big goal that cannot be reached in a predictable time frame
should be challenged over the years and the plans, in so far they
exist, need to be adjusted accordingly. Still that doesn't mean
the goal is not worthwhile or not achievable.


On an ending note: I don't like at all the way this discussion unraveled:
1. Someone wants to fix a reported problem after the new threading changes
2. It is questioned why a feature that exists for over a decade is there

I hope this can get back on a more constructive rail. Otherwise
I fear it just sets precedence for more to come :(


  Alexander
___
ffmpeg-devel mailing list
ffmpeg-devel@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 bit support v5 1/3] avcodec/amfenc: Fixes the color information in the output.

[Evgeny Pavlov]

On Mon, Dec 11, 2023 at 10:21 PM Mark Thompson  wrote:

>
> Not the same, but here is a freely-available test video which has the same
> effect: .  Output below.
>
> It doesn't seem like this should be dependent on the underlying hardware
> since (I hope) it won't go to the hardware for header information.  Still,
> just in case: it's a 5850U APU running driver version 23.11.1 on Windows 10.
>
> (Seems like it might be a good idea for the debug output to print the
> driver and hardware versions at least?)
>
> The VPS out-of-order is also a weird effect - it makes it look like the
> two headers are generated by separate processes, which doesn't seem like a
> good idea when you want them to be identical.
>

I've  tested the video on 5700U APU with 23.11.1 on Windows 11 & confirmed
that there is an issue with missing color information in the header. It
seems that for 5xxxU APU drivers 23.11.1 doesn't contain a fix for this bug
in AMF.
I've checked with the latest AMF library on  5700 U APU and the issue was
fixed, so I believe future driver releases will include the updated version
of AMF library.
This issue with missing color information isn't related with ffmpeg code
itself, we need to wait for updated AMD drivers for APU
___
ffmpeg-devel mailing list
ffmpeg-devel@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] avfoundation: Fix version checks

[Zhao Zhili]

> On Dec 15, 2023, at 19:41, Thilo Borgmann via ffmpeg-devel 
>  wrote:
> 
> Am 15.12.23 um 12:32 schrieb Martin Storsjö via ffmpeg-devel:
>> On Fri, 15 Dec 2023, Zhao Zhili wrote:
>>> 
 On Dec 15, 2023, at 18:11, Martin Storsjö  wrote:
 
 _VERSION_MAX_ALLOWED indicates what version is available in
 the SDK, while _VERSION_MIN_REQUIRED is the version we can
 assume is available, i.e. similar to what is set with e.g.
 -miphoneos-version-min on the command line.
 ^
>>> 
>>> I think we need some utils for version check on Apple’s multiple target OS. 
>>> It’s hard
>>> to get it right and very lengthy to write. Ping Marvin since he is expert 
>>> on this
>>> subject.
>>> 
>>> And can we setup a group of CI for these platforms?
>> That would be good.
>> We do have a mac mini running fate tests; it would probably be good to add 
>> test configurations that build for both macOS and iOS, for both whatever the 
>> latest version in the installed SDK is, and with an old deployment target 
>> (those builds often get broken).
>> (And then, someone would need to check the FATE status as well.)
> 
> That would be great!
> Fate on the M1 discovered the other bug about the availability macro in 
> audiotoolbox only because it used the 11.3 SDK on a 12.0 OS.
> 
> Marvin knows this OS specific stuff way better than me, it would be great if 
> he wanted to set it up more sophisticated :)


Two other similar bugs:

https://trac.ffmpeg.org/ticket/10690
https://trac.ffmpeg.org/ticket/10695

It’s easy to workaround by !TARGET_OS_IPHONE, but I want to enable it for as 
many platforms as possible.
I haven’t got the time to read Marvin’s article and figure out how to do it 
properly yet.

> 
> -Thilo
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] avfoundation: Fix version checks

[Thilo Borgmann via ffmpeg-devel]

Am 15.12.23 um 12:32 schrieb Martin Storsjö via ffmpeg-devel:

On Fri, 15 Dec 2023, Zhao Zhili wrote:




On Dec 15, 2023, at 18:11, Martin Storsjö  wrote:

_VERSION_MAX_ALLOWED indicates what version is available in
the SDK, while _VERSION_MIN_REQUIRED is the version we can
assume is available, i.e. similar to what is set with e.g.
-miphoneos-version-min on the command line.
    ^


I think we need some utils for version check on Apple’s multiple target OS. 
It’s hard
to get it right and very lengthy to write. Ping Marvin since he is expert on 
this
subject.

And can we setup a group of CI for these platforms?


That would be good.

We do have a mac mini running fate tests; it would probably be good to add test 
configurations that build for both macOS and iOS, for both whatever the latest 
version in the installed SDK is, and with an old deployment target (those 
builds often get broken).

(And then, someone would need to check the FATE status as well.)


That would be great!
Fate on the M1 discovered the other bug about the availability macro in 
audiotoolbox only because it used the 11.3 SDK on a 12.0 OS.

Marvin knows this OS specific stuff way better than me, it would be great if he 
wanted to set it up more sophisticated :)

-Thilo

___
ffmpeg-devel mailing list
ffmpeg-devel@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] avfoundation: Fix version checks

[Martin Storsjö via ffmpeg-devel]

On Fri, 15 Dec 2023, Zhao Zhili wrote:




On Dec 15, 2023, at 18:11, Martin Storsjö  wrote:

_VERSION_MAX_ALLOWED indicates what version is available in
the SDK, while _VERSION_MIN_REQUIRED is the version we can
assume is available, i.e. similar to what is set with e.g.
-miphoneos-version-min on the command line.
^


I think we need some utils for version check on Apple’s multiple target OS. 
It’s hard
to get it right and very lengthy to write. Ping Marvin since he is expert on 
this
subject.

And can we setup a group of CI for these platforms?


That would be good.

We do have a mac mini running fate tests; it would probably be good to add 
test configurations that build for both macOS and iOS, for both whatever 
the latest version in the installed SDK is, and with an old deployment 
target (those builds often get broken).


(And then, someone would need to check the FATE status as well.)

// 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] avfoundation: Fix version checks

[Zhao Zhili]

> On Dec 15, 2023, at 18:11, Martin Storsjö  wrote:
> 
> _VERSION_MAX_ALLOWED indicates what version is available in
> the SDK, while _VERSION_MIN_REQUIRED is the version we can
> assume is available, i.e. similar to what is set with e.g.
> -miphoneos-version-min on the command line.
> ^

I think we need some utils for version check on Apple’s multiple target OS. 
It’s hard
to get it right and very lengthy to write. Ping Marvin since he is expert on 
this
subject.

And can we setup a group of CI for these platforms?
___
ffmpeg-devel mailing list
ffmpeg-devel@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] avfoundation: Fix version checks

[Thilo Borgmann via ffmpeg-devel]

Am 15.12.23 um 11:11 schrieb Martin Storsjö:

_VERSION_MAX_ALLOWED indicates what version is available in
the SDK, while _VERSION_MIN_REQUIRED is the version we can
assume is available, i.e. similar to what is set with e.g.
-miphoneos-version-min on the command line.

This fixes build errors like these:

src/libavdevice/avfoundation.m:788:37: error: 
'AVCaptureDeviceTypeContinuityCamera' is only available on macOS 14.0 or newer 
[-Werror,-Wunguarded-availability-new]
 [deviceTypes addObject: AVCaptureDeviceTypeContinuityCamera];
 ^~~
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/AVFoundation.framework/Headers/AVCaptureDevice.h:551:38:
 note: 'AVCaptureDeviceTypeContinuityCamera' has been marked as being 
introduced in macOS 14.0 here, but the deployment target is macOS 13.0.0
AVF_EXPORT AVCaptureDeviceType const AVCaptureDeviceTypeContinuityCamera 
API_AVAILABLE(macos(14.0), ios(17.0), macCatalyst(17.0), tvos(17.0)) 
API_UNAVAILABLE(visionos) API_UNAVAILABLE(watchos);
  ^

Alternatively, we could use these more modern APIs, if enclosed
in suitable @available() checks.
---
  libavdevice/avfoundation.m | 20 ++--
  1 file changed, 10 insertions(+), 10 deletions(-)


Pushed, thanks!

-Thilo

___
ffmpeg-devel mailing list
ffmpeg-devel@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] avfoundation: Fix version checks

[Martin Storsjö]

_VERSION_MAX_ALLOWED indicates what version is available in
the SDK, while _VERSION_MIN_REQUIRED is the version we can
assume is available, i.e. similar to what is set with e.g.
-miphoneos-version-min on the command line.

This fixes build errors like these:

src/libavdevice/avfoundation.m:788:37: error: 
'AVCaptureDeviceTypeContinuityCamera' is only available on macOS 14.0 or newer 
[-Werror,-Wunguarded-availability-new]
[deviceTypes addObject: AVCaptureDeviceTypeContinuityCamera];
^~~
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/AVFoundation.framework/Headers/AVCaptureDevice.h:551:38:
 note: 'AVCaptureDeviceTypeContinuityCamera' has been marked as being 
introduced in macOS 14.0 here, but the deployment target is macOS 13.0.0
AVF_EXPORT AVCaptureDeviceType const AVCaptureDeviceTypeContinuityCamera 
API_AVAILABLE(macos(14.0), ios(17.0), macCatalyst(17.0), tvos(17.0)) 
API_UNAVAILABLE(visionos) API_UNAVAILABLE(watchos);
 ^

Alternatively, we could use these more modern APIs, if enclosed
in suitable @available() checks.
---
 libavdevice/avfoundation.m | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
index c1432ec80f..a0ef87edff 100644
--- a/libavdevice/avfoundation.m
+++ b/libavdevice/avfoundation.m
@@ -762,41 +762,41 @@ static int get_audio_config(AVFormatContext *s)
 }
 
 static NSArray* getDevicesWithMediaType(AVMediaType mediaType) {
-#if ((TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MAX_ALLOWED >= 10) || 
(TARGET_OS_OSX && __MAC_OS_X_VERSION_MAX_ALLOWED >= 101500))
+#if ((TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MIN_REQUIRED >= 10) || 
(TARGET_OS_OSX && __MAC_OS_X_VERSION_MIN_REQUIRED >= 101500))
 NSMutableArray *deviceTypes = nil;
 if (mediaType == AVMediaTypeVideo) {
 deviceTypes = [NSMutableArray 
arrayWithArray:@[AVCaptureDeviceTypeBuiltInWideAngleCamera]];
-#if (TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MAX_ALLOWED >= 10)
+#if (TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MIN_REQUIRED >= 10)
 [deviceTypes addObject: AVCaptureDeviceTypeBuiltInDualCamera];
 [deviceTypes addObject: AVCaptureDeviceTypeBuiltInTelephotoCamera];
 #endif
-#if (TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MAX_ALLOWED >= 110100)
+#if (TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MIN_REQUIRED >= 110100)
 [deviceTypes addObject: AVCaptureDeviceTypeBuiltInTrueDepthCamera];
 #endif
-#if (TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MAX_ALLOWED >= 13)
+#if (TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MIN_REQUIRED >= 13)
 [deviceTypes addObject: AVCaptureDeviceTypeBuiltInTripleCamera];
 [deviceTypes addObject: AVCaptureDeviceTypeBuiltInDualWideCamera];
 [deviceTypes addObject: AVCaptureDeviceTypeBuiltInUltraWideCamera];
 #endif
-#if (TARGET_OS_OSX && __MAC_OS_X_VERSION_MAX_ALLOWED >= 13)
+#if (TARGET_OS_OSX && __MAC_OS_X_VERSION_MIN_REQUIRED >= 13)
 [deviceTypes addObject: AVCaptureDeviceTypeDeskViewCamera];
 #endif
-#if (TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MAX_ALLOWED >= 150400)
+#if (TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MIN_REQUIRED >= 150400)
 [deviceTypes addObject: 
AVCaptureDeviceTypeBuiltInLiDARDepthCamera];
 #endif
-#if (TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MAX_ALLOWED >= 17 || 
(TARGET_OS_OSX && __MAC_OS_X_VERSION_MAX_ALLOWED >= 14))
+#if (TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MIN_REQUIRED >= 17 || 
(TARGET_OS_OSX && __MAC_OS_X_VERSION_MIN_REQUIRED >= 14))
 [deviceTypes addObject: AVCaptureDeviceTypeContinuityCamera];
 #endif
 } else if (mediaType == AVMediaTypeAudio) {
-#if (TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MAX_ALLOWED >= 17 || 
(TARGET_OS_OSX && __MAC_OS_X_VERSION_MAX_ALLOWED >= 14))
+#if (TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MIN_REQUIRED >= 17 || 
(TARGET_OS_OSX && __MAC_OS_X_VERSION_MIN_REQUIRED >= 14))
 deviceTypes = [NSMutableArray 
arrayWithArray:@[AVCaptureDeviceTypeMicrophone]];
 #else
 deviceTypes = [NSMutableArray 
arrayWithArray:@[AVCaptureDeviceTypeBuiltInMicrophone]];
 #endif
 } else if (mediaType == AVMediaTypeMuxed) {
-#if (TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MAX_ALLOWED >= 17 || 
(TARGET_OS_OSX && __MAC_OS_X_VERSION_MAX_ALLOWED >= 14))
+#if (TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MIN_REQUIRED >= 17 || 
(TARGET_OS_OSX && __MAC_OS_X_VERSION_MIN_REQUIRED >= 14))
 deviceTypes = [NSMutableArray 
arrayWithArray:@[AVCaptureDeviceTypeExternal]];
-#elif (TARGET_OS_OSX && 

Re: [FFmpeg-devel] [PATCH 4/4] libavfilter/vf_dnn_detect: Set used pointer to NULL

[Guo, Yejun]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> wenbin.chen-at-intel@ffmpeg.org
> Sent: Thursday, December 14, 2023 10:49 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH 4/4] libavfilter/vf_dnn_detect: Set used
> pointer to NULL
> 
> From: Wenbin Chen 
> 
> Set used pointer to NULL in case it leaks the storage.
> 
> Signed-off-by: Wenbin Chen 
> ---
>  libavfilter/vf_dnn_detect.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/libavfilter/vf_dnn_detect.c b/libavfilter/vf_dnn_detect.c index
> 5668b8b017..3464af86c8 100644
> --- a/libavfilter/vf_dnn_detect.c
> +++ b/libavfilter/vf_dnn_detect.c
> @@ -223,6 +223,7 @@ static int dnn_detect_parse_yolo_output(AVFrame
> *frame, DNNData *output, int out
>  av_freep();
>  return AVERROR(ENOMEM);
>  }
> +bbox = NULL;
>  }
>  }
>  return 0;
> --
LGTM, will push soon.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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