> -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:
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 m
> -原始邮件-
> 发件人: "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 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)
> > > +#end
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.
---
co
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 m
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
docume
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 -
> libavfilter/x86/vf_gblu
> -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:
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 as
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 inserti
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
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
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
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 initiali
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 200
(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 b/ff
(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(&avctx->internal->byte_buffer,
> &avctx->internal->byte_buffe
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(&avctx->internal->byte_buffer,
>> &avctx->i
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.
Additionall
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 1
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(&avctx->internal->byte_buffer,
>>>
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 +1
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
--- a/libavcodec/mips/con
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 @@
#el
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 -
libavcodec/aacdec_fixed.
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 inc
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 b/libavcodec/huf
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 b/libavcodec/int
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 libavco
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 +
4
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
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 1bcfb830a1..6
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
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
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 f
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
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 @ 0x7f899a4187
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: Ni
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 a/tests/ref/fa
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
> > ---
> > tests/ref/fate/filte
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
signature.a
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 -
> [Parsed_
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 md5
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
> > > by
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
>
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
--- a/libavcodec/mpeg12de
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 --g
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 adm
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 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.
> Reg
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
+
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 b/libavcodec/cbs_h264
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 b/libavcodec/h
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
+++ b/libavfilter/vf_show
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 Kieran
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 @
> -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
> ff_postscale_slice_avx512(
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 | 2
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 b/libav
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 m
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".
lgtm, check if some headers are not needed after this.
___
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 "unsubsc
63 matches
Mail list logo
