[FFmpeg-devel] Compiling Error within MSYS2-mingw32-environment

2023-02-27 Thread Reiner Sombrowsky 

Hello *ffmpeg* developers,
I compile *ffmpeg* sources within a *Windows 11 MSYS2*
*mingw64* and *mingw32* environment for using in my
applications that can be downloaded for free
on my homepage***www.somby.de *.
Since the last 2 months I have problems with compiling
within *mingw32* environment. The compiling within *mingw64*
environment is ok.
I use the *git repository* of *ffmpeg*. My last checked
*HEAD -> master* revision was *ac6eec1fc2*.
Following *MSYS2* packets are installed:
*pacman -S --needed base-devel \**
**  mingw-w64-i686-gcc \**
**  mingw-w64-x86_64-gcc \**
**  mingw-w64-i686-toolchain \**
**  mingw-w64-x86_64-toolchain \**
**  git \**
**  subversion \**
**  mercurial \**
**  mingw-w64-i686-cmake \**
**  mingw-w64-x86_64-cmake \**
**  autoconf \**
**  mingw-w64-i686-gtk3 \**
**  mingw-w64-x86_64-gtk3 \**
**  yasm \**
**  nasm \**
**  perl \**
**  diffutils \**
**  make \**
**  pkgconf \**
**  mingw-w64-i686-SDL2 \**
**  mingw-w64-x86_64-SDL2 \**
**  mingw-w64-i686-ffmpeg \**
**  mingw-w64-x86_64-ffmpeg *


The current versions of
*mingw-w64-i686-gcc* and *mingw-w64-x86_64-gcc* are
*12.2.0-10*.

My current *ffmpeg-configuration* is:
*./configure --enable-gpl \**
** --enable-libmp3lame \**
** --enable-libxvid \**
** --enable-libx264 \**
** --enable-libx265 \**
** --enable-libvorbis \**
** --disable-static \**
** --enable-shared \**
** --enable-ffplay \**
** --disable-debug \**
** --enable-vulkan \**
** --enable-version3 \**
** --enable-opengl \**
** --prefix="$HOME/ffmpeg_build"*

If I compile within the *mingw32* environment
the following error occurs during *make*:
*...**
**CC  libavcodec/h2645_sei.o**
**CC  libavcodec/h2645_vui.o**
**CC  libavcodec/h2645data.o**
**CC  libavcodec/h264_cabac.o**
**In file included from libavcodec/cabac_functions.h:49,**
** from libavcodec/h264_cabac.c:36:**
**In function 'get_cabac_inline_x86',**
**    inlined from 'get_cabac' at libavcodec/cabac_functions.h:145:12,**
**    inlined from 'decode_cabac_mb_intra4x4_pred_mode' at 
libavcodec/h264_cabac.c:1377:9,**
**    inlined from 'ff_h264_decode_mb_cabac' at 
libavcodec/h264_cabac.c:2081:32:**
**libavcodec/x86/cabac.h:199:5: error: 'asm' operand has impossible 
constraints**

**  199 | __asm__ volatile(**
**  | ^~~**
**libavcodec/x86/cabac.h:199:5: error: 'asm' operand has impossible 
constraints**
**libavcodec/x86/cabac.h:199:5: error: 'asm' operand has impossible 
constraints**
**libavcodec/x86/cabac.h:199:5: error: 'asm' operand has impossible 
constraints**

**make: *** [ffbuild/common.mak:81: libavcodec/h264_cabac.o] Error 1*

Perhaps you can fix this error in the
next revisions.

Best regards
Reiner Sombrowsky
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Bump major version of swresample

2023-02-27 Thread Michael Niedermayer 
essOn Sat, Feb 25, 2023 at 12:03:02AM +0800, Wang Bin wrote:
> 

>  version_major.h |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> a87056c2fe65d68b2cf5d1de06be28ea40c69b73  
> 0001-Bump-major-version-of-swresample.patch
> From e3e6a3833f2fba743ee9c05962e804e9e570dd75 Mon Sep 17 00:00:00 2001
> From: wang-bin 
> Date: Fri, 24 Feb 2023 23:54:51 +0800
> Subject: [PATCH] Bump major version of swresample
> 
> ---
>  libswresample/version_major.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libswresample/version_major.h b/libswresample/version_major.h
> index 7f265c2073..dd13f2bbe3 100644
> --- a/libswresample/version_major.h
> +++ b/libswresample/version_major.h
> @@ -26,6 +26,6 @@
>   * Libswresample version macros
>   */
>  
> -#define LIBSWRESAMPLE_VERSION_MAJOR   4
> +#define LIBSWRESAMPLE_VERSION_MAJOR   5

No oppinion if this should be changed now before 6.0 or not
but if its done it should be done on master and release/6.0 at the same time
and LIBSWRESAMPLE_VERSION_MINOR needs to be reset too while
LIBSWRESAMPLE_VERSION_MINOR needs to be +1 on master compared to release/6.0

oppinon from others is welcome here. Iam not a user of the releases so its
hard for me to really guess which way is better. Its a little messy to
change now

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
than the original author, trying to rewrite it will not make it better.


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

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

Re: [FFmpeg-devel] Bump major version of swresample

2023-02-27 Thread zhilizhao(赵志立) 



> On Feb 27, 2023, at 18:03, Michael Niedermayer  wrote:
> 
> essOn Sat, Feb 25, 2023 at 12:03:02AM +0800, Wang Bin wrote:
>> 
> 
>> version_major.h |2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> a87056c2fe65d68b2cf5d1de06be28ea40c69b73  
>> 0001-Bump-major-version-of-swresample.patch
>> From e3e6a3833f2fba743ee9c05962e804e9e570dd75 Mon Sep 17 00:00:00 2001
>> From: wang-bin 
>> Date: Fri, 24 Feb 2023 23:54:51 +0800
>> Subject: [PATCH] Bump major version of swresample
>> 
>> ---
>> libswresample/version_major.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/libswresample/version_major.h b/libswresample/version_major.h
>> index 7f265c2073..dd13f2bbe3 100644
>> --- a/libswresample/version_major.h
>> +++ b/libswresample/version_major.h
>> @@ -26,6 +26,6 @@
>>  * Libswresample version macros
>>  */
>> 
>> -#define LIBSWRESAMPLE_VERSION_MAJOR   4
>> +#define LIBSWRESAMPLE_VERSION_MAJOR   5
> 
> No oppinion if this should be changed now before 6.0 or not
> but if its done it should be done on master and release/6.0 at the same time
> and LIBSWRESAMPLE_VERSION_MINOR needs to be reset too while
> LIBSWRESAMPLE_VERSION_MINOR needs to be +1 on master compared to release/6.0
> 
> oppinon from others is welcome here. Iam not a user of the releases so its
> hard for me to really guess which way is better. Its a little messy to
> change now

There is no major changes since last bump. Is it an option to keep current
major version?

> 
> thx
> 
> [...]
> 
> -- 
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> Rewriting code that is poorly written but fully understood is good.
> Rewriting code that one doesnt understand is a sign that one is less smart
> than the original author, trying to rewrite it will not make it better.
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] Bump major version of swresample

2023-02-27 Thread James Almer 

On 2/27/2023 7:03 AM, Michael Niedermayer wrote:

essOn Sat, Feb 25, 2023 at 12:03:02AM +0800, Wang Bin wrote:





  version_major.h |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
a87056c2fe65d68b2cf5d1de06be28ea40c69b73  
0001-Bump-major-version-of-swresample.patch
 From e3e6a3833f2fba743ee9c05962e804e9e570dd75 Mon Sep 17 00:00:00 2001
From: wang-bin 
Date: Fri, 24 Feb 2023 23:54:51 +0800
Subject: [PATCH] Bump major version of swresample

---
  libswresample/version_major.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libswresample/version_major.h b/libswresample/version_major.h
