moved or disabled.
You were asking for proof that corporate-style mindset harms the
project, you have one right here: “we do not want this new feature
because it could mean bad PR” is one of the leitmotivs that have pushed
the project towards stagnation since the GA has had influence.
--
James Almer (12025-01-15):
> You mean getting a const pointer to the side data in buffersink, so the
> caller may clone it if needed?
Exactly. Possibly along with an equivalent for av_frame_side_data_get()
that finds the right one, or an unification of these functions.
Regards,
--
N
or packets and frames, accessing the side data directly is allowed, and
the utility functions to query return the data directly, without new
allocation. This API should have the same behavior, both for consistency
and convenience.
Regards,
--
Nicolas George
___
de we want for
the long run.
--
Nicolas George
___
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 subject "unsubscribe".
, revoked their access.
First, we need to close the loophole. Afterwards we can explain why we
did it and discusser better ways. But please, first close the loophole
for good.
Regards,
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@f
as just a bad idea, for that very reason among others, let us
drop it.
Regards,
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffm
Same goes for patch #2 in this series.
1: For the same reason, I have always refrained from explaining how to
legally ship GPL ffmpeg with a proprietary binary.
Regards,
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://
function. I suppose the issue was a negative return value? If so,
please use >= 1 instead of == 1.
> arg += len;
> if (parse_channel_name(&arg, &in_ch_id, &named)){
> av_log(ctx, AV_LOG_ERROR,
Regards,
--
Nicolas George
___
Fix “Could not update timestamps for skipped samples” warning
and associated misfeature.
Signed-off-by: Nicolas George
---
libavfilter/src_movie.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavfilter/src_movie.c b/libavfilter/src_movie.c
index d2aa572d12..a1b3d026a6 100644
--- a
ew ideas and
instead getting on to managing releases and fuzzing the code.
Regards,
--
Nicolas George
___
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 subject "unsubscribe".
by Google or James you must
use an address at a less monopolistic operator for your CC seat.
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above,
r
proposal”.
> This is not sound argumentation; this is outright libel against my person.
“You keep using that word. I do not think it means what you think it
means.”
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmp
those effects. I am afraid that I do not
> have
> an answer to your absurd 20-typos hypothetical.
I am just applying the rule that you defend. I see you have no argument
in favor of democracy since the only thing you found to answer was t
ould have as much
power over the direction of the project as somebody who knows multiple
subsystems inside-out and maintains them?
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
James Almer (12025-01-02):
> The string type is a remnant of the old channel layout API implementation.
Looks ok.
Regards,
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
tenance by the
most experienced developers.
Michael did an excellent job as a leader for years, and it only turns
sour when a small faction get greedy and tries to oust him to take over.
I look forward to him again being able to act as a leader without
obstruction from them.
Regards,
-
and irrelevance. And in our case, it is worsened
because some people have borrowed their definition from Erdoğan, “like a
tram, you ride it until you arrive at your destination, then you step
off”.
Regards,
--
Nicolas George
___
ffmpeg-devel mailing l
eory” is the kind of accusation anybody can throw
around when they do not have factual objections beyond a few
misremembered details about who helped with the daily merges.
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.o
than libav.
At some point, I do not exactly know when, libav died and its members
started coming back in the ffmpeg project.
I strongly suggest to read the list of names in the 2011 mail I have
quoted earlier and compare it to the list of people who criticize
Michael
Anton Khirnov (12024-12-24):
> So boiling down your verbal vomit, I get
> * you are delusional
This kind of is unacceptable. Especially from somebody who recently
volunteered to judge over other people's civility.
--
Nicolas George
___
f
Could you all stop ganging against Michael? It is reminiscent of the
bullying he was subjected to in the months leading to the fork that
convinced him to “resign” as project leader even though he was doing an
excellent job of if.
Thank you very much.
--
Nicolas George
End of text from me on this.
--
Nicolas George
___
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 subject "unsubscribe".
Kieran Kunhya via ffmpeg-devel (12024-12-13):
> Where is the second sample rate stored in wav?
Nowhere, obviously. I am surprised somebody who has been in the project
for more than 12 years still does not know how it works.
--
Nicolas Geo
ing.
The answer is yes.
--
Nicolas George
___
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 subject "unsubscribe".
e/swr-async-firstpts | 34 +--
> 13 files changed, 560 insertions(+), 560 deletions(-)
Ok of course.
Thanks.
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, vis
-
> 1 file changed, 23 insertions(+), 1 deletion(-)
Sorry for the delay. The logic looks sound, and I am assuming you have
checked that it now gives periodical output when the frequency is a
divisor of the sample frequency, so ok.
Regards,
--
Nicolas George
Jean-Baptiste Kempf (12024-11-26):
> Once again you attack people directly on threads.
« your kind of » ≠ « you », please do not abuse code of conduct rules to
silence discourse that you want to silence. It is part of the kind of
governance that is harming the project.
--
“I dont see why” isnt
xploit it for profit is the worst
possible person to manage or contribute to manage a Libre Software
project.
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, v
Jean-Baptiste Kempf (12024-11-26):
Replying to this would be a waste of time.
It took me time to realize the harm your kind of governance did to
FFmpeg, but now it is quite obvious.
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel
as Open Source might explain why the
result is such a mess.
--
Nicolas George
___
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.or
e a right to know who is accusing them and who the witnesses
are except in exceptional circumstances. I think the CC should grand the
same right to their accused.
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org
said on the
criticised mail, but I fully agree with you that this intervention of a
CC member is entirely inappropriate and abusive.
Regards,
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmp
ot important.
LGTM.
Regards,
--
Nicolas George
___
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 subject "unsubscribe".
Marton Balint (12024-11-10):
> The filter currently use inaccurate frequencies, this is inpreparation for
uses
> fixing that.
... by using numbers that will map to the equivalent value in the future
code.
LGTM otherwise.
Sorry for the delay.
Regards,
--
Nicolas
Marton Balint (12024-11-15):
> Will apply the series soon.
Sorry, this was the series I was thinking of when replying:
I have had a busy week, I will be able to look at it this week-end.
Regards,
--
Nicolas George
___
ffmpeg-devel mailing l
Marton Balint (12024-11-15):
> Ping for this, will apply soon.
I have had a busy week, I will be able to look at it this week-end.
Regards,
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listi
and server distributions are not the only kind there is.
--
Nicolas George
___
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 subject "unsubscribe".
James Almer (12024-11-07):
> Linux x86_32 is pretty much obsolete and deprecated.
Source?
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above,
s that we move
to such a tool mostly come from people who would have contributed
anyway. People who want their code in, shifting the burden of
maintenance to the project, but do not want to invest time into learning
different tools, even when they are superior.
Regards,
--
Nicolas
:
5.1. Add dphi_rem to phi_rem.
5.2. If phi_rem >= 0, subtract dphi_den to it and increment phi.
Regards,
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscr
tests/ref/fate/swr-async-firstpts | 2 +-
> 4 files changed, 94 insertions(+), 90 deletions(-)
Urgh, this is abominable.
NAK!
Regards,
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmp
test filter
from 10^-9 to 10^-19 is a very minor enhancement that could easily
shelved until benchmark can be obtained.
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubsc
James Almer (12024-11-05):
> Asking for benchmarks on old CPUs that are running deprecated or obsolete
> OSes is not reasonable.
I did not ask that they be running deprecated or obsolete OSes, so…
Also there are recent ARM32 CPUs.
--
Nicolas
Anton Khirnov (12024-11-05):
> 32bit CPUs are effectively obsolete and heading to extinction
The idea that FFmpeg is only for new hardware and should not support
“obsolete” hardware is unreasonable.
--
Nicolas George
___
ffmpeg-devel mailing l
Anton Khirnov (12024-11-05):
> That is an unreasonable demand IMO.
Care to elaborate why requesting benchmarks for changes on a filter that
was designed for speed on the architectures it would be most impacted on
seems to you unreasonable?
--
Nicolas Geo
an emulation or compatibility mode, and preferably a low-end
one.
Regards,
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpe
ction (so AVBufferRef → 🗑️).
Eventually, these AVWhateverLibraryInstance take charge of all global
mutable state: log callback, threads manager, overridden memory
allocation functions, etc.
I have had all this designed for quite some time.
Regards,
--
Nicol
shared
FFmpeg on the system. So I wonder one would utter such an obvious
falsehood.
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffm
everal megaoctets with a custom build?
--
Nicolas George
___
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 subject "unsubscribe".
with what
ff_filter_process_command() does, i.e. change the value of options on
the fly.
Note: commands are not a part I am familiar with, I had to check and it
took me less than 30 seconds. You could have done the same.
--
Nicolas George.
___
ffmpeg-devel mailing li
Anton Khirnov (12024-10-15):
> headers, but that first requires to eliminate its use.
Not an excuse to remove the feature it was used for at the same time,
especially without warning about it.
--
Nicolas George
___
ffmpeg-devel mailing list
ffm
ommand callback, once as the flag. Having
the same information twice in the source code is a recipe for bugs:
unavoidably somebody will update one and not the other.
The correct way of doing this would be to add a function in libavfilter.
--
Nicolas
Alexander Strasser via ffmpeg-devel (12024-10-14):
> Learning question: How can we see this is a private field?
I suppose “revert everything and start again properly designing things
without loss of feature” will not be appreciated?
Regards,
--
Nicolas Geo
Anton Khirnov (12024-10-13):
> > I was experimenting with mencoder
> why oh oh god why?
Among other things, because on that other project there are no people
who think they can tell their fellow developers what they should or
should not be working on.
--
Nicol
anged.
This is making the code worse. Please stop and do better.
--
Nicolas George
___
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 subject "unsubscribe".
e memcpy()
to fetch/return it.
- Have an instance of the struct in the buffersrc/sink and make it
available for that use.
Regards,
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/f
op the series altogether.
--
Nicolas George
___
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 subject "unsubscribe".
Anton Khirnov (12024-09-23):
> ---
> fftools/ffplay.c | 20 +---
> 1 file changed, 17 insertions(+), 3 deletions(-)
What an enhancement!
--
“I dont see why” isn't an argument.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
htt
this flag is set, av_buffersink_get_frame_flags() fills the non-data
> + * fields of the supplied frame without causing any filtergraph activity.
> + *
> + * @note While frame data will be NULL, certain other allocated fields may be
> + * filled (e.g. ch_layout, hw_frames_ctx), so the
Anton Khirnov (12024-09-23):
> I fail to see
…
> how that is a problem, since you need an allocated AVFrame
> to use the buffersink API anyway.
Not at the same point in code.
> Not to mention that even if one allocates a dedicated AVFrame for the
> parameters, the cost is trivial
Anton Khirnov (12024-09-23):
> That is all av_buffersink_get_*() except type and frame_rate, for which
> AVFrame does not currently have fields.
NAK: an API that requires an allocated AVFrame to retrieve the
parameters is significantly worst than the existing.
--
Nicolas
is the proper fix,
but it is highly unlikely any other change is.
Regards,
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-deve
now the technicals of
this instance, but the first version of this patch looks like it could
be the proper fix fix. The second version is not a fix at all, no need
to know the technicals to know it.
Regards,
--
Nicolas George
___
ffmpeg-devel mailing li
s. Add asserts where there are none.
Regards,
--
Nicolas George
___
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.or
ike is…
concerning.
--
Nicolas George
___
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 subject "unsubscribe".
on. It is not something
one can resign from, and even less something one can be expelled from.
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link abo
necessary, but it is possible a small bit in
the common framework is missing to fully work with the simplified
interface.
Regards,
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-
me.
--
Nicolas George
___
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 subject "unsubscribe".
ave to think about when you design an
API.
--
Nicolas George
___
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 s
idget(opt);
} else {
???
}
What do you put in the else clause when you already handled all types
you know how to handle?
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman
f you are using a 2026 FFmpeg with an application
from 2024, all the types introduced in FFmpeg between 2024 and 2026 will
be and cannot have a specific GUI, unless they are trivial enumerations.
This is why you need powerful text manipulation even with GUIs.
--
Nicol
lso blocked by the lack of a good strings API:
- exfiltration of structured data (statistics, detection…) from filters;
- rich built-in documentation;
- API for error reporting (≠ logging);
- list not exhaustive.
Regards,
--
Nicolas George
___
ffmpeg-
y, the fftools
should be just user interface around the high-level APIs provided by the
libraries.
Regards,
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, vis
Paul B Mahol (12024-06-17):
> And once you close all buffersinks the EOF will and must propagate backward
> to all not-closed filters and their in/out pads.
Your analysis here is right, obviously. Closing a source for this bug
makes no sense.
Regards,
--
Nicolas
Nicolas George (12024-04-14):
> Either we find options to make ffplay display frames as fast as
> possible, or we must document to the user that no adequate replacement
> exists.
Please add “-vf setpts=0”. It still has a little more latency than a
built-in device, but at least the featu
the last one
is almost instantaneous.
Either we find options to make ffplay display frames as fast as
possible, or we must document to the user that no adequate replacement
exists.
Or we make a point of fixing the devices that were broken.
Regards,
--
Nicol
Tomas Härdin (12024-04-12):
> Makes me wonder what kind of devices people run that haven't been
> updated in 10+ years..
The kind of devices that no longer get software updates but the owner
cannot afford to replace.
--
Nicolas George
___
an older package was 2017, build 152.
While the last time FFmpeg added features… is not that recent since
features are more being removed these days, but still recent enough.
Regards,
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@f
Niklas Haas (12024-04-10):
> I think a greedy algorithm (not requiring juggling multiple random
> passes) can still work,
It does not work for audio. Have you studied what works for audio? It is
quite subtle and full of pitfalls.
Regards,
--
Nicolas
ime display devices, prevent me from
adding the strings API necessary for proper built-in documentation and
information exfiltration from devices, etc., and apparently can.
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https:/
wer to enforce. I am ancient enough in
the project to remember the time where supporting every use case was
almost an official motto, and lucid enough to realise that it was the
main reason for the success of the project.
--
Nicolas George
___
ffmpe
7;m making a normative argument.
I do not know what you try to mean here and I do not want to know. I
hope you realize you have no authority to decide which ASS file is valid
and which is not.
--
Nicolas George
___
ffmpeg-devel mailing list
ffmp
upposed to be already sorted; ASS demuxer sorts its packets because
there is no guarantee the text are sorted in the file. [exploding head
emoji]
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/list
after the
dialogues, relying on sorting by the player.
(But I guess in the New and Improved FFmpeg, files originating from the
fansub world are not worth our time, it is enough to be able to decode
files for Crunchyroll…)
--
Nicolas George
___
ffmp
an option.
Please let somebody else do it.
--
Nicolas George
___
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 wit
p, and re-instate a
project leader from the second category. Or just consider that the
ousting of the leader was unlawful.
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To un
Those
who cannot learn from history are doomed to repeat it.” New contributors
who are not familiar with these events need to ear of them all the more.
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman
Ronald S. Bultje (12024-03-08):
> I hope you realize that is what reconciliation looks like.
No, it is not. It is what a takeover disguised as reconciliation looks
like.
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
ht
cedures and evolution.
--
Nicolas George
___
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 subject "unsubscribe".
Sean McGovern (12024-03-08):
> Everybody can we *please* keep the responses civil/professional on the ML.
Civil, certainly, provided others are civil to me.
Professional, not a chance. This is Libre Software, not a job.
--
Nicolas George
___
ffm
that, “shut up, I'm on the CC too”.
Regards,
--
Nicolas George
___
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 subject "unsubscribe".
ed one of the options.
But at this point, what's a little more of it…
Regards,
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
f
d luck proving nobody in the whole world ever chose to try this
codec and kept the file. Maybe they are not even subscribed to this list
right now. I know, shocking!
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmp
J. Dekker (12024-02-28):
> Keeping the codec around based on 'what if?'s doesn't seem
> reasonable.
Spending your efforts on it, even if it is just to remove it, is a waste
of your time.
--
Nicolas George
___
ffmpeg-devel mail
proposal strengthens the rule, by making it clear recusal is the
expected action when there is the slightest doubt about a bias. It is
the only way to keep members of the TC equal to the other developers.
--
Nicolas George
___
ffmpeg-devel mailing lis
gt; Signed-off-by: Hanna Ciebiera
Hi. This is completely wrong. And I am pretty sure with this patch the
compiler produces a new warning that tell that it is wrong.
Regards,
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
ht
e, it was because you thought it was
right to apply it, that this rule applied would make the ruling more
just and trustworthy.
My proposal wants to make absolutely clear your concern was valid.
Regards,
--
Nicolas George
___
ffmpeg-devel mailing l
Michael Niedermayer (12024-02-23):
> Each option should provide a patch.
Fine. But the wording can be discussed too.
Regards,
--
Nicolas George
>From 7955ed2c1074f85f0f55a58072a8623c8ff4bf34 Mon Sep 17 00:00:00 2001
From: Nicolas George
Date: Fri, 23 Feb 2024 15:12:51 +0100
Subject:
in my alternate proposition as is.
--
Nicolas George
___
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 subject "unsubscribe".
Kieran Kunhya (12024-02-20):
> This isn't the same thing. The TC is more like a jury where a juror can
> have an opinion and their opinion can be swayed by arguments during private
In a jury trial, the defense can recuse any juror they want.
--
Nic
1 - 100 of 1141 matches
Mail list logo
