Re: [FFmpeg-devel] [PATCH] web: add a news entry for 7.0

2024-04-04 Thread James Almer

On 4/1/2024 3:07 PM, Anton Khirnov wrote:

---
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)


Will apply now that 7.0 was tagged.
___
ffmpeg-devel mailing list
ffmpeg-devel@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] FFmpeg 7.0.1

2024-04-04 Thread Michael Niedermayer
Hi all

i intend to make a 7.0.1 in a few weeks for all the bug fixes that didnt
make it in 7.0

thx

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire


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

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


Re: [FFmpeg-devel] 7.0 Name

2024-04-04 Thread Michael Niedermayer
On Fri, Apr 05, 2024 at 12:25:01AM +0200, Michael Niedermayer wrote:
> On Mon, Apr 01, 2024 at 10:00:47PM +0200, 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.
> 
> I think the outcome is quite clear
> 
> Dijkstra got 7 votes, every other name had only 1

Here are the votes i counted:

Anton   (Paul)
Dijkstra(Sean, Reto, Marth64, epirat07, Vittorio, Andreas, Niklas)
Leavitt (Ingo)
NINEVAH (RaDSL)
Viterbi (mypopy)
Voltaire(Lynne)

Thanks to everyone for voting

[...]

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

2024-04-04 Thread Paul B Mahol
LibAV yet again!

On Fri, Apr 5, 2024 at 12:25 AM Michael Niedermayer 
wrote:

> On Mon, Apr 01, 2024 at 10:00:47PM +0200, 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.
>
> I think the outcome is quite clear
>
> Dijkstra got 7 votes, every other name had only 1
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Take away the freedom of one citizen and you will be jailed, take away
> the freedom of all citizens and you will be congratulated by your peers
> in Parliament.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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 2/2] avformat/lc3: Add file format for LC3/LC3plus transport

2024-04-04 Thread Antoine Soulier via ffmpeg-devel
From: Antoine SOULIER 

A file format is described in Bluetooth SIG LC3 and ETSI TS 103 634, for
test purpose. This is the format implemented here.
---
 Changelog|   1 +
 doc/muxers.texi  |   6 ++
 libavformat/Makefile |   2 +
 libavformat/allformats.c |   2 +
 libavformat/lc3dec.c | 160 +++
 libavformat/lc3enc.c | 100 
 6 files changed, 271 insertions(+)
 create mode 100644 libavformat/lc3dec.c
 create mode 100644 libavformat/lc3enc.c

diff --git a/Changelog b/Changelog
index 18e83b99a1..92670f6a05 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
 - Raw Captions with Time (RCWT) closed caption demuxer
 - LC3/LC3plus decoding/encoding using external library liblc3
 
diff --git a/doc/muxers.texi b/doc/muxers.texi
index d8a1f83309..ed4144f6d1 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -2700,6 +2700,12 @@ computer-generated compositions.
 
 This muxer accepts a single audio stream containing PCM data.
 
+@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 9981799cc9..027d0cdae5 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 ae925dcf60..305fa46532 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..1fcde8ca4e
--- /dev/null
+++ b/libavformat/lc3dec.c
@@ -0,0 +1,160 @@
+/*
+ * 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;
+int64_t end_dts;
+} LC3DemuxContext;
+
+static int lc3_read_probe(const AVProbeData *p)
+{
+uint16_t frame_10us, srate_100hz;
+
+if (p->buf_size < 12)
+return 0;
+
+if (AV_RB16(p->buf + 0) != 0x1ccc ||
+AV_RL16(p->buf + 2) <  9 * sizeof(uint16_t))
+return 0;
+
+srate_100hz = AV_RL16(p->buf + 4);
+if (srate_100hz !=  8000/100 && srate_100hz != 16000/100 &&
+srate_100hz != 24000/100 && srate_100hz != 32000/100 &&
+srate_100hz != 48000/100 && srate_100hz != 96000/100)
+return 0;
+
+

[FFmpeg-devel] [PATCH 1/2] avcodec/liblc3dec: Retrieve duration of the last packet from the demux

2024-04-04 Thread Antoine Soulier via ffmpeg-devel
From: Antoine SOULIER 

Use the packet duration field to invalid last samples of the last frame.
---
 libavcodec/liblc3dec.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/libavcodec/liblc3dec.c b/libavcodec/liblc3dec.c
index 90da28679b..d250ace38a 100644
--- a/libavcodec/liblc3dec.c
+++ b/libavcodec/liblc3dec.c
@@ -34,7 +34,6 @@ typedef struct LibLC3DecContext {
 int frame_us, srate_hz, hr_mode;
 void *decoder_mem;
 lc3_decoder_t decoder[DECODER_MAX_CHANNELS];
-int64_t length;
 } LibLC3DecContext;
 
 static av_cold int liblc3_decode_init(AVCodecContext *avctx)
@@ -44,12 +43,12 @@ static av_cold int liblc3_decode_init(AVCodecContext *avctx)
 int ep_mode;
 unsigned decoder_size;
 
-if (avctx->extradata_size < 10)
+if (avctx->extradata_size < 6)
 return AVERROR_INVALIDDATA;
 if (channels < 0 || channels > DECODER_MAX_CHANNELS) {
 av_log(avctx, AV_LOG_ERROR,
"Invalid number of channels %d. Max %d channels are accepted\n",
-   channels, DECODER_MAX_CHANNES);
+   channels, DECODER_MAX_CHANNELS);
 return AVERROR(EINVAL);
 }
 
@@ -57,7 +56,6 @@ static av_cold int liblc3_decode_init(AVCodecContext *avctx)
 liblc3->srate_hz = avctx->sample_rate;
 ep_mode  = AV_RL16(avctx->extradata + 2);
 liblc3->hr_mode  = AV_RL16(avctx->extradata + 4);
-liblc3->length   = AV_RL32(avctx->extradata + 6);
 if (ep_mode != 0) {
 av_log(avctx, AV_LOG_ERROR,
"Error protection mode is not supported.\n");
@@ -126,11 +124,7 @@ static int liblc3_decode(AVCodecContext *avctx, AVFrame 
*frame,
 in += nbytes;
 }
 
-if (liblc3->length > 0) {
-int64_t end_pts = liblc3->length + avctx->delay;
-frame->nb_samples = FFMIN(frame->nb_samples,
-  FFMAX(end_pts - frame->pts, 0));
-}
+frame->nb_samples = FFMIN(frame->nb_samples, avpkt->duration);
 
 *got_frame_ptr = 1;
 
-- 
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-04 Thread Michael Niedermayer
On Mon, Apr 01, 2024 at 10:00:47PM +0200, 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.

I think the outcome is quite clear

Dijkstra got 7 votes, every other name had only 1

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Take away the freedom of one citizen and you will be jailed, take away
the freedom of all citizens and you will be congratulated by your peers
in Parliament.


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 v4 2/4] avcodec/{ass, webvttdec}: fix handling of backslashes

2024-04-04 Thread Stefano Sabatini
On date Thursday 2024-04-04 20:36:50 +0200, Oneric wrote:
> On Thu, Apr 04, 2024 at 13:26:55 -0500, Marth64 wrote:
> > >  Is \N a special sequence in ASS-speak
> > \N is the special line break sequence in ASS
> > 
> > I’m not sure of other special sequences following the \ character, I yield
> > to Oneric on this question.
> 
> Standard ASS(2) and SSAv4 have
>   \N (forced linebreak)
>   \n (linebreak hint)
>   \h (nonbreaking space)
> 
> libass further has \{ and \} dealt with by the following commit.
> Afaik no ASS renderer ever supported \\.
> 
> The added escaping happens for non-ASS format (in which those sequences
> are just normal text) which get encoded into ASS by ffmpeg. If it weren’t
> escaped we’d get sudden linebreaks, spaces etc and missing text.
> It doesn’t affect ASS->ASS remuxing.

Thanks for the clarification.

I think the patcheset should be good, but I'll wait a few days for
letting more comments.

I can fix the typos before pushing, or feel free to send an update.
___
ffmpeg-devel mailing list
ffmpeg-devel@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-04 Thread Marton Balint



On Mon, 1 Apr 2024, Poorva wrote:






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.


No, the last hunk still removes a newline.

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


[FFmpeg-devel] [PATCH] avcodec/jni: fix mixed declaration and code

2024-04-04 Thread Matthieu Bouron
---
 libavcodec/jni.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavcodec/jni.c b/libavcodec/jni.c
index 1193c608c3..fcb4837413 100644
--- a/libavcodec/jni.c
+++ b/libavcodec/jni.c
@@ -84,11 +84,13 @@ void *av_jni_get_java_vm(void *log_ctx)
 int av_jni_set_android_app_ctx(void *app_ctx, void *log_ctx)
 {
 #if CONFIG_JNI
+jobjectRefType type;
+
 JNIEnv *env = ff_jni_get_env(log_ctx);
 if (!env)
 return AVERROR(EINVAL);
 
-jobjectRefType type = (*env)->GetObjectRefType(env, app_ctx);
+type = (*env)->GetObjectRefType(env, app_ctx);
 if (type != JNIGlobalRefType) {
 av_log(log_ctx, AV_LOG_ERROR, "Application context must be passed as a 
global reference");
 return AVERROR(EINVAL);
-- 
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".


Re: [FFmpeg-devel] [PATCH v2 1/1] avcodec, avformat/ffjni: fix duplicate JNI symbols

2024-04-04 Thread Matthieu Bouron
On Tue, Apr 02, 2024 at 02:55:16PM +0200, Matthieu Bouron wrote:
> On Mon, Apr 01, 2024 at 10:03:54AM +0200, Matthieu Bouron wrote:
> > On Wed, Mar 27, 2024 at 09:06:19AM -0400, Leo Izen wrote:
> > > Use SHLIBOBJS and STLIBOBJS in the Makefiles for avcodec and avformat,
> > > and add a stub ffjni.c to libavformat, which allows the symbols to be
> > > duplicated for shared builds but not static builds.
> > > 
> > > Signed-off-by: Leo Izen 
> > > ---
> > >  libavcodec/Makefile  |  1 +
> > >  libavformat/Makefile |  1 +
> > >  libavformat/ffjni.c  | 23 +++
> > >  libavformat/file.c   |  2 +-
> > >  4 files changed, 26 insertions(+), 1 deletion(-)
> > >  create mode 100644 libavformat/ffjni.c
> > > 
> > > diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> > > index 9ce6d445c1..113adb22d5 100644
> > > --- a/libavcodec/Makefile
> > > +++ b/libavcodec/Makefile
> > > @@ -1068,6 +1068,7 @@ STLIBOBJS-$(CONFIG_ISO_MEDIA)  += 
> > > mpegaudiotabs.o
> > >  STLIBOBJS-$(CONFIG_FLV_MUXER)  += mpeg4audio_sample_rates.o
> > >  STLIBOBJS-$(CONFIG_HLS_DEMUXER)+= ac3_channel_layout_tab.o
> > >  STLIBOBJS-$(CONFIG_IMAGE_JPEGXL_PIPE_DEMUXER) += jpegxl_parse.o
> > > +STLIBOBJS-$(CONFIG_JNI)+= ffjni.o
> > >  STLIBOBJS-$(CONFIG_JPEGXL_ANIM_DEMUXER)   += jpegxl_parse.o
> > >  STLIBOBJS-$(CONFIG_MATROSKA_DEMUXER)   += mpeg4audio_sample_rates.o
> > >  STLIBOBJS-$(CONFIG_MOV_DEMUXER)+= ac3_channel_layout_tab.o
> > > diff --git a/libavformat/Makefile b/libavformat/Makefile
> > > index 44aa485029..a89df7e9a3 100644
> > > --- a/libavformat/Makefile
> > > +++ b/libavformat/Makefile
> > > @@ -728,6 +728,7 @@ SHLIBOBJS-$(CONFIG_ISO_MEDIA)+= 
> > > mpegaudiotabs.o
> > >  SHLIBOBJS-$(CONFIG_FLV_MUXER)+= mpeg4audio_sample_rates.o
> > >  SHLIBOBJS-$(CONFIG_HLS_DEMUXER)  += ac3_channel_layout_tab.o
> > >  SHLIBOBJS-$(CONFIG_IMAGE_JPEGXL_PIPE_DEMUXER)+= jpegxl_parse.o
> > > +SHLIBOBJS-$(CONFIG_JNI)  += ffjni.o
> > >  SHLIBOBJS-$(CONFIG_JPEGXL_ANIM_DEMUXER)  += jpegxl_parse.o
> > >  SHLIBOBJS-$(CONFIG_MATROSKA_DEMUXER) += mpeg4audio_sample_rates.o
> > >  SHLIBOBJS-$(CONFIG_MOV_DEMUXER)  += ac3_channel_layout_tab.o
> > > diff --git a/libavformat/ffjni.c b/libavformat/ffjni.c
> > > new file mode 100644
> > > index 00..2b1483cf42
> > > --- /dev/null
> > > +++ b/libavformat/ffjni.c
> > > @@ -0,0 +1,23 @@
> > > +/*
> > > + * JNI utility functions - included stub
> > > + *
> > > + * Copyright (c) 2024 Leo Izen 
> > > + *
> > > + * This file is part of FFmpeg.
> > > + *
> > > + * FFmpeg is free software; you can redistribute it and/or
> > > + * modify it under the terms of the GNU Lesser General Public
> > > + * License as published by the Free Software Foundation; either
> > > + * version 2.1 of the License, or (at your option) any later version.
> > > + *
> > > + * FFmpeg is distributed in the hope that it will be useful,
> > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> > > + * Lesser General Public License for more details.
> > > + *
> > > + * You should have received a copy of the GNU Lesser General Public
> > > + * License along with FFmpeg; if not, write to the Free Software
> > > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 
> > > 02110-1301 USA
> > > + */
> > > +
> > > +#include "libavcodec/ffjni.c"
> > > diff --git a/libavformat/file.c b/libavformat/file.c
> > > index 182995717a..1f853e0e17 100644
> > > --- a/libavformat/file.c
> > > +++ b/libavformat/file.c
> > > @@ -527,8 +527,8 @@ const URLProtocol ff_fd_protocol = {
> > >  
> > >  #if CONFIG_ANDROID_CONTENT_PROTOCOL
> > >  #include 
> > > +#include "libavcodec/ffjni.h"
> > >  #include "libavcodec/jni.h"
> > > -#include "libavcodec/ffjni.c"
> > >  
> > >  typedef struct JFields {
> > >  jclass uri_class;
> > 
> > LGTM, thanks.
> 
> Once the patch is applied. Can you also backport it to the 7.0 branch ?
> 
> Thanks in advance,

Applied and backported.

-- 
Matthieu B.
___
ffmpeg-devel mailing list
ffmpeg-devel@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/ppc/h264dsp: Fix left shifts of negative numbers

2024-04-04 Thread Andreas Rheinhardt
Andreas Rheinhardt:
> PPC equivalent of c756b3fca240df75ffa28e75f2eb34834c10294d.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/ppc/h264dsp.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/ppc/h264dsp.c b/libavcodec/ppc/h264dsp.c
> index f50f2553a2..0650768d7b 100644
> --- a/libavcodec/ppc/h264dsp.c
> +++ b/libavcodec/ppc/h264dsp.c
> @@ -663,7 +663,7 @@ void weight_h264_W_altivec(uint8_t *block, int stride, 
> int height,
>  DECLARE_ALIGNED(16, int32_t, temp)[4];
>  LOAD_ZERO;
>  
> -offset <<= log2_denom;
> +offset *= 1 << log2_denom;
>  if(log2_denom) offset += 1<<(log2_denom-1);
>  temp[0] = log2_denom;
>  temp[1] = weight;
> @@ -712,7 +712,7 @@ void biweight_h264_W_altivec(uint8_t *dst, uint8_t *src, 
> int stride, int height,
>  DECLARE_ALIGNED(16, int32_t, temp)[4];
>  LOAD_ZERO;
>  
> -offset = ((offset + 1) | 1) << log2_denom;
> +offset = ((offset + 1) | 1) * (1 << log2_denom);
>  temp[0] = log2_denom+1;
>  temp[1] = weights;
>  temp[2] = weightd;

Will apply so that this makes it into 7.0.

- 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 9/9] avcodec/dv: Don't pretend initializing work chunks can fail

2024-04-04 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/dv.c  | 4 +---
 libavcodec/dv_internal.h | 2 +-
 libavcodec/dvdec.c   | 6 +-
 libavcodec/dvenc.c   | 6 +-
 4 files changed, 4 insertions(+), 14 deletions(-)

diff --git a/libavcodec/dv.c b/libavcodec/dv.c
index eb49978ad8..194d982562 100644
--- a/libavcodec/dv.c
+++ b/libavcodec/dv.c
@@ -166,7 +166,7 @@ static inline void dv_calc_mb_coordinates(const AVDVProfile 
*d, int chan,
 }
 }
 
-int ff_dv_init_dynamic_tables(DVwork_chunk *work_chunks, const AVDVProfile *d)
+void ff_dv_init_dynamic_tables(DVwork_chunk *work_chunks, const AVDVProfile *d)
 {
 int j, i, c, s, p;
 
@@ -185,6 +185,4 @@ int ff_dv_init_dynamic_tables(DVwork_chunk *work_chunks, 
const AVDVProfile *d)
 }
 }
 }
-
-return 0;
 }
diff --git a/libavcodec/dv_internal.h b/libavcodec/dv_internal.h
index 4b4151c88d..05e26a8138 100644
--- a/libavcodec/dv_internal.h
+++ b/libavcodec/dv_internal.h
@@ -32,7 +32,7 @@ typedef struct DVwork_chunk {
 uint16_t mb_coordinates[5];
 } DVwork_chunk;
 