index 7f265c2073..dd13f2bbe3 100644
--- a/libswresample/version_major.h
+++ b/libswresample/version_major.h
@@ -26,6 +26,6 @@
   * Libswresample version macros
   */
  
-#define LIBSWRESAMPLE_VERSION_MAJOR   4

+#define LIBSWRESAMPLE_VERSION_MAJOR   5


No oppinion if this should be changed now before 6.0 or not
but if its done it should be done on master and release/6.0 at the same time
and LIBSWRESAMPLE_VERSION_MINOR needs to be reset too while
LIBSWRESAMPLE_VERSION_MINOR needs to be +1 on master compared to release/6.0

oppinon from others is welcome here. Iam not a user of the releases so its
hard for me to really guess which way is better. Its a little messy to
change now

thx


I don't think it's a good idea to do it now. No API was removed from it 
so leaving the major as is should be 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 v2 1/8] avformat/movenc: add PCM in mp4 support

2023-02-27 Thread Tomas Härdin 
lör 2023-02-25 klockan 02:28 +0800 skrev Zhao Zhili:
> From: Zhao Zhili 
> 
> It's defined by ISO/IEC 23003-5.
> 
> Fixes ticket #10185
> 
> Signed-off-by: Zhao Zhili 
> ---
>  libavformat/movenc.c | 60
> +++-
>  1 file changed, 59 insertions(+), 1 deletion(-)

Looks OK

/Tomas

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

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

Re: [FFmpeg-devel] [PATCH v2 2/8] avformat/mov: check that pcmC box is of the expected type

2023-02-27 Thread Tomas Härdin 
lör 2023-02-25 klockan 02:28 +0800 skrev Zhao Zhili:
> From: Jan Ekström 
> 
> As per 23003-5:2020 this box is defined as
> PCMConfig extends FullBox(‘pcmC’, version = 0, 0), which means
> that version is 0 and flags should be zero.
> ---
>  libavformat/mov.c | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)

Probably OK, but I'm not versed i the version problems relating to this
tag. Should we also support version > 0?

/Tomas

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

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

Re: [FFmpeg-devel] [PATCH v2 3/8] avformat/mov: base the endianness on just the LSB

2023-02-27 Thread Tomas Härdin 
lör 2023-02-25 klockan 02:28 +0800 skrev Zhao Zhili:
> From: Jan Ekström 
> 
> As per 23003-5:2020, the rest of the bits are reserved, and thus
> in the future they may be utilized for something else.
> 
> Quote:
> format_flags is a field of flags that modify the default PCM sample
> format.
> Undefined flags are reserved and shall be zero. The following flag is
> defined:
>   0x01 indicates little-endian format. If not present, big-endian
> format is used.
> ---
>  libavformat/mov.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index cdd44a9e44..a9911c0f79 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -1608,7 +1608,7 @@ static int mov_read_pcmc(MOVContext *c,
> AVIOContext *pb, MOVAtom atom)
>  }
>  
>  format_flags = avio_r8(pb);
> -    if (format_flags == 1) // indicates little-endian format. If not
> present, big-endian format is used
> +    if (format_flags & 1) // indicates little-endian format. If not
> present, big-endian format is used

Should be OK.

/Tomas

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

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

Re: [FFmpeg-devel] [PATCH v2 4/8] avformat/mov: fix ISO/IEC 23003-5 support

2023-02-27 Thread Tomas Härdin 
lör 2023-02-25 klockan 02:28 +0800 skrev Zhao Zhili:
> From: Zhao Zhili 
> 
> Missing floating-point formats support.
> 
> Signed-off-by: Zhao Zhili 
> ---
>  libavformat/mov.c | 47
> +++
>  1 file changed, 47 insertions(+)

Should still be OK

/Tomas

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

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

Re: [FFmpeg-devel] [PATCH v2 6/8] avformat/mov: parse ISO-14496-12 ChannelLayout

2023-02-27 Thread Tomas Härdin 
lör 2023-02-25 klockan 02:28 +0800 skrev Zhao Zhili:
> 
> +    if (!layout) {
> +    uint8_t *positions = av_malloc(st->codecpar-
> >ch_layout.nb_channels);

Could be allocated on the stack, either using a fixed-size array, a VLA
or alloca(), thus avoiding a heap allocation

/Tomas

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

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

Re: [FFmpeg-devel] [PATCH v2 5/8] avformat/isom_tags: remove ipcm from movaudio_tags

2023-02-27 Thread Tomas Härdin 
lör 2023-02-25 klockan 02:28 +0800 skrev Zhao Zhili:
> From: Zhao Zhili 
> 
> ipcm is defined by ISO/IEC 23003-5, not defined by quicktime. After
> adding ISO/IEC 23003-5 support, we don't need it for ticket #9219.
> 
> Signed-off-by: Zhao Zhili 
> ---
>  libavformat/isom_tags.c | 2 --
>  1 file changed, 2 deletions(-)

Should also still be OK

/Tomas

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

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

Re: [FFmpeg-devel] [PATCH v2 7/8] avformat/movenc: write ChannelLayout box for PCM

2023-02-27 Thread Tomas Härdin 
lör 2023-02-25 klockan 02:28 +0800 skrev Zhao Zhili:
> 
> +static int mov_write_chnl_tag(AVFormatContext *s, AVIOContext *pb,
> MOVTrack *track)
> +{
> +    int64_t pos = avio_tell(pb);
> +    int config = 0;
> +    int ret;
> +    uint8_t *speaker_pos = NULL;

Could also be allocated on the stack

/Tomas

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

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

Re: [FFmpeg-devel] [PATCH] Fix broken build on Android due to broken asm-generic/termbits.h include

2023-02-27 Thread zhilizhao(赵志立) 


> On Feb 23, 2023, at 23:01, Hendrik Leppkes  wrote:
> 
> On Thu, Feb 23, 2023 at 3:37 PM copypaste  wrote:
>> It gets included because this platform does indeed have Video4Linux so some 
>> of the aarch64 stuff is relevant. Furthermore I think that the HEVC stuff 
>> includes it.
>> 
> 
> If its relevant for V4L or other hardware integration is fine and all
> ... but the real question is, how does it end up in aaccoder.c and
> other files entirely unrelated to video or hardware? And can we just
> get it out of those?

I know this issue exists for a long time. But I can’t reproduce it
these days.

https://github.com/android/ndk/issues/630
https://trac.ffmpeg.org/ticket/7130

The ‘B0’ macro comes from , which is defined by
asm-generic/termbits.h.  is included by libavutil/timer.h.
Thanks to the cleanup work done by Andreas Rheinhardt, the conflicts
has been reduced a lot, I think that’s why I didn’t get build errors.

Google suggests FFmpeg to fix the code problem, while NDK has
break more than one projects, see

https://github.com/jupyter-xeus/cpp-terminal/issues/35 

You can reproduce the build error with:

$ cat foo.c 
#include 

int main()
{
int B0 = 123;
}

$ make foo
cc foo.c   -o foo
foo.c:5:9: error: expected identifier or '('
int B0 = 123;
^
/data/data/com.termux/files/usr/include/asm-generic/termbits.h:118:12: note: 
expanded from macro 'B0'
#define B0 000
   ^
1 error generated.
make: *** [: foo] Error 1

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

___
ffmpeg-devel mailing list
ffmpeg-devel@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] Bump major version of swresample

2023-02-27 Thread Wang Bin 
>
>
> There is no major changes since last bump. Is it an option to keep current
> major version?
>
>
libpostproc changes less
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v2 2/8] avformat/mov: check that pcmC box is of the expected type

2023-02-27 Thread Jan Ekström 
On Mon, Feb 27, 2023 at 3:36 PM Tomas Härdin  wrote:
>
> lör 2023-02-25 klockan 02:28 +0800 skrev Zhao Zhili:
> > From: Jan Ekström 
> >
> > As per 23003-5:2020 this box is defined as
> > PCMConfig extends FullBox(‘pcmC’, version = 0, 0), which means
> > that version is 0 and flags should be zero.
> > ---
> >  libavformat/mov.c | 13 +++--
> >  1 file changed, 11 insertions(+), 2 deletions(-)
>
> Probably OK, but I'm not versed i the version problems relating to this
> tag. Should we also support version > 0?
>
> /Tomas

