Re: [FFmpeg-devel] [PATCH v2 2/6] avformat: add Android content resolver protocol support

2024-03-16 Thread Zhao Zhili
Sorry for the long delay of review.

> On Mar 5, 2024, at 03:37, Matthieu Bouron  wrote:
> 
> On Tue, Feb 27, 2024 at 03:50:38PM +0100, Matthieu Bouron wrote:
>> Handles Android content-uri starting with content://.
>> ---
> 
> [...]
> 

> Handles Android content-uri starting with content://.
> ---
>  configure   |   2 +
>  doc/APIchanges  |   3 +
>  libavcodec/jni.c|   1 +
>  libavformat/Makefile|   1 +
>  libavformat/file.c  | 157 
>  libavformat/protocols.c |   1 +
>  6 files changed, 165 insertions(+)
> 
> diff --git a/configure b/configure
> index bb5e630bad..790a1df7c8 100755
> --- a/configure
> +++ b/configure
> @@ -3655,6 +3655,8 @@ xcbgrab_indev_suggest="libxcb_shm libxcb_shape 
> libxcb_xfixes"
>  xv_outdev_deps="xlib_xv xlib_x11 xlib_xext"
>  
>  # protocols
> +android_content_protocol_deps="jni"
> +android_content_protocol_select="file_protocol"
>  async_protocol_deps="threads"
>  bluray_protocol_deps="libbluray"
>  ffrtmpcrypt_protocol_conflict="librtmp_protocol"
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 10f6667e9e..258e953ca6 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -2,6 +2,9 @@ The last version increases of all libraries were on 2023-02-09
>  
>  API changes, most recent first:
>  
> +2024-02-xx - xx - lavc 60.41.100 - jni.h
> +  Add av_jni_set_android_app_ctx() and av_jni_get_android_app_ctx().

Should be added together with patch 1/6.

