Sure, changed in PATCH v4.
发件人: ffmpeg-devel 代表 Michael Niedermayer
发送时间: 2024年12月23日 5:41
收件人: FFmpeg development discussions and patches
主题: Re: [FFmpeg-devel] [PATCH v3] avcodec/h264_mb: Fix tmp buffer overlap in
mc_part_weighted
On Fri, Dec 20, 2024 at 0
libjxl supports animated encoding, so we add a wrapper to the
library using the receive_packet callback method.
This code was based largely on a patch sent by Zsolt Vadász,
although it was updated to use more recent coding practices
and many of the leaks and issues were fixed.
Reviewed-by: Marth6
A new codec ID has been added to avcodec for animated JPEG XL, so
we should use that in the animated JPEG XL demuxer.
Reviewed-by: Marth64
Signed-off-by: Leo Izen
---
libavformat/jpegxl_anim_dec.c| 2 +-
tests/ref/fate/jxl-anim-demux-icos4d | 2 +-
tests/ref/fate/jxl-anim-demux-newton |
Changes since v3:
- Added APIChanges and Changelog entry
- bumped minor version (new codec id)
- Changed commit message to libjxl:
- Added Reviewed-by to commits
Changes since v2:
- Replaced "goto end;" with "return ret;" when unnecessary
- removed *data from JXLEncodeContext and added it as an ar
When decoding a bitstream with weighted-bipred enabled,
the results on ARM and x86 platforms may differ.
The reason for the inconsistency is that the value of
STRIDE_ALIGN differs between platforms. And STRIDE_ALIGN
is set to the buffer stride of temporary buffers for U
and V components in mc_part
Quoting Michael Niedermayer (2024-12-23 21:37:32)
> If i stand by and do nothing, THAT would be abusing of my power
Behold, the favorite excuse of every tin-pot dictator ever.
So boiling down your verbal vomit, I get
Yes, your democracy IS just pretend and I - the person who
* tries ver
Will push soon
___
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".
code LGTM.
think it needs doc/APIchanges update for new AV_CODEC_ID_JPEGXL_ANIM
___
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.
On Thu, Dec 12, 2024 at 04:39:38AM +0100, Michael Niedermayer wrote:
> Fixes: Timeout
> Fixes:
> 382804863/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SGA_fuzzer-5652795669151744
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Sig
On Sun, Dec 08, 2024 at 04:56:58AM +0100, Michael Niedermayer wrote:
> Fixes:
> 379768251/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_INDEO5_fuzzer-5981329084186624
> Fixes: Timeout
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>
Hi Peter
On Sun, Dec 08, 2024 at 06:29:58PM +1100, Peter Ross wrote:
> On Sun, Dec 08, 2024 at 04:57:00AM +0100, Michael Niedermayer wrote:
> > Fixes:
> > 378634700/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RV60_fuzzer-5008344043028480
> > Fixes: assertion failure
> >
> > Found-by: conti
Hi Peter
On Sun, Dec 08, 2024 at 06:35:21PM +1100, Peter Ross wrote:
> On Sun, Dec 08, 2024 at 04:57:01AM +0100, Michael Niedermayer wrote:
> > Fixes: NULL ptr use
> > Fixes:
> > 378634700/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RV60_fuzzer-5008344043028480
> >
> > Found-by: continuous
Hi Vittorio
On Sat, Dec 21, 2024 at 09:46:13PM -0500, Vittorio Giovara wrote:
> On Sat, Dec 21, 2024 at 7:19 PM Michael Niedermayer
> wrote:
>
> > Found-by: Youngjae Choi
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavutil/timecode.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 d
On Mon, 16 Dec 2024, Marton Balint wrote:
On Mon, 16 Dec 2024, Anton Khirnov wrote:
Quoting Marton Balint (2024-12-16 09:47:39)
On Mon, 16 Dec 2024, Anton Khirnov wrote:
Quoting Marton Balint (2024-12-15 01:02:42)
Signed-off-by: Marton Balint
---
doc/APIchanges | 3 +++
---
libavformat/flvdec.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index 39e872f473..018249d1fe 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -1721,20 +1721,22 @@ retry_duration:
I am not seeing the previous commit to this file in the mailing list
so I'm not sure what to respond to. The previous commit broke the
build on Windows as it results in an empty array:
commit 18af3a1db2db07cd24d611cc9cdc86fcdec4b505
Author: Lynne
Date: Wed Dec 18 13:14:27 2024 +0900
hwcont
On Mon, Dec 23, 2024 at 3:37 PM Michael Niedermayer
wrote:
> Hi
>
> On Mon, Dec 23, 2024 at 07:44:49AM +0100, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2024-12-21 04:57:26)
> > >
> >
> > This is frankly a load of bullshit, and I find it insulting that you
> > expect people to swallow
Hi
On Mon, Dec 23, 2024 at 07:44:49AM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-12-21 04:57:26)
> >
>
> This is frankly a load of bullshit, and I find it insulting that you
> expect people to swallow it.
>
> At least in the past five years, ML moderators have NEVER used the
Hi Anton
On Mon, Dec 23, 2024 at 08:08:14AM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-12-22 16:13:50)
> > You mean, the poll superviser delaying the vote until a specific person he
> > asked, applies as candidate, would cause said poll superviser to resign
> > and involved pa
From: sunyuechi
---
libavcodec/riscv/h26x/asm.S| 36 +-
libavcodec/riscv/vvc/sad_rvv.S | 2 +-
2 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/libavcodec/riscv/h26x/asm.S b/libavcodec/riscv/h26x/asm.S
index d99690d9a0..0c9ebbdaad 100644
--- a
Hi, It looks like you submitted your review comments not long after the
patch was merged.
Previously, regarding the VVC avg patch, you mentioned "LGTM for the RISC-V
side. No clue about the VVC side",
so I contacted Nuomi in the hope that he could help merge the patch that
had been pending for a w
> That makes zero sense. The logical multiplier does not accommodate larger
> vector lengths than 256 bits as things stand, and in the extreme, you can
> always have vector lengths to large that even the smallest valid
multiplier is
> "too" large.
Yes, I didn't consider vlen > 256. What do you thi
On 12/15/24 12:04 PM, Leo Izen wrote:
Changes since v2:
- Replaced "goto end;" with "return ret;" when unnecessary
- removed *data from JXLEncodeContext and added it as an argument
to libjxl_preprocess_frame as that's the only place it was used
- Added some comments
Changes since v1:
- Fixed FAT
On 12/19/24 3:59 AM, Wang Bin wrote:
based on Hendrik Leppkes's fork
___
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 wit
Le 23 décembre 2024 14:23:54 GMT+01:00, "Ronald S. Bultje"
a écrit :
>Hi,
>
>On Mon, Dec 23, 2024 at 8:22 AM Nicolas George wrote:
>
>> Could you all stop ganging against Michael? It is reminiscent of the
>> bullying he was subjected to in the months leading to the fork that
>> convinced him t
> On Dec 23, 2024, at 14:44, Anton Khirnov wrote:
>
> Quoting Michael Niedermayer (2024-12-21 04:57:26)
>>
>
> This is frankly a load of bullshit, and I find it insulting that you
> expect people to swallow it.
>
> At least in the past five years, ML moderators have NEVER used their
> powers
Hi,
On Mon, Dec 23, 2024 at 8:22 AM Nicolas George wrote:
> Could you all stop ganging against Michael? It is reminiscent of the
> bullying he was subjected to in the months leading to the fork that
> convinced him to “resign” as project leader even though he was doing an
> excellent job of if.
Could you all stop ganging against Michael? It is reminiscent of the
bullying he was subjected to in the months leading to the fork that
convinced him to “resign” as project leader even though he was doing an
excellent job of if.
Thank you very much.
--
Nicolas George
_
On 12/23/2024 10:13 AM, Niklas Haas wrote:
On Mon, 23 Dec 2024 10:02:48 -0300 James Almer wrote:
On 12/23/2024 9:48 AM, Niklas Haas wrote:
From: Niklas Haas
As discussed in the previous commit, we often need a convenient way of
stripping all side data related to a certain aspect of the frame
On Mon, 23 Dec 2024 10:02:48 -0300 James Almer wrote:
> On 12/23/2024 9:48 AM, Niklas Haas wrote:
> > From: Niklas Haas
> >
> > As discussed in the previous commit, we often need a convenient way of
> > stripping all side data related to a certain aspect of the frame. This
> > helper
> > accompl
On 12/23/2024 9:48 AM, Niklas Haas wrote:
From: Niklas Haas
As discussed in the previous commit, we often need a convenient way of
stripping all side data related to a certain aspect of the frame. This helper
accomplishes just that.
I considered also adding a way to match only side data matchi
From: Niklas Haas
---
libavfilter/vf_scale.c| 18 --
libavfilter/vf_scale_cuda.c | 5 +
libavfilter/vf_scale_npp.c| 5 +
libavfilter/vf_scale_vaapi.c | 6 ++
libavfilter/vf_scale_vt.c | 4
libavfilter/vf_scale_vulkan.c | 5 +
6 files c
From: Niklas Haas
---
libavfilter/vf_colorspace.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
index 62055aa1bf..84c6767302 100644
--- a/libavfilter/vf_colorspace.c
+++ b/libavfilter/vf_colorspace.c
@@ -25,6 +25,7 @@
#inc
From: Niklas Haas
Required for both size changes 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 e456053b4e..569d0
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 | 3 +++
libavfilter/vf_lut2.c | 2 ++
libavfilter/vf_lut3d.c | 3 +++
3 files changed, 8 insertions(+)
diff --gi
From: Niklas Haas
Switches to av_frame_side_data_remove_by_props(), 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
As discussed in the previous commit, we often need a convenient way of
stripping all side data related to a certain aspect of the frame. This helper
accomplishes just that.
I considered also adding a way to match only side data matching *all*
properties, but I think this is suf
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. For
From: Niklas Haas
This entry was seemingly missing.
---
libavutil/frame.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavutil/frame.c b/libavutil/frame.c
index 5fb47dbaa6..3020845ef8 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -58,6 +58,7 @@ static const AVSideDataDescrip
Le dimanche 22 décembre 2024, 17:13:50 EET Michael Niedermayer a écrit :
> Hi Rémi
>
> On Sat, Dec 21, 2024 at 03:47:50PM +0200, Rémi Denis-Courmont wrote:
> > Hi,
> >
> > Le 21 décembre 2024 05:57:26 GMT+02:00, Michael Niedermayer
a écrit :
> > >Hi Anton
> > >
> > >On Fri, Dec 20, 2024 at 06:2
From: Niklas Haas
This has the downside of requiring these tables to be recomputed on every
init, but saves ~270 kB of static data.
Signed-off-by: Niklas Haas
---
libswscale/utils.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/libswscale/utils
From: Niklas Haas
The current logic uses 12-bit linear light math, which is woefully insufficient
and leads to nasty postarization artifacts. This patch simply switches the
internal logic to 16-bit precision.
This raises the memory requirement of these tables from 32 kB to 272 kB.
All relevant
From: Niklas Haas
Needed for lazy allocation of XYZ tables.
Signed-off-by: Niklas Haas
---
libswscale/utils.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 5235cbed8d..82bb93e184 100644
--- a/libswscale/
From: Niklas Haas
Fixes: ticket #9520
Signed-off-by: Niklas Haas
Sponsored-by: Sovereign Tech Fund
---
libswscale/swscale.c | 8
libswscale/swscale_unscaled.c | 81 ++-
2 files changed, 87 insertions(+), 2 deletions(-)
diff --git a/libswscale/swsc
Le mardi 17 décembre 2024, 11:50:26 EET flow gg a écrit :
> > Don't clobber v8 here.
> > Use vsub.vv here to avoid the sequential dependency.
>
> Thanks, I will update later
>
> > Are you sure this does not require tail-undisturbed mode? I think you're
> > setting tail-agnostic mode up.
>
> I’m
Hello,
I remember agreeing to rename files. I do not remember agreeing to merging this
new functionality. To the contrary, this patch had objections from me, and not
just about performance. The functional issues are not even addressed here.
Why the heck was this broken SAD code merged when the
> On Dec 19, 2024, at 20:45, Zhao Zhili wrote:
>
>
>> On Dec 19, 2024, at 08:28, James Almer wrote:
>>
>> On 12/18/2024 6:59 PM, Scott Theisen wrote:
>>> Originally from:
>>> https://github.com/MythTV/mythtv/commit/669955c6cb29196b4b5120451b5b998d67a65749
>>> ---
>>> v3:
>>> remove unnecessa
47 matches
Mail list logo
