[FFmpeg-devel] [PATCH v2 3/3] avcodec/v210enc: suppport frame thread for v210

[lance . lmwang]

From: Limin Wang 

Signed-off-by: Limin Wang 
---
 libavcodec/v210enc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/v210enc.c b/libavcodec/v210enc.c
index 22875be..16c4f82 100644
--- a/libavcodec/v210enc.c
+++ b/libavcodec/v210enc.c
@@ -156,7 +156,7 @@ const AVCodec ff_v210_encoder = {
 .long_name  = NULL_IF_CONFIG_SMALL("Uncompressed 4:2:2 10-bit"),
 .type   = AVMEDIA_TYPE_VIDEO,
 .id = AV_CODEC_ID_V210,
-.capabilities   = AV_CODEC_CAP_DR1,
+.capabilities   = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
 .priv_data_size = sizeof(V210EncContext),
 .init   = encode_init,
 .encode2= encode_frame,
-- 
1.8.3.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 2/3] avcodec/rawenc: suppport frame thread for rawvideo

[lance . lmwang]

From: Limin Wang 

Signed-off-by: Limin Wang 
---
 libavcodec/rawenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/rawenc.c b/libavcodec/rawenc.c
index 7e15084..561d992 100644
--- a/libavcodec/rawenc.c
+++ b/libavcodec/rawenc.c
@@ -85,7 +85,7 @@ const AVCodec ff_rawvideo_encoder = {
 .long_name  = NULL_IF_CONFIG_SMALL("raw video"),
 .type   = AVMEDIA_TYPE_VIDEO,
 .id = AV_CODEC_ID_RAWVIDEO,
-.capabilities   = AV_CODEC_CAP_DR1,
+.capabilities   = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
 .init   = raw_encode_init,
 .encode2= raw_encode,
 .caps_internal  = FF_CODEC_CAP_INIT_THREADSAFE,
-- 
1.8.3.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 1/3] fate: use single thread for rawvideo

[lance . lmwang]

From: Limin Wang 

Signed-off-by: Limin Wang 
---
 tests/fate/ffmpeg.mak | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak
index 4ba73a8..2a6a066 100644
--- a/tests/fate/ffmpeg.mak
+++ b/tests/fate/ffmpeg.mak
@@ -32,7 +32,7 @@ fate-ffmpeg-filter_complex_audio: CMD = framecrc 
-auto_conversion_filters -filte
 
 # Ticket 6375, use case of NoX
 FATE_SAMPLES_FFMPEG-$(call ALLYES, MOV_DEMUXER PNG_DECODER ALAC_DECODER 
PCM_S16LE_ENCODER RAWVIDEO_ENCODER) += fate-ffmpeg-attached_pics
-fate-ffmpeg-attached_pics: CMD = threads=2 framecrc -i 
$(TARGET_SAMPLES)/lossless-audio/inside.m4a -c:a pcm_s16le 
-max_muxing_queue_size 16 -af aresample
+fate-ffmpeg-attached_pics: CMD = threads=2 framecrc -i 
$(TARGET_SAMPLES)/lossless-audio/inside.m4a -c:a pcm_s16le -threads 1 
-max_muxing_queue_size 16 -af aresample
 
 FATE_SAMPLES_FFMPEG-$(CONFIG_COLORKEY_FILTER) += fate-ffmpeg-filter_colorkey
 fate-ffmpeg-filter_colorkey: tests/data/filtergraphs/colorkey
@@ -54,7 +54,7 @@ fate-sub2video: CMD = framecrc -auto_conversion_filters \
   -f rawvideo -r 5 -s 352x288 -pix_fmt yuv420p -i 
$(TARGET_PATH)/tests/data/vsynth_lena.yuv \
   -ss 132 -i $(TARGET_SAMPLES)/sub/vobsub.idx \
   -filter_complex 
"sws_flags=+accurate_rnd+bitexact\;[0:0]scale=720:480[v]\;[v][1:0]overlay[v2]" \
-  -map "[v2]" -c:v rawvideo -map 1:s -c:s dvdsub
+  -map "[v2]" -c:v rawvideo -threads 1 -map 1:s -c:s dvdsub
 
 # Very basic sub2video example, decode and convert to AVFrame with sub2video.
 # Attempt to not touch timestamps.
@@ -63,7 +63,7 @@ fate-sub2video_basic: CMD = framecrc -auto_conversion_filters 
\
   -i $(TARGET_SAMPLES)/sub/vobsub.idx \
   -vsync passthrough -copyts \
   -filter_complex "sws_flags=+accurate_rnd+bitexact\;[0:s:0]scale" \
-  -c:v rawvideo
+  -c:v rawvideo -threads 1
 
 # Time-limited run with a sample that doesn't require seeking and
 # contains samples within the initial period.
@@ -73,7 +73,7 @@ fate-sub2video_time_limited: CMD = framecrc 
-auto_conversion_filters \
   -vsync passthrough -copyts \
   -t 15 \
   -filter_complex "sws_flags=+accurate_rnd+bitexact\;[0:s:0]scale" \
-  -c:v rawvideo
+  -c:v rawvideo -threads 1
 
 FATE_FFMPEG-$(call ALLYES, PCM_S16LE_DEMUXER PCM_S16LE_MUXER PCM_S16LE_DECODER 
PCM_S16LE_ENCODER) += fate-unknown_layout-pcm
 fate-unknown_layout-pcm: $(AREF)
@@ -170,7 +170,7 @@ fate-streamcopy: $(FATE_STREAMCOPY-yes)
 FATE_SAMPLES_FFMPEG-$(call ALLYES, MOV_DEMUXER MATROSKA_MUXER) += 
fate-rgb24-mkv
 fate-rgb24-mkv: $(SAMPLES)/qtrle/aletrek-rle.mov
 fate-rgb24-mkv: CMD = transcode "mov" $(TARGET_SAMPLES)/qtrle/aletrek-rle.mov\
-  matroska "-c:v rawvideo -pix_fmt rgb24 -allow_raw_vfw 1 
-frames:v 1"
+  matroska "-c:v rawvideo -threads 1 -pix_fmt rgb24 
-allow_raw_vfw 1 -frames:v 1"
 
 FATE_SAMPLES_FFMPEG-$(call ALLYES, AAC_DEMUXER MOV_MUXER) += 
fate-adtstoasc_ticket3715
 fate-adtstoasc_ticket3715: $(SAMPLES)/aac/foo.aac
-- 
1.8.3.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] IMF demuxer status

[Pierre-Anthony Lemieux]

Hi all,

I have posted v9 of the IMF demuxer patch. The small changes are the
result of my running the demuxer through valgrind and failing
individual heap allocation calls.

Outstanding issues (I know of):

- it was suggested that libuuid be used to parse UUIDs in the IMF CPL.
As detailed at [1], I feel libuuid is not a great match for the
specific IMF demuxer use case

- strong concerns were expressed that the same save_avio_options()
function is defined in HLS, DASH and (proposed) IMF demuxers. Happy to
refactor it to a common location. Where should that be?

Looking forward to next steps.

Best,

-- Pierre

[1] http://ffmpeg.org/pipermail/ffmpeg-devel/2021-December/289093.html

P.S.: Is there a way to instrument ffmpeg to programmatically fail
memory allocation functions?
___
ffmpeg-devel mailing list
ffmpeg-devel@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 v9 2/2] avformat/imf: Tests

[pal]

From: Pierre-Anthony Lemieux 

Signed-off-by: Pierre-Anthony Lemieux 
---

Notes:
Tests for the IMF demuxer.

 libavformat/Makefile|   1 +
 libavformat/tests/imf.c | 525 
 2 files changed, 526 insertions(+)
 create mode 100644 libavformat/tests/imf.c

diff --git a/libavformat/Makefile b/libavformat/Makefile
index 7f058f3ea0..533bb67f31 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -697,6 +697,7 @@ TESTPROGS-$(CONFIG_FFRTMPCRYPT_PROTOCOL) += rtmpdh
 TESTPROGS-$(CONFIG_MOV_MUXER)+= movenc
 TESTPROGS-$(CONFIG_NETWORK)  += noproxy
 TESTPROGS-$(CONFIG_SRTP) += srtp
+TESTPROGS-$(CONFIG_IMF_DEMUXER)  += imf
 
 TOOLS = aviocat \
 ismindex\
diff --git a/libavformat/tests/imf.c b/libavformat/tests/imf.c
new file mode 100644
index 00..02ec5030ad
--- /dev/null
+++ b/libavformat/tests/imf.c
@@ -0,0 +1,525 @@
+/*
+ * 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
+ */
+
+/*
+ *
+ * Copyright (c) Sandflow Consulting LLC
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *
+ * * Redistributions of source code must retain the above copyright notice, 
this
+ *   list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright notice,
+ *   this list of conditions and the following disclaimer in the documentation
+ *   and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/**
+ * Tests for IMF CPL and ASSETMAP processing
+ * 
+ * @author Valentin Noel
+ * @author Pierre-Anthony Lemieux
+ * @file
+ * @ingroup lavu_imf
+ */
+
+#include "libavformat/imf_cpl.c"
+#include "libavformat/imfdec.c"
+#include "libavformat/mxf.h"
+
+#include 
+
+const char *cpl_doc =
+"http://www.smpte-ra.org/schemas/2067-3/2016\"";
+" xmlns:cc=\"http://www.smpte-ra.org/schemas/2067-2/2016\"";
+" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\";>"
+"urn:uuid:8713c020-2489-45f5-a9f7-87be539e20b5"
+"2021-07-13T17:06:22Z"
+"FFMPEG"
+"FFMPEG sample content"
+""
+"  "
+"urn:uuid:8e097bb0-cff7-4969-a692-bad47bfb528f"
+"  "
+""
+"24000 1001"
+""
+""
+"urn:uuid:81fed4e5-9722-400a-b9d1-7f2bd21df4b6"
+""
+""
+"urn:uuid:16327185-9205-47ef-a17b-ee28df251db7"
+"urn:uuid:461f5424-8f6e-48a9-a385-5eda46fda381"
+""
+""
+"urn:uuid:ea3d0f23-55d6-4e03-86ec-cfe0666f0e6a"
+"24"
+""
+"LFOA"
+"5"
+""
+""
+""
+""
+""
+"urn:uuid:6ae100b0-92d1-41be-9321-85e0933dfc42"
+"urn:uuid:e8ef9653-565c-479c-8039-82d4547973c5"
+""
+""
+"urn:uuid:7d418acb-07a3-4e57-984c-b8ea2f7de4ec"
+"24"
+
"urn:uuid:f00e49a8-0dec-4e6c-95e7-078df988b751"
+"urn:uuid:6f768ca4-c89e-4dac-9056-a29425d40ba1"
+""
+""
+""
+""
+"urn:uuid:754dae53-c25f-4f3c-97e4-2bfe5463f83b"
+"urn:uuid:68e3fae5-d94b-44d2-92a6-b94877fbcdb5"
+""
+""
+"urn:uuid:61ce2a70-10a2-4521-850b-4218755ff3c9"
+"24"
+
"urn:uuid:f00e49a8-0dec-4e6c-95e7-078df988b751"
+"urn:uuid:381dadd2-061e-46cc-a63a-e3d58ce7f488"
+""
+""
+""
+""
+"urn:uuid:d29b3884-6633-4dad-9c67-7154af342bc6"
+"urn:uuid:6978c106-95bc-424b-a17

[FFmpeg-devel] [PATCH v9 1/2] avformat/imf: Demuxer

[pal]

From: Pierre-Anthony Lemieux 

Signed-off-by: Pierre-Anthony Lemieux 
---

Notes:
The IMF demuxer accepts as input an IMF CPL. The assets referenced by the 
CPL can be
contained in multiple deliveries, each defined by an ASSETMAP file:

ffmpeg -assetmaps ,,... -i 

If -assetmaps is not specified, FFMPEG looks for a file called ASSETMAP.xml 
in the same directory as the CPL.

EXAMPLE:
ffmpeg -i 
http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/CPL_f5095caa-f204-4e1c-8a84-7af48c7ae16b.xml
 out.mp4

The Interoperable Master Format (IMF) is a file-based media format for the
delivery and storage of professional audio-visual masters.
An IMF Composition consists of an XML playlist (the Composition Playlist)
and a collection of MXF files (the Track Files). The Composition Playlist 
(CPL)
assembles the Track Files onto a timeline, which consists of multiple 
tracks.
The location of the Track Files referenced by the Composition Playlist is 
stored
in one or more XML documents called Asset Maps. More details at 
https://www.imfug.com/explainer.
The IMF standard was first introduced in 2013 and is managed by the SMPTE.

CHANGE NOTES:

- fix leaks when head allocation fails

 MAINTAINERS  |   1 +
 configure|   3 +-
 doc/demuxers.texi|   6 +
 libavformat/Makefile |   1 +
 libavformat/allformats.c |   1 +
 libavformat/imf.h| 207 +
 libavformat/imf_cpl.c| 782 ++
 libavformat/imfdec.c | 892 +++
 8 files changed, 1892 insertions(+), 1 deletion(-)
 create mode 100644 libavformat/imf.h
 create mode 100644 libavformat/imf_cpl.c
 create mode 100644 libavformat/imfdec.c

diff --git a/MAINTAINERS b/MAINTAINERS
index dcac46003e..7a6972fe1a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -433,6 +433,7 @@ Muxers/Demuxers:
   idroqdec.cMike Melanson
   iff.c Jaikrishnan Menon
   img2*.c   Michael Niedermayer
+  imf*.cMarc-Antoine Arnaud, Pierre-Anthony 
Lemieux, Valentin Noël
   ipmovie.c Mike Melanson
   ircam*Paul B Mahol
   iss.c Stefan Gehrer
diff --git a/configure b/configure
index 04f319b197..4401069cb9 100755
--- a/configure
+++ b/configure
@@ -298,7 +298,7 @@ External library support:
   --enable-libxvid enable Xvid encoding via xvidcore,
native MPEG-4/Xvid encoder exists [no]
   --enable-libxml2 enable XML parsing using the C library libxml2, 
needed
-   for dash demuxing support [no]
+   for dash and imf demuxing support [no]
   --enable-libzimg enable z.lib, needed for zscale filter [no]
   --enable-libzmq  enable message passing via libzmq [no]
   --enable-libzvbi enable teletext support via libzvbi [no]
@@ -3400,6 +3400,7 @@ hls_muxer_select="mpegts_muxer"
 hls_muxer_suggest="gcrypt openssl"
 image2_alias_pix_demuxer_select="image2_demuxer"
 image2_brender_pix_demuxer_select="image2_demuxer"
+imf_demuxer_deps="libxml2"
 ipod_muxer_select="mov_muxer"
 ismv_muxer_select="mov_muxer"
 ivf_muxer_select="av1_metadata_bsf vp9_superframe_bsf"
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index cab8a7072c..655704d2c4 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -267,6 +267,12 @@ which streams to actually receive.
 Each stream mirrors the @code{id} and @code{bandwidth} properties from the
 @code{} as metadata keys named "id" and "variant_bitrate" 
respectively.
 
+@section imf
+
+Interoperable Master Format demuxer.
+
+This demuxer presents audio and video streams found in an IMF Composition.
+
 @section flv, live_flv, kux
 
 Adobe Flash Video Format demuxer.
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 2b5caf9d33..7f058f3ea0 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -285,6 +285,7 @@ OBJS-$(CONFIG_IMAGE_WEBP_PIPE_DEMUXER)+= img2dec.o 
img2.o
 OBJS-$(CONFIG_IMAGE_XBM_PIPE_DEMUXER) += img2dec.o img2.o
 OBJS-$(CONFIG_IMAGE_XPM_PIPE_DEMUXER) += img2dec.o img2.o
 OBJS-$(CONFIG_IMAGE_XWD_PIPE_DEMUXER) += img2dec.o img2.o
+OBJS-$(CONFIG_IMF_DEMUXER)   += imfdec.o imf_cpl.o
 OBJS-$(CONFIG_INGENIENT_DEMUXER) += ingenientdec.o rawdec.o
 OBJS-$(CONFIG_IPMOVIE_DEMUXER)   += ipmovie.o
 OBJS-$(CONFIG_IPU_DEMUXER)   += ipudec.o rawdec.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 1054ac9667..f680616cdd 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -212,6 +212,7 @@ extern const AVInputFormat  ff_image2pipe_demuxer;
 extern const AVOutputFormat ff_image2pipe_muxer;
 extern const AVInputFormat  ff_image2_alias_pix_de

[FFmpeg-devel] [PATCH] accelerate h2645 nalu start code finding

[Lingjiang Fang]

---
 libavcodec/h2645_parse.c | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

refer from webrtc h264 parser

diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
index 6fbe97ad4a..e372d2a27b 100644
--- a/libavcodec/h2645_parse.c
+++ b/libavcodec/h2645_parse.c
@@ -330,16 +330,25 @@ static int h264_parse_nal_header(H2645NAL *nal, void 
*logctx)
 static int find_next_start_code(const uint8_t *buf, const uint8_t *next_avc)
 {
 int i = 0;
+const uint8_t *end = NULL;
 
 if (buf + 3 >= next_avc)
 return next_avc - buf;
 
-while (buf + i + 3 < next_avc) {
-if (buf[i] == 0 && buf[i + 1] == 0 && buf[i + 2] == 1)
-break;
-i++;
+end = next_avc - 3;
+while (buf + i < end) {
+if (buf[i + 2] > 1) {
+i += 3;
+} else if (buf[i + 2] == 1) {
+if (buf[i + 1] == 0 && buf[i] == 0) {
+break;
+}
+i += 3;
+} else {
+++i;
+}
 }
-return i + 3;
+return (buf + i + 3 > next_avc)? next_avc - buf : i + 3;
 }
 
 static void alloc_rbsp_buffer(H2645RBSP *rbsp, unsigned int size, int use_ref)
-- 
2.29.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 v3 1/3] avfilter/x86/vf_exposure: add x86 SIMD optimization

