Re: [FFmpeg-devel] 7.0 Name

2024-04-01 Thread AV Preservation by reto.ch (lists)
Sean McGovern wrote:

>Not sure if I am allowed to pick, my choice is Dijkstra.

When I started programming in 1975, Edsger W. Dijkstra was one of my heroes, 
which is why I support your proposal, even though I am not an FFmpeg developer.

Best regards, Reto
___
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] FFmpeg TC input needed

2024-04-01 Thread Gyan Doshi

Ping.

As the TC rules matter has been concluded, this should go ahead.

Regards,
Gyan


On 2024-02-17 05:15 pm, Gyan Doshi wrote:

Issue:

Patch: avcodec/s302m: enable non-PCM decoding
URL: 
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20240127103854.9971-1-ffm...@gyani.pro/


The issue needing resolution is whether the patch should be added to 
the existing s302m decoder or should that decoder
be removed and all old and new patched features inlined into the 
mpeg-ts demuxer.


Summary:

SMPTE ST 302 specifies for carriage of LPCM media in MPEG-TS. SMPTE ST 
337 enables this for non-PCM codecs. The payload
has a custom layout so it can't be directly processed hence lavc/s302m 
decodes the packet data to yield LPCM media. But
it can only deal at present with LPCM payloads, meaning that non-PCM 
payloads need to be exported to a raw bytestream
format and then decoded in a 2nd step, which prohibits direct 
transcoding of live/streaming inputs. This patch corrects
the identification process for non-PCM payloads, reformats the payload 
and then carries out in-place decoding by calling

a nested decoder similar to the ftr or imm5 decoders in lavc.

In the v1 patch review, Andreas, in response to the proposed doc entry 
describing the feature capability of multiple
or differing payloads in a s302m stream, suggested[1] that s302m 
should be a bitstream filter instead, but I did not
see that as an actionable suggestion as he immediately listed the bsf 
limitations preventing the possibility. I also
had not seen an actual sample of s302m with multiple embedded streams. 
Kieran also observed[2] that he had not seen
such a stream in the wild. So the added features of this patch, 
wherever they are ultimately located, shall not yield
more than one media stream. Anton suggested[3] that the decoder should 
instead be a demuxer. I saw no other objections

to the architecture of the patch.

I posted the v2 patch, incorporating some changes suggested by 
Andreas, 4 days later. This had gone uncommented for
over two weeks when I posted a notice stating an intention to push. 
Anton posted[4] a new objection that "If it
dynamically generates nested decoders, then it's not a proper codec in 
our model". This new objection is not connected
to multiple streams but only to a codec 'model' that I don't see 
described anywhere and which contradicts the
implementations of multiple decoders with a nested decoder, including 
the ftr and imm5 decoders, which are most similar
in design to the patched s302m decoder. Anton later on mentioned[5] 
that nested decoders are "a constant source of
issues". However, I didn't find anything on trac reporting an issue 
with the nested decoders of ftr and imm5 nor
anything on ffmpeg-devel-ml or ffmpeg-user-ml. Nothing in their commit 
history either points to architectural bugs.
These decoders have been around for 6 years among themselves. The 
testing of the patched s302m decoder over the past
month by myself, an OTT provider and others shows no issues either. 
Finally, Anton speculates[6] that the burden of
fixes will likely fall upon him. In none of his objections, till the 
time of writing, did I see specific concerns with

the patch.

There are some limitations in shifting this decoder wholesale to 
inside the MPEG-TS demuxer. A s302m stream may contain
some non-media payload accompanying non-PCM media i.e. S-ADM metadata. 
At present, I have neither the samples nor the
specification needed in order to locate and extract or parse this 
metadata. Formatting the payload data inside the
demuxer will lead to irrevocable loss of such metadata if present. 
However, a decoder patch allows simultaneuous output
of both a decoded stream alongside a copied stream. The end-user can 
then do with the raw data whatever they wish.


Ultimately, s302m is specified an an elementary stream inside a 
MPEG-TS container. Its internal handling is better left
to a dedicated module like a decoder. A bitstream filter might be a 
better fit if s302m streams with multiple media
payloads ever start appearing - none have, so far - but for single 
media payloads, a decoder remains the best place.


Regards,
Gyan

