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
<BtbN>
For PRs it can kinda be done with a properly maintained CODEOWNERS file. At least I think getting assigned still sends you an E-Mail, even if not watching
<BtbN>
but for an issue, someone has to manually assign you. Or we actually need to employ an LLM, that reads issues, and somehow guesses who might care
Compn has quit [Read error: Connection reset by peer]
Compn has joined #ffmpeg-devel
Kimapr_ is now known as Kimapr
Guest96 has quit [Quit: Client closed]
<kasper93>
BtbN: I changed lint script to use api, still in python though
<BtbN>
kasper93: so did I, see my PR
<BtbN>
I pinged you there
<BtbN>
I basically made it capable of running both locally (which it couldn't before, it needed GITHUB_* vars), and on Actions
<kasper93>
I didn't see, I would comment there.
<kasper93>
I think my version is simplier, I removed all the unnecessary crap
<kasper93>
also by the looks of commit report we used the same tools
secondcreek has quit [Ping timeout: 252 seconds]
<kasper93>
also I made it so it gets only one file, doesn't even checkout repo at all
<BBB>
code lint? I hope it's not require to pass before code gets merged?
<BBB>
(I hade code linters)
<BBB>
hate*
BtbN has quit [Remote host closed the connection]
BtbN has joined #ffmpeg-devel
iive has quit [Quit: They came for me...]
\\Mr_C\\ has joined #ffmpeg-devel
<BBB>
oh I see it's not a code linter; it's a git commit message linter
secondcreek has joined #ffmpeg-devel
<BtbN>
There is also a code linter and typo squatter
<Lynne>
I can't help but think that it will be a MAJOR PIA for specific commits
<Lynne>
sure, it may work for 90% of commits, but for the last 10% you may get death threats
<Lynne>
and no, stop forcing adding sign-offs when we've never used them
<Lynne>
its like requiring formal business attire at our irl meetings in the hopes of looking like we're synergizing important business decisions
<kasper93>
I think we can revisit commit msg linter at another time
<kasper93>
With proper documentation update, with resoning on some of the restictions. Because right now I agree that some people might get very unhappy that ci is not passing their commits
<kasper93>
Though from experience, this kind of check really helps with drive-by contributors. Almost certenly they will do something that doesn't much existing "style" of commit messages
<kasper93>
and sure it is not relevant, but reading consistent looking git log is easier to follow along
<kasper93>
(ffmepg is pretty good about it already)
<Kimapr>
so i made a demuxer for a format that is half something i made up and half a niche demoscene thing (bytebeat). should i submit this to upstream ffmpeg or keep it on my personal soft-fork?
<Kimapr>
bytebeats are typically shared as URLs to a web player with data encoded in the URL or short snippets of code, but i made them into a self-contained file format with metadata embedded as a comment at the top of the file so that it's possible to conveniently play them in a media player
jamrial has quit []
<Lynne>
you can submit a PR
<Lynne>
IMO I think it would be fine, we have various fun demoscene formats like 8088 corruption
<Yalda>
I fed ffplay a 50GB block device with unrecognizable partition today which was fun. Video came out!
Traneptora has joined #ffmpeg-devel
<Traneptora>
BtbN: can you ban balling from the new tracker? they've already been banned from trac and from IRC
<Traneptora>
it's the same guy as Valzpod
<Traneptora>
already banned from nearly every multimedia tracker
<kasper93>
not banned on trac
<Kimapr>
Lynne: by PR do you mean like on the new forgejo instance? the main site says to submit patches to the mailing list, but lurking here i learn that there is also a forgejo instance now
<kasper93>
they are the main user
<Lynne>
Kimapr: use the forgejo instance, everyone that matters is on there now
<Kimapr>
i see .. that is also preferrable to me, as i am not well-versed with email
<Kimapr>
though i did set up a personal email server the other day
<Kimapr>
should i also move my bugfix for the libopenmpt demuxer to forgejo? i submitted it to the mailing list
mkver has joined #ffmpeg-devel
<Lynne>
sure, it would make merging easier
<Lynne>
does "RGhA" mean anything to anyone?
<Lynne>
as well as "bp16"/"bp64"
<Yalda>
RGhA sounds like a fourcc
<Lynne>
found them, CVPixelFormatType FOURCC
<Yalda>
Ah, Core Video
<Lynne>
oh god
<Lynne>
if I'm reading this right, apple have integrated some sort of partial debayering in their prores raw decoder
<Lynne>
it looks like plain bilinear debayer
<Lynne>
actually this looks like the qscale matrix and some decompiler jank
<Lynne>
still, I think I've finally found the dequant function
<Lynne>
all of them, they apply different dequant for various output formats (rgha/bp16/bp64 (whatever downscaled bayer is?))
<Lynne>
with 4 different variants
_whitelogger has joined #ffmpeg-devel
<Traneptora>
kasper93: they are banned on trac, they just keep making alt accounts
<Traneptora>
whack-a-mole
Warcop has quit [Remote host closed the connection]
andm100 has joined #ffmpeg-devel
<Kimapr>
i have another question: what's a decent way to pass purely textual "video" data from my demuxer? bytebeat in principle is an audio-only format, but the commonly used web player displays errors thrown from the code in a neat monospace box which some songs exploited to display animations by throwing a specially-crafted error once in N samples
<Kimapr>
subtitles seem like a nice way to do this (though this is definitely an unconventional use of them), as i won't have to be responsible for turning text into pixels then
<Yalda>
yes, i think its still timed text falling into the realm of subtitles
<Yalda>
may not be visually ideal without some ASS markup to force monospace and alignment, but it sounds like the easiest path
<Kimapr>
now the problem is figuring out how to make a subtitle stream (idk how lol)
<Kimapr>
for audio stream i was lucky to know of a demuxer that happened to have the same exact structure as i would want mine to be, but there's no examples for subtitles that i can comprehend
<BtbN>
Traneptora: I could, but I don't really wanna get into said whack-a-mole. There is no good way to ban someone from just making a new account over and over.
<BtbN>
Unless there's actually extreme transgressions, I think it might be better to at least know for sure who's on the other side of the screen.
\\Mr_C\\ has quit [Remote host closed the connection]
<kasper93>
I'm also not a big fan of auto-merging, but maybe it's for the best to automate things, especially for not a big patches
<kasper93>
the banner `michaeln i scheduled this pull request to auto merge when all checks succeed 16 minutes ago.` is big enough to see that it's been scheduled
<kasper93>
Can I configure forgejo "quote and reply" to not include @XYZ wrote in <link> part?
<BtbN>
nope, nothing in the Mail-Headers to distinguish those
<BtbN>
Though making a sieve-filter on "mentioned you" and "assigned you" would work
<beastd>
i forgot on who mentioned it already (wbs iirc) but ideally we would make forgejo post the important stuff to the ffmpeg-devel ML and forgejo would only email individuals about mentions and for issues or PRs they already were part of.
<BtbN>
Yes, but someone needs to write such a feature
<kasper93>
BtbN: For emails, I can do it myself. For javascript Play-Doh website, seems to be not so flexible
<BtbN>
Well, I've now installed a sieve filter for "mentioned you" and "assigned you"
<BtbN>
that should get me most pings to a seperate folder
<Lynne>
please don't, I don't want double notifications from both ffmpeg-devel and code.ffmpeg.org
<BtbN>
We absolutely need to at least forward new PRs to the ML
<BtbN>
But not much else imo
<BtbN>
Also, a few days ago didn't you say we should just drown the ML in notifications? :D
<BtbN>
kasper93: one downside of the simplified script is that it now only works on PRs, not pushes
<BtbN>
though I disabled it for pushes anyway, cause at that point it's too late and would just be red forever
<kasper93>
I know, that was explicit
<kasper93>
there is no point to checking pushes, cant fix those anyway
<BtbN>
Well, it was still enabled for pushes
<kasper93>
I know I forgot to disable it
<kasper93>
I was thinking about it at some point, but never did it ;p
<fjlogger>
[FFmpeg/FFmpeg] Pull request #20088 merged: avformat/mov: move AVC-Intra extradata generation to earlier in the stsd parsing process (https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20088) by jamrial
<BtbN>
The whole signed commits thing confuses me
<BtbN>
how did they work with E-Mail based patches?
<BtbN>
You GPG signed the E-Mail, and it somehow carried into the commit?
<jamrial>
no, you sign the commit
<BtbN>
But you can only do that if you push it yourself then
<jamrial>
yeah
<BtbN>
So that's the same with Forgejo still then
<jamrial>
or pull the commit from some public repo
<BtbN>
push yourself, and mark PR as manually merged
<BtbN>
There is some support for GPG in Forgejo, but I doubt you can or should upload your private key
<jamrial>
yes, that's how to workaround it, but still more work than a "rebase and merge" click :p
<BtbN>
Like, you can add your GPG pubkey in your account
<BtbN>
If you want signed commits, I see no other way to do that. You need to rebase yourself
<jamrial>
people that care about signing can do it, so not a problem really
<BtbN>
I could enable the "FF Only" merge option
<BtbN>
so if it's available, you can at least use it and the signature survives
<BtbN>
I guess a proper merge-commit would also retain it?
<BtbN>
But we never used those before ever
<jamrial>
yes, but i don't like the idea of doing branch merges
<jamrial>
it makes bisecting a pain
<BtbN>
If you force-push upgrade the PR branch first, before manually merging to master, it'll also auto-detect the PR as merged and close it
<BtbN>
needs to be the same commit hash for that to work
<kasper93>
yes, if forgejo don't rebase internally, signature will survive
<kasper93>
signed tags / releases is important, for each commit it's less relevant
<kasper93>
unless every single commit require signature... it's just easy to bypass it. Of course there is impersonation aspect to it.
fjlogger has quit [Remote host closed the connection]
fjlogger has joined #ffmpeg-devel
<fjlogger>
[FFmpeg/FFmpeg] Pull request #20098 opened: avformat/mov: set primary extradata based on the first Sample only if it's not already in place (https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20098) by jamrial
fjlogger has quit [Remote host closed the connection]
<fjlogger>
[FFmpeg/FFmpeg] Pull request #20098 opened: avformat/mov: set primary extradata based on the first Sample only if it's not already in place (https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20098) by jamrial
<kasper93>
BtbN: rebased lint branch, with small adjstemnts to script, mostly types, and assert.
<kasper93>
I don't like `os.environ["GITHUB_REF"].split("/")[2]` but it will work untill it doesn't, probably not a big deal
mkver has joined #ffmpeg-devel
fjlogger has quit [Remote host closed the connection]
<BtbN>
That's the standard way of getting the PR numbers in A LOT of workflows
<BtbN>
they can't break that
fjlogger has joined #ffmpeg-devel
<fjlogger>
[FFmpeg/FFmpeg] Pull request #20098 opened: avformat/mov: set primary extradata based on the first Sample only if it's not already in place (https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20098) by jamrial
<BtbN>
last time this one re-plays. It should have sent an E-Mail of the PR to ffmpeg-devel
<BtbN>
There is some weird stuff going on with E-Mail formating. That ">" in front of the From line is not there anywhere.
<BtbN>
But git am does not seem to mind
<BtbN>
It is using the wrong From: though, despite the correct one being in the mail. Guess if you want it to get it right you gotta download the linked mbox format patch
<kasper93>
> If no one answers within a reasonable time-frame (12h for build failures and security fixes, 3 days small changes, 1 week for big patches) then commit your patch if you think it is OK.
<kierank>
when was that added
<kasper93>
I don't know, but for years, patches are merged like that.
<Yalda>
GewoonLeon: sorry; I had stepped away. it already went stale. I can rebase and merge via forgejo button if you're good with that
<kasper93>
BtbN: looks like you can trust the signature and re-sign commit.
<BtbN>
That's what collaborator mode seems to do
<kasper93>
I remembered correctly, that in GitHub-like signing, it would change commiter
<BtbN>
Yeah, comment there seems to indicate that
<kasper93>
I think it's fine, but it should be documented somewhere in docs, that such (re)signing happens.
Guest73 has quit [Quit: Client closed]
piolad has quit [Quit: Client closed]
<Yalda>
oo BtbN did you just add it by chance? I got a 502 then refreshed, and now instead of telling me it won't sign, it implies to sign as long as I add my public key
<BtbN>
Yeah, just restarted it to enable the settings
<BtbN>
the lock there on the PR would have had to be green in order to get carried over
<Yalda>
i get it now, that probably ties in to the fact that when I click the lock from the MR it tells me "Signed by untrusted user:", which matches your statement earlier of the commit being signed with a collaborator's key
<Yalda>
needing to be signed with*
<BtbN>
I'm not sure how it would have went if their key would have been added to their account
<BtbN>
Cause by getting their PR merges they also are a collaborator
<BtbN>
so maybe a green lock there, and you having 2FA, would have been enough
<Yalda>
i think the user has another MR if that one gets merged down the road it could be a good case study
<BtbN>
We should tell them to add their signing key to their account
<Yalda>
though I only did g728 last time it looks straightforward
<kasper93>
I think "collaborator" mode is misleading, I think it means "people with push access"
<BtbN>
Yeah
<kasper93>
else it's not trusted, even if verified.
<BtbN>
Would changing the model to committer help?
<kasper93>
I think it would yes
<BtbN>
This collaborator model seems quite limited
<BtbN>
basically nothing from an external person could ever be signed
<kasper93>
Though then commiter is rewritten by forgejo. I think they idea is that you don't want to put trust to commits with foregin commiter.
<BtbN>
There's collaboratorcommitter, which seems to demand _both_
<Traneptora>
Yalda: should I ping you when I'm ready to approve the change before merge?
<Traneptora>
so you can test whatever you want to test
DauntlessOne498 has quit [Read error: Connection reset by peer]
DauntlessOne498 has joined #ffmpeg-devel
<Yalda>
Traneptora: I will wait since BtbN looks like might be considering changing config ^ I think the goal was just to chime in to ask the user to add a signing key to their account so we can tease out this commit signing workflow is all
<Yalda>
ty
<BtbN>
I'm not sure if we should change config there
<BtbN>
I'll leave it as it is for now, it at least enabled michael to keep signed commits via PRs :D
Kimapr has quit [Remote host closed the connection]
Kimapr_ has joined #ffmpeg-devel
<Yalda>
cool. yeah I see his are nice and green. then Traneptora yes sure whenever you approve just let me know and I'm happy to add a comment there - doesn't make sense now in the middle of the review. I will tag you BtbN
<Yalda>
so we are asking them to add their public key and thats it ?