On Tue, 25 Jul 2023, Lynne wrote:
I think, however, the process has become rather opaque in this case.
Usually, there has to be a clear writeup of the issue, with all context
removed, that all parties have to agree on is presentable to the TC
for guidelines. In the past, whenever developers have
Hi,
Sorry, I totally missed the last version. I'll see if I can dig it out of the
archives or patchwork.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
f
On Mon, Jul 24, 2023 at 8:46 PM Tomas Härdin wrote:
> mån 2023-07-24 klockan 10:57 +0200 skrev Paul B Mahol:
> > On Mon, Jul 24, 2023 at 10:34 AM Andreas Rheinhardt <
> > andreas.rheinha...@outlook.com> wrote:
> >
> > > Michael Niedermayer:
> > > > On Sat, Jun 17, 2023 at 12:20:44AM +0200, Michae
LGTM.
On Mon, Jul 24, 2023 at 5:46 PM Michael Niedermayer
wrote:
>
> Suggested-by: Pierre-Anthony Lemieux
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/imf_cpl.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/libavformat/imf_cpl.c b/libavformat/imf_cpl.c
> index 69155d
It appears that all the issues raised during the review have been fixed,
and there have been no additional comments for over 1 month.
Could I kindly request assistance in pushing the patch?
On Mon, Jun 19, 2023 at 9:06 PM Arnie Chang wrote:
> Optimize the put and avg filtering for 4xH and 2xH bl
On 7/24/2023 9:46 PM, Michael Niedermayer wrote:
The unchecked read caused the 2nd subsequent tell call to move backward
resulting
in a negative length
Fixes: assertion failure
Fixes:
60276/clusterfuzz-testcase-minimized-ffmpeg_BSF_TRACE_HEADERS_fuzzer-5434126636023808
Found-by: continuous fu
On 7/24/2023 9:46 PM, Michael Niedermayer wrote:
Fixes: division by zero
Fixes:
60306/clusterfuzz-testcase-minimized-ffmpeg_BSF_TRACE_HEADERS_fuzzer-5538913553612800
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niede
Timo Rothenpieler 于2023年7月25日周二 08:01写道：
>
> ---
> libavformat/flvenc.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
> index 335d900415..41636ba1b8 100644
> --- a/libavformat/flvenc.c
> +++ b/libavformat/flvenc.c
> @@
The unchecked read caused the 2nd subsequent tell call to move backward
resulting
in a negative length
Fixes: assertion failure
Fixes:
60276/clusterfuzz-testcase-minimized-ffmpeg_BSF_TRACE_HEADERS_fuzzer-5434126636023808
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/t
Fixes: division by zero
Fixes:
60306/clusterfuzz-testcase-minimized-ffmpeg_BSF_TRACE_HEADERS_fuzzer-5538913553612800
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/cbs_h266_syntax_template.c
Suggested-by: Pierre-Anthony Lemieux
Signed-off-by: Michael Niedermayer
---
libavformat/imf_cpl.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavformat/imf_cpl.c b/libavformat/imf_cpl.c
index 69155d786d..5f1a67443f 100644
--- a/libavformat/imf_cpl.c
+++ b/libavformat/imf_cpl.c
@@ -
On 25.07.2023 01:41, Hendrik Leppkes wrote:
The size offset was previously being accounted for in flv_set_video_codec
for h264 and mpeg4, instead of being directly accounted for in the spot
where its read, which desynced on HEVC streams.
For clarity, move the size offset directly to the parsing,
---
libavformat/flvenc.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index 335d900415..41636ba1b8 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -863,6 +863,9 @@ static int flv_write_packet(AVFormatContext
The size offset was previously being accounted for in flv_set_video_codec
for h264 and mpeg4, instead of being directly accounted for in the spot
where its read, which desynced on HEVC streams.
For clarity, move the size offset directly to the parsing, similar to
how its done for all other header
Lynne:
> Jul 25, 2023, 00:19 by andreas.rheinha...@outlook.com:
>
>> Lynne:
>>
>>> Subject: [PATCH 2/2] lavc/avfft: deprecate the API
>>>
>>> This deprecates the currently unused API.
>>>
>> ^
>> superseded
>>
>>> ---
>>> doc/APIchanges | 4
>>> libavcodec/avfft.h | 25
>
> I think, however, the process has become rather opaque in this case.
> Usually, there has to be a clear writeup of the issue, with all context
> removed, that all parties have to agree on is presentable to the TC
> for guidelines.
>
I don't see why such a writeup is relevant, the mailing list
Jul 25, 2023, 00:19 by andreas.rheinha...@outlook.com:
> Lynne:
>
>> Subject: [PATCH 2/2] lavc/avfft: deprecate the API
>>
>> This deprecates the currently unused API.
>>
> ^
> superseded
>
>> ---
>> doc/APIchanges | 4
>> libavcodec/avfft.h | 25 +++
---
libavfilter/vf_xfade_vulkan.c | 20
1 file changed, 20 insertions(+)
diff --git a/libavfilter/vf_xfade_vulkan.c b/libavfilter/vf_xfade_vulkan.c
index faa19a0518..0409d6bdb1 100644
--- a/libavfilter/vf_xfade_vulkan.c
+++ b/libavfilter/vf_xfade_vulkan.c
@@ -78,6 +78,7 @@ en
mån 2023-07-24 klockan 10:19 +0200 skrev Nicolas George:
> Also, is it only for receiving? It is there, at least as a potential,
> the possibility of sending, maybe in the Citizen Band?
Only licensed gear may be operated on the ISM bands, and only licensed
amateurs are allowed to build their own u
Lynne:
> Subject: [PATCH 2/2] lavc/avfft: deprecate the API
>
> This deprecates the currently unused API.
^
superseded
> ---
> doc/APIchanges | 4
> libavcodec/avfft.h | 25 +
> libavcodec/tests/fft.c
Jul 24, 2023, 23:27 by mar...@martin.st:
> On Mon, 17 Jul 2023, Rémi Denis-Courmont wrote:
>
>> Since you're giving zero valid reasons, I'm invoking the TC.
>>
>
> Just for public record and visibility:
>
> The TC has discussed the matter at hand. Overall, the TC considered that the
> approach of
This deprecates the currently unused API.
Patch attached.
>From 8cf7041345ebef47e710b65395095190ea88dd4a Mon Sep 17 00:00:00 2001
From: Lynne
Date: Mon, 24 Jul 2023 23:55:55 +0200
Subject: [PATCH 2/2] lavc/avfft: deprecate the API
This deprecates the currently unused API.
---
doc/APIchanges
On Sun, Jul 23, 2023 at 10:15:50AM +0200, Marton Balint wrote:
>
>
> On Fri, 21 Jul 2023, Richard Acayan wrote:
>
>> Will this patch be applied or receive any comments? I have been waiting
>> more than 2 weeks since the original submission
>> (https://ffmpeg.org/pipermail/ffmpeg-devel/2023-July/311
Patch attached.
>From a3e8ab975d21b3240a63f3f09fe486e05083ab7d Mon Sep 17 00:00:00 2001
From: Lynne
Date: Sat, 18 Feb 2023 13:14:31 +0100
Subject: [PATCH 1/2] ffplay: port to lavu/tx
---
fftools/ffplay.c | 42 +++---
1 file changed, 27 insertions(+), 15 delet
On 24 Jul 2023, at 23:11, Marvin Scholz wrote:
> ---
> libavfilter/vf_xfade_vulkan.c | 43 +++
> 1 file changed, 43 insertions(+)
>
> diff --git a/libavfilter/vf_xfade_vulkan.c b/libavfilter/vf_xfade_vulkan.c
> index 8825717890..d044714199 100644
> --- a/libavfil
---
libavfilter/vf_xfade_vulkan.c | 38 +--
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/libavfilter/vf_xfade_vulkan.c b/libavfilter/vf_xfade_vulkan.c
index c3b08b52f5..faa19a0518 100644
--- a/libavfilter/vf_xfade_vulkan.c
+++ b/libavfilter/vf_xfa
---
libavfilter/vf_xfade_vulkan.c | 37 +++
1 file changed, 37 insertions(+)
diff --git a/libavfilter/vf_xfade_vulkan.c b/libavfilter/vf_xfade_vulkan.c
index 8825717890..c3b08b52f5 100644
--- a/libavfilter/vf_xfade_vulkan.c
+++ b/libavfilter/vf_xfade_vulkan.c
@@ -7
Martin Storsjo (12023-07-25):
> The TC has discussed the matter at hand.
The TC (and CC) has been elected for a year in July of 2020. That means
your mandate is two years expired. This decision is therefore not
binding.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
On Mon, 17 Jul 2023, Rémi Denis-Courmont wrote:
Since you're giving zero valid reasons, I'm invoking the TC.
Just for public record and visibility:
The TC has discussed the matter at hand. Overall, the TC considered that
the approach of using an indirect call seemed tolerable given the benef
---
libavfilter/vf_xfade_vulkan.c | 38 +--
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/libavfilter/vf_xfade_vulkan.c b/libavfilter/vf_xfade_vulkan.c
index d044714199..4f26398410 100644
--- a/libavfilter/vf_xfade_vulkan.c
+++ b/libavfilter/vf_xfa
---
libavfilter/vf_xfade_vulkan.c | 43 +++
1 file changed, 43 insertions(+)
diff --git a/libavfilter/vf_xfade_vulkan.c b/libavfilter/vf_xfade_vulkan.c
index 8825717890..d044714199 100644
--- a/libavfilter/vf_xfade_vulkan.c
+++ b/libavfilter/vf_xfade_vulkan.c
@@ -7
libavcodec/vulkan_video_codec_av1std.h currently does not pass
checkheaders: It is missing stdint.h and vulkan/vulkan_core.h.
The comment "This header is NOT YET generated from the Khronos Vulkan
XML API Registry." as well as the fact that it does not use our standard
inclusion guards makes the fil
On Thu, Jul 20, 2023 at 4:08 PM Thilo Borgmann wrote:
>
> All issues of v2 fixed. Makes tsan happy now as well.
>
> Patch 5/6 is still there for making changes in lavc/webp reviewable but
> shall be stashed when pushing.
>
This looks to fail fate:
https://patchwork.ffmpeg.org/check/83180/
It seem
mån 2023-07-24 klockan 10:13 +0200 skrev Nicolas George:
> Tomas Härdin (12023-07-23):
> > No to this entire patchset.
>
> 404 argument not found.
>
> > Users can test libavradio's master if they wish. Do not assume
> > merging
> > this fork will happen, especially not without TC approval, nor th
sön 2023-07-23 klockan 16:01 -0300 skrev James Almer:
> What bothers me is that even though it's added outside of lavd, it's
> being added as a brand new lavd, with all the drawbacks this implies,
> including it being tied to lavf in an awful way. And all for a single
> "device" AVInputFormat. It'
mån 2023-07-24 klockan 10:57 +0200 skrev Paul B Mahol:
> On Mon, Jul 24, 2023 at 10:34 AM Andreas Rheinhardt <
> andreas.rheinha...@outlook.com> wrote:
>
> > Michael Niedermayer:
> > > On Sat, Jun 17, 2023 at 12:20:44AM +0200, Michael Niedermayer
> > > wrote:
> > > > Signed-off-by: Michael Niederm
Signed-off-by: Michael Niedermayer
---
libavradio/sdr.h | 2 ++
libavradio/sdrdemux.c | 11 ++-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/libavradio/sdr.h b/libavradio/sdr.h
index a5a291ee37..6d11ef794f 100644
--- a/libavradio/sdr.h
+++ b/libavradio/sdr.h
@@ -21
Signed-off-by: Michael Niedermayer
---
libavradio/sdrinradio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavradio/sdrinradio.c b/libavradio/sdrinradio.c
index 2865b6a9a6..ab7e786744 100644
--- a/libavradio/sdrinradio.c
+++ b/libavradio/sdrinradio.c
@@ -113,7 +113,7 @@
Also use this to detect a DC offset instead of the driver
Signed-off-by: Michael Niedermayer
---
libavradio/sdr.h | 1 +
libavradio/sdrdemux.c | 11 ++-
tests/ref/fate/sdr-am | 38 +++---
3 files changed, 26 insertions(+), 24 deletions(-)
diff --git
This way it is also available for file input from specific hw
Signed-off-by: Michael Niedermayer
---
libavradio/sdrdemux.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavradio/sdrdemux.c b/libavradio/sdrdemux.c
index b0b63827eb..123a1a9d0f 100644
--- a/libavradio/
Signed-off-by: Michael Niedermayer
---
libavradio/sdr.h| 5 +
libavradio/sdrdemux.c | 8
libavradio/sdrinradio.c | 5 +
3 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/libavradio/sdr.h b/libavradio/sdr.h
index de0a479d26..7d7bfd6806 100644
--- a/libavrad
Signed-off-by: Michael Niedermayer
---
libavradio/sdrinradio.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/libavradio/sdrinradio.c b/libavradio/sdrinradio.c
index c24a30d746..5c14250f8c 100644
--- a/libavradio/sdrinradio.c
+++ b/libavradio/sdrinradio.c
@@ -
On 7/24/2023 6:07 AM, Paul B Mahol wrote:
On Mon, Jul 24, 2023 at 10:21 AM Nicolas George wrote:
Paul B Mahol (12023-07-23):
Your comment is extremely rude and unhelpful.
I am sorry for any perceived rudeness. Shall I point each time I find
your comments to me extremely rude and/or unhelpfu
> What is the benefit of supporting a custom allocator for all filters in
> the chain? Internally, it's already using a very optimized buffer pool.
> The caller only cares about how what they get out of buffersink is
>
You may want to reuse a larger existing pool instead of FFmpeg have its own.
K
On Sat, Jul 22, 2023 at 04:11:00PM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavradio/vissualize.c | 14 +-
> 1 file changed, 9 insertions(+), 5 deletions(-)
will apply patchset (to libavradio repository)
thx
[...]
--
Michael GnuPG finger
Hi
On Mon, Jul 24, 2023 at 10:19:08AM +0200, Nicolas George wrote:
> Michael Niedermayer (12023-07-24):
> > There are other pathes forward but thats the current plan _IF_ this
> > isnt killed off by the community and _IF_ others join and enjoy
> > working on this. Also nothing is cast in stone, t
Pls don't top-post.
Am 24.07.23 um 15:04 schrieb Rémi Denis-Courmont:
Hi,
That doesn't sound really viable for regular "day-to-day" operations of social
network channels, and it's superfluous for stuff that's already been agreed upon.
If you think in patches, I see it would be superfluous. N
On 7/24/2023 12:25 PM, Tomas Härdin wrote:
+static int prores_check_frame_header(const uint8_t *buf, const int
data_size)
+{
+ int hdr_size, width, height;
+ int version, alpha_info;
+
+ hdr_size = AV_RB16(buf);
+ if (hdr_size < 20)
+ return AVERROR_INVALIDDATA;
+
+ version
> +static int prores_check_frame_header(const uint8_t *buf, const int
> data_size)
> +{
> + int hdr_size, width, height;
> + int version, alpha_info;
> +
> + hdr_size = AV_RB16(buf);
> + if (hdr_size < 20)
> + return AVERROR_INVALIDDATA;
> +
> + version = buf[3];
> + if (ve
On 7/24/2023 3:37 AM, hung kuishing wrote:
> ---
> libavcodec/Makefile| 1 +
> libavcodec/parsers.c | 1 +
> libavcodec/prores_parser.c | 91 ++
> libavformat/Makefile | 2 +
> libavformat/allformats.c | 2 +
> libavformat/proresdec.c
Pointers to these functions are used in comparisons.
Currently the compiler has to presume the worst for these,
namely that the functions are from another DSO and therefore
loads their addresses from the GOT (which also entails a
relocation entry that is processed at runtime, regardless
of whether
It is the more proper place for them given that this is
the only API using them.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/asvenc.c| 1 -
libavcodec/dct.h | 7 ---
libavcodec/fdctdsp.c | 1 -
libavcodec/fdctdsp.h | 7 +++
libavcodec/jf
Hi,
That doesn't sound really viable for regular "day-to-day" operations of social
network channels, and it's superfluous for stuff that's already been agreed
upon.
The problem is abusing your account privileges to push forward something that
was obviously not agreed upon in the first place, s
Am 24.07.23 um 13:06 schrieb Leo Izen:
On 7/24/23 04:59, Michael Niedermayer wrote:
what ?
libavradio is part of FFmpeg its just a seperate repository.
libavradio will also be part of the 6.1 release, it was even officially
announced. The tweet had over 500 likes IIRC. No sneaking here.
An
These are no longer used as they have been replaced by avutil/tx.
Yet they are still compiled for all builds and included
by default in the resulting DSO for shared builds (they are discarded
for shared builds). This commit stops doing so.
This saves 8KiB in .rodata, about 43KiB in .bss and more th
This commit adds option for enabling SmartAccess Video (SAV)
in AMF encoders. SAV is an AMD hardware-specific feature which
enables the parallelization of encode and decode streams across
multiple Video Codec Engine (VCN) hardware instances.
Signed-off-by: Evgeny Pavlov
---
Changes in v2:
- Enab
On 7/24/23 04:59, Michael Niedermayer wrote:
what ?
libavradio is part of FFmpeg its just a seperate repository.
libavradio will also be part of the 6.1 release, it was even officially
announced. The tweet had over 500 likes IIRC. No sneaking here.
And who made that tweet? Or the decision
Andreas Rheinhardt 于2023年7月24日周一 15:54写道：
>
> Steven Liu:
> > Andreas Rheinhardt 于2023年7月24日周一 15:36写道：
> >>
> >> Steven Liu:
> >>> Signed-off-by: Steven Liu
> >>> ---
> >>> tests/fate/flvenc.mak| 7 +-
> >>> tests/ref/fate/enhanced-flv-hevc | 256 +++
>
Signed-off-by: Steven Liu
---
tests/fate/flvenc.mak | 4 ++
tests/ref/fate/enhanced-flv-av1 | 70 +
2 files changed, 74 insertions(+)
create mode 100644 tests/ref/fate/enhanced-flv-av1
diff --git a/tests/fate/flvenc.mak b/tests/fate/flvenc.mak
index da
Signed-off-by: Steven Liu
---
tests/fate/flvenc.mak | 4
tests/ref/fate/enhanced-flv-vp9 | 18 ++
2 files changed, 22 insertions(+)
create mode 100644 tests/ref/fate/enhanced-flv-vp9
diff --git a/tests/fate/flvenc.mak b/tests/fate/flvenc.mak
index 406d04db1d..dae
Signed-off-by: Steven Liu
---
tests/fate/flvenc.mak| 7 +-
tests/ref/fate/enhanced-flv-hevc | 258 +++
2 files changed, 264 insertions(+), 1 deletion(-)
create mode 100644 tests/ref/fate/enhanced-flv-hevc
diff --git a/tests/fate/flvenc.mak b/tests/fate/
On Mon, Jul 24, 2023 at 10:21 AM Nicolas George wrote:
> Paul B Mahol (12023-07-23):
> > Your comment is extremely rude and unhelpful.
>
> I am sorry for any perceived rudeness. Shall I point each time I find
> your comments to me extremely rude and/or unhelpful too?
>
> > The patch at best only
On Sun, Jul 23, 2023 at 07:48:27PM +0200, Tomas Härdin wrote:
> lör 2023-07-22 klockan 17:40 +0200 skrev Michael Niedermayer:
> > On Sat, Jun 17, 2023 at 12:20:44AM +0200, Michael Niedermayer wrote:
> > > Signed-off-by: Michael Niedermayer
> > > ---
> > > libavutil/tx_template.c | 12
On Mon, Jul 24, 2023 at 10:34 AM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Michael Niedermayer:
> > On Sat, Jun 17, 2023 at 12:20:44AM +0200, Michael Niedermayer wrote:
> >> Signed-off-by: Michael Niedermayer
> >> ---
> >> libavutil/tx_template.c | 12
> >> 1 fil
Michael Niedermayer:
> On Sat, Jun 17, 2023 at 12:20:44AM +0200, Michael Niedermayer wrote:
>> Signed-off-by: Michael Niedermayer
>> ---
>> libavutil/tx_template.c | 12
>> 1 file changed, 12 insertions(+)
>
> will apply patches 1-4
> (this should reduce the differences in the avrad
Andreas Rheinhardt: Thank you for your review! I will try use prefixed length.
发件人: ffmpeg-devel 代表 Andreas Rheinhardt
发送时间: 2023年7月24日 15:25
收件人: ffmpeg-devel@ffmpeg.org
主题: Re: [FFmpeg-devel] [PATCH] add prores bitstream demuxer and muxer
hung kuishing:
> -
Paul B Mahol (12023-07-23):
> Your comment is extremely rude and unhelpful.
I am sorry for any perceived rudeness. Shall I point each time I find
your comments to me extremely rude and/or unhelpful too?
> The patch at best only replaces last get_buffer call of buffersink.
Yes, indeed, that is ex
Michael Niedermayer (12023-07-24):
> There are other pathes forward but thats the current plan _IF_ this
> isnt killed off by the community and _IF_ others join and enjoy
> working on this. Also nothing is cast in stone, this plan is intended
> to be adapted as needed on the way.
I would love to p
Tomas Härdin (12023-07-23):
> No to this entire patchset.
404 argument not found.
> Users can test libavradio's master if they wish. Do not assume merging
> this fork will happen, especially not without TC approval, nor that
> trying to sneak it in won't be noticed and opposed.
A striving Libre
Steven Liu:
> Andreas Rheinhardt 于2023年7月24日周一 15:36写道：
>>
>> Steven Liu:
>>> Signed-off-by: Steven Liu
>>> ---
>>> tests/fate/flvenc.mak| 7 +-
>>> tests/ref/fate/enhanced-flv-hevc | 256 +++
>>> 2 files changed, 262 insertions(+), 1 deletion(-)
>>> cr
Andreas Rheinhardt 于2023年7月24日周一 15:36写道：
>
> Steven Liu:
> > Signed-off-by: Steven Liu
> > ---
> > tests/fate/flvenc.mak| 7 +-
> > tests/ref/fate/enhanced-flv-hevc | 256 +++
> > 2 files changed, 262 insertions(+), 1 deletion(-)
> > create mode 100644
Steven Liu:
> Signed-off-by: Steven Liu
> ---
> tests/fate/flvenc.mak| 7 +-
> tests/ref/fate/enhanced-flv-hevc | 256 +++
> 2 files changed, 262 insertions(+), 1 deletion(-)
> create mode 100644 tests/ref/fate/enhanced-flv-hevc
>
> diff --git a/tests/f
hung kuishing:
> ---
> libavcodec/Makefile| 1 +
> libavcodec/parsers.c | 1 +
> libavcodec/prores_parser.c | 91 ++
> libavformat/Makefile | 2 +
> libavformat/allformats.c | 2 +
> libavformat/proresdec.c| 62 +
73 matches
Mail list logo