[1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-January/320119.html
[2]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-January/320321.html
[3]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-January/320258.html
[4]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-February/321514.html
[5]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-February/321523.html
[6]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-February/321539.html

___
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

[FFmpeg-devel] [PATCH v11 6/6] doc/indevs: update CC extraction example to use RCWT muxer

2024-04-01 Thread Marth64
Signed-off-by: Marth64 
---
 doc/indevs.texi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/indevs.texi b/doc/indevs.texi
index d1b2bacf8b..734fc65752 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -1069,9 +1069,9 @@ ffplay -f lavfi 
"movie=test.avi[out0];amovie=test.wav[out1]"
 @end example
 
 @item
-Dump decoded frames to images and closed captions to a file (experimental):
+Dump decoded frames to images and Closed Captions to an RCWT backup:
 @example
-ffmpeg -f lavfi -i "movie=test.ts[out0+subcc]" -map v frame%08d.png -map s -c 
copy -f rawvideo subcc.bin
+ffmpeg -f lavfi -i "movie=test.ts[out0+subcc]" -map v frame%08d.png -map s -c 
copy -f rcwt subcc.bin
 @end example
 
 @end itemize
-- 
2.34.1

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

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


[FFmpeg-devel] [PATCH v11 5/6] doc/muxers: refresh the RCWT muxer's doc to be consistent with the demuxer

2024-04-01 Thread Marth64
Signed-off-by: Marth64 
---
 doc/muxers.texi | 29 +++--
 1 file changed, 19 insertions(+), 10 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index a10a8e216f..c960af1bdc 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -3038,19 +3038,18 @@ ogg files can be safely chained.
 
 @end table
 
-@anchor{rcwt}
+@anchor{rcwtenc}
 @section rcwt
 
-Raw Captions With Time (RCWT) is a format native to ccextractor, a commonly
-used open source tool for processing 608/708 closed caption (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.
+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 extracted CC bitstream and to produce
+a source file for later processing or conversion. The format allows
+for interoperability between ccextractor and FFmpeg, is simple to parse,
+and can be used to create a backup of the CC presentation.
 
-This muxer implements the specification as of 2024-01-05, which has
-been stable and unchanged for 10 years as of this writing.
+This muxer implements the specification as of March 2024, which has
+been stable and unchanged since April 2014.
 
 This muxer will have some nuances from the way that ccextractor muxes RCWT.
 No compatibility issues when processing the output with ccextractor
@@ -3060,6 +3059,16 @@ and outputs will not be a bit-exact match.
 A free specification of RCWT can be found here:
 
@url{https://github.com/CCExtractor/ccextractor/blob/master/docs/BINARY_FILE_FORMAT.TXT}
 
+@subsection Examples
+
+@itemize
+@item
+Extract Closed Captions to RCWT using lavfi:
+@example
+ffmpeg -f lavfi -i "movie=INPUT.mkv[out+subcc]" -map 0:s:0 -c:s copy -f rcwt 
CC.rcwt.bin
+@end example
+@end itemize
+
 @anchor{segment}
 @section segment, stream_segment, ssegment
 
-- 
2.34.1

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

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


[FFmpeg-devel] [PATCH v11 4/6] avformat/rcwtenc: remove repeated documentation

2024-04-01 Thread Marth64
The high level summary of RCWT can be delegated doc/muxers, which
makes it easier to maintain and more consistent with the documentation
of the demuxer.

Signed-off-by: Marth64 
---
 libavformat/rcwtenc.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/libavformat/rcwtenc.c b/libavformat/rcwtenc.c
index ed613d45f5..270154b701 100644
--- a/libavformat/rcwtenc.c
+++ b/libavformat/rcwtenc.c
@@ -21,11 +21,6 @@
 /*
  * 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 muxer implements the specification as of March 2024, which has
  * been stable and unchanged since April 2014.
-- 
2.34.1

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

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


[FFmpeg-devel] [PATCH v11 3/6] avformat/rcwtenc: don't assume .bin extension

2024-04-01 Thread Marth64
Signed-off-by: Marth64 
---
 libavformat/rcwtenc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/libavformat/rcwtenc.c b/libavformat/rcwtenc.c
index f2459ef1d3..ed613d45f5 100644
--- a/libavformat/rcwtenc.c
+++ b/libavformat/rcwtenc.c
@@ -159,7 +159,6 @@ static int rcwt_write_trailer(AVFormatContext *avf)
 const FFOutputFormat ff_rcwt_muxer = {
 .p.name = "rcwt",
 .p.long_name= NULL_IF_CONFIG_SMALL("RCWT (Raw Captions With 
Time)"),
-.p.extensions   = "bin",
 .p.flags= AVFMT_GLOBALHEADER | AVFMT_VARIABLE_FPS | 
AVFMT_TS_NONSTRICT,
 .p.video_codec  = AV_CODEC_ID_NONE,
 .p.audio_codec  = AV_CODEC_ID_NONE,
-- 
2.34.1

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

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


[FFmpeg-devel] [PATCH v11 2/6] avformat/rcwtdec: add RCWT Closed Captions demuxer

2024-04-01 Thread Marth64
RCWT (Raw Captions With Time) is a format native to ccextractor,
a commonly used OSS tool for processing 608/708 Closed Captions (CC).
RCWT can be used to archive the original extracted 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 interop
with ccextractor (which produces RCWT). Using the muxer/demuxer combo,
the CC bits can be kept for processing or rendering with either tool.
This can be an effective way to backup an original CC stream, including
format extensions like EIA-708 and overall original presentation.

Signed-off-by: Marth64 
---
 doc/demuxers.texi|  30 ++
 libavformat/Makefile |   1 +
 libavformat/allformats.c |   1 +
 libavformat/rcwtdec.c| 122 +++
 4 files changed, 154 insertions(+)
 create mode 100644 libavformat/rcwtdec.c

diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index b70f3a38d7..04293c4813 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -1038,6 +1038,36 @@ the command:
 ffplay -f rawvideo -pixel_format rgb24 -video_size 320x240 -framerate 10 
input.raw
 @end example
 
+@anchor{rcwtdec}
+@section rcwt
+
+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.
+For more information on the format, see @ref{rcwtenc,,,ffmpeg-formats}.
+
+This demuxer implements the specification as of March 2024, which has
+been stable and unchanged since April 2014.
+
+@subsection Examples
+
+@itemize
+@item
+Render CC to ASS using the built-in decoder:
+@example
+ffmpeg -i CC.rcwt.bin CC.ass
+@end example
+Note that if your output appears to be empty, you may have to manually
+set the decoder's @option{data_field} option to pick the desired CC substream.
+
+@item
+Convert an RCWT backup to Scenarist (SCC) format:
+@example
+ffmpeg -i CC.rcwt.bin -c:s copy CC.scc
+@end example
+Note that the SCC format does not support all of the possible CC extensions
+that can be stored in RCWT (such as EIA-708).
+@end itemize
+
 @section sbg
 
 SBaGen script demuxer.
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 44aa485029..5d77cba7f1 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 9df42bb87a..ae925dcf60 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..f6a007cbdb
--- /dev/null
+++ b/libavformat/rcwtdec.c
@@ -0,0 +1,122 @@
+/*
+ * 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.
+ *
+ * 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_HEADER_SIZE11
+
+typedef 

[FFmpeg-devel] [PATCH v11 1/6] avformat/subtitles: extend ff_subtitles_queue_insert() to support not yet available events

2024-04-01 Thread Marth64
If ff_subtitles_queue_insert() were given a NULL buffer
with 0 length, it would still attempt to grow the packet
or memcpy depending on if merge option is enabled.

In this commit, allow passing a NULL buffer with 0 length
without attempting to do such operations. This way, if a
subtitle demuxer happens to pass an empty cue or wants to
use av_get_packet() to read bytes, there are no unnecessary
operations on the packet after it is allocated.

Signed-off-by: Marth64 
---
 libavformat/subtitles.c | 23 +++
 libavformat/subtitles.h |  2 +-
 2 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/libavformat/subtitles.c b/libavformat/subtitles.c
index d7723c497f..69e4df88a3 100644
--- a/libavformat/subtitles.c
+++ b/libavformat/subtitles.c
@@ -21,6 +21,7 @@
 #include "avformat.h"
 #include "subtitles.h"
 #include "avio_internal.h"
+#include "libavutil/avassert.h"
 #include "libavutil/avstring.h"
 #include "libavutil/mem.h"
 
@@ -112,15 +113,19 @@ AVPacket *ff_subtitles_queue_insert(FFDemuxSubtitlesQueue 
*q,
 {
 AVPacket **subs, *sub;
 
+av_assert1(event || len == 0);
+
 if (merge && q->nb_subs > 0) {
 /* merge with previous event */
 
 int old_len;
 sub = q->subs[q->nb_subs - 1];
 old_len = sub->size;
-if (av_grow_packet(sub, len) < 0)
-return NULL;
-memcpy(sub->data + old_len, event, len);
+if (event) {
+if (av_grow_packet(sub, len) < 0)
+return NULL;
+memcpy(sub->data + old_len, event, len);
+}
 } else {
 /* new event */
 
@@ -134,14 +139,16 @@ AVPacket *ff_subtitles_queue_insert(FFDemuxSubtitlesQueue 
*q,
 sub = av_packet_alloc();
 if (!sub)
 return NULL;
-if (av_new_packet(sub, len) < 0) {
-av_packet_free();
-return NULL;
+if (event) {
+if (av_new_packet(sub, len) < 0) {
+av_packet_free();
+return NULL;
+}
+memcpy(sub->data, event, len);
 }
-subs[q->nb_subs++] = sub;
 sub->flags |= AV_PKT_FLAG_KEY;
 sub->pts = sub->dts = 0;
-memcpy(sub->data, event, len);
+subs[q->nb_subs++] = sub;
 }
 return sub;
 }
diff --git a/libavformat/subtitles.h b/libavformat/subtitles.h
index 88665663c5..ad6b96ca6a 100644
--- a/libavformat/subtitles.h
+++ b/libavformat/subtitles.h
@@ -112,7 +112,7 @@ typedef struct {
 /**
  * Insert a new subtitle event.
  *
- * @param event the subtitle line, may not be zero terminated
+ * @param event the subtitle line (not zero terminated) or NULL on not yet 
available event
  * @param len   the length of the event (in strlen() sense, so without '\0')
  * @param merge set to 1 if the current event should be concatenated with the
  *  previous one instead of adding a new entry, 0 otherwise
-- 
2.34.1

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

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


[FFmpeg-devel] [PATCH v11 0/6] RCWT Closed Captions demuxer (v11)

2024-04-01 Thread Marth64
Since v9:
* Removes .bin extension association in demuxer and muxer
* Updates examples in documentation

Signed-off-by: Marth64 
-- 
2.34.1

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

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


Re: [FFmpeg-devel] [PATCH v3 2/2] lavc/vaapi_encode_h265: Set general_*_constriaint flags with profile

2024-04-01 Thread Wang, Fei W
On Mon, 2024-04-01 at 21:02 +0100, Mark Thompson wrote:
> On 20/03/2024 08:44, Wang, Fei W wrote:
> > On Mon, 2024-03-18 at 21:22 +, Mark Thompson wrote:
> > > On 18/03/2024 04:21, fei.w.wang-at-intel@ffmpeg.org wrote:
> > > > From: Fei Wang 
> > > > 
> > > > According to Table A.2 in spec.
> > > > 
> > > > Signed-off-by: Fei Wang 
> > > > ---
> > > >libavcodec/vaapi_encode_h265.c | 176
> > > > +++-
> > > > -
> > > >1 file changed, 123 insertions(+), 53 deletions(-)
> > > > 
> > > > diff --git a/libavcodec/vaapi_encode_h265.c
> > > > b/libavcodec/vaapi_encode_h265.c
> > > > index 43755e2188..5ed317ce11 100644
> > > > --- a/libavcodec/vaapi_encode_h265.c
> > > > +++ b/libavcodec/vaapi_encode_h265.c
> > > > @@ -258,6 +258,124 @@ fail:
> > > >return err;
> > > >}
> > > >
> > > > +static int vaapi_encode_h265_init_ptl(AVCodecContext *avctx)
> > > > +{
> > > > +VAAPIEncodeContext  *ctx = avctx->priv_data;
> > > > +VAAPIEncodeH265Context *priv = avctx->priv_data;
> > > > +H265RawVPS  *vps = >raw_vps;
> > > > +H265RawProfileTierLevel *ptl = >profile_tier_level;
> > > > +
> > > > +ptl->general_profile_space = 0;
> > > > +ptl->general_profile_idc   = avctx->profile;
> > > > +ptl->general_tier_flag = priv->tier;
> > > > +
> > > > +ptl->general_profile_compatibility_flag[ptl-
> > > > > general_profile_idc] = 1;
> > > > +
> > > > +if (ptl->general_profile_compatibility_flag[1])
> > > > +ptl->general_profile_compatibility_flag[2] = 1;
> > > > +if (ptl->general_profile_compatibility_flag[3]) {
> > > > +ptl->general_profile_compatibility_flag[1] = 1;
> > > > +ptl->general_profile_compatibility_flag[2] = 1;
> > > > +}
> > > > +
> > > > +ptl->general_progressive_source_flag= 1;
> > > > +ptl->general_interlaced_source_flag = 0;
> > > > +ptl->general_non_packed_constraint_flag = 1;
> > > > +ptl->general_frame_only_constraint_flag = 1;
> > > > +
> > > > +if (avctx->profile >= 4) {
> > > > +ptl->general_intra_constraint_flag= ctx-
> > > > > gop_size == 1;
> > > > +ptl->general_one_picture_only_constraint_flag = 0;
> > > > +ptl->general_lower_bit_rate_constraint_flag   = 1;
> > > > +ptl->general_max_14bit_constraint_flag= 0;
> > > > +
> > > > +switch (ctx->va_profile) {
> > > > +#if VA_CHECK_VERSION(1, 2, 0)
> > > > +case VAProfileHEVCMain12:
> > > > +// Main 12
> > > > +ptl->general_max_12bit_constraint_flag  = 1;
> > > > +ptl->general_max_10bit_constraint_flag  = 0;
> > > > +ptl->general_max_8bit_constraint_flag   = 0;
> > > > +ptl->general_max_422chroma_constraint_flag  = 1;
> > > > +ptl->general_max_420chroma_constraint_flag  = 1;
> > > > +ptl->general_max_monochrome_constraint_flag = 0;
> > > > +break;
> > > > +case VAProfileHEVCMain422_10:
> > > > +// Main 4:2:2 10
> > > > +ptl->general_max_12bit_constraint_flag  = 1;
> > > > +ptl->general_max_10bit_constraint_flag  = 1;
> > > > +ptl->general_max_8bit_constraint_flag   = 0;
> > > > +ptl->general_max_422chroma_constraint_flag  = 1;
> > > > +ptl->general_max_420chroma_constraint_flag  = 0;
> > > > +ptl->general_max_monochrome_constraint_flag = 0;
> > > > +break;
> > > > +case VAProfileHEVCMain422_12:
> > > > +// Main 4:2:2 12
> > > > +ptl->general_max_12bit_constraint_flag  = 1;
> > > > +ptl->general_max_10bit_constraint_flag  = 0;
> > > > +ptl->general_max_8bit_constraint_flag   = 0;
> > > > +ptl->general_max_422chroma_constraint_flag  = 1;
> > > > +ptl->general_max_420chroma_constraint_flag  = 0;
> > > > +ptl->general_max_monochrome_constraint_flag = 0;
> > > > +break;
> > > > +case VAProfileHEVCMain444:
> > > > +// Main 4:4:4
> > > > +ptl->general_max_12bit_constraint_flag  = 1;
> > > > +ptl->general_max_10bit_constraint_flag  = 1;
> > > > +ptl->general_max_8bit_constraint_flag   = 1;
> > > > +ptl->general_max_422chroma_constraint_flag  = 0;
> > > > +ptl->general_max_420chroma_constraint_flag  = 0;
> > > > +ptl->general_max_monochrome_constraint_flag = 0;
> > > > +break;
> > > > +case VAProfileHEVCMain444_10:
> > > > +// Main 4:4:4 10
> > > > +ptl->general_max_12bit_constraint_flag  = 1;
> > > > +ptl->general_max_10bit_constraint_flag  = 1;
> > > > +ptl->general_max_8bit_constraint_flag   = 0;
> > > > +ptl->general_max_422chroma_constraint_flag  = 0;
> > > > +

Re: [FFmpeg-devel] [PATCH v10 2/5] avformat/rcwtdec: add RCWT Closed Captions demuxer

2024-04-01 Thread Marth64
Sorry for the delay, v11 coming shortly with the fix.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


Re: [FFmpeg-devel] [PATCH 3/3] avformat/mov: fix the entry count overflow check in the keys atom

2024-04-01 Thread Andreas Rheinhardt
James Almer:
> Signed-off-by: James Almer 
> ---
>  libavformat/mov.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index a935ef7326..9fca402896 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -5025,7 +5025,7 @@ static int mov_read_keys(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
>  avio_skip(pb, 4);
>  count = avio_rb32(pb);
>  atom.size -= 8;
> -if (count > UINT_MAX / sizeof(*c->meta_keys) - 1) {
> +if (count + 1LL > UINT_MAX / sizeof(*c->meta_keys)) {
>  av_log(c->fc, AV_LOG_ERROR,
> "The 'keys' atom with the invalid key count: %"PRIu32"\n", 
> count);
>  return AVERROR_INVALIDDATA;

What is supposed to be wrong here in the first place? The only thing I
can think of is the case in which sizeof(*c->meta_keys) is > UINT_MAX,
in which case the rhs would wrap around. But I don't think that is what
you meant given that sizeof(*c->meta_keys) == sizeof(char*).
Anyway, a simpler check that works even if sizeof(*c->meta_keys) were
insanely large is "count >= UINT_MAX / sizeof(*c->meta_keys)".

- 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] mov demuxer: Check if a key is longer than the atom containing it

2024-04-01 Thread James Almer

On 4/1/2024 11:28 PM, Eugene Zemtsov via ffmpeg-devel wrote:

From: Eugene Zemtsov 

Stop reading keys and return AVERROR_INVALIDDATA if key_size
is larger than the amount of space left in the atom.

Bug: https://crbug.com/41496983
Signed-off-by: Eugene Zemtsov 
---
  libavformat/mov.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 662301bf67..2d92e7963b 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -5048,12 +5048,13 @@ static int mov_read_keys(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
  for (i = 1; i <= count; ++i) {
  uint32_t key_size = avio_rb32(pb);
  uint32_t type = avio_rl32(pb);
-if (key_size < 8) {
+if (key_size < 8 || key_size > atom.size) {
  av_log(c->fc, AV_LOG_ERROR,
 "The key# %"PRIu32" in meta has invalid size:"
 "%"PRIu32"\n", i, key_size);
  return AVERROR_INVALIDDATA;
  }
+atom.size -= key_size;
  key_size -= 8;
  if (type != MKTAG('m','d','t','a')) {
  avio_skip(pb, key_size);


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

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


[FFmpeg-devel] [PATCH 3/3] avformat/mov: fix the entry count overflow check in the keys atom

2024-04-01 Thread James Almer
Signed-off-by: James Almer 
---
 libavformat/mov.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index a935ef7326..9fca402896 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -5025,7 +5025,7 @@ static int mov_read_keys(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 avio_skip(pb, 4);
 count = avio_rb32(pb);
 atom.size -= 8;
-if (count > UINT_MAX / sizeof(*c->meta_keys) - 1) {
+if (count + 1LL > UINT_MAX / sizeof(*c->meta_keys)) {
 av_log(c->fc, AV_LOG_ERROR,
"The 'keys' atom with the invalid key count: %"PRIu32"\n", 
count);
 return AVERROR_INVALIDDATA;
-- 
2.44.0

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

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


[FFmpeg-devel] [PATCH 2/3] avformat/mov: don't read key_size bytes twice in the keys atom

2024-04-01 Thread James Almer
We only support mdta as type, yet we were not skipping other types,
but rather reading key_size worth of bytes twice per entry.

Signed-off-by: James Almer 
---
 libavformat/mov.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 3273e2e89b..a935ef7326 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -5049,6 +5049,7 @@ static int mov_read_keys(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 key_size -= 8;
 if (type != MKTAG('m','d','t','a')) {
 avio_skip(pb, key_size);
+continue;
 }
 c->meta_keys[i] = av_mallocz(key_size + 1);
 if (!c->meta_keys[i])
-- 
2.44.0

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

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


[FFmpeg-devel] [PATCH 1/3] avformat/mov: take into account the first eight bytes in the keys atom

2024-04-01 Thread James Almer
Signed-off-by: James Almer 
---
 libavformat/mov.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 2b7ddc516c..3273e2e89b 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -5024,6 +5024,7 @@ static int mov_read_keys(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 
 avio_skip(pb, 4);
 count = avio_rb32(pb);
+atom.size -= 8;
 if (count > UINT_MAX / sizeof(*c->meta_keys) - 1) {
 av_log(c->fc, AV_LOG_ERROR,
"The 'keys' atom with the invalid key count: %"PRIu32"\n", 
count);
-- 
2.44.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 v1] lavfi/dnn_backend_torch: Include mem.h

2024-04-01 Thread fei . w . wang-at-intel . com
From: Fei Wang 

Fix build fail since 790f793844.

Signed-off-by: Fei Wang 
---
 libavfilter/dnn/dnn_backend_torch.cpp | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavfilter/dnn/dnn_backend_torch.cpp 
b/libavfilter/dnn/dnn_backend_torch.cpp
index fa9a2e6d99..ae55893a50 100644
--- a/libavfilter/dnn/dnn_backend_torch.cpp
+++ b/libavfilter/dnn/dnn_backend_torch.cpp
@@ -31,6 +31,7 @@ extern "C" {
 #include "dnn_io_proc.h"
 #include "dnn_backend_common.h"
 #include "libavutil/opt.h"
+#include "libavutil/mem.h"
 #include "queue.h"
 #include "safe_queue.h"
 }
-- 
2.25.1

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

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


Re: [FFmpeg-devel] [PATCH 1/3] avcodec/vvc/vvcdec: Do not submit frames without VVCFrameThread

2024-04-01 Thread Nuo Mi
On Tue, Apr 2, 2024 at 1:06 AM Michael Niedermayer 
wrote:

> On Fri, Jan 26, 2024 at 10:46:49PM +0100, Michael Niedermayer wrote:
> > Such frames will crash when pthread functions are called on the NULL
> pointer
> >
> > Fixes: member access within null pointer of type 'VVCFrameThread' (aka
> 'struct VVCFrameThread')
> > Fixes:
> 65160/clusterfuzz-testcase-minimized-ffmpeg_BSF_VVC_METADATA_fuzzer-4665241535119360
> (partly)
> > Fixes:
> 65636/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VVC_fuzzer-5394745824182272
> >
> > Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/vvc/vvcdec.c | 3 +++
> >  1 file changed, 3 insertions(+)
>
> will apply
>
sure, please

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> If you think the mosad wants you dead since a long time then you are either
> wrong or dead since a long time.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


[FFmpeg-devel] [PATCH] mov demuxer: Check if a key is longer than the atom containing it

2024-04-01 Thread Eugene Zemtsov via ffmpeg-devel
From: Eugene Zemtsov 

Stop reading keys and return AVERROR_INVALIDDATA if key_size
is larger than the amount of space left in the atom.

Bug: https://crbug.com/41496983
Signed-off-by: Eugene Zemtsov 
---
 libavformat/mov.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 662301bf67..2d92e7963b 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -5048,12 +5048,13 @@ static int mov_read_keys(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
 for (i = 1; i <= count; ++i) {
 uint32_t key_size = avio_rb32(pb);
 uint32_t type = avio_rl32(pb);
-if (key_size < 8) {
+if (key_size < 8 || key_size > atom.size) {
 av_log(c->fc, AV_LOG_ERROR,
"The key# %"PRIu32" in meta has invalid size:"
"%"PRIu32"\n", i, key_size);
 return AVERROR_INVALIDDATA;
 }
+atom.size -= key_size;
 key_size -= 8;
 if (type != MKTAG('m','d','t','a')) {
 avio_skip(pb, key_size);
-- 
2.44.0.478.gd926399ef9-goog

___
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] mov demuxer: Check if a key is longer than the atom containing it

2024-04-01 Thread Eugene Zemtsov via ffmpeg-devel
Thanks for the comments. I got rid of bytes_left_in_atom.

___
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] fate/libswscale: Disable ffmpeg-dependent tests without ffmpeg

2024-04-01 Thread Andreas Rheinhardt
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt 
> ---
>  tests/fate/libswscale.mak | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/tests/fate/libswscale.mak b/tests/fate/libswscale.mak
> index f8572f9c37..4c29220e6f 100644
> --- a/tests/fate/libswscale.mak
> +++ b/tests/fate/libswscale.mak
> @@ -17,17 +17,15 @@ $(SWS_SLICE_TEST-yes): tools/scale_slice_test$(EXESUF)
>  $(SWS_SLICE_TEST-yes): REF = /dev/null
>  FATE_LIBSWSCALE_SAMPLES += $(SWS_SLICE_TEST-yes)
>  
> -FATE_LIBSWSCALE-$(CONFIG_RAWVIDEO_DEMUXER) += fate-sws-yuv-colorspace
> +FATE_LIBSWSCALE_FFMPEG-$(call FRAMECRC, RAWVIDEO, RAWVIDEO, SCALE_FILTER) += 
> fate-sws-yuv-colorspace \
> + 
> fate-sws-yuv-range
>  fate-sws-yuv-colorspace: tests/data/vsynth1.yuv
> -fate-sws-yuv-colorspace: ffmpeg$(PROGSSUF)$(EXESUF)
>  fate-sws-yuv-colorspace: CMD = framecrc \
>-f rawvideo -s 352x288 -pix_fmt yuv420p -i 
> $(TARGET_PATH)/tests/data/vsynth1.yuv \
>-frames 1 \
>-vf 
> scale=in_color_matrix=bt709:in_range=limited:out_color_matrix=bt601:out_range=full:flags=+accurate_rnd+bitexact
>  
> -FATE_LIBSWSCALE-$(CONFIG_RAWVIDEO_DEMUXER) += fate-sws-yuv-range
>  fate-sws-yuv-range: tests/data/vsynth1.yuv
> -fate-sws-yuv-range: ffmpeg$(PROGSSUF)$(EXESUF)
>  fate-sws-yuv-range: CMD = framecrc \
>-f rawvideo -s 352x288 -pix_fmt yuv420p -i 
> $(TARGET_PATH)/tests/data/vsynth1.yuv \
>-frames 1 \
> @@ -36,5 +34,6 @@ fate-sws-yuv-range: CMD = framecrc \
>  FATE_LIBSWSCALE += $(FATE_LIBSWSCALE-yes)
>  FATE_LIBSWSCALE_SAMPLES += $(FATE_LIBSWSCALE_SAMPLES-yes)
>  FATE-$(CONFIG_SWSCALE) += $(FATE_LIBSWSCALE)
> +FATE_FFMPEG += $(FATE_LIBSWSCALE_FFMPEG-yes)
>  FATE_EXTERN-$(CONFIG_SWSCALE) += $(FATE_LIBSWSCALE_SAMPLES)
> -fate-libswscale: $(FATE_LIBSWSCALE) $(FATE_LIBSWSCALE_SAMPLES)
> +fate-libswscale: $(FATE_LIBSWSCALE) $(FATE_LIBSWSCALE_SAMPLES) 
> $(FATE_LIBSWSCALE_FFMPEG-yes)

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] avcodec/proresdec2: Rename to proresdec

2024-04-01 Thread Andreas Rheinhardt
Andreas Rheinhardt:
> Once upon a time, there used to be a LGPL and a GPL ProRes decoder
> in FFmpeg; the current decoder evolved from the second of these.
> But given that it is now the only ProRes decoder we have, it's file
> should simply be named proresdec.c (which also brings it in line with
> its header).
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/Makefile  | 2 +-
>  libavcodec/{proresdec2.c => proresdec.c} | 0
>  2 files changed, 1 insertion(+), 1 deletion(-)
>  rename libavcodec/{proresdec2.c => proresdec.c} (100%)
> 
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index eef936944d..8c8c2ce659 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -608,7 +608,7 @@ OBJS-$(CONFIG_PNG_DECODER) += png.o pngdec.o 
> pngdsp.o
>  OBJS-$(CONFIG_PNG_ENCODER) += png.o pngenc.o
>  OBJS-$(CONFIG_PPM_DECODER) += pnmdec.o pnm.o
>  OBJS-$(CONFIG_PPM_ENCODER) += pnmenc.o
> -OBJS-$(CONFIG_PRORES_DECODER)  += proresdec2.o proresdsp.o 
> proresdata.o
> +OBJS-$(CONFIG_PRORES_DECODER)  += proresdec.o proresdsp.o 
> proresdata.o
>  OBJS-$(CONFIG_PRORES_ENCODER)  += proresenc_anatoliy.o proresdata.o
>  OBJS-$(CONFIG_PRORES_AW_ENCODER)   += proresenc_anatoliy.o proresdata.o
>  OBJS-$(CONFIG_PRORES_KS_ENCODER)   += proresenc_kostya.o proresdata.o
> diff --git a/libavcodec/proresdec2.c b/libavcodec/proresdec.c
> similarity index 100%
> rename from libavcodec/proresdec2.c
> rename to libavcodec/proresdec.c

Will apply 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".


[FFmpeg-devel] [PATCH 6/7] avcodec/dsd: Hoist branch out of loop

2024-04-01 Thread Andreas Rheinhardt
This is possible by not converting from LSBF to MSBF; instead
add LSBF LUTs.
This approach necessitates reversing the initial values.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/dsd.c| 12 
 libavcodec/dsddec.c |  3 ++-
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/libavcodec/dsd.c b/libavcodec/dsd.c
index ec63a706f6..1093c5e2dd 100644
--- a/libavcodec/dsd.c
+++ b/libavcodec/dsd.c
@@ -68,7 +68,8 @@ static const double htaps[HTAPS] = {
  3.423230509967409e-07,  1.244182214744588e-07,  3.130441005359396e-08
 };
 
-static double ctables[CTABLES][256];
+static double ctables_lsbf[CTABLES][256];
+static double ctables_msbf[CTABLES][256];
 
 static av_cold void dsd_ctables_tableinit(void)
 {
@@ -81,8 +82,10 @@ static av_cold void dsd_ctables_tableinit(void)
 for (t = 0; t < CTABLES; ++t)
 acc[t] += sign * htaps[t * 8 + m];
 }
-for (t = 0; t < CTABLES; ++t)
-ctables[CTABLES - 1 - t][e] = acc[t];
+for (t = 0; t < CTABLES; ++t) {
+ctables_msbf[CTABLES - 1 - t][e] = acc[t];
+ctables_lsbf[CTABLES - 1 - t][ff_reverse[e]] = acc[t];
+}
 }
 }
 
@@ -100,13 +103,14 @@ void ff_dsd2pcm_translate(DSDContext* s, size_t samples, 
int lsbf,
 unsigned pos, i;
 uint8_t* p;
 double sum;
+const double (*const ctables)[256] = lsbf ? ctables_lsbf : ctables_msbf;
 
 pos = s->pos;
 
 memcpy(buf, s->buf, sizeof(buf));
 
 while (samples-- > 0) {
-buf[pos] = lsbf ? ff_reverse[*src] : *src;
+buf[pos] = *src;
 src += src_stride;
 
 p = buf + ((pos - CTABLES) & FIFOMASK);
diff --git a/libavcodec/dsddec.c b/libavcodec/dsddec.c
index 2bb2e73b75..dd1ea83784 100644
--- a/libavcodec/dsddec.c
+++ b/libavcodec/dsddec.c
@@ -56,7 +56,8 @@ static av_cold int decode_init(AVCodecContext *avctx)
 if (!s)
 return AVERROR(ENOMEM);
 
-silence = DSD_SILENCE;
+silence = avctx->codec_id == AV_CODEC_ID_DSD_LSBF_PLANAR ||
+  avctx->codec_id == AV_CODEC_ID_DSD_LSBF ? DSD_SILENCE_REVERSED : 
DSD_SILENCE;
 for (i = 0; i < avctx->ch_layout.nb_channels; i++) {
 s[i].pos = 0;
 memset(s[i].buf, silence, sizeof(s[i].buf));
-- 
2.40.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 5/7] avcodec/dsddec: Fix decoding LSBF samples

2024-04-01 Thread Andreas Rheinhardt
ff_dsd2pcm_translate() works internally by converting LSBF input
to MSBF upon reading; its buffer is therefore always MSBF
and should therefore be initialized with MSBF silence;
but this is not true since e3d8963c3cb5b8cd31460dd9b3b9dba2a2343bf5
which this patch effectively reverts.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/dsddec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/dsddec.c b/libavcodec/dsddec.c
index 22009c70ef..2bb2e73b75 100644
--- a/libavcodec/dsddec.c
+++ b/libavcodec/dsddec.c
@@ -56,7 +56,7 @@ static av_cold int decode_init(AVCodecContext *avctx)
 if (!s)
 return AVERROR(ENOMEM);
 
-silence = avctx->codec_id == AV_CODEC_ID_DSD_LSBF || avctx->codec_id == 
AV_CODEC_ID_DSD_LSBF_PLANAR ? DSD_SILENCE_REVERSED : DSD_SILENCE;
+silence = DSD_SILENCE;
 for (i = 0; i < avctx->ch_layout.nb_channels; i++) {
 s[i].pos = 0;
 memset(s[i].buf, silence, sizeof(s[i].buf));
-- 
2.40.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 4/7] avcodec/wavpack: Only initialize DSD data when encountering DSD

2024-04-01 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/wavpack.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libavcodec/wavpack.c b/libavcodec/wavpack.c
index 36bd4662e8..c96c8e0583 100644
--- a/libavcodec/wavpack.c
+++ b/libavcodec/wavpack.c
@@ -1049,8 +1049,6 @@ static av_cold int wavpack_decode_init(AVCodecContext 
*avctx)
 if (!s->curr_frame.f || !s->prev_frame.f)
 return AVERROR(ENOMEM);
 
-ff_init_dsd_data();
-
 return 0;
 }
 
@@ -1529,6 +1527,7 @@ static int wavpack_decode_block(AVCodecContext *avctx, 
int block_no,
 return ret;
 }
 ff_thread_release_ext_buffer(>curr_frame);
+ff_init_dsd_data();
 }
 av_channel_layout_copy(>ch_layout, _ch_layout);
 avctx->sample_rate = new_samplerate;
-- 
2.40.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 7/7] avcodec/wavpack: Remove always-false check

2024-04-01 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/wavpack.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/libavcodec/wavpack.c b/libavcodec/wavpack.c
index c96c8e0583..73d69d66ff 100644
--- a/libavcodec/wavpack.c
+++ b/libavcodec/wavpack.c
@@ -1095,11 +1095,6 @@ static int wavpack_decode_block(AVCodecContext *avctx, 
int block_no,
 }
 
 s = wc->fdec[block_no];
-if (!s) {
-av_log(avctx, AV_LOG_ERROR, "Context for block %d is not present\n",
-   block_no);
-return AVERROR_INVALIDDATA;
-}
 
 memset(s->decorr, 0, MAX_TERMS * sizeof(Decorr));
 memset(s->ch, 0, sizeof(s->ch));
-- 
2.40.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 3/7] fate/wavpack: Add test for DSD

2024-04-01 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
Tested on aarch64, alpha, arm, mips, ppc and riscv via qemu;
of course also tested on x64 and x86.

 tests/fate/wavpack.mak  | 3 +++
 tests/ref/fate/wavpack-lossless-dsd | 1 +
 2 files changed, 4 insertions(+)
 create mode 100644 tests/ref/fate/wavpack-lossless-dsd

diff --git a/tests/fate/wavpack.mak b/tests/fate/wavpack.mak
index c684d93f99..41e1b0afad 100644
--- a/tests/fate/wavpack.mak
+++ b/tests/fate/wavpack.mak
@@ -18,6 +18,9 @@ fate-wavpack-lossless-32bit: CMD = md5pipe -i 
$(TARGET_SAMPLES)/wavpack/lossless
 FATE_WAVPACK_F32 += fate-wavpack-lossless-float
 fate-wavpack-lossless-float: CMD = md5pipe -i 
$(TARGET_SAMPLES)/wavpack/lossless/32bit_float-partial.wv -f f32le -af aresample
 
+FATE_WAVPACK_F32 += fate-wavpack-lossless-dsd
+fate-wavpack-lossless-dsd: CMD = md5pipe -i 
$(TARGET_SAMPLES)/wavpack/lossless/dsd.wv -f f32le -af aresample
+
 # lossy
 
 FATE_WAVPACK_S8 += fate-wavpack-lossy-8bit
diff --git a/tests/ref/fate/wavpack-lossless-dsd 
b/tests/ref/fate/wavpack-lossless-dsd
new file mode 100644
index 00..eba76df518
--- /dev/null
+++ b/tests/ref/fate/wavpack-lossless-dsd
@@ -0,0 +1 @@
+0b33207f1ec7e47333878cb8420c21ce
-- 
2.40.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/7] avcodec/dsd: Use double for LUTs

2024-04-01 Thread Andreas Rheinhardt
Needed to make DSD->PCM conversion bitexact across arches.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/dsd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/dsd.c b/libavcodec/dsd.c
index e039302c99..ec63a706f6 100644
--- a/libavcodec/dsd.c
+++ b/libavcodec/dsd.c
@@ -68,7 +68,7 @@ static const double htaps[HTAPS] = {
  3.423230509967409e-07,  1.244182214744588e-07,  3.130441005359396e-08
 };
 
-static float ctables[CTABLES][256];
+static double ctables[CTABLES][256];
 
 static av_cold void dsd_ctables_tableinit(void)
 {
-- 
2.40.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 3/7] fate/wavpack: Add test for DSD

2024-04-01 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
Tested on aarch64, alpha, arm, mips, ppc and riscv via qemu;
of course also tested on x64 and x86.

 tests/fate/wavpack.mak  | 3 +++
 tests/ref/fate/wavpack-lossless-dsd | 1 +
 2 files changed, 4 insertions(+)
 create mode 100644 tests/ref/fate/wavpack-lossless-dsd

diff --git a/tests/fate/wavpack.mak b/tests/fate/wavpack.mak
index c684d93f99..41e1b0afad 100644
--- a/tests/fate/wavpack.mak
+++ b/tests/fate/wavpack.mak
@@ -18,6 +18,9 @@ fate-wavpack-lossless-32bit: CMD = md5pipe -i 
$(TARGET_SAMPLES)/wavpack/lossless
 FATE_WAVPACK_F32 += fate-wavpack-lossless-float
 fate-wavpack-lossless-float: CMD = md5pipe -i 
$(TARGET_SAMPLES)/wavpack/lossless/32bit_float-partial.wv -f f32le -af aresample
 
+FATE_WAVPACK_F32 += fate-wavpack-lossless-dsd
+fate-wavpack-lossless-dsd: CMD = md5pipe -i 
$(TARGET_SAMPLES)/wavpack/lossless/dsd.wv -f f32le -af aresample
+
 # lossy
 
 FATE_WAVPACK_S8 += fate-wavpack-lossy-8bit
diff --git a/tests/ref/fate/wavpack-lossless-dsd 
b/tests/ref/fate/wavpack-lossless-dsd
new file mode 100644
index 00..eba76df518
--- /dev/null
+++ b/tests/ref/fate/wavpack-lossless-dsd
@@ -0,0 +1 @@
+0b33207f1ec7e47333878cb8420c21ce
-- 
2.40.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/7] avcodec/dsd: Use double for LUTs

2024-04-01 Thread Andreas Rheinhardt
Needed to make DSD->PCM conversion bitexact across arches.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/dsd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/dsd.c b/libavcodec/dsd.c
index e039302c99..ec63a706f6 100644
--- a/libavcodec/dsd.c
+++ b/libavcodec/dsd.c
@@ -68,7 +68,7 @@ static const double htaps[HTAPS] = {
  3.423230509967409e-07,  1.244182214744588e-07,  3.130441005359396e-08
 };
 
-static float ctables[CTABLES][256];
+static double ctables[CTABLES][256];
 
 static av_cold void dsd_ctables_tableinit(void)
 {
-- 
2.40.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/7] avcodec/wavpack: Fix leak and segfault on reallocation error

2024-04-01 Thread Andreas Rheinhardt
av_realloc_f() frees the buffer it is given on allocation
failure. But in this case, the buffer is an array of
ownership pointers, causing leaks on error. Furthermore,
the count of pointers is unchanged on error and the codec's
close function uses it to free said ownership pointers,
causing a NPD.
This is a regression since 46412a8935e4632b2460988bfce4152c7dccce22.

Fix this by switching to av_realloc_array().

Signed-off-by: Andreas Rheinhardt 
---
Actually, one only needs one WavpackFrameContext at a time, given
that this decoder does not do proper slice threading.
Alternatively, one could implement proper slice threading.

 libavcodec/wavpack.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/libavcodec/wavpack.c b/libavcodec/wavpack.c
index 7e60a1456a..36bd4662e8 100644
--- a/libavcodec/wavpack.c
+++ b/libavcodec/wavpack.c
@@ -973,9 +973,11 @@ static inline int wv_unpack_mono(WavpackFrameContext *s, 
GetBitContext *gb,
 
 static av_cold int wv_alloc_frame_context(WavpackContext *c)
 {
-c->fdec = av_realloc_f(c->fdec, c->fdec_num + 1, sizeof(*c->fdec));
-if (!c->fdec)
+WavpackFrameContext **fdec = av_realloc_array(c->fdec, c->fdec_num + 1, 
sizeof(*c->fdec));
+
+if (!fdec)
 return -1;
+c->fdec = fdec;
 
 c->fdec[c->fdec_num] = av_mallocz(sizeof(**c->fdec));
 if (!c->fdec[c->fdec_num])
-- 
2.40.1

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

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


Re: [FFmpeg-devel] [PATCH 1/6] avformat/isom: Uninit layout in ff_mp4_read_dec_config_descr()

2024-04-01 Thread James Almer

On 4/1/2024 8:40 PM, Michael Niedermayer wrote:

On Mon, Apr 01, 2024 at 06:33:22PM -0300, James Almer wrote:

On 4/1/2024 5:56 PM, Michael Niedermayer wrote:

Fixes: memleak
Fixes: 
67442/clusterfuzz-testcase-minimized-ffmpeg_dem_CAF_fuzzer-5068813261406208

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

diff --git a/libavformat/isom.c b/libavformat/isom.c
index 9fbccd4437f..c5930bd4d87 100644
--- a/libavformat/isom.c
+++ b/libavformat/isom.c
@@ -359,6 +359,7 @@ int ff_mp4_read_dec_config_descr(AVFormatContext *fc, 
AVStream *st, AVIOContext
   
st->codecpar->extradata_size, 1, fc);
   if (ret < 0)
   return ret;
+av_channel_layout_uninit(>codecpar->ch_layout);
   st->codecpar->ch_layout.order = AV_CHANNEL_ORDER_UNSPEC;


Not strictly related to this fix, but should we really drop the layout here
by forcing unspec? We're also not even bothering to check if cfg.channels
matches st->codecpar->ch_layout.nb_channels.


I was wondering the same.
I was hoping someone would know the specs well enouh to just say straight
"this and that isnt legal together error out if thats true"


Maybe Marton knows, since he's been working on this code.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


Re: [FFmpeg-devel] [PATCH 4/6] avformat/demux_utils: Avoid leaking the packet in ff_add_attached_pic()

2024-04-01 Thread Michael Niedermayer
On Mon, Apr 01, 2024 at 11:35:56PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > Fixes: memleak
> > Fixes: 
> > 67714/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5671570999476224
> > 
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavformat/demux_utils.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/libavformat/demux_utils.c b/libavformat/demux_utils.c
> > index 86f551245be..96e6e20d1ec 100644
> > --- a/libavformat/demux_utils.c
> > +++ b/libavformat/demux_utils.c
> > @@ -123,9 +123,9 @@ int ff_add_attached_pic(AVFormatContext *s, AVStream 
> > *st0, AVIOContext *pb,
> >  if (!st && !(st = avformat_new_stream(s, NULL)))
> >  return AVERROR(ENOMEM);
> >  pkt = >attached_pic;
> > +av_packet_unref(pkt);
> >  if (buf) {
> >  av_assert1(*buf);
> > -av_packet_unref(pkt);
> >  pkt->buf  = *buf;
> >  pkt->data = (*buf)->data;
> >  pkt->size = (*buf)->size - AV_INPUT_BUFFER_PADDING_SIZE;
> 
> This seems to be from the ff_add_attached_pic() call in
> mov_read_chapters() with the referenced stream having been created in
> mov_read_covr(). The latter does not set a proper id -- it just takes
> what avformat_new_stream() sets as id on every new stream (namely zero).
> So it makes no real sense to compare it to the ids contained in
> chapter_tracks (can really every track be reinterpreted as chapter
> track?). But I am no mov/mp4 expert.
> Anyway, does the following fix it?
> 
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 7bdeeb99f9..51d97296f1 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -8820,7 +8820,7 @@ static void mov_read_chapters(AVFormatContext *s)
> 
>  if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) {
>  st->disposition |= AV_DISPOSITION_ATTACHED_PIC |
> AV_DISPOSITION_TIMED_THUMBNAILS;
> -if (sti->nb_index_entries) {
> +if (!st->attached_pic.data && sti->nb_index_entries) {
>  // Retrieve the first frame, if possible
>  AVIndexEntry *sample = >index_entries[0];
>  if (avio_seek(sc->pb, sample->pos, SEEK_SET) !=
> sample->pos) {
> s

Yes, this fixes it too, please apply and backport as needed

thx

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

Homeopathy is like voting while filling the ballot out with transparent ink.
Sometimes the outcome one wanted occurs. Rarely its worse than filling out
a ballot properly.


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

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


Re: [FFmpeg-devel] [PATCH 2/6] avformat/mov: Check that tile_item_list is initialized in read_image_iovl()

2024-04-01 Thread Michael Niedermayer
On Mon, Apr 01, 2024 at 06:54:35PM -0300, James Almer wrote:
> On 4/1/2024 5:56 PM, Michael Niedermayer wrote:
> > Fixes: null pointer dereference
> > Fixes: 
> > 67494/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-6528714521247744
> > 
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >   libavformat/mov.c | 4 
> >   1 file changed, 4 insertions(+)
> > 
> > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > index 7bdeeb99f98..fa4c237c0d8 100644
> > --- a/libavformat/mov.c
> > +++ b/libavformat/mov.c
> > @@ -9364,6 +9364,10 @@ static int read_image_iovl(AVFormatContext *s, const 
> > HEIFGrid *grid,
> >   }
> >   for (int i = 0; i < tile_grid->nb_tiles; i++) {
> > +if (!grid->tile_item_list[i]) {
> > +ret = AVERROR_INVALIDDATA;
> > +goto fail;
> > +}
> 
> This should not happen. We shouldn't get this far if the array was not
> filled.
> 
> Can you please test the following?
> 
> > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > index 7bdeeb99f9..fb0113b149 100644
> > --- a/libavformat/mov.c
> > +++ b/libavformat/mov.c
> > @@ -9397,8 +9397,9 @@ static int mov_parse_tiles(AVFormatContext *s)
> > 
> >  for (int j = 0; j < grid->nb_tiles; j++) {
> >  int tile_id = grid->tile_id_list[j];
> > +int k;
> > 
> > -for (int k = 0; k < mov->nb_heif_item; k++) {
> > +for (k = 0; k < mov->nb_heif_item; k++) {
> >  HEIFItem *item = >heif_item[k];
> >  AVStream *st = item->st;
> > 
> > @@ -9424,6 +9425,13 @@ static int mov_parse_tiles(AVFormatContext *s)
> >  break;
> >  }
> > 
> > +if (k == grid->nb_tiles) {
> > +av_log(s, AV_LOG_WARNING, "HEIF item id %d referenced by 
> > grid id %d doesn't "
> > +  "exist\n",
> > +   tile_id, grid->item->item_id);
> > +ff_remove_stream_group(s, stg);
> > +loop = 0;
> > +}
> >  if (!loop)
> >  break;
> >  }

i confirm the code fixes the issue, please apply (if it passes fate) and 
backport (if needed)

thx

[...]
-- 
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".


Re: [FFmpeg-devel] 7.0 Name

2024-04-01 Thread Sean McGovern
Hi,

On Mon, Apr 1, 2024, 18:00 Lynne  wrote:

> Apr 1, 2024, 22:01 by mich...@niedermayer.cc:
>
> > Hi all
> >
> > I think we didnt decide on a name for 7.0 yet
> >
> > Previously suggested names:
> > Darwin,
> > De broglie,
> > Dijkstra,
> > Galois,
> > Gauss,
> > Jacobi,
> > Jemison
> > Johnson
> > Leavitt
> > Maxwell,
> > Mellin,
> > Perelman,
> > Poincaré,
> > Ramanujan,
> > Sagan,
> > Ting
> > Viterbi,
> > Voltaire,
> > de Sitter,
> >
> > Please reply with what you prefer or add more to the list.
> > If we end in a tie, previously suggested names will be favoured
> > I will vote last so that i can resolve a tie if one occurs.
> >
>
> Voltaire
> ___
> 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".
>

Not sure if I am allowed to pick, my choice is Dijkstra.

-- Sean McGovern

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

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


Re: [FFmpeg-devel] [PATCH 1/6] avformat/isom: Uninit layout in ff_mp4_read_dec_config_descr()

2024-04-01 Thread Michael Niedermayer
On Mon, Apr 01, 2024 at 06:33:22PM -0300, James Almer wrote:
> On 4/1/2024 5:56 PM, Michael Niedermayer wrote:
> > Fixes: memleak
> > Fixes: 
> > 67442/clusterfuzz-testcase-minimized-ffmpeg_dem_CAF_fuzzer-5068813261406208
> > 
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >   libavformat/isom.c | 1 +
> >   1 file changed, 1 insertion(+)
> > 
> > diff --git a/libavformat/isom.c b/libavformat/isom.c
> > index 9fbccd4437f..c5930bd4d87 100644
> > --- a/libavformat/isom.c
> > +++ b/libavformat/isom.c
> > @@ -359,6 +359,7 @@ int ff_mp4_read_dec_config_descr(AVFormatContext *fc, 
> > AVStream *st, AVIOContext
> >   
> > st->codecpar->extradata_size, 1, fc);
> >   if (ret < 0)
> >   return ret;
> > +av_channel_layout_uninit(>codecpar->ch_layout);
> >   st->codecpar->ch_layout.order = AV_CHANNEL_ORDER_UNSPEC;
> 
> Not strictly related to this fix, but should we really drop the layout here
> by forcing unspec? We're also not even bothering to check if cfg.channels
> matches st->codecpar->ch_layout.nb_channels.

I was wondering the same.
I was hoping someone would know the specs well enouh to just say straight
"this and that isnt legal together error out if thats true"

thx

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

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates


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] web/download: List the expected differences for releases and git and the expected signing key

2024-04-01 Thread Michael Niedermayer
This is kept terse, as few users are expected to check that but its important 
that we list what the expected differences and
signing key is, so any anomalies can be quickly detected.

Signed-off-by: Michael Niedermayer 
---
 src/download | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/download b/src/download
index 0e6fa7e..9866a3b 100644
--- a/src/download
+++ b/src/download
@@ -285,6 +285,8 @@ gpg:issuer "ffmpeg-devel@ffmpeg.org"
 gpg: Good signature from "FFmpeg release signing key 
ffmpeg-devel@ffmpeg.org" [full]
   
 
+Optionally, you can verify that git and tarball match, the only 
differences should be the absence of .git* files in the tarball and a VERSION 
file in the tarball containing the version.
+The git tags should be signed with EDDSA key 
DD1EC9E8DE085C629B3E1846B18E8928B3948D64
   
 
   
-- 
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] [PATCH] mov demuxer: Check if a key is longer than the atom containing it

2024-04-01 Thread James Almer

On 4/1/2024 8:12 PM, Eugene Zemtsov via ffmpeg-devel wrote:

From: Eugene Zemtsov 

Stop reading keys and return AVERROR_INVALIDDATA if key_size
is larger than the amount of space left in the atom.

Bug: https://crbug.com/41496983
Signed-off-by: Eugene Zemtsov 
---
  libavformat/mov.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 662301bf67..5d2f7fa690 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -5045,15 +5045,18 @@ static int mov_read_keys(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
  if (!c->meta_keys)
  return AVERROR(ENOMEM);
  
+uint32_t bytes_left_in_atom = atom.size;

  for (i = 1; i <= count; ++i) {
  uint32_t key_size = avio_rb32(pb);
  uint32_t type = avio_rl32(pb);
-if (key_size < 8) {
+if (key_size < 8 || key_size > bytes_left_in_atom) {
  av_log(c->fc, AV_LOG_ERROR,
 "The key# %"PRIu32" in meta has invalid size:"
 "%"PRIu32"\n", i, key_size);
  return AVERROR_INVALIDDATA;
  }
+
+bytes_left_in_atom -= key_size;


atom is a copy and not used anywhere else in this function, so you can 
just do atom.size -= key_size and check for that above instead.



  key_size -= 8;
  if (type != MKTAG('m','d','t','a')) {
  avio_skip(pb, key_size);

___
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] mov demuxer: Check if a key is longer than the atom containing it

2024-04-01 Thread Eugene Zemtsov via ffmpeg-devel
From: Eugene Zemtsov 

Stop reading keys and return AVERROR_INVALIDDATA if key_size
is larger than the amount of space left in the atom.

Bug: https://crbug.com/41496983
Signed-off-by: Eugene Zemtsov 
---
 libavformat/mov.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 662301bf67..5d2f7fa690 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -5045,15 +5045,18 @@ static int mov_read_keys(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
 if (!c->meta_keys)
 return AVERROR(ENOMEM);
 
+uint32_t bytes_left_in_atom = atom.size;
 for (i = 1; i <= count; ++i) {
 uint32_t key_size = avio_rb32(pb);
 uint32_t type = avio_rl32(pb);
-if (key_size < 8) {
+if (key_size < 8 || key_size > bytes_left_in_atom) {
 av_log(c->fc, AV_LOG_ERROR,
"The key# %"PRIu32" in meta has invalid size:"
"%"PRIu32"\n", i, key_size);
 return AVERROR_INVALIDDATA;
 }
+
+bytes_left_in_atom -= key_size;
 key_size -= 8;
 if (type != MKTAG('m','d','t','a')) {
 avio_skip(pb, key_size);
-- 
2.44.0.478.gd926399ef9-goog

___
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] 7.0 Name

2024-04-01 Thread Lynne
Apr 1, 2024, 22:01 by mich...@niedermayer.cc:

> Hi all
>
> I think we didnt decide on a name for 7.0 yet
>
> Previously suggested names:
> Darwin,
> De broglie,
> Dijkstra,
> Galois,
> Gauss,
> Jacobi,
> Jemison
> Johnson
> Leavitt
> Maxwell,
> Mellin,
> Perelman,
> Poincaré,
> Ramanujan,
> Sagan,
> Ting
> Viterbi,
> Voltaire,
> de Sitter,
>
> Please reply with what you prefer or add more to the list.
> If we end in a tie, previously suggested names will be favoured
> I will vote last so that i can resolve a tie if one occurs.
>

Voltaire
___
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/6] avformat/mov: Check that tile_item_list is initialized in read_image_iovl()

2024-04-01 Thread James Almer

On 4/1/2024 5:56 PM, Michael Niedermayer wrote:

Fixes: null pointer dereference
Fixes: 
67494/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-6528714521247744

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

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 7bdeeb99f98..fa4c237c0d8 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -9364,6 +9364,10 @@ static int read_image_iovl(AVFormatContext *s, const 
HEIFGrid *grid,
  }
  
  for (int i = 0; i < tile_grid->nb_tiles; i++) {

+if (!grid->tile_item_list[i]) {
+ret = AVERROR_INVALIDDATA;
+goto fail;
+}


This should not happen. We shouldn't get this far if the array was not 
filled.


Can you please test the following?


diff --git a/libavformat/mov.c b/libavformat/mov.c
index 7bdeeb99f9..fb0113b149 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -9397,8 +9397,9 @@ static int mov_parse_tiles(AVFormatContext *s)

 for (int j = 0; j < grid->nb_tiles; j++) {
 int tile_id = grid->tile_id_list[j];
+int k;

-for (int k = 0; k < mov->nb_heif_item; k++) {
+for (k = 0; k < mov->nb_heif_item; k++) {
 HEIFItem *item = >heif_item[k];
 AVStream *st = item->st;

@@ -9424,6 +9425,13 @@ static int mov_parse_tiles(AVFormatContext *s)
 break;
 }

+if (k == grid->nb_tiles) {
+av_log(s, AV_LOG_WARNING, "HEIF item id %d referenced by grid id %d 
doesn't "
+  "exist\n",
+   tile_id, grid->item->item_id);
+ff_remove_stream_group(s, stg);
+loop = 0;
+}
 if (!loop)
 break;
 }

___
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 4/6] avformat/demux_utils: Avoid leaking the packet in ff_add_attached_pic()

2024-04-01 Thread Andreas Rheinhardt
Michael Niedermayer:
> Fixes: memleak
> Fixes: 
> 67714/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5671570999476224
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/demux_utils.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/demux_utils.c b/libavformat/demux_utils.c
> index 86f551245be..96e6e20d1ec 100644
> --- a/libavformat/demux_utils.c
> +++ b/libavformat/demux_utils.c
> @@ -123,9 +123,9 @@ int ff_add_attached_pic(AVFormatContext *s, AVStream 
> *st0, AVIOContext *pb,
>  if (!st && !(st = avformat_new_stream(s, NULL)))
>  return AVERROR(ENOMEM);
>  pkt = >attached_pic;
> +av_packet_unref(pkt);
>  if (buf) {
>  av_assert1(*buf);
> -av_packet_unref(pkt);
>  pkt->buf  = *buf;
>  pkt->data = (*buf)->data;
>  pkt->size = (*buf)->size - AV_INPUT_BUFFER_PADDING_SIZE;

This seems to be from the ff_add_attached_pic() call in
mov_read_chapters() with the referenced stream having been created in
mov_read_covr(). The latter does not set a proper id -- it just takes
what avformat_new_stream() sets as id on every new stream (namely zero).
So it makes no real sense to compare it to the ids contained in
chapter_tracks (can really every track be reinterpreted as chapter
track?). But I am no mov/mp4 expert.
Anyway, does the following fix it?

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 7bdeeb99f9..51d97296f1 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -8820,7 +8820,7 @@ static void mov_read_chapters(AVFormatContext *s)

 if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) {
 st->disposition |= AV_DISPOSITION_ATTACHED_PIC |
AV_DISPOSITION_TIMED_THUMBNAILS;
-if (sti->nb_index_entries) {
+if (!st->attached_pic.data && sti->nb_index_entries) {
 // Retrieve the first frame, if possible
 AVIndexEntry *sample = >index_entries[0];
 if (avio_seek(sc->pb, sample->pos, SEEK_SET) !=
sample->pos) {
s

- 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 1/6] avformat/isom: Uninit layout in ff_mp4_read_dec_config_descr()

2024-04-01 Thread James Almer

On 4/1/2024 5:56 PM, Michael Niedermayer wrote:

Fixes: memleak
Fixes: 
67442/clusterfuzz-testcase-minimized-ffmpeg_dem_CAF_fuzzer-5068813261406208

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

diff --git a/libavformat/isom.c b/libavformat/isom.c
index 9fbccd4437f..c5930bd4d87 100644
--- a/libavformat/isom.c
+++ b/libavformat/isom.c
@@ -359,6 +359,7 @@ int ff_mp4_read_dec_config_descr(AVFormatContext *fc, 
AVStream *st, AVIOContext
  st->codecpar->extradata_size, 
1, fc);
  if (ret < 0)
  return ret;
+av_channel_layout_uninit(>codecpar->ch_layout);
  st->codecpar->ch_layout.order = AV_CHANNEL_ORDER_UNSPEC;


Not strictly related to this fix, but should we really drop the layout 
here by forcing unspec? We're also not even bothering to check if 
cfg.channels matches st->codecpar->ch_layout.nb_channels.



  st->codecpar->ch_layout.nb_channels = cfg.channels;
  if (cfg.object_type == 29 && cfg.sampling_index < 3) // old mp3on4

___
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] avformat/lc3: Add file format for LC3/LC3plus transport

2024-04-01 Thread Antoine Soulier via ffmpeg-devel
A file format is described in Bluetooth SIG LC3 and ETSI TS 103 634, for
test purpose. This is the format implemented here.

Signed-off-by: Antoine Soulier 
---
 Changelog|   1 +
 doc/muxers.texi  |   6 ++
 libavformat/Makefile |   2 +
 libavformat/allformats.c |   2 +
 libavformat/lc3dec.c | 127 +++
 libavformat/lc3enc.c | 100 ++
 6 files changed, 238 insertions(+)
 create mode 100644 libavformat/lc3dec.c
 create mode 100644 libavformat/lc3enc.c

diff --git a/Changelog b/Changelog
index 83a4cf7888..08c200a41d 100644
--- a/Changelog
+++ b/Changelog
@@ -2,6 +2,7 @@ Entries are sorted chronologically from oldest to youngest 
within each release,
 releases are sorted from youngest to oldest.
 
 version :
+- LC3/LC3plus demuxer and muxer
 - LC3/LC3plus decoding/encoding using external library liblc3
 
 
diff --git a/doc/muxers.texi b/doc/muxers.texi
index a10a8e216f..9687746c30 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -2612,6 +2612,12 @@ WebDAV server every second:
 ffmpeg -f x11grab -framerate 1 -i :0.0 -q:v 6 -update 1 -protocol_opts 
method=PUT http://example.com/desktop.jpg
 @end example
 
+@section lc3
+Bluetooth SIG Low Complexity Communication Codec audio (LC3), or
+ETSI TS 103 634 Low Complexity Communication Codec plus (LC3plus).
+
+This muxer accepts a single @code{lc3} audio stream.
+
 @section matroska
 
 Matroska container muxer.
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 44aa485029..4961c42852 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -332,6 +332,8 @@ OBJS-$(CONFIG_KVAG_DEMUXER)  += kvag.o
 OBJS-$(CONFIG_KVAG_MUXER)+= kvag.o rawenc.o
 OBJS-$(CONFIG_LAF_DEMUXER)   += lafdec.o
 OBJS-$(CONFIG_LATM_MUXER)+= latmenc.o rawenc.o
+OBJS-$(CONFIG_LC3_DEMUXER)   += lc3dec.o
+OBJS-$(CONFIG_LC3_MUXER) += lc3enc.o
 OBJS-$(CONFIG_LMLM4_DEMUXER) += lmlm4.o
 OBJS-$(CONFIG_LOAS_DEMUXER)  += loasdec.o rawdec.o
 OBJS-$(CONFIG_LUODAT_DEMUXER)+= luodatdec.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 9df42bb87a..0b36a7c3eb 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -252,6 +252,8 @@ extern const FFInputFormat  ff_kvag_demuxer;
 extern const FFOutputFormat ff_kvag_muxer;
 extern const FFInputFormat  ff_laf_demuxer;
 extern const FFOutputFormat ff_latm_muxer;
+extern const FFInputFormat  ff_lc3_demuxer;
+extern const FFOutputFormat ff_lc3_muxer;
 extern const FFInputFormat  ff_lmlm4_demuxer;
 extern const FFInputFormat  ff_loas_demuxer;
 extern const FFInputFormat  ff_luodat_demuxer;
diff --git a/libavformat/lc3dec.c b/libavformat/lc3dec.c
new file mode 100644
index 00..7232e9847e
--- /dev/null
+++ b/libavformat/lc3dec.c
@@ -0,0 +1,127 @@
+/*
+ * LC3 demuxer
+ * Copyright (C) 2024  Antoine Soulier 
+ *
+ * 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
+ */
+
+/**
+ * @file
+ * Based on the file format specified by :
+ *
+ * - Bluetooth SIG - Low Complexity Communication Codec Test Suite
+ *   https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=502301
+ *   3.2.8.2 Reference LC3 Codec Bitstream Format
+ *
+ * - ETSI TI 103 634 V1.4.1 - Low Complexity Communication Codec plus
+ *   
https://www.etsi.org/deliver/etsi_ts/103600_103699/103634/01.04.01_60/ts_103634v010401p.pdf
+ *   LC3plus conformance script package
+ */
+
+#include "libavcodec/packet.h"
+#include "libavutil/intreadwrite.h"
+
+#include "avformat.h"
+#include "avio.h"
+#include "demux.h"
+#include "internal.h"
+
+typedef struct LC3DemuxContext {
+int frame_samples;
+} LC3DemuxContext;
+
+static int lc3_read_header(AVFormatContext *s)
+{
+LC3DemuxContext *lc3 = s->priv_data;
+AVStream *st = NULL;
+uint16_t tag, hdr_size;
+uint16_t frame_10us;
+uint32_t length;
+int ep_mode, hr_mode;
+int srate_hz, channels, bit_rate;
+int num_extra_params, ret;
+
+tag = avio_rb16(s->pb);
+hdr_size = avio_rl16(s->pb);
+
+if (tag != 0x1ccc || hdr_size < 9 * sizeof(uint16_t))
+return AVERROR_INVALIDDATA;
+
+num_extra_params = hdr_size / sizeof(uint16_t) - 9;
+
+

[FFmpeg-devel] [PATCH 1/2] avcodec/liblc3: Add encoding/decoding support of LC3 audio codec

2024-04-01 Thread Antoine Soulier via ffmpeg-devel
The LC3 audio codec is the default codec of Bluetooth LE audio.
This is a wrapper over the liblc3 library (https://github.com/google/liblc3).

Signed-off-by: Antoine Soulier 
---
 Changelog |   4 +
 configure |   6 ++
 doc/encoders.texi |  57 +++
 doc/general_contents.texi |  11 +-
 libavcodec/Makefile   |   2 +
 libavcodec/allcodecs.c|   2 +
 libavcodec/codec_desc.c   |   7 ++
 libavcodec/codec_id.h |   1 +
 libavcodec/liblc3dec.c| 145 ++
 libavcodec/liblc3enc.c| 210 ++
 10 files changed, 444 insertions(+), 1 deletion(-)
 create mode 100644 libavcodec/liblc3dec.c
 create mode 100644 libavcodec/liblc3enc.c

diff --git a/Changelog b/Changelog
index e83a00e35c..83a4cf7888 100644
--- a/Changelog
+++ b/Changelog
@@ -1,6 +1,10 @@
 Entries are sorted chronologically from oldest to youngest within each release,
 releases are sorted from youngest to oldest.
 
+version :
+- LC3/LC3plus decoding/encoding using external library liblc3
+
+
 version 7.0:
 - DXV DXT1 encoder
 - LEAD MCMP decoder
diff --git a/configure b/configure
index 2d46ef0b9c..e5d9ba9f53 100755
--- a/configure
+++ b/configure
@@ -244,6 +244,7 @@ External library support:
   --enable-libjxl  enable JPEG XL de/encoding via libjxl [no]
   --enable-libklvanc   enable Kernel Labs VANC processing [no]
   --enable-libkvazaar  enable HEVC encoding via libkvazaar [no]
+  --enable-liblc3  enable LC3 de/encoding via liblc3 [no]
   --enable-liblensfun  enable lensfun lens correction [no]
   --enable-libmodplug  enable ModPlug via libmodplug [no]
   --enable-libmp3lame  enable MP3 encoding via libmp3lame [no]
@@ -1926,6 +1927,7 @@ EXTERNAL_LIBRARY_LIST="
 libjxl
 libklvanc
 libkvazaar
+liblc3
 libmodplug
 libmp3lame
 libmysofa
@@ -3499,6 +3501,9 @@ libilbc_encoder_deps="libilbc"
 libjxl_decoder_deps="libjxl libjxl_threads"
 libjxl_encoder_deps="libjxl libjxl_threads"
 libkvazaar_encoder_deps="libkvazaar"
+liblc3_decoder_deps="liblc3"
+liblc3_encoder_deps="liblc3"
+liblc3_encoder_select="audio_frame_queue"
 libmodplug_demuxer_deps="libmodplug"
 libmp3lame_encoder_deps="libmp3lame"
 libmp3lame_encoder_select="audio_frame_queue mpegaudioheader"
@@ -6869,6 +6874,7 @@ enabled libjxl&& require_pkg_config libjxl 
"libjxl >= 0.7.0" jxl/dec
  require_pkg_config libjxl_threads "libjxl_threads 
>= 0.7.0" jxl/thread_parallel_runner.h JxlThreadParallelRunner
 enabled libklvanc && require libklvanc libklvanc/vanc.h 
klvanc_context_create -lklvanc
 enabled libkvazaar&& require_pkg_config libkvazaar "kvazaar >= 2.0.0" 
kvazaar.h kvz_api_get
+enabled liblc3&& require_pkg_config liblc3 "lc3 >= 1.1.0" lc3.h 
lc3_hr_setup_encoder
 enabled liblensfun&& require_pkg_config liblensfun lensfun lensfun.h 
lf_db_create
 
 if enabled libmfx && enabled libvpl; then
diff --git a/doc/encoders.texi b/doc/encoders.texi
index 7c223ed74c..66847191e1 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -814,6 +814,63 @@ ffmpeg -i input.wav -c:a libfdk_aac -profile:a aac_he -b:a 
64k output.m4a
 @end example
 @end itemize
 
+@anchor{liblc3-enc}
+@section liblc3
+
+liblc3 LC3 (Low Complexity Communication Codec) encoder wrapper.
+
+Requires the presence of the liblc3 headers and library during configuration.
+You need to explicitly configure the build with @code{--enable-liblc3}.
+
+This encoder has support for the Bluetooth SIG LC3 codec for the LE Audio
+protocol, and the following features of LC3plus:
+@itemize
+@item
+Frame duration of 2.5 and 5ms.
+@item
+High-Resolution mode, 48 KHz, and 96 kHz sampling rates.
+@end itemize
+
+For more information see the liblc3 project at
+@url{https://github.com/google/liblc3}.
+
+@subsection Options
+
+The following options are mapped on the shared FFmpeg codec options.
+
+@table @option
+@item b @var{bitrate}
+Set the bit rate in bits/s. This will determine the fixed size of the encoded
+frames, for a selected frame duration.
+
+@item ar @var{frequency}
+Set the audio sampling rate (in Hz).
+
+@item channels
+Set the number of audio channels.
+
+@item frame_duration
+Set the audio frame duration in milliseconds. Default value is 10ms.
+Allowed frame durations are 2.5ms, 5ms, 7.5ms and 10ms.
+LC3 (Bluetooth LE Audio), allows 7.5ms and 10ms; and LC3plus 2.5ms, 5ms
+and 10ms.
+
+The 10ms frame duration is available in LC3 and LC3 plus standard.
+In this mode, the produced bitstream can be referenced either as LC3 or 
LC3plus.
+
+@item high_resolution @var{boolean}
+Enable the high-resolution mode if set to 1. The high-resolution mode is
+available with all LC3plus frame durations and for a sampling rate of 48 KHz,
+and 96 KHz.
+
+The encoder automatically turns off this mode at lower sampling rates and
+activates it at 96 KHz.
+
+This mode should be preferred at high bitrates. In this mode, 

Re: [FFmpeg-devel] [PATCH 1/6] avformat/isom: Uninit layout in ff_mp4_read_dec_config_descr()

2024-04-01 Thread James Almer

On 4/1/2024 6:25 PM, James Almer wrote:

On 4/1/2024 5:56 PM, Michael Niedermayer wrote:

Fixes: memleak
Fixes: 
67442/clusterfuzz-testcase-minimized-ffmpeg_dem_CAF_fuzzer-5068813261406208


Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg

Signed-off-by: Michael Niedermayer 
---
  libavformat/isom.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/libavformat/isom.c b/libavformat/isom.c
index 9fbccd4437f..c5930bd4d87 100644
--- a/libavformat/isom.c
+++ b/libavformat/isom.c
@@ -359,6 +359,7 @@ int ff_mp4_read_dec_config_descr(AVFormatContext 
*fc, AVStream *st, AVIOContext
  
st->codecpar->extradata_size, 1, fc);

  if (ret < 0)
  return ret;
+    av_channel_layout_uninit(>codecpar->ch_layout);


Why is there a custom layout here to begin with? The caf demuxer doesn't 
export one.


Nevermind, it calls ff_mov_read_chan() which may generate one.

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

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


Re: [FFmpeg-devel] [PATCH 1/6] avformat/isom: Uninit layout in ff_mp4_read_dec_config_descr()

2024-04-01 Thread James Almer

On 4/1/2024 5:56 PM, Michael Niedermayer wrote:

Fixes: memleak
Fixes: 
67442/clusterfuzz-testcase-minimized-ffmpeg_dem_CAF_fuzzer-5068813261406208

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

diff --git a/libavformat/isom.c b/libavformat/isom.c
index 9fbccd4437f..c5930bd4d87 100644
--- a/libavformat/isom.c
+++ b/libavformat/isom.c
@@ -359,6 +359,7 @@ int ff_mp4_read_dec_config_descr(AVFormatContext *fc, 
AVStream *st, AVIOContext
  st->codecpar->extradata_size, 
1, fc);
  if (ret < 0)
  return ret;
+av_channel_layout_uninit(>codecpar->ch_layout);


Why is there a custom layout here to begin with? The caf demuxer doesn't 
export one.



  st->codecpar->ch_layout.order = AV_CHANNEL_ORDER_UNSPEC;
  st->codecpar->ch_layout.nb_channels = cfg.channels;
  if (cfg.object_type == 29 && cfg.sampling_index < 3) // old mp3on4

___
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] avcodec/apedec: Use NABS to avoid undefined negation

2024-04-01 Thread Michael Niedermayer
Fixes: negation of -2147483648 cannot be represented in type 'int32_t' (aka 
'int'); cast to an unsigned type to negate this value to itself
Fixes: 
67738/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APE_fuzzer-5444313212321792

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

diff --git a/libavcodec/apedec.c b/libavcodec/apedec.c
index 86b79182a73..d75a85f4664 100644
--- a/libavcodec/apedec.c
+++ b/libavcodec/apedec.c
@@ -1287,7 +1287,7 @@ static void predictor_decode_stereo_3950(APEContext *ctx, 
int count)
 int32_t left  = a1 - (unsigned)(a0 / 2);
 int32_t right = left + (unsigned)a0;
 
-if (FFMAX(FFABS(left), FFABS(right)) > (1<<23)) {
+if (FFMIN(FFNABS(left), FFNABS(right)) < -(1<<23)) {
 ctx->interim_mode = !interim_mode;
 av_log(ctx->avctx, AV_LOG_VERBOSE, "Interim mode: %d\n", 
ctx->interim_mode);
 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 4/6] avformat/demux_utils: Avoid leaking the packet in ff_add_attached_pic()

2024-04-01 Thread Michael Niedermayer
Fixes: memleak
Fixes: 
67714/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5671570999476224

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

diff --git a/libavformat/demux_utils.c b/libavformat/demux_utils.c
index 86f551245be..96e6e20d1ec 100644
--- a/libavformat/demux_utils.c
+++ b/libavformat/demux_utils.c
@@ -123,9 +123,9 @@ int ff_add_attached_pic(AVFormatContext *s, AVStream *st0, 
AVIOContext *pb,
 if (!st && !(st = avformat_new_stream(s, NULL)))
 return AVERROR(ENOMEM);
 pkt = >attached_pic;
+av_packet_unref(pkt);
 if (buf) {
 av_assert1(*buf);
-av_packet_unref(pkt);
 pkt->buf  = *buf;
 pkt->data = (*buf)->data;
 pkt->size = (*buf)->size - AV_INPUT_BUFFER_PADDING_SIZE;
-- 
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 5/6] avcodec/hevc_ps: --typo

2024-04-01 Thread Michael Niedermayer
Fixes: null pointer dereference
Fixes: 
67737/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-4858162608930816

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

diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index 38b3721a6d5..25f087ed754 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -460,7 +460,7 @@ int ff_hevc_decode_nal_vps(GetBitContext *gb, 
AVCodecContext *avctx,
 int ret = AVERROR_INVALIDDATA;
 HEVCVPS *vps;
 
-if (ps->pps_list[vps_id]) {
+if (ps->vps_list[vps_id]) {
 const HEVCVPS *vps1 = ps->vps_list[vps_id];
 if (vps1->data_size == nal_size &&
 !memcmp(vps1->data, gb->buffer, vps1->data_size))
-- 
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/6] avformat/mov: Check that tile_item_list is initialized in read_image_iovl()

2024-04-01 Thread Michael Niedermayer
Fixes: null pointer dereference
Fixes: 
67494/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-6528714521247744

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

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 7bdeeb99f98..fa4c237c0d8 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -9364,6 +9364,10 @@ static int read_image_iovl(AVFormatContext *s, const 
HEIFGrid *grid,
 }
 
 for (int i = 0; i < tile_grid->nb_tiles; i++) {
+if (!grid->tile_item_list[i]) {
+ret = AVERROR_INVALIDDATA;
+goto fail;
+}
 tile_grid->offsets[i].idx= grid->tile_item_list[i]->st->index;
 tile_grid->offsets[i].horizontal = (flags & 1) ? avio_rb32(s->pb) : 
avio_rb16(s->pb);
 tile_grid->offsets[i].vertical   = (flags & 1) ? avio_rb32(s->pb) : 
avio_rb16(s->pb);
-- 
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 3/6] tools/target_dec_fuzzer: Adjust threshold for RV30

2024-04-01 Thread Michael Niedermayer
Fixes: Timeout
Fixes: 
67530/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RV30_fuzzer-6635676118351872

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 | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index a6e6b2f27f7..e7633c6ad8f 100644
--- a/tools/target_dec_fuzzer.c
+++ b/tools/target_dec_fuzzer.c
@@ -279,6 +279,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t 
size) {
 case AV_CODEC_ID_RSCC:maxpixels  /= 256;   break;
 case AV_CODEC_ID_RASC:maxpixels  /= 16;break;
 case AV_CODEC_ID_RTV1:maxpixels  /= 16;break;
+case AV_CODEC_ID_RV30:maxpixels  /= 16;break;
 case AV_CODEC_ID_SANM:maxpixels  /= 16;break;
 case AV_CODEC_ID_SCPR:maxpixels  /= 32;break;
 case AV_CODEC_ID_SCREENPRESSO:maxpixels  /= 64;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 1/6] avformat/isom: Uninit layout in ff_mp4_read_dec_config_descr()

2024-04-01 Thread Michael Niedermayer
Fixes: memleak
Fixes: 
67442/clusterfuzz-testcase-minimized-ffmpeg_dem_CAF_fuzzer-5068813261406208

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

diff --git a/libavformat/isom.c b/libavformat/isom.c
index 9fbccd4437f..c5930bd4d87 100644
--- a/libavformat/isom.c
+++ b/libavformat/isom.c
@@ -359,6 +359,7 @@ int ff_mp4_read_dec_config_descr(AVFormatContext *fc, 
AVStream *st, AVIOContext
 st->codecpar->extradata_size, 
1, fc);
 if (ret < 0)
 return ret;
+av_channel_layout_uninit(>codecpar->ch_layout);
 st->codecpar->ch_layout.order = AV_CHANNEL_ORDER_UNSPEC;
 st->codecpar->ch_layout.nb_channels = cfg.channels;
 if (cfg.object_type == 29 && cfg.sampling_index < 3) // old mp3on4
-- 
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] [PATCH 3/4] avformat/mov_chan: respect channel order when parsing and creating chnl atom

2024-04-01 Thread Marton Balint




On Mon, 1 Apr 2024, James Almer wrote:


On 4/1/2024 3:56 PM, Marton Balint wrote:

 Previously we always assumed that the channels are in native order, even
 if
 they were not. The new channel layout API allows us to signal the proper
 channel order, so let's do so.

 Signed-off-by: Marton Balint 
 ---
   libavformat/mov_chan.c | 145 +
   libavformat/mov_chan.h |   5 +-
   tests/ref/fate/mov-mp4-pcm |   2 +-
   3 files changed, 86 insertions(+), 66 deletions(-)


[...]


 diff --git a/tests/ref/fate/mov-mp4-pcm b/tests/ref/fate/mov-mp4-pcm
 index 6bae8f800b..19a978df95 100644
 --- a/tests/ref/fate/mov-mp4-pcm
 +++ b/tests/ref/fate/mov-mp4-pcm
 @@ -1,4 +1,4 @@
 -99ad26b4054794e84bd962a1124cdccf *tests/data/fate/mov-mp4-pcm.mp4
 +462668dd69e7ce4fde4934d1d5978531 *tests/data/fate/mov-mp4-pcm.mp4


What changes in the output?


The chnl atom changes for the 7.1 layout, the order of channels (being in 
native order) is different from the the ISO order, so defined layout 12

cannot be used.

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

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


Re: [FFmpeg-devel] [PATCH 1/4] avformat/mov_chan: check channel count at compile time by using a nonconst expression

2024-04-01 Thread Andreas Rheinhardt
Marton Balint:
> If the channel tag does not match the number of channels, the constant
> expression evaluation should fail.
> 
> Signed-off-by: Marton Balint 
> ---
>  libavformat/mov_chan.c | 48 +++---
>  1 file changed, 22 insertions(+), 26 deletions(-)
> 
> diff --git a/libavformat/mov_chan.c b/libavformat/mov_chan.c
> index e7d181d71f..6ccc26b3f1 100644
> --- a/libavformat/mov_chan.c
> +++ b/libavformat/mov_chan.c
> @@ -81,24 +81,28 @@ struct MovChannelLayoutMap {
>  };
>  };
>  
> -#define TAG(_0)  {.tag = _0}
> -#define ID(_0)   {.id = c_##_0}
> -#define CHLIST(_0, ...)  TAG(_0), __VA_ARGS__
> -#define CHLIST01(_0, _1) CHLIST(_0, ID(_1))
> -#define CHLIST02(_0, _1, _2) CHLIST(_0, ID(_1), 
> ID(_2))
> -#define CHLIST03(_0, _1, _2, _3) CHLIST(_0, ID(_1), 
> ID(_2), ID(_3))
> -#define CHLIST04(_0, _1, _2, _3, _4) CHLIST(_0, ID(_1), 
> ID(_2), ID(_3), ID(_4))
> -#define CHLIST05(_0, _1, _2, _3, _4, _5) CHLIST(_0, ID(_1), 
> ID(_2), ID(_3), ID(_4), ID(_5))
> -#define CHLIST06(_0, _1, _2, _3, _4, _5, _6) CHLIST(_0, ID(_1), 
> ID(_2), ID(_3), ID(_4), ID(_5), ID(_6))
> -#define CHLIST07(_0, _1, _2, _3, _4, _5, _6, _7) CHLIST(_0, ID(_1), 
> ID(_2), ID(_3), ID(_4), ID(_5), ID(_6), ID(_7))
> -#define CHLIST08(_0, _1, _2, _3, _4, _5, _6, _7, _8) CHLIST(_0, ID(_1), 
> ID(_2), ID(_3), ID(_4), ID(_5), ID(_6), ID(_7), ID(_8))
> -#define CHLIST09(_0, _1, _2, _3, _4, _5, _6, _7, _8, _9) CHLIST(_0, ID(_1), 
> ID(_2), ID(_3), ID(_4), ID(_5), ID(_6), ID(_7), ID(_8), ID(_9))
> -#define CHLIST16(_0, _1, _2, _3, _4, _5, _6, _7, _8, _9, _10, _11, _12, _13, 
> _14, _15, _16) \
> -CHLIST(_0, ID(_1),  ID(_2),  ID(_3),  ID(_4),  ID(_5),  ID(_6), ID(_7), 
> ID(_8), ID(_9), ID(_10), \
> -   ID(_11), ID(_12), ID(_13), ID(_14), ID(_15), ID(_16))
> -#define CHLIST21(_0, _1, _2, _3, _4, _5, _6, _7, _8, _9, _10, _11, _12, _13, 
> _14, _15, _16, _17, _18, _19, _20, _21) \
> -CHLIST(_0, ID(_1),  ID(_2),  ID(_3),  ID(_4),  ID(_5),  ID(_6),  ID(_7), 
>  ID(_8),  ID(_9),  ID(_10), \
> -   ID(_11), ID(_12), ID(_13), ID(_14), ID(_15), ID(_16), 
> ID(_17), ID(_18), ID(_19), ID(_20), ID(_21))
> +static int nonconst_expr(void) {
> +return 0;
> +}
> +
> +#define TAG(_tag, _cnt){.tag = (_tag & 
> 0x) == _cnt ? _tag : nonconst_expr()}
> +#define ID(_0) {.id = c_##_0}
> +#define CHLIST(_tag, _cnt, ...)TAG(_tag, _cnt), 
> __VA_ARGS__
> +#define CHLIST01(_tag, _1) CHLIST(_tag, 1, 
> ID(_1))
> +#define CHLIST02(_tag, _1, _2) CHLIST(_tag, 2, 
> ID(_1), ID(_2))
> +#define CHLIST03(_tag, _1, _2, _3) CHLIST(_tag, 3, 
> ID(_1), ID(_2), ID(_3))
> +#define CHLIST04(_tag, _1, _2, _3, _4) CHLIST(_tag, 4, 
> ID(_1), ID(_2), ID(_3), ID(_4))
> +#define CHLIST05(_tag, _1, _2, _3, _4, _5) CHLIST(_tag, 5, 
> ID(_1), ID(_2), ID(_3), ID(_4), ID(_5))
> +#define CHLIST06(_tag, _1, _2, _3, _4, _5, _6) CHLIST(_tag, 6, 
> ID(_1), ID(_2), ID(_3), ID(_4), ID(_5), ID(_6))
> +#define CHLIST07(_tag, _1, _2, _3, _4, _5, _6, _7) CHLIST(_tag, 7, 
> ID(_1), ID(_2), ID(_3), ID(_4), ID(_5), ID(_6), ID(_7))
> +#define CHLIST08(_tag, _1, _2, _3, _4, _5, _6, _7, _8) CHLIST(_tag, 8, 
> ID(_1), ID(_2), ID(_3), ID(_4), ID(_5), ID(_6), ID(_7), ID(_8))
> +#define CHLIST09(_tag, _1, _2, _3, _4, _5, _6, _7, _8, _9) CHLIST(_tag, 9, 
> ID(_1), ID(_2), ID(_3), ID(_4), ID(_5), ID(_6), ID(_7), ID(_8), ID(_9))
> +#define CHLIST16(_tag, _1, _2, _3, _4, _5, _6, _7, _8, _9, _10, _11, _12, 
> _13, _14, _15, _16) \
> +CHLIST(_tag, 16, ID(_1),  ID(_2),  ID(_3),  ID(_4),  ID(_5),  ID(_6), 
> ID(_7), ID(_8), ID(_9), ID(_10), \
> + ID(_11), ID(_12), ID(_13), ID(_14), ID(_15), ID(_16))
> +#define CHLIST21(_tag, _1, _2, _3, _4, _5, _6, _7, _8, _9, _10, _11, _12, 
> _13, _14, _15, _16, _17, _18, _19, _20, _21) \
> +CHLIST(_tag, 21, ID(_1),  ID(_2),  ID(_3),  ID(_4),  ID(_5),  ID(_6),  
> ID(_7),  ID(_8),  ID(_9),  ID(_10), \
> + ID(_11), ID(_12), ID(_13), ID(_14), ID(_15), ID(_16), 
> ID(_17), ID(_18), ID(_19), ID(_20), ID(_21))
>  
>  static const struct MovChannelLayoutMap mov_ch_layout_map[] = {
>  CHLIST01( MOV_CH_LAYOUT_MONO, C ),
> @@ -281,14 +285,6 @@ static const struct {
>  
>  static const struct MovChannelLayoutMap* find_layout_map(uint32_t tag)
>  {
> -#if defined(ASSERT_LEVEL) && ASSERT_LEVEL > 1
> -{
> -int i;
> -for (i = 0; i < FF_ARRAY_ELEMS(mov_ch_layout_map); i += 1 + 
> (mov_ch_layout_map[i].tag & 0x))
> -

Re: [FFmpeg-devel] 7.0 Name

2024-04-01 Thread Paul B Mahol
On Mon, Apr 1, 2024 at 10:01 PM Michael Niedermayer 
wrote:

> Hi all
>
> I think we didnt decide on a name for 7.0 yet
>
> Previously suggested names:
> Darwin,
> De broglie,
> Dijkstra,
> Galois,
> Gauss,
> Jacobi,
> Jemison
> Johnson
> Leavitt
> Maxwell,
> Mellin,
> Perelman,
> Poincaré,
> Ramanujan,
> Sagan,
> Ting
> Viterbi,
> Voltaire,
> de Sitter,
>
> Please reply with what you prefer or add more to the list.
> If we end in a tie, previously suggested names will be favoured
> I will vote last so that i can resolve a tie if one occurs.
>

Anton


>
> thx
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> No snowflake in an avalanche ever feels responsible. -- Voltaire
> ___
> 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] lavc/vaapi_hevc: Add support for Main Intra & Main 10 Intra

2024-04-01 Thread Mark Thompson

On 28/03/2024 02:07, Xiang, Haihao wrote:

From: Haihao Xiang 

Both Main Intra and Main 10 Intra are Rext, we may use Main and Main 10
instead for decoding. This patch fixes the error below:

[hevc @ 0x55a771b80a00] No support for codec hevc profile 4.
[hevc @ 0x55a771b80a00] Failed setup for format vaapi: hwaccel
initialisation returned error.

Signed-off-by: Haihao Xiang 
---
  libavcodec/vaapi_hevc.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/libavcodec/vaapi_hevc.c b/libavcodec/vaapi_hevc.c
index 3bdd2dd1b8..83b94d1a55 100644
--- a/libavcodec/vaapi_hevc.c
+++ b/libavcodec/vaapi_hevc.c
@@ -612,6 +612,13 @@ VAProfile 
ff_vaapi_parse_hevc_rext_scc_profile(AVCodecContext *avctx)
  av_log(avctx, AV_LOG_VERBOSE, "HEVC profile %s is found.\n", 
profile->name);
  }
  
+#if VA_CHECK_VERSION(0, 37, 0)

+if (!strcmp(profile->name, "Main Intra"))
+return VAProfileHEVCMain;
+else if (!strcmp(profile->name, "Main 10 Intra"))
+return VAProfileHEVCMain10;
+#endif
+
  #if VA_CHECK_VERSION(1, 2, 0)
  if (!strcmp(profile->name, "Main 12") ||
  !strcmp(profile->name, "Main 12 Intra"))


What if high_precision_offsets_enabled_flag is set?

(That doesn't matter for the VAAPI encoder setting the profile because we 
always have it as zero.)

Thanks,

- Mark
___
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 2/2] lavc/vaapi_encode_h265: Set general_*_constriaint flags with profile

2024-04-01 Thread Mark Thompson

On 20/03/2024 08:44, Wang, Fei W wrote:

On Mon, 2024-03-18 at 21:22 +, Mark Thompson wrote:

On 18/03/2024 04:21, fei.w.wang-at-intel@ffmpeg.org wrote:

From: Fei Wang 

According to Table A.2 in spec.

Signed-off-by: Fei Wang 
---
   libavcodec/vaapi_encode_h265.c | 176 +++-
-
   1 file changed, 123 insertions(+), 53 deletions(-)

diff --git a/libavcodec/vaapi_encode_h265.c
b/libavcodec/vaapi_encode_h265.c
index 43755e2188..5ed317ce11 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -258,6 +258,124 @@ fail:
   return err;
   }
   
