On Sat, 06 Apr 2024 21:10:45 -0300 James Almer wrote:
> On 4/6/2024 8:38 AM, Niklas Haas wrote:
> > On Fri, 05 Apr 2024 16:36:50 -0300 James Almer wrote:
> >> On 4/5/2024 3:57 PM, Niklas Haas wrote:
> >>> From: Niklas Haas
> >>>
> >>> While
On Sun, 07 Apr 2024 01:16:39 +0200 Michael Niedermayer
wrote:
> On Fri, Apr 05, 2024 at 08:57:11PM +0200, Niklas Haas wrote:
> > From: Niklas Haas
> >
> > This replaces the myriad of existing lists in AVCodec by a unified API
> > call, allowing us to (ultimately) t
On Sat, 06 Apr 2024 13:14:45 +0200 Niklas Haas wrote:
> From: Niklas Haas
>
> Invalid input files may contain film grain metadata which survives
> ff_h274_film_grain_params_supported() but does not pass
> av_film_grain_params_select(), leading to a SIGSEGV on hevc_frame_
On Fri, 05 Apr 2024 16:36:50 -0300 James Almer wrote:
> On 4/5/2024 3:57 PM, Niklas Haas wrote:
> > From: Niklas Haas
> >
> > While rewriting this macro, I decided to make it a bit more flexible so
> > it can work for all of the fields (including future fields
From: Niklas Haas
Invalid input files may contain film grain metadata which survives
ff_h274_film_grain_params_supported() but does not pass
av_film_grain_params_select(), leading to a SIGSEGV on hevc_frame_end().
Fix this by duplicating the av_film_grain_params_select() check at frame
init
On Fri, 05 Apr 2024 20:57:11 +0200 Niklas Haas wrote:
> From: Niklas Haas
> In addition to the already covered lists, add two new entries for color
> space and color range, mirroring the newly added negotiable fields in
> libavfilter.
If this passes review, I will submit a s
From: Niklas Haas
I preserved the no-op condition on `!ch_layouts`, even though I suspect
it's not actually needed.
---
fftools/ffmpeg_filter.c | 59 -
1 file changed, 46 insertions(+), 13 deletions(-)
diff --git a/fftools/ffmpeg_filter.c b/fftools
From: Niklas Haas
---
fftools/ffmpeg_mux_init.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/fftools/ffmpeg_mux_init.c b/fftools/ffmpeg_mux_init.c
index d3d7d022ff6..508c4f7a697 100644
--- a/fftools/ffmpeg_mux_init.c
+++ b/fftools/ffmpeg_mux_init.c
From: Niklas Haas
While rewriting this macro, I decided to make it a bit more flexible so
it can work for all of the fields (including future fields) in a more
generic way.
---
fftools/opt_common.c | 86 ++--
1 file changed, 43 insertions(+), 43 deletions
From: Niklas Haas
Having macros initialize local variables seems strange to me, and there
are no more current users of these macros. (The one that was commented
out was incorrect anyway, since the macro has changed in the meantime)
---
fftools/cmdutils.h | 13 -
fftools
From: Niklas Haas
All hail get_supported_config()
---
libavcodec/allcodecs.c | 7 +--
libavcodec/codec_internal.h | 8
2 files changed, 1 insertion(+), 14 deletions(-)
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index a9f1797930a..1f22e06e710 100644
From: Niklas Haas
---
libavcodec/libaomenc.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
index 4a71bba9c9c..899aa2b261f 100644
--- a/libavcodec/libaomenc.c
+++ b/libavcodec/libaomenc.c
From: Niklas Haas
---
libavcodec/libvpxenc.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index bcbdc4981e5..ac7f01e2aa9 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -2086,13
From: Niklas Haas
---
libavcodec/libx265.c | 26 ++
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index 0645cd20457..ff1e8463aa1 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -892,14 +892,24
From: Niklas Haas
In order to avoid breaking older clients not yet using the new API, we
need to add backwards compatibility for codecs which have switched from
init_static() to get_supported_config().
This function can be removed entirely once the deprecated static fields
are removed
From: Niklas Haas
---
libavcodec/encode.c | 88 -
1 file changed, 55 insertions(+), 33 deletions(-)
diff --git a/libavcodec/encode.c b/libavcodec/encode.c
index 34658d13d0c..d0e79379048 100644
--- a/libavcodec/encode.c
+++ b/libavcodec/encode.c
From: Niklas Haas
This replaces the myriad of existing lists in AVCodec by a unified API
call, allowing us to (ultimately) trim down the sizeof(AVCodec) quite
substantially, while also making this more trivially extensible.
In addition to the already covered lists, add two new entries for color
From: Niklas Haas
This version is four years old, and present in Debian oldstable, Ubuntu
22.04 and Leap 15.1.
Allows cleaning up both the configure check and the file substantially.
In particular, this is motivated by the desire to stop relying on
init_static_data.
---
configure
On Thu, 04 Apr 2024 19:05:14 +0200 Nicolas Gaullier
wrote:
> Fixes a regression due to the fact that the colorspace filter does
> not use the new API introduced by 8c7934f73ab6c568acaa.
> The scale filter uses it since 45e09a30419cc2a7251e, and the setparams
> filter since 3bf80df3ccd32aed23f0.
On Thu, 04 Apr 2024 12:01:36 + Nicolas Gaullier
wrote:
> >De : Niklas Haas
> >Envoyé : jeudi 4 avril 2024 12:18
> >> --- a/libavfilter/vf_colorspace.c
> >> +++ b/libavfilter/vf_colorspace.c
> >> @@ -433,8 +433,7 @@ static int create_filtergraph(
On Tue, 02 Apr 2024 15:05:59 +0200 Nicolas Gaullier
wrote:
> Fixes a regression due to the fact that the colorspace filter does
> not use the new API introduced by 8c7934f73ab6c568acaa.
> The scale filter uses it since 45e09a30419cc2a7251e, and the setparams
> filter since 3bf80df3ccd32aed23f0.
On Sun, 24 Mar 2024 14:04:37 +0100 Andreas Rheinhardt
wrote:
> Niklas Haas:
> > On Mon, 05 Feb 2024 19:04:30 +0100 Andreas Rheinhardt
> > wrote:
> >> This presumes the relevant states to be a cartesian product. Which need
> >> not be true. A callback would
From: Niklas Haas
Since this is guarded behind strict unofficial, we should warn if the
user feeds a dolby vision stream to this muxer, as it will otherwise
result in a broken file.
---
libavformat/movenc.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git
From: Niklas Haas
---
libavcodec/libaomenc.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
index d660afab4ec..6bc46ec6e28 100644
--- a/libavcodec/libaomenc.c
+++ b/libavcodec/libaomenc.c
@@ -43,6 +43,7
From: Niklas Haas
libx265 supports these natively, we just need to attach the generated
NALs to the x265picture, as well as setting the appropriate DV profile.
---
libavcodec/libx265.c | 36
1 file changed, 36 insertions(+)
diff --git a/libavcodec/libx265.c
From: Niklas Haas
This function takes a decoded AVDOVIMetadata struct and turns it back
into a binary RPU. Verified using existing tools, and matches the
bitstream in official reference files.
I decided to just roll the EMDF and NAL encapsulation into this function
because the end user
From: Niklas Haas
We need to set up the configuration struct appropriately based on the
codec type, colorspace metadata, and presence/absence of an EL (though,
we currently don't support an EL).
When present, we use the signalled RPU data header to help infer (and
validate) the right values
From: Niklas Haas
This is based on HEVC only, H.264/AV1 use their own (hopefully correctly
signalled) profiles.
---
libavcodec/dovi_rpu.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/dovi_rpu.c b/libavcodec/dovi_rpu.c
index 267e52ceb66..4da711d763e 100644
From: Niklas Haas
The code was written under the misguided assumption that these fields
would only be present when the value changes, however this does not
match the actual patent specification, which says that streams are
required to either always signal this metadata, or never signal
From: Niklas Haas
This was never set in ff_dovi_ctx_replace(), leading to possibly
out-of-date when copying from a sub-thread to the main thread.
---
libavcodec/dovi_rpu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/dovi_rpu.c b/libavcodec/dovi_rpu.c
index d95c7e03af9
From: Niklas Haas
And make it public.
For encoding, users may also be interested in the configured level and
compatibility ID. So generalize the dv_profile field and just expose the
whole configuration record.
This makes the already rather reductive ff_dovi_update_cfg() function
almost wholly
From: Niklas Haas
Tri-state yes/no/auto option. Allows users to set `dolbyvision` to `no`
to suppress coding dolby vision even when supported by the target codec.
---
doc/APIchanges | 3 +++
doc/codecs.texi| 12
libavcodec/avcodec.h | 11
On Mon, 01 Apr 2024 19:42:29 -0400 Sean McGovern wrote:
> Hi,
>
> On Mon, Apr 1, 2024, 18:00 Lynne wrote:
>
> > Apr 1, 2024, 22:01 by mich...@niedermayer.cc:
> >
> > > Hi all
> > >
> > > I think we didnt decide on a name for 7.0 yet
> > >
> > > Previously suggested names:
> > > Darwin,
> > >
On Sat, 23 Mar 2024 20:19:57 +0100 Niklas Haas wrote:
> From: Niklas Haas
>
> ---
> libavcodec/dovi_rpu.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/dovi_rpu.c b/libavcodec/dovi_rpu.c
> index b3defd87bda..2b4d2b470c2 1
On Sat, 23 Mar 2024 20:19:49 +0100 Niklas Haas wrote:
> Changes since v1:
> - Rebased onto master
> - Dropped av_dovi_metadata_alloc_ext(), instead statically allocate
> space for 32 extension blocks (AV_DOVI_MAX_EXT_BLOCKS)
> - Removed misleading comment on nlq_pivots
>
On Mon, 25 Mar 2024 16:10:55 +0100 Niklas Haas wrote:
> On Mon, 25 Mar 2024 14:40:44 +0100 Niklas Haas wrote:
> > From: Niklas Haas
> >
> > Ironically, despite being introduced to make YUVJ unnecessary, the new
> > YUV negotiation logic failed to actually negotiate
On Mon, 25 Mar 2024 14:40:44 +0100 Niklas Haas wrote:
> From: Niklas Haas
>
> Ironically, despite being introduced to make YUVJ unnecessary, the new
> YUV negotiation logic failed to actually negotiate YUVJ formats
> themselves correctly, leading to errors when pass
From: Niklas Haas
Doing this with REDUCE_FORMATS() instead of swap_color_*() is not only
shorter, but more importantly comes with the benefit of being done
inside a loop, allowing us to correctly propagate complex graphs
involving multiple conversion filters (e.g. -vf scale,zscale).
The latter
On Mon, 25 Mar 2024 16:02:23 +0100 Niklas Haas wrote:
> On Mon, 25 Mar 2024 15:36:26 +0100 Damiano Galassi wrote:
> > On Mon, Mar 25, 2024 at 2:40 PM Niklas Haas wrote:
> >
> > > > ffmpeg -i in.mp4 -vf
> > > > "scale='width=1920:height=10
On Mon, 25 Mar 2024 15:36:26 +0100 Damiano Galassi wrote:
> On Mon, Mar 25, 2024 at 2:40 PM Niklas Haas wrote:
>
> > > ffmpeg -i in.mp4 -vf
> > > "scale='width=1920:height=1080',zscale='width=1920:height=1080'" out.mp4
> > > ffmpeg -i in.jpg -v
On Mon, 25 Mar 2024 07:20:56 +0100 "Jean-Baptiste Kempf"
wrote:
> Hello,
>
> On Mon, 25 Mar 2024, at 01:03, Michael Niedermayer wrote:
> > Should i wait till all issues marked as blocking 7.0 on trac are fixed
> > before branching ?
>
> I think you should branch now.
> And get things fixed in
From: Niklas Haas
Ironically, despite being introduced to make YUVJ unnecessary, the new
YUV negotiation logic failed to actually negotiate YUVJ formats
themselves correctly, leading to errors when passing YUVJ frames into
a filter graph. (They were effectively treated like RGB or Grayscale
On Sun, 24 Mar 2024 20:03:03 +0100 Damiano Galassi wrote:
> On Sun, Mar 24, 2024 at 6:53 PM Niklas Haas wrote:
>
> > But wait - aren't all filter's lists set to the same reference? Isn't that
> > the
> > point of the design? If they share the same format list, t
On Sun, 24 Mar 2024 20:03:03 +0100 Damiano Galassi wrote:
> On Sun, Mar 24, 2024 at 6:53 PM Niklas Haas wrote:
>
> > But wait - aren't all filter's lists set to the same reference? Isn't that
> > the
> > point of the design? If they share the same format list, t
On Sun, 24 Mar 2024 14:47:27 +0100 Damiano Galassi wrote:
> On Sun, Mar 24, 2024 at 2:14 PM Niklas Haas wrote:
>
> > On Sun, 24 Mar 2024 13:49:04 +0100 Damiano Galassi
> > wrote:
> > > AVFilterLink colorspace and color_range are first set in
> > > avf
On Sun, 24 Mar 2024 13:49:04 +0100 Damiano Galassi wrote:
> AVFilterLink colorspace and color_range are first set in
> avfiltergraph.c pick_format(),
> so in ff_filter_config_links() they will never be AVCOL_SPC_NONE or
> AVCOL_SPC_NONE.
Wait, now I'm confused what this patch even accomplishes
On Sun, 24 Mar 2024 13:23:28 +0100 Niklas Haas wrote:
> diff --git a/tests/ref/fate/rgb24-mkv b/tests/ref/fate/rgb24-mkv
> index 1cbed136dde..99234f10523 100644
> --- a/tests/ref/fate/rgb24-mkv
> +++ b/tests/ref/fate/rgb24-mkv
> @@ -1,5 +1,5 @@
> -7d767e8238c674ecfa80458cb281c09
On Sun, 24 Mar 2024 10:26:35 +0100 Damiano Galassi wrote:
> There two new fields were never sent down the filter chain,
> and no filter after the first had colorspace and color_range set,
> causing breakage in zscale and possible other filters.
> ---
> libavfilter/avfilter.c | 4
>
From: Niklas Haas
---
libavcodec/dovi_rpu.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavcodec/dovi_rpu.c b/libavcodec/dovi_rpu.c
index b3defd87bda..2b4d2b470c2 100644
--- a/libavcodec/dovi_rpu.c
+++ b/libavcodec/dovi_rpu.c
@@ -94,7 +94,7 @@ int
From: Niklas Haas
We split the inner loop between v1 and v2 extension blocks to print
a warning where an extension block was encountered in an unexpected
context.
Co-authored-by: quietvoid
---
libavcodec/dovi_rpu.c | 178 ++
1 file changed, 178
From: Niklas Haas
The Dolby Vision RPU contains a CRC32 to validate the payload against.
The implementation is CRC32/MPEG-2.
The CRC is only verified with the AV_EF_CRCCHECK flag.
Co-authored-by: quietvoid
---
libavcodec/av1dec.c | 3 ++-
libavcodec/dovi_rpu.c | 18
From: Niklas Haas
---
libavcodec/dovi_rpu.c | 3 +++
libavcodec/dovi_rpu.h | 6 ++
2 files changed, 9 insertions(+)
diff --git a/libavcodec/dovi_rpu.c b/libavcodec/dovi_rpu.c
index d584d99590a..6097bd5422f 100644
--- a/libavcodec/dovi_rpu.c
+++ b/libavcodec/dovi_rpu.c
@@ -47,6 +47,7
From: Niklas Haas
This ensures that `gb` in the following section is fully byte-aligned,
points at the start of the actual RPU, and ends on the CRC terminator.
This is important for both calculation of the CRC, as well as dovi
extension block parsing (which aligns to byte boundaries in various
From: Niklas Haas
Instead of AVERROR(EINVAL)
---
libavcodec/dovi_rpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/dovi_rpu.c b/libavcodec/dovi_rpu.c
index c84a942f476..53f8c288db0 100644
--- a/libavcodec/dovi_rpu.c
+++ b/libavcodec/dovi_rpu.c
@@ -483,5 +483,5
From: Niklas Haas
As well as accessors plus a function for allocating this struct with
extension blocks,
Definitions generously taken from quietvoid/dovi_tool, which is
assembled as a collection of various patent fragments, as well as output
by the official Dolby Vision bitstream verifier tool
From: quietvoid
The NLQ pivots are not documented but should be present in the header
for profile 7 RPU format. It has been verified using Dolby's
verification toolkit.
Signed-off-by: quietvoid
Signed-off-by: Niklas Haas
---
doc/APIchanges| 3 +++
libavcodec/dovi_rpu.c | 9
Changes since v1:
- Rebased onto master
- Dropped av_dovi_metadata_alloc_ext(), instead statically allocate
space for 32 extension blocks (AV_DOVI_MAX_EXT_BLOCKS)
- Removed misleading comment on nlq_pivots
- Fix memory leak on ff_dovi_ctx_flush()
- Switch to using ff_refstruct to properly manage
On Sat, 23 Mar 2024 19:08:04 +0100 Niklas Haas wrote:
> On Sat, 23 Mar 2024 18:58:51 +0100 Andreas Rheinhardt
> wrote:
> > Niklas Haas:
> > > From: Niklas Haas
> > >
> > > As well as accessors plus a function for allocating this struct with
> >
On Sat, 23 Mar 2024 19:00:59 +0100 Andreas Rheinhardt
wrote:
> Niklas Haas:
> > From: Niklas Haas
> >
> > We split the inner loop between v1 and v2 extension blocks to print
> > a warning where an extension block was encountered in an unexpected
> > context.
&
On Sat, 23 Mar 2024 18:58:51 +0100 Andreas Rheinhardt
wrote:
> Niklas Haas:
> > From: Niklas Haas
> >
> > As well as accessors plus a function for allocating this struct with
> > extension blocks,
> >
> > Definitions generously taken from quie
On Sat, 23 Mar 2024 19:02:26 +0100 Andreas Rheinhardt
wrote:
> Niklas Haas:
> > From: Niklas Haas
> >
> > This ensures that `gb` in the following section is fully byte-aligned,
> > points at the start of the actual RPU, and ends on the CRC terminator.
> >
On Fri, 09 Feb 2024 13:11:38 +0100 Niklas Haas wrote:
> On Mon, 05 Feb 2024 19:04:30 +0100 Andreas Rheinhardt
> wrote:
> > This presumes the relevant states to be a cartesian product. Which need
> > not be true. A callback would be better; this would also allow to base
>
On Wed, 20 Mar 2024 20:55:26 +0100 Michael Niedermayer
wrote:
> On Wed, Mar 20, 2024 at 03:23:53PM +0100, Niklas Haas wrote:
> > On Tue, 19 Mar 2024 22:55:56 +0100 Michael Niedermayer
> > wrote:
> > > is it neccessary to drop compatibility to the old syntax ?
> &g
On Tue, 19 Mar 2024 20:16:39 +0100 Niklas Haas wrote:
> From: Niklas Haas
>
> AV1 streams don't use configuration records, so delete them when
> encoding to AV1. Ideally this would be, as the comment suggests, handled
> at the frame-level (and stripped by the av1 enco
From: Niklas Haas
We split the inner loop between v1 and v2 extension blocks to print
a warning where an extension block was encountered in an unexpected
context.
Co-authored-by: quietvoid
---
libavcodec/dovi_rpu.c | 178 ++
1 file changed, 178
From: Niklas Haas
---
libavcodec/dovi_rpu.c | 1 +
libavcodec/dovi_rpu.h | 7 +++
2 files changed, 8 insertions(+)
diff --git a/libavcodec/dovi_rpu.c b/libavcodec/dovi_rpu.c
index cd54c8716dc..21cb1850e3e 100644
--- a/libavcodec/dovi_rpu.c
+++ b/libavcodec/dovi_rpu.c
@@ -48,6 +48,7 @@ void
From: quietvoid
The NLQ pivots are not documented but should be present in the header
for profile 7 RPU format. It has been verified using Dolby's
verification toolkit.
Signed-off-by: quietvoid
Signed-off-by: Niklas Haas
---
doc/APIchanges| 3 +++
libavcodec/dovi_rpu.c | 9
From: Niklas Haas
As well as accessors plus a function for allocating this struct with
extension blocks,
Definitions generously taken from quietvoid/dovi_tool, which is
assembled as a collection of various patent fragments, as well as output
by the official Dolby Vision bitstream verifier tool
From: Niklas Haas
This ensures that `gb` in the following section is fully byte-aligned,
points at the start of the actual RPU, and ends on the CRC terminator.
This is important for both calculation of the CRC, as well as dovi
extension block parsing (which aligns to byte boundaries in various
From: Niklas Haas
The Dolby Vision RPU contains a CRC32 to validate the payload against.
The implementation is CRC32/MPEG-2.
The CRC is only verified with the AV_EF_CRCCHECK flag.
Co-authored-by: quietvoid
---
libavcodec/av1dec.c | 3 ++-
libavcodec/dovi_rpu.c | 18
On Fri, 22 Mar 2024 22:02:39 +0100 Damiano Galassi wrote:
> There two new fields were never sent down the filter chain, and no filter
> after the first had colorspace and color_range set, causing breakage in
> zscale and possible other filters.
> ---
> libavfilter/avfilter.c | 4
>
On Fri, 22 Mar 2024 14:08:07 +0100 Niklas Haas wrote:
> On Fri, 22 Mar 2024 10:41:13 +0100 Anton Khirnov wrote:
> > Quoting Niklas Haas (2024-03-21 13:11:32)
> > > On Thu, 21 Mar 2024 11:16:57 +0100 Anton Khirnov
> > > wrote:
> > > > Quoting Niklas Ha
On Fri, 22 Mar 2024 10:41:13 +0100 Anton Khirnov wrote:
> Quoting Niklas Haas (2024-03-21 13:11:32)
> > On Thu, 21 Mar 2024 11:16:57 +0100 Anton Khirnov wrote:
> > > Quoting Niklas Haas (2024-03-19 20:16:39)
> > > > From: Niklas Haas
> > > >
> >
On Mon, 18 Mar 2024 17:54:08 +0100 Niklas Haas wrote:
> Changes since v3:
>
> - Moved metadata into common AVFilmGrainParams struct, as per James
> Almer's recommendation
> - Fixed width/height field validation
> - Signal this metadata for AV1 (instead of setting
On Thu, 21 Mar 2024 11:16:57 +0100 Anton Khirnov wrote:
> Quoting Niklas Haas (2024-03-19 20:16:39)
> > From: Niklas Haas
> >
> > AV1 streams don't use configuration records, so delete them when
> > encoding to AV1. Ideally this would be, as the comment suggests, han
On Tue, 19 Mar 2024 19:19:29 -0400 Vittorio Giovara
wrote:
> On Tue, Mar 19, 2024 at 7:04 PM Niklas Haas wrote:
>
> > On Tue, 19 Mar 2024 21:59:53 + Cosmin Stejerean via ffmpeg-devel <
> > ffmpeg-devel@ffmpeg.org> wrote:
> > >
> > >
> > &
On Wed, 20 Mar 2024 23:22:03 +0200 Jan Ekström wrote:
> On Wed, Mar 20, 2024 at 9:30 PM Michael Niedermayer
> wrote:
> >
> > On Tue, Mar 19, 2024 at 08:16:42PM +0100, Niklas Haas wrote:
> > > From: Niklas Haas
> > >
> > > libx265 supports
On Tue, 19 Mar 2024 22:55:56 +0100 Michael Niedermayer
wrote:
> is it neccessary to drop compatibility to the old syntax ?
Only if we want to use framesync. If we don't care about synchronizing
the streams, then we could drop FS and just use a custom activate
function which forwards output
On Tue, 19 Mar 2024 21:59:53 + Cosmin Stejerean via ffmpeg-devel
wrote:
>
>
> > On Mar 19, 2024, at 2:39 PM, Derek Buitenhuis
> > wrote:
> >
> > The reason I never implemented this back when I adde RPU side data is that
> > there is a strong chance of generating broken files.
> >
> >
From: Niklas Haas
libx265 supports these natively, we just need to forward them to the
x265picture.
---
libavcodec/libx265.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index 92183b9ca26..92b25844ef6 100644
--- a/libavcodec
From: Niklas Haas
Using the new conversion function implemented in the previous commit.
---
libavcodec/libaomenc.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
index 8c1f84cc9fb..2c8fe524fa7 100644
--- a/libavcodec
From: Niklas Haas
AV1 streams don't use configuration records, so delete them when
encoding to AV1. Ideally this would be, as the comment suggests, handled
at the frame-level (and stripped by the av1 encoder), but given the
status quo of copying the packet-level data here directly, we should
From: Niklas Haas
This function converts from DOVI_RPU_BUFFER (raw RPU NAL) to the more
standardized T.35 syntax introduced with Dolby Vision Profile 10.
---
libavcodec/Makefile | 2 +-
libavcodec/dovi_rpu.c | 91 +++
libavcodec/dovi_rpu.h | 10
From: Niklas Haas
Implementation copied wholesale from dav1d, sans SIMD, under permissive
license. This implementation was extensively verified to be bit-exact,
so it serves as a much better starting point than trying to re-engineer
this from scratch for no reason. (I also authored the original
From: Niklas Haas
Common utility function that can be used by all codecs to select the
right (any valid) film grain parameter set. In particular, this is
useful for AFGS1, which has support for multiple parameters.
However, it also performs parameter validation for H274.
---
doc/APIchanges
From: Niklas Haas
Based on the AOMedia Film Grain Synthesis 1 (AFGS1) spec:
https://aomediacodec.github.io/afgs1-spec/
The parsing has been changed substantially relative to the AV1 film
grain OBU. In particular:
1. There is the possibility of maintaining multiple independent film
grain
From: Niklas Haas
I restricted this SEI to HEVC for now, until I see a H.264 sample.
---
libavcodec/Makefile| 2 +-
libavcodec/h2645_sei.c | 25 +
libavcodec/h2645_sei.h | 3 +++
3 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/libavcodec/Makefile b
From: Niklas Haas
Not directly signalled by AV1, but we should still set this accordingly
so that users will know what the original intended video characteristics
and chroma resolution were.
---
libavcodec/av1dec.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavcodec
From: Niklas Haas
Not directly signalled by AV1, but we should still set this accordingly
so that users will know what the original intended video characteristics
and chroma resolution were.
---
libavcodec/libdav1d.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavcodec
From: Niklas Haas
H.274 specifies that film grain parameters are signalled as intended for
4:4:4 frames, so we always signal this, regardless of the frame's actual
subsampling.
---
libavcodec/h2645_sei.c | 46 +-
1 file changed, 28 insertions(+), 18
From: Niklas Haas
Following the usual logic for H.274 film grain.
---
libavcodec/Makefile | 2 +-
libavcodec/hevcdec.c | 29 ++---
2 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 824845276ae..7ef2e03ca6a
From: Niklas Haas
To allow for AFGS1 usage, which can expose multiple parameter sets for
a single frame.
---
libavutil/frame.h | 4
1 file changed, 4 insertions(+)
diff --git a/libavutil/frame.h b/libavutil/frame.h
index b94687941db..7f616488be8 100644
--- a/libavutil/frame.h
+++ b
From: Niklas Haas
Follow the establish convention of printing the bit depth metadata
per-component.
---
fftools/ffprobe.c | 41 ++---
1 file changed, 26 insertions(+), 15 deletions(-)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index fe2da82e24c
Changes since v3:
- Moved metadata into common AVFilmGrainParams struct, as per James
Almer's recommendation
- Fixed width/height field validation
- Signal this metadata for AV1 (instead of setting it to unspecified)
- Implement ffprobe/showinfo support for the new fields
From: Niklas Haas
---
libavutil/film_grain_params.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/libavutil/film_grain_params.c b/libavutil/film_grain_params.c
index 930d23c7fe9..230ce8d701c 100644
--- a/libavutil/film_grain_params.c
+++ b/libavutil
From: Niklas Haas
---
libavfilter/vf_showinfo.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
index 095cb22639f..28d8ea76e9b 100644
--- a/libavfilter/vf_showinfo.c
+++ b/libavfilter
From: Niklas Haas
This is needed for AV1 film grain as well, when using AFGS1 streams.
Also add extra width/height and subsampling information, which AFGS1
cares about, as part of the same API bump. (And in principle, H274
should also expose this information, since it is needed downstream
On Fri, 15 Mar 2024 09:20:04 -0300 James Almer wrote:
> On 3/15/2024 8:58 AM, Niklas Haas wrote:
> > From: Niklas Haas
> >
> > Unused by AV1, but should still be set properly.
>
> The doxy for av_film_grain_params_alloc() says "Allocate an
> AVFilmGrain
On Fri, 15 Mar 2024 12:58:58 +0100 Niklas Haas wrote:
> From: Niklas Haas
>
> Common utility function that can be used by all codecs to select the
> right (any valid) film grain parameter set. In particular, this is
> useful for AFGS1, which has support for multiple parameter
From: Niklas Haas
Following the usual logic for H.274 film grain.
---
libavcodec/Makefile | 2 +-
libavcodec/hevcdec.c | 29 ++---
2 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 824845276ae..7ef2e03ca6a
101 - 200 of 786 matches
Mail list logo
