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 parties to resign as candidates ?
>
> Dez 13 19:19:53 elenril: trolling me in
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 in this manner. Not even once, not in the most toxic threads,
never. An
Hi Niklas
On Fri, Dec 20, 2024 at 12:24:05PM +0100, Niklas Haas wrote:
> From: Niklas Haas
>
> We should at least bias towards the nearest integer, instead of always
> rounding down, when not dithering. This is a bit more correct.
>
> The FATE changes are only in the cases where sws_dither was
On Fri, Dec 20, 2024 at 01:54:28PM +0100, Niklas Haas wrote:
> From: Niklas Haas
>
> This code only checks hcScale. In practice this is not an issue because
> the function pointers should always be identical to hyScale for the same
> filter size.
>
> Add an assertion just to make sure this assum
On Fri, Dec 20, 2024 at 01:26:37PM +0800, Bin Peng wrote:
> 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 th
On 18/12/2024 17:16, Lynne wrote:
---
libavcodec/vulkan_av1.c| 1 +
libavcodec/vulkan_decode.c | 2 +-
libavcodec/vulkan_decode.h | 1 +
libavcodec/vulkan_h264.c | 1 +
libavcodec/vulkan_hevc.c | 1 +
5 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/libavcodec/vulkan_a
On 22/12/2024 17:24, Lynne via ffmpeg-devel wrote:
On 22/12/2024 05:25, Benjamin Cheng via ffmpeg-devel wrote:
Some drivers are more strict about the size of the reference lists given
(i.e. VAOn12 [1]). The next_prev list is used to handle multiple "L0"
references in AV1 encode. Restrict the siz
On Sun, 22 Dec 2024, 15:14 Michael Niedermayer,
wrote:
> I think what we need is some friendly smiles, some mutual respect,
> some virtual hugs and mutual tolerance. We can do the opposite, but it
> will make noone happier.
>
translation: everyone must agree with me
This plays out the same way
On 12/20/2024 8:06 AM, Niklas Haas wrote:
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(+
Hi
On Fri, Dec 20, 2024 at 12:06:01PM +0100, Niklas Haas wrote:
> 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 ++-
Hi
On Sat, Dec 21, 2024 at 12:25:02PM -0500, Ronald S. Bultje wrote:
> Hi Janne,
>
> On Thu, Dec 19, 2024 at 4:12 PM Janne Grunau
> wrote:
>
> > The arm/aarch64 horizontal filter reads one additional pixel beyond what
> > the filter uses. This can become an issue if the application does not
> >
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:24:46AM +0100, Anton Khirnov wrote:
> >> Quoting Michael Niedermayer (2024-12-19 20:52:39)
On Thu, Dec 19, 2024 at 03:08:00PM +0100, Niklas Haas wrote:
> From: Niklas Haas
>
> As fixed in the previous commit, this enables semipacked range and
> bit depth conversions. Previously these would go through the general
> purpose path.
>
> Signed-off-by: Niklas Haas
> Sponsored-by: Sovereign
On Thu, Dec 19, 2024 at 03:07:59PM +0100, Niklas Haas wrote:
> From: Niklas Haas
>
> This fixes multiple bugs with semiplanar formats like NV12. Not only do these
> false positive the grayscale format checks (because dst[2] in NULL), but they
> also copied an incorrect number of pixels.
>
> Fixe
When the current subpicture has sps_subpic_treated_as_pic_flag equal to
1, motion vectors are cropped such that they cannot point to other
subpictures. This was accounted for in the prediction logic, but not
in pred_get_y, which is used by the scheduling logic to determine which
parts of the refer
On Sat, Dec 21, 2024 at 9:42 PM Rémi Denis-Courmont wrote:
> Hi
>
> The RISC-V bits look ok. No opinion on x86.
>
Thank you for the review.
Pushed.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg
On Sun, Dec 22, 2024 at 3:03 AM Ronald S. Bultje wrote:
> Hi,
>
> On Sat, Dec 21, 2024 at 5:02 AM Nuo Mi wrote:
>
>> rename from libavcodec/x86/hevc_add_res.asm
>> rename to libavcodec/x86/hevc/add_res.asm
>>
>
> Good idea - LGTM. I should probably do this for VP9 also...
>
Kudos to Anton and Zh
On 12/22/24 3:08 AM, Peter Ross wrote:
Fixes CID 1636854
---
libavformat/iff.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavformat/iff.c b/libavformat/iff.c
index ab0488dd31..de58b93421 100644
--- a/libavformat/iff.c
+++ b/libavformat/iff.c
@@ -1007,8 +1007,6 @@ static int iff_rea
On 12/21/24 4:50 AM, Niklas Haas wrote:
On Mon, 16 Dec 2024 14:56:07 +0100 Niklas Haas wrote:
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 p
On 22/12/2024 05:25, Benjamin Cheng via ffmpeg-devel wrote:
Some drivers are more strict about the size of the reference lists given
(i.e. VAOn12 [1]). The next_prev list is used to handle multiple "L0"
references in AV1 encode. Restrict the size of next_prev based on the
value of ref_l0 when the
Fixes CID 1636854
---
libavformat/iff.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavformat/iff.c b/libavformat/iff.c
index ab0488dd31..de58b93421 100644
--- a/libavformat/iff.c
+++ b/libavformat/iff.c
@@ -1007,8 +1007,6 @@ static int iff_read_packet(AVFormatContext *s,
av_as
21 matches
Mail list logo