+static int vaapi_encode_h265_init_ptl(AVCodecContext *avctx)

+{
+VAAPIEncodeContext  *ctx = avctx->priv_data;
+VAAPIEncodeH265Context *priv = avctx->priv_data;
+H265RawVPS  *vps = >raw_vps;
+H265RawProfileTierLevel *ptl = >profile_tier_level;
+
+ptl->general_profile_space = 0;
+ptl->general_profile_idc   = avctx->profile;
+ptl->general_tier_flag = priv->tier;
+
+ptl->general_profile_compatibility_flag[ptl-

general_profile_idc] = 1;

+
+if (ptl->general_profile_compatibility_flag[1])
+ptl->general_profile_compatibility_flag[2] = 1;
+if (ptl->general_profile_compatibility_flag[3]) {
+ptl->general_profile_compatibility_flag[1] = 1;
+ptl->general_profile_compatibility_flag[2] = 1;
+}
+
+ptl->general_progressive_source_flag= 1;
+ptl->general_interlaced_source_flag = 0;
+ptl->general_non_packed_constraint_flag = 1;
+ptl->general_frame_only_constraint_flag = 1;
+
+if (avctx->profile >= 4) {
+ptl->general_intra_constraint_flag= ctx-

gop_size == 1;

+ptl->general_one_picture_only_constraint_flag = 0;
+ptl->general_lower_bit_rate_constraint_flag   = 1;
+ptl->general_max_14bit_constraint_flag= 0;
+
+switch (ctx->va_profile) {
+#if VA_CHECK_VERSION(1, 2, 0)
+case VAProfileHEVCMain12:
+// Main 12
+ptl->general_max_12bit_constraint_flag  = 1;
+ptl->general_max_10bit_constraint_flag  = 0;
+ptl->general_max_8bit_constraint_flag   = 0;
+ptl->general_max_422chroma_constraint_flag  = 1;
+ptl->general_max_420chroma_constraint_flag  = 1;
+ptl->general_max_monochrome_constraint_flag = 0;
+break;
+case VAProfileHEVCMain422_10:
+// Main 4:2:2 10
+ptl->general_max_12bit_constraint_flag  = 1;
+ptl->general_max_10bit_constraint_flag  = 1;
+ptl->general_max_8bit_constraint_flag   = 0;
+ptl->general_max_422chroma_constraint_flag  = 1;
+ptl->general_max_420chroma_constraint_flag  = 0;
+ptl->general_max_monochrome_constraint_flag = 0;
+break;
+case VAProfileHEVCMain422_12:
+// Main 4:2:2 12
+ptl->general_max_12bit_constraint_flag  = 1;
+ptl->general_max_10bit_constraint_flag  = 0;
+ptl->general_max_8bit_constraint_flag   = 0;
+ptl->general_max_422chroma_constraint_flag  = 1;
+ptl->general_max_420chroma_constraint_flag  = 0;
+ptl->general_max_monochrome_constraint_flag = 0;
+break;
+case VAProfileHEVCMain444:
+// Main 4:4:4
+ptl->general_max_12bit_constraint_flag  = 1;
+ptl->general_max_10bit_constraint_flag  = 1;
+ptl->general_max_8bit_constraint_flag   = 1;
+ptl->general_max_422chroma_constraint_flag  = 0;
+ptl->general_max_420chroma_constraint_flag  = 0;
+ptl->general_max_monochrome_constraint_flag = 0;
+break;
+case VAProfileHEVCMain444_10:
+// Main 4:4:4 10
+ptl->general_max_12bit_constraint_flag  = 1;
+ptl->general_max_10bit_constraint_flag  = 1;
+ptl->general_max_8bit_constraint_flag   = 0;
+ptl->general_max_422chroma_constraint_flag  = 0;
+ptl->general_max_420chroma_constraint_flag  = 0;
+ptl->general_max_monochrome_constraint_flag = 0;
+break;
+case VAProfileHEVCMain444_12:
+// Main 4:4:4 12
+ptl->general_max_12bit_constraint_flag  = 1;
+ptl->general_max_10bit_constraint_flag  = 0;
+ptl->general_max_8bit_constraint_flag   = 0;
+ptl->general_max_422chroma_constraint_flag  = 0;
+ptl->general_max_420chroma_constraint_flag  = 0;
+ptl->general_max_monochrome_constraint_flag = 0;
+break;
+#endif
+default:
+av_log(avctx, AV_LOG_ERROR, "Unknown profile to init
PTL.\n");
+return AVERROR(EINVAL);
+}
+}


Why is this an improvement over the current code which sets the
constraint flags based on the actual content of the stream?

Note 

[FFmpeg-devel] 7.0 Name

2024-04-01 Thread Michael Niedermayer
Hi all

I think we didnt decide on a name for 7.0 yet

Previously suggested names:
Darwin,
De broglie,
Dijkstra,
Galois,
Gauss,
Jacobi,
Jemison
Johnson
Leavitt
Maxwell,
Mellin,
Perelman,
Poincaré,
Ramanujan,
Sagan,
Ting
Viterbi,
Voltaire,
de Sitter,

Please reply with what you prefer or add more to the list.
If we end in a tie, previously suggested names will be favoured
I will vote last so that i can resolve a tie if one occurs.

thx

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- 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 v1 1/7] lavc/vaapi_dec: Create VA parameters dynamically

2024-04-01 Thread Mark Thompson

On 28/03/2024 01:26, fei.w.wang-at-intel@ffmpeg.org wrote:

From: Fei Wang 

Signed-off-by: Fei Wang 
---
  libavcodec/vaapi_decode.c | 29 ++---
  libavcodec/vaapi_decode.h |  7 ++-
  2 files changed, 24 insertions(+), 12 deletions(-)


This is because the VVC code is going to want to make a lot more of these param 
buffers - can we just set a slightly larger fixed limit?

If you always need 20 buffers (say), then this has turned 1 allocation per 
picture into 3 and used more memory in the non-VVC case as well because of the 
overhead of that (but if you might variably need up to 200 then this is 
completely fair).


diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
index cca94b5336..1b1972a2a9 100644
--- a/libavcodec/vaapi_decode.c
+++ b/libavcodec/vaapi_decode.c
@@ -38,12 +38,23 @@ int ff_vaapi_decode_make_param_buffer(AVCodecContext *avctx,
  {
  VAAPIDecodeContext *ctx = avctx->internal->hwaccel_priv_data;
  VAStatus vas;
-VABufferID buffer;
  
-av_assert0(pic->nb_param_buffers + 1 <= MAX_PARAM_BUFFERS);

+av_assert0(pic->nb_param_buffers <= pic->param_allocated);
+if (pic->nb_param_buffers == pic->param_allocated) {
+pic->param_buffers =
+av_realloc_array(pic->param_buffers,
+ pic->param_allocated + 16,
+ sizeof(*pic->param_buffers));


Use av_reallocp_array() to avoid leaking the pointer on failure.


+if (!pic->param_buffers)
+return AVERROR(ENOMEM);
+
+pic->param_allocated += 16;
+}
+av_assert0(pic->nb_param_buffers + 1 <= pic->param_allocated);
  
  vas = vaCreateBuffer(ctx->hwctx->display, ctx->va_context,

- type, size, 1, (void*)data, );
+ type, size, 1, (void*)data,
+ >param_buffers[pic->nb_param_buffers]);
  if (vas != VA_STATUS_SUCCESS) {
  av_log(avctx, AV_LOG_ERROR, "Failed to create parameter "
 "buffer (type %d): %d (%s).\n",
@@ -51,14 +62,14 @@ int ff_vaapi_decode_make_param_buffer(AVCodecContext *avctx,
  return AVERROR(EIO);
  }
  
-pic->param_buffers[pic->nb_param_buffers++] = buffer;

-
  av_log(avctx, AV_LOG_DEBUG, "Param buffer (type %d, %zu bytes) "
-   "is %#x.\n", type, size, buffer);
+   "is %#x.\n", type, size, pic->param_buffers[pic->nb_param_buffers]);
+
+++pic->nb_param_buffers;
+
  return 0;
  }
  
-

  int ff_vaapi_decode_make_slice_buffer(AVCodecContext *avctx,
VAAPIDecodePicture *pic,
const void *params_data,
@@ -215,6 +226,8 @@ fail:
  fail_at_end:
  exit:
  pic->nb_param_buffers = 0;
+pic->param_allocated  = 0;
+av_freep(>param_buffers);
  pic->nb_slices= 0;
  pic->slices_allocated = 0;
  av_freep(>slice_buffers);
@@ -228,6 +241,8 @@ int ff_vaapi_decode_cancel(AVCodecContext *avctx,
  ff_vaapi_decode_destroy_buffers(avctx, pic);
  
  pic->nb_param_buffers = 0;

+pic->param_allocated  = 0;
+av_freep(>param_buffers);
  pic->nb_slices= 0;
  pic->slices_allocated = 0;
  av_freep(>slice_buffers);
diff --git a/libavcodec/vaapi_decode.h b/libavcodec/vaapi_decode.h
index 6beda14e52..a41d7ff2ff 100644
--- a/libavcodec/vaapi_decode.h
+++ b/libavcodec/vaapi_decode.h
@@ -32,15 +32,12 @@ static inline VASurfaceID ff_vaapi_get_surface_id(AVFrame 
*pic)
  return (uintptr_t)pic->data[3];
  }
  
-enum {

-MAX_PARAM_BUFFERS = 16,
-};
-
  typedef struct VAAPIDecodePicture {
  VASurfaceID   output_surface;
  
  intnb_param_buffers;

-VABufferIDparam_buffers[MAX_PARAM_BUFFERS];
+VABufferID   *param_buffers;


Previously the array was zeroed at allocation but now it isn't.  Can you 
confirm that that isn't a problem?


+int   param_allocated;


Maybe "nb_param_buffers_allocated" would be clearer.

  
  intnb_slices;

  VABufferID   *slice_buffers;


Thanks,

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

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


Re: [FFmpeg-devel] [PATCH 3/4] avformat/mov_chan: respect channel order when parsing and creating chnl atom

2024-04-01 Thread James Almer

On 4/1/2024 3:56 PM, Marton Balint wrote:

Previously we always assumed that the channels are in native order, even if
they were not. The new channel layout API allows us to signal the proper
channel order, so let's do so.

Signed-off-by: Marton Balint 
---
  libavformat/mov_chan.c | 145 +
  libavformat/mov_chan.h |   5 +-
  tests/ref/fate/mov-mp4-pcm |   2 +-
  3 files changed, 86 insertions(+), 66 deletions(-)


[...]


diff --git a/tests/ref/fate/mov-mp4-pcm b/tests/ref/fate/mov-mp4-pcm
index 6bae8f800b..19a978df95 100644
--- a/tests/ref/fate/mov-mp4-pcm
+++ b/tests/ref/fate/mov-mp4-pcm
@@ -1,4 +1,4 @@
-99ad26b4054794e84bd962a1124cdccf *tests/data/fate/mov-mp4-pcm.mp4
+462668dd69e7ce4fde4934d1d5978531 *tests/data/fate/mov-mp4-pcm.mp4


What changes in the output?


  10587977 tests/data/fate/mov-mp4-pcm.mp4
  #tb 0: 1/44100
  #media_type 0: audio

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

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


Re: [FFmpeg-devel] [PATCH] [v4] avcodec/vaapi_encode: add customized surface alignment

2024-04-01 Thread Mark Thompson

On 27/03/2024 11:14, Araz wrote:

On Fri, Mar 22, 2024 at 11:35 AM Anton Khirnov  wrote:
Why this unnecessary complication? Just use two ints, or two uint8_t's
if you really need to save space, though that also seems unncessary as
this struct is allocated rarely and usually does not live long.


https://github.com/intel/libva/pull/794
The alignment range for log2_size of 4bit is in range of
[2**0, 2**15] = [1, 32768] this is large enough, or other way is to
directly use the alignment value, however I would want it to be in
powers of 2 and not any number, to force this condition, the common
way is to use log2_size(), which is using less bits and forcing
the alignment to be in powers of 2.


It is not necessary to copy exactly the same field layout.

Are you sure that there is never a meaningful non-power-of-two-bytes case?

Given that this is defining new public API to libavutil we don't want to be 
artificially constrained to precisely what happens to be needed in this case.


On Sun, Mar 24, 2024 at 5:38 PM Mark Thompson  wrote:
What other users do you have in mind for this?  (Are you expecting

hwupload to use it as well, say?)


If this is only used in VAAPI encode then I would suggest putting the

query there rather than adding new library API for it.


Also agree with Anton that this form is unnecessarily confusing - just

make it a normal field, don't pack it like this.  (And possibly drop the
log2 as well?  That doesn't seem like it adds anything useful.)

The limitation is for AMD HW, and it is not limited to VAAPI, and for other
HW encoding protocols this limitation also exists.


Does that mean we need this in hwupload and other similar surface-creation 
places or not?

If this is only inside the VAAPI encoder for reconstructed frames then it 
doesn't seem useful to push the information into the public API.

Thanks,

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

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


Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_av1: Set roi_quant_range

2024-04-01 Thread Mark Thompson

On 01/04/2024 19:00, David Rosca wrote:

---
  libavcodec/vaapi_encode_av1.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/libavcodec/vaapi_encode_av1.c b/libavcodec/vaapi_encode_av1.c
index a46b882ab9..02a31b894d 100644
--- a/libavcodec/vaapi_encode_av1.c
+++ b/libavcodec/vaapi_encode_av1.c
@@ -155,6 +155,8 @@ static av_cold int 
vaapi_encode_av1_configure(AVCodecContext *avctx)
  priv->q_idx_idr = priv->q_idx_p = priv->q_idx_b = 128;
  }
  
+ctx->roi_quant_range = AV1_MAX_QUANT;

+
  return 0;
  }
  


Huh, that was missed in the original AV1 encode patch.  Will apply.

Thanks,

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

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


[FFmpeg-devel] [PATCH 4/4] avformat/mov_chan: add support for omitted_channel bitmask in chnl atom

2024-04-01 Thread Marton Balint
Signed-off-by: Marton Balint 
---
 libavformat/mov_chan.c | 43 ++
 libavformat/mov_chan.h |  2 +-
 2 files changed, 24 insertions(+), 21 deletions(-)

diff --git a/libavformat/mov_chan.c b/libavformat/mov_chan.c
index e3cef3f4e8..e591ff031b 100644
--- a/libavformat/mov_chan.c
+++ b/libavformat/mov_chan.c
@@ -367,25 +367,33 @@ static const struct MovChannelLayoutMap* 
find_layout_map(uint32_t tag, const str
  * @param[in]  tagchannel layout tag
  * @return<0 on error
  */
-static int mov_get_channel_layout(AVChannelLayout *ch_layout, uint32_t tag, 
const struct MovChannelLayoutMap *map)
+static int mov_get_channel_layout(AVChannelLayout *ch_layout, uint32_t tag, 
uint64_t omitted_channel_map, const struct MovChannelLayoutMap *map)
 {
-int i, channels;
 const struct MovChannelLayoutMap *layout_map;
 
-channels = tag & 0x;
-
 /* find the channel layout for the specified layout tag */
 layout_map = find_layout_map(tag, map);
 if (layout_map) {
 int ret;
+int map_layout_nb_channels = tag & 0x;
+int nb_channels = ch_layout->nb_channels;
+
+/* Omitted channel bits must not exceed number of channels in map */
+if (omitted_channel_map >> map_layout_nb_channels)
+return AVERROR_INVALIDDATA;
+
 av_channel_layout_uninit(ch_layout);
-ret = av_channel_layout_custom_init(ch_layout, channels);
+ret = av_channel_layout_custom_init(ch_layout, nb_channels);
 if (ret < 0)
 return ret;
-for (i = 0; i < channels; i++) {
-enum AVChannel id = layout_map[i].id;
-ch_layout->u.map[i].id = (id != AV_CHAN_NONE ? id : 
AV_CHAN_UNKNOWN);
+
+for (int i = 0, idx = 0; i < map_layout_nb_channels && idx < 
nb_channels; i++, omitted_channel_map >>= 1) {
+if (!(omitted_channel_map & 1)) {
+enum AVChannel id = layout_map[i].id;
+ch_layout->u.map[idx++].id = (id != AV_CHAN_NONE ? id : 
AV_CHAN_UNKNOWN);
+}
 }
+
 return av_channel_layout_retype(ch_layout, 0, 
AV_CHANNEL_LAYOUT_RETYPE_FLAG_CANONICAL);
 }
 return 0;
@@ -580,7 +588,7 @@ int ff_mov_read_chan(AVFormatContext *s, AVIOContext *pb, 
AVStream *st,
 if (!ch_layout->nb_channels)
 ch_layout->nb_channels = nb_channels;
 if (nb_channels == ch_layout->nb_channels) {
-ret = mov_get_channel_layout(ch_layout, layout_tag, 
mov_ch_layout_map);
+ret = mov_get_channel_layout(ch_layout, layout_tag, 0, 
mov_ch_layout_map);
 if (ret < 0)
 return ret;
 } else {
@@ -741,16 +749,17 @@ int ff_mov_get_channel_config_from_layout(const 
AVChannelLayout *layout, int *co
 return 0;
 }
 
-int ff_mov_get_channel_layout_from_config(int config, AVChannelLayout *layout)
+int ff_mov_get_channel_layout_from_config(int config, AVChannelLayout *layout, 
uint64_t omitted_channel_map)
 {
 if (config > 0) {
 uint32_t layout_tag;
+int nb_omitted_channels = av_popcount64(omitted_channel_map);
 
-if (layout->nb_channels <= 0 || layout->nb_channels > UINT16_MAX)
+if (layout->nb_channels <= 0 || layout->nb_channels > UINT16_MAX - 
nb_omitted_channels)
 return AVERROR_INVALIDDATA;
 
-layout_tag = (config << 16) | layout->nb_channels;
-return mov_get_channel_layout(layout, layout_tag, iso_ch_layout_map);
+layout_tag = (config << 16) | (layout->nb_channels + 
nb_omitted_channels);
+return mov_get_channel_layout(layout, layout_tag, omitted_channel_map, 
iso_ch_layout_map);
 }
 return 1;
 }
@@ -826,13 +835,7 @@ int ff_mov_read_chnl(AVFormatContext *s, AVIOContext *pb, 
AVStream *st)
 return ret;
 } else {
 uint64_t omitted_channel_map = avio_rb64(pb);
-
-if (omitted_channel_map) {
-avpriv_request_sample(s, "omitted_channel_map 0x%" PRIx64 " != 
0",
-  omitted_channel_map);
-return AVERROR_PATCHWELCOME;
-}
-ret = ff_mov_get_channel_layout_from_config(layout, 
>codecpar->ch_layout);
+ret = ff_mov_get_channel_layout_from_config(layout, 
>codecpar->ch_layout, omitted_channel_map);
 if (ret < 0)
 return ret;
 }
diff --git a/libavformat/mov_chan.h b/libavformat/mov_chan.h
index 604395d7d3..ea8be47196 100644
--- a/libavformat/mov_chan.h
+++ b/libavformat/mov_chan.h
@@ -176,7 +176,7 @@ int ff_mov_get_channel_config_from_layout(const 
AVChannelLayout *layout, int *co
  * 0  if the config was found
  * <0 on error
  */
-int ff_mov_get_channel_layout_from_config(int config, AVChannelLayout *layout);
+int ff_mov_get_channel_layout_from_config(int config, AVChannelLayout *layout, 
uint64_t omitted_channel_map);
 
 /**
  * Get ISO/IEC 23001-8 

[FFmpeg-devel] [PATCH 3/4] avformat/mov_chan: respect channel order when parsing and creating chnl atom

2024-04-01 Thread Marton Balint
Previously we always assumed that the channels are in native order, even if
they were not. The new channel layout API allows us to signal the proper
channel order, so let's do so.

Signed-off-by: Marton Balint 
---
 libavformat/mov_chan.c | 145 +
 libavformat/mov_chan.h |   5 +-
 tests/ref/fate/mov-mp4-pcm |   2 +-
 3 files changed, 86 insertions(+), 66 deletions(-)

diff --git a/libavformat/mov_chan.c b/libavformat/mov_chan.c
index 9ee896f229..e3cef3f4e8 100644
--- a/libavformat/mov_chan.c
+++ b/libavformat/mov_chan.c
@@ -74,6 +74,46 @@ enum {
 c_Haptic = AV_CHAN_NONE,
 };
 
+enum {
+iso_L= AV_CHAN_FRONT_LEFT,
+iso_R= AV_CHAN_FRONT_RIGHT,
+iso_C= AV_CHAN_FRONT_CENTER,
+iso_LFE  = AV_CHAN_LOW_FREQUENCY,
+iso_Lsr  = AV_CHAN_BACK_LEFT,
+iso_Rsr  = AV_CHAN_BACK_RIGHT,
+iso_Lc   = AV_CHAN_FRONT_LEFT_OF_CENTER,
+iso_Rc   = AV_CHAN_FRONT_RIGHT_OF_CENTER,
+iso_Cs   = AV_CHAN_BACK_CENTER,
+/* Side and surround are not exactly the same, but in order to have
+ * consistent 5.1/7.1 layouts we map them to the side channels. */
+iso_Ls   = AV_CHAN_SIDE_LEFT,
+iso_Lss  = AV_CHAN_SIDE_LEFT,
+iso_Rs   = AV_CHAN_SIDE_RIGHT,
+iso_Rss  = AV_CHAN_SIDE_RIGHT,
+iso_Ts   = AV_CHAN_TOP_CENTER,
+iso_Lv   = AV_CHAN_TOP_FRONT_LEFT,
+iso_Cv   = AV_CHAN_TOP_FRONT_CENTER,
+iso_Rv   = AV_CHAN_TOP_FRONT_RIGHT,
+iso_Lvr  = AV_CHAN_TOP_BACK_LEFT,
+iso_Cvr  = AV_CHAN_TOP_BACK_CENTER,
+iso_Rvr  = AV_CHAN_TOP_BACK_RIGHT,
+//   = AV_CHAN_STEREO_LEFT,
+//   = AV_CHAN_STEREO_RIGHT,
+iso_Lw   = AV_CHAN_WIDE_LEFT,
+iso_Rw   = AV_CHAN_WIDE_RIGHT,
+iso_Lsd  = AV_CHAN_SURROUND_DIRECT_LEFT,
+iso_Rsd  = AV_CHAN_SURROUND_DIRECT_RIGHT,
+iso_LFE2 = AV_CHAN_LOW_FREQUENCY_2,
+iso_Lvss = AV_CHAN_TOP_SIDE_LEFT,
+iso_Rvss = AV_CHAN_TOP_SIDE_RIGHT,
+iso_Cb   = AV_CHAN_BOTTOM_FRONT_CENTER,
+iso_Lb   = AV_CHAN_BOTTOM_FRONT_LEFT,
+iso_Rb   = AV_CHAN_BOTTOM_FRONT_RIGHT,
+/* The following have no exact counterparts */
+iso_Lvs  = AV_CHAN_NONE,
+iso_Rvs  = AV_CHAN_NONE,
+};
+
 struct MovChannelLayoutMap {
 union {
 uint32_t tag;
@@ -103,6 +143,10 @@ static int nonconst_expr(void) {
 #define CHLIST21(_tag, _1, _2, _3, _4, _5, _6, _7, _8, _9, _10, _11, _12, _13, 
_14, _15, _16, _17, _18, _19, _20, _21) \
 CHLIST(_tag, 21, ID(_1),  ID(_2),  ID(_3),  ID(_4),  ID(_5),  ID(_6),  
ID(_7),  ID(_8),  ID(_9),  ID(_10), \
  ID(_11), ID(_12), ID(_13), ID(_14), ID(_15), ID(_16), 
ID(_17), ID(_18), ID(_19), ID(_20), ID(_21))
+#define CHLIST24(_tag, _1, _2, _3, _4, _5, _6, _7, _8, _9, _10, _11, _12, _13, 
_14, _15, _16, _17, _18, _19, _20, _21, _22, _23, _24) \
+CHLIST(_tag, 24, ID(_1),  ID(_2),  ID(_3),  ID(_4),  ID(_5),  ID(_6),  
ID(_7),  ID(_8),  ID(_9),  ID(_10), \
+ ID(_11), ID(_12), ID(_13), ID(_14), ID(_15), ID(_16), 
ID(_17), ID(_18), ID(_19), ID(_20), \
+ ID(_21), ID(_22), ID(_23), ID(_24))
 
 static const struct MovChannelLayoutMap mov_ch_layout_map[] = {
 CHLIST01( MOV_CH_LAYOUT_MONO, C ),
@@ -190,6 +234,29 @@ static const struct MovChannelLayoutMap 
mov_ch_layout_map[] = {
 { {0} },
 };
 
+#undef ID
+#undef TAG
+#define ID(_0){.id = iso_##_0}
+#define TAG(_tag, _cnt)   {.tag = (_tag << 16) | _cnt}
+
+/* ISO/IEC 23001-8 */
+static const struct MovChannelLayoutMap iso_ch_layout_map[] = {
+CHLIST01(  1,  C ),
+CHLIST02(  2,  L,   R   ),
+CHLIST03(  3,  C,   L,   R   ),
+CHLIST04(  4,  C,   L,   R,Cs  ),
+CHLIST05(  5,  C,   L,   R,Ls,   Rs  ),
+CHLIST06(  6,  C,   L,   R,Ls,   Rs,   LFE ),
+CHLIST08(  7,  C,   Lc,  Rc,   L,R,Ls,   Rs,   LFE ),
+CHLIST03(  9,  L,   R,   Cs  ),
+CHLIST04( 10,  L,   R,   Ls,   Rs  ),
+CHLIST07( 11,  C,   L,   R,Ls,   Rs,   Cs,   LFE ),
+CHLIST08( 12,  C,   L,   R,Ls,   Rs,   Lsr,  Rsr,  LFE ),
+CHLIST24( 13,  C,   Lc,  Rc,   L,R,Lss,  Rss,  Lsr,  Rsr,  Cs,  
LFE,  LFE2,  Cv,  Lv,  Rv,  Lvss,  Rvss,  Ts,  Lvr,  Rvr,  Cvr,  Cb,  Lb,  Rb),
+CHLIST08( 14,  C,   L,   R,Ls,   Rs,   LFE,  Lv,   Rv),
+{ {0} },
+};
+
 static const enum MovChannelLayoutTag mov_ch_layouts_aac[] = {
 MOV_CH_LAYOUT_MONO,
 MOV_CH_LAYOUT_STEREO,
@@ -529,60 +596,6 @@ out:
 return ret;
 }
 
-/* ISO/IEC 23001-8, 8.2 */
-static const AVChannelLayout iso_channel_configuration[] = {
-// 0: any setup
-{0},
-
-// 1: centre front
-AV_CHANNEL_LAYOUT_MONO,
-
-// 2: left front, right front
-AV_CHANNEL_LAYOUT_STEREO,
-
-// 3: centre front, left front, right front
-AV_CHANNEL_LAYOUT_SURROUND,
-
-// 4: centre front, left front, right front, rear centre
-AV_CHANNEL_LAYOUT_4POINT0,
-
-// 5: centre front, left front, right front, left surround, right surround
-AV_CHANNEL_LAYOUT_5POINT0,
-
-// 6: 5 + LFE
-   

[FFmpeg-devel] [PATCH 2/4] avformat/mov_chan: factorize some layout map search functions

2024-04-01 Thread Marton Balint
Signed-off-by: Marton Balint 
---
 libavformat/mov_chan.c | 62 --
 1 file changed, 35 insertions(+), 27 deletions(-)

diff --git a/libavformat/mov_chan.c b/libavformat/mov_chan.c
index 6ccc26b3f1..9ee896f229 100644
--- a/libavformat/mov_chan.c
+++ b/libavformat/mov_chan.c
@@ -187,6 +187,7 @@ static const struct MovChannelLayoutMap mov_ch_layout_map[] 
= {
 CHLIST09( MOV_CH_LAYOUT_DTS_8_1_B,Lc,  C,   Rc,   L,R,
Ls,Cs,   Rs,   LFE ),
 CHLIST16( MOV_CH_LAYOUT_TMH_10_2_STD, L,   R,   C,Vhc,  Lsd,  
Rsd,   Ls,   Rs,   Vhl,  Vhr,  Lw,  Rw,  Csd,  Cs,  LFE1,  LFE2),
 CHLIST21( MOV_CH_LAYOUT_TMH_10_2_FULL,L,   R,   C,Vhc,  Lsd,  
Rsd,   Ls,   Rs,   Vhl,  Vhr,  Lw,  Rw,  Csd,  Cs,  LFE1,  LFE2,  Lc,  Rc,  HI, 
 VI,  Haptic),
+{ {0} },
 };
 
 static const enum MovChannelLayoutTag mov_ch_layouts_aac[] = {
@@ -283,11 +284,11 @@ static const struct {
 { AV_CODEC_ID_NONE,NULL},
 };
 
-static const struct MovChannelLayoutMap* find_layout_map(uint32_t tag)
+static const struct MovChannelLayoutMap* find_layout_map(uint32_t tag, const 
struct MovChannelLayoutMap *map)
 {
-for (int i = 0; i < FF_ARRAY_ELEMS(mov_ch_layout_map); i += 1 + 
(mov_ch_layout_map[i].tag & 0x))
-if (mov_ch_layout_map[i].tag == tag)
-return _ch_layout_map[i + 1];
+for (int i = 0; map[i].tag & 0x; i += 1 + (map[i].tag & 0x))
+if (map[i].tag == tag)
+return [i + 1];
 return NULL;
 }
 
@@ -299,7 +300,7 @@ static const struct MovChannelLayoutMap* 
find_layout_map(uint32_t tag)
  * @param[in]  tagchannel layout tag
  * @return<0 on error
  */
-static int mov_get_channel_layout(AVChannelLayout *ch_layout, uint32_t tag)
+static int mov_get_channel_layout(AVChannelLayout *ch_layout, uint32_t tag, 
const struct MovChannelLayoutMap *map)
 {
 int i, channels;
 const struct MovChannelLayoutMap *layout_map;
@@ -307,7 +308,7 @@ static int mov_get_channel_layout(AVChannelLayout 
*ch_layout, uint32_t tag)
 channels = tag & 0x;
 
 /* find the channel layout for the specified layout tag */
-layout_map = find_layout_map(tag);
+layout_map = find_layout_map(tag, map);
 if (layout_map) {
 int ret;
 av_channel_layout_uninit(ch_layout);
@@ -361,12 +362,34 @@ static uint32_t mov_get_channel_label(enum AVChannel 
channel)
 return 0;
 }
 
+static int is_layout_valid_for_tag(const AVChannelLayout *ch_layout, uint32_t 
tag, const struct MovChannelLayoutMap *map)
+{
+const struct MovChannelLayoutMap *layout_map;
+int channels = ch_layout->nb_channels;
+
+/* get the layout map based on the channel count */
+if ((tag & 0x) != channels)
+return 0;
+
+layout_map = find_layout_map(tag, map);
+if (layout_map) {
+int i;
+for (i = 0; i < channels; i++) {
+if (av_channel_layout_channel_from_index(ch_layout, i) != 
layout_map[i].id)
+break;
+}
+if (i == channels)
+return 1;
+}
+return 0;
+}
+
 int ff_mov_get_channel_layout_tag(const AVCodecParameters *par,
   uint32_t *layout,
   uint32_t *bitmap,
   uint32_t **pchannel_desc)
 {
-int i, j;
+int i;
 uint32_t tag = 0;
 const enum MovChannelLayoutTag *layouts = NULL;
 
@@ -379,26 +402,11 @@ int ff_mov_get_channel_layout_tag(const AVCodecParameters 
*par,
 layouts = mov_codec_ch_layouts[i].layouts;
 
 if (layouts) {
-int channels;
-const struct MovChannelLayoutMap *layout_map;
-
-/* get the layout map based on the channel count */
-channels = par->ch_layout.nb_channels;
-
 /* find the layout tag for the specified channel layout */
-for (i = 0; layouts[i] != 0; i++) {
-if ((layouts[i] & 0x) != channels)
-continue;
-layout_map = find_layout_map(layouts[i]);
-if (layout_map) {
-for (j = 0; j < channels; j++) {
-if (av_channel_layout_channel_from_index(>ch_layout, 
j) != layout_map[j].id)
-break;
-}
-if (j == channels)
-break;
-}
-}
+for (i = 0; layouts[i] != 0; i++)
+if (is_layout_valid_for_tag(>ch_layout, layouts[i], 
mov_ch_layout_map))
+break;
+
 tag = layouts[i];
 }
 
@@ -505,7 +513,7 @@ int ff_mov_read_chan(AVFormatContext *s, AVIOContext *pb, 
AVStream *st,
 if (!ch_layout->nb_channels)
 ch_layout->nb_channels = nb_channels;
 if (nb_channels == ch_layout->nb_channels) {
-ret = mov_get_channel_layout(ch_layout, layout_tag);
+ret = mov_get_channel_layout(ch_layout, layout_tag, 
mov_ch_layout_map);
  

[FFmpeg-devel] [PATCH 1/4] avformat/mov_chan: check channel count at compile time by using a nonconst expression

2024-04-01 Thread Marton Balint
If the channel tag does not match the number of channels, the constant
expression evaluation should fail.

Signed-off-by: Marton Balint 
---
 libavformat/mov_chan.c | 48 +++---
 1 file changed, 22 insertions(+), 26 deletions(-)

diff --git a/libavformat/mov_chan.c b/libavformat/mov_chan.c
index e7d181d71f..6ccc26b3f1 100644
--- a/libavformat/mov_chan.c
+++ b/libavformat/mov_chan.c
@@ -81,24 +81,28 @@ struct MovChannelLayoutMap {
 };
 };
 
-#define TAG(_0)  {.tag = _0}
-#define ID(_0)   {.id = c_##_0}
-#define CHLIST(_0, ...)  TAG(_0), __VA_ARGS__
-#define CHLIST01(_0, _1) CHLIST(_0, ID(_1))
-#define CHLIST02(_0, _1, _2) CHLIST(_0, ID(_1), 
ID(_2))
-#define CHLIST03(_0, _1, _2, _3) CHLIST(_0, ID(_1), 
ID(_2), ID(_3))
-#define CHLIST04(_0, _1, _2, _3, _4) CHLIST(_0, ID(_1), 
ID(_2), ID(_3), ID(_4))
-#define CHLIST05(_0, _1, _2, _3, _4, _5) CHLIST(_0, ID(_1), 
ID(_2), ID(_3), ID(_4), ID(_5))
-#define CHLIST06(_0, _1, _2, _3, _4, _5, _6) CHLIST(_0, ID(_1), 
ID(_2), ID(_3), ID(_4), ID(_5), ID(_6))
-#define CHLIST07(_0, _1, _2, _3, _4, _5, _6, _7) CHLIST(_0, ID(_1), 
ID(_2), ID(_3), ID(_4), ID(_5), ID(_6), ID(_7))
-#define CHLIST08(_0, _1, _2, _3, _4, _5, _6, _7, _8) CHLIST(_0, ID(_1), 
ID(_2), ID(_3), ID(_4), ID(_5), ID(_6), ID(_7), ID(_8))
-#define CHLIST09(_0, _1, _2, _3, _4, _5, _6, _7, _8, _9) CHLIST(_0, ID(_1), 
ID(_2), ID(_3), ID(_4), ID(_5), ID(_6), ID(_7), ID(_8), ID(_9))
-#define CHLIST16(_0, _1, _2, _3, _4, _5, _6, _7, _8, _9, _10, _11, _12, _13, 
_14, _15, _16) \
-CHLIST(_0, ID(_1),  ID(_2),  ID(_3),  ID(_4),  ID(_5),  ID(_6), ID(_7), 
ID(_8), ID(_9), ID(_10), \
-   ID(_11), ID(_12), ID(_13), ID(_14), ID(_15), ID(_16))
-#define CHLIST21(_0, _1, _2, _3, _4, _5, _6, _7, _8, _9, _10, _11, _12, _13, 
_14, _15, _16, _17, _18, _19, _20, _21) \
-CHLIST(_0, ID(_1),  ID(_2),  ID(_3),  ID(_4),  ID(_5),  ID(_6),  ID(_7),  
ID(_8),  ID(_9),  ID(_10), \
-   ID(_11), ID(_12), ID(_13), ID(_14), ID(_15), ID(_16), ID(_17), 
ID(_18), ID(_19), ID(_20), ID(_21))
+static int nonconst_expr(void) {
+return 0;
+}
+
+#define TAG(_tag, _cnt){.tag = (_tag & 
0x) == _cnt ? _tag : nonconst_expr()}
+#define ID(_0) {.id = c_##_0}
+#define CHLIST(_tag, _cnt, ...)TAG(_tag, _cnt), 
__VA_ARGS__
+#define CHLIST01(_tag, _1) CHLIST(_tag, 1, 
ID(_1))
+#define CHLIST02(_tag, _1, _2) CHLIST(_tag, 2, 
ID(_1), ID(_2))
+#define CHLIST03(_tag, _1, _2, _3) CHLIST(_tag, 3, 
ID(_1), ID(_2), ID(_3))
+#define CHLIST04(_tag, _1, _2, _3, _4) CHLIST(_tag, 4, 
ID(_1), ID(_2), ID(_3), ID(_4))
+#define CHLIST05(_tag, _1, _2, _3, _4, _5) CHLIST(_tag, 5, 
ID(_1), ID(_2), ID(_3), ID(_4), ID(_5))
+#define CHLIST06(_tag, _1, _2, _3, _4, _5, _6) CHLIST(_tag, 6, 
ID(_1), ID(_2), ID(_3), ID(_4), ID(_5), ID(_6))
+#define CHLIST07(_tag, _1, _2, _3, _4, _5, _6, _7) CHLIST(_tag, 7, 
ID(_1), ID(_2), ID(_3), ID(_4), ID(_5), ID(_6), ID(_7))
+#define CHLIST08(_tag, _1, _2, _3, _4, _5, _6, _7, _8) CHLIST(_tag, 8, 
ID(_1), ID(_2), ID(_3), ID(_4), ID(_5), ID(_6), ID(_7), ID(_8))
+#define CHLIST09(_tag, _1, _2, _3, _4, _5, _6, _7, _8, _9) CHLIST(_tag, 9, 
ID(_1), ID(_2), ID(_3), ID(_4), ID(_5), ID(_6), ID(_7), ID(_8), ID(_9))
+#define CHLIST16(_tag, _1, _2, _3, _4, _5, _6, _7, _8, _9, _10, _11, _12, _13, 
_14, _15, _16) \
+CHLIST(_tag, 16, ID(_1),  ID(_2),  ID(_3),  ID(_4),  ID(_5),  ID(_6), 
ID(_7), ID(_8), ID(_9), ID(_10), \
+ ID(_11), ID(_12), ID(_13), ID(_14), ID(_15), ID(_16))
+#define CHLIST21(_tag, _1, _2, _3, _4, _5, _6, _7, _8, _9, _10, _11, _12, _13, 
_14, _15, _16, _17, _18, _19, _20, _21) \
+CHLIST(_tag, 21, ID(_1),  ID(_2),  ID(_3),  ID(_4),  ID(_5),  ID(_6),  
ID(_7),  ID(_8),  ID(_9),  ID(_10), \
+ ID(_11), ID(_12), ID(_13), ID(_14), ID(_15), ID(_16), 
ID(_17), ID(_18), ID(_19), ID(_20), ID(_21))
 
 static const struct MovChannelLayoutMap mov_ch_layout_map[] = {
 CHLIST01( MOV_CH_LAYOUT_MONO, C ),
@@ -281,14 +285,6 @@ static const struct {
 
 static const struct MovChannelLayoutMap* find_layout_map(uint32_t tag)
 {
-#if defined(ASSERT_LEVEL) && ASSERT_LEVEL > 1
-{
-int i;
-for (i = 0; i < FF_ARRAY_ELEMS(mov_ch_layout_map); i += 1 + 
(mov_ch_layout_map[i].tag & 0x))
-av_assert2(mov_ch_layout_map[i].tag & 0x);
-av_assert2(i == FF_ARRAY_ELEMS(mov_ch_layout_map));
-}
-#endif
 for (int i = 0; i < FF_ARRAY_ELEMS(mov_ch_layout_map); i += 1 + 

Re: [FFmpeg-devel] [PATCH] avcodec/mfenc: expose more properties of the media foundation encoder

2024-04-01 Thread Mark Thompson

On 01/04/2024 17:25, Mark Samuelson wrote:

On Mon, Apr 1, 2024 at 10:06 AM Mark Thompson  wrote:


On 28/03/2024 12:34, Mark Samuelson wrote:

Thank you for the notes, here is a new patch that incorporates your

suggestions.  You are right, the default value of 12 for gop_size is
suprising, I didn't know about it before now.


---
   libavcodec/mf_utils.h |  5 +
   libavcodec/mfenc.c| 33 +++--
   2 files changed, 32 insertions(+), 6 deletions(-)


Patch looks good.

I did a bit of testing with the Microsoft H.264 MFT: GOP size and

compression level work as expected, and VBV parameters seem to be doing
something sensible.


Under what conditions are you expecting global_quality ->

AVEncVideoEncodeQP to do anything, though?  When I set it alone the output
was always identical regardless of what value I set > it to.  (Including
with "-rate_control quality".)


Thanks,

- Mark




I have also had issues making the Media Foundation encoder respect that
value.  I put it in there so that I could easily test it, because I was
having issues with the existing opt_enc_quality -> AVEncCommonQuality.  I
figured it was better to leave it in so people can experiment with it.


Fair, these options are not particularly consistent between different encoder 
MFT implementations.

I will apply this patch tomorrow unless there are any more comments on it.

Thanks,

- Mark
___
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/5] avcodec/ppc/hpeldsp_altivec: Fix left-shift of negative number

2024-04-01 Thread Andreas Rheinhardt
Andreas Rheinhardt:
> It is UB and affected e.g. the vp5 and vp61 FATE tests:
> https://fate.ffmpeg.org/report.cgi?time=20240327083327=ppc-linux-gcc-13.2-ubsan-altivec-qemu
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/ppc/hpeldsp_altivec.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/ppc/hpeldsp_altivec.c 
> b/libavcodec/ppc/hpeldsp_altivec.c
> index a531b6b6ec..4bf6b28ed6 100644
> --- a/libavcodec/ppc/hpeldsp_altivec.c
> +++ b/libavcodec/ppc/hpeldsp_altivec.c
> @@ -41,9 +41,9 @@ void ff_put_pixels16_altivec(uint8_t *block, const uint8_t 
> *pixels, ptrdiff_t li
>  register vector unsigned char pixelsv1D;
>  
>  int i;
> -register ptrdiff_t line_size_2 = line_size << 1;
> +register ptrdiff_t line_size_2 = line_size * (1 << 1);
>  register ptrdiff_t line_size_3 = line_size + line_size_2;
> -register ptrdiff_t line_size_4 = line_size << 2;
> +register ptrdiff_t line_size_4 = line_size * (1 << 2);
>  
>  // hand-unrolling the loop by 4 gains about 15%
>  // mininum execution time goes from 74 to 60 cycles

Will apply the remainder of 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 01/10] avcodec/libvpxenc: Avoid unused-variable warning if VP9 enc is disabled

2024-04-01 Thread Andreas Rheinhardt
James Zern via ffmpeg-devel:
> On Sat, Mar 30, 2024 at 10:30 PM Andreas Rheinhardt
>  wrote:
>>
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>>  libavcodec/libvpxenc.c | 7 ---
>>  1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
>> index 635cdf7a0e..bcbdc4981e 100644
>> --- a/libavcodec/libvpxenc.c
>> +++ b/libavcodec/libvpxenc.c
>> @@ -49,6 +49,9 @@
>>  #include "libavutil/opt.h"
>>  #include "libavutil/pixdesc.h"
>>
>> +#define IS_VP9(avctx) (CONFIG_LIBVPX_VP9_ENCODER && avctx->codec_id == 
>> AV_CODEC_ID_VP9)
>> +#define IS_VP8(avctx) (CONFIG_LIBVPX_VP8_ENCODER && avctx->codec_id == 
>> AV_CODEC_ID_VP8)
>> +
>>  /**
>>   * Portion of struct vpx_codec_cx_pkt from vpx_encoder.h.
>>   * One encoded frame returned from the library.
>> @@ -359,8 +362,7 @@ static int frame_data_submit(AVCodecContext *avctx, 
>> AVFifo *fifo,
>>  FrameData fd = { .pts = frame->pts };
>>  int ret;
>>
>> -#if CONFIG_LIBVPX_VP9_ENCODER
>> -if (avctx->codec_id == AV_CODEC_ID_VP9 &&
>> +if (IS_VP9(avctx) &&
> 
> This works and I think the style is largely prevalent in other code.
> Given the current structure you could move the enccfg declaration to
> this block as an alternative.

The latter would entail either opening a new block for the #if part or
hoping (due to -Wdeclaration-after-statement) that this #if block stays
at the start of this function. I prefer my approach above to either of
these alternatives (a third alternative would be to avoid the enccfg
variable altogether and to check ctx->encoder.config.enc->g_bit_depth
instead; another alternative is av_unused). Just tell me which
alternative you prefer.

> 
>>  // Keep HDR10+ if it has bit depth higher than 8 and
>>  // it has PQ trc (SMPTE2084).
>>  enccfg->g_bit_depth > 8 && avctx->color_trc == AVCOL_TRC_SMPTE2084) 
>> {
>> @@ -372,7 +374,6 @@ static int frame_data_submit(AVCodecContext *avctx, 
>> AVFifo *fifo,
>>  return AVERROR(ENOMEM);
>>  }
>>  }
>> -#endif
>>
>>  fd.duration = frame->duration;
>>  fd.frame_opaque = frame->opaque;
>> --
>> 2.40.1

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

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


Re: [FFmpeg-devel] [PATCH 01/10] avcodec/libvpxenc: Avoid unused-variable warning if VP9 enc is disabled

2024-04-01 Thread James Zern via ffmpeg-devel
On Sat, Mar 30, 2024 at 10:30 PM Andreas Rheinhardt
 wrote:
>
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/libvpxenc.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> index 635cdf7a0e..bcbdc4981e 100644
> --- a/libavcodec/libvpxenc.c
> +++ b/libavcodec/libvpxenc.c
> @@ -49,6 +49,9 @@
>  #include "libavutil/opt.h"
>  #include "libavutil/pixdesc.h"
>
> +#define IS_VP9(avctx) (CONFIG_LIBVPX_VP9_ENCODER && avctx->codec_id == 
> AV_CODEC_ID_VP9)
> +#define IS_VP8(avctx) (CONFIG_LIBVPX_VP8_ENCODER && avctx->codec_id == 
> AV_CODEC_ID_VP8)
> +
>  /**
>   * Portion of struct vpx_codec_cx_pkt from vpx_encoder.h.
>   * One encoded frame returned from the library.
> @@ -359,8 +362,7 @@ static int frame_data_submit(AVCodecContext *avctx, 
> AVFifo *fifo,
>  FrameData fd = { .pts = frame->pts };
>  int ret;
>
> -#if CONFIG_LIBVPX_VP9_ENCODER
> -if (avctx->codec_id == AV_CODEC_ID_VP9 &&
> +if (IS_VP9(avctx) &&

This works and I think the style is largely prevalent in other code.
Given the current structure you could move the enccfg declaration to
this block as an alternative.

>  // Keep HDR10+ if it has bit depth higher than 8 and
>  // it has PQ trc (SMPTE2084).
>  enccfg->g_bit_depth > 8 && avctx->color_trc == AVCOL_TRC_SMPTE2084) {
> @@ -372,7 +374,6 @@ static int frame_data_submit(AVCodecContext *avctx, 
> AVFifo *fifo,
>  return AVERROR(ENOMEM);
>  }
>  }
> -#endif
>
>  fd.duration = frame->duration;
>  fd.frame_opaque = frame->opaque;
> --
> 2.40.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] web: add a news entry for 7.0

2024-04-01 Thread Anton Khirnov
---
Now mentioning that vvcdec is experimental, as suggested by Martin on
IRC.
---
 src/index | 28 
 1 file changed, 28 insertions(+)

diff --git a/src/index b/src/index
index 1eb5524..2deb6af 100644
--- a/src/index
+++ b/src/index
@@ -35,6 +35,34 @@
 News
   
 
+  April xxth, 2024, FFmpeg 7.0 "XXX"
+  
+  A new major release, FFmpeg 7.0 
"XXX",
+  is now available for download. The most noteworthy changes for most users are
+  a native VVC decoder (currently experimental, until 
more
+  fuzzing is done), IAMF support, or a
+  multi-threaded ffmpeg CLI tool.
+  
+
+  
+  This release is not backwards compatible, removing APIs deprecated 
before 6.0.
+  The biggest change for most library callers will be the removal of the old 
bitmask-based
+  channel layout API, replaced by the AVChannelLayout API 
allowing such
+  features as custom channel ordering, or Ambisonics. Certain deprecated 
ffmpeg
+  CLI options were also removed, and a C11-compliant compiler is now required 
to build
+  the code.
+  
+
+  
+  As usual, there is also a number of new supported formats and codecs, new 
filters, APIs,
+  and countless smaller features and bugfixes. Compared to 6.0, the 
git repository
+  contains almost 2000 new commits by 100 authors, touching 
10 lines in
+  2000 files  thanks to everyone who contributed. See the
+  https://git.videolan.org/?p=ffmpeg.git;a=blob_plain;f=Changelog;hb=n7.0;>Changelog,
+  https://git.videolan.org/?p=ffmpeg.git;a=blob_plain;f=doc/APIchanges;hb=n7.0;>APIchanges,
+  and the git log for more comprehensive lists of changes.
+  
+
   January 3rd, 2024, native VVC decoder
   
   The libavcodec library now contains a native VVC (Versatile 
Video Coding)
-- 
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] lavc/vaapi_encode_av1: Set roi_quant_range

2024-04-01 Thread David Rosca
---
 libavcodec/vaapi_encode_av1.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavcodec/vaapi_encode_av1.c b/libavcodec/vaapi_encode_av1.c
index a46b882ab9..02a31b894d 100644
--- a/libavcodec/vaapi_encode_av1.c
+++ b/libavcodec/vaapi_encode_av1.c
@@ -155,6 +155,8 @@ static av_cold int 
vaapi_encode_av1_configure(AVCodecContext *avctx)
 priv->q_idx_idr = priv->q_idx_p = priv->q_idx_b = 128;
 }
 
+ctx->roi_quant_range = AV1_MAX_QUANT;
+
 return 0;
 }
 
-- 
2.44.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] [RFC/PATCH] web: add a news entry for 7.0

2024-04-01 Thread Anton Khirnov
---
 src/index | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/src/index b/src/index
index 1eb5524..ba4f0e8 100644
--- a/src/index
+++ b/src/index
@@ -35,6 +35,33 @@
 News
   
 
+  April xxth, 2024, FFmpeg 7.0 "XXX"
+  
+  A new major release, FFmpeg 7.0 
"XXX",
+  is now available for download. The most noteworthy changes for most users are
+  a native VVC decoder, IAMF support,
+  or a multi-threaded ffmpeg CLI 
tool.
+  
+
+  
+  This release is not backwards compatible, removing APIs deprecated 
before 6.0.
+  The biggest change for most library callers will be the removal of the old 
bitmask-based
+  channel layout API, replaced by the AVChannelLayout API 
allowing such
+  features as custom channel ordering, or Ambisonics. Certain deprecated 
ffmpeg
+  CLI options were also removed, and a C11-compliant compiler is now required 
to build
+  the code.
+  
+
+  
+  As usual, there is also a number of new supported formats and codecs, new 
filters, APIs,
+  and countless smaller features and bugfixes. Compared to 6.0, the 
git repository
+  contains almost 2000 new commits by 100 authors, touching 
10 lines in
+  2000 files  thanks to everyone who contributed. See the
+  https://git.videolan.org/?p=ffmpeg.git;a=blob_plain;f=Changelog;hb=n7.0;>Changelog,
+  https://git.videolan.org/?p=ffmpeg.git;a=blob_plain;f=doc/APIchanges;hb=n7.0;>APIchanges,
+  and the git log for more comprehensive lists of changes.
+  
+
   January 3rd, 2024, native VVC decoder
   
   The libavcodec library now contains a native VVC (Versatile 
Video Coding)
-- 
2.43.0

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

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


Re: [FFmpeg-devel] [PATCH 1/3] avcodec/vvc/vvcdec: Do not submit frames without VVCFrameThread

2024-04-01 Thread Michael Niedermayer
On Fri, Jan 26, 2024 at 10:46:49PM +0100, Michael Niedermayer wrote:
> Such frames will crash when pthread functions are called on the NULL pointer
> 
> Fixes: member access within null pointer of type 'VVCFrameThread' (aka 
> 'struct VVCFrameThread')
> Fixes: 
> 65160/clusterfuzz-testcase-minimized-ffmpeg_BSF_VVC_METADATA_fuzzer-4665241535119360
>  (partly)
> Fixes: 
> 65636/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VVC_fuzzer-5394745824182272
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/vvc/vvcdec.c | 3 +++
>  1 file changed, 3 insertions(+)

will apply

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

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.


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/mpegts: Reset local nb_prg on add_program() failure

2024-04-01 Thread Michael Niedermayer
On Sun, Mar 10, 2024 at 07:07:19PM +0100, Michael Niedermayer wrote:
> add_program() will deallocate the whole array on failure so
> we must clear nb_prgs
> 
> Fixes: null pointer dereference
> Fixes: crash-35a3b39ddcc5babeeb005b7399a3a1217c8781bc
> 
> Found-by: Catena cyber
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/mpegts.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

will apply

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

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway


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

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


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

2024-04-01 Thread Michael Niedermayer
On Sat, Mar 16, 2024 at 10:26:35PM +0100, Michael Niedermayer wrote:
> 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(-)

will apply

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

If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.


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 3/3] avformat/aiffdec: Check for previously set channels

2024-04-01 Thread Michael Niedermayer
On Sat, Mar 23, 2024 at 12:08:18AM +0100, Michael Niedermayer wrote:
> Fixes: out of array access (av_channel_layout_copy())
> Fixes: 
> 67087/clusterfuzz-testcase-minimized-ffmpeg_dem_AIFF_fuzzer-4920720268263424
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/aiffdec.c | 2 ++
>  1 file changed, 2 insertions(+)

will apply

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

No great genius has ever existed without some touch of madness. -- Aristotle


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/movenc: Check that cts fits in 32bit

2024-04-01 Thread Michael Niedermayer
On Mon, Apr 01, 2024 at 12:45:36PM -0300, James Almer wrote:
> On 4/1/2024 12:38 PM, Michael Niedermayer wrote:
> > On Sun, Mar 31, 2024 at 01:30:26PM -0300, James Almer wrote:
> > > On 3/31/2024 8:40 AM, Michael Niedermayer wrote:
> > > > Fixes: Assertion av_rescale_rnd(start_dts, mov->movie_timescale, 
> > > > track->timescale, AV_ROUND_DOWN) <= 0 failed at 
> > > > libavformat/movenc.c:3694
> > > > Fixes: poc2
> > > > 
> > > > Found-by: Wang Dawei and Zhou Geng, from Zhongguancun Laboratory
> > > > Signed-off-by: Michael Niedermayer 
> > > > ---
> > > >libavformat/movenc.c | 6 ++
> > > >1 file changed, 6 insertions(+)
> > > > 
> > > > diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> > > > index ae94d8d5959..5617a2620c5 100644
> > > > --- a/libavformat/movenc.c
> > > > +++ b/libavformat/movenc.c
> > > > @@ -6194,6 +6194,12 @@ int ff_mov_write_packet(AVFormatContext *s, 
> > > > AVPacket *pkt)
> > > >if (ret < 0)
> > > >return ret;
> > > > +if (pkt->pts != AV_NOPTS_VALUE &&
> > > > +(uint64_t)pkt->dts - pkt->pts != (int32_t)((uint64_t)pkt->dts 
> > > > - pkt->pts)) {
> > > > +av_log(s, AV_LOG_WARNING, "pts/dts pair unsupported\n");
> > > > +return AVERROR_PATCHWELCOME;
> > > > +}
> > > 
> > > Any such check should happen in check_pkt(), called directly above. And
> > > afaict there's no reason to not support 64bit cts. Even in
> > > mov_write_edts_tag() we check for it and write a version 1 of the box that
> > > supports 64bit values.
> > > 
> > > Maybe the problem is that MOVIentry.cts is an int, when it should be an
> > > int64_t like start_cts? Can you test the following?
> > 
> > changing cts to 64bit does avoid the assert with the test sample but
> > 
> > If you chaneg cts to 64bit consider cts is assigned to MOVCtts duration 
> > (32bit)
> > in mov_write_ctts_tag() and also compared to it.
> > its also written with avio_wb32() later
> > 
> > theres also
> > avio_wb32(pb, track->cluster[i].cts);
> > in mov_write_trun_tag()
> 
> You're right, there's no 64bit version for these, i guess they will not
> define one either in a future revision of the spec. So your patch should be
> fine.

ok, will apply

thx

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

While the State exists there can be no freedom; when there is freedom there
will be no State. -- 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".


Re: [FFmpeg-devel] [PATCH] avformat/mxfdec: Check that edit_unit_byte_count is not negative

2024-04-01 Thread Michael Niedermayer
On Mon, Apr 01, 2024 at 06:22:47PM +0200, Marton Balint wrote:
> 
> 
> On Mon, 1 Apr 2024, Michael Niedermayer wrote:
> 
> > Signed-off-by: Michael Niedermayer 
> > ---
> > libavformat/mxfdec.c | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > index e484db052ef..37446963369 100644
> > --- a/libavformat/mxfdec.c
> > +++ b/libavformat/mxfdec.c
> > @@ -1245,9 +1245,13 @@ static int mxf_read_index_entry_array(AVIOContext 
> > *pb, MXFIndexTableSegment *seg
> > static int mxf_read_index_table_segment(void *arg, AVIOContext *pb, int 
> > tag, int size, UID uid, int64_t klv_offset)
> > {
> > MXFIndexTableSegment *segment = arg;
> > +int tmp;
> > switch(tag) {
> > case 0x3F05:
> > -segment->edit_unit_byte_count = avio_rb32(pb);
> 
> Why not simply make segment->edit_unit_byte_count unsigned?

ok will apply that instead

thx

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

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- 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] avcodec/mfenc: expose more properties of the media foundation encoder

2024-04-01 Thread Mark Samuelson
On Mon, Apr 1, 2024 at 10:06 AM Mark Thompson  wrote:

> > On 28/03/2024 12:34, Mark Samuelson wrote:
> > > Thank you for the notes, here is a new patch that incorporates your
> suggestions.  You are right, the default value of 12 for gop_size is
> suprising, I didn't know about it before now.
> > >
> > > ---
> > >   libavcodec/mf_utils.h |  5 +
> > >   libavcodec/mfenc.c| 33 +++--
> > >   2 files changed, 32 insertions(+), 6 deletions(-)
> >
> > Patch looks good.
> >
> > I did a bit of testing with the Microsoft H.264 MFT: GOP size and
> compression level work as expected, and VBV parameters seem to be doing
> something sensible.
> >
> > Under what conditions are you expecting global_quality ->
> AVEncVideoEncodeQP to do anything, though?  When I set it alone the output
> was always identical regardless of what value I set > it to.  (Including
> with "-rate_control quality".)
> >
> > Thanks,
> >
> > - Mark
>

I have also had issues making the Media Foundation encoder respect that
value.  I put it in there so that I could easily test it, because I was
having issues with the existing opt_enc_quality -> AVEncCommonQuality.  I
figured it was better to leave it in so people can experiment with it.

>
> > > diff --git a/libavcodec/mf_utils.h b/libavcodec/mf_utils.h
> > > index aebfb9ad21..387c005f38 100644
> > > --- a/libavcodec/mf_utils.h
> > > +++ b/libavcodec/mf_utils.h
> > > @@ -97,6 +97,11 @@ DEFINE_GUID(ff_CODECAPI_AVEncH264CABACEnable,
> 0xee6cad62, 0xd305, 0x4248, 0xa
> > >   DEFINE_GUID(ff_CODECAPI_AVEncVideoForceKeyFrame, 0x398c1b98, 0x8353,
> 0x475a, 0x9e, 0xf2, 0x8f, 0x26, 0x5d, 0x26, 0x3, 0x45);
> > >   DEFINE_GUID(ff_CODECAPI_AVEncMPVDefaultBPictureCount, 0x8d390aac,
> 0xdc5c, 0x4200, 0xb5, 0x7f, 0x81, 0x4d, 0x04, 0xba, 0xba, 0xb2);
> > >   DEFINE_GUID(ff_CODECAPI_AVScenarioInfo,
> 0xb28a6e64,0x3ff9,0x446a,0x8a,0x4b,0x0d,0x7a,0x53,0x41,0x32,0x36);
> > > +DEFINE_GUID(ff_CODECAPI_AVEncCommonBufferSize, 0x0db96574, 0xb6a4,
> 0x4c8b, 0x81, 0x06, 0x37, 0x73, 0xde, 0x03, 0x10, 0xcd);
> > > +DEFINE_GUID(ff_CODECAPI_AVEncCommonMaxBitRate, 0x9651eae4, 0x39b9,
> 0x4ebf, 0x85, 0xef, 0xd7, 0xf4, 0x44, 0xec, 0x74, 0x65);
> > > +DEFINE_GUID(ff_CODECAPI_AVEncCommonQualityVsSpeed, 0x98332df8,
> 0x03cd, 0x476b, 0x89, 0xfa, 0x3f, 0x9e, 0x44, 0x2d, 0xec, 0x9f);
> > > +DEFINE_GUID(ff_CODECAPI_AVEncMPVGOPSize, 0x95f31b26, 0x95a4, 0x41aa,
> 0x93, 0x03, 0x24, 0x6a, 0x7f, 0xc6, 0xee, 0xf1);
> > > +DEFINE_GUID(ff_CODECAPI_AVEncVideoEncodeQP, 0x2cb5696b, 0x23fb,
> 0x4ce1, 0xa0, 0xf9, 0xef, 0x5b, 0x90, 0xfd, 0x55, 0xca);
> > >
> > >   DEFINE_GUID(ff_MF_SA_D3D11_BINDFLAGS, 0xeacf97ad, 0x065c, 0x4408,
> 0xbe, 0xe3, 0xfd, 0xcb, 0xfd, 0x12, 0x8b, 0xe2);
> > >   DEFINE_GUID(ff_MF_SA_D3D11_USAGE, 0xe85fe442, 0x2ca3, 0x486e, 0xa9,
> 0xc7, 0x10, 0x9d, 0xda, 0x60, 0x98, 0x80);
> > > diff --git a/libavcodec/mfenc.c b/libavcodec/mfenc.c
> > > index 9225692c51..cad531bd7d 100644
> > > --- a/libavcodec/mfenc.c
> > > +++ b/libavcodec/mfenc.c
> > > @@ -695,6 +695,21 @@ FF_ENABLE_DEPRECATION_WARNINGS
> > >   if (c->opt_enc_quality >= 0)
> > >   ICodecAPI_SetValue(c->codec_api,
> _CODECAPI_AVEncCommonQuality, FF_VAL_VT_UI4(c->opt_enc_quality));
> > >
> > > +if (avctx->rc_max_rate > 0)
> > > +ICodecAPI_SetValue(c->codec_api,
> _CODECAPI_AVEncCommonMaxBitRate, FF_VAL_VT_UI4(avctx->rc_max_rate));
> > > +
> > > +if (avctx->gop_size > 0)
> > > +ICodecAPI_SetValue(c->codec_api,
> _CODECAPI_AVEncMPVGOPSize, FF_VAL_VT_UI4(avctx->gop_size));
> > > +
> > > +if(avctx->rc_buffer_size > 0)
> > > +ICodecAPI_SetValue(c->codec_api,
> _CODECAPI_AVEncCommonBufferSize, FF_VAL_VT_UI4(avctx->rc_buffer_size));
> > > +
> > > +if(avctx->compression_level >= 0)
> > > +ICodecAPI_SetValue(c->codec_api,
> _CODECAPI_AVEncCommonQualityVsSpeed,
> FF_VAL_VT_UI4(avctx->compression_level));
> > > +
> > > +if(avctx->global_quality > 0)
> > > +ICodecAPI_SetValue(c->codec_api,
> _CODECAPI_AVEncVideoEncodeQP, FF_VAL_VT_UI4(avctx->global_quality ));
> > > +
> > >   // Always set the number of b-frames. Qualcomm's HEVC
> encoder on SD835
> > >   // defaults this to 1, and that setting is buggy with many
> of the
> > >   // rate control modes. (0 or 2 b-frames works fine with most
> rate
> > > @@ -1223,7 +1238,7 @@ static int mf_init(AVCodecContext *avctx)
> > >
> > >   #define OFFSET(x) offsetof(MFContext, x)
> > >
> > > -#define MF_ENCODER(MEDIATYPE, NAME, ID, OPTS, FMTS, CAPS) \
> > > +#define MF_ENCODER(MEDIATYPE, NAME, ID, OPTS, FMTS, CAPS, DEFAULTS) \
> > >   static const AVClass ff_ ## NAME ## _mf_encoder_class = {
>   \
> > >   .class_name = #NAME "_mf",
>\
> > >   .item_name  = av_default_item_name,
>   \
> > > @@ -1243,6 +1258,7 @@ static int mf_init(AVCodecContext *avctx)
> > >   FMTS
>\
> > >   CAPS
>\
> 

Re: [FFmpeg-devel] [PATCH] avformat/mxfdec: Check that edit_unit_byte_count is not negative

2024-04-01 Thread Marton Balint




On Mon, 1 Apr 2024, Michael Niedermayer wrote:


Signed-off-by: Michael Niedermayer 
---
libavformat/mxfdec.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index e484db052ef..37446963369 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -1245,9 +1245,13 @@ static int mxf_read_index_entry_array(AVIOContext *pb, 
MXFIndexTableSegment *seg
static int mxf_read_index_table_segment(void *arg, AVIOContext *pb, int tag, 
int size, UID uid, int64_t klv_offset)
{
MXFIndexTableSegment *segment = arg;
+int tmp;
switch(tag) {
case 0x3F05:
-segment->edit_unit_byte_count = avio_rb32(pb);


Why not simply make segment->edit_unit_byte_count unsigned?

Thanks,
Marton



+tmp = avio_rb32(pb);
+if (tmp < 0)
+return AVERROR_INVALIDDATA;
+segment->edit_unit_byte_count = tmp;
av_log(NULL, AV_LOG_TRACE, "EditUnitByteCount %d\n", 
segment->edit_unit_byte_count);
break;
case 0x3F06:
--
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 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] avformat/iamf_reader: Check len before summing

2024-04-01 Thread Michael Niedermayer
On Mon, Mar 25, 2024 at 04:29:08AM +0100, Michael Niedermayer wrote:
> Fixes: integer overflow
> Fixes: 
> 67275/clusterfuzz-testcase-minimized-ffmpeg_dem_IAMF_fuzzer-5438920751906816
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/iamf_reader.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

will apply this

[...]
-- 
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".


[FFmpeg-devel] [PATCH 2/2] avformat/flvdec: Add support for demuxing multi-track FLV

2024-04-01 Thread Dennis Sädtler via ffmpeg-devel
Based on enhanced-rtmp v2 spec published by Veovera:
https://veovera.github.io/enhanced-rtmp/docs/enhanced/enhanced-rtmp-v2

Signed-off-by: Dennis Sädtler 
---
 libavformat/flvdec.c | 117 +++
 1 file changed, 96 insertions(+), 21 deletions(-)

diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index 22a9b9e4a7..39d01d3b1f 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -105,6 +105,10 @@ typedef struct FLVContext {
 
 FLVMetaVideoColor *metaVideoColor;
 int meta_color_info_flag;
+
+uint8_t **mt_extradata;
+int *mt_extradata_sz;
+int mt_extradata_cnt;
 } FLVContext;
 
 /* AMF date type */
@@ -187,13 +191,18 @@ static void add_keyframes_index(AVFormatContext *s)
 }
 }
 
