This commit implements a standard, compliant, version 3 and version 4
FFv1 encoder, entirely in Vulkan. The encoder is written in standard
GLSL and requires a Vulkan 1.3 supporting GPU with the BDA extension.
The encoder can use any amount of slices, but nominally, should use
32x32 slices (1024 in
---
libavcodec/ffv1enc.c | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
index 023b32e10c..36db135f49 100644
--- a/libavcodec/ffv1enc.c
+++ b/libavcodec/ffv1enc.c
@@ -710,24 +710,6 @@ av_cold int
It isn't immediately obvious what indexing this array does.
Use standard syntax instead.
---
libavcodec/ffv1.h | 2 +-
libavcodec/ffv1dec_template.c | 2 +-
libavcodec/ffv1enc_template.c | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/ffv1.h b/libavc
---
libavcodec/ffv1enc.c | 40
libavcodec/ffv1enc.h | 2 ++
2 files changed, 26 insertions(+), 16 deletions(-)
diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
index 10103f129b..023b32e10c 100644
--- a/libavcodec/ffv1enc.c
+++ b/libavcodec/ffv1enc
---
libavcodec/ffv1enc.c | 352 +++
libavcodec/ffv1enc.h | 30
2 files changed, 216 insertions(+), 166 deletions(-)
create mode 100644 libavcodec/ffv1enc.h
diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
index 7a6c718b41..10103f129b 100644
-
---
.gitignore | 2 ++
1 file changed, 2 insertions(+)
diff --git a/.gitignore b/.gitignore
index e810d11107..9cfc78b414 100644
--- a/.gitignore
+++ b/.gitignore
@@ -41,3 +41,5 @@
/src
/mapfile
/tools/python/__pycache__/
+/libavcodec/vulkan/*.c
+/libavfilter/vulkan/*.c
--
2.45.2.753.g447d99e1
---
libavutil/hwcontext_vulkan.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c
index 0b52ad5112..0c9047f4c6 100644
--- a/libavutil/hwcontext_vulkan.c
+++ b/libavutil/hwcontext_vulkan.c
@@ -4200,13 +4200,1
On Fri, Nov 8, 2024 at 5:02 PM Thilo Borgmann via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:
> > For me, interactive face-to-face discussions around these subjects, even
> > amongst only subsets of the full devgroup, are far superior compared to
> > endless email discussions. I see it as bazaa
On Fri, Nov 8, 2024 at 7:29 PM James Almer wrote:
> On 11/8/2024 10:51 PM, Pavel Koshevoy wrote:
> > I ran into segfaults in zimg when I attempted to use zscale
> > to convert a 512x538@yuv444p16le(tv) image from HLG to Bt.709
> > with this filter chain:
> >
> >
> buffer=width=512:height=538:pix_
ping
于2024年10月12日周六 17:28写道：
> From: sunyuechi
>
> k230 banana_f3
> dmvr_8_12x20_c: 619.3 ( 1.00x)624.1 ( 1.00x)
> dmvr_8_12x20_rvv_i32: 128.6 ( 4.82x)103.4 ( 6.04x)
> dmvr_8_20x12_c:
Nicolas George 于2024年11月8日周五 00:24写道：
>
> Michael Niedermayer (12024-11-03):
> > We can install gitlab on our infrastructure, if the community decides that
> > it
> > wants gitlab. We can also install anything else the community wants.
>
> If we want a more-than-monthly emergency security update
I ran into segfaults in zimg when I attempted to use zscale
to convert a 512x538@yuv444p16le(tv) image from HLG to Bt.709
with this filter chain:
buffer=width=512:height=538:pix_fmt=yuv444p16le:time_base=1/1:sar=1/1,zscale=min=2020_ncl:rin=limited:pin=2020:tin=arib-std-b67:cin=left:t=linear,format
On 11/8/2024 10:51 PM, Pavel Koshevoy wrote:
I ran into segfaults in zimg when I attempted to use zscale
to convert a 512x538@yuv444p16le(tv) image from HLG to Bt.709
with this filter chain:
buffer=width=512:height=538:pix_fmt=yuv444p16le:time_base=1/1:sar=1/1,zscale=min=2020_ncl:rin=limited:pin
Hi Pierre,
LGTM.
I have also confirmed that this patch passes all the test cases defined in
ISO/IEC 15444-4 conformance testing.
That means the PAE and MSE values with the reconstructed images are under
allowable tolerance.
Best,
Osamu
> On Nov 9, 2024, at 6:09, p...@sandflow.com wrote:
>
>
On Sat, 9 Nov 2024 at 00:37, Michael Niedermayer wrote:
>
> On Mon, Nov 04, 2024 at 06:14:07AM +, South East wrote:
> > Hi all - what do I need to do to progress this?
>
> iam a bit overloaded with work ATM, but bayer or interlacing combined with
> jpeg gives me memories of segfaults. So maybe
Hi,
On Fri, Nov 8, 2024 at 6:56 PM Michael Niedermayer
wrote:
> On Fri, Nov 08, 2024 at 01:15:41PM -0500, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Fri, Nov 8, 2024 at 11:45 AM Michael Niedermayer <
> mich...@niedermayer.cc>
> > wrote:
> >
> > > On Fri, Nov 08, 2024 at 11:23:49AM -0500, Ronald
On Wed, Nov 06, 2024 at 02:08:08PM +0100, Thilo Borgmann via ffmpeg-devel wrote:
> Hi,
>
> I also request reimbursement for this years GSoC summit.
>
> My costs included:
>
> 903,91 EUR Flight (BER to SFO)
> 248,71 EUR Hotel
> -
> 1152,62 EUR Total
> =
On Sat, Nov 02, 2024 at 07:22:46AM +0100, Kacper Michajlow wrote:
> On Sat, 2 Nov 2024 at 01:54, Michael Niedermayer
> wrote:
> >
> > Hi
> >
> > On Fri, Nov 01, 2024 at 02:20:33PM +0100, Kacper Michajlow wrote:
> > > On Sat, 10 Aug 2024 at 18:49, Kacper Michajlow wrote:
> > > >
> > > > On Sat, 1
On Mon, Nov 04, 2024 at 06:14:07AM +, South East wrote:
> Hi all - what do I need to do to progress this?
>
> I'm not sure, but it sounds like Tomas thought patch 1 might need
> someone with experience with Bayer taking a look.
iam a bit overloaded with work ATM, but bayer or interlacing comb
Hi
On Thu, Nov 07, 2024 at 06:59:36PM -0500, shenleban tongying wrote:
> fix ticket #11054 and #11078
>
> * reduce false decoding errors
> * fix wrong frame_size
>
> Co-authored-by: Paul B Mahol
> Signed-off-by: shenleban tongying
> ---
> libavcodec/speexdec.c | 10 ++
> 1 file changed,
On Fri, Nov 08, 2024 at 04:56:38PM -0300, James Almer wrote:
> On 11/8/2024 5:15 AM, Martin Storsjö wrote:
> > On Thu, 7 Nov 2024, James Almer wrote:
> >
> > > Should fix fate failures across different systems.
> > >
> > > Signed-off-by: James Almer
> > > ---
> > > This only hides the bug in the
On Fri, Nov 08, 2024 at 01:15:41PM -0500, Ronald S. Bultje wrote:
> Hi,
>
> On Fri, Nov 8, 2024 at 11:45 AM Michael Niedermayer
> wrote:
>
> > On Fri, Nov 08, 2024 at 11:23:49AM -0500, Ronald S. Bultje wrote:
> > > On Fri, Nov 8, 2024 at 11:17 AM Michael Niedermayer <
> > mich...@niedermayer.cc>
Pointers to specific entries in the array are stored in other structs, so
in the scenario where heif_item was reallocated when parsing an iloc box after
and iinf one, the pointers may end up referencing freed memory.
Fixes use-after-free with such samples.
Signed-off-by: James Almer
---
libavfo
Thank you very much
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Am 07.11.24 um 19:55 schrieb Ronald S. Bultje:
Hi,
You raise good questions that certainly deserve further exploration, in
fact I'd be deeply supportive of such discussions. However...
On Sat, Nov 2, 2024 at 7:56 PM Michael Niedermayer
wrote:
That said, I find the discussions about such key
In order to reproduce the problem you need to compile with warnings as
errors and "enum-conversion" warning enabled.
This is the what clang complains about:
../../third_party/ffmpeg/libavcodec/decode.c:1469:60: error: implicit
conversion from enumeration type 'const enum AVPacketSideDataType' to
d
From: Pierre-Anthony Lemieux
---
tests/fate/jpeg2000.mak | 122 ++-
tests/ref/fate/jpeg2000dec-ds0_hm_15_b8 | 6 ++
tests/ref/fate/jpeg2000dec-ds0_ht_02_b11 | 6 ++
tests/ref/fate/jpeg2000dec-ds0_ht_02_b12 | 6 ++
tests/ref/fate/jpeg2000dec-ds0_ht_03_b
On 11/8/2024 5:15 AM, Martin Storsjö wrote:
On Thu, 7 Nov 2024, James Almer wrote:
Should fix fate failures across different systems.
Signed-off-by: James Almer
---
This only hides the bug in the dither path for unscaled planar yuv
8bit to
hbd and vice-versa.
Someone more familiar with the
Hi,
On Fri, Nov 8, 2024 at 11:45 AM Michael Niedermayer
wrote:
> On Fri, Nov 08, 2024 at 11:23:49AM -0500, Ronald S. Bultje wrote:
> > On Fri, Nov 8, 2024 at 11:17 AM Michael Niedermayer <
> mich...@niedermayer.cc>
> > > my wish would be that the 15k could be spend on a plugin interface
> > > fo
Eugene Zemtsov:
LGTM. Is there a way to reproduce any bug that this fixes?
Will test for side effects and wait for a few days in case anyone has
comments or concerns.
Thank you
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/ma
Le perjantaina 8. marraskuuta 2024, 18.45.29 EET Michael Niedermayer a écrit :
> > Wes from Meta gave a talk about this at VDD2024.
>
> is there a recording ?
> do you have a link ?
I think that day was recorded, but it will probably take a while before the
videos are processed and released by t
Le torstaina 7. marraskuuta 2024, 22.04.04 EET Michael Niedermayer a écrit :
> On Thu, Nov 07, 2024 at 02:48:13PM +, Derek Buitenhuis wrote:
> > On 11/6/2024 11:11 PM, Michael Niedermayer wrote:
> > > 3. actually remove libpostproc from master repository (2025 future)
> > > (send to SPI
Le torstaina 7. marraskuuta 2024, 21.02.14 EET Nicolas George a écrit :
> Rémi Denis-Courmont (12024-11-07):
> > It is very hard to believe that someone such as you would be unable to
> > trivially obtain any such sources with about as much efforts that it would
> > have taken to write that mail.
>
From 613629758c059c941a43c3e1b64de59f4076f746 Mon Sep 17 00:00:00 2001
From: Jose Santiago
Date: Fri, 8 Nov 2024 10:57:07 -0600
Subject: [PATCH V7] Patch to add interlaced HEVC decoding to HEVCDEC
V7 Fixes FATE regression and cropping for reconstructed field pictures.
---
libavcodec/hevc/hevc
On Fri, Nov 08, 2024 at 11:23:49AM -0500, Ronald S. Bultje wrote:
> Hi,
>
> On Fri, Nov 8, 2024 at 11:17 AM Michael Niedermayer
> wrote:
>
> > On Fri, Nov 08, 2024 at 11:44:03AM +0100, Tomas Härdin wrote:
> > > tor 2024-11-07 klockan 00:11 +0100 skrev Michael Niedermayer:
> > > > Hi all
> > > >
Will push in 12-24hr
Thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Hi,
On Fri, Nov 8, 2024 at 11:17 AM Michael Niedermayer
wrote:
> On Fri, Nov 08, 2024 at 11:44:03AM +0100, Tomas Härdin wrote:
> > tor 2024-11-07 klockan 00:11 +0100 skrev Michael Niedermayer:
> > > Hi all
> > >
> > > Should libpostproc be split out into a seperate source repository ?
> > >
> >
On Fri, Nov 08, 2024 at 11:44:03AM +0100, Tomas Härdin wrote:
> tor 2024-11-07 klockan 00:11 +0100 skrev Michael Niedermayer:
> > Hi all
> >
> > Should libpostproc be split out into a seperate source repository ?
> >
> > Several people did over the years want libpostproc removed, and such
> > a t
Before:
$ make tools/enc_recon_frame_test
$ tools/enc_recon_frame_test ~/Movies/cif/bus_cif.y4m libx264 'tune=psnr'
Error submitting a frame for encoding
After:
All 150 encoded frames match
---
tools/enc_recon_frame_test.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/enc_recon_fram
SAN FRME objects specify width/height as well as offsets from top/left.
These offsets need to be taken into account for the diff buffers
as well. Fixes playback of all SAN videos of "Shadows of the Empire",
which have a constant top offset of 60 (640x272 video on a 640x480 window)
and show tons of
The codec47 header provides colors to use to clear the
2 difference buffers. This fixes artifacts (black hair, faces) in
Curse of Monkey Island "CURSERNG.SAN" video.
Signed-off-by: Manuel Lauss
---
libavcodec/sanm.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/lib
ons 2024-10-30 klockan 11:44 +0100 skrev Tomas Härdin:
> I also made some test files to demonstrate the differences in behavior.
> What's being addressed here is early termination of the file. One thing
> to bikeshed over is whether to return AVERROR_EOF or
> AVERROR_INVALIDDATA in that case. The a
tor 2024-11-07 klockan 00:11 +0100 skrev Michael Niedermayer:
> Hi all
>
> Should libpostproc be split out into a seperate source repository ?
>
> Several people did over the years want libpostproc removed, and such
> a task was part of the submitted and approved STF 2024 projects.
> But when i r
tor 2024-10-31 klockan 20:02 +0100 skrev Marton Balint:
>
>
> On Tue, 29 Oct 2024, Tomas Härdin wrote:
>
> > tis 2024-10-29 klockan 12:21 -0300 skrev James Almer:
> > > > From ce4b1dfb97530b242f899e5d1686f98fa83a7698 Mon Sep 17 00:00:00
> > > > 2001
> > > > From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Also passes fate-mxf
/Tomas
From 164175d6f7e2e1eab767c129d953e6e9ebbfc94d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Fri, 8 Nov 2024 11:26:24 +0100
Subject: [PATCH 2/2] lavf/mxfenc: Return AVERROR(EINVAL) in
mxf_write_jpeg2000_subdesc() is pixfmt not set
---
libavform
Passes fate-mxf
/Tomas
From 8f221258a9e5328c4a03fef6e8eab18ce20ce4f4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Fri, 8 Nov 2024 11:24:05 +0100
Subject: [PATCH 1/2] lavf/mxfenc: Make write_desc return int
This enables returning AVERRORs
---
libavformat/mxfenc.c | 61 +++
tor 2024-10-31 klockan 09:57 +0100 skrev Tomas Härdin:
> tis 2024-10-29 klockan 08:48 -0700 skrev Pierre-Anthony Lemieux:
> > LGTM
>
> Will push later today
Wups, forgot to. Pushed now though
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
Some codec47 frames come with an interpolation table:
Combining 2 adjacent pixels into a 16bit value, this value can
then be used as index into the interpolation table to get a new
pixel value. This is used for subcodec 1, which encodes a key-
frame at half width and height, and makes these frame
Outlaws' RAE.SAN file did not properly fade out in certain scenes,
but simply turned to black as soon as the first XPAL chunk with
the apply command was encountered.
Signed-off-by: Manuel Lauss
---
libavcodec/sanm.c | 69 ---
1 file changed, 41 inserti
This set of 2 patches adds support for SMUSH codec47 subcodec1 interpolation
table support, and fixes handling of the SMUSH XPAL (delta palette) chunk.
Patch 1 aims to reduce the blockyness of quarter-sized keyframes: the codec
stream provides data to construct a 256x256 table where the values of
On Thu, 7 Nov 2024, James Almer wrote:
Should fix fate failures across different systems.
Signed-off-by: James Almer
---
This only hides the bug in the dither path for unscaled planar yuv 8bit to
hbd and vice-versa.
Someone more familiar with the code should check what exactly is going on.
L
51 matches
Mail list logo
