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:
+
+
+
>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:
>> +
>> +
>> +
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
>-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
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
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
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:
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
>
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.
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.
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
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?
> >
> >
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
+
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
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
> >
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
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
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:
> > > > >
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
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
+++
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
>
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
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
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
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
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
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
> 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
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?)
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
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
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
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
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
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
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
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
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
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
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
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
>
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
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
@@
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
---
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
+++
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 -
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
---
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
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
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
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
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
---
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
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
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
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
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
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
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
+++
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
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
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
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
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
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
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
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
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
>
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
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 ++-
> >
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
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
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 =
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
1 - 100 of 113 matches
Mail list logo
