Okay, I revert the volatile in ff_read_time
How about this version?
use vls instead vlseg, and use vfmacc
The benchmark is sometimes better, sometimes the same
fcmul_add_c: 3.5
fcmul_add_rvv_f32: 3.5
- af_afir.fcmul_add [OK]
fcmul_add_c: 4.5
fcmul_add_rvv_f32: 4.2
- af_afir.fcmul_add [OK]
On 9/27/2023 7:58 PM, Marton Balint wrote:
On Wed, 27 Sep 2023, James Almer wrote:
Fixes build failures introduced in 7f685d0f49.
Signed-off-by: James Almer
---
doc/filters.texi | 2 ++
1 file changed, 2 insertions(+)
LGTM, thanks.
Marton
Applied.
Michael Niedermayer:
> On Wed, Sep 27, 2023 at 12:17:00AM +0200, Andreas Rheinhardt wrote:
>> Everything besides VLC.table is basically write-only
>> and only VLC.table needs to be retained.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> libavcodec/mobiclip.c | 41
On Wed, Sep 27, 2023 at 12:17:00AM +0200, Andreas Rheinhardt wrote:
> Everything besides VLC.table is basically write-only
> and only VLC.table needs to be retained.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/mobiclip.c | 41 ++---
> 1 file
On Wed, 27 Sep 2023, James Almer wrote:
Fixes build failures introduced in 7f685d0f49.
Signed-off-by: James Almer
---
doc/filters.texi | 2 ++
1 file changed, 2 insertions(+)
LGTM, thanks.
Marton
diff --git a/doc/filters.texi b/doc/filters.texi
index c25450cf6c..a729a08dce 100644
---
Fixes build failures introduced in 7f685d0f49.
Signed-off-by: James Almer
---
doc/filters.texi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/doc/filters.texi b/doc/filters.texi
index c25450cf6c..a729a08dce 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -16837,6 +16837,7 @@
SVT-AV1 does not support requesting keyframes at arbitrary points
by setting pic_type to EB_AV1_KEY_PICTURE.
This patch changes the following:
* Set pic_type to EB_AV1_KEY_PICTURE only when gop_size == 1. This
only has an effect in this case (combined with force_key_frames).
In all other
Hi
On Wed, Sep 27, 2023 at 01:37:40PM +0200, Tomas Härdin wrote:
> fre 2023-09-22 klockan 21:13 +0200 skrev Michael Niedermayer:
> > Suggested-by: Tomas Härdin
> > Fixes: 51896/clusterfuzz-testcase-minimized-ffmpeg_dem_MXF_fuzzer-
> > 5130394286817280
> >
> > Signed-off-by: Michael Niedermayer
Michael Niedermayer (12023-09-27):
> With SDR they do ask for a seperate library.
And they are being dishonest in that. Nothing successful starts as a
library, they start small and grow, and get turned into libraries once
multiple projects can use them.
Demanding you make a separate library and
On Wed, Sep 27, 2023 at 03:53:56PM +0200, Tomas Härdin wrote:
> tis 2023-09-26 klockan 19:16 +0200 skrev Michael Niedermayer:
>
> > Anyway, i appologize for announcing SDR in 6.1. I was too much in
> > love with
> > SDR and how cool it would be ...
>
> This is why I have suggested many times
On 9/27/23, Michael Niedermayer wrote:
> On Wed, Sep 27, 2023 at 03:00:35PM +0200, Paul B Mahol wrote:
>> On Wed, Sep 27, 2023 at 2:57 PM Nicolas George wrote:
>>
>> > Paul B Mahol (12023-09-27):
>> > > I think that having parser is much more useful.
>> >
>> > Having a parser when it can be done
Attached.
From 6b7e51e2b4facead9c45fb94647c85b58e6fdf22 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Wed, 27 Sep 2023 21:48:49 +0200
Subject: [PATCH] avcodec/photocd: allow decoding vlc with errors
Also rename option that no longer works.
Also make tables finding more robust.
Andreas Rheinhardt:
> Fixes a -Wstrict-prototypes warning from Clang 15.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavdevice/fbdev_common.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavdevice/fbdev_common.c b/libavdevice/fbdev_common.c
> index
Andreas Rheinhardt:
> Fixes a -Wunused-but-set-variable from Clang 15.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/error_resilience.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/error_resilience.c b/libavcodec/error_resilience.c
> index
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/jpegxl_parser.c | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/libavcodec/jpegxl_parser.c b/libavcodec/jpegxl_parser.c
> index 6656ed35c5..d25a1b6e1d 100644
> --- a/libavcodec/jpegxl_parser.c
> +++
On Wed, Sep 27, 2023 at 03:56:15PM +0200, Niklas Haas wrote:
> From: Niklas Haas
>
> The spec specifies x^31 + x^3 + 1 as the polynomial, but the diagram in
> Figure 1-1 omits the +1 offset. The initial implementation was based on
> the diagram, but this is wrong (produces subtly incorrect
On Wed, Sep 27, 2023 at 03:00:35PM +0200, Paul B Mahol wrote:
> On Wed, Sep 27, 2023 at 2:57 PM Nicolas George wrote:
>
> > Paul B Mahol (12023-09-27):
> > > I think that having parser is much more useful.
> >
> > Having a parser when it can be done without is a waste of code and
> > resources.
Hi
Ill add a few points to sw/infrastructure point here
On Sun, Sep 24, 2023 at 12:09:38PM +0200, Michael Niedermayer wrote:
[...]
> On Sun, Sep 24, 2023 at 09:37:03AM +0100, Kyle Swanson wrote:
[...]
> > Gitlab (or something like Gitlab)
> > -
> >
> > - Ronald
Hi,
On Mon, Sep 25, 2023 at 9:10 AM Timo Rothenpieler
wrote:
> lgtm
>
Pushed.
Thanks,
Kyle
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
Attached.
From 3e58da932f88e6781eb772d883efa6f0997de936 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Wed, 27 Sep 2023 16:06:02 +0200
Subject: [PATCH 1/4] avutil: add GBRAP14 format support
Signed-off-by: Paul B Mahol
---
libavutil/pixdesc.c | 28
On Wed, 27 Sep 2023, Rémi Denis-Courmont wrote:
It does not make much sense to me, but GCC somehow optimises the
inline assembler way even when the output are very obviously used.
This reverts commit 09731fbfc3a914ec4f6ffad60aa9062db6a8f6aa.
---
libavutil/riscv/timer.h | 4 ++--
1 file changed,
Le tiistaina 26. syyskuuta 2023, 12.24.58 EEST flow gg a écrit :
> benchmark:
> fcmul_add_c: 19.7
> fcmul_add_rvv_f32: 6.7
With optimisations enabled and the benchmarking fix, I get this (on the same
hardware, I believe):
fcmul_add_c: 3.5
fcmul_add_rvv_f32: 6.7
For sure unfortunate design
Le keskiviikkona 27. syyskuuta 2023, 4.47.26 EEST flow gg a écrit :
> >>> please pad mnemonics to at least 8 columns for consistency
>
> okay, changed
>
> >>> It seems that you could just as well use vlseg2 without register
>
> stride, no?
>
> yes, vlseg will better, changed
>
> >>> Note that
It does not make much sense to me, but GCC somehow optimises the
inline assembler way even when the output are very obviously used.
This reverts commit 09731fbfc3a914ec4f6ffad60aa9062db6a8f6aa.
---
libavutil/riscv/timer.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Le keskiviikkona 27. syyskuuta 2023, 4.47.26 EEST flow gg a écrit :
> ```
> tests/checkasm/checkasm --bench --test=aacpsdsp
> tests/checkasm/checkasm --bench --test=alacdsp
> tests/checkasm/checkasm --bench --test=audiodsp
> tests/checkasm/checkasm --bench --test=g722dsp
> tests/checkasm/checkasm
Context: I compared our implementation against a H.274 reference stream.
Identified this issues as a result.
This is still not bit-exact, we round incorrectly in some cases (~2% of
output pixels are +1 or -1). I'm not sure where we pick up the remaining
error from..
From: Niklas Haas
Either the average, or the sum right-shifted. Not the average
right-shifted.
---
libavcodec/h274.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/h274.c b/libavcodec/h274.c
index 2388826d547..a5caf09564d 100644
--- a/libavcodec/h274.c
+++
From: Niklas Haas
The spec specified indices in the order [x][y], but our code follows the
traditional C convention of [y][x]. This was not correctly account for
when calculating the base index of the grain database access.
---
libavcodec/h274.c | 8
1 file changed, 4 insertions(+), 4
From: Niklas Haas
The spec specifies x^31 + x^3 + 1 as the polynomial, but the diagram in
Figure 1-1 omits the +1 offset. The initial implementation was based on
the diagram, but this is wrong (produces subtly incorrect results).
---
libavcodec/h274.c | 2 +-
1 file changed, 1 insertion(+), 1
tis 2023-09-26 klockan 19:16 +0200 skrev Michael Niedermayer:
> Anyway, i appologize for announcing SDR in 6.1. I was too much in
> love with
> SDR and how cool it would be ...
This is why I have suggested many times that you should get involved in
actual SDR projects. For example the FreeDV
On Wed, Sep 27, 2023 at 6:01 AM Michael Niedermayer
wrote:
> What we have currently is not a king making decissions.
> What we have currently is the founder having a final (very difficult to
> use)
> veto power to prevent something catastrophic
>
This is basically saying that you don't trust
sön 2023-09-24 klockan 09:37 +0100 skrev Kyle Swanson:
> Gitlab (or something like Gitlab)
> -
> - J-B recommends against gitea, suggesting that we piggyback on the
> videolan Gitlab experience infra.
As someone who's tried to maintain a Gitlab instance I can
Signed-off-by: James Almer
---
libavcodec/avcodec.h | 2 +-
libavcodec/decode.c | 10 ++
libavcodec/decode.h | 3 +++
libavcodec/hevcdec.c | 15 ++-
4 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index
This is no longer needed as the side data is available for decoders in the
AVCodecContext.
Signed-off-by: James Almer
---
fftools/ffplay.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index e29b0ad0f9..87e04226c9 100644
--- a/fftools/ffplay.c
+++
Signed-off-by: James Almer
---
fftools/ffprobe.c | 30 ++
1 file changed, 14 insertions(+), 16 deletions(-)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index c20f464623..d5415be61a 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -2279,16 +2279,9 @@
This is no longer needed as the side data is available for decoders in the
AVCodecContext.
The tests affected reflect the removal of useless CPB and Stereo 3D side
data in packets.
Signed-off-by: James Almer
---
fftools/ffmpeg_demux.c| 22 ---
Signed-off-by: James Almer
---
fftools/ffplay.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 006da7ab57..e29b0ad0f9 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -1916,8 +1916,13 @@ static int
Signed-off-by: James Almer
---
libavcodec/decode.c | 48 +
1 file changed, 40 insertions(+), 8 deletions(-)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index a7196b5740..3b4bb70689 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
Signed-off-by: James Almer
---
fftools/ffmpeg_demux.c| 12
fftools/ffmpeg_enc.c | 31 +--
fftools/ffmpeg_filter.c | 6 +-
fftools/ffmpeg_mux_init.c | 21 -
4 files changed, 34 insertions(+), 36 deletions(-)
diff --git
Explaining what or who may use it, and in what scenarios.
Signed-off-by: James Almer
---
libavcodec/packet.h | 15 +++
1 file changed, 15 insertions(+)
diff --git a/libavcodec/packet.h b/libavcodec/packet.h
index 96fc0084d6..f88dad2b3c 100644
--- a/libavcodec/packet.h
+++
Deprecate AVStream.side_data and its helpers in favor of the AVStream's
codecpar.side_data.
This will considerably simplify the propagation of global side data to decoders
and from encoders. Instead of having to do it inside packets, it will be
available during init().
Global and frame specific
This will simplify the propagation of side data to decoders and from encoders.
Global side data will now reside in the AVCodecContext, thus be available
during init(), removing the need to propagate it inside packets.
Global and frame specific side data will therefore be distinct.
Signed-off-by:
Handling AVPacketSideData directly, which can used on structs other than
AVPacket.
This will be useful in the following commits.
Signed-off-by: James Almer
---
libavcodec/avpacket.c | 99 +++
libavcodec/packet.h | 96
Changes since the previous version:
- Removed AVPacketSideDataSet altogheter. Array and size fields now reside
without being wrapped. Helpers now take pointer to array of side data and
pointer to size as input/output arguments.
- Added some description for AVPacketSideData and where the API
On Wed, Sep 27, 2023 at 3:04 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Nicolas George:
> > Andreas Rheinhardt (12023-09-27):
> >> Then you could simply reuse the code inside libavformat.
> >
> > Do you finally support merging the libraries then?
> >
> > Because otherwise,
ons 2023-09-27 klockan 14:59 +0200 skrev Paul B Mahol:
> On Wed, Sep 27, 2023 at 2:57 PM Tomas Härdin wrote:
>
> > ons 2023-09-27 klockan 14:56 +0200 skrev Paul B Mahol:
> > > On Wed, Sep 27, 2023 at 2:55 PM Tomas Härdin
> > > wrote:
> > >
> > > > Needs a FATE test.
> > > >
> > > >
> > >
Nicolas George:
> Andreas Rheinhardt (12023-09-27):
>> Then you could simply reuse the code inside libavformat.
>
> Do you finally support merging the libraries then?
>
> Because otherwise, using from libavformat code for an individual
> component of libavcodec requires adding a new avpriv
On Wed, Sep 27, 2023 at 2:57 PM Nicolas George wrote:
> Paul B Mahol (12023-09-27):
> > I think that having parser is much more useful.
>
> Having a parser when it can be done without is a waste of code and
> resources.
>
I already wrote that parser is useful addition. Mainly because of many
On Wed, Sep 27, 2023 at 2:57 PM Nicolas George wrote:
> Paul B Mahol (12023-09-27):
> > I think that having parser is much more useful.
>
> Having a parser when it can be done without is a waste of code and
> resources.
>
> Do not push like that.
>
As you never pushed anything marginally useful
On Wed, Sep 27, 2023 at 2:57 PM Tomas Härdin wrote:
> ons 2023-09-27 klockan 14:56 +0200 skrev Paul B Mahol:
> > On Wed, Sep 27, 2023 at 2:55 PM Tomas Härdin wrote:
> >
> > > Needs a FATE test.
> > >
> > >
> > Feel free to upload sample(s).
>
> Don't have any. But I presume you do. Also wasn't
Andreas Rheinhardt (12023-09-27):
> Then you could simply reuse the code inside libavformat.
Do you finally support merging the libraries then?
Because otherwise, using from libavformat code for an individual
component of libavcodec requires adding a new avpriv function.
Regards,
--
Nicolas
ons 2023-09-27 klockan 14:56 +0200 skrev Paul B Mahol:
> On Wed, Sep 27, 2023 at 2:55 PM Tomas Härdin wrote:
>
> > Needs a FATE test.
> >
> >
> Feel free to upload sample(s).
Don't have any. But I presume you do. Also wasn't it decided that new
formats/codecs mustn't be added without tests?
Paul B Mahol (12023-09-27):
> I think that having parser is much more useful.
Having a parser when it can be done without is a waste of code and
resources.
Do not push like that.
--
Nicolas George
___
ffmpeg-devel mailing list
On Wed, Sep 27, 2023 at 2:55 PM Tomas Härdin wrote:
> Needs a FATE test.
>
>
Feel free to upload sample(s).
> /Tomas
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe,
Needs a FATE test.
/Tomas
___
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".
On Wed, Sep 27, 2023 at 2:51 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Paul B Mahol:
> > On Sun, Sep 24, 2023 at 2:04 AM Andreas Rheinhardt <
> > andreas.rheinha...@outlook.com> wrote:
> >
> >> Paul B Mahol:
> >>>
> >>> +if (!qoa->frame_size) {
> >>> +
Paul B Mahol:
> On Sun, Sep 24, 2023 at 2:04 AM Andreas Rheinhardt <
> andreas.rheinha...@outlook.com> wrote:
>
>> Paul B Mahol:
>>>
>>> +if (!qoa->frame_size) {
>>> +for (; i < buf_size; i++) {
>>> +state = (state << 8) | buf[i];
>>> +if
On Sun, Sep 24, 2023 at 2:50 AM Paul B Mahol wrote:
>
> New patches.
>
Will apply.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
fre 2023-09-22 klockan 21:13 +0200 skrev Michael Niedermayer:
> Suggested-by: Tomas Härdin
> Fixes: 51896/clusterfuzz-testcase-minimized-ffmpeg_dem_MXF_fuzzer-
> 5130394286817280
>
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/mxfdec.c | 28 ++--
> 1 file
On Wed, 27 Sep 2023 12:20:37 +0200 Andreas Rheinhardt
wrote:
> Why is this a separate function and not just a new parameter to
> ff_icc_profile_read_primaries() given that these seem to always be used
> a pair?
Because it mutates the profile. It seems strange to me for a function
named
Niklas Haas:
> From: Niklas Haas
>
> Buggy ICCv4 profiles are unfortunately used in the wild, and it's quite
> easy to work around them by just forcing the white point to the correct
> value. Display a warning just in case.
>
> See-Also: https://trac.ffmpeg.org/ticket/9673
> ---
>
Quoting Niklas Haas (2023-09-27 12:03:52)
> +static av_always_inline AVRational av_abs_q(AVRational q)
> +{
> +if (q.num < 0)
> +q.num = -q.num;
> +return q;
What if q.num > 0 and q.den < 0.
--
Anton Khirnov
___
ffmpeg-devel mailing
From: Niklas Haas
Fixes: https://trac.ffmpeg.org/ticket/9673
---
libavcodec/decode.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 466c393c1e2..6f4ef7da0c2 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@
From: Niklas Haas
---
libavfilter/vf_iccdetect.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavfilter/vf_iccdetect.c b/libavfilter/vf_iccdetect.c
index 5288b0320d2..16eacbbb560 100644
--- a/libavfilter/vf_iccdetect.c
+++ b/libavfilter/vf_iccdetect.c
@@ -93,7 +93,9
From: Niklas Haas
---
libavutil/csp.c | 23 ---
1 file changed, 8 insertions(+), 15 deletions(-)
diff --git a/libavutil/csp.c b/libavutil/csp.c
index 7ef822c60bc..655a8d6 100644
--- a/libavutil/csp.c
+++ b/libavutil/csp.c
@@ -100,13 +100,6 @@ const AVColorPrimariesDesc
From: Niklas Haas
Buggy ICCv4 profiles are unfortunately used in the wild, and it's quite
easy to work around them by just forcing the white point to the correct
value. Display a warning just in case.
See-Also: https://trac.ffmpeg.org/ticket/9673
---
libavcodec/fflcms2.c | 45
From: Niklas Haas
Seems like an obvious utility function to be missing, and useful in at
least several places in the code.
---
doc/APIchanges | 3 +++
libavutil/rational.h | 12
libavutil/version.h | 2 +-
3 files changed, 16 insertions(+), 1 deletion(-)
diff --git
Concludes the discussion from https://trac.ffmpeg.org/ticket/9673
It was found that at least one widely-used ICCv4 profile found in the
wild contains broken tagging which violates the ICCv4 specification. It
seems that lcms2 gets confused by this wrong tag and returns wrong
values for this
On Tue, Sep 26, 2023 at 03:21:49PM +0200, Ronald S. Bultje wrote:
> Hi Michael,
>
> On Sun, Sep 24, 2023 at 6:45 PM Michael Niedermayer
> wrote:
>
> > I disagree
> > * Who is and is not a member of the GA is in flux, there can be disputes
> > even on GA membership.
> > * You cannot have
On Tue, 26 Sep 2023, Andreas Rheinhardt wrote:
Martin Storsjö:
On Tue, 26 Sep 2023, Anton Khirnov wrote:
Quoting Andreas Rheinhardt (2023-09-26 01:54:30)
It is of no value to the user, because every muxer can always
be flushed with a NULL packet. As its documentation shows
("If not set, the
70 matches
Mail list logo