-int ff_dv_init_dynamic_tables(DVwork_chunk *work_chunks, const AVDVProfile *d);
+void ff_dv_init_dynamic_tables(DVwork_chunk *work_chunks, const AVDVProfile 
*d);
 
 static inline int dv_work_pool_size(const AVDVProfile *d)
 {
diff --git a/libavcodec/dvdec.c b/libavcodec/dvdec.c
index a06e4807e7..9e8d40187d 100644
--- a/libavcodec/dvdec.c
+++ b/libavcodec/dvdec.c
@@ -637,11 +637,7 @@ static int dvvideo_decode_frame(AVCodecContext *avctx, 
AVFrame *frame,
 }
 
 if (sys != s->sys) {
-ret = ff_dv_init_dynamic_tables(s->work_chunks, sys);
-if (ret < 0) {
-av_log(avctx, AV_LOG_ERROR, "Error initializing the work 
tables.\n");
-return ret;
-}
+ff_dv_init_dynamic_tables(s->work_chunks, sys);
 dv_init_weight_tables(s, sys);
 s->sys = sys;
 }
diff --git a/libavcodec/dvenc.c b/libavcodec/dvenc.c
index ce21247081..3afeedbb87 100644
--- a/libavcodec/dvenc.c
+++ b/libavcodec/dvenc.c
@@ -93,11 +93,7 @@ static av_cold int dvvideo_encode_init(AVCodecContext *avctx)
 return AVERROR(EINVAL);
 }
 
-ret = ff_dv_init_dynamic_tables(s->work_chunks, s->sys);
-if (ret < 0) {
-av_log(avctx, AV_LOG_ERROR, "Error initializing work tables.\n");
-return ret;
-}
+ff_dv_init_dynamic_tables(s->work_chunks, s->sys);
 
 memset(,0, sizeof(fdsp));
 memset(,0, sizeof(mecc));
-- 
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 8/9] avcodec/huffyuvdec: Use assert to check for things that can't fail

2024-04-04 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/huffyuvdec.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavcodec/huffyuvdec.c b/libavcodec/huffyuvdec.c
index e35d55c8ad..a8ccb724f5 100644
--- a/libavcodec/huffyuvdec.c
+++ b/libavcodec/huffyuvdec.c
@@ -290,13 +290,13 @@ static int read_old_huffman_tables(HYuvDecContext *s)
 
 bytestream2_init(, classic_shift_luma,
  sizeof(classic_shift_luma));
-if ((ret = read_len_table(s->len[0], , 256)) < 0)
-return ret;
+ret = read_len_table(s->len[0], , 256);
+av_assert1(ret >= 0);
 
 bytestream2_init(, classic_shift_chroma,
  sizeof(classic_shift_chroma));
-if ((ret = read_len_table(s->len[1], , 256)) < 0)
-return ret;
+ret = read_len_table(s->len[1], , 256);
+av_assert1(ret >= 0);
 
 for (i = 0; i < 256; i++)
 s->bits[0][i] = classic_add_luma[i];
-- 
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 9/9] avcodec/dv: Don't pretend initializing work chunks can fail

2024-04-04 Thread Andreas Rheinhardt
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/dv.c  | 4 +---
>  libavcodec/dv_internal.h | 2 +-
>  libavcodec/dvdec.c   | 6 +-
>  libavcodec/dvenc.c   | 6 +-
>  4 files changed, 4 insertions(+), 14 deletions(-)
> 
> diff --git a/libavcodec/dv.c b/libavcodec/dv.c
> index eb49978ad8..194d982562 100644
> --- a/libavcodec/dv.c
> +++ b/libavcodec/dv.c
> @@ -166,7 +166,7 @@ static inline void dv_calc_mb_coordinates(const 
> AVDVProfile *d, int chan,
>  }
>  }
>  
> -int ff_dv_init_dynamic_tables(DVwork_chunk *work_chunks, const AVDVProfile 
> *d)
> +void ff_dv_init_dynamic_tables(DVwork_chunk *work_chunks, const AVDVProfile 
> *d)
>  {
>  int j, i, c, s, p;
>  
> @@ -185,6 +185,4 @@ int ff_dv_init_dynamic_tables(DVwork_chunk *work_chunks, 
> const AVDVProfile *d)
>  }
>  }
>  }
> -
> -return 0;
>  }
> diff --git a/libavcodec/dv_internal.h b/libavcodec/dv_internal.h
> index 4b4151c88d..05e26a8138 100644
> --- a/libavcodec/dv_internal.h
> +++ b/libavcodec/dv_internal.h
> @@ -32,7 +32,7 @@ typedef struct DVwork_chunk {
>  uint16_t mb_coordinates[5];
>  } DVwork_chunk;
>  
> -int ff_dv_init_dynamic_tables(DVwork_chunk *work_chunks, const AVDVProfile 
> *d);
> +void ff_dv_init_dynamic_tables(DVwork_chunk *work_chunks, const AVDVProfile 
> *d);
>  
>  static inline int dv_work_pool_size(const AVDVProfile *d)
>  {
> diff --git a/libavcodec/dvdec.c b/libavcodec/dvdec.c
> index a06e4807e7..9e8d40187d 100644
> --- a/libavcodec/dvdec.c
> +++ b/libavcodec/dvdec.c
> @@ -637,11 +637,7 @@ static int dvvideo_decode_frame(AVCodecContext *avctx, 
> AVFrame *frame,
>  }
>  
>  if (sys != s->sys) {
> -ret = ff_dv_init_dynamic_tables(s->work_chunks, sys);
> -if (ret < 0) {
> -av_log(avctx, AV_LOG_ERROR, "Error initializing the work 
> tables.\n");
> -return ret;
> -}
> +ff_dv_init_dynamic_tables(s->work_chunks, sys);
>  dv_init_weight_tables(s, sys);
>  s->sys = sys;
>  }
> diff --git a/libavcodec/dvenc.c b/libavcodec/dvenc.c
> index ce21247081..3afeedbb87 100644
> --- a/libavcodec/dvenc.c
> +++ b/libavcodec/dvenc.c
> @@ -93,11 +93,7 @@ static av_cold int dvvideo_encode_init(AVCodecContext 
> *avctx)
>  return AVERROR(EINVAL);
>  }
>  
> -ret = ff_dv_init_dynamic_tables(s->work_chunks, s->sys);
> -if (ret < 0) {
> -av_log(avctx, AV_LOG_ERROR, "Error initializing work tables.\n");
> -return ret;
> -}
> +ff_dv_init_dynamic_tables(s->work_chunks, s->sys);
>  
>  memset(,0, sizeof(fdsp));
>  memset(,0, sizeof(mecc));

Sorry, sent the wrong patches. Ignore v1 of #8 and #9.

- 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 v2 9/9] avcodec/huffyuvdec: Use assert to check for things that can't fail

2024-04-04 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/huffyuvdec.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavcodec/huffyuvdec.c b/libavcodec/huffyuvdec.c
index e35d55c8ad..a8ccb724f5 100644
--- a/libavcodec/huffyuvdec.c
+++ b/libavcodec/huffyuvdec.c
@@ -290,13 +290,13 @@ static int read_old_huffman_tables(HYuvDecContext *s)
 
 bytestream2_init(, classic_shift_luma,
  sizeof(classic_shift_luma));
-if ((ret = read_len_table(s->len[0], , 256)) < 0)
-return ret;
+ret = read_len_table(s->len[0], , 256);
+av_assert1(ret >= 0);
 
 bytestream2_init(, classic_shift_chroma,
  sizeof(classic_shift_chroma));
-if ((ret = read_len_table(s->len[1], , 256)) < 0)
-return ret;
+ret = read_len_table(s->len[1], , 256);
+av_assert1(ret >= 0);
 
 for (i = 0; i < 256; i++)
 s->bits[0][i] = classic_add_luma[i];
-- 
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 v2 8/9] avcodec/huffyuvdec: Use bytestream API for byte-aligned reads

2024-04-04 Thread Andreas Rheinhardt
This also allows to remove the padding from these buffers.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/huffyuvdec.c | 53 ++---
 1 file changed, 28 insertions(+), 25 deletions(-)

diff --git a/libavcodec/huffyuvdec.c b/libavcodec/huffyuvdec.c
index 12ecfcb933..e35d55c8ad 100644
--- a/libavcodec/huffyuvdec.c
+++ b/libavcodec/huffyuvdec.c
@@ -36,6 +36,7 @@
 
 #include "avcodec.h"
 #include "bswapdsp.h"
+#include "bytestream.h"
 #include "codec_internal.h"
 #include "get_bits.h"
 #include "huffyuv.h"
@@ -86,21 +87,17 @@ typedef struct HYuvDecContext {
 } HYuvDecContext;
 
 
-#define classic_shift_luma_table_size 42
-static const unsigned char classic_shift_luma[classic_shift_luma_table_size + 
AV_INPUT_BUFFER_PADDING_SIZE] = {
+static const uint8_t classic_shift_luma[] = {
 34, 36, 35, 69, 135, 232,   9, 16, 10, 24,  11,  23,  12,  16, 13, 10,
 14,  8, 15,  8,  16,   8,  17, 20, 16, 10, 207, 206, 205, 236, 11,  8,
-10, 21,  9, 23,   8,   8, 199, 70, 69, 68,   0,
-  0,0,0,0,0,0,0,0,
+10, 21,  9, 23,   8,   8, 199, 70, 69, 68,
 };
 
-#define classic_shift_chroma_table_size 59
-static const unsigned char 
classic_shift_chroma[classic_shift_chroma_table_size + 
AV_INPUT_BUFFER_PADDING_SIZE] = {
+static const uint8_t classic_shift_chroma[] = {
 66, 36,  37,  38, 39, 40,  41,  75,  76,  77, 110, 239, 144, 81, 82,  83,
 84, 85, 118, 183, 56, 57,  88,  89,  56,  89, 154,  57,  58, 57, 26, 141,
 57, 56,  58,  57, 58, 57, 184, 119, 214, 245, 116,  83,  82, 49, 80,  79,
-78, 77,  44,  75, 41, 40,  39,  38,  37,  36,  34,  0,
-  0,0,0,0,0,0,0,0,
+78, 77,  44,  75, 41, 40,  39,  38,  37,  36,  34,
 };
 
 static const unsigned char classic_add_luma[256] = {
@@ -141,23 +138,30 @@ static const unsigned char classic_add_chroma[256] = {
   6,  12,   8,  10,   7,   9,   6,   4,   6,   2,   2,   3,   3,   3,   3, 
  2,
 };
 
-static int read_len_table(uint8_t *dst, GetBitContext *gb, int n)
+static int read_len_table(uint8_t *dst, GetByteContext *gb, int n)
 {
 int i, val, repeat;
 
 for (i = 0; i < n;) {
-repeat = get_bits(gb, 3);
-val= get_bits(gb, 5);
-if (repeat == 0)
-repeat = get_bits(gb, 8);
-if (i + repeat > n || get_bits_left(gb) < 0) {
-av_log(NULL, AV_LOG_ERROR, "Error reading huffman table\n");
-return AVERROR_INVALIDDATA;
+if (bytestream2_get_bytes_left(gb) <= 0)
+goto error;
+repeat = bytestream2_peek_byteu(gb) >> 5;
+val= bytestream2_get_byteu(gb) & 0x1F;
+if (repeat == 0) {
+if (bytestream2_get_bytes_left(gb) <= 0)
+goto error;
+repeat = bytestream2_get_byteu(gb);
 }
+if (i + repeat > n)
+goto error;
 while (repeat--)
 dst[i++] = val;
 }
 return 0;
+
+error:
+av_log(NULL, AV_LOG_ERROR, "Error reading huffman table\n");
+return AVERROR_INVALIDDATA;
 }
 
 static int generate_joint_tables(HYuvDecContext *s)
@@ -253,12 +257,11 @@ out:
 
 static int read_huffman_tables(HYuvDecContext *s, const uint8_t *src, int 
length)
 {
-GetBitContext gb;
+GetByteContext gb;
 int i, ret;
 int count = 3;
 
-if ((ret = init_get_bits(, src, length * 8)) < 0)
-return ret;
+bytestream2_init(, src, length);
 
 if (s->version > 2)
 count = 1 + s->alpha + 2*s->chroma;
@@ -277,21 +280,21 @@ static int read_huffman_tables(HYuvDecContext *s, const 
uint8_t *src, int length
 if ((ret = generate_joint_tables(s)) < 0)
 return ret;
 
-return (get_bits_count() + 7) / 8;
+return bytestream2_tell();
 }
 
 static int read_old_huffman_tables(HYuvDecContext *s)
 {
-GetBitContext gb;
+GetByteContext gb;
 int i, ret;
 
-init_get_bits(, classic_shift_luma,
-  classic_shift_luma_table_size * 8);
+bytestream2_init(, classic_shift_luma,
+ sizeof(classic_shift_luma));
 if ((ret = read_len_table(s->len[0], , 256)) < 0)
 return ret;
 
-init_get_bits(, classic_shift_chroma,
-  classic_shift_chroma_table_size * 8);
+bytestream2_init(, classic_shift_chroma,
+ sizeof(classic_shift_chroma));
 if ((ret = read_len_table(s->len[1], , 256)) < 0)
 return ret;
 
-- 
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] avcodec/dv: Don't pretend initializing work chunks can fail

2024-04-04 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/dv.c  | 4 +---
 libavcodec/dv_internal.h | 2 +-
 libavcodec/dvdec.c   | 6 +-
 libavcodec/dvenc.c   | 6 +-
 4 files changed, 4 insertions(+), 14 deletions(-)

diff --git a/libavcodec/dv.c b/libavcodec/dv.c
index eb49978ad8..194d982562 100644
--- a/libavcodec/dv.c
+++ b/libavcodec/dv.c
@@ -166,7 +166,7 @@ static inline void dv_calc_mb_coordinates(const AVDVProfile 
*d, int chan,
 }
 }
 
-int ff_dv_init_dynamic_tables(DVwork_chunk *work_chunks, const AVDVProfile *d)
+void ff_dv_init_dynamic_tables(DVwork_chunk *work_chunks, const AVDVProfile *d)
 {
 int j, i, c, s, p;
 
@@ -185,6 +185,4 @@ int ff_dv_init_dynamic_tables(DVwork_chunk *work_chunks, 
const AVDVProfile *d)
 }
 }
 }
-
-return 0;
 }
diff --git a/libavcodec/dv_internal.h b/libavcodec/dv_internal.h
index 4b4151c88d..05e26a8138 100644
--- a/libavcodec/dv_internal.h
+++ b/libavcodec/dv_internal.h
@@ -32,7 +32,7 @@ typedef struct DVwork_chunk {
 uint16_t mb_coordinates[5];
 } DVwork_chunk;
 
-int ff_dv_init_dynamic_tables(DVwork_chunk *work_chunks, const AVDVProfile *d);
+void ff_dv_init_dynamic_tables(DVwork_chunk *work_chunks, const AVDVProfile 
*d);
 
 static inline int dv_work_pool_size(const AVDVProfile *d)
 {
diff --git a/libavcodec/dvdec.c b/libavcodec/dvdec.c
index a06e4807e7..9e8d40187d 100644
--- a/libavcodec/dvdec.c
+++ b/libavcodec/dvdec.c
@@ -637,11 +637,7 @@ static int dvvideo_decode_frame(AVCodecContext *avctx, 
AVFrame *frame,
 }
 
 if (sys != s->sys) {
-ret = ff_dv_init_dynamic_tables(s->work_chunks, sys);
-if (ret < 0) {
-av_log(avctx, AV_LOG_ERROR, "Error initializing the work 
tables.\n");
-return ret;
-}
+ff_dv_init_dynamic_tables(s->work_chunks, sys);
 dv_init_weight_tables(s, sys);
 s->sys = sys;
 }
diff --git a/libavcodec/dvenc.c b/libavcodec/dvenc.c
index ce21247081..3afeedbb87 100644
--- a/libavcodec/dvenc.c
+++ b/libavcodec/dvenc.c
@@ -93,11 +93,7 @@ static av_cold int dvvideo_encode_init(AVCodecContext *avctx)
 return AVERROR(EINVAL);
 }
 
-ret = ff_dv_init_dynamic_tables(s->work_chunks, s->sys);
-if (ret < 0) {
-av_log(avctx, AV_LOG_ERROR, "Error initializing work tables.\n");
-return ret;
-}
+ff_dv_init_dynamic_tables(s->work_chunks, s->sys);
 
 memset(,0, sizeof(fdsp));
 memset(,0, sizeof(mecc));
-- 
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 5/5] avformat/pcm: Use 64bit in bitrate computation

2024-04-04 Thread Michael Niedermayer
On Thu, Apr 04, 2024 at 07:12:40PM +0200, Marton Balint wrote:
> 
> 
> On Thu, 4 Apr 2024, Michael Niedermayer wrote:
> 
> > Fixes: signed integer overflow: 65792 * 65312 cannot be represented in type 
> > 'int'
> > Fixes: 
> > 67819/clusterfuzz-testcase-minimized-ffmpeg_dem_WADY_fuzzer-5236100912185344
> > 
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> > libavformat/pcm.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/libavformat/pcm.c b/libavformat/pcm.c
> > index 051e86dd464..a774dbc3726 100644
> > --- a/libavformat/pcm.c
> > +++ b/libavformat/pcm.c
> > @@ -41,7 +41,7 @@ int ff_pcm_default_packet_size(AVCodecParameters *par)
> > /* Don't trust the codecpar bitrate if we can calculate it ourselves */
> > if (bits_per_sample > 0 && par->sample_rate > 0 && 
> > par->ch_layout.nb_channels > 0)
> > if ((int64_t)par->sample_rate * par->ch_layout.nb_channels < 
> > INT64_MAX / bits_per_sample)
> > -bitrate = bits_per_sample * par->sample_rate * 
> > par->ch_layout.nb_channels;
> > +bitrate = bits_per_sample * (int64_t)par->sample_rate * 
> > par->ch_layout.nb_channels;
> 
> LGTM, thanks.
> 
> I wonder why we usually cast the second operand and not the first to 64 bit,
> since cast has higher precedence than multiplication, it should not matter,
> should it?

If the reader isnt sure about the precedence, writing it as
a * (int64_t)b
has the advantage that precedence doesnt matter, so the code is easier to
understand and verify than

(int64_t)a * b

thx


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

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope


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

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


Re: [FFmpeg-devel] [PATCH v4 2/4] avcodec/{ass, webvttdec}: fix handling of backslashes

2024-04-04 Thread Oneric
On Thu, Apr 04, 2024 at 13:26:55 -0500, Marth64 wrote:
> >  Is \N a special sequence in ASS-speak
> \N is the special line break sequence in ASS
> 
> I’m not sure of other special sequences following the \ character, I yield
> to Oneric on this question.

Standard ASS(2) and SSAv4 have
  \N (forced linebreak)
  \n (linebreak hint)
  \h (nonbreaking space)

libass further has \{ and \} dealt with by the following commit.
Afaik no ASS renderer ever supported \\.

The added escaping happens for non-ASS format (in which those sequences
are just normal text) which get encoded into ASS by ffmpeg. If it weren’t
escaped we’d get sudden linebreaks, spaces etc and missing text.
It doesn’t affect ASS->ASS remuxing.


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 v4 2/4] avcodec/{ass, webvttdec}: fix handling of backslashes

