From: Zhao Zhili
Signed-off-by: Zhao Zhili
---
libavcodec/v4l2_m2m.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavcodec/v4l2_m2m.c b/libavcodec/v4l2_m2m.c
index 602efb7a16..bac3eb0588 100644
--- a/libavcodec/v4l2_m2m.c
+++ b/libavcodec/v4l2_m2m.c
@@ -255,7 +255,6 @@ static void
On date Monday 2023-12-11 02:35:10 +0100, Clément Bœsch wrote:
> ---
> libavcodec/proresenc_kostya.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c
> index 2d45f9a685..103051830a 100644
> ---
On Wed, 13 Dec 2023, Martin Storsjö wrote:
On Wed, 13 Dec 2023, Rémi Denis-Courmont wrote:
Le tiistaina 12. joulukuuta 2023, 0.14.06 EET Martin Storsjö a écrit :
This can be used to run tests multple times, with e.g. differing
QEMU settings, by adding something like this to the FATE
On Sat, 16 Dec 2023, Rémi Denis-Courmont wrote:
Le perjantaina 15. joulukuuta 2023, 17.38.45 EET Martin Storsjö a écrit :
We can't call ff_get_rv_vlenb() if we don't have RVV available
at all.
Due to the SIGILL signal handler in checkasm catching it, in an
unexpected place, this caused
On Sat, 16 Dec 2023, Rémi Denis-Courmont wrote:
The 8x4 and 4x4 use a needlessly large multiplier (unless/until we care
about embedded 64-bit-vector hardware). This is merely suboptimal.
The 8x4 case also uses an incorrect vector length, which leads to incorrect
behaviour on
On date Monday 2023-12-11 02:35:09 +0100, Clément Bœsch wrote:
> This matches the logic from proresenc_anatoliy.
> ---
> libavcodec/proresenc_kostya.c | 21 ++---
> 1 file changed, 6 insertions(+), 15 deletions(-)
LGTM.
___
ffmpeg-devel
On date Monday 2023-12-11 02:35:08 +0100, Clément Bœsch wrote:
> This is going to be shared with proresenc_kostya in the upcoming commit.
> ---
> libavcodec/proresdata.c | 2 ++
> libavcodec/proresdata.h | 1 +
> libavcodec/proresenc_anatoliy.c | 3 +--
> 3 files changed, 4
On date Monday 2023-12-11 02:35:07 +0100, Clément Bœsch wrote:
> This is already defined in proresdata.h
> ---
> libavcodec/proresenc_anatoliy.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/libavcodec/proresenc_anatoliy.c b/libavcodec/proresenc_anatoliy.c
> index
On date Saturday 2023-12-09 19:12:29 +0100, Stefano Sabatini wrote:
> On date Sunday 2023-12-03 16:05:40 +0100, Stefano Sabatini wrote:
> > On date Thursday 2023-11-30 01:49:13 +0100, Stefano Sabatini wrote:
> > > Generalize drawtext utilities to make them usable in other filters.
> > > This will
On date Thursday 2023-12-14 11:32:44 +0100, Lena wrote:
> Updated the wording of the documentation, and added error checking for strtol.
>
> I looked at how other parts of the codebase check for errors on strtol and
> implemented it that way (iec61883, filter_units_bsf, etc).
>
> As for
The removal of an entry in the middle column left a 'hole'
in the grid.
Container tags shifted to restore alignment.
---
src/consulting | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/consulting b/src/consulting
index 1e205b5..801ea8a 100644
--- a/src/consulting
+++
On date Thursday 2023-12-14 10:35:56 +0100, Nicolas George wrote:
> Anton Khirnov (12023-12-14):
[...]
> > I have to strongly disagree. This is neither practically workable,
> > nor a good goal to aim at.
>
> And I strongly agree with Stefano. Having the tools just thin wrappers
> around the
On 12/16/2023 11:52 AM, Paul B Mahol wrote:
On Sat, Dec 16, 2023 at 3:49 PM James Almer wrote:
On 12/16/2023 11:47 AM, Paul B Mahol wrote:
On Sat, Dec 16, 2023 at 3:45 PM James Almer wrote:
On 12/16/2023 11:43 AM, Paul B Mahol wrote:
On Sat, Dec 16, 2023 at 3:41 PM James Almer wrote:
On Sat, Dec 16, 2023 at 3:49 PM James Almer wrote:
> On 12/16/2023 11:47 AM, Paul B Mahol wrote:
> > On Sat, Dec 16, 2023 at 3:45 PM James Almer wrote:
> >
> >> On 12/16/2023 11:43 AM, Paul B Mahol wrote:
> >>> On Sat, Dec 16, 2023 at 3:41 PM James Almer wrote:
> >>>
> On 12/16/2023 11:34
On 12/16/2023 11:47 AM, Paul B Mahol wrote:
On Sat, Dec 16, 2023 at 3:45 PM James Almer wrote:
On 12/16/2023 11:43 AM, Paul B Mahol wrote:
On Sat, Dec 16, 2023 at 3:41 PM James Almer wrote:
On 12/16/2023 11:34 AM, Paul B Mahol wrote:
Can someone commit this already?
You still have
On Sat, Dec 16, 2023 at 3:45 PM James Almer wrote:
> On 12/16/2023 11:43 AM, Paul B Mahol wrote:
> > On Sat, Dec 16, 2023 at 3:41 PM James Almer wrote:
> >
> >> On 12/16/2023 11:34 AM, Paul B Mahol wrote:
> >>> Can someone commit this already?
> >>
> >> You still have commit rights.
> >>
> >
>
On 12/16/2023 11:43 AM, Paul B Mahol wrote:
On Sat, Dec 16, 2023 at 3:41 PM James Almer wrote:
On 12/16/2023 11:34 AM, Paul B Mahol wrote:
Can someone commit this already?
You still have commit rights.
For web?
Yes, The ssh key you use for ffmpeg.git should work for ffmpeg-web.git
On Sat, Dec 16, 2023 at 3:41 PM James Almer wrote:
> On 12/16/2023 11:34 AM, Paul B Mahol wrote:
> > Can someone commit this already?
>
> You still have commit rights.
>
For web?
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
>
On 12/16/2023 11:34 AM, Paul B Mahol wrote:
Can someone commit this already?
You still have commit rights.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or
Can someone commit this already?
___
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".
---
libavfilter/vf_overlay.c | 260 ---
1 file changed, 53 insertions(+), 207 deletions(-)
diff --git a/libavfilter/vf_overlay.c b/libavfilter/vf_overlay.c
index fa39abb23a..caf0634b51 100644
--- a/libavfilter/vf_overlay.c
+++ b/libavfilter/vf_overlay.c
@@
On 12/16/2023 9:16 AM, Michael Niedermayer wrote:
Fixes: abort()
Fixes:
64232/clusterfuzz-testcase-minimized-ffmpeg_BSF_TRACE_HEADERS_fuzzer-5417957987319808
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
Fixes: signed integer overflow: 2314885530818453536 - -7412889664301817824
cannot be represented in type 'long'
Fixes:
64296/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-6304027146846208
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Fixes: signed integer overflow: 2147478526 + 33924 cannot be represented in
type 'int'
Fixes: shift exponent 32 is too large for 32-bit type 'unsigned int'
Fixes:
64243/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEGLS_fuzzer-5195717848989696
Found-by: continuous fuzzing process
Fixes: Timeout
Fixes:
64220/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP6A_fuzzer-5653856213925888
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
tools/target_dec_fuzzer.c | 1 +
1 file
Fixes: abort()
Fixes:
64232/clusterfuzz-testcase-minimized-ffmpeg_BSF_TRACE_HEADERS_fuzzer-5417957987319808
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/cbs_vp8.c | 4 +++-
1 file changed,
This skips the round-trip to scalar register for the sliding 'x'
coefficients, improving performance by about 5%. The trick here is that
the vector slide-up instruction preserves elements in destination vector
until the slide offset.
The switch from vfslide1up.vf to vslideup.vi also allows the
Here is the msg: "libavfilter/metal/utils.m:35: error: 'MTLGPUFamilyCommon3' is
only available on iOS 13.0"
More Info:
https://developer.apple.com/documentation/metal/mtlgpufamily/mtlgpufamilycommon3
Signed-off-by: xufuji456 <839789...@qq.com>
---
libavfilter/metal/utils.m | 2 +-
1 file
On 2023-12-15 11:46 pm, Michael Niedermayer wrote:
On Fri, Dec 15, 2023 at 12:30:46PM +0530, Gyan Doshi wrote:
During a resampling operation where
1) user has specified first_pts
2) SWR_FLAG_RESAMPLE is not set initially (directly or otherwise)
3) first_pts has been fulfilled (always using
During a resampling operation where
1) user has specified first_pts
2) SWR_FLAG_RESAMPLE is not set initially (directly or otherwise)
3) first_pts has been fulfilled (always using hard compensation)
then upon first encountering a delay where a soft compensation is
required, swr_set_compensation
Le perjantaina 15. joulukuuta 2023, 17.38.45 EET Martin Storsjö a écrit :
> We can't call ff_get_rv_vlenb() if we don't have RVV available
> at all.
>
> Due to the SIGILL signal handler in checkasm catching it, in an
> unexpected place, this caused checkasm to hang instead of reporting
> the
The 8x4 and 4x4 use a needlessly large multiplier (unless/until we care
about embedded 64-bit-vector hardware). This is merely suboptimal.
The 8x4 case also uses an incorrect vector length, which leads to incorrect
behaviour on future/hypothetical hardware with 256-bit or larger vectors.
---
tests/Makefile | 6 +++-
tests/fate/filter-video.mak | 6
tests/maps/fsync-down| 7
tests/maps/fsync-up | 57 +
tests/ref/fate/filter-fsync-down | 12 +++
tests/ref/fate/filter-fsync-up | 62
---
Changelog| 1 +
MAINTAINERS | 1 +
configure| 2 +
doc/filters.texi | 33 +
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/version.h| 2 +-
libavfilter/vf_fsync.c | 286
Synchronize video frames with an external mapping from a file.
Follows up on the idea in
https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-January/305986.html
implemented as a filter.
Not storing the frame map in a probably huge string but buffering
piece-wise. Using a fixed format string.
Am 15.12.23 um 15:17 schrieb Andreas Rheinhardt:
Thilo Borgmann via ffmpeg-devel:
---
Changelog| 1 +
MAINTAINERS | 1 +
doc/filters.texi | 33 +
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/version.h|
36 matches
Mail list logo
