Michael Niedermayer (12025-01-21):
> The contributor looks in MAINTAINERS and sees if there is a preferred place to
> submit a patch(set) to.
What if the patch series affects areas handled by multiple maintainers?
What if the patch would benefit from the expertise of another developer
than the ma
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Michael Niedermayer
> Sent: Tuesday, January 21, 2025 1:41 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Democratization
>
> Hi Gyan
>
> On Mon, Jan 20, 2025 at 11:44:41PM +053
Hi Michael,
> I do think the CC is a problematic entity in a community where there are
> complex friendships and hatred. And then the members of this CC come from this
> small group and mainly judge members of this same group
I am not from this group. I volunteered for the role to help the cultur
Kieran:
> Running two systems concurrently is a recipe for disaster and makes a
> difficult process essentially impossible.
I agree this is confusing and unsustainable. There should be only one
"system of record", in a sense.
Are there hooks or simple integration methods we can implement to
mirror
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Kieran Kunhya via ffmpeg-devel
> Sent: Tuesday, January 21, 2025 4:57 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Cc: Kieran Kunhya
> Subject: Re: [FFmpeg-devel] Regarding Git Tooling
>
> >
> > Ah, I go
>
> Ah, I got you now. This would mean that one part of patches will never go
> through the ML and another part will never be seen on "WEB". I hadn't even
> considered that as a possible/acceptable way, but I wouldn't mind.
>
How is this not confusing as hell for new contributors?
Running two sys
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> James Almer
> Sent: Tuesday, January 21, 2025 3:57 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] Regarding Git Tooling
>
> I don't think Forgejo's comment section for commits, bugs and MRs is
> good enough for discu
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Michael Niedermayer
> Sent: Tuesday, January 21, 2025 3:38 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Regarding Git Tooling
>
> Hi
>
> On Tue, Jan 21, 2025 at 01:56:09AM
On 11/1/2024 11:57 AM, Patrice Dumas wrote:
Here is a proposed patch for portability of doc/t2h.pm for GNU Texinfo
7.1 and 7.1.90 (7.2 pretest). I tested against 7.1 and 7.1.90 (7.2
pretest). There is a difference in the headings compared to the website
version, maybe related to FA_ICONS not b
On 1/20/2025 11:41 PM, Michael Niedermayer wrote:
On Tue, Jan 21, 2025 at 02:26:24AM +0100, Michael Niedermayer wrote:
Hi
On Mon, Jan 20, 2025 at 02:39:29PM -0600, Marth64 wrote:
Hello, in the context of a GA member,
I think there is general interest in modernizing technical tooling
specifica
On Tue, Jan 21, 2025 at 02:26:24AM +0100, Michael Niedermayer wrote:
> Hi
>
> On Mon, Jan 20, 2025 at 02:39:29PM -0600, Marth64 wrote:
> > Hello, in the context of a GA member,
> >
> > I think there is general interest in modernizing technical tooling
> > specifically regarding ML/patch workflow
Hi
On Tue, Jan 21, 2025 at 01:56:09AM +, Soft Works wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Michael Niedermayer
> > Sent: Tuesday, January 21, 2025 2:26 AM
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-de
On Tue, 21 Jan 2025 02:26:24 +0100, Michael Niedermayer wrote:
> I also dont think we even need a vote to just setup a Forgejo on ffmpeg.org
> when it replaces nothing but just adds an option
i agree lets turn on and test these options instead of endlessly
discussing and voting.
-compn
__
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Michael Niedermayer
> Sent: Tuesday, January 21, 2025 2:26 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Regarding Git Tooling
> I dont know why the options are exclusive. One
Hi
On Sat, Jan 18, 2025 at 05:59:58AM +0100, Michael Niedermayer wrote:
> resetting the version causes any previously set values to be disregarded
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/ffv1enc.c | 1 -
> 1 file changed, 1 deletion(-)
will apply this (bugfix?)
and the combi
Hi
On Mon, Jan 20, 2025 at 02:39:29PM -0600, Marth64 wrote:
> Hello, in the context of a GA member,
>
> I think there is general interest in modernizing technical tooling
> specifically regarding ML/patch workflow vs. integrated git solution.
> Both have their merits. I think what we have today i
Hi
On Mon, Jan 20, 2025 at 09:00:57PM +, Soft Works wrote:
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Nicolas George
> > Sent: Monday, January 20, 2025 9:50 PM
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-de
Hi Gyan
On Mon, Jan 20, 2025 at 11:44:41PM +0530, Gyan Doshi wrote:
>
>
> On 2025-01-20 11:14 pm, Soft Works wrote:
> > - An indication that the aim and direction of the contribution is
> >generally acceptable
>
> This the crux of the matter. There appear to be two camps at odds with one
>
Hi
On Mon, Jan 20, 2025 at 10:38:17AM -0600, Marth64 wrote:
> All this time people send back and forth emails attacking each other or the
> project could have spent toward investing in modern DevOps infrastructure
> or discussing other advancements.
>
> It’s energy-draining to both read and write
Hi compn:
> i think a good starting off point would be to check all of the
> suggestion options and see how they cohabitate with git-send-mail?
I agree, a breakthrough there could be the most natural on-ramp from
the current flow.
___
ffmpeg-devel mailin
Hi Nicolas,
This is fine and your preferences are understandable. Everyone has
their tools of choice.
That said, I did try Forgejo on a local instance today without
JavaScript and it was not a usable experience for a contributor.
I could do some limited functions but not raise a PR, for example.
On Mon, 20 Jan 2025 23:25:22 +0100, Nicolas George wrote:
> It is important that our process be compatible with somebody who, same
> as me, likes to do everything with Vim. But it is equally important that
> our process be compatible with somebody who likes to do everything in
> Emacs. Or in VS Cod
Marth64 (12025-01-20):
> I'm in this camp too. I also like JS off.
> I do not know the correct answer here.
> As much as I don't like it, I'd be willing to allowlist the particular
> site on my JS blocker if there is not an option.
But please, tell me, how do I enable javascript in Perl's
WWW::Mec
Hi Nicolas (+),
> Let us add that the camp that wants more stability than originality
> already tried to become the dominant camp in the last years of the 2000s
> decade, with the same strategy of bullying Michael.
Just to reaffirm,
I have no such intention and am not in this camp.
Folks have bee
On 1/20/25 4:09 PM, Nicolas George wrote:
Marth64 (12025-01-20):
These are some options I noticed interest in (in no particular order):
- Forgejo
- GitLab
- Mailing List/Patch Workflow (current solution)
I have already pointed that GitLab is a piece of crap with a track
record of about one eme
Hi Nicolas,
> Can any of the solution you would favor be used without a
> javascript-enabled web browser?
I'm in this camp too. I also like JS off.
I do not know the correct answer here.
As much as I don't like it, I'd be willing to allowlist the particular
site on my JS blocker if there is not a
Marth64 (12025-01-20):
> These are some options I noticed interest in (in no particular order):
> - Forgejo
> - GitLab
> - Mailing List/Patch Workflow (current solution)
I have already pointed that GitLab is a piece of crap with a track
record of about one emergency release for security reasons pe
Hi Nicolas,
Re: Tooling
I am suggesting that there can be a middle ground somewhere.
I am not fond of modern heavy web GUIs myself and fully understand
that more senior developers have advanced needs.
The custom tooling I am referring to is Patchwork.
A neat tool, but is this not also a web GUI?
Gyan Doshi (12025-01-20):
> This the crux of the matter. There appear to be two camps at odds with one
> another:
>
> 1) a conservative camp which wants to avoid features or changes which don't
> neatly fit within a conventional pure architecture with clear separation of
> roles and duties, or fea
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Nicolas George
> Sent: Monday, January 20, 2025 9:50 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Democratization
>
> Marth64 (12025-01-20):
> > There are people who have sp
Marth64 (12025-01-20):
> Who wants to spend the time to decipher say, 30 commits as individual
> emails or learn custom software to do this, just to review PRs?
What custom software? The point is precisely that anybody is free to use
the software of their choosing.
>
Marth64 (12025-01-20):
> There are people who have specialty areas.
> They are the de facto leaders of their domains.
They are *potential* leaders. To be actual leaders, they would need to
act as such, and the members of the project would need to respect them
as much.
> There is also a Technical
Hello, in the context of a GA member,
I think there is general interest in modernizing technical tooling
specifically regarding ML/patch workflow vs. integrated git solution.
Both have their merits. I think what we have today is optimized for
some but cumbersome for many. Like shopping for a drill
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Marth64
> Sent: Monday, January 20, 2025 7:19 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Democratization
>
> And I still blame our infrastructure.
> The process is annoying,
Hi, Nicolas George:
> No, we do not.
I disagree.
There are people who have specialty areas.
They are the de facto leaders of their domains.
If you gave me constructive feedback on a patch in your domain, I’d look at
you as a technical thought leader in the space.
There is also a Technical Commi
Hi,
Re: Softworks,
> As a contributor, I'm expecting my contributions to:
> - Not be ignored
> - Receive one of these three responses:
> 1. OK (and get merged in a timely manner)
> 2. No (for whichever reason)
> 3. Ok but needs changes
The contribution is more likely to be ignored or responded
On 2025-01-20 11:14 pm, Soft Works wrote:
- An indication that the aim and direction of the contribution is
generally acceptable
This the crux of the matter. There appear to be two camps at odds with
one another:
1) a conservative camp which wants to avoid features or changes which
do
Marth64 (12025-01-20):
> The project already has technical leaders.
No, we do not. The leader we had, who was doing an excellent job, was
bullied into resigning. Unfortunately, his major flaw as a leader is to
be too agreeable to realize the proper way to deal with these bullies
when is to kick th
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Marth64
> The project is hard to work with or seemingly "hostile, non-
> welcoming"
> because we are using ancient workflows that aren't conducive to new
> innovation,
> or iterative development.
The workflow and tooling is archaic
All this time people send back and forth emails attacking each other or the
project could have spent toward investing in modern DevOps infrastructure
or discussing other advancements.
It’s energy-draining to both read and write.
It makes me wonder do folks actually get enjoyment out of the drama?
James Almer:
> I'd really like if we can stop with the "Everything's fucked, nothing
> can be done" mails every other week and instead make use of the
> framework we came up with, or if needed, change it and improve it.
+1
or we will never move forward with anything
__
IMHO (as myself and not representing the CC).
The project already has technical leaders.
The project already has great talent.
The project has some semblance of democratic processes.
The project is hard to work with or seemingly "hostile, non-welcoming"
because we are using ancient workflows that
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Michael Niedermayer
> Sent: Thursday, January 2, 2025 3:18 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: [FFmpeg-devel] Democratization
>
> Hi all
>
> I was working in the last few days a little
On 1/20/2025 11:30 AM, Nicolas George wrote:
James Almer (12025-01-17):
I don't see how the GA has anything to do with this when we're talking about
one person, but you're not wrong in that rejecting a feature for being
incomplete is not ideal.
The codebase is not lacking in partially implemente
On Mon, Jan 20, 2025 at 2:51 PM Nicolas George wrote:
>
> Kieran Kunhya via ffmpeg-devel (12025-01-17):
> > I am the author of the only known functional OSS implementation of FEC.
>
> Seen from here, your rejection of this proposal looks a teeny tiny
> little bit like trying to make sure you stay
Kieran Kunhya via ffmpeg-devel (12025-01-17):
> I am the author of the only known functional OSS implementation of FEC.
Seen from here, your rejection of this proposal looks a teeny tiny
little bit like trying to make sure you stay the only one and have no
competition in providing consulting about
Devin Heitmueller (12025-01-17):
> It's an intrinsically difficult
> problem. The data arrives on multiple sockets, leading to all sorts
> of opportunities for timing behavior and reordering issues.
I will add something on top of that: The architecture of net
James Almer (12025-01-17):
> I don't see how the GA has anything to do with this when we're talking about
> one person, but you're not wrong in that rejecting a feature for being
> incomplete is not ideal.
> The codebase is not lacking in partially implemented features and protocols,
> and as long
On Jan 20, 2025, at 18:23, zjd via ffmpeg-devel wrote:
>
> The current issue is that when dealing with a long interval between
> keyframes, seeking to a specified position takes a considerable amount of
> time. Please provide possible solutions
1. This mailing list is for FFmpeg development, n
Adding support for hwaccels means that avctx->pix_fmt will indicate
hardware formats.
---
libavcodec/ffv1.h| 1 +
libavcodec/ffv1dec.c | 140 ---
2 files changed, 78 insertions(+), 63 deletions(-)
diff --git a/libavcodec/ffv1.h b/libavcodec/ffv1.h
ind
The current issue is that when dealing with a long interval between keyframes,
seeking to a specified position takes a considerable amount of time. Please
provide possible solutions
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.or
On Tue, Dec 24, 2024 at 9:34 AM Lingyi Kong wrote:
>
> add fate test case
>
> Signed-off-by: Lingyi Kong
For whatever reason PATCHv4 is in neither of my email boxes, one of
which is subscribed to ffmpeg-devel, the other of which is not
subscribed but I still receive the emails. It's a great syst
52 matches
Mail list logo