2024-04-04 Thread Marth64
>  Is \N a special sequence in ASS-speak
\N is the special line break sequence in ASS

I’m not sure of other special sequences following the \ character, I yield
to Oneric on this question.

Best,
Marth64
___
ffmpeg-devel mailing list
ffmpeg-devel@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 2/4] avcodec/{ass, webvttdec}: fix handling of backslashes

2024-04-04 Thread Stefano Sabatini
On date Thursday 2024-04-04 12:56:30 -0500, Marth64 wrote:
> > I'm confused by this, what kind of \N
> > sequences might appear in an ASS file?
> > Can you show an offending sequence?
> 
> Good day Stefano,
> 

> The one I tested with was something like :
> Jim\Nancy

Is N a literal or is this impacting also sequences in the form:
Jim\Joe?

Is \N a special sequence in ASS-speak or does it mean a slash followed
by any character?
___
ffmpeg-devel mailing list
ffmpeg-devel@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 2/4] avcodec/{ass, webvttdec}: fix handling of backslashes

2024-04-04 Thread Marth64
> I'm confused by this, what kind of \N
> sequences might appear in an ASS file?
> Can you show an offending sequence?

Good day Stefano,

The one I tested with was something like :
Jim\Nancy

I made this up while testing. But I have seen similar in real world
scenarios particularly in ASS files originating from subtitles that are
“summarized”. In legacy content this is common, to fit content in a 4:3
screen the subtitle writer would shorten or abbreviate what is spoken on
the screen and slashes are a replacement for “and”.

Hope this helps.
___
ffmpeg-devel mailing list
ffmpeg-devel@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/huffyuvenc: Deduplicate options

2024-04-04 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/huffyuvenc.c | 42 ++---
 1 file changed, 18 insertions(+), 24 deletions(-)

diff --git a/libavcodec/huffyuvenc.c b/libavcodec/huffyuvenc.c
index d822793406..294d6ad41c 100644
--- a/libavcodec/huffyuvenc.c
+++ b/libavcodec/huffyuvenc.c
@@ -989,37 +989,24 @@ static av_cold int encode_end(AVCodecContext *avctx)
 #define OFFSET(x) offsetof(HYuvEncContext, x)
 #define VE AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_ENCODING_PARAM
 
-#define COMMON_OPTIONS \
-{ "non_deterministic", "Allow multithreading for e.g. context=1 at the 
expense of determinism", \
-  OFFSET(non_determ), AV_OPT_TYPE_BOOL, { .i64 = 0 }, \
-  0, 1, VE }, \
-{ "pred", "Prediction method", OFFSET(predictor), AV_OPT_TYPE_INT, { .i64 
= LEFT }, LEFT, MEDIAN, VE, .unit = "pred" }, \
-{ "left",   NULL, 0, AV_OPT_TYPE_CONST, { .i64 = LEFT },   INT_MIN, 
INT_MAX, VE, .unit = "pred" }, \
-{ "plane",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = PLANE },  INT_MIN, 
INT_MAX, VE, .unit = "pred" }, \
-{ "median", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MEDIAN }, INT_MIN, 
INT_MAX, VE, .unit = "pred" }, \
-
-static const AVOption normal_options[] = {
-COMMON_OPTIONS
-{ NULL },
-};
-
-static const AVOption ff_options[] = {
-COMMON_OPTIONS
+static const AVOption options[] = {
+/* ffvhuff-only options */
 { "context", "Set per-frame huffman tables", OFFSET(context), 
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, VE },
+/* Common options */
+{ "non_deterministic", "Allow multithreading for e.g. context=1 at the 
expense of determinism",
+  OFFSET(non_determ), AV_OPT_TYPE_BOOL, { .i64 = 0 },
+  0, 1, VE },
+{ "pred", "Prediction method", OFFSET(predictor), AV_OPT_TYPE_INT, { .i64 
= LEFT }, LEFT, MEDIAN, VE, .unit = "pred" },
+{ "left",   NULL, 0, AV_OPT_TYPE_CONST, { .i64 = LEFT },   INT_MIN, 
INT_MAX, VE, .unit = "pred" },
+{ "plane",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = PLANE },  INT_MIN, 
INT_MAX, VE, .unit = "pred" },
+{ "median", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MEDIAN }, INT_MIN, 
INT_MAX, VE, .unit = "pred" },
 { NULL },
 };
 
 static const AVClass normal_class = {
 .class_name = "huffyuv",
 .item_name  = av_default_item_name,
-.option = normal_options,
-.version= LIBAVUTIL_VERSION_INT,
-};
-
-static const AVClass ff_class = {
-.class_name = "ffvhuff",
-.item_name  = av_default_item_name,
-.option = ff_options,
+.option = options + 1,
 .version= LIBAVUTIL_VERSION_INT,
 };
 
@@ -1043,6 +1030,13 @@ const FFCodec ff_huffyuv_encoder = {
 };
 
 #if CONFIG_FFVHUFF_ENCODER
+static const AVClass ff_class = {
+.class_name = "ffvhuff",
+.item_name  = av_default_item_name,
+.option = options,
+.version= LIBAVUTIL_VERSION_INT,
+};
+
 const FFCodec ff_ffvhuff_encoder = {
 .p.name = "ffvhuff",
 CODEC_LONG_NAME("Huffyuv FFmpeg variant"),
-- 
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 v4 4/4] avocdec/ass: simplify linebreaks

2024-04-04 Thread Stefano Sabatini
On date Monday 2024-02-19 22:42:27 +0100, Oneric wrote:
> ff_ass_subtitle_header_* still used explicit CRLF linebreaks
> eventhough they will get normalised to LF later since commit
> 7bf1b9b35769b37684dd2f18a54f01d852a540c8. Just directly use LF.
> ---
>  libavcodec/ass.c | 28 ++--
>  1 file changed, 14 insertions(+), 14 deletions(-)

Looks good to me, 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".


Re: [FFmpeg-devel] [PATCH v4 3/4] avcodec/{ass, webvttdec}: more portable curly brace escapes

2024-04-04 Thread Stefano Sabatini
On date Monday 2024-02-19 22:42:26 +0100, Oneric wrote:
> Unlike what the old comment suggested, standard ASS has no character
> escape mechanism, but a closing curly bracket doesn't even need one.
> 

> For manual authored sub files using a full-width variant of an apropiate

appropriate?

> font and with scaling and psacing modifiers is a common workaround.

spacing

