On Mon, 2021-08-02 at 10:27 +, Soft Works wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Xiang, Haihao
> > Sent: Monday, 2 August 2021 10:25
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH v2 1/2] qsvdec: add support for
> > HW_DEVICE_CTX
From: maryam ebr
Hello,
similar to CVE-2013-0868, here return value check for 'init_vlc' is needed.
crafted DNxHD data can cause unspecified impact.
---
libavcodec/dnxhddec.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/libavcodec/dnxhddec.c
After standardizing the use of 'pxor' in commit 'ebedd26', FFmpeg
build failed with upstream compiler, for 'pxor' is not supported
in time. This patch helps to workaround the build failure by
checking whether 'pxor' is supported during configuration, if not,
MMI will be disabled.
---
configure |
> -Original Message-
> From: myp...@gmail.com
> Sent: Monday, August 2, 2021 5:31 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Cc: Wu, Jianhua ; Cheng, Yanfei
>
> Subject: Re: [FFmpeg-devel] [PATCH 1/5] libavfilter/x86/vf_gblur: add
>
The field is documented to be for decoding only.
Signed-off-by: James Almer
---
libavcodec/mfenc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavcodec/mfenc.c b/libavcodec/mfenc.c
index 26f1c8057f..410ad64d8d 100644
--- a/libavcodec/mfenc.c
+++ b/libavcodec/mfenc.c
@@ -100,8 +100,6
Have you checked the mailing list archives? Maybe its slow to get to others but
fast to get on the ML.
Regardless, maybe its just a gmail problem. The multiple (non Gmail) providers
ive been using/have used all work even faster than gmail. I think Nicolas Lynne
and Niedermayer along with
Signed-off-by: James Almer
---
libavfilter/vf_showinfo.c | 70 +++
1 file changed, 70 insertions(+)
diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
index 5e1c4dc2e3..2d1748bd0b 100644
--- a/libavfilter/vf_showinfo.c
+++
Signed-off-by: James Almer
---
libavcodec/hevc_sei.c | 44 ++
libavcodec/hevc_sei.h | 22 +
libavcodec/hevcdec.c | 56 +++
3 files changed, 122 insertions(+)
diff --git a/libavcodec/hevc_sei.c
Signed-off-by: James Almer
---
libavcodec/cbs_h2645.c| 6 +++
libavcodec/cbs_h265.h | 21 +
libavcodec/cbs_h265_syntax_template.c | 65 +++
3 files changed, 92 insertions(+)
diff --git a/libavcodec/cbs_h2645.c
Signed-off-by: Andreas Rheinhardt
---
libavformat/yuv4mpegenc.c | 87 +++
1 file changed, 14 insertions(+), 73 deletions(-)
diff --git a/libavformat/yuv4mpegenc.c b/libavformat/yuv4mpegenc.c
index efa05133d5..fca0ee3120 100644
--- a/libavformat/yuv4mpegenc.c
On 8/2/2021 10:48 PM, ffmpegandmahanstreamer@e.email wrote:
> Have you checked the mailing list archives? Maybe its slow to get to others
> but fast to get on the ML.
No, it is not. It's the same issue as we looked at above. I suspect Soft Work
has
the correct interpretation of the issue.
>
677a030b26045acb50353d7954ae984ceefcd807 introduced more printable
side data types in ffprobe, however the Audio Service Type side data
'type' field that was introduced aliases an existing field of the same
name within the side data array, which can lead to JSON output like:
"side_data_list":
On 7/14/2021 8:05 PM, Nicolas George wrote:
> Therefore, the information we need now to debug is what the logs of
> ffbox0-bg.mplayerhq.hu contains immediately after 20 Feb 2021 11:47:04
> -0800.
>
> If it happens to you again, you can ask for the logs immediately, it will
> be more likely the
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 31
libavfilter/Makefile | 2 +
libavfilter/allfilters.c | 2 +
libavfilter/f_segment.c | 328 +++
4 files changed, 363 insertions(+)
create mode 100644 libavfilter/f_segment.c
diff
Also split error message to error and warning.
Signed-off-by: Marton Balint
---
libavcodec/mpeg12dec.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index 858dca660c..49d865853b 100644
---
On Mon, Aug 02, 2021 at 01:34:36PM +0800, Wu Jianhua wrote:
> The new vertical slice with AVX2/512 acceleration can significantly
> improve the performance of Gaussian Filter 2D.
>
> Performance data (fps):
> ff_verti_slice_c: 32.57
> ff_verti_slice_avx2: 476.19
> ff_verti_slice_avx512: 833.33
>
On Tue, Aug 3, 2021 at 12:48 AM Michael Niedermayer
wrote:
> On Sun, Aug 01, 2021 at 04:08:17PM +0200, Nicolas George wrote:
> > Linjie Fu (12021-08-01):
> > > Checked swscale, it uses bicubic by default.
> > > Scale filter sets the flags to bilinear if sws_scale_opt is not
> initialized
> > >
Linjie Fu (12021-08-03):
> From: Linjie Fu
>
> Pass sws_flags to scale filter through scale_sws_opts and correct the
> dumped flags information.
>
> CMD:
> $ffmpeg -v verbose -i input.mp4 -sws_flags lanczos+bitexact+accurate_rnd \
> -vf format=yuv420p,scale=800x600 -an -vframes 10 -f
Linjie Fu (12021-08-03):
> From: Linjie Fu
>
> Currently the default swscale flags for simple filter graph is bicubic,
> however for complex filter graph it uses bilinear as decleared in scale
> filter.
>
> $ffmpeg -v verbose -i input.mp4 -vf format=yuv420p,scale=800x600 -an -f null -
>
Linjie Fu (12021-08-03):
> From: Linjie Fu
>
> Signed-off-by: Linjie Fu
> ---
> libswscale/utils.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
Nack. The original logic needs to be evaluated to see if the others
scalers are better.
Regards,
--
Nicolas George
Hi Andreas,
On Tue, Aug 3, 2021 at 12:50 AM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Linjie Fu:
> > From: Linjie Fu
> >
> > Since we prefer to use bicubic flags for scale filter to keep pace with
> > swscale.
> >
> > Signed-off-by: Linjie Fu
> > ---
> >
Linjie Fu:
> From: Linjie Fu
>
> Since we prefer to use bicubic flags for scale filter to keep pace with
> swscale.
>
> Signed-off-by: Linjie Fu
> ---
> tests/ref/fate/filter-scale2ref_keep_aspect | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git
On 8/2/2021 9:06 AM, Niklas Haas wrote:
From: Niklas Haas
The current code reads the wrong number of bits for `fg_model_id`, which
causes all of the values downstream of this to contain corrupt values.
Fixes: corrupt SEI values
Fixes: 4ff73add5dbe6c319d693355be44df2e17a0b8bf
Signed-off-by:
From: Linjie Fu
Pass sws_flags to scale filter through scale_sws_opts and correct the
dumped flags information.
CMD:
$ffmpeg -v verbose -i input.mp4 -sws_flags lanczos+bitexact+accurate_rnd \
-vf format=yuv420p,scale=800x600 -an -vframes 10 -f md5 -
Before:
[auto_scaler_0 @
From: Linjie Fu
Signed-off-by: Linjie Fu
---
libswscale/utils.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 176fc6fd63..dea3b76eb3 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -1250,12 +1250,7 @@ av_cold
From: Linjie Fu
Currently the default swscale flags for simple filter graph is bicubic,
however for complex filter graph it uses bilinear as decleared in scale
filter.
$ffmpeg -v verbose -i input.mp4 -vf format=yuv420p,scale=800x600 -an -f null -
[Parsed_scale_1 @ 0x7f86d2c160c0] w:1920 h:1080
From: Linjie Fu
Since we prefer to use bicubic flags for scale filter to keep pace with
swscale.
Signed-off-by: Linjie Fu
---
tests/ref/fate/filter-scale2ref_keep_aspect | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tests/ref/fate/filter-scale2ref_keep_aspect
On Sun, Aug 01, 2021 at 04:08:17PM +0200, Nicolas George wrote:
> Linjie Fu (12021-08-01):
> > Checked swscale, it uses bicubic by default.
> > Scale filter sets the flags to bilinear if sws_scale_opt is not initialized
> > by sws_dict.
> >
> > We should use the same default flags for both simple
It is the natural header for it.
Signed-off-by: Andreas Rheinhardt
---
libavfilter/internal.h | 16
libavfilter/qp_table.h | 17 +
2 files changed, 17 insertions(+), 16 deletions(-)
diff --git a/libavfilter/internal.h b/libavfilter/internal.h
index
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vdpau.c | 3 +++
libavutil/internal.h | 4
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/libavcodec/vdpau.c b/libavcodec/vdpau.c
index f20dbd78e2..7c29746adb 100644
--- a/libavcodec/vdpau.c
+++ b/libavcodec/vdpau.c
@@ -69,6
They are not used by the header at all and only used by very few files;
so include the headers in their users instead of in internal.h.
Signed-off-by: Andreas Rheinhardt
---
libavfilter/audio.c| 1 +
libavfilter/avfilter.c | 1 +
libavfilter/internal.h | 2 --
libavfilter/video.c| 1 +
The reasons for including them don't exist any longer: ff_tlog() has
been moved to libavutil/internal.h and FF_QSCALE_TYPE_* has been moved
to qp_table.h.
Signed-off-by: Andreas Rheinhardt
---
The following headers are now no longer provided by
libavfilter/internal.h:
libavcodec/avcodec.h
It is also used by libavfilter and it is only natural to define it
alongside ff_dlog().
Signed-off-by: Andreas Rheinhardt
---
libavcodec/internal.h | 7 ---
libavutil/internal.h | 6 ++
2 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/libavcodec/internal.h
Said AVCodecContext is only used for logging; it furthermore avoids
an avcodec.h inclusion.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/huffman.c | 7 +++
libavcodec/huffman.h | 5 +++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/huffman.c
Signed-off-by: Andreas Rheinhardt
---
ppc/fft_vsx.h uses sqrthalf (provided by fft-internal.h) which uses
M_SQRT1_2 which it seems to get via fft.h which includes mem_internal.h
which includes avassert.h which includes avutil.h which includes
mathematics.h which provides this. Several of these
Since the removal of the 16-bit FFT said define is unnecessary as
FFT_FIXED_32 is always !FFT_FLOAT. But one wouldn't believe it when
looking at the code.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/aac_defines.h | 2 --
libavcodec/aacdec.c| 1 -
Signed-off-by: Andreas Rheinhardt
---
libavcodec/fft-internal.h | 4
1 file changed, 4 deletions(-)
diff --git a/libavcodec/fft-internal.h b/libavcodec/fft-internal.h
index 3bd5a1123d..cd809578ce 100644
--- a/libavcodec/fft-internal.h
+++ b/libavcodec/fft-internal.h
@@ -36,8 +36,6 @@
Don't rely on the user including it (mostly indirectly).
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mips/constants.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/mips/constants.h b/libavcodec/mips/constants.h
index df54b3016f..f6eaf4415e 100644
---
Signed-off-by: James Almer
---
libavfilter/avfilter.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
index c04afc6639..1f33702482 100644
--- a/libavfilter/avfilter.c
+++ b/libavfilter/avfilter.c
@@ -1446,19
Andreas Rheinhardt:
> Lynne:
>> (One-line) Patch attached:
>>
>>> --- a/libavcodec/encode.c
>>> +++ b/libavcodec/encode.c
>>> @@ -44,6 +44,7 @@ int ff_alloc_packet(AVCodecContext *avctx, AVPacket
>>> *avpkt, int64_t size)
>>> av_fast_padded_malloc(>internal->byte_buffer,
>>>
Jan Ekström:
> From: Jan Ekström
>
> This way it can be re-utilized in movenc.
>
> Signed-off-by: Jan Ekström
> ---
> libavformat/ttmlenc.c | 9 ++---
> libavformat/ttmlenc.h | 39 +++
> 2 files changed, 41 insertions(+), 7 deletions(-)
> create mode
On Mon, 26 Jul 2021, Jan Ekström wrote:
From: Jan Ekström
Includes basic support for both the ISMV ('dfxp') and MP4 ('stpp')
methods. This initial version also foregoes fragmentation support
in case the built-in sample squashing is to be utilized, as this
eases the initial review.
Lynne:
> (One-line) Patch attached:
>
>> --- a/libavcodec/encode.c
>> +++ b/libavcodec/encode.c
>> @@ -44,6 +44,7 @@ int ff_alloc_packet(AVCodecContext *avctx, AVPacket
>> *avpkt, int64_t size)
>> av_fast_padded_malloc(>internal->byte_buffer,
>>
(One-line) Patch attached:
> --- a/libavcodec/encode.c
> +++ b/libavcodec/encode.c
> @@ -44,6 +44,7 @@ int ff_alloc_packet(AVCodecContext *avctx, AVPacket *avpkt,
> int64_t size)
> av_fast_padded_malloc(>internal->byte_buffer,
> >internal->byte_buffer_size,
(One-line) Patch attached
>From 144766b469a497e9abfff57f43052361620fdd43 Mon Sep 17 00:00:00 2001
From: Lynne
Date: Mon, 2 Aug 2021 14:33:07 +0200
Subject: [PATCH 1/2] ffprobe: print packet timebase
---
fftools/ffprobe.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fftools/ffprobe.c
2 Aug 2021, 05:03 by andreas.rheinha...@outlook.com:
> Lynne:
>
>> 8 Jul 2021, 21:20 by andreas.rheinha...@outlook.com:
>>
>>> Lynne:
>>>
Apr 26, 2021, 03:27 by andreas.rheinha...@outlook.com:
> Lynne:
>
>> From 097aed2ac33dda0bb2052d8b0402711ce95079ba Mon Sep 17 00:00:00
Am 25.07.21 um 09:47 schrieb Thilo Borgmann:
> Am 16.07.21 um 09:45 schrieb Thilo Borgmann:
>> Hi,
>>
> when transcoding 608 cc, the cc stream frame pts is set to the same value
> as its container frame's pts. However, the time_base is always set to
> 1/9 (default) in the
From: Niklas Haas
The current code reads the wrong number of bits for `fg_model_id`, which
causes all of the values downstream of this to contain corrupt values.
Fixes: corrupt SEI values
Fixes: 4ff73add5dbe6c319d693355be44df2e17a0b8bf
Signed-off-by: Niklas Haas
---
libavcodec/h264_sei.c | 2
On Mon, 02 Aug 2021 08:49:49 -0300 James Almer wrote:
> On 8/2/2021 7:36 AM, Niklas Haas wrote:
> > From: Niklas Haas
> >
> > The current code has a number of issues:
> > 1. The fg_model_id is specified in H.274 as u(2), not u(8)
>
> Yes, good catch.
>
> > 2. This SEI has no ue(v) "repetition
On 8/2/2021 7:36 AM, Niklas Haas wrote:
From: Niklas Haas
The current code has a number of issues:
1. The fg_model_id is specified in H.274 as u(2), not u(8)
Yes, good catch.
2. This SEI has no ue(v) "repetition period", but a u(1) persistence flag
This one however isn't. ITU-T H.264 has
sön 2021-08-01 klockan 03:55 +0200 skrev Marton Balint:
> The code expects every kind of metadata set to start with the generic metadata
> set attributes.
>
> Signed-off-by: Marton Balint
> ---
> libavformat/mxfdec.c | 66 ++--
> 1 file changed, 21
From: Niklas Haas
The current code has a number of issues:
1. The fg_model_id is specified in H.274 as u(2), not u(8)
2. This SEI has no ue(v) "repetition period", but a u(1) persistence flag
Additionally, we can get away with using the non-long version of
get_se_golomb() because the SEI spec
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Xiang, Haihao
> Sent: Monday, 2 August 2021 10:25
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v2 1/2] qsvdec: add support for
> HW_DEVICE_CTX method
>
> On Mon, 2021-08-02 at 07:11 +, Soft Works wrote:
Do you have CPU info, I can't find more info from the patch set
On Mon, Aug 2, 2021 at 1:35 PM Wu Jianhua wrote:
>
> Co-authored-by: Cheng Yanfei
> Co-authored-by: Jin Jun
> Signed-off-by: Wu Jianhua
> ---
> libavfilter/x86/vf_gblur.asm| 21 -
>
Soft Works (12021-08-01):
> > segment is more intuitive because it's a direct match. We already
> > have concat as a protocol / demuxer / filter; users will manage.
> Maybe segmentsplit ?
I am ok with either proposal.
Just make sure "segment" and "split" appear in the first sentence of the
Paul B Mahol (12021-08-01):
> Signed-off-by: Paul B Mahol
> ---
> doc/filters.texi | 31
> libavfilter/Makefile | 2 +
> libavfilter/allfilters.c | 2 +
> libavfilter/f_separate.c | 346 +++
> 4 files changed, 381 insertions(+)
> create
After standardizing usage of 'pxor' in commit 'ebedd26', FFmpeg
build failed with upstream compiler where pxor is untimely
supported. This patch help to workaround this build failure
by checking pxor in configure. When using upstream compiler
where pxor is unsupported, MMI will be disabled.
---
On Fri, Jul 30, 2021 at 9:51 PM Christopher Degawa wrote:
>
> On Fri, Jul 30, 2021 at 4:48 AM Jan Ekström wrote:
>
> > On Fri, Jul 23, 2021 at 5:02 AM Christopher Degawa
> > wrote:
> > > +#ifndef SVTAV1_MAKE_VERSION
> > > +#define SVTAV1_MAKE_VERSION(x,y,z) ((x) << 16 | (y) << 8 | z)
> > >
> -原始邮件-
> 发件人: "Jiaxun Yang"
> 发送时间: 2021-08-02 13:40:54 (星期一)
> 收件人: "FFmpeg development discussions and patches" ,
> yinshiyou...@loongson.cn
> 抄送:
> 主题: Re: [FFmpeg-devel] [PATCH] avcodec/mips: Support old style mmi
> instruction mnemonics
>
>
> 在 2021/7/29 20:26, Jiaxun Yang 写道:
On Mon, 2021-08-02 at 07:11 +, Soft Works wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Xiang, Haihao
> > Sent: Monday, 2 August 2021 07:53
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH v2 1/2] qsvdec: add support for
> > HW_DEVICE_CTX
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Xiang, Haihao
> Sent: Monday, 2 August 2021 07:53
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v2 1/2] qsvdec: add support for
> HW_DEVICE_CTX method
>
> On Fri, 2021-07-30 at 08:18 +, Soft Works wrote:
I do not like that, I prefer AVFrame to keep it as is currently.
frame allocation can be moved elsewhere.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
62 matches
Mail list logo
