Andreas Rheinhardt (12022-09-12):
> Signed-off-by: Andreas Rheinhardt
> ---
> libavfilter/avfilter.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
Series should be ok.
Regards,
--
Nicolas George
___
ffmpeg-devel mailing lis
On 9/12/22, Paul B Mahol wrote:
> Patch attached.
>
> How to get more speed?
>
Thanks for review, updated patch attached.
From 2a5bab90b863c7cc9dbbb4d3d3021bec8ab09843 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Mon, 12 Sep 2022 18:53:31 +0200
Subject: [PATCH] avcodec/x86/audiodsp: add sca
Paul B Mahol:
>
> +INIT_YMM avx2
> +cglobal scalarproduct_int16, 3,3,2, v1, v2, order
> +add orderd, orderd
> +add v1q, orderq
> +add v2q, orderq
> +neg orderq
> +pxorm1, m1
> +.loop:
> +movum0, [v1q + orderq]
> +pmaddwd m0, [v2q + orderq]
> +paddd m1, m0
On 9/8/22, Paul B Mahol wrote:
> Patch attached.
>
Will apply soon.
___
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 s
Wujian(Chin):
> Signed-off-by: wujian_nanjing
> ---
> libavcodec/avpacket.c | 44
> libavcodec/packet.h | 17 +
> libavformat/demux.c | 7 +++
> libavformat/rtpdec.c | 37 -
> 4 files change
On 9/13/22, Paul B Mahol wrote:
> On 9/12/22, Paul B Mahol wrote:
>> Patch attached.
>>
>> How to get more speed?
>>
>
> Thanks for review, updated patch attached.
>
Fixed patch from Andreas review attached.
From aa3cbb9d792d18c1756d00138925382eab924804 Mon Sep 17 00:00:00 2001
From: Paul B Maho
Possible since 81d070dd09ce154d635414fd07d80a591266b421.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/dolby_e_parser.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavcodec/dolby_e_parser.c b/libavcodec/dolby_e_parser.c
index 9f54627356..d2566e5446 100644
--- a/libavcodec/dolby_e_p
In reality, the bit allocation VLCs do not use the same number
of bits at all.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/dcahuff.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavcodec/dcahuff.c b/libavcodec/dcahuff.c
index 8d5541f9d0..d1b64798ab 100644
--- a/libavcodec/dcahuff.c
Signed-off-by: Andreas Rheinhardt
---
libavcodec/dcahuff.c | 30 ++
1 file changed, 10 insertions(+), 20 deletions(-)
diff --git a/libavcodec/dcahuff.c b/libavcodec/dcahuff.c
index d1b64798ab..9b809cc415 100644
--- a/libavcodec/dcahuff.c
+++ b/libavcodec/dcahuff.c
@@
The ff_dca_vlc_transition_mode VLCs don't use an offset at all,
so just use ordinary VLCs for them.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/dca_core.c | 3 ++-
libavcodec/dcahuff.c | 8 +++-
libavcodec/dcahuff.h | 2 +-
3 files changed, 6 insertions(+), 7 deletions(-)
diff --git
It increases the size of one VLC from two to three bits, thereby
requiring four more VLCEntries (16 bytes .bss), but it allows to
inline the number of bits used when reading them.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/dca_core.c | 2 +-
libavcodec/dcahuff.c | 5 ++---
libavcodec/dcah
Signed-off-by: Andreas Rheinhardt
---
libavcodec/dca_core.c | 2 +-
libavcodec/dca_lbr.c | 4 ++--
libavcodec/dcahuff.c | 45 ---
libavcodec/dcahuff.h | 1 -
4 files changed, 24 insertions(+), 28 deletions(-)
diff --git a/libavcodec/dca_core.c b/liba
Up until now, initializing the dca VLC tables uses ff_init_vlc_sparse()
with length tables of type uint8_t and code tables of type uint16_t
(except for the LBR tables, which uses length and symbols of type
uint8_t; these tables are interleaved). In case of the quant index
codebooks these arrays wer
Signed-off-by: Andreas Rheinhardt
---
libavcodec/dca_core.c | 6 --
libavcodec/dcahuff.c | 7 +++
libavcodec/dcahuff.h | 3 ++-
3 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/libavcodec/dca_core.c b/libavcodec/dca_core.c
index 96787fe95d..7dff6633df 100644
--- a/libavcod
Most of the VLCs used here have a max_depth of two;
some have a max_depth of one. Therefore one can just use two
and avoid the runtime check for whether one should
perform another round of LUT lookup in case the first read
did not read a complete codeword.
Signed-off-by: Andreas Rheinhardt
---
l
This is possible now that the offsets are already applied
when creating the VLC.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/dca_core.c | 10 +-
libavcodec/dcahuff.c | 13 +
libavcodec/dcahuff.h | 9 ++---
3 files changed, 12 insertions(+), 20 deletions(-)
diff -
The code to initialize it takes more space (in .text) than
the table to be initialized (namely 86B vs 64B for GCC 11.2
with -O3 in an av_cold function), so hardcode the table.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/dca_lbr.c | 15 +++
1 file changed, 11 insertions(+), 4 del
Signed-off-by: Andreas Rheinhardt
---
libavcodec/dca_lbr.c | 31 ---
libavcodec/dcahuff.c | 24
libavcodec/dcahuff.h | 11 +++
3 files changed, 39 insertions(+), 27 deletions(-)
diff --git a/libavcodec/dca_lbr.c b/libavcodec/dca_lbr.c
Up until now, the encoder used the same tables that the decoder
uses to create its VLCs. These have the downside of requiring
the encoder to offset the tables at runtime as well as having
to read from separate tables for the length as well as the code
of the symbol to encode. The former are uint8_t
On 9/11/22, Li-Heng Chen wrote:
> When input is video bitstream (e.g. *.264) with framerate set by -r,
> ist->pts could be a nonsense value.
>
> In libavfilter/vf_fps, the pts value of EOF from above is compared to pts
> derived from inlink. The wrong EOF pts may trigger a bug, where ffmpeg keeps
Patch attached
From fce08a8582169c44dc3a08a956897ccb36731822 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Tue, 13 Sep 2022 14:38:18 +0200
Subject: [PATCH] avcodec/tak*: use cached bitstream reader on !x86_32
Increases single thread decoding speed in one example from 85x to 90x
Signed-off-by
From: Rémi Denis-Courmont
INT_MAX is (typically) a value with 31 significant bits but float can
only represent 23 significant bits, leading to a rounding error.
This substitutes the actual rounded value to avoid a clang warning:
warning: implicit conversion from 'int' to 'float' changes value
r...@remlab.net:
> From: Rémi Denis-Courmont
>
> INT_MAX is (typically) a value with 31 significant bits but float can
> only represent 23 significant bits, leading to a rounding error.
>
> This substitutes the actual rounded value to avoid a clang warning:
>
> warning: implicit conversion fro
Le tiistaina 13. syyskuuta 2022, 18.11.35 EEST Andreas Rheinhardt a écrit :
> r...@remlab.net:
> > From: Rémi Denis-Courmont
> >
> > INT_MAX is (typically) a value with 31 significant bits but float can
> > only represent 23 significant bits, leading to a rounding error.
> >
> > This substitutes
Rémi Denis-Courmont:
> Le tiistaina 13. syyskuuta 2022, 18.11.35 EEST Andreas Rheinhardt a écrit :
>> r...@remlab.net:
>>> From: Rémi Denis-Courmont
>>>
>>> INT_MAX is (typically) a value with 31 significant bits but float can
>>> only represent 23 significant bits, leading to a rounding error.
>>
From: Rémi Denis-Courmont
INT_MAX is (typically) a value with 31 significant bits but float can
only represent 23 significant bits, leading to a rounding error.
This substitutes the actual rounded value as an unsigned int,
to avoid a clang warning while not overflowing signed int:
warning: imp
From: Rémi Denis-Courmont
Even though they have the same size, and typically the same alignment,
uint32_t and float are under no circumstances compatible types in C.
The casts from float * to uint32_t * are invalid here. Insofar as the
resulting pointers are dereferenced, this is undefined behav
r...@remlab.net:
> From: Rémi Denis-Courmont
>
> Even though they have the same size, and typically the same alignment,
> uint32_t and float are under no circumstances compatible types in C.
>
> The casts from float * to uint32_t * are invalid here. Insofar as the
> resulting pointers are derefe
From: Rémi Denis-Courmont
Even though they have the same size, and typically the same alignment,
uint32_t and float are under no circumstances compatible types in C.
The casts from float * to uint32_t * are invalid here. Insofar as the
resulting pointers are dereferenced, this is undefined behav
On Tue, Sep 13, 2022 at 11:28 AM Paul B Mahol wrote:
> On 9/8/22, Paul B Mahol wrote:
> > Patch attached.
> >
>
> Will apply soon.
Curious where the 1 << 28 constant come from?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/
If a key already exists in an AVDictionary and the AV_DICT_APPEND flag
is set, the old entry is at first discarded from the dictionary, but
a pointer to the value is kept. Lateron enough memory to store the
appended string is allocated; should this allocation fail, the old string
is not freed and h
When appending two values (due to AV_DICT_APPEND), the earlier code
would first zero-allocate a buffer of the required size and then
copy both parts into it via av_strlcat(). This is problematic,
as it leads to quadratic performance in case of frequent enlargements.
Fix this by using av_realloc() (
We know that an AVDictionary is not empty if we have just added
an entry to it, so only check for it being empty on the branch
that does not do so.
Signed-off-by: Andreas Rheinhardt
---
libavutil/dict.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavutil/dict.c
On 9/13/22, Andreas Rheinhardt wrote:
> We know that an AVDictionary is not empty if we have just added
> an entry to it, so only check for it being empty on the branch
> that does not do so.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavutil/dict.c | 8
> 1 file changed, 4 inserti
On 11.09.2022 09:28, Roman Arzumanyan wrote:
Thanks for the detailed review, Timo.
Please find fixed patch in attachement.
I've renamed the filter to colorspace_cuda, did some super minor
stylistic fixes and applied the patch.
Works as I would expect. Obviously it's super limited in what it
Mantissas are the last data in the channel subsegment and it appears it is
sometimes missing a very few bits for the parsing to complete.
This should not be confused with data corruption.
For 5.1+2@25fps, the occurence of this issue is pretty steady and about once
every 2 hours.
The truncation is
this maps to the vpxenc argument with the same name and the
VP9E_SET_MIN_GF_INTERVAL codec control
Signed-off-by: James Zern
---
doc/encoders.texi | 2 ++
libavcodec/libvpxenc.c | 11 +++
libavcodec/version.h | 2 +-
3 files changed, 14 insertions(+), 1 deletion(-)
diff --git a
av_strlcpy() returns the length of the src string to enable
the caller to check for truncation. It is currently used in
the following way in dump_metadata(): Every metadata value
is searched for \b, \n, \v, \f, \r and then the data up to
the first of these characters found is copied to a small
temp
38 matches
Mail list logo