> This is not an option here, but we can still make things much less bad.
> Now the desired opening bracket still shows up in libass and
> standard renders will merely display a backslash in its place
> instead of stripping the following text like before.
> ---
>  libavcodec/ass.c  | 12 
>  libavcodec/webvttdec.c|  2 +-
>  tests/ref/fate/sub-webvtt |  2 +-
>  3 files changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/libavcodec/ass.c b/libavcodec/ass.c
> index a68d3568b4..e7a1ac0eb5 100644
> --- a/libavcodec/ass.c
> +++ b/libavcodec/ass.c
> @@ -181,10 +181,14 @@ void ff_ass_bprint_text_event(AVBPrint *buf, const char 
> *p, int size,
>  if (linebreaks && strchr(linebreaks, *p)) {
>  av_bprintf(buf, "\\N");
>  
> -/* standard ASS escaping so random characters don't get 
> mis-interpreted
> - * as ASS */
> -} else if (!keep_ass_markup && strchr("{}", *p)) {
> -av_bprintf(buf, "\\%c", *p);
> +/* cancel curly brackets to avoid bogus override tag blocks
> + * hiding text. Standard ASS has no character escapes,
> + * though (only) libass provides \{ and \}.
> + * Unpaired closing brackets don't need escaping at all though and
> + * to make the situation less bad in standard ASS insert an empty 
> block
> + */
> +} else if (!keep_ass_markup && *p == '{') {
> +av_bprintf(buf, "\\{{}");
>  
>  /* append word-joiner U+2060 as UTF-8 to break up sequences like \N 
> */
>  } else if (!keep_ass_markup && *p == '\\') {
> diff --git a/libavcodec/webvttdec.c b/libavcodec/webvttdec.c
> index 6e55bc5499..35bdbe805d 100644
> --- a/libavcodec/webvttdec.c
> +++ b/libavcodec/webvttdec.c
> @@ -37,7 +37,7 @@ static const struct {
>  {"", "{\\i1}"}, {"", "{\\i0}"},
>  {"", "{\\b1}"}, {"", "{\\b0}"},
>  {"", "{\\u1}"}, {"", "{\\u0}"},
> -{"{", "\\{"}, {"}", "\\}"}, {"\\", "\\\xe2\x81\xa0"}, // escape to avoid 
> ASS markup conflicts
> +{"{", "\\{{}"}, {"\\", "\\\xe2\x81\xa0"}, // escape to avoid ASS markup 
> conflicts
>  {"", ">"}, {"", "<"},
>  {"", "\xe2\x80\x8e"}, {"", "\xe2\x80\x8f"},
>  {"", "&"}, {"", "\\h"},
> diff --git a/tests/ref/fate/sub-webvtt b/tests/ref/fate/sub-webvtt
> index ea587b327c..fae50607fb 100644
> --- a/tests/ref/fate/sub-webvtt
> +++ b/tests/ref/fate/sub-webvtt
> @@ -21,7 +21,7 @@ Dialogue: 0,0:00:22.00,0:00:24.00,Default,,0,0,0,,at the 
> AMNH.
>  Dialogue: 0,0:00:24.00,0:00:26.00,Default,,0,0,0,,Thank you for walking down 
> here.
>  Dialogue: 0,0:00:27.00,0:00:30.00,Default,,0,0,0,,And I want to do a 
> follow-up on the last conversation we did.\Nmultiple lines\Nagain
>  Dialogue: 0,0:00:30.00,0:00:31.50,Default,,0,0,0,,When we e-mailed—
> -Dialogue: 0,0:00:30.50,0:00:32.50,Default,,0,0,0,,Didn't we {\b1}talk 
> {\i1}about\N{\i0} enough{\b0} in that conversation? \{I'm not an ASS comment\}
> +Dialogue: 0,0:00:30.50,0:00:32.50,Default,,0,0,0,,Didn't we {\b1}talk 
> {\i1}about\N{\i0} enough{\b0} in that conversation? \{{}I'm not an ASS 
> comment}
>  Dialogue: 0,0:00:32.00,0:00:35.50,Default,,0,0,0,,No! No no no no; 'cos 'cos 
> obviously 'cos
>  Dialogue: 0,0:00:32.50,0:00:33.50,Default,,0,0,0,,{\i1}Laughs{\i0}
>  Dialogue: 0,0:00:35.50,0:00:38.00,Default,,0,0,0,,You know I'm so excited my 
> glasses are falling off here.

Should be good otherwise (but a second look from someone more familiar
with ASS also might be good).
___
ffmpeg-devel mailing list
ffmpeg-devel@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 2/4] avcodec/{ass, webvttdec}: fix handling of backslashes

2024-04-04 Thread Stefano Sabatini
On date Monday 2024-02-19 22:42:25 +0100, Oneric wrote:
> Backslashes cannot be escaped by a backslash in any ASS renderer,
> but unless followed by specific characters it is just printed out.
> Insert a word-joiner character after a backslash to break up
> active sequences without changing the visual output.
> ---
>  libavcodec/ass.c   | 9 -
>  libavcodec/webvttdec.c | 2 +-
>  2 files changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/ass.c b/libavcodec/ass.c
> index 5058dc8337..a68d3568b4 100644
> --- a/libavcodec/ass.c
> +++ b/libavcodec/ass.c
> @@ -183,9 +183,16 @@ void ff_ass_bprint_text_event(AVBPrint *buf, const char 
> *p, int size,
>  
>  /* standard ASS escaping so random characters don't get 
> mis-interpreted
>   * as ASS */
> -} else if (!keep_ass_markup && strchr("{}\\", *p)) {
> +} else if (!keep_ass_markup && strchr("{}", *p)) {
>  av_bprintf(buf, "\\%c", *p);
>  

> +/* append word-joiner U+2060 as UTF-8 to break up sequences like \N 
> */

I'm confused by this, what kind of \N sequences might appear in an ASS
file? Can you show an offending sequence?

> +} else if (!keep_ass_markup && *p == '\\') {
> +if (p_end - p <= 3 || strncmp(p + 1, "\xe2\x81\xa0", 3))
> +av_bprintf(buf, "\\\xe2\x81\xa0");
> +else
> +av_bprintf(buf, "\\");
> +
>  /* some packets might end abruptly (no \0 at the end, like for 
> example
>   * in some cases of demuxing from a classic video container), some
>   * might be terminated with \n or \r\n which we have to remove (for
> diff --git a/libavcodec/webvttdec.c b/libavcodec/webvttdec.c
> index 990d150f16..6e55bc5499 100644
> --- a/libavcodec/webvttdec.c
> +++ b/libavcodec/webvttdec.c
> @@ -37,7 +37,7 @@ static const struct {
>  {"", "{\\i1}"}, {"", "{\\i0}"},
>  {"", "{\\b1}"}, {"", "{\\b0}"},
>  {"", "{\\u1}"}, {"", "{\\u0}"},
> -{"{", "\\{"}, {"}", "\\}"}, // escape to avoid ASS markup conflicts
> +{"{", "\\{"}, {"}", "\\}"}, {"\\", "\\\xe2\x81\xa0"}, // escape to avoid 
> ASS markup conflicts
>  {"", ">"}, {"", "<"},
>  {"", "\xe2\x80\x8e"}, {"", "\xe2\x80\x8f"},
>  {"", "&"}, {"", "\\h"},
___
ffmpeg-devel mailing list
ffmpeg-devel@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 5/5] avformat/pcm: Use 64bit in bitrate computation

2024-04-04 Thread Andreas Rheinhardt
Marton Balint:
> 
> 
> On Thu, 4 Apr 2024, Michael Niedermayer wrote:
> 
>> Fixes: signed integer overflow: 65792 * 65312 cannot be represented in
>> type 'int'
>> Fixes:
>> 67819/clusterfuzz-testcase-minimized-ffmpeg_dem_WADY_fuzzer-5236100912185344
>>
>> Found-by: continuous fuzzing process
>> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>> Signed-off-by: Michael Niedermayer 
>> ---
>> libavformat/pcm.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavformat/pcm.c b/libavformat/pcm.c
>> index 051e86dd464..a774dbc3726 100644
>> --- a/libavformat/pcm.c
>> +++ b/libavformat/pcm.c
>> @@ -41,7 +41,7 @@ int ff_pcm_default_packet_size(AVCodecParameters *par)
>>     /* Don't trust the codecpar bitrate if we can calculate it
>> ourselves */
>>     if (bits_per_sample > 0 && par->sample_rate > 0 &&
>> par->ch_layout.nb_channels > 0)
>>     if ((int64_t)par->sample_rate * par->ch_layout.nb_channels <
>> INT64_MAX / bits_per_sample)
>> -    bitrate = bits_per_sample * par->sample_rate *
>> par->ch_layout.nb_channels;
>> +    bitrate = bits_per_sample * (int64_t)par->sample_rate *
>> par->ch_layout.nb_channels;
> 
> LGTM, thanks.
> 
> I wonder why we usually cast the second operand and not the first to 64
> bit, since cast has higher precedence than multiplication, it should not
> matter, should it?
> 

Presuming that all variables here have integer conversion rank <=
int64_t (true here for normal systems), then it does not matter: Casting
the first operand would automatically promote all the other operands to
int64_t, too; but if you add the cast to the last operand only, the
first multiplication will be performed with ints only.

- 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 5/5] avformat/pcm: Use 64bit in bitrate computation

2024-04-04 Thread Marton Balint




On Thu, 4 Apr 2024, Michael Niedermayer wrote:


Fixes: signed integer overflow: 65792 * 65312 cannot be represented in type 
'int'
Fixes: 
67819/clusterfuzz-testcase-minimized-ffmpeg_dem_WADY_fuzzer-5236100912185344

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

diff --git a/libavformat/pcm.c b/libavformat/pcm.c
index 051e86dd464..a774dbc3726 100644
--- a/libavformat/pcm.c
+++ b/libavformat/pcm.c
@@ -41,7 +41,7 @@ int ff_pcm_default_packet_size(AVCodecParameters *par)
/* Don't trust the codecpar bitrate if we can calculate it ourselves */
if (bits_per_sample > 0 && par->sample_rate > 0 && par->ch_layout.nb_channels 
> 0)
if ((int64_t)par->sample_rate * par->ch_layout.nb_channels < INT64_MAX 
/ bits_per_sample)
-bitrate = bits_per_sample * par->sample_rate * 
par->ch_layout.nb_channels;
+bitrate = bits_per_sample * (int64_t)par->sample_rate * 
par->ch_layout.nb_channels;


LGTM, thanks.

I wonder why we usually cast the second operand and not the first to 64 
bit, since cast has higher precedence than multiplication, it should not 
matter, should it?


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

2024-04-04 Thread Andreas Rheinhardt
Antoine Soulier via ffmpeg-devel:
> In a previous patch, I modified the duration of the packet. But since, we
> now support seeking, I don't know how to obtain the pts of the packet (or
> sample position since start), without an implementation of a `read_seek()`
> function.
> Can you help me on how I can derive the pts of the packet?
> Thanks.
> 

Have you already taken a look at FFStream.cur_dts?

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

2024-04-04 Thread Andreas Rheinhardt
Stefano Sabatini:
> On date Monday 2024-04-01 21:32:05 +, ffmpeg-devel Mailing List wrote:
>> 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
> 
> Paul, Andreas, do you have more comments or is it fine to push as is?
> 

Besides my comment about the actual patch: You applied the lavc commit
with incorrect author information: "Antoine Soulier via ffmpeg-devel
"

- 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 v4 1/1] avfilter/vf_colorspace: use colorspace negotiation API

2024-04-04 Thread Nicolas Gaullier
Fixes a regression due to the fact that the colorspace filter does
not use the new API introduced by 8c7934f73ab6c568acaa.
The scale filter uses it since 45e09a30419cc2a7251e, and the setparams
filter since 3bf80df3ccd32aed23f0.

Example:
ffprobe -f lavfi yuvtestsrc,setparams=color_primaries=bt470bg:color_trc=
bt470bg:colorspace=bt470bg,colorspace=bt709:range=tv,scale,showinfo

Before:
  color_range:unknown color_space:bt470bg ...
After:
  color_range:tv color_space:bt709 ...

Signed-off-by: Nicolas Gaullier 
---
 libavfilter/vf_colorspace.c | 62 +
 1 file changed, 36 insertions(+), 26 deletions(-)

diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
index d181e81ace..7bacd7892a 100644
--- a/libavfilter/vf_colorspace.c
+++ b/libavfilter/vf_colorspace.c
@@ -433,8 +433,7 @@ static int create_filtergraph(AVFilterContext *ctx,
 if (out->color_trc   != s->out_trc) s->out_txchr = NULL;
 if (in->colorspace   != s->in_csp ||
 in->color_range  != s->in_rng)  s->in_lumacoef   = NULL;
-if (out->colorspace  != s->out_csp ||
-out->color_range != s->out_rng) s->out_lumacoef  = NULL;
+if (out->color_range != s->out_rng) s->rgb2yuv   = NULL;
 
 if (!s->out_primaries || !s->in_primaries) {
 s->in_prm = in->color_primaries;
@@ -563,26 +562,8 @@ static int create_filtergraph(AVFilterContext *ctx,
 redo_yuv2rgb = 1;
 }
 
-if (!s->out_lumacoef) {
-s->out_csp = out->colorspace;
+if (!s->rgb2yuv) {
 s->out_rng = out->color_range;
-s->out_lumacoef = av_csp_luma_coeffs_from_avcsp(s->out_csp);
-if (!s->out_lumacoef) {
-if (s->out_csp == AVCOL_SPC_UNSPECIFIED) {
-if (s->user_all == CS_UNSPECIFIED) {
-av_log(ctx, AV_LOG_ERROR,
-   "Please specify output colorspace\n");
-} else {
-av_log(ctx, AV_LOG_ERROR,
-   "Unsupported output color property %d\n", 
s->user_all);
-}
-} else {
-av_log(ctx, AV_LOG_ERROR,
-   "Unsupported output colorspace %d (%s)\n", s->out_csp,
-   av_color_space_name(s->out_csp));
-}
-return AVERROR(EINVAL);
-}
 redo_rgb2yuv = 1;
 }
 
@@ -687,6 +668,26 @@ static av_cold int init(AVFilterContext *ctx)
 {
 ColorSpaceContext *s = ctx->priv;
 
+s->out_csp  = s->user_csp == AVCOL_SPC_UNSPECIFIED ?
+  default_csp[FFMIN(s->user_all, CS_NB)] : s->user_csp;
+s->out_lumacoef = av_csp_luma_coeffs_from_avcsp(s->out_csp);
+if (!s->out_lumacoef) {
+if (s->out_csp == AVCOL_SPC_UNSPECIFIED) {
+if (s->user_all == CS_UNSPECIFIED) {
+av_log(ctx, AV_LOG_ERROR,
+   "Please specify output colorspace\n");
+} else {
+av_log(ctx, AV_LOG_ERROR,
+   "Unsupported output color property %d\n", s->user_all);
+}
+} else {
+av_log(ctx, AV_LOG_ERROR,
+   "Unsupported output colorspace %d (%s)\n", s->out_csp,
+   av_color_space_name(s->out_csp));
+}
+return AVERROR(EINVAL);
+}
+
 ff_colorspacedsp_init(>dsp);
 
 return 0;
@@ -735,6 +736,9 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
 return res;
 }
 
+out->colorspace =  s->out_csp;
+out->color_range = s->user_rng == AVCOL_RANGE_UNSPECIFIED ?
+   in->color_range : s->user_rng;
 out->color_primaries = s->user_prm == AVCOL_PRI_UNSPECIFIED ?
default_prm[FFMIN(s->user_all, CS_NB)] : 
s->user_prm;
 if (s->user_trc == AVCOL_TRC_UNSPECIFIED) {
@@ -746,10 +750,6 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
 } else {
 out->color_trc   = s->user_trc;
 }
-out->colorspace  = s->user_csp == AVCOL_SPC_UNSPECIFIED ?
-   default_csp[FFMIN(s->user_all, CS_NB)] : 
s->user_csp;
-out->color_range = s->user_rng == AVCOL_RANGE_UNSPECIFIED ?
-   in->color_range : s->user_rng;
 if (rgb_sz != s->rgb_sz) {
 const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(out->format);
 int uvw = in->width >> desc->log2_chroma_w;
@@ -841,8 +841,18 @@ static int query_formats(AVFilterContext *ctx)
 };
 int res;
 ColorSpaceContext *s = ctx->priv;
+AVFilterLink *outlink = ctx->outputs[0];
 AVFilterFormats *formats = ff_make_format_list(pix_fmts);
 
+res = ff_formats_ref(ff_make_formats_list_singleton(s->out_csp), 
>incfg.color_spaces);
+if (res < 0)
+return res;
+if (s->user_rng != AVCOL_RANGE_UNSPECIFIED) {
+res = ff_formats_ref(ff_make_formats_list_singleton(s->user_rng), 
>incfg.color_ranges);
+if (res < 0)
+

[FFmpeg-devel] [PATCH v4 0/1] avfilter/vf_colorspace: use colorspace negotiation API

2024-04-04 Thread Nicolas Gaullier
v4:
- remove dynamic color_range pass-through (which requires changing outlink 
dynamically and is forbidden)
- nits style
- commit msg: simplified example (+ removed example for dynamic color_range 
pass-through)

Nicolas Gaullier (1):
  avfilter/vf_colorspace: use colorspace negotiation API

 libavfilter/vf_colorspace.c | 62 +
 1 file changed, 36 insertions(+), 26 deletions(-)

-- 
2.30.2

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

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


Re: [FFmpeg-devel] [PATCH 2/2] avcodec/liblc3enc: don't force unspec channel layouts

2024-04-04 Thread Stefano Sabatini
On date Thursday 2024-04-04 18:59:09 +0200, Andreas Rheinhardt wrote:
> James Almer:
> > We only care about channel count. Layout details will be ignored either way.
> > 
> > Signed-off-by: James Almer 
> > ---
> >  libavcodec/liblc3enc.c | 8 +---
> >  1 file changed, 5 insertions(+), 3 deletions(-)
> > 
> > diff --git a/libavcodec/liblc3enc.c b/libavcodec/liblc3enc.c
> > index 63d1645b10..5f8169a0cf 100644
> > --- a/libavcodec/liblc3enc.c
> > +++ b/libavcodec/liblc3enc.c
> > @@ -61,6 +61,11 @@ static av_cold int liblc3_encode_init(AVCodecContext 
> > *avctx)
> > "Unsupported frame duration %.1f ms.\n", frame_us / 1000.f);
> >  return AVERROR(EINVAL);
> >  }
> > +if (channels < 0 || channels > ENCODER_MAX_CHANNELS) {
> > +av_log(avctx, AV_LOG_ERROR,
> > +   "Unsupported channel count %d. Should be 1 or 2\n", 
> > channels);
> > +return AVERROR(EINVAL);
> > +}
> >  
> >  hr_mode |= srate_hz > 48000;
> >  hr_mode &= srate_hz >= 48000;
> > @@ -195,9 +200,6 @@ const FFCodec ff_liblc3_encoder = {
> >  .p.type = AVMEDIA_TYPE_AUDIO,
> >  .p.id   = AV_CODEC_ID_LC3,
> >  .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY,
> > -.p.ch_layouts = (const AVChannelLayout[])
> > -{ { AV_CHANNEL_ORDER_UNSPEC, 1 },
> > -  { AV_CHANNEL_ORDER_UNSPEC, 2 }, { 0 } },
> >  .p.supported_samplerates = (const int [])
> >  { 96000, 48000, 32000, 24000, 16000, 8000, 0 },
> >  .p.sample_fmts = (const enum AVSampleFormat[])
> 

> I think we should rather change encode.c to mean that an UNSPEC channel
> layout (in AVCodec.ch_layouts) works with every channel layout with the
> same number of channels.

This was my naive interpretation of the code, without checking the
code. This would probably save some boilerplate (OTOH it should also
be fine to apply the hotfix).
___
ffmpeg-devel mailing list
ffmpeg-devel@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 1/4] avcodec/webvttdec: honour bidi marks

2024-04-04 Thread Stefano Sabatini
On date Monday 2024-02-19 22:42:24 +0100, Oneric wrote:
> ---
>  libavcodec/webvttdec.c | 2 +-
>  tests/ref/fate/sub-webvtt2 | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/webvttdec.c b/libavcodec/webvttdec.c
> index 690f00dc47..990d150f16 100644
> --- a/libavcodec/webvttdec.c
> +++ b/libavcodec/webvttdec.c
> @@ -39,7 +39,7 @@ static const struct {
>  {"", "{\\u1}"}, {"", "{\\u0}"},
>  {"{", "\\{"}, {"}", "\\}"}, // escape to avoid ASS markup conflicts
>  {"", ">"}, {"", "<"},
> -{"", ""}, {"", ""}, // FIXME: properly honor bidi marks
> +{"", "\xe2\x80\x8e"}, {"", "\xe2\x80\x8f"},
>  {"", "&"}, {"", "\\h"},
>  };
>  
> diff --git a/tests/ref/fate/sub-webvtt2 b/tests/ref/fate/sub-webvtt2
> index 90f78d904b..2925d892a0 100644
> --- a/tests/ref/fate/sub-webvtt2
> +++ b/tests/ref/fate/sub-webvtt2
> @@ -21,6 +21,6 @@ Dialogue: 0,0:00:12.50,0:00:32.50,Default,,0,0,0,,OK, let’s 
> go.
>  Dialogue: 0,0:00:38.00,0:00:43.00,Default,,0,0,0,,I want to 愛あい love 
> you\NThat's not proper English!
>  Dialogue: 0,0:00:43.00,0:00:46.00,Default,,0,0,0,,{\i1}キツネ{\i0}じゃない 
> キツネじゃない\N乙女おとめは
>  Dialogue: 0,0:00:50.00,0:00:55.00,Default,,0,0,0,,Some time ago in a rather 
> distant place
> -Dialogue: 0,0:00:55.00,0:01:00.00,Default,,0,0,0,,Descending: 
> 123456\NAscending: 123456
> +Dialogue: 0,0:00:55.00,0:01:00.00,Default,,0,0,0,,Descending: 
> ‏123456‎\NAscending: 123456
>  Dialogue: 0,0:01:00.00,0:01:05.00,Default,,0,0,0,,>> Never gonna give you up 
> Never gonna let you down\NNever\hgonna\hrun\haround & desert\hyou
>  Dialogue: 0,0:55:00.00,1:00:00.00,Default,,0,0,0,,Transcrit par Célestes™
> -- 
> 2.39.2

Should be good, 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".


Re: [FFmpeg-devel] [PATCH 2/2] avcodec/liblc3enc: don't force unspec channel layouts

2024-04-04 Thread Andreas Rheinhardt
James Almer:
> We only care about channel count. Layout details will be ignored either way.
> 
> Signed-off-by: James Almer 
> ---
>  libavcodec/liblc3enc.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/libavcodec/liblc3enc.c b/libavcodec/liblc3enc.c
> index 63d1645b10..5f8169a0cf 100644
> --- a/libavcodec/liblc3enc.c
> +++ b/libavcodec/liblc3enc.c
> @@ -61,6 +61,11 @@ static av_cold int liblc3_encode_init(AVCodecContext 
> *avctx)
> "Unsupported frame duration %.1f ms.\n", frame_us / 1000.f);
>  return AVERROR(EINVAL);
>  }
> +if (channels < 0 || channels > ENCODER_MAX_CHANNELS) {
> +av_log(avctx, AV_LOG_ERROR,
> +   "Unsupported channel count %d. Should be 1 or 2\n", channels);
> +return AVERROR(EINVAL);
> +}
>  
>  hr_mode |= srate_hz > 48000;
>  hr_mode &= srate_hz >= 48000;
> @@ -195,9 +200,6 @@ const FFCodec ff_liblc3_encoder = {
>  .p.type = AVMEDIA_TYPE_AUDIO,
>  .p.id   = AV_CODEC_ID_LC3,
>  .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY,
> -.p.ch_layouts = (const AVChannelLayout[])
> -{ { AV_CHANNEL_ORDER_UNSPEC, 1 },
> -  { AV_CHANNEL_ORDER_UNSPEC, 2 }, { 0 } },
>  .p.supported_samplerates = (const int [])
>  { 96000, 48000, 32000, 24000, 16000, 8000, 0 },
>  .p.sample_fmts = (const enum AVSampleFormat[])

I think we should rather change encode.c to mean that an UNSPEC channel
layout (in AVCodec.ch_layouts) works with every channel layout with the
same number of channels.

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

2024-04-04 Thread Antoine Soulier via ffmpeg-devel
In a previous patch, I modified the duration of the packet. But since, we
now support seeking, I don't know how to obtain the pts of the packet (or
sample position since start), without an implementation of a `read_seek()`
function.
Can you help me on how I can derive the pts of the packet?
Thanks.

On Thu, Apr 4, 2024, 9:30 AM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:

> 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
> > + *
> 

Re: [FFmpeg-devel] [PATCH] avformat/httpauth: add SHA-256 Digest Authorization [update]

2024-04-04 Thread Stefano Sabatini
On date Thursday 2024-04-04 02:07:17 +, �� | Eugene wrote:
>  add SHA-256 Digest Authorization for RFC7616 using avutil/hash.h
> - make_digest_auth_sha() : A1hash-> a1_hash and A2hash -> a2_hash
> - combine with lint fix patch
> 
> Signed-off-by: Eugene-bitsensing 
> ---
>  libavformat/httpauth.c | 130 ++---
>  libavformat/httpauth.h |   8 +++
>  2 files changed, 130 insertions(+), 8 deletions(-)
> 
> diff --git a/libavformat/httpauth.c b/libavformat/httpauth.c
> index 9780928357..6069523bca 100644
> --- a/libavformat/httpauth.c
> +++ b/libavformat/httpauth.c
> @@ -25,6 +25,7 @@
>  #include "internal.h"
>  #include "libavutil/random_seed.h"
>  #include "libavutil/md5.h"
> +#include "libavutil/hash.h"
>  #include "urldecode.h"
>  

>  static void handle_basic_params(HTTPAuthState *state, const char *key,
> @@ -143,7 +144,7 @@ static char *make_digest_auth(HTTPAuthState *state, const 
> char *username,
>  char cnonce[17];
>  char nc[9];
>  int i;
> -char A1hash[33], A2hash[33], response[33];
> +char a1_hash[33], a2_hash[33], response[33];
>  struct AVMD5 *md5ctx;
>  uint8_t hash[16];
>  char *authstr;
> @@ -163,14 +164,14 @@ static char *make_digest_auth(HTTPAuthState *state, 
> const char *username,
>  av_md5_init(md5ctx);
>  update_md5_strings(md5ctx, username, ":", state->realm, ":", password, 
> NULL);
>  av_md5_final(md5ctx, hash);
> -ff_data_to_hex(A1hash, hash, 16, 1);
> +ff_data_to_hex(a1_hash, hash, 16, 1);
>  
>  if (!strcmp(digest->algorithm, "") || !strcmp(digest->algorithm, "MD5")) 
> {
>  } else if (!strcmp(digest->algorithm, "MD5-sess")) {
>  av_md5_init(md5ctx);
> -update_md5_strings(md5ctx, A1hash, ":", digest->nonce, ":", cnonce, 
> NULL);
> +update_md5_strings(md5ctx, a1_hash, ":", digest->nonce, ":", cnonce, 
> NULL);
>  av_md5_final(md5ctx, hash);
> -ff_data_to_hex(A1hash, hash, 16, 1);
> +ff_data_to_hex(a1_hash, hash, 16, 1);
>  } else {
>  /* Unsupported algorithm */
>  av_free(md5ctx);
> @@ -180,14 +181,14 @@ static char *make_digest_auth(HTTPAuthState *state, 
> const char *username,
>  av_md5_init(md5ctx);
>  update_md5_strings(md5ctx, method, ":", uri, NULL);
>  av_md5_final(md5ctx, hash);
> -ff_data_to_hex(A2hash, hash, 16, 1);
> +ff_data_to_hex(a2_hash, hash, 16, 1);
>  
>  av_md5_init(md5ctx);
> -update_md5_strings(md5ctx, A1hash, ":", digest->nonce, NULL);
> +update_md5_strings(md5ctx, a1_hash, ":", digest->nonce, NULL);
>  if (!strcmp(digest->qop, "auth") || !strcmp(digest->qop, "auth-int")) {
>  update_md5_strings(md5ctx, ":", nc, ":", cnonce, ":", digest->qop, 
> NULL);
>  }
> -update_md5_strings(md5ctx, ":", A2hash, NULL);
> +update_md5_strings(md5ctx, ":", a2_hash, NULL);
>  av_md5_final(md5ctx, hash);
>  ff_data_to_hex(response, hash, 16, 1);

this is fine but it would be better sent as a separate patch (to avoid
mixing functional and cosmetical changes)

>  
> @@ -236,6 +237,114 @@ static char *make_digest_auth(HTTPAuthState *state, 
> const char *username,
>  return authstr;
>  }
>  

> +/**
> + * Generate a digest reply SHA-256, according to RFC 7616.
> + * TODO : support other RFC 7616 Algorithm 
> + */
> +static char *make_digest_auth_sha(HTTPAuthState *state, const char *username,
> +  const char *password, const char *uri,
> +  const char *method, const char *algorithm)
> +{

BTW I see this function contains much duplicated code from
make_digest_auth().

Is it possible to make make_digest_auth use this new function with the
MD5 algorithm? This would avoid much code duplication.

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

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


Re: [FFmpeg-devel] [PATCH 2/2] avcodec/liblc3enc: don't force unspec channel layouts

2024-04-04 Thread James Almer

On 4/4/2024 1:45 PM, Stefano Sabatini wrote:

On date Thursday 2024-04-04 13:29:36 -0300, James Almer wrote:

We only care about channel count. Layout details will be ignored either way.

Signed-off-by: James Almer 
---
  libavcodec/liblc3enc.c | 8 +---
  1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/libavcodec/liblc3enc.c b/libavcodec/liblc3enc.c
index 63d1645b10..5f8169a0cf 100644
--- a/libavcodec/liblc3enc.c
+++ b/libavcodec/liblc3enc.c
@@ -61,6 +61,11 @@ static av_cold int liblc3_encode_init(AVCodecContext *avctx)
 "Unsupported frame duration %.1f ms.\n", frame_us / 1000.f);
  return AVERROR(EINVAL);
  }
+if (channels < 0 || channels > ENCODER_MAX_CHANNELS) {
+av_log(avctx, AV_LOG_ERROR,
+   "Unsupported channel count %d. Should be 1 or 2\n", channels);
+return AVERROR(EINVAL);
+}
  
  hr_mode |= srate_hz > 48000;

  hr_mode &= srate_hz >= 48000;
@@ -195,9 +200,6 @@ const FFCodec ff_liblc3_encoder = {
  .p.type = AVMEDIA_TYPE_AUDIO,
  .p.id   = AV_CODEC_ID_LC3,
  .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY,



-.p.ch_layouts = (const AVChannelLayout[])
-{ { AV_CHANNEL_ORDER_UNSPEC, 1 },
-  { AV_CHANNEL_ORDER_UNSPEC, 2 }, { 0 } },


shouldn't this be equivalent?

Should be good anyway.


No, because if you pass it a mono or stereo layout, the generic encode 
code will reject it, whereas after this change it will work because the 
encoder will only cares about channel count, not overall layout.

___
ffmpeg-devel mailing list
ffmpeg-devel@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/wavarc: fix signed integer overflow in block type 6/19

2024-04-04 Thread Michael Niedermayer
On Thu, Apr 04, 2024 at 12:51:30AM +0200, Michael Niedermayer wrote:
> Fixes: signed integer overflow: -2088796289 + -91276551 cannot be represented 
> in type 'int'
> Fixes: 
> 67772/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WAVARC_fuzzer-6533568953122816
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/wavarc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

will apply and backport these

[...]
-- 
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/2] avcodec/liblc3enc: don't force unspec channel layouts

2024-04-04 Thread Stefano Sabatini
On date Thursday 2024-04-04 13:29:36 -0300, James Almer wrote:
> We only care about channel count. Layout details will be ignored either way.
> 
> Signed-off-by: James Almer 
> ---
>  libavcodec/liblc3enc.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/libavcodec/liblc3enc.c b/libavcodec/liblc3enc.c
> index 63d1645b10..5f8169a0cf 100644
> --- a/libavcodec/liblc3enc.c
> +++ b/libavcodec/liblc3enc.c
> @@ -61,6 +61,11 @@ static av_cold int liblc3_encode_init(AVCodecContext 
> *avctx)
> "Unsupported frame duration %.1f ms.\n", frame_us / 1000.f);
>  return AVERROR(EINVAL);
>  }
> +if (channels < 0 || channels > ENCODER_MAX_CHANNELS) {
> +av_log(avctx, AV_LOG_ERROR,
> +   "Unsupported channel count %d. Should be 1 or 2\n", channels);
> +return AVERROR(EINVAL);
> +}
>  
>  hr_mode |= srate_hz > 48000;
>  hr_mode &= srate_hz >= 48000;
> @@ -195,9 +200,6 @@ const FFCodec ff_liblc3_encoder = {
>  .p.type = AVMEDIA_TYPE_AUDIO,
>  .p.id   = AV_CODEC_ID_LC3,
>  .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY,

> -.p.ch_layouts = (const AVChannelLayout[])
> -{ { AV_CHANNEL_ORDER_UNSPEC, 1 },
> -  { AV_CHANNEL_ORDER_UNSPEC, 2 }, { 0 } },

shouldn't this be equivalent?

Should be good anyway.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


Re: [FFmpeg-devel] [PATCH 1/2] avcodec/liblc3dec: sanitize channel count in avctx

2024-04-04 Thread Stefano Sabatini
On date Thursday 2024-04-04 13:29:35 -0300, James Almer wrote:
> Should prevent out of array accesses.
> 
> Signed-off-by: James Almer 
> ---
>  libavcodec/liblc3dec.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/libavcodec/liblc3dec.c b/libavcodec/liblc3dec.c
> index c0a31bc91f..52364859d4 100644
> --- a/libavcodec/liblc3dec.c
> +++ b/libavcodec/liblc3dec.c
> @@ -46,6 +46,8 @@ static av_cold int liblc3_decode_init(AVCodecContext *avctx)
>  
>  if (avctx->extradata_size < 10)
>  return AVERROR_INVALIDDATA;

> +if (channels < 0 || channels > DECODER_MAX_CHANNELS)
> +return AVERROR_INVALIDDATA;

add a log:
av_log(avctx, AV_LOG_ERROR,
   "Invalid number of channels %d, max %d decoder channels are accepted\n",
   channels, DECODER_MAX_CHANNES);

>  liblc3->frame_us = AV_RL16(avctx->extradata + 0) * 10;
>  liblc3->srate_hz = avctx->sample_rate;

LGTM otherwise, 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".


Re: [FFmpeg-devel] 7.0 release

2024-04-04 Thread Michael Niedermayer
On Thu, Apr 04, 2024 at 09:51:50AM -0300, James Almer wrote:
> On 4/4/2024 9:29 AM, Michael Niedermayer wrote:
> > On Thu, Apr 04, 2024 at 08:50:12AM -0300, James Almer wrote:
> > > On 4/4/2024 8:47 AM, Michael Niedermayer wrote:
> > > > On Thu, Apr 04, 2024 at 09:12:04AM +0200, Anton Khirnov wrote:
> > > > > Quoting Michael Niedermayer (2024-04-04 00:57:39)
> > > > > > Hi
> > > > > > 
> > > > > > I will try to make the 7.0 release from the release branch in the 
> > > > > > next 48h
> > > > > > (with some luck but easy possible it will get delayed)
> > > > > > i will not try to fix any issues marked as blocking 7.0 on trac, 
> > > > > > IIRC
> > > > > 
> > > > > IMO people are overly eager to mark everything as 'blocking'.
> > > > 
> > > > No, thats not true, very few bugs are marked as blocking, we have 2837
> > > > open/new bugs and 1 marked as blocking. And we had maybe 2-3 marked as
> > > > blocking maximum at any time over the last weeks
> > > 
> > > The bug marked as blocking has no available sample, and the commit you say
> > 
> > https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket4161/
> > 
> > I dont understand why google hasnt indexed (or finding that) though
> > 
> > My testcase:
> > -i VR_MOVIE_GuyMartinsSpitfireBcast169\ qsf\ lappyAspectNoChnge_extract.mpg 
> > -bitexact -vcodec libx264 -an -vsync cfr file-16:9.ts
> > 
> > 
> > > generated the regression just moved a failure path around, so how can it
> > > change the reported aspect ratio of the input?
> > 
> > I have not investigated it, I just see that there are various circular 
> > features
> > in the video that are not circular anymore
> 
> I can't find a difference between 6.1 and master:
[...]
> Am i doing something wrong?

This bug is cursed, be carefull

git checkout  924a6f3cc7788e2d258348b1547a49805091ea2d^
make -j32
./ffmpeg -i ~/tickets/4161/VR_MOVIE_GuyMartinsSpitfireBcast169\ qsf\ 
lappyAspectNoChnge_extract.mpg -bitexact -vcodec libx264 -an -vsync cfr 
file-169-924a6f3cc7788e2d258348b1547a49805091ea2d^.ts

git checkout  924a6f3cc7788e2d258348b1547a49805091ea2d
make -j32
./ffmpeg -i ~/tickets/4161/VR_MOVIE_GuyMartinsSpitfireBcast169\ qsf\ 
lappyAspectNoChnge_extract.mpg -bitexact -vcodec libx264 -an -vsync cfr 
file-169-924a6f3cc7788e2d258348b1547a49805091ea2d.ts

ls -alF file-169-924a6f3cc7788e2d258348b1547a49805091ea2d.ts 
file-169-924a6f3cc7788e2d258348b1547a49805091ea2d^.ts
-rw-r- 1 michael michael 1255652 Apr  4 18:32 
'file-169-924a6f3cc7788e2d258348b1547a49805091ea2d^.ts'
-rw-r- 1 michael michael 1255652 Apr  4 18:33  
file-169-924a6f3cc7788e2d258348b1547a49805091ea2d.ts

md5sum  file-169-924a6f3cc7788e2d258348b1547a49805091ea2d.ts 
file-169-924a6f3cc7788e2d258348b1547a49805091ea2d^.ts
9ec90b2497787f7d5d76aa1d34cde7eb  
file-169-924a6f3cc7788e2d258348b1547a49805091ea2d.ts
4361f0f20181c39a3a9b3a7f35619520  
file-169-924a6f3cc7788e2d258348b1547a49805091ea2d^.ts

now if i play these with ffplay

./ffplay file-169-924a6f3cc7788e2d258348b1547a49805091ea2d.ts
./ffplay file-169-924a6f3cc7788e2d258348b1547a49805091ea2d^.ts

and one of these simply has the wrong aspect ratio
i never looked at anything else but i now also see in the ffplay output

Stream #0:0[0x100]: Video: h264 (High) ([27][0][0][0] / 0x001B), 
yuv420p(progressive), 720x576 [SAR 16:15 DAR 4:3], 25 fps, 25 tbr, 90k tbn
vs.
Stream #0:0[0x100]: Video: h264 (High) ([27][0][0][0] / 0x001B), 
yuv420p(progressive), 720x576 [SAR 64:45 DAR 16:9], 25 fps, 25 tbr, 90k tbn

thx

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

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data


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

2024-04-04 Thread Andreas Rheinhardt
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;

[FFmpeg-devel] [PATCH 2/2] avcodec/liblc3enc: don't force unspec channel layouts

2024-04-04 Thread James Almer
We only care about channel count. Layout details will be ignored either way.

Signed-off-by: James Almer 
---
 libavcodec/liblc3enc.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/libavcodec/liblc3enc.c b/libavcodec/liblc3enc.c
index 63d1645b10..5f8169a0cf 100644
--- a/libavcodec/liblc3enc.c
+++ b/libavcodec/liblc3enc.c
@@ -61,6 +61,11 @@ static av_cold int liblc3_encode_init(AVCodecContext *avctx)
"Unsupported frame duration %.1f ms.\n", frame_us / 1000.f);
 return AVERROR(EINVAL);
 }
+if (channels < 0 || channels > ENCODER_MAX_CHANNELS) {
+av_log(avctx, AV_LOG_ERROR,
+   "Unsupported channel count %d. Should be 1 or 2\n", channels);
+return AVERROR(EINVAL);
+}
 
 hr_mode |= srate_hz > 48000;
 hr_mode &= srate_hz >= 48000;
@@ -195,9 +200,6 @@ const FFCodec ff_liblc3_encoder = {
 .p.type = AVMEDIA_TYPE_AUDIO,
 .p.id   = AV_CODEC_ID_LC3,
 .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY,
-.p.ch_layouts = (const AVChannelLayout[])
-{ { AV_CHANNEL_ORDER_UNSPEC, 1 },
-  { AV_CHANNEL_ORDER_UNSPEC, 2 }, { 0 } },
 .p.supported_samplerates = (const int [])
 { 96000, 48000, 32000, 24000, 16000, 8000, 0 },
 .p.sample_fmts = (const enum AVSampleFormat[])
-- 
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/2] avcodec/liblc3dec: sanitize channel count in avctx

2024-04-04 Thread James Almer
Should prevent out of array accesses.

Signed-off-by: James Almer 
---
 libavcodec/liblc3dec.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavcodec/liblc3dec.c b/libavcodec/liblc3dec.c
index c0a31bc91f..52364859d4 100644
--- a/libavcodec/liblc3dec.c
+++ b/libavcodec/liblc3dec.c
@@ -46,6 +46,8 @@ static av_cold int liblc3_decode_init(AVCodecContext *avctx)
 
 if (avctx->extradata_size < 10)
 return AVERROR_INVALIDDATA;
+if (channels < 0 || channels > DECODER_MAX_CHANNELS)
+return AVERROR_INVALIDDATA;
 
 liblc3->frame_us = AV_RL16(avctx->extradata + 0) * 10;
 liblc3->srate_hz = avctx->sample_rate;
-- 
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".


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

2024-04-04 Thread Andreas Rheinhardt
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 

Re: [FFmpeg-devel] [PATCH 2/2] avformat/lc3: Add file format for LC3/LC3plus transport

2024-04-04 Thread James Almer

On 4/1/2024 6:32 PM, Antoine Soulier via ffmpeg-devel wrote:

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))
+ 

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

