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
jdek has quit [Ping timeout: 265 seconds]
jdek has joined #ffmpeg-devel
mkver has quit [Ping timeout: 248 seconds]
abdu has quit [Quit: Client closed]
thilo has quit [Ping timeout: 252 seconds]
thilo has joined #ffmpeg-devel
<fflogger>
[editedticket] MasterQuestionable: Ticket #11566 ([ffmpeg] Arabic subtitles rendering artifact for lacking font support) updated https://trac.ffmpeg.org/ticket/11566#comment:2
<Lynne>
BtbN: when do we take the forgejo instance for a test drive with development?
<BtbN>
Not my decision really
<BtbN>
it's as ready as can be from a hosting pov
sebas_ has quit [Quit: Konversation terminated!]
microchip_ has quit [Quit: There is no spoon!]
microchip_ has joined #ffmpeg-devel
<Lynne>
as far as I can recall, there was a consensus to run both in parallel for a few months
<BtbN>
Well, as far as I'm concerned, I'd be happy to make it the main repo over g.v.o, which is struggling hard anyway
<wbs>
Lynne: I don't think I've seen any such consensus about running multiple repos in parallel
<BtbN>
not repos, it + ML
<wbs>
yeah, well that
<Lynne>
that's what michaelni agreed a few months ago to, and a few others chimed in they'd be happy with that
<wbs>
how'd that work - pushes to forgejo being immediately forwarded to the other one, and vice versa? or only reviewing in forgejo and pushing to the preexisting main repo?
<wbs>
oh, ok, I may have forgotten about that then
<BtbN>
There is no good way to have two main repos
<wbs>
in any case - I'm totally in favour of getting away from the ML based workflow
<wbs>
BtbN: yeah exactly
<BtbN>
The forgejo repo can be set up to forward pushes elsewhere, so the g.v.o repo would be made read-only except for forgejo, and everyone would need to push there
<BtbN>
not sure if there is such a thing as "forwarding" in gitolite
<wbs>
I presume there are some sort of regular git repo hooks there
<BtbN>
Well, the git repo hooks all call forgejo binaries
<BtbN>
and then you configure stuff in Forgejo
<wbs>
I mean on the existing videolan gitolite side
<michaelni>
I see no problem with running forgejo and ML in parallel
<michaelni>
git merge makes that easy
<BtbN>
Well, the repos would all need to redirect still
<BtbN>
having more than exactly one source of truth is needless trouble
<michaelni>
also main repository should be on ffmpeg infra
<BBB>
BtbN: I'm guessing he would first need to identify which file is to be uploaded :)
<michaelni>
BtbN, is what you suggested that forgejo would be the main repo and everyone currently pushing to g.v.o (reviewed on ML) could push to that directly ?
<michaelni>
i need to think about this, and have to leave ATM but i think we should long term consider moving to a model similar to linux with merges as its more scalable and gives people their own repository to work with less friction
<BtbN>
michaelni: people would keep pushing to g.v.o as they are right now, which also keeps auth working as it is. But gitolite there is then set up to redirect the push, at the ssh level, to Forgejo, via some deploy key
<BtbN>
that's the least dirsuptive way of migration
<BtbN>
code.ffmpeg.org would then become the main repo
<michaelni>
I think we should consider fliping source.ffmpeg.org and g.v.o so that g.v.o becomes a pure mirror but maybe theres a reason against that. As is our setup is a bit strange
<BtbN>
well, right now everyone has to push to g.v.o, so just changing where to push to like that will be incredibly disruptive
<michaelni>
what i meant is source.ffmpeg.org would be made to point to where git.ffmpeg.org points now and g.v.o would become a mirror, so the few people hardcoding g.v.o can continue reading from it while people pushing need to update their ssh host fingerprint
<michaelni>
it would increase reliability IIUC
<BtbN>
pushing to g.v.o is the standard though
<BtbN>
so it's not "the few people", it's almost everyone
<michaelni>
i have url = git@source.ffmpeg.org:ffmpeg and thats what doc/git-howto.texi lists too
<BtbN>
When I tried that, it plain didn't work, so g.v.o it is
<BtbN>
And if we want to switch to Forgejo in the near future anyway, I see zero point in doing two disruptive changes in quick succession
<jamrial>
i have pushURL = git@source.ffmpeg.org:ffmpeg.git
<BtbN>
videolan gitolite can just be set up to redirect pushes elsewhere
<michaelni>
then it can be set to redirect to git@source.ffmpeg.org:ffmpeg
<jamrial>
in any case, the forgejo workflow would be to push to your personal repo and then opening an MR
<BtbN>
Or opening the PR via the AGit flow, if you prefer
<jamrial>
so no pushing to the main repo anymore
<BtbN>
that works without a fork
<BtbN>
For the time being, pushes to master would be allowed
<BtbN>
mandating PRs-Only is a thing to discuss for the future
<BtbN>
If pushes to master would be blocked, co-existence with the ML would not work
<michaelni>
"so no pushing to the main repo anymore" i think thats a step in the wrong direction, its more centralization
<BtbN>
what?
<BtbN>
Nothing about that changes. It's centralized either way
<another|>
wat?
<BtbN>
There can only be exactly one source of truth for the repo
<BtbN>
everything else is just a mirror
<BtbN>
The question of blocking pushes to master is just a question of workflow
<BtbN>
As it enforces PRs for everything
<jamrial>
yeah, that comes later, when we fully migrate to it and the ML is used only for discussion
<michaelni>
About centralization, if everyone can push its decentralized, if everyone gets merged when they say they want the code that they maintain to be merged its decentralized. If everyone NEEDS to send a PR that can be rejected even for code they maintain its centralized
<BtbN>
that makes no sense oO
<BtbN>
It's always the same server, and always the same people who decide what code goes in
<BtbN>
you can insta-merge your own PRs if you like
<BtbN>
Enforcing Multi-Person review is a whole other discussion on top of that
<BtbN>
Enforcing PRs allows enforcing passing CI checks though
<BtbN>
Which prevents accidentally pushing completely broken code. At least for the parts CI covers
<jamrial>
michaelni: the way it will works is that there's will be a given group of accounts who have MR merging rights (the same way people now have push access)
<jamrial>
if approval by x amount of devs is not forced, any of them can merge any MR, be it theirs or by someone else
<michaelni>
"<BtbN> Enforcing Multi-Person review is a whole other discussion on top of that", yes but a discussion the individual doesnt have to agree to to be affected by it. ATM a maintainer could have his own repository, his own setup his own team and submit pull requests
<michaelni>
the direction this goes in is giving more power to a central group, iam just concerned about that
<BtbN>
It's the exact same group as now?
<BtbN>
I really don't follow
<BtbN>
People who can push now can merge MRs then, if we actually were to implement such a workflow
<BtbN>
For the time being nothing would be mandatory anyway, and everything possible
<jamrial>
michaelni: anyone currently with push access could be added to the user group with MR merging rights. it doesn't need to be smaller
<BtbN>
it'd be silly to make it smaller anyway. We just add everyone as FFmpeg Org Member, and they gain push and MR merge access
abdu has quit [Ping timeout: 240 seconds]
<michaelni>
I think i need to think about this and sleep over it but what i envissiioned was more that people would move toward each having their own repo, one could use forgejo one gitlab, and they would each use the review workflow that they like. One could be a libavfilter repo under pauls control for example and these would all get merged (somewhat like in linux)
<michaelni>
anyway, ill try to get some fresh air, i need to think about this :)
<BtbN>
You can still do that, and then send a PR?
<BtbN>
Nobody can stop anyone from hosting a completely independent repo elsewhere
<BtbN>
Just if you want to merge code into the main repo, you need to have push access, just as it is now
<BtbN>
I really don't see _anything_ that changes in that regard
<jamrial>
exactly. this is about the main repository, not people's personal hosting solutions
<michaelni>
requiring review to happen in the "central repository" and not in the "independent repo elsewhere" would change it, maybe other things too
<BtbN>
Not sure what you mean. Right now review is required to happen on the ML
<BtbN>
It'd just add a second official option for reviews
<BtbN>
You're saying that right now there are external repos somewhere, and stuff developed there can go into master without any further review?
DVedaa has joined #ffmpeg-devel
<michaelni>
threres alot of patches that are applied with just the author reviewing on his local machien, and also patches being reviewied by people having no special access. for example loongson author and a seperate reviewer just posted that to the ML and i applied
<jamrial>
and you think that couldn't be done anymore?
<BtbN>
Literally nothing about that would change
<michaelni>
of course it could be done, maybe my concern is unfounded
<BtbN>
Extra effort would need to be taken to prevent it even
<BtbN>
Even if we were to some day enforce PRs for everything, they still could be reviewed by a random third party, and you or anyone else with push access could then pull the trigger to merge
<BtbN>
And you can actually send PRs to Forgejo without having a fork on Forgejo itself, via AGit
<BtbN>
so in theory you can have a Gitlab somewhere, and then send a PR for a branch there
<BtbN>
bit clunks of a workflow though imo
ccawley2011_ has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 265 seconds]
<wbs>
also regarding reviews; one reason for not wanting to have them scattered all over the internet, but only done in one main official location, is for digging up past review discussions. just like looking into the git history itself, one occasionally need to be able to look up what actually was discussed during the review of a patch, and one shouldn't need to hunt for this all across the internet, but
<wbs>
looking in the PRs of the forge we use, or ...
<wbs>
... in the ML archive
<BBB>
github doesn't actually link the merged commit with the MR though, does it? it would be nice if it did
<BBB>
(I know we're not using github, just musing)
<wbs>
in the case of gitlab, as used in videolan, there's no such link afaik (unless gitlab itself adds some magic somewhere, but I haven't seen that)
<wbs>
github can do it, depending on how you merge the PRs
cone-269 has joined #ffmpeg-devel
<cone-269>
ffmpeg James Almer master:8ebccdf2a4f9: avformat/av1dec: fix setting AVPacket->pos in Annex-B demuxer
<wbs>
if merged with "rebase and merge", i.e. merging the original source commits, there's no link added. but if you merge with a merge commit, that merge commit contains a #<pr-number> tag which is a link in the web ui
<wbs>
and the same if you merge with "squash and merge" (which squashes all commits on the PR branch into one commit, with the commit message taken from the PR description), then you also get a #1234 tag added in the commit message, which links back to the PR
<wbs>
without that, it's not trivial to do the commit->PR mapping, but it should at least be possible as long as there's just one location to look in
microlappy has joined #ffmpeg-devel
microlappy has quit [Client Quit]
<kierank>
could just use videolan gitlab
<kierank>
and not have to look at some anime thing for 20 seconds
<kierank>
have ci for all sorts of platforms already done
<BtbN>
sounds weird to use a fragmented format with a playlist file that constantly updates for ingest
<thardin>
they support HLS too, and HLS is considerably easies to use. just point ffmpeg to a URL with a stream key in it that you get from your youtube account's streaming page
<BtbN>
Can't you just use rtmp?
abdu37 has joined #ffmpeg-devel
<thardin>
does rtmp support multiple subs?
<BtbN>
No idea if flv supports subtitles at all
abdu has quit [Ping timeout: 240 seconds]
<thardin>
it does, but only one subtitle stream
<BtbN>
time to propose multiple subtitle streams as well
<BtbN>
it already has multiple audio and video ones
<beastd>
michaelni: hmm, AFAICT you are mis-interpreting the switch to forgejo as was proposed by BtbN. it is just having the main ffmpeg repo in our forgejo instance. so there would be no difference to the procedures except that code could additionally be merged from PRs on forgejo.
<beastd>
regarding merging PRs I would also say (at least at first) intent to merge a PR should be announced 3 days before on ffmpeg-devel (to give subscribers the chance to comment in the PR)
<BtbN>
kierank: I can't reproduce that
<BtbN>
Have you tried Ctrl+F5? Might be stale cache, cause of the recent 11.0.0 update
<TheVibeCoder>
Ctrl+Alt+Del
<jamrial>
mkver: annexb av1 has a lot of extra size fields in between each OBU that are not part of an access unit
<BtbN>
jamrial: do you plan to push the extra Stereo 3D info patches, or should I push them as part of the nvenv set for it?
<jamrial>
push them with the rest of the nvenc set
<jamrial>
or wait, did this hit the ml?
<BtbN>
Your patches? Not that I'm aware of.
cone-269 has quit [Quit: transmission timeout]
<BtbN>
I'm still not sure if alpha layer support works now
<BtbN>
nothing can play back those files
<jamrial>
BtbN: yes, i sent it back in january
<BtbN>
Well, hvcc_add_nal_unit() goes past the nuh_layer_id != hvcc->alpha_layer_nuh_id check, without forcing global headers to off
<BtbN>
so I guess it means it works?
<michaelni>
beastd, maybe new PRs should produce a notification on the ML
<BtbN>
I thought we had HEVC alpha layer decoding in avcodec now
<jamrial>
we do
<BtbN>
hm, then how do I get the alpha layer back out :D
<jamrial>
we're misparsing something when reading the pps in the decoder, i guess
TheVibeCoder has quit [Quit: Client closed]
<BtbN>
so not another nvenc bug?
<jamrial>
i'm looking
<beastd>
michaelni: yeah, automatic notification up on PR creation might be better solution. thought about it as well. should hopefully not be too hard to implement.
<BtbN>
Need to sign up with an address that forwards all mail it gets to the ML pretty much
<BtbN>
and then configure notifications
mkver has quit [Ping timeout: 244 seconds]
<michaelni>
BtbN, can we make 2FA mandatory on forgejo ?
<BtbN>
I think that's a setting, yeah. Not sure if global though
<BtbN>
can set it at the org level, so that everyone with push access to FFmpeg needs 2FA
<michaelni>
i see most people dont have 2FA and i myself didnt either, i just enabled 2FA for my account
<michaelni>
yes, i think we should have 2FA for push
<Lynne>
I hate 2fa
<michaelni>
why ?
<jamrial>
2fa only for those with merge privileges. if you force it for everyone it will only make people think twice before registering and contributing
<Lynne>
it always times out, and I have to find my phone, power it on, and tbh I don't care about it enough to be careful not to lose it
<BtbN>
times out?
<Lynne>
yes
<BtbN>
That's not something that can happen with TOPT normally
<michaelni>
Lynne, buy some fido2 keys
<jamrial>
there are non phone OS 2fa applications
<Lynne>
or "you'd like to update a link on your bio? please authenticate"
<BtbN>
Keepass can hold TOTP tokens for example
<michaelni>
terzor and ledger if you have also work as keys
<Lynne>
2fa is for those who don't practise responsible opsec
<BtbN>
Losing a password happens faster than one likes
<Lynne>
if you lose a password you don't practise responsible opsec
<michaelni>
BtbN, so true, i searched for my forgejo pw 10min today ;(
<BtbN>
Well, as long as nobody found it before you, you're good
<michaelni>
"<Lynne> 2fa is for those who don't practise responsible opsec" <-- this is only partly true, if your machine is hacked, your browser, some plugin,, someone looks over your sholder, has the right equipment to listen to keyboard/screen emissions, ... they can find some stuff out about your pw, but they cannot do that with 2FA
<michaelni>
anyway i am not insisting on 2FA if people are against. I just wanted to highlite thats something that should be considered. And i think it looks better for FFmpeg if we require 2FA for developers push access
<BtbN>
I think it's a good idea to enforce it for push access
<BtbN>
Keep in mind ssh keys won't prompt for the 2FA token on push or anything
mkver has joined #ffmpeg-devel
ccawley2011_ has quit [Ping timeout: 248 seconds]
ccawley2011 has joined #ffmpeg-devel
abdu37 has quit [Quit: Client closed]
ccawley2011_ has joined #ffmpeg-devel
<michaelni>
ssh doesnt require me to enter my private key in a browser window
ccawley2011__ has quit [Ping timeout: 265 seconds]
ccawley2011 has quit [Ping timeout: 248 seconds]
ccawley2011_ has quit [Ping timeout: 248 seconds]
<jamrial>
BtbN: actually, it may be nvenc creating a broken slice for the alpha layer
<jamrial>
i see get_bits_left(gb) go below 0 in the middle of slice header parsing
<jamrial>
so not even a full header, let alone the slice data
<BtbN>
hm
russellty has joined #ffmpeg-devel
<russellty>
Is patchwork down?
<michaelni>
seems up for me
<BtbN>
It's just its usual dead slow self
<BtbN>
That's not even crawlers, but just shoddy programming
System_Error has quit [Remote host closed the connection]