pcmC only has version 0 and flags coded to zero, thankfully

The channel layout box is where the "fun" begins with version 1 as
well as this following quote:

> When authoring, version 1 should be preferred over version 0.
> Version 1 conveys the channel ordering, which is not always the case for
> version 0. Version 1 should be used to convey the base channel count for DRC.

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

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

Re: [FFmpeg-devel] [PATCH v4] avcodec/pngdec: read colorspace info when decoding with AVDISCARD_ALL

2023-02-27 Thread Leo Izen 

On 2/21/23 17:35, Leo Izen wrote:

These chunks are lightweight and it's useful information to have when
running ffmpeg -i or ffprobe, for example.
---
  libavcodec/pngdec.c  | 136 ++-
  tests/ref/fate/png-icc   |   8 +--
  tests/ref/fate/png-side-data |   2 +-
  3 files changed, 91 insertions(+), 55 deletions(-)

diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c


I will push this soon-ish if there's no other objections.

- Leo Izen (thebombzen)


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

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

[FFmpeg-devel] [PATCH 1/2] avcodec/avutil: move dynamic HDR metadata parsing to libavutil

2023-02-27 Thread Raphaël Zumer 


This patch set implements serialization for HDR10+ dynamic metadata 
(AVDynamicHDRPlus), which is the inverse operation of the existing 
ff_parse_itu_t_t35_to_dynamic_hdr10_plus() function. It also moves both 
functions from libavcodec to libavutil and makes them public. For 
consistency, the equivalent vivid HDR parsing function is also migrated, 
but I did not implement serialization for it. Finally, the patch renames 
those functions to av_dynamic_hdr_plus_from_t35() (for parsing) and 
av_dynamic_hdr_plus_to_t35 (for serialization), with the equivalent 
change being made for vivid as well.


The motivation for this change is to allow users to easily convert 
HDR10+ side data (which is parsed into AVDynamicHDRPlus) to a standard 
ITU-T T.35 payload that can be passed directly to applications that 
expect HDR10+ dynamic metadata in that format (e.g. x265 and rav1e 
encoders).


The return value of the serialization function is AVBufferRef*, which I 
expect to be contentious. Payload size is not embedded in the T.35 data, 
so it must be calculated, used to allocate a buffer, and returned along 
with that buffer to the user. As far as I'm aware, AVBufferRef is the 
simplest way to do that, but I will be happy to consider alternative 
solutions.


Please let me know if it is preferred to bump libavutil with the first 
commit, or with both of them, considering there are public API changes 
associated with each one.


Raphaël Zumer

Signed-off-by: Raphaël Zumer 
---
 libavcodec/Makefile|   3 +-
 libavcodec/dynamic_hdr10_plus.c| 198 -
 libavcodec/dynamic_hdr10_plus.h|  35 -
 libavcodec/dynamic_hdr_vivid.c | 139 -
 libavcodec/dynamic_hdr_vivid.h |  35 -
 libavcodec/h2645_sei.c |  12 +-
 libavutil/hdr_dynamic_metadata.c   | 180 ++
 libavutil/hdr_dynamic_metadata.h   |  11 ++
 libavutil/hdr_dynamic_vivid_metadata.c | 120 +++
 libavutil/hdr_dynamic_vivid_metadata.h |  11 ++
 10 files changed, 329 insertions(+), 415 deletions(-)
 delete mode 100644 libavcodec/dynamic_hdr10_plus.c
 delete mode 100644 libavcodec/dynamic_hdr10_plus.h
 delete mode 100644 libavcodec/dynamic_hdr_vivid.c
 delete mode 100644 libavcodec/dynamic_hdr_vivid.h

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 389253f5d0..4bdfcbab12 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -103,8 +103,7 @@ OBJS-$(CONFIG_H264QPEL)+= h264qpel.o
 OBJS-$(CONFIG_H264_SEI)+= h264_sei.o h2645_sei.o
 OBJS-$(CONFIG_HEVCPARSE)   += hevc_parse.o hevc_ps.o 
hevc_data.o \
   h2645data.o h2645_parse.o 
h2645_vui.o

-OBJS-$(CONFIG_HEVC_SEI)+= hevc_sei.o h2645_sei.o \
-  dynamic_hdr10_plus.o 
dynamic_hdr_vivid.o

+OBJS-$(CONFIG_HEVC_SEI)+= hevc_sei.o h2645_sei.o
 OBJS-$(CONFIG_HPELDSP) += hpeldsp.o
 OBJS-$(CONFIG_HUFFMAN) += huffman.o
 OBJS-$(CONFIG_HUFFYUVDSP)  += huffyuvdsp.o
diff --git a/libavcodec/dynamic_hdr10_plus.c 
b/libavcodec/dynamic_hdr10_plus.c

