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.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
kurosu has quit [Quit: Connection closed for inactivity]
<Yalda>
there are some changes I need to upstream to libdvdnav and libbluray later to unlock some performance gain (DVD chapters), CLPI metadata (bluray)
<Yalda>
and we need finally a way to list titles
<Yalda>
but these are 8.1 goals
<Yalda>
interactive menu support for these is still theoretical... need a way to gracefully tell playing application how to reconfigure streams. I believe elenril(?) suggested long time ago one option is simply stop streams and add new ones.
<Yalda>
anyways, good night for now
GewoonLeon has quit [Ping timeout: 276 seconds]
Teukka has quit [Read error: Connection reset by peer]
<frankplow>
If a video is to be played on a variety of displays, some of which support wide gamuts and some of which don’t, is there any advantage to mastering in a lowest common denominator gamut like srgb?
<frankplow>
I.e. how bad is an average display/player at narrowing colours?
<frankplow>
Sorry if the question is poorly worded, this is far out of my expertise
<BtbN>
on consomer hardware color is pretty much random I feel like
<BtbN>
*consumer
<nevcairiel>
Its certainly one strategy and depends how bad your player is, unfortunately most consumet players are likely going to be crap
<kasper93>
majority of players will just clip the gamut
<nevcairiel>
If even that, i would think many will just ignore it
<kasper93>
and even more advanced players will look differently between each other, depending on gamut mapping method used. no easy solution
<kasper93>
> That's quite some attitude and wants me to look for alternatives for the whole tool.
<kasper93>
I had the same initial feeling
<kasper93>
maybe we should follow michael suggestion and NIH those checks
minimal has joined #ffmpeg-devel
<kasper93>
we may lose, some more "advanced" ones, but maybe they are not that important.
<wbs>
kasper93: btw, re forgejo - for me, it's not so much about making it easier for newcomers to contribute, but to make my life easier in reviewing a patch. for a fresh initial submission, ML may be easier, but anywhere after that, a forge makes it just so much easier to keep track of earlier review comments and whatnot
<wbs>
(plus I've had to deal with reviews with people who flat out were unable to respond to my inline comments in mail; that made the review discussion very painful)
<BtbN>
Forgejo fires a webhook whenever a job is started, and a script then checks how many jobs are already waiting, and if it's too many, fires a "CI" run on that repo :D
<wbs>
BtbN: ooh, that's awesome. so we can leverage github's windows/macos runners for our CI this way too? :-)
<BtbN>
In theory yes, but need to get the go-written runner to run there first
<BtbN>
Given it heavily hinges on docker, I'm not sure it can handle anything but Linux at the moment
<wbs>
right
<BtbN>
well, docker or lxc, but lxc is even less Windows-Friendly :D
<BtbN>
It might be able to run on a windows-runner inside of WSL, which would mean it can execute windows binaries natively
realies934 has joined #ffmpeg-devel
realies934 has quit [Read error: Connection reset by peer]
<wbs>
but neat anyway; github offers soo much free capacity
<kasper93>
nevcairiel: you might want to migrate your fate runners to git.ffmpeg.org, v.d.o seems to be in limbo
<BtbN>
I hope it's not against their TOS or something
<BtbN>
kasper93: all videolan admins seem to have vanished
<BtbN>
thresh is absent since almost a week now, and I have no idea who else there is to contact who could fix this
realies934 has joined #ffmpeg-devel
ShadowJK has quit [Ping timeout: 252 seconds]
<BtbN>
like, it shouldn't be complicated to just disconnect the hooks from the ffmpeg repo
<kasper93>
wbs: that's certainly is the main point to better track patches and reviews. But having more contributors in OSS is not bad, especially if patches now (hopefully) will be harder to lose
<kasper93>
(I just don't like people saying, "we should only allow patches from true hackers, that use email only and no javascript")
<kasper93>
sorry
<BtbN>
Yeah, that level of blatant elitism and intentional gatekeeping is ridiculous
<BtbN>
I have stopped taking Nicolas for full these last couple days. The mails read like an absolute mental breakdown to me
<Yalda>
he lost me at "[someone can sign up but not have read the guidelines]"
<BtbN>
It's like full on delusional talk there
<BtbN>
Ironically, we _could_ make a quiz before signing up. We already have one, though it only asks about birds.
<Yalda>
i am just so happy forgejo exists, a whole class of nuanced rules like "no top posting" and mail headaches disappear for actual work
<Yalda>
thank you for all the efforts BtbN and others who assisted
<BtbN>
The main "issue" that remains is figuring out how to pay for hosting
<BtbN>
cause so far I'm just flat out paying for it myself, and plan to like every half year post a bill for review to SPI
Sean_McG has joined #ffmpeg-devel
GewoonLeon has joined #ffmpeg-devel
<beastd>
wbs: sure. using a forge can help maintainers as well. and especially when interacting with new contributors unfamiliar with emails and the parts of git tooling needed to serve our current processes.
<beastd>
nothing has only upsides. i think we are heading in the right direction and when we eventually implement it right it will help contributors and maintainers.
<beastd>
i also find it nice to have that one place i can visit on the web to see what was the latest state of things with a particular issue or contribution was.
<beastd>
tho the tools are still partially clumsy, it's just more comfortable and easier than scanning big patch set discussions in mails.
realies934 has quit [Quit: Ping timeout (120 seconds)]
realies934 has joined #ffmpeg-devel
GewoonLeon has joined #ffmpeg-devel
<wbs>
regarding CI, it's also possible to have some jobs conditionally trigger on some files; e.g. if touching lib*/aarch64, it can be relevant to try building with msvc-arm64, which we probably don't want to build with otherwise
<jamrial>
but it can get annoying if you need to rebase with no real changes
<kasper93>
yeah, might get annoying long term
<kasper93>
I wish it didn't do that if there is not real change, but it did here
<beastd>
kasper93, jamrial: i think dismiss approval is better tho. otherwise it's to easy for things to slip thru.
<jamrial>
yes
<kasper93>
yes, agree
<beastd>
agree it can be annoying at times. but better safe than sorry
<kasper93>
signature situation gets more complicated, because before you could 1. get approved 2. push rebase with signed commits 3. merge
<beastd>
but that would leave opening for someone to approve sth he didn't fully review, no?
<beastd>
what is also not so easy to see and check (that's for email and local git as well) is if commit messages were changed. guess this is because for git those are entirely new commit objects and thus there is no tooling to match and diff them.