Re: [FFmpeg-devel] [PATCH 1/2] hwcontext_vulkan: add a new mechanism to expose used queue families
Quoting Lynne via ffmpeg-devel (2024-07-10 01:56:57)
> On 09/07/2024 08:57, Anton Khirnov wrote:
> > Quoting Lynne via ffmpeg-devel (2024-07-09 03:07:12)
> >> @@ -151,6 +162,17 @@ typedef struct AVVulkanDeviceContext {
> >>* Similar to lock_queue(), unlocks a queue. Must only be called
> >> after locking.
> >>*/
> >> void (*unlock_queue)(struct AVHWDeviceContext *ctx, uint32_t
> >> queue_family, uint32_t index);
> >> +
> >> +/**
> >> + * Queue families used. Must be preferentially ordered. List may
> >> contain
> >> + * duplicates, as long as their capability flags do not match.
> >> + *
> >> + * For compatibility reasons, all the enabled queue families listed
> >> above
> >> + * (queue_family_(tx/comp/encode/decode)_index) must also be included
> >> in
> >> + * this list until they're removed after deprecation.
> >> + */
> >> +AVVulkanDeviceQueueFamily qf[16];
> >
> > Why 16? And are we really really sure sizeof(AVVulkanDeviceQueueFamily)
> > should be a part of the ABI?
>
> 16 is just an arbitrary limit. I don't expect to need more than this
> ever, but if we do, its not something that we can't wait until a bump
> occurs.
> I can increase it to 32 if you're concerned about it.
>
> There are 6 total queue family types, and 6 more currently supported
> encode and decode operations for each queue -> 12.
>
> I'd like to avoid making this not a part of the ABI, particularly as its
> a context that users should be able to easily set themselves.
I'm more concerned about adding new fields to AVVulkanDeviceQueueFamily.
Can't you just make qf an array of pointers, with a new function that
adds a new queue family to it?
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil/imgutils: av_image_check_size2() ensure width and height fit in 32bit
Quoting Michael Niedermayer (2024-07-10 00:00:32) > On Tue, Jul 09, 2024 at 05:14:37PM +0200, Anton Khirnov wrote: > > Quoting Michael Niedermayer (2024-07-09 15:28:10) > > > On Tue, Jul 09, 2024 at 03:17:58PM +0200, Anton Khirnov wrote: > > > > > ensure width and height fit in 32bit > > > > > > > > why? > > > > > > because not everyone wants undefined behavior > > > because not everyone wants security issues > > > because we dont support width and height > 32bit and its easier to check > > > in a central place > > > because the changed codes purpose is to check if the image paramaters are > > > within what we support, and width of 100 billion is not. You can try > > > all encoders with 100billion width. Then try to decode. > > > Iam curious, how many work, how many fail and how they fail > > > how many invalid bitstreams with no warning, how many undefined > > > behaviors, ... > > > > > > Simply building FFmpeg on a platform with 64bit ints doesnt update > > > ISO and ITU standards to allow larger values > > > > Quoting Michael Niedermayer (2020-10-07 16:45:56): > > > At least in code i wrote and write i consider it a bug if it would > > > assume sizeof(int/unsigned) == 4 > > > > Make up your mind. > > Where do you see a contradiction ? > > 2020: assuming sizeof(int/unsigned) == 4 is a bug > 2024: we do not support more than 32bit width and height, > nor is that supported by the majority of codec bitsterams and formats > -> We thus should in a central place check that instead of generating > undefined behavior and security issues > > What i suggest IS actually fixing a "sizeof(int/unsigned) == 4" bug > > If someone wants to make the codebase work with 64bit width and height, this > should not be limited to "int is 64bit" systems that would be a very seriously > broken design and also very illogic. I don't see any existing conditions on video dimensions being 32bit, the condition currently is that every dimension and their product must fit in an int. I also don't see what actual problems does this patch address. > Also your terse replies feel a bit rude What a coincidence, your wall of patronizing blah blah that does nothing to actually answer my original question also seems pretty rude to me. Reap what you sow. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg_filter: set keep_aspect to true for the crop filter
Quoting James Almer (2024-07-09 21:06:26) > The input sample aspect ratio applies to the pre-cropping dimensions, so > update it. I don't understand this reasoning, why should cropping a video change pixel aspect ratio? -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] avcodec: add Mediacodec audio decoders support
Le mer. 12 juin 2024, 3:47 PM, Matthieu Bouron a écrit : > --- > configure | 14 ++ > libavcodec/Makefile | 7 + > libavcodec/allcodecs.c| 7 + > libavcodec/mediacodecdec.c| 215 ++- > libavcodec/mediacodecdec_common.c | 333 +++--- > 5 files changed, 545 insertions(+), 31 deletions(-) > > diff --git a/configure b/configure > index 83284427df..d7de3b73ed 100755 > --- a/configure > +++ b/configure > @@ -3321,14 +3321,22 @@ amf_deps_any="libdl LoadLibrary" > nvenc_deps="ffnvcodec" > nvenc_deps_any="libdl LoadLibrary" > > +aac_mediacodec_decoder_deps="mediacodec" > +aac_mediacodec_decoder_select="aac_adtstoasc_bsf aac_parser" > aac_mf_encoder_deps="mediafoundation" > ac3_mf_encoder_deps="mediafoundation" > +amrnb_mediacodec_decoder_deps="mediacodec" > +amrnb_mediacodec_decoder_select="amr_parser" > +amrwb_mediacodec_decoder_deps="mediacodec" > +amrwb_mediacodec_decoder_select="amr_parser" > av1_cuvid_decoder_deps="cuvid CUVIDAV1PICPARAMS" > av1_mediacodec_decoder_deps="mediacodec" > av1_mediacodec_encoder_deps="mediacodec" > av1_mediacodec_encoder_select="extract_extradata_bsf" > av1_nvenc_encoder_deps="nvenc NV_ENC_PIC_PARAMS_AV1" > av1_nvenc_encoder_select="atsc_a53" > +flac_mediacodec_decoder_deps="mediacodec" > +flac_mediacodec_decoder_select="flac_parser" > h263_v4l2m2m_decoder_deps="v4l2_m2m h263_v4l2_m2m" > h263_v4l2m2m_encoder_deps="v4l2_m2m h263_v4l2_m2m" > h264_amf_encoder_deps="amf" > @@ -3377,6 +3385,8 @@ mjpeg_qsv_encoder_select="qsvenc" > mjpeg_vaapi_encoder_deps="VAEncPictureParameterBufferJPEG" > mjpeg_vaapi_encoder_select="cbs_jpeg jpegtables vaapi_encode" > mp3_mf_encoder_deps="mediafoundation" > +mp3_mediacodec_decoder_deps="mediacodec" > +mp3_mediacodec_decoder_select="mpegaudioheader" > mpeg1_cuvid_decoder_deps="cuvid" > mpeg1_v4l2m2m_decoder_deps="v4l2_m2m mpeg1_v4l2_m2m" > mpeg2_cuvid_decoder_deps="cuvid" > @@ -3394,10 +3404,14 @@ mpeg4_mmal_decoder_deps="mmal" > mpeg4_omx_encoder_deps="omx" > mpeg4_v4l2m2m_decoder_deps="v4l2_m2m mpeg4_v4l2_m2m" > mpeg4_v4l2m2m_encoder_deps="v4l2_m2m mpeg4_v4l2_m2m" > +opus_mediacodec_decoder_deps="mediacodec" > +opus_mediacodec_decoder_select="opus_parser" > vc1_cuvid_decoder_deps="cuvid" > vc1_mmal_decoder_deps="mmal" > vc1_qsv_decoder_select="qsvdec" > vc1_v4l2m2m_decoder_deps="v4l2_m2m vc1_v4l2_m2m" > +vorbis_mediacodec_decoder_deps="mediacodec" > +vorbis_mediacodec_decoder_select="vorbis_parser" > vp8_cuvid_decoder_deps="cuvid" > vp8_mediacodec_decoder_deps="mediacodec" > vp8_mediacodec_encoder_deps="mediacodec" > diff --git a/libavcodec/Makefile b/libavcodec/Makefile > index 1a44352906..64771b9944 100644 > --- a/libavcodec/Makefile > +++ b/libavcodec/Makefile > @@ -196,6 +196,7 @@ OBJS-$(CONFIG_AAC_ENCODER) += aacenc.o > aaccoder.o aacenctab.o\ >aacenc_pred.o \ >psymodel.o kbdwin.o \ >mpeg4audio_sample_rates.o > +OBJS-$(CONFIG_AAC_MEDIACODEC_DECODER) += mediacodecdec.o > OBJS-$(CONFIG_AAC_MF_ENCODER) += mfenc.o mf_utils.o > OBJS-$(CONFIG_AASC_DECODER)+= aasc.o msrledec.o > OBJS-$(CONFIG_AC3_DECODER) += ac3dec_float.o ac3dec_data.o > ac3.o \ > @@ -222,6 +223,8 @@ OBJS-$(CONFIG_AMRWB_DECODER) += amrwbdec.o > celp_filters.o \ >celp_math.o acelp_filters.o \ >acelp_vectors.o \ >acelp_pitch_delay.o > +OBJS-$(CONFIG_AMRNB_MEDIACODEC_DECODER) += mediacodecdec.o > +OBJS-$(CONFIG_AMRWB_MEDIACODEC_DECODER) += mediacodecdec.o > OBJS-$(CONFIG_AMV_ENCODER) += mjpegenc.o mjpegenc_common.o > OBJS-$(CONFIG_ANM_DECODER) += anm.o > OBJS-$(CONFIG_ANULL_DECODER) += null.o > @@ -367,6 +370,7 @@ OBJS-$(CONFIG_FIC_DECODER) += fic.o > OBJS-$(CONFIG_FITS_DECODER)+= fitsdec.o fits.o > OBJS-$(CONFIG_FITS_ENCODER)+= fitsenc.o > OBJS-$(CONFIG_FLAC_DECODER)+= flacdec.o flacdata.o flacdsp.o > flac.o > +OBJS-$(CONFIG_FLAC_MEDIACODEC_DECODER) += mediacodecdec.o > OBJS-$(CONFIG_FLAC_ENCODER)+= flacenc.o flacdata.o > flacencdsp.o > OBJS-$(CONFIG_FLASHSV_DECODER) += flashsv.o > OBJS-$(CONFIG_FLASHSV_ENCODER) += flashsvenc.o > @@ -518,6 +522,7 @@ OBJS-$(CONFIG_MP2FIXED_ENCODER)+= > mpegaudioenc_fixed.o mpegaudio.o \ >mpegaudiotabs.o > OBJS-$(CONFIG_MP2FLOAT_DECODER)+= mpegaudiodec_float.o > OBJS-$(CONFIG_MP3_DECODER) += mpegaudiodec_fixed.o > +OBJS-$(CONFIG_MP3_MEDIACODEC_DECODER) += mediacodecdec.o > OBJS-$(CONFIG_MP3_MF_ENCODER) += mfenc.o mf_utils.o > OBJS-$(CONFIG_MP3ADU_DECODER) += mpegaudiodec_fixed.o
Re: [FFmpeg-devel] [PATCH 1/2] avfilter/vf_scale: fix frame lifetimes
Patchset looks ok. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] avutil/executor: Fix stack overflow due to recursive call
Quoting Nuo Mi (2024-07-09 13:36:09)
> On Tue, Jul 9, 2024 at 6:35 AM Timo Rothenpieler
> wrote:
>
> > On 08.07.2024 17:32, Zhao Zhili wrote:
> > >
> > >
> > >> On Jul 8, 2024, at 22:07, Timo Rothenpieler
> > wrote:
> > >>
> > >> On 08.07.2024 09:43, Zhao Zhili wrote:
> > >>> From: Zhao Zhili
> > >>> av_executor_execute run the task directly when thread is disabled.
> > >>> The task can schedule a new task by call av_executor_execute. This
> > >>> forms an implicit recursive call. This patch removed the recursive
> > >>> call.
> > >>> ---
> > >>> libavutil/executor.c | 5 +
> > >>> 1 file changed, 5 insertions(+)
> > >>> diff --git a/libavutil/executor.c b/libavutil/executor.c
> > >>> index 89058fab2f..c145c51be9 100644
> > >>> --- a/libavutil/executor.c
> > >>> +++ b/libavutil/executor.c
> > >>> @@ -58,6 +58,7 @@ struct AVExecutor {
> > >>> int die;
> > >>> AVTask *tasks;
> > >>> +int stack_depth;
> > >>> };
> > >>> static AVTask* remove_task(AVTask **prev, AVTask *t)
> > >>> @@ -207,8 +208,12 @@ void av_executor_execute(AVExecutor *e, AVTask *t)
> > >>> }
> > >>> if (!e->thread_count || !HAVE_THREADS) {
> > >>> +if (e->stack_depth > 0)
> > >>> +return;
> > >>> +e->stack_depth++;
> > >>> // We are running in a single-threaded environment, so we
> > must handle all tasks ourselves
> > >>> while (run_one_task(e, e->local_contexts))
> > >>> /* nothing */;
> > >>> +e->stack_depth--;
> > >>
> > >> Won't this put the above line into the "nothing" while-loop?
> > >> Is that intended? If so, the indentation should be adjusted accordingly.
> > >> If not, the while-loop should gain empty {}.
> > >
> > > The comment specify it’s a while loop with empty body. Maybe it’s not
> > obvious
> > > in the email client.
> >
> > Oh, there is a ; behind the comment.
> > Completely missed that. Can't say I like it, but yeah, that works.
> >
> Google suggests using "while (cond) continue;":
> https://google.github.io/styleguide/cppguide.html#Formatting_Looping_Branching
> .
> However, it's not better than using /* nothing */.
continue gets hilit by your editor.
Also, I'd put it on a separate line for extra visibility.
And bikesheds should be black with red stripes.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/avformat: Store SDP attributes from RTSP stream into AVStream side data.
Hi,
I've tried to push this patch several times, but it looks like my email client
is messing up the diff, and patchwork isn't able to apply it.
On 09/07/2024 12:02, Bernardo Pilarz via ffmpeg-devel wrote:
Connecting to an RTSP stream will now cause the SDP attributes of each media
stream to be stored in the codecpar of the relative AVStream.
The SDP attributes are stored in the coded_side_data using the (new) type
AV_PKT_DATA_SDP_ATTRIBUTES (AVPacketSideDataType enum).
Signed-off-by: bpilarz
---
libavcodec/packet.h | 7
libavformat/rtsp.c | 97 +
2 files changed, 104 insertions(+)
diff --git a/libavcodec/packet.h b/libavcodec/packet.h
index 13667ffa36..3091c3ce56
--- a/libavcodec/packet.h
+++ b/libavcodec/packet.h
@@ -339,6 +339,13 @@ enum AVPacketSideDataType {
*/
AV_PKT_DATA_FRAME_CROPPING,
+ /**
+ * Attributes found in the SDP, associated with the stream. This is a
+ * list of zero terminated key/value strings. There is no end marker for
+ * the list, so it is required to rely on the side data size to stop.
+ */
+ AV_PKT_DATA_SDP_ATTRIBUTES,
+
/**
* The number of side data types.
* This is not part of the public API/ABI in the sense that it may
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index 19b93df839..10594e501a
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -283,6 +283,91 @@ static int init_satip_stream(AVFormatContext *s)
}
#endif
+static int sdp_add_attribute_to_stream_side_data(AVFormatContext *s,
+ AVStream *st,
+ const char *p)
+{
+ AVPacketSideData *side_data = NULL;
+ AVDictionary* attributes_dict = NULL;
+ char *key = NULL, *value = NULL;
+ int ret = 0;
+
+ /* Get the stream's attributes dictionary.
+ * If the stream has no attributes dictionary, it will be automatically
+ * created by av_dict_set. */
+ side_data = av_packet_side_data_get(st->codecpar->coded_side_data,
+ st->codecpar->nb_coded_side_data,
+ AV_PKT_DATA_SDP_ATTRIBUTES);
+ if (side_data) {
+ ret = av_packet_unpack_dictionary(side_data->data, side_data->size,
+ &attributes_dict);
+ if (ret) {
+ av_log(s, AV_LOG_WARNING,
+ "Unable to unpack SDP attributes dictionary.\n");
+ return -1;
+ }
+ }
+
+ /* The attribute can either be a value attribute (key:value) or
+ * property attribute (just the key).
+ * Look for the ':' separator, and create the 'key' and 'value'
+ * appropriately. */
+ const char *separator = strchr(p, ':');
+ if (separator) {
+ /* Make a copy of the key and value. */
+ key = av_strndup(p, separator - p);
+ value = av_strdup(separator + 1);
+ } else {
+ /* Copy the key and create an empty value. */
+ key = av_strdup(p);
+ value = av_mallocz(1);
+ }
+ if (!key || !value) {
+ av_dict_free(&attributes_dict);
+ av_free(value);
+ av_free(key);
+ return -1;
+ }
+
+ /* Add the attribute, then pack the dictionary again. */
+ ret = av_dict_set(&attributes_dict, key, value,
+ AV_DICT_DONT_STRDUP_KEY |
+ AV_DICT_DONT_STRDUP_VAL |
+ AV_DICT_MULTIKEY);
+ if (ret) {
+ av_log(s, AV_LOG_WARNING,
+ "Unable to add SDL attribute to dictionary.\n");
+ av_dict_free(&attributes_dict);
+ return -1;
+ }
+ size_t packed_dict_size = 0u;
+ uint8_t *packed_dict = av_packet_pack_dictionary(attributes_dict,
+ &packed_dict_size);
+
+ /* Free the dictionary, which is not needed any longer. */
+ av_dict_free(&attributes_dict);
+
+ /* Make sure the dictionary was packet successfully, then add it
+ * back to the stream's side data. */
+ if (!packed_dict) {
+ av_log(s, AV_LOG_WARNING,
+ "Unable to pack SDP attributes dictionary.\n");
+ return -1;
+ }
+ side_data = av_packet_side_data_add(&st->codecpar->coded_side_data,
+ &st->codecpar->nb_coded_side_data,
+ AV_PKT_DATA_SDP_ATTRIBUTES,
+ packed_dict, packed_dict_size,
+ 0);
+ if (!side_data) {
+ av_log(s, AV_LOG_WARNING,
+ "Unable to add SDP attributes side data to stream.\n");
+ return -1;
+ }
+
+ return 0;
+}
+
/* parse the rtpmap description: /[/] */
static int sdp_parse_rtpmap(AVFormatContext *s,
AVStream *st, RTSPStream *rtsp_st,
@@ -570,6 +655,18 @@ static void sdp_parse_line(AVFormatContext *s,
SDPParseState *s1,
sizeof(rtsp_st->control_url));
break;
case 'a':
+ /* add all SDP attributes to the stream's side data */
+ if (rt->nb_rtsp_streams > 0) {
+ rtsp_st = rt->rtsp_stre
[FFmpeg-devel] [PATCH] lavc/vvc_mc: R-V V avg w_avg
From: sunyuechi C908 X60 avg_8_2x2_c:1.21.2 avg_8_2x2_rvv_i32 :0.70.7 avg_8_2x4_c:2.02.0 avg_8_2x4_rvv_i32 :1.21.0 avg_8_2x8_c:3.74.0 avg_8_2x8_rvv_i32 :1.71.5 avg_8_2x16_c :7.27.5 avg_8_2x16_rvv_i32 :3.02.7 avg_8_2x32_c : 14.5 15.2 avg_8_2x32_rvv_i32 :5.55.0 avg_8_2x64_c : 53.5 42.2 avg_8_2x64_rvv_i32 : 42.0 33.2 avg_8_2x128_c : 93.5 86.0 avg_8_2x128_rvv_i32: 79.2 74.0 avg_8_4x2_c:1.72.0 avg_8_4x2_rvv_i32 :1.01.0 avg_8_4x4_c:3.53.5 avg_8_4x4_rvv_i32 :1.21.0 avg_8_4x8_c:6.57.0 avg_8_4x8_rvv_i32 :1.71.7 avg_8_4x16_c : 13.5 14.0 avg_8_4x16_rvv_i32 :3.02.5 avg_8_4x32_c : 26.2 27.5 avg_8_4x32_rvv_i32 :5.75.0 avg_8_4x64_c : 79.0 66.5 avg_8_4x64_rvv_i32 : 41.7 34.2 avg_8_4x128_c : 154.0 128.7 avg_8_4x128_rvv_i32: 80.5 74.5 avg_8_8x2_c:3.23.2 avg_8_8x2_rvv_i32 :1.00.7 avg_8_8x4_c:6.56.5 avg_8_8x4_rvv_i32 :1.21.0 avg_8_8x8_c: 12.5 13.2 avg_8_8x8_rvv_i32 :2.01.7 avg_8_8x16_c : 25.2 26.5 avg_8_8x16_rvv_i32 :3.22.7 avg_8_8x32_c : 50.0 52.7 avg_8_8x32_rvv_i32 :6.24.7 avg_8_8x64_c : 130.0 112.2 avg_8_8x64_rvv_i32 : 44.2 33.5 avg_8_8x128_c : 241.5 226.7 avg_8_8x128_rvv_i32: 78.7 74.0 avg_8_16x2_c :6.26.5 avg_8_16x2_rvv_i32 :1.20.7 avg_8_16x4_c : 12.2 13.0 avg_8_16x4_rvv_i32 :1.71.0 avg_8_16x8_c : 24.7 25.7 avg_8_16x8_rvv_i32 :3.01.7 avg_8_16x16_c : 49.0 51.5 avg_8_16x16_rvv_i32:5.53.2 avg_8_16x32_c : 97.7 102.7 avg_8_16x32_rvv_i32: 10.55.5 avg_8_16x64_c : 219.5 223.5 avg_8_16x64_rvv_i32: 56.7 34.5 avg_8_16x128_c : 409.7 426.0 avg_8_16x128_rvv_i32 : 98.7 73.5 avg_8_32x2_c : 12.5 13.0 avg_8_32x2_rvv_i32 :1.71.0 avg_8_32x4_c : 24.2 25.5 avg_8_32x4_rvv_i32 :3.01.5 avg_8_32x8_c : 48.5 50.7 avg_8_32x8_rvv_i32 :5.22.7 avg_8_32x16_c : 96.5 101.2 avg_8_32x16_rvv_i32: 10.25.0 avg_8_32x32_c : 192.7 202.5 avg_8_32x32_rvv_i32: 19.79.5 avg_8_32x64_c : 433.5 415.5 avg_8_32x64_rvv_i32: 38.7 18.2 avg_8_32x128_c : 812.0 820.7 avg_8_32x128_rvv_i32 : 145.2 73.0 avg_8_64x2_c : 24.0 25.2 avg_8_64x2_rvv_i32 :2.71.5 avg_8_64x4_c : 48.0 50.5 avg_8_64x4_rvv_i32
Re: [FFmpeg-devel] [PATCH v5] lavc/vvc_mc: R-V V avg w_avg
Sorry, the previous logic was indeed a bit confusing. I rewrote it, renaming the third parameter to max_lmul. If e16 is involved in the function, then vsetvlstatic8 uses max_lmul == m4. If e32 is involved in the function, then vsetvlstatic8 uses max_lmul == m2. If e16 is involved in the function, then vsetvlstatic16 uses max_lmul == m8. If e32 is involved in the function, then vsetvlstatic16 uses max_lmul == m4. I think it is clearer now. Rémi Denis-Courmont 于2024年7月8日周一 23:41写道： > Le maanantaina 1. heinäkuuta 2024, 19.09.01 EEST flow gg a écrit : > > I reviewed it again, the purpose of is_w is to limit lmul to a maximum of > > 1/4 of vlen, > > 1/4 of vlen? Do you mean limit to EMUL=1 for EEW=32 and EMUL=1/4 for EEW=8? > > Limiting LMUL to less than 1 at maximum EEW is useless from a functional > standpoint, since fractional registers cannot be addressed individually. > (Of > course it might still be useful for performance reasons.) > > > to prevent vector register shortage, which can also be > > considered as vset limiting lmul. I renamed it to quarter_len_limit. > > TBH, I don't really understand. > > If a lower LMUL limit is reached, then specialisations for the > corresponding > VLEN are simply unncessary/infeasible and the code for lower VLEN should > be > used. > > If a higher LMUL limit is reached due to register pressure (or the 8 hard > limit), then the given VLEN cannot be supported at all, or requires some > completely different code. > > Either way, I don't really follow why vsetvlfixed macros need to be > involved. > > -- > 雷米‧德尼-库尔蒙 > http://www.remlab.net/ > > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg_filter: set keep_aspect to true for the crop filter
On 7/10/2024 5:29 AM, Anton Khirnov wrote: Quoting James Almer (2024-07-09 21:06:26) The input sample aspect ratio applies to the pre-cropping dimensions, so update it. I don't understand this reasoning, why should cropping a video change pixel aspect ratio? You're right, this patch is not ok. I noticed the display aspect ratio was preserved with this option, but this is not intended by the container. ___ 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/vf_scale: fix frame lifetimes
On Tue, Jul 09, 2024 at 11:34:36AM +0200, Niklas Haas wrote: > From: Niklas Haas > > scale_frame() inconsistently handled the lifetime of `in`. Fixes a > possible double free and a possible memory leak. > > The new code always has `scale_frame` take over ownership of the input > frame. I first tried writing this code in a way where the calling code > retains ownership, but this is nontrivial due to the presence of the > no-op short-circuit condition in which the input frame is directly > returned. (As an alternative, we could use av_frame_clone() instead, but > I wanted to avoid touching the original behavior in this commit) > --- > libavfilter/vf_scale.c | 29 + > 1 file changed, 17 insertions(+), 12 deletions(-) patchset LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell 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] avutil/imgutils: av_image_check_size2() ensure width and height fit in 32bit
On Wed, Jul 10, 2024 at 10:23:57AM +0200, Anton Khirnov wrote: > Quoting Michael Niedermayer (2024-07-10 00:00:32) > > On Tue, Jul 09, 2024 at 05:14:37PM +0200, Anton Khirnov wrote: > > > Quoting Michael Niedermayer (2024-07-09 15:28:10) > > > > On Tue, Jul 09, 2024 at 03:17:58PM +0200, Anton Khirnov wrote: > > > > > > ensure width and height fit in 32bit > > > > > > > > > > why? > > > > > > > > because not everyone wants undefined behavior > > > > because not everyone wants security issues > > > > because we dont support width and height > 32bit and its easier to > > > > check in a central place > > > > because the changed codes purpose is to check if the image paramaters > > > > are > > > > within what we support, and width of 100 billion is not. You can try > > > > all encoders with 100billion width. Then try to decode. > > > > Iam curious, how many work, how many fail and how they fail > > > > how many invalid bitstreams with no warning, how many undefined > > > > behaviors, ... > > > > > > > > Simply building FFmpeg on a platform with 64bit ints doesnt update > > > > ISO and ITU standards to allow larger values > > > > > > Quoting Michael Niedermayer (2020-10-07 16:45:56): > > > > At least in code i wrote and write i consider it a bug if it would > > > > assume sizeof(int/unsigned) == 4 > > > > > > Make up your mind. > > > > Where do you see a contradiction ? > > > > 2020: assuming sizeof(int/unsigned) == 4 is a bug > > 2024: we do not support more than 32bit width and height, > > nor is that supported by the majority of codec bitsterams and formats > > -> We thus should in a central place check that instead of generating > > undefined behavior and security issues > > > > What i suggest IS actually fixing a "sizeof(int/unsigned) == 4" bug > > > > If someone wants to make the codebase work with 64bit width and height, this > > should not be limited to "int is 64bit" systems that would be a very > > seriously > > broken design and also very illogic. > > I don't see any existing conditions on video dimensions being 32bit, the > condition currently is that every dimension and their product must fit > in an int. I also don't see what actual problems does this patch > address. > > > Also your terse replies feel a bit rude > > What a coincidence, your wall of patronizing blah blah that does nothing to > actually answer my original question also seems pretty rude to me. Reap > what you sow. Lets take my reply and go over it: because not everyone wants undefined behavior because not everyone wants security issues because we dont support width and height > 32bit and its easier to check in a central place When writing code, it has generally not been considered that width or height would exceed 32bit. int can be 64bit yes, but not width and height. So every line needs to be reviewed, if you want to use it with 64bit width and height. Either way, the whole subject is mood as close to nothing supports this. movenc: avio_wb16(pb, track->par->width); /* Video width */ avio_wb16(pb, track->height); /* Video height */ mxfenc: avio_wb32(pb, stored_width); avio_wb32(pb, stored_height>>sc->interlaced); avienc: avio_wl16(pb, par->width); avio_wl16(pb, par->height); matroska: maybe nutenc: yes also lets assume either width and height is the smallest value over 32bit, 0x8000 what modern video codec supports this ? realistically you need at least a full row of macroblocks, and 3 frames, thats 96gb for a 16pixel high and 2 billion pixel long gray scale image (which is not a realistic case, people encode images closer to square btw) a more normal 16:9 image would probably fit if you combine all memory from all humans on earth. So i dont know but i think memory prices need to fall a bit before this becomes a real use cases and by then we will have int128_t likely making this cleaner and easier to support and again, like i said already, if we want to support 64bit width and height this has nothing to do with what int on a platform is. width and height should be changed to int64_t or a similar type through the codebase IFF that is wanted Also there is code that will outright break, again please try this instead of pretending it would work. for example all our code assumes product of 2 of width, height, a aspect ratio component fit in a int64_t this is violated with width or height being larger than 32bit Do you still object to a 32bit check on width and height ? If not i intend to apply a patch adding such limits If you object i will take this to the TC thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Rewriting code that is poorly written but fully understood is good. Rewriting code that one doesnt understand is a sign that one is less smart than the original author, trying to rewrite it will not make it better. signature.asc Description: PGP signature ___
Re: [FFmpeg-devel] [PATCH] avutil/imgutils: av_image_check_size2() ensure width and height fit in 32bit
Quoting Michael Niedermayer (2024-07-10 15:44:47) > Do you still object to a 32bit check on width and height ? > If not i intend to apply a patch adding such limits > If you object i will take this to the TC In my first reply in this thread I asked for a very simple thing - justify this commit, as the commit message provided ZERO arguments for why is this done and what it actually improves. Instead of answering the question you keep painting ever wordier walls of text. I'm not reading all that. Just answer the question, in the form suitable for a commit message. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Add Mediacodec audio decoders support
> On Jun 12, 2024, at 21:42, Matthieu Bouron wrote: > > Hello, > > This patchset adds Mediacodec audio decoders support. Currently, only AAC, > AMR, > MP3, FLAC, VORBIS and OPUS are supported. > > This is mainly useful to avoid shipping Android builds of FFmpeg that are > subjects to licensing/patents (due to AAC and AMR). I’m not keen on put OS audio decoder/encoder wrapper into FFmpeg. They don’t bring new features, they don’t improve performance. I know these type of wrapper exist in current project, but I’m not sure if it’s a good idea to add more. This is a policy issue rather than technique issue, it requires more people to discuss and decide. > > Best regards, > Matthieu > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil/imgutils: av_image_check_size2() ensure width and height fit in 32bit
On Wed, Jul 10, 2024 at 12:00 AM Michael Niedermayer wrote: > On Tue, Jul 09, 2024 at 05:14:37PM +0200, Anton Khirnov wrote: > > Quoting Michael Niedermayer (2024-07-09 15:28:10) > > > On Tue, Jul 09, 2024 at 03:17:58PM +0200, Anton Khirnov wrote: > > > > > ensure width and height fit in 32bit > > > > > > > > why? > > > > > > because not everyone wants undefined behavior > > > because not everyone wants security issues > > > because we dont support width and height > 32bit and its easier to > check in a central place > > > because the changed codes purpose is to check if the image paramaters > are > > > within what we support, and width of 100 billion is not. You can > try > > > all encoders with 100billion width. Then try to decode. > > > Iam curious, how many work, how many fail and how they fail > > > how many invalid bitstreams with no warning, how many undefined > behaviors, ... > > > > > > Simply building FFmpeg on a platform with 64bit ints doesnt update > > > ISO and ITU standards to allow larger values > > > > Quoting Michael Niedermayer (2020-10-07 16:45:56): > > > At least in code i wrote and write i consider it a bug if it would > > > assume sizeof(int/unsigned) == 4 > > > > Make up your mind. > > Where do you see a contradiction ? > > 2020: assuming sizeof(int/unsigned) == 4 is a bug > 2024: we do not support more than 32bit width and height, > nor is that supported by the majority of codec bitsterams and formats > -> We thus should in a central place check that instead of generating > undefined behavior and security issues > > What i suggest IS actually fixing a "sizeof(int/unsigned) == 4" bug > > If someone wants to make the codebase work with 64bit width and height, > this > should not be limited to "int is 64bit" systems that would be a very > seriously > broken design and also very illogic. > > Also your terse replies feel a bit rude > One can not simply reason with toxic humanoids. > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > No great genius has ever existed without some touch of madness. -- > Aristotle > ___ > 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] lavu/opt: Mention that AV_OPT_TYPE_IMAGE_SIZE can be unsigned
tile and untile are wrong ___ 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 v19] avformat: add farbfeld muxer and demuxer
demuxer is wrong on multiple levels, it should operate as pipe/stream only ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] avcodec/packet: mention an example source for frame cropping information
Signed-off-by: James Almer
---
libavcodec/packet.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/packet.h b/libavcodec/packet.h
index 13667ffa36..fa73edaf85 100644
--- a/libavcodec/packet.h
+++ b/libavcodec/packet.h
@@ -328,7 +328,8 @@ enum AVPacketSideDataType {
/**
* The number of pixels to discard from the top/bottom/left/right border
of the
- * decoded frame to obtain the sub-rectangle intended for presentation.
+ * decoded frame to obtain the sub-rectangle intended for presentation
(e.g.
+ * ISOBMFF clean apperture and Matroska crop elements).
*
* @code
* u32le crop_top
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] doc/demuxers: mention support for Image File Format
Signed-off-by: James Almer --- doc/demuxers.texi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/demuxers.texi b/doc/demuxers.texi index 04293c4813..986c427b1f 100644 --- a/doc/demuxers.texi +++ b/doc/demuxers.texi @@ -853,9 +853,9 @@ Range is from 1000 to INT_MAX. The value default is 48000. @section mov/mp4/3gp -Demuxer for Quicktime File Format & ISO/IEC Base Media File Format (ISO/IEC 14496-12 or MPEG-4 Part 12, ISO/IEC 15444-12 or JPEG 2000 Part 12). +Demuxer for Quicktime File Format & ISO/IEC Base Media File Format (ISO/IEC 14496-12 or MPEG-4 Part 12, ISO/IEC 15444-12 or JPEG 2000 Part 12, ISO/IEC 23008-12). -Registered extensions: mov, mp4, m4a, 3gp, 3g2, mj2, psp, m4b, ism, ismv, isma, f4v +Registered extensions: mov, mp4, m4a, 3gp, 3g2, mj2, psp, m4b, ism, ismv, isma, f4v, heic, heif, avif @subsection Options -- 2.45.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] lavu/opt: Mention that AV_OPT_TYPE_IMAGE_SIZE can be unsigned
On Wed, Jul 10, 2024 at 04:01:44PM +0200, Paul B Mahol wrote: > tile and untile are wrong How so? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avfilter/vf_scale: validate values before converting to integer
Fixes the conversion of double values to integer, which may be out of
the representable range.
Also, bail out on overflow check instead of printing an error only.
Found by OSS-Fuzz.
Signed-off-by: Kacper Michajłow
---
libavfilter/vf_scale.c | 33 +++--
1 file changed, 15 insertions(+), 18 deletions(-)
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index ae7356fd7b..66bb81dd1f 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -537,7 +537,6 @@ static int scale_eval_dimensions(AVFilterContext *ctx)
const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(inlink->format);
const AVPixFmtDescriptor *out_desc = av_pix_fmt_desc_get(outlink->format);
char *expr;
-int eval_w, eval_h;
int ret;
double res;
const AVPixFmtDescriptor *main_desc;
@@ -588,26 +587,20 @@ static int scale_eval_dimensions(AVFilterContext *ctx)
}
res = av_expr_eval(scale->w_pexpr, scale->var_values, NULL);
-eval_w = scale->var_values[VAR_OUT_W] = scale->var_values[VAR_OW] = (int)
res == 0 ? inlink->w : (int) res;
-
-res = av_expr_eval(scale->h_pexpr, scale->var_values, NULL);
-if (isnan(res)) {
-expr = scale->h_expr;
+if (isnan(res) || res < INT_MIN || res > INT_MAX) {
+expr = scale->w_expr;
ret = AVERROR(EINVAL);
goto fail;
}
-eval_h = scale->var_values[VAR_OUT_H] = scale->var_values[VAR_OH] = (int)
res == 0 ? inlink->h : (int) res;
+scale->w = scale->var_values[VAR_OUT_W] = scale->var_values[VAR_OW] = res
== 0 ? inlink->w : res;
-res = av_expr_eval(scale->w_pexpr, scale->var_values, NULL);
-if (isnan(res)) {
-expr = scale->w_expr;
+res = av_expr_eval(scale->h_pexpr, scale->var_values, NULL);
+if (isnan(res) || res < INT_MIN || res > INT_MAX) {
+expr = scale->h_expr;
ret = AVERROR(EINVAL);
goto fail;
}
-eval_w = scale->var_values[VAR_OUT_W] = scale->var_values[VAR_OW] = (int)
res == 0 ? inlink->w : (int) res;
-
-scale->w = eval_w;
-scale->h = eval_h;
+scale->h = scale->var_values[VAR_OUT_H] = scale->var_values[VAR_OH] = res
== 0 ? inlink->h : res;
return 0;
@@ -642,11 +635,15 @@ static int config_props(AVFilterLink *outlink)
scale->force_original_aspect_ratio,
scale->force_divisible_by);
-if (outlink->w > INT_MAX ||
-outlink->h > INT_MAX ||
-(outlink->h * inlink->w) > INT_MAX ||
-(outlink->w * inlink->h) > INT_MAX)
+if (outlink->w <= 0 ||
+outlink->h <= 0 ||
+outlink->h > INT_MAX / inlink->w ||
+outlink->w > INT_MAX / inlink->h)
+{
av_log(ctx, AV_LOG_ERROR, "Rescaled value for width or height is too
big.\n");
+ret = AVERROR(EINVAL);
+goto fail;
+}
/* TODO: make algorithm configurable */
--
2.43.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avfilter/vf_scale: Cleanup some checks
On Tue, 9 Jul 2024 at 23:43, Michael Niedermayer wrote: > > On Tue, Jul 09, 2024 at 04:46:59PM +0200, Kacper Michajlow wrote: > > On Tue, 9 Jul 2024 at 15:17, Anton Khirnov wrote: > > > > > > Quoting Michael Niedermayer (2024-07-09 13:37:11) > > > > Fixes: CID1513722 Operands don't affect result > > > > > > > > Sponsored-by: Sovereign Tech Fund > > > > Signed-off-by: Michael Niedermayer > > > > --- > > > > libavfilter/vf_scale.c | 6 ++ > > > > 1 file changed, 2 insertions(+), 4 deletions(-) > > > > > > > > diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c > > > > index bf09196e10d..18e9393d6c1 100644 > > > > --- a/libavfilter/vf_scale.c > > > > +++ b/libavfilter/vf_scale.c > > > > @@ -645,10 +645,8 @@ static int config_props(AVFilterLink *outlink) > > > > if (ret < 0) > > > > goto fail; > > > > > > > > -if (outlink->w > INT_MAX || > > > > -outlink->h > INT_MAX || > > > > -(outlink->h * inlink->w) > INT_MAX || > > > > -(outlink->w * inlink->h) > INT_MAX) > > > > +if ((outlink->h * (int64_t)inlink->w) > INT32_MAX || > > > > +(outlink->w * (int64_t)inlink->h) > INT32_MAX) > > > > > > This does not seems cleaner to me. > > > > > > Also, this check overall seems fishy. Why is it here at all and not e.g. > > > in ff_scale_adjust_dimensions()? Why does it not call > > > av_image_check_size()? Why does it only print a warning and not do > > > anything else? > > I intend to post a better version, but iam a little overworked ATM > so not sure if someone else will do it first. > > > > > > I agree with Anton here. The checks in vf_scale are iffy at best. > > > For starters, this is `outlink->w > INT_MAX` dead check. As the `w` is > > int already. > > that was removed by my patch for that reason. The issue btw originated > by code factorization that replaced int64 by int IIRC > > > > And there is already an UB in `scale_eval_dimensions()` > > which converts double value to int without any checks. > > i try to work on one issue at a time ... > > > > > > I think something like this would make sense to reject big numbers, > > and ofcourse ff_scale_adjust_dimensions() should be more clever about > > overflows too. There is also an overflow in swscale, but that's > > another story. > > > > diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c > > index a1a322ed9e..9483db7564 100644 > > --- a/libavfilter/vf_scale.c > > +++ b/libavfilter/vf_scale.c > > @@ -537,7 +537,7 @@ static int scale_eval_dimensions(AVFilterContext *ctx) > > const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(inlink->format); > > const AVPixFmtDescriptor *out_desc = av_pix_fmt_desc_get(outlink->format); > > char *expr; > > - int eval_w, eval_h; > > + double eval_w, eval_h; > > int ret; > > double res; > > const AVPixFmtDescriptor *main_desc; > > not a valid patch, that wont apply, its also too messed up formating wise > to review Ah, sorry, I wanted to just point at the issue, with quick diff, but my client destroyed it. I've sent a properly formatted patch now, as I feel it is a good change to do. - Kacper ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/wmavoice: use av_clipd for double values
Fixes Clang warning.
Signed-off-by: Kacper Michajłow
---
libavcodec/wmavoice.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/wmavoice.c b/libavcodec/wmavoice.c
index 258c71330c..3db73773b7 100644
--- a/libavcodec/wmavoice.c
+++ b/libavcodec/wmavoice.c
@@ -655,7 +655,7 @@ static void calc_input_response(WMAVoiceContext *s, float
*lpcs_src,
lpcs[n] = angle_mul * pwr;
/* 70.57 =~ 1/log10(1.0331663) */
-idx = av_clipf((pwr * gain_mul - 0.0295) * 70.570526123, 0, INT_MAX /
2);
+idx = av_clipd((pwr * gain_mul - 0.0295) * 70.570526123, 0, INT_MAX /
2);
if (idx > 127) { // fall back if index falls outside table range
coeffs[n] = wmavoice_energy_table[127] *
--
2.43.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] avutil/imgutils: av_image_check_size2() ensure width and height fit in 32bit
width and height > 32bit is not supported and its easier to check in a central
place
Signed-off-by: Michael Niedermayer
---
libavutil/imgutils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/imgutils.c b/libavutil/imgutils.c
index d2463815637..b738cff37c2 100644
--- a/libavutil/imgutils.c
+++ b/libavutil/imgutils.c
@@ -298,7 +298,7 @@ int av_image_check_size2(unsigned int w, unsigned int h,
int64_t max_pixels, enu
stride = 8LL*w;
stride += 128*8;
-if ((int)w<=0 || (int)h<=0 || stride >= INT_MAX ||
stride*(uint64_t)(h+128) >= INT_MAX) {
+if (w==0 || h==0 || w > INT32_MAX || h > INT32_MAX || stride >= INT_MAX ||
stride*(uint64_t)(h+128) >= INT_MAX) {
av_log(&imgutils, AV_LOG_ERROR, "Picture size %ux%u is invalid\n", w,
h);
return AVERROR(EINVAL);
}
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avutil/imgutils: av_image_check_size2() ensure width and height fit in 32bit
On 7/10/2024 12:49 PM, Michael Niedermayer wrote:
width and height > 32bit is not supported and its easier to check in a central
place
Signed-off-by: Michael Niedermayer
---
libavutil/imgutils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/imgutils.c b/libavutil/imgutils.c
index d2463815637..b738cff37c2 100644
--- a/libavutil/imgutils.c
+++ b/libavutil/imgutils.c
@@ -298,7 +298,7 @@ int av_image_check_size2(unsigned int w, unsigned int h,
int64_t max_pixels, enu
stride = 8LL*w;
stride += 128*8;
-if ((int)w<=0 || (int)h<=0 || stride >= INT_MAX || stride*(uint64_t)(h+128) >= INT_MAX) {
+if (w==0 || h==0 || w > INT32_MAX || h > INT32_MAX || stride >= INT_MAX ||
stride*(uint64_t)(h+128) >= INT_MAX) {
You could do stride*(h+128ULL) while at it, to make the line more readable.
av_log(&imgutils, AV_LOG_ERROR, "Picture size %ux%u is invalid\n", w,
h);
return AVERROR(EINVAL);
}
___
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] avformat/mov: ensure pasp box derived SAR is used if present
On 7/9/24 1:21 PM, James Almer wrote:
It's meant to override any codec specific (but container level) information,
but its position is not guaranteed, so apply the values after the entire trak
structure has been parsed.
Also, replace the ugly roundabout int -> double -> int method to set SAR from
existing dimensions while at it.
Signed-off-by: James Almer
---
libavformat/isom.h | 2 ++
libavformat/mov.c | 16
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/libavformat/isom.h b/libavformat/isom.h
index a0498f45e5..5b6125a908 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -215,6 +215,8 @@ typedef struct MOVStreamContext {
int timecode_track;
int width;///< tkhd width
int height; ///< tkhd height
+int h_spacing;///< pasp hSpacing
+int v_spacing;///< pasp vSpacing
int dts_shift;///< dts shift when ctts is negative
uint32_t palette[256];
int has_palette;
diff --git a/libavformat/mov.c b/libavformat/mov.c
index ced4b2e6b3..ce95842ce5 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1287,14 +1287,18 @@ static int mov_read_pasp(MOVContext *c, AVIOContext
*pb, MOVAtom atom)
const int num = avio_rb32(pb);
const int den = avio_rb32(pb);
AVStream *st;
+MOVStreamContext *sc;
if (c->fc->nb_streams < 1)
return 0;
st = c->fc->streams[c->fc->nb_streams-1];
+sc = st->priv_data;
+
+av_log(c->fc, AV_LOG_TRACE, "pasp: hSpacing %d, vSpacing %d\n", num, den);
if (den != 0) {
-av_reduce(&st->sample_aspect_ratio.num, &st->sample_aspect_ratio.den,
- num, den, 32767);
+sc->h_spacing = num;
+sc->v_spacing = den;
}
If den == 0, nothing is assigned at all, but if den != 0 and if num ==
0, we assign 0 to h_spacing, which will end up doing nothing because we
check h_spacing && v_spacing later on in the other line you add.
Is this intentional? Is this desired behavior? etc.
- Leo Izen (Traneptora)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCHv4] swscale: prevent undefined behaviour in the PUTRGBA macro
On Tue, Jul 09, 2024 at 05:41:32PM -0400, Sean McGovern wrote: > For even small values of 'asrc[x]', shifting them by 24 bits or more > will cause arithmetic overflow and be caught by > GCC's undefined behaviour sanitizer. > > Ensure the values do not overflow by up-casting the bracketed > expressions involving 'asrc' to uint32_t. > --- > libswscale/yuv2rgb.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB You can kill me, but you cannot change the truth. 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] avformat/mov: ensure pasp box derived SAR is used if present
On 7/10/2024 1:02 PM, Leo Izen wrote:
On 7/9/24 1:21 PM, James Almer wrote:
It's meant to override any codec specific (but container level)
information,
but its position is not guaranteed, so apply the values after the
entire trak
structure has been parsed.
Also, replace the ugly roundabout int -> double -> int method to set
SAR from
existing dimensions while at it.
Signed-off-by: James Almer
---
libavformat/isom.h | 2 ++
libavformat/mov.c | 16
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/libavformat/isom.h b/libavformat/isom.h
index a0498f45e5..5b6125a908 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -215,6 +215,8 @@ typedef struct MOVStreamContext {
int timecode_track;
int width; ///< tkhd width
int height; ///< tkhd height
+ int h_spacing; ///< pasp hSpacing
+ int v_spacing; ///< pasp vSpacing
int dts_shift; ///< dts shift when ctts is negative
uint32_t palette[256];
int has_palette;
diff --git a/libavformat/mov.c b/libavformat/mov.c
index ced4b2e6b3..ce95842ce5 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1287,14 +1287,18 @@ static int mov_read_pasp(MOVContext *c,
AVIOContext *pb, MOVAtom atom)
const int num = avio_rb32(pb);
const int den = avio_rb32(pb);
AVStream *st;
+ MOVStreamContext *sc;
if (c->fc->nb_streams < 1)
return 0;
st = c->fc->streams[c->fc->nb_streams-1];
+ sc = st->priv_data;
+
+ av_log(c->fc, AV_LOG_TRACE, "pasp: hSpacing %d, vSpacing %d\n",
num, den);
if (den != 0) {
- av_reduce(&st->sample_aspect_ratio.num,
&st->sample_aspect_ratio.den,
- num, den, 32767);
+ sc->h_spacing = num;
+ sc->v_spacing = den;
}
If den == 0, nothing is assigned at all, but if den != 0 and if num ==
0, we assign 0 to h_spacing, which will end up doing nothing because we
check h_spacing && v_spacing later on in the other line you add.
Is this intentional? Is this desired behavior? etc.
A 0/x SAR is just 0, or unset, regardless of the value for den, and we
check for sar.num immediately after the "sc->h_spacing && sc->v_spacing"
one and set it to something if it's 0, so it will make no difference.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavfi/perlin: Fix out of bounds stack buffer write
On Tue, Jul 09, 2024 at 02:41:16PM +0200, epira...@gmail.com wrote:
>
>
> On 6 Jul 2024, at 11:26, Stefano Sabatini wrote:
>
> > On date Tuesday 2024-07-02 20:38:00 +0200, Marvin Scholz wrote:
> >> An incorrect calculation in ff_perlin_init causes a write to the
> >> stack array at index 256, which is out of bounds.
> >>
> >> Fixes: CID1608711
> >> ---
> >> libavfilter/perlin.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/libavfilter/perlin.c b/libavfilter/perlin.c
> >> index 09bae7ad33..ffad8c1e4e 100644
> >> --- a/libavfilter/perlin.c
> >> +++ b/libavfilter/perlin.c
> >> @@ -129,7 +129,7 @@ int ff_perlin_init(FFPerlin *perlin, double period,
> >> int octaves, double persiste
> >> for (i = 0; i < 256; i++) {
> >> unsigned int random_idx = av_lfg_get(&lfg) % (256-i);
> >> uint8_t random_val = random_permutations[random_idx];
> >> -random_permutations[random_idx] = random_permutations[256-i];
> >> +random_permutations[random_idx] = random_permutations[255-i];
> >>
> >> perlin->permutations[i] = perlin->permutations[i+256] =
> >> random_val;
> >> }
> >
> > Looks good, thanks.
>
> Please push then, I do not have commit access.
applied
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
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] Add Mediacodec audio decoders support
On Wed, Jul 10, 2024 at 4:04 PM Zhao Zhili wrote: > > > > On Jun 12, 2024, at 21:42, Matthieu Bouron > > wrote: > > > > Hello, > > > > This patchset adds Mediacodec audio decoders support. Currently, only AAC, > > AMR, > > MP3, FLAC, VORBIS and OPUS are supported. > > > > This is mainly useful to avoid shipping Android builds of FFmpeg that are > > subjects to licensing/patents (due to AAC and AMR). > > I’m not keen on put OS audio decoder/encoder wrapper into FFmpeg. They don’t > bring > new features, they don’t improve performance. I know these type of wrapper > exist in current > project, but I’m not sure if it’s a good idea to add more. I agree that on the technical side it doesn't bring new features nor performance improvements. It's all about avoiding licensing/patents issues with AAC and AMR here. In this specific case we already have the wrapper infrastructure, the audio part only needs small adjustments to work. Moreover, if that helps, I can reduce the scope of the patch to AAC and AMR only and get rid of mp3/flac/vorbis/opus support. What do you think ? > > This is a policy issue rather than technique issue, it requires more people > to discuss and > decide. > [...] ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil/hwcontext_videotoolbox: Fix version check
On 7/9/2024 5:43 AM, epira...@gmail.com wrote:
On 8 Jul 2024, at 8:30, Zhao Zhili wrote:
From: Zhao Zhili
---
libavutil/hwcontext_videotoolbox.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/hwcontext_videotoolbox.c
b/libavutil/hwcontext_videotoolbox.c
index 953155ce32..dd89edfa08 100644
--- a/libavutil/hwcontext_videotoolbox.c
+++ b/libavutil/hwcontext_videotoolbox.c
@@ -588,7 +588,7 @@ static int vt_pixbuf_set_colorspace(void *log_ctx,
} else
CVBufferRemoveAttachment(pixbuf, kCVImageBufferGammaLevelKey);
-if (__builtin_available(macOS 10.8, iOS 10, *)) {
+if (__builtin_available(macOS 12.0, iOS 15.0, *)) {
CFDictionaryRef attachments = CVBufferCopyAttachments(pixbuf,
kCVAttachmentMode_ShouldPropagate);
if (attachments) {
colorspace =
CVImageBufferCreateColorSpaceFromAttachments(attachments);
--
2.42.0
LGTM. Sorry for breaking this.
http://fate.ffmpeg.org/log.cgi?time=20240710170512&slot=aarch64-osx-clang-1200.0.32.29&log=compile
Looks like it's not enough.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] fftools/ffmpeg_filter: use a bprint buffer for the crop filter arguments
Should ensure no truncation ocurrs.
The input sample aspect ratio applies to the pre-cropping dimensions, so update
it.
Signed-off-by: James Almer
---
fftools/ffmpeg_filter.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 097bd2ed48..bb88c6711a 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -1702,12 +1702,12 @@ static int configure_input_video_filter(FilterGraph
*fg, AVFilterGraph *graph,
av_assert0(desc);
if ((ifp->opts.flags & IFILTER_FLAG_CROP)) {
-char crop_buf[64];
-snprintf(crop_buf, sizeof(crop_buf), "w=iw-%d-%d:h=ih-%d-%d:x=%d:y=%d",
+av_bprint_clear(&args);
+av_bprintf(&args, "w=iw-%d-%d:h=ih-%d-%d:x=%d:y=%d",
ifp->opts.crop_left, ifp->opts.crop_right,
ifp->opts.crop_top, ifp->opts.crop_bottom,
ifp->opts.crop_left, ifp->opts.crop_top);
-ret = insert_filter(&last_filter, &pad_idx, "crop", crop_buf);
+ret = insert_filter(&last_filter, &pad_idx, "crop", args.str);
if (ret < 0)
return ret;
}
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil/hwcontext_videotoolbox: Fix version check
On 10 Jul 2024, at 19:26, James Almer wrote:
> On 7/9/2024 5:43 AM, epira...@gmail.com wrote:
>>
>>
>> On 8 Jul 2024, at 8:30, Zhao Zhili wrote:
>>
>>> From: Zhao Zhili
>>>
>>> ---
>>> libavutil/hwcontext_videotoolbox.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/libavutil/hwcontext_videotoolbox.c
>>> b/libavutil/hwcontext_videotoolbox.c
>>> index 953155ce32..dd89edfa08 100644
>>> --- a/libavutil/hwcontext_videotoolbox.c
>>> +++ b/libavutil/hwcontext_videotoolbox.c
>>> @@ -588,7 +588,7 @@ static int vt_pixbuf_set_colorspace(void *log_ctx,
>>> } else
>>> CVBufferRemoveAttachment(pixbuf, kCVImageBufferGammaLevelKey);
>>>
>>> -if (__builtin_available(macOS 10.8, iOS 10, *)) {
>>> +if (__builtin_available(macOS 12.0, iOS 15.0, *)) {
>>> CFDictionaryRef attachments = CVBufferCopyAttachments(pixbuf,
>>> kCVAttachmentMode_ShouldPropagate);
>>> if (attachments) {
>>> colorspace =
>>> CVImageBufferCreateColorSpaceFromAttachments(attachments);
>>> --
>>> 2.42.0
>>
>> LGTM. Sorry for breaking this.
>
> http://fate.ffmpeg.org/log.cgi?time=20240710170512&slot=aarch64-osx-clang-1200.0.32.29&log=compile
>
> Looks like it's not enough.
See my patch from yesterday, should fix it.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] avformat/rmdec: use 64bit for audio_framesize checks
On Sat, Jun 08, 2024 at 01:18:00AM +0200, Michael Niedermayer wrote: > It is not entirely clear what would prevent such overflow so even if it is > not possible, it is better to use 64bit > > Fixes: CID1491898 Unintentional integer overflow > > Sponsored-by: Sovereign Tech Fund > Signed-off-by: Michael Niedermayer > --- > libavformat/rmdec.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) will apply patchset [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire 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 7/7] avcodec/proresenc_kostya: use unsigned alpha for rotation
On Tue, Jun 18, 2024 at 03:48:26PM +0200, Michael Niedermayer wrote: > Fixes: left shift of negative value -208 > Fixes: > 69073/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PRORES_KS_fuzzer-4745020002336768 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/proresenc_kostya.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 06/11] doc/examples/mux: remove nop
On Mon, Jul 01, 2024 at 01:12:45AM +0200, Michael Niedermayer wrote: > Found through code review related to CID1604493 Overflowed constant > > Sponsored-by: Sovereign Tech Fund > Signed-off-by: Michael Niedermayer > --- > doc/examples/mux.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] lavc/h264dsp: avoid \+ expansion
This seems to be unsupported by LLVM-as. --- libavcodec/riscv/h264idct_rvv.S | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/libavcodec/riscv/h264idct_rvv.S b/libavcodec/riscv/h264idct_rvv.S index 741e7a5532..6f17df66cc 100644 --- a/libavcodec/riscv/h264idct_rvv.S +++ b/libavcodec/riscv/h264idct_rvv.S @@ -68,8 +68,10 @@ func ff_h264_idct_add_8_rvv, zve32x vse16.v v2, (t2) vse16.v v3, (t3) vlseg4e16.v v0, (a1) +.equoffset, 0 .rept 256 / __riscv_xlen -sx zero, ((__riscv_xlen / 8) * \+)(a1) +sx zero, offset(a1) +.equoffset, offset + (__riscv_xlen / 8) .endr jal t0, ff_h264_idct4_rvv add t1, a0, a2 @@ -179,8 +181,10 @@ func ff_h264_idct8_add_8_rvv, zve32x vse16.v v6, (t6) vse16.v v7, (a7) vlseg8e16.v v0, (a1) +.equoffset, 0 .rept 1024 / __riscv_xlen -sx zero, ((__riscv_xlen / 8) * \+)(a1) +sx zero, offset(a1) +.equoffset, offset + (__riscv_xlen / 8) .endr jal t0, ff_h264_idct8_rvv add t1, a0, a2 -- 2.45.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] lavc/h264dsp: R-V V high-depth h264_idct_add
T-Head C908 (cycles):
h264_idct4_add_9bpp_c:248.2
h264_idct4_add_9bpp_rvv_i32: 128.7
h264_idct4_add_10bpp_c: 256.7
h264_idct4_add_10bpp_rvv_i32: 128.7
h264_idct4_add_12bpp_c: 252.5
h264_idct4_add_12bpp_rvv_i32: 129.7
h264_idct4_add_14bpp_c: 258.0
h264_idct4_add_14bpp_rvv_i32: 129.7
---
libavcodec/riscv/h264dsp_init.c | 19 +-
libavcodec/riscv/h264idct_rvv.S | 63 +
2 files changed, 81 insertions(+), 1 deletion(-)
diff --git a/libavcodec/riscv/h264dsp_init.c b/libavcodec/riscv/h264dsp_init.c
index 5d1eddbab4..28e042e91f 100644
--- a/libavcodec/riscv/h264dsp_init.c
+++ b/libavcodec/riscv/h264dsp_init.c
@@ -52,6 +52,11 @@ void ff_h264_idct8_add4_8_rvv(uint8_t *dst, const int
*blockoffset,
int16_t *block, int stride,
const uint8_t nnzc[5 * 8]);
+void ff_h264_idct_add_9_rvv(uint8_t *dst, int16_t *block, int stride);
+void ff_h264_idct_add_10_rvv(uint8_t *dst, int16_t *block, int stride);
+void ff_h264_idct_add_12_rvv(uint8_t *dst, int16_t *block, int stride);
+void ff_h264_idct_add_14_rvv(uint8_t *dst, int16_t *block, int stride);
+
extern int ff_startcode_find_candidate_rvb(const uint8_t *, int);
extern int ff_startcode_find_candidate_rvv(const uint8_t *, int);
@@ -65,7 +70,9 @@ av_cold void ff_h264dsp_init_riscv(H264DSPContext *dsp, const
int bit_depth,
dsp->startcode_find_candidate = ff_startcode_find_candidate_rvb;
# if HAVE_RVV
if (flags & AV_CPU_FLAG_RVV_I32) {
-if (bit_depth == 8 && ff_rv_vlen_least(128)) {
+const bool zvl128b = ff_rv_vlen_least(128);
+
+if (bit_depth == 8 && zvl128b) {
for (int i = 0; i < 4; i++) {
dsp->weight_h264_pixels_tab[i] =
ff_h264_weight_funcs_8_rvv[i].weight;
@@ -86,6 +93,16 @@ av_cold void ff_h264dsp_init_riscv(H264DSPContext *dsp,
const int bit_depth,
dsp->h264_idct8_add4 = ff_h264_idct8_add4_8_rvv;
# endif
}
+
+if (bit_depth == 9 && zvl128b)
+dsp->h264_idct_add = ff_h264_idct_add_9_rvv;
+if (bit_depth == 10 && zvl128b)
+dsp->h264_idct_add = ff_h264_idct_add_10_rvv;
+if (bit_depth == 12 && zvl128b)
+dsp->h264_idct_add = ff_h264_idct_add_12_rvv;
+if (bit_depth == 14 && zvl128b)
+dsp->h264_idct_add = ff_h264_idct_add_14_rvv;
+
dsp->startcode_find_candidate = ff_startcode_find_candidate_rvv;
}
# endif
diff --git a/libavcodec/riscv/h264idct_rvv.S b/libavcodec/riscv/h264idct_rvv.S
index 6f17df66cc..23dcf45437 100644
--- a/libavcodec/riscv/h264idct_rvv.S
+++ b/libavcodec/riscv/h264idct_rvv.S
@@ -105,6 +105,69 @@ func ff_h264_idct_add_8_rvv, zve32x
ret
endfunc
+func ff_h264_idct_add_16_rvv, zve32x
+csrwi vxrm, 0
+vsetivlizero, 4, e32, m1, ta, ma
+addit1, a1, 1 * 4 * 4
+vle32.v v0, (a1)
+addit2, a1, 2 * 4 * 4
+vle32.v v1, (t1)
+addit3, a1, 3 * 4 * 4
+vle32.v v2, (t2)
+vle32.v v3, (t3)
+jal t0, ff_h264_idct4_rvv
+vse32.v v0, (a1)
+vse32.v v1, (t1)
+vse32.v v2, (t2)
+vse32.v v3, (t3)
+vlseg4e32.v v0, (a1)
+.equoffset, 0
+.rept 512 / __riscv_xlen
+sx zero, offset(a1)
+.equoffset, offset + (__riscv_xlen / 8)
+.endr
+jal t0, ff_h264_idct4_rvv
+add t1, a0, a2
+vle16.v v4, (a0)
+add t2, t1, a2
+vle16.v v5, (t1)
+add t3, t2, a2
+vle16.v v6, (t2)
+vle16.v v7, (t3)
+.irpn,0,1,2,3
+vssra.viv\n, v\n, 6
+.endr
+vsetvli zero, zero, e16, mf2, ta, ma
+vwaddu.wv v0, v0, v4
+vwaddu.wv v1, v1, v5
+vwaddu.wv v2, v2, v6
+vwaddu.wv v3, v3, v7
+vsetvli zero, zero, e32, m1, ta, ma
+.irpn,0,1,2,3
+vmax.vx v\n, v\n, zero
+.endr
+.irpn,0,1,2,3
+vmin.vx v\n, v\n, a3
+.endr
+vsetvli zero, zero, e16, mf2, ta, ma
+vncvt.x.x.w v4, v0
+vncvt.x.x.w v5, v1
+vncvt.x.x.w v6, v2
+vncvt.x.x.w v7, v3
+vse16.v v4, (a0)
+vse16.v v5, (t1)
+vse16.v v6, (t2)
+vse16.v v7, (t3)
+ret
+endfunc
+
+.irpdepth, 9, 10, 12, 14
+func ff_h264_idct_add_\depth\()_rvv, zve32x
+li a3, (1 << \depth) - 1
+j ff_h264_idct_add_16_rvv
+endfunc
+.endr
+
.variant_cc ff_h264_idct8_rvv
func ff_h264_idct8_rvv, zve32x
vsra.vi v9, v7, 1
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-d
[FFmpeg-devel] [PATCH 1/6] avfilter/vf_tiltandshift: Free dst on error
Fixes: CID1559901 Resource leak
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavfilter/vf_tiltandshift.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavfilter/vf_tiltandshift.c b/libavfilter/vf_tiltandshift.c
index b49a713339d..08bcb062473 100644
--- a/libavfilter/vf_tiltandshift.c
+++ b/libavfilter/vf_tiltandshift.c
@@ -237,8 +237,10 @@ static int output_frame(AVFilterLink *outlink)
// set correct timestamps and props as long as there is proper input
ret = av_frame_copy_props(dst, s->input);
-if (ret < 0)
+if (ret < 0) {
+av_frame_free(&dst);
return ret;
+}
// discard frame at the top of the list since it has been fully processed
list_remove_head(s);
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/6] avfilter/vf_tonemap_opencl: Dereference after NULL check
Fixes: CID1437472 Dereference before null check
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavfilter/vf_tonemap_opencl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavfilter/vf_tonemap_opencl.c b/libavfilter/vf_tonemap_opencl.c
index a2a27307b48..03219857d46 100644
--- a/libavfilter/vf_tonemap_opencl.c
+++ b/libavfilter/vf_tonemap_opencl.c
@@ -343,8 +343,7 @@ static int tonemap_opencl_filter_frame(AVFilterLink
*inlink, AVFrame *input)
int err;
double peak = ctx->peak;
-AVHWFramesContext *input_frames_ctx =
-(AVHWFramesContext*)input->hw_frames_ctx->data;
+AVHWFramesContext *input_frames_ctx;
av_log(ctx, AV_LOG_DEBUG, "Filter input: %s, %ux%u (%"PRId64").\n",
av_get_pix_fmt_name(input->format),
@@ -352,6 +351,7 @@ static int tonemap_opencl_filter_frame(AVFilterLink
*inlink, AVFrame *input)
if (!input->hw_frames_ctx)
return AVERROR(EINVAL);
+input_frames_ctx = (AVHWFramesContext*)input->hw_frames_ctx->data;
output = ff_get_video_buffer(outlink, outlink->w, outlink->h);
if (!output) {
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/6] avfilter/vf_tpad: Dont clone NULL
untested
Fixes: CID1440836 Dereference after null check
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavfilter/vf_tpad.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavfilter/vf_tpad.c b/libavfilter/vf_tpad.c
index 72d0bf338fe..a230a50022c 100644
--- a/libavfilter/vf_tpad.c
+++ b/libavfilter/vf_tpad.c
@@ -132,6 +132,7 @@ static int activate(AVFilterContext *ctx)
s->cache_start = ff_inlink_peek_frame(inlink, 0);
} else if (!s->cache_start) {
FF_FILTER_FORWARD_WANTED(outlink, inlink);
+return FFERROR_NOT_READY;
}
frame = av_frame_clone(s->cache_start);
if (!frame)
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 4/6] avfilter/vf_unsharp_opencl: Use AV_VIDEO_MAX_PLANES
Related: CID1423281 Out-of-bounds read
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavfilter/vf_unsharp_opencl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/vf_unsharp_opencl.c b/libavfilter/vf_unsharp_opencl.c
index 09398464ca3..1b7cbde9fdb 100644
--- a/libavfilter/vf_unsharp_opencl.c
+++ b/libavfilter/vf_unsharp_opencl.c
@@ -59,7 +59,7 @@ typedef struct UnsharpOpenCLContext {
cl_int size_y;
cl_float amount;
cl_float threshold;
-} plane[4];
+} plane[AV_VIDEO_MAX_PLANES];
} UnsharpOpenCLContext;
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 5/6] avfilter/vf_v360: Assert that vf was initialized
Maybe helps: CID1504571 Uninitialized scalar variable Sponsored-by: Sovereign Tech Fund Signed-off-by: Michael Niedermayer --- libavfilter/vf_v360.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavfilter/vf_v360.c b/libavfilter/vf_v360.c index 299dbe9ff54..9a6c31228d3 100644 --- a/libavfilter/vf_v360.c +++ b/libavfilter/vf_v360.c @@ -3789,6 +3789,8 @@ static int barrelsplit_to_xyz(const V360Context *s, case 3: // back bottom vf = (y * 2.f - 1.5f) / scaleh + 3.f - facef; break; +default: +av_assert0(0); } l_x = (0.5f - uf) / scalew; l_y = 0.5f * dir_vert; -- 2.45.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 6/6] avfilter/vf_xfade: Compute w2, h2 with float
Fixes: CID1458148 Result is not floating-point
Fixes: CID1458149 Result is not floating-point
Fixes: CID1458150 Result is not floating-point
Fixes: CID1458151 Result is not floating-point
Fixes: CID1458152 Result is not floating-point
Fixes: CID1458154 Result is not floating-point
Fixes: CID1458155 Result is not floating-point
Fixes: CID1458156 Result is not floating-point
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavfilter/vf_xfade.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavfilter/vf_xfade.c b/libavfilter/vf_xfade.c
index 4eea761dac6..e67a917d14f 100644
--- a/libavfilter/vf_xfade.c
+++ b/libavfilter/vf_xfade.c
@@ -956,7 +956,7 @@ static void vertopen##name##_transition(AVFilterContext
*ctx,
{
\
XFadeContext *s = ctx->priv;
\
const int width = out->width;
\
-const float w2 = out->width / 2;
\
+const float w2 = out->width / 2.0;
\
\
for (int y = slice_start; y < slice_end; y++) {
\
for (int x = 0; x < width; x++) {
\
@@ -984,7 +984,7 @@ static void vertclose##name##_transition(AVFilterContext
*ctx,
XFadeContext *s = ctx->priv;
\
const int nb_planes = s->nb_planes;
\
const int width = out->width;
\
-const float w2 = out->width / 2;
\
+const float w2 = out->width / 2.0;
\
\
for (int y = slice_start; y < slice_end; y++) {
\
for (int x = 0; x < width; x++) {
\
@@ -1012,7 +1012,7 @@ static void horzopen##name##_transition(AVFilterContext
*ctx,
XFadeContext *s = ctx->priv;
\
const int nb_planes = s->nb_planes;
\
const int width = out->width;
\
-const float h2 = out->height / 2;
\
+const float h2 = out->height / 2.0;
\
\
for (int y = slice_start; y < slice_end; y++) {
\
const float smooth = 2.f - fabsf((y - h2) / h2) - progress * 2.f;
\
@@ -1040,7 +1040,7 @@ static void horzclose##name##_transition(AVFilterContext
*ctx,
XFadeContext *s = ctx->priv;
\
const int nb_planes = s->nb_planes;
\
const int width = out->width;
\
-const float h2 = out->height / 2;
\
+const float h2 = out->height / 2.0;
\
\
for (int y = slice_start; y < slice_end; y++) {
\
const float smooth = 1.f + fabsf((y - h2) / h2) - progress * 2.f;
\
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