> +
>  2024-02-26 - xx - lavf 60.22.101 - avformat.h
>AV_DISPOSITION_DEPENDENT may now also be used for video streams
>intended to be merged with other video streams for presentation.
> diff --git a/libavcodec/jni.c b/libavcodec/jni.c
> index cfe95bd1ec..1193c608c3 100644
> --- a/libavcodec/jni.c
> +++ b/libavcodec/jni.c
> @@ -35,6 +35,7 @@
>  #include "ffjni.h"
>  
>  static void *java_vm;
> +static void *android_app_ctx;
>  static pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
>  
>  int av_jni_set_java_vm(void *vm, void *log_ctx)
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index 4a380668bd..08fe98a535 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -657,6 +657,7 @@ OBJS-$(CONFIG_LIBOPENMPT_DEMUXER)+= libopenmpt.o
>  OBJS-$(CONFIG_VAPOURSYNTH_DEMUXER)   += vapoursynth.o
>  
>  # protocols I/O
> +OBJS-$(CONFIG_ANDROID_CONTENT_PROTOCOL)  += file.o
>  OBJS-$(CONFIG_ASYNC_PROTOCOL)+= async.o
>  OBJS-$(CONFIG_APPLEHTTP_PROTOCOL)+= hlsproto.o
>  OBJS-$(CONFIG_BLURAY_PROTOCOL)   += bluray.o
> diff --git a/libavformat/file.c b/libavformat/file.c
> index 64df7ff6fb..1b2b69f090 100644
> --- a/libavformat/file.c
> +++ b/libavformat/file.c
> @@ -40,6 +40,12 @@
>  #include 
>  #include "os_support.h"
>  #include "url.h"
> +#if CONFIG_ANDROID_CONTENT_PROTOCOL
> +#include 
> +#include "libavcodec/jni.h"
> +#include "libavcodec/ffjni.c"
> +#endif
> +
>  
>  /* Some systems may not have S_ISFIFO */
>  #ifndef S_ISFIFO
> @@ -101,6 +107,21 @@ typedef struct FileContext {
>  int64_t initial_pos;
>  } FileContext;
>  
> +
> +#if CONFIG_ANDROID_CONTENT_PROTOCOL
> +static const AVOption android_content_options[] = {
> +{ "blocksize", "set I/O operation maximum block size", 
> offsetof(FileContext, blocksize), AV_OPT_TYPE_INT, { .i64 = INT_MAX }, 1, 
> INT_MAX, AV_OPT_FLAG_ENCODING_PARAM },
> +{ NULL }
> +};
> +
> +static const AVClass android_content_class = {
> +.class_name = "android_content",
> +.item_name  = av_default_item_name,
> +.option = android_content_options,
> +.version= LIBAVUTIL_VERSION_INT,
> +};
> +#endif
> +
>  static const AVOption file_options[] = {
>  { "truncate", "truncate existing files on write", offsetof(FileContext, 
> trunc), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, AV_OPT_FLAG_ENCODING_PARAM },
>  { "blocksize", "set I/O operation maximum block size", 
> offsetof(FileContext, blocksize), AV_OPT_TYPE_INT, { .i64 = INT_MAX }, 1, 
> INT_MAX, AV_OPT_FLAG_ENCODING_PARAM },
> @@ -524,3 +545,139 @@ const URLProtocol ff_fd_protocol = {
>  };
>  
>  #endif /* CONFIG_FD_PROTOCOL */
> +
> +#if CONFIG_ANDROID_CONTENT_PROTOCOL
> +
> +struct JFields {
> +jclass uri_class;
> +jmethodID parse_id;
> +
> +jclass context_class;
> +jmethodID get_content_resolver_id;
> +
> +jclass content_resolver_class;
> +jmethodID open_file_descriptor_id;
> +
> +jclass parcel_file_descriptor_class;
> +jmethodID detach_fd_id;
> +};

typedef struct is the preferred coding style of FFmpeg, it’s mentioned in
developer.texi.

> +
> +#define OFFSET(x) offsetof(struct JFields, x)
> +static const struct FFJniField jfields_mapping[] = {
> +{ "android/net/Uri", NULL, NULL, FF_JNI_CLASS, OFFSET(uri_class), 1 },
> +{ "android/net/Uri", "parse", 
> "(Ljava/lang/String;)Landroid/net/Uri;", FF_JNI_STATIC_METHOD, 
> OFFSET(parse_id), 1 },
> +
> +{ "android/content/Context", NULL, NULL, FF_JNI_CLASS, 
> 

[FFmpeg-devel] [PATCH v4] avformat/rcwtdec: add RCWT Closed Captions demuxer

2024-03-16 Thread Marth64
Raw Captions With Time (RCWT) is a format native to ccextractor, a commonly
used open source tool for processing 608/708 Closed Captions (CC) sources.
RCWT can be used to archive the original CC bitstream. The muxer was added
in January 2024. In this commit, add the demuxer.

One can now demux RCWT files for rendering in ccaption_dec or interoperate
with ccextractor (which produces RCWT). Using the muxer/demuxer combination,
the CC bits can be kept for further processing or rendering with either tool.
This can be an effective approach to backup original CC presentations.

Prior to this, the next best solution was FFmpeg's SCC muxer, but SCC itself
is not compatible with ccextractor (which is a de facto OSS CC processing tool)
and it is a proprietary format.

Tests will follow.

Signed-off-by: Marth64 
---
 libavformat/Makefile |   1 +
 libavformat/allformats.c |   1 +
 libavformat/rcwtdec.c| 153 +++
 3 files changed, 155 insertions(+)
 create mode 100644 libavformat/rcwtdec.c

diff --git a/libavformat/Makefile b/libavformat/Makefile
index 94a949f555..a6de720d8c 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -493,6 +493,7 @@ OBJS-$(CONFIG_QOA_DEMUXER)   += qoadec.o
 OBJS-$(CONFIG_R3D_DEMUXER)   += r3d.o
 OBJS-$(CONFIG_RAWVIDEO_DEMUXER)  += rawvideodec.o
 OBJS-$(CONFIG_RAWVIDEO_MUXER)+= rawenc.o
+OBJS-$(CONFIG_RCWT_DEMUXER)  += rcwtdec.o subtitles.o
 OBJS-$(CONFIG_RCWT_MUXER)+= rcwtenc.o subtitles.o
 OBJS-$(CONFIG_REALTEXT_DEMUXER)  += realtextdec.o subtitles.o
 OBJS-$(CONFIG_REDSPARK_DEMUXER)  += redspark.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index e15d0fa6d7..3140018f8d 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -391,6 +391,7 @@ extern const FFInputFormat  ff_qoa_demuxer;
 extern const FFInputFormat  ff_r3d_demuxer;
 extern const FFInputFormat  ff_rawvideo_demuxer;
 extern const FFOutputFormat ff_rawvideo_muxer;
+extern const FFInputFormat  ff_rcwt_demuxer;
 extern const FFOutputFormat ff_rcwt_muxer;
 extern const FFInputFormat  ff_realtext_demuxer;
 extern const FFInputFormat  ff_redspark_demuxer;
diff --git a/libavformat/rcwtdec.c b/libavformat/rcwtdec.c
new file mode 100644
index 00..1fd35be41b
--- /dev/null
+++ b/libavformat/rcwtdec.c
@@ -0,0 +1,153 @@
+/*
+ * RCWT (Raw Captions With Time) demuxer
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/*
+ * RCWT (Raw Captions With Time) is a format native to ccextractor, a commonly
+ * used open source tool for processing 608/708 Closed Captions (CC) sources.
+ * It can be used to archive the original, raw CC bitstream and to produce
+ * a source file for later CC processing or conversion. As a result,
+ * it also allows for interopability with ccextractor for processing CC data
+ * extracted via ffmpeg. The format is simple to parse and can be used
+ * to retain all lines and variants of CC.
+ *
+ * This demuxer implements the specification as of March 2024, which has
+ * been stable and unchanged since April 2014.
+ *
+ * A free specification of RCWT can be found here:
+ * 
@url{https://github.com/CCExtractor/ccextractor/blob/master/docs/BINARY_FILE_FORMAT.TXT}
+ */
+
+#include "avformat.h"
+#include "demux.h"
+#include "internal.h"
+#include "subtitles.h"
+#include "libavutil/intreadwrite.h"
+
+#define RCWT_CLUSTER_MAX_BLOCKS 65535
+#define RCWT_BLOCK_SIZE 3
+#define RCWT_HEADER_SIZE11
+
+typedef struct RCWTContext {
+FFDemuxSubtitlesQueue q;
+} RCWTContext;
+
+static int rcwt_read_header(AVFormatContext *avf)
+{
+RCWTContext *rcwt = avf->priv_data;
+
+AVPacket  *sub = NULL;
+AVStream  *st;
+uint8_t   header[RCWT_HEADER_SIZE] = {0};
+int   nb_bytes = 0;
+
+/* validate the header */
+nb_bytes = avio_read(avf->pb, header, RCWT_HEADER_SIZE);
+if (nb_bytes != RCWT_HEADER_SIZE) {
+av_log(avf, AV_LOG_ERROR, "Header does not have the expected size "
+  "(expected=%d actual=%d)\n",
+  RCWT_HEADER_SIZE, nb_bytes);
+return AVERROR_INVALIDDATA;
+

Re: [FFmpeg-devel] [PATCH v3 3/6] avcodec/ccaption_dec: ignore leading non-breaking spaces

2024-03-16 Thread Marth64
Hi Stefano,

I would like to withdraw this patch for now.
I have found content where this breaks center
justified text further (which is already not supported).

I will instead try to implement center justification
and incorporate this through that route.

Please ignore it.

Thank you for understanding,
___
ffmpeg-devel mailing list
ffmpeg-devel@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 v5] avcodec/libx264: fix extradata when config annexb=0

2024-03-16 Thread Zhao Zhili


> On Mar 14, 2024, at 21:14, Andreas Rheinhardt 
>  wrote:
> 
> Zhao Zhili:
>> From: Zhao Zhili 
>> 
>> ---
>> v5: Decode chroma_format_idc directly instead of 
>> ff_h264_decode_seq_parameter_set
>> v4: Fix missing SEI in set_avcc_extradata
>> v3: Remove unnecessary inclusion
>> 
>> libavcodec/libx264.c | 162 ---
>> 1 file changed, 138 insertions(+), 24 deletions(-)
>> 
>> diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
>> index 10d646bd76..64cefb5fb0 100644
>> --- a/libavcodec/libx264.c
>> +++ b/libavcodec/libx264.c
>> @@ -38,6 +38,7 @@
>> #include "packet_internal.h"
>> #include "atsc_a53.h"
>> #include "sei.h"
>> +#include "golomb.h"
>> 
>> #include 
>> #include 
>> @@ -865,6 +866,140 @@ static int convert_pix_fmt(enum AVPixelFormat pix_fmt)
>> return 0;
>> }
>> 
>> +static int save_sei(AVCodecContext *avctx, x264_nal_t *nal)
>> +{
>> +X264Context *x4 = avctx->priv_data;
>> +
>> +av_log(avctx, AV_LOG_INFO, "%s\n", nal->p_payload + 25);
>> +x4->sei_size = nal->i_payload;
>> +x4->sei = av_malloc(x4->sei_size);
>> +if (!x4->sei)
>> +return AVERROR(ENOMEM);
>> +
>> +memcpy(x4->sei, nal->p_payload, nal->i_payload);
>> +
>> +return 0;
>> +}
>> +
>> +static int set_avcc_extradata(AVCodecContext *avctx, x264_nal_t *nal, int 
>> nnal)
>> +{
>> +X264Context *x4 = avctx->priv_data;
>> +x264_nal_t *sps_nal = NULL;
>> +x264_nal_t *pps_nal = NULL;
>> +uint8_t *p, *sps;
>> +int ret;
>> +
>> +/* We know it's in the order of SPS/PPS/SEI, but it's not documented in 
>> x264 API.
>> + * The x264 param i_sps_id implies there is a single pair of SPS/PPS.
>> + */
>> +for (int i = 0; i < nnal; i++) {
>> +switch (nal[i].i_type) {
>> +case NAL_SPS:
>> +sps_nal = [i];
>> +break;
>> +case NAL_PPS:
>> +pps_nal = [i];
>> +break;
>> +case NAL_SEI:
>> +ret = save_sei(avctx, [i]);
>> +if (ret < 0)
>> +return ret;
>> +break;
>> +}
>> +}
>> +if (!sps_nal || !pps_nal)
>> +return AVERROR_EXTERNAL;
>> +
>> +avctx->extradata_size = sps_nal->i_payload + pps_nal->i_payload + 7;
>> +avctx->extradata = av_mallocz(avctx->extradata_size + 
>> AV_INPUT_BUFFER_PADDING_SIZE);
>> +if (!avctx->extradata)
>> +return AVERROR(ENOMEM);
>> +
>> +// Now create AVCDecoderConfigurationRecord
>> +p = avctx->extradata;
>> +// Skip size part
>> +sps = sps_nal->p_payload + 4;
>> +*p++ = 1; // version
>> +*p++ = sps[1]; // AVCProfileIndication
>> +*p++ = sps[2]; // profile_compatibility
>> +*p++ = sps[3]; // AVCLevelIndication
>> +*p++ = 0xFF;
>> +*p++ = 0xE0 | 0x01; // 3 bits reserved (111) + 5 bits number of sps
>> +memcpy(p, sps_nal->p_payload + 2, sps_nal->i_payload - 2);
>> +// Make sps has AV_INPUT_BUFFER_PADDING_SIZE padding, so it can be used
>> +// with GetBitContext
>> +sps = p + 2;
>> +p += sps_nal->i_payload - 2;
>> +*p++ = 1;
>> +memcpy(p, pps_nal->p_payload + 2, pps_nal->i_payload - 2);
>> +p += pps_nal->i_payload - 2;
>> +
>> +if (sps[3] != 66 && sps[3] != 77 && sps[3] != 88) {
>> +GetBitContext gbc;
>> +int chroma_format_idc;
>> +int bit_depth_luma_minus8, bit_depth_chroma_minus8;
>> +
>> +/* It's not possible to have emulation prevention byte before
>> + * bit_depth_chroma_minus8 due to the range of sps id, 
>> chroma_format_idc
>> + * and so on. So we can read directly without need to escape 
>> emulation
>> + * prevention byte.
> 
> There is a slight problem here: You ignore the possibility of
> profile_idc being zero. After all, all values not being used are merely
> reserved and can be used at any time (although I doubt that they will
> ever use this). Shall we ignore this?
> The above check (and presumably the ISOBMFF spec for this) uses an
> opt-out check for profile, whereas the H.264 spec actually uses an
> opt-in check. I just wanted to mention it, feel free to ignore it.
> 
>> + *
>> + * +4 to skip until sps id.
>> + */
>> +init_get_bits8(, sps + 4, sps_nal->i_payload - 4 - 4);
>> +// Skip sps id
>> +get_ue_golomb_31();
>> +chroma_format_idc = get_ue_golomb_31();
>> +if (chroma_format_idc == 3)
>> +skip_bits1();
>> +bit_depth_luma_minus8 = get_ue_golomb_31();
>> +bit_depth_chroma_minus8 = get_ue_golomb_31();
>> +
>> +*p++ = 0xFC | chroma_format_idc;
>> +*p++ = 0xF8 | bit_depth_luma_minus8;
>> +*p++ = 0xF8 | bit_depth_chroma_minus8;
>> +*p++ = 0;
>> +}
>> +av_assert0(avctx->extradata + avctx->extradata_size >= p);
> 
> Does this have to be an av_assert0?

Switched to assert2 in v6. 

> 
>> +avctx->extradata_size = p - avctx->extradata;
>> +
>> +return 0;
>> +}
>> +
>> 

[FFmpeg-devel] [PATCH v6] avcodec/libx264: fix extradata when config annexb=0

2024-03-16 Thread Zhao Zhili
From: Zhao Zhili 

---
v6: use av_assert2
select golomb in configure
conditional compile in case of CONFIG_LIBX264_ENCODER=0
v5: Decode chroma_format_idc directly instead of 
ff_h264_decode_seq_parameter_set
v4: Fix missing SEI in set_avcc_extradata
v3: Remove unnecessary inclusion

 configure|   2 +-
 libavcodec/libx264.c | 166 ---
 2 files changed, 143 insertions(+), 25 deletions(-)

diff --git a/configure b/configure
index 2b4c4ec9a2..d9d2183a47 100755
--- a/configure
+++ b/configure
@@ -3484,7 +3484,7 @@ libwebp_encoder_deps="libwebp"
 libwebp_anim_encoder_deps="libwebp"
 libx262_encoder_deps="libx262"
 libx264_encoder_deps="libx264"
-libx264_encoder_select="atsc_a53"
+libx264_encoder_select="atsc_a53 golomb"
 libx264rgb_encoder_deps="libx264"
 libx264rgb_encoder_select="libx264_encoder"
 libx265_encoder_deps="libx265"
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 0997c4e134..ddec06d960 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -38,6 +38,7 @@
 #include "packet_internal.h"
 #include "atsc_a53.h"
 #include "sei.h"
+#include "golomb.h"
 
 #include 
 #include 
@@ -847,6 +848,144 @@ static int convert_pix_fmt(enum AVPixelFormat pix_fmt)
 return 0;
 }
 
+static int save_sei(AVCodecContext *avctx, x264_nal_t *nal)
+{
+X264Context *x4 = avctx->priv_data;
+
+av_log(avctx, AV_LOG_INFO, "%s\n", nal->p_payload + 25);
+x4->sei_size = nal->i_payload;
+x4->sei = av_malloc(x4->sei_size);
+if (!x4->sei)
+return AVERROR(ENOMEM);
+
+memcpy(x4->sei, nal->p_payload, nal->i_payload);
+
+return 0;
+}
+
+#if CONFIG_LIBX264_ENCODER
+static int set_avcc_extradata(AVCodecContext *avctx, x264_nal_t *nal, int nnal)
+{
+X264Context *x4 = avctx->priv_data;
+x264_nal_t *sps_nal = NULL;
+x264_nal_t *pps_nal = NULL;
+uint8_t *p, *sps;
+int ret;
+
+/* We know it's in the order of SPS/PPS/SEI, but it's not documented in 
x264 API.
+ * The x264 param i_sps_id implies there is a single pair of SPS/PPS.
+ */
+for (int i = 0; i < nnal; i++) {
+switch (nal[i].i_type) {
+case NAL_SPS:
+sps_nal = [i];
+break;
+case NAL_PPS:
+pps_nal = [i];
+break;
+case NAL_SEI:
+ret = save_sei(avctx, [i]);
+if (ret < 0)
+return ret;
+break;
+}
+}
+if (!sps_nal || !pps_nal)
+return AVERROR_EXTERNAL;
+
+avctx->extradata_size = sps_nal->i_payload + pps_nal->i_payload + 7;
+avctx->extradata = av_mallocz(avctx->extradata_size + 
AV_INPUT_BUFFER_PADDING_SIZE);
+if (!avctx->extradata)
+return AVERROR(ENOMEM);
+
+// Now create AVCDecoderConfigurationRecord
+p = avctx->extradata;
+// Skip size part
+sps = sps_nal->p_payload + 4;
+*p++ = 1; // version
+*p++ = sps[1]; // AVCProfileIndication
+*p++ = sps[2]; // profile_compatibility
+*p++ = sps[3]; // AVCLevelIndication
+*p++ = 0xFF;
+*p++ = 0xE0 | 0x01; // 3 bits reserved (111) + 5 bits number of sps
+memcpy(p, sps_nal->p_payload + 2, sps_nal->i_payload - 2);
+// Make sps has AV_INPUT_BUFFER_PADDING_SIZE padding, so it can be used
+// with GetBitContext
+sps = p + 2;
+p += sps_nal->i_payload - 2;
+*p++ = 1;
+memcpy(p, pps_nal->p_payload + 2, pps_nal->i_payload - 2);
+p += pps_nal->i_payload - 2;
+
+if (sps[3] != 66 && sps[3] != 77 && sps[3] != 88) {
+GetBitContext gbc;
+int chroma_format_idc;
+int bit_depth_luma_minus8, bit_depth_chroma_minus8;
+
+/* It's not possible to have emulation prevention byte before
+ * bit_depth_chroma_minus8 due to the range of sps id, 
chroma_format_idc
+ * and so on. So we can read directly without need to escape emulation
+ * prevention byte.
+ *
+ * +4 to skip until sps id.
+ */
+init_get_bits8(, sps + 4, sps_nal->i_payload - 4 - 4);
+// Skip sps id
+get_ue_golomb_31();
+chroma_format_idc = get_ue_golomb_31();
+if (chroma_format_idc == 3)
+skip_bits1();
+bit_depth_luma_minus8 = get_ue_golomb_31();
+bit_depth_chroma_minus8 = get_ue_golomb_31();
+
+*p++ = 0xFC | chroma_format_idc;
+*p++ = 0xF8 | bit_depth_luma_minus8;
+*p++ = 0xF8 | bit_depth_chroma_minus8;
+*p++ = 0;
+}
+av_assert2(avctx->extradata + avctx->extradata_size >= p);
+avctx->extradata_size = p - avctx->extradata;
+
+return 0;
+}
+#endif
+
+static int set_extradata(AVCodecContext *avctx)
+{
+X264Context *x4 = avctx->priv_data;
+x264_nal_t *nal;
+uint8_t *p;
+int nnal, s;
+
+s = x264_encoder_headers(x4->enc, , );
+if (s < 0)
+return AVERROR_EXTERNAL;
+
+#if CONFIG_LIBX264_ENCODER
+if (!x4->params.b_annexb)
+return set_avcc_extradata(avctx, nal, nnal);
+#endif
+
+

[FFmpeg-devel] [PATCH] avformat/hls: update current segment reference before use

2024-03-16 Thread Kacper Michajłow
It may be invalidated by the time it is used.

Fixes use after free when accessing current segment.

Fixes: #10825
---
 libavformat/hls.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavformat/hls.c b/libavformat/hls.c
index f6b44c2e35..94bc6bc064 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -2098,6 +2098,7 @@ static int hls_read_header(AVFormatContext *s)
  * If encryption scheme is SAMPLE-AES and audio setup information is 
present in external audio track,
  * use that information to find the media format, otherwise probe 
input data
  */
+seg = current_segment(pls);
 if (seg && seg->key_type == KEY_SAMPLE_AES && pls->is_id3_timestamped 
&&
 pls->audio_setup_info.codec_id != AV_CODEC_ID_NONE) {
 void *iter = NULL;
@@ -2124,6 +2125,7 @@ static int hls_read_header(AVFormatContext *s)
 av_free(url);
 }
 
+seg = current_segment(pls);
 if (seg && seg->key_type == KEY_SAMPLE_AES) {
 if (strstr(in_fmt->name, "mov")) {
 char key[33];
@@ -2170,6 +2172,7 @@ static int hls_read_header(AVFormatContext *s)
  * on us if they want to.
  */
 if (pls->is_id3_timestamped || (pls->n_renditions > 0 && 
pls->renditions[0]->type == AVMEDIA_TYPE_AUDIO)) {
+seg = current_segment(pls);
 if (seg && seg->key_type == KEY_SAMPLE_AES && 
pls->audio_setup_info.setup_data_length > 0 &&
 pls->ctx->nb_streams == 1)
 ret = ff_hls_senc_parse_audio_setup_info(pls->ctx->streams[0], 
>audio_setup_info);
-- 
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 v4] avcodec/h2645_sei: validate Mastering Display Colour Volume SEI values

2024-03-16 Thread Kacper Michajłow
As we can read in ST 2086:

Values outside the specified ranges of luminance and chromaticity values
are not reserved by SMPTE, and can be used for purposes outside the
scope of this standard.

This is further acknowledged by ITU-T H.264 and ITU-T H.265. Which says
that values out of range are unknown or unspecified or specified by
other means not specified in this Specification.

Signed-off-by: Kacper Michajłow 
---
 libavcodec/h2645_sei.c | 55 ++
 1 file changed, 39 insertions(+), 16 deletions(-)

diff --git a/libavcodec/h2645_sei.c b/libavcodec/h2645_sei.c
index e60606f43f..ba0eb5059f 100644
--- a/libavcodec/h2645_sei.c
+++ b/libavcodec/h2645_sei.c
@@ -719,38 +719,61 @@ int ff_h2645_sei_to_frame(AVFrame *frame, H2645SEI *sei,
 return ret;
 
 if (metadata) {
+metadata->has_luminance = 1;
+metadata->has_primaries = 1;
+
 for (i = 0; i < 3; i++) {
 const int j = mapping[i];
 metadata->display_primaries[i][0].num = 
sei->mastering_display.display_primaries[j][0];
 metadata->display_primaries[i][0].den = chroma_den;
+metadata->has_primaries &= 
sei->mastering_display.display_primaries[j][0] >= 5 &&
+   
sei->mastering_display.display_primaries[j][0] <= 37000;
+
 metadata->display_primaries[i][1].num = 
sei->mastering_display.display_primaries[j][1];
 metadata->display_primaries[i][1].den = chroma_den;
+metadata->has_primaries &= 
sei->mastering_display.display_primaries[j][1] >= 5 &&
+   
sei->mastering_display.display_primaries[j][1] <= 42000;
 }
 metadata->white_point[0].num = 
sei->mastering_display.white_point[0];
 metadata->white_point[0].den = chroma_den;
+metadata->has_primaries &= sei->mastering_display.white_point[0] 
>= 5 &&
+   sei->mastering_display.white_point[0] 
<= 37000;
+
 metadata->white_point[1].num = 
sei->mastering_display.white_point[1];
 metadata->white_point[1].den = chroma_den;
+metadata->has_primaries &= sei->mastering_display.white_point[1] 
>= 5 &&
+   sei->mastering_display.white_point[1] 
<= 42000;
 
 metadata->max_luminance.num = sei->mastering_display.max_luminance;
 metadata->max_luminance.den = luma_den;
+metadata->has_luminance &= sei->mastering_display.max_luminance >= 
5 &&
+   sei->mastering_display.max_luminance <= 
1;
+
 metadata->min_luminance.num = sei->mastering_display.min_luminance;
 metadata->min_luminance.den = luma_den;
-metadata->has_luminance = 1;
-metadata->has_primaries = 1;
-
-av_log(avctx, AV_LOG_DEBUG, "Mastering Display Metadata:\n");
-av_log(avctx, AV_LOG_DEBUG,
-   "r(%5.4f,%5.4f) g(%5.4f,%5.4f) b(%5.4f %5.4f) wp(%5.4f, 
%5.4f)\n",
-   av_q2d(metadata->display_primaries[0][0]),
-   av_q2d(metadata->display_primaries[0][1]),
-   av_q2d(metadata->display_primaries[1][0]),
-   av_q2d(metadata->display_primaries[1][1]),
-   av_q2d(metadata->display_primaries[2][0]),
-   av_q2d(metadata->display_primaries[2][1]),
-   av_q2d(metadata->white_point[0]), 
av_q2d(metadata->white_point[1]));
-av_log(avctx, AV_LOG_DEBUG,
-   "min_luminance=%f, max_luminance=%f\n",
-   av_q2d(metadata->min_luminance), 
av_q2d(metadata->max_luminance));
+metadata->has_luminance &= sei->mastering_display.min_luminance >= 
1 &&
+   sei->mastering_display.min_luminance <= 
5 &&
+   sei->mastering_display.min_luminance <
+   sei->mastering_display.max_luminance;
+
+if (metadata->has_luminance || metadata->has_primaries)
+av_log(avctx, AV_LOG_DEBUG, "Mastering Display Metadata:\n");
+if (metadata->has_primaries) {
+av_log(avctx, AV_LOG_DEBUG,
+   "r(%5.4f,%5.4f) g(%5.4f,%5.4f) b(%5.4f %5.4f) wp(%5.4f, 
%5.4f)\n",
+   av_q2d(metadata->display_primaries[0][0]),
+   av_q2d(metadata->display_primaries[0][1]),
+   av_q2d(metadata->display_primaries[1][0]),
+   av_q2d(metadata->display_primaries[1][1]),
+   av_q2d(metadata->display_primaries[2][0]),
+   av_q2d(metadata->display_primaries[2][1]),
+   av_q2d(metadata->white_point[0]), 
av_q2d(metadata->white_point[1]));
+}
+if 

Re: [FFmpeg-devel] [PATCH 1/2] avfilter: mark scale2ref as supporting dynamic sizes

2024-03-16 Thread Michael Niedermayer
On Wed, Mar 13, 2024 at 01:24:24PM +0100, Niklas Haas wrote:
> From: Niklas Haas 
> 
> Analogous to the "scale" filter, which this is practically identical
> with.
> ---
>  libavfilter/avfilter.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
> index 831871de90b..dcad4d55292 100644
> --- a/libavfilter/avfilter.c
> +++ b/libavfilter/avfilter.c
> @@ -1027,7 +1027,8 @@ int ff_filter_frame(AVFilterLink *link, AVFrame *frame)
>  strcmp(link->dst->filter->name, "format") &&
>  strcmp(link->dst->filter->name, "idet") &&
>  strcmp(link->dst->filter->name, "null") &&
> -strcmp(link->dst->filter->name, "scale")) {
> +strcmp(link->dst->filter->name, "scale") &&
> +strcmp(link->dst->filter->name, "scale2ref")) {
>  av_assert1(frame->format== link->format);
>  av_assert1(frame->width == link->w);
>  av_assert1(frame->height== link->h);

LGTM

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

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin


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 3/3] tools/target_dec_fuzzer: adjust threshold for AV_CODEC_ID_IFF_ILBM

2024-03-16 Thread Michael Niedermayer
Fixes: timeout
Fixes: 
66444/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_IFF_ILBM_fuzzer-4812862400823296

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 tools/target_dec_fuzzer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index 84b646b7f4..104219ed5e 100644
--- a/tools/target_dec_fuzzer.c
+++ b/tools/target_dec_fuzzer.c
@@ -245,7 +245,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t 
size) {
 case AV_CODEC_ID_HEVC:maxpixels  /= 16384; break;
 case AV_CODEC_ID_HNM4_VIDEO:  maxpixels  /= 128;   break;
 case AV_CODEC_ID_HQ_HQA:  maxpixels  /= 128;   break;
-case AV_CODEC_ID_IFF_ILBM:maxpixels  /= 128;   break;
+case AV_CODEC_ID_IFF_ILBM:maxpixels  /= 4096;  break;
 case AV_CODEC_ID_INDEO4:  maxpixels  /= 128;   break;
 case AV_CODEC_ID_INTERPLAY_ACM: maxsamples /= 16384;  break;
 case AV_CODEC_ID_JPEG2000:maxpixels  /= 4096;  break;
-- 
2.17.1

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

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


[FFmpeg-devel] [PATCH 2/3] avcodec/iff: dont add into unused pointers

2024-03-16 Thread Michael Niedermayer
Fixes: overflowing pointers
Fixes: 
66444/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_IFF_ILBM_fuzzer-4812862400823296

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/iff.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/libavcodec/iff.c b/libavcodec/iff.c
index faf4e21c42..dcca7018c4 100644
--- a/libavcodec/iff.c
+++ b/libavcodec/iff.c
@@ -1661,7 +1661,7 @@ static int decode_frame(AVCodecContext *avctx, AVFrame 
*frame,
 uint8_t *row = >data[0][y * frame->linesize[0]];
 memset(row, 0, avctx->width);
 for (plane = 0; plane < s->bpp; plane++) {
-buf += decode_byterun(s->planebuf, s->planesize, gb);
+decode_byterun(s->planebuf, s->planesize, gb);
 if (avctx->codec_tag == MKTAG('A', 'N', 'I', 'M')) {
 memcpy(video, s->planebuf, s->planesize);
 video += s->planesize;
@@ -1674,7 +1674,7 @@ static int decode_frame(AVCodecContext *avctx, AVFrame 
*frame,
 uint8_t *row = >data[0][y * frame->linesize[0]];
 memset(s->mask_buf, 0, avctx->width * sizeof(uint32_t));
 for (plane = 0; plane < s->bpp; plane++) {
-buf += decode_byterun(s->planebuf, s->planesize, gb);
+decode_byterun(s->planebuf, s->planesize, gb);
 decodeplane32(s->mask_buf, s->planebuf, s->planesize, 
plane);
 }
 lookup_pal_indicies((uint32_t *)row, s->mask_buf, 
s->mask_palbuf, avctx->width);
@@ -1685,7 +1685,7 @@ static int decode_frame(AVCodecContext *avctx, AVFrame 
*frame,
 uint8_t *row = >data[0][y * frame->linesize[0]];
 memset(s->ham_buf, 0, s->planesize * 8);
 for (plane = 0; plane < s->bpp; plane++) {
-buf += decode_byterun(s->planebuf, s->planesize, gb);
+decode_byterun(s->planebuf, s->planesize, gb);
 if (avctx->codec_tag == MKTAG('A', 'N', 'I', 'M')) {
 memcpy(video, s->planebuf, s->planesize);
 video += s->planesize;
@@ -1699,7 +1699,7 @@ static int decode_frame(AVCodecContext *avctx, AVFrame 
*frame,
 uint8_t *row = >data[0][y * frame->linesize[0]];
 memset(row, 0, avctx->width << 2);
 for (plane = 0; plane < s->bpp; plane++) {
-buf += decode_byterun(s->planebuf, s->planesize, gb);
+decode_byterun(s->planebuf, s->planesize, gb);
 decodeplane32((uint32_t *)row, s->planebuf, 
s->planesize, plane);
 }
 }
@@ -1708,12 +1708,12 @@ static int decode_frame(AVCodecContext *avctx, AVFrame 
*frame,
 if (avctx->pix_fmt == AV_PIX_FMT_PAL8 || avctx->pix_fmt == 
AV_PIX_FMT_GRAY8) {
 for (y = 0; y < avctx->height; y++) {
 uint8_t *row = >data[0][y * frame->linesize[0]];
-buf += decode_byterun(row, avctx->width, gb);
+decode_byterun(row, avctx->width, gb);
 }
 } else if (s->ham) { // IFF-PBM: HAM to AV_PIX_FMT_BGR32
 for (y = 0; y < avctx->height; y++) {
 uint8_t *row = >data[0][y * frame->linesize[0]];
-buf += decode_byterun(s->ham_buf, avctx->width, gb);
+decode_byterun(s->ham_buf, avctx->width, gb);
 decode_ham_plane32((uint32_t *)row, s->ham_buf, 
s->ham_palbuf, s->planesize);
 }
 } else
-- 
2.17.1

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

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


[FFmpeg-devel] [PATCH 1/3] tools/target_dem_fuzzer: add libavformat/demux.h

2024-03-16 Thread Michael Niedermayer
needed for FFInputFormat

Signed-off-by: Michael Niedermayer 
---
 tools/target_dem_fuzzer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/target_dem_fuzzer.c b/tools/target_dem_fuzzer.c
index 76eed9f6a2..fe69eb9be0 100644
--- a/tools/target_dem_fuzzer.c
+++ b/tools/target_dem_fuzzer.c
@@ -23,7 +23,7 @@
 #include "libavcodec/avcodec.h"
 #include "libavcodec/bytestream.h"
 #include "libavformat/avformat.h"
-
+#include "libavformat/demux.h"
 
 typedef struct IOContext {
 int64_t pos;
-- 
2.17.1

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

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


Re: [FFmpeg-devel] duplicate symbol '_dec_init' in: fftools/ffmpeg_dec.o

2024-03-16 Thread Helmut K. C. Tessarek

Hi,

On 2024-03-16 10:26, Christopher Degawa wrote:

Seems the conflict comes from
https://code.videolan.org/videolan/libbluray/-/blob/master/src/libbluray/disc/dec.c?ref_type=heads#L287
  and
https://github.com/FFmpeg/FFmpeg/commit/c4de5778bceab3c15f1239f1f16816749a7fd3b6

Perhaps you could also try asking libbluray if they could use an internal
prefix. Otherwise you might need to do a rename of that function on
ffmpeg's side.


Hmm, this commit in ffmpeg broke the possibility to link ffmpeg with 
libbluray. Just to make this perfectly clear, before that commit it 
worked without issues.


This means that nobody is able to use libbluray and ffmpeg from this 
point forward. I am sorry, but this commit should be reverted.


The commit message reads: Rename dec_open to dec_init(), as it is more 
descriptive of its new purpose.


Who cares about how descriptive it is as long as it works. Now it 
doesn't. This was not a change to implement a feature or fix a bug, but 
a simple refactor, because somebody didn't like the name.


In reality I agree with you that it might be better for libbluray to use 
a prefix/namespace or whatever.  But until then, ffmpeg should still be 
able to be linked with libbluray.


Is my standpoint unreasonable? If so, why?

Cheers,
  K. C.

--
regards Helmut K. C. Tessarek  KeyID 0x172380A011EF4944
Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944

/*
   Thou shalt not follow the NULL pointer for chaos and madness
   await thee at its end.
*/


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

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


Re: [FFmpeg-devel] [PATCH] doc/filters: Change rdiv (vf_convolution) documentation to reflect actual behavior

2024-03-16 Thread Marton Balint




On Thu, 14 Mar 2024, Stone Chen wrote:


The documentation correctly states that the rdiv is a multiplier but 
incorrectly states the default behavior is to multiply by the sum of all matrix 
elements - it multiplies by 1/sum.

This changes the documentation to match the code.

Address trac #10889
---
doc/filters.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index e0436a5755..913365671d 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -10497,7 +10497,7 @@ and from 1 to 49 odd number of signed integers in 
@var{row} mode.
@item 2rdiv
@item 3rdiv
Set multiplier for calculated value for each plane.
-If unset or 0, it will be sum of all matrix elements.
+If unset or 0, it will be 1/sum of all matrix elements.

@item 0bias
@item 1bias
--
2.44.0



Will apply.

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

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


Re: [FFmpeg-devel] duplicate symbol '_dec_init' in: fftools/ffmpeg_dec.o

2024-03-16 Thread James Almer

On 3/16/2024 11:26 AM, Christopher Degawa wrote:

On Sat, Mar 16, 2024 at 09:08 Gnattu OC via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:


If you are using Xcode >= 15 then you will need to add `-Wl,-ld_classic`
to LDFLAGS.  During configure you will also need to set
`--host-ldflags='-Wl,-ld_classic’`.


On Mar 16, 2024, at 09:04, Helmut K. C. Tessarek 

wrote:


Hello,

It's me again - the dude who compiles ffmpeg for macOS... ;-)

I haven't updated the referenced libbluray, but only compiled ffmpeg the

way I always do. The last time was about 3 days ago and all was good.


This is the git hash of ffmpeg I tried to compile: b47abd5737

duplicate symbol '_dec_init' in:
fftools/ffmpeg_dec.o
/Users/Shared/ffmpeg/sw/lib/libbluray.a(libbluray_la-dec.o)
ld: 1 duplicate symbol for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see

invocation)


The only code that changed was ffmpeg and libx265, thus I suspect it was

a change to ffmpeg. I can't really do a git bisect, because this error only
happens after ffmpeg is compiled at the linker stage, so that would take me
forever


However, the dev who did a change related to this would probably know

right away.


Cheers,
  K. C.


--
regards Helmut K. C. Tessarek  KeyID 0x172380A011EF4944
Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944

/*
   Thou shalt not follow the NULL pointer for chaos and madness
   await thee at its end.
*/
___
ffmpeg-devel mailing list
ffmpeg-devel@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".




Seems the conflict comes from
https://code.videolan.org/videolan/libbluray/-/blob/master/src/libbluray/disc/dec.c?ref_type=heads#L287
  and
https://github.com/FFmpeg/FFmpeg/commit/c4de5778bceab3c15f1239f1f16816749a7fd3b6

Perhaps you could also try asking libbluray if they could use an internal
prefix. Otherwise you might need to do a rename of that function on
ffmpeg's side.


libbluray 100% needs to either prefix it, or hid it so it's not 
exported. It's a library, so it should not be exporting such simple and 
short unprefix named symbols.

___
ffmpeg-devel mailing list
ffmpeg-devel@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] duplicate symbol '_dec_init' in: fftools/ffmpeg_dec.o

2024-03-16 Thread Helmut K. C. Tessarek

Hello,

On 2024-03-16 10:07, Gnattu OC via ffmpeg-devel wrote:

If you are using Xcode >= 15 then you will need to add `-Wl,-ld_classic` to 
LDFLAGS.


I've already been using it since I switched to Xcode 15.

Cheers,
  K. C.

--
regards Helmut K. C. Tessarek  KeyID 0x172380A011EF4944
Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944

/*
   Thou shalt not follow the NULL pointer for chaos and madness
   await thee at its end.
*/


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

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


[FFmpeg-devel] [PATCH] x86: Update x86inc.asm

2024-03-16 Thread Henrik Gramner via ffmpeg-devel
Makes things up-to-date with the upstream at
https://code.videolan.org/videolan/x86inc.asm

Specifying every individual change is difficult as there have been
divergences and cherry-picks over time, but the full upstream change
log can be found at
https://code.videolan.org/videolan/x86inc.asm/-/commits/master?ref_type=heads

Tested and passes FATE on Linux (x86-64), macOS (x86-64), and Windows
(x86-64 and x86-32). The macOS system with AVX2, the rest with
AVX512ICL.

The following local changes compared to upstream remain (is the OS/2
part still relevant?):
@@ -37,2 +37,5 @@

+%if HAVE_ALIGNED_STACK
+%define STACK_ALIGNMENT 16
+%endif
 %ifndef STACK_ALIGNMENT
@@ -86,4 +89,11 @@

+; aout does not support align=
+; NOTE: This section is out of sync with x264, in order to
+; keep supporting OS/2.
 %macro SECTION_RODATA 0-1 16
-%ifidn __OUTPUT_FORMAT__,win32
+%ifidn __OUTPUT_FORMAT__,aout
+SECTION .text
+%elifidn __OUTPUT_FORMAT__,coff
+SECTION .text
+%elifidn __OUTPUT_FORMAT__,win32
 SECTION .rdata align=%1


x86_update_x86inc.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".


Re: [FFmpeg-devel] [PATCH 1/7] avformat/iamf: Mark symbols as hidden

2024-03-16 Thread Andreas Rheinhardt
Andreas Rheinhardt:
> Avoids .got entries for ff_iamf_scalable_ch_layouts and
> ff_iamf_sound_system_map (whether they would have been
> created otherwise depends upon the compiler and compiler
> options).
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavformat/iamf.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/libavformat/iamf.h b/libavformat/iamf.h
> index d662f6e76b..68f05c635b 100644
> --- a/libavformat/iamf.h
> +++ b/libavformat/iamf.h
> @@ -25,6 +25,7 @@
>  #include 
>  #include 
>  
> +#include "libavutil/attributes_internal.h"
>  #include "libavutil/channel_layout.h"
>  #include "libavutil/iamf.h"
>  #include "libavcodec/codec_id.h"
> @@ -162,6 +163,7 @@ struct IAMFSoundSystemMap {
>  AVChannelLayout layout;
>  };
>  
> +FF_VISIBILITY_PUSH_HIDDEN
>  extern const AVChannelLayout ff_iamf_scalable_ch_layouts[10];
>  extern const struct IAMFSoundSystemMap ff_iamf_sound_system_map[13];
>  
> @@ -195,5 +197,6 @@ static inline IAMFParamDefinition 
> *ff_iamf_get_param_definition(const IAMFContex
>  void ff_iamf_free_audio_element(IAMFAudioElement **paudio_element);
>  void ff_iamf_free_mix_presentation(IAMFMixPresentation **pmix_presentation);
>  void ff_iamf_uninit_context(IAMFContext *c);
> +FF_VISIBILITY_POP_HIDDEN
>  
>  #endif /* AVFORMAT_IAMF_H */

Will apply this patchset tomorrow unless there are objections.

- Andreas

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

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


Re: [FFmpeg-devel] [PATCH] avformat/mxfdec: signal channel layouts using the new channel layout api

2024-03-16 Thread Marton Balint



On Thu, 14 Mar 2024, Tomas Härdin wrote:


fre 2024-03-08 klockan 21:13 +0100 skrev Marton Balint:

Signed-off-by: Marton Balint 
---
 libavformat/mxfdec.c | 129 ++---
--
 1 file changed, 53 insertions(+), 76 deletions(-)


No idea how the new API works, but it's less code which seems nice.

Changing AV_CH_* to AV_CHAN_* seems like needless busywork. But that
has little to do with this patch.

No objections from my end.


Ok, will apply.

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

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


Re: [FFmpeg-devel] Fixes #10509

2024-03-16 Thread Marton Balint



On Sun, 17 Mar 2024, Poorva wrote:


On Mon, Mar 11, 2024 at 1:10 AM Leo Izen  wrote:


On 3/9/24 15:49, Poorva wrote:

I have attached the git patch containing the changes for your review.

This patch is submitted as part of my qualification task for Google Summer
of Code (GSoC)



Your editor appears to have stripped the newline at the end of the file.



diff --git a/libavfilter/f_select.c b/libavfilter/f_select.c
index 9b330a0673..965f5a0b54 100644
--- a/libavfilter/f_select.c
+++ b/libavfilter/f_select.c
@@ -90,6 +90,9 @@ static const char *const var_names[] = {

 "concatdec_select",  ///< frame is within the interval set by the concat 
demuxer

+"ih",///< ih: Represents the height of the input video 
frame.
+"iw",///< iw: Represents the width of the input video 
frame.
+
 NULL
 };

@@ -144,6 +147,9 @@ enum var_name {

 VAR_CONCATDEC_SELECT,

+VAR_IH,
+VAR_IW,
+
 VAR_VARS_NB
 };

@@ -264,6 +270,9 @@ static int config_input(AVFilterLink *inlink)
 select->var_values[VAR_CONSUMED_SAMPLES_N] = NAN;
 select->var_values[VAR_SAMPLES_N]  = NAN;

+select->var_values[VAR_IH] = inlink->h;
+select->var_values[VAR_IW] = inlink->w;


Initial valaues should be NAN. This may well be an audio filter, when 
ih/iw is not available.



+
 select->var_values[VAR_SAMPLE_RATE] =
 inlink->type == AVMEDIA_TYPE_AUDIO ? inlink->sample_rate : NAN;

@@ -371,6 +380,9 @@ FF_ENABLE_DEPRECATION_WARNINGS
 break;
 }

+select->var_values[VAR_IH] = frame->height;
+select->var_values[VAR_IW] = frame->width;


You shold only set these for the VIDEO case.


+
 select->select = res = av_expr_eval(select->expr, select->var_values, 
NULL);
 av_log(inlink->dst, AV_LOG_DEBUG,
"n:%f pts:%f t:%f key:%d",
@@ -546,3 +558,4 @@ const AVFilter ff_vf_select = {
 .flags = AVFILTER_FLAG_DYNAMIC_OUTPUTS | 
AVFILTER_FLAG_METADATA_ONLY,
 };
 #endif /* CONFIG_SELECT_FILTER */
+


Extra added line.


--
2.43.0.windows.1


Documentation update missing.

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

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


Re: [FFmpeg-devel] Fixes #10509

2024-03-16 Thread Poorva
On Mon, Mar 11, 2024 at 1:10 AM Leo Izen  wrote:
>
> On 3/9/24 15:49, Poorva wrote:
> > I have attached the git patch containing the changes for your review.
> >
> > This patch is submitted as part of my qualification task for Google Summer
> > of Code (GSoC)
> >
>
> Your editor appears to have stripped the newline at the end of the file.
>

Thank you for your feedback on the Git patch I submitted for review. I
apologize for the newline issue; it seems my editor removed it
unintentionally.
I have rectified the problem by adding the necessary newline at the
end of the file. The updated patch file is attached for your review.


0001-avfilter-f_select.c-add-support-for-iw-and-ih-consta.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".


Re: [FFmpeg-devel] [PATCH] vvcdec: Mark as experimental

2024-03-16 Thread Nuo Mi
On Fri, Mar 15, 2024 at 11:05 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:

> Frank Plowman:
> > On 15/03/2024 10:22, Kieran Kunhya wrote:
> >> On Thu, 14 Mar 2024, 22:54 Michael Niedermayer,  >
> >> wrote:
> >>
> >>> On Wed, Feb 07, 2024 at 10:55:18PM +, Kieran Kunhya wrote:
>  On Wed, 7 Feb 2024 at 22:06, Paul B Mahol  wrote:
> 
> > On Wed, Feb 7, 2024 at 10:13 PM Kieran Kunhya 
> wrote:
> >
> >> $subj
> >>
> >> As discussed at FOSDEM.
> >>
> >
> > Author of this patch above is forced to FUZZ this decoder until
> > experimental flag is removed.
> >
> 
>  Sure, I will set some fuzzers up over the weekend.
> >>>
> >>> over a month later ...
> >>> has this been done ?
> >>>
> >>>
> >>> thx
> >>>
> >>> [...]
> >>>
> >>
> >> Frank said there was no need as he was doing it himself.
> >>
> >> I do not appreciate your passive aggressive tone.
> >>
> >> Kieran
> >>
> >
> > I have been fuzzing since the end of January.  Various patches have made
> > the decoder much more robust than it was then.  Still getting a crash on
> > occasion, but most are now false positives due to assertion failures
> > rather than segmentation faults or other potential security issues.
> > That being said, the hardware I am using is extremely modest compared to
> > oss-fuzz's.
>
> An assertion failure is not a false positive. Even if it is an av_assert2.
>
Agree, we need to return PATCH_WELCOME for them too.

>
> - Andreas
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@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] vvcdec: Mark as experimental

2024-03-16 Thread Nuo Mi
On Fri, Mar 15, 2024 at 11:01 PM Frank Plowman 
wrote:

> On 15/03/2024 10:22, Kieran Kunhya wrote:
> > On Thu, 14 Mar 2024, 22:54 Michael Niedermayer, 
> > wrote:
> >
> >> On Wed, Feb 07, 2024 at 10:55:18PM +, Kieran Kunhya wrote:
> >>> On Wed, 7 Feb 2024 at 22:06, Paul B Mahol  wrote:
> >>>
>  On Wed, Feb 7, 2024 at 10:13 PM Kieran Kunhya  wrote:
> 
> > $subj
> >
> > As discussed at FOSDEM.
> >
> 
>  Author of this patch above is forced to FUZZ this decoder until
>  experimental flag is removed.
> 
> >>>
> >>> Sure, I will set some fuzzers up over the weekend.
> >>
> >> over a month later ...
> >> has this been done ?
> >>
> >>
> >> thx
> >>
> >> [...]
> >>
> >
> > Frank said there was no need as he was doing it himself.
> >
> > I do not appreciate your passive aggressive tone.
> >
> > Kieran
> >
>
> I have been fuzzing since the end of January.  Various patches have made
> the decoder much more robust than it was then.  Still getting a crash on
> occasion, but most are now false positives due to assertion failures
> rather than segmentation faults or other potential security issues.
> That being said, the hardware I am using is extremely modest compared to
> oss-fuzz's.
>


>
> --
> Frank
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] duplicate symbol '_dec_init' in: fftools/ffmpeg_dec.o

2024-03-16 Thread Christopher Degawa
On Sat, Mar 16, 2024 at 09:08 Gnattu OC via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:

> If you are using Xcode >= 15 then you will need to add `-Wl,-ld_classic`
> to LDFLAGS.  During configure you will also need to set
> `--host-ldflags='-Wl,-ld_classic’`.
>
> > On Mar 16, 2024, at 09:04, Helmut K. C. Tessarek 
> wrote:
> >
> > Hello,
> >
> > It's me again - the dude who compiles ffmpeg for macOS... ;-)
> >
> > I haven't updated the referenced libbluray, but only compiled ffmpeg the
> way I always do. The last time was about 3 days ago and all was good.
> >
> > This is the git hash of ffmpeg I tried to compile: b47abd5737
> >
> > duplicate symbol '_dec_init' in:
> >fftools/ffmpeg_dec.o
> >/Users/Shared/ffmpeg/sw/lib/libbluray.a(libbluray_la-dec.o)
> > ld: 1 duplicate symbol for architecture x86_64
> > clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> >
> > The only code that changed was ffmpeg and libx265, thus I suspect it was
> a change to ffmpeg. I can't really do a git bisect, because this error only
> happens after ffmpeg is compiled at the linker stage, so that would take me
> forever
> >
> > However, the dev who did a change related to this would probably know
> right away.
> >
> > Cheers,
> >  K. C.
> >
> >
> > --
> > regards Helmut K. C. Tessarek  KeyID 0x172380A011EF4944
> > Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944
> >
> > /*
> >   Thou shalt not follow the NULL pointer for chaos and madness
> >   await thee at its end.
> > */
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@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".



Seems the conflict comes from
https://code.videolan.org/videolan/libbluray/-/blob/master/src/libbluray/disc/dec.c?ref_type=heads#L287
 and
https://github.com/FFmpeg/FFmpeg/commit/c4de5778bceab3c15f1239f1f16816749a7fd3b6

Perhaps you could also try asking libbluray if they could use an internal
prefix. Otherwise you might need to do a rename of that function on
ffmpeg's side.
___
ffmpeg-devel mailing list
ffmpeg-devel@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] duplicate symbol '_dec_init' in: fftools/ffmpeg_dec.o

2024-03-16 Thread Gnattu OC via ffmpeg-devel
If you are using Xcode >= 15 then you will need to add `-Wl,-ld_classic` to 
LDFLAGS.  During configure you will also need to set 
`--host-ldflags='-Wl,-ld_classic’`.

> On Mar 16, 2024, at 09:04, Helmut K. C. Tessarek  wrote:
> 
> Hello,
> 
> It's me again - the dude who compiles ffmpeg for macOS... ;-)
> 
> I haven't updated the referenced libbluray, but only compiled ffmpeg the way 
> I always do. The last time was about 3 days ago and all was good.
> 
> This is the git hash of ffmpeg I tried to compile: b47abd5737
> 
> duplicate symbol '_dec_init' in:
>fftools/ffmpeg_dec.o
>/Users/Shared/ffmpeg/sw/lib/libbluray.a(libbluray_la-dec.o)
> ld: 1 duplicate symbol for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> 
> The only code that changed was ffmpeg and libx265, thus I suspect it was a 
> change to ffmpeg. I can't really do a git bisect, because this error only 
> happens after ffmpeg is compiled at the linker stage, so that would take me 
> forever
> 
> However, the dev who did a change related to this would probably know right 
> away.
> 
> Cheers,
>  K. C.
> 
> 
> -- 
> regards Helmut K. C. Tessarek  KeyID 0x172380A011EF4944
> Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944
> 
> /*
>   Thou shalt not follow the NULL pointer for chaos and madness
>   await thee at its end.
> */
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] avformat/mpegtsenc: correct bitstream check

2024-03-16 Thread Gyan Doshi



On 2024-03-16 02:02 pm, Marton Balint wrote:



On Sat, 16 Mar 2024, Gyan Doshi wrote:


8559cce3c3 made the bitstream check generic using a LUT.
However, one of the comparisons which involves a bitwise AND
and equality check is faulty due to operator precedence.

First reported and analysed at
https://github.com/streamlink/streamlink/issues/5876

Fixes #10908
---
libavformat/mpegtsenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 06e88e9879..b8efc535a7 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -2319,7 +2319,7 @@ static int 
mpegts_check_bitstream(AVFormatContext *s, AVStream *st,

    pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 &&
    (AV_RB24(pkt->data) != 0x01 ||
    (st->codecpar->extradata_size > 0 &&
-    (st->codecpar->extradata[0] & e->mask == 
e->value
+    ((st->codecpar->extradata[0] & e->mask) == 
e->value
    return ff_stream_add_bitstream_filter(st, e->bsf_name, 
NULL);

    }
    return 1;
--


LGTM, thanks.


Thanks. Pushed as f5441e441f9b0d235e49bdccc69e141ccd92e854

Regards,
Gyan

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

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


Re: [FFmpeg-devel] [PATCH v3 7/9] avformat/pcm: factorize and improve determining the default packet size

2024-03-16 Thread Marton Balint




On Fri, 15 Mar 2024, Marton Balint wrote:


- Remove the 1024 cap on the number of samples, for high sample rate audio it
 was suboptimal, calculate the low neighbour power of two for the number of
 samples (audio blocks) instead.
- Make the function work correctly also for non-pcm codecs by using the stream
 bitrate to estimate the target packet size. A previous version of this patch
 used av_get_audio_frame_duration2() the estimate the desired packet size, but
 for some codecs that returns the duration of a single audio frame regardless
 of frame_bytes.
- Fallback to 4096/block_align*block_align if bitrate is not available.


Will apply the this and the rest of the series.

Regards,
Marton



Signed-off-by: Marton Balint 
---
libavformat/pcm.c  | 41 ++---
libavformat/pcm.h  |  1 +
tests/ref/seek/lavf-al | 46 +-
tests/ref/seek/lavf-ul | 46 +-
4 files changed, 76 insertions(+), 58 deletions(-)

diff --git a/libavformat/pcm.c b/libavformat/pcm.c
index 9741f73667..9676da3251 100644
--- a/libavformat/pcm.c
+++ b/libavformat/pcm.c
@@ -24,27 +24,44 @@
#include "internal.h"
#include "pcm.h"

-#define RAW_SAMPLES 1024
+#define PCM_DEMUX_TARGET_FPS  25

-int ff_pcm_read_packet(AVFormatContext *s, AVPacket *pkt)
+int ff_pcm_default_packet_size(AVCodecParameters *par)
{
-AVCodecParameters *par = s->streams[0]->codecpar;
-int ret, size;
+int nb_samples, max_samples, bits_per_sample;
+int64_t bitrate;

if (par->block_align <= 0)
return AVERROR(EINVAL);

-/*
- * Compute read size to complete a read every 62ms.
- * Clamp to RAW_SAMPLES if larger.
- */
-size = FFMAX(par->sample_rate/25, 1);
-if (par->block_align <= INT_MAX / RAW_SAMPLES) {
-size = FFMIN(size, RAW_SAMPLES) * par->block_align;
+max_samples = INT_MAX / par->block_align;
+bits_per_sample = av_get_bits_per_sample(par->codec_id);
+bitrate = par->bit_rate;
+
+/* Don't trust the codecpar bitrate if we can calculate it ourselves */
+if (bits_per_sample > 0 && par->sample_rate > 0 && par->ch_layout.nb_channels 
> 0)
+if ((int64_t)par->sample_rate * par->ch_layout.nb_channels < INT64_MAX 
/ bits_per_sample)
+bitrate = bits_per_sample * par->sample_rate * 
par->ch_layout.nb_channels;
+
+if (bitrate > 0) {
+nb_samples = av_clip64(bitrate / 8 / PCM_DEMUX_TARGET_FPS / 
par->block_align, 1, max_samples);
+nb_samples = 1 << av_log2(nb_samples);
} else {
-size = par->block_align;
+/* Fallback to a size based method for a non-pcm codec with unknown 
bitrate */
+nb_samples = av_clip(4096 / par->block_align, 1, max_samples);
}

+return par->block_align * nb_samples;
+}
+
+int ff_pcm_read_packet(AVFormatContext *s, AVPacket *pkt)
+{
+int ret, size;
+
+size = ff_pcm_default_packet_size(s->streams[0]->codecpar);
+if (size < 0)
+return size;
+
ret = av_get_packet(s->pb, pkt, size);

pkt->flags &= ~AV_PKT_FLAG_CORRUPT;
diff --git a/libavformat/pcm.h b/libavformat/pcm.h
index 9af36d5a2e..1928497eed 100644
--- a/libavformat/pcm.h
+++ b/libavformat/pcm.h
@@ -24,6 +24,7 @@

#include "avformat.h"

+int ff_pcm_default_packet_size(AVCodecParameters *par);
int ff_pcm_read_packet(AVFormatContext *s, AVPacket *pkt);
int ff_pcm_read_seek(AVFormatContext *s,
 int stream_index, int64_t timestamp, int flags);
diff --git a/tests/ref/seek/lavf-al b/tests/ref/seek/lavf-al
index 5a4085af4e..ebf7993425 100644
--- a/tests/ref/seek/lavf-al
+++ b/tests/ref/seek/lavf-al
@@ -1,50 +1,50 @@
-ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:  0 size:   
882
+ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:  0 size:   
512
ret: 0 st:-1 flags:0  ts:-1.00
-ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:  0 size:   
882
+ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:  0 size:   
512
ret: 0 st:-1 flags:1  ts: 1.894167
-ret: 0 st: 0 flags:1 dts: 1.894150 pts: 1.894150 pos:  41766 size:   
882
+ret: 0 st: 0 flags:1 dts: 1.894150 pts: 1.894150 pos:  41766 size:   
512
ret: 0 st: 0 flags:0  ts: 0.788345
-ret: 0 st: 0 flags:1 dts: 0.788345 pts: 0.788345 pos:  17383 size:   
882
+ret: 0 st: 0 flags:1 dts: 0.788345 pts: 0.788345 pos:  17383 size:   
512
ret: 0 st: 0 flags:1  ts:-0.317506
-ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:  0 size:   
882
+ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:  0 size:   
512
ret:-1 st:-1 flags:0  ts: 2.576668
ret: 0 st:-1 flags:1  ts: 1.470835
-ret: 0 st: 0 flags:1 dts: 1.470839 pts: 1.470839 pos:  32432 size:   
882
+ret: 0 st: 0 flags:1 dts: 1.470839 pts: 1.470839 pos:  32432 size:   
512
ret: 0 st: 0 flags:0  ts: 0.364989
-ret: 0 

Re: [FFmpeg-devel] [PATCH 1/7] avutil/channel_layout: add AV_CHANNEL_LAYOUT_RETYPE_FLAG_CANONICAL

2024-03-16 Thread Marton Balint




On Sat, 9 Mar 2024, Marton Balint wrote:


Signed-off-by: Marton Balint 
---
doc/APIchanges |  3 +++
libavutil/channel_layout.c | 30 ++
libavutil/channel_layout.h |  7 +++
libavutil/version.h|  2 +-
4 files changed, 41 insertions(+), 1 deletion(-)


Will apply the series.

Regards,
Marton



diff --git a/doc/APIchanges b/doc/APIchanges
index cf58c8c5f0..a44c8e4f10 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,9 @@ The last version increases of all libraries were on 2024-03-07

API changes, most recent first:

+2024-03-xx - xx - lavu 59.2.100 - channel_layout.h
+  Add AV_CHANNEL_LAYOUT_RETYPE_FLAG_CANONICAL.
+
2024-03-08 - xx - lavc 61.1.100 - avcodec.h
  Add AVCodecContext.[nb_]side_data_prefer_packet.

diff --git a/libavutil/channel_layout.c b/libavutil/channel_layout.c
index 8c1b3362f7..d3abb2dc42 100644
--- a/libavutil/channel_layout.c
+++ b/libavutil/channel_layout.c
@@ -553,6 +553,33 @@ static int ambisonic_order(const AVChannelLayout 
*channel_layout)
return order;
}

+static enum AVChannelOrder canonical_order(AVChannelLayout *channel_layout)
+{
+int has_known_channel = 0;
+int order;
+
+if (channel_layout->order != AV_CHANNEL_ORDER_CUSTOM)
+return channel_layout->order;
+
+if (has_channel_names(channel_layout))
+return AV_CHANNEL_ORDER_CUSTOM;
+
+for (int i = 0; i < channel_layout->nb_channels && !has_known_channel; i++)
+if (channel_layout->u.map[i].id != AV_CHAN_UNKNOWN)
+has_known_channel = 1;
+if (!has_known_channel)
+return AV_CHANNEL_ORDER_UNSPEC;
+
+if (masked_description(channel_layout, 0) > 0)
+return AV_CHANNEL_ORDER_NATIVE;
+
+order = ambisonic_order(channel_layout);
+if (order >= 0 && masked_description(channel_layout, (order + 1) * (order + 
1)) >= 0)
+return AV_CHANNEL_ORDER_AMBISONIC;
+
+return AV_CHANNEL_ORDER_CUSTOM;
+}
+
/**
 * If the custom layout is n-th order standard-order ambisonic, with optional
 * extra non-diegetic channels at the end, write its string description in bp.
@@ -892,6 +919,9 @@ int av_channel_layout_retype(AVChannelLayout 
*channel_layout, enum AVChannelOrde
if (!av_channel_layout_check(channel_layout))
return AVERROR(EINVAL);

+if (flags & AV_CHANNEL_LAYOUT_RETYPE_FLAG_CANONICAL)
+order = canonical_order(channel_layout);
+
if (channel_layout->order == order)
return 0;

diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
index 10ffe74468..a1e9b08064 100644
--- a/libavutil/channel_layout.h
+++ b/libavutil/channel_layout.h
@@ -680,6 +680,13 @@ int av_channel_layout_compare(const AVChannelLayout *chl, 
const AVChannelLayout
 */
#define AV_CHANNEL_LAYOUT_RETYPE_FLAG_LOSSLESS (1 << 0)

+/**
+ * The specified retype target order is ignored and the simplest possible
+ * (canonical) order is used for which the input layout can be losslessy
+ * represented.
+ */
+#define AV_CHANNEL_LAYOUT_RETYPE_FLAG_CANONICAL (1 << 1)
+
/**
 * Change the AVChannelOrder of a channel layout.
 *
diff --git a/libavutil/version.h b/libavutil/version.h
index 09f8cdc292..57cad02ec0 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
 */

#define LIBAVUTIL_VERSION_MAJOR  59
-#define LIBAVUTIL_VERSION_MINOR   1
+#define LIBAVUTIL_VERSION_MINOR   2
#define LIBAVUTIL_VERSION_MICRO 100

#define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
--
2.35.3

___
ffmpeg-devel mailing list
ffmpeg-devel@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] avformat/mpegtsenc: correct bitstream check

2024-03-16 Thread Marton Balint




On Sat, 16 Mar 2024, Gyan Doshi wrote:


8559cce3c3 made the bitstream check generic using a LUT.
However, one of the comparisons which involves a bitwise AND
and equality check is faulty due to operator precedence.

First reported and analysed at
https://github.com/streamlink/streamlink/issues/5876

Fixes #10908
---
libavformat/mpegtsenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 06e88e9879..b8efc535a7 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -2319,7 +2319,7 @@ static int mpegts_check_bitstream(AVFormatContext *s, 
AVStream *st,
pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 &&
(AV_RB24(pkt->data) != 0x01 ||
(st->codecpar->extradata_size > 0 &&
-(st->codecpar->extradata[0] & e->mask == e->value
+((st->codecpar->extradata[0] & e->mask) == e->value
return ff_stream_add_bitstream_filter(st, e->bsf_name, NULL);
}
return 1;
--


LGTM, thanks.

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

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


Re: [FFmpeg-devel] [PATCH 1/3] swscale: [LA] Optimize range convert for yuvj420p.

2024-03-16 Thread 陈昊
LGTM

2024-03-16 11:03:31 "yinshiyou...@loongson.cn"  写道:
> ---
>  libswscale/loongarch/swscale.S| 368 ++
>  libswscale/loongarch/swscale_init_loongarch.c |  33 ++
>  libswscale/loongarch/swscale_loongarch.h  |  11 +
>  libswscale/swscale_internal.h |   1 +
>  libswscale/utils.c|   6 +-
>  5 files changed, 418 insertions(+), 1 deletion(-)
> 
> diff --git a/libswscale/loongarch/swscale.S b/libswscale/loongarch/swscale.S
> index aa4c5cbe28..67b1bc834d 100644
> --- a/libswscale/loongarch/swscale.S
> +++ b/libswscale/loongarch/swscale.S
> @@ -1866,3 +1866,371 @@ function ff_hscale_16_to_19_sub_lsx
>  ld.d s8,  sp, 64
>  addi.d   sp,  sp, 72
>  endfunc
> +
> +function lumRangeFromJpeg_lsx
> +li.w  t0,14071
> +li.w  t1,33561947
> +vreplgr2vr.h  vr0,   t0
> +srli.wt2,a1,3
> +andi  t3,a1,7
> +beqz  t2,2f
> +1:
> +vld   vr1,   a0,0
> +vreplgr2vr.w  vr2,   t1
> +vreplgr2vr.w  vr3,   t1
> +vmaddwev.w.h  vr2,   vr0,   vr1
> +vmaddwod.w.h  vr3,   vr0,   vr1
> +vsrai.w   vr2,   vr2,   14
> +vsrai.w   vr3,   vr3,   14
> +vpackev.h vr1,   vr3,   vr2
> +vst   vr1,   a0,0
> +addi.da0,a0,16
> +addi.dt2,t2,-1
> +bnez  t2,1b
> +2:
> +beqz  t3,4f
> +3:
> +ld.h  t4,a0,0
> +mul.w t4,t4,t0
> +add.w t4,t4,t1
> +srai.wt4,t4,14
> +st.h  t4,a0,0
> +addi.da0,a0,2
> +addi.dt3,t3,-1
> +bnez  t3,3b
> +4:
> +endfunc
> +
> +function lumRangeFromJpeg_lasx
> +li.w   t0,14071
> +li.w   t1,33561947
> +xvreplgr2vr.h  xr0,   t0
> +srli.w t2,a1,4
> +andi   t3,a1,15
> +beqz   t2,2f
> +1:
> +xvld   xr1,   a0,0
> +xvreplgr2vr.w  xr2,   t1
> +xvreplgr2vr.w  xr3,   t1
> +xvmaddwev.w.h  xr2,   xr0,   xr1
> +xvmaddwod.w.h  xr3,   xr0,   xr1
> +xvsrai.w   xr2,   xr2,   14
> +xvsrai.w   xr3,   xr3,   14
> +xvpackev.h xr1,   xr3,   xr2
> +xvst   xr1,   a0,0
> +addi.d a0,a0,32
> +addi.d t2,t2,-1
> +bnez   t2,1b
> +2:
> +beqz  t3,4f
> +3:
> +ld.h  t4,a0,0
> +mul.w t4,t4,t0
> +add.w t4,t4,t1
> +srai.wt4,t4,14
> +st.h  t4,a0,0
> +addi.da0,a0,2
> +addi.dt3,t3,-1
> +bnez  t3,3b
> +4:
> +endfunc
> +
> +function lumRangeToJpeg_lsx
> +li.w  t0,19077
> +li.w  t1,-39057361
> +li.w  t2,30189
> +vreplgr2vr.h  vr0,   t0
> +vreplgr2vr.h  vr4,   t2
> +srli.wt2,a1,3
> +andi  t3,a1,7
> +beqz  t2,2f
> +1:
> +vld   vr1,   a0,0
> +vreplgr2vr.w  vr2,   t1
> +vreplgr2vr.w  vr3,   t1
> +vmin.hvr1,   vr1,   vr4
> +vmaddwev.w.h  vr2,   vr0,   vr1
> +vmaddwod.w.h  vr3,   vr0,   vr1
> +vsrai.w   vr2,   vr2,   14
> +vsrai.w   vr3,   vr3,   14
> +vpackev.h vr1,   vr3,   vr2
> +vst   vr1,   a0,0
> +addi.da0,a0,16
> +addi.dt2,t2,-1
> +bnez  t2,1b
> +2:
> +beqz  t3,4f
> +3:
> +ld.h  t4,a0,0
> +vreplgr2vr.h  vr1,   t4
> +vmin.hvr1,   vr1,   vr4
> +vpickve2gr.h  t4,vr1,   0
> +mul.w t4,t4,t0
> +add.w t4,t4,t1
> +srai.wt4,t4,14
> +st.h  t4,a0,0
> +addi.da0,a0,2
> +addi.dt3,t3,-1
> +bnez  t3,3b
> +4:
> +endfunc
> +
> +function lumRangeToJpeg_lasx
> +li.w   t0,19077
> +li.w   t1,-39057361
> +li.w   t2,30189
> +xvreplgr2vr.h  xr0,   t0
> +xvreplgr2vr.h  xr4,   t2
> +srli.w t2,a1,4
> +andi   t3,a1,15
> +beqz   t2,2f
> +1:
> +xvld   xr1,   a0,0
> +xvreplgr2vr.w  xr2,   t1
> +xvreplgr2vr.w  xr3,   t1
> +xvmin.hxr1,   xr1,   xr4
> +xvmaddwev.w.h  xr2,   xr0,   xr1
> +xvmaddwod.w.h  xr3,   xr0,   xr1
> +xvsrai.w   xr2,   xr2,   14
> +xvsrai.w   xr3,   xr3,   14
> +xvpackev.h xr1,   xr3,   xr2
> +xvst   xr1,   a0,0
> +addi.d a0,a0,32
> +addi.d t2,t2,-1
> +bnez   t2,1b
> +2:
> +beqz   t3,4f
> +3:
> +ld.h