Quoting Anton Khirnov (2024-09-10 08:39:47)
> Please put
> https://ups.khirnov.net/3dc9efb9d882bbbf05876bfa67d5257fb0ee93065b43dc5512539ac3dfe91208/pir.hevc
> to hevc/pir.hevc
Ccing samples-request
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg
Would trigger #10887 before it was fixed, sample cut from the one
attached to the bug.
---
Please put
https://ups.khirnov.net/3dc9efb9d882bbbf05876bfa67d5257fb0ee93065b43dc5512539ac3dfe91208/pir.hevc
to hevc/pir.hevc
---
tests/fate/hevc.mak | 3 +++
tests/ref/fate/hevc-pir | 15 +
Fixes #10887
---
libavcodec/hevc/hevcdec.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c
index 993349b678..df68e0b626 100644
--- a/libavcodec/hevc/hevcdec.c
+++ b/libavcodec/hevc/hevcdec.c
@@ -2629,6 +2629,11 @@ static int hls_decode
In hls_decode_entry_wpp(), self_id is always identical to thread.
---
libavcodec/hevc/hevcdec.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c
index c8c425fd71..993349b678 100644
--- a/libavcodec/hevc/hevcdec.c
+++ b/l
Signed-off-by: Osamu Watanabe
---
tests/ref/fate/j2k-dwt | 59
tests/ref/fate/jpeg2000-dcinema | 4 +-
tests/ref/fate/jpeg2000dec-p0_04 | 2 +-
tests/ref/fate/jpeg2000dec-p0_05 | 2 +-
tests/ref/fate/jpeg2000dec-p0_09
This commit fixes the problem described below on the integer version of the
inverse 9-7 DWT processing (FF_DWT97_INT,
https://trac.ffmpeg.org/ticket/10123), which is activated with `-flags
+bitexact`.
I went through the code path for 9-7 transform (integer) and improved precision
to match confo
On Mon, Sep 9, 2024 at 9:24 AM Araz wrote:
>
> > Apologies for missing this prior to merge, but you can't safely make these
> > assumptions about primaries and TRC just based on the input bit depth. Just
> > because it's 8-bit content doesn't mean it will be BT.709 and likewise for
> > 10-bit and
AMF_VIDEO_ENCODER_AV1_INPUT_HDR_METADATA was set above in the normal
input case but forgotten for the same in the delayed surface codepath.
Signed-off-by: Cameron Gutman
---
libavcodec/amfenc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
index
On Mon, Sep 9, 2024 at 6:48 PM Cameron Gutman wrote:
>
> On Mon, Sep 9, 2024 at 11:05 AM Araz wrote:
> >>
> >> > I took a look at this using AMD's AMF EncoderLatency sample and found
> >> > that
> >> > setting the QUERY_TIMEOUT option to 50 ms (as is default for the new AMF
> >> > HQ and HQLL us
On Mon, Sep 9, 2024 at 11:05 AM Araz wrote:
>>
>> > I took a look at this using AMD's AMF EncoderLatency sample and found that
>> > setting the QUERY_TIMEOUT option to 50 ms (as is default for the new AMF
>> > HQ and HQLL usage values) results in latency that is better than the
>> > current AMF co
On Sun, 8 Sep 2024, Martin Schitter wrote:
As suggested by Zhao Zhili, here is a squash rebased 3rd attempt.
I'm still unsure about my solution of adding the codec_id entries and
increasing the lead-position value, as criticized by Andreas Rheinhard,
but I don't see any other way to make it
On Tue, 11 Jun 2024, Michael Riedl wrote:
Deprecate the option 'draw_bars' in favor of the new option
'signal_loss_action',
which controls the behavior when the input signal is not available
(including the behavior previously available through draw_bars).
The default behavior remains unchang
Thanks for the patch set! Ran some initial tests and here are some
findings:
1. Tested using the HTM ref SW encoded bitstreams; the HTM encoded 2 layer
MV-HEVC elementary streams are decoded by both the HTM decoder and ffmpeg,
and both resulted in the same decoded pixels for both views.
2. Teste
On Mon, Sep 9, 2024 at 1:23 PM Timo Rothenpieler
wrote:
> On 09/09/2024 12:02, Anton Khirnov wrote:
> > Quoting Rémi Denis-Courmont (2024-09-09 09:32:07)
> >> Hi,
> >>
> >> Le 8 septembre 2024 19:57:38 GMT+03:00, Timo Rothenpieler <
> t...@rothenpieler.org> a écrit :
> >>>
> >>> Well, the reality
>
> > I took a look at this using AMD's AMF EncoderLatency sample and found
> that
> > setting the QUERY_TIMEOUT option to 50 ms (as is default for the new AMF
> > HQ and HQLL usage values) results in latency that is better than the
> > current AMF code in FFmpeg *and* this patch without having to
libavutil/ppc: Make use of getauxval() and elf_aux_info() on ppc
Modern Linux has getauxval() and FreeBSD/OpenBSD ppc have elf_aux_info().
Signed-off-by: Brad Smith
---
libavutil/ppc/cpu.c | 16
1 file changed, 16 insertions(+)
diff --git a/libavutil/ppc/cpu.c b/libavutil/ppc/
From: Rémi Denis-Courmont
Header contents taken from VLC commit 7a970a33329c9836d169727ddbaf49a33240d587.
Signed-off-by: Anton Khirnov
---
I will use this in my pending MV-HEVC set.
Could also be used to replace parts of intmath.h/common.h
---
compat/stdbit/stdbit.h | 594 +
Since we now require a C11-compliant compiler, there should be no
supported configurations where any of these is used.
---
compat/atomics/gcc/stdatomic.h | 173 -
compat/atomics/pthread/stdatomic.c | 39 --
compat/atomics/pthread/stdatomic.h | 197 -
> -if (color_depth == AMF_COLOR_BIT_DEPTH_8) {
> -/// Color Transfer Characteristics (AMF matches ISO/IEC)
> -AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_OUTPUT_TRANSFER_CHARACTERISTIC,
AMF_COLOR_TRANSFER_CHARACTERISTIC_BT709);
> -/// Color Primari
> Apologies for missing this prior to merge, but you can't safely make these
> assumptions about primaries and TRC just based on the input bit depth.
Just
> because it's 8-bit content doesn't mean it will be BT.709 and likewise for
> 10-bit and BT.2020+SMPTE 2084 PQ.
>
> Why doesn't amfenc_hevc (an
> On Sep 9, 2024, at 18:35, Anton Khirnov wrote:
>
> Quoting Zhao Zhili (2024-09-07 19:13:40)
>> From: Zhao Zhili
>>
>> ---
>> libavcodec/hevc/dsp_template.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavcodec/hevc/dsp_template.c b/libavcodec/hevc/dsp_t
Quoting James Almer (2024-09-06 16:05:33)
> On 9/6/2024 10:33 AM, Anton Khirnov wrote:
> > This is not the the only place where you're adding a check for discard,
>
> Because it's the only code i don't want to trigger for non-standalone
> output packets.
???
>
> > and I strongly dislike that '
Quoting James Almer (2024-09-08 15:26:51)
> On 9/6/2024 8:44 AM, Anton Khirnov wrote:
> > Quoting James Almer (2024-08-31 18:31:10)
> >> +typedef struct AVStreamGroupLCEVC {
> >> +const AVClass *av_class;
> >> +
> >> +/**
> >> + * Width of the final stream for presentation.
> >> + *
Not all changelog readers may be familiar with it.
---
Changelog | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Changelog b/Changelog
index 7237648f95..b6f91d7c8c 100644
--- a/Changelog
+++ b/Changelog
@@ -19,7 +19,8 @@ version :
- Cropping metadata parsing and writing in M
On 09/09/2024 12:02, Anton Khirnov wrote:
Quoting Rémi Denis-Courmont (2024-09-09 09:32:07)
Hi,
Le 8 septembre 2024 19:57:38 GMT+03:00, Timo Rothenpieler
a écrit :
Well, the reality is, that without printing all these warnings, nobody will
ever fix them.
Unless someone sits down and spends
On 2024-09-09 7:11 a.m., Ramiro Polla wrote:
On Mon, Sep 9, 2024 at 1:06 PM Brad Smith
wrote:
On 2024-09-09 7:00 a.m., Martin Storsjö wrote:
On Mon, 9 Sep 2024, Brad Smith wrote:
aarch64: Implement support for elf_aux_info(3) on FreeBSD and OpenBSD
FreeBSD 12.0+, OpenBSD -current and what w
On Mon, Sep 9, 2024 at 1:06 PM Brad Smith
wrote:
> On 2024-09-09 7:00 a.m., Martin Storsjö wrote:
> > On Mon, 9 Sep 2024, Brad Smith wrote:
> >
> >> aarch64: Implement support for elf_aux_info(3) on FreeBSD and OpenBSD
> >>
> >> FreeBSD 12.0+, OpenBSD -current and what will be OpenBSD 7.6 support
On Mon, Sep 9, 2024 at 1:01 PM Martin Storsjö wrote:
> On Mon, 9 Sep 2024, Brad Smith wrote:
>
> > aarch64: Implement support for elf_aux_info(3) on FreeBSD and OpenBSD
> >
> > FreeBSD 12.0+, OpenBSD -current and what will be OpenBSD 7.6 support
> > elf_aux_info(3).
> >
> > Signed-off-by: Brad Smi
On 2024-09-09 7:00 a.m., Martin Storsjö wrote:
On Mon, 9 Sep 2024, Brad Smith wrote:
aarch64: Implement support for elf_aux_info(3) on FreeBSD and OpenBSD
FreeBSD 12.0+, OpenBSD -current and what will be OpenBSD 7.6 support
elf_aux_info(3).
Signed-off-by: Brad Smith
---
configure
On 09/09/2024 11:57, Anton Khirnov wrote:
Quoting Lynne via ffmpeg-devel (2024-09-09 10:34:21)
This solves
ffmpeg -help bsf=trace_headers =>
Supported codecs: av1 h264 hevc vvc mjpeg mpeg2video vp8 vp9
---
fftools/opt_common.c | 1 +
1 file changed, 1 insertion(+)
Looks ok
Pushed, thank
Quoting epira...@gmail.com (2024-09-09 12:48:42)
>
>
> On 9 Sep 2024, at 12:10, Anton Khirnov wrote:
>
> > Quoting Marvin Scholz (2024-09-08 19:43:27)
> >> ---
> >> fftools/opt_common.c | 12 ++--
> >> 1 file changed, 6 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/fftools/opt_co
On Mon, 9 Sep 2024, Brad Smith wrote:
aarch64: Implement support for elf_aux_info(3) on FreeBSD and OpenBSD
FreeBSD 12.0+, OpenBSD -current and what will be OpenBSD 7.6 support
elf_aux_info(3).
Signed-off-by: Brad Smith
---
configure | 2 ++
libavutil/aarch64/cpu.c | 2 +-
libavut
The acaps variable was used outside of the #if DSHOWDEBUG block with
a1c4929f, but it is no longer used outside of the block since f125c504.
---
libavdevice/dshow.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c
index 84db151577..6e973
Quoting Martin Schitter (2024-09-08 20:41:38)
> diff --git a/libavcodec/dnxucdec.c b/libavcodec/dnxucdec.c
> new file mode 100644
> index 000..455c374
> --- /dev/null
> +++ b/libavcodec/dnxucdec.c
> @@ -0,0 +1,495 @@
> +/*
> + * Avid DNxUncomressed / SMPTE RDD 50 demuxer
This says it's a demux
aarch64: Implement support for elf_aux_info(3) on FreeBSD and OpenBSD
FreeBSD 12.0+, OpenBSD -current and what will be OpenBSD 7.6 support
elf_aux_info(3).
Signed-off-by: Brad Smith
---
configure | 2 ++
libavutil/aarch64/cpu.c | 2 +-
libavutil/cpu.c | 9 -
3 file
On 9 Sep 2024, at 12:10, Anton Khirnov wrote:
> Quoting Marvin Scholz (2024-09-08 19:43:27)
>> ---
>> fftools/opt_common.c | 12 ++--
>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/fftools/opt_common.c b/fftools/opt_common.c
>> index 9d2d5184a0..059f7a53d2 100644
Quoting Martin Schitter (2024-09-08 20:41:38)
> As suggested by Zhao Zhili, here is a squash rebased 3rd attempt.
>
> I'm still unsure about my solution of adding the codec_id entries and
> increasing the lead-position value, as criticized by Andreas Rheinhard,
> but I don't see any other way to m
This commit adds the first Vulkan hardware encoder.
Currently, P, and **B**-frames are supported. This marks the
first implementation to support both.
The encoder has feature-parity with VAAPI.
---
configure |1 +
libavcodec/Makefile |3 +
libavcodec/all
This commit adds the common Vulkan video encoding framework.
It makes full use of the asynchronous features of our new common
hardware encoding code, and of Vulkan.
The code is able to handle anything from H264 to AV1 and MJPEG.
---
configure | 2 +
libavcodec/Makefile|
Quoting Zhao Zhili (2024-09-07 19:13:40)
> From: Zhao Zhili
>
> ---
> libavcodec/hevc/dsp_template.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/hevc/dsp_template.c b/libavcodec/hevc/dsp_template.c
> index aebccd1a0c..a0f79c2673 100644
> --- a/libavco
Quoting Marvin Scholz (2024-09-05 03:13:13)
> Introduced in eddffbedb3443d5a4fe642de6e35b9e6a35cfda7
>
> Fixes: CID1618897 Resource leak
> ---
> libavfilter/avfiltergraph.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Thanks, pushed.
--
Anton Khirnov
_
Quoting sfan5 (2024-09-04 18:55:37)
> From 57b37df52c7d528a1ce926cd7a7d75f62f6b46c6 Mon Sep 17 00:00:00 2001
> From: sfan5
> Date: Wed, 4 Sep 2024 17:56:05 +0200
> Subject: [PATCH] lavf/tls_mbedtls: restrict TLSv1.3 verification workaround to
> affected version
>
> Now that mbedTLS 3.6.1 is rele
Quoting Marvin Scholz (2024-09-08 20:12:15)
> ---
> libavfilter/vf_vmafmotion.c | 53 +
> 1 file changed, 24 insertions(+), 29 deletions(-)
Looks good.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffm
Quoting Marvin Scholz (2024-09-08 20:05:57)
> ---
> libavfilter/vf_vmafmotion.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
Likely ok
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/li
Quoting Marvin Scholz (2024-09-08 20:02:34)
> No need to explicitly specify the buffer here as it is only
> ever passed to av_log, so av_err2str can be used.
> ---
> libavfilter/vf_vmafmotion.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
Possibly ok
--
Anton Khirnov
_
Quoting Marvin Scholz (2024-09-08 20:01:15)
> No need to explicitly specify the buffer here as it is only
> ever passed to av_log, so av_err2str can be used.
> ---
> libavfilter/vf_psnr.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
Looks fine
--
Anton Khirnov
Quoting Marvin Scholz (2024-09-08 19:58:16)
> ---
> fftools/cmdutils.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Ok
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-d
Quoting Marvin Scholz (2024-09-08 19:54:47)
> ---
> libavfilter/vf_ssim360.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
Looks ok.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org
Quoting Marvin Scholz (2024-09-08 19:50:46)
> No need to explicitly specify the buffer here as it is only ever passed
> to av_log, so av_err2str can be used.
> ---
> libavfilter/vf_ssim360.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
Looks ok.
--
Anton Khirnov
_
Quoting Marvin Scholz (2024-09-08 19:43:27)
> ---
> fftools/opt_common.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/fftools/opt_common.c b/fftools/opt_common.c
> index 9d2d5184a0..059f7a53d2 100644
> --- a/fftools/opt_common.c
> +++ b/fftools/opt_common.
Quoting Marvin Scholz (2024-09-08 19:14:10)
> ---
> fftools/ffmpeg_opt.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
Ok
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg
Le 9 septembre 2024 12:23:18 GMT+03:00, Ramiro Polla a
écrit :
>On Sat, Aug 24, 2024 at 3:30 PM Brad Smith
> wrote:
>> avutil/cpu_internal: Provide ff_getauxval() wrapper for getauxvaul()
>>
>> Initially used for getauxval() but will be used to add support for
>> other API.
>
>I'm curious, what
On 2024-09-09 5:55 a.m., Ramiro Polla wrote:
On Mon, Sep 9, 2024 at 11:34 AM Brad Smith wrote:
On 2024-09-09 5:23 a.m., Ramiro Polla wrote:
On Sat, Aug 24, 2024 at 3:30 PM Brad Smith
wrote:
avutil/cpu_internal: Provide ff_getauxval() wrapper for getauxvaul()
Initially used for getauxval() b
Quoting Rémi Denis-Courmont (2024-09-09 09:32:07)
> Hi,
>
> Le 8 septembre 2024 19:57:38 GMT+03:00, Timo Rothenpieler
> a écrit :
> >
> >Well, the reality is, that without printing all these warnings, nobody will
> >ever fix them.
> >Unless someone sits down and spends potentially multiple days
Quoting Rémi Denis-Courmont (2024-09-09 09:41:59)
>
>
> Le 8 septembre 2024 22:22:01 GMT+03:00, James Almer a
> écrit :
> >It's non-standard C.
>
> The description is a little bit misleading. `typeof` is standard C (as of
> last year). Sure, technically `__typeof__` is not standard but this i
Quoting Lynne via ffmpeg-devel (2024-09-09 10:34:21)
> This solves
> ffmpeg -help bsf=trace_headers =>
>
> Supported codecs: av1 h264 hevc vvc mjpeg mpeg2video vp8 vp9
> ---
> fftools/opt_common.c | 1 +
> 1 file changed, 1 insertion(+)
Looks ok
--
Anton Khirnov
___
On Mon, Sep 9, 2024 at 11:34 AM Brad Smith wrote:
> On 2024-09-09 5:23 a.m., Ramiro Polla wrote:
>
> On Sat, Aug 24, 2024 at 3:30 PM Brad Smith
> wrote:
>
> avutil/cpu_internal: Provide ff_getauxval() wrapper for getauxvaul()
>
> Initially used for getauxval() but will be used to add support for
On 2024-09-09 5:23 a.m., Ramiro Polla wrote:
On Sat, Aug 24, 2024 at 3:30 PM Brad Smith
wrote:
avutil/cpu_internal: Provide ff_getauxval() wrapper for getauxvaul()
Initially used for getauxval() but will be used to add support for
other API.
I'm curious, what other API do you have in mind? Is
On Sat, Aug 24, 2024 at 3:30 PM Brad Smith
wrote:
> avutil/cpu_internal: Provide ff_getauxval() wrapper for getauxvaul()
>
> Initially used for getauxval() but will be used to add support for
> other API.
I'm curious, what other API do you have in mind? Is ff_getauxval()
going to simulate getauxv
This solves
ffmpeg -help bsf=trace_headers =>
Supported codecs: av1 h264 hevc vvc mjpeg mpeg2video vp8 vp9
---
fftools/opt_common.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fftools/opt_common.c b/fftools/opt_common.c
index f44fc4c97c..021ed75272 100644
--- a/fftools/opt_common.c
+++ b/
On Sat, 24 Aug 2024, Brad Smith wrote:
avutil/cpu_internal: Provide ff_getauxval() wrapper for getauxvaul()
Initially used for getauxval() but will be used to add support for
other API.
Signed-off-by: Brad Smith
---
libavutil/aarch64/cpu.c | 4 ++--
libavutil/arm/cpu.c | 2 +-
libavut
the VVC test cases cbs-vvc should prerequisites
VVC{demuxer, parser, metadata_bsf, muser}
Signed-off-by: Steven Liu
---
tests/fate/cbs.mak | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/fate/cbs.mak b/tests/fate/cbs.mak
index 4c30c5ec6c..dfd9e7d93c 100644
--- a/tes
fix fate error when --disable-everything --samples=fate-suite/
--enable-demuxer=mov
Signed-off-by: Steven Liu
---
tests/fate/demux.mak | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/fate/demux.mak b/tests/fate/demux.mak
index d9b9045f0b..e0d1fccc8f 100644
--- a/tests/
add h264_metadata_bsf and file protocol for cbs-hevc-discard test cases
Signed-off-by: Steven Liu
---
tests/fate/cbs.mak | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/fate/cbs.mak b/tests/fate/cbs.mak
index 368385982c..4c30c5ec6c 100644
--- a/tests/fate/cbs.mak
+++ b/
add h264_metadata and file protocol for cbs-h264-discard test
Signed-off-by: Steven Liu
---
tests/fate/cbs.mak | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/fate/cbs.mak b/tests/fate/cbs.mak
index 802b0351a3..368385982c 100644
--- a/tests/fate/cbs.mak
+++ b/tests/fate
fix error at fate-seek-* when
configure with --disable-everything --samples=fate-suite/ --enable-demuxer=mov
Signed-off-by: Steven Liu
---
tests/fate/seek.mak | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tests/fate/seek.mak b/tests/fate/seek.mak
index dfc2fa6a96..8
Le 8 septembre 2024 22:22:01 GMT+03:00, James Almer a écrit
:
>It's non-standard C.
The description is a little bit misleading. `typeof` is standard C (as of last
year). Sure, technically `__typeof__` is not standard but this is easily
misinterpreted.
Also TBH, this change seems highly erro
Hi,
Le 8 septembre 2024 19:57:38 GMT+03:00, Timo Rothenpieler
a écrit :
>
>Well, the reality is, that without printing all these warnings, nobody will
>ever fix them.
>Unless someone sits down and spends potentially multiple days if not weeks of
>work to fix all the current ones.
>
>If we pri
68 matches
Mail list logo
