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 t
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 becau
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 | 8
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
> index
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 specified
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)
In
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 the
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
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
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(+
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
o
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 fro
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
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/
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
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/libav
On Sun, 09 Jun 2024 17:05:46 +0200 Niklas Haas wrote:
> 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" metadat
From: Niklas Haas
---
libavcodec/dovi_rpudec.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/libavcodec/dovi_rpudec.c b/libavcodec/dovi_rpudec.c
index a477dbd4e3..fc3b0a2b82 100644
--- a/libavcodec/dovi_rpudec.c
+++ b/libavcodec/dovi_rpudec.c
From: Niklas Haas
This is specified to be in the range -1 to 4095, apparently the only
extension level with such a restriction.
---
libavcodec/dovi_rpudec.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/dovi_rpudec.c b/libavcodec/dovi_rpudec.c
index fc3b0a2b82..306efbb31f
On Thu, 23 May 2024 19:50:23 + 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.
>
> Compared to v2 this makes the dovi field name a parameter of the
> DOVI_ENCOD
On Wed, 22 May 2024 15:50:34 + Cosmin Stejerean via ffmpeg-devel
wrote:
> From: Cosmin Stejerean
>
> Some DolbyVision samples fail to parse currently due to mis-reading the
> el_bit_depth_minus8 field. Upon investigation it seems that the RPU syntax has
> been extended in an as of yet undoc
Moves metadata compression out of the codecs and into a bitstream
filter. This is required by design, because keyframes must have
compression disabled (for obvious reasons). Therefore, we _must_
generate the dolby vision RPUs after encoding.
The downside of this approach is that it requires "redun
From: Niklas Haas
ff_dovi_rpu_parse() and ff_dovi_rpu_generate() are a bit inconsistent in
that they expect different levels of encapsulation, due to the nature of
how this is handled in the context of different APIs. Clarify the status
quo. (And fix an incorrect reference to the RPU payload
From: Niklas Haas
As the comment implies, DOVIContext.ext_blocks should also reflect the
current state after ff_dovi_rpu_generate().
Fluff for now, but will be needed once we start implementing metadata
compression for extension blocks as well.
---
libavcodec/dovi_rpuenc.c | 12
1
From: Niklas Haas
And only override it if we either have an exact match, or if we still
have unused metadata slots (to avoid an overwrite).
---
libavcodec/dovi_rpuenc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/dovi_rpuenc.c b/libavcodec/dovi_rpuenc.c
From: Niklas Haas
Will be used to control compression, encapsulation etc.
---
libavcodec/dovi_rpu.h| 2 +-
libavcodec/dovi_rpuenc.c | 2 +-
libavcodec/libaomenc.c | 2 +-
libavcodec/libsvtav1.c | 2 +-
libavcodec/libx265.c | 3 ++-
5 files changed, 6 insertions(+), 5 deletions
From: Niklas Haas
And move the choice of desired container to `flags`. This is needed to
handle differing API requirements (e.g. libx265 requires the NAL RBSP,
but CBS BSF requires the unescaped bytes).
---
libavcodec/dovi_rpu.h| 16 ++--
libavcodec/dovi_rpuenc.c | 22
From: Niklas Haas
Keyframes must reset the metadata compression state, so we cannot enable
metadata compression inside the encoders. Solve this by adding a new
flag, rather than removing it entirely, because I plan on adding
a bitstream filter for metadata compression.
---
libavcodec/dovi_rpu.h
From: Niklas Haas
Provides direct access to the AVDOVIMetadata without having to attach it
to a frame.
---
libavcodec/dovi_rpu.h| 9 +
libavcodec/dovi_rpudec.c | 40 +++-
2 files changed, 36 insertions(+), 13 deletions(-)
diff --git a/libavcodec
From: Niklas Haas
This can be used to strip dovi metadata, or enable/disable dovi
metadata compression. Possibly more use cases in the future.
---
configure | 1 +
doc/bitstream_filters.texi | 21 +++
libavcodec/bitstream_filters.c | 1 +
libavcodec/bsf/Makefile
On Tue, 18 Jun 2024 21:35:33 +0200 Niklas Haas wrote:
> From: Niklas Haas
>
> And only override it if we either have an exact match, or if we still
> have unused metadata slots (to avoid an overwrite).
> ---
> libavcodec/dovi_rpuenc.c | 4 ++--
> 1 file changed, 2 inser
proach seem reasonable? How do people feel about introducing
a new API vs. trying to hammer the existing API into the shape I want it to be?
I've attached an example of what could end up looking like. If
there is broad agreement on this design, I will move on to an implementation.
/*
* Copy
On Sat, 22 Jun 2024 15:23:22 +0100 Andrew Sayers
wrote:
> On Sat, Jun 22, 2024 at 03:13:34PM +0200, Niklas Haas wrote:
> [...]
> >
> > ## Comments / feedback?
> >
> > Does the above approach seem reasonable? How do people feel about
> > introducing
&g
On Sat, 22 Jun 2024 21:52:42 +0200 Michael Niedermayer
wrote:
> On Sat, Jun 22, 2024 at 05:10:28PM +0200, Niklas Haas wrote:
> > On Sat, 22 Jun 2024 15:23:22 +0100 Andrew Sayers
> > wrote:
> > > On Sat, Jun 22, 2024 at 03:13:34PM
On Sun, 23 Jun 2024 00:19:13 +0200 Vittorio Giovara
wrote:
> On Sat, Jun 22, 2024 at 3:22 PM Niklas Haas wrote:
>
> > Hey,
> >
> > As some of you know, I got contracted (by STF 2024) to work on improving
> > swscale, over the course of the next couple of months.
On Sun, 23 Jun 2024 14:57:31 -0300 James Almer wrote:
> On 6/22/2024 7:19 PM, Vittorio Giovara wrote:
> > Needless to say I support the plan of renaming the library so that it can
> > be inline with the other libraries names, and the use of a separate header
> > since downstream applications will
On Mon, 24 Jun 2024 15:56:12 + Cosmin Stejerean via ffmpeg-devel
wrote:
> From: Cosmin Stejerean
>
> now that we are reading ext_mapping_idc as the upper 8 bits of
> el_bit_depth_minus8 we need to use get_ue_golomb_long rather than
> get_ue_golomb_31 for reading it
>
> ---
> libavcodec/do
From: Niklas Haas
ff_dovi_rpu_parse() and ff_dovi_rpu_generate() are a bit inconsistent in
that they expect different levels of encapsulation, due to the nature of
how this is handled in the context of different APIs. Clarify the status
quo. (And fix an incorrect reference to the RPU payload
From: Niklas Haas
As the comment implies, DOVIContext.ext_blocks should also reflect the
current state after ff_dovi_rpu_generate().
Fluff for now, but will be needed once we start implementing metadata
compression for extension blocks as well.
---
libavcodec/dovi_rpuenc.c | 12
1
From: Niklas Haas
And only override it if we either have an exact match, or if we still
have unused metadata slots (to avoid an overwrite).
---
libavcodec/dovi_rpuenc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/dovi_rpuenc.c b/libavcodec/dovi_rpuenc.c
From: Niklas Haas
The version as written also compared the vdr_rpu_id field, which would
defeat the purpose of trying to look for a matching slot in the
first place.
---
libavcodec/dovi_rpuenc.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/libavcodec
From: Niklas Haas
Will be used to control compression, encapsulation etc.
---
libavcodec/dovi_rpu.h| 2 +-
libavcodec/dovi_rpuenc.c | 2 +-
libavcodec/libaomenc.c | 2 +-
libavcodec/libsvtav1.c | 2 +-
libavcodec/libx265.c | 3 ++-
5 files changed, 6 insertions(+), 5 deletions
From: Niklas Haas
And move the choice of desired container to `flags`. This is needed to
handle differing API requirements (e.g. libx265 requires the NAL RBSP,
but CBS BSF requires the unescaped bytes).
---
libavcodec/dovi_rpu.h| 16 ++--
libavcodec/dovi_rpuenc.c | 22
From: Niklas Haas
Keyframes must reset the metadata compression state, so we cannot enable
metadata compression inside the encoders. Solve this by adding a new
flag, rather than removing it entirely, because I plan on adding
a bitstream filter for metadata compression.
---
libavcodec/dovi_rpu.h
From: Niklas Haas
Provides direct access to the AVDOVIMetadata without having to attach it
to a frame.
---
libavcodec/dovi_rpu.h| 9 +
libavcodec/dovi_rpudec.c | 40 +++-
2 files changed, 36 insertions(+), 13 deletions(-)
diff --git a/libavcodec
From: Niklas Haas
This can be used to strip dovi metadata, or enable/disable dovi
metadata compression. Possibly more use cases in the future.
---
configure | 1 +
doc/bitstream_filters.texi | 21 +++
libavcodec/bitstream_filters.c | 1 +
libavcodec/bsf/Makefile
On Mon, 24 Jun 2024 16:44:33 +0200 Vittorio Giovara
wrote:
> On Sun, Jun 23, 2024 at 7:57 PM James Almer wrote:
>
> > On 6/22/2024 7:19 PM, Vittorio Giovara wrote:
> > > Needless to say I support the plan of renaming the library so that it can
> > > be inline with the other libraries names, and
On Tue, 25 Jun 2024 10:58:00 +0200 "J. Dekker" wrote:
> Signed-off-by: J. Dekker
> ---
> libavutil/riscv/cpu.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavutil/riscv/cpu.h b/libavutil/riscv/cpu.h
> index bb8e08aa14..191e4478c5 100644
> --- a/libavutil/riscv/cpu
On Sat, 29 Jun 2024 15:41:58 +0800 Zhao Zhili wrote:
>
>
> > On Jun 22, 2024, at 21:13, Niklas Haas wrote:
> >
> > Hey,
> >
> > As some of you know, I got contracted (by STF 2024) to work on improving
> > swscale, over the course of the next couple
On Sat, 22 Jun 2024 15:13:34 +0200 Niklas Haas wrote:
> Hey,
>
> As some of you know, I got contracted (by STF 2024) to work on improving
> swscale, over the course of the next couple of months. I want to share my
> current plans and gather feedback + measure sentiment.
>
>
On Sat, 29 Jun 2024 14:35:32 +0200 Michael Niedermayer
wrote:
> On Sat, Jun 29, 2024 at 01:47:43PM +0200, Niklas Haas wrote:
> > On Sat, 22 Jun 2024 15:13:34 +0200 Niklas Haas wrote:
> > > Hey,
> > >
> > > As some of you know, I got contracted (by STF 2024
From: Niklas Haas
Similar in spirit and design to 66845cffc3bbb, but slightly simpler due
to the lack of interlaced frames in HEVC. See that commit for more
details.
For the seed value, since no specification for this appears to exist, I
semi-arbitrarily decided to base it off the POC id alone
and most importantly,
> > it's bug-free and extendable.
> >
> > Of interest to anyone who's only interested in public API changes
> > are patches 2/14 and 6/14. The changes made are backwards compatible,
> > and will not break API users.
> >
> >
From: Niklas Haas
This filter conceptually maps the libplacebo `pl_renderer` API into
libavfilter, which is a high-level image rendering API designed to work
with an RGB pipeline internally. As such, there's no way to avoid e.g.
chroma interpolation with this filter, although new versio
From: Niklas Haas
In particular, allows users to go all the way up to PL_LOG_TRACE if
desired. (While also avoiding some potentially unnecessary callbacks for
filtered messages, including e.g. the CPU cost of printing out shader
sources)
Response to runtime log level changes by updating it once
On Thu, 02 Dec 2021 19:13:17 +0100 Andreas Rheinhardt
wrote:
> Lynne:
> > The issue is that if ffmpeg is compiled without Vulkan, and an API
> > user includes and uses the functions exposed in hwcontext_vulkan.h,
> > then a linking error will happen, as the hwcontext_vulkan.c file has
> > not be
A follow-up to my previous post (almost a year ago) about YUVJ removal.
This patchset does not add full filter colorspace negotiation - rather,
we add metadata only to AVCodec, with a warning being printed if
incorrect frames are sent. fftools/ffmpeg_filter.c gained an explicit
auto-conversion case
From: Niklas Haas
This is motivated primarily by a desire for YUVJ removal, which will
require signalling the supported color ranges as part of the codec
capabilities. But since we're here anyway, we might as well add all of
the metadata, which I foresee seeing more use in the future
From: Niklas Haas
This currently defaults to AVCOL_SPC_RGB, but it should properly default
to AVCOL_SPC_UNSPECIFIED, following the logic of the other fields.
---
libavcodec/options.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/options.c b/libavcodec/options.c
index a9b35ee1c3
From: Niklas Haas
To convert between color ranges/matrices, if needed by the codec
properties. Swscale can't do this currently, so we fall back to using
zscale. We momentarily duplicate the mjpeg strictness logic to also
enfoce full range. This duplication will be cleaned up in the next
c
From: Niklas Haas
Since swscale currently can't handle conversion between different
colorimetry sets, supplement the missing bits and pieces using zscale.
Subject to change in the future, if libswscale ever gets the capability
to convert between colorspaces natively.
---
fftools/ffmpeg_fil
From: Niklas Haas
In general, the logic is always the same: if the codec supports only a
single format, enforce it if possible. Otherwise, throw an error when
an incompatible format is thrown.
To preserve backwards compatibility and make this check less pedantic
than it needs to be, always
From: Niklas Haas
Only affects amv and roqvideo. (mjpeg is handled separately by fftools)
---
libavcodec/mjpegenc.c| 3 +++
libavcodec/roqvideoenc.c | 2 ++
2 files changed, 5 insertions(+)
diff --git a/libavcodec/mjpegenc.c b/libavcodec/mjpegenc.c
index 508772987f..c827a47e59 100644
--- a
On Wed, 11 Oct 2023 18:55:21 +0200 Michael Niedermayer
wrote:
> On Wed, Oct 11, 2023 at 04:55:38PM +0200, Niklas Haas wrote:
> > From: Niklas Haas
> >
> > Since swscale currently can't handle conversion between different
> > colorimetry sets, supplement the miss
From: Niklas Haas
Curiously absent.
---
libavfilter/vf_showinfo.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
index bf8580bc8d..71869446c6 100644
--- a/libavfilter/vf_showinfo.c
+++ b/libavfilter/vf_showinfo.c
From: Niklas Haas
This logic only covers the case of yuv420p. Extend this logic to cover
*all* vertically subsampled YUV formats, which require the same
interlaced scaling logic.
Fortunately, we can get away with re-using the same code for both JPEG
and MPEG range YUV, because the only
Changes since v1:
- Remove unneeded patch (AVCodecContext.colorspace init)
- Merge auto-range conversion into auto-scale filter
- Replace vf_zscale by vf_colorspace in fftools
- Add some miscellaneous fixes for various FATE tests
- Clean up some additional vestigiaul YUVJ remnants
__
From: Niklas Haas
If we don't convert the pixel format, then we shouldn't touch the pixel
range by default, either. Ensures full-range YUV input comes out as
full-range YUV output, unless we go through a pixel format conversion.
In theory, we may also want to extend this logic t
From: Niklas Haas
This is motivated primarily by a desire for YUVJ removal, which will
require signalling the supported color ranges as part of the codec
capabilities. But since we're here anyway, we might as well add all of
the metadata, which I foresee seeing more use in the future
From: Niklas Haas
To convert between color ranges, if needed by the codec properties. We
momentarily duplicate the mjpeg strictness logic to also enfoce full
range. This duplication will be cleaned up in the next commit.
Due to avcodec_open2 being called after ofilter_bind_ost, we need to
look
From: Niklas Haas
Setting the output range/primaries/colorspace to unspecified now infers
the value from the input signal. If the input signal also has unknown
prim/trc, and no specific output is requested, enable passthrough mode.
As a technical implementation detail, define a static const
From: Niklas Haas
These no longer exist.
---
libavutil/pixdesc.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index d640624aaf..75b1ae3cea 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -2977,8 +2977,7
From: Niklas Haas
To convert between color space/transfer/primaries, if needed by the
codec properties. Libswscale can't handle this at the moment, but
fortunately there exists vf_colorspace which we can use unconditionally.
---
fftools/ffmpeg_filter.c
From: Niklas Haas
In general, the logic is always the same: if the codec supports only a
single format, enforce it if possible. Otherwise, throw an error when
an incompatible format is thrown.
To preserve backwards compatibility and make this check less pedantic
than it needs to be, always
From: Niklas Haas
The input file is MPEG range, so we should also encode to MPEG range
before comparing against it. This bug was avoided in the past because
JPEG range YUV inputs were tagged as YUVJ, which resulted in an
automatic conversion to PC range by default.
After YUVJ removal, we will
From: Niklas Haas
This requires conversion from full to limited range JPEG, as mjpeg only
accepts limited range (without extra strictness options). The old
solution to this problem was to manually insert -vf scale, but this does
not work in the absencee of YUVJ as vf_scale cannot (yet) negotiate
From: Niklas Haas
Only affects amv and roqvideo. (mjpeg is handled separately by fftools)
---
libavcodec/mjpegenc.c| 3 +++
libavcodec/roqvideoenc.c | 2 ++
2 files changed, 5 insertions(+)
diff --git a/libavcodec/mjpegenc.c b/libavcodec/mjpegenc.c
index 508772987f..c827a47e59 100644
--- a
From: Niklas Haas
YUVJ no longer exists, so this is now just a check for luma-only
formats, and no longer needs to mutate the pixel format.
---
libswscale/utils.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/libswscale/utils.c b/libswscale/utils.c
index
From: Niklas Haas
---
tests/ref/fate/filter-pixdesc-yuvj411p | 1 -
tests/ref/fate/filter-pixdesc-yuvj420p | 1 -
tests/ref/fate/filter-pixdesc-yuvj422p | 1 -
tests/ref/fate/filter-pixdesc-yuvj440p | 1 -
tests/ref/fate/filter-pixdesc-yuvj444p | 1 -
tests/ref/pixfmt/yuvj420p | 2
On Fri, 13 Oct 2023 21:19:34 +0200 Michael Niedermayer
wrote:
> Hi everyone
>
> I propose using 15k$ from SPI for funding sws cleanup work.
> this is substantially less than what people belive this needs (see IRC logs
> from yesterday or so)
> So it really is more a small price for a good deed
On Fri, 13 Oct 2023 19:42:44 -0300 James Almer wrote:
> Anton wrote and pushed an AVFrame based API. It can surely be
> improved/extended to use AVFrame metadata.
Yes, this is actually a good idea. This API endpoint already has the
"correct" signature, so we could definitely re-use it (and SwsCo
On Sat, 14 Oct 2023 00:52:23 +0200 Michael Niedermayer
wrote:
> On Fri, Oct 13, 2023 at 04:22:05PM +0200, Niklas Haas wrote:
> > From: Niklas Haas
> >
> > This logic only covers the case of yuv420p. Extend this logic to cover
> > *all* vertically subsampled YUV form
On Fri, 13 Oct 2023 19:10:33 +0200 Andreas Rheinhardt
wrote:
> This design has several drawbacks:
> 1. It adds stuff that will only be set by a tiny minority of AVCodec's
> to all of them.
> 2. It is based around the underlying assumption that the set of
> permissible states (tupels) is a cartesi
On Fri, 13 Oct 2023 19:10:33 +0200 Andreas Rheinhardt
wrote:
> 2. It is based around the underlying assumption that the set of
> permissible states (tupels) is a cartesian product of a set of color
> spaces, a set of color ranges etc. This is wrong: E.g. VP9 disallows
> limited-range RGB (it is s
On Sat, 14 Oct 2023 09:31:32 -0400 Leo Izen wrote:
> On 10/13/23 10:24, Niklas Haas wrote:
> > From: Niklas Haas
> >
> > This is motivated primarily by a desire for YUVJ removal, which will
> > require signalling the supported color ranges as part of the codec
> &
On Sat, 14 Oct 2023 19:00:36 +0200 Michael Niedermayer
wrote:
> Well there are 2 further aspects with that.
>
> The first one is bluntly put. If you dont understand the old code, then
> you probably are not qualified to write better code.
> People tend not to successfully improve things they don
On Fri, 13 Oct 2023 14:33:11 -0400 Vittorio Giovara
wrote:
> On Fri, Oct 13, 2023 at 10:27 AM Niklas Haas wrote:
>
> > Changes since v1:
> >
> > - Remove unneeded patch (AVCodecContext.colorspace init)
> > - Merge auto-range conversion into auto-scale fil
From: Niklas Haas
These are not supported by the drawing functions at all, and were
incorrectly advertised as supported in the past.
---
libavfilter/drawutils.c | 3 +++
tests/ref/fate/filter-pixfmts-pad | 1 -
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavfilter
From: Niklas Haas
There are already several places in the codebase that match desc->name
against "xyz", and many downstream clients replicate this behavior.
I have no idea why this is not just a flag.
Motivated by my desire to add yet another check for XYZ to the codebase,
and I
From: Niklas Haas
---
libavfilter/drawutils.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/libavfilter/drawutils.c b/libavfilter/drawutils.c
index c31ab6bd5a..1081938d86 100644
--- a/libavfilter/drawutils.c
+++ b/libavfilter/drawutils.c
@@ -22,7 +22,6 @@
#include
#include
From: Niklas Haas
---
libavutil/pixdesc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index f2647d3d55..4e4a63e287 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -3055,13 +3055,13 @@ static int
From: Niklas Haas
---
libavformat/vapoursynth.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/libavformat/vapoursynth.c b/libavformat/vapoursynth.c
index 965d36dc2e..b79ecfcf1b 100644
--- a/libavformat/vapoursynth.c
+++ b/libavformat/vapoursynth.c
@@ -118,7 +118,8
On Thu, 26 Oct 2023 10:13:03 -0300 James Almer wrote:
> On 10/26/2023 9:23 AM, Nicolas George wrote:
> > Niklas Haas (12023-10-26):
> >> From: Niklas Haas
> >>
> >> ---
> >> libavfilter/drawutils.c | 3 ---
> >> 1 file changed, 3 deletions
From: Niklas Haas
These are not supported by the drawing functions at all, and were
incorrectly advertised as supported in the past.
Note: This check is added only to separate the logic change from the API
change in the following commit, and will be removed again after it
becomes redundant
From: Niklas Haas
There are already several places in the codebase that match desc->name
against "xyz", and many downstream clients replicate this behavior.
I have no idea why this is not just a flag.
Motivated by my desire to add yet another check for XYZ to the codebase,
and I
From: Niklas Haas
The code above this does a whitelist on desc->flags, which now includes
the (disallowed) AV_PIX_FMT_FLAG_XYZ for XYZ formats. So there is no
more need for a separate check, here.
---
libavfilter/drawutils.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/libavfil
From: Niklas Haas
---
libavutil/pixdesc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index f2647d3d55..4e4a63e287 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -3055,13 +3055,13 @@ static int
From: Niklas Haas
---
libavformat/vapoursynth.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/libavformat/vapoursynth.c b/libavformat/vapoursynth.c
index 965d36dc2e..b79ecfcf1b 100644
--- a/libavformat/vapoursynth.c
+++ b/libavformat/vapoursynth.c
@@ -118,7 +118,8
From: Niklas Haas
More commonly, this fixes the case of sws_setColorspaceDetails after
sws_getContext, since the latter implies sws_init_context.
The problem here is that sws_init_context sets up the range conversion
and fast path tables based on the values of srcRange/dstRange at init
time
From: Niklas Haas
Alpha planes are explicitly full range, even for limited range YUVA
formats. Mark them as such.
---
libavfilter/vf_extractplanes.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavfilter/vf_extractplanes.c b/libavfilter/vf_extractplanes.c
index 7b7149ab24..ca406ff323
1 - 100 of 1709 matches
Mail list logo
