michaelni changed the topic of #ffmpeg-devel to: Welcome to the FFmpeg development channel | Questions about using FFmpeg or developing with libav* libs should be asked in #ffmpeg | This channel is publicly logged | FFmpeg 6.1.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
<Lynne>
oh no, it begins
<IndecisiveTurtle>
:(
rvalue has quit [Ping timeout: 255 seconds]
<psykose>
i got trolled in the first 10 minutes
<IndecisiveTurtle>
Lynne: Could you explain a simple outline regarding the more technical side of the proposal? I know it will be about writing the vc2 encoder and the benefits of hand-made implementation compared to hardware encoders are visible, something more about the journey. Like how we plan to optimize with subgroup opts and if we can expect it to reach close/match the hardware encoder performance?
rvalue has joined #ffmpeg-devel
<IndecisiveTurtle>
I think something quite simple would be fine, but good to make the proposal more complete
<Lynne>
IndecisiveTurtle: chances are, it will be fast enough even without subgroup ops
<Lynne>
in terms of priority, after getting it running with simple haar transforms, would be implementing more advanced wavelets (5/3 legall or 9/7), and better rate control and AQ
<IndecisiveTurtle>
Mhm
thilo has quit [Ping timeout: 260 seconds]
<Lynne>
then it's feature complete and finished, up to you what do to next, either writing a decoder or moving on to another codec, or something different
thilo has joined #ffmpeg-devel
<IndecisiveTurtle>
Decoder sounds like a natural evolution after the encoder for VC2
<Lynne>
sure, wouldn't be too difficult for you after writing the encoder
<IndecisiveTurtle>
I would like to tinker with fvv1 though, you said it's too hard for a gsoc project but after that we got all the time :p
lexano has quit [Ping timeout: 240 seconds]
<aaabbb>
what makes ffv1 particularly hard?
blb has quit [Changing host]
blb has joined #ffmpeg-devel
<Lynne>
IndecisiveTurtle: absolutely, feel free to hack on it when you get bored enough
<Lynne>
aaabbb: it's the entropy encoding system
<Lynne>
ordinary golomb ffv1 is about as easy as a vc2 encoder
Oneric has quit [Changing host]
Oneric has joined #ffmpeg-devel
<Lynne>
but you easily lose 30-50% of compression with golomb
<Lynne>
but with entropy encoding, you have state that needs to change upon writing every single bit
<Lynne>
which makes it difficult to parallelize
<aaabbb>
isn't there some sort of hypothetical input that could poison ffv1's entropy coding and force it to constantly mispredict?
<Lynne>
it's called white noise, but even then, EC is still more efficient than golomb
<Lynne>
your best bet for parallelization is to limit all impossible state modifications, save the possible ones, and use a pass on the CPU to produce a single coherent stream
<aaabbb>
oh maybe i was thinking of a different codec then
IndecisiveTurtle has quit [Ping timeout: 268 seconds]
dre-droid has quit [Remote host closed the connection]
HarshK23 has joined #ffmpeg-devel
<michaelni>
j-b, we still have to apply that patch from JiaT57, it comes with sponsorship from Jong Kim Un _AND_ NSA, they said its joint work and very important for their countries inteligence sharing agreement. Its just that peski issue they cant fix. Also the code needs to be cleaned up first so everyone can see what exactly its doing. Its quite brilliant
<michaelni>
I think they are just going to patch valgrind to fix the remaining issue
<michaelni>
but they said their deadline is 2024.04.01 thats today so iam not sure they will make it
<kierank>
The NSA has indirectly supported FFmpeg a lot
<kierank>
With ghidra
<Daemon404>
ehhh most of ffmpeg used ida pro
<Lynne>
wish ghidra would do something, just shows a blank screen for me
kurosu has joined #ffmpeg-devel
<elenril>
Lynne: waiting until I wake up
<elenril>
huh, the results are interesting
<kierank>
11:49:44 <Daemon404> ehhh most of ffmpeg used ida pro
<kierank>
Not for years
<Daemon404>
most important RE was years ago
<Lynne>
there's still a need to hack old binaries to keep them running
<kierank>
I bet the xz situation won't stop the obsession with upgrades many people have
Krowl has quit [Read error: Connection reset by peer]
<JEEB>
yea, IDA Pro or its demo was previously the most used, nowadays I'm getting to grips with things with Ghidra alright. baby's first windows binary analysis, but still enjoyable
<j-b>
michaelni: hahah :D
<Gramner>
kierank: on the flip side it's not like the patches to stable distributions cover more than a tiny fraction of all bug fixes with security implications. so it's a case of picking your poison - do you want old issues or new issues? sometimes one is preferable over the other
<kierank>
j-b: when do we leave Bulgarian host
<Gramner>
not to mention that if nobosy is using the unstable stuff that just means stable becomes the new testing ground
<kierank>
Gramner: fair point
<JEEB>
yea
<JEEB>
I've really noticed how little testing comparatively esp. on linux master builds get
<JEEB>
then when things hit distros, that's when you suddenly get the reports
mkver has joined #ffmpeg-devel
lexano has joined #ffmpeg-devel
b50d has joined #ffmpeg-devel
pmozil has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
b50d has quit [Remote host closed the connection]
pmozil has quit [Quit: Client closed]
pmozil has joined #ffmpeg-devel
pmozil has quit [Remote host closed the connection]
pmozil has joined #ffmpeg-devel
pmozil has quit [Remote host closed the connection]
pmozil has joined #ffmpeg-devel
pmozil has quit [Remote host closed the connection]
pmozil has joined #ffmpeg-devel
pmozil4 has joined #ffmpeg-devel
pmozil has quit [Remote host closed the connection]
pmozil4 has quit [Client Quit]
pmozil has joined #ffmpeg-devel
cone-271 has quit [Quit: transmission timeout]
pmozil has quit [Quit: Client closed]
pmozil has joined #ffmpeg-devel
<pmozil>
@IndecisiveTurtle, Hello, i'm the second student that applied for the vc2 encoder to GSoC. If it is fine with you, I'll do the decoder then
<JEEB>
they don't have everything there, for example 2128 is not public (yet?). but a whole bunch of previously closed stuff is now publicly available
jamrial has joined #ffmpeg-devel
<IndecisiveTurtle>
pmozil: Halo, yeah also applied for that project. I'm not too picky though, Lynne said jpeg2000-ht exists as an alternative. Most pressing is the 48 hour deadline now, so need to prepare the proposal haha
<IndecisiveTurtle>
I would prefer vc2 slightly over that as it's related to video though
<JEEB>
movie theatre masters are using j2k because it's slow to swdec
<Lynne>
proposals don't need to be airtight, they're normally only read by mentors, a few sentences would be enough
<pmozil>
IndecisiveTurtle: If you wanna do the full vc2 codec, I cold do the jped200 one, though I too think that we should split it now, as to touch up the proposals a bit. So, would you like to do the full vc2 codec, or do we split it and do an encoder and a decoder each?
<pmozil>
Sry, I meant one of us doing the encoder, and another the decoderr
<Lynne>
*jpeg2000-ht, jpeg2000 is pure madness
<thardin>
j2k is basically cabac on every single bit
<thardin>
at least it's designed w ||ism in mind
<BBB>
j-b, kierank: we should use the xz fiasco to re-start talking about open source software sustainability
<j-b>
BBB: yes.
<pmozil>
Lynne: sry
<kierank>
BBB: yes, but arguably the problem is ever so slightly different in the xz case
<kierank>
Imo it's the obsession with upgrades on stuff which is "done*
<kierank>
And the lack of lts in open soirce
<Daemon404>
BBB, or... and stay with me on this... our infra situation in which we dont know who has access to what
<BBB>
ever so slightly different =~ basically the same
<BBB>
Daemon404: I agree, I have been asking that question also
<kierank>
A lot of these projects should just be frozen and fuzzed
<BBB>
meh
<BBB>
I disagree
<BBB>
I agree that "xz development" was silly
<BBB>
but fuzzing implies fixing which implies changes which is the opposite of frozen
<BBB>
so the two are in direct contradiction
<kierank>
It's the same issue with SSL libraries, the complexity is in all the weird stuff. There was a presentation at fosdem about this
<BBB>
you need a knowledgeable maintainer who is happy to do that for a living while being paid for it
<kierank>
It's feature development in stuff that is "done"
<kierank>
That's where sqlite have it right
<Daemon404>
a lot of core stuff is in exactly that done state already
<IndecisiveTurtle>
pmozil: Sure sounds good. I think it would be best to consider the amount of work together with how many improvements will be contributed to ffmpeg. If the full vc2 codec is about the same amount of work with jpeg2000-ht, would probably be better to split it that way. Otherwise it should be okay to split the vc2 work
<BBB>
there are so many lessons to be learned here and next steps to be taken
<BBB>
but that's for others
<BBB>
one thing we should focus on is hammering on the sustainability nail
<BBB>
a nail has presented itself, we are the hammer
<BBB>
go ham boys
<Daemon404>
all the corporate support in the world wont fix the core ffmpeg sustainability problem: multimedia isnt sexy
<Daemon404>
-> no new blood
<Daemon404>
(i say, as some gsoc students linger)
<BBB>
but Daemon404 that is another problem
<BBB>
sustain is not to grow anew
<BBB>
they are both important
<BBB>
the problem we've been trying to talk about is sustainability, allowing some of us devs to be paid to work on ffmpeg in a way that is fair and allows for long-term project involvement
<BBB>
you're right we need new blood also, but that's a separate angle, I think
<BBB>
the two go hand in hand
<Lynne>
IndecisiveTurtle: pmozil: do both of you think one can do both an encoder and a decoder?
<IndecisiveTurtle>
I'm not quite sure myself, this task was my introduction to wavelet transforms in general. But assuming one person does them both, it will probably be easier for them to write the other having gained knowledge of the codec. How many LoC do you expect for that combined work to be?
<pmozil>
Lynne: I mean, just implementing the wavelets wouldn't be that difficult. The hardest part would be actually making it conform to the vc2 standard. I believe it would be best to split the encoder and decoder, and then, if we have the time, just do the same with htj2k
<IndecisiveTurtle>
Hm diving the work might be best then, if it give us to opportunity to better test and verify the implementation against the standard
Krowl has quit [Read error: Connection reset by peer]
<pmozil>
vc2 conformance software has the decoder and encoder tests be separate too, i think us splitting the work would be logistically easier
<elenril>
>we have no idea what to teach young people that will still be relevant in 20 years
<elenril>
who can seriously say stuff like that
<nevcairiel>
guess our votes for not taking part in this nonsense day were overruled then
<elenril>
calculus and linear algebra have been around for centuries, odds are they will last a bit more
<Lynne>
j-b: yes, haasn agreed to co-mentor, but I think thardin knows enough to help out too if I'm not available
<pmozil>
Hardware design will probably stay relevant, at least the analog stuff
<Lynne>
I'm of the opinion everything should be digital, and if digital is not good enough, then it should be made good enough
<Lynne>
but I'm often told I don't live in the real world
AbleBacon has joined #ffmpeg-devel
<pmozil>
Hahahahah, i meant the analog part of like power supplies and relays, lol
<pmozil>
Though digital degign would also be pretty relevant for a while, but it'd probably change a lot, ig
Krowl has joined #ffmpeg-devel
<Lynne>
even analogue is going digital-ish, with switching power supplies and class-D/E/F amplifiers
<elenril>
the universe is digital on the fundamental level
<elenril>
checkmate, EEs
<Lynne>
there's no escape, not when you can buy 2 cent microcontrollers in volume with built-in flash and ADCs/DACs to do what you'd otherwise do with dozens of discrete analogue components
<Lynne>
elenril: better still, electricity is purely digital, we only make do with flooding atoms with electrons because we can't perfectly control single atoms
<elenril>
if you want to be precise, only bound states are discrete
<elenril>
continuous spectra do exist
<elenril>
unless you subscribe to some discrete-spacetime theory, then everything is discrete
rvalue has quit [Read error: Connection reset by peer]
<pmozil>
Woah, CPLDs cost like $1 a piece. You really can make anything digital now
<Lynne>
if you want to nitpick, quarks in their unhadronized form are non-discrete fractions of the elementary charge
rvalue has joined #ffmpeg-devel
<jdek>
kierank: banger tweet
<Lynne>
pmozil: but why would you get CPLDs when you can actually buy sub-5 cent microcontrollers with memory and moon-lander arithmetic performance?
<elenril>
quark states have discrete charges iirc
<kierank>
jdek: a lot of people think it's real
<jdek>
wish
<elenril>
then again good luck getting 1) any nontrivial QCD computations 2) unbound quark states
<elenril>
also I just remembered QED is nonlinear and a photon-photon vertex exists, so it's all moot anyway
<Lynne>
yeah, you don't observe free quarks long enough such that they have time to interact with other particles with the electromagnetic force
<Lynne>
unless you subscribe to a GUT
<elenril>
I subscribe to a MUT
<elenril>
obviously QCD and electroweak should be unified
<elenril>
but gravity is geometry and therefore separate
<Lynne>
ah, but quarks interact with the weak force, which becomes unified as the electroweak force, but then charges start to lose their meaning as nothing remains stable enough to interact
<pmozil>
Lynne: You're right, i'm just kinda swayed( a cypres employee mentored my project, and they really like PLAs
<Lynne>
nah, they just had a whole bag of them lying around after ordering the entire world's supply by mistake and need to get rid of them
<pmozil>
lol, you're probably right
<elenril>
charges don't lose their meaning IIRC
<kierank>
STV is completely insane
<elenril>
charges are noetherian conserved currents, and hence well defined
<kierank>
Nicolas proposition was heavily voted 7
<kierank>
yet the final outcome is 4
<elenril>
independenly of your energy state
<Lynne>
elenril: you don't believe that changes in spacetime curvature are discrete?
<kierank>
this is why the public don't trust neckbeard voting systems
<elenril>
kierank: "the public" has no clue and should be ignored
<kierank>
said every dictator
<elenril>
Lynne: according to LQG they are, so I guess I do
<elenril>
would be nice to have an actual testable theory though
<elenril>
kierank: feel welcome to present an actual analysis
<elenril>
"it looks wrong" doesn't count
<kierank>
it's the other way round, a lot of people give it a 7 and it ends up as a 4 is complete BS
<kierank>
15/23
<kierank>
the minority is able to sway what the majority believe
<kierank>
in the name of intellectual voting purity
<kierank>
gyan proposal has a pretty poor showing too
<elenril>
his proposal wins 16/5, 13/7, and 11/7 against Michael 2, leave, remove
<elenril>
and loses to others
<elenril>
hence it makes sense that it's in the fourth place
<elenril>
I see no issue
<kierank>
thank god this isn't voting in TC or something
<elenril>
TC would probably use the same system if we ever had a complicated vote
<kierank>
it perpetuates the "disciple" problem we have in this community
<elenril>
are you proposing an alternative system?
<elenril>
I don't even see what the problem is
<kierank>
disciples can follow their leader and get elected even if the majority strongly disagree
<elenril>
minorities should get their representation
blb has quit [Ping timeout: 256 seconds]
blb has joined #ffmpeg-devel
<kierank>
1/4 of the power but less than 1/4 of the support
<kierank>
maximising extreme positions
<kierank>
in a real democracy this method would be voted out immediately
<elenril>
no, I don't think that's how it works
<elenril>
the number of representatives a faction gets is proportional to its support in the electorate
<kierank>
if N is large, yes
<elenril>
that's an explicit goal of the system we use
<kierank>
but it's not large
<kierank>
where N is the number of seats up for election
<kierank>
it is not large, hence in this example, the strong opinions of tiny put nicolas in 4th place
<elenril>
I think our committees are broadly representative
b50d has joined #ffmpeg-devel
<kierank>
of a tiny minority
<elenril>
it's not a tiny minority
<Daemon404>
stv does seem like a poor choice for literally ranking 1-7
<elenril>
16 people prefer nicolas over michael 1
<elenril>
13 people prefer nicolas over leave as is
<elenril>
11 people prefer nicolas over remove
<elenril>
the last one is small, but not tiny
<Daemon404>
not really surprisingly anal retentive projects like anal retentive voting systems for simple things tho
<elenril>
the others are rather large
<kierank>
Daemon404: should be a run off imo, it's the goat problem
<kierank>
people vote differently based on the options
<kierank>
the system assumes people rank equally but they would rank based on teh 7 options they see
<elenril>
because tactical voting is so great
<Daemon404>
i bet yet again almost all the voters didnt understand that it isnt selecting spots 1 to 7 when you vote
<Daemon404>
gyan seems not to have
<JEEB>
yea, at least it explained that in the doc before the listing that things can share a spot
<elenril>
doesn't matter, as long as you understand that 1 is like and 7 is not like, then the system will DWIM
<JEEB>
yea, put some high and some low
kurosu has quit [Quit: Connection closed for inactivity]
<Daemon404>
id argue a voting system that the electorate struggle to understand is overly clever and a poor choice
<elenril>
I'd argue a voting system that encourages people to vote tactically is a ridiculously bad choice, when better systems exist
<elenril>
and I don't see what's so hard about "rank things in order of preference"
pmozil has quit [Remote host closed the connection]
pmozil has joined #ffmpeg-devel
<nevcairiel>
STV is a good and fair system without meta-shenanigans, a tiny bit of understanding to rank your choices doesnt seem like it should be a burden, its just ranking your choices
<nevcairiel>
why it doesnt get used for coutnry elections? because those are not wanted to be fair, but benefit those that made the rules
<kierank>
Lol
<kierank>
I love business 101 and now politics 101 from FFmpeg
<elenril>
you started this discussion you know
<kierank>
All wrapped in a sandwich of conspiracy theory as per anything in ffmpeg
<elenril>
"voting systems are hard to change because elected representatives would need to vote against the system that gave them power" is a pretty mainstream position though
<kierank>
15:47:42 <• elenril> and I don't see what's so hard about "rank things in order of preference"
<kierank>
Because it's not about voting for preference, it's about voting for the actual thing
<kierank>
Those are not the same
Workl has joined #ffmpeg-devel
Krowl has quit [Ping timeout: 272 seconds]
<nevcairiel>
but it is, "I would really like this thing to be the new rule (put at 1), but if it doesn't win, I would prefer this other one (put at 2), over these ones (put further down)" .. if you only let users pick their one favorite, you disregard any gradient of choice
<jamrial>
yeah. in this vote in particular there were two very similar options, michael's, so voting only one would potentially split the vote and make both lose
<nevcairiel>
thats why you have to vote strategically in those single-favored choice votes
<nevcairiel>
because if you vote for an unpopular option, your vote might as well not be cast
<jamrial>
whereas with order of preference, you can give both the same preference, or one immediately below the other, and both will still have a chance
<kierank>
And that's exactly why it's a dumb system for voting a committee
<kierank>
As it forces you to make false comparisons
<kierank>
Between lesser evils
<nevcairiel>
you can just put everyone you dont want at the lowest number, STV doesnt make an average out of the numbers or anything like that anyway
<elenril>
kierank: are you suggesting that a runoff system does not force you choose between lesser evil
<elenril>
it's MASSIVELY worse in that regard
<elenril>
see e.g. US presidential elections
<kierank>
If N candidates is large you would have more choices
<kierank>
But it's not
<kierank>
So unpopular candidates end up getting elected
<kierank>
As would have happened in this example
<kierank>
And you can't argue everyone understood this as a candidate himself didn't even understand
<elenril>
again, a person only gets elected if their support among the electorate is at least 1/N
<elenril>
which seems fair to me
<kierank>
Wild, allows a vocal minority to have a huge control
<kierank>
Over the views of the majority
<nevcairiel>
thats really not how it works
<elenril>
it's proportional to their size, so I don't see how it's "huge"
<nevcairiel>
if you have 100 people voting and 20 people vote for 1 person to get one of 5 seats, that seems like representation to me
<elenril>
BUT, you can proposa a different voting system
<elenril>
and we can have a vote
<kierank>
But the numbers are small, if you look at the Nicolas case there is strong opposition yet he comes 4th
<elenril>
and it'd be a single-choice vote, so none of this propotional stuff applies
<nevcairiel>
low numbers mean nothing in STV
<nevcairiel>
err, high numbers mean nothing
<nevcairiel>
low numbers is what counts
<kierank>
So that strong opposition to his proposal means nothing obviously because a few people believe in it strongly
<kierank>
This is why the public never accepts neckbeard voting systems
<nevcairiel>
this is not about down-voting what you hate, but voting for what you want
pmozil has quit [Remote host closed the connection]
<nevcairiel>
like, how all elections work
<elenril>
*should* work, you mean
<elenril>
many actual public elections are actually about downvoting what you hate, because of those awesome shaved-neck voting systems
<j-b>
You should vote for a tyrant
<j-b>
Like Elon
<elenril>
paul for bdfl
<nevcairiel>
actually if you break that down to a "only favored choice", more people voted 1 for nicolas then they did for gyan, michael 1, left as is, or removed, and equal to michael 2, the argument that it has no support seems to just not be there
<another|>
Daemon404: I disagree about the core ffmpeg problem. IMHO the core problem is the toxic community with regular flamewars fueled by different goals from different people, underpinned by legal uncertainty.
<JEEB>
yea, some parts of the community are a problem as someone decides to give the project a try. while dae is mostly mentioning the problem with lack of interest to even attempt. both are definitely problems.
<kierank>
another|: wrapped in paranoid conspiracy theory sandwiches
<kierank>
16:20:46 <• nevcairiel> actually if you break that down to a "only favored choice", more people voted 1 for nicolas then they did for gyan, michael 1, left as is, or removed, and equal to michael 2, the argument that it has no support seems to just not be there
<kierank>
No words
<j-b>
I read that proposition A has 15 people voting it 7th place (on 23 people). It's clearly the less wanted.
<nevcairiel>
thats not a factor in evaluating votes though, its how many people want it, not how many people don't. so if you are voting for a commitee, you get representation anyway.
<j-b>
we're not voting for a commitee, here.
<nevcairiel>
which means anything but #1 is irrelevant
<nevcairiel>
so why are we discussing spot 4?
<j-b>
nevcairiel: no idea :D
<j-b>
I got in the middle of the discussion :D
<j-b>
nevcairiel: I guess because it's Easter Monday and we're bored and avoiding family reunios
<nevcairiel>
in this vote the system used was entirely pointless anyway, because #1 won with an absolute majority of favored choice
<Daemon404>
arguably the whole vote was entirely pointless
<nevcairiel>
pretty much, but if you cant get your way you complain about the rules, apparently
<Daemon404>
that outlook and spot 4 may have something in common
<nevcairiel>
the entire concept of "we have people with the entire purpose of having an opinion about the code" and "but if their opinion is bad for me, they must be excluded" is totally dumb
<JEEB>
yea
<nevcairiel>
i'm totally with you that it makes sense if they are pushing for a patch, the investment there is different, but if they are the reviewer .. thats why they are in the TC to begin with
<haasn>
Maybe I wasn’t joking after all when I suggested we switch to a cardinal voting system
<Daemon404>
battle royal, been saying it for >10 years
<Daemon404>
royale*
<jamrial>
mtg tournament
<elenril>
nevcairiel: I don't agree that it makes sense for patch authorship either
<elenril>
e.g. I have an opinion on how things should be
<elenril>
I use that same general opinion to write patches, review patches, and vote in TC
<JEEB>
opinion is not conflict of interest. also one person is just one person of any committee
<nevcairiel>
in an ideal world sure, but if you are the one asked to re-do or abandon your work, you might have non-technical feelings influencing that
<elenril>
that's why we have 5 people and regular elections
<nevcairiel>
i suppose so, it doesnt really come up often enough to even be an issue to me
<elenril>
you could have non-technical feelings about anything here
<nevcairiel>
that this entire patch went to TC to begin with was already stupid, just change it
<elenril>
you could just dislike the patchauthor
<elenril>
we have to trust that TC members are above such things
<Daemon404>
LOL
<Daemon404>
is that a joke
<nevcairiel>
but i'm also a bit more non-confrontational
<elenril>
I think the main problem with our system currently is that voters don't see how their representatives vote
<Daemon404>
i think 4/5 of the committee members would be fine with people seeing that.
<jamrial>
last few CC votes were unanimous, and i don't recall a recent TC vote
<jamrial>
unless you meant the process
<elenril>
jamrial: many CC votes end up in /dev/null
Workl has quit [Read error: Connection reset by peer]
<elenril>
and if you're not in CC you don't get to see why
<jdek>
Daemon404: public votes? or wdym, I honestly don't understand how the voting system works I just rank it
<elenril>
jdek: this is about the votes inside the committees themselvs
<Daemon404>
jdek, public cc and tc votes
<Daemon404>
not ga
<jdek>
what difference would it make for 5 people votes
<jdek>
besides like
<jdek>
>elenril blocked my patch again zzz
<Daemon404>
for nicolas? 0.
<Daemon404>
but i dont see a reason it should be private.
<nevcairiel>
nicolas doesnt write patches anymore
<nevcairiel>
he just trolls the ML
<jdek>
there's no r eason for it to be public either no?
<nevcairiel>
transparency, i guess
<Daemon404>
private == fuel conspiracy theories
<nevcairiel>
write a 500 word reasoning for your votes each as well, please and thank you :D
<jkqxz>
Is anyone actually against it being public?
<jkqxz>
If everyone currently on it agrees then it would be fine to publish everything.
<jdek>
get the tc to vote on it
<Daemon404>
the ga would vote on it
<Daemon404>
not tc
<jkqxz>
If not, there could be a GA vote before the next election. (And then people with a secret agenda would avoid standing.)
<nevcairiel>
a GA vote could force it, the TC could just decide to do it anyway
<jdek>
ok but we've done GA votes for 4 years now or whatever
<nevcairiel>
because there is no mandate to keep it private
<jkqxz>
(Not that anyone has disclosed their secret agenda in committee deliberations as far as I know. How disappointing.)
<jdek>
why do we have to vote on absolutely everything
<Daemon404>
you know the answer.
<jdek>
Never permit short-cuts to be taken in order to expedite decisions.
<Daemon404>
i was gonna go with something else, but yours is better
<elenril>
>@jdek | there's no r eason for it to be public either no?
<elenril>
the reason for it to be public is that you know who (not) to vote for in the next TC/CC election
<Daemon404>
i think of it like parliament/congress/etc
<elenril>
oh look, it's paul again
<jkqxz>
Voting provides the illusion of consensus so that the secret cabal can continue to decide everything behind the scenes.
<j-b>
conspiracies!
<Daemon404>
going to start FAnon
<j-b>
I will do XZAnon
<j-b>
XZ is going to be much more funny/sad soon
<jdek>
replaced by zstd already
Krowl has joined #ffmpeg-devel
<elenril>
do we have an official release name yet?
<jkqxz>
Wasn't that the vote we just did? It decided on "Anton".
<Daemon404>
lol
<elenril>
aw crap
<another|>
"Jia Tan" /s
<elenril>
[trolling intensifies]
<cone-628>
ffmpeg Michael Niedermayer master:19ad05e9e0f0: avcodec/jpeg2000htdec: Check magp before using it in a shift
<cone-628>
ffmpeg Michael Niedermayer master:7b7eea8e63f7: avcodec/jpeg2000htdec: warn about non zero roi shift
<cone-628>
ffmpeg Michael Niedermayer master:d6ed6f6e8dff: avformat/mxfdec: Check first case of offset_temp computation for overflow
<Daemon404>
'Back Door'
<cone-628>
ffmpeg Michael Niedermayer master:f26ee6e0667d: avformat/iamf_reader: Check len before summing
<cone-628>
ffmpeg James Almer master:0a693bce6216: avformat/iamf_parse: keep count_label consistent on language_label allocation failure
<another|>
at least I clearly marked it
<another|>
"Rob Banks" /s
<elenril>
anything said in this channel should be considered trolling unless proven otherwise
<elenril>
especially things said by cone-628
<another|>
How do you prove non-trolling?
<Daemon404>
FFmpeg 7.0 'Elon'
<elenril>
another|: that's the neat part
pmozil has joined #ffmpeg-devel
<elenril>
Lynne: should vulkan av1 changes be in changelog?
<j-b>
FFmpeg 7.0 "Trolling++"
<Daemon404>
FFmpeg 7.0 'Sponsored by Bitmovin'
<j-b>
Any cool math feature from VVC?
<j-b>
that could infer a cool math person?
IndecisiveTurtle has quit [Ping timeout: 260 seconds]
Raz- has joined #ffmpeg-devel
<BBB>
math? inverse transforms, of course
<BBB>
their symbol coder is just shitty h264, very disappointing
<BBB>
could've gone for a shiny new multisymbol one, but instead they went all 2001
<BBB>
sad
<BBB>
the warp features are also cool, as is the mv inference
<BtbN>
I learned about it by pure chance, and most of the added options would have been defunct without setting it. No idea why nvenc can't figure that out on its own. I just set it to some random integer++