-static AVStream *create_stream(AVFormatContext *s, int codec_type)
+static AVStream *create_stream(AVFormatContext *s, int codec_type, int 
track_idx)
 {
 FLVContext *flv   = s->priv_data;
 AVStream *st = avformat_new_stream(s, NULL);
 if (!st)
 return NULL;
 st->codecpar->codec_type = codec_type;
+st->id = track_idx;
+avpriv_set_pts_info(st, 32, 1, 1000); /* 32 bit pts in ms */
+if (track_idx)
+return st;
+
 if (s->nb_streams>=3 ||(   s->nb_streams==2
&& s->streams[0]->codecpar->codec_type != 
AVMEDIA_TYPE_SUBTITLE
&& s->streams[1]->codecpar->codec_type != 
AVMEDIA_TYPE_SUBTITLE
@@ -210,8 +219,6 @@ static AVStream *create_stream(AVFormatContext *s, int 
codec_type)
 st->avg_frame_rate = flv->framerate;
 }
 
-
-avpriv_set_pts_info(st, 32, 1, 1000); /* 32 bit pts in ms */
 flv->last_keyframe_stream_index = s->nb_streams - 1;
 add_keyframes_index(s);
 return st;
@@ -351,6 +358,7 @@ static int flv_same_video_codec(AVCodecParameters *vpar, 
uint32_t flv_codecid)
 case FLV_CODECID_VP6A:
 return vpar->codec_id == AV_CODEC_ID_VP6A;
 case FLV_CODECID_H264:
+case MKBETAG('a', 'v', 'c', '1'):
 return vpar->codec_id == AV_CODEC_ID_H264;
 default:
 return vpar->codec_tag == flv_codecid;
@@ -407,6 +415,7 @@ static int flv_set_video_codec(AVFormatContext *s, AVStream 
*vstream,
 ret = 1; // 1 byte body size adjustment for flv_read_packet()
 break;
 case FLV_CODECID_H264:
+case MKBETAG('a', 'v', 'c', '1'):
 par->codec_id = AV_CODEC_ID_H264;
 vstreami->need_parsing = AVSTREAM_PARSE_HEADERS;
 break;
@@ -676,7 +685,7 @@ static int amf_parse_object(AVFormatContext *s, AVStream 
*astream,
 } else if (!strcmp(key, "height") && vpar) {
 vpar->height = num_val;
 } else if (!strcmp(key, "datastream")) {
-AVStream *st = create_stream(s, AVMEDIA_TYPE_SUBTITLE);
+AVStream *st = create_stream(s, AVMEDIA_TYPE_SUBTITLE, 
0);
 if (!st)
 return AVERROR(ENOMEM);
 st->codecpar->codec_id = AV_CODEC_ID_TEXT;
@@ -885,6 +894,9 @@ static int flv_read_close(AVFormatContext *s)
 FLVContext *flv = s->priv_data;
 for (i=0; inew_extradata[i]);
+for (i=0; i < flv->mt_extradata_cnt; i++)
+av_freep(>mt_extradata[i]);
+av_freep(>mt_extradata_sz);
 av_freep(>keyframe_times);
 av_freep(>keyframe_filepositions);
 av_freep(>metaVideoColor);
@@ -904,18 +916,47 @@ static int flv_get_extradata(AVFormatContext *s, AVStream 
*st, int size)
 }
 
 static int flv_queue_extradata(FLVContext *flv, AVIOContext *pb, int stream,
-   int size)
+   int size, int multitrack)
 {
 if (!size)
 return 0;
 
-av_free(flv->new_extradata[stream]);
-flv->new_extradata[stream] = av_mallocz(size +
-AV_INPUT_BUFFER_PADDING_SIZE);
-if (!flv->new_extradata[stream])
-return AVERROR(ENOMEM);
-flv->new_extradata_size[stream] = size;
-avio_read(pb, flv->new_extradata[stream], size);
+if (!multitrack) {
+av_free(flv->new_extradata[stream]);
+flv->new_extradata[stream] = av_mallocz(size +
+AV_INPUT_BUFFER_PADDING_SIZE);
+if (!flv->new_extradata[stream])
+return AVERROR(ENOMEM);
+flv->new_extradata_size[stream] = size;
+avio_read(pb, flv->new_extradata[stream], size);
+} else {
+int new_count = stream + 1;
+
+if (flv->mt_extradata_cnt < new_count) {
+flv->mt_extradata = av_realloc(flv->mt_extradata,
+   sizeof(*flv->mt_extradata) * 
+   new_count);
+flv->mt_extradata_sz = av_realloc(flv->mt_extradata_sz,
+  sizeof(*flv->mt_extradata_sz) *
+  new_count);

[FFmpeg-devel] [PATCH 1/2] avformat/flvenc: Implement support for multi-track video

2024-04-01 Thread Dennis Sädtler via ffmpeg-devel
Based on enhanced-rtmp v2 spec published by Veovera:
https://veovera.github.io/enhanced-rtmp/docs/enhanced/enhanced-rtmp-v2

This implementation maintains some backwards compatibility by only
writing the track information for track indices > 0. This means that
older FFmpeg versions - and possibly other software - can still read the
first video track properly and skip over unsupported packets.

Signed-off-by: Dennis Sädtler 
---
 libavformat/flv.h|   7 ++
 libavformat/flvenc.c | 160 ++-
 2 files changed, 119 insertions(+), 48 deletions(-)

diff --git a/libavformat/flv.h b/libavformat/flv.h
index f710963b92..653c2bc82c 100644
--- a/libavformat/flv.h
+++ b/libavformat/flv.h
@@ -125,6 +125,13 @@ enum {
 PacketTypeCodedFramesX  = 3,
 PacketTypeMetadata  = 4,
 PacketTypeMPEG2TSSequenceStart  = 5,
+PacketTypeMultitrack= 6,
+};
+
+enum {
+   MultitrackTypeOneTrack = 0x00,
+   MultitrackTypeManyTracks   = 0x10,
+   MultitrackTypeManyTracksManyCodecs = 0x20,
 };
 
 enum {
diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index aba1d7d80b..82f275777f 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -125,8 +125,9 @@ typedef struct FLVContext {
 AVCodecParameters *data_par;
 
 int flags;
-int64_t last_ts[FLV_STREAM_TYPE_NB];
-int metadata_pkt_written;
+int64_t *last_ts;
+int *metadata_pkt_written;
+int *video_track_idx_map;
 } FLVContext;
 
 static int get_audio_flags(AVFormatContext *s, AVCodecParameters *par)
@@ -484,7 +485,7 @@ static void write_metadata(AVFormatContext *s, unsigned int 
ts)
 avio_wb32(pb, flv->metadata_totalsize + 11);
 }
 
-static void flv_write_metadata_packet(AVFormatContext *s, AVCodecParameters 
*par, unsigned int ts)
+static void flv_write_metadata_packet(AVFormatContext *s, AVCodecParameters 
*par, unsigned int ts, int stream_idx)
 {
 AVIOContext *pb = s->pb;
 FLVContext *flv = s->priv_data;
@@ -494,7 +495,9 @@ static void flv_write_metadata_packet(AVFormatContext *s, 
AVCodecParameters *par
 int64_t total_size = 0;
 const AVPacketSideData *side_data = NULL;
 
-if (flv->metadata_pkt_written) return;
+if (flv->metadata_pkt_written[stream_idx])
+return;
+
 if (par->codec_id == AV_CODEC_ID_HEVC || par->codec_id == AV_CODEC_ID_AV1 
||
 par->codec_id == AV_CODEC_ID_VP9) {
 int flags_size = 5;
@@ -616,7 +619,7 @@ static void flv_write_metadata_packet(AVFormatContext *s, 
AVCodecParameters *par
 avio_wb24(pb, total_size);
 avio_skip(pb, total_size + 10 - 3);
 avio_wb32(pb, total_size + 11); // previous tag size
-flv->metadata_pkt_written = 1;
+flv->metadata_pkt_written[stream_idx] = 1;
 }
 }
 
@@ -631,7 +634,7 @@ static int unsupported_codec(AVFormatContext *s,
 return AVERROR(ENOSYS);
 }
 
-static void flv_write_codec_header(AVFormatContext* s, AVCodecParameters* par, 
int64_t ts) {
+static void flv_write_codec_header(AVFormatContext* s, AVCodecParameters* par, 
int64_t ts, int stream_index) {
 int64_t data_size;
 AVIOContext *pb = s->pb;
 FLVContext *flv = s->priv_data;
@@ -681,12 +684,32 @@ static void flv_write_codec_header(AVFormatContext* s, 
AVCodecParameters* par, i
 }
 avio_write(pb, par->extradata, par->extradata_size);
 } else {
-if (par->codec_id == AV_CODEC_ID_HEVC) {
-avio_w8(pb, FLV_IS_EX_HEADER | PacketTypeSequenceStart | 
FLV_FRAME_KEY); // ExVideoTagHeader mode with PacketTypeSequenceStart
-avio_write(pb, "hvc1", 4);
-} else if (par->codec_id == AV_CODEC_ID_AV1 || par->codec_id == 
AV_CODEC_ID_VP9) {
-avio_w8(pb, FLV_IS_EX_HEADER | PacketTypeSequenceStart | 
FLV_FRAME_KEY);
-avio_write(pb, par->codec_id == AV_CODEC_ID_AV1 ? "av01" : 
"vp09", 4);
+int track_idx = flv->video_track_idx_map[stream_index];
+// If video stream has track_idx > 0 we need to send H.264 as 
extended video packet
+int extended_flv = (par->codec_id == AV_CODEC_ID_H264 && track_idx)
+|| par->codec_id == AV_CODEC_ID_HEVC
+|| par->codec_id == AV_CODEC_ID_AV1
+|| par->codec_id == AV_CODEC_ID_VP9;
+
+if (extended_flv) {
+if (track_idx) {
+avio_w8(pb, FLV_IS_EX_HEADER | PacketTypeMultitrack | 
FLV_FRAME_KEY);
+avio_w8(pb, MultitrackTypeOneTrack | 
PacketTypeSequenceStart);
+} else {
+avio_w8(pb, FLV_IS_EX_HEADER | PacketTypeSequenceStart | 
FLV_FRAME_KEY);
+}
+
+if (par->codec_id == AV_CODEC_ID_H264)
+avio_write(pb, "avc1", 4);
+else if (par->codec_id == AV_CODEC_ID_HEVC)
+

[FFmpeg-devel] [PATCH] avformat/mxfdec: Check that edit_unit_byte_count is not negative

2024-04-01 Thread Michael Niedermayer
Signed-off-by: Michael Niedermayer 
---
 libavformat/mxfdec.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index e484db052ef..37446963369 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -1245,9 +1245,13 @@ static int mxf_read_index_entry_array(AVIOContext *pb, 
MXFIndexTableSegment *seg
 static int mxf_read_index_table_segment(void *arg, AVIOContext *pb, int tag, 
int size, UID uid, int64_t klv_offset)
 {
 MXFIndexTableSegment *segment = arg;
+int tmp;
 switch(tag) {
 case 0x3F05:
-segment->edit_unit_byte_count = avio_rb32(pb);
+tmp = avio_rb32(pb);
+if (tmp < 0)
+return AVERROR_INVALIDDATA;
+segment->edit_unit_byte_count = tmp;
 av_log(NULL, AV_LOG_TRACE, "EditUnitByteCount %d\n", 
segment->edit_unit_byte_count);
 break;
 case 0x3F06:
-- 
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] [PATCH 3/3] avformat/mxfdec: Check first case of offset_temp computation for overflow

2024-04-01 Thread Michael Niedermayer
On Sat, Mar 30, 2024 at 10:01:32AM +0100, Tomas Härdin wrote:
> fre 2024-03-29 klockan 20:32 +0100 skrev Michael Niedermayer:
> > This is kind of ugly
> > Fixes: signed integer overflow: 255 * 1157565362826411919 cannot be
> > represented in type 'long'
> > Fixes: 67313/clusterfuzz-testcase-minimized-ffmpeg_dem_MXF_fuzzer-
> > 6250434245230592
> > 
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavformat/mxfdec.c | 9 +++--
> >  1 file changed, 7 insertions(+), 2 deletions(-)
> > 
> > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > index c9af4628555..fe86f516630 100644
> > --- a/libavformat/mxfdec.c
> > +++ b/libavformat/mxfdec.c
> > @@ -1891,9 +1891,14 @@ static int
> > mxf_edit_unit_absolute_offset(MXFContext *mxf, MXFIndexTable *index_t
> >  if (edit_unit < s->index_start_position + s->index_duration)
> > {
> >  int64_t index = edit_unit - s->index_start_position;
> >  
> > -    if (s->edit_unit_byte_count)
> > +    if (s->edit_unit_byte_count) {
> > +    if (s->edit_unit_byte_count * (uint64_t)index / s-
> > >edit_unit_byte_count != index ||
> 
> Don't we already have a function for testing these kinds of overflows

We have av_size_mult() thats for size_t


> for av_calloc()? Or do it manually less uglily like so:
> 
>   index > INT64_MAX / s->edit_unit_byte_count

ok

> 
> > +    s->edit_unit_byte_count * index > INT64_MAX -
> > offset_temp
> > +    )
> 
> Nit: looks a bit weird to have the ) there rather than at the end of
> the previous line

will push with this changed

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

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


Re: [FFmpeg-devel] [RFC] clarifying the TC conflict of interest rule

2024-04-01 Thread Paul B Mahol
On Mon, Apr 1, 2024 at 4:59 PM Michael Niedermayer 
wrote:

> On Mon, Apr 01, 2024 at 01:16:48PM +0200, Anton Khirnov wrote:
> > Hi all,
> >
> > the vote has now ended with 23 votes cast, results are available at
> > https://vote.ffmpeg.org/cgi-bin/civs/results.pl?id=E_a6be1eb156d0e589
> >
> > The winning option is 'Anton', i.e. my proposal. Voting data as reported
> > by CIVS is attached to this email for future reference.
>
> Congratulations! :)
>
>
Next time prepare more voting bots than opponent, than you will surely win
again.


> thx
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> I have often repented speaking, but never of holding my tongue.
> -- Xenocrates
> ___
> 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/movenc: Check that cts fits in 32bit

2024-04-01 Thread James Almer

On 4/1/2024 12:38 PM, Michael Niedermayer wrote:

On Sun, Mar 31, 2024 at 01:30:26PM -0300, James Almer wrote:

On 3/31/2024 8:40 AM, Michael Niedermayer wrote:

Fixes: Assertion av_rescale_rnd(start_dts, mov->movie_timescale, track->timescale, 
AV_ROUND_DOWN) <= 0 failed at libavformat/movenc.c:3694
Fixes: poc2

Found-by: Wang Dawei and Zhou Geng, from Zhongguancun Laboratory
Signed-off-by: Michael Niedermayer 
---
   libavformat/movenc.c | 6 ++
   1 file changed, 6 insertions(+)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index ae94d8d5959..5617a2620c5 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -6194,6 +6194,12 @@ int ff_mov_write_packet(AVFormatContext *s, AVPacket 
*pkt)
   if (ret < 0)
   return ret;
+if (pkt->pts != AV_NOPTS_VALUE &&
+(uint64_t)pkt->dts - pkt->pts != (int32_t)((uint64_t)pkt->dts - 
pkt->pts)) {
+av_log(s, AV_LOG_WARNING, "pts/dts pair unsupported\n");
+return AVERROR_PATCHWELCOME;
+}


Any such check should happen in check_pkt(), called directly above. And
afaict there's no reason to not support 64bit cts. Even in
mov_write_edts_tag() we check for it and write a version 1 of the box that
supports 64bit values.

Maybe the problem is that MOVIentry.cts is an int, when it should be an
int64_t like start_cts? Can you test the following?


changing cts to 64bit does avoid the assert with the test sample but

If you chaneg cts to 64bit consider cts is assigned to MOVCtts duration (32bit)
in mov_write_ctts_tag() and also compared to it.
its also written with avio_wb32() later

theres also
avio_wb32(pb, track->cluster[i].cts);
in mov_write_trun_tag()


You're right, there's no 64bit version for these, i guess they will not 
define one either in a future revision of the spec. So your patch should 
be fine.




so the suggestion would avoid the assert but the code is not correct, now one 
can
maybe add support for this by switching to 64bit variants. But this needs to be
backported too.
and "64bit cts support" seems not ideal both because of complexity and beacause
its not a bugfix

I would prefer to keep a simple (easy backportable) bugfix for the releases.

thx

[...]


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

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

___
ffmpeg-devel 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] avcodec/jpeg2000htdec: Check magp before using it in a shift

2024-04-01 Thread Michael Niedermayer
On Sat, Mar 30, 2024 at 09:56:58AM +0100, Tomas Härdin wrote:
> fre 2024-03-29 klockan 20:32 +0100 skrev Michael Niedermayer:
> > Fixes: shift exponent -1 is negative
> > Fixes: 65378/clusterfuzz-testcase-minimized-
> > ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-5457678193197056
> > 
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/jpeg2000dec.c | 7 +--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
> > index 1afc6b1e2dd..fe2afb05057 100644
> > --- a/libavcodec/jpeg2000dec.c
> > +++ b/libavcodec/jpeg2000dec.c
> > @@ -1910,6 +1910,8 @@ static inline void tile_codeblocks(const
> > Jpeg2000DecoderContext *s, Jpeg2000Tile
> >  int nb_precincts, precno;
> >  Jpeg2000Band *band = rlevel->band + bandno;
> >  int cblkno = 0, bandpos;
> > +    /* See Rec. ITU-T T.800, Equation E-2 */
> > +    int magp = quantsty->expn[subbandno] + quantsty-
> > >nguardbits - 1;
> >  
> >  bandpos = bandno + (reslevelno > 0);
> >  
> > @@ -1917,6 +1919,9 @@ static inline void tile_codeblocks(const
> > Jpeg2000DecoderContext *s, Jpeg2000Tile
> >  band->coord[1][0] == band->coord[1][1])
> >  continue;
> >  
> > +    if ((codsty->cblk_style & JPEG2000_CTSY_HTJ2K_F) &&
> > magp >= 31)
> > +    return;
> 
> Please also print an error message and return AVERROR_PATCHWELCOME

will apply with these changes

thx

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

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato


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] [RFC] clarifying the TC conflict of interest rule

2024-04-01 Thread Paul B Mahol
On Mon, Apr 1, 2024 at 1:17 PM Anton Khirnov  wrote:

> Hi all,
>
> the vote has now ended with 23 votes cast, results are available at
> https://vote.ffmpeg.org/cgi-bin/civs/results.pl?id=E_a6be1eb156d0e589
>
> The winning option is 'Anton', i.e. my proposal. Voting data as reported
> by CIVS is attached to this email for future reference.
>

As expected...


>
> Cheers,
> --
> Anton Khirnov
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


Re: [FFmpeg-devel] [PATCH] avformat/movenc: Check that cts fits in 32bit

2024-04-01 Thread Michael Niedermayer
On Sun, Mar 31, 2024 at 01:30:26PM -0300, James Almer wrote:
> On 3/31/2024 8:40 AM, Michael Niedermayer wrote:
> > Fixes: Assertion av_rescale_rnd(start_dts, mov->movie_timescale, 
> > track->timescale, AV_ROUND_DOWN) <= 0 failed at libavformat/movenc.c:3694
> > Fixes: poc2
> > 
> > Found-by: Wang Dawei and Zhou Geng, from Zhongguancun Laboratory
> > Signed-off-by: Michael Niedermayer 
> > ---
> >   libavformat/movenc.c | 6 ++
> >   1 file changed, 6 insertions(+)
> > 
> > diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> > index ae94d8d5959..5617a2620c5 100644
> > --- a/libavformat/movenc.c
> > +++ b/libavformat/movenc.c
> > @@ -6194,6 +6194,12 @@ int ff_mov_write_packet(AVFormatContext *s, AVPacket 
> > *pkt)
> >   if (ret < 0)
> >   return ret;
> > +if (pkt->pts != AV_NOPTS_VALUE &&
> > +(uint64_t)pkt->dts - pkt->pts != (int32_t)((uint64_t)pkt->dts - 
> > pkt->pts)) {
> > +av_log(s, AV_LOG_WARNING, "pts/dts pair unsupported\n");
> > +return AVERROR_PATCHWELCOME;
> > +}
> 
> Any such check should happen in check_pkt(), called directly above. And
> afaict there's no reason to not support 64bit cts. Even in
> mov_write_edts_tag() we check for it and write a version 1 of the box that
> supports 64bit values.
> 
> Maybe the problem is that MOVIentry.cts is an int, when it should be an
> int64_t like start_cts? Can you test the following?

changing cts to 64bit does avoid the assert with the test sample but

If you chaneg cts to 64bit consider cts is assigned to MOVCtts duration (32bit)
in mov_write_ctts_tag() and also compared to it.
its also written with avio_wb32() later

theres also
avio_wb32(pb, track->cluster[i].cts);
in mov_write_trun_tag()

so the suggestion would avoid the assert but the code is not correct, now one 
can
maybe add support for this by switching to 64bit variants. But this needs to be
backported too.
and "64bit cts support" seems not ideal both because of complexity and beacause
its not a bugfix

I would prefer to keep a simple (easy backportable) bugfix for the releases.

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

What does censorship reveal? It reveals fear. -- Julian Assange


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] avcodec/mfenc: expose more properties of the media foundation encoder

2024-04-01 Thread Mark Thompson

On 28/03/2024 12:34, Mark Samuelson wrote:

Thank you for the notes, here is a new patch that incorporates your 
suggestions.  You are right, the default value of 12 for gop_size is suprising, 
I didn't know about it before now.

---
  libavcodec/mf_utils.h |  5 +
  libavcodec/mfenc.c| 33 +++--
  2 files changed, 32 insertions(+), 6 deletions(-)


Patch looks good.

I did a bit of testing with the Microsoft H.264 MFT: GOP size and compression 
level work as expected, and VBV parameters seem to be doing something sensible.

Under what conditions are you expecting global_quality -> AVEncVideoEncodeQP to do 
anything, though?  When I set it alone the output was always identical regardless of what 
value I set it to.  (Including with "-rate_control quality".)

Thanks,

- Mark


diff --git a/libavcodec/mf_utils.h b/libavcodec/mf_utils.h
index aebfb9ad21..387c005f38 100644
--- a/libavcodec/mf_utils.h
+++ b/libavcodec/mf_utils.h
@@ -97,6 +97,11 @@ DEFINE_GUID(ff_CODECAPI_AVEncH264CABACEnable,0xee6cad62, 
0xd305, 0x4248, 0xa
  DEFINE_GUID(ff_CODECAPI_AVEncVideoForceKeyFrame, 0x398c1b98, 0x8353, 0x475a, 
0x9e, 0xf2, 0x8f, 0x26, 0x5d, 0x26, 0x3, 0x45);
  DEFINE_GUID(ff_CODECAPI_AVEncMPVDefaultBPictureCount, 0x8d390aac, 0xdc5c, 
0x4200, 0xb5, 0x7f, 0x81, 0x4d, 0x04, 0xba, 0xba, 0xb2);
  DEFINE_GUID(ff_CODECAPI_AVScenarioInfo, 
0xb28a6e64,0x3ff9,0x446a,0x8a,0x4b,0x0d,0x7a,0x53,0x41,0x32,0x36);
+DEFINE_GUID(ff_CODECAPI_AVEncCommonBufferSize, 0x0db96574, 0xb6a4, 0x4c8b, 
0x81, 0x06, 0x37, 0x73, 0xde, 0x03, 0x10, 0xcd);
+DEFINE_GUID(ff_CODECAPI_AVEncCommonMaxBitRate, 0x9651eae4, 0x39b9, 0x4ebf, 
0x85, 0xef, 0xd7, 0xf4, 0x44, 0xec, 0x74, 0x65);
+DEFINE_GUID(ff_CODECAPI_AVEncCommonQualityVsSpeed, 0x98332df8, 0x03cd, 0x476b, 
0x89, 0xfa, 0x3f, 0x9e, 0x44, 0x2d, 0xec, 0x9f);
+DEFINE_GUID(ff_CODECAPI_AVEncMPVGOPSize, 0x95f31b26, 0x95a4, 0x41aa, 0x93, 
0x03, 0x24, 0x6a, 0x7f, 0xc6, 0xee, 0xf1);
+DEFINE_GUID(ff_CODECAPI_AVEncVideoEncodeQP, 0x2cb5696b, 0x23fb, 0x4ce1, 0xa0, 
0xf9, 0xef, 0x5b, 0x90, 0xfd, 0x55, 0xca);
  
  DEFINE_GUID(ff_MF_SA_D3D11_BINDFLAGS, 0xeacf97ad, 0x065c, 0x4408, 0xbe, 0xe3, 0xfd, 0xcb, 0xfd, 0x12, 0x8b, 0xe2);

  DEFINE_GUID(ff_MF_SA_D3D11_USAGE, 0xe85fe442, 0x2ca3, 0x486e, 0xa9, 0xc7, 
0x10, 0x9d, 0xda, 0x60, 0x98, 0x80);
diff --git a/libavcodec/mfenc.c b/libavcodec/mfenc.c
index 9225692c51..cad531bd7d 100644
--- a/libavcodec/mfenc.c
+++ b/libavcodec/mfenc.c
@@ -695,6 +695,21 @@ FF_ENABLE_DEPRECATION_WARNINGS
  if (c->opt_enc_quality >= 0)
  ICodecAPI_SetValue(c->codec_api, _CODECAPI_AVEncCommonQuality, 
FF_VAL_VT_UI4(c->opt_enc_quality));
  
+if (avctx->rc_max_rate > 0)

+ICodecAPI_SetValue(c->codec_api, _CODECAPI_AVEncCommonMaxBitRate, 
FF_VAL_VT_UI4(avctx->rc_max_rate));
+
+if (avctx->gop_size > 0)
+ICodecAPI_SetValue(c->codec_api, _CODECAPI_AVEncMPVGOPSize, 
FF_VAL_VT_UI4(avctx->gop_size));
+
+if(avctx->rc_buffer_size > 0)
+ICodecAPI_SetValue(c->codec_api, _CODECAPI_AVEncCommonBufferSize, 
FF_VAL_VT_UI4(avctx->rc_buffer_size));
+
+if(avctx->compression_level >= 0)
+ICodecAPI_SetValue(c->codec_api, 
_CODECAPI_AVEncCommonQualityVsSpeed, FF_VAL_VT_UI4(avctx->compression_level));
+
+if(avctx->global_quality > 0)
+ICodecAPI_SetValue(c->codec_api, _CODECAPI_AVEncVideoEncodeQP, 
FF_VAL_VT_UI4(avctx->global_quality ));
+
  // Always set the number of b-frames. Qualcomm's HEVC encoder on SD835
  // defaults this to 1, and that setting is buggy with many of the
  // rate control modes. (0 or 2 b-frames works fine with most rate
@@ -1223,7 +1238,7 @@ static int mf_init(AVCodecContext *avctx)
  
  #define OFFSET(x) offsetof(MFContext, x)
  
-#define MF_ENCODER(MEDIATYPE, NAME, ID, OPTS, FMTS, CAPS) \

+#define MF_ENCODER(MEDIATYPE, NAME, ID, OPTS, FMTS, CAPS, DEFAULTS) \
  static const AVClass ff_ ## NAME ## _mf_encoder_class = { 
 \
  .class_name = #NAME "_mf",
 \
  .item_name  = av_default_item_name,   
 \
@@ -1243,6 +1258,7 @@ static int mf_init(AVCodecContext *avctx)
  FMTS  
 \
  CAPS  
 \
  .caps_internal  = FF_CODEC_CAP_INIT_CLEANUP,  
 \
+   .defaults   = DEFAULTS, 
   \
  };
  
  #define AFMTS \

@@ -1252,9 +1268,9 @@ static int mf_init(AVCodecContext *avctx)
  .p.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_HYBRID |  
 \
AV_CODEC_CAP_DR1 | AV_CODEC_CAP_VARIABLE_FRAME_SIZE,
  
-MF_ENCODER(AUDIO, aac, AAC, NULL, AFMTS, ACAPS);

-MF_ENCODER(AUDIO, ac3, AC3, NULL, AFMTS, ACAPS);
-MF_ENCODER(AUDIO, mp3, MP3, 

Re: [FFmpeg-devel] [RFC] clarifying the TC conflict of interest rule

2024-04-01 Thread Michael Niedermayer
On Mon, Apr 01, 2024 at 01:16:48PM +0200, Anton Khirnov wrote:
> Hi all,
> 
> the vote has now ended with 23 votes cast, results are available at
> https://vote.ffmpeg.org/cgi-bin/civs/results.pl?id=E_a6be1eb156d0e589
> 
> The winning option is 'Anton', i.e. my proposal. Voting data as reported
> by CIVS is attached to this email for future reference.

Congratulations! :)

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


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] Fixes #10509

2024-04-01 Thread Poorva
>
>
>
On Sun, Mar 31, 2024 at 8:35 PM Marton Balint  wrote:

>
>
> On Fri, 29 Mar 2024, Poorva wrote:
>
> >>
> >
> > On Tue, Mar 26, 2024 at 2:36 AM Poorva <2003gaikarpoo...@gmail.com>
> wrote:
> >>>
> >>>
> >>
> >>
> >> Thank you for your feedback on the Git patch I submitted for review.
> >> I have rectified the problem by adding the necessary changes .
> >> The updated patch file is attached for your review.
> >>>
> >>>
> > I wanted to follow up on the patch titled
> > "v3-0001-avfilter-f_select.c - Add Support for IW and IH" that I
> > submitted earlier and provide an update based on the feedback
> > received.
> >
> > In response to your suggestion about the switch block, I have
> > integrated the changes into the existing switch block for
> > AVMEDIA_TYPE_VIDEO. Additionally, I have removed an unnecessary new
> > line that was added at the end of the file.
> >
> > Despite these modifications, I have not received any further feedback
> > or comments on the patch. Therefore, I kindly request the community to
> > review the updated patch attached to this email.
>
> [..]
>
> > @@ -371,6 +383,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
> >  break;
> >  }
> >
> > +
> >  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",
> > @@ -545,4 +558,4 @@ const AVFilter ff_vf_select = {
> >  FILTER_QUERY_FUNC(query_formats),
> >  .flags = AVFILTER_FLAG_DYNAMIC_OUTPUTS |
> AVFILTER_FLAG_METADATA_ONLY,
> >  };
> > -#endif /* CONFIG_SELECT_FILTER */
> > +#endif /* CONFIG_SELECT_FILTER */
> > \ No newline at end of file
> > --
> > 2.43.0.windows.1
> >
>
> These two whitespace changes are still unnecessary. Please check your
> patch before sending.
>
> I did remove all the unnecessary whitespaces ,rest which are present are
to keep the code style .
Patch is attached to this email.

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


v3-0001-avfilter-f_select.c-add-support-for-iw-and-ih-con.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 2/3] lavf/srtdec: Permit streaming input

2024-04-01 Thread Tomas Härdin
lör 2024-03-30 klockan 17:02 +0100 skrev Andreas Rheinhardt:
> If you force reordering on our users, then this is a breaking change

Another thing that bears keeping in mind: sorting isn't consistent even
across demuxers that sort. Most sort by timestamp (SUB_SORT_TS_POS),
but vobsub sorts by byte position (SUB_SORT_POS_TS). It does this so as
to be able to merge split subtitles later, but it does then not sort by
timestamp after merging, as far as I can tell.

I'm a bit busy with other stuff in the coming days, but hopefully I
should be able to knock out a prototype by the end of the week that
still provides sorted subs when possible, except when the input is a
stream (which doesn't work now anyways).

This kind of nonsense is why being strict with input is a good idea.

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

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


Re: [FFmpeg-devel] [PATCH 2/3] lavf/srtdec: Permit streaming input

2024-04-01 Thread arch1t3cht

On 30/03/2024 17:02, Andreas Rheinhardt wrote:

Tomas Härdin:

lör 2024-03-30 klockan 15:49 +0100 skrev Nicolas George:

ASS demuxer sorts its packets because
there is no guarantee the text are sorted in the file


So? I'm making a normative argument.



Normative about what? The ASS specification [1] explicitly says:

"SSA does not care what order events are entered in.

[1]: www.tcax.org/docs/ass-specs.htm


It's worth noting that this document, while often referred to as the
ASS specification, is not actually an authoritative specification.
The ASS format is implementation-defined:

https://github.com/libass/libass/wiki/ASS-File-Format-Guide#preface-other-format-guidesspecification

But of course this doesn't change the fact that the format allows events
to be in any order. (Though this is also not the same as not caring at
all what order events are entered in: While any order is valid, the 
order of events will affect their layering and collision detection.)


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

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


Re: [FFmpeg-devel] [RFC] clarifying the TC conflict of interest rule

2024-04-01 Thread Anton Khirnov
Quoting Gyan Doshi (2024-04-01 14:20:01)
> On 2024-04-01 04:46 pm, Anton Khirnov wrote:
> > Hi all,
> >
> > the vote has now ended with 23 votes cast, results are available at
> > https://vote.ffmpeg.org/cgi-bin/civs/results.pl?id=E_a6be1eb156d0e589
> >
> > The winning option is 'Anton', i.e. my proposal. Voting data as reported
> > by CIVS is attached to this email for future reference.
> 
> How come there's an entry with all 7s?
> The choices were ranks, not weight markers.

I think "last rank for all choices" is the default state, so the voter
probably just clicked submit without changing anything.

-- 
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 3/3] avcodec/hevcdec: Fix null dereference in hevc_frame_end()

2024-04-01 Thread Andreas Rheinhardt
Michael Niedermayer:
> Fixes: member access within null pointer of type 'const AVFilmGrainParams' 
> (aka 'const struct AVFilmGrainParams')
> Fixes: 
> 67701/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-6595117570916352
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/hevcdec.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
> index 752459af2d3..2514d522ba5 100644
> --- a/libavcodec/hevcdec.c
> +++ b/libavcodec/hevcdec.c
> @@ -2945,6 +2945,8 @@ static int hevc_frame_end(HEVCContext *s)
>  if (out->needs_fg) {
>  av_assert0(out->frame_grain->buf[0]);
>  fgp = av_film_grain_params_select(out->frame);
> +if (!fgp)
> +return 0;
>  switch (fgp->type) {
>  case AV_FILM_GRAIN_PARAMS_NONE:
>  av_assert0(0);

There seems to be a deeper logic bug here: If there is no usable (as
defined by av_film_grain_params_select()) film grain stuff here, then
the frame_grain frame will be "blank" (may contain e.g. an earlier
frame, but definitely not the one it is supposed to have), but it will
nevertheless be the frame to be output.

- 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] [RFC] clarifying the TC conflict of interest rule

2024-04-01 Thread Gyan Doshi




On 2024-04-01 04:46 pm, Anton Khirnov wrote:

Hi all,

the vote has now ended with 23 votes cast, results are available at
https://vote.ffmpeg.org/cgi-bin/civs/results.pl?id=E_a6be1eb156d0e589

The winning option is 'Anton', i.e. my proposal. Voting data as reported
by CIVS is attached to this email for future reference.


How come there's an entry with all 7s?
The choices were ranks, not weight markers.

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


  1   2   >