Hi Pierre,
Here is the list of supported J2K reference codestreams.
p0_10.j2k
p1_01.j2k
p1_02.j2k
p1_03.j2k
p1_04.j2k
p1_05.j2k
p1_06.j2k
ds0_hm_15_b8.j2k
ds0_ht_02_b11.j2k
ds0_ht_02_b12.j2k
ds0_ht_03_b11.j2k
ds0_ht_03_b14.j2k
ds0_ht_04_b11.j2k
ds0_ht_04_b12.j2k
ds0_ht_05_b11.j2k
ds0_ht_05_b12.j2k
On 2024-06-15 03:54 am, Dennis Sädtler via ffmpeg-devel wrote:
On 2024-06-14 13:23, Gyan Doshi wrote:
On 2024-06-14 04:35 pm, Timo Rothenpieler wrote:
On 14/06/2024 12:44, Martin Storsjö wrote:
On Fri, 14 Jun 2024, Gyan Doshi wrote:
On 2024-06-14 02:18 am, Martin Storsjö wrote:
On Thu,
On date Thursday 2024-06-13 15:20:38 +0100, Andrew Sayers wrote:
> On Wed, Jun 12, 2024 at 10:52:00PM +0200, Stefano Sabatini wrote:
[...]
> > > +@section Context_general “Context” as a general concept
> [...]
> > I'd skip all this part, as we assume the reader is already familiar
> > with C langua
From: Zhao Zhili
Test on Apple M1 with kperf
bgr24_to_uv_8_c: 41.5
bgr24_to_uv_8_neon: 41.8
bgr24_to_uv_128_c: 133.5
bgr24_to_uv_128_neon: 94.3
bgr24_to_uv_1080_c: 960.5
bgr24_to_uv_1080_neon: 751.0
bgr24_to_uv_1920_c: 1695.3
bgr24_to_uv_1920_neon: 1357.3
bgr24_to_uv_half_8_c: 45.0
bgr24_to_uv_h
From: Zhao Zhili
Test on Apple M1 with kperf
bgra_to_uv_8_c: 13.4
bgra_to_uv_8_neon: 37.4
bgra_to_uv_128_c: 155.9
bgra_to_uv_128_neon: 91.7
bgra_to_uv_1080_c: 1173.2
bgra_to_uv_1080_neon: 822.7
bgra_to_uv_1920_c: 2078.2
bgra_to_uv_1920_neon: 1437.7
bgra_to_uv_half_8_c: 17.9
bgra_to_uv_half_8_neo
From: sunyuechi
C908 X60
vp9_avg_8tap_smooth_4h_8bpp_c : 12.7 11.2
vp9_avg_8tap_smooth_4h_8bpp_rvv_i32:4.74.2
vp9_avg_8tap_smooth_4v_8bpp_c : 29.7 12.5
vp9_avg_8tap_smo
From: sunyuechi
C908 X60
vp9_avg_8tap_smooth_4hv_8bpp_c : 32.0 28.0
vp9_avg_8tap_smooth_4hv_8bpp_rvv_i32 : 15.0 13.2
vp9_avg_8tap_smooth_8hv_8bpp_c : 98.0 86.2
vp9_avg_8tap_smo
From: sunyuechi
C908 X60
vp9_avg_bilin_4h_8bpp_c:5.54.7
vp9_avg_bilin_4h_8bpp_rvv_i32 :1.71.5
vp9_avg_bilin_4v_8bpp_c:5.54.7
vp9_avg_bilin_4v
From: sunyuechi
C908 X60
vp9_avg_bilin_4hv_8bpp_c : 10.79.5
vp9_avg_bilin_4hv_8bpp_rvv_i32 :4.03.5
vp9_avg_bilin_8hv_8bpp_c : 38.5 34.2
vp9_avg_bilin_8h
Just like in VP8, the unroll has been updated.
于2024年6月15日周六 19:51写道：
> From: sunyuechi
>
> C908 X60
> vp9_avg_bilin_4h_8bpp_c:5.54.7
> vp9_avg_bilin_4h_8bpp_rvv_i32 :1.71.5
>
> Copying vectors is rarely justified - mostly only before destructive
> instructions such as FMA.
It is slightly different from VP8. In VP8, many scalar values are positive,
so the related calculations can be easily replaced. However, in this
context of VP9, since t2 is a negative number, vwmaccs
> You can directly LLA filters + 16 * 8 * 2 and save one add. Same below.
You can
> also use .equ to alias the filter addresses, and avoid if's.
> That's a lot of address dependencies, which is going to hurt performance.
It
> might help to just spill more S registers if needed.
> This can be done
On Sat, Jun 15, 2024 at 2:35 PM Christophe Gisquet <
christophe.gisq...@gmail.com> wrote:
> Le ven. 14 juin 2024, 11:39, Frank Plowman a
> écrit :
>
> > When the SPS associated with a particular SPS ID changes, invalidate all
> > the PPSs which use that SPS ID. Fixes crashes with illegal bitstre
On Wed, Jun 12, 2024 at 9:36 PM Nuo Mi wrote:
> Hi all,
> If there are no objections, I will push it in 3 days.
>
> Thank you, Christian
>
>
> On Thu, Jun 6, 2024 at 3:52 AM Christian Bartnik
> wrote:
>
>> From: Thomas Siedel
>>
>> Add external encoder VVenC for H266/VVC encoding.
>> Register
On Sat, Jun 15, 2024 at 2:38 AM Frank Plowman wrote:
> Hi,
>
> Thanks for the patch. Unfortunately it looks to be corrupted and does
> not apply. Also, it looks as though you submitted five near-identical
> patches. I would suggest you try directing patches to your own mailbox
> and re-applyin
> >> From: ffmpeg-devel On Behalf Of
> >> Lynne via ffmpeg-devel
> >> Sent: Monday, June 10, 2024 10:01 AM
> >> To: FFmpeg development discussions and patches >> de...@ffmpeg.org>
> >> Cc: Lynne
> >> Subject: Re: [FFmpeg-devel] [PATCH v13 06/15] avcodec/vaapi_encode:
> >> move the dpb logic from
n 15/06/2024 13:24, Nuo Mi wrote:
> On Sat, Jun 15, 2024 at 2:35 PM Christophe Gisquet <
> christophe.gisq...@gmail.com> wrote:
>
>> Le ven. 14 juin 2024, 11:39, Frank Plowman a
>> écrit :
>>
>>> When the SPS associated with a particular SPS ID changes, invalidate all
>>> the PPSs which use that
Signed-off-by: Andreas Rheinhardt
---
libavcodec/h261enc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/h261enc.c b/libavcodec/h261enc.c
index dd4419ec8c..8e08c749d1 100644
--- a/libavcodec/h261enc.c
+++ b/libavcodec/h261enc.c
@@ -133,8 +133,8 @@ static voi
H.261 does not have B-frames.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/motion_est.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/libavcodec/motion_est.c b/libavcodec/motion_est.c
index e783e79a94..554fc9780e 100644
--- a/libavcodec/motion_est.c
+++ b
These must not be modified (even when they are initialized at runtime
and therefore modifiable).
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo_enc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index ab
This will allow to avoid the indirection via ff_h261_rl_tcoeff
in future commits.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/h261.h | 4
libavcodec/h261data.c | 12 ++--
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/libavcodec/h261.h b/libavcodec/h261.h
The RLTable API in rl.c is not well designed for codecs with
an explicit end-of-block code. ff_h261_rl_tcoeff's vlc has
the EOB code as first element (presumably so that the decoder
can check for it via "if (level == 0)") and this implies
that the indices returned by get_rl_index() are off by one
f
These tables are supposed to contain the number of bits needed
to encode a given (run, level) pair. Yet the number of bits
for pairs needing the escape code was wrong (it only contained
the escape code and not the bits needed for run and level).
Furthermore, H.261 (a format with explicit end-of-bl
Fixes ticket #11057.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/loongarch/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/loongarch/Makefile b/libavcodec/loongarch/Makefile
index 07da2964e4..92c8b35906 100644
--- a/libavcodec/loongarch/Makefile
+++ b
On Sat, Jun 15, 2024 at 12:15:16PM +0900, Osamu Watanabe wrote:
> Signed-off-by: Osamu Watanabe
> ---
> libavcodec/jpeg2000.h | 10 +
> libavcodec/jpeg2000dec.c | 454 ++---
> libavcodec/jpeg2000dec.h | 7 +
> libavcodec/jpeg2000htdec.c | 225 ++
Hello,
I updated the VapourSynth input module from the old API to the "new" API
(the "new" API was introduced 4 years ago).
The greatest advantage of the new API is, that it requires only a single
import from the VapourSynth library, optimizing it for runtime loading
instead of linking to the li
From: Pierre-Anthony Lemieux
p0_10.j2k is one of the reference codestreams included in Rec. ITU-T T.803 |
ISO/IEC 15444-4.
---
tests/fate/jpeg2000.mak | 3 +++
tests/ref/fate/jpeg2000dec-p0_10 | 6 ++
2 files changed, 9 insertions(+)
create mode 100644 tests/ref/fate/jpeg2000dec-p
> On Jun 14, 2024, at 19:09, Martin Storsjö wrote:
>
> The default timer register pmccntr_el0 usually requires enabling
> access with e.g. a kernel module.
>
> On macOS, using cntvct_el0 gives measurements with the same
> magnitude as mach_absolute_time (which is used currently), but
> possibl
> On Jun 12, 2024, at 23:22, Zhao Zhili wrote:
>
> From: Zhao Zhili
>
> Firstly, make ff_kperf_cycles as an implementation of AV_READ_TIME
> avoids code duplication.
>
> Secondly, fix compilation error since 6a18c0bc87e when macos-kperf
> is enabled. mach_time.h is included only when CONFIG
29 matches
Mail list logo