2024-04-04 Thread James Almer

On 4/1/2024 6:32 PM, Antoine Soulier via ffmpeg-devel wrote:

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 

Re: [FFmpeg-devel] [PATCH] Changelog: fix typos for 7.0 section

2024-04-04 Thread Marth64
Works for me. Looks great now. Thank you!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


Re: [FFmpeg-devel] [PATCH] Changelog: fix typos for 7.0 section

2024-04-04 Thread Stefano Sabatini
On date Thursday 2024-04-04 10:08:21 -0500, Marth64 wrote:
> If it's not too late, I thought these fixes would make
> the section look nicer for this big release.
> 
> ---
>  Changelog | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/Changelog b/Changelog
> index a65c8ceee5..7ed638514b 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -40,17 +40,17 @@ version 7.0:
>  - ffmpeg CLI loopback decoders
>  - Support PacketTypeMetadata of PacketType in enhanced flv format
>  - ffplay with hwaccel decoding support (depends on vulkan renderer via 
> libplacebo)

> -- dnn filter libtorch backend
> +- dnn filter now has libtorch backend

nit+: I believe this is not needed, if no verb is specified the item
implicitly represents what was added in nominal form, no need to use a
verb or a time adverb in this case.

>  - Android content URIs protocol
>  - AOMedia Film Grain Synthesis 1 (AFGS1)
> -- RISC-V optimizations for AAC, FLAC, JPEG-2000,LPC, RV4.0, SVQ, VC1, VP8 
> and more
> +- RISC-V optimizations for AAC, FLAC, JPEG-2000, LPC, RV4.0, SVQ, VC1, VP8, 
> and more
>  - Loongarch optimizations for HEVC decoding
>  - Important AArch64 optimizations for HEVC
>  - IAMF support inside MP4/ISOBMFF
>  - Support for HEIF/AVIF still images and tiled still images
>  - Dolby Vision profile 10 support in AV1
>  - Support for Ambient Viewing Environment metadata in MP4/ISOBMFF
> -- HDR10 metadata passthrough when encoding with libx264, libx265 and 
> libsvtav1
> +- HDR10 metadata passthrough when encoding with libx264, libx265, and 
> libsvtav1

LGTM otherwise.
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Changelog: fix typos for 7.0 section

2024-04-04 Thread James Almer

On 4/4/2024 12:08 PM, Marth64 wrote:

If it's not too late, I thought these fixes would make
the section look nicer for this big release.

---
  Changelog | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Changelog b/Changelog
index a65c8ceee5..7ed638514b 100644
--- a/Changelog
+++ b/Changelog
@@ -40,17 +40,17 @@ version 7.0:
  - ffmpeg CLI loopback decoders
  - Support PacketTypeMetadata of PacketType in enhanced flv format
  - ffplay with hwaccel decoding support (depends on vulkan renderer via 
libplacebo)
-- dnn filter libtorch backend
+- dnn filter now has libtorch backend


This one is unnecessary


  - Android content URIs protocol
  - AOMedia Film Grain Synthesis 1 (AFGS1)
-- RISC-V optimizations for AAC, FLAC, JPEG-2000,LPC, RV4.0, SVQ, VC1, VP8 and 
more
+- RISC-V optimizations for AAC, FLAC, JPEG-2000, LPC, RV4.0, SVQ, VC1, VP8, 
and more
  - Loongarch optimizations for HEVC decoding
  - Important AArch64 optimizations for HEVC
  - IAMF support inside MP4/ISOBMFF
  - Support for HEIF/AVIF still images and tiled still images
  - Dolby Vision profile 10 support in AV1
  - Support for Ambient Viewing Environment metadata in MP4/ISOBMFF
-- HDR10 metadata passthrough when encoding with libx264, libx265 and libsvtav1
+- HDR10 metadata passthrough when encoding with libx264, libx265, and libsvtav1


But these two are ok. Will apply them. 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".


Re: [FFmpeg-devel] [PATCH 2/2] avformat/lc3: Add file format for LC3/LC3plus transport

2024-04-04 Thread Stefano Sabatini
On date Monday 2024-04-01 21:32:05 +, ffmpeg-devel Mailing List wrote:
> 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

Paul, Andreas, do you have more comments or is it fine to push as is?

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


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

2024-04-04 Thread Stefano Sabatini
On date Monday 2024-04-01 21:32:04 +, ffmpeg-devel Mailing List wrote:
> 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

will apply this soon (after a rebase)

Note: I had to add the libavutil/mem.h includes to fix local
compilation.

Also, liblc3 meson will install the .pc file in
lib/x86_64-linux-gnu/pkgconfig/ which is a bit unexpected, as the
PKG_CONFIG_PATH is usually lib/pkgconfig.

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] Changelog: fix typos for 7.0 section

2024-04-04 Thread Marth64
If it's not too late, I thought these fixes would make
the section look nicer for this big release.

---
 Changelog | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Changelog b/Changelog
index a65c8ceee5..7ed638514b 100644
--- a/Changelog
+++ b/Changelog
@@ -40,17 +40,17 @@ version 7.0:
 - ffmpeg CLI loopback decoders
 - Support PacketTypeMetadata of PacketType in enhanced flv format
 - ffplay with hwaccel decoding support (depends on vulkan renderer via 
libplacebo)
-- dnn filter libtorch backend
+- dnn filter now has libtorch backend
 - Android content URIs protocol
 - AOMedia Film Grain Synthesis 1 (AFGS1)
-- RISC-V optimizations for AAC, FLAC, JPEG-2000,LPC, RV4.0, SVQ, VC1, VP8 and 
more
+- RISC-V optimizations for AAC, FLAC, JPEG-2000, LPC, RV4.0, SVQ, VC1, VP8, 
and more
 - Loongarch optimizations for HEVC decoding
 - Important AArch64 optimizations for HEVC
 - IAMF support inside MP4/ISOBMFF
 - Support for HEIF/AVIF still images and tiled still images
 - Dolby Vision profile 10 support in AV1
 - Support for Ambient Viewing Environment metadata in MP4/ISOBMFF
-- HDR10 metadata passthrough when encoding with libx264, libx265 and libsvtav1
+- HDR10 metadata passthrough when encoding with libx264, libx265, and libsvtav1
 
 
 version 6.1:
-- 
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] [GASPP PATCH] Implicitly start out in the text section for armasm

2024-04-04 Thread Henrik Gramner via ffmpeg-devel
On Wed, Apr 3, 2024 at 3:47 PM Martin Storsjö  wrote:
>
> This fixes assembling files starting with bare symbol declarations,
> without explicitly switching to .text first.

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 v3 2/2] avfilter/vf_colorspace: Use colorspace negotiation API

