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.
>
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
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
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 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
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 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-
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 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 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 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
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
---
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 +++
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
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
---
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
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
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
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
---
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
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
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
---
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
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
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.
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
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
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
28 matches
Mail list logo
