Le lauantaina 23. syyskuuta 2023, 9.49.47 EEST Neal Gompa a écrit :
> On Fri, Sep 22, 2023 at 12:33 PM Michael Niedermayer
>
> wrote:
> > > What does this mean? Does this mean an FFmpeg release containing code
> > > that
> > > interfaces with your SDR library? Or does it mean the library fully
>
This is an option to modify the behaviour of the writer, not a syntax
field.
---
On 26/09/2023 03:34, Wang, Fei W wrote:
On Mon, 2023-09-25 at 14:53 +0100, Mark Thompson wrote:
...
diff --git a/libavcodec/vaapi_encode_av1.c
b/libavcodec/vaapi_encode_av1.c
index 3ff1c47b53..861bf4a13b 100644
---
For lots of static VLCs, the number of bits is not read from
VLC.bits, but rather a compile-constant that is hardcoded
at the callsite of get_vlc2(). Only VLC.table is ever used
and not using it directly is just an unnecessary indirection.
This commit adds helper functions and macros to avoid the
The VLCs, their init code and the tables used for initialization
are currently duplicated for the floating- and fixed-point decoders.
This commit stops doing so and moves this stuff to aacdec_common.c.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/aacdec_common.c | 263
It allows to replace code tables of type uint32_t or uint16_t
by symbols of type uint8_t. It is also faster.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/aacdec_common.c | 377 +++--
1 file changed, 154 insertions(+), 223 deletions(-)
diff --git
Signed-off-by: Andreas Rheinhardt
---
libavcodec/aacpsy.c | 2 +-
libavcodec/aactab.c | 8
libavcodec/aactab.h | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/aacpsy.c b/libavcodec/aacpsy.c
index 933369e445..1fbd259e51 100644
--- a/libavcodec/aacpsy.c
This allows to avoid the relocations inherent in a table
to individual tables; it also reduces padding.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/aacdec_common.c | 59 +++---
1 file changed, 10 insertions(+), 49 deletions(-)
diff --git
For all VLCs here, the number of bits of the VLC is
write-only, because it is hardcoded at the call site.
Therefore one can replace these VLC structures with
the only thing that is actually used: The pointer
to the VLCElem table. And in some cases one can even
avoid this.
Signed-off-by: Andreas
This avoids having to apply it later after every get_vlc2().
Signed-off-by: Andreas Rheinhardt
---
libavcodec/aacdec_common.c | 6 +-
libavcodec/aacsbr.h | 3 ---
libavcodec/aacsbr_template.c | 26 ++
3 files changed, 11 insertions(+), 24 deletions(-)
For all VLCs here, the number of bits of the VLC is
write-only, because it is hardcoded at the call site.
Therefore one can replace these VLC structures with
the only thing that is actually used: The pointer
to the VLCElem table.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/aacdec_common.c
On Tue, 2023-09-26 at 21:30 +0100, Mark Thompson wrote:
> This is an option to modify the behaviour of the writer, not a syntax
> field.
> ---
> On 26/09/2023 03:34, Wang, Fei W wrote:
> > On Mon, 2023-09-25 at 14:53 +0100, Mark Thompson wrote:
> > > ...
> > > diff --git
For all VLCs here, the number of bits of the VLC is
write-only, because it is hardcoded at the call site.
Therefore one can replace these VLC structures with
the only thing that is actually used: The pointer
to the VLCElem table. And in some cases one can even
avoid this.
Signed-off-by: Andreas
Everything besides VLC.table is basically write-only
and even VLC.table can be removed by accessing the
underlying table directly.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/4xm.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/libavcodec/4xm.c
Everything besides VLC.table is basically write-only
and even VLC.table can be removed by accessing the
underlying table directly.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mimic.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/libavcodec/mimic.c
Everything besides VLC.table is basically write-only
and even VLC.table can be removed by accessing the
underlying table directly.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/imm4.c | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git
It is known at compile-time for the vec_entry_vlcs.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mss4.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/libavcodec/mss4.c b/libavcodec/mss4.c
index 0e7cc3e124..8ae4f152c6 100644
--- a/libavcodec/mss4.c
+++
Everything besides VLC.table is basically write-only
and even VLC.table can be removed by accessing the
underlying table directly.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/lagarith.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/lagarith.c
Everything besides VLC.table is basically write-only
and even VLC.table can be removed by accessing the
underlying table directly.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/speedhqdec.c | 52 -
1 file changed, 26 insertions(+), 26 deletions(-)
Everything besides VLC.table is basically write-only
and even VLC.table can be removed by accessing the
underlying table directly.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/indeo2.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/indeo2.c
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> wenbin.chen-at-intel@ffmpeg.org
> Sent: Thursday, September 21, 2023 9:27 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH v2 3/3] libavfilter/dnn: Initialze DNNData
> variables
>
> From: Wenbin Chen
>
>
Attached.
From d0b6b08b38e5f4314f046118bff70d1e08b46bbf Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Tue, 26 Sep 2023 09:37:12 +0200
Subject: [PATCH] avcodec/vlc: fix heap use after free
Signed-off-by: Paul B Mahol
---
libavcodec/vlc.c | 19 ---
1 file changed, 12
Yo,
On Fri, 22 Sep 2023, at 17:27, Paul B Mahol wrote:
>> about it because i did not know anyone else who knows perl and be willing
>> to help look into a not entirely trivial (for me) issue in fate server
>
> Do not lie, [...]
Calling people liars is not really fitting our Code of Conduct.
It's
Of all these VLCs here, only VLC.table was really used
after init, so use the ff_vlc_init_tables API
to get rid of them.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/asvdec.c | 50 ++---
1 file changed, 25 insertions(+), 25 deletions(-)
diff --git
Of all these VLCs here, only VLC.table was really used
after init, so use the ff_vlc_init_tables API
to get rid of them.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/faxcompr.c | 32 ++--
1 file changed, 14 insertions(+), 18 deletions(-)
diff --git
This is especially important for frame-threaded decoders like
this one, because up until now each thread had an identical
copy of all these VLC tables.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vp3.c | 162 +++
1 file changed, 81 insertions(+),
These are quite small and therefore force reloads
that can be avoided by modest increases in the number of bits used.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vp3.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/vp3.c b/libavcodec/vp3.c
index
Of all these VLCs here, only VLC.table was really used
after init, so use the ff_vlc_init_tables API
to get rid of them.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/h264_cavlc.c | 190 +---
1 file changed, 80 insertions(+), 110 deletions(-)
diff --git
Of all these VLCs here, only VLC.table was really used
after init, so use the ff_vlc_init_tables API
to get rid of them.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/h261dec.c | 40
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git
Signed-off-by: Andreas Rheinhardt
---
libavcodec/h264_cavlc.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/libavcodec/h264_cavlc.c b/libavcodec/h264_cavlc.c
index dc22955626..f17e30e853 100644
--- a/libavcodec/h264_cavlc.c
+++ b/libavcodec/h264_cavlc.c
Signed-off-by: Andreas Rheinhardt
---
libavcodec/h264_cavlc.c | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/libavcodec/h264_cavlc.c b/libavcodec/h264_cavlc.c
index f17e30e853..19f067afb4 100644
--- a/libavcodec/h264_cavlc.c
+++ b/libavcodec/h264_cavlc.c
It allows to replace codes of type uint16_t or uint32_t
by symbols of type uint8_t.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/aacps_common.c | 28 ++
libavcodec/aacpsdata.c| 204 +-
2 files changed, 102 insertions(+), 130 deletions(-)
diff
This avoids having to apply it later after every get_vlc2().
Signed-off-by: Andreas Rheinhardt
---
libavcodec/aacps_common.c | 14 +++---
libavcodec/aacpsdata.c| 6 +++---
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/libavcodec/aacps_common.c
For some VLCs here, the number of bits of the VLC is
write-only, because it is hardcoded at the call site.
Therefore one can replace these VLC structures with
the only thing that is actually used: The pointer
to the VLCElem table.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegaudiodata.h
This allows to avoid the relocations inherent in an array
to individual tables; it also reduces padding.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/aacps_common.c | 27 +--
libavcodec/aacpsdata.c| 31 +++
2 files changed, 8
Everything besides VLC.table is basically write-only
and even VLC.table can be removed by accessing the
underlying tables directly.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpeg12.c| 58 +-
libavcodec/mpeg12dec.c | 12 -
For all VLCs here, the number of bits of the VLC is
write-only, because it is hardcoded at the call site.
Therefore one can replace these VLC structures with
the only thing that is actually used: The pointer
to the VLCElem table.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/aacps_common.c |
ff_ps_init() initializes some tables for AAC parametric stereo
and some of them are only valid for the fixed- or floating-point
decoder, whereas others (namely VLCs) are valid for both.
The latter are therefore initialized by ff_ps_init_common()
and because the two versions of ff_ps_init() can be
Andreas Rheinhardt:
> This already avoids unnecessary indirectly included headers
> in the arch-specific vf_bwdif_init.c files; it is also in
> preparation for splitting the actual functions out of vf_bwdif.c.
>
> Signed-off-by: Andreas Rheinhardt
> ---
>
Of all these VLCs here, only VLC.table was really used
after init, so use the ff_vlc_init_tables API
to get rid of them.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/rv40.c | 69 ++-
1 file changed, 32 insertions(+), 37 deletions(-)
diff --git
Of all these VLCs here, only VLC.table was really used
after init, so use the ff_vlc_init_tables API
to get rid of them.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpc7.c | 52 ---
1 file changed, 27 insertions(+), 25 deletions(-)
diff --git
Of all these VLCs here, only VLC.table was really used
after init, so use the ff_vlc_init_tables API
to get rid of them.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/intrax8.c | 46 +++-
1 file changed, 20 insertions(+), 26 deletions(-)
diff --git
It allows to reduce the number of maximum reloads by one.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/svq1dec.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/svq1dec.c b/libavcodec/svq1dec.c
index 372420bffe..af02063a45 100644
---
Of all these VLCs here, only VLC.table was really used
after init, so use the ff_vlc_init_tables API
to get rid of them.
Also combine the ff_msmp4_dc_(luma|chroma)_vlcs as well
as the tables used to generate them to simplify the code.
Signed-off-by: Andreas Rheinhardt
---
Of all these VLCs here, only VLC.table was really used
after init, so use the ff_vlc_init_tables API
to get rid of them.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/h263dec.h | 8 ++---
libavcodec/ituh263dec.c| 68 +++---
Of all these VLCs here, only VLC.table was really used
after init, so use the ff_vlc_init_tables API
to get rid of them.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/svq1dec.c | 82
1 file changed, 38 insertions(+), 44 deletions(-)
diff --git
> On Sep 26, 2023, at 11:14 AM, Anton Khirnov wrote:
>
> From my perspective, the objections to SDR have been largely
> technical,
>From my perspective the objections against the current SDR implementation
>could be grouped into roughly 3 categories:
A) support for taking input from an SDR
For all VLCs here, the number of bits of the VLC is write-only,
because it is hardcoded at the call site. Therefore one can replace
these VLC structures with the only thing that is actually used:
The pointer to the VLCElem table. And in most cases one can even
avoid this.
Signed-off-by: Andreas
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vlc.h | 41 -
1 file changed, 41 deletions(-)
diff --git a/libavcodec/vlc.h b/libavcodec/vlc.h
index 679666801a..0cc106c499 100644
--- a/libavcodec/vlc.h
+++ b/libavcodec/vlc.h
@@ -185,47 +185,6 @@ void
Everything besides VLC.table is basically write-only
and even VLC.table can be removed by accessing the
underlying table directly.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/wmavoice.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/wmavoice.c
Signed-off-by: Andreas Rheinhardt
---
libavcodec/Makefile | 6 +-
libavcodec/aacdec.c | 8 +--
libavcodec/aacdec_common.c | 119 +++
libavcodec/aacdec_fixed.c| 4 +-
libavcodec/aacdec_template.c | 36 +--
They (as well as their init code) are currently duplicated
for the floating- and fixed-point decoders.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/aacdec_common.c | 43
libavcodec/aacdec_template.c | 42 ++-
For all VLCs here, the number of bits of the VLC is write-only,
because it is hardcoded at the call site. Therefore one can replace
these VLC structures with the only thing that is actually used:
The pointer to the VLCElem table. And in some cases one can even
avoid this.
Signed-off-by: Andreas
For all VLCs here, the number of bits of the VLC is
write-only, because it is hardcoded at the call site.
Therefore one can replace these VLC structures with
the only thing that is actually used: The pointer
to the VLCElem table. And in some cases one can even
avoid this.
Signed-off-by: Andreas
The fixed-point decoder actually does not use the floating-point
tables initialized by ff_aac_tableinit() at all. So don't
initialize them for it; instead merge initializing these tables
into ff_aac_float_common_init() which is already the function
for the common static initializations of the
Signed-off-by: Andreas Rheinhardt
---
libavcodec/aacps.h| 3 +--
libavcodec/aacps_common.c | 26 +-
2 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/libavcodec/aacps.h b/libavcodec/aacps.h
index 9d7e79c2b2..c8814b4c3d 100644
---
Signed-off-by: Andreas Rheinhardt
---
libavcodec/aacps.c | 3 +--
libavcodec/aacps.h | 2 +-
libavcodec/aacsbr_template.c | 2 +-
3 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/libavcodec/aacps.c b/libavcodec/aacps.c
index 655e8fe5b4..ed6a3a 100644
---
Hi Michael,
On Tue, Sep 26, 2023 at 7:16 PM Michael Niedermayer
wrote:
> Should i ask the counter-question ?
> are the developers who have less than 10 commits since 2017 abusing
> something
> by organizing and rallying the people against SDR, against the domain owner
> and against me ?
>
For now, this API is supposed to replace all the internal uses
of reference counted objects in libavcodec; "internal" here
means that the object is created in libavcodec and is never
put directly in the hands of anyone outside of it.
It is intended to be made public eventually, but for now
I
These VLCs are very big: The VP3 one have 164382 elements
but due to the overallocation enough memory for 313344 elements
are allocated (1.195 MiB with sizeof(VLCElem) == 4);
for VP4 the numbers are very similar, namely 311296 and 164392
elements. Since 1f4cf92cfbd3accbae582ac63126ed5570ddfd37,
Of all these VLCs here, only VLC.table was really used
after init, so use the ff_vlc_init_tables API
to get rid of them.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/atrac9dec.c | 52 --
1 file changed, 25 insertions(+), 27 deletions(-)
diff --git
Of all these VLCs here, only VLC.table was really used
after init, so use the ff_vlc_init_tables API
to get rid of them.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/clearvideo.c | 74 -
1 file changed, 36 insertions(+), 38 deletions(-)
diff --git
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vp3.c | 61
1 file changed, 31 insertions(+), 30 deletions(-)
diff --git a/libavcodec/vp3.c b/libavcodec/vp3.c
index 1abf7e8078..b7c323b153 100644
--- a/libavcodec/vp3.c
+++ b/libavcodec/vp3.c
@@
Of all these VLCs here, only VLC.table was really used
after init, so use the ff_vlc_init_tables API
to get rid of them.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/imc.c | 28 +++-
1 file changed, 11 insertions(+), 17 deletions(-)
diff --git a/libavcodec/imc.c
>>> 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 you could do the double versions with very little extra
efforts.
okay
>>> But really, DO
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 changed, 18 insertions(+), 23 deletions(-)
diff --git a/libavcodec/mobiclip.c
For most VLCs here, the number of bits of the VLC is
write-only, because it is hardcoded at the call site.
Therefore one can replace these VLC structures with
the only thing that is actually used: The pointer
to the VLCElem table.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/rv34.c | 74
Everything besides VLC.table is basically write-only
and even VLC.table can be removed by accessing the
underlying table directly.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vqcdec.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/libavcodec/vqcdec.c
Everything besides VLC.table is basically write-only
and even VLC.table can be removed by accessing the
underlying table directly.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mv30.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/libavcodec/mv30.c
Said object is only allowed to be modified during its
initialization and is immutable afterwards.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/rv34.c | 5 +++--
libavcodec/rv34.h | 2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavcodec/rv34.c b/libavcodec/rv34.c
Everything besides VLC.table is basically write-only
and even VLC.table can be removed by accessing the
underlying table directly.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/wnv1.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/wnv1.c
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vp3.c | 52
1 file changed, 26 insertions(+), 26 deletions(-)
diff --git a/libavcodec/vp3.c b/libavcodec/vp3.c
index b7c323b153..b11be97fbf 100644
--- a/libavcodec/vp3.c
+++ b/libavcodec/vp3.c
@@
benchmark:
fcmul_add_c: 19.7
fcmul_add_rvv_f32: 6.7
From 6bef2523728a472bb803ce085a1aafdfd624e212 Mon Sep 17 00:00:00 2001
From: h
Date: Tue, 26 Sep 2023 15:03:12 +0800
Subject: [PATCH] af_afir: RISC-V V fcmul_add
fcmul_add_c: 19.7
fcmul_add_rvv_f32: 6.7
---
libavfilter/af_afirdsp.h |
Hi,
Thanks, this looks mostly ok now.
There were a few minor issues left that I can fix up before pushing. There
were a number of cases with register restoring like this:
ldr x30, [sp]
ldp x4, x6, [sp, #16]
ldp x0, x1, [sp, #32]
Mark Thompson:
> This is an option to modify the behaviour of the writer, not a syntax
> field.
> ---
> Tested by hacking av1_metadata. For example, adding:
>
> av_opt_set_int(ctx->common.output->priv_data, "fixed_obu_size_length",
> 7, 0);
>
> gets you OBU headers that look like:
>
>
Paul B Mahol:
> Attached.
>
Michael already sent a less intrusive patch for this:
https://ffmpeg.org/pipermail/ffmpeg-devel/2023-September/314376.html
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
Quoting Michael Niedermayer (2023-09-22 11:27:54)
> The idea was really just, that i said ill include SDR and i want to
> keep this word
Well, you should not have spoken for the entire project without
consulting the rest of the community first. Nobody here is entitled to
decide unilaterally what
James Almer:
> On 9/25/2023 8:55 PM, Andreas Rheinhardt wrote:
>> It is also used by AVCodecContext.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> doc/APIchanges | 3 +++
>> libavcodec/codec_par.h | 10 +-
>> libavcodec/defs.h | 8
>> 3 files changed, 12
Series LGTM.
___
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 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 muxer will not receive a NULL packet in
the write_packet
---
Some patches had inconsistent semicolons when invoking these macros.
By omitting the trailing semicolon in the macro, it requires the
callers to use it consistently.
---
libavcodec/aarch64/hevcdsp_init_aarch64.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
On 7/7/23 02:40, Lynne wrote:
May as well decide on a name in the meanwhile.
Anyone got any suggestions?
___
Has Thomson been used?
https://en.wikipedia.org/wiki/J._J._Thomson
- Leo Izen
___
Quoting Michael Niedermayer (2023-09-26 17:09:47)
> On Tue, Sep 26, 2023 at 11:13:40AM +0200, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2023-09-22 11:27:54)
> > > The idea was really just, that i said ill include SDR and i want to
> > > keep this word
> >
> > Well, you should not have
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 muxer will not receive a NULL
On Tue, Sep 26, 2023 at 11:13:40AM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2023-09-22 11:27:54)
> > The idea was really just, that i said ill include SDR and i want to
> > keep this word
>
> Well, you should not have spoken for the entire project without
> consulting the rest
> Iam part of the community, i would think and for 99% of the tweets made
> on the official twitter account i have never been asked or even had a
> chance to comment before they where made. So what you suggest here is
> "the correct way", has never been applied.
Announcing feature are going to be
On Thu, Sep 14, 2023 at 1:48 AM Michael Niedermayer
wrote:
> Fixes: use after free
> Fixes:
> 62153/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MAGICYUV_fuzzer-4702814909366272
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>
LGTM
___
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".
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 muxer will not receive a NULL packet in
> the write_packet function") it is actually an internal flag
>
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 something owned by a group like that. There needs to be
> an individual like a
On 9/26/2023 4:30 PM, Anton Khirnov wrote:
> This is disingenuous sophistry, and honestly I find it insulting that
> you expect people to swallow it.
I have been pretty silent on list, but as one of the people who has
access to the Twitter account as a delegate (but who was locked out
at the time
On Tue, Sep 26, 2023 at 05:27:23PM +0100, Derek Buitenhuis wrote:
> On 9/26/2023 4:30 PM, Anton Khirnov wrote:
> > This is disingenuous sophistry, and honestly I find it insulting that
> > you expect people to swallow it.
>
> I have been pretty silent on list, but as one of the people who has
>
James Almer (12023-09-26):
> We don't want you to resign anything. We want a proper discussion in how to
> handle SDR, if at all. Pushing it in a form that everyone agrees is not
> ready for upstream is not a good idea.
We can agree on this, if we consider that the opinion on whether it is
ready
Paul B Mahol (12023-09-25):
> [computer@archlinux ffmpeg]$ git sn libavdevice/|grep Paul\ B\ Mahol
~/prog/ffmpeg $ git sn libavformat/|grep Paul\ B\ Mahol
git: 'sn' is not a git command. See 'git --help'.
> I had great plans for libavdevice, but as my proposal to change API was
> rejected I'm
On Tue, Sep 26, 2023 at 05:30:19PM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2023-09-26 17:09:47)
> > On Tue, Sep 26, 2023 at 11:13:40AM +0200, Anton Khirnov wrote:
> > > Quoting Michael Niedermayer (2023-09-22 11:27:54)
> > > > The idea was really just, that i said ill include
They are similar to AVIF images (both use the HEIF container).
The only additional work needed is to parse the hvcC box and put
it in the extradata.
With this patch applied, ffmpeg (when built with an HEVC decoder)
is able to decode the files in
On 9/26/2023 2:16 PM, Michael Niedermayer wrote:
On Tue, Sep 26, 2023 at 05:30:19PM +0200, Anton Khirnov wrote:
Quoting Michael Niedermayer (2023-09-26 17:09:47)
On Tue, Sep 26, 2023 at 11:13:40AM +0200, Anton Khirnov wrote:
Quoting Michael Niedermayer (2023-09-22 11:27:54)
The idea was
Quoting Michael Niedermayer (2023-09-26 19:16:30)
> On Tue, Sep 26, 2023 at 05:30:19PM +0200, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2023-09-26 17:09:47)
> > > On Tue, Sep 26, 2023 at 11:13:40AM +0200, Anton Khirnov wrote:
> > > > Quoting Michael Niedermayer (2023-09-22 11:27:54)
>
Paul B Mahol (12023-09-21):
> If this SDR troll code ever get committed in FFmpeg libraries I will
> immediately leave project.
That would be sad for the project. But I am sorry, I sincerely believe
that if you were to follow through with it, it would be a price worth
paying to have Michael
Anton Khirnov (12023-09-26):
> It is not. From my perspective, the objections to SDR have been largely
> technical
We have not read the same discussion. The objections to SDR start and
end at “it does not belong in FFmpeg”, which is not a technical
objection but an aesthetic one.
Furthermore,
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
Nit: please pad mnemonics to at least 8 columns for consistency.
I'm a bit surprised that the performance improves this much, considering that
the C910 is notoriously bad
1 - 100 of 110 matches
Mail list logo
