Le 27 août 2024 03:03:37 GMT+03:00, Marton Balint a écrit :
>Using INFINITY can cause issues with -ffast-math, and since we only use this
>value to decide the formatting, we can just as easily use 0 for log10 of zero.
FFmpeg does not enable fast-math and last I tried it won't work at all anyway
Using INFINITY can cause issues with -ffast-math, and since we only use this
value to decide the formatting, we can just as easily use 0 for log10 of zero.
Signed-off-by: Marton Balint
---
libavutil/timestamp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/timesta
If the demuxer does not provide per-stream indexes, the generic seek search can
attempt to read the whole media file from the beginning when seeking. For large
MXF files this can cause huge lockups for a seek after the last timestamp,
which will eventually fail. So let's disable the generic seek fo
On Thu, 8 Aug 2024, Michael Niedermayer wrote:
On Wed, Aug 07, 2024 at 09:03:01AM +0200, Stefano Mandelli wrote:
Recently, I have been experiencing an increasing number
of user that use ffmpeg to retrive RTSP stream from
personal mediaproxies (e.g. MediaMtx) with
authorization based on JWT.
Fixes ticket #11134.
Signed-off-by: Marton Balint
---
libavformat/libzmq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/libzmq.c b/libavformat/libzmq.c
index f4bb849e46..da84efee73 100644
--- a/libavformat/libzmq.c
+++ b/libavformat/libzmq.c
@@ -94,7 +94,7 @@ s
---
libavcodec/dnxucdec.c | 179 --
1 file changed, 102 insertions(+), 77 deletions(-)
diff --git a/libavcodec/dnxucdec.c b/libavcodec/dnxucdec.c
index de9e06f..74369db 100644
--- a/libavcodec/dnxucdec.c
+++ b/libavcodec/dnxucdec.c
@@ -29,7 +29,7 @@
short
This version doesn't only fix the trivial platform specific _Float16 issue and
some
cosmetic cleanup but also corrects a few bitpack alignment issues affecting the
10 and 12bit decoders of my first patch...
---
Changelog | 1 +
doc/general_contents.texi | 1 +
libavcodec/Make
RISC-V stuff looks OK (did not test though).
--
雷米‧德尼-库尔蒙
http://www.remlab.net/
___
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...@ffmp
---
libavfilter/vf_libvmaf.c | 328 ++-
1 file changed, 326 insertions(+), 2 deletions(-)
diff --git a/libavfilter/vf_libvmaf.c b/libavfilter/vf_libvmaf.c
index f655092b20..e6707aff53 100644
--- a/libavfilter/vf_libvmaf.c
+++ b/libavfilter/vf_libvmaf.c
@@ -27,8
This patch adds metadata propagation support to vf_libvmaf filter
according to changes in libvmaf library. For test you should set
vmaf_version < 3.0.0 in filter.
changes since v1:
- Fixed sync issue (Was the main problem of first version).
- Added inline explanation.
Yigithan Yigit (1):
avfil
Hi and thanks for taking a look at this!
> maybe you can add a fate test
I understand my colleague (who supports me on this) right, he's still looking
into how to do that.
But to have some quick progress on your other comments:
> libavfilter/vf_xpsnr.c:38:10: fatal error: internal.h: No such fi
ons 2024-08-21 klockan 23:19 +0200 skrev Marton Balint:
>
>
> 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
---
libavcodec/aarch64/mpegvideoencdsp_init.c | 6 ++---
libavcodec/aarch64/mpegvideoencdsp_neon.S | 9 +++
libavcodec/arm/mpegvideoencdsp_init_arm.c | 4 +--
libavcodec/mips/h263dsp_mips.h| 2 +-
libavcodec/mips/mpegvideoencdsp_msa.c | 2 +-
libavcodec/mpegvideoencdsp.c
From: Zhao Zhili
---
libavfilter/vf_unsharp.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/libavfilter/vf_unsharp.c b/libavfilter/vf_unsharp.c
index 52b2ab8d44..b5dd468b6f 100644
--- a/libavfilter/vf_unsharp.c
+++ b/libavfilter/vf_unsharp.c
@@ -74,7 +74,6 @@ typedef
On Mon, Aug 26, 2024 at 01:59:32PM +0200, Anton Khirnov wrote:
> Quoting Zhao Zhili (2024-08-26 13:52:41)
> >
> >
> > > On Aug 24, 2024, at 22:40, Matthieu Bouron
> > > wrote:
> > >
> > > ---
> > >
> > > Diff with the v1:
> > > - dropped support of ENCODING_PCM_24BIT_PACKED as it uses 3 conse
---
Diff with v2:
- Dropped flac/vorbis/opus support
---
configure | 8 +
libavcodec/Makefile | 4 +
libavcodec/allcodecs.c| 4 +
libavcodec/mediacodecdec.c| 102 -
libavcodec/mediacodecdec_common.c | 333 +++
Quoting Zhao Zhili (2024-08-26 13:52:41)
>
>
> > On Aug 24, 2024, at 22:40, Matthieu Bouron
> > wrote:
> >
> > ---
> >
> > Diff with the v1:
> > - dropped support of ENCODING_PCM_24BIT_PACKED as it uses 3 consecutive
> > bytes
> > for one sample and there is no direct AVSampleFormat equival
> On Aug 24, 2024, at 22:40, Matthieu Bouron wrote:
>
> ---
>
> Diff with the v1:
> - dropped support of ENCODING_PCM_24BIT_PACKED as it uses 3 consecutive bytes
> for one sample and there is no direct AVSampleFormat equivalent (that would
> require a dedicated copy routine to copy the 3 by
On Thu, Aug 22, 2024 at 1:29 PM Ramiro Polla wrote:
> On Wed, Aug 21, 2024 at 9:44 PM Martin Storsjö wrote:
> > 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 w
On Thu, Aug 22, 2024 at 1:33 PM Ramiro Polla wrote:
> On Wed, Aug 21, 2024 at 4:56 PM Ramiro Polla wrote:
> > 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:
On Sat, Aug 24, 2024 at 1:50 AM Michael Niedermayer
wrote:
> On Wed, Aug 21, 2024 at 04:55:49PM +0200, Ramiro Polla wrote:
> > ---
> > libavcodec/x86/mpegvideoencdsp_init.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
>
> LGTM
Pushed.
__
On Sun, Aug 25, 2024 at 7:52 PM J. Dekker wrote:
> On Thu, Aug 22, 2024, at 16:57, Ramiro Polla wrote:
> > On Wed, Aug 21, 2024 at 1:26 PM J. Dekker wrote:
> >>
> >> Port dav1d's checkasm output format to FFmpeg's checkasm, includes
> >> relative speedups and aligns results.
> >>
> >> Signed-off-
fre 2024-08-23 klockan 10:14 +0200 skrev Nicolas Gaullier:
> The time_base was a bad guess.
>
> Currently, fate-time_base test data assumed that overriding the input
> time_base would affect the frame_rate, but this behaviour is not
> documented, so just fix the fate data now that this is fixed.
>
On Thu, Aug 22, 2024 at 1:11 PM Ramiro Polla wrote:
> On Fri, Aug 16, 2024 at 12:58 PM Martin Storsjö wrote:
> > On Thu, 15 Aug 2024, Ramiro Polla wrote:
> > > Thank you for the review. New patch attached.
> >
> > Thanks - this looks very straightforward and nice now! Just one minor nit
> > below
On Sat, Aug 24, 2024 at 1:06 PM Stefan Oltmanns via ffmpeg-devel
wrote:
> Am 23.08.24 um 14:25 schrieb Ramiro Polla:
> >
> > I finally managed to test the patches on a real Windows system.
> >
> > They both look good to me, I'll apply them in a couple of days if
> > there are no other comments.
A
On Thu, Aug 22, 2024 at 2:06 PM Martin Storsjö wrote:
> On Thu, 22 Aug 2024, Ramiro Polla wrote:
>
> > ---
> > libavutil/aarch64/intreadwrite.h | 42
> > libavutil/intreadwrite.h | 4 ++-
> > 2 files changed, 45 insertions(+), 1 deletion(-)
> > create mode 1
Bumping up for visibility for review.
On Sat, Aug 24, 2024 at 12:46 AM Rajiv Harlalka
wrote:
> Adds the PU21 encoding filter for high dynamic range images and video
> quality assessment
> Mantiuk, R., & Azimi, M. PU21: A novel perceptually uniform encoding
> for adapting existing quality metrics
Yes, it is related to the potential problem.
The problem may be here:
https://github.com/FFmpeg/FFmpeg/blob/40dda881d6ad761b4589c3078b925e0d849546b3/libavcodec/jpeg2000dec.c#L2139
Shifting down by 16 bits here is too much because it will cancel the value of
"1" (=0.5) below the binary point.
>
28 matches
Mail list logo
