It was not introduced until glibc 2.18.
---
This should fix the ppc32 FATE node.
---
libavutil/ppc/cpu.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavutil/ppc/cpu.c b/libavutil/ppc/cpu.c
index 96b491c716..bc8bb5f47c 100644
--- a/libavutil/ppc/cpu.c
+++
On date Sunday 2023-10-15 03:09:14 +0200, Timo Rothenpieler wrote:
> On 14.10.2023 19:24, Stefano Sabatini wrote:
> > Fix rendering of int values within a side data element, which was
> > broken since commit d2d3a83ad93, where the side data element was
> > correctly marked as a variable fields
On Tue, Sep 5, 2023 at 9:16 PM Nuo Mi wrote:
>
>>
>> #14 0x55aa01f2 in avformat_find_stream_info (ic=0x58698900,
>> options=0x5869a3c0) at libavformat/demux.c:2771
>> #15 0x55697446 in ifile_open (o=0x7fffdaa0,
>> filename=0x7fffe56b
On 14.10.2023 19:24, Stefano Sabatini wrote:
Fix rendering of int values within a side data element, which was
broken since commit d2d3a83ad93, where the side data element was
correctly marked as a variable fields element. Logic to render a
string variable was implemented already, but it was not
In f7ac3512f5b5cb8eb149f37300b43461d8e93af3 the size of the dynamically
allocated buffer was shrunk, but it was made too small for very small
alphabet sizes. This patch restores the size to prevent an OOB read.
Reported-by: Cole Dilorenzo
Signed-off-by: Leo Izen
---
libavcodec/jpegxl_parser.c
Fixes: Assertion failure
Fixes:
62866/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5282997370486784
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/mov.c | 5 ++---
1 file changed, 2
Michael Niedermayer:
> On Sat, Oct 07, 2023 at 02:40:26AM +0200, Andreas Rheinhardt wrote:
>> They are generally set in ff_mpv_init_context_frame()
>> (mostly called by ff_mpv_common_init()); setting them
>> somewhere else should be avoided.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>>
On date Saturday 2023-10-14 19:24:28 +0200, Stefano Sabatini wrote:
> Fix rendering of int values within a side data element, which was
> broken since commit d2d3a83ad93, where the side data element was
> correctly marked as a variable fields element. Logic to render a
> string variable was
On Sat, Oct 14, 2023 at 1:00 PM Michael Niedermayer
wrote:
>
> PS: whats the real issue with sws ?
> it evolved out of a piece yuv->rgb converter from a video player.
> It evolved from that and stuff was added into it.
> This is a similar situation to why ffmpeg.c needed cleanup
>
I'll give you
On date Friday 2023-10-13 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
On Sat, 14 Oct 2023, 18:00 Michael Niedermayer,
wrote:
> On Sat, Oct 14, 2023 at 03:19:49PM +0100, Kieran Kunhya wrote:
> > On Sat, 14 Oct 2023 at 00:17, Cosmin Stejerean via ffmpeg-devel <
> > ffmpeg-devel@ffmpeg.org> wrote:
> >
> > >
> > >
> > > > On Oct 13, 2023, at 4:00 PM, Vittorio Giovara
Quoting Kieran Kunhya (2023-10-14 16:19:49)
> On Sat, 14 Oct 2023 at 00:17, Cosmin Stejerean via ffmpeg-devel <
> ffmpeg-devel@ffmpeg.org> wrote:
>
> >
> >
> > > On Oct 13, 2023, at 4:00 PM, Vittorio Giovara <
> > vittorio.giov...@gmail.com> wrote:
> > >
> > > TBF this is in part why i was
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
Fix rendering of int values within a side data element, which was
broken since commit d2d3a83ad93, where the side data element was
correctly marked as a variable fields element. Logic to render a
string variable was implemented already, but it was not implemented
for the int fields path, which was
On Sat, Oct 14, 2023 at 6:02 AM xyz1001 wrote:
>
> 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
On Sat, Oct 14, 2023 at 04:45:39PM +0800, Logan.Lyu wrote:
[...]
> diff --git a/libavcodec/aarch64/hevcdsp_epel_neon.S
> b/libavcodec/aarch64/hevcdsp_epel_neon.S
> index b4ca1e4c20..e541db5430 100644
> --- a/libavcodec/aarch64/hevcdsp_epel_neon.S
> +++ b/libavcodec/aarch64/hevcdsp_epel_neon.S
> @@
On Sat, Oct 14, 2023 at 03:19:49PM +0100, Kieran Kunhya wrote:
> On Sat, 14 Oct 2023 at 00:17, Cosmin Stejerean via ffmpeg-devel <
> ffmpeg-devel@ffmpeg.org> wrote:
>
> >
> >
> > > On Oct 13, 2023, at 4:00 PM, Vittorio Giovara <
> > vittorio.giov...@gmail.com> wrote:
> > >
> > > TBF this is in
Fixes build failures when the Vulkan headers are too old and libglslang
or libshaderc are enabled.
Patch attached.
>From b47d5d3759f9c3de15846ae0fa184f1fa93f2c9a Mon Sep 17 00:00:00 2001
From: Lynne
Date: Sat, 14 Oct 2023 18:36:46 +0200
Subject: [PATCH] configure: disable libglslang/libshaderc
On Fri Oct 13, 2023 at 11:59 PM EDT, xyz1001 wrote:
> 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
prof_h264_high uses either DXVA2_ModeH264_E or
Hi
On Fri, Oct 13, 2023 at 11:16:50PM +, Cosmin Stejerean via ffmpeg-devel
wrote:
>
>
> > 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
Oct 14, 2023, 17:16 by vittorio.giov...@gmail.com:
> On Sat, Oct 14, 2023 at 9:11 AM Lynne wrote:
>
>> Oct 14, 2023, 00:22 by vittorio.giov...@gmail.com:
>>
>> > On Fri, Oct 13, 2023 at 5:14 PM Lynne wrote:
>> >
>> >> Oct 13, 2023, 20:33 by vittorio.giov...@gmail.com:
>> >>
>> >> > On Fri, Oct
On Sat, Oct 14, 2023 at 9:11 AM Lynne wrote:
> Oct 14, 2023, 00:22 by vittorio.giov...@gmail.com:
>
> > 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:
> >> >
> >> >>
On Sat, 14 Oct 2023 at 00:17, Cosmin Stejerean via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:
>
>
> > On Oct 13, 2023, at 4:00 PM, Vittorio Giovara <
> vittorio.giov...@gmail.com> wrote:
> >
> > TBF this is in part why i was suggesting a new library - I feel like sws
> is
> > affected by bad
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
> > capabilities. But since we're
Oct 14, 2023, 00:22 by vittorio.giov...@gmail.com:
> 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
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
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
checkasm bench:
put_hevc_qpel_hv4_8_c: 422.1
put_hevc_qpel_hv4_8_i8mm: 101.6
put_hevc_qpel_hv6_8_c: 756.4
put_hevc_qpel_hv6_8_i8mm: 225.9
put_hevc_qpel_hv8_8_c: 1189.9
put_hevc_qpel_hv8_8_i8mm: 296.6
put_hevc_qpel_hv12_8_c: 2407.4
put_hevc_qpel_hv12_8_i8mm: 552.4
put_hevc_qpel_hv16_8_c: 4021.4
checkasm bench:
put_hevc_qpel_v4_8_c: 138.1
put_hevc_qpel_v4_8_neon: 41.1
put_hevc_qpel_v6_8_c: 276.6
put_hevc_qpel_v6_8_neon: 60.9
put_hevc_qpel_v8_8_c: 478.9
put_hevc_qpel_v8_8_neon: 72.9
put_hevc_qpel_v12_8_c: 1072.6
put_hevc_qpel_v12_8_neon: 203.9
put_hevc_qpel_v16_8_c: 1852.1
checkasm bench:
put_hevc_epel_hv4_8_c: 213.7
put_hevc_epel_hv4_8_i8mm: 59.4
put_hevc_epel_hv6_8_c: 350.9
put_hevc_epel_hv6_8_i8mm: 130.2
put_hevc_epel_hv8_8_c: 548.7
put_hevc_epel_hv8_8_i8mm: 136.9
put_hevc_epel_hv12_8_c: 1126.7
put_hevc_epel_hv12_8_i8mm: 302.2
put_hevc_epel_hv16_8_c: 1925.2
checkasm bench:
put_hevc_epel_v4_8_c: 79.9
put_hevc_epel_v4_8_neon: 25.7
put_hevc_epel_v6_8_c: 151.4
put_hevc_epel_v6_8_neon: 46.4
put_hevc_epel_v8_8_c: 250.9
put_hevc_epel_v8_8_neon: 41.7
put_hevc_epel_v12_8_c: 542.7
put_hevc_epel_v12_8_neon: 108.7
put_hevc_epel_v16_8_c: 939.4
checkasm bench:
put_hevc_qpel_hv4_8_c: 422.1
put_hevc_qpel_hv4_8_i8mm: 101.6
put_hevc_qpel_hv6_8_c: 756.4
put_hevc_qpel_hv6_8_i8mm: 225.9
put_hevc_qpel_hv8_8_c: 1189.9
put_hevc_qpel_hv8_8_i8mm: 296.6
put_hevc_qpel_hv12_8_c: 2407.4
put_hevc_qpel_hv12_8_i8mm: 552.4
put_hevc_qpel_hv16_8_c: 4021.4
checkasm bench:
put_hevc_qpel_v4_8_c: 138.1
put_hevc_qpel_v4_8_neon: 41.1
put_hevc_qpel_v6_8_c: 276.6
put_hevc_qpel_v6_8_neon: 60.9
put_hevc_qpel_v8_8_c: 478.9
put_hevc_qpel_v8_8_neon: 72.9
put_hevc_qpel_v12_8_c: 1072.6
put_hevc_qpel_v12_8_neon: 203.9
put_hevc_qpel_v16_8_c: 1852.1
checkasm bench:
put_hevc_epel_v4_8_c: 79.9
put_hevc_epel_v4_8_neon: 25.7
put_hevc_epel_v6_8_c: 151.4
put_hevc_epel_v6_8_neon: 46.4
put_hevc_epel_v8_8_c: 250.9
put_hevc_epel_v8_8_neon: 41.7
put_hevc_epel_v12_8_c: 542.7
put_hevc_epel_v12_8_neon: 108.7
put_hevc_epel_v16_8_c: 939.4
checkasm bench:
put_hevc_epel_hv4_8_c: 213.7
put_hevc_epel_hv4_8_i8mm: 59.4
put_hevc_epel_hv6_8_c: 350.9
put_hevc_epel_hv6_8_i8mm: 130.2
put_hevc_epel_hv8_8_c: 548.7
put_hevc_epel_hv8_8_i8mm: 136.9
put_hevc_epel_hv12_8_c: 1126.7
put_hevc_epel_hv12_8_i8mm: 302.2
put_hevc_epel_hv16_8_c: 1925.2
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
36 matches
Mail list logo
