On 12.11.24 08:51, Martin Storsjö wrote:
On Tue, 12 Nov 2024, martin schitter wrote:
The git history of Patches here on this mailinglist are usually
rewritten whenever one of the reviewers requests some change, but the
typical workflow in github/gitlab doesn't use or even forbids this
kind
On Tue, Nov 12, 2024 at 9:44 AM martin schitter wrote:
>
>
>
> On 12.11.24 08:51, Martin Storsjö wrote:
> > On Tue, 12 Nov 2024, martin schitter wrote:
> >
> >> The git history of Patches here on this mailinglist are usually
> >> rewritten whenever one of the reviewers requests some change, but th
On 12 Nov 2024, at 9:44, martin schitter wrote:
> On 12.11.24 08:51, Martin Storsjö wrote:
>> On Tue, 12 Nov 2024, martin schitter wrote:
>>
>>> The git history of Patches here on this mailinglist are usually rewritten
>>> whenever one of the reviewers requests some change, but the typical
>>>
On 12 Nov 2024, at 10:09, Diederick C. Niehorster wrote:
> On Tue, Nov 12, 2024 at 9:44 AM martin schitter wrote:
>>
>>
>>
>> On 12.11.24 08:51, Martin Storsjö wrote:
>>> On Tue, 12 Nov 2024, martin schitter wrote:
>>>
The git history of Patches here on this mailinglist are usually
re
fre 2024-11-08 klockan 11:29 +0100 skrev Tomas Härdin:
> Passes fate-mxf
Will push in a day or two
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
Le maanantaina 11. marraskuuta 2024, 1.06.12 EET Michael Niedermayer a écrit :
> > On the other hand, if we assume that it does not get separated, I think
> > the lack of activity tells about the impopularity of the library. I don't
> > see the point in spending time and/or money if nobody cares an
Microsoft has formally standardized DXVA GUIDs for HEVC Range Extension
profiles in the Windows 11 24H2 SDK. They are supported by Intel GPUs
starting with Tiger Lake.
Like VDPAU and VAAPI, DXVA has separate GUIDs for each RExt profile, so
we must parse the SPS like those hwaccels do to figure out
On 11/12/2024 5:05 PM, James Almer wrote:
> This is not true. I have write access to the website, for example, as do
> others. And Michael cuts releases because he was given the task, not
> because nobody else can or want. And nobody prevents anyone from just
> fetching a git tag instead (Distro
On Thu, Nov 07, 2024 at 01:19:58AM +, James Almer wrote:
> ffmpeg | branch: master | James Almer | Sat Nov 2
> 20:06:24 2024 -0300| [271aea60a4cd211d92923c53b72cd074c3030897] | committer:
> James Almer
>
> fate/pixfmts: extend the high bit depth test
>
> Also test 8bit formats, and try bi
On Sat, Nov 9, 2024 at 10:31 AM Pavel Koshevoy wrote:
>
>
> On Sat, Nov 9, 2024 at 9:53 AM James Almer wrote:
>
>> On 11/9/2024 12:55 PM, Pavel Koshevoy wrote:
>> > On Sat, Nov 9, 2024 at 6:22 AM James Almer wrote:
>> >
>> >> On 11/9/2024 1:40 AM, Pavel Koshevoy wrote:
>> >>> On Fri, Nov 8, 202
Hi,
On Tue, Nov 12, 2024 at 2:14 PM Frank Plowman wrote:
> Remove the MMX versions of these functions and modify the SSE
> implementations to avoid using MMX registers.
>
> Signed-off-by: Frank Plowman
> ---
> This wasn't wholly straightforward as the existing SSE implementation did
> not only
On Tue, 12 Nov 2024 17:30:57 +
Derek Buitenhuis wrote:
> On 11/12/2024 5:05 PM, James Almer wrote:
> > This is not true. I have write access to the website, for example,
> > as do others. And Michael cuts releases because he was given the
> > task, not because nobody else can or want. And nob
Hi Kyle
On Tue, Nov 12, 2024 at 02:09:25PM -0800, Kyle Swanson wrote:
> Hi,
>
> Should we consult with someone (a professional) outside of FFmpeg to
> assess the situation and provide a set of recommendations? This would
> be money well spent IMO.
I do have a list of ideas from people (not the q
This patch is incomplete because the UBSAN error in
libavcodec/tests/jpeg2000dwt.c has not been fixed.
I will send the v2 patch soon.
> On Nov 11, 2024, at 17:34, WATANABE Osamu
> wrote:
>
> This patch fixes undefined behaviour error in left shift
> operations in jpeg2000dec.c and jpeg2000htde
Hi
On Tue, Nov 12, 2024 at 10:38:09PM +, Kieran Kunhya via ffmpeg-devel wrote:
> On Tue, 12 Nov 2024, 21:03 Michael Niedermayer,
> wrote:
>
> > On Tue, Nov 12, 2024 at 05:32:40PM +, Derek Buitenhuis wrote:
> > > On 11/12/2024 5:07 PM, James Almer wrote:
> > > > I personally don't agree w
On Tue, 12 Nov 2024 21:17:01 +0200
Rémi Denis-Courmont wrote:
> Le sunnuntaina 3. marraskuuta 2024, 19.25.50 EET Michael Niedermayer
> a écrit :
> > Hi
> >
> > On Sun, Nov 03, 2024 at 08:56:36PM +0900, Rémi Denis-Courmont wrote:
> > [...]
> >
> > > >Thats besides the root admins should genera
On Tue, 12 Nov 2024, 21:03 Michael Niedermayer,
wrote:
> On Tue, Nov 12, 2024 at 05:32:40PM +, Derek Buitenhuis wrote:
> > On 11/12/2024 5:07 PM, James Almer wrote:
> > > I personally don't agree with giving the domain/trademark to the
> general
> > > assembly, as some have argued. It's just
On Tue, Nov 12, 2024 at 05:32:40PM +, Derek Buitenhuis wrote:
> On 11/12/2024 5:07 PM, James Almer wrote:
> > I personally don't agree with giving the domain/trademark to the general
> > assembly, as some have argued. It's just not safe at all.
>
> Sorry, I didn't necessarily mean giving it o
On Thu, 7 Nov 2024 at 17:31, Leo Izen wrote:
>
> The JPEG XL parser has an entropy decoder inside, which supports LZ77
> length-distance pairs. If the first symbol from the entropy stream is an
> LZ77 pair, the bitstream is invalid, so we should abort immediately rather
> than attempt to read it a
this mail might have come off angry, i didnt mean for this to be an
angry email.
can safely ignore this mail.
-compn
On Tue, 12 Nov 2024 12:51:23 -1000
compn wrote:
> are you talking about the same Josh who asked not to have their photo
> taken during vdd?
>
> you want a root admin who doesnt
On Wed, 13 Nov 2024, 00:10 Michael Niedermayer,
wrote:
> Hi
>
> On Tue, Nov 12, 2024 at 10:38:09PM +, Kieran Kunhya via ffmpeg-devel
> wrote:
> > On Tue, 12 Nov 2024, 21:03 Michael Niedermayer,
> > wrote:
> >
> > > On Tue, Nov 12, 2024 at 05:32:40PM +, Derek Buitenhuis wrote:
> > > > On
On 11/11/2024 7:33 PM, Michael Niedermayer wrote:
>> This only convinces me further that it this whole setup ins't for for
>> purpose,
>> and is being run by people who have no concept of actual security. This is
>> totally insane.
Honestly, this is so exhausting and painful, I dread responding.
Hi,
Le 12 novembre 2024 19:07:56 GMT+02:00, James Almer a écrit
:
>On 11/12/2024 1:58 PM, Derek Buitenhuis wrote:
>> Answers aren't sufficient or complete, and you purposely avoid giving
>> community
>> power over the ifnrastructure, domains, or trademark. It is solely at your
>> discretion.
>
On 11/12/2024 1:58 PM, Derek Buitenhuis wrote:
For example, right now, one person (you) has the ability to cut release, modify
the website, sign the tarballs, etc. It's all you. I'm sure that's great in your
mind, as you deem yourself trustworthy. From our end, nothing stops it from
being
xz par
On 11/11/2024 7:34 PM, compn wrote:
> if your goal is to post old quotes, thats cool.
Woosh.
> one of my goals is to make sure that certain developers, who made their
> own project and then ran it into the ground, arent made as admins
> again. they had a good run but couldnt even make an
> announ
Instead of duplicating it across all supported decoders.
Signed-off-by: James Almer
---
libavcodec/h2645_sei.c| 3 +++
libavcodec/h264_slice.c | 2 --
libavcodec/hevc/hevcdec.c | 2 --
3 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/libavcodec/h2645_sei.c b/libavcodec/h2645_
It's a pointless indirection.
Signed-off-by: James Almer
---
libavcodec/h264_sei.h | 6 --
libavcodec/h264_slice.c | 2 +-
2 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/libavcodec/h264_sei.h b/libavcodec/h264_sei.h
index bb9275e569..8c8f6e6c73 100644
--- a/libavcodec/h264_s
It's also a pointless indirection.
Signed-off-by: James Almer
---
libavcodec/hevc/sei.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/libavcodec/hevc/sei.h b/libavcodec/hevc/sei.h
index 806540fac6..ee640003bc 100644
--- a/libavcodec/hevc/sei.h
+++ b/libavcodec/hevc/sei.h
@@ -109,11 +10
On Tue, 12 Nov 2024 10:00:56 +
Kieran Kunhya via ffmpeg-devel wrote:
> On Tue, 12 Nov 2024, 04:07 compn, wrote:
>
> > haven't seen arpi in a while so remove his root authorized key +
> > remove him from maintainers. maybe he'll come back?
> >
> > anyone know how to contact tim nicholson? hi
On 11/12/2024 5:07 PM, James Almer wrote:
> I personally don't agree with giving the domain/trademark to the general
> assembly, as some have argued. It's just not safe at all.
Sorry, I didn't necessarily mean giving it ot the GA. I mean having it in a
better state than being held hostage by some
On 11/12/2024 1:58 PM, Derek Buitenhuis wrote:
Answers aren't sufficient or complete, and you purposely avoid giving community
power over the ifnrastructure, domains, or trademark. It is solely at your
discretion.
I personally don't agree with giving the domain/trademark to the general
assemb
On Tue, 12 Nov 2024 16:46:42 +
Derek Buitenhuis wrote:
> On 11/11/2024 7:34 PM, compn wrote:
> > if your goal is to post old quotes, thats cool.
>
> Woosh.
the quotes are from michael in 2015 saying elect a new leader. pretty
sure we never elected one.
feel free to start a vote.
> > on
Remove the MMX versions of these functions and modify the SSE
implementations to avoid using MMX registers.
Signed-off-by: Frank Plowman
---
This wasn't wholly straightforward as the existing SSE implementation did
not only use SSE but rather a blend of SSE and MMX. I would appreciate
some revie
Le sunnuntaina 3. marraskuuta 2024, 19.25.50 EET Michael Niedermayer a écrit :
> Hi
>
> On Sun, Nov 03, 2024 at 08:56:36PM +0900, Rémi Denis-Courmont wrote:
> [...]
>
> > >Thats besides the root admins should generally be professional admins and
> > >not "popular politicans".
> >
> > You have bl
Hi,
Should we consult with someone (a professional) outside of FFmpeg to
assess the situation and provide a set of recommendations? This would
be money well spent IMO.
Thanks,
Kyle
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org
Hi,
On Mon, Nov 11, 2024 at 4:03 AM Frank Plowman wrote:
> I thought the same before submitting this patch, and tried only adding
> the line conditionally based on the mmsize, but found neither wrapping
> it in an a) mmsize == 8, nor b) mmsize != 8 block alone worked.
>
Can we just get rid of t
On 11/12/2024 9:37 AM, Ronald S. Bultje wrote:
Hi,
On Mon, Nov 11, 2024 at 4:03 AM Frank Plowman wrote:
I thought the same before submitting this patch, and tried only adding
the line conditionally based on the mmsize, but found neither wrapping
it in an a) mmsize == 8, nor b) mmsize != 8 blo
On Mon, Nov 11, 2024 at 06:06:07PM -1000, compn wrote:
> haven't seen arpi in a while so remove his root authorized key + remove
> him from maintainers. maybe he'll come back?
it would be cool if arpi came back :)
but until then, patch is ok
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128
On Tue, 12 Nov 2024 10:50:42 +0100 Niklas Haas wrote:
> From: Niklas Haas
>
> This interface has been designed from the ground up to serve as a new
> framework for dispatching various scaling operations at a high level. This
> will eventually replace the old ad-hoc system of using cascaded contex
On Tue, 12 Nov 2024, 04:07 compn, wrote:
> haven't seen arpi in a while so remove his root authorized key + remove
> him from maintainers. maybe he'll come back?
>
> anyone know how to contact tim nicholson? his mails are
> bouncing. https://uk.linkedin.com/in/tim-nicholson-7a2a3963
This is all
From: Niklas Haas
This is a purely cosmetic commit aimed at replacing accesses to
SwsInternal.opts by direct access to SwsContext wherever convenient.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas
---
libswscale/options.c | 2 +-
libswscale/swscale.c
From: Niklas Haas
Reorganize the list, fix whitespace, make indentation consistent, and
rename some descriptions for clarity, consistency or informativeness.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas
---
libswscale/options.c | 86 ++--
From: Niklas Haas
Instead of sprinkling av_assert0 into random init functions.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas
---
libswscale/swscale_internal.h | 11 +++
libswscale/utils.c| 2 --
libswscale/x86/swscale.c | 4
3 files changed, 11 in
Changes since v5:
- Fix FATE regression introduced in v5
- Fix build error on loongson introduced by rebase
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
From: Niklas Haas
Most logic from this filter has been co-opted into swscale itself,
allowing the resulting filter to be substantially simpler as it no
longer has to worry about context initialization, interlacing, etc.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas
---
libavfilt
From: Niklas Haas
Following in the footsteps of the work in the previous commit, it's now
relatively straightforward to expose the options struct publicly as
SwsContext. This is a step towards making this more user friendly, as
well as following API conventions established elsewhere.
Sponsored-b
From: Niklas Haas
Group them into an enum rather than random #defines, and document their
behavior a bit more obviously.
Of particular note, I discovered that SWS_DIRECT_BGR is not referenced
anywhere else in the code base. As such, I have moved it to the deprecated
section, alongside SWS_ERROR_
From: Niklas Haas
Used by the graph API swscale wrapper, for now.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas
---
libswscale/swscale_internal.h | 3 +++
libswscale/utils.c| 4 ++--
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/libswscale/swscale_in
From: Niklas Haas
With the ability to set the thread count as well. This benchmark includes
the constant overhead of context initialization.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas
---
libswscale/tests/swscale.c | 93 --
1 file changed,
From: Niklas Haas
This interface has been designed from the ground up to serve as a new
framework for dispatching various scaling operations at a high level. This
will eventually replace the old ad-hoc system of using cascaded contexts,
as well as allowing us to plug in more dynamic scaling passe
From: Niklas Haas
This rewrite cleans up the code to use AVFrames and the new swscale API. The
log format has also been simplified and expanded to account for the new
options. (Not yet implemented)
The self testing code path has also been expanded to test the new swscale
implementation against t
From: Niklas Haas
As part of a larger, ongoing effort to modernize and partially rewrite
libswscale, it was decided and generally agreed upon to introduce a new
public API for libswscale. This API is designed to be less stateful, more
explicitly defined, and considerably easier to use than the ex
52 matches
Mail list logo