2024-04-04 Thread Nicolas Gaullier
>De : ffmpeg-devel  De la part de Niklas Haas
>Envoyé : jeudi 4 avril 2024 14:44
>
>> >> @@ -735,6 +736,9 @@ static int filter_frame(AVFilterLink *link, AVFrame 
>> >> *in)
>> >>  return res;
>> >>  }
>> >>  
>> >> +out->colorspace = s->out_csp;
>> >> +outlink->color_range = s->user_rng != AVCOL_RANGE_UNSPECIFIED ? 
>> >> s->user_rng : in->color_range;
>> >> +out->color_range = outlink->color_range;
>> >
>> >Changing outlink dynamically like this seems not correct to me (what if the 
>> >next filter in the chain only supports one color range?). Changing the 
>> >range on the fly would at the minimum require reconfiguring the filter 
>> >graph, and >>possibly insertion of more auto-scale filters.
>> This is the kind of questioning I had when working on this issue. This seems 
>> very annoying and overly complex for a very uncommon scenario; is it even 
>> possible within the filter to ask for a reconfiguration of the filter graph ?
>
>No, reconfiguring the filter graph is (currently) the API user's 
>responsibility. (See fftools/ffmpeg_filter.c for an example)
>
>vf_buffersrc even warns you if you try and change colorspace properties 
>mid-stream, and for good reason - IMO there is no general expectation that 
>filters should be able to handle dynamically changing colorspace properties. 
>(This is >a feature, not a bug)
>
>There *are* some filters that handle dynamically changing input properties 
>(e.g. scale, zscale, libplacebo), but these are the exception rather than the 
>norm, and it's only because they're already written in a way that can 
>trivially >handle dynamic conversions.
>
>If it's difficult to do from within vf_colorspace, there's no need to do so. 
>Feel free to assume that frame->colorspace == inlink->colorspace == constant. 
>(Ditto color_range)

Thank you, this is pretty clear. I agree dynamic change of color range sounds 
weird and I am pleased it can be assumed constant.
In my patch, it means the problematic "outlink->color_range = xxx" you pointed 
at can be dropped. Nice.

>> 
>> >The logic that is used in the other YUV negotiation aware filters is to 
>> >just set `out->colorspace = outlink->colorspace` and `out->color_range = 
>> >outlink->color_range`, since the link properties are authoritative.
>> This is the kind of easy logic I tried at the beginning. Some water has 
>> flowed under the bridge, notably b89ee26539, but I just tried at the moment 
>> (with current code) an easy patch with just these two lines, and it still 
>> does not >work as "I" expected.
>> More specifically:
>> When running: ./ffprobe -f lavfi -i 
>> yuvtestsrc,setparams=color_primaries=bt470bg:color_trc=smpte170m:color
>> space=bt470bg,colorspace=bt709:range=tv,scale,showinfo
>> At the entry of filter_frame(), the outlink values are incorrect:
>> colorspace = AVCOL_SPC_BT470BG
>> And color_range = AVCOL_RANGE_UNSPECIFIED So, this is why I introduced 
>> the negotiation for the colorspace to early set and persist this outlink 
>> property.
>> But for the range, I am bit confused with the documentation, it is not clear 
>> to me, but possibly it is expected to pass through? so it cannot be 
>> negotiated, so I am sticked if the outlink range cannot be changed 
>> dynamically...
>
>Note: passing through the range untouched *is* the default behavior (via 
>ff_default_query_formats). So I think the correct logic can be condensed into 
>just:
>
>if (out_rng != UNSPEC) {
>ret = set_common_color_ranges(make_singleton(out_rng));
>if (ret < 0)
>return ret;
>}
>
>That way, if the user passes unspec, it's guaranteed that the input range == 
>output_range (but with no preference for any specific range); but if the user 
>passes a specific range, both the input and output of the filter are forced to 
>be >this range.

Well, this is where I still not feel confident. Dynamic input range is not 
expected but somewhat still supported.
First thing: in my understanding, the colorspace filter is aimed at converting 
from any input range to the desired output range (if specified), and I think my 
patch is ok with the current 
"ff_formats_ref(ff_make_formats_list_singleton(s->user_rng), 
>incfg.color_ranges)". I don't think they are issues against it, so I 
will keep it that way unless you object.
Second thing: I understand the default behaviour is to pass through (I 
mean/guess dynamically) the range, but it is not what I experience. To test 
this, my patch serie includes a first patch to make setparams support timeline 
and here it is when running a "dynamic input range input":
ffmpeg -f lavfi -i yuvtestsrc -vf 
"setparams=color_primaries=bt470bg:color_trc=smpte170m:colorspace=bt470bg:range=unknown,
setparams=range=pc:enable='between(n,1,2)',
setparams=range=tv:enable='between(n,2,3)',
colorspace=bt709,scale,showinfo" -f null -frames 3 - 2>&1|awk "/color_/ {print 
\$4 \" \" \$5}"

Current master (solely patched for timeline support in setparams):
color_range:tv 

Re: [FFmpeg-devel] [PATCH] Update the Changelog for 7.0

2024-04-04 Thread James Almer

On 4/4/2024 9:59 AM, Jean-Baptiste Kempf wrote:

On Thu, 4 Apr 2024, at 07:30, Vittorio Giovara wrote:

On Thu, Apr 4, 2024 at 1:28 AM Jean-Baptiste Kempf  wrote:


On Wed, 3 Apr 2024, at 23:18, Jean-Baptiste Kempf wrote:

As attached.


Updated version attached (v2).



lgtm with AV1 capitalized


Fixed & Attached.


Will apply.
___
ffmpeg-devel mailing list
ffmpeg-devel@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 5/5] avcodec/ac3: Implement sum_square_butterfly_float for aarch64 NEON

2024-04-04 Thread Martin Storsjö

On Tue, 2 Apr 2024, Geoff Hill wrote:


Signed-off-by: Geoff Hill 
---
libavcodec/aarch64/ac3dsp_init_aarch64.c |  5 
libavcodec/aarch64/ac3dsp_neon.S | 35 
tests/checkasm/ac3dsp.c  | 26 ++
3 files changed, 66 insertions(+)

diff --git a/libavcodec/aarch64/ac3dsp_neon.S b/libavcodec/aarch64/ac3dsp_neon.S
index fa8fcf2e47..4a78ec0b2a 100644
--- a/libavcodec/aarch64/ac3dsp_neon.S
+++ b/libavcodec/aarch64/ac3dsp_neon.S
@@ -88,3 +88,38 @@ function ff_ac3_sum_square_butterfly_int32_neon, export=1
st1 {v0.1d-v3.1d}, [x0]
1:  ret
endfunc
+
+function ff_ac3_sum_square_butterfly_float_neon, export=1
+cbz w3, 1f
+moviv0.4s, #0
+moviv1.4s, #0
+moviv2.4s, #0
+moviv3.4s, #0
+0:  ld1 {v30.4s}, [x1], #16
+ld1 {v31.4s}, [x2], #16
+faddv16.4s, v30.4s, v31.4s
+fsubv17.4s, v30.4s, v31.4s
+fmulv30.4s, v30.4s, v30.4s
+faddv0.4s, v0.4s, v30.4s


The arm version here used vmla instead of separate vmul+vadd - is there 
any reason why we can't use fmla here?


// Martin

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

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


Re: [FFmpeg-devel] [PATCH] Update the Changelog for 7.0

2024-04-04 Thread Jean-Baptiste Kempf
On Thu, 4 Apr 2024, at 07:30, Vittorio Giovara wrote:
> On Thu, Apr 4, 2024 at 1:28 AM Jean-Baptiste Kempf  wrote:
>
>> On Wed, 3 Apr 2024, at 23:18, Jean-Baptiste Kempf wrote:
>> > As attached.
>>
>> Updated version attached (v2).
>>
>
> lgtm with AV1 capitalized

Fixed & Attached.

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
https://jbkempf.com/From ed92996f6e33c6bffe61df0898655bfe4623dbef Mon Sep 17 00:00:00 2001
From: Jean-Baptiste Kempf 
Date: Wed, 3 Apr 2024 23:12:54 +0200
Subject: [PATCH] Update the Changelog for 7.0

---
 Changelog | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/Changelog b/Changelog
index fcc9f7cfba..a66c3048f0 100644
--- a/Changelog
+++ b/Changelog
@@ -21,7 +21,7 @@ version 7.0:
 - qrencode filter and qrencodesrc source
 - quirc filter
 - lavu/eval: introduce randomi() function in expressions
-- VVC decoder
+- VVC decoder (experimental)
 - fsync filter
 - Raw Captions with Time (RCWT) closed caption muxer
 - ffmpeg CLI -bsf option may now be used for input as well as output
@@ -42,6 +42,15 @@ version 7.0:
 - ffplay with hwaccel decoding support (depends on vulkan renderer via libplacebo)
 - dnn filter libtorch backend
 - Android content URIs protocol
+- AOMedia Film Grain Synthesis 1 (AFGS1)
+- RISC-V optimizations for AAC, FLAC, JPEG-2000,LPC, RV4.0, SVQ, VC1, VP8 and more
+- Loongarch optimizations for HEVC decoding
+- Important AArch64 optimizations for HEVC
+- IAMF support inside MP4/ISOBMFF
+- Support for HEIF/AVIF still images and tiled still images
+- Dolby Vision profile 10 support in AV1
+- Support for Ambient Viewing Environment metadata in MP4/ISOBMFF
+- HDR10 metadata passthrough when encoding with libx264, libx265 and SVT-AV1
 
 
 version 6.1:
-- 
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 v3 4/5] avcodec/ac3: Implement sum_square_butterfly_int32 for aarch64 NEON

2024-04-04 Thread Martin Storsjö

On Tue, 2 Apr 2024, Geoff Hill wrote:


Signed-off-by: Geoff Hill 
---
libavcodec/aarch64/ac3dsp_init_aarch64.c |  5 +
libavcodec/aarch64/ac3dsp_neon.S | 24 +
tests/checkasm/ac3dsp.c  | 27 
3 files changed, 56 insertions(+)

diff --git a/libavcodec/aarch64/ac3dsp_init_aarch64.c 
b/libavcodec/aarch64/ac3dsp_init_aarch64.c
index 1bdc215b51..e95436c651 100644
--- a/libavcodec/aarch64/ac3dsp_init_aarch64.c
+++ b/libavcodec/aarch64/ac3dsp_init_aarch64.c
@@ -28,6 +28,10 @@
void ff_ac3_exponent_min_neon(uint8_t *exp, int num_reuse_blocks, int nb_coefs);
void ff_ac3_extract_exponents_neon(uint8_t *exp, int32_t *coef, int nb_coefs);
void ff_float_to_fixed24_neon(int32_t *dst, const float *src, size_t len);
+void ff_ac3_sum_square_butterfly_int32_neon(int64_t sum[4],
+const int32_t *coef0,
+const int32_t *coef1,
+int len);

av_cold void ff_ac3dsp_init_aarch64(AC3DSPContext *c)
{
@@ -37,4 +41,5 @@ av_cold void ff_ac3dsp_init_aarch64(AC3DSPContext *c)
c->ac3_exponent_min = ff_ac3_exponent_min_neon;
c->extract_exponents = ff_ac3_extract_exponents_neon;
c->float_to_fixed24 = ff_float_to_fixed24_neon;
+c->sum_square_butterfly_int32 = ff_ac3_sum_square_butterfly_int32_neon;
}
diff --git a/libavcodec/aarch64/ac3dsp_neon.S b/libavcodec/aarch64/ac3dsp_neon.S
index b26f71a3f6..fa8fcf2e47 100644
--- a/libavcodec/aarch64/ac3dsp_neon.S
+++ b/libavcodec/aarch64/ac3dsp_neon.S
@@ -64,3 +64,27 @@ function ff_float_to_fixed24_neon, export=1
b.ne0b
ret
endfunc
+
+function ff_ac3_sum_square_butterfly_int32_neon, export=1
+cbz w3, 1f


The arm version of this patch doesn't have any corresponding check for 
whether this parameter is zero, and the checkasm test doesn't test that 
behaviour either. Is that never feasiable (and we could leave it out here) 
or should we test that and fix it in other assembly versions? In the 
latter case, it's of course ok to defer that to a separate later patch, 
not holding up this one.


// Martin


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

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


Re: [FFmpeg-devel] [PATCH v3 0/5] avcodec/ac3: Add aarch64 NEON DSP

2024-04-04 Thread Martin Storsjö

On Tue, 2 Apr 2024, Geoff Hill wrote:


Here's v3 to push the AC-3 ARMv8 NEON experiment a step further.

This version implements 5 of the AC-3 encoder DSP functions,
and adds checkasm tests where missing.

I've tested that the checkasm tests pass on aarch64 and x86.


Thanks, I've tested that checkasm also passes on 32 bit arm (where we also 
do have an ac3dsp implementation).


Overall the patches look mostly fine.

Are these implementations based on the existing 32 bit arm ones? The code 
is quite similar (although there's not very many different ways to 
implement things, so this could be a coincidence)? If based on the 
existing code, it would be good to retain the copyright statement from 
that file.


These functions have a different indentation than the rest of 
essentially all our aarch64 assembly (the code you're adding is aligned in 
two different ways) - please check other files (e.g. vp8dsp_neon.S) for 
example. The instructions should be aligned to 8 leading spaces, and 
operands to 24 leading characters.


Other than those generic points, I have two comments on the patches 
themselves.


// Martin

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

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


Re: [FFmpeg-devel] 7.0 release

2024-04-04 Thread James Almer

On 4/4/2024 9:29 AM, Michael Niedermayer wrote:

On Thu, Apr 04, 2024 at 08:50:12AM -0300, James Almer wrote:

On 4/4/2024 8:47 AM, Michael Niedermayer wrote:

On Thu, Apr 04, 2024 at 09:12:04AM +0200, Anton Khirnov wrote:

Quoting Michael Niedermayer (2024-04-04 00:57:39)

Hi

I will try to make the 7.0 release from the release branch in the next 48h
(with some luck but easy possible it will get delayed)
i will not try to fix any issues marked as blocking 7.0 on trac, IIRC


IMO people are overly eager to mark everything as 'blocking'.


No, thats not true, very few bugs are marked as blocking, we have 2837
open/new bugs and 1 marked as blocking. And we had maybe 2-3 marked as
blocking maximum at any time over the last weeks


The bug marked as blocking has no available sample, and the commit you say


https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket4161/

I dont understand why google hasnt indexed (or finding that) though

My testcase:
-i VR_MOVIE_GuyMartinsSpitfireBcast169\ qsf\ lappyAspectNoChnge_extract.mpg 
-bitexact -vcodec libx264 -an -vsync cfr file-16:9.ts



generated the regression just moved a failure path around, so how can it
change the reported aspect ratio of the input?


I have not investigated it, I just see that there are various circular features
in the video that are not circular anymore


I can't find a difference between 6.1 and master:


$ ffmpeg-6.1 -i VR_MOVIE_GuyMartinsSpitfireBcast169\ qsf\ 
lappyAspectNoChnge_extract.mpeg -bitexact -vcodec libx264 -an -vsync cfr 
-nostats -y file-16-9_6.1.ts
ffmpeg version n6.1.1-20240112 Copyright (c) 2000-2023 the FFmpeg developers
  built with gcc 13.2.0 (crosstool-NG 1.25.0.232_c175b21)
  configuration: --prefix=/ffbuild/prefix --pkg-config-flags=--static 
--pkg-config=pkg-config --cross-prefix=x86_64-w64-mingw32- --arch=x86_64 
--target-os=mingw32 --enable-gpl --enable-version3 --disable-debug 
--disable-w32threads --enable-pthreads --enable-iconv --enable-libxml2 
--enable-zlib --enable-libfreetype --enable-libfribidi --enable-gmp 
--enable-lzma --enable-fontconfig --enable-libharfbuzz --enable-libvorbis 
--enable-opencl --disable-libpulse --enable-libvmaf --disable-libxcb 
--disable-xlib --enable-amf --enable-libaom --enable-libaribb24 
--enable-avisynth --enable-chromaprint --enable-libdav1d --enable-libdavs2 
--disable-libfdk-aac --enable-ffnvcodec --enable-cuda-llvm --enable-frei0r 
--enable-libgme --enable-libkvazaar --enable-libaribcaption --enable-libass 
--enable-libbluray --enable-libjxl --enable-libmp3lame --enable-libopus 
--enable-librist --enable-libssh --enable-libtheora --enable-libvpx 
--enable-libwebp --enable-lv2 --enable-libvpl --enable-openal --enable-lib

opencore-amrnb --enable-libopencore-amrwb --enable-libopenh264 
--enable-libopenjpeg --enable-libopenmpt --enable-librav1e 
--enable-librubberband --enable-schannel --enable-sdl2 --enable-libsoxr 
--enable-libsrt --enable-libsvtav1 --enable-libtwolame --enable-libuavs3d 
--disable-libdrm --enable-vaapi --enable-libvidstab --enable-vulkan 
--enable-libshaderc --enable-libplacebo --enable-libx264 --enable-libx265 
--enable-libxavs2 --enable-libxvid --enable-libzimg --enable-libzvbi 
--extra-cflags=-DLIBTWOLAME_STATIC --extra-cxxflags= --extra-ldflags=-pthread 
--extra-ldexeflags= --extra-libs=-lgomp --extra-version=20240112

  libavutil  58. 29.100 / 58. 29.100
  libavcodec 60. 31.102 / 60. 31.102
  libavformat60. 16.100 / 60. 16.100
  libavdevice60.  3.100 / 60.  3.100
  libavfilter 9. 12.100 /  9. 12.100
  libswscale  7.  5.100 /  7.  5.100
  libswresample   4. 12.100 /  4. 12.100
  libpostproc57.  3.100 / 57.  3.100
-vsync is deprecated. Use -fps_mode
Input #0, mpeg, from 'VR_MOVIE_GuyMartinsSpitfireBcast169 qsf 
lappyAspectNoChnge_extract.mpeg':
  Duration: 00:00:09.02, start: 0.20, bitrate: 9119 kb/s
  Stream #0:0[0x1e0]: Video: mpeg2video (Main), yuv420p(tv, top first), 720x576 
[SAR 16:15 DAR 4:3], 25 fps, 25 tbr, 90k tbn
Side data:
  cpb: bitrate max/min/avg: 9263200/0/0 buffer size: 1835008 vbv_delay: N/A
  Stream #0:1[0x80]: Audio: ac3, 48000 Hz, stereo, fltp, 384 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (mpeg2video (native) -> h264 (libx264))
