On 7/25/2024 11:15 PM, James Almer wrote:
Signed-off-by: James Almer
---
doc/APIchanges | 3 +++
libavutil/intreadwrite.h | 39 +++
libavutil/version.h | 2 +-
3 files changed, 43 insertions(+), 1 deletion(-)
Will apply set.
___
Signed-off-by: Nathan E. Egge
---
libavutil/timer.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavutil/timer.h b/libavutil/timer.h
index 663daf81c6..03706b0d10 100644
--- a/libavutil/timer.h
+++ b/libavutil/timer.h
@@ -80,6 +80,7 @@
return ts.tv_sec * INT64_C(10) +
T-Head C908 (ns):
h264_biweight2_8_c:2414.5
h264_biweight2_8_rvv_i32: 701.8 (before)
h264_biweight2_8_rvv_i32: 562.8 (after)
h264_biweight4_8_c:4655.3
h264_biweight4_8_rvv_i32: 1377.5 (before)
h264_biweight4_8_rvv_i32: 1109.0 (after)
h264_biweight8_8_c:9701.5
h264_biwe
Le sunnuntaina 28. heinäkuuta 2024, 20.10.51 EEST Nathan E. Egge a écrit :
> The implementation of ff_read_time() for RISC-V uses rdtime which has
> precision on existing hardware too low (!) for benchmarking purposes.
> Deleting this implementation falls back on clock_gettime() which was
> added
This ensures that if a codec isn't on codec_whitelist, its VUI
information can still be populated during find_stream_info()
via parsers.
Signed-off-by: Dale Curtis
---
libavcodec/avcodec.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
no_reinit.patch
Description: Binary da
>-Original Message-
>From: ffmpeg-devel On Behalf Of
>fei.w.wang-at-intel@ffmpeg.org
>Sent: 2024年7月23日 9:27
>To: ffmpeg-devel@ffmpeg.org
>Cc: fei.w.w...@intel.com
>Subject: [FFmpeg-devel] [PATCH] lavu/hwcontext_qsv: Derive bind flag from
>frame type if no valid surface
>
>From: Fei Wan
Le tiistaina 23. heinäkuuta 2024, 11.51.48 EEST u...@foxmail.com a écrit :
> 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.
Hi,
Le lauantaina 22. kesäkuuta 2024, 18.58.03 EEST u...@foxmail.com a écrit :
> From: sunyuechi
In my opinion, we can't keep on like this. By the end of year, there will also
be 512-bit vector hardware. In the worst case, specialisation on vector length
could require 7 variants of eve
Lynne:
>Subject: Re: [FFmpeg-devel] [PATCH 2/2] lavc/d3d12va_encode: trim header
>alignment at output
>
>On 28/07/2024 15:06, Tong Wu wrote:
>> Tong Wu:
>>> Subject: [FFmpeg-devel][PATCH 2/2] lavc/d3d12va_encode: trim header
>>> alignment at output
>>>
>>> It is d3d12va's requirement that the Frame
On Thu, 25 Jul 2024, Martin Storsjö wrote:
A command like "cc -c -E" is tautological; the -c is ignored, when
we explicitly specify that we want to preprocess only.
Since
https://github.com/llvm/llvm-project/commit/6461e537815f7fa68cef06842505353cf5600e9c
and https://github.com/llvm/llvm-projec
Add an OpenCL filter for filtering GoPro Max native .360 files
into standard equirectangular or youtube equiangular cubemap (eac)
projection.
The .360 file contains separated two video streams.
This filter combine two streams into single stream with standard
format.
---
configure
This is updated patch of:
https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=3943
I contacted to Ronan LE MEILLAT and agreed with him to submit new patch.
Abstruct of GoPro Max .360 video file format is described in:
https://gopro.com/news/max-tech-specs-stitching-resolution
The specificati
> @Osamu Watanabe Can you update the patch to make FFMPEG exit when
> encountering an illegal codestream, even if FFMPEG can theoretically
> decode it?
I will update the patch in a few days.
> On Jul 27, 2024, at 6:11, Pierre-Anthony Lemieux wrote:
>
> On Fri, Jul 26, 2024 at 1:04?AM Tomas Har
13 matches
Mail list logo
