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 a/libavcodec/vaapi_encode_a
>>> 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
> 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 d
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 ff_v
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 b/li
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 Rh
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 -
libavcodec/mpeg
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 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 b/libavcodec/aacps_c
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 insertions
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 --g
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 r
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(-)
di
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 a/libavcodec/aacdec_
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 a/libavcodec/
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
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 +
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 Rh
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
++
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 float
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 ++-
libavcodec/a
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 +--
libavcodec/aacdectab.
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
--- a/libavcodec/aacps.
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
--- a/li
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 Rh
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 Rh
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
+++ b/libavco
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 b/libavc
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 b/libavc
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 Rh
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(-)
diff
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 b/libav
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 a/
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 b/libavcodec
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 b/libavc
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 b/lib
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 b/libavcodec/m
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 b/libavcod
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
inde
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
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
@@ -2
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
@@ -1
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, eac
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 enjoy
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 b/li
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 a/l
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 a/l
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 a/l
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 a/l
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 a/l
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
--- a/libavcodec/svq1dec.
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 a/l
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
---
libavcodec/msmpeg4_vc1_
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 +++---
libavcodec/mpeg4videodec.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/h261dec.c | 40
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/libav
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 a/libavcodec/f
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 a/l
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
@@
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
@@
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 a/
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 91
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(+),
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
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
> ---
> libavfilter/aarch64/vf_bwdif_init_aarch6
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 ?
>
Hm...
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
---
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
>
On 26/09/2023 10:19, Andreas Rheinhardt wrote:
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 header
Le torstaina 21. syyskuuta 2023, 21.56.52 EEST Michael Niedermayer a écrit :
> Hi
>
> On Thu, Sep 21, 2023 at 05:33:54PM +0100, Kieran Kunhya via ffmpeg-devel
wrote:
> > On Thu, Sep 21, 2023 at 5:21 PM Michael Niedermayer
> >
> > wrote:
> > > OTOH If a majority of people are against the SDR cod
Quoting Michael Niedermayer (2023-09-24 18:45:37)
> > I believe the GA should have sole control and ownership over the domain and
> > trademark. I suggested to kindly ask Fabrice to transfer ownership and/or
> > legal control permanently to a non-profit controlled by and composed of
> > only our GA
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
+li t1, 4
+vsetvli t0, t1, e32, m1, ta, ma
vsetivli t0, 4, ...
But really, DO NOT use a fixed vector length here. At best, you're wasting half
the vector width. Yo
Quoting Kyle Swanson (2023-09-24 10:37:03)
> Hi,
>
> Here are my notes from the VDD meeting. If I missed anything, please feel
> free to send corrections.
Thank you very much for the notes, they are very helpful.
--
Anton Khirnov
___
ffmpeg-devel mail
Le tiistaina 26. syyskuuta 2023, 21.40.12 EEST Paul B Mahol a écrit :
> On Tue, Sep 26, 2023 at 8:35 PM Rémi Denis-Courmont wrote:
> > 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 mne
Andreas Rheinhardt:
> Regression since 4565747056a11356210ed8edcecb920105e40b60.
> Fixes Coverity ticket #1545072.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/evc_ps.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/evc_ps.c b/libavcodec/ev
On Tue, Sep 26, 2023 at 8:35 PM Rémi Denis-Courmont wrote:
> 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 perfo
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 at
Vittorio Giovara (12023-09-26):
> This is not true.
If you say so.
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, vi
On Tue, Sep 26, 2023 at 2:24 PM Nicolas George wrote:
> 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 i
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, the
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 workin
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 no
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 o
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
https://github.com/nokiatech/heif/tree/gh-pages/cont
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 reall
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
> ac
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 SDR
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
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
> 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 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 of
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 pack
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
___
ffmpeg-deve
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 treassure
---
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 a/libavcod
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]
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 function"
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
> th
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".
1 - 100 of 110 matches
Mail list logo
