On Fri, Aug 16, 2024 at 12:58 PM Martin Storsjö wrote:
> On Thu, 15 Aug 2024, Ramiro Polla wrote:
> > Thank you for the review. New patch attached.
>
> Thanks - this looks very straightforward and nice now! Just one minor nit
> below:
>
> > +add x4, x4, x5, sxtw// s
On Wed, Aug 21, 2024 at 9:44 PM Martin Storsjö wrote:
> On Wed, 21 Aug 2024, Ramiro Polla wrote:
> >> BTW, this instruction is kinda exotic and the docs aren't super clear, so
> >> it'd be good to test manually that it really does what we want, for
> >> negative numbers and numbers close to the en
On Wed, Aug 21, 2024 at 4:56 PM Ramiro Polla wrote:
> This commit also restricts w to 4, 8, or 16.
>
> Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz:
> beforeafter
> draw_edges_8_1724_4_c: 46796.5 7141.7 ( 6.55x)
> draw_edges_8_1724_8_c:
On Thu, 22 Aug 2024, Ramiro Polla wrote:
---
libavutil/aarch64/intreadwrite.h | 42
libavutil/intreadwrite.h | 4 ++-
2 files changed, 45 insertions(+), 1 deletion(-)
create mode 100644 libavutil/aarch64/intreadwrite.h
diff --git a/libavutil/aarch64/intre
Quoting Michael Niedermayer (2024-08-20 22:57:37)
> Hi
>
> On Sun, Aug 18, 2024 at 01:26:53PM +0200, Anton Khirnov wrote:
> > ---
> > libavutil/opt.h | 78 +++--
> > 1 file changed, 75 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavutil/opt.h
On 2024-08-21 09:56, Poorva wrote:
Hello FFmpeg Team,
I am submitting the completed work from my Google Summer of Code project,
which focuses on updating the SiTi filter for ITU-T P.910 07/22 compliance
and adding HDR support.
Attached is the patch for your review. I appreciate your feedback a
On Wed, Aug 21, 2024 at 1:26 PM J. Dekker wrote:
>
> Port dav1d's checkasm output format to FFmpeg's checkasm, includes
> relative speedups and aligns results.
>
> Signed-off-by: J. Dekker
> ---
> tests/checkasm/checkasm.c | 53 +++
> 1 file changed, 48 insert
On Thu, Aug 22, 2024 at 2:24 AM WATANABE Osamu
wrote:
>
> Hi Pierre, Tomas,
>
> For lossy codestreams, I found a potential problem on the current 9x7 integer
> IDWT (which will be activated with the +bitexact flag.)
Probably related?
https://trac.ffmpeg.org/ticket/10123
>
> I have confirmed th
The input time_base was a bad guess.
Currently, fate-time_base test data assumed that overriding the input
time_base would affect the frame_rate, but this behaviour is not
documented, so just fix the fate data now that this is fixed.
Fix regression since 10185e2d4c1e9839bc58a1d6a63c861677b13fd0:
For fate-copy-trac4914, this is a revert of
10185e2d4c1e9839bc58a1d6a63c861677b13fd0.
Signed-off-by: Nicolas Gaullier
---
tests/fate/ffmpeg.mak | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak
index 9e0c68da20..4f15356e0e 10064
10 matches
Mail list logo