Commits d49210788b0836d56dd872d517fe73f83b080101 and
ee8ce211ead04c8684da0c9c143814e57e9b9eda set the
FF_CODEC_CAP_INIT_THREADSAFE flag for the Snow encoder resp. decoder;
yet these codecs init functions aren't threadsafe at all:
ff_snow_common_init() initializes static data, but there is no check
The usage of a static variable presents a potential for data races and
means that this function can't be used in init functions of codecs with
FF_CODEC_CAP_INIT_THREADSAFE (unless of course one presumes that
everything is alright in which case the error is not triggered; but then
the whole function
Signed-off-by: Andreas Rheinhardt
---
libavcodec/ituh263enc.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/libavcodec/ituh263enc.c b/libavcodec/ituh263enc.c
index b1b78218a5..e1debcf63b 100644
--- a/libavcodec/ituh263enc.c
+++ b/libavcodec/ituh263enc.c
@@
This already makes initializing all the objects exclusively initialized
by ff_h263_encode_init() thread-safe; this includes the static tables of
ituh263enc.c: uni_h263_int*_rl_len, mv_penalty, fcode_tab as well as
umv_fcode_tab; it does not ff_h263_rl_inter as well as ff_rl_intra_aic,
as these are
Up until now, ff_h263_rl_inter and ff_rl_intra_aic were initialized by
both ituh263dec and ituh263enc; the result was that although
ff_h263_encode_init() guards the initialization of its static data with
an AVOnce, initializing the aforementioned RLTables was still not
thread-safe because ff_h263_d
The size of ff_qexp is only 32 bytes, but the code to generate it at
runtime takes 47 bytes (GCC 9.3, x64, -O3 in an av_cold function); so
just hardcode it.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/snow.c | 10 --
libavcodec/snow.h | 2 +-
libavcodec/snowdata.h | 10
Signed-off-by: Andreas Rheinhardt
---
libavcodec/dfa.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/dfa.c b/libavcodec/dfa.c
index 31c6c39089..cd3a9d97a3 100644
--- a/libavcodec/dfa.c
+++ b/libavcodec/dfa.c
@@ -424,4 +424,5 @@ AVCodec ff_dfa_decoder = {
.close = df
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cscd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/cscd.c b/libavcodec/cscd.c
index d50ddd6258..6c72178f83 100644
--- a/libavcodec/cscd.c
+++ b/libavcodec/cscd.c
@@ -175,6 +175,6 @@ AVCodec ff_cscd_decoder = {
> ---
> libavcodec/qsvdec_other.c | 188 --
> 1 file changed, 36 insertions(+), 152 deletions(-)
>
> diff --git a/libavcodec/qsvdec_other.c b/libavcodec/qsvdec_other.c
> index 2775e07955..266ac9f2e5 100644
> --- a/libavcodec/qsvdec_other.c
> +++ b/libavcodec/q
On Thu, 2020-11-26 at 18:20 +0800, Xu Guangxin wrote:
> ---
> libavcodec/Makefile | 8 +-
> libavcodec/qsvdec.c | 215 -
> libavcodec/qsvdec_h2645.c | 248 --
> 3 files changed, 217 insertions(+), 254 deletions(-)
>
Hi Haihao,
If you check the final code. The QSVOtherContext and QSVH2645Context will
be unified to QSVDecContext. It's no need to pass the priv_data_size.
In the final version, we have two macros
DEFINE_QSV_DECODER_WITH_OPTION for h265 only. Maybe av1 can use it for film
grain too.
DEFINE_QSV_DECO
> Hi Haihao,
> If you check the final code. The QSVOtherContext and QSVH2645Context will
> be unified to QSVDecContext. It's no need to pass the priv_data_size.
>
> In the final version, we have two macros
> DEFINE_QSV_DECODER_WITH_OPTION for h265 only. Maybe av1 can use it for film
> grain too.
Hi Haihao,
Thanks for the review.
This patch just moves all code from qsvdec_h2645.c to qsvdec.c.
The original code in qsvdec_h2645.c did not free the point, so the code
will not free it.
The av_freep(&s->qsv.load_plugins); will addressed by
https://patchwork.ffmpeg.org/project/ffmpeg/patch/2020112
On Wed, 2020-12-02 at 09:52 +0800, wenbin.c...@intel.com wrote:
> From: Wenbinc-Bin
>
> The max_frame_size parameter is set only when codec is h264. Now I add
> hevc in that conditional statement.
>
> Signed-off-by: Wenbin CHEN
> ---
> libavcodec/qsvenc.c | 2 +-
> 1 file changed, 1 insertion(
101 - 114 of 114 matches
Mail list logo
