Quoting Carotti, Elias via ffmpeg-devel (2023-10-11 12:54:21)
> diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
> index 77a9f173b4..85bd870f5d 100644
> --- a/libavcodec/libx264.c
> +++ b/libavcodec/libx264.c
> @@ -726,7 +726,39 @@ FF_ENABLE_DEPRECATION_WARNINGS
>
> pkt->flags |= AV_P
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 differenc
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 to YUV->YUV
conver
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 (e.g.
automa
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 u
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 sent
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 | 65 ++
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 consi
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 ne
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 c17
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, 2023-10-13 at 16:16 +0200, Anton Khirnov wrote:
> CAUTION: This email originated from outside of the organization. Do
> not click links or open attachments unless you can confirm the sender
> and know the content is safe.
>
>
>
> Quoting Carotti, Elias via ffmpeg-devel (2023-10-11 12:54:
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 filter
> - Replace vf_zscale by vf_colorspace in fftools
>
Why is this? I haven't checked what vf_colorspace suppor
On Fri, Oct 13, 2023 at 12:53:34AM +0200, Stefano Sabatini wrote:
> On date Wednesday 2023-10-11 20:10:15 +0200, Michael Niedermayer wrote:
> > This explains how to request refunds and what can be funded by SPI
> > ---
> > doc/spi.txt | 50 ++
> > 1
On Fri, Oct 13, 2023 at 1:09 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> 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 disallow
h->long_ref isn't guaranteed to be contiguously filled. Use the approach
from both vaapi_h264 and vdpau_h264 which goes through the 16 frames in
h->long_ref to find the LTR entries.
Fixes MR2_MW_A.264 from JVT-AVC_V1.
---
libavcodec/vulkan_h264.c | 11 ---
1 file changed, 8 insertions(+)
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 and not proper payment.
This of course is only available to competent develo
On Fri, Oct 13, 2023 at 3:19 PM 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 and n
On Fri, Oct 13, 2023 at 10:21 AM Niklas Haas wrote:
> 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 10064
Oct 13, 2023, 20:33 by vittorio.giov...@gmail.com:
> 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 filter
>> - Replace vf_zscale by vf_colorspace in fftools
Oct 13, 2023, 22:31 by vittorio.giov...@gmail.com:
> On Fri, Oct 13, 2023 at 3:19 PM 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
On Fri, Oct 13, 2023 at 04:30:56PM -0400, Vittorio Giovara wrote:
> On Fri, Oct 13, 2023 at 3:19 PM 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
> > log
On Fri, Oct 13, 2023 at 5:14 PM Lynne wrote:
> Oct 13, 2023, 20:33 by vittorio.giov...@gmail.com:
>
> > 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-s
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, 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 formats, which require the same
> interlaced scaling logic.
>
> Fortunately, we can get away with re-using
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 formats, which require the same
>
On Fri, Oct 13, 2023 at 6:55 PM Niklas Haas wrote:
> 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
> "
On Sat, Oct 14, 2023 at 01:00:50AM +0200, Niklas Haas wrote:
> 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 co
> On Oct 13, 2023, at 4:00 PM, Vittorio Giovara
> wrote:
>
> TBF this is in part why i was suggesting a new library - I feel like sws is
> affected by bad brading because of these caching issues and imprecise
> conversion, and a new clean api in a new library would make a lot of sense
> in my
dxva2 fail to init when decode h264 with baseline profile becase
`prof_h264_high` does not contains `AV_PROFILE_H264_BASELINE` and
`dxva_check_codec_compatibility` will return error
---
libavcodec/dxva2.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/dxva2.c b/
> On Oct 13, 2023, at 4:00 PM, Niklas Haas wrote:
>
> That said, if the status quo for the past decades is to for vf_scale
> treat unspecified chroma loc as center-aligned, I am no longer sure if
> suddenly changing this behavior is a good idea.
I'd say that the current default (jpeg chroma lo
From: ichlubna
Related to my ticket here: https://trac.ffmpeg.org/ticket/10586
VMAF score was not propagated to AVFormat like SSIM or PSNR in the result of
the filter graph. I have fixed this to make the usage consistent and possible
to get VMAF score per-frame in libavfilter.
The only dirty th
38 matches
Mail list logo