[Wu, Jianhua]

Ping
Wu, Jianhua:
> Ping.
> > From: Wu, Jianhua 
> > Sent: Monday, November 22, 2021 4:09 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Wu, Jianhua 
> > Subject: [PATCH v3 1/3] avfilter/x86/vf_exposure: add x86 SIMD
> > optimization
> >
> > Performance data(Less is better):
> > exposure_c:857394
> > exposure_sse:  327589
> >
> > Signed-off-by: Wu Jianhua 
> > ---
> >  libavfilter/exposure.h | 36 +++
> >  libavfilter/vf_exposure.c  | 36 +--
> >  libavfilter/x86/Makefile   |  2 ++
> >  libavfilter/x86/vf_exposure.asm| 55
> > ++
> >  libavfilter/x86/vf_exposure_init.c | 36 +++
> >  5 files changed, 147 insertions(+), 18 deletions(-)  create mode
> > 100644 libavfilter/exposure.h  create mode 100644
> > libavfilter/x86/vf_exposure.asm create mode 100644
> > libavfilter/x86/vf_exposure_init.c
> >
> > diff --git a/libavfilter/exposure.h b/libavfilter/exposure.h new file
> > mode
> > 100644 index 00..e76a517826
> > --- /dev/null
> > +++ b/libavfilter/exposure.h
> > @@ -0,0 +1,36 @@
> > +/*
> > + * 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  */
> > +
> > +#ifndef AVFILTER_EXPOSURE_H
> > +#define AVFILTER_EXPOSURE_H
> > +#include "avfilter.h"
> > +
> > +typedef struct ExposureContext {
> > +const AVClass *class;
> > +
> > +float exposure;
> > +float black;
> > +float scale;
> > +
> > +void (*exposure_func)(float *ptr, int length, float black, float
> > +scale); } ExposureContext;
> > +
> > +void ff_exposure_init(ExposureContext *s); void
> > +ff_exposure_init_x86(ExposureContext *s);
> > +
> > +#endif
> > diff --git a/libavfilter/vf_exposure.c b/libavfilter/vf_exposure.c
> > index
> > 108fba7930..045ae710d3 100644
> > --- a/libavfilter/vf_exposure.c
> > +++ b/libavfilter/vf_exposure.c
> > @@ -26,23 +26,20 @@
> >  #include "formats.h"
> >  #include "internal.h"
> >  #include "video.h"
> > +#include "exposure.h"
> >
> > -typedef struct ExposureContext {
> > -const AVClass *class;
> > -
> > -float exposure;
> > -float black;
> > +static void exposure_c(float *ptr, int length, float black, float
> > +scale) {
> > +int i;
> >
> > -float scale;
> > -int (*do_slice)(AVFilterContext *s, void *arg,
> > -int jobnr, int nb_jobs);
> > -} ExposureContext;
> > +for (i = 0; i < length; i++)
> > +ptr[i] = (ptr[i] - black) * scale; }
> >
> >  static int exposure_slice(AVFilterContext *ctx, void *arg, int jobnr,
> > int
> > nb_jobs)  {
> >  ExposureContext *s = ctx->priv;
> >  AVFrame *frame = arg;
> > -const int width = frame->width;
> >  const int height = frame->height;
> >  const int slice_start = (height * jobnr) / nb_jobs;
> >  const int slice_end = (height * (jobnr + 1)) / nb_jobs; @@ -52,24
> > +49,27 @@ static int exposure_slice(AVFilterContext *ctx, void *arg,
> > int jobnr, int nb_job
> >  for (int p = 0; p < 3; p++) {
> >  const int linesize = frame->linesize[p] / 4;
> >  float *ptr = (float *)frame->data[p] + slice_start * linesize;
> > -for (int y = slice_start; y < slice_end; y++) {
> > -for (int x = 0; x < width; x++)
> > -ptr[x] = (ptr[x] - black) * scale;
> > -
> > -ptr += linesize;
> > -}
> > +s->exposure_func(ptr, linesize * (slice_end - slice_start),
> > + black, scale);
> >  }
> >
> >  return 0;
> >  }
> >
> > +void ff_exposure_init(ExposureContext *s) {
> > +s->exposure_func = exposure_c;
> > +
> > +if (ARCH_X86)
> > +ff_exposure_init_x86(s);
> > +}
> > +
> >  static int filter_frame(AVFilterLink *inlink, AVFrame *frame)  {
> >  AVFilterContext *ctx = inlink->dst;
> >  ExposureContext *s = ctx->priv;
> >
> >  s->scale = 1.f / (exp2f(-s->exposure) - s->black);
> > -ff_filter_execute(ctx, s->do_slice, frame, NULL,
> > +ff_filter_execute(ctx, exposure_slice, frame, NULL,
> >FFMIN(frame->height,
> > ff_filter_get_nb_threads(ctx)));
> >
> >  return ff_filter_frame(ctx->outputs[0], frame); @@ -80,7 +80,7 @@
> > static av_cold int config_input(AVFilterLink *inlink)
> > 

Re: [FFmpeg-devel] [PATCH 4/5] avcodec/rawenc: suppport frame thread for rawvideo

[lance . lmwang]

On Thu, Dec 09, 2021 at 09:19:42AM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang 
> 
> Signed-off-by: Limin Wang 
> ---
>  libavcodec/rawenc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/rawenc.c b/libavcodec/rawenc.c
> index 7e15084..561d992 100644
> --- a/libavcodec/rawenc.c
> +++ b/libavcodec/rawenc.c
> @@ -85,7 +85,7 @@ const AVCodec ff_rawvideo_encoder = {
>  .long_name  = NULL_IF_CONFIG_SMALL("raw video"),
>  .type   = AVMEDIA_TYPE_VIDEO,
>  .id = AV_CODEC_ID_RAWVIDEO,
> -.capabilities   = AV_CODEC_CAP_DR1,
> +.capabilities   = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
>  .init   = raw_encode_init,
>  .encode2= raw_encode,
>  .caps_internal  = FF_CODEC_CAP_INIT_THREADSAFE,
> -- 
> 1.8.3.1
> 

In fact, I want to keep default thread to 1 which can keep same behavior as
before. I'm not sure where is better place to set it?  Or I had to change
some test case for rawvideo in fate to threads 1.

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

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

[FFmpeg-devel] [PATCH 5/5] avcodec/v210enc: suppport frame thread for v210

[lance . lmwang]

From: Limin Wang 

Signed-off-by: Limin Wang 
---
 libavcodec/v210enc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/v210enc.c b/libavcodec/v210enc.c
index 22875be..16c4f82 100644
--- a/libavcodec/v210enc.c
+++ b/libavcodec/v210enc.c
@@ -156,7 +156,7 @@ const AVCodec ff_v210_encoder = {
 .long_name  = NULL_IF_CONFIG_SMALL("Uncompressed 4:2:2 10-bit"),
 .type   = AVMEDIA_TYPE_VIDEO,
 .id = AV_CODEC_ID_V210,
-.capabilities   = AV_CODEC_CAP_DR1,
+.capabilities   = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
 .priv_data_size = sizeof(V210EncContext),
 .init   = encode_init,
 .encode2= encode_frame,
-- 
1.8.3.1

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

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

[FFmpeg-devel] [PATCH 4/5] avcodec/rawenc: suppport frame thread for rawvideo

[lance . lmwang]

From: Limin Wang 

Signed-off-by: Limin Wang 
---
 libavcodec/rawenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/rawenc.c b/libavcodec/rawenc.c
index 7e15084..561d992 100644
--- a/libavcodec/rawenc.c
+++ b/libavcodec/rawenc.c
@@ -85,7 +85,7 @@ const AVCodec ff_rawvideo_encoder = {
 .long_name  = NULL_IF_CONFIG_SMALL("raw video"),
 .type   = AVMEDIA_TYPE_VIDEO,
 .id = AV_CODEC_ID_RAWVIDEO,
-.capabilities   = AV_CODEC_CAP_DR1,
+.capabilities   = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
 .init   = raw_encode_init,
 .encode2= raw_encode,
 .caps_internal  = FF_CODEC_CAP_INIT_THREADSAFE,
-- 
1.8.3.1

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

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

[FFmpeg-devel] [PATCH 3/5] avfilter/dnn: fix the return value of async_thread_routine

[lance . lmwang]

From: Limin Wang 

Signed-off-by: Limin Wang 
---
 libavfilter/dnn/dnn_backend_common.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/libavfilter/dnn/dnn_backend_common.c 
b/libavfilter/dnn/dnn_backend_common.c
index 6a9c4cc..8c020e5 100644
--- a/libavfilter/dnn/dnn_backend_common.c
+++ b/libavfilter/dnn/dnn_backend_common.c
@@ -83,10 +83,13 @@ static void *async_thread_routine(void *args)
 void *request = async_module->args;
 
 if (async_module->start_inference(request) != DNN_SUCCESS) {
-return DNN_ASYNC_FAIL;
+pthread_exit((void*)DNN_ASYNC_FAIL);
+return NULL;
 }
 async_module->callback(request);
-return DNN_ASYNC_SUCCESS;
+
+pthread_exit((void*)DNN_ASYNC_SUCCESS);
+return NULL;
 }
 
 DNNReturnType ff_dnn_async_module_cleanup(DNNAsyncExecModule *async_module)
-- 
1.8.3.1

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

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

[FFmpeg-devel] [PATCH 2/5] avfilter/af_astats: improve options descriptions

[lance . lmwang]

From: Limin Wang 

Signed-off-by: Limin Wang 
---
 libavfilter/af_astats.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavfilter/af_astats.c b/libavfilter/af_astats.c
index d0810b5..776a8aa 100644
--- a/libavfilter/af_astats.c
+++ b/libavfilter/af_astats.c
@@ -114,8 +114,8 @@ typedef struct AudioStatsContext {
 static const AVOption astats_options[] = {
 { "length", "set the window length", OFFSET(time_constant), 
AV_OPT_TYPE_DOUBLE, {.dbl=.05}, 0, 10, FLAGS },
 { "metadata", "inject metadata in the filtergraph", OFFSET(metadata), 
AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1, FLAGS },
-{ "reset", "recalculate stats after this many frames", 
OFFSET(reset_count), AV_OPT_TYPE_INT, {.i64=0}, 0, INT_MAX, FLAGS },
-{ "measure_perchannel", "only measure_perchannel these per-channel 
statistics", OFFSET(measure_perchannel), AV_OPT_TYPE_FLAGS, {.i64=MEASURE_ALL}, 
0, UINT_MAX, FLAGS, "measure" },
+{ "reset", "Set number of frame after which stats are going to be 
recalculated", OFFSET(reset_count), AV_OPT_TYPE_INT, {.i64=0}, 0, INT_MAX, 
FLAGS },
+{ "measure_perchannel", "Select the entries which need to be measured per 
channel", OFFSET(measure_perchannel), AV_OPT_TYPE_FLAGS, {.i64=MEASURE_ALL}, 0, 
UINT_MAX, FLAGS, "measure" },
   { "none"  , "", 0, AV_OPT_TYPE_CONST, 
{.i64=MEASURE_NONE}, 0, 0, FLAGS, "measure" },
   { "all"   , "", 0, AV_OPT_TYPE_CONST, 
{.i64=MEASURE_ALL }, 0, 0, FLAGS, "measure" },
   { "DC_offset" , "", 0, AV_OPT_TYPE_CONST, 
{.i64=MEASURE_DC_OFFSET   }, 0, 0, FLAGS, "measure" },
@@ -143,7 +143,7 @@ static const AVOption astats_options[] = {
   { "Number_of_NaNs", "", 0, AV_OPT_TYPE_CONST, 
{.i64=MEASURE_NUMBER_OF_NANS  }, 0, 0, FLAGS, "measure" },
   { "Number_of_Infs", "", 0, AV_OPT_TYPE_CONST, 
{.i64=MEASURE_NUMBER_OF_INFS  }, 0, 0, FLAGS, "measure" },
   { "Number_of_denormals"   , "", 0, AV_OPT_TYPE_CONST, 
{.i64=MEASURE_NUMBER_OF_DENORMALS }, 0, 0, FLAGS, "measure" },
-{ "measure_overall", "only measure_perchannel these overall statistics", 
OFFSET(measure_overall), AV_OPT_TYPE_FLAGS, {.i64=MEASURE_ALL}, 0, UINT_MAX, 
FLAGS, "measure" },
+{ "measure_overall", "Select the entries which need to be measured 
overall", OFFSET(measure_overall), AV_OPT_TYPE_FLAGS, {.i64=MEASURE_ALL}, 0, 
UINT_MAX, FLAGS, "measure" },
 { NULL }
 };
 
-- 
1.8.3.1

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

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

[FFmpeg-devel] [PATCH 1/5] avformat/rtpdec_rfc4175: cosmetic changes

[lance . lmwang]

From: Limin Wang 

Signed-off-by: Limin Wang 
---
 libavformat/rtpdec_rfc4175.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/libavformat/rtpdec_rfc4175.c b/libavformat/rtpdec_rfc4175.c
index 7feefd2..a66e00d 100644
--- a/libavformat/rtpdec_rfc4175.c
+++ b/libavformat/rtpdec_rfc4175.c
@@ -195,17 +195,17 @@ static int rfc4175_parse_sdp_line(AVFormatContext *s, int 
st_index,
 static int rfc4175_finalize_packet(PayloadContext *data, AVPacket *pkt,
int stream_index)
 {
-   int ret;
+int ret;
 
-   pkt->stream_index = stream_index;
-   ret = av_packet_from_data(pkt, data->frame, data->frame_size);
-   if (ret < 0) {
-   av_freep(&data->frame);
-   }
+pkt->stream_index = stream_index;
+ret = av_packet_from_data(pkt, data->frame, data->frame_size);
+if (ret < 0) {
+av_freep(&data->frame);
+}
 
-   data->frame = NULL;
+data->frame = NULL;
 
-   return ret;
+return ret;
 }
 
 static int rfc4175_handle_packet(AVFormatContext *ctx, PayloadContext *data,
-- 
1.8.3.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 6/6] avcodec/movtextdec: Fix wrong error code

[Andreas Rheinhardt]

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

diff --git a/libavcodec/movtextdec.c b/libavcodec/movtextdec.c
index 63709eb54b..825632ca9b 100644
--- a/libavcodec/movtextdec.c
+++ b/libavcodec/movtextdec.c
@@ -294,7 +294,7 @@ static int decode_styl(const uint8_t *tsmb, MovTextContext 
*m, uint64_t size)
 if (style->end < style->start ||
 (i && style->start < m->s[i - 1].end)) {
 mov_text_cleanup(m);
-return AVERROR(ENOMEM);
+return AVERROR_INVALIDDATA;
 }
 if (style->start == style->end) {
 /* Skip this style as it applies to no character */
-- 
2.32.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 5/6] avcodec/movtextdec: Switch to pointer comparisons and bytestream API

[Andreas Rheinhardt]

Improves readability and avoids a redundant index variable
that was mistakenly called "tracksize".

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/movtextdec.c | 36 ++--
 1 file changed, 14 insertions(+), 22 deletions(-)

diff --git a/libavcodec/movtextdec.c b/libavcodec/movtextdec.c
index 967c0adf7f..63709eb54b 100644
--- a/libavcodec/movtextdec.c
+++ b/libavcodec/movtextdec.c
@@ -102,7 +102,6 @@ typedef struct {
 MovTextDefault d;
 uint8_t box_flags;
 uint16_t style_entries, ftab_entries;
-uint64_t tracksize;
 int readorder;
 int frame_width;
 int frame_height;
@@ -481,9 +480,7 @@ static int mov_text_decode_frame(AVCodecContext *avctx,
 int ret;
 AVBPrint buf;
 const char *ptr = avpkt->data, *end;
-int text_length, tsmb_type, ret_tsmb;
-uint64_t tsmb_size;
-const uint8_t *tsmb;
+int text_length;
 size_t i;
 
 if (!ptr || avpkt->size < 2)
@@ -510,27 +507,23 @@ static int mov_text_decode_frame(AVCodecContext *avctx,
 
 mov_text_cleanup(m);
 
-tsmb_size = 0;
-m->tracksize = 2 + text_length;
 m->style_entries = 0;
 m->box_flags = 0;
 // Note that the spec recommends lines be no longer than 2048 characters.
 av_bprint_init(&buf, 0, AV_BPRINT_SIZE_UNLIMITED);
-if (text_length + 2 != avpkt->size) {
-while (m->tracksize + 8 <= avpkt->size) {
-int size_var;
-// A box is a minimum of 8 bytes.
-tsmb = ptr + m->tracksize - 2;
-tsmb_size = AV_RB32(tsmb);
-tsmb += 4;
-tsmb_type = AV_RB32(tsmb);
-tsmb += 4;
+if (text_length + 2 < avpkt->size) {
+const uint8_t *tsmb = end;
+const uint8_t *const tsmb_end = avpkt->data + avpkt->size;
+// A box is a minimum of 8 bytes.
+while (tsmb_end - tsmb >= 8) {
+uint64_t tsmb_size = bytestream_get_be32(&tsmb);
+uint32_t tsmb_type = bytestream_get_be32(&tsmb);
+int size_var, ret_tsmb;
 
 if (tsmb_size == 1) {
-if (m->tracksize + 16 > avpkt->size)
+if (tsmb_end - tsmb < 8)
 break;
-tsmb_size = AV_RB64(tsmb);
-tsmb += 8;
+tsmb_size = bytestream_get_be64(&tsmb);
 size_var = 16;
 } else
 size_var = 8;
@@ -540,13 +533,11 @@ static int mov_text_decode_frame(AVCodecContext *avctx,
 av_log(avctx, AV_LOG_ERROR, "tsmb_size invalid\n");
 return AVERROR_INVALIDDATA;
 }
+tsmb_size -= size_var;
 
-if (tsmb_size > avpkt->size - m->tracksize)
+if (tsmb_end - tsmb < tsmb_size)
 break;
 
-m->tracksize += tsmb_size;
-tsmb_size -= size_var;
-
 for (i = 0; i < box_count; i++) {
 if (tsmb_type == box_types[i].type) {
 if (tsmb_size < box_types[i].base_size)
@@ -556,6 +547,7 @@ static int mov_text_decode_frame(AVCodecContext *avctx,
 break;
 }
 }
+tsmb += tsmb_size;
 }
 text_to_ass(&buf, ptr, end, avctx);
 mov_text_cleanup(m);
-- 
2.32.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 4/6] avcodec/movtextdec: Redo TextSampleModifierBox size checks

[Andreas Rheinhardt]

The current checks just check whether the boxes fit into the remaining
size of the packet instead of whether they actually fit into the box
size. This has been changed; part of this change is to pass the size of
the box (minus the box header) as parameter instead of a pointer to
the AVPacket by which the box parsing function is supposed to
recalculate whether enough data is available.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/movtextdec.c | 28 +++-
 1 file changed, 15 insertions(+), 13 deletions(-)

diff --git a/libavcodec/movtextdec.c b/libavcodec/movtextdec.c
index 001df6a5a1..967c0adf7f 100644
--- a/libavcodec/movtextdec.c
+++ b/libavcodec/movtextdec.c
@@ -103,7 +103,6 @@ typedef struct {
 uint8_t box_flags;
 uint16_t style_entries, ftab_entries;
 uint64_t tracksize;
-int size_var;
 int readorder;
 int frame_width;
 int frame_height;
@@ -112,7 +111,7 @@ typedef struct {
 typedef struct {
 uint32_t type;
 unsigned base_size;
-int (*decode)(const uint8_t *tsmb, MovTextContext *m, const AVPacket 
*avpkt);
+int (*decode)(const uint8_t *tsmb, MovTextContext *m, uint64_t size);
 } Box;
 
 static void mov_text_cleanup(MovTextContext *m)
@@ -241,14 +240,14 @@ static int mov_text_tx3g(AVCodecContext *avctx, 
MovTextContext *m)
 return 0;
 }
 
-static int decode_twrp(const uint8_t *tsmb, MovTextContext *m, const AVPacket 
*avpkt)
+static int decode_twrp(const uint8_t *tsmb, MovTextContext *m, uint64_t size)
 {
 m->box_flags |= TWRP_BOX;
 m->w.wrap_flag = bytestream_get_byte(&tsmb);
 return 0;
 }
 
-static int decode_hlit(const uint8_t *tsmb, MovTextContext *m, const AVPacket 
*avpkt)
+static int decode_hlit(const uint8_t *tsmb, MovTextContext *m, uint64_t size)
 {
 m->box_flags |= HLIT_BOX;
 m->h.hlit_start = bytestream_get_be16(&tsmb);
@@ -256,7 +255,7 @@ static int decode_hlit(const uint8_t *tsmb, MovTextContext 
*m, const AVPacket *a
 return 0;
 }
 
-static int decode_hclr(const uint8_t *tsmb, MovTextContext *m, const AVPacket 
*avpkt)
+static int decode_hclr(const uint8_t *tsmb, MovTextContext *m, uint64_t size)
 {
 m->box_flags |= HCLR_BOX;
 bytestream_get_buffer(&tsmb, m->c.hlit_color, 4);
@@ -271,14 +270,14 @@ static int styles_equivalent(const StyleBox *a, const 
StyleBox *b)
 #undef CMP
 }
 
-static int decode_styl(const uint8_t *tsmb, MovTextContext *m, const AVPacket 
*avpkt)
+static int decode_styl(const uint8_t *tsmb, MovTextContext *m, uint64_t size)
 {
 int i;
 int style_entries = bytestream_get_be16(&tsmb);
 StyleBox *tmp;
 
 // A single style record is of length 12 bytes.
-if (m->tracksize + m->size_var + 2 + style_entries * 12 > avpkt->size)
+if (2 + style_entries * 12 > size)
 return -1;
 
 tmp = av_realloc_array(m->s, style_entries, sizeof(*m->s));
@@ -519,6 +518,7 @@ static int mov_text_decode_frame(AVCodecContext *avctx,
 av_bprint_init(&buf, 0, AV_BPRINT_SIZE_UNLIMITED);
 if (text_length + 2 != avpkt->size) {
 while (m->tracksize + 8 <= avpkt->size) {
+int size_var;
 // A box is a minimum of 8 bytes.
 tsmb = ptr + m->tracksize - 2;
 tsmb_size = AV_RB32(tsmb);
@@ -531,12 +531,12 @@ static int mov_text_decode_frame(AVCodecContext *avctx,
 break;
 tsmb_size = AV_RB64(tsmb);
 tsmb += 8;
-m->size_var = 16;
+size_var = 16;
 } else
-m->size_var = 8;
+size_var = 8;
 //size_var is equal to 8 or 16 depending on the size of box
 
-if (tsmb_size < m->size_var) {
+if (tsmb_size < size_var) {
 av_log(avctx, AV_LOG_ERROR, "tsmb_size invalid\n");
 return AVERROR_INVALIDDATA;
 }
@@ -544,16 +544,18 @@ static int mov_text_decode_frame(AVCodecContext *avctx,
 if (tsmb_size > avpkt->size - m->tracksize)
 break;
 
+m->tracksize += tsmb_size;
+tsmb_size -= size_var;
+
 for (i = 0; i < box_count; i++) {
 if (tsmb_type == box_types[i].type) {
-if (m->tracksize + m->size_var + box_types[i].base_size > 
avpkt->size)
+if (tsmb_size < box_types[i].base_size)
 break;
-ret_tsmb = box_types[i].decode(tsmb, m, avpkt);
+ret_tsmb = box_types[i].decode(tsmb, m, tsmb_size);
 if (ret_tsmb == -1)
 break;
 }
 }
-m->tracksize = m->tracksize + tsmb_size;
 }
 text_to_ass(&buf, ptr, end, avctx);
 mov_text_cleanup(m);
-- 
2.32.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-devel] [PATCH 3/6] avcodec/movtextdec: Use const where appropriate

[Andreas Rheinhardt]

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

diff --git a/libavcodec/movtextdec.c b/libavcodec/movtextdec.c
index 5083308d58..001df6a5a1 100644
--- a/libavcodec/movtextdec.c
+++ b/libavcodec/movtextdec.c
@@ -481,8 +481,7 @@ static int mov_text_decode_frame(AVCodecContext *avctx,
 MovTextContext *m = avctx->priv_data;
 int ret;
 AVBPrint buf;
-char *ptr = avpkt->data;
-char *end;
+const char *ptr = avpkt->data, *end;
 int text_length, tsmb_type, ret_tsmb;
 uint64_t tsmb_size;
 const uint8_t *tsmb;
-- 
2.32.0

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

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

[FFmpeg-devel] [PATCH 2/6] avcodec/movtextdec: Improve size check

[Andreas Rheinhardt]

Signed-off-by: Andreas Rheinhardt 
---
The error checks here are btw a bit inconsistent: Most errors only lead
to a break; in case of errors from parsing the boxes this just ends
the box-parsing for-loop, not the outer while loop (and is therefore
actually redundant, because for each type there is at most one 
corresponding Box entry for parsing). Yet this is different.

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

diff --git a/libavcodec/movtextdec.c b/libavcodec/movtextdec.c
index 8dd571d64c..5083308d58 100644
--- a/libavcodec/movtextdec.c
+++ b/libavcodec/movtextdec.c
@@ -537,8 +537,8 @@ static int mov_text_decode_frame(AVCodecContext *avctx,
 m->size_var = 8;
 //size_var is equal to 8 or 16 depending on the size of box
 
-if (tsmb_size == 0) {
-av_log(avctx, AV_LOG_ERROR, "tsmb_size is 0\n");
+if (tsmb_size < m->size_var) {
+av_log(avctx, AV_LOG_ERROR, "tsmb_size invalid\n");
 return AVERROR_INVALIDDATA;
 }
 
-- 
2.32.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/6] avcodec/movtextdec: Switch to smaller type

[Andreas Rheinhardt]

The base size of a box refers to the size the box has in a file,
not in memory; so size_t is not their natural type. Therefore use
a plain unsigned which is smaller on 64bit systems and still big
enough to represent any conceivable base size.

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

diff --git a/libavcodec/movtextdec.c b/libavcodec/movtextdec.c
index b0c54bf1d0..8dd571d64c 100644
--- a/libavcodec/movtextdec.c
+++ b/libavcodec/movtextdec.c
@@ -111,7 +111,7 @@ typedef struct {
 
 typedef struct {
 uint32_t type;
-size_t base_size;
+unsigned base_size;
 int (*decode)(const uint8_t *tsmb, MovTextContext *m, const AVPacket 
*avpkt);
 } Box;
 
-- 
2.32.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 000/279] New channel layout API

[Paul B Mahol]

On Wed, Dec 8, 2021 at 4:09 PM Nicolas George  wrote:

> Anton Khirnov (12021-12-08):
> > I have no idea what you mean, the CUSTOM order can have any channel at
> > any location. This was true in all versions of this API back to 2013.
>
> Ok, my memories were muddy, now I remember better: it is possible, but
> without (2) and (3) it is unusable: there is no point in having two LFE
> channels if the user cannot specify "the second one" or know which one
> is which.
>
> > Multiplexing multiple streams into a single AVFrame is not a valid use
> > case. Just use multiple streams.
>
> We get to decide what is a valid use case and what is not. And in this
> case, since the devices and filter I quoted already behave like that, I
> posit that it IS a valid use case. Therefore, this new API must be
> capable of handling them.
>

Flawed logic.

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

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

Re: [FFmpeg-devel] [PATCH] libavdevice/avfoundation.m: use AudioConvert, extend supported formats

[Romain Beauxis]

> On Dec 7, 2021, at 7:21 AM, Thilo Borgmann  wrote:
> 
> Hi,
> 
> will look at this soon (tm), ping me if I don‘t. 

Great, thank you!

Would it be a good use of your time to send the two other patches that I have 
pending as well?

— Romain
___
ffmpeg-devel mailing list
ffmpeg-devel@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 000/279] New channel layout API

[Nicolas George]

Anton Khirnov (12021-12-08):
> I have no idea what you mean, the CUSTOM order can have any channel at
> any location. This was true in all versions of this API back to 2013.

Ok, my memories were muddy, now I remember better: it is possible, but
without (2) and (3) it is unusable: there is no point in having two LFE
channels if the user cannot specify "the second one" or know which one
is which.

> Multiplexing multiple streams into a single AVFrame is not a valid use
> case. Just use multiple streams.

We get to decide what is a valid use case and what is not. And in this
case, since the devices and filter I quoted already behave like that, I
posit that it IS a valid use case. Therefore, this new API must be
capable of handling them.

Regards,

-- 
  Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@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 000/279] New channel layout API

[Nicolas George]

James Almer (12021-12-08):
> What is wrong with it? All the functions returning a string in this API use
> the same signature. You pass it a pre-allocated buffer and it's filled with
> the string, truncating it if there's not enough space and letting the user
> know about it.
> I recall you were against dynamic allocation of the string, which the user
> then had to free, so this was the alternative.

There is nothing wrong with it, just as there is nothing wrong with
wearing pelts and a loincloth, but modern clothes are much more
comfortable.

In this case, there is a little usability issue: this description is
almost always very short but can be arbitrarily long, handling that
properly in the caller is very annoying: start with a small buffer on
the stack, try the conversion, if it fails start allocating a bigger
buffer on the heap, etc.

> I could make it use a user provided AVBprint buffer instead of using one
> internally, if you think that's better, but since you planned to replace
> that with AVWriter i figured using AVBprint in the signature would mean an
> eventual deprecation and removal.

We are on the same page on this.

A memory allocation would be a big no here, because it can happen once
every frame. We have implemented pools for frames and buffers, we do
consider once-per-frame to be frequent enough to warrant code to avoid
allocations.

My preferred outcome would be that we apply AVWriter before this series,
and using it here. The idea would be to start using AVWriter everywhere
we return some kind of string: AVWriter in one or two places is crap,
but the more we use it, the more its benefits outweigh the costs.

I will start a new discussion on string API soon, and
since we do not really disagree here but the rest will take
some time, we can continue discussing this later.

Regards,

-- 
  Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@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 001/279] Add a new channel layout API

[Lynne]

8 Dec 2021, 14:10 by h.lepp...@gmail.com:

> On Wed, Dec 8, 2021 at 1:54 PM Lynne  wrote:
>
>>
>> 8 Dec 2021, 13:19 by an...@khirnov.net:
>>
>> > Quoting Marton Balint (2021-12-08 11:55:37)
>> >
>> >>
>> >>
>> >> On Wed, 8 Dec 2021, Lynne wrote:
>> >>
>> >> > 8 Dec 2021, 11:06 by c...@passwd.hu:
>> >> >
>> >> >>
>> >> >>
>> >> >> On Wed, 8 Dec 2021, Lynne wrote:
>> >> >>
>> >> >>> 8 Dec 2021, 10:22 by h.lepp...@gmail.com:
>> >> >>>
>> >>  On Wed, Dec 8, 2021 at 10:14 AM Lynne  wrote:
>> >> 
>> >> >
>> >> > 8 Dec 2021, 02:06 by jamr...@gmail.com:
>> >> >
>> >> >>
>> >> >> +enum AVChannel {
>> >> >> +///< Invalid channel index
>> >> >> +AV_CHAN_NONE = -1,
>> >> >> +AV_CHAN_FRONT_LEFT,
>> >> >>
>> >> >
>> >> > No, not the pixfmt mistake again. Set AV_CHAN_NONE to 0,
>> >> > the rest can follow. Or keep AV_CHAN_NONE to -1
>> >> > and add a new AV_CHAN_UNSPECIFIED as 0.
>> >> >
>> >> 
>> >>  Care to elaborate on the reasons of this opinion? Using -1 as invalid
>> >>  and 0...x as valid entries seems quite reasonable to me.
>> >> 
>> >> >>>
>> >> >>> Zero-initialization. I've had issues in the past telling
>> >> >>> YUV420P from .
>> >> >>>
>> >> >>
>> >> >> It is convenient to be able to set the channel layout mask by a simple 
>> >> >> byte shift of the ID-s.
>> >> >>
>> >> >> AV_CH_FRONT_LEFT = 1 << AV_CHAN_FRONT_LEFT.
>> >> >>
>> >> >> So I'd say that is the reason that it is designed that way, because 
>> >> >> this way existing channel layout masks can be kept without breaking 
>> >> >> ABI.
>> >> >>
>> >> >
>> >> > Those can be set with offsets, e.g.
>> >> > AV_CH_FRONT_LEFT = 1 << (AV_CHAN_FRONT_LEFT - 2).
>> >>
>> >> Well, I find this less fortunate then the need to initialize NONE to -1...
>> >>
>> >> > I'd like to not have weird values in enums because the old
>> >> > API, just being deprecated, must have its way and can't deal
>> >> > with an offset.
>> >>
>> >> AV_CH_FRONT_LEFT and similar is not deprecated, these are still used for
>> >> the native channel order which is still using a mask.
>> >>
>> >
>> > Yes, the direct mapping between channel indices and WAVEFORMATEXTENSIBLE
>> > values is a design goal here, just as it was in the old API.
>> >
>> > I also belive that the initialization issue of pixel/sample formats is
>> > less of a problem here, since you rarely need to store actual channel
>> > ids. So IMO retaining channel index compatibility is more important.
>> >
>>
>> That's not a goal, it's anti-goal, and a cause for hysterical raisin
>> picking in the future.
>>
>
> The old AV_CH_* values are not chosen randomly, they match  the
> WAVEFORMAT channel ordering and bit position, which a lot of formats
> and system use to identify channel layouts - and will continue to do
> so in the future.
> So its hardly just compatibility with FFmpeg from yester-year thats
> being considered here, but the multimedia infrastructure at large.
>

I don't mind AV_CH_ flags using WAVEFORMATEXTENSIBLE,
but I do mind enum AVChannel following those one to one
with no offset. The two are independent, and having
an offset of one or two won't do anything to the flags as
long as that offset is accounted for when the flags are set.
___
ffmpeg-devel mailing list
ffmpeg-devel@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 crashing system with GPU intalled?

[John Riker]

I have some older systems but still decent that I have been doing hevc encoding 
with for a long time.  These are Dell Precision R5500 rack mount systems with 
dual X5680 Xeon CPUs.  One had no GPU in it and was running Windows 10 and 
working fine.  The second running Windows 2016 Server and has a NVidia NVS 295 
GPU in it with latest drivers.  The server kept crashing at random times.  
ffmpeg 4.4-full The Windows 10 was fine.  
Tried triaging the Server issues so replaced thermal paste and set my 6 fans to 
100% and the device was running cool.  Still crashed but just black screens and 
no crash logs.  So I recently installed a GPU back into the Windows 10 
computer.  NVidia Quadro M4000 with latest drivers.  It bluescreened during 
encoding and received crash logs which look like it's NVidia related but my 
encoding is not using the GPU at all or don't think so and task manager doesn't 
show any activity for it.
Below is an example of the command I'm sending:
ffmpeg.exe -i ".mkv" -c:v libx265 -x265-params 
level=51:hdr10=1:hdr-opt=1:high-tier=1:repeat-headers=1:colorprim=bt2020:transfer=smpte2084:colormatrix=bt2020nc:master-display=G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(1000,1):max-cll=854,365:crf=16:chromaloc=2:no-sao=1:info=0:range=limited:vbv-maxrate=15000:vbv-bufsize=15000
 -vf crop=3840:1600:0:280 -preset slower -pix_fmt yuv420p10le -sn -an 
".hevc"

I do suspect "maybe?" at some point when RDPing into the server maybe that's 
related?  But doesn't seem to happen for the most part, just sometimes shortly 
after remoting in it goes down even though it didn't the last 50 times so may 
be a coincidence?  The review of the crash log on the Windows 10 system is:
> > 14: kd> !analyze -v
> ***
> * 
> *
> *Bugcheck Analysis
> *
> * 
> *
> ***
> 
> DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1) An attempt was made to access a
> pageable (or completely invalid) address at an interrupt request level
> (IRQL) that is too high.  This is usually caused by drivers using
> improper addresses. If kernel debugger is available get stack
> backtrace. Arguments: Arg1: 35a4, memory referenced Arg2:
> 000c, IRQL Arg3: , value 0 = read
> operation, 1 = write operation Arg4: f80035712f86, address which
> referenced memory
> 
> Debugging Details:
> --
> 
> 
> KEY_VALUES_STRING: 1
> 
> Key  : Analysis.CPU.mSec
> Value: 6233
> 
> Key  : Analysis.DebugAnalysisManager
> Value: Create
> 
> Key  : Analysis.Elapsed.mSec
> Value: 8351
> 
> Key  : Analysis.Init.CPU.mSec
> Value: 1639
> 
> Key  : Analysis.Init.Elapsed.mSec
> Value: 45867
> 
> Key  : Analysis.Memory.CommitPeak.Mb
> Value: 87
> 
> Key  : WER.OS.Branch
> Value: vb_release
> 
> Key  : WER.OS.Timestamp
> Value: 2019-12-06T14:06:00Z
> 
> Key  : WER.OS.Version
> Value: 10.0.19041.1
> 
> 
> FILE_IN_CAB:  MEMORY.DMP
> 
> BUGCHECK_CODE:  d1
> 
> BUGCHECK_P1: 35a4
> 
> BUGCHECK_P2: c
> 
> BUGCHECK_P3: 0
> 
> BUGCHECK_P4: f80035712f86
> 
> READ_ADDRESS:  35a4 
> 
> BLACKBOXBSD: 1 (!blackboxbsd)
> 
> 
> BLACKBOXNTFS: 1 (!blackboxntfs)
> 
> 
> BLACKBOXPNP: 1 (!blackboxpnp)
> 
> 
> BLACKBOXWINLOGON: 1
> 
> PROCESS_NAME:  ffmpeg.exe
> 
> TRAP_FRAME:  bc80b81f2160 -- (.trap 0xbc80b81f2160) NOTE: The
> trap frame does not contain all registers. Some register values may be
> zeroed or incorrect. rax=cd8387447d00 rbx=
> rcx=2700 rdx=cd8389a22000 rsi=
> rdi= rip=f80035712f86 rsp=bc80b81f22f8
> rbp=0001  r8=  r9=
> r10=cd838a91f7a0 r11=cd838a91f460 r12=
> r13= r14= r15= iopl=0 
> nv up ei ng nz ac pe nc nvlddmkm+0xa2f86: f800`35712f86
> 8b81a40emov eax,dword ptr [rcx+0EA4h]
> ds:`35a4= Resetting default scope
> 
> STACK_TEXT:   bc80`b81f2018 f800`2d809069 :
> `000a `35a4 `000c
> ` : nt!KeBugCheckEx bc80`b81f2020
> f800`2d805369 : `00025106 `00989680
> ` ` : nt!KiBugCheckDispatch+0x69
> bc80`b81f2160 f800`35712f86 : cd83`89b64000
> ` ` ` :
> nt!KiPageFault+0x469 bc80`b81f22f8 f800`35713896 :
> bc80`b81f2490 ` `
> ` : nvlddmkm+0xa2f86 bc80`b81f2328
> cd83`89aea000 : cd83`89aea000 fff

Re: [FFmpeg-devel] [PATCH 1/2] avformat/utils: Fix wrong indentation

[Andreas Rheinhardt]

Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavformat/utils.c | 34 +-
>  1 file changed, 17 insertions(+), 17 deletions(-)
> 
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 7840e8717c..827e7c8d5a 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -1479,23 +1479,23 @@ static int match_stream_specifier(AVFormatContext *s, 
> AVStream *st,
>  int ret;
>  
>  if (match) {
> -   spec += 2;
> -   val = strchr(spec, ':');
> -
> -   key = val ? av_strndup(spec, val - spec) : av_strdup(spec);
> -   if (!key)
> -   return AVERROR(ENOMEM);
> -
> -   tag = av_dict_get(st->metadata, key, NULL, 0);
> -   if (tag) {
> -   if (!val || !strcmp(tag->value, val + 1))
> -   ret = 1;
> -   else
> -   ret = 0;
> -   } else
> -   ret = 0;
> -
> -   av_freep(&key);
> +spec += 2;
> +val = strchr(spec, ':');
> +
> +key = val ? av_strndup(spec, val - spec) : av_strdup(spec);
> +if (!key)
> +return AVERROR(ENOMEM);
> +
> +tag = av_dict_get(st->metadata, key, NULL, 0);
> +if (tag) {
> +if (!val || !strcmp(tag->value, val + 1))
> +ret = 1;
> +else
> +ret = 0;
> +} else
> +ret = 0;
> +
> +av_freep(&key);
>  }
>  return match && ret;
>  } else if (*spec == 'u' && *(spec + 1) == '\0') {
> 

Will apply this patchset tonight unless there are objections.

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

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

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: fix DNxHD GC ULs

[Tomas Härdin]

ons 2021-12-08 klockan 02:18 +0100 skrev Marton Balint:
> 
> 
> On Wed, 8 Dec 2021, Tomas Härdin wrote:
> 
> > fre 2021-12-03 klockan 09:38 + skrev Nicolas Gaullier:
> > > > Please add a reference to the relevant SMPTE document in the
> > > > comment, or perhaps at the list of references at the start of
> > > > the
> > > > file
> > > > 
> > > > /Tomas
> > > 
> > > I have added the reference to ST2019-4 for "VC3 mapping", so that
> > > should be ok for generic standard files.
> > > It seems redundant for me, but if you want, I could add the link
> > > to
> > > the online register where the container ul is public ?
> > > https://registry.smpte-ra.org/apps/pages/
> > > 
> > > Concerning the essence key, it is more tricky because of AVID in
> > > the
> > > place...
> > > To start with, apart AVID, all frame-wrapped samples I have (I
> > > can
> > > share them with you but not all of them publicly), do respect the
> > > standard
> > > - frame-wrapped : ARRI, Adobe Media Encoder, Harmonic : always
> > > 0x0C
> > > ("DNxHD" frame-mapping)
> > > There are up to date publicly available ARRI samples where 0x0C
> > > is
> > > used here:
> > >  
> > > https://www.arri.com/en/learn-help/learn-help-camera-system/camera-sample-footage
> > > 
> > > But I also have an AVID Op1a file where the value 0x05 is used
> > > ("MPEG" frame-mapping, ie. s381m).
> > > And concerning OPAtom, Philip de Nier has an AVID sample where
> > > the
> > > value 0x06 is used ("MPEG" clip-wrapping).
> > > 
> > > So, what is apparent at the end is that :
> > > - apart from AVID, the standard values 0x0c/0x0d are used
> > > - AVID uses the values from the older "MPEG mapping" (ie smpte
> > > 381m)
> > > 
> > > Now :
> > > - currently ffmpeg uses 0x05 for OPatom which does not follow any
> > > implementation and seems bad
> > > - it seems there is a consensus (incl. AVID) to always use 0x05
> > > or
> > > 0x0C for frame-wrapping and 0x06 or 0x0d for clip-wrapping
> > > (OPAtom)
> > > => follow either s381m or st2019-4
> > > - it seems clear ffmpeg shall take the "standard-flavor" for
> > > generic
> > > OP's, so 0x0C for frame-based wrapping
> > > - it is less clear about OPAtom which is rather an AVID-hack-
> > > thing,
> > > but it should be moved to either 0x06 or 0x0d
> > > - I have discussed this with philip de nier, and bmx (a reference
> > > software in my opinion) will stick to the AVID form, so 0x06. And
> > > I
> > > think it is reasonable, since OPAtom/Avid are almost the same
> > > damn
> > > thing
> > > 
> > > Note: no matter the essence key, the link between the tracks and
> > > the
> > > body with the TrackNumber always work, so it seems there are not
> > > much
> > > interoperability issues with it.
> > 
> > Seems I missed the reference to the VC-3 spec somehow, sorry. Since
> > it
> > is Matthieu Bouron who added this initially, you should really talk
> > to
> > him. I care less about mxfenc than I do mxfdec, since the latter
> > can
> > more easily induce CVEs.
> > 
> > That said, if we want this to work correctly for everyone then we
> > need
> > a proper set of tests. We also need to go over all the specs, and
> > what
> > all implementations are currently doing. Which is a lot of work. Or
> > a
> > lot of billable hours!
> 
> Nicolas already made a reasonable investigation, so I am not sure
> what 
> else is required. FWIW there is also a trac ticket with this issue:
> 
> https://trac.ffmpeg.org/ticket/6380

I suppose we should just try to get a hold of Matthieu then, see if it
breaks any of his stuff

> > 
> > This is why I've said for years now that we should delete mxfenc
> > and
> > just bring in bmx. We don't need what little free software people
> > there
> > are who know MXF to keep maintaining two codebases.
> > 
> > We could just bring in bmx as a subtree and be done with it. Delete
> > all
> > MXF code native to FFmpeg, put all effort into bmx. People in this
> > project suffer from the belief that code is valuable rather than a
> > liability. Worse is not better. Correct is better.
> 
> Tested and polished code is valuable, and I think you underestimate
> the 
> work required to integrate bmxlib as an mxf muxer. If somebody starts
> working on it, great. I certainly won't oppose it to add it as an 
> alternate way to mux MXF files.

Perhaps next time I get a major MXF job I'll look into it. Because what
I don't like is the hacks upon hacks that will need to be implemented
in multiple places.

> 
> But also keep in mind that ffmpeg tends to prefer native components,
> and 
> the external library (and its integration to ffmpeg) has to be
> superior in 
> every way to even think about dropping the native one...

Of course. There must at the very least be feature parity. But I will
keep pointing out that we should aim to have less code, not more.
Especially in lavf. The NIH runs deep, and it must be combatted.

For lavc this is less clear because sometimes we get codec
implementations that are better in some aspect. 

Re: [FFmpeg-devel] [PATCH 001/279] Add a new channel layout API

[Hendrik Leppkes]

On Wed, Dec 8, 2021 at 1:54 PM Lynne  wrote:
>
> 8 Dec 2021, 13:19 by an...@khirnov.net:
>
> > Quoting Marton Balint (2021-12-08 11:55:37)
> >
> >>
> >>
> >> On Wed, 8 Dec 2021, Lynne wrote:
> >>
> >> > 8 Dec 2021, 11:06 by c...@passwd.hu:
> >> >
> >> >>
> >> >>
> >> >> On Wed, 8 Dec 2021, Lynne wrote:
> >> >>
> >> >>> 8 Dec 2021, 10:22 by h.lepp...@gmail.com:
> >> >>>
> >>  On Wed, Dec 8, 2021 at 10:14 AM Lynne  wrote:
> >> 
> >> >
> >> > 8 Dec 2021, 02:06 by jamr...@gmail.com:
> >> >
> >> >>
> >> >> +enum AVChannel {
> >> >> +///< Invalid channel index
> >> >> +AV_CHAN_NONE = -1,
> >> >> +AV_CHAN_FRONT_LEFT,
> >> >>
> >> >
> >> > No, not the pixfmt mistake again. Set AV_CHAN_NONE to 0,
> >> > the rest can follow. Or keep AV_CHAN_NONE to -1
> >> > and add a new AV_CHAN_UNSPECIFIED as 0.
> >> >
> >> 
> >>  Care to elaborate on the reasons of this opinion? Using -1 as invalid
> >>  and 0...x as valid entries seems quite reasonable to me.
> >> 
> >> >>>
> >> >>> Zero-initialization. I've had issues in the past telling
> >> >>> YUV420P from .
> >> >>>
> >> >>
> >> >> It is convenient to be able to set the channel layout mask by a simple 
> >> >> byte shift of the ID-s.
> >> >>
> >> >> AV_CH_FRONT_LEFT = 1 << AV_CHAN_FRONT_LEFT.
> >> >>
> >> >> So I'd say that is the reason that it is designed that way, because 
> >> >> this way existing channel layout masks can be kept without breaking ABI.
> >> >>
> >> >
> >> > Those can be set with offsets, e.g.
> >> > AV_CH_FRONT_LEFT = 1 << (AV_CHAN_FRONT_LEFT - 2).
> >>
> >> Well, I find this less fortunate then the need to initialize NONE to -1...
> >>
> >> > I'd like to not have weird values in enums because the old
> >> > API, just being deprecated, must have its way and can't deal
> >> > with an offset.
> >>
> >> AV_CH_FRONT_LEFT and similar is not deprecated, these are still used for
> >> the native channel order which is still using a mask.
> >>
> >
> > Yes, the direct mapping between channel indices and WAVEFORMATEXTENSIBLE
> > values is a design goal here, just as it was in the old API.
> >
> > I also belive that the initialization issue of pixel/sample formats is
> > less of a problem here, since you rarely need to store actual channel
> > ids. So IMO retaining channel index compatibility is more important.
> >
>
> That's not a goal, it's anti-goal, and a cause for hysterical raisin
> picking in the future.

The old AV_CH_* values are not chosen randomly, they match  the
WAVEFORMAT channel ordering and bit position, which a lot of formats
and system use to identify channel layouts - and will continue to do
so in the future.
So its hardly just compatibility with FFmpeg from yester-year thats
being considered here, but the multimedia infrastructure at large.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@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 001/279] Add a new channel layout API

[Lynne]

8 Dec 2021, 13:16 by an...@khirnov.net:

> Quoting Lynne (2021-12-08 10:02:34)
>
>> 8 Dec 2021, 02:06 by jamr...@gmail.com:
>>
>> > From: Anton Khirnov 
>> >
>> > The new API is more extensible and allows for custom layouts.
>> > More accurate information is exported, eg for decoders that do not
>> > set a channel layout, lavc will not make one up for them.
>> >
>> > Deprecate the old API working with just uint64_t bitmasks.
>> >
>> > Expanded and completed by Vittorio Giovara 
>> > and James Almer .
>> > Signed-off-by: Vittorio Giovara 
>> > Signed-off-by: James Almer 
>> > ---
>> >  libavutil/channel_layout.c | 498 ++--
>> >  libavutil/channel_layout.h | 510 ++---
>> >  libavutil/version.h|   1 +
>> >  3 files changed, 906 insertions(+), 103 deletions(-)
>> > 
>> >  /**
>> >  * @}
>> > @@ -128,6 +199,157 @@ enum AVMatrixEncoding {
>> >  AV_MATRIX_ENCODING_NB
>> >  };
>> > 
>> > +/**
>> > + * @}
>> > + */
>> > +
>> > +/**
>> > + * An AVChannelCustom defines a single channel within a custom order 
>> > layout
>> > + *
>> > + * Unlike most structures in FFmpeg, sizeof(AVChannelCustom) is a part of 
>> > the
>> > + * public ABI.
>> > + *
>> > + * No new fields may be added to it without a major version bump.
>> > + */
>> > +typedef struct AVChannelCustom {
>> > +enum AVChannel id;
>> > +} AVChannelCustom;
>> >
>>
>> Consider adding a 25-byte or so of a description field string here that
>> would also be copied if the frame/layout is copied?
>> That way, users can assign a description label to each channel,
>> for example labeling each channel in a 255 channel custom layout
>> Opus stream used in production at a venue somewhere.
>> Also, consider additionally reserving 16-bytes here, just in case.
>>
>
> That would enlarge the layout size by a significant amount. Keep in mind
> that this is all per frame. And for something that very few people would
> want to use.
>
> These descriptors, if anyone really needs them, can live in side data.
>

That's fine with me.
Can we at least have an opaque uint64_t? I'd accept a uintptr_t,
or an int too, or even a single-byte uint8_t.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 001/279] Add a new channel layout API

[Lynne]

8 Dec 2021, 13:19 by an...@khirnov.net:

> Quoting Marton Balint (2021-12-08 11:55:37)
>
>>
>>
>> On Wed, 8 Dec 2021, Lynne wrote:
>>
>> > 8 Dec 2021, 11:06 by c...@passwd.hu:
>> >
>> >>
>> >>
>> >> On Wed, 8 Dec 2021, Lynne wrote:
>> >>
>> >>> 8 Dec 2021, 10:22 by h.lepp...@gmail.com:
>> >>>
>>  On Wed, Dec 8, 2021 at 10:14 AM Lynne  wrote:
>> 
>> >
>> > 8 Dec 2021, 02:06 by jamr...@gmail.com:
>> >
>> >>
>> >> +enum AVChannel {
>> >> +///< Invalid channel index
>> >> +AV_CHAN_NONE = -1,
>> >> +AV_CHAN_FRONT_LEFT,
>> >>
>> >
>> > No, not the pixfmt mistake again. Set AV_CHAN_NONE to 0,
>> > the rest can follow. Or keep AV_CHAN_NONE to -1
>> > and add a new AV_CHAN_UNSPECIFIED as 0.
>> >
>> 
>>  Care to elaborate on the reasons of this opinion? Using -1 as invalid
>>  and 0...x as valid entries seems quite reasonable to me.
>> 
>> >>>
>> >>> Zero-initialization. I've had issues in the past telling
>> >>> YUV420P from .
>> >>>
>> >>
>> >> It is convenient to be able to set the channel layout mask by a simple 
>> >> byte shift of the ID-s.
>> >>
>> >> AV_CH_FRONT_LEFT = 1 << AV_CHAN_FRONT_LEFT.
>> >>
>> >> So I'd say that is the reason that it is designed that way, because this 
>> >> way existing channel layout masks can be kept without breaking ABI.
>> >>
>> >
>> > Those can be set with offsets, e.g.
>> > AV_CH_FRONT_LEFT = 1 << (AV_CHAN_FRONT_LEFT - 2).
>>
>> Well, I find this less fortunate then the need to initialize NONE to -1...
>>
>> > I'd like to not have weird values in enums because the old
>> > API, just being deprecated, must have its way and can't deal
>> > with an offset.
>>
>> AV_CH_FRONT_LEFT and similar is not deprecated, these are still used for 
>> the native channel order which is still using a mask.
>>
>
> Yes, the direct mapping between channel indices and WAVEFORMATEXTENSIBLE
> values is a design goal here, just as it was in the old API.
>
> I also belive that the initialization issue of pixel/sample formats is
> less of a problem here, since you rarely need to store actual channel
> ids. So IMO retaining channel index compatibility is more important.
>

That's not a goal, it's anti-goal, and a cause for hysterical raisin
picking in the future.
Having an instantly debuggable structure rather than one that
makes you question your sanity is much more important than
some compatibility few care about, apart from some users who
don't even use it but think it's 'neat' and nothing more.
___
ffmpeg-devel mailing list
ffmpeg-devel@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 000/279] New channel layout API

[Anton Khirnov]

Quoting Nicolas George (2021-12-08 11:55:40)
> James Almer (12021-12-07):
> > This is an updated and rebased version of the API that was sent to this 
> > mailing
> > list about two years ago. It expands it with some new helpers, implements 
> > some
> > changes that allows further extensibility for new features down the line, 
> > and
> > finishes porting all missing modules and those introduced since 2019.
> 
> I see the concerns I raised last time have not been addressed:
> 
> (1) the ability to have a channel at a certain location several times;

I have no idea what you mean, the CUSTOM order can have any channel at
any location. This was true in all versions of this API back to 2013.

> 
> (2) the ability to attach an arbitrary label to a channel or to a group
> of channels;
> 
> (3) an API and syntax for the user to specify a particular channel.
> 
> (1) is necessary for the amerge filter: merge two stereo streams, you
> get two FL and two FR.
> 
> (1) is also necessary for devices that can record several sources
> simultaneously. IIRC, that is the case for the BlackMagick devices. If
> your devices records a band from two stereo and three mono microphones,
> we need two FL, two FR and three FC.

Multiplexing multiple streams into a single AVFrame is not a valid use
case. Just use multiple streams.

-- 
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 001/279] Add a new channel layout API

[Anton Khirnov]

Quoting Marton Balint (2021-12-08 11:55:37)
> 
> 
> On Wed, 8 Dec 2021, Lynne wrote:
> 
> > 8 Dec 2021, 11:06 by c...@passwd.hu:
> >
> >>
> >>
> >> On Wed, 8 Dec 2021, Lynne wrote:
> >>
> >>> 8 Dec 2021, 10:22 by h.lepp...@gmail.com:
> >>>
>  On Wed, Dec 8, 2021 at 10:14 AM Lynne  wrote:
> 
> >
> > 8 Dec 2021, 02:06 by jamr...@gmail.com:
> >
> >>
> >> +enum AVChannel {
> >> +///< Invalid channel index
> >> +AV_CHAN_NONE = -1,
> >> +AV_CHAN_FRONT_LEFT,
> >>
> >
> > No, not the pixfmt mistake again. Set AV_CHAN_NONE to 0,
> > the rest can follow. Or keep AV_CHAN_NONE to -1
> > and add a new AV_CHAN_UNSPECIFIED as 0.
> >
> 
>  Care to elaborate on the reasons of this opinion? Using -1 as invalid
>  and 0...x as valid entries seems quite reasonable to me.
> 
> >>>
> >>> Zero-initialization. I've had issues in the past telling
> >>> YUV420P from .
> >>>
> >>
> >> It is convenient to be able to set the channel layout mask by a simple 
> >> byte shift of the ID-s.
> >>
> >> AV_CH_FRONT_LEFT = 1 << AV_CHAN_FRONT_LEFT.
> >>
> >> So I'd say that is the reason that it is designed that way, because this 
> >> way existing channel layout masks can be kept without breaking ABI.
> >>
> >
> > Those can be set with offsets, e.g.
> > AV_CH_FRONT_LEFT = 1 << (AV_CHAN_FRONT_LEFT - 2).
> 
> Well, I find this less fortunate then the need to initialize NONE to -1...
> 
> > I'd like to not have weird values in enums because the old
> > API, just being deprecated, must have its way and can't deal
> > with an offset.
> 
> AV_CH_FRONT_LEFT and similar is not deprecated, these are still used for 
> the native channel order which is still using a mask.

Yes, the direct mapping between channel indices and WAVEFORMATEXTENSIBLE
values is a design goal here, just as it was in the old API.

I also belive that the initialization issue of pixel/sample formats is
less of a problem here, since you rarely need to store actual channel
ids. So IMO retaining channel index compatibility is more important.

-- 
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 001/279] Add a new channel layout API

[Anton Khirnov]

Quoting Lynne (2021-12-08 10:02:34)
> 8 Dec 2021, 02:06 by jamr...@gmail.com:
> 
> > From: Anton Khirnov 
> >
> > The new API is more extensible and allows for custom layouts.
> > More accurate information is exported, eg for decoders that do not
> > set a channel layout, lavc will not make one up for them.
> >
> > Deprecate the old API working with just uint64_t bitmasks.
> >
> > Expanded and completed by Vittorio Giovara 
> > and James Almer .
> > Signed-off-by: Vittorio Giovara 
> > Signed-off-by: James Almer 
> > ---
> >  libavutil/channel_layout.c | 498 ++--
> >  libavutil/channel_layout.h | 510 ++---
> >  libavutil/version.h|   1 +
> >  3 files changed, 906 insertions(+), 103 deletions(-)
> >  
> >  /**
> >  * @}
> > @@ -128,6 +199,157 @@ enum AVMatrixEncoding {
> >  AV_MATRIX_ENCODING_NB
> >  };
> >  
> > +/**
> > + * @}
> > + */
> > +
> > +/**
> > + * An AVChannelCustom defines a single channel within a custom order layout
> > + *
> > + * Unlike most structures in FFmpeg, sizeof(AVChannelCustom) is a part of 
> > the
> > + * public ABI.
> > + *
> > + * No new fields may be added to it without a major version bump.
> > + */
> > +typedef struct AVChannelCustom {
> > +enum AVChannel id;
> > +} AVChannelCustom;
> >
> 
> Consider adding a 25-byte or so of a description field string here that
> would also be copied if the frame/layout is copied?
> That way, users can assign a description label to each channel,
> for example labeling each channel in a 255 channel custom layout
> Opus stream used in production at a venue somewhere.
> Also, consider additionally reserving 16-bytes here, just in case.

That would enlarge the layout size by a significant amount. Keep in mind
that this is all per frame. And for something that very few people would
want to use.

These descriptors, if anyone really needs them, can live in side data.

-- 
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 000/279] New channel layout API

[James Almer]

On 12/8/2021 7:55 AM, Nicolas George wrote:

James Almer (12021-12-07):

This is an updated and rebased version of the API that was sent to this mailing
list about two years ago. It expands it with some new helpers, implements some
changes that allows further extensibility for new features down the line, and
finishes porting all missing modules and those introduced since 2019.


I see the concerns I raised last time have not been addressed:

(1) the ability to have a channel at a certain location several times;

(2) the ability to attach an arbitrary label to a channel or to a group
 of channels;

(3) an API and syntax for the user to specify a particular channel.

(1) is necessary for the amerge filter: merge two stereo streams, you
get two FL and two FR.

(1) is also necessary for devices that can record several sources
simultaneously. IIRC, that is the case for the BlackMagick devices. If
your devices records a band from two stereo and three mono microphones,
we need two FL, two FR and three FC.

(2) and (3) are necessary consequences of (1).

I also have concerns with the signature of av_channel_description():
this is level 0 of string manipulation, we need to get past this. I
should post again about this in a separate thread.


What is wrong with it? All the functions returning a string in this API 
use the same signature. You pass it a pre-allocated buffer and it's 
filled with the string, truncating it if there's not enough space and 
letting the user know about it.
I recall you were against dynamic allocation of the string, which the 
user then had to free, so this was the alternative.


I could make it use a user provided AVBprint buffer instead of using one 
internally, if you think that's better, but since you planned to replace 
that with AVWriter i figured using AVBprint in the signature would mean 
an eventual deprecation and removal.




Regards,


___
ffmpeg-devel mailing list
ffmpeg-devel@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 001/279] Add a new channel layout API

[Nicolas George]

Lynne (12021-12-08):
> Consider adding a 25-byte or so of a description field string here that
> would also be copied if the frame/layout is copied?
> That way, users can assign a description label to each channel,
> for example labeling each channel in a 255 channel custom layout
> Opus stream used in production at a venue somewhere.

I posted a remark with the same concern.

But if we add it, or if we make the labels dynamically allocated, the
structure will become large and/or slow: I suspect we will need to make
it refcounted. Long ago, I posted a template to implement refcounting in
structure without the syntactic and memory overhead that buffers
require, it was in part meant for this.

Regards,

-- 
  Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@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 000/279] New channel layout API

[Nicolas George]

James Almer (12021-12-07):
> This is an updated and rebased version of the API that was sent to this 
> mailing
> list about two years ago. It expands it with some new helpers, implements some
> changes that allows further extensibility for new features down the line, and
> finishes porting all missing modules and those introduced since 2019.

I see the concerns I raised last time have not been addressed:

(1) the ability to have a channel at a certain location several times;

(2) the ability to attach an arbitrary label to a channel or to a group
of channels;

(3) an API and syntax for the user to specify a particular channel.

(1) is necessary for the amerge filter: merge two stereo streams, you
get two FL and two FR.

(1) is also necessary for devices that can record several sources
simultaneously. IIRC, that is the case for the BlackMagick devices. If
your devices records a band from two stereo and three mono microphones,
we need two FL, two FR and three FC.

(2) and (3) are necessary consequences of (1).

I also have concerns with the signature of av_channel_description():
this is level 0 of string manipulation, we need to get past this. I
should post again about this in a separate thread.

Regards,

-- 
  Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@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 001/279] Add a new channel layout API

[Marton Balint]

On Wed, 8 Dec 2021, Lynne wrote:


8 Dec 2021, 11:06 by c...@passwd.hu:




On Wed, 8 Dec 2021, Lynne wrote:


8 Dec 2021, 10:22 by h.lepp...@gmail.com:


On Wed, Dec 8, 2021 at 10:14 AM Lynne  wrote:



8 Dec 2021, 02:06 by jamr...@gmail.com:



+enum AVChannel {
+///< Invalid channel index
+AV_CHAN_NONE = -1,
+AV_CHAN_FRONT_LEFT,



No, not the pixfmt mistake again. Set AV_CHAN_NONE to 0,
the rest can follow. Or keep AV_CHAN_NONE to -1
and add a new AV_CHAN_UNSPECIFIED as 0.



Care to elaborate on the reasons of this opinion? Using -1 as invalid
and 0...x as valid entries seems quite reasonable to me.



Zero-initialization. I've had issues in the past telling
YUV420P from .



It is convenient to be able to set the channel layout mask by a simple byte 
shift of the ID-s.

AV_CH_FRONT_LEFT = 1 << AV_CHAN_FRONT_LEFT.

So I'd say that is the reason that it is designed that way, because this way 
existing channel layout masks can be kept without breaking ABI.



Those can be set with offsets, e.g.
AV_CH_FRONT_LEFT = 1 << (AV_CHAN_FRONT_LEFT - 2).


Well, I find this less fortunate then the need to initialize NONE to -1...


I'd like to not have weird values in enums because the old
API, just being deprecated, must have its way and can't deal
with an offset.


AV_CH_FRONT_LEFT and similar is not deprecated, these are still used for 
the native channel order which is still using a mask.


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 001/279] Add a new channel layout API

[Lynne]

8 Dec 2021, 11:06 by c...@passwd.hu:

>
>
> On Wed, 8 Dec 2021, Lynne wrote:
>
>> 8 Dec 2021, 10:22 by h.lepp...@gmail.com:
>>
>>> On Wed, Dec 8, 2021 at 10:14 AM Lynne  wrote:
>>>

 8 Dec 2021, 02:06 by jamr...@gmail.com:

>
> +enum AVChannel {
> +///< Invalid channel index
> +AV_CHAN_NONE = -1,
> +AV_CHAN_FRONT_LEFT,
>

 No, not the pixfmt mistake again. Set AV_CHAN_NONE to 0,
 the rest can follow. Or keep AV_CHAN_NONE to -1
 and add a new AV_CHAN_UNSPECIFIED as 0.

>>>
>>> Care to elaborate on the reasons of this opinion? Using -1 as invalid
>>> and 0...x as valid entries seems quite reasonable to me.
>>>
>>
>> Zero-initialization. I've had issues in the past telling
>> YUV420P from .
>>
>
> It is convenient to be able to set the channel layout mask by a simple byte 
> shift of the ID-s.
>
> AV_CH_FRONT_LEFT = 1 << AV_CHAN_FRONT_LEFT.
>
> So I'd say that is the reason that it is designed that way, because this way 
> existing channel layout masks can be kept without breaking ABI.
>

Those can be set with offsets, e.g.
AV_CH_FRONT_LEFT = 1 << (AV_CHAN_FRONT_LEFT - 2).

I'd like to not have weird values in enums because the old
API, just being deprecated, must have its way and can't deal
with an offset.
___
ffmpeg-devel mailing list
ffmpeg-devel@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 001/279] Add a new channel layout API

[Lynne]

8 Dec 2021, 11:13 by c...@passwd.hu:

>
>
> On Wed, 8 Dec 2021, Lynne wrote:
>
>> 8 Dec 2021, 02:06 by jamr...@gmail.com:
>>
>>>
>>> +enum AVChannel {
>>> +///< Invalid channel index
>>> +AV_CHAN_NONE = -1,
>>> +AV_CHAN_FRONT_LEFT,
>>>
>>
>> No, not the pixfmt mistake again. Set AV_CHAN_NONE to 0,
>> the rest can follow. Or keep AV_CHAN_NONE to -1
>> and add a new AV_CHAN_UNSPECIFIED as 0.
>>
>>
>>> +AV_CHAN_FRONT_RIGHT,
>>> +AV_CHAN_FRONT_CENTER,
>>> +AV_CHAN_LOW_FREQUENCY,
>>> +AV_CHAN_BACK_LEFT,
>>> +AV_CHAN_BACK_RIGHT,
>>> +AV_CHAN_FRONT_LEFT_OF_CENTER,
>>> +AV_CHAN_FRONT_RIGHT_OF_CENTER,
>>> +AV_CHAN_BACK_CENTER,
>>> +AV_CHAN_SIDE_LEFT,
>>> +AV_CHAN_SIDE_RIGHT,
>>> +AV_CHAN_TOP_CENTER,
>>> +AV_CHAN_TOP_FRONT_LEFT,
>>> +AV_CHAN_TOP_FRONT_CENTER,
>>> +AV_CHAN_TOP_FRONT_RIGHT,
>>> +AV_CHAN_TOP_BACK_LEFT,
>>> +AV_CHAN_TOP_BACK_CENTER,
>>> +AV_CHAN_TOP_BACK_RIGHT,
>>> +/** Stereo downmix. */
>>> +AV_CHAN_STEREO_LEFT = 29,
>>> +/** See above. */
>>> +AV_CHAN_STEREO_RIGHT,
>>> +AV_CHAN_WIDE_LEFT,
>>> +AV_CHAN_WIDE_RIGHT,
>>> +AV_CHAN_SURROUND_DIRECT_LEFT,
>>> +AV_CHAN_SURROUND_DIRECT_RIGHT,
>>> +AV_CHAN_LOW_FREQUENCY_2,
>>> +AV_CHAN_TOP_SIDE_LEFT,
>>> +AV_CHAN_TOP_SIDE_RIGHT,
>>> +AV_CHAN_BOTTOM_FRONT_CENTER,
>>> +AV_CHAN_BOTTOM_FRONT_LEFT,
>>> +AV_CHAN_BOTTOM_FRONT_RIGHT,
>>> +
>>> +/** Channel is empty can be safely skipped. */
>>> +AV_CHAN_SILENCE = 64,
>>> +};
>>>
>>
>> Why is AV_CHAN_SILENCE set to 64? If it's special,
>> set it to follow just after AV_CHAN_NONE or
>> AV_CHAN_UNSPECIFIED.
>>
>
> Because of the channel layout bitmask representation and its relation to the 
> channel ID. We might want to add real channel designations which can be 
> represented using the bitmask layout, and using SILENCE for that does not 
> make a lot of sense. E.g. there can be more than one silent channel. And if 
> somebody wants sparse channel layout then making the extended representation 
> a hard requirement seems also a good idea.
>
> Regards,
> Marton
>

If it's a flag, then I'd like for it to be specified with a hint,
either AV_CHAN_FLAG_SILENCE, or a comment, or
using AV_CHAN_SILENCE = 1 << 16.
___
ffmpeg-devel mailing list
ffmpeg-devel@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 v3] lavc/hevcdec: Parse DOVI RPU NALs

[Niklas Haas]

From: Niklas Haas 

And expose the parsed values as frame side data.

Signed-off-by: Niklas Haas 
---
 libavcodec/hevcdec.c | 32 ++--
 libavcodec/hevcdec.h |  2 ++
 2 files changed, 32 insertions(+), 2 deletions(-)

diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 46d9edf8eb..70f1e7f045 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -38,6 +38,7 @@
 #include "bswapdsp.h"
 #include "bytestream.h"
 #include "cabac_functions.h"
+#include "dovi.h"
 #include "golomb.h"
 #include "hevc.h"
 #include "hevc_data.h"
@@ -2967,6 +2968,19 @@ static int set_side_data(HEVCContext *s)
 s->rpu_buf = NULL;
 }
 
+if (s->dovi_ctx.mapping && s->dovi_ctx.color) {
+AVDOVIMetadata *dovi;
+AVFrameSideData *sd = av_frame_new_side_data(out, 
AV_FRAME_DATA_DOVI_METADATA,
+ sizeof(AVDOVIMetadata));
+if (!sd)
+return AVERROR(ENOMEM);
+
+dovi = (AVDOVIMetadata *) sd->data;
+memcpy(&dovi->header, &s->dovi_ctx.header, sizeof(dovi->header));
+memcpy(&dovi->mapping, s->dovi_ctx.mapping, sizeof(dovi->mapping));
+memcpy(&dovi->color, s->dovi_ctx.color, sizeof(dovi->color));
+}
+
 return 0;
 }
 
@@ -3298,16 +3312,23 @@ static int decode_nal_units(HEVCContext *s, const 
uint8_t *buf, int length)
 if (s->pkt.nb_nals > 1 && s->pkt.nals[s->pkt.nb_nals - 1].type == 
HEVC_NAL_UNSPEC62 &&
 s->pkt.nals[s->pkt.nb_nals - 1].size > 2 && 
!s->pkt.nals[s->pkt.nb_nals - 1].nuh_layer_id
 && !s->pkt.nals[s->pkt.nb_nals - 1].temporal_id) {
+H2645NAL *nal = &s->pkt.nals[s->pkt.nb_nals - 1];
 if (s->rpu_buf) {
 av_buffer_unref(&s->rpu_buf);
 av_log(s->avctx, AV_LOG_WARNING, "Multiple Dolby Vision RPUs found 
in one AU. Skipping previous.\n");
 }
 
-s->rpu_buf = av_buffer_alloc(s->pkt.nals[s->pkt.nb_nals - 1].raw_size 
- 2);
+s->rpu_buf = av_buffer_alloc(nal->raw_size - 2);
 if (!s->rpu_buf)
 return AVERROR(ENOMEM);
 
-memcpy(s->rpu_buf->data, s->pkt.nals[s->pkt.nb_nals - 1].raw_data + 2, 
s->pkt.nals[s->pkt.nb_nals - 1].raw_size - 2);
+memcpy(s->rpu_buf->data, nal->raw_data + 2, nal->raw_size - 2);
+ret = ff_dovi_rpu_parse(&s->dovi_ctx, nal->data + 2, nal->size - 2);
+if (ret < 0) {
+av_buffer_unref(&s->rpu_buf);
+av_log(s->avctx, AV_LOG_WARNING, "Error parsing DOVI NAL unit.\n");
+/* ignore */
+}
 }
 
 /* decode the NAL units */
@@ -3553,6 +3574,7 @@ static av_cold int hevc_decode_free(AVCodecContext *avctx)
 
 pic_arrays_free(s);
 
+ff_dovi_ctx_unref(&s->dovi_ctx);
 av_buffer_unref(&s->rpu_buf);
 
 av_freep(&s->md5_ctx);
@@ -3637,6 +3659,7 @@ static av_cold int hevc_init_context(AVCodecContext 
*avctx)
 
 ff_bswapdsp_init(&s->bdsp);
 
+s->dovi_ctx.avctx = avctx;
 s->context_initialized = 1;
 s->eos = 0;
 
@@ -3745,6 +3768,10 @@ static int hevc_update_thread_context(AVCodecContext 
*dst,
 if (ret < 0)
 return ret;
 
+ret = ff_dovi_ctx_replace(&s->dovi_ctx, &s0->dovi_ctx);
+if (ret < 0)
+return ret;
+
 s->sei.frame_packing= s0->sei.frame_packing;
 s->sei.display_orientation  = s0->sei.display_orientation;
 s->sei.mastering_display= s0->sei.mastering_display;
@@ -3801,6 +3828,7 @@ static void hevc_decode_flush(AVCodecContext *avctx)
 HEVCContext *s = avctx->priv_data;
 ff_hevc_flush_dpb(s);
 ff_hevc_reset_sei(&s->sei);
+ff_dovi_ctx_unref(&s->dovi_ctx);
 av_buffer_unref(&s->rpu_buf);
 s->max_ra = INT_MAX;
 s->eos = 1;
diff --git a/libavcodec/hevcdec.h b/libavcodec/hevcdec.h
index 870ff178d4..5b04a8ad83 100644
--- a/libavcodec/hevcdec.h
+++ b/libavcodec/hevcdec.h
@@ -32,6 +32,7 @@
 #include "avcodec.h"
 #include "bswapdsp.h"
 #include "cabac.h"
+#include "dovi.h"
 #include "get_bits.h"
 #include "hevcpred.h"
 #include "h2645_parse.h"
@@ -574,6 +575,7 @@ typedef struct HEVCContext {
 int nuh_layer_id;
 
 AVBufferRef *rpu_buf;   ///< 0 or 1 Dolby Vision RPUs.
+DOVIContext dovi_ctx;   ///< Dolby Vision decoding context
 } HEVCContext;
 
 /**
-- 
2.34.1

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

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

Re: [FFmpeg-devel] [PATCH 001/279] Add a new channel layout API

[Marton Balint]

On Wed, 8 Dec 2021, Lynne wrote:


8 Dec 2021, 02:06 by jamr...@gmail.com:



+enum AVChannel {
+///< Invalid channel index
+AV_CHAN_NONE = -1,
+AV_CHAN_FRONT_LEFT,



No, not the pixfmt mistake again. Set AV_CHAN_NONE to 0,
the rest can follow. Or keep AV_CHAN_NONE to -1
and add a new AV_CHAN_UNSPECIFIED as 0.



+AV_CHAN_FRONT_RIGHT,
+AV_CHAN_FRONT_CENTER,
+AV_CHAN_LOW_FREQUENCY,
+AV_CHAN_BACK_LEFT,
+AV_CHAN_BACK_RIGHT,
+AV_CHAN_FRONT_LEFT_OF_CENTER,
+AV_CHAN_FRONT_RIGHT_OF_CENTER,
+AV_CHAN_BACK_CENTER,
+AV_CHAN_SIDE_LEFT,
+AV_CHAN_SIDE_RIGHT,
+AV_CHAN_TOP_CENTER,
+AV_CHAN_TOP_FRONT_LEFT,
+AV_CHAN_TOP_FRONT_CENTER,
+AV_CHAN_TOP_FRONT_RIGHT,
+AV_CHAN_TOP_BACK_LEFT,
+AV_CHAN_TOP_BACK_CENTER,
+AV_CHAN_TOP_BACK_RIGHT,
+/** Stereo downmix. */
+AV_CHAN_STEREO_LEFT = 29,
+/** See above. */
+AV_CHAN_STEREO_RIGHT,
+AV_CHAN_WIDE_LEFT,
+AV_CHAN_WIDE_RIGHT,
+AV_CHAN_SURROUND_DIRECT_LEFT,
+AV_CHAN_SURROUND_DIRECT_RIGHT,
+AV_CHAN_LOW_FREQUENCY_2,
+AV_CHAN_TOP_SIDE_LEFT,
+AV_CHAN_TOP_SIDE_RIGHT,
+AV_CHAN_BOTTOM_FRONT_CENTER,
+AV_CHAN_BOTTOM_FRONT_LEFT,
+AV_CHAN_BOTTOM_FRONT_RIGHT,
+
+/** Channel is empty can be safely skipped. */
+AV_CHAN_SILENCE = 64,
+};



Why is AV_CHAN_SILENCE set to 64? If it's special,
set it to follow just after AV_CHAN_NONE or
AV_CHAN_UNSPECIFIED.


Because of the channel layout bitmask representation and its relation to 
the channel ID. We might want to add real channel designations which can 
be represented using the bitmask layout, and using SILENCE for that does 
not make a lot of sense. E.g. there can be more than one silent channel. 
And if somebody wants sparse channel layout then making the extended 
representation a hard requirement seems also a good idea.


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 v2 3/4] lavc: Implement Dolby Vision RPU parsing

[Niklas Haas]

From: Niklas Haas 

Based on a mixture of guesswork, partial documentation in patents, and
reverse engineering of real-world samples. Confirmed working for all the
samples I've thrown at it.

Contains some annoying machinery to persist these values in between
frames, which is needed in theory even though I've never actually seen a
sample that relies on it in practice. May or may not work.

Notable omissions:
- CRC32 verificaiton. This is based on the MPEG2 CRC32 type, which does
  not seem to be implemented in lavc. (And I don't care enough to do so)
- Linear interpolation support. Nothing documents this (beyond its
  existence) and no samples use it, so impossible to implement.
- All of the extension metadata blocks, but these contain values that
  are basically congruent with ST2094, HDR10, or other existing forms of
  side data, so I will defer parsing/attaching them to a future commit.

Heavily influenced by https://github.com/quietvoid/dovi_tool
Documentation drawn from US Patent 10,701,399 B2 and ETSI GS CCM 001

Signed-off-by: Niklas Haas 
---
 libavcodec/Makefile |   1 +
 libavcodec/dovi.c   | 369 
 libavcodec/dovi.h   |  62 
 3 files changed, 432 insertions(+)
 create mode 100644 libavcodec/dovi.c
 create mode 100644 libavcodec/dovi.h

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 4122a9b144..c327e0d764 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -40,6 +40,7 @@ OBJS = ac3_parser.o   
  \
d3d11va.o\
decode.o \
dirac.o  \
+   dovi.o   \
dv_profile.o \
encode.o \
imgconvert.o \
diff --git a/libavcodec/dovi.c b/libavcodec/dovi.c
new file mode 100644
index 00..7e90092f0d
--- /dev/null
+++ b/libavcodec/dovi.c
@@ -0,0 +1,369 @@
+/*
+ * Dolby Vision RPU decoder
+ *
+ * Copyright (C) 2021 Jan Ekström
+ * Copyright (C) 2021 Niklas Haas
+ *
+ * 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 "dovi.h"
+#include "golomb.h"
+#include "get_bits.h"
+
+enum {
+RPU_COEFF_FIXED = 0,
+RPU_COEFF_FLOAT = 1,
+};
+
+/**
+ * Private contents of vdr_ref.
+ */
+typedef struct DOVIVdrRef {
+AVDOVIDataMapping mapping;
+AVDOVIColorMetadata color;
+} DOVIVdrRef;
+
+void ff_dovi_ctx_unref(DOVIContext *s)
+{
+for (int i = 0; i < DOVI_MAX_DM_ID; i++)
+av_buffer_unref(&s->vdr_ref[i]);
+
+/* Preserve the AVCodecContext explicitly, reset everything else */
+*s = (DOVIContext) {
+.avctx = s->avctx,
+};
+}
+
+int ff_dovi_ctx_replace(DOVIContext *s, const DOVIContext *s0)
+{
+int ret;
+for (int i = 0; i < DOVI_MAX_DM_ID; i++) {
+if ((ret = av_buffer_replace(&s->vdr_ref[i], s0->vdr_ref[i])) < 0) {
+s->mapping = NULL; /* sanity */
+s->color = NULL;
+return ret;
+}
+}
+
+s->mapping = s0->mapping;
+s->color = s0->color;
+return 0;
+}
+
+static inline uint64_t get_ue_coef(GetBitContext *gb, const 
AVDOVIRpuDataHeader *hdr)
+{
+uint64_t ipart;
+union { uint32_t u32; float f32; } fpart;
+
+switch (hdr->coef_data_type) {
+case RPU_COEFF_FIXED:
+ipart = get_ue_golomb_long(gb);
+fpart.u32 = get_bits_long(gb, hdr->coef_log2_denom);
+return (ipart << hdr->coef_log2_denom) + fpart.u32;
+
+case RPU_COEFF_FLOAT:
+fpart.u32 = get_bits_long(gb, 32);
+return fpart.f32 * (1 << hdr->coef_log2_denom);
+}
+
+return 0; /* unreachable */
+}
+
+static inline int64_t get_se_coef(GetBitContext *gb, const AVDOVIRpuDataHeader 
*hdr)
+{
+int64_t ipart;
+union { uint32_t u32; float f32; } fpart;
+
+switch (hdr->coef_data_type) {
+case RPU_COEFF_FIXED:
+ipart = get_se_golomb_long(gb);
+fpart.u32 = get_bits_long(gb, hdr->coef_log2_denom);
+return (ipart 

[FFmpeg-devel] [PATCH v2 2/4] lavfi/showinfo: Support AV_FRAME_DATA_DOVI_METADATA

[Niklas Haas]

From: Niklas Haas 

Signed-off-by: Niklas Haas 
---
 libavfilter/vf_showinfo.c | 108 ++
 1 file changed, 108 insertions(+)

diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
index 62c7833247..79294f6891 100644
--- a/libavfilter/vf_showinfo.c
+++ b/libavfilter/vf_showinfo.c
@@ -27,6 +27,7 @@
 #include "libavutil/bswap.h"
 #include "libavutil/adler32.h"
 #include "libavutil/display.h"
+#include "libavutil/dovi_meta.h"
 #include "libavutil/imgutils.h"
 #include "libavutil/internal.h"
 #include "libavutil/film_grain_params.h"
@@ -429,6 +430,110 @@ static void 
dump_sei_film_grain_params_metadata(AVFilterContext *ctx, const AVFr
 }
 }
 
+static void dump_dovi_metadata(AVFilterContext *ctx, const AVFrameSideData *sd)
+{
+const AVDOVIMetadata *dovi = (const AVDOVIMetadata *) sd->data;
+const AVDOVIRpuDataHeader *hdr = &dovi->header;
+const AVDOVIDataMapping *mapping = &dovi->mapping;
+const AVDOVIColorMetadata *color = &dovi->color;
+
+av_log(ctx, AV_LOG_INFO, "Dolby Vision RPU metadata:\n");
+av_log(ctx, AV_LOG_INFO, "rpu_type=%"PRIu8"; ", hdr->rpu_type);
+av_log(ctx, AV_LOG_INFO, "rpu_format=%"PRIu16"; ", hdr->rpu_format);
+av_log(ctx, AV_LOG_INFO, "vdr_rpu_profile=%"PRIu8"; ", 
hdr->vdr_rpu_profile);
+av_log(ctx, AV_LOG_INFO, "vdr_rpu_level=%"PRIu8"; ", hdr->vdr_rpu_level);
+av_log(ctx, AV_LOG_INFO, "chroma_resampling_explicit_filter_flag=%d; ", 
hdr->chroma_resampling_explicit_filter_flag);
+av_log(ctx, AV_LOG_INFO, "coef_data_type=%"PRIu8"; ", hdr->coef_data_type);
+av_log(ctx, AV_LOG_INFO, "coef_log2_denom=%"PRIu8"; ", 
hdr->coef_log2_denom);
+av_log(ctx, AV_LOG_INFO, "vdr_rpu_normalized_idc=%"PRIu8"; ", 
hdr->vdr_rpu_normalized_idc);
+av_log(ctx, AV_LOG_INFO, "bl_video_full_range_flag=%d; ", 
hdr->bl_video_full_range_flag);
+av_log(ctx, AV_LOG_INFO, "bl_bit_depth=%"PRIu8"; ", hdr->bl_bit_depth);
+av_log(ctx, AV_LOG_INFO, "el_bit_depth=%"PRIu8"; ", hdr->el_bit_depth);
+av_log(ctx, AV_LOG_INFO, "vdr_bit_depth=%"PRIu8"; ", hdr->vdr_bit_depth);
+av_log(ctx, AV_LOG_INFO, "spatial_resampling_filter_flag=%d; ", 
hdr->spatial_resampling_filter_flag);
+av_log(ctx, AV_LOG_INFO, "el_spatial_resampling_filter_flag=%d; ", 
hdr->el_spatial_resampling_filter_flag);
+av_log(ctx, AV_LOG_INFO, "disable_residual_flag=%d\n", 
hdr->disable_residual_flag);
+
+av_log(ctx, AV_LOG_INFO, "data mapping: ");
+av_log(ctx, AV_LOG_INFO, "vdr_rpu_id=%"PRIu8"; ", mapping->vdr_rpu_id);
+av_log(ctx, AV_LOG_INFO, "mapping_color_space=%"PRIu8"; ", 
mapping->mapping_color_space);
+av_log(ctx, AV_LOG_INFO, "mapping_chroma_format_idc=%"PRIu8"; ", 
mapping->mapping_chroma_format_idc);
+av_log(ctx, AV_LOG_INFO, "nlq_method_idc=%d; ", (int) 
mapping->nlq_method_idc);
+av_log(ctx, AV_LOG_INFO, "num_x_partitions=%"PRIu32"; ", 
mapping->num_x_partitions);
+av_log(ctx, AV_LOG_INFO, "num_y_partitions=%"PRIu32"\n", 
mapping->num_y_partitions);
+
+for (int c = 0; c < 3; c++) {
+const AVDOVIReshapingCurve *curve = &mapping->curves[c];
+const AVDOVINLQParams *nlq = &mapping->nlq[c];
+av_log(ctx, AV_LOG_INFO, "  channel %d: ", c);
+av_log(ctx, AV_LOG_INFO, "pivots={ ");
+for (int i = 0; i < curve->num_pivots; i++)
+av_log(ctx, AV_LOG_INFO, "%"PRIu16" ", curve->pivots[i]);
+av_log(ctx, AV_LOG_INFO, "}; mapping_idc={ ");
+for (int i = 0; i < curve->num_pivots - 1; i++)
+av_log(ctx, AV_LOG_INFO, "%d ", (int) curve->mapping_idc[i]);
+av_log(ctx, AV_LOG_INFO, "}; poly_order={ ");
+for (int i = 0; i < curve->num_pivots - 1; i++)
+av_log(ctx, AV_LOG_INFO, "%"PRIu8" ", curve->poly_order[i]);
+av_log(ctx, AV_LOG_INFO, "}; poly_coef={ ");
+for (int i = 0; i < curve->num_pivots - 1; i++) {
+av_log(ctx, AV_LOG_INFO, "{%"PRIi64", %"PRIi64", %"PRIi64"} ",
+   curve->poly_coef[i][0],
+   curve->poly_coef[i][1],
+   curve->poly_coef[i][2]);
+}
+
+av_log(ctx, AV_LOG_INFO, "}; mmr_order={ ");
+for (int i = 0; i < curve->num_pivots - 1; i++)
+av_log(ctx, AV_LOG_INFO, "%"PRIu8" ", curve->mmr_order[i]);
+av_log(ctx, AV_LOG_INFO, "}; mmr_constant={ ");
+for (int i = 0; i < curve->num_pivots - 1; i++)
+av_log(ctx, AV_LOG_INFO, "%"PRIi64" ", curve->mmr_constant[i]);
+av_log(ctx, AV_LOG_INFO, "}; mmr_coef={ ");
+for (int i = 0; i < curve->num_pivots - 1; i++) {
+av_log(ctx, AV_LOG_INFO, "{");
+for (int j = 0; j < curve->mmr_order[i]; j++) {
+for (int k = 0; k < 7; k++)
+av_log(ctx, AV_LOG_INFO, "%"PRIi64" ", 
curve->mmr_coef[i][j][k]);
+}
+av_log(ctx, AV_LOG_INFO, "} ");
+}
+
+av_log(ctx, AV_LOG_INFO, "}; nlq_offset=%"PRIu64"; ", nlq->nlq_offset);

[FFmpeg-devel] [PATCH v2 1/4] lavu/frame: Add Dolby Vision metadata side data type

[Niklas Haas]

From: Niklas Haas 

Signed-off-by: Niklas Haas 
---
 doc/APIchanges|   3 ++
 libavutil/dovi_meta.c |  23 
 libavutil/dovi_meta.h | 122 ++
 libavutil/frame.c |   1 +
 libavutil/frame.h |   9 +++-
 libavutil/version.h   |   2 +-
 6 files changed, 158 insertions(+), 2 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 2914ad6734..422874e3b9 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -14,6 +14,9 @@ libavutil: 2021-04-27
 
 API changes, most recent first:
 
+2021-12-06 - xx - lavu 57.11.100 - frame.h
+  Add AV_FRAME_DATA_DOVI_RESHAPING.
+
 2021-11-xx - xx - lavfi 8.19.100 - avfilter.h
   Add AVFILTER_FLAG_METADATA_ONLY.
 
diff --git a/libavutil/dovi_meta.c b/libavutil/dovi_meta.c
index 7bd08f6c54..e2ef8ac3a4 100644
--- a/libavutil/dovi_meta.c
+++ b/libavutil/dovi_meta.c
@@ -33,3 +33,26 @@ AVDOVIDecoderConfigurationRecord *av_dovi_alloc(size_t *size)
 
 return dovi;
 }
+
+/* based on guesswork, see mkvtoolnix and dovi_tool */
+int av_dovi_profile(const AVDOVIRpuDataHeader *hdr)
+{
+switch (hdr->vdr_rpu_profile) {
+case 0:
+if (hdr->bl_video_full_range_flag)
+return 5;
+break;
+case 1:
+if (hdr->el_spatial_resampling_filter_flag && 
!hdr->disable_residual_flag) {
+if (hdr->vdr_bit_depth == 12) {
+return 7;
+} else {
+return 4;
+}
+} else {
+return 8;
+}
+}
+
+return 0; /* unknown */
+}
diff --git a/libavutil/dovi_meta.h b/libavutil/dovi_meta.h
index 299911d434..a3a97463ac 100644
--- a/libavutil/dovi_meta.h
+++ b/libavutil/dovi_meta.h
@@ -29,6 +29,7 @@
 
 #include 
 #include 
+#include "rational.h"
 
 /*
  * DOVI configuration
@@ -67,4 +68,125 @@ typedef struct AVDOVIDecoderConfigurationRecord {
  */
 AVDOVIDecoderConfigurationRecord *av_dovi_alloc(size_t *size);
 
+/**
+ * Dolby Vision RPU data header.
+ */
+typedef struct AVDOVIRpuDataHeader {
+uint8_t rpu_type;
+uint16_t rpu_format;
+uint8_t vdr_rpu_profile;
+uint8_t vdr_rpu_level;
+int chroma_resampling_explicit_filter_flag;
+uint8_t coef_data_type; /* informative, lavc always converts to fixed */
+uint8_t coef_log2_denom;
+uint8_t vdr_rpu_normalized_idc;
+int bl_video_full_range_flag;
+uint8_t bl_bit_depth; /* [8, 16] */
+uint8_t el_bit_depth; /* [8, 16] */
+uint8_t vdr_bit_depth; /* [8, 16] */
+int spatial_resampling_filter_flag;
+int el_spatial_resampling_filter_flag;
+int disable_residual_flag;
+} AVDOVIRpuDataHeader;
+
+/**
+ * Return the Dolby Vision profile number derived from a given RPU data header,
+ * or 0 for unknown/unrecognized profiles.
+ */
+int av_dovi_profile(const AVDOVIRpuDataHeader *hdr);
+
+enum AVDOVIMappingMethod {
+AV_DOVI_MAPPING_POLYNOMIAL = 0,
+AV_DOVI_MAPPING_MMR = 1,
+};
+
+/**
+ * Coefficients of a piece-wise function. The pieces of the function span the
+ * value ranges between two adjacent pivot values.
+ */
+#define FF_DOVI_MAX_PIECES 8
+typedef struct AVDOVIReshapingCurve {
+uint8_t num_pivots; /* [2, 9] */
+uint16_t pivots[FF_DOVI_MAX_PIECES + 1];/* sorted ascending */
+enum AVDOVIMappingMethod mapping_idc[FF_DOVI_MAX_PIECES];
+/* AV_DOVI_MAPPING_POLYNOMIAL */
+uint8_t poly_order[FF_DOVI_MAX_PIECES]; /* [1, 2] */
+int64_t poly_coef[FF_DOVI_MAX_PIECES][3];   /* x^0, x^1, x^2 */
+/* AV_DOVI_MAPPING_MMR */
+uint8_t mmr_order[FF_DOVI_MAX_PIECES];  /* [1, 3] */
+int64_t mmr_constant[FF_DOVI_MAX_PIECES];
+int64_t mmr_coef[FF_DOVI_MAX_PIECES][3/* order - 1 */][7];
+} AVDOVIReshapingCurve;
+
+enum AVDOVINLQMethod {
+AV_DOVI_NLQ_NONE = -1,
+AV_DOVI_NLQ_LINEAR_DZ = 0,
+};
+
+/**
+ * Coefficients of the non-linear inverse quantization. For the interpretation
+ * of these, see ETSI GS CCM 001.
+ */
+typedef struct AVDOVINLQParams {
+uint64_t nlq_offset;
+uint64_t vdr_in_max;
+/* AV_DOVI_NLQ_LINEAR_DZ */
+uint64_t linear_deadzone_slope;
+uint64_t linear_deadzone_threshold;
+} AVDOVINLQParams;
+
+/**
+ * Dolby Vision RPU data mapping parameters.
+ */
+typedef struct AVDOVIDataMapping {
+uint8_t vdr_rpu_id;
+uint8_t mapping_color_space;
+uint8_t mapping_chroma_format_idc;
+AVDOVIReshapingCurve curves[3]; /* per component */
+
+/* Non-linear inverse quantization */
+enum AVDOVINLQMethod nlq_method_idc;
+uint32_t num_x_partitions;
+uint32_t num_y_partitions;
+AVDOVINLQParams nlq[3]; /* per component */
+} AVDOVIDataMapping;
+
+typedef struct AVDOVIColorMetadata {
+uint8_t dm_metadata_id;
+int scene_refresh_flag;
+
+/**
+ * Coefficients of the custom Dolby Vision IPT-PQ matrices. These are to be
+ * used instead of the matrices indicated by the frame's colorspace tags.
+ * The output of rgb_to_lms_matrix is to be fed into a BT.2020 LMS->RGB
+ * matrix b

[FFmpeg-devel] [PATCH v2 4/4] lavc/hevcdec: Parse DOVI RPU NALs

[Niklas Haas]

From: Niklas Haas 

And expose the parsed values as frame side data.

Signed-off-by: Niklas Haas 
---
 libavcodec/hevcdec.c | 34 +++---
 libavcodec/hevcdec.h |  2 ++
 2 files changed, 33 insertions(+), 3 deletions(-)

diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 46d9edf8eb..926764bdf4 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -38,6 +38,7 @@
 #include "bswapdsp.h"
 #include "bytestream.h"
 #include "cabac_functions.h"
+#include "dovi.h"
 #include "golomb.h"
 #include "hevc.h"
 #include "hevc_data.h"
@@ -2967,6 +2968,19 @@ static int set_side_data(HEVCContext *s)
 s->rpu_buf = NULL;
 }
 
+if (s->dovi_ctx.mapping && s->dovi_ctx.color) {
+AVDOVIMetadata *dovi;
+AVFrameSideData *sd = av_frame_new_side_data(out, 
AV_FRAME_DATA_DOVI_METADATA,
+ sizeof(AVDOVIMetadata));
+if (!sd)
+return AVERROR(ENOMEM);
+
+dovi = (AVDOVIMetadata *) sd->data;
+memcpy(&dovi->header, &s->dovi_ctx.header, sizeof(dovi->header));
+memcpy(&dovi->mapping, s->dovi_ctx.mapping, sizeof(dovi->mapping));
+memcpy(&dovi->color, s->dovi_ctx.color, sizeof(dovi->color));
+}
+
 return 0;
 }
 
@@ -3298,16 +3312,23 @@ static int decode_nal_units(HEVCContext *s, const 
uint8_t *buf, int length)
 if (s->pkt.nb_nals > 1 && s->pkt.nals[s->pkt.nb_nals - 1].type == 
HEVC_NAL_UNSPEC62 &&
 s->pkt.nals[s->pkt.nb_nals - 1].size > 2 && 
!s->pkt.nals[s->pkt.nb_nals - 1].nuh_layer_id
 && !s->pkt.nals[s->pkt.nb_nals - 1].temporal_id) {
+H2645NAL *nal = &s->pkt.nals[s->pkt.nb_nals - 1];
 if (s->rpu_buf) {
 av_buffer_unref(&s->rpu_buf);
 av_log(s->avctx, AV_LOG_WARNING, "Multiple Dolby Vision RPUs found 
in one AU. Skipping previous.\n");
 }
 
-s->rpu_buf = av_buffer_alloc(s->pkt.nals[s->pkt.nb_nals - 1].raw_size 
- 2);
+s->rpu_buf = av_buffer_alloc(nal->raw_size - 2);
 if (!s->rpu_buf)
 return AVERROR(ENOMEM);
 
-memcpy(s->rpu_buf->data, s->pkt.nals[s->pkt.nb_nals - 1].raw_data + 2, 
s->pkt.nals[s->pkt.nb_nals - 1].raw_size - 2);
+memcpy(s->rpu_buf->data, nal->raw_data + 2, nal->raw_size - 2);
+ret = ff_dovi_rpu_parse(&s->dovi_ctx, nal->data + 2, nal->size - 2);
+if (ret < 0) {
+av_buffer_unref(&s->rpu_buf);
+av_log(s->avctx, AV_LOG_WARNING, "Error parsing DOVI NAL unit.\n");
+goto fail;
+}
 }
 
 /* decode the NAL units */
@@ -3325,7 +3346,7 @@ static int decode_nal_units(HEVCContext *s, const uint8_t 
*buf, int length)
 if (ret < 0) {
 av_log(s->avctx, AV_LOG_WARNING,
"Error parsing NAL unit #%d.\n", i);
-goto fail;
+/* ignore */
 }
 }
 
@@ -3553,6 +3574,7 @@ static av_cold int hevc_decode_free(AVCodecContext *avctx)
 
 pic_arrays_free(s);
 
+ff_dovi_ctx_unref(&s->dovi_ctx);
 av_buffer_unref(&s->rpu_buf);
 
 av_freep(&s->md5_ctx);
@@ -3637,6 +3659,7 @@ static av_cold int hevc_init_context(AVCodecContext 
*avctx)
 
 ff_bswapdsp_init(&s->bdsp);
 
+s->dovi_ctx.avctx = avctx;
 s->context_initialized = 1;
 s->eos = 0;
 
@@ -3745,6 +3768,10 @@ static int hevc_update_thread_context(AVCodecContext 
*dst,
 if (ret < 0)
 return ret;
 
+ret = ff_dovi_ctx_replace(&s->dovi_ctx, &s0->dovi_ctx);
+if (ret < 0)
+return ret;
+
 s->sei.frame_packing= s0->sei.frame_packing;
 s->sei.display_orientation  = s0->sei.display_orientation;
 s->sei.mastering_display= s0->sei.mastering_display;
@@ -3801,6 +3828,7 @@ static void hevc_decode_flush(AVCodecContext *avctx)
 HEVCContext *s = avctx->priv_data;
 ff_hevc_flush_dpb(s);
 ff_hevc_reset_sei(&s->sei);
+ff_dovi_ctx_unref(&s->dovi_ctx);
 av_buffer_unref(&s->rpu_buf);
 s->max_ra = INT_MAX;
 s->eos = 1;
diff --git a/libavcodec/hevcdec.h b/libavcodec/hevcdec.h
index 870ff178d4..5b04a8ad83 100644
--- a/libavcodec/hevcdec.h
+++ b/libavcodec/hevcdec.h
@@ -32,6 +32,7 @@
 #include "avcodec.h"
 #include "bswapdsp.h"
 #include "cabac.h"
+#include "dovi.h"
 #include "get_bits.h"
 #include "hevcpred.h"
 #include "h2645_parse.h"
@@ -574,6 +575,7 @@ typedef struct HEVCContext {
 int nuh_layer_id;
 
 AVBufferRef *rpu_buf;   ///< 0 or 1 Dolby Vision RPUs.
+DOVIContext dovi_ctx;   ///< Dolby Vision decoding context
 } HEVCContext;
 
 /**
-- 
2.34.1

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

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

Re: [FFmpeg-devel] [PATCH 001/279] Add a new channel layout API

[Marton Balint]

On Wed, 8 Dec 2021, Lynne wrote:


8 Dec 2021, 10:22 by h.lepp...@gmail.com:


On Wed, Dec 8, 2021 at 10:14 AM Lynne  wrote:



8 Dec 2021, 02:06 by jamr...@gmail.com:



+enum AVChannel {
+///< Invalid channel index
+AV_CHAN_NONE = -1,
+AV_CHAN_FRONT_LEFT,



No, not the pixfmt mistake again. Set AV_CHAN_NONE to 0,
the rest can follow. Or keep AV_CHAN_NONE to -1
and add a new AV_CHAN_UNSPECIFIED as 0.



Care to elaborate on the reasons of this opinion? Using -1 as invalid
and 0...x as valid entries seems quite reasonable to me.



Zero-initialization. I've had issues in the past telling
YUV420P from .


It is convenient to be able to set the channel 
layout mask by a simple byte shift of the ID-s.


AV_CH_FRONT_LEFT = 1 << AV_CHAN_FRONT_LEFT.

So I'd say that is the reason that it is designed that way, because this 
way existing channel layout masks can be kept without breaking ABI.


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 001/279] Add a new channel layout API

[Lynne]

8 Dec 2021, 10:22 by h.lepp...@gmail.com:

> On Wed, Dec 8, 2021 at 10:14 AM Lynne  wrote:
>
>>
>> 8 Dec 2021, 02:06 by jamr...@gmail.com:
>>
>> >
>> > +enum AVChannel {
>> > +///< Invalid channel index
>> > +AV_CHAN_NONE = -1,
>> > +AV_CHAN_FRONT_LEFT,
>> >
>>
>> No, not the pixfmt mistake again. Set AV_CHAN_NONE to 0,
>> the rest can follow. Or keep AV_CHAN_NONE to -1
>> and add a new AV_CHAN_UNSPECIFIED as 0.
>>
>
> Care to elaborate on the reasons of this opinion? Using -1 as invalid
> and 0...x as valid entries seems quite reasonable to me.
>

Zero-initialization. I've had issues in the past telling
YUV420P from .
___
ffmpeg-devel mailing list
ffmpeg-devel@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 001/279] Add a new channel layout API

[Hendrik Leppkes]

On Wed, Dec 8, 2021 at 10:14 AM Lynne  wrote:
>
> 8 Dec 2021, 02:06 by jamr...@gmail.com:
>
> >
> > +enum AVChannel {
> > +///< Invalid channel index
> > +AV_CHAN_NONE = -1,
> > +AV_CHAN_FRONT_LEFT,
> >
>
> No, not the pixfmt mistake again. Set AV_CHAN_NONE to 0,
> the rest can follow. Or keep AV_CHAN_NONE to -1
> and add a new AV_CHAN_UNSPECIFIED as 0.
>

Care to elaborate on the reasons of this opinion? Using -1 as invalid
and 0...x as valid entries seems quite reasonable to me.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@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 001/279] Add a new channel layout API

[Lynne]

8 Dec 2021, 02:06 by jamr...@gmail.com:

>  
> +enum AVChannel {
> +///< Invalid channel index
> +AV_CHAN_NONE = -1,
> +AV_CHAN_FRONT_LEFT,
>

No, not the pixfmt mistake again. Set AV_CHAN_NONE to 0,
the rest can follow. Or keep AV_CHAN_NONE to -1
and add a new AV_CHAN_UNSPECIFIED as 0.


> +AV_CHAN_FRONT_RIGHT,
> +AV_CHAN_FRONT_CENTER,
> +AV_CHAN_LOW_FREQUENCY,
> +AV_CHAN_BACK_LEFT,
> +AV_CHAN_BACK_RIGHT,
> +AV_CHAN_FRONT_LEFT_OF_CENTER,
> +AV_CHAN_FRONT_RIGHT_OF_CENTER,
> +AV_CHAN_BACK_CENTER,
> +AV_CHAN_SIDE_LEFT,
> +AV_CHAN_SIDE_RIGHT,
> +AV_CHAN_TOP_CENTER,
> +AV_CHAN_TOP_FRONT_LEFT,
> +AV_CHAN_TOP_FRONT_CENTER,
> +AV_CHAN_TOP_FRONT_RIGHT,
> +AV_CHAN_TOP_BACK_LEFT,
> +AV_CHAN_TOP_BACK_CENTER,
> +AV_CHAN_TOP_BACK_RIGHT,
> +/** Stereo downmix. */
> +AV_CHAN_STEREO_LEFT = 29,
> +/** See above. */
> +AV_CHAN_STEREO_RIGHT,
> +AV_CHAN_WIDE_LEFT,
> +AV_CHAN_WIDE_RIGHT,
> +AV_CHAN_SURROUND_DIRECT_LEFT,
> +AV_CHAN_SURROUND_DIRECT_RIGHT,
> +AV_CHAN_LOW_FREQUENCY_2,
> +AV_CHAN_TOP_SIDE_LEFT,
> +AV_CHAN_TOP_SIDE_RIGHT,
> +AV_CHAN_BOTTOM_FRONT_CENTER,
> +AV_CHAN_BOTTOM_FRONT_LEFT,
> +AV_CHAN_BOTTOM_FRONT_RIGHT,
> +
> +/** Channel is empty can be safely skipped. */
> +AV_CHAN_SILENCE = 64,
> +};
>

Why is AV_CHAN_SILENCE set to 64? If it's special,
set it to follow just after AV_CHAN_NONE or
AV_CHAN_UNSPECIFIED.

Finally, consider adding an AV_CHAN_NB at
the end, not part of the API, for jut in case.
___
ffmpeg-devel mailing list
ffmpeg-devel@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 001/279] Add a new channel layout API

[Lynne]

8 Dec 2021, 02:06 by jamr...@gmail.com:

> From: Anton Khirnov 
>
> The new API is more extensible and allows for custom layouts.
> More accurate information is exported, eg for decoders that do not
> set a channel layout, lavc will not make one up for them.
>
> Deprecate the old API working with just uint64_t bitmasks.
>
> Expanded and completed by Vittorio Giovara 
> and James Almer .
> Signed-off-by: Vittorio Giovara 
> Signed-off-by: James Almer 
> ---
>  libavutil/channel_layout.c | 498 ++--
>  libavutil/channel_layout.h | 510 ++---
>  libavutil/version.h|   1 +
>  3 files changed, 906 insertions(+), 103 deletions(-)
>  
>  /**
>  * @}
> @@ -128,6 +199,157 @@ enum AVMatrixEncoding {
>  AV_MATRIX_ENCODING_NB
>  };
>  
> +/**
> + * @}
> + */
> +
> +/**
> + * An AVChannelCustom defines a single channel within a custom order layout
> + *
> + * Unlike most structures in FFmpeg, sizeof(AVChannelCustom) is a part of the
> + * public ABI.
> + *
> + * No new fields may be added to it without a major version bump.
> + */
> +typedef struct AVChannelCustom {
> +enum AVChannel id;
> +} AVChannelCustom;
>

Consider adding a 25-byte or so of a description field string here that
would also be copied if the frame/layout is copied?
That way, users can assign a description label to each channel,
for example labeling each channel in a 255 channel custom layout
Opus stream used in production at a venue somewhere.
Also, consider additionally reserving 16-bytes here, just in case.

Rest looks fine.
___
ffmpeg-devel mailing list
ffmpeg-devel@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 181/279] aac: convert to new channel layout API

[Lynne]

8 Dec 2021, 02:06 by jamr...@gmail.com:

> From: Anton Khirnov 
>
> Signed-off-by: Vittorio Giovara 
> Signed-off-by: Anton Khirnov 
> Signed-off-by: James Almer 
> ---
>  libavcodec/aac.h  | 11 --
>  libavcodec/aac_ac3_parser.c   |  9 +++--
>  libavcodec/aaccoder.c | 10 +++---
>  libavcodec/aaccoder_twoloop.h |  4 +--
>  libavcodec/aacdec_template.c  | 59 
>  libavcodec/aacenc.c   | 13 ---
>  libavcodec/aacenc.h   | 64 ++-
>  libavcodec/aacenctab.h| 16 -
>  libavcodec/aacpsy.c   |  8 ++---
>  libavcodec/psymodel.c |  8 ++---
>  libavcodec/psymodel.h |  2 +-
>  11 files changed, 125 insertions(+), 79 deletions(-)
>
> diff --git a/libavcodec/aac.h b/libavcodec/aac.h
> index 1e82f56ca9..53be546857 100644
> --- a/libavcodec/aac.h
> +++ b/libavcodec/aac.h
> @@ -32,6 +32,7 @@
>  
>  
>  #include "aac_defines.h"
> +#include "libavutil/channel_layout.h"
>  #include "libavutil/float_dsp.h"
>  #include "libavutil/fixed_dsp.h"
>  #include "libavutil/mem_internal.h"
> @@ -125,8 +126,7 @@ typedef struct OutputConfiguration {
>  MPEG4AudioConfig m4ac;
>  uint8_t layout_map[MAX_ELEM_ID*4][3];
>  int layout_map_tags;
> -int channels;
> -uint64_t channel_layout;
> +AVChannelLayout ch_layout;
>  enum OCStatus status;
>  } OutputConfiguration;
>  
> @@ -288,6 +288,11 @@ typedef struct ChannelElement {
>  SpectralBandReplication sbr;
>  } ChannelElement;
>  
> +enum AACOutputChannelOrder {
> +CHANNEL_ORDER_DEFAULT,
> +CHANNEL_ORDER_CODED,
> +};
> +
>  /**
>  * main AAC context
>  */
> @@ -352,6 +357,8 @@ struct AACContext {
>  int dmono_mode;  ///< 0->not dmono, 1->use first channel, 2->use second 
> channel
>  /** @} */
>  
> +enum AACOutputChannelOrder output_channel_order;
> +
>  DECLARE_ALIGNED(32, INTFLOAT, temp)[128];
>  
>  OutputConfiguration oc[2];
> diff --git a/libavcodec/aac_ac3_parser.c b/libavcodec/aac_ac3_parser.c
> index e84d30aea2..cd54a0a3e2 100644
> --- a/libavcodec/aac_ac3_parser.c
> +++ b/libavcodec/aac_ac3_parser.c
> @@ -90,8 +90,13 @@ get_next:
>  if (avctx->codec_id != AV_CODEC_ID_AAC) {
>  avctx->sample_rate = s->sample_rate;
>  if (!CONFIG_EAC3_DECODER || avctx->codec_id != AV_CODEC_ID_EAC3) {
> -avctx->channels = s->channels;
> -avctx->channel_layout = s->channel_layout;
> +av_channel_layout_uninit(&avctx->ch_layout);
> +if (s->channel_layout) {
> +av_channel_layout_from_mask(&avctx->ch_layout, 
> s->channel_layout);
> +} else {
> +avctx->ch_layout.order   = AV_CHANNEL_ORDER_UNSPEC;
> +avctx->ch_layout.nb_channels = s->channels;
> +}
>  }
>  s1->duration = s->samples;
>  avctx->audio_service_type = s->service_type;
> diff --git a/libavcodec/aaccoder.c b/libavcodec/aaccoder.c
> index 7bbd4d5b2e..f460479498 100644
> --- a/libavcodec/aaccoder.c
> +++ b/libavcodec/aaccoder.c
> @@ -397,7 +397,7 @@ static void search_for_quantizers_fast(AVCodecContext 
> *avctx, AACEncContext *s,
>  const float lambda)
>  {
>  int start = 0, i, w, w2, g;
> -int destbits = avctx->bit_rate * 1024.0 / avctx->sample_rate / 
> avctx->channels * (lambda / 120.f);
> +int destbits = avctx->bit_rate * 1024.0 / avctx->sample_rate / 
> avctx->ch_layout.nb_channels * (lambda / 120.f);
>  float dists[128] = { 0 }, uplims[128] = { 0 };
>  float maxvals[128];
>  int fflag, minscaler;
> @@ -556,7 +556,7 @@ static void search_for_pns(AACEncContext *s, 
> AVCodecContext *avctx, SingleChanne
>  const float pns_transient_energy_r = FFMIN(0.7f, lambda / 140.f);
>  
>  int refbits = avctx->bit_rate * 1024.0 / avctx->sample_rate
> -/ ((avctx->flags & AV_CODEC_FLAG_QSCALE) ? 2.0f : avctx->channels)
> +/ ((avctx->flags & AV_CODEC_FLAG_QSCALE) ? 2.0f : 
> avctx->ch_layout.nb_channels)
>  * (lambda / 120.f);
>  
>  /** Keep this in sync with twoloop's cutoff selection */
> @@ -564,7 +564,7 @@ static void search_for_pns(AACEncContext *s, 
> AVCodecContext *avctx, SingleChanne
>  int prev = -1000, prev_sf = -1;
>  int frame_bit_rate = (avctx->flags & AV_CODEC_FLAG_QSCALE)
>  ? (refbits * rate_bandwidth_multiplier * avctx->sample_rate / 1024)
> -: (avctx->bit_rate / avctx->channels);
> +: (avctx->bit_rate / avctx->ch_layout.nb_channels);
>  
>  frame_bit_rate *= 1.15f;
>  
> @@ -693,14 +693,14 @@ static void mark_pns(AACEncContext *s, AVCodecContext 
> *avctx, SingleChannelEleme
>  const float pns_transient_energy_r = FFMIN(0.7f, lambda / 140.f);
>  
>  int refbits = avctx->bit_rate * 1024.0 / avctx->sample_rate
> -/ ((avctx->flags & AV_CODEC_FLAG_QSCALE) ? 2.0f : avctx->channels)
> +/ ((avctx->flags & AV_CODEC_FLAG_QSCALE) ? 2.0f : 
> avctx->ch_layout.nb_channels)
>  * (lambda / 120.f);
>  
>  /** Keep this in sync with twoloop's cutoff selection */
>  float rate_b

Re: [FFmpeg-devel] [PATCH 000/279] New channel layout API

[Paul B Mahol]

On Wed, Dec 8, 2021 at 2:07 AM James Almer  wrote:

> This is an updated and rebased version of the API that was sent to this
> mailing
> list about two years ago. It expands it with some new helpers, implements
> some
> changes that allows further extensibility for new features down the line,
> and
> finishes porting all missing modules and those introduced since 2019.
>
> I'm sending a reduced amount of patches to not spam the ML too much. In
> total
> it's 279 patches, the bulk being one per module ported, which it's what i'm
> skipping.
> This reduced set will obviously not apply as is, so you can find the
> entire set
> in https://github.com/jamrial/FFmpeg/commits/channel_layout


How are custom channel layouts defined?

I remember that if they are defined by '+', some other need to be used to
split multiple layouts when used at once.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: fix DNxHD GC ULs

[Paul B Mahol]

This is unacceptable behavior for maintainer.

On Wed, Dec 8, 2021 at 12:13 AM Tomas Härdin  wrote:

> fre 2021-12-03 klockan 09:38 + skrev Nicolas Gaullier:
> > > Please add a reference to the relevant SMPTE document in the
> > > comment, or perhaps at the list of references at the start of the
> > > file
> > >
> > > /Tomas
> >
> > I have added the reference to ST2019-4 for "VC3 mapping", so that
> > should be ok for generic standard files.
> > It seems redundant for me, but if you want, I could add the link to
> > the online register where the container ul is public ?
> > https://registry.smpte-ra.org/apps/pages/
> >
> > Concerning the essence key, it is more tricky because of AVID in the
> > place...
> > To start with, apart AVID, all frame-wrapped samples I have (I can
> > share them with you but not all of them publicly), do respect the
> > standard
> > - frame-wrapped : ARRI, Adobe Media Encoder, Harmonic : always 0x0C
> > ("DNxHD" frame-mapping)
> > There are up to date publicly available ARRI samples where 0x0C is
> > used here:
> >
> https://www.arri.com/en/learn-help/learn-help-camera-system/camera-sample-footage
> >
> > But I also have an AVID Op1a file where the value 0x05 is used
> > ("MPEG" frame-mapping, ie. s381m).
> > And concerning OPAtom, Philip de Nier has an AVID sample where the
> > value 0x06 is used ("MPEG" clip-wrapping).
> >
> > So, what is apparent at the end is that :
> > - apart from AVID, the standard values 0x0c/0x0d are used
> > - AVID uses the values from the older "MPEG mapping" (ie smpte 381m)
> >
> > Now :
> > - currently ffmpeg uses 0x05 for OPatom which does not follow any
> > implementation and seems bad
> > - it seems there is a consensus (incl. AVID) to always use 0x05 or
> > 0x0C for frame-wrapping and 0x06 or 0x0d for clip-wrapping (OPAtom)
> > => follow either s381m or st2019-4
> > - it seems clear ffmpeg shall take the "standard-flavor" for generic
> > OP's, so 0x0C for frame-based wrapping
> > - it is less clear about OPAtom which is rather an AVID-hack-thing,
> > but it should be moved to either 0x06 or 0x0d
> > - I have discussed this with philip de nier, and bmx (a reference
> > software in my opinion) will stick to the AVID form, so 0x06. And I
> > think it is reasonable, since OPAtom/Avid are almost the same damn
> > thing
> >
> > Note: no matter the essence key, the link between the tracks and the
> > body with the TrackNumber always work, so it seems there are not much
> > interoperability issues with it.
>
> Seems I missed the reference to the VC-3 spec somehow, sorry. Since it
> is Matthieu Bouron who added this initially, you should really talk to
> him. I care less about mxfenc than I do mxfdec, since the latter can
> more easily induce CVEs.
>
> That said, if we want this to work correctly for everyone then we need
> a proper set of tests. We also need to go over all the specs, and what
> all implementations are currently doing. Which is a lot of work. Or a
> lot of billable hours!
>
> This is why I've said for years now that we should delete mxfenc and
> just bring in bmx. We don't need what little free software people there
> are who know MXF to keep maintaining two codebases.
>
> We could just bring in bmx as a subtree and be done with it. Delete all
> MXF code native to FFmpeg, put all effort into bmx. People in this
> project suffer from the belief that code is valuable rather than a
> liability. Worse is not better. Correct is better.
>
> /Tomas
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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