deleted file mode 100644
index 34a44aac65..00
--- a/libavcodec/dynamic_hdr10_plus.c
+++ /dev/null
@@ -1,198 +0,0 @@
-/*
- * 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 "dynamic_hdr10_plus.h"
-#include "get_bits.h"
-
-static const int64_t luminance_den = 1;
-static const int32_t peak_luminance_den = 15;
-static const int64_t rgb_den = 10;
-static const int32_t fraction_pixel_den = 1000;
-static const int32_t knee_point_den = 4095;
-static const int32_t bezier_anchor_den = 1023;
-static const int32_t saturation_weight_den = 8;
-
-int ff_parse_itu_t_t35_to_dynamic_hdr10_plus(AVDynamicHDRPlus *s, const 
uint8_t *data,

- int size)
-{
-GetBitContext gbc, *gb = &gbc;
-int ret;
-
-if (!s)
-return AVERROR(ENOMEM);
-
-ret = init_get_bits8(gb, data, size);
-if (ret < 0)
-return ret;
-
-if (get_bits_left(gb) < 10)
-return AVERROR_INVALIDDATA;
-
-s->application_version = get_bits(gb, 8);
-s->num_windows = get_bits(gb

[FFmpeg-devel] [PATCH 2/2] avutil: add HDR10+ dynamic metadata serialization function

2023-02-27 Thread Raphaël Zumer 


See the previous patch for context.

Signed-off-by: Raphaël Zumer 
---
 libavutil/hdr_dynamic_metadata.c | 147 +++
 libavutil/hdr_dynamic_metadata.h |  10 +++
 libavutil/version.h  |   2 +-
 3 files changed, 158 insertions(+), 1 deletion(-)

diff --git a/libavutil/hdr_dynamic_metadata.c 
b/libavutil/hdr_dynamic_metadata.c

index 98f399b032..72d310e633 100644
--- a/libavutil/hdr_dynamic_metadata.c
+++ b/libavutil/hdr_dynamic_metadata.c
@@ -225,3 +225,150 @@ int av_dynamic_hdr_plus_from_t35(AVDynamicHDRPlus 
*s, const uint8_t *data,

  return 0;
 }
+
+AVBufferRef *av_dynamic_hdr_plus_to_t35(AVDynamicHDRPlus *s)
+{
+AVBufferRef *buf;
+size_t size_bits, size_bytes;
+PutBitContext pbc, *pb = &pbc;
+
+if (!s)
+return NULL;
+
+// Buffer size per CTA-861-H p.253-254:
+size_bits =
+// 56 bits for the header
+58 +
+// 2 bits for num_windows
+2 +
+// 937 bits for window geometry for each window above 1
+FFMAX((s->num_windows - 1), 0) * 937 +
+// 27 bits for targeted_system_display_maximum_luminance
+27 +
+// 1-3855 bits for targeted system display peak luminance information
+1 + (s->targeted_system_display_actual_peak_luminance_flag ? 10 +
+s->num_rows_targeted_system_display_actual_peak_luminance *
+s->num_cols_targeted_system_display_actual_peak_luminance * 4 : 
0) +

+// 0-442 bits for intra-window pixel distribution information
+s->num_windows * 82;
+for (int w = 0; w < s->num_windows; w++) {
+size_bits += s->params[w].num_distribution_maxrgb_percentiles * 24;
+}
+// 1-3855 bits for mastering display peak luminance information
+size_bits += 1 + (s->mastering_display_actual_peak_luminance_flag ? 
10 +

+s->num_rows_mastering_display_actual_peak_luminance *
+s->num_cols_mastering_display_actual_peak_luminance * 4 : 0) +
+// 0-537 bits for per-window tonemapping information
+s->num_windows * 1;
+for (int w = 0; w < s->num_windows; w++) {
+if (s->params[w].tone_mapping_flag) {
+size_bits += 28 + s->params[w].num_bezier_curve_anchors * 10;
+}
+}
+// 0-21 bits for per-window color saturation mapping information
+size_bits += s->num_windows * 1;
+for (int w = 0; w < s->num_windows; w++) {
+if (s->params[w].color_saturation_mapping_flag) {
+size_bits += 6;
+}
+}
+
+size_bytes = (size_bits + 7) / 8;
+
+buf = av_buffer_alloc(size_bytes);
+if (!buf) {
+return NULL;
+}
+
+init_put_bits(pb, buf->data, size_bytes);
+
+// itu_t_t35_country_code shall be 0xB5 (USA)
+put_bits(pb, 8, 0xB5);
+// itu_t_t35_terminal_provider_code shall be 0x003C
+put_bits(pb, 16, 0x003C);
+// itu_t_t35_terminal_provider_oriented_code is set to ST 2094-40
+put_bits(pb, 16, 0x0001);
+// application_identifier shall be set to 4
+put_bits(pb, 8, 4);
+// application_mode is set to Application Version 1
+put_bits(pb, 8, 1);
+
+// Payload as per CTA-861-H p.253-254
+put_bits(pb, 2, s->num_windows);
+
+for (int w = 1; w < s->num_windows; w++) {
+put_bits(pb, 16, s->params[w].window_upper_left_corner_x.num / 
s->params[w].window_upper_left_corner_x.den);
+put_bits(pb, 16, s->params[w].window_upper_left_corner_y.num / 
s->params[w].window_upper_left_corner_y.den);
+put_bits(pb, 16, s->params[w].window_lower_right_corner_x.num / 
s->params[w].window_lower_right_corner_x.den);
+put_bits(pb, 16, s->params[w].window_lower_right_corner_y.num / 
s->params[w].window_lower_right_corner_y.den);

+put_bits(pb, 16, s->params[w].center_of_ellipse_x);
+put_bits(pb, 16, s->params[w].center_of_ellipse_y);
+put_bits(pb, 8, s->params[w].rotation_angle);
+put_bits(pb, 16, s->params[w].semimajor_axis_internal_ellipse);
+put_bits(pb, 16, s->params[w].semimajor_axis_external_ellipse);
+put_bits(pb, 16, s->params[w].semiminor_axis_external_ellipse);
+put_bits(pb, 1, s->params[w].overlap_process_option);
+}
+
+put_bits(pb, 27, s->targeted_system_display_maximum_luminance.num * 
luminance_den /

+s->targeted_system_display_maximum_luminance.den);
+put_bits(pb, 1, s->targeted_system_display_actual_peak_luminance_flag);
+if (s->targeted_system_display_actual_peak_luminance_flag) {
+put_bits(pb, 5, 
s->num_rows_targeted_system_display_actual_peak_luminance);
+put_bits(pb, 5, 
s->num_cols_targeted_system_display_actual_peak_luminance);
+for (int i = 0; i < 
s->num_rows_targeted_system_display_actual_peak_luminance; i++) {
+for (int j = 0; j < 
s->num_cols_targeted_system_display_actual_peak_luminance; j++) {
+put_bits(pb, 4, 
s->targeted_system_display_actual_peak_luminance[i][j].num * 
peak_luminance_den /

+ s->targeted_system_display_actual_peak_luminance[i][j].den);
+

[FFmpeg-devel] [PATCH 1/2] avcodec/avutil: move dynamic HDR metadata parsing to libavutil

2023-02-27 Thread Raphaël Zumer 
Resending this patch set due to my mail client messing with the line wrapping 
in the messages I sent earlier today.

Below is a copy of the initial explanation.

This patch set implements serialization for HDR10+ dynamic metadata 
(AVDynamicHDRPlus), which is the inverse operation of the existing 
ff_parse_itu_t_t35_to_dynamic_hdr10_plus() function. It also moves both 
functions from libavcodec to libavutil and makes them public. For 
consistency, the equivalent vivid HDR parsing function is also migrated, 
but I did not implement serialization for it. Finally, the patch renames 
those functions to av_dynamic_hdr_plus_from_t35() (for parsing) and 
av_dynamic_hdr_plus_to_t35 (for serialization), with the equivalent 
change being made for vivid as well.

The motivation for this change is to allow users to easily convert 
HDR10+ side data (which is parsed into AVDynamicHDRPlus) to a standard 
ITU-T T.35 payload that can be passed directly to applications that 
expect HDR10+ dynamic metadata in that format (e.g. x265 and rav1e 
encoders).

The return value of the serialization function is AVBufferRef*, which I 
expect to be contentious. Payload size is not embedded in the T.35 data, 
so it must be calculated, used to allocate a buffer, and returned along 
with that buffer to the user. As far as I'm aware, AVBufferRef is the 
simplest way to do that, but I will be happy to consider alternative 
solutions.

Please let me know if it is preferred to bump libavutil with the first 
commit, or with both of them, considering there are public API changes 
associated with each one.

Raphaël Zumer

Signed-off-by: Raphaël Zumer 
---
 libavcodec/Makefile|   3 +-
 libavcodec/dynamic_hdr10_plus.c| 198 -
 libavcodec/dynamic_hdr10_plus.h|  35 -
 libavcodec/dynamic_hdr_vivid.c | 139 -
 libavcodec/dynamic_hdr_vivid.h |  35 -
 libavcodec/h2645_sei.c |  12 +-
 libavutil/hdr_dynamic_metadata.c   | 180 ++
 libavutil/hdr_dynamic_metadata.h   |  11 ++
 libavutil/hdr_dynamic_vivid_metadata.c | 120 +++
 libavutil/hdr_dynamic_vivid_metadata.h |  11 ++
 10 files changed, 329 insertions(+), 415 deletions(-)
 delete mode 100644 libavcodec/dynamic_hdr10_plus.c
 delete mode 100644 libavcodec/dynamic_hdr10_plus.h
 delete mode 100644 libavcodec/dynamic_hdr_vivid.c
 delete mode 100644 libavcodec/dynamic_hdr_vivid.h

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 389253f5d0..4bdfcbab12 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -103,8 +103,7 @@ OBJS-$(CONFIG_H264QPEL)+= h264qpel.o
 OBJS-$(CONFIG_H264_SEI)+= h264_sei.o h2645_sei.o
 OBJS-$(CONFIG_HEVCPARSE)   += hevc_parse.o hevc_ps.o hevc_data.o \
   h2645data.o h2645_parse.o h2645_vui.o
-OBJS-$(CONFIG_HEVC_SEI)+= hevc_sei.o h2645_sei.o \
-  dynamic_hdr10_plus.o 
dynamic_hdr_vivid.o
+OBJS-$(CONFIG_HEVC_SEI)+= hevc_sei.o h2645_sei.o
 OBJS-$(CONFIG_HPELDSP) += hpeldsp.o
 OBJS-$(CONFIG_HUFFMAN) += huffman.o
 OBJS-$(CONFIG_HUFFYUVDSP)  += huffyuvdsp.o
diff --git a/libavcodec/dynamic_hdr10_plus.c b/libavcodec/dynamic_hdr10_plus.c
deleted file mode 100644
index 34a44aac65..00
--- a/libavcodec/dynamic_hdr10_plus.c
+++ /dev/null
@@ -1,198 +0,0 @@
-/*
- * 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 "dynamic_hdr10_plus.h"
-#include "get_bits.h"
-
-static const int64_t luminance_den = 1;
-static const int32_t peak_luminance_den = 15;
-static const int64_t rgb_den = 10;
-static const int32_t fraction_pixel_den = 1000;
-static const int32_t knee_point_den = 4095;
-static const int32_t bezier_anchor_den = 1023;
-static const int32_t saturation_weight_den = 8;
-
-int ff_parse_itu_t_t35_to_dynamic_hdr10_plus(AVDynamicHDRPlus *s, const 
uint8_t *data,
- int size)
-{
-GetBitContext gbc, *gb = &gbc;
-int ret;
-
-if (!s)
-return AVERROR(ENOMEM);
-
-ret = init_get_bits8(gb, data, size);
-if (ret < 0)
-return ret;
-
-

[FFmpeg-devel] [PATCH 2/2] avutil: add HDR10+ dynamic metadata serialization function

2023-02-27 Thread Raphaël Zumer 
Resent due to my mail client incorrectly re-wrapping lines in the version I 
sent earlier.
See the previous patch for context.

Signed-off-by: Raphaël Zumer 
---
 libavutil/hdr_dynamic_metadata.c | 147 +++
 libavutil/hdr_dynamic_metadata.h |  10 +++
 libavutil/version.h  |   2 +-
 3 files changed, 158 insertions(+), 1 deletion(-)

diff --git a/libavutil/hdr_dynamic_metadata.c b/libavutil/hdr_dynamic_metadata.c
index 98f399b032..72d310e633 100644
--- a/libavutil/hdr_dynamic_metadata.c
+++ b/libavutil/hdr_dynamic_metadata.c
@@ -225,3 +225,150 @@ int av_dynamic_hdr_plus_from_t35(AVDynamicHDRPlus *s, 
const uint8_t *data,
 
 return 0;
 }
+
+AVBufferRef *av_dynamic_hdr_plus_to_t35(AVDynamicHDRPlus *s)
+{
+AVBufferRef *buf;
+size_t size_bits, size_bytes;
+PutBitContext pbc, *pb = &pbc;
+
+if (!s)
+return NULL;
+
+// Buffer size per CTA-861-H p.253-254:
+size_bits =
+// 56 bits for the header
+58 +
+// 2 bits for num_windows
+2 +
+// 937 bits for window geometry for each window above 1
+FFMAX((s->num_windows - 1), 0) * 937 +
+// 27 bits for targeted_system_display_maximum_luminance
+27 +
+// 1-3855 bits for targeted system display peak luminance information
+1 + (s->targeted_system_display_actual_peak_luminance_flag ? 10 +
+s->num_rows_targeted_system_display_actual_peak_luminance *
+s->num_cols_targeted_system_display_actual_peak_luminance * 4 : 0) +
+// 0-442 bits for intra-window pixel distribution information
+s->num_windows * 82;
+for (int w = 0; w < s->num_windows; w++) {
+size_bits += s->params[w].num_distribution_maxrgb_percentiles * 24;
+}
+// 1-3855 bits for mastering display peak luminance information
+size_bits += 1 + (s->mastering_display_actual_peak_luminance_flag ? 10 +
+s->num_rows_mastering_display_actual_peak_luminance *
+s->num_cols_mastering_display_actual_peak_luminance * 4 : 0) +
+// 0-537 bits for per-window tonemapping information
+s->num_windows * 1;
+for (int w = 0; w < s->num_windows; w++) {
+if (s->params[w].tone_mapping_flag) {
+size_bits += 28 + s->params[w].num_bezier_curve_anchors * 10;
+}
+}
+// 0-21 bits for per-window color saturation mapping information
+size_bits += s->num_windows * 1;
+for (int w = 0; w < s->num_windows; w++) {
+if (s->params[w].color_saturation_mapping_flag) {
+size_bits += 6;
+}
+}
+
+size_bytes = (size_bits + 7) / 8;
+
+buf = av_buffer_alloc(size_bytes);
+if (!buf) {
+return NULL;
+}
+
+init_put_bits(pb, buf->data, size_bytes);
+
+// itu_t_t35_country_code shall be 0xB5 (USA)
+put_bits(pb, 8, 0xB5);
+// itu_t_t35_terminal_provider_code shall be 0x003C
+put_bits(pb, 16, 0x003C);
+// itu_t_t35_terminal_provider_oriented_code is set to ST 2094-40
+put_bits(pb, 16, 0x0001);
+// application_identifier shall be set to 4
+put_bits(pb, 8, 4);
+// application_mode is set to Application Version 1
+put_bits(pb, 8, 1);
+
+// Payload as per CTA-861-H p.253-254
+put_bits(pb, 2, s->num_windows);
+
+for (int w = 1; w < s->num_windows; w++) {
+put_bits(pb, 16, s->params[w].window_upper_left_corner_x.num / 
s->params[w].window_upper_left_corner_x.den);
+put_bits(pb, 16, s->params[w].window_upper_left_corner_y.num / 
s->params[w].window_upper_left_corner_y.den);
+put_bits(pb, 16, s->params[w].window_lower_right_corner_x.num / 
s->params[w].window_lower_right_corner_x.den);
+put_bits(pb, 16, s->params[w].window_lower_right_corner_y.num / 
s->params[w].window_lower_right_corner_y.den);
+put_bits(pb, 16, s->params[w].center_of_ellipse_x);
+put_bits(pb, 16, s->params[w].center_of_ellipse_y);
+put_bits(pb, 8, s->params[w].rotation_angle);
+put_bits(pb, 16, s->params[w].semimajor_axis_internal_ellipse);
+put_bits(pb, 16, s->params[w].semimajor_axis_external_ellipse);
+put_bits(pb, 16, s->params[w].semiminor_axis_external_ellipse);
+put_bits(pb, 1, s->params[w].overlap_process_option);
+}
+
+put_bits(pb, 27, s->targeted_system_display_maximum_luminance.num * 
luminance_den /
+s->targeted_system_display_maximum_luminance.den);
+put_bits(pb, 1, s->targeted_system_display_actual_peak_luminance_flag);
+if (s->targeted_system_display_actual_peak_luminance_flag) {
+put_bits(pb, 5, 
s->num_rows_targeted_system_display_actual_peak_luminance);
+put_bits(pb, 5, 
s->num_cols_targeted_system_display_actual_peak_luminance);
+for (int i = 0; i < 
s->num_rows_targeted_system_display_actual_peak_luminance; i++) {
+for (int j = 0; j < 
s->num_cols_targeted_system_display_actual_peak_luminance; j++) {
+put_bits(pb, 4, 
s->targeted_system_display_actual_peak_luminance[i][j].num * peak_luminance_den

Re: [FFmpeg-devel] [PATCH v2 1/8] avformat/movenc: add PCM in mp4 support

2023-02-27 Thread Jan Ekström 
On Fri, Feb 24, 2023 at 8:29 PM Zhao Zhili  wrote:
>
> From: Zhao Zhili 
>
> It's defined by ISO/IEC 23003-5.
>
> Fixes ticket #10185
>
> Signed-off-by: Zhao Zhili 

Technically if you wanted to split these commits, then this
implementation would have to be limited to one audio channel streams,
as 23003-5:2020
says as follows:

- The ChannelLayout as defined in ISO/IEC 14496-12 is mandatory if the
PCM channel count is larger than one.

> ---
>  libavformat/movenc.c | 60 +++-
>  1 file changed, 59 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index c4fcb5f8b1..3315057b88 100644
> --- a/libavformat/movenc.c
> +++ b/libavformat/movenc.c
> @@ -1179,6 +1179,47 @@ static int mov_write_btrt_tag(AVIOContext *pb, 
> MOVTrack *track)
>  return update_size(pb, pos);
>  }
>
> +static int is_mp4_pcm_codec(enum AVCodecID codec)
> +{
> +switch (codec) {
> +case AV_CODEC_ID_PCM_S16BE:
> +case AV_CODEC_ID_PCM_S16LE:
> +case AV_CODEC_ID_PCM_S24BE:
> +case AV_CODEC_ID_PCM_S24LE:
> +case AV_CODEC_ID_PCM_S32BE:
> +case AV_CODEC_ID_PCM_S32LE:
> +
> +case AV_CODEC_ID_PCM_F32BE:
> +case AV_CODEC_ID_PCM_F32LE:
> +case AV_CODEC_ID_PCM_F64BE:
> +case AV_CODEC_ID_PCM_F64LE:
> +return 1;
> +default:
> +return 0;
> +}
> +}

This should be unnecessary if the check is switched to the codec_tags
in mov_write_audio_tag.

> +
> +static int mov_write_pcmc_tag(AVFormatContext *s, AVIOContext *pb, MOVTrack 
> *track)
> +{
> +int64_t pos = avio_tell(pb);
> +int format_flags;
> +
> +avio_wb32(pb, 0); /* size */
> +ffio_wfourcc(pb, "pcmC");
> +avio_wb32(pb, 0); /* version & flags */
> +
> +/* 0x01: indicates little-endian format */
> +format_flags = (track->par->codec_id == AV_CODEC_ID_PCM_F32LE ||
> +track->par->codec_id == AV_CODEC_ID_PCM_F64LE ||
> +track->par->codec_id == AV_CODEC_ID_PCM_S16LE ||
> +track->par->codec_id == AV_CODEC_ID_PCM_S24LE ||
> +track->par->codec_id == AV_CODEC_ID_PCM_S32LE);
> +avio_w8(pb, format_flags);
> +avio_w8(pb, track->par->bits_per_raw_sample);
> +
> +return update_size(pb, pos);
> +}

