Le 6 juin 2024 10:01:24 GMT+03:00, Christophe Gisquet
a écrit :
>Le jeu. 6 juin 2024 à 08:11, Rémi Denis-Courmont a écrit :
>> >James Almer:
>> >> uyvytoyuv422_c: 23991.8
>> >> uyvytoyuv422_sse2: 2817.8
>> >> uyvytoyuv422_avx: 2819.3
>> >
>> >Why don't you nuke the avx version in a follow-up p
On Mon, May 27, 2024 at 3:47 PM llyyr wrote:
>
> instead of just resyncing and skipping a bunch of TS packets, leading to
> a loss of frames.
>
> Before this, a stray byte with the value of 0x47 in TP_extra_header
> would throw off the detection of where TS packets start.
>
> A typical file that c
On Fri, Jun 7, 2024 at 9:47 AM Hendrik Leppkes wrote:
>
> On Mon, May 27, 2024 at 3:47 PM llyyr wrote:
> >
> > instead of just resyncing and skipping a bunch of TS packets, leading to
> > a loss of frames.
> >
> > Before this, a stray byte with the value of 0x47 in TP_extra_header
> > would throw
On Fri, 7 Jun 2024, Zhao Zhili wrote:
From: Zhao Zhili
B0 is defined by system header.
Can you add more details about which header defines this? (I did a quick
grep in a copy of the android NDK, and found it in
asm-generic/termbits-common.h.)
// Martin
__
> On Jun 7, 2024, at 16:21, Martin Storsjö wrote:
>
> On Fri, 7 Jun 2024, Zhao Zhili wrote:
>
>> From: Zhao Zhili
>>
>> B0 is defined by system header.
>
> Can you add more details about which header defines this? (I did a quick grep
> in a copy of the android NDK, and found it in asm-gene
On Fri, 7 Jun 2024, Martin Storsjö wrote:
On Fri, 7 Jun 2024, Zhao Zhili wrote:
From: Zhao Zhili
B0 is defined by system header.
Can you add more details about which header defines this? (I did a quick grep
in a copy of the android NDK, and found it in asm-generic/termbits-common.h.)
Bt
On Fri, 7 Jun 2024, Zhao Zhili wrote:
On Jun 7, 2024, at 16:21, Martin Storsjö wrote:
On Fri, 7 Jun 2024, Zhao Zhili wrote:
From: Zhao Zhili
B0 is defined by system header.
Can you add more details about which header defines this? (I did a quick grep
in a copy of the android NDK, and
> On Jun 7, 2024, at 16:38, Martin Storsjö wrote:
>
> On Fri, 7 Jun 2024, Martin Storsjö wrote:
>
>> On Fri, 7 Jun 2024, Zhao Zhili wrote:
>>
>>> From: Zhao Zhili
>>> B0 is defined by system header.
>>
>> Can you add more details about which header defines this? (I did a quick
>> grep in a
On Fri, 7 Jun 2024, Zhao Zhili wrote:
Note both tests use clang as compiler, which has vectorization
enabled by default with -O3.
FWIW, for more interesting benchmarks, you can configure the build with
--optflags="-O3 -fno-vectorize".
(Although, the benchmarks against a compiler vectorized
On Fri, 7 Jun 2024, Zhao Zhili wrote:
From: Zhao Zhili
It will fallback to mach_absolute_time inside libavutil/timer.h
---
libavutil/aarch64/timer.h | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/libavutil/aarch64/timer.h b/libavutil/aarch64/timer.h
index 8b28fd354c.
On Fri, 7 Jun 2024, Zhao Zhili wrote:
From: Zhao Zhili
---
libavutil/timer.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavutil/timer.h b/libavutil/timer.h
index 2cd299eca3..74c4d84e69 100644
--- a/libavutil/timer.h
+++ b/libavutil/timer.h
@@ -46,6 +46,8 @@
#include "macos_kperf
The default timer register pmccntr_el0 usually requires enabling
access with e.g. a kernel module.
---
cntvct_el0 has significantly better resolution than
av_gettime_relative (while the unscaled nanosecond output of
clock_gettime is much higher resolution).
In one tested case, the cntvct_el0 timer
Le 7 juin 2024 12:12:45 GMT+03:00, "Martin Storsjö" a écrit :
>The default timer register pmccntr_el0 usually requires enabling
>access with e.g. a kernel module.
>---
>cntvct_el0 has significantly better resolution than
>av_gettime_relative (while the unscaled nanosecond output of
>clock_gettim
On Fri, Jun 07, 2024 at 09:45:09AM +0300, Rémi Denis-Courmont wrote:
> Hi,
>
> Le 7 juin 2024 06:33:20 GMT+03:00, Shiqi Zhu a écrit :
> >> Initialization and render in the same thread is one of the issues. Another
> >> issue is SDL render should be run in main thread. Maybe it’s not the
> >> duty
On Fri, 7 Jun 2024, Rémi Denis-Courmont wrote:
Le 7 juin 2024 12:12:45 GMT+03:00, "Martin Storsjö" a écrit :
The default timer register pmccntr_el0 usually requires enabling
access with e.g. a kernel module.
---
cntvct_el0 has significantly better resolution than
av_gettime_relative (while the
On Sun, Jun 02, 2024 at 02:02:53PM +0200, Gerion Entrup wrote:
> Actually, the jaccard distance is defined as D = 1 - intersect / union.
> Additionally, the distance value is compared against a constant that
> must be between 0 and 1, which is not the case here. Both facts together
> has led to the
Quoting Michael Niedermayer (2024-06-07 11:53:51)
> On Fri, Jun 07, 2024 at 09:45:09AM +0300, Rémi Denis-Courmont wrote:
> > Hi,
> >
> > Le 7 juin 2024 06:33:20 GMT+03:00, Shiqi Zhu a écrit :
> > >> Initialization and render in the same thread is one of the issues.
> > >> Another
> > >> issue is
> On Jun 7, 2024, at 17:09, Martin Storsjö wrote:
>
> On Fri, 7 Jun 2024, Zhao Zhili wrote:
>
>> Note both tests use clang as compiler, which has vectorization
>> enabled by default with -O3.
>
> FWIW, for more interesting benchmarks, you can configure the build with
> --optflags="-O3 -fno-v
> On Jun 7, 2024, at 17:09, Martin Storsjö wrote:
>
> On Fri, 7 Jun 2024, Zhao Zhili wrote:
>
>> Note both tests use clang as compiler, which has vectorization
>> enabled by default with -O3.
>
> FWIW, for more interesting benchmarks, you can configure the build with
> --optflags="-O3 -fno-v
Am 04.06.24 um 12:25 schrieb sfan5:
___
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".
Will com
On Fri, 7 Jun 2024, Zhao Zhili wrote:
On Jun 7, 2024, at 17:09, Martin Storsjö wrote:
On Fri, 7 Jun 2024, Zhao Zhili wrote:
Note both tests use clang as compiler, which has vectorization
enabled by default with -O3.
FWIW, for more interesting benchmarks, you can configure the build with
-
Le 7 juin 2024 12:53:51 GMT+03:00, Michael Niedermayer
a écrit :
>We can require anything from an API that we are able to change and extend
>Of course we can decide not to allow such requirment even if optional
>but we surely _could_ add such a feature if we choose to do so
Sure. You can also
On Mon, May 27, 2024 at 01:52:20AM +0200, Michael Niedermayer wrote:
> Fixes: CID1598556 Unchecked return value
>
> Sponsored-by: Sovereign Tech Fund
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/vp8.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
will apply the vp8 pat
SliceHeader.{entry_point_offset,size,offset} are not derived from frame
size and do not need to be freed here.
---
libavcodec/hevc/hevcdec.c | 4
1 file changed, 4 deletions(-)
diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c
index 4e0df4d033..d317c1471a 100644
--- a/libavc
PPS depends on, and is parsed for, specific SPS data.
This will be useful in following commits.
---
libavcodec/hevc/hevcdec.c | 4 ++--
libavcodec/hevc/parser.c | 8 ++--
libavcodec/hevc/ps.c | 4
libavcodec/hevc/ps.h | 2 ++
4 files changed, 10 insertions(+), 8 deletions(-)
---
libavcodec/hevc/hevcdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c
index d317c1471a..43cbc45062 100644
--- a/libavcodec/hevc/hevcdec.c
+++ b/libavcodec/hevc/hevcdec.c
@@ -3115,7 +3115,7 @@ static int decode_nal_un
The exact same code is executed at the beginning of decode_nal_units()
---
libavcodec/hevc/hevcdec.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c
index 43cbc45062..46db7923fe 100644
--- a/libavcodec/hevc/hevcdec.c
+++ b/libavcodec/hevc/he
Instead, accept PPS as a function argument and retrieve SPS through it.
Makes the code shorter and significantly reduces diff in future commits.
---
libavcodec/hevc/hevcdec.c | 28 +
libavcodec/hevc/hevcdec.h | 8 ++-
libavcodec/hevc/mvs.c | 126
And replace the HEVCContext* parameter by void *logctx.
Makes it clear that only SliceHeader is modified by this function.
---
libavcodec/hevc/hevcdec.c | 75 ---
1 file changed, 38 insertions(+), 37 deletions(-)
diff --git a/libavcodec/hevc/hevcdec.c b/libavc
Instead, accept PPS/SPS as function arguments.
Makes the code shorter and significantly reduces diff in future commits.
---
libavcodec/hevc/hevcdec.c | 26 +--
libavcodec/hevc/pred.h | 4 +-
libavcodec/hevc/pred_template.c | 74
libavcodec/mips/hevcpred_mips.h | 4 +-
They are useless duplicates of corresponding AVCodecContext fields.
---
libavcodec/hevc/filter.c | 6 +++---
libavcodec/hevc/hevcdec.c | 36 +---
libavcodec/hevc/hevcdec.h | 3 ---
libavcodec/hevc/mvs.c | 4 ++--
libavcodec/hevc/refs.c| 2 +-
5 files ch
Instead, accept PPS/SPS as function arguments.
Makes the code shorter and significantly reduces diff in future commits.
---
libavcodec/hevc/hevcdec.c | 876 --
1 file changed, 469 insertions(+), 407 deletions(-)
diff --git a/libavcodec/hevc/hevcdec.c b/libavco
All other errors should cause a failure, regardless of the value of
err_recognition. Also, print a warning message when skipping invalid NAL
units.
---
libavcodec/hevc/hevcdec.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/he
Not once per each slice header, as it makes no sense and may cause races
with frame threading.
---
libavcodec/hevc/hevcdec.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c
index dd3c188418..bf6e93ba1b 100644
--- a/l
It is only done once per frame. Also, rename the variable to poc_tid0 to
be consistent with our naming conventions.
---
libavcodec/hevc/hevcdec.c | 26 +-
libavcodec/hevc/hevcdec.h | 2 +-
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/libavcodec/hevc/hev
Pass the only things required from it - slice header and PPS -
explicitly.
Will be useful in the following commits to avoid mofiying HEVCContext in
hls_slice_header().
---
libavcodec/hevc/hevcdec.c | 2 +-
libavcodec/hevc/hevcdec.h | 2 +-
libavcodec/hevc/refs.c| 8
libavcodec/nvdec_
Into decode_slice_data(). This is a step towards constifying
HEVCContext in hls_slice_header().
---
libavcodec/hevc/hevcdec.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c
index bbcaa350c7..cda52e05ef 10064
---
libavcodec/hevc/hevcdec.c | 4
libavcodec/hevc/hevcdec.h | 1 -
2 files changed, 5 deletions(-)
diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c
index a241e25196..b9aea45edb 100644
--- a/libavcodec/hevc/hevcdec.c
+++ b/libavcodec/hevc/hevcdec.c
@@ -3143,7 +3143,6 @@ sta
Its meaning is only specified for IRAP frames.
As it's currently never used otherwise, this should not change decoder
behaviour, but will be useful in future commits.
---
libavcodec/hevc/hevcdec.c | 4 +++-
libavcodec/hevc/hevcdec.h | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)
diff --g
"Currently active PPS" is a property of the decoding process, not of the
list of available parameter sets.
---
libavcodec/dxva2_hevc.c | 8
libavcodec/hevc/hevcdec.c | 19 ---
libavcodec/hevc/hevcdec.h | 1 +
libavcodec/hevc/ps.c | 12 ++--
libavcodec/hevc
Pass the two numbers needed from it explicitly.
Makes it clear that HEVCContext is not modified by this function.
---
libavcodec/hevc/hevcdec.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c
index 6a9de79dcd..960a0
Also move there a sanity check from hls_decode_entry() that should also
be performed when WPP is active (note that the check is not moved to
hls_slice_header() because it requires the HEVCContext.tab_slice_address
to be set up).
---
libavcodec/hevc/hevcdec.c | 36 ++
Rather than decoding directly into HEVCContext.poc.
This is a step towards constifying HEVCContext in hls_slice_header().
---
libavcodec/hevc/hevcdec.c | 13 +++--
libavcodec/hevc/hevcdec.h | 1 +
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/libavcodec/hevc/hevcdec.c b/
Pass this information explicitly instead.
---
libavcodec/hevc/cabac.c | 7 ---
libavcodec/hevc/hevcdec.c | 4 ++--
libavcodec/hevc/hevcdec.h | 3 ++-
3 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/libavcodec/hevc/cabac.c b/libavcodec/hevc/cabac.c
index 8708efc248..39ca7c0135
>From decode_nal_unit(), as that is a more appropriate place for it.
---
libavcodec/hevc/hevcdec.c | 38 +-
1 file changed, 17 insertions(+), 21 deletions(-)
diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c
index 0bf68ea45c..c148244361 100644
Combine it with an existing similar check.
---
libavcodec/hevc/hevcdec.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c
index df6d1565bc..9c1d879953 100644
--- a/libavcodec/hevc/hevcdec.c
+++ b/libavcodec/hevc/hevcd
>From decode_nal_unit(), as that is a more appropriate place for it.
---
libavcodec/hevc/hevcdec.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c
index cda52e05ef..0bf68ea45c 100644
--- a/libavcodec/hevc/hevcde
---
libavcodec/hevc/hevcdec.c | 97 +--
1 file changed, 52 insertions(+), 45 deletions(-)
diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c
index b9aea45edb..7263b80a24 100644
--- a/libavcodec/hevc/hevcdec.c
+++ b/libavcodec/hevc/hevcdec.c
@@ -
---
libavcodec/hevc/hevcdec.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c
index c148244361..804cceac3e 100644
--- a/libavcodec/hevc/hevcdec.c
+++ b/libavcodec/hevc/hevcdec.c
@@ -665,11 +665,9
hls_slice_header() no longer modifies anything in HEVCContext besides
SliceHeader.
---
libavcodec/hevc/hevcdec.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c
index b13e3e06a3..2809e1e61d 100644
--- a/libav
Not in hls_slice_header(), as it should only be done once per frame.
---
libavcodec/hevc/hevcdec.c | 52 ---
1 file changed, 27 insertions(+), 25 deletions(-)
diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c
index 804cceac3e..9abae3260d 100644
Do not do it in hls_slice_header(), which is the wrong place for it.
Avoids special magic return value of 1 in that function. The comment
mentioning potential corrupted state is no longer relevant, as
hls_slice_header() modifies no state beyond SliceHeader, which will only
get used for a valid fram
Instead, accept PPS/SPS as function arguments.
Makes the code shorter and significantly reduces diff in future commits.
---
libavcodec/hevc/cabac.c | 145 +++---
libavcodec/hevc/hevcdec.c | 31
libavcodec/hevc/hevcdec.h | 22 +++---
3 files changed, 10
The parser does not need to preserve these between frames.
---
libavcodec/hevc/parser.c | 55
1 file changed, 27 insertions(+), 28 deletions(-)
diff --git a/libavcodec/hevc/parser.c b/libavcodec/hevc/parser.c
index 49f7bccdfa..f4e6e3c36d 100644
--- a/libav
SPS and its dependent PPSes depend on, and are parsed for, specific VPS data.
This will be useful in following commits.
---
libavcodec/hevc/hevcdec.c | 5 ++---
libavcodec/hevc/parser.c | 2 +-
libavcodec/hevc/ps.c | 13 +
libavcodec/hevc/ps.h | 2 ++
4 files changed, 14
Instead, accept PPS as a function argument and retrieve SPS through it.
Makes the code shorter and significantly reduces diff in future commits.
---
libavcodec/hevc/filter.c | 311 --
libavcodec/hevc/hevcdec.c | 20 +--
libavcodec/hevc/hevcdec.h | 14 +-
3 f
---
libavcodec/hevc/hevcdec.c | 9 ++---
libavcodec/hevc/hevcdec.h | 1 -
2 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c
index 6dda923df5..d599373c9d 100644
--- a/libavcodec/hevc/hevcdec.c
+++ b/libavcodec/hevc/hevcdec.c
@@
Instead of an ad-hoc scheme. Also, combine skipping RASL frames with
skip_frame handling - current code seems flawed as it only executes for
the first slice of a RASL frame and unnecessarily unsets is_decoded,
which should not be set at this point anyway..
Some RASL frames in fate-hevc-afd-tc-sei
>From hls_slice_header(). It is only done once per frame, so that is a
more appropriate place for this code.
---
libavcodec/hevc/hevcdec.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c
index 9abae3260d..b13e3e0
It's a race with frame threading.
---
libavcodec/hevc/hevcdec.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c
index a8c2172674..5fc55d5de9 100644
--- a/libavcodec/hevc/hevcdec.c
+++ b/libavcodec/hevc/hevcdec.c
@@ -3135
Specifically, calling hwaccel end_frame, verifying frame checksum,
and printing the frame-was-decoded message.
---
libavcodec/hevc/hevcdec.c | 187 +++---
libavcodec/hevc/hevcdec.h | 1 -
2 files changed, 91 insertions(+), 97 deletions(-)
diff --git a/libavcodec/
---
libavcodec/hevc/hevcdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c
index 5fc55d5de9..88f2bcecad 100644
--- a/libavcodec/hevc/hevcdec.c
+++ b/libavcodec/hevc/hevcdec.c
@@ -3449,7 +3449,7 @@ static int hevc_decode_f
From: Zhao Zhili
It will fallback to mach_absolute_time inside libavutil/timer.h
---
libavutil/aarch64/timer.h | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/libavutil/aarch64/timer.h b/libavutil/aarch64/timer.h
index 8b28fd354c..fadc9568f8 100644
--- a/libavutil/aarc
From: Zhao Zhili
---
v3: add ff_read_time() rather than use av_gettime_relative() to get
nanosecond precision.
libavutil/timer.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavutil/timer.h b/libavutil/timer.h
index 2cd299eca3..3e5d5ef23f 100644
--- a/libavutil/timer.h
+++
From: Zhao Zhili
B0 is defined by system header, see f0f596dbc6b for ref.
---
v3: add f0f596dbc6b as ref.
tests/checkasm/llviddsp.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/tests/checkasm/llviddsp.c b/tests/checkasm/llviddsp.c
index b75c0ea099..9f8d
From: Zhao Zhili
Test on Apple M1:
rgb24_to_uv_8_c: 0.0
rgb24_to_uv_8_neon: 0.2
rgb24_to_uv_128_c: 1.0
rgb24_to_uv_128_neon: 0.5
rgb24_to_uv_1080_c: 7.0
rgb24_to_uv_1080_neon: 5.7
rgb24_to_uv_1920_c: 12.5
rgb24_to_uv_1920_neon: 9.5
rgb24_to_uv_half_8_c: 0.2
rgb24_to_uv_half_8_neon: 0.2
rgb24_to_
---
tests/checkasm/Makefile | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
index 6eb94d10d5..3ce152e818 100644
--- a/tests/checkasm/Makefile
+++ b/tests/checkasm/Makefile
@@ -63,7 +63,9 @@ AVFILTEROBJS-$(CONFIG_SOBEL_FILTER)
---
tests/checkasm/Makefile | 1 +
tests/checkasm/checkasm.c | 1 +
tests/checkasm/checkasm.h | 1 +
tests/checkasm/sw_range_convert.c | 134 ++
4 files changed, 137 insertions(+)
create mode 100644 tests/checkasm/sw_range_convert.c
dif
chrRangeFromJpeg_8_c: 19.9
chrRangeFromJpeg_8_sse4: 16.2
chrRangeFromJpeg_24_c: 60.7
chrRangeFromJpeg_24_sse4: 28.9
chrRangeFromJpeg_128_c: 325.7
chrRangeFromJpeg_128_sse4: 160.2
chrRangeFromJpeg_144_c: 364.2
chrRangeFromJpeg_144_sse4: 194.9
chrRangeFromJpeg_256_c: 630.7
chrRangeFromJpeg_256_sse4:
chrRangeFromJpeg_8_c: 28.5
chrRangeFromJpeg_8_neon: 21.2
chrRangeFromJpeg_24_c: 81.2
chrRangeFromJpeg_24_neon: 34.7
chrRangeFromJpeg_128_c: 425.2
chrRangeFromJpeg_128_neon: 162.0
chrRangeFromJpeg_144_c: 480.2
chrRangeFromJpeg_144_neon: 180.2
chrRangeFromJpeg_256_c: 838.2
chrRangeFromJpeg_256_neon:
Le perjantaina 7. kesäkuuta 2024, 16.44.50 EEST Zhao Zhili a écrit :
> From: Zhao Zhili
>
> ---
> v3: add ff_read_time() rather than use av_gettime_relative() to get
> nanosecond precision.
>
> libavutil/timer.h | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/libavutil/tim
On 03/06/2024 11:18, tong1.wu-at-intel@ffmpeg.org wrote:
From: Tong Wu
Move receive_packet function to base. This requires adding *alloc,
*issue, *output, *free as hardware callbacks. HWBaseEncodePicture is
introduced as the base layer structure. The related parameters in
VAAPIEncodeContext
>From: ffmpeg-devel On Behalf Of Lynne
>via ffmpeg-devel
>Sent: Friday, June 7, 2024 11:10 PM
>To: ffmpeg-devel@ffmpeg.org
>Cc: Lynne
>Subject: Re: [FFmpeg-devel] [PATCH v13 06/15] avcodec/vaapi_encode: move
>the dpb logic from VAAPI to base layer
>
>On 03/06/2024 11:18, tong1.wu-at-intel@ffm
C908 X60
chrRangeFromJpeg_8_c: 2.72.5
chrRangeFromJpeg_8_rvv_i32:1.71.5
chrRangeFromJpeg_24_c: 7.56.7
chrRangeFromJpeg_24_rvv_i32: 1.71.5
chrRangeFromJpeg_128_c: 55.2 34.7
chrRangeFromJpeg_128_rvv_i32: 6.53.0
chrRang
On 07/06/2024 17:22, Wu, Tong1 wrote:
From: ffmpeg-devel On Behalf Of Lynne
via ffmpeg-devel
Sent: Friday, June 7, 2024 11:10 PM
To: ffmpeg-devel@ffmpeg.org
Cc: Lynne
Subject: Re: [FFmpeg-devel] [PATCH v13 06/15] avcodec/vaapi_encode: move
the dpb logic from VAAPI to base layer
On 03/06/2024 1
Since the C11 support is required, those GCC versions can no longer be
supported anyhow.
---
libavutil/arm/bswap.h| 20
libavutil/arm/intreadwrite.h | 91
libavutil/intreadwrite.h | 4 +-
3 files changed, 1 insertion(+), 114 deletions(-)
Since the C11 support is required, those GCC versions can no longer be
supported anyhow.
---
libavutil/x86/bswap.h | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/libavutil/x86/bswap.h b/libavutil/x86/bswap.h
index b2f18b6c93..1ce9dcfc65 100644
--- a/libavutil/x8
On Fri, Jun 7, 2024 at 4:05 PM Ramiro Polla wrote:
>
> chrRangeFromJpeg_8_c: 19.9
> chrRangeFromJpeg_8_sse4: 16.2
> chrRangeFromJpeg_24_c: 60.7
> chrRangeFromJpeg_24_sse4: 28.9
> chrRangeFromJpeg_128_c: 325.7
> chrRangeFromJpeg_128_sse4: 160.2
> chrRangeFromJpeg_144_c: 364.2
> chrRangeFromJpeg_144
chrRangeFromJpeg_8_c: 49.4
chrRangeFromJpeg_8_sse4: 15.9
chrRangeFromJpeg_8_avx2: 22.6
chrRangeFromJpeg_24_c: 129.4
chrRangeFromJpeg_24_sse4: 32.1
chrRangeFromJpeg_24_avx2: 35.1
chrRangeFromJpeg_128_c: 534.6
chrRangeFromJpeg_128_sse4: 165.6
chrRangeFromJpeg_128_avx2: 100.4
chrRangeFromJpeg_144_c: 7
On Fri, Jun 7, 2024 at 7:38 PM Ramiro Polla wrote:
>
> chrRangeFromJpeg_8_c: 49.4
> chrRangeFromJpeg_8_sse4: 15.9
> chrRangeFromJpeg_8_avx2: 22.6
> chrRangeFromJpeg_24_c: 129.4
> chrRangeFromJpeg_24_sse4: 32.1
> chrRangeFromJpeg_24_avx2: 35.1
> chrRangeFromJpeg_128_c: 534.6
> chrRangeFromJpeg_128_
Le perjantaina 7. kesäkuuta 2024, 21.05.50 EEST marcus a écrit :
> On Friday, June 7th, 2024 at 11:49 AM, Rémi Denis-Courmont
wrote:
> > Since the C11 support is required, those GCC versions can no longer be
> > supported anyhow.
> > ---
> > libavutil/x86/bswap.h | 13 ++---
> > 1 file cha
C code or compiler built-ins are preferable over inline assembler for
byte-swaps as it allows for better optimisations (e.g. instruction
scheduling) which would otherwise be impossible.
As with f64c2e710fa1a7b59753224e717f57c48462076f for x86 and Arm,
this removes the inline assembler on GCC (and
Support for SuperH was dropped over a decade ago. There no longer is any
architecture-specific code to be found, so just remove the corresponding
test. Technically it is still possible to compile FFmpeg as the
"generic" (pure C) architecture.
---
configure | 4
libavcodec/sh4/READ
marcus:
>
>
>
>
>
> On Friday, June 7th, 2024 at 11:49 AM, Rémi Denis-Courmont
> wrote:
>
>>
>>
>> Since the C11 support is required, those GCC versions can no longer be
>> supported anyhow.
>> ---
>> libavutil/x86/bswap.h | 13 ++---
>> 1 file changed, 2 insertions(+), 11 deletions(
Ramiro Polla:
> ---
> tests/checkasm/Makefile | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
> index 6eb94d10d5..3ce152e818 100644
> --- a/tests/checkasm/Makefile
> +++ b/tests/checkasm/Makefile
> @@ -63,7 +63,9 @@ AVF
On Fri, May 10, 2024 at 04:07:03PM +0200, Michael Niedermayer wrote:
> Yes the same dead code is in "iLBC Speech Coder ANSI-C Source Code"
>
> Fixes: CID1509370 Logically dead code
>
> Sponsored-by: Sovereign Tech Fund
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/ilbcdec.c | 6 --
Help coverity with CID1500302 Uninitialized scalar variable
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavformat/img2dec.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
index ba523530745..20b1bc31f6a 100644
---
On Wed, May 08, 2024 at 04:39:22AM +0200, Michael Niedermayer wrote:
> Found by reviewing code related to CID1500301 String not null terminated
>
> Sponsored-by: Sovereign Tech Fund
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/sdp.c | 3 +++
> 1 file changed, 3 insertions(+)
will ap
On Sun, Apr 28, 2024 at 01:54:19AM +0200, Michael Niedermayer wrote:
> Fixes: CID1538863 Resource leak
>
> Sponsored-by: Sovereign Tech Fund
> Signed-off-by: Michael Niedermayer
> ---
> fftools/ffmpeg_mux_init.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
will apply
[...]
--
Micha
On Sun, Apr 28, 2024 at 01:54:21AM +0200, Michael Niedermayer wrote:
> issue found while reviewing CID1452612 Free of array-typed value
>
> Sponsored-by: Sovereign Tech Fund
> Signed-off-by: Michael Niedermayer
> ---
> fftools/cmdutils.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
w
On Fri, Jun 7, 2024 at 8:46 PM Andreas Rheinhardt
wrote:
>
> Ramiro Polla:
> > ---
> > tests/checkasm/Makefile | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
> > index 6eb94d10d5..3ce152e818 100644
> > --- a/test
Do av_clip_int16(val) _after_ copying the value to last_dc.
Related commits: c28f648b19d and dffae122d0f
Related ticket: 4683
---
libavcodec/mjpegdec.c| 3 +--
tests/ref/fate/jpg-12bpp | 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mj
Ramiro Polla:
> # swscale tests
> -SWSCALEOBJS += sw_gbrp.o sw_rgb.o sw_scale.o
> +SWSCALEOBJS += sw_gbrp.o \
> + sw_rgb.o \
> + sw_scale.o \
>
> CHECKASMO
Ramiro Polla:
> Do av_clip_int16(val) _after_ copying the value to last_dc.
>
> Related commits: c28f648b19d and dffae122d0f
> Related ticket: 4683
> ---
> libavcodec/mjpegdec.c| 3 +--
> tests/ref/fate/jpg-12bpp | 2 +-
> 2 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/lib
On Fri, Jun 7, 2024 at 9:27 PM Andreas Rheinhardt
wrote:
>
> Ramiro Polla:
> > # swscale tests
> > -SWSCALEOBJS += sw_gbrp.o sw_rgb.o sw_scale.o
> > +SWSCALEOBJS += sw_gbrp.o \
> > + sw_rgb.o \
> > +
On Fri, Jun 7, 2024 at 9:35 PM Andreas Rheinhardt
wrote:
> Ramiro Polla:
> > Do av_clip_int16(val) _after_ copying the value to last_dc.
> >
> > Related commits: c28f648b19d and dffae122d0f
> > Related ticket: 4683
> > ---
> > libavcodec/mjpegdec.c| 3 +--
> > tests/ref/fate/jpg-12bpp | 2 +-
On 07/06/2024 21:33, Marcus B Spencer wrote:
On Friday, June 7th, 2024 at 1:12 PM, Lynne via ffmpeg-devel
wrote:
Since the "codec" is essentially just raw data, you should just make the
demuxer output native RGBA64, and the muxer accept RGBA64. There's no
reason to have this as a codec,
On Fri, Jun 7, 2024 at 12:49 PM Rémi Denis-Courmont wrote:
>
> Since the C11 support is required, those GCC versions can no longer be
> supported anyhow.
> ---
> libavutil/arm/bswap.h| 20
> libavutil/arm/intreadwrite.h | 91
> libavutil/intre
On Fri, Jun 7, 2024 at 2:20 PM Rémi Denis-Courmont wrote:
>
> C code or compiler built-ins are preferable over inline assembler for
> byte-swaps as it allows for better optimisations (e.g. instruction
> scheduling) which would otherwise be impossible.
>
> As with f64c2e710fa1a7b59753224e717f57c484
On Fri, Jun 7, 2024 at 2:20 PM Rémi Denis-Courmont wrote:
>
> Support for SuperH was dropped over a decade ago. There no longer is any
> architecture-specific code to be found, so just remove the corresponding
> test. Technically it is still possible to compile FFmpeg as the
> "generic" (pure C) a
1 - 100 of 109 matches
Mail list logo
