On Mon, Aug 19, 2024 at 9:31 AM Araz Iusubov wrote:
>
> From: Evgeny Pavlov
>
> This commit increase precision of Sleep() function on Windows.
> This fix reduces the sleep time on Windows to improve AMF encoding
> performance on low resolution input videos.
>
> Fix for issue #10622
>
> We evaluat
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 and
suggestions.
From e33fa1928164d986b
On Tue, Aug 20, 2024 at 11:52:20PM +0200, Lynne via ffmpeg-devel wrote:
> On 20/08/2024 22:33, Michael Niedermayer wrote:
> > On Tue, Aug 20, 2024 at 02:36:53PM +0200, Lynne via ffmpeg-devel wrote:
> > > On 20/08/2024 14:13, b...@gget.it wrote:
> > > > > > More generally, which is the recommanded w
Le 20 août 2024 15:36:53 GMT+03:00, Lynne via ffmpeg-devel
a écrit :
>> Thank you Zhao for your answer.
>>
>> Is there a feature already available in ffmpeg to use one of your 2
>> solutions?
>> Or is someone already working on this topic? (if so, can I join this feature
>> development?)
>>
Le sam. 17 août 2024 à 21:15, Marton Balint a écrit :
>
>
> On Wed, 14 Aug 2024, Marc-Antoine Arnaud wrote:
>
> > ---
> > libavformat/mxfdec.c | 14 +-
> > 1 file changed, 13 insertions(+), 1 deletion(-)
>
> Why would you want to tune this?
>
Hi Marton
In some MXF files, index tables
When collecting performance information from checkasm it is common
to parse the output for use in graphs to compare vs different
architectures.
Signed-off-by: J. Dekker
---
tests/checkasm/checkasm.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/tests
Signed-off-by: J. Dekker
---
tests/checkasm/checkasm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
index d9b5c94faa..c5c1eeb07a 100644
--- a/tests/checkasm/checkasm.c
+++ b/tests/checkasm/checkasm.c
@@ -775,7 +775
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 insertions(+), 5 deletions(-)
diff --git a/tests/checkasm/checkasm.c b
Added:
--test=Filter tests by glob style pattern.
--bench[=] Run benchmark and optionally filter functions
by glob style pattern.
Example:
$ ./tests/checkasm/checkasm --bench=yuva*
[...]
yuva420p_bgr24_8_c: 34.5 ( 1.00x)
yuva420p_
> On Sat, Aug 17, 2024 at 5:38 AM Marth64 wrote:
> >
> > I would like to get DVD seeking in and some recent bugfixes (initial
> > patchset was sent, working on revision). I'm chasing one last
> > lingering issue with chapter-based extraction.
> > Hopefully, I can make a breakthrough or get help
The tests have now been run on an A55 instead of an A53 (the RK3588 has
both in-order A55 and out-of-order A76, so it makes testing easier).
Changes:
- draw_edges_mmx: support negative strides
- draw_edges_mmx: removed redundant variable assignment (last_line)
- checkasm: merged commits adding mpe
---
libavcodec/x86/mpegvideoencdsp_init.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/x86/mpegvideoencdsp_init.c
b/libavcodec/x86/mpegvideoencdsp_init.c
index ec174b15aa..c901e4dbaa 100644
--- a/libavcodec/x86/mpegvideoencdsp_init.c
+++ b/libavcodec/x86/mp
---
tests/checkasm/Makefile | 1 +
tests/checkasm/checkasm.c| 3 +
tests/checkasm/checkasm.h| 1 +
tests/checkasm/mpegvideoencdsp.c | 147 +++
tests/fate/checkasm.mak | 1 +
5 files changed, 153 insertions(+)
create mode 100644
A55 A76
pix_norm1_c: 484.3 235.2
pix_norm1_neon: 193.8 ( 2.50x) 44.7 ( 5.26x)
pix_sum_c: 302.8 243.7
pix_sum_neon: 81.6 ( 3.71x) 26.0 ( 9.37x)
---
libavcodec/aarch64/Makefile | 2 +
libavcodec/aarch64/mpegvideoenc
A55 A76
pix_norm1_c:484.3 235.2
pix_norm1_neon: 193.8 ( 2.50x) 44.7 ( 5.26x)
pix_norm1_dotprod: 91.8 ( 5.28x) 21.2 (11.09x)
---
libavcodec/aarch64/mpegvideoencdsp_init.c | 10
libavcodec/aarch64/mpegvideoencdsp_neon.S | 28
Not only w == 8 and w == 16 are supported, but also w == 4.
---
libavcodec/x86/mpegvideoencdsp_init.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavcodec/x86/mpegvideoencdsp_init.c
b/libavcodec/x86/mpegvideoencdsp_init.c
index c901e4dbaa..f199b23299 100644
--- a/libav
The mmx memory copy code is not nearly as efficient as memcpy(), which
would make draw_edges_mmx much slower than draw_edges_8_c.
Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz:
beforeafter
draw_edges_8_1724_4_mmx: 8700.5 8751.8 ( 0.99x)
draw_edg
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: 43584.5 7216.5 ( 6.04x)
draw_edges_8_1724_16_c:
From: Lynne
This commit cleans up and refactors the mess of private state upon
private state that used to be.
Now, FFHWBaseEncodePicture is fully initialized upon call-time,
and, most importantly, this lets APIs which require initialization
data for frames (VkImageViews) to initialize this for b
Lynne:
>On 19/08/2024 17:07, Tong Wu wrote:
>> Lynne:
>>> Subject: [PATCH] hw_base_encode: refactor picture allocation/freeing
>>>
>>> This commit cleans up and refactors the mess of private state upon
>>> private state that used to be.
>>>
>>> Now, FFHWBaseEncodePicture is fully initialized upon c
On Wed, Jun 19, 2024 at 1:42 AM Tomas Härdin wrote:
>
> tis 2024-06-18 klockan 07:59 -0700 skrev Pierre-Anthony Lemieux:
> > On Tue, Jun 18, 2024 at 7:25 AM Tomas Härdin wrote:
> > >
> > > lör 2024-06-15 klockan 21:47 -0700 skrev p...@sandflow.com:
> > > > From: Pierre-Anthony Lemieux
> > > >
>
mån 2024-08-19 klockan 23:03 -0700 skrev p...@sandflow.com:
> From: Pierre-Anthony Lemieux
>
> ---
> tests/fate/jpeg2000.mak | 129
I presume you've tested that the frames match the references as
required. If so then it looks OK to me
/Tomas
ons 2024-07-17 klockan 13:27 +0200 skrev Michael Niedermayer:
> Fixes: signed integer overflow: 9223372036854775807 - -1 cannot be
> represented in type 'long'
> Fixes: 68578/clusterfuzz-testcase-minimized-ffmpeg_dem_MXF_fuzzer-
> 6032171648221184
>
> Found-by: continuous fuzzing process
> https:/
On Wed, Aug 21, 2024 at 8:54 AM Tomas Härdin wrote:
>
> mån 2024-08-19 klockan 23:03 -0700 skrev p...@sandflow.com:
> > From: Pierre-Anthony Lemieux
> >
> > ---
> > tests/fate/jpeg2000.mak | 129
>
> I presume you've tested that the frames match the references as
> required. If s
ons 2024-08-14 klockan 09:59 +0200 skrev Marc-Antoine Arnaud:
> ---
> libavformat/mxfdec.c | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
Good idea. Could use some documentation.
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel
ons 2024-08-14 klockan 09:59 +0200 skrev Marc-Antoine Arnaud:
> sponsored by nxtedition
> ---
> libavformat/mxfdec.c | 56
> 1 file changed, 56 insertions(+)
>
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> index df958819300..83f9e5fc9e0
On Wed, 21 Aug 2024, Ramiro Polla wrote:
A55 A76
pix_norm1_c: 484.3 235.2
pix_norm1_neon: 193.8 ( 2.50x) 44.7 ( 5.26x)
pix_sum_c: 302.8 243.7
pix_sum_neon: 81.6 ( 3.71x) 26.0 ( 9.37x)
---
libavcodec/aarch64/Makefile
On Mon, Aug 19, 2024 at 7:31 PM Timo Rothenpieler wrote:
>
> On 19.08.2024 16:23, Araz Iusubov wrote:
> > From: Evgeny Pavlov
> >
> > This commit increase precision of Sleep() function on Windows.
> > This fix reduces the sleep time on Windows to improve AMF encoding
> > performance on low resolu
On Wed, Aug 21, 2024 at 6:41 PM Martin Storsjö wrote:
> On Wed, 21 Aug 2024, Ramiro Polla wrote:
> > A55 A76
> > pix_norm1_c: 484.3 235.2
> > pix_norm1_neon: 193.8 ( 2.50x) 44.7 ( 5.26x)
> > pix_sum_c: 302.8 243.7
> > pix_sum_neon:
On 7/28/2024 12:17 AM, Nuo Mi wrote:
The parser stage is not parallelizable.
We need to schedule it as soon as possible to create later stages, which are
more parallelizable
clips | before | after | delta
|---
I have very little experience with mailing lists, my apologies if this
reply does not end up where it is supposed to be.
The Apple developer docs say that AVMediaType is a struct, but it looks
seems that in reality it is typedef-ed to NSString*, just with an extra
specifier NS_EXTENSIBLE_STRING_EN
avfoundation.m uses constants prefixed with AVMediaType on Mac OS X > 10.6.
In 10.7 through 10.12 their type was NSString*, but starting with 10.13 a
new type alias AVMediaType was introduced. In avfoundation.m, the function
getDevicesWithMediaType takes this type as parameter, which breaks support
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 ends of the value range; I
didn't do that manually yet.
I prefer just
T-Head C908:
h264_v_loop_filter_chroma_8bpp_c: 137.4
h264_v_loop_filter_chroma_8bpp_rvv_i32: 54.2
---
libavcodec/riscv/h264dsp_init.c | 15 +
libavcodec/riscv/h264dsp_rvv.S | 99 -
2 files changed, 99 insertions(+), 15 deletions(-)
diff --git a/libavcodec
---
libavcodec/riscv/h264dsp_rvv.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/riscv/h264dsp_rvv.S b/libavcodec/riscv/h264dsp_rvv.S
index 2149c4217f..2472ba7925 100644
--- a/libavcodec/riscv/h264dsp_rvv.S
+++ b/libavcodec/riscv/h264dsp_rvv.S
@@ -309,7 +309,7 @@ e
---
libavcodec/riscv/h264dsp_rvv.S | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavcodec/riscv/h264dsp_rvv.S b/libavcodec/riscv/h264dsp_rvv.S
index 0d641008cb..2149c4217f 100644
--- a/libavcodec/riscv/h264dsp_rvv.S
+++ b/libavcodec/riscv/h264dsp_rvv.S
@@ -301,8 +301,
On Wed, 21 Aug 2024, Marc-Antoine ARNAUD wrote:
Le sam. 17 août 2024 à 21:15, Marton Balint a écrit :
On Wed, 14 Aug 2024, Marc-Antoine Arnaud wrote:
> ---
> libavformat/mxfdec.c | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
Why would you want to tune this?
Hi
MpegEncContext already has a BlockDSPContext, so we don't need another
one for DNXHDEncContext (which has an MpegEncContext).
---
libavcodec/dnxhdenc.c | 10 +-
libavcodec/dnxhdenc.h | 1 -
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/libavcodec/dnxhdenc.c b/libavcodec/d
The x86 optimized dct_quantize only calculates the last nonzero
coefficient correctly if the zigzag scan order is used. For the
alternate scan order, this value is incorrect.
To work around this, the dct_unquantize functions process the entire
block if the alternate scan order is used.
But a seco
---
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/intreadwrite.h b/libavutil/aarch64/intreadwri
It's safe to assume that LOCAL_ALIGNED_16 does indeed align. Otherwise
we would have many more problems...
This assert was added in f8188626 all the way back in 2003.
---
libavcodec/x86/mpegvideoenc_template.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavcodec/x86/mpegvideoenc_templa
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.)
I have confirmed that FFMPEG passes all the test cases without the flag.
The problem has been locally solved with the updated code, however, th
42 matches
Mail list logo