Press [q] to stop, [?] for help
[libx264 @ 01c5022c7000] using SAR=16/15
[libx264 @ 01c5022c7000] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 
AVX FMA3 BMI2 AVX2
[libx264 @ 01c5022c7000] profile High, level 3.0, 4:2:0, 8-bit
Output #0, mpegts, to 'file-16-9_6.1.ts':
  Stream #0:0: Video: h264, yuv420p(tv, top coded first (swapped)), 720x576 
[SAR 16:15 DAR 4:3], q=2-31, 25 fps, 90k tbn
Metadata:
  encoder : Lavc libx264
Side data:
  cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: N/A
[out#0/mpegts @ 01c502242000] video:1144kB audio:0kB subtitle:0kB other 
streams:0kB global headers:0kB muxing overhead: 7.177651%
frame=  225 fps=0.0 q=-1.0 Lsize=1226kB time=00:00:08.88 
bitrate=1131.0kbits/s dup=3 drop=0 

Re: [FFmpeg-devel] 7.0 release

2024-04-04 Thread Michael Niedermayer
On Thu, Apr 04, 2024 at 08:50:12AM -0300, James Almer wrote:
> On 4/4/2024 8:47 AM, Michael Niedermayer wrote:
> > On Thu, Apr 04, 2024 at 09:12:04AM +0200, Anton Khirnov wrote:
> > > Quoting Michael Niedermayer (2024-04-04 00:57:39)
> > > > Hi
> > > > 
> > > > I will try to make the 7.0 release from the release branch in the next 
> > > > 48h
> > > > (with some luck but easy possible it will get delayed)
> > > > i will not try to fix any issues marked as blocking 7.0 on trac, IIRC
> > > 
> > > IMO people are overly eager to mark everything as 'blocking'.
> > 
> > No, thats not true, very few bugs are marked as blocking, we have 2837
> > open/new bugs and 1 marked as blocking. And we had maybe 2-3 marked as
> > blocking maximum at any time over the last weeks
> 
> The bug marked as blocking has no available sample, and the commit you say
> generated the regression just moved a failure path around, so how can it
> change the reported aspect ratio of the input?

Its the wrong commit, its the next commit 
924a6f3cc7788e2d258348b1547a49805091ea2d

fftools/ffmpeg_dec: override video SAR with AVCodecParameters value

Rather than access the AVStream one.

This is a step towards decoupling Decoder and InputStream.

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


Re: [FFmpeg-devel] [PATCH v3 2/2] avfilter/vf_colorspace: Use colorspace negotiation API

2024-04-04 Thread Niklas Haas
On Thu, 04 Apr 2024 12:01:36 + Nicolas Gaullier 
 wrote:
> >De : Niklas Haas  
> >Envoyé : jeudi 4 avril 2024 12:18
> >> --- a/libavfilter/vf_colorspace.c
> >> +++ b/libavfilter/vf_colorspace.c
> >> @@ -433,8 +433,7 @@ static int create_filtergraph(AVFilterContext *ctx,
> >>  if (out->color_trc   != s->out_trc) s->out_txchr = NULL;
> >>  if (in->colorspace   != s->in_csp ||
> >>  in->color_range  != s->in_rng)  s->in_lumacoef   = NULL;
> >> -if (out->colorspace  != s->out_csp ||
> >> -out->color_range != s->out_rng) s->out_lumacoef  = NULL;
> >> +if (out->color_range != s->out_rng) s->rgb2yuv   = NULL;
> >
> >Can you explain this change to me?
> 
> This is how I understand things: the output colorspace is a mandatory 
> parameter of the filter, so it can be set early and negotiated,
> So I lifted some part of the code from the "dynamic" part 
> (filter_frame/create_filtergraph) to upstream "init/query_formats".
> out_lumacoef depends on colorspace solely, so it seems there is no point to 
> unset it and re-set it again.
> rgb2yuv is dynamic, dependent on the range, so this is the new trigger, the 
> pointer that has to be updated.
> 
> >> @@ -735,6 +736,9 @@ static int filter_frame(AVFilterLink *link, AVFrame 
> >> *in)
> >>  return res;
> >>  }
> >>  
> >> +out->colorspace = s->out_csp;
> >> +outlink->color_range = s->user_rng != AVCOL_RANGE_UNSPECIFIED ? 
> >> s->user_rng : in->color_range;
> >> +out->color_range = outlink->color_range;
> >
> >Changing outlink dynamically like this seems not correct to me (what if the 
> >next filter in the chain only supports one color range?). Changing the range 
> >on the fly would at the minimum require reconfiguring the filter graph, and 
> >>possibly insertion of more auto-scale filters.
> This is the kind of questioning I had when working on this issue. This seems 
> very annoying and overly complex for a very uncommon scenario; is it even 
> possible within the filter to ask for a reconfiguration of the filter graph ?

No, reconfiguring the filter graph is (currently) the API user's
responsibility. (See fftools/ffmpeg_filter.c for an example)

vf_buffersrc even warns you if you try and change colorspace properties
mid-stream, and for good reason - IMO there is no general expectation
that filters should be able to handle dynamically changing colorspace
properties. (This is a feature, not a bug)

There *are* some filters that handle dynamically changing input
properties (e.g. scale, zscale, libplacebo), but these are the exception
rather than the norm, and it's only because they're already written in
a way that can trivially handle dynamic conversions.

If it's difficult to do from within vf_colorspace, there's no need to do
so. Feel free to assume that frame->colorspace == inlink->colorspace ==
constant. (Ditto color_range)

> 
> >The logic that is used in the other YUV negotiation aware filters is to just 
> >set `out->colorspace = outlink->colorspace` and `out->color_range = 
> >outlink->color_range`, since the link properties are authoritative.
> This is the kind of easy logic I tried at the beginning. Some water has 
> flowed under the bridge, notably b89ee26539, but I just tried at the moment 
> (with current code) an easy patch with just these two lines, and it still 
> does not work as "I" expected.
> More specifically:
> When running: ./ffprobe -f lavfi -i 
> yuvtestsrc,setparams=color_primaries=bt470bg:color_trc=smpte170m:colorspace=bt470bg,colorspace=bt709:range=tv,scale,showinfo
> At the entry of filter_frame(), the outlink values are incorrect:
> colorspace = AVCOL_SPC_BT470BG
> And color_range = AVCOL_RANGE_UNSPECIFIED
> So, this is why I introduced the negotiation for the colorspace to early set 
> and persist this outlink property.
> But for the range, I am bit confused with the documentation, it is not clear 
> to me, but possibly it is expected to pass through? so it cannot be 
> negotiated, so I am sticked if the outlink range cannot be changed 
> dynamically...

Note: passing through the range untouched *is* the default behavior (via
ff_default_query_formats). So I think the correct logic can be condensed
into just:

if (out_rng != UNSPEC) {
ret = set_common_color_ranges(make_singleton(out_rng));
if (ret < 0)
return ret;
}

That way, if the user passes unspec, it's guaranteed that the input
range == output_range (but with no preference for any specific range);
but if the user passes a specific range, both the input and output of
the filter are forced to be this range.

Hopefully that clears up some confusion?

> 
> >Nit: Why introduce a new result variable instead of re-using the one that's 
> >already declared?
> >IMO this logic would look cleaner if you assigned ret before testing it, 
> >especially since it's nested.
> Thanks, ok, will fix this in the next version.
> 
> Thank you for your review; as you can see, I have no certainty, 

Re: [FFmpeg-devel] 7.0 release

2024-04-04 Thread Michael Niedermayer
On Thu, Apr 04, 2024 at 08:50:12AM -0300, James Almer wrote:
> On 4/4/2024 8:47 AM, Michael Niedermayer wrote:
> > On Thu, Apr 04, 2024 at 09:12:04AM +0200, Anton Khirnov wrote:
> > > Quoting Michael Niedermayer (2024-04-04 00:57:39)
> > > > Hi
> > > > 
> > > > I will try to make the 7.0 release from the release branch in the next 
> > > > 48h
> > > > (with some luck but easy possible it will get delayed)
> > > > i will not try to fix any issues marked as blocking 7.0 on trac, IIRC
> > > 
> > > IMO people are overly eager to mark everything as 'blocking'.
> > 
> > No, thats not true, very few bugs are marked as blocking, we have 2837
> > open/new bugs and 1 marked as blocking. And we had maybe 2-3 marked as
> > blocking maximum at any time over the last weeks
> 
> The bug marked as blocking has no available sample, and the commit you say

https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket4161/

I dont understand why google hasnt indexed (or finding that) though

My testcase:
-i VR_MOVIE_GuyMartinsSpitfireBcast169\ qsf\ lappyAspectNoChnge_extract.mpg 
-bitexact -vcodec libx264 -an -vsync cfr file-16:9.ts


> generated the regression just moved a failure path around, so how can it
> change the reported aspect ratio of the input?

I have not investigated it, I just see that there are various circular features
in the video that are not circular anymore

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data


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 v3 2/2] avfilter/vf_colorspace: Use colorspace negotiation API

2024-04-04 Thread Nicolas Gaullier
>De : Nicolas Gaullier 
>Envoyé : jeudi 4 avril 2024 14:02
>
>>The logic that is used in the other YUV negotiation aware filters is to just 
>>set `out->colorspace = outlink->colorspace` and `out->color_range = 
>>outlink->color_range`, since the link properties are authoritative.
>This is the kind of easy logic I tried at the beginning. Some water has flowed 
>under the bridge, notably b89ee26539, but I just tried at the moment (with 
>current code) an easy patch with just these two lines, and it still does not 
>work >as "I" expected.
>More specifically:
>When running: ./ffprobe -f lavfi -i 
>yuvtestsrc,setparams=color_primaries=bt470bg:color_trc=smpte170m:colorspace=bt470bg,colorspace=bt709:range=tv,scale,showinfo
>At the entry of filter_frame(), the outlink values are incorrect:
>colorspace = AVCOL_SPC_BT470BG
>And color_range = AVCOL_RANGE_UNSPECIFIED So, this is why I introduced the 
>negotiation for the colorspace to early set and persist this outlink property.
>But for the range, I am bit confused with the documentation, it is not clear 
>to me, but possibly it is expected to pass through? so it cannot be 
>negotiated, so I am sticked if the outlink range cannot be changed 
>dynamically...

I was too hasty, sorry, let me precise what is running wrong:
the "out" frame colorspace/range is fine
And when running:
/ffprobe -f lavfi -i 
yuvtestsrc,setparams=color_primaries=bt470bg:color_trc=smpte170m:colorspace=bt470bg,colorspace=bt709:range=tv,showinfo
 2>&1|grep color_space
you actually get, as expected:
color_range:tv color_space:bt709

The issue is the link, and it is raised when chaining with the scale filter for 
example here:
./ffprobe -f lavfi -i 
yuvtestsrc,setparams=color_primaries=bt470bg:color_trc=smpte170m:colorspace=bt470bg,colorspace=bt709:range=tv,scale,showinfo
 2>&1|grep color_space
color_range:unknown color_space:bt470bg

So, I don't know, maybe my approach (fixing vf_colorspace) is wrong ?
Anyway, the "out->color_range = outlink->color_range" logic does not seem to be 
the kind of things to do here.

Thank you again
Nicolas
___
ffmpeg-devel mailing list
ffmpeg-devel@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] avfilter/vf_colorspace: Use colorspace negotiation API

2024-04-04 Thread Nicolas Gaullier
>De : Niklas Haas  
>Envoyé : jeudi 4 avril 2024 12:18
>> --- a/libavfilter/vf_colorspace.c
>> +++ b/libavfilter/vf_colorspace.c
>> @@ -433,8 +433,7 @@ static int create_filtergraph(AVFilterContext *ctx,
>>  if (out->color_trc   != s->out_trc) s->out_txchr = NULL;
>>  if (in->colorspace   != s->in_csp ||
>>  in->color_range  != s->in_rng)  s->in_lumacoef   = NULL;
>> -if (out->colorspace  != s->out_csp ||
>> -out->color_range != s->out_rng) s->out_lumacoef  = NULL;
>> +if (out->color_range != s->out_rng) s->rgb2yuv   = NULL;
>
>Can you explain this change to me?

This is how I understand things: the output colorspace is a mandatory parameter 
of the filter, so it can be set early and negotiated,
So I lifted some part of the code from the "dynamic" part 
(filter_frame/create_filtergraph) to upstream "init/query_formats".
out_lumacoef depends on colorspace solely, so it seems there is no point to 
unset it and re-set it again.
rgb2yuv is dynamic, dependent on the range, so this is the new trigger, the 
pointer that has to be updated.

>> @@ -735,6 +736,9 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
>>  return res;
>>  }
>>  
>> +out->colorspace = s->out_csp;
>> +outlink->color_range = s->user_rng != AVCOL_RANGE_UNSPECIFIED ? 
>> s->user_rng : in->color_range;
>> +out->color_range = outlink->color_range;
>
>Changing outlink dynamically like this seems not correct to me (what if the 
>next filter in the chain only supports one color range?). Changing the range 
>on the fly would at the minimum require reconfiguring the filter graph, and 
>>possibly insertion of more auto-scale filters.
This is the kind of questioning I had when working on this issue. This seems 
very annoying and overly complex for a very uncommon scenario; is it even 
possible within the filter to ask for a reconfiguration of the filter graph ?

>The logic that is used in the other YUV negotiation aware filters is to just 
>set `out->colorspace = outlink->colorspace` and `out->color_range = 
>outlink->color_range`, since the link properties are authoritative.
This is the kind of easy logic I tried at the beginning. Some water has flowed 
under the bridge, notably b89ee26539, but I just tried at the moment (with 
current code) an easy patch with just these two lines, and it still does not 
work as "I" expected.
More specifically:
When running: ./ffprobe -f lavfi -i 
yuvtestsrc,setparams=color_primaries=bt470bg:color_trc=smpte170m:colorspace=bt470bg,colorspace=bt709:range=tv,scale,showinfo
At the entry of filter_frame(), the outlink values are incorrect:
colorspace = AVCOL_SPC_BT470BG
And color_range = AVCOL_RANGE_UNSPECIFIED
So, this is why I introduced the negotiation for the colorspace to early set 
and persist this outlink property.
But for the range, I am bit confused with the documentation, it is not clear to 
me, but possibly it is expected to pass through? so it cannot be negotiated, so 
I am sticked if the outlink range cannot be changed dynamically...

>Nit: Why introduce a new result variable instead of re-using the one that's 
>already declared?
>IMO this logic would look cleaner if you assigned ret before testing it, 
>especially since it's nested.
Thanks, ok, will fix this in the next version.

Thank you for your review; as you can see, I have no certainty, rather many 
questions...

Nicolas
___
ffmpeg-devel mailing list
ffmpeg-devel@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 release

2024-04-04 Thread James Almer

On 4/4/2024 8:47 AM, Michael Niedermayer wrote:

On Thu, Apr 04, 2024 at 09:12:04AM +0200, Anton Khirnov wrote:

Quoting Michael Niedermayer (2024-04-04 00:57:39)

Hi

I will try to make the 7.0 release from the release branch in the next 48h
(with some luck but easy possible it will get delayed)
i will not try to fix any issues marked as blocking 7.0 on trac, IIRC


IMO people are overly eager to mark everything as 'blocking'.


No, thats not true, very few bugs are marked as blocking, we have 2837
open/new bugs and 1 marked as blocking. And we had maybe 2-3 marked as
blocking maximum at any time over the last weeks


The bug marked as blocking has no available sample, and the commit you 
say generated the regression just moved a failure path around, so how 
can it change the reported aspect ratio of the input?

___
ffmpeg-devel mailing list
ffmpeg-devel@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 release

2024-04-04 Thread Michael Niedermayer
On Thu, Apr 04, 2024 at 09:12:04AM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-04-04 00:57:39)
> > Hi
> > 
> > I will try to make the 7.0 release from the release branch in the next 48h
> > (with some luck but easy possible it will get delayed)
> > i will not try to fix any issues marked as blocking 7.0 on trac, IIRC
> 
> IMO people are overly eager to mark everything as 'blocking'.

No, thats not true, very few bugs are marked as blocking, we have 2837
open/new bugs and 1 marked as blocking. And we had maybe 2-3 marked as
blocking maximum at any time over the last weeks


> Not every
> bug ... should be blocking,

true


> and not every regression

IMO, every regression should by default be blocking. Adding regressions
is not ok. And adding and releasing with regressions should not be the
default mode of operation.

It should be
1. Mark every regression as blocking
2. Make an effort to fix the bugs you caused and help others to fix theirs
3. If some individual bug is too difficult to fix, make a concious decission
   to move that specific bugs blocking tag to the next release
4. If teh release gets delayed too much, its possible to release with the
   regressions, because "no release" can be worse


> otherwise nothing ever
> gets finished.

Lets look at the facts
we have 151 open/new bugs marked as regressions, 3 of them are less than
8 months old.
That means 2 things

1. we have hundreads of old regressions (some maybe even arent reported)
that are not getting fixed. Thats an issue and more attention should be
brought to them.

2. we have 3 regressions that are new, I do think we can and should
handle fixing new regressions.

and 3. we arent really blocking the release, the blocking tag is flexible
and very easy to change to the next release. But it gives things more 
vissibility

thx

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

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad


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] movenc: Allow writing timed ID3 metadata

2024-04-04 Thread Martin Storsjö
This is based on a spec at https://aomediacodec.github.io/id3-emsg/,
further based on ISO/IEC 23009-1:2019.

Within libavformat, timed ID3 metadata (already supported by the
mpegts demuxer and muxer) is handled as a separate data AVStream
with codec type AV_CODEC_ID_TIMED_ID3. However, it doesn't
have a corresponding track in the mov file - instead, these events
are written as separate toplevel 'emsg' boxes.
---
 libavformat/movenc.c   | 49 -
 libavformat/tests/movenc.c | 55 +-
 tests/ref/fate/movenc  |  8 ++
 3 files changed, 104 insertions(+), 8 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index ccdd2dbfc9..29b1e4bb0f 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -5515,7 +5515,7 @@ static int mov_write_ftyp_tag(AVIOContext *pb, 
AVFormatContext *s)
 {
 MOVMuxContext *mov = s->priv_data;
 int64_t pos = avio_tell(pb);
-int has_h264 = 0, has_av1 = 0, has_video = 0, has_dolby = 0;
+int has_h264 = 0, has_av1 = 0, has_video = 0, has_dolby = 0, has_id3 = 0;
 int has_iamf = 0;
 
 for (int i = 0; i < s->nb_stream_groups; i++) {
@@ -5544,6 +5544,8 @@ static int mov_write_ftyp_tag(AVIOContext *pb, 
AVFormatContext *s)
 st->codecpar->nb_coded_side_data,
 AV_PKT_DATA_DOVI_CONF))
 has_dolby = 1;
