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
___
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):
> 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):
> 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
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
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
>
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
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, 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, 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 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 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
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 "
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
>> ---
>
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
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
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 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,
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
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".
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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/
---
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
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
++
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
40 matches
Mail list logo
