On Mon, Jan 29, 2024 at 8:58 AM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Michael Niedermayer:
> > On Sun, Jan 28, 2024 at 08:52:20PM -0300, James Almer wrote:
> >> On 1/28/2024 7:41 PM, Michael Niedermayer wrote:
> >>> On Sun, Jan 28, 2024 at 02:49:26PM +0100, Andreas Rheinhar
On Sun, Jan 28, 2024 at 10:32 PM Connor Worley
wrote:
> I'd like to get this series merged before doing any further DXV work. Is
> anyone able to help with uploading the linked samples?
>
I unfortunately don't have access to the FATE samples server, can you mail
samples-requ...@ffmpeg.org?
--
V
>On 2024-01-28 04:24 pm, Anton Khirnov wrote:
>> Quoting Gyan Doshi (2024-01-26 05:23:50)
>>>
>>> On 2024-01-25 06:47 pm, Andreas Rheinhardt wrote:
Gyan Doshi:
>> On 2024-01-25 10:29 am, Andreas Rheinhardt wrote:
>> Gyan Doshi:
>>> Set up framework for non-PCM decoding in-place and
On Sun, Jan 28, 2024 at 11:47 PM Michael Niedermayer
wrote:
> On Sun, Jan 28, 2024 at 01:28:36PM +0100, Anton Khirnov wrote:
> > Previously, the implicit standard was to wait 2 years before deprecation
> > and removal, but it has been widely agreed at developer meetings that
> > time-based measur
Anton Khirnov:
> ---
> libavcodec/Makefile | 49 +---
> libavcodec/bsf/Makefile | 57 +++
> .../aac_adtstoasc.c} | 0
> .../av1_frame_merge.c}| 0
> .../av1_frame_split.c}
Connor Worley:
> Adds tests to cover decoding YCoCg DXV3 formats with and without alpha
>
> Samples:
> https://connorworley.com/fate-suite/dxv/dxv3-hqna.mov
> https://connorworley.com/fate-suite/dxv/dxv3-hqwa.mov
> Signed-off-by: Connor Worley
> ---
> tests/fate/video.mak | 6 ++
> tests
On 2024-01-29 02:57 pm, Nicolas Gaullier wrote:
On 2024-01-28 04:24 pm, Anton Khirnov wrote:
Quoting Gyan Doshi (2024-01-26 05:23:50)
On 2024-01-25 06:47 pm, Andreas Rheinhardt wrote:
Gyan Doshi:
On 2024-01-25 10:29 am, Andreas Rheinhardt wrote:
Gyan Doshi:
Set up framework for non-PCM dec
On Mon, 29 Jan 2024 at 10:17, Gyan Doshi wrote:
>
>
> On 2024-01-29 02:57 pm, Nicolas Gaullier wrote:
> >> On 2024-01-28 04:24 pm, Anton Khirnov wrote:
> >>> Quoting Gyan Doshi (2024-01-26 05:23:50)
> On 2024-01-25 06:47 pm, Andreas Rheinhardt wrote:
> > Gyan Doshi:
> >>> On 2024-01-
Quoting Andreas Rheinhardt (2024-01-29 10:57:19)
> Anton Khirnov:
> > +# add libavcodec/ to include path for bsfs
> > +$(addprefix libavcodec/, $(sort $(filter bsf/%,$(OBJS_BSF-yes:
> > CPPFLAGS += -I$(SRC_PATH)/libavcodec/
>
> 1. Why sort?
To get rid of duplicates, otherwise the flags can b
Please ignore this version of the patch. I'll send out v2 soon. Apologies
for the noise.
On Thu, Jan 25, 2024 at 6:13 PM Dariusz Marcinkiewicz
wrote:
> This exposes VP8E_SET_SCREEN_CONTENT_MODE option from libvpx.
>
> Change authored by Erik Språng
>
> Signed-off-by: Dariusz Marcinkiewicz
> --
On Sat, 27 Jan 2024 at 16:57, Nuo Mi wrote:
>
>
> On Sat, Jan 27, 2024 at 10:38 PM James Almer wrote:
>
>> On 1/27/2024 1:15 AM, Nuo Mi wrote:
>> > diff --git a/libavformat/isom_tags.c b/libavformat/isom_tags.c
>> > index a575b7c160..705811e950 100644
>> > --- a/libavformat/isom_tags.c
>> > +++
Anton Khirnov:
> Quoting Andreas Rheinhardt (2024-01-29 10:57:19)
>> Anton Khirnov:
>>> +# add libavcodec/ to include path for bsfs
>>> +$(addprefix libavcodec/, $(sort $(filter bsf/%,$(OBJS_BSF-yes:
>>> CPPFLAGS += -I$(SRC_PATH)/libavcodec/
>>
>> 1. Why sort?
>
> To get rid of duplicates, ot
Quoting Michael Niedermayer (2024-01-28 23:47:06)
> On Sun, Jan 28, 2024 at 01:28:36PM +0100, Anton Khirnov wrote:
> > Previously, the implicit standard was to wait 2 years before deprecation
> > and removal, but it has been widely agreed at developer meetings that
> > time-based measures do not ma
Quoting Andreas Rheinhardt (2024-01-29 11:55:19)
> Anton Khirnov:
> > Quoting Andreas Rheinhardt (2024-01-29 10:57:19)
> >> Anton Khirnov:
> >>> +# add libavcodec/ to include path for bsfs
> >>> +$(addprefix libavcodec/, $(sort $(filter bsf/%,$(OBJS_BSF-yes:
> >>> CPPFLAGS += -I$(SRC_PATH)/lib
---
libavcodec/Makefile | 55 +++
libavcodec/bsf/Makefile | 49 +
.../aac_adtstoasc.c} | 0
.../av1_frame_merge.c}| 0
.../av1_frame_split.c}|
пн, 29 янв. 2024 г., 13:55 Anton Khirnov :
> Quoting Michael Niedermayer (2024-01-28 23:47:06)
> > On Sun, Jan 28, 2024 at 01:28:36PM +0100, Anton Khirnov wrote:
> > > Previously, the implicit standard was to wait 2 years before
> deprecation
> > > and removal, but it has been widely agreed at dev
Anton Khirnov:
> ---
> libavcodec/Makefile | 55 +++
> libavcodec/bsf/Makefile | 49 +
> .../aac_adtstoasc.c} | 0
> .../av1_frame_merge.c}| 0
> .../av1_frame_split.c
On Mon, Jan 29, 2024 at 11:29 AM Zhao Zhili wrote:
>
> >
> > If someone can show me code in FFmpeg that parses loaded data as text,
> > I can follow
> > that and send a new patch. This is to avoid doing things the wrong
> > way, as I'm a newcomer
> > and don't know if there's existing code to do t
On Mon, Jan 29, 2024 at 10:31:02AM +0100, Vittorio Giovara wrote:
> On Sun, Jan 28, 2024 at 11:47 PM Michael Niedermayer
> wrote:
>
> > On Sun, Jan 28, 2024 at 01:28:36PM +0100, Anton Khirnov wrote:
> > > Previously, the implicit standard was to wait 2 years before deprecation
> > > and removal,
On Mon, Jan 29, 2024 at 02:20:00PM +0300, Andrew Randrianasulu wrote:
> пн, 29 янв. 2024 г., 13:55 Anton Khirnov :
>
> > Quoting Michael Niedermayer (2024-01-28 23:47:06)
> > > On Sun, Jan 28, 2024 at 01:28:36PM +0100, Anton Khirnov wrote:
> > > > Previously, the implicit standard was to wait 2 ye
I have slightly adjusted the rvv and updated patch in this reply.
flow gg 于2023年12月20日周三 18:15写道：
> Because the format of [PATCH 1/3] was modified, this patch needs to be
> changed, and it has been modified in this reply.
>
> flow gg 于2023年12月20日周三 16:41写道：
>
>> C908:
>> get_pixels_8x4_sym_c: 2
On 1/28/2024 3:25 AM, Michael Niedermayer wrote:
> At this point, what we need is a list of Projects so we can submit an
> application to STF
> at or before 12th Feb. (at the 14th they have a meeting and will review our
> submission)
> What STF told us, they need ATM is:
As others have said, the
On 1/29/2024 2:26 AM, Jonatas L. Nogueira via ffmpeg-devel wrote:
> Because the General Assembly will already have exercised its sovereignty
> before the work started.
The contract needs to be shared with the GA for it to be able to actually
exercise its sovereignty.
Frankly this all seems pretty
Major chagnes since v3:
movenc: ff_mov_write_packet, get cenc nal_size_length from par->extradata[4]
(James, Thomas)
isom_tags: remove vvc from ff_codec_movvideo_tags (James)
mpegtsenc: mpegts_check_bitstream, use long variable names to enhance code
readability.(Andreas)
mpegtsenc: mpegps_read_pa
---
libavformat/mpegtsenc.c | 33 ++---
1 file changed, 18 insertions(+), 15 deletions(-)
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 84edd418f0..4e5c264d2a 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -2257,23 +2257,26
From: Thomas Siedel
Add muxer for vvcc byte stream format.
Add AV_CODEC_ID_VVC to ff_mp4_obj_type.
Add AV_CODEC_ID_VVC to ISO Media codec (VvcConfigurationBox vvi1,
vvc1 defined in ISO/IEC 14496-15:2021).
Add VvcConfigurationBox vvcC which extends FullBox type in
ISO/IEC 14496-15:2021.
Tested wi
---
libavformat/mpegtsenc.c | 26 --
1 file changed, 8 insertions(+), 18 deletions(-)
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 4e5c264d2a..5e089f2866 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -1759,16 +1759,16 @@ stat
---
libavformat/mpegtsenc.c | 32 +++-
1 file changed, 19 insertions(+), 13 deletions(-)
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 5e089f2866..3872be0f46 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -31,6 +31,7 @@
#i
From: Thomas Siedel
Add transport stream stream type 0x33 for vvc.
Add STREAM_TYPE_VIDEO_VVC to MPEG-1/2 and MPEG-2 transport stream.
Add basic transport stream support for TS mux/demux.
Tested with:
ffmpeg -i NovosobornayaSquare_1920x1080.mp4 -c:v libvvenc test.ts && ffmpeg -i
test.ts -f null
---
libavformat/mpegtsenc.c | 45 +
1 file changed, 28 insertions(+), 17 deletions(-)
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 3872be0f46..7bc3feaef1 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -1834,6 +
>
>
> >> [...] the GA definitly cannot object to an invoice for a project that
> the GA approved previously.
> > "The General Assembly is sovereign and legitimate for all its decisions
> regarding the FFmpeg project."
>
> When working with a contract (and a SOW), the General Assembly won't be
> abl
On 1/29/2024 3:02 PM, Kieran Kunhya wrote:
> In this project, acceptance of a patch is based on the technical contents
> of a patch, not a few vague paragraphs in a SoW. These decisions are made
> by the Technical Committee and the General Assembly.
>
> Tying the project contractually is unaccepta
On Fri, 26 Jan 2024 at 16:22, Nuo Mi wrote:
>
>
> On Fri, Jan 26, 2024 at 10:04 PM Thomas Siedel
> wrote:
>
>> Thanks for picking up the patch set!
>>
>> On Thu, 25 Jan 2024 at 13:26, Nuo Mi wrote:
>>
>>> From: Thomas Siedel
>>>
>>> Add muxer for vvcc byte stream format.
>>> Add AV_CODEC_ID_VV
Hi,
+/*
+ * Copyright (c) 2023 Institue of Software Chinese Academy of Sciences
(ISCAS).
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Softwar
> I expect that it would be faster to make one large load, and then 4 small
> stores, but that might work only for exactly 128-bit vectors?
This seems to require vle128, so I didn't modify it.
> That's not needed. You can use immediate values.
> You can reorder to avoid immediate data dependencie
Again, this sounds like a misunderstanding.
The SOW is subservient to the merge, not the other way around. In other
words, the SOW don't require you to merge, but when/if you do merge, then
the SOW will require the payment to the contractor, which SPI handles. So
the SOW makes clear that if FFmpeg
> This is also why there's no need to review the invoices, and no risk of a
> legitimate invoice being rejected: Because the deliverable will likely be
> the commit (unless the GA objects beforehand and asks SPI to use something
> else), so until it (the MR/PR) is accepted, there's no invoice to st
Quoting Chen Yufei (2024-01-29 04:01:51)
> On Sun, Jan 28, 2024 at 10:10 PM Anton Khirnov wrote:
> >
> > Quoting Zhao Zhili (2024-01-28 14:51:58)
> > >
> > >
> > > > On Jan 28, 2024, at 18:31, Anton Khirnov wrote:
> > > >
> > > > Quoting Chen Yufei (2024-01-25 17:16:46)
> > > >> On Wed, Jan 24, 2
Hi, out of curiosity, I did not know 44.1/32 is supported on DVD PCM. Does
this type of output work on an actual DVD player? Thank you
On Mon, Jan 22, 2024 at 3:59 AM Andrew Randrianasulu <
randrianas...@gmail.com> wrote:
> -- Forwarded message -
> От: Andrew Randrianasulu
> Dat
Quoting Andrew Randrianasulu (2024-01-29 12:20:00)
> пн, 29 янв. 2024 г., 13:55 Anton Khirnov :
>
> > Quoting Michael Niedermayer (2024-01-28 23:47:06)
> > > On Sun, Jan 28, 2024 at 01:28:36PM +0100, Anton Khirnov wrote:
> > > > Previously, the implicit standard was to wait 2 years before
> > depr
Hello Kieran
On Mon, Jan 29, 2024 at 03:02:24PM +, Kieran Kunhya wrote:
> >
> >
> > >> [...] the GA definitly cannot object to an invoice for a project that
> > the GA approved previously.
> > > "The General Assembly is sovereign and legitimate for all its decisions
> > regarding the FFmpeg pr
>
> Mysteriously, there was a total absence of similar drama there.
> I wonder how it could have been possible to do that for over a decade
> with not one instance of drama or problems like here.
>
> We had students passing the mentors review, being paid but code was
> found not be clean enough yet
Le maanantaina 29. tammikuuta 2024, 19.27.14 EET Michael Niedermayer a écrit :
> Also FFmpeg has been part of Google summer of code for many many years
> and also in the past in outreachy. All these projects payed "students"
> for work they did.
> From a legal point of view, these are probably very
On Mon, Jan 29, 2024 at 07:43:17PM +0200, Rémi Denis-Courmont wrote:
> Le maanantaina 29. tammikuuta 2024, 19.27.14 EET Michael Niedermayer a écrit :
> > Also FFmpeg has been part of Google summer of code for many many years
> > and also in the past in outreachy. All these projects payed "students"
Hi Derek
On Mon, Jan 29, 2024 at 02:38:42PM +, Derek Buitenhuis wrote:
> On 1/28/2024 3:25 AM, Michael Niedermayer wrote:
> > At this point, what we need is a list of Projects so we can submit an
> > application to STF
> > at or before 12th Feb. (at the 14th they have a meeting and will revie
On Sun, 28 Jan 2024 at 21:47, Michael Niedermayer
wrote:
> Hi Kieran
>
> On Sun, Jan 28, 2024 at 08:42:00PM +, Kieran Kunhya wrote:
> > On Sun, 28 Jan 2024, 20:37 Kieran Kunhya, wrote:
> >
> > > Both work fine really. For example iam not employed by FFlabs and the
> work
> > >> i did for the
I could generate smaller samples if preferred. I opted to match the
existing NQ ones.
On Mon, Jan 29, 2024 at 1:56 AM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Connor Worley:
> > Adds tests to cover decoding YCoCg DXV3 formats with and without alpha
> >
> > Samples:
> > https:
>> On 1/28/2024 3:25 AM, Michael Niedermayer wrote:
>> As others have said, the whole model of using discrete projects here seems
>> opposed to
>> the actual intent of the STF - maintained and stable OSS long term.
>
> The whole suggestion here is based on what STF and SPI said. There was a
> co
Tested-by: Jiří Eliášek, Misha Aizatulin
---
Now requested an infinite timeout from
IDXGIOutputDuplication_AcquireNextFrame() when a frame is required.
---
doc/filters.texi | 15 +++
libavfilter/vsrc_ddagrab.c | 9 +++--
2 files changed, 18 insertions(+), 6 deletions(-)
Analogous to the (a)showinfo lavfi filters, logs basic packet
information. Mainly useful for debugging/testing/development.
---
Changelog | 1 +
doc/bitstream_filters.texi | 4 +++
libavcodec/bitstream_filters.c | 1 +
libavcodec/bsf/Makefile| 1 +
libavcodec/b
I'm not sure how I would write it in a way that isn't a repetition of the
new definition of ctx->tex_size
On Sun, Jan 28, 2024 at 11:52 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Connor Worley:
> > Signed-off-by: Connor Worley
> > ---
> > libavcodec/dxv.c | 53
Please keep in mind we're a public charity using public money from
taxpayers, which means we need a criteria for payments and that said
payments must be issued objectively. The GA might be able to distribute
money with subjective criterias... But not this specific money which is
being discussed. I
On Mon, 29 Jan 2024 04:19:43 +0100 Michael Niedermayer
wrote:
> On Sun, Dec 31, 2023 at 09:49:47PM +, Niklas Haas wrote:
> > ffmpeg | branch: master | Niklas Haas | Tue Oct 31
> > 13:52:53 2023 +0100| [45e09a30419cc2a7251e72689142e021ecdfe6d9] |
> > committer: Niklas Haas
> >
> > vf_scale
Hi Kieran
On Mon, Jan 29, 2024 at 06:31:30PM +, Kieran Kunhya wrote:
> On Sun, 28 Jan 2024 at 21:47, Michael Niedermayer
> wrote:
>
> > Hi Kieran
> >
> > On Sun, Jan 28, 2024 at 08:42:00PM +, Kieran Kunhya wrote:
> > > On Sun, 28 Jan 2024, 20:37 Kieran Kunhya, wrote:
> > >
> > > > Both
On 29.01.2024 19:31, Anton Khirnov wrote:
Tested-by: Jiří Eliášek, Misha Aizatulin
---
Now requested an infinite timeout from
IDXGIOutputDuplication_AcquireNextFrame() when a frame is required.
---
doc/filters.texi | 15 +++
libavfilter/vsrc_ddagrab.c | 9 +++--
2 f
Quoting Timo Rothenpieler (2024-01-29 19:55:26)
> On 29.01.2024 19:31, Anton Khirnov wrote:
> > { NULL }
> > };
> >
> > @@ -688,7 +691,7 @@ static int next_frame_internal(AVFilterContext *avctx,
> > ID3D11Texture2D **desktop
> >
> > hr = IDXGIOutputDuplication_AcquireNextFrame(
On Mon, 29 Jan 2024, 18:54 Michael Niedermayer,
wrote:
>
> > You weren't willing to compromise last time
> > for your hobby, what makes you willing to compromise in that situation?
>
> This insult is unacceptable.
> I just a few days ago stated that i intend to implement SDR within what the
> com
Tested-by: Jiří Eliášek, Misha Aizatulin
---
doc/filters.texi | 15 +++
libavfilter/vsrc_ddagrab.c | 7 ++-
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 1d70f4d934..b9b539acee 100644
--- a/doc/filters.texi
+++
On 1/27/2024 9:05 PM, Michael Niedermayer wrote:
On Sat, Jan 27, 2024 at 09:02:30PM -0300, James Almer wrote:
On 1/27/2024 8:56 PM, Michael Niedermayer wrote:
On Sat, Jan 27, 2024 at 09:25:16AM -0300, James Almer wrote:
On 1/26/2024 6:46 PM, Michael Niedermayer wrote:
It is not possible to en
Hi Derek
On Mon, Jan 29, 2024 at 06:37:44PM +, Derek Buitenhuis wrote:
> >> On 1/28/2024 3:25 AM, Michael Niedermayer wrote:
> >> As others have said, the whole model of using discrete projects here seems
> >> opposed to
> >> the actual intent of the STF - maintained and stable OSS long term.
On Mon, Jan 29, 2024 at 10:09:52AM +0100, Vittorio Giovara wrote:
> On Mon, Jan 29, 2024 at 8:58 AM Andreas Rheinhardt <
> andreas.rheinha...@outlook.com> wrote:
>
> > Michael Niedermayer:
> > > On Sun, Jan 28, 2024 at 08:52:20PM -0300, James Almer wrote:
> > >> On 1/28/2024 7:41 PM, Michael Niede
On Mon, Jan 29, 2024 at 8:16 PM Marth64 wrote:
>
> Hi, out of curiosity, I did not know 44.1/32 is supported on DVD PCM. Does
> this type of output work on an actual DVD player?
We try to determinate this, but unfortunately new DVD players a bit
TOO flexible and forgiving?
https://lists.cinele
On Mon, Jan 29, 2024 at 08:24:21PM +0100, Michael Niedermayer wrote:
> On Mon, Jan 29, 2024 at 10:09:52AM +0100, Vittorio Giovara wrote:
> > On Mon, Jan 29, 2024 at 8:58 AM Andreas Rheinhardt <
> > andreas.rheinha...@outlook.com> wrote:
> >
> > > Michael Niedermayer:
> > > > On Sun, Jan 28, 2024 a
On 29.01.2024 20:03, Anton Khirnov wrote:
Tested-by: Jiří Eliášek, Misha Aizatulin
---
doc/filters.texi | 15 +++
libavfilter/vsrc_ddagrab.c | 7 ++-
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 1d70f4d934
On Mon, Jan 29, 2024 at 07:02:57PM +, Kieran Kunhya wrote:
> On Mon, 29 Jan 2024, 18:54 Michael Niedermayer,
> wrote:
>
> >
> > > You weren't willing to compromise last time
> > > for your hobby, what makes you willing to compromise in that situation?
> >
> > This insult is unacceptable.
> >
On Mon, Jan 29, 2024 at 8:22 PM Michael Niedermayer
wrote:
> > I have yet to see an actual project of "this magnitude" materialize as a
> proposal.
>
> you can suggest one ?
>
libavscale!
or there is nothing you want improved in FFmpeg ?
> Or only if SPI isnt involved or iam not sure what exact
On 1/29/2024 8:09 PM, Vittorio Giovara wrote:
> This is not something that should be discussed on a public ML and the lack
> of visibility and clarity on how SPI/STM got involved this time around is
> at least disingenuous IMO.
I am more curious how Thilo managed to insert himself as the sole repr
Quoting Vittorio Giovara (2024-01-29 21:09:42)
> This is not something that should be discussed on a public ML
Where do you think it should be discussed then?
I, for one, see a much bigger problem in the fact that it only starts
being discussed on the ML this late, after so much underground deali
On 29/01/2024 19:04, James Almer wrote:
Well, turns out the current code is fine and my suggested change above
is wrong. Fun how that goes.
Can you test the following instead?
diff --git a/libavcodec/cbs_h266_syntax_template.c
b/libavcodec/cbs_h266_syntax_template.c
index 549d021211..30b4
On 1/29/2024 8:19 PM, Anton Khirnov wrote:
> I, for one, see a much bigger problem in the fact that it only starts
> being discussed on the ML this late, after so much underground dealings
> that bypassed the community entirely.
+1
- Derek
___
ffmpeg-de
On Mon, Jan 29, 2024 at 9:19 PM Anton Khirnov wrote:
> Quoting Vittorio Giovara (2024-01-29 21:09:42)
> > This is not something that should be discussed on a public ML
>
> Where do you think it should be discussed then?
>
IMO anywhere with a more limited set of constituents, such as the GA or th
On Mon, Jan 29, 2024 at 9:10 PM Vittorio Giovara
wrote:
>
> On Mon, Jan 29, 2024 at 8:22 PM Michael Niedermayer
> wrote:
>
> > > I have yet to see an actual project of "this magnitude" materialize as a
> > proposal.
> >
> > you can suggest one ?
> >
>
> libavscale!
Not being a regular, this may
Le maanantaina 29. tammikuuta 2024, 20.11.19 EET Michael Niedermayer a écrit :
> > The "drama" is about how and through whom the funding goes.
>
> ok, elaborate please
>
> All FFmpeg money has always been handled through SPI or associated entities
It was already a bit of a stretch to compare GSo
Quoting Michael Niedermayer (2024-01-28 04:25:49)
> There can be no late objections here to any project suggestions.
> Objections must be before a project suggestion is submitted to STF,
> objections after that cannot be considered!
Self-imposed restrictions like these at the very least need a GA
On 1/29/2024 5:19 PM, Frank Plowman wrote:
On 29/01/2024 19:04, James Almer wrote:
Well, turns out the current code is fine and my suggested change above
is wrong. Fun how that goes.
Can you test the following instead?
diff --git a/libavcodec/cbs_h266_syntax_template.c
b/libavcodec/cbs_h2
Quoting Diederick C. Niehorster (2024-01-29 21:41:29)
> On Mon, Jan 29, 2024 at 9:10 PM Vittorio Giovara
> wrote:
> >
> > On Mon, Jan 29, 2024 at 8:22 PM Michael Niedermayer
> > wrote:
> >
> > > > I have yet to see an actual project of "this magnitude" materialize as a
> > > proposal.
> > >
> > >
Hi
On Mon, Jan 29, 2024 at 09:36:27PM +0100, Vittorio Giovara wrote:
> On Mon, Jan 29, 2024 at 9:19 PM Anton Khirnov wrote:
>
> > Quoting Vittorio Giovara (2024-01-29 21:09:42)
> > > This is not something that should be discussed on a public ML
> >
> > Where do you think it should be discussed t
Quoting Kieran Kunhya (2024-01-28 20:34:46)
> The threading changes took the best part of a year and are still ongoing.
Over two years actually. I started working on it in November 2021.
And I agree that estimating the amount of work needed is a HUGE problem,
in both directions.
--
Anton Khirnov
On 26/01/2024 07:25, Xiang, Haihao wrote:
On Wo, 2023-12-20 at 15:10 +0800, Xiang, Haihao wrote:
From: Haihao Xiang
This allows a downstream element stores more frames from VAAPI
decoders and fixes error in get_buffer()
$ ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi -i input_100frames.m
> On Jan 28, 2024, at 7:54 AM, Kieran Kunhya wrote:
>
> So work like Anton's threading, YUVJ removal etc, that couldn't be funded
> via bounties as they have no direct commercial value but require expertise
> in the codebase.
> Statements of Work and milestones (by definition) are for features.
On 29/01/2024 21:13, James Almer wrote:
On 1/29/2024 5:19 PM, Frank Plowman wrote:
Below is a patch which addresses the issue, an integer overflow when
calculating the bounds for
vps_num_ols_timing_hrd_params_minus1. There's also a similar fix for
vps_num_dpb_params_minus1.
diff --git a/lib
On Mon, 29 Jan 2024, 22:23 Cosmin Stejerean via ffmpeg-devel, <
ffmpeg-devel@ffmpeg.org> wrote:
>
>
> > On Jan 28, 2024, at 7:54 AM, Kieran Kunhya wrote:
> >
> > So work like Anton's threading, YUVJ removal etc, that couldn't be funded
> > via bounties as they have no direct commercial value but
Hi
On Mon, Jan 29, 2024 at 11:01:05PM +0200, Rémi Denis-Courmont wrote:
> Le maanantaina 29. tammikuuta 2024, 20.11.19 EET Michael Niedermayer a écrit :
[...]
> > Its under the control of the community and its transparent
>
> You always have the control of the community at the time of review and
Add an AVOption to the libjxl encoder wrapper, which exposes the flag
uses_original_profile in libjxl. For highly unusual ICC profiles where
the target needs to stay in the original space, this can be useful.
Signed-off-by: Leo Izen
---
libavcodec/libjxlenc.c | 5 -
1 file changed, 4 inserti
>
> I guess that conculdes the "most serious schism in the project since the
> fork"
> until the next most serious ?
>
If you think that was the sole consequence of your attempt to ram SDR into
ffmpeg then I have no words.
Kieran
>
___
ffmpeg-devel mai
The reference line buffers are used with indices in the range
-MAX_TB_SIZE - 3 to refw + FFMAX(1, w/h) * ref_idx + 1, which is
at most 5*MAX_TB_SIZE + 1.
Fixes buffer overflows.
http://fate.ffmpeg.org/report.cgi?slot=armv7-linux-gcc-9&time=20240124051736
---
libavcodec/vvc/vvcdsp.c | 8
Existing code could have caused wrong channel order signalling or reduced
channel count if a channel designation appeared multiple times. This is
actually an old bug, but the conversion to the new channel layout API made it
visible, because now the code overrides the proper channel count with the o
The channel designation metadata should not override the number of channels.
Let's warn the user if it is inconsistent, and keep the channel layout
unspecified.
Before the conversion to the channel layout API the code only set the mask, but
never overridden the channel count, so this restores the
Signed-off-by: Marton Balint
---
doc/APIchanges | 3 +++
libavutil/channel_layout.c | 20
libavutil/channel_layout.h | 13 +
libavutil/version.h| 4 ++--
4 files changed, 38 insertions(+), 2 deletions(-)
diff --git a/doc/APIchanges b/doc/API
Signed-off-by: Marton Balint
---
doc/APIchanges | 3 +++
libavutil/channel_layout.c | 48 ++
libavutil/channel_layout.h | 11 +
libavutil/version.h| 2 +-
4 files changed, 63 insertions(+), 1 deletion(-)
diff --git a/doc/APIchange
Signed-off-by: Marton Balint
---
libavformat/mov_chan.c | 99 +++---
1 file changed, 54 insertions(+), 45 deletions(-)
diff --git a/libavformat/mov_chan.c b/libavformat/mov_chan.c
index 6b206745b4..ce1e462dd1 100644
--- a/libavformat/mov_chan.c
+++ b/libavform
On 1/29/2024 8:22 PM, Frank Plowman wrote:
The reference line buffers are used with indices in the range
-MAX_TB_SIZE - 3 to refw + FFMAX(1, w/h) * ref_idx + 1, which is
at most 5*MAX_TB_SIZE + 1.
Fixes buffer overflows.
http://fate.ffmpeg.org/report.cgi?slot=armv7-linux-gcc-9&time=2024012405173
On 1/29/2024 7:28 PM, Frank Plowman wrote:
On 29/01/2024 21:13, James Almer wrote:
On 1/29/2024 5:19 PM, Frank Plowman wrote:
Below is a patch which addresses the issue, an integer overflow when
calculating the bounds for
vps_num_ols_timing_hrd_params_minus1. There's also a similar fix for
v
Anton: "whether anything requires the projects to be owned by
individuals"... I don't think so. At least, not from the SPI side, STF
might have objections which I cannot anticipate.
But from the SPI side, we probably could do a MSA/SOW with a company rather
than individuals just fine, although I w
On date Monday 2024-01-29 22:11:49 +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-01-28 04:25:49)
> > There can be no late objections here to any project suggestions.
> > Objections must be before a project suggestion is submitted to STF,
> > objections after that cannot be conside
Hi Anton,
CCing Jonatas as there are questions beyond my knowledge in here
and also iam not sure if my awnsers are all correct
On Mon, Jan 29, 2024 at 10:11:49PM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-01-28 04:25:49)
> > There can be no late objections here to any project
Hi all
I just now realize you already CC-ed jonatan and he already awnsered
sorry for the noise
On Tue, Jan 30, 2024 at 01:15:54AM +0100, Michael Niedermayer wrote:
> Hi Anton,
>
> CCing Jonatas as there are questions beyond my knowledge in here
> and also iam not sure if my awnsers are all corr
libjxl doesn't support negative strides, but JPEG XL has an orientation
flag inside the codestream. We can use this to work around the library
limitation, by taking the absolute value of the negative row stride,
sending the image up-side-down, and telling the library that the image
has a vertical-f
Hi all
after people said they would help and start a wiki page (no not thilo dont
blame him)
I again wrote one myself. This is really early WIP
it contains the application we would send to STF, this is NOT written by me
and a few random projects
the structure of the application at the end is i t
On Tue, Jan 30, 2024 at 1:07 AM Anton Khirnov wrote:
>
> Quoting Chen Yufei (2024-01-29 04:01:51)
> > On Sun, Jan 28, 2024 at 10:10 PM Anton Khirnov wrote:
> > >
> > > Quoting Zhao Zhili (2024-01-28 14:51:58)
> > > >
> > > >
> > > > > On Jan 28, 2024, at 18:31, Anton Khirnov wrote:
> > > > >
> >
1 - 100 of 108 matches
Mail list logo