+if (st->codecpar->codec_id == AV_CODEC_ID_TIMED_ID3)
+has_id3 = 1;
 }
 
 avio_wb32(pb, 0); /* size */
@@ -5623,6 +5625,9 @@ static int mov_write_ftyp_tag(AVIOContext *pb, 
AVFormatContext *s)
 if (mov->flags & FF_MOV_FLAG_DASH && mov->flags & FF_MOV_FLAG_GLOBAL_SIDX)
 ffio_wfourcc(pb, "dash");
 
+if (has_id3)
+ffio_wfourcc(pb, "aid3");
+
 return update_size(pb, pos);
 }
 
@@ -6704,6 +6709,34 @@ static int mov_build_iamf_packet(AVFormatContext *s, 
MOVTrack *trk, AVPacket *pk
 return ret;
 }
 
+static int mov_write_emsg_tag(AVIOContext *pb, AVStream *st, AVPacket *pkt)
+{
+int64_t pos = avio_tell(pb);
+const char *scheme_id_uri = "https://aomedia.org/emsg/ID3;;
+const char *value = "";
+
+av_assert0(st->time_base.num == 1);
+
+avio_write_marker(pb,
+  av_rescale_q(pkt->pts, st->time_base, AV_TIME_BASE_Q),
+  AVIO_DATA_MARKER_BOUNDARY_POINT);
+
+avio_wb32(pb, 0); /* size */
+ffio_wfourcc(pb, "emsg");
+avio_w8(pb, 1); /* version */
+avio_wb24(pb, 0);
+avio_wb32(pb, st->time_base.den); /* timescale */
+avio_wb64(pb, pkt->pts); /* presentation_time */
+avio_wb32(pb, 0xU); /* event_duration */
+avio_wb32(pb, 0); /* id */
+/* null terminated UTF8 strings */
+avio_write(pb, scheme_id_uri, strlen(scheme_id_uri) + 1);
+avio_write(pb, value, strlen(value) + 1);
+avio_write(pb, pkt->data, pkt->size);
+
+return update_size(pb, pos);
+}
+
 static int mov_write_packet(AVFormatContext *s, AVPacket *pkt)
 {
 MOVMuxContext *mov = s->priv_data;
@@ -6714,6 +6747,11 @@ static int mov_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 return 1;
 }
 
+if (s->streams[pkt->stream_index]->codecpar->codec_id == 
AV_CODEC_ID_TIMED_ID3) {
+mov_write_emsg_tag(s->pb, s->streams[pkt->stream_index], pkt);
+return 0;
+}
+
 trk = s->streams[pkt->stream_index]->priv_data;
 
 if (trk->iamf) {
@@ -7365,6 +7403,12 @@ static int mov_init(AVFormatContext *s)
 AVStream *st = s->streams[i];
 if (st->priv_data)
 continue;
+// Don't produce a track in the output file for timed ID3 streams.
+if (st->codecpar->codec_id == AV_CODEC_ID_TIMED_ID3) {
+// Leave priv_data set to NULL for these AVStreams that don't
+// have a corresponding track.
+continue;
+}
 st->priv_data = st;
 mov->nb_tracks++;
 }
@@ -7462,6 +7506,9 @@ static int mov_init(AVFormatContext *s)
 MOVTrack *track = st->priv_data;
 AVDictionaryEntry *lang = av_dict_get(st->metadata, "language", 
NULL,0);
 
+if (!track)
+continue;
+
 if (!track->st) {
 track->st  = st;
 track->par = st->codecpar;
diff --git a/libavformat/tests/movenc.c b/libavformat/tests/movenc.c
index 12a3632d4e..2fd5c67e76 100644
--- a/libavformat/tests/movenc.c
+++ b/libavformat/tests/movenc.c
@@ -58,7 +58,7 @@ struct AVMD5* md5;
 uint8_t hash[HASH_SIZE];
 
 AVPacket *pkt;
-AVStream *video_st, *audio_st;
+AVStream *video_st, *audio_st, *id3_st;
 int64_t audio_dts, video_dts;
 
 int bframes;
@@ -177,7 +177,7 @@ static void check_func(int value, int line, const char 
*msg, ...)
 }
 #define check(value, ...) check_func(value, __LINE__, __VA_ARGS__)
 
-static void init_fps(int bf, int audio_preroll, int fps)
+static void init_fps(int bf, int audio_preroll, int fps, int id3)
 {
 AVStream *st;
 int iobuf_size = 

[FFmpeg-devel] [PATCH] tests/movenc: Validate that normal muxer usage doesn't print warnings

2024-04-04 Thread Martin Storsjö
We have test to make sure that certain configurations do print
warnings. However, the normal operation of the muxer within this
test always printed a warning, so those tests to check for
extra warnings didn't essentially guard anything.

The warning that always was printed, "track 1: codec frame size is
not set" was not present in the libav fork where this testcase
originated, it was removed in f234e8a32e6c69d7b63f8627f278be7c2c987f43.

Set the frame size for the audio stream to silence the warning,
and use this frame size in a couple later calculations, and check
that one test configuration doesn't print warnings.

Setting the frame size apparently changes the rounding of a timestamp
in the ismv muxing testcase.
---
 libavformat/tests/movenc.c | 10 --
 tests/ref/fate/movenc  |  2 +-
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/libavformat/tests/movenc.c b/libavformat/tests/movenc.c
index 77f73abdfa..12a3632d4e 100644
--- a/libavformat/tests/movenc.c
+++ b/libavformat/tests/movenc.c
@@ -215,6 +215,7 @@ static void init_fps(int bf, int audio_preroll, int fps)
 st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
 st->codecpar->codec_id = AV_CODEC_ID_AAC;
 st->codecpar->sample_rate = 44100;
+st->codecpar->frame_size = 1024;
 st->codecpar->ch_layout = (AVChannelLayout)AV_CHANNEL_LAYOUT_STEREO;
 st->time_base.num = 1;
 st->time_base.den = 44100;
@@ -232,9 +233,10 @@ static void init_fps(int bf, int audio_preroll, int fps)
 frames = 0;
 gop_size = 30;
 duration = video_st->time_base.den / fps;
-audio_duration = 1024LL * audio_st->time_base.den / 
audio_st->codecpar->sample_rate;
+audio_duration = (long long)audio_st->codecpar->frame_size *
+ audio_st->time_base.den / audio_st->codecpar->sample_rate;
 if (audio_preroll)
-audio_preroll = 2048LL * audio_st->time_base.den / 
audio_st->codecpar->sample_rate;
+audio_preroll = 2 * audio_duration;
 
 bframes = bf;
 video_dts = bframes ? -duration : 0;
@@ -442,6 +444,7 @@ int main(int argc, char **argv)
 // Similar to the previous one, but with input that doesn't start at
 // pts/dts 0. avoid_negative_ts behaves in the same way as
 // in non-empty-moov-no-elst above.
+init_count_warnings();
 init_out("empty-moov-no-elst");
 av_dict_set(, "movflags", "+frag_keyframe+empty_moov", 0);
 init(1, 0);
@@ -449,6 +452,9 @@ int main(int argc, char **argv)
 finish();
 close_out();
 
+reset_count_warnings();
+check(num_warnings == 0, "Unexpected warnings printed");
+
 // Same as the previous one, but disable avoid_negative_ts (which
 // would require using an edit list, but with empty_moov, one can't
 // write a sensible edit list, when the start timestamps aren't known).
diff --git a/tests/ref/fate/movenc b/tests/ref/fate/movenc
index 968a3d27f2..0c77f5187c 100644
--- a/tests/ref/fate/movenc
+++ b/tests/ref/fate/movenc
@@ -20,7 +20,7 @@ write_data len 828, time nopts, type unknown atom -
 write_data len 728, time 99, type sync atom moof
 write_data len 812, time nopts, type unknown atom -
 write_data len 148, time nopts, type trailer atom -
-92ce825ff40505ec8676191705adb7e7 4439 ismv
+d2df24d323f4a8896441cd91203ac5f8 4439 ismv
 write_data len 36, time nopts, type header atom ftyp
 write_data len 1123, time nopts, type header atom -
 write_data len 796, time 0, type sync atom moof
-- 
2.39.3 (Apple Git-146)

___
ffmpeg-devel mailing list
ffmpeg-devel@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] movenc: Remove a leftover commented out line

2024-04-04 Thread Martin Storsjö
This line originates from 6f69f7a8bf6a0d013985578df2ef42ee6b1c7994.
---
 libavformat/movenc.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 46a5b3a62f..ccdd2dbfc9 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -1173,8 +1173,6 @@ static int get_samples_per_packet(MOVTrack *track)
 {
 int i, first_duration;
 
-// return track->par->frame_size;
-
 /* use 1 for raw PCM */
 if (!track->audio_vbr)
 return 1;
-- 
2.39.3 (Apple Git-146)

___
ffmpeg-devel mailing list
ffmpeg-devel@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] avfilter/vf_colorspace: Use colorspace negotiation API

2024-04-04 Thread Niklas Haas
On Tue, 02 Apr 2024 15:05:59 +0200 Nicolas Gaullier 
 wrote:
> Fixes a regression due to the fact that the colorspace filter does
> not use the new API introduced by 8c7934f73ab6c568acaa.
> The scale filter uses it since 45e09a30419cc2a7251e, and the setparams
> filter since 3bf80df3ccd32aed23f0.
> 
> Example 1 - color_range specified:
> ffmpeg -f lavfi -i yuvtestsrc -vf setparams=color_primaries=bt470bg:
> color_trc=smpte170m:colorspace=bt470bg,colorspace=bt709:range=tv,scale
> ,showinfo -f null -frames 1 -
> 
> Before:
>   color_range:unknown color_space:bt470bg ...
> After:
>   color_range:tv color_space:bt709 ...
> 
> Example 2 - color_range pass-through:
> ffmpeg -f lavfi -i yuvtestsrc -vf "setparams=color_primaries=bt470bg:
> color_trc=smpte170m:colorspace=bt470bg:range=unknown,
> setparams=range=pc:enable='between(n,1,2)',
> setparams=range=tv:enable='between(n,2,3)',
> colorspace=bt709,scale,showinfo"
> -f null -frames 3 - 2>&1|awk "/color_/ {print \$4 \" \" \$5}"
> 
> Before:
> color_range:tv color_space:bt470bg
> color_range:tv color_space:bt470bg
> color_range:tv color_space:bt470bg
> After:
> color_range:unknown color_space:bt709
> color_range:pc color_space:bt709
> color_range:tv color_space:bt709
> 
> Signed-off-by: Nicolas Gaullier 
> ---
>  libavfilter/vf_colorspace.c | 63 +
>  1 file changed, 36 insertions(+), 27 deletions(-)
> 
> diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
> index d181e81ace..12a571172b 100644
> --- a/libavfilter/vf_colorspace.c
> +++ b/libavfilter/vf_colorspace.c
> @@ -433,8 +433,7 @@ static int create_filtergraph(AVFilterContext *ctx,
>  if (out->color_trc   != s->out_trc) s->out_txchr = NULL;
>  if (in->colorspace   != s->in_csp ||
>  in->color_range  != s->in_rng)  s->in_lumacoef   = NULL;
> -if (out->colorspace  != s->out_csp ||
> -out->color_range != s->out_rng) s->out_lumacoef  = NULL;
> +if (out->color_range != s->out_rng) s->rgb2yuv   = NULL;

Can you explain this change to me?

>  
>  if (!s->out_primaries || !s->in_primaries) {
>  s->in_prm = in->color_primaries;
> @@ -563,26 +562,8 @@ static int create_filtergraph(AVFilterContext *ctx,
>  redo_yuv2rgb = 1;
>  }
>  
> -if (!s->out_lumacoef) {
> -s->out_csp = out->colorspace;
> +if (!s->rgb2yuv) {
>  s->out_rng = out->color_range;
> -s->out_lumacoef = av_csp_luma_coeffs_from_avcsp(s->out_csp);
> -if (!s->out_lumacoef) {
> -if (s->out_csp == AVCOL_SPC_UNSPECIFIED) {
> -if (s->user_all == CS_UNSPECIFIED) {
> -av_log(ctx, AV_LOG_ERROR,
> -   "Please specify output colorspace\n");
> -} else {
> -av_log(ctx, AV_LOG_ERROR,
> -   "Unsupported output color property %d\n", 
> s->user_all);
> -}
> -} else {
> -av_log(ctx, AV_LOG_ERROR,
> -   "Unsupported output colorspace %d (%s)\n", s->out_csp,
> -   av_color_space_name(s->out_csp));
> -}
> -return AVERROR(EINVAL);
> -}
>  redo_rgb2yuv = 1;
>  }
>  
> @@ -687,6 +668,26 @@ static av_cold int init(AVFilterContext *ctx)
>  {
>  ColorSpaceContext *s = ctx->priv;
>  
> +s->out_csp  = s->user_csp == AVCOL_SPC_UNSPECIFIED ?
> +  default_csp[FFMIN(s->user_all, CS_NB)] : s->user_csp;
> +s->out_lumacoef = av_csp_luma_coeffs_from_avcsp(s->out_csp);
> +if (!s->out_lumacoef) {
> +if (s->out_csp == AVCOL_SPC_UNSPECIFIED) {
> +if (s->user_all == CS_UNSPECIFIED) {
> +av_log(ctx, AV_LOG_ERROR,
> +   "Please specify output colorspace\n");
> +} else {
> +av_log(ctx, AV_LOG_ERROR,
> +   "Unsupported output color property %d\n", 
> s->user_all);
> +}
> +} else {
> +av_log(ctx, AV_LOG_ERROR,
> +   "Unsupported output colorspace %d (%s)\n", s->out_csp,
> +   av_color_space_name(s->out_csp));
> +}
> +return AVERROR(EINVAL);
> +}
> +
>  ff_colorspacedsp_init(>dsp);
>  
>  return 0;
> @@ -735,6 +736,9 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
>  return res;
>  }
>  
> +out->colorspace = s->out_csp;
> +outlink->color_range = s->user_rng != AVCOL_RANGE_UNSPECIFIED ? 
> s->user_rng : in->color_range;
> +out->color_range = outlink->color_range;

Changing outlink dynamically like this seems not correct to me (what if
the next filter in the chain only supports one color range?). Changing
the range on the fly would at the minimum require reconfiguring the
filter graph, and possibly insertion of more auto-scale filters.

The logic that is used in the other YUV negotiation aware filters is to
just 

Re: [FFmpeg-devel] [PATCH v3 0/2] avfilter/vf_colorspace: Use colorspace negotiation API

2024-04-04 Thread Nicolas Gaullier
>Envoyé : mardi 2 avril 2024 15:06
>
>v3:
>- Fixes case where colorspace is the first filter (no inlink)
>- Illustrates with proper examples in commit msg (use yuvtestsrc instead of 
>testsrc)
>
>Please note that it is a regression compared to the previous release:
>both examples (see commit msg) behave the same way as 6.1 after this patch.
>
>Nicolas Gaullier (2):
>  avfilter/vf_setparams: Add timeline support
>  avfilter/vf_colorspace: Use colorspace negotiation API

Any chance to get this regression fixed for 7.0 one way or another?
For remembering:
./ffprobe -f lavfi -i 
yuvtestsrc,setparams=color_primaries=bt470bg:color_trc=smpte170m:colorspace=bt470bg,colorspace=bt709:range=tv,scale,showinfo
 2>&1|grep color_space
Current code:
color_range:unknown color_space:bt470bg ...
Release 6.1: (expected values) [or current code with my proposed patch]
color_range:tv color_space:bt709 ...

Thanks
Nicolas
___
ffmpeg-devel mailing list
ffmpeg-devel@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 release

2024-04-04 Thread Anton Khirnov
Quoting Michael Niedermayer (2024-04-04 00:57:39)
> Hi
> 
> I will try to make the 7.0 release from the release branch in the next 48h
> (with some luck but easy possible it will get delayed)
> i will not try to fix any issues marked as blocking 7.0 on trac, IIRC

IMO people are overly eager to mark everything as 'blocking'. Not every
bug and not every regression should be blocking, otherwise nothing ever
gets finished.

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

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


Re: [FFmpeg-devel] [PATCH 2/2] libavfilter/dnn_io_proc: Take step into consideration when crop frame

2024-04-04 Thread Guo, Yejun



> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> wenbin.chen-at-intel@ffmpeg.org
> Sent: Tuesday, April 2, 2024 4:13 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH 2/2] libavfilter/dnn_io_proc: Take step into
> consideration when crop frame
> 
> From: Wenbin Chen 
> 
> Signed-off-by: Wenbin Chen 
> ---
>  libavfilter/dnn/dnn_io_proc.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/libavfilter/dnn/dnn_io_proc.c b/libavfilter/dnn/dnn_io_proc.c
> index e5d6edb301..d2ec9f63f5 100644
> --- a/libavfilter/dnn/dnn_io_proc.c
> +++ b/libavfilter/dnn/dnn_io_proc.c
> @@ -350,6 +350,7 @@ int ff_frame_to_dnn_classify(AVFrame *frame,
> DNNData *input, uint32_t bbox_index
>  const AVDetectionBBoxHeader *header;
>  const AVDetectionBBox *bbox;
>  AVFrameSideData *sd = av_frame_get_side_data(frame,
> AV_FRAME_DATA_DETECTION_BBOXES);
> +int max_step[4] = { 0 };
>  av_assert0(sd);
> 
>  /* (scale != 1 and scale != 0) or mean != 0 */ @@ -405,8 +406,9 @@ int
> ff_frame_to_dnn_classify(AVFrame *frame, DNNData *input, uint32_t
> bbox_index
>  offsety[1] = offsety[2] = AV_CEIL_RSHIFT(top, desc->log2_chroma_h);
>  offsety[0] = offsety[3] = top;
> 
> +av_image_fill_max_pixsteps(max_step, NULL, desc);
>  for (int k = 0; frame->data[k]; k++)
> -bbox_data[k] = frame->data[k] + offsety[k] * frame->linesize[k] +
> offsetx[k];
> +bbox_data[k] = frame->data[k] + offsety[k] * frame->linesize[k]
> + + offsetx[k] * max_step[k];
> 
>  sws_scale(sws_ctx, (const uint8_t *const *)_data, frame->linesize,
> 0, height,

Thanks for the catch, will push soon.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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