From: Niklas Haas
This is used by future versions of the spec to implement metadata
compression. Given that we don't yet implement that spec, validate that
this is equal to 0 for now.
---
libavcodec/dovi_rpudec.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavcodec
From: Niklas Haas
In the spec, dm_metadata_present also toggles all extension blocks, so
we need to move them inside the branch.
---
libavcodec/dovi_rpudec.c | 25 +
libavcodec/dovi_rpuenc.c | 21 -
2 files changed, 25 insertions(+), 21 deletions
From: Niklas Haas
Only flush state when we started parsing data, otherwise just error out.
Remove the 'fail' label to make this a bit less confusing to read.
---
libavcodec/dovi_rpudec.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/libavcodec
From: Niklas Haas
Despite the suggestive size limits, this metadata ID has nothing to do
with the VDR metadata ID used for the data mappings. Actually, the
specification leaves them wholly unexplained, other than acknowleding
their existence. Must be some secret dolby sauce. They're not even
From: Niklas Haas
When this is 0, the metadata is explicitly inferred to stated default
values from the spec, rather than inferred from the previous frame's
values.
Likewise, when encoding, instead of checking if the value changed since
the last frame, we need to check if it differs from
From: Niklas Haas
According to the spec, missing previous VDR RPU IDs do not constitute an
error, but we should instead fallback first to VDR RPU with ID 0, and
failing that, synthesize "neutral" metadata.
That's nontrivial though as the resulting metadata will be dependent on
other
From: Niklas Haas
Storing the color metadata alongside the data mapping is no longer
needed, so we can simplify this array's type.
---
libavcodec/dovi_rpu.h| 7 +--
libavcodec/dovi_rpudec.c | 6 +++---
libavcodec/dovi_rpuenc.c | 10 +-
3 files changed, 9 insertions(+), 14
From: Niklas Haas
Move `vdr` into local scope and point only to the field we actually care
about.
---
libavcodec/dovi_rpudec.c | 35 ---
1 file changed, 16 insertions(+), 19 deletions(-)
diff --git a/libavcodec/dovi_rpudec.c b/libavcodec/dovi_rpudec.c
index
On Wed, 05 Jun 2024 12:07:08 +0200 Andreas Rheinhardt
wrote:
> Niklas Haas:
> > From: Niklas Haas
> >
> > This code was unnecessarily trying to be robust against downgrades of
> > libavutil (relative to the version libavcodec was compiled against), but
> > i
From: Niklas Haas
This code was unnecessarily trying to be robust against downgrades of
libavutil (relative to the version libavcodec was compiled against), but
in the process, ended up with very brittle code that is easy to
accidentally forget to update when adding new fields.
Instead, do
From: Niklas Haas
The code as written was wrong. The l2.ms_weight value is coded as
a *signed* integer, rather than a shifted unsigned integer. (And even
so, the offset of 8192 would be too large, since 2^12 = 4096. Ditto for
l8.ms_weight, which should have an offset of 2048, not 8192
From: Niklas Haas
The H.265 specification is quite clear on this case:
> When min_display_mastering_luminance is not in the range of 1 to
> 5, the nominal maximum display luminance of the mastering display
> is unknown or unspecified or specified by other means not
On Wed, 22 May 2024 15:50:43 + Cosmin Stejerean via ffmpeg-devel
wrote:
> From: Cosmin Stejerean
>
> ---
> libavutil/dovi_meta.h | 2 ++
> libavutil/version.h | 2 +-
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/libavutil/dovi_meta.h b/libavutil/dovi_meta.h
>
On Thu, 23 May 2024 03:45:44 + Cosmin Stejerean via ffmpeg-devel
wrote:
> From: Cosmin Stejerean
>
> not all clients support metadata compression, output when
> vdr_dm_metadata_changed fails the DV verifier.
> ---
> libavcodec/dovi_rpu.h| 10 ++
> libavcodec/dovi_rpuenc.c |
On Tue, 21 May 2024 01:17:32 + Cosmin Stejerean via ffmpeg-devel
wrote:
> From: Cosmin Stejerean
>
> It looks like the el_bitdepth_minus8 value in the header can also encode
> ext_mapping_idc in the upper 8 bits.
>
> Samples having a non-zero ext_mapping_idc fail validation currently
On Tue, 21 May 2024 04:03:43 + Cosmin Stejerean via ffmpeg-devel
wrote:
> From: Cosmin Stejerean
>
> not all clients support metadata compression, make this an option and off by
> default until we can verify output.
>
> vdr_dm_metadata_changed = 0 case fails the DV verifier so force this
From: Niklas Haas
Fixes: bb8044581366fe286e16b14515d873979133dbda
---
libavfilter/vf_scale.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index bc53571c1c..696ee272ec 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
On Thu, 11 Apr 2024 00:09:05 +0200 Michael Niedermayer
wrote:
> On Mon, Apr 08, 2024 at 11:55:02PM +0200, Niklas Haas wrote:
> > On Mon, 08 Apr 2024 22:18:33 +0200 Michael Niedermayer
> > wrote:
> > > On Fri, Apr 05, 2024 at 08:57:11PM +0200, Niklas Haas wrote:
&
On Wed, 24 Apr 2024 12:51:55 +0200 Niklas Haas wrote:
> As discussed in my previous series for fixing scale2ref[1], this filter
> is fundamentally broken, and the only real fix would be to switch to
> activate(), or ideally FFFrameSync.
>
> [1] https://ffmpeg.org//pipermail/ff
On Fri, 26 Apr 2024 16:29:03 -0300 James Almer wrote:
> On 4/26/2024 9:27 AM, Niklas Haas wrote:
> > From: Niklas Haas
> >
> > Many filters modify certain aspects of frame data, e.g. through resizing
> > (vf_*scale* family), color volume mapping (vf_lut*, vf_tonema
On Fri, 26 Apr 2024 14:27:58 +0200 Niklas Haas wrote:
> From: Niklas Haas
>
> Many filters modify certain aspects of frame data, e.g. through resizing
> (vf_*scale* family), color volume mapping (vf_lut*, vf_tonemap*), or
> possibly others.
>
> When this happens, we should
From: Niklas Haas
These filters, in general, will apply some arbitrary color volume
transformation. Strip corresponding metadata to be conservative/safe.
---
libavfilter/vf_lut.c | 2 ++
libavfilter/vf_lut2.c | 1 +
libavfilter/vf_lut3d.c | 2 ++
3 files changed, 5 insertions(+)
diff --git
From: Niklas Haas
---
libavfilter/vf_colorspace.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
index 7bacd7892a..46c442f3fb 100644
--- a/libavfilter/vf_colorspace.c
+++ b/libavfilter/vf_colorspace.c
@@ -750,6 +750,10 @@ static
From: Niklas Haas
Switches to av_frame_remove_side_data_changed(), covering a number of
cases that we previously ignored. Additionally, stop stripping metadata
when merely changing colorspace or color range, since these do not
affect the actual color volume of the image data, only the encoding
From: Niklas Haas
Required for both size chnages and color volume changes (as a result of
changing primaries/transfer).
---
libavfilter/vf_zscale.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/libavfilter/vf_zscale.c b/libavfilter/vf_zscale.c
index 45f1bd25ce
From: Niklas Haas
---
libavfilter/vf_scale.c| 2 ++
libavfilter/vf_scale_cuda.c | 3 +++
libavfilter/vf_scale_npp.c| 3 +++
libavfilter/vf_scale_vaapi.c | 3 +++
libavfilter/vf_scale_vt.c | 3 +++
libavfilter/vf_scale_vulkan.c | 3 +++
6 files changed, 17 insertions(+)
diff
From: Niklas Haas
Many filters modify certain aspects of frame data, e.g. through resizing
(vf_*scale* family), color volume mapping (vf_lut*, vf_tonemap*), or
possibly others.
When this happens, we should strip all frame side data that will no
longer be correct/relevant after the operation
On Wed, 24 Apr 2024 16:48:54 +0530 Gyan Doshi wrote:
>
>
> On 2024-04-24 04:21 pm, Niklas Haas wrote:
> > As discussed in my previous series for fixing scale2ref[1], this filter
> > is fundamentally broken, and the only real fix would be to switch to
> > activat
From: Niklas Haas
And remove it from the documentation.
---
Changelog | 1 +
doc/filters.texi | 73 --
libavfilter/vf_scale.c | 3 ++
3 files changed, 4 insertions(+), 73 deletions(-)
diff --git a/Changelog b/Changelog
index
From: Niklas Haas
---
tests/filtergraphs/scale2ref_keep_aspect | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/tests/filtergraphs/scale2ref_keep_aspect
b/tests/filtergraphs/scale2ref_keep_aspect
index f407460ec7..00b04fc3d1 100644
--- a/tests/filtergraphs
From: Niklas Haas
This is automatically enabled if the width/height expressions reference
any ref_* variable. This will ultimately serve as a more principled
replacement for the fundamentally broken scale2ref.
See-Also: https://trac.ffmpeg.org/ticket/10795
---
Changelog | 1
From: Niklas Haas
Preliminary commit, in anticipation of adding support for multiple
inputs (with proper synchronization and activate() callback).
---
doc/filters.texi | 4 +--
libavfilter/vf_scale.c | 65 +++---
2 files changed, 63 insertions(+), 6
From: Niklas Haas
And rename to ff_framesync_class. More convenient for downstream users.
---
libavfilter/framesync.c | 6 +++---
libavfilter/framesync.h | 1 +
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavfilter/framesync.c b/libavfilter/framesync.c
index 1afd70ab21
As discussed in my previous series for fixing scale2ref[1], this filter
is fundamentally broken, and the only real fix would be to switch to
activate(), or ideally FFFrameSync.
[1] https://ffmpeg.org//pipermail/ffmpeg-devel/2024-March/323382.html
The main thing making this difficult is the fact
From: Niklas Haas
Add all recently added frame data types, as well as the new name for
DETECTION_BBOXES as an alias to the older DETECTION_BOUNDING_BOXES.
---
libavfilter/f_sidedata.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/libavfilter/f_sidedata.c b
On Thu, 18 Apr 2024 22:53:51 +0200 Michael Niedermayer
wrote:
> A plugin system moves this patch-management to people who actually
> care, that is the authors of the codecs and (de)muxers.
A plugin system will only solve this insomuch as plugin authors will
just host their plugin code on GitHub
On Wed, 17 Apr 2024 15:58:32 +0200 Michael Niedermayer
wrote:
> Hi all
>
> The pace of inovation in FFmpeg has been slowing down.
> Most work is concentarted nowadays on code refactoring, and adding
> support for new codecs and formats.
>
> Should we
> * make a list of longer term goals
> *
On Thu, 18 Apr 2024 13:30:39 +0200 Andreas Rheinhardt
wrote:
> Niklas Haas:
> > From: Niklas Haas
> >
> > This could be used by codecs to selectively disable parsing Dolby Vision
> > RPUs, and is cheap to support.
> > ---
> > libavcodec/av1dec.c
On Thu, 04 Apr 2024 19:05:13 +0200 Nicolas Gaullier
wrote:
> v4:
> - remove dynamic color_range pass-through (which requires changing outlink
> dynamically and is forbidden)
> - nits style
> - commit msg: simplified example (+ removed example for dynamic color_range
> pass-through)
>
>
On Fri, 12 Apr 2024 13:35:14 +0200 Niklas Haas wrote:
> Changes since v2:
> - Split up dovi_rpu.c into dovi_rpudec.c and dovi_rpueenc.
> - Added missing dependencies of encoders onto dovi_rpueenc
> - Clarified and documented semantics of guess_profile()
> - Changed misleading
On Fri, 12 Apr 2024 12:45:44 +0200 Niklas Haas wrote:
> On Tue, 09 Apr 2024 15:12:05 +0200 Niklas Haas wrote:
> > From: Niklas Haas
> >
> > This version is seven years old, and present in Debian oldoldstable,
> > Ubuntu 20.04 and Leap 15.0.
> >
> > Al
On Sat, 13 Apr 2024 17:21:08 +0200 Kacper Michajłow wrote:
> As we can read in ST 2086:
>
> Values outside the specified ranges of luminance and chromaticity values
> are not reserved by SMPTE, and can be used for purposes outside the
> scope of this standard.
>
> This is further acknowledged
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 could be used by codecs to selectively disable parsing Dolby Vision
RPUs, and is cheap to support.
---
libavcodec/av1dec.c | 1 +
libavcodec/dovi_rpu.h| 2 ++
libavcodec/dovi_rpudec.c | 6 ++
libavcodec/hevcdec.c | 1 +
libavcodec/libdav1d.c| 1 +
5
From: Niklas Haas
To allow compiling the decoding objects without the encoding objects and
vice versa. Common helpers that users of both APIs need are put into the
shared dovi_rpu.c.
---
libavcodec/Makefile | 2 +-
libavcodec/dovi_rpu.c| 624
From: Niklas Haas
To distinguish it from the to-be-added dovi_rpuenc.
---
configure | 10 +-
libavcodec/Makefile | 2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/configure b/configure
index 55f1fc354d..c1e1ece1e2 100755
--- a/configure
+++ b/configure
From: Niklas Haas
---
configure | 2 +-
libavcodec/libaomenc.c | 28
2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index d25d0f6907..bf63c831af 100755
--- a/configure
+++ b/configure
@@ -3485,7 +3485,7
From: Niklas Haas
To allow internally re-using it for both the encoder and decoder.
This is based on HEVC only, H.264/AV1 use their own (hopefully correctly
signalled) profiles (and in particular, the AV1 decoders implicitly
default the correct profile in the absence of a configuration record
From: Niklas Haas
---
configure | 1 +
libavcodec/libsvtav1.c | 34 ++
2 files changed, 35 insertions(+)
diff --git a/configure b/configure
index cce37bb32e..6fbd0e44ff 100755
--- a/configure
+++ b/configure
@@ -3534,6 +3534,7
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
libx265 supports these natively, we just need to attach the generated
NALs to the x265picture, as well as setting the appropriate DV profile.
---
configure| 2 +-
libavcodec/libx265.c | 40
2 files changed, 41 insertions
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
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
This was never set in ff_dovi_ctx_replace(), leading to possibly
out-of-date when copying from one thread to another.
---
libavcodec/dovi_rpu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/dovi_rpu.c b/libavcodec/dovi_rpu.c
index d95c7e03af..bfb7b9fe66 100644
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
Changes since v2:
- Split up dovi_rpu.c into dovi_rpudec.c and dovi_rpueenc.
- Added missing dependencies of encoders onto dovi_rpueenc
- Clarified and documented semantics of guess_profile()
- Changed misleading commit message
___
ffmpeg-devel mailing
On Tue, 09 Apr 2024 15:12:05 +0200 Niklas Haas wrote:
> From: Niklas Haas
>
> This version is seven years old, and present in Debian oldoldstable,
> Ubuntu 20.04 and Leap 15.0.
>
> Allows cleaning up the file substantially. In particular, this is
> motivated by the d
le
operations (e.g. S302M -> Dolby E -> MXF remux).
Regarding Gyan Doshi's main objection that doing so would possibly
delete S302M metadata (e.g. S-ADM), it was observed that if the need for
such metadata truly arises, it should either be parsed by FFmpeg or
attached as an opaque side data bl
On Wed, 10 Apr 2024 15:18:52 +0200 Michael Niedermayer
wrote:
> On Tue, Apr 09, 2024 at 02:53:28PM +0200, Niklas Haas wrote:
> > On Sat, 06 Apr 2024 22:28:26 +0200 Michael Niedermayer
> > wrote:
> > > On Fri, Apr 05, 2024 at 07:44:52PM +0200, Niklas Haas wrote:
&
On Wed, 10 Apr 2024 14:59:15 +0200 Michael Niedermayer
wrote:
> On Wed, Apr 10, 2024 at 12:29:06PM +0200, Niklas Haas wrote:
> > On Wed, 10 Apr 2024 03:25:45 +0200 Michael Niedermayer
> > wrote:
> > > On Mon, Apr 08, 2024 at 02:57:20PM +0200, Niklas Haas wrote:
&
On Wed, 10 Apr 2024 03:13:02 +0200 Michael Niedermayer
wrote:
> On Mon, Apr 08, 2024 at 02:57:18PM +0200, Niklas Haas wrote:
> > From: Niklas Haas
> >
> > The only meaningful difference between choose_pix_fmts and the default
> > code was the inclusion of an ext
On Wed, 10 Apr 2024 12:29:06 +0200 Niklas Haas wrote:
> On Wed, 10 Apr 2024 03:25:45 +0200 Michael Niedermayer
> wrote:
> > On Mon, Apr 08, 2024 at 02:57:20PM +0200, Niklas Haas wrote:
> > > From: Niklas Haas
> > >
> > > To convert between colo
On Wed, 10 Apr 2024 03:25:45 +0200 Michael Niedermayer
wrote:
> On Mon, Apr 08, 2024 at 02:57:20PM +0200, Niklas Haas wrote:
> > From: Niklas Haas
> >
> > To convert between color spaces/ranges, if needed by the codec
> > properties.
> > ---
On Tue, 09 Apr 2024 17:36:30 +0200 Andreas Rheinhardt
wrote:
> Niklas Haas:
> > 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.
> > ---
&
On Tue, 09 Apr 2024 17:37:32 +0200 Andreas Rheinhardt
wrote:
> Niklas Haas:
> > From: Niklas Haas
> >
> > This is based on HEVC only, H.264/AV1 use their own (hopefully correctly
> > signalled) profiles.
> > ---
> > libavcodec/dovi_rpu.c | 5 +++--
From: Niklas Haas
This version is seven years old, and present in Debian oldoldstable,
Ubuntu 20.04 and Leap 15.0.
Allows cleaning up the file substantially. In particular, this is
motivated by the desire to stop relying on init_static_data.
---
configure| 2 +-
libavcodec/libx264
On Mon, 08 Apr 2024 14:57:17 +0200 Niklas Haas wrote:
> From: Niklas Haas
>
> For avcodec_get_supported_config(), which requires this value be set on
> the actual ost->enc_ctx being queried.
> ---
> fftools/ffmpeg_filter.c | 16 ++--
> 1 file changed, 6 ins
On Mon, 08 Apr 2024 14:57:13 +0200 Niklas Haas wrote:
> 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 --g
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 | 40
1 file changed, 40 insertions(+)
diff --git a/libavcodec
From: Niklas Haas
---
libavcodec/libaomenc.c | 28
1 file changed, 28 insertions(+)
diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
index 4a71bba9c9c..b43a902a384 100644
--- a/libavcodec/libaomenc.c
+++ b/libavcodec/libaomenc.c
@@ -43,6 +43,7
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
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 could be used by codecs to selectively disable parsing Dolby Vision
RPUs, and is cheap to support.
---
libavcodec/av1dec.c | 1 +
libavcodec/dovi_rpu.c | 6 ++
libavcodec/dovi_rpu.h | 2 ++
libavcodec/hevcdec.c | 1 +
libavcodec/libdav1d.c | 1 +
5 files changed
From: Niklas Haas
---
libavcodec/libsvtav1.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index 105c3369c0f..cd62103dba4 100644
--- a/libavcodec/libsvtav1.c
+++ b/libavcodec/libsvtav1.c
@@ -23,6 +23,7
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
Changes since v1:
- Moved dolbyvision option from AVCodecContext to DOVIContext, and
add an explicit option only to codecs that use it
- Changed its type to AV_OPT_TYPE_BOOL
- Made it control decoding as well as encoding, so you can use
`-dolbyvision off` as an input option to suppress it
-
On Sat, 06 Apr 2024 22:28:26 +0200 Michael Niedermayer
wrote:
> On Fri, Apr 05, 2024 at 07:44:52PM +0200, Niklas Haas wrote:
> > From: Niklas Haas
> >
> > This version is four years old, and present in Debian oldstable, Ubuntu
> > 22.04 and Leap 15.1.
>
> Ubun
On Mon, 08 Apr 2024 22:18:33 +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
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
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, and to also print the channel layout using an AVBPrint to
avoid hard-coding the assumption that the length is less than 128
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
This codec's capabilities should be set dynamically based on the value
of strict_std_compliance, when available. This will allow us to finally
get rid of the strictness hack in ffmpeg_filter.c.
---
libavcodec/mjpegenc.c | 21 +++--
1 file changed, 19 insertions
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 5023d2fda42..0488e5c3c9a 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 cdb83312614..64dc69f8547 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -2087,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 3533ac5cc1f..e36a1eb9505 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -892,14 +892,24
From: Niklas Haas
To convert between color spaces/ranges, if needed by the codec
properties.
---
fftools/ffmpeg_filter.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 83259416a68..a40c6f381f2
From: Niklas Haas
The only meaningful difference between choose_pix_fmts and the default
code was the inclusion of an extra branch for `keep_pix_fmt` being true.
However, in this case, we either:
1. Force the specific `ofp->format` that we inherited from
ofilter_bind_ost, or if no for
From: Niklas Haas
This is no longer needed, since we now correctly negotiate the required
range from the mjpeg encoder via avcodec_get_supported_config().
---
fftools/ffmpeg_filter.c | 15 ---
1 file changed, 15 deletions(-)
diff --git a/fftools/ffmpeg_filter.c b/fftools
From: Niklas Haas
For avcodec_get_supported_config(), which requires this value be set on
the actual ost->enc_ctx being queried.
---
fftools/ffmpeg_filter.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filte
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..4f8c81102d3 100644
--- a/fftools/ffmpeg_mux_init.c
+++ b/fftools/ffmpeg_mux_init.c
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
I went through all codecs and put them into five basic categories:
1. JPEG range only
2. MPEG range only
3. Explicitly tagged
4. Broken (codec supports both but encoder ignores tags)
5. N/A (headerless or pseudo-formats)
Filters in category 5 remain untouched. The rest gain
Changes since v1:
- Add implementation of AV_CODEC_CONFIG_COLOR_RANGE for all codecs
- Use AVBPrint instead of char desc[128] for printing channel
descriptions
- Implement new constraints inside fftools/ffmpeg_filter.c
- Remove old YUVJ/MJPEG strictness hack
1 - 100 of 786 matches
Mail list logo