Generally looks good. I utilized av_get_exact_bits_per_sample, but
since mov_write_audio_tag also writes down bits_per_raw_sample, so I
think being consistent should be OK :)

> +
>  static int mov_write_audio_tag(AVFormatContext *s, AVIOContext *pb, 
> MOVMuxContext *mov, MOVTrack *track)
>  {
>  int64_t pos = avio_tell(pb);
> @@ -1243,7 +1284,8 @@ static int mov_write_audio_tag(AVFormatContext *s, 
> AVIOContext *pb, MOVMuxContex
>  } else { /* reserved for mp4/3gp */
>  avio_wb16(pb, track->par->ch_layout.nb_channels);
>  if (track->par->codec_id == AV_CODEC_ID_FLAC ||
> -track->par->codec_id == AV_CODEC_ID_ALAC) {
> +track->par->codec_id == AV_CODEC_ID_ALAC ||
> +is_mp4_pcm_codec(track->par->codec_id)) {

I know why you think you should be doing this, but:

1. 14496-12:2022 still defines AudioSampleEntry::samplesize as
"template unsigned int(16) samplesize = 16;", so ISOBMFF itself only
lets you set 16 here.
2.  23003-5:2020 does not allow other values to be written (the
downstream spec should explicitly allow writing of non-template
values). This is probably because pcmC itself contains PCM_sample_size
for this same use.

So writing samplesize here is technically incorrect, even though I
know that most likely some implementations do this (technically
against these specs).

Why channelcount was made non-template yet samplesize was not? A very
good question. Most likely the channel layout v1 and DRC boxes'
changes started requiring the former, but not the latter?

>  avio_wb16(pb, track->par->bits_per_raw_sample);
>  } else {
>  avio_wb16(pb, 16);
> @@ -1307,6 +1349,8 @@ static int mov_write_audio_tag(AVFormatContext *s, 
> AVIOContext *pb, MOVMuxContex
>  ret = mov_write_dmlp_tag(s, pb, track);
>  else if (track->vos_len > 0)
>  ret = mov_write_glbl_tag(pb, track);
> +else if (track->mode == MODE_MP4 && 
> is_mp4_pcm_codec(track->par->codec_id))
> +ret = mov_write_pcmc_tag(s, pb, track);

It would seem that the generic vos_data extradata writing should be
the last else if in this logic? Could be unnecessary cargo culting,
but at least so far all new codec handling went before it?

Personally I would have just based this check on the codec tag, a la

else if (tag == MOV_MP4_IPCM_TAG || tag == MOV_MP4_FPCM_TAG)
// pcmC is required for these tags as per ISO/IEC 23003-5
ret = mov_write_pcmc_tag(s, pb, track);

As that matches the specification's note:

- Mandatory: Yes, if codingname of SampleEntry is ‘ipcm’ or ‘fpcm’.

The codec tags are also only defined in codec_mp4_tags, so they would
only

Re: [FFmpeg-devel] [PATCH] libavcodec/libfdk-aacnc: send encoder delay/padding in packet side data

2023-02-27 Thread Jonathan Gee 
> On Fri, Feb 24, 2023 at 3:14 PM JonHGee  wrote:
> ---
>  libavcodec/libfdk-aacenc.c | 27 ++-
>  1 file changed, 26 insertions(+), 1 deletion(-)
> diff --git a/libavcodec/libfdk-aacenc.c b/libavcodec/libfdk-aacenc.c
> index 54549de473..55d10990e4 100644
> --- a/libavcodec/libfdk-aacenc.c
> +++ b/libavcodec/libfdk-aacenc.c
> @@ -21,6 +21,7 @@
>  #include "libavutil/channel_layout.h"
>  #include "libavutil/common.h"
> +#include "libavutil/intreadwrite.h"
>  #include "libavutil/opt.h"
>  #include "avcodec.h"
>  #include "audio_frame_queue.h"
> @@ -46,6 +47,7 @@ typedef struct AACContext {
>  int latm;
>  int header_period;
>  int vbr;
> +int delay_sent;
>  AudioFrameQueue afq;
>  } AACContext;
> @@ -368,7 +370,7 @@ static int aac_encode_frame(AVCodecContext *avctx, 
> AVPacket *avpkt,
>  int out_buffer_identifier = OUT_BITSTREAM_DATA;
>  int out_buffer_size, out_buffer_element_size;
>  void *in_ptr, *out_ptr;
> -int ret;
> +int ret, discard_padding;
>  uint8_t dummy_buf[1];
>  AACENC_ERROR err;
> @@ -428,6 +430,29 @@ static int aac_encode_frame(AVCodecContext *avctx, 
> AVPacket *avpkt,
>  ff_af_queue_remove(&s->afq, avctx->frame_size, &avpkt->pts,
> &avpkt->duration);
> +discard_padding = avctx->frame_size - avpkt->duration;
> +// Check if subtraction resulted in an overflow
> +if ((discard_padding < avctx->frame_size) != (avpkt->duration > 0)) {
> +av_log(avctx, AV_LOG_ERROR, "discard padding overflow\n");
> +av_packet_unref(avpkt);
> +av_free(avpkt);
> +return AVERROR(EINVAL);
> +}
> +if ((!s->delay_sent && avctx->initial_padding > 0) || discard_padding > 
> 0) {
> +uint8_t *side_data =
> +av_packet_new_side_data(avpkt, AV_PKT_DATA_SKIP_SAMPLES, 10);
> +if (!side_data) {
> +av_packet_unref(avpkt);
> +av_free(avpkt);
> +return AVERROR(ENOMEM);
> +}
> +if (!s->delay_sent) {
> +AV_WL32(side_data, avctx->initial_padding);
> +s->delay_sent = 1;
> +}
> +AV_WL32(side_data + 4, discard_padding);
> +}
> +
>  avpkt->size = out_args.numOutBytes;
>  *got_packet_ptr = 1;
>  return 0;
> --
> 2.39.2.637.g21b0678d19-goog
>

Ping?
___
ffmpeg-devel mailing list
ffmpeg-devel@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 v7 0/4] add ARIB caption decoder using libaribcaption

2023-02-27 Thread Ridley Combs 


> On Feb 23, 2023, at 04:17, TADANO Tokumei  wrote:
> 
> Ping with rebased patch set.
> Some chages are added to reflect review results from outside of this ML.
> 
> ---
> This patch set add another ARIB caption decoder using libaribcaption
> external library: https://github.com/xqq/libaribcaption
> The library decodes subtitles of ISDB-based TV broadcasting.
> It is not only for Japanese ARIB STD-B24 caption, but also for
> Brazilian ABNT NBR 15606-1 and Philippines version of ISDB-T.
> 
> Unlike libaribb24, it supports 3 types of subtitle outputs:
> * text: plain text
> * ass: ASS formatted text
> * bitmap: bitmap image
> 
> Default subtitle type is ASS as same as libaribb24.
> Advantages compared with libaribb24 on ASS subtitle are:
> * Subtitle positioning.
> * Multi-rect subtitle: some captions are displayed at different
>  position at a time.
> * More stability and reproducibility.
> 
> Subtitle type can be changed by `-sub_type` option.
> You can see ARIB caption with ffplay tool:
>  ffplay -sub_type bitmap MPEG.TS
> 
> Sample files exist under:
>  https://streams.videolan.org/streams/ts/ARIB/
> Some of them are encrypted and some don't contain ARIB caption data.
> Good samples for ARIB caption are:
>  brazil/07-25_20-33-35_UCV - HD_.ts
>  japan/channel2[137]_clear.ts
>  japan/osaka_15.ts
> 
> ---
> v7: reflect review results from outside of this ML
>  - rename -ass_workaround option to -ass_single_rect and default to
>false (latest mpv supports multiple ASS rectangle)
>  - add -canvas_size option to specify frame size to render bitmap subtitle
>  - add -caption_encoding option to specify encoding of subtitle text
>  - change behavior of profile C ARIB caption
>  - some cosmetic changes
> v6: reflect review results from outside of this ML
>  - check clut table overflow
>  - do not adjust vertical position of ruby for ASS format
> v5: reflect review comments from Mao Hata
>  - reset correct variable in aribcaption_close()
>  - add aribcaption_close() to some places in aribcaption_init()
>  - check if av_strdup() returns NULL in set_ass_header()
> v4: reflect review results from outside of this ML.
>  - resize bitmap subtitle image to display fonts with correct aspect ratio
>  - multiple font families can be specified by '-font' option
>  - remove 'rendering_backend' option
>  - add document
>  - minor bug fixes
> v3: combine former 1/4 and 2/4 due to the patchwork shows build error.
>  - fix help option content which incorrectly separated to 2 lines in 2/4.
>  - amend commit message of 4/4.
> 
> TADANO Tokumei (4):
>  lavc/libaribcaption.c: add ARIB caption decoder using libaribcaption
>  lavc/codec_desc.c: remove AV_CODEC_PROP_TEXT_SUB property
>  lavf/mpegts.c: set some properties for ARIB caption
>  doc/decoders.texi: add document of aribcaption decoder
> 
> configure   |4 +
> doc/decoders.texi   |  150 +
> libavcodec/Makefile |1 +
> libavcodec/allcodecs.c  |1 +
> libavcodec/codec_desc.c |1 -
> libavcodec/libaribb24.c |1 +
> libavcodec/libaribcaption.c | 1171 +++
> libavformat/mpegts.c|6 +-
> 8 files changed, 1333 insertions(+), 2 deletions(-)
> create mode 100644 libavcodec/libaribcaption.c
> 
> -- 
> 2.30.2
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

This set looks reasonable to me at this point; the one thing blocking it is the 
issue with assenc.c muxing for AVSubtitles with multiple rects, which needs a 
decision on this question: 
http://ffmpeg.org/pipermail/ffmpeg-devel/2023-February/306850.html

Once that's resolved, I'm happy to merge this.

___
ffmpeg-devel mailing list
ffmpeg-devel@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] Bump major version of swresample

2023-02-27 Thread Wang Bin 
James Almer  于2023年2月27日周一 20:00写道：

> On 2/27/2023 7:03 AM, Michael Niedermayer wrote:
> > essOn Sat, Feb 25, 2023 at 12:03:02AM +0800, Wang Bin wrote:
> >>
> >
> >>   version_major.h |2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >> a87056c2fe65d68b2cf5d1de06be28ea40c69b73
> 0001-Bump-major-version-of-swresample.patch
> >>  From e3e6a3833f2fba743ee9c05962e804e9e570dd75 Mon Sep 17 00:00:00 2001
> >> From: wang-bin 
> >> Date: Fri, 24 Feb 2023 23:54:51 +0800
> >> Subject: [PATCH] Bump major version of swresample
> >>
> >> ---
> >>   libswresample/version_major.h | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/libswresample/version_major.h
> b/libswresample/version_major.h
> >> index 7f265c2073..dd13f2bbe3 100644
> >> --- a/libswresample/version_major.h
> >> +++ b/libswresample/version_major.h
> >> @@ -26,6 +26,6 @@
> >>* Libswresample version macros
> >>*/
> >>
> >> -#define LIBSWRESAMPLE_VERSION_MAJOR   4
> >> +#define LIBSWRESAMPLE_VERSION_MAJOR   5
> >
> > No oppinion if this should be changed now before 6.0 or not
> > but if its done it should be done on master and release/6.0 at the same
> time
> > and LIBSWRESAMPLE_VERSION_MINOR needs to be reset too while
> > LIBSWRESAMPLE_VERSION_MINOR needs to be +1 on master compared to
> release/6.0
> >
> > oppinon from others is welcome here. Iam not a user of the releases so
> its
> > hard for me to really guess which way is better. Its a little messy to
> > change now
> >
> > thx
>
> I don't think it's a good idea to do it now. No API was removed from it
> so leaving the major as is should be fine.
>

Currently no api change and even no abi change. But AVFrame is used in the
public api swr_convert_frame, AVFrame abi changes may break swresample
binary compatibility without swresample code change. All other modules
except postproc and avutil public apis also depend on structs from another
module. So it's better to bump major version of all modules.

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] Bump major version of swresample

2023-02-27 Thread Zhao Zhili 

> 在 2023年2月28日，09:43，Wang Bin  写道：
> 
> James Almer  于2023年2月27日周一 20:00写道：
> 
>>> On 2/27/2023 7:03 AM, Michael Niedermayer wrote:
>>> essOn Sat, Feb 25, 2023 at 12:03:02AM +0800, Wang Bin wrote:
 
>>> 
  version_major.h |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 a87056c2fe65d68b2cf5d1de06be28ea40c69b73
>> 0001-Bump-major-version-of-swresample.patch
 From e3e6a3833f2fba743ee9c05962e804e9e570dd75 Mon Sep 17 00:00:00 2001
 From: wang-bin 
 Date: Fri, 24 Feb 2023 23:54:51 +0800
 Subject: [PATCH] Bump major version of swresample
 
 ---
  libswresample/version_major.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/libswresample/version_major.h
>> b/libswresample/version_major.h
 index 7f265c2073..dd13f2bbe3 100644
 --- a/libswresample/version_major.h
 +++ b/libswresample/version_major.h
 @@ -26,6 +26,6 @@
   * Libswresample version macros
   */
 
 -#define LIBSWRESAMPLE_VERSION_MAJOR   4
 +#define LIBSWRESAMPLE_VERSION_MAJOR   5
>>> 
>>> No oppinion if this should be changed now before 6.0 or not
>>> but if its done it should be done on master and release/6.0 at the same
>> time
>>> and LIBSWRESAMPLE_VERSION_MINOR needs to be reset too while
>>> LIBSWRESAMPLE_VERSION_MINOR needs to be +1 on master compared to
>> release/6.0
>>> 
>>> oppinon from others is welcome here. Iam not a user of the releases so
>> its
>>> hard for me to really guess which way is better. Its a little messy to
>>> change now
>>> 
>>> thx
>> 
>> I don't think it's a good idea to do it now. No API was removed from it
>> so leaving the major as is should be fine.
>> 
> 
> Currently no api change and even no abi change. But AVFrame is used in the
> public api swr_convert_frame, AVFrame abi changes may break swresample
> binary compatibility without swresample code change.

I don’t think that’s how ABI and so version works.

> All other modules
> except postproc and avutil public apis also depend on structs from another
> module. So it's better to bump major version of all modules.
> 
> 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 wit

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

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

Re: [FFmpeg-devel] [PATCH v2 1/8] avformat/movenc: add PCM in mp4 support

2023-02-27 Thread zhilizhao(赵志立) 


> On Feb 28, 2023, at 04:24, Jan Ekström  wrote:
> 
> On Fri, Feb 24, 2023 at 8:29 PM Zhao Zhili  wrote:
>> 
>> From: Zhao Zhili 
>> 
>> It's defined by ISO/IEC 23003-5.
>> 
>> Fixes ticket #10185
>> 
>> Signed-off-by: Zhao Zhili 
> 
> Technically if you wanted to split these commits, then this
> implementation would have to be limited to one audio channel streams,
> as 23003-5:2020
> says as follows:
> 
> - The ChannelLayout as defined in ISO/IEC 14496-12 is mandatory if the
> PCM channel count is larger than one.

OK. Will do a ping-pong with v3.

> 
>> ---
>> libavformat/movenc.c | 60 +++-
>> 1 file changed, 59 insertions(+), 1 deletion(-)
>> 
>> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
>> index c4fcb5f8b1..3315057b88 100644
>> --- a/libavformat/movenc.c
>> +++ b/libavformat/movenc.c
>> @@ -1179,6 +1179,47 @@ static int mov_write_btrt_tag(AVIOContext *pb, 
>> MOVTrack *track)
>> return update_size(pb, pos);
>> }
>> 
>> +static int is_mp4_pcm_codec(enum AVCodecID codec)
>> +{
>> +switch (codec) {
>> +case AV_CODEC_ID_PCM_S16BE:
>> +case AV_CODEC_ID_PCM_S16LE:
>> +case AV_CODEC_ID_PCM_S24BE:
>> +case AV_CODEC_ID_PCM_S24LE:
>> +case AV_CODEC_ID_PCM_S32BE:
>> +case AV_CODEC_ID_PCM_S32LE:
>> +
>> +case AV_CODEC_ID_PCM_F32BE:
>> +case AV_CODEC_ID_PCM_F32LE:
>> +case AV_CODEC_ID_PCM_F64BE:
>> +case AV_CODEC_ID_PCM_F64LE:
>> +return 1;
>> +default:
>> +return 0;
>> +}
>> +}
> 
> This should be unnecessary if the check is switched to the codec_tags
> in mov_write_audio_tag.

> 
>> +
>> +static int mov_write_pcmc_tag(AVFormatContext *s, AVIOContext *pb, MOVTrack 
>> *track)
>> +{
>> +int64_t pos = avio_tell(pb);
>> +int format_flags;
>> +
>> +avio_wb32(pb, 0); /* size */
>> +ffio_wfourcc(pb, "pcmC");
>> +avio_wb32(pb, 0); /* version & flags */
>> +
>> +/* 0x01: indicates little-endian format */
>> +format_flags = (track->par->codec_id == AV_CODEC_ID_PCM_F32LE ||
>> +track->par->codec_id == AV_CODEC_ID_PCM_F64LE ||
>> +track->par->codec_id == AV_CODEC_ID_PCM_S16LE ||
>> +track->par->codec_id == AV_CODEC_ID_PCM_S24LE ||
>> +track->par->codec_id == AV_CODEC_ID_PCM_S32LE);
>> +avio_w8(pb, format_flags);
>> +avio_w8(pb, track->par->bits_per_raw_sample);
>> +
>> +return update_size(pb, pos);
>> +}
> 
> Generally looks good. I utilized av_get_exact_bits_per_sample, but
> since mov_write_audio_tag also writes down bits_per_raw_sample, so I
> think being consistent should be OK :)
> 
>> +
>> static int mov_write_audio_tag(AVFormatContext *s, AVIOContext *pb, 
>> MOVMuxContext *mov, MOVTrack *track)
>> {
>> int64_t pos = avio_tell(pb);
>> @@ -1243,7 +1284,8 @@ static int mov_write_audio_tag(AVFormatContext *s, 
>> AVIOContext *pb, MOVMuxContex
>> } else { /* reserved for mp4/3gp */
>> avio_wb16(pb, track->par->ch_layout.nb_channels);
>> if (track->par->codec_id == AV_CODEC_ID_FLAC ||
>> -track->par->codec_id == AV_CODEC_ID_ALAC) {
>> +track->par->codec_id == AV_CODEC_ID_ALAC ||
>> +is_mp4_pcm_codec(track->par->codec_id)) {
> 
> I know why you think you should be doing this, but:
> 
> 1. 14496-12:2022 still defines AudioSampleEntry::samplesize as
> "template unsigned int(16) samplesize = 16;", so ISOBMFF itself only
> lets you set 16 here.
> 2.  23003-5:2020 does not allow other values to be written (the
> downstream spec should explicitly allow writing of non-template
> values). This is probably because pcmC itself contains PCM_sample_size
> for this same use.
> 
> So writing samplesize here is technically incorrect, even though I
> know that most likely some implementations do this (technically
> against these specs).

Technically it’s against spec. However:

1. It lets old version of libavformat able to demux PCM in mp4.
samplesize is used inside mov_parse_stsd_audio for AV_CODEC_ID_PCM.

2. samplesize is a fixed value in spec. If other mp4 demuxer implementations
ignore this field, it’s fine. If they use samplesize, it’s better to
set the real value. It’s a problem only if they reject samplesize != 16,
which is unlikely.

What do you think?

> 
> Why channelcount was made non-template yet samplesize was not? A very
> good question. Most likely the channel layout v1 and DRC boxes'
> changes started requiring the former, but not the latter?
> 
>> avio_wb16(pb, track->par->bits_per_raw_sample);
>> } else {
>> avio_wb16(pb, 16);
>> @@ -1307,6 +1349,8 @@ static int mov_write_audio_tag(AVFormatContext *s, 
>> AVIOContext *pb, MOVMuxContex
>> ret = mov_write_dmlp_tag(s, pb, track);
>> else if (track->vos_len > 0)
>> ret = mov_write_glbl_tag(pb, track);
>> +else if (track->mode == MODE_MP4 && 
>> is_mp4_pcm_codec(track->par->codec_id

[FFmpeg-devel] [PATCH v1] lavc/vp9: Add RGB* formats for VAAPI hwaccel

2023-02-27 Thread Fei Wang 
Signed-off-by: Fei Wang 
---
 libavcodec/vp9.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index 7c0a246446..7ff387faf4 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -239,6 +239,13 @@ static int update_size(AVCodecContext *avctx, int w, int h)
 case AV_PIX_FMT_YUV444P12:
 #if CONFIG_VP9_VAAPI_HWACCEL
 *fmtp++ = AV_PIX_FMT_VAAPI;
+#endif
+break;
+case AV_PIX_FMT_GBRP:
+case AV_PIX_FMT_GBRP10:
+case AV_PIX_FMT_GBRP12:
+#if CONFIG_VP9_VAAPI_HWACCEL
+*fmtp++ = AV_PIX_FMT_VAAPI;
 #endif
 break;
 }
-- 
2.25.1

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

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