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 7.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
cone-501 has joined #ffmpeg-devel
<cone-501>
ffmpeg James Almer master:1edc748effbd: avformat/movenc: explicitly support V30XLE and not the host native endian version
thilo_ has quit [Ping timeout: 252 seconds]
thilo_ has joined #ffmpeg-devel
iive has quit [Quit: They came for me...]
keithah has joined #ffmpeg-devel
keithah is now known as keith
keith is now known as keithah
keithah is now known as keith
em___ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
haihao has quit [Ping timeout: 255 seconds]
haihao_ has joined #ffmpeg-devel
mkver has quit [Ping timeout: 252 seconds]
haihao_ has quit [Ping timeout: 246 seconds]
haihao has joined #ffmpeg-devel
arch1t3cht5 has joined #ffmpeg-devel
arch1t3cht has quit [Ping timeout: 248 seconds]
arch1t3cht5 is now known as arch1t3cht
jamrial has quit []
cone-501 has quit [Quit: transmission timeout]
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 248 seconds]
zsoltiv_ has quit [Ping timeout: 252 seconds]
psykose has quit [Remote host closed the connection]
psykose has joined #ffmpeg-devel
rvalue- has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 252 seconds]
rvalue- is now known as rvalue
System_Error has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
ngaullier has joined #ffmpeg-devel
feiw1 has quit [Ping timeout: 252 seconds]
feiw1 has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
Workl has joined #ffmpeg-devel
Krowl has quit [Ping timeout: 252 seconds]
Krowl has joined #ffmpeg-devel
Workl has quit [Ping timeout: 276 seconds]
Workl has joined #ffmpeg-devel
Krowl has quit [Ping timeout: 252 seconds]
<pross>
finally solved the motion estimation problem for interlaced vp6
Krowl has joined #ffmpeg-devel
Workl has quit [Ping timeout: 252 seconds]
Krowl has quit [Read error: Connection reset by peer]
<beastd>
pross: cool. took a long time to arrive at the solution or didn't have time to work on it?
System_Error has quit [Remote host closed the connection]
<Lynne>
third, most likely option: it was really annoying
System_Error has joined #ffmpeg-devel
<pross>
beastd: time. plus debugging interlaced motion estimation requires a lot of mental energy
<cone-716>
ffmpeg Marvin Scholz master:c98810ab47fa: avcodec/hw_base_encode: fix use after free on close
Krowl has joined #ffmpeg-devel
Cheetahze has joined #ffmpeg-devel
j45 has quit [Ping timeout: 260 seconds]
j45 has joined #ffmpeg-devel
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
___nick___ has joined #ffmpeg-devel
___nick___ has quit [Client Quit]
___nick___ has joined #ffmpeg-devel
<haasn>
so
System_Error has quit [Ping timeout: 260 seconds]
<haasn>
how comfortable are people if I just copy paste libplacebo's filters.c and tone_mapping.c into libswscale
<haasn>
I really don't see a point in reinventing the wheel here
<JEEB>
if license matches, and it wörks and the code style isn't too different - then WhyNot
<haasn>
to eliminate double maintaining this code I could consider making libplacebo depend on it
<haasn>
it's LGPL v2.1+
<JEEB>
yea, so compatible
<haasn>
but I am the sole author of most of it
<haasn>
obviously I'd change some things to make it more compatible
<haasn>
but the overall algorithms etc would be the same
<JEEB>
yea
<haasn>
and the general API, particularly of pl_filter
<haasn>
so users can configure custom samplers the same way
<haasn>
I think this is pretty much the most flexible and future proof way of doing ih
<psykose>
if libplacebo depends on swscale for the code then isn't it circular since lavf depends on libplacebo
<psykose>
(optional but ykwim)
<JEEB>
lavfi you mean?
<psykose>
yea
<haasn>
not quite, since sws and lavfi are separate libraries and often packages
<haasn>
but yeah its' awkward for sure
<haasn>
I don't really see a good solution to that
<haasn>
I don't think people would be terribly happy about adding a mandatory third party dependency to swscale
<haasn>
one could even say that this was explicitly NAK'd by michaelni
<haasn>
not that I particularly disagree
<haasn>
if anything I could see myself spawning a new shared third party library that both sws and placebo can depend on
<JEEB>
but yea, as long as the basics are followed then I'd say reusing matching good code is not a bad thing
<haasn>
which would embed just the colorspace moth
<JEEB>
at first commented that it is based on XYZ in libplacebo, and if it ever becomes the primary source then that could be modified
<haasn>
but for now I'll just duplicate the code since it's unlikely I'll touch the libplacebo algorithms anytime soon
<haasn>
colorspace math even, though I now have a vivid mental picture of in irridescent moth coming to visit me
<psykose>
sounds good :)
<psykose>
get a sun lamp for the moth
<Daemon404>
Lynne, let's spend some time on priming/gapless at vdd maybe
<Daemon404>
strobe absokutely skewered ffmpeg's bad support last night at demuxed.
<Daemon404>
and i couldnt disagree
<Daemon404>
troll driven development...
<haasn>
the most productive I've ever been has been to prove a point
<haasn>
mostly that FOSS software can outdo $$$$$ proprietary garbage :)
<Daemon404>
well proprietary garbage is also bad at gapless
<Daemon404>
were just worse :D
System_Error has joined #ffmpeg-devel
<Lynne>
Daemon404: sure
<Lynne>
though I don't care about the opinions of anyone presenting at somewhere where you have to pay to watch
<Lynne>
let alone criticizing an open source project of volunteers
<Lynne>
if they sent me a shitpost-styled very angry email I'd probably fix it in 20 minutes though
<Daemon404>
itll be on yt soon but thats fair
<Lynne>
5 minutes if it had 1337speech
<Daemon404>
it was an aside in a presentstion about why hapless is hard
<Daemon404>
he did say maybe yt would send patches
<Daemon404>
but do you trust them do handle edit lists again?
<Daemon404>
inl dont
<Daemon404>
i also think some of the issues are specific to the cli... which is less fun
<beastd>
yeah, sure one can be annoyed about the style of critics, but as long as it contains actual information about problems it is very useful. basically someone doing work for you. (even if it's very hard to see if you feel personally attacked.)
<Daemon404>
we were already aware of our shortcomings here ;)
mkver has joined #ffmpeg-devel
<beastd>
Can be considered a "friendly" reminder still :)
<Daemon404>
with a healthy dose also of "other software doesnt geberate proper files"
<Daemon404>
sure is typos today
<beastd>
i keep hearing about gapless, but personally I'm not affected that much that I would consider looking into it. It's sure very useful for some usecases tho.
<Daemon404>
the case study he used was alive 2007 lol
<Daemon404>
tbf great album
<Daemon404>
if you go back to the vinyl days a lot of concept albums rely on it
<JEEB>
yea
<JEEB>
Daemon404: lol > yt > edit lists , that brings things to mind ^^;
<Daemon404>
ikr
<Daemon404>
"havent you done enough damage"
<elenril>
Daemon404: speaking of troll-driven development, mcw solemnly swears they'll fix the x265 bugs Very Soon now
<Daemon404>
LOL
<Daemon404>
i worked woth them directly on mvhevc
<Daemon404>
with them as a paid vendor
<elenril>
my condolences
<Daemon404>
i had to fix their own bugs myself
<Daemon404>
they werenr able to even comprehend my bug reports
<Daemon404>
so dont hold out hope
<elenril>
well, the recent abi breakage tells me they don't understand what abi is
<Daemon404>
its even worse
<elenril>
or the sigill problem mentioned yesterday
<Daemon404>
one of their buvs was because they assumed width==stride (because it is in their cli yuv reader)
<Daemon404>
thats the level of expertuse.
<Daemon404>
and it took a weel and me sending them a patch to get them to understand
<Daemon404>
week*
<Daemon404>
we still have like 3 patches locally
<Daemon404>
one is because they dont understand sonames
<Daemon404>
:D
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
<llyyr>
wasnt the bug reported to them in 2019? if they haven't fixed it until now I wouldn't think they will do it now
<elenril>
llyyr: they just promised on ML
<elenril>
because we threatened to mark it as experimental in lavc
<llyyr>
ah
<elenril>
also, there's even the patch on their bugtracker
<Daemon404>
are they gonna fix their 200 leaks too
<elenril>
so it's not that they don't know how to fix it, they just didn't care
<Daemon404>
and uninit mem use
<Daemon404>
i literallt have to ship a valgrind supp file at work to run tests
<Daemon404>
because it leaks
<elenril>
I know, I tried to add a fate test for it once
<Daemon404>
lol
<elenril>
which failed because it would trigger the valgrind instances
<Daemon404>
yep
<Daemon404>
ubrelated to anything
<llyyr>
>keep up code hygiene that we have maintained so far
<JEEB>
I noted this in May since fedora 40 defaulted to zlib-ng
<JEEB>
I have patches which allow to remove the bitexactness stuff (exact hash, size) from tests when those are not required
<JEEB>
but it seems like at least two people in that thread noted that focus should rather be on adding zlib implementation into FFmpeg itself. which I don't disagree with, but was not planning to do myself
<beastd>
Daemon404: With compression level 0 it should not differ and didn't as far as we could see with Ramiro's patch setting the compression level to 0 for tests relying on zlib
<JEEB>
and then there was something regarding zlib having differing results between versions or so?
<JEEB>
which is why that was reverted
<beastd>
Daemon404: Then there was a few tests differ for some people which ramiro tracked down to a bug in zlib (not zlib-ng)
<beastd>
yeah agree, the revert in itself is fine. just annoying for people that have systems with zlib-ng in place like me :)
<JEEB>
yes, I've had fedora 40 and 41 now for half a year and I need to each time run fate with GEN=1 :P
<JEEB>
and then check that if the diff is on expected files or not
<JEEB>
I do note that if you install zlib + devel package I think you can make the binary utilize normie zlib
<JEEB>
but I've been :effort: to do that
<Daemon404>
beastd, there is no guarantee comrpession level 0 is bit exact
<Daemon404>
afaik
<Daemon404>
i dont really have an opinion on adding an impl to ffmpeg, but testing the output for bit-exactness at any compression level is misguided.
<Daemon404>
the test itself is not a useful test
<JEEB>
yea, since the main thing is that the decoded result of encoded thing is the same
<JEEB>
which is what other parts of the test did test usually
<JEEB>
the fact that the encoded packet is EXACTLY of xyz size or checksum is not that importante
<Daemon404>
i'd consider it an anti-test to test that.
<Daemon404>
needlessly rigid, ensuring no progress can be made
<beastd>
Daemon404: I'm not completely, but so far I understood it this way that it is guaranteed for compression level 0
<Daemon404>
beastd, it becomes irrelevant regardless if we test the right thing.
<JEEB>
this was the example thing which I did methinks
<Daemon404>
this whole saga seems liek a cope around a rigid test/system =p
<beastd>
Daemon404: I'm not saying there is no other way. This just seemed the most approachable for now.
<Daemon404>
it's the wrong way
<Daemon404>
it digs teh hole deeper.
<beastd>
Daemon404: I don't agree. Especially for this case. All tradeoffs need to be considered
<Daemon404>
adding more test infra to work around broken test/infra.
<Daemon404>
the entirely fundemental thing being tested here is incorrect
<beastd>
That's inaccurate description AFAIU
<Daemon404>
i would love to know what value is gained from testing hash and size of packets of en encoder that sues zlib
<JEEB>
and you add to that "give that we check that the decoded result still matches"
<JEEB>
*given
<Daemon404>
yes
<beastd>
Daemon404: We test that the packet is there and has the right content? Or what do you mean?
<JEEB>
beastd: think of the various tests where we test an encoder + the result of decoding that encoded result
<Daemon404>
beastd, we're testing the exact size and hash of its contents
<Daemon404>
we do not gain anything of value from this
<Daemon404>
"encoder outputs exact same bits" isn't useful to test
<Daemon404>
what we care about is the decoded output.
<Daemon404>
and that it is a valid bitstream
<Daemon404>
the bit-exact contents are irrelevant
<beastd>
Daemon404: I partially agree, but often it is important that it produces the same byte sequence
<Daemon404>
in this case, it is not.
<Daemon404>
at all.
<beastd>
If you change sth and you see tests blow up, you need to check why and if it is expected
<Daemon404>
that's what a test is
<beastd>
That's a useful trait of a good regressions test suite
<Daemon404>
if it blows up for the wrong reason, the test is bad.
<Daemon404>
it's an anti-test.
<Daemon404>
it ensures you can't change things for no reason;
<Daemon404>
"everythign stays exactly the same forever" is an anti-pattern in tests
<beastd>
i didn't say that at all
<jamrial>
<Daemon404> i'd consider it an anti-test to test that <- for external deps, sure
<beastd>
I sure agree, but if there is nothing I'm missing (and there well might be) than it didn't blow up for the wrong reason but for a reason of a bug in a dep
<jamrial>
as is the case of zlib
<Daemon404>
jamrial, i dont agree still
<Daemon404>
for a lossless encoder, for which we can e.g. improve compression
<Daemon404>
testing the exact hash/data makes no sense.
<Daemon404>
even internal.
<Daemon404>
it brings no value other than "yep data changed"
<jamrial>
yeah, and in that case the ref is updated
<Daemon404>
sure you can but the test itself is providing no value there
<Daemon404>
you gain no useful info by having it
<jamrial>
it can catch unintended changes to the encoded output that don't affect the decoded output
<jamrial>
like, compression got worse
<Daemon404>
a better test for that would not be equality
<Daemon404>
but size >=
<Daemon404>
hash comparison is needlessly rigid
<beastd>
Sure but you also need to cater for unintended changes
<Daemon404>
that's what the encoder and metadata tests (and parsing) should really be for
<Daemon404>
not a dumb hash comparison.
<Daemon404>
how do you think lossy works?
<beastd>
Daemon404: Not sure why you are attacking me so strongly. I didn't say our current solution is the best solution for everything. It still has many good properties and we have it right now.
<Daemon404>
ive not attacked you
<Daemon404>
i've only rebuted your arguments
<Daemon404>
nothing personal.
<Daemon404>
accusing me of a personal attack is unhelpful. if i have anywhere, i apolgoize.
<beastd>
Just saying we need to do sth completely different has unknown pros and cons so I can't really judge the outcome and amount of work needed
<jamrial>
anyway, found a solution. most helpers have the no_file_checksums option for this exact scenario
<jamrial>
so we just need to use it
<Daemon404>
i said exactly what needs to be done?
<Daemon404>
i dunno man, ive def been guilty of being personal before, but not this time
<Daemon404>
it's a technical discussion
<Daemon404>
jamrial, that sounds perfect
<beastd>
Daemon404: well, maybe I have just taken it the wrong way.
<jamrial>
those need to stop printing pos and size
<Daemon404>
are the seek tests those .c files, iirc?
<Daemon404>
weird we'd be running those the same on FATE files and test-produced files
<Daemon404>
since the usecase is a little diff
<Daemon404>
also totally unrelated, but the ML has been weird for me lately... emails from some people like beastd or Lynne don't come as their names/emails
<Lynne>
that's what happens if the ML can't manipulate your emails
<Daemon404>
is this a DKIM thing
<Lynne>
I've disabled every modern protection
<Lynne>
but it still does
bilboed has joined #ffmpeg-devel
<Daemon404>
weird
<Lynne>
so who knows
<Daemon404>
it's a bit of a pain because i can't even see who the author is
<Lynne>
it is
<Lynne>
I get that too
<beastd>
Daemon404: Actually I think I mostly agree with most of your points. Only the not needing to update ref files strikes me as a bit risky because it can hide unintended changes. Could be secured otherwise but I would think overall it's a lot of work ot get there. But it might be worth it.
<Lynne>
we should switch to forgejo already
<Daemon404>
beastd, it's def some work, but i don't think it's totally massive
<beastd>
yeah, that mailing list stuff since this new security measures for mail transport are in place are really annoying.
<Daemon404>
was this a change on the list end or the sender end?
<Daemon404>
either way, i prefer the bikeshed green
<llyyr>
what's the status on the forgejo stuff? are we at the "do we even want this" or "how do we do this" phase
<beastd>
AFAIK for the mailing list being able to send stuff through it won't go through all stmps servers. So on the server side the mailing list proactively rewrites some headers
<Daemon404>
llyyr, i mix between not everyone agreeing to move of the ML, and then not agreeing on what to move to
<Daemon404>
what colour bikeshed do you like?
<Daemon404>
beastd, i see... fun... i would have hoped it is smart enough to keep the sender name
<Daemon404>
seems not
<beastd>
llyyr: Not sure overall. I think forgejo kind of looks best right now but I didn't really use it much and don't know much of the internals. I have a gogs (was forked as gitea and than as forgejo) running for many years tho, but gogs does not have enough features for our use case.
<JEEB>
some people ( BtbN ?) noted that they'd be OK with doing the management of a gitlab instance as long as the infra was provided
<llyyr>
why not use videolan's infra or is that not an option?
<BtbN>
I'd also prefer Videolans Infra
<JEEB>
yea
<BtbN>
Cause Gitlab is rather hungry
<llyyr>
though gitlab is kind of slow but it's still better than ML
<BtbN>
But most of that is static hunger, not per-user
<beastd>
I would still keep mailing lists but handling patches and tickets on some forge software like forgejo or gitlab looks preferable to me
<JEEB>
some people want to have their own, and thus there was the alternative of first having own instance and then when people find out how much crap having their own is - move to videolan or so :P
<JEEB>
but anyways at this point someone should just list the alternatives on ML, and then a voting process or whatever could take place
<BtbN>
Running Gitlab and having adequate backups isn't cheap
<JEEB>
yea
<JEEB>
gitlab@videolan, gitlab@own (which infra?), forgejo (infra & managed by whom?), github (lol, but technically an alternative)
<BtbN>
There is now a multitutde of Gitlab-Alternatives
<BtbN>
But Gitlab is the only one I trust not to just vanish or suffer some other annoying fate in a couple years
<beastd>
i guess if we would prefer forgejo we could also consider using codeberg
<BtbN>
I honestly wouldn't mind Github being the primary repo. I like their interface by far the best
<BtbN>
Gitlab is super confusing to find simple things at times
<llyyr>
I don't think codeberg is a good idea, it's down quite often in my experience
<llyyr>
it just uses forgejo though, so one could use it to see if they like forgejo
<BtbN>
The advantage of Github is, it also gives you CI for free
<BtbN>
Hosting useful CI outselves is going to be insanely expensive as well
<BtbN>
Videolan also already did that work and expense
<JEEB>
yea
<JEEB>
which is why in theory my personal top alternative would be getting to a sharing agreement with videolan's existing infra.
<BtbN>
Videolan has invited us multiple times at this point
<JEEB>
yes
<BtbN>
imo anything but using their Gitlab or Github is a bit insane
<BtbN>
we struggle to keep trac running, Gitlab is in the long run only going to be worse and expensive
<JEEB>
yes, better to provide resources for existing infra where there are maintainers already than trying to duplicate that work
<Lynne>
I've volunteered to maintain a forgejo instance
<Lynne>
I dislike working with gitlab *that* much
<Lynne>
I shouldn't need to wait for 30 seconds for 100 megabytes of js frameworks to load to display diffs
<JEEB>
ok, so then it's the same as with gitlab. someone could do the maintenance, it would just be a question of infra (main host & CI runners)
<Lynne>
we have a server
<JEEB>
but yea, as I noted the main thing would be just to lay these alternatives down
<JEEB>
on the ML
<JEEB>
list them and then have a decision be made
<BtbN>
The server we have is simply not adequeate for the scale that's needed
IndecisiveTurtle has quit [Ping timeout: 260 seconds]
<BtbN>
And I'm very much not a fan of Forgejo, would much rather have Gitlab
<another|>
has anyone looked at sourcehut ?
<BtbN>
Like I said, the more exotic it gets, the more I'm strictly against it
<Lynne>
sourcehut is dead
<Lynne>
gitlab sucks
<Lynne>
everything sucks
<BtbN>
I don't see the big issue with gitlab
<BtbN>
their UI is weirdly sorted, but that's a matter of getting used to it
<JEEB>
and the cli tools apparently were the least bad out of the alternatives?
Krowl has quit [Read error: Connection reset by peer]
<Lynne>
no, they were inadequate
<Lynne>
you couldn't do reviews
<BtbN>
If you want CLI tools, there is not much else but Github
IndecisiveTurtle has joined #ffmpeg-devel
<BtbN>
Though I don't see the big need for them. Never once used any cli tools beyond just git
<Lynne>
forgejo has some that allow for review when I looked at it
<Lynne>
gitlab is simply too slow
<Lynne>
that's my main issue
<JEEB>
I think the cli tools were checked at VDD'23 and FOSDEM'24?
<Lynne>
nope, 2021
<Lynne>
years ago
<JEEB>
I am pretty sure someone checked them when I was around, and I think I wasn't in 2021
<JEEB>
jdek I think did
<another|>
... and thus the bikeshedding continues...
<llyyr>
all the bikeshed colors than the current
<jdek>
We checked, they kinda sucked. Chicken and egg problem I think
<llyyr>
are better*
<JEEB>
more like I'm trying to comment that someone "just" needs to do the listing and post it on the ML to get a decision rolling :P
<BtbN>
It's simply not a good idea to pick something super exotic that's hip today, and then dies in a year or two
<BtbN>
Gitlab is by far the least likely for that to happen
em___ has joined #ffmpeg-devel
IndecisiveTurtle has quit [Ping timeout: 265 seconds]
<llyyr>
github seems like the best option based on the requirements listed so far
<BtbN>
Yeah, but some people get an instant aneurism when they hear Microsoft
<Daemon404>
i dont think most here will go for anything controlled by a corproation
<Lynne>
forgejo has been around as gittea for over 10 years now
<Lynne>
its not going to disappear overnight, not least because it backs a large github competitor (codeberg)
<Lynne>
and its the only truly free option, since it has no free/premium version, you get all features upfront
<BtbN>
Well, Gitea went away over night due to a dispute in the community, cause the main developer wanted to make a living
<BtbN>
So that makes any of those forks not viable imo
<Daemon404>
i am prett sure no matter which option is chosen (including staying on ML), multiple people will be unhappy
<Daemon404>
such is lfie
<Daemon404>
life even
<BtbN>
And the main problem also remains, running the infra for something like that is expensive and a lot of work, specially if we want CI
<BtbN>
The only long-term viable options we really have is to collaborate with Videolan, i.e. use their gitlab and help with infra/admin, or use Github
<Daemon404>
this discussion could have been copypasted from any point in the last 5 years :D
<another|>
(I should open a bikeshed colouring shop... Hm....)
<Daemon404>
another|, green please
<BtbN>
Well, something will need to happen at some point in the mid-future
<BtbN>
Cause mailman2 is aging as well, and there is no easy migration to mailman3 apparently
<Daemon404>
i think it will end in a vote, but hisotrically the vote has been avoided
<another|>
Daemon404: Sure thing. 3.50€ please
<Daemon404>
in favour of concensus
<Daemon404>
im not sure how viable that is.
<Daemon404>
another|, didnt know you were scottish
<another|>
has anyone looked at winehq's migration from ML to gitlab as a case study?
<Daemon404>
vlc did it too.
<Daemon404>
and i assume wbs experienced the winehq move first-hand
<Lynne>
BtbN: main developer sold out the community
<Lynne>
you can say he wanted to make a living, but he sold it all out to a company
<Lynne>
all developers left and forked it to forgejo
<Lynne>
its like the freenode->libera situation
<Lynne>
and I don't get your concerns about CI
lexano has quit [Ping timeout: 246 seconds]
<Lynne>
the way that mesa handles it is like we handle FATE - everyone can ask for their runner to be integrated
<Lynne>
if there's an issue with it, its just removed from testing
<Lynne>
the server doesn't handle CI, it only handles hosting
<Lynne>
neither github nor videolan's gitlab have anywhere near the hardware that we currently test with FATE, so doing the CI indepdently is the only way to go
em___ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
em___ has joined #ffmpeg-devel
<JEEB>
I mean, I don't think anyone said the CI runners would be the same server.
<JEEB>
you *want* to have them split in any case
<JEEB>
the FATE-things would follow master, while CI runners would be doing MRs as well
<Lynne>
then the question about our current server being weak goes away, since you can run a forgejo/gittea instance on a raspberry pi
em___ has quit [Client Quit]
<JEEB>
you still need to host the actual CI runners doing MRs etc
<Lynne>
in mesa's case, that's handled independently
<Lynne>
users just ask for their instance to be used
<another|>
mesa is on fd.o gitlab, isn't it?
<llyyr>
speaking of wine-hq, their gitlab instance has none of the slowness I associate with fd.o or videolan's gitlab instance
<Lynne>
yes
<JEEB>
and in case of videolan there are CI runners and we could have our own sponsored ones. anyways, it'd all depend on whatever agreement we would get with videolan regarding the usage of the stuff
<JEEB>
but at this point nothing would move on unless someone lists the alternatives and has a week or two-week period for people to propose their own options if they are not listed.
<wbs>
llyyr: wine-hq's gitlab was quite recently beefed up
ccawley2011 has joined #ffmpeg-devel
<wbs>
regarding FATE and CI, I see precommit CI (with mandatory checks on a selection of important configs) and fate.ffmpeg.org with postcommit catch-up testing on various exotic setups (where people volunteer their HW and decide themselves how often it is run)
<JEEB>
yea
<wbs>
I'm not volunteering my HW for any precommit CI, but I can keep running things the way I do it right now
<JEEB>
yup, that's why I brought that whole thing with separation of MRs and master
lexano has joined #ffmpeg-devel
em___ has joined #ffmpeg-devel
em___ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<kurosu>
if x265 is going to fix so quickly their bugs, I imagine it won't hurt that just one version isn't compatible, and customers can be easily informed to wait out a 7.x ?
<kurosu>
also heh @ pvmaf @ quortex - strange that Jan presented that then
System_Error has quit [Remote host closed the connection]
em___ has joined #ffmpeg-devel
em___ has quit [Client Quit]
em___ has joined #ffmpeg-devel
ngaullier has quit [Read error: Connection reset by peer]
<ePirat>
another|, I looked at sourcehut, seems to be a bit of mess tbh
em___ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
em___ has joined #ffmpeg-devel
em___ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Daemon404>
kurosu, why strange
<Daemon404>
because he works for synamedia?
System_Error has joined #ffmpeg-devel
<kurosu>
Rather unexpected rather. Quortex is now a subsidiary, but it's afaik only located in France, while he and probably the related team is in Belgium (but yes, Synamedia)
<another|>
ePirat: okay
<BtbN>
You can't easily have community provided CI runners, since they for one run arbitrary code, and then also need to be set up in a very specific way to ensure reprodueable CI accross all of them
<elenril>
>17:11:45 llyyr | what's the status on the forgejo stuff?
<elenril>
as I see it, the main blocker is nobody willing to invest actual effort into this
<ePirat>
what is someone supposed to do?
<ePirat>
without any decision it could all be wasted time
<elenril>
decisions don't happen on their own
<elenril>
any effort could be wasted time
<ePirat>
right but again what is a single person supposed to do?
<llyyr>
well there were two people in this chat willing to manage gitlab/forgejo respectively
<ePirat>
buy a server on their own, set up an instance?
<elenril>
ePirat: could start by making the decision happen
<elenril>
i.e. organize a discussion, voting, etc.
<elenril>
research the options, their pros and cons, ...
<llyyr>
I thought ffmpeg went through all that around vdd but without the voting part
<elenril>
my point is, the above discussion happened multiple times already and does not lead to anything
<elenril>
if someone wants things to actually happen, they need to put effort into it
<BtbN>
Cause no decision was made
<elenril>
and yes, that effort may end up wasted
<elenril>
which is probably why noone wants to do it
<BtbN>
It also involved actual money to rent server capacity
<BtbN>
so it's not like you can just do it
<ePirat>
yeah thats my point ^
<ePirat>
no one can "just do it"
<BtbN>
Also, for some perspective: Our trac instance is an 8-core server. And the CPU is so busy that logging in via ssh takes a hot minute
<llyyr>
could someone just send a mail to the ML listing all the options and their pros and cons and just ask for voting on that?
<BtbN>
Wait nono, not trac. I mean our gitweb
<elenril>
how is that possible
<BtbN>
So no, not "any rpi" could host our Gitlab/Gitea/Whatever
<elenril>
do we even have that much traffic?
<ePirat>
BtbN, why is the server so busy
<BtbN>
Cause every access interacts with git, and does multiple git calls in the background
<BtbN>
so it's a lot of IO, and a lot of cpu intensive git stuff
<BtbN>
And it's actually quite busy indeed
<ePirat>
it doesnt cache anything in ram?
<BtbN>
I don't think gitweb does, no
<elenril>
llyyr: "just"
<elenril>
I think it's far from a trivial task
<Daemon404>
technically moving to videolan's gitlab is low effort =p
* Daemon404
runs
<ePirat>
I can give my opinion about pros/cons regarding gitlab and forgejo at least (if anyone cares) having used and set up both
<elenril>
Daemon404: now port the development process
<Daemon404>
you dont port anything, it'd be new
<elenril>
we need to have one
<elenril>
it has to come from somewhere
<elenril>
it has to be approved by existing developers
<Daemon404>
i think a real risk is front-loading EVERYTHING
<Daemon404>
so nothing ever happens
<Daemon404>
nothing is perfect day 1
<BtbN>
It would always be a gradual shift, not a hard migration
<BtbN>
nothing prevents ML and any kind of Github-Alike from coexisting for however long it's needed
<elenril>
at the very least someone needs to propose how will it actually happen
<elenril>
and supervise the migration
<Daemon404>
well right now we cant even agree on which to use
<elenril>
bitbucket, duh
<BtbN>
What is there to supervise? Declade new repo the "main repo", and say MRs are accepted.
<BtbN>
The rest has to happen organically on its own
<Daemon404>
i really thing nothing can be done until an option is chosen
<Daemon404>
think, even
<ePirat>
if you dont care about trac for now, migration is trivial-ish
<elenril>
Daemon404: write a proposal then
<elenril>
organize the vote
<elenril>
I did organize votes on some controversial things in the past year
<elenril>
it's a fun experience
<Daemon404>
happy to organize a vote, but last vdd we couldnt even agree on if a vote was the right thign to do :P
<elenril>
conveniently, there's a vdd happening soonish
<Daemon404>
indeed
<elenril>
we could also have a civil and respectful ML thread on whether we want to vote on it
<BtbN>
Since there is no single person who CAN just decide something like this, what else but a vote is there?
<Daemon404>
gitlab discussions are the new fork discussions
<Daemon404>
amirite
* Daemon404
runs
<Daemon404>
BtbN, concensus
<Daemon404>
if you believe in fairy tales
<elenril>
also there's a lot of freedom in what exactly the vote looks like
<elenril>
like if there's a 51% majority for github, but 30% of people ragequit, do we really want that outcome
<llyyr>
well first you need a vote on whether ffmpeg actually even wants to allow contributors who aren't familiar with mailing lists/emails or just don't want to deal with it to send and get their patches merged
<llyyr>
even simply just saying ffmpeg will accept and review patches on the github repo will be sufficient for that, no need to change anything else
<elenril>
ffmpeg does not review patches
<elenril>
people review patches
<Daemon404>
a move to gitwhatever doesnt entail lowering standards
<Daemon404>
or even allowing drive-bys
<elenril>
you cannot force people to review github patches unless they want to
<elenril>
or you switch entirely to github
<ePirat>
IMHo if anything, having proper pre-commit CI will improve standards…
<Daemon404>
i dont think a single person proposed github
<elenril>
llyyr just did
<llyyr>
people did in the discussion earlier as well
<elenril>
I think some others did as well
<llyyr>
github was just an example, replace it with your preferred bikeshed
<Daemon404>
if i manage to recover sufficiently by vdd (and if i dont, please just kill me), i will have a small presentation maybe
<elenril>
just eat enough kimchi and you'll be fine
<Daemon404>
considering what i have/had is a severe multi-week campylobacter infection
<Daemon404>
prob not
<Daemon404>
i even had to ace my SF trip
<Daemon404>
(just finished muh antibiotics)
<llyyr>
Daemon404: It doesn't need to entail lowering standards, it just needs to be more accessible. I don't think knowing how to find lost patches on the ML or knowing how to reply to an email you can see on ffmpeg-devel archive but is not in your inbox anymore have anything in common with good development
<Daemon404>
llyyr, sure
<Daemon404>
i only wanted to point out that we can maintain "users required to register" on pretty much any optino
vipyne has joined #ffmpeg-devel
vipyne_ has joined #ffmpeg-devel
vipyne_ has quit [Read error: Connection reset by peer]
vipyne has quit [Read error: Connection reset by peer]
Krowl has joined #ffmpeg-devel
em___ has joined #ffmpeg-devel
vipyne has joined #ffmpeg-devel
IndecisiveTurtle has joined #ffmpeg-devel
vipyne_ has joined #ffmpeg-devel
IndecisiveTurtle has quit [Ping timeout: 244 seconds]
<Marth64>
its like quitting cigarettes...you cant just do it but you have to do it
<Marth64>
ML gets confusing
<Marth64>
imo
<Marth64>
pick software, get server, get licenses if needed, do ETL
<Marth64>
</ramble>
<Marth64>
need good project manager
em___ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
IndecisiveTurtle has joined #ffmpeg-devel
<Marth64>
it is not that bad and you could do it in phases
em___ has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
em___ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
lexano has quit [Ping timeout: 276 seconds]
Kei_N has quit [Read error: Connection reset by peer]
Kei_N has joined #ffmpeg-devel
lexano has joined #ffmpeg-devel
vipyne has quit [Quit: Leaving.]
vipyne has joined #ffmpeg-devel
vipyne has quit [Client Quit]
vipyne_ has quit [Ping timeout: 264 seconds]
Marth64 has quit [Quit: Leaving]
em___ has joined #ffmpeg-devel
em___ has quit [Client Quit]
em___ has joined #ffmpeg-devel
___nick___ has quit [Ping timeout: 252 seconds]
Krowl has joined #ffmpeg-devel
b50d has joined #ffmpeg-devel
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
b50d has quit [Remote host closed the connection]
System_Error has quit [Remote host closed the connection]
Krowl has quit [Read error: Connection reset by peer]
System_Error has joined #ffmpeg-devel
vipyne has joined #ffmpeg-devel
vipyne_ has joined #ffmpeg-devel
vipyne has quit [Quit: Leaving.]
vipyne_ has quit [Ping timeout: 252 seconds]
ccawley2011 has quit [Read error: Connection reset by peer]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
<Lynne>
BtbN: my point is that its really *not* that busy and definitely something we can run
<BtbN>
Looking at gitweb, it's quite busy.
<Lynne>
its still really not a problem
<Lynne>
its not like it runs an elasticsearch/meilisearch instance in the background
<BtbN>
Not sure what you base that on
<BtbN>
I'm looking at the actual server, and it's rather busy
vipyne has joined #ffmpeg-devel
vipyne_ has joined #ffmpeg-devel
<Lynne>
I've ran stuff like that for 5 years now
<Lynne>
its really not a lot to run forgejo/gittea, it isn't gitlab with 30 megabytes of js per page
em___ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<BtbN>
Whatever that got to do with server load
<BtbN>
And I can assure you, _anything_ will struggle if enough people use it
<BtbN>
ffmpeg git is apparently looked at by a surprising amount of people
<BtbN>
So no, some random Raspberry Pi will not manage to host ffmpeg git
<BtbN>
keeping in mind that a lot of load will be hitting videolan git and the github mirror instead.
<BtbN>
Which might shift if we set up our own main solution