Signed-off-by: Wu Jianhua
---
libavutil/x86/cpu.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/libavutil/x86/cpu.c b/libavutil/x86/cpu.c
index bcd41a50a2..9e6015cf31 100644
--- a/libavutil/x86/cpu.c
+++ b/libavutil/x86/cpu.c
@@ -148,11 +148,10 @@ int ff_get_cpu_flags_x
Based on IceLake-AVX512 and newer architecture, a broad
range of the subsets of AVX512 could be supported.
Signed-off-by: Wu Jianhua
---
configure | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index 94b30afe74..f282e9997a 100755
--- a/configure
++
Maximum size of a MOV chunk should be taken from the configurable
max_chunk_size option in AVFormatContext. If it is not defined revert to
the previously set limit of 1mb.
This patch was made in order to control the size of chunks in a MOV format
writer. I noticed that there was already an option
On 2021-08-18 04:10 am, Mohammad Izadi wrote:
From: Gyan Doshi
Can you refresh my memory on how I'm involved?
The fate test file can be found here:
https://drive.google.com/file/d/1jGW3f94rglLfr5WGmMQe3SEnp1YkbMRy/view?usp=drivesdk
The video file needs to be copied to fate-suite/mkv/
---
James Almer W rote:
> On 8/17/2021 4:24 PM, James Almer wrote:
> > On 8/17/2021 12:25 PM, Ronald S. Bultje wrote:
> >> Hi,
> >>
> >> On Tue, Aug 17, 2021 at 2:33 AM Hendrik Leppkes
> >> wrote:
> >>
> >>> On Tue, Aug 17, 2021 at 8:30 AM Wu Jianhua
> wrote:
> Based on IceLake-AVX512 and new
On Wed, Aug 18, 2021 at 5:01 AM Jan Ekström wrote:
>
> Unlike libx264, libx265 does not have a separate "unspecified"/"auto"
> default for color range, so we do always have to specify it.
> Thus, we are required to handle the RGB case on the libavcodec
> side to enable the correct value to be writ
On 8/17/2021 4:54 PM, Niklas Haas wrote:
From: Niklas Haas
Because we need access to ref frames without film grain applied, we have
to add an extra AVFrame to H264Picture to avoid messing with the
original. This requires some amount of overhead to make the reference
moves work out, but it allow
From: Gyan Doshi
The fate test file can be found here:
https://drive.google.com/file/d/1jGW3f94rglLfr5WGmMQe3SEnp1YkbMRy/view?usp=drivesdk
The video file needs to be copied to fate-suite/mkv/
---
libavcodec/dynamic_hdr10_plus.c | 273 +---
libavcodec/dynamic_hdr10_pl
Unlike libx264, libx265 does not have a separate "unspecified"/"auto"
default for color range, so we do always have to specify it.
Thus, we are required to handle the RGB case on the libavcodec
side to enable the correct value to be written out in in case
of RGB content with unspecified color range
By default the x264 full range flag is set to -1. By not setting
it to something else, we can let libx264 handle the RGB case.
Additionally, change the preference order to user-specified range
first, and then any fall-back logic left for the YUVJ pix_fmts.
Fixes the capture part of #9374
---
liba
Hi,
On Tue, Aug 17, 2021 at 3:27 PM James Almer wrote:
> On 8/17/2021 4:24 PM, James Almer wrote:
> > On 8/17/2021 12:25 PM, Ronald S. Bultje wrote:
> >> On Tue, Aug 17, 2021 at 2:33 AM Hendrik Leppkes
> >> wrote:
> >>> On Tue, Aug 17, 2021 at 8:30 AM Wu Jianhua
> wrote:
> Based on IceLak
From: Niklas Haas
Because we need access to ref frames without film grain applied, we have
to add an extra AVFrame to H264Picture to avoid messing with the
original. This requires some amount of overhead to make the reference
moves work out, but it allows us to benefit from frame multithreading
f
Oops, missing av_frame_unref() in the decoder uninit. Will fix.
___
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
On 8/17/2021 4:24 PM, James Almer wrote:
On 8/17/2021 12:25 PM, Ronald S. Bultje wrote:
Hi,
On Tue, Aug 17, 2021 at 2:33 AM Hendrik Leppkes
wrote:
On Tue, Aug 17, 2021 at 8:30 AM Wu Jianhua wrote:
Based on IceLake-AVX512 and newer architecture, a broad
range of the subsets of AVX512 coul
From: Niklas Haas
Because we need access to ref frames without film grain applied, we have
to add an extra AVFrame to H264Picture to avoid messing with the
original. This requires some amount of overhead to make the reference
moves work out, but it allows us to benefit from frame multithreading
f
From: Niklas Haas
This could arguably also be a vf, but I decided to put it here since
decoders are technically required to apply film grain during the output
step, and I would rather want to avoid requiring users insert the
correct film grain synthesis filter on their own.
The code, while in C,
From: Niklas Haas
>From SMPTE RDD 5-2006, the grain seed is to be computed from the
following definition of `pic_offset`:
> When decoding H.264 | MPEG-4 AVC bitstreams, pic_offset is defined as
> follows:
> - pic_offset = PicOrderCnt(CurrPic) + (PicOrderCnt_offset << 5)
> where:
> - PicOrder
On Sun, 15 Aug 2021 19:11:42 +0200 Michael Niedermayer
wrote:
> On Sat, Aug 14, 2021 at 01:36:20PM +0200, Niklas Haas wrote:
> > From: Niklas Haas
> >
> > Because we need access to ref frames without film grain applied, we have
> > to add an extra AVFrame to H264Picture to avoid messing with th
On 8/17/2021 12:25 PM, Ronald S. Bultje wrote:
Hi,
On Tue, Aug 17, 2021 at 2:33 AM Hendrik Leppkes wrote:
On Tue, Aug 17, 2021 at 8:30 AM Wu Jianhua wrote:
Based on IceLake-AVX512 and newer architecture, a broad
range of the subsets of AVX512 could be supported.
[..]
-enabled a
Paul B Mahol:
> Signed-off-by: Paul B Mahol
> ---
> +bytestream2_init_writer(&s->pb, pkt->data, pkt->size);
> +
> +bytestream2_put_be32(&s->pb, 0x00);
> +
> +pal = av_packet_new_side_data(pkt, AV_PKT_DATA_PALETTE, AVPALETTE_SIZE);
Missing check for allocation failure.
> +memcpy(p
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 subject "unsubscribe".
August 17, 2021 3:58 AM, "Nicolas George" wrote:
> Xiang Xiao (12021-08-17):
>
>> Nicolas, do you have any more progress? I am very interested in your
>> proposal and want to test your change in our special device.
>
> Sorry. I have been focusing on other projects while looking for a good
> way
On Tue, 17 Aug 2021, James Almer wrote:
On 8/17/2021 12:35 PM, Christopher Degawa wrote:
Fixes https://trac.ffmpeg.org/ticket/8903
relevant https://github.com/msys2/MINGW-packages/discussions/9258
Signed-off-by: Christopher Degawa
---
libavcodec/x86/cabac.h | 9 +++--
1 file changed,
On Tue, 17 Aug 2021, Christopher Degawa wrote:
Fixes https://trac.ffmpeg.org/ticket/8903
relevant https://github.com/msys2/MINGW-packages/discussions/9258
Signed-off-by: Christopher Degawa
---
libavcodec/x86/cabac.h | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/l
On 8/17/2021 12:35 PM, Christopher Degawa wrote:
Fixes https://trac.ffmpeg.org/ticket/8903
relevant https://github.com/msys2/MINGW-packages/discussions/9258
Signed-off-by: Christopher Degawa
---
libavcodec/x86/cabac.h | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --gi
Fixes https://trac.ffmpeg.org/ticket/8903
relevant https://github.com/msys2/MINGW-packages/discussions/9258
Signed-off-by: Christopher Degawa
---
libavcodec/x86/cabac.h | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/libavcodec/x86/cabac.h b/libavcodec/x86/cabac.h
i
Nicolas George:
> Andreas Rheinhardt (12021-08-17):
>> This can be enabled/disabled on a per-filter basis by setting
>> the new internal flags FF_FILTER_FLAG_FREE_(IN|OUT)PADS and
>> on a per-pad basis by setting the AVFILTERPAD_FLAG_FREE_NAME flag.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>
Hi,
On Tue, Aug 17, 2021 at 2:33 AM Hendrik Leppkes wrote:
> On Tue, Aug 17, 2021 at 8:30 AM Wu Jianhua wrote:
> > Based on IceLake-AVX512 and newer architecture, a broad
> > range of the subsets of AVX512 could be supported.
>
[..]
> > -enabled avx512 && check_x86asm avx512_external "
On Tue, Aug 17, 2021 at 3:58 PM Nicolas George wrote:
> Xiang Xiao (12021-08-17):
> > Nicolas, do you have any more progress? I am very interested in your
> > proposal and want to test your change in our special device.
>
>
We are building an audio framework on top of FFmpeg for a wearable device
On 8/11/2021 4:42 PM, Soft Works wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of
Haihao Xiang
Sent: Wednesday, 11 August 2021 08:44
To: ffmpeg-devel@ffmpeg.org
Cc: Haihao Xiang
Subject: [FFmpeg-devel] [PATCH] ffmpeg_hw: Don't ignore key
parameters when initializing a hw dev
On Mon, 16 Aug 2021, Mikhail Nitenko wrote:
Benchmarks:A53 A72
pred8x8_dc_10_c: 64.255.7
pred8x8_dc_10_neon:61.753.7
pred8x8_dc_128_10_c: 26.020.7
pred8x8_dc_128_10_neon:30.724.5
pred8x8_horiz
On Mon, 16 Aug 2021, Mikhail Nitenko wrote:
Benchmarks: A53 A72
h264_h_loop_filter_chroma422_10bpp_c: 277.5 114.2
h264_h_loop_filter_chroma422_10bpp_neon: 109.781.7
h264_h_loop_filter_chroma_10bpp_c:
On Mon, Aug 16, 2021 at 11:31:15PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > Fixes: left shift of 16711968 by 8 places cannot be represented in type
> > 'int'
> > Fixes:
> > 36601/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-6581933285965824
> >
> > Found-by: c
On Mon, Aug 16, 2021 at 11:28:41PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Sun, Aug 15, 2021 at 07:35:35PM +0200, Andreas Rheinhardt wrote:
> >>
> >> PS: I still don't know whether my patch for av_opt_copy needs to bump
> >> minor or micro.
> >
> > you mean the documentation
Gyan Doshi (12021-08-16):
> The maximum, if specified, should be a single value.
Strictly speaking, yes. But I want to express that it is ok to choose a
lower maximum on a per-commit basis. I personally wrap to 64-66.
> Don't hold up on my account. I'll do it later when I survey that whole page
>
Xiang Xiao (12021-08-17):
> Nicolas, do you have any more progress? I am very interested in your
> proposal and want to test your change in our special device.
Sorry. I have been focusing on other projects while looking for a good
way to avoid dynamic allocations in the thread-aware scheduler.
Si
Andreas Rheinhardt (12021-08-17):
> This can be enabled/disabled on a per-filter basis by setting
> the new internal flags FF_FILTER_FLAG_FREE_(IN|OUT)PADS and
> on a per-pad basis by setting the AVFILTERPAD_FLAG_FREE_NAME flag.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> I decided to combine b
Andreas Rheinhardt (12021-08-17):
> Signed-off-by: Andreas Rheinhardt
> ---
> libavfilter/af_acrossover.c | 2 +-
> libavfilter/af_afir.c | 8
> libavfilter/af_aiir.c | 4 ++--
> libavfilter/af_amerge.c | 2 +-
> libavfilter/af_amix.c | 2 +-
Andreas Rheinhardt (12021-08-17):
> It will be useful in the future when more flags are added.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavfilter/af_anequalizer.c | 2 +-
> libavfilter/af_channelmap.c | 2 +-
> libavfilter/af_firequalizer.c | 2 +-
> libavfilter/avfilter
Andreas Rheinhardt (12021-08-17):
> av_frame_copy_props() already copies pts.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavfilter/avfilter.c | 1 -
> 1 file changed, 1 deletion(-)
All three look ok. Thanks.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
40 matches
Mail list logo
