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 insertion
> -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
>
> Si
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
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 w
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 in
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:
>
> [trace_he
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 | 3
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
https://ffmpeg.org/mailman/listinfo
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
> Signed
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".
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".
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
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"
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]
---
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 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
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
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 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
> 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
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
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: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 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 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
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
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
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
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
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)
> >
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
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
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
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
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
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
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
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, 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 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 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
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 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
---
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...
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
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
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 91
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/
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
@@
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
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/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/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.
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/svq1dec.c | 82
1 file changed, 38 insertions(+), 44 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/rv40.c | 69 ++-
1 file changed, 32 insertions(+), 37 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/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/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/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/imc.c | 28 +++-
1 file changed, 11 insertions(+), 17 deletions(-)
diff --git a/libavcodec/imc.c b/li
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
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
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
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
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
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
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
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/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 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/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 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/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/speedhqdec.c | 52 -
1 file changed, 26 insertions(+), 26 deletions(-)
diff
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/4xm.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/libavcodec/4xm.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/indeo2.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/indeo2.c b/libavc
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
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
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
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/Makefile | 6 +-
libavcodec/aacdec.c | 8 +--
libavcodec/aacdec_common.c | 119 +++
libavcodec/aacdec_fixed.c| 4 +-
libavcodec/aacdec_template.c | 36 +--
libavcodec/aacdectab.
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
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
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
++
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
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.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/aacdec_common.c
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/
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_
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
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
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 |
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
1 - 100 of 110 matches
Mail list logo
