On 2023-11-10 11:09 am, Lynne wrote:
Nov 10, 2023, 05:08 by ffm...@gyani.pro:
On 2023-11-10 03:23 am, Lynne wrote:
Contents:
+ November 10th, 2023, FFmpeg 6.1 "Heaviside"
+
+ FFmpeg 6.1 "Heaviside", a new
+ major release, is now available! Some of the highlights:
+
+
+ lib
>Nov 8, 2023, 02:06 by tong1.wu-at-intel@ffmpeg.org:
>
>> From: Wu Jianhua <> toq...@outlook.com> >
>>
>> Signed-off-by: Wu Jianhua <> toq...@outlook.com> >
>> Signed-off-by: Tong Wu <> tong1...@intel.com> >
>> ---
>> configure | 5 +
>> doc/APIchanges
Nov 10, 2023, 05:08 by ffm...@gyani.pro:
>
>
> On 2023-11-10 03:23 am, Lynne wrote:
>
>> Contents:
>>
>> + November 10th, 2023, FFmpeg 6.1 "Heaviside"
>> +
>> + FFmpeg 6.1 "Heaviside", a new
>> + major release, is now available! Some of the highlights:
>> +
>> +
>> + libaribcaption
On 2023-11-10 03:23 am, Lynne wrote:
Contents:
+ November 10th, 2023, FFmpeg 6.1 "Heaviside"
+
+ FFmpeg 6.1 "Heaviside", a new
+ major release, is now available! Some of the highlights:
+
+
+ libaribcaption decoder
+ Playdate video decoder and demuxer
+ Extend VAAPI suppo
>-Original Message-
>From: ffmpeg-devel On Behalf Of Jean-
>Baptiste Kempf
>Sent: Wednesday, November 8, 2023 7:04 PM
>To: fmpeg-devel
>Subject: Re: [FFmpeg-devel] [PATCH v9 1/9] libavutil: add hwcontext_d3d12va
>and AV_PIX_FMT_D3D12
>
>Hello,
>
>On Wed, 8 Nov 2023, at 02:05, Tong Wu w
On Thu, Nov 09, 2023 at 09:20:33AM +0100, Lynne wrote:
> Nov 7, 2023, 08:36 by d...@lynne.ee:
>
> > Oct 29, 2023, 06:57 by d...@lynne.ee:
> >
> >> Oct 29, 2023, 05:51 by mich...@niedermayer.cc:
> >>
> >>> On Sat, Oct 28, 2023 at 09:23:45PM +0200, Lynne wrote:
> >>>
> Oct 28, 2023, 18:49 by mi
On 11/9/2023 7:00 PM, Alexander Strasser wrote:
On 2023-11-09 12:55 +0100, Michael Niedermayer wrote:
On Thu, Nov 09, 2023 at 10:44:12AM +0100, Anton Khirnov wrote:
As nobody expressed a preference, the vote will start next Monday
(2023-11-13). It should run for a week, and will be followed by
On Thu, Nov 09, 2023 at 12:09:52AM +0100, Michael Niedermayer wrote:
> Hi
>
> At around 8 o clock today there was heavy load on gitweb from the following
> IP ranges
> 27.44.204.*|27.44.125.*|27.44.122.*|14.17.95.*|14.17.85.*|120.233.114.*|120.233.118.*
>
> This caused eventually some process fro
On Thu, Nov 09, 2023 at 10:27:28AM +0100, Dawid Kozinski/Multimedia (PLT)
/SRPOL/Staff Engineer/Samsung Electronics wrote:
> Michael
>
> Could you please apply the following patch
yes, sorry i somehow seem to have forgotten
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF1336
On Wed, Nov 08, 2023 at 03:12:43AM +0100, Michael Niedermayer wrote:
> Fixes: index -1 out of bounds for type 'CFrameBuffer [100]'
> Fixes:
> 63877/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FOURXM_fuzzer-5854263397711872
>
> Found-by: continuous fuzzing process
> https://github.com/googl
On Thu, 9 Nov 2023, at 23:49, Michael Niedermayer wrote:
> On Thu, Nov 09, 2023 at 08:30:15PM +0100, Jean-Baptiste Kempf wrote:
>>
>>
>> On Thu, 9 Nov 2023, at 19:15, Michael Niedermayer wrote:
>> > On Thu, Nov 09, 2023 at 07:53:33PM +0200, Rémi Denis-Courmont wrote:
>> >> Le torstaina 9. marrask
On Thu, Nov 09, 2023 at 08:30:15PM +0100, Jean-Baptiste Kempf wrote:
>
>
> On Thu, 9 Nov 2023, at 19:15, Michael Niedermayer wrote:
> > On Thu, Nov 09, 2023 at 07:53:33PM +0200, Rémi Denis-Courmont wrote:
> >> Le torstaina 9. marraskuuta 2023, 19.41.53 EET Michael Niedermayer a écrit
> >> :
> >
On Thu, Nov 9, 2023 at 3:17 PM Michael Niedermayer
wrote:
> On Thu, Nov 09, 2023 at 08:30:15PM +0100, Jean-Baptiste Kempf wrote:
> >
> >
> > On Thu, 9 Nov 2023, at 19:15, Michael Niedermayer wrote:
> > > On Thu, Nov 09, 2023 at 07:53:33PM +0200, Rémi Denis-Courmont wrote:
> > >> Le torstaina 9. m
On Thu, Nov 09, 2023 at 10:52:19PM +0200, Rémi Denis-Courmont wrote:
> Le torstaina 9. marraskuuta 2023, 22.45.35 EET Alexander Strasser a écrit :
> > I can't see how the reason for the presence of code can be ultimately
> > defined objectively and non-arbitrary.
>
> Ultimately, this was discussed
On Thu, Nov 09, 2023 at 08:15:33PM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2023-11-09 19:50:16)
> > >
> > > > these are lists with roughly 50 entries, now we _know_ 2 people differ
> > >
> > > We don't. You only mention one, whom I adress above. Who is the second?
> >
> > Alex
Contents:
+ November 10th, 2023, FFmpeg 6.1 "Heaviside"
+
+ FFmpeg 6.1 "Heaviside", a new
+ major release, is now available! Some of the highlights:
+
+
+ libaribcaption decoder
+ Playdate video decoder and demuxer
+ Extend VAAPI support for libva-win32 on Windows
+ afireq
On 2023-11-09 12:55 +0100, Michael Niedermayer wrote:
> On Thu, Nov 09, 2023 at 10:44:12AM +0100, Anton Khirnov wrote:
> > As nobody expressed a preference, the vote will start next Monday
> > (2023-11-13). It should run for a week, and will be followed by TC/CC
> > elections.
> >
> > The only extr
On Thu, 9 Nov 2023, Rémi Denis-Courmont wrote:
With a value of zero, the function is a glorified memory copy.
---
tests/checkasm/sbrdsp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/checkasm/sbrdsp.c b/tests/checkasm/sbrdsp.c
index 2fb14d5bf8..5cc3b33215 100644
-
Quoting Nicolas George (2023-11-09 11:47:23)
> Anton Khirnov (12023-11-09):
> > The problem with that code (and the reason this patch exists), is that
> > it depends on the order in which the frames arrive on filtergraph
> > inputs, which is not meaningful (and becomes non-deterministic with
> > th
Hi Anton!
On 2023-11-09 13:15 +0100, Anton Khirnov wrote:
> Quoting Alexander Strasser (2023-11-06 16:56:55)
> > On 2023-11-06 07:10 +0100, Jean-Baptiste Kempf wrote:
> > > Yo,
> > >
> > > Time is up, results are here:
> > > https://vote.ffmpeg.org/cgi-bin/civs/results.pl?id=E_029f7195fed7aadf
> >
hf_gen_c: 2922.7
hf_gen_rvv_f32: 731.5
---
libavcodec/riscv/sbrdsp_init.c | 4 +++
libavcodec/riscv/sbrdsp_rvv.S | 50 ++
2 files changed, 54 insertions(+)
diff --git a/libavcodec/riscv/sbrdsp_init.c b/libavcodec/riscv/sbrdsp_init.c
index c1ed5b639c..e573645
Le torstaina 9. marraskuuta 2023, 22.45.35 EET Alexander Strasser a écrit :
> I can't see how the reason for the presence of code can be ultimately
> defined objectively and non-arbitrary.
Ultimately, this was discussed and decided in a meeting, which Michael
attended (albeit remotely) and for wh
On 2023-11-08 17:58 -0500, Vittorio Giovara wrote:
> On Wed, Nov 8, 2023 at 3:46 PM Alexander Strasser wrote:
>
> > On 2023-11-08 12:40 +0100, Anton Khirnov wrote:
> > > Quoting Michael Niedermayer (2023-10-31 09:40:44)
> > > > On Mon, Oct 30, 2023 at 02:11:27PM +0100, Andreas Rheinhardt wrote:
>
On 2023-11-09 11:13 +0100, Anton Khirnov wrote:
> Quoting Alexander Strasser (2023-11-08 21:55:10)
> > On 2023-11-08 12:40 +0100, Anton Khirnov wrote:
> > > Quoting Michael Niedermayer (2023-10-31 09:40:44)
> > > > On Mon, Oct 30, 2023 at 02:11:27PM +0100, Andreas Rheinhardt wrote:
> > > > > Sectio
Quoting Michael Niedermayer (2023-11-09 21:17:34)
> Not for anything else. Especially not for having vote rights.
Getting vote rights requires one to submit patches publicly.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https:
With a value of zero, the function is a glorified memory copy.
---
tests/checkasm/sbrdsp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/checkasm/sbrdsp.c b/tests/checkasm/sbrdsp.c
index 2fb14d5bf8..5cc3b33215 100644
--- a/tests/checkasm/sbrdsp.c
+++ b/tests/checkas
On Thu, Nov 09, 2023 at 08:30:15PM +0100, Jean-Baptiste Kempf wrote:
>
>
> On Thu, 9 Nov 2023, at 19:15, Michael Niedermayer wrote:
> > On Thu, Nov 09, 2023 at 07:53:33PM +0200, Rémi Denis-Courmont wrote:
> >> Le torstaina 9. marraskuuta 2023, 19.41.53 EET Michael Niedermayer a écrit
> >> :
> >
Le torstaina 9. marraskuuta 2023, 20.34.53 EET Rémi Denis-Courmont a écrit :
> In my personal opinion, we should not need to support unaligned YUY2
> pixel maps. They should always be aligned to at least 32 bits, and the
> current code assumes just 16 bits. However checkasm does test for
> unaligne
On Thu, 9 Nov 2023, at 19:15, Michael Niedermayer wrote:
> On Thu, Nov 09, 2023 at 07:53:33PM +0200, Rémi Denis-Courmont wrote:
>> Le torstaina 9. marraskuuta 2023, 19.41.53 EET Michael Niedermayer a écrit :
> [...]
>> If you think some people should be added, as far as I am concerned, you are
>
Quoting Michael Niedermayer (2023-11-09 19:50:16)
> >
> > > these are lists with roughly 50 entries, now we _know_ 2 people differ
> >
> > We don't. You only mention one, whom I adress above. Who is the second?
>
> Alexander Strasser
It seems clear that none of the three extra GA members were o
On Thu, Nov 09, 2023 at 07:12:24PM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2023-11-09 18:39:23)
> > On Thu, Nov 09, 2023 at 06:06:16PM +0100, Anton Khirnov wrote:
> > > Quoting Michael Niedermayer (2023-11-09 17:21:12)
> > > > On Thu, Nov 09, 2023 at 01:21:13PM +0100, Anton Khirn
On Thu, 9 Nov 2023, Michael Niedermayer wrote:
On Thu, Nov 09, 2023 at 07:53:33PM +0200, Rémi Denis-Courmont wrote:
Le torstaina 9. marraskuuta 2023, 19.41.53 EET Michael Niedermayer a écrit :
[...]
If you think some people should be added, as far as I am concerned, you are of
course welcome
Le torstaina 9. marraskuuta 2023, 20.11.12 EET Cosmin Stejerean via ffmpeg-
devel a écrit :
> > On Nov 9, 2023, at 9:53 AM, Rémi Denis-Courmont wrote:
> >
> > The point is that, whether or not they are on the mailing list, people
> > should
> > not be volunteered to the GA by others, but on thei
In my personal opinion, we should not need to support unaligned YUY2
pixel maps. They should always be aligned to at least 32 bits, and the
current code assumes just 16 bits. However checkasm does test for
unaligned input bitmaps. QEMU accepts it, but real hardware dose not.
In this particular cas
This saves three scratch registers and three instructions per line. The
performance gains are mostly negligible. The main point is to free up
registers for further rework.
---
libswscale/riscv/rgb2rgb_rvv.S | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff --g
Quoting Michael Niedermayer (2023-11-09 19:15:35)
> On Thu, Nov 09, 2023 at 07:53:33PM +0200, Rémi Denis-Courmont wrote:
> > Le torstaina 9. marraskuuta 2023, 19.41.53 EET Michael Niedermayer a écrit :
> [...]
> > If you think some people should be added, as far as I am concerned, you are
> > of
On Thu, Nov 09, 2023 at 07:53:33PM +0200, Rémi Denis-Courmont wrote:
> Le torstaina 9. marraskuuta 2023, 19.41.53 EET Michael Niedermayer a écrit :
[...]
> If you think some people should be added, as far as I am concerned, you are
> of
> course welcome to nudge them via private message to friend
> On Nov 9, 2023, at 9:53 AM, Rémi Denis-Courmont wrote:
>
> The point is that, whether or not they are on the mailing list, people should
> not be volunteered to the GA by others, but on their own volition. The
> circumstances are different for those on the mailing list and those not, but
>
Quoting Michael Niedermayer (2023-11-09 18:39:23)
> On Thu, Nov 09, 2023 at 06:06:16PM +0100, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2023-11-09 17:21:12)
> > > On Thu, Nov 09, 2023 at 01:21:13PM +0100, Anton Khirnov wrote:
> > > > As far as I can tell, the voter list in the last vote
Am 09.11.23 um 18:50 schrieb Michael Niedermayer:
On Thu, Nov 09, 2023 at 06:31:13PM +0100, Jean-Baptiste Kempf wrote:
On Thu, 9 Nov 2023, at 18:24, Michael Niedermayer wrote:
theres a list of voters in 2020 and 2023
The list of voters in 2020 comes from the script written by Josh (IIRC?) and
Le torstaina 9. marraskuuta 2023, 19.41.53 EET Michael Niedermayer a écrit :
> On Thu, Nov 09, 2023 at 07:04:00PM +0200, Rémi Denis-Courmont wrote:
> > Le torstaina 9. marraskuuta 2023, 18.50.52 EET Michael Niedermayer a écrit
:
> > > that said, i checked ML subscribers and found
> > > 16 of the p
On Thu, Nov 09, 2023 at 06:31:13PM +0100, Jean-Baptiste Kempf wrote:
> On Thu, 9 Nov 2023, at 18:24, Michael Niedermayer wrote:
> > theres a list of voters in 2020 and 2023
>
> The list of voters in 2020 comes from the script written by Josh (IIRC?) and
> run by Thilo (?) IIRC when Thilo installe
On Thu, Nov 09, 2023 at 07:04:00PM +0200, Rémi Denis-Courmont wrote:
> Le torstaina 9. marraskuuta 2023, 18.50.52 EET Michael Niedermayer a écrit :
> > that said, i checked ML subscribers and found
> > 16 of the people above to be currently subscribed with email addresses
> > that i found by grepin
On Thu, Nov 9, 2023 at 5:06 PM Anton Khirnov wrote:
>
> Quoting Michael Niedermayer (2023-11-09 17:21:12)
> > On Thu, Nov 09, 2023 at 01:21:13PM +0100, Anton Khirnov wrote:
> > > As far as I can tell, the voter list in the last vote should be the same
> > > as the GA from 2020, except for the extr
On Thu, Nov 09, 2023 at 06:06:16PM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2023-11-09 17:21:12)
> > On Thu, Nov 09, 2023 at 01:21:13PM +0100, Anton Khirnov wrote:
> > > As far as I can tell, the voter list in the last vote should be the same
> > > as the GA from 2020, except for
On Thu, 9 Nov 2023, at 18:24, Michael Niedermayer wrote:
> theres a list of voters in 2020 and 2023
The list of voters in 2020 comes from the script written by Josh (IIRC?) and
run by Thilo (?) IIRC when Thilo installed CIVS.
It quite matches the gitlog.
The list was reused for the vote, and now
On Thu, Nov 09, 2023 at 05:36:10PM +0100, Jean-Baptiste Kempf wrote:
>
>
> On Thu, 9 Nov 2023, at 17:21, Michael Niedermayer wrote:
> > On Thu, Nov 09, 2023 at 01:21:13PM +0100, Anton Khirnov wrote:
> >> Quoting Michael Niedermayer (2023-11-09 12:55:25)
> >> > On Thu, Nov 09, 2023 at 10:44:12AM +
Quoting Michael Niedermayer (2023-11-09 17:21:12)
> On Thu, Nov 09, 2023 at 01:21:13PM +0100, Anton Khirnov wrote:
> > As far as I can tell, the voter list in the last vote should be the same
> > as the GA from 2020, except for the extra members whose voting rights
> > expire after 2 years.
> >
>
Le torstaina 9. marraskuuta 2023, 18.50.52 EET Michael Niedermayer a écrit :
> that said, i checked ML subscribers and found
> 16 of the people above to be currently subscribed with email addresses
> that i found by greping their name. (not posting the list due to privacy
> concerns)
Thing is, if
On Thu, Nov 09, 2023 at 01:21:13PM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2023-11-09 12:55:25)
[...]
> > If the current GA stays as it is, then i propose the following people
> > (this list was quickly made and certainly has omisions and possibly errors,
> > check anything thats
On Thu, Nov 9, 2023 at 10:40 AM Michael Niedermayer
wrote:
> On Thu, Nov 09, 2023 at 07:11:37AM -0500, Vittorio Giovara wrote:
> > On Thu, Nov 9, 2023 at 6:55 AM Michael Niedermayer <
> mich...@niedermayer.cc>
> > wrote:
> >
> > > Fabrice Bellard(Founder of the project over 600 commits in FFm
On Thu, 9 Nov 2023, at 17:21, Michael Niedermayer wrote:
> On Thu, Nov 09, 2023 at 01:21:13PM +0100, Anton Khirnov wrote:
>> Quoting Michael Niedermayer (2023-11-09 12:55:25)
>> > On Thu, Nov 09, 2023 at 10:44:12AM +0100, Anton Khirnov wrote:
>> > > As nobody expressed a preference, the vote will
On Thu, Nov 09, 2023 at 01:21:13PM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2023-11-09 12:55:25)
> > On Thu, Nov 09, 2023 at 10:44:12AM +0100, Anton Khirnov wrote:
> > > As nobody expressed a preference, the vote will start next Monday
> > > (2023-11-13). It should run for a week,
On Thu, Nov 09, 2023 at 07:11:37AM -0500, Vittorio Giovara wrote:
> On Thu, Nov 9, 2023 at 6:55 AM Michael Niedermayer
> wrote:
>
> > Fabrice Bellard(Founder of the project over 600 commits in FFmpeg)
> > Aman Karmani (17 authored commits in 2020-2023, recently active in
> > 2023-June a
Hi,
Le 9 novembre 2023 12:16:28 GMT+02:00, "Dawid Kozinski/Multimedia (PLT)
/SRPOL/Staff Engineer/Samsung Electronics" a écrit :
>Hi,
>
>Both, the implementation of the EVC encoder and decoder for FFmpeg depend on
>external libraries (at least for now). They are just wrappers using external
>
Ping. v6 didn’t changed much compare to v5.
> On Nov 8, 2023, at 00:45, Zhao Zhili wrote:
>
> From: Zhao Zhili
>
> Add vulkan renderer via libplacebo.
>
> Simple usage:
> $ ffplay -hwaccel vulkan foo.mp4
>
> Use cuda to vulkan map:
> $ ffplay -hwaccel cuda foo.mp4
>
> Create vulkan instance
On Thu, Nov 9, 2023 at 12:46 PM Anton Khirnov wrote:
> If nobody objects, I will push 01-07/24 soonish.
>
Only after Nicolas properly reviews this.
> --
> Anton Khirnov
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/
On Thu, Nov 9, 2023 at 12:55 PM Michael Niedermayer
wrote:
> On Thu, Nov 09, 2023 at 10:44:12AM +0100, Anton Khirnov wrote:
> > As nobody expressed a preference, the vote will start next Monday
> > (2023-11-13). It should run for a week, and will be followed by TC/CC
> > elections.
> >
> > The on
Quoting James Almer (2023-11-09 13:24:45)
> Hendrik Leppkes and Reimar Döffinger are active, at least. I agree they
> should be in the GA.
Right, I did not mean to imply ALL the people in the above list are
inactive. But many are.
--
Anton Khirnov
___
From: Niklas Haas
This is at odds with the YUV matrix negotiation API, in which such
dynamic changes in YUV encoding are no longer easily possible. There is
also no really strong motivating reason to do this, since the choice of
YUV matrix is essentially arbitrary and not actually related to the
From: Niklas Haas
Only assigned, never read.
---
libavfilter/vf_zscale.c | 15 ---
1 file changed, 15 deletions(-)
diff --git a/libavfilter/vf_zscale.c b/libavfilter/vf_zscale.c
index 788870ffaf..f76c9954cd 100644
--- a/libavfilter/vf_zscale.c
+++ b/libavfilter/vf_zscale.c
@@ -132,1
From: Niklas Haas
Following the same design as vf_scale.
---
libavfilter/vf_zscale.c | 44 +++--
1 file changed, 34 insertions(+), 10 deletions(-)
diff --git a/libavfilter/vf_zscale.c b/libavfilter/vf_zscale.c
index f76c9954cd..3b14ce4f33 100644
--- a/libavfi
From: Niklas Haas
This filter will always accept any input format, even if the user sets
a specific in_range/in_color_matrix. This is to preserve status quo with
current behavior, where passing a specific in_color_matrix merely
overrides the incoming frames' attributes. (Use `vf_format` to force
From: Niklas Haas
This is never avertised as supported to upstream filters.
---
libavfilter/vf_scale.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index 44dc1f2bf8..dbe380d4c0 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale
From: Niklas Haas
To allow adding proper negotiation, in particular, to fftools.
These values will simply be negotiated downstream for YUV formats, and
ignored otherwise.
---
doc/filters.texi| 10 +++
libavfilter/buffersrc.c | 62 -
libavfilte
From: Niklas Haas
Propagates input metadata to the input filter graph.
---
fftools/ffmpeg_filter.c | 24 +---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index e699798897..dd5cfe4481 100644
--- a/fftools/ffm
From: Niklas Haas
In general, the logic is always the same: if the codec supports only a
single format, enforce it if possible. Otherwise, throw an error when
an incompatible format is thrown.
To preserve backwards compatibility and make this check less pedantic
than it needs to be, always consi
From: Niklas Haas
These no longer exist.
---
libavutil/pixdesc.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index 2886c9e0f5..9244b9d7a8 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -2977,8 +2977,7
From: Niklas Haas
The input file is MPEG range, so we should also encode to MPEG range
before comparing against it. This bug was avoided in the past because
JPEG range YUV inputs were tagged as YUVJ, which resulted in an
automatic conversion to PC range by default.
After YUVJ removal, we will ne
From: Niklas Haas
To convert between color spaces/ranges, if needed by the codec
properties. We momentarily duplicate the mjpeg strictness logic to also
enfoce full range. This duplication will be cleaned up in an upcoming
commit.
Due to avcodec_open2 being called after ofilter_bind_ost, we need
From: Niklas Haas
The only meaningful difference between choose_pix_fmts and the default
code was the inclusion of an extra branch for `keep_pix_fmt` being true.
However, in this case, we either:
1. Force the specific `ofp->format` that we inherited from
ofilter_bind_ost, or if no format was
From: Niklas Haas
Only affects amv and roqvideo. (mjpeg is handled separately by fftools)
---
libavcodec/mjpegenc.c| 3 +++
libavcodec/roqvideoenc.c | 2 ++
2 files changed, 5 insertions(+)
diff --git a/libavcodec/mjpegenc.c b/libavcodec/mjpegenc.c
index 508772987f..c827a47e59 100644
--- a/
From: Niklas Haas
This is motivated primarily by a desire for YUVJ removal, which will
require signalling the supported color ranges as part of the codec
capabilities. But since we're adding YUV range, we might as well add the
YUV color matrix as well - since some codecs (e.g. VP8, JPEG) only
sup
From: Niklas Haas
Mirroring the previous commit, all codecs which previously never
accepted YUVJ now need to be labelled as MPEG range only.
TODO:
- add the rest of the codecs
---
libavcodec/mpeg4videoenc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/mpeg4videoenc.c b/liba
From: Niklas Haas
Needed for fftools/ffmpeg_filter to be able to force specific output
formats via the filter chain.
---
doc/filters.texi| 8
libavfilter/vf_format.c | 44 +
2 files changed, 48 insertions(+), 4 deletions(-)
diff --git a/
From: Niklas Haas
Which will impose no restriction. This makes sense when using e.g.
`color_ranges=pc` to limit the color range, without also limiting the
pixel format.
---
libavfilter/vf_format.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/libavfilter/vf_format.
From: Niklas Haas
Needed for fftools.
---
doc/APIchanges | 3 +++
libavfilter/buffersink.c | 2 ++
libavfilter/buffersink.h | 2 ++
libavfilter/version.h| 2 +-
4 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index ce3f90a674..97b6de827
From: Niklas Haas
Rewrite the format parsing code to make it more easily generalizable. In
particular, `invert_formats` does not depend on the type of format list
passed to it, which allows me to re-use this helper in an upcoming
commit.
Slightly shortens the code, at the sole cost of doing seve
From: Niklas Haas
---
libavfilter/vf_libplacebo.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/libavfilter/vf_libplacebo.c b/libavfilter/vf_libplacebo.c
index b6e82a61e0..a9a3d884ce 100644
--- a/libavfilter/vf_libplacebo.c
+++ b/libavfilter/vf_l
From: Niklas Haas
This memset is bogus, it accomplishes nothing in the best case and
regresses future additions to AVBufferSrcParameters in the worst case.
---
fftools/ffmpeg_filter.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index b7
From: Niklas Haas
Motivated by YUVJ removal. This change will allow full negotiation
between color ranges and matrices as needed. By default, all ranges and
matrices are marked as supported.
Because grayscale formats are currently handled very inconsistently (and
in particular, assumed as forced
From: Niklas Haas
Even if a query func is set. This is safe to do, because
ff_default_query_formats is documented not to touch any filter lists
that were already set by the query func.
The reason to do this is because it allows us to extend
AVFilterFormatsConfig without having to touch every fil
Following up on the previous attempts at YUVJ removal, this series
implements full filter negotiation. It is WIP because I still need to go
through the remaining AVCodec (which are not covered by FATE) and
properly tag their colorspace and color range support. (See patch 19/25)
The rest should be
From: Niklas Haas
In particular, make it clear that this function will not touch format
lists which were already set by the caller before calling into this
function.
---
libavfilter/formats.h | 4
1 file changed, 4 insertions(+)
diff --git a/libavfilter/formats.h b/libavfilter/formats.h
in
On 11/9/2023 9:21 AM, Anton Khirnov wrote:
Quoting Michael Niedermayer (2023-11-09 12:55:25)
On Thu, Nov 09, 2023 at 10:44:12AM +0100, Anton Khirnov wrote:
As nobody expressed a preference, the vote will start next Monday
(2023-11-13). It should run for a week, and will be followed by TC/CC
ele
Quoting Michael Niedermayer (2023-11-09 12:55:25)
> On Thu, Nov 09, 2023 at 10:44:12AM +0100, Anton Khirnov wrote:
> > As nobody expressed a preference, the vote will start next Monday
> > (2023-11-13). It should run for a week, and will be followed by TC/CC
> > elections.
> >
> > The only extra G
Quoting Alexander Strasser (2023-11-06 16:56:55)
> Hi all,
> hi J-B!
>
> On 2023-11-06 07:10 +0100, Jean-Baptiste Kempf wrote:
> > Yo,
> >
> > Time is up, results are here:
> > https://vote.ffmpeg.org/cgi-bin/civs/results.pl?id=E_029f7195fed7aadf
>
> Should I have been mailed about this vote?
>
On Thu, 9 Nov 2023, at 12:55, Michael Niedermayer wrote:
> If the current GA stays as it is, then i propose the following people
Most of those people have not been active for years.
Adding the people who were part of the GA before;
or are just under the threshold, but were active before;
or a
On Thu, Nov 9, 2023 at 6:55 AM Michael Niedermayer
wrote:
> Fabrice Bellard(Founder of the project over 600 commits in FFmpeg)
> Aman Karmani (17 authored commits in 2020-2023, recently active in
> 2023-June and work all over the codebase)
> Baptiste Coudurier (Pays for our fate server
Quoting James Almer (2023-11-09 12:47:56)
> On 11/9/2023 8:41 AM, Anton Khirnov wrote:
> > Quoting James Almer (2023-11-04 14:39:44)
> >> On 11/4/2023 4:56 AM, Anton Khirnov wrote:
> >>> This will be the appropriate place for it after the rest of transcoding
> >>> is switched to a threaded architec
On Thu, Nov 09, 2023 at 10:44:12AM +0100, Anton Khirnov wrote:
> As nobody expressed a preference, the vote will start next Monday
> (2023-11-13). It should run for a week, and will be followed by TC/CC
> elections.
>
> The only extra GA candidate I see proposed so far is Ronald. If anyone
> wants
On 11/9/2023 8:41 AM, Anton Khirnov wrote:
Quoting James Almer (2023-11-04 14:39:44)
On 11/4/2023 4:56 AM, Anton Khirnov wrote:
This will be the appropriate place for it after the rest of transcoding
is switched to a threaded architecture.
---
fftools/ffmpeg_mux.c | 112 +
If nobody objects, I will push 01-07/24 soonish.
--
Anton Khirnov
___
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 sub
As previously for decoding, this is merely "scaffolding" for moving to a
fully threaded architecture and does not yet make filtering truly
parallel - the main thread will currently wait for the filtering thread
to finish its work before continuing. That will change in future commits
after encoders
Quoting James Almer (2023-11-04 14:39:44)
> On 11/4/2023 4:56 AM, Anton Khirnov wrote:
> > This will be the appropriate place for it after the rest of transcoding
> > is switched to a threaded architecture.
> > ---
> > fftools/ffmpeg_mux.c | 112 ++-
> > 1
Quoting Michael Niedermayer (2023-11-04 19:44:09)
> On Sat, Nov 04, 2023 at 08:56:27AM +0100, Anton Khirnov wrote:
> > See the comment block at the top of fftools/ffmpeg_sched.h for more
> > details on what this scheduler is for.
> >
> > This commit adds the scheduling code itself, along with mini
See the comment block at the top of fftools/ffmpeg_sched.h for more
details on what this scheduler is for.
This commit adds the scheduling code itself, along with minimal
integration with the rest of the program:
* allocating and freeing the scheduler
* passing it throughout the call stack in orde
Quoting James Almer (2023-11-04 14:53:25)
> On 11/4/2023 4:56 AM, Anton Khirnov wrote:
> > +static void *task_wrapper(void *arg)
> > +{
> > +SchTask *task = arg;
> > +Scheduler *sch = task->parent;
> > +int ret;
> > +int err = 0;
> > +
> > +ret = (intptr_t)task->func(task->func
Anton Khirnov (12023-11-09):
> The problem with that code (and the reason this patch exists), is that
> it depends on the order in which the frames arrive on filtergraph
> inputs, which is not meaningful (and becomes non-deterministic with
> threading).
I can understand that. We will have to find
Quoting Nicolas George (2023-11-04 15:19:00)
> Anton Khirnov (12023-11-04):
> > It only seems to produce duplicate frames.
>
> Yes it does, that is the point of it. Without the duplicated frame, a
> filter with synchronized inputs (like overlay) will accumulate video
> frames while waiting for the
1 - 100 of 113 matches
Mail list logo