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
Kimapr_ has quit [Remote host closed the connection]
Kimapr_ has joined #ffmpeg-devel
lexano has quit [Ping timeout: 252 seconds]
Kimapr_ has quit [Remote host closed the connection]
Kimapr_ has joined #ffmpeg-devel
kurosu has quit [Quit: Connection closed for inactivity]
iive has quit [Quit: They came for me...]
<fflogger>
[newticket] wavybaby: Ticket #11696 ([undetermined] ffmpeg unable to parse full runtime of wav file) created https://trac.ffmpeg.org/ticket/11696
<Kimapr>
i sent a tiny patch to ML to fix a bug in libopenmpt demuxer the other day, can someone review/merge it? pretty new to this so not sure if i'm doing things right
<Kimapr>
there's still some strangeness with libopenmpt seeking left (mpv exits when seeking to the beginning, which doesn't happen with other formats) even with the patch so i'll probably do a follow up later
Kimapr has quit [Remote host closed the connection]
<fjlogger>
[FFmpeg/FFmpeg] New comment on pull request #20024 rewrite/add mcc [de]muxer, add AV_CODEC_ID_SMPTE_436M_ANC with mxf support, and add conversions <-> eia-608/708 (https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20024) by programmerjake
<fjlogger>
[FFmpeg/FFmpeg] Pull request review requested: #20024 rewrite/add mcc [de]muxer, add AV_CODEC_ID_SMPTE_436M_ANC with mxf support, and add conversions <-> eia-608/708 (https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20024) by programmerjake
<cone-053>
ffmpeg zhaozhenghang master:eade338656b0: libavformat/mov.c: Fix "statement will never be executed" warning
mkver has joined #ffmpeg-devel
deeyes has joined #ffmpeg-devel
bwu25 has joined #ffmpeg-devel
bwu25 has quit [Client Quit]
<fjlogger>
[FFmpeg/FFmpeg] New comment on pull request #20038 avfilter: add vf_scale_d3d11 filter and mfenc support for d3d11 frames (https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20038) by dashsantosh-mcw
Kimapr has quit [Remote host closed the connection]
LainIwakura has joined #ffmpeg-devel
MisterMinister has quit [Ping timeout: 260 seconds]
MisterMinister has joined #ffmpeg-devel
indecisiveturtle has joined #ffmpeg-devel
cone-922 has joined #ffmpeg-devel
<cone-922>
ffmpeg Vittorio Giovara master:c275f3bfa160: mov: Export frame packing information from pack box
<cone-922>
ffmpeg Vittorio Giovara master:119d127d05c9: lavu/spherical: Add support for Spherical Immersive type
LainIwakura has quit [Ping timeout: 272 seconds]
LainIwakura has joined #ffmpeg-devel
<haasn>
Lynne: fair enough, in such a case the TC can be the overruling decision maker anyway
<haasn>
have we ever thought about auto-generating the libav* version numbers and API changelog from something like a list of files in doc/APIchanges.d ?
<haasn>
I think we are collectively losing more hours constantly solving these merge conflicts than it would take to automatic something like thi
<APic>
APIc-hanges.d ♥
<haasn>
we could also easily automate generation of the date and git commit hash fields
<haasn>
by just querying, at build time, which commit introduced a given file
<kasper93>
I think it's good idea, conflicts in changelog/apichanges are pointless work to resolve.
<JEEB>
yea, I think I brought something similar up before, mentioning the array in libplacebo as an example
<JEEB>
esp. since it's much easier to not mess up adding a line to an array merge conflict than to have a number bump go missing since someone else bumped to that exact number
<kasper93>
forgejo has messed up all my comments
<kasper93>
I don't like those javascript tools anymore
<TheVibeCoder>
added seeking support to THP demuxer
<TheVibeCoder>
figured what the most best of ffmpeg devs couldn't figure
LainIwakura has joined #ffmpeg-devel
<CounterPillow>
I think you mean Claude figured it out
<TheVibeCoder>
not using Claude
HarshK23 has quit [Quit: Connection closed for inactivity]
Kimapr has joined #ffmpeg-devel
<haasn>
Lynne: just fyi the assumptions vf_overlay_vulkan makes about the alpha blending are very odd
<haasn>
it basically only works as written if the top layer is straight alpha but the bottom layer is premultiplied
<haasn>
because for blending straight onto straight you need further math (cf. code in vf_overlay)
<haasn>
but you then make this point moot by stripping the alpha channel of the output anyway which means it breaks if the input has any transparency
<TheVibeCoder>
hacks!
LainIwakura has quit [Ping timeout: 272 seconds]
<haasn>
it also doesn't seem to handle planar inputs with alpha at all, since it doesn't make any effort to load the overlay alpha value from a different plane
<Lynne>
yeah, IIRC that filter's one of the last written before I sent the set off to the ml, and I wanted to get it over and done with
<haasn>
I propose we simply remove the ability to alpha blend at all until this mess is sorted out, since as it stands it's basically broken
<haasn>
fair
<Lynne>
sure
DodoGTA has quit [Read error: Connection reset by peer]
LainIwakura has joined #ffmpeg-devel
lexano has joined #ffmpeg-devel
<haasn>
kasper93: that seems like a pretty major bug; I've never experienced such with gitlab
<haasn>
kasper93: I saw in the thread that there was a force-push shortly before your review; is it possible that there was a race condition where the code was being updated while you were reviewing it?
<haasn>
maybe I can try and test to see if we can recreate these conditions
<kasper93>
I think it is possible I made those comments before the force push
<kasper93>
and posted review after
<haasn>
it was 13 minutes before the review was posted
<kasper93>
but I would still expect them to be anchored to respective lines
<haasn>
yeah, me too
<wbs>
very few forges handle inline comments across rebase/forcepushes very well unfortunately :-(
<averne_>
As far as I can tell from the spec, grayscale is not supposed to be supported by prores, and filling the chroma planes with a neutral value is out of spec
<TheVibeCoder>
leader is known for very long to commit hacks
jamrial has joined #ffmpeg-devel
<TheVibeCoder>
the most prominent hack is breaking mjpeg decoding of flat white colored images
<averne_>
So filling the chroma planes when the entropy coded data is null doesn't feel correct at all. I don't think I'll mirror that behavior in my vulkan decoder.
<Traneptora>
<kasper93> 2. list of commits is "stuck" in timeline
<Traneptora>
that is why I assumed the force-push didn't work and closed-and-opened anotehr PR
<Lynne>
averne_: better yet, send a patch to get rid of that filth
<averne_>
Lynne: Sounds good, I'll do that
<averne_>
Should I also get rid of the encoder side in prores_aw? Checking the spec, I'm pretty sure the entropy data is never supposed to be empty, and should contain at least the DC coeffs.
<haasn>
(disclaimer: I've never actually tried using pijul)
<haasn>
though I have used vcs based on patch theory
<Traneptora>
I don't understand the concept of "patch theory" ngl
<Traneptora>
the big selling point pijul has on their website is "we use a correct 3-way merge algorithm" as though that's a property of the VCS and git can never change that
<Traneptora>
or that "patches are unordered diffs so they can't conflict" like.... yes they can?
<haasn>
the fundamental problem with git is that commits describe the state of the repo, whereas what developers want to actually work with, more often than not, is diffs
<Traneptora>
I was under the impression that a git commit both describes state and previous state
<haasn>
though at some level you can argue that this is just a question of performance/efficiency
<Traneptora>
which means there's a diff inherent in it
<haasn>
right, but its using the "correct" 3-way merge algorithm becomes very expensive
<haasn>
as you have to recompute diffs on the fly potentially very often for it
<haasn>
that's why I think it's not so much a question of git being fundamentally incapable so much as it is the fact that git's core design is engineered in a way to make its model very inefficient and the patch model very inefficient
<haasn>
large rebases already are considerably slower than e.g. large merges
<Traneptora>
I see, so it's all just a performance issue really
<haasn>
whereas in a patch theory vcs, rebasing is the default (=cheap) operation, I guess you could say?
<haasn>
yes and no; it's also a question of the core design informs downstream decisions about which tools exist and what modes they end up supporting
<Traneptora>
but I see what you're saying. if I have a 20-patch set and someone pushes a commit to master, then rebasing my patchset requires git to recompute the state in 20 different ways
<Traneptora>
or rather, recompute the "state" 20 times
<haasn>
notably, we live in the reality where every project I have ever worked with demands a linear timeline on master with feature branches having to be rebased constantly
<Traneptora>
yea, that
<haasn>
and merge commits are explicitly disallowed, despite merge commits being the *intended* way to use git
<Traneptora>
kernel notably still uses merges and merge commits
<haasn>
to recompute and reapply the diff, but yes
<haasn>
I think a lot of large projects outside of the foss bubble use merge commits for feature branches also
<haasn>
and usually merge commits are used when two projects depend on each other, e.g. if you have a foss upstream and your own fork
<Traneptora>
I feel like the git model of merges is like, the idea of mainstream software where you have a version with a stable release and you cut that release, and then features are off in a separate branch
<haasn>
problem is that the git tooling makes merge commits a pain to deal with as well
<haasn>
e.g. bisecting becomes harder with merge commits
<haasn>
and this is also a problem that, as I understand it, patch theory vcs avoids
<Traneptora>
doesn't subversion use revisions?
<BtbN>
bisect handles merge commits fine, it adds an extra step though when it needs to check a merge base
<haasn>
Traneptora: svn uses the git model afaict
<Traneptora>
nvm then
^Neo has joined #ffmpeg-devel
<haasn>
BtbN: ideally yes; in practice, sometimes you have to abort and restart the merge process or are trying to bisect a heisenbug or something else happens and it helps having a linear timeline so our brains can more easily understand where in history we are
<haasn>
at least that's my experience
<haasn>
anyway, not a big deal
<BtbN>
you can merge master into feature branches fine
<BtbN>
just need to rebase it one final time before getting merged
<wbs>
haasn: I'm not entirely sure, but I had the impression that svn, at least back before git got properly started, only stored diffs; within the repo you'd have a neat series of one (internal state) file per revision - but I'm not sure how svn did checkouts without it taking forever then
<haasn>
BtbN: does that actually clear out the merge commits?
<haasn>
if so I may start doing that
<BtbN>
yes, rebasing flattens out merge commits in that case
<BtbN>
if they're from the branch you rebase onto of course
<BtbN>
if they're random other merge commits, they'll stay
<Traneptora>
wbs: my impression was that svn had inverse commits, where checking out trunk was fast but checking out a specific revision required the server to recompute the diffs in reverse order
<haasn>
as an aside, rebasing is also plain more difficult that merging when you have 10 commits in a row that change the same place
<wbs>
Traneptora: oh, that may very well be the case
<Traneptora>
but that was my impression from having used svn in like, a long time ago
<haasn>
for example, if 5 commits increase the same version number, and you rebase it onto master that also changed the same number
<Traneptora>
I'm not very old. most projects switched to git when I was still in high school
<haasn>
you now have to manually stop, edit, add, and continue for 5 separate commits in a row
<haasn>
rather than just doing it once with a merge commit
<BtbN>
haasn: do you not have rerere enabled?
<haasn>
BtbN: rerere doesn't help in this scenario
<haasn>
because it's never seen the conflict before
<haasn>
that only happens if you rebase the same commit onto the same branch multiple times; e.g. if you abort and restart the rebase
<Traneptora>
haasn's thing is a real issue. constantly dealing with it with the exif overhaul which bumps version.h numbers *and* doc/APIChanges commit that all need to be fixed constantly
<haasn>
but the problem with the scenario I just described is that each commit linearly depends on (and in turn conflicts with) the previous commit's resolution
<BtbN>
Yeah, though merge commits aren't a great solution either
<haasn>
admittedly I don't know how pijul fares in this scenario either
<BtbN>
It makes it really confusing to read what was changed
<haasn>
ultimately the most flexible solution is to do exactly what I described earlier and simply stop having a single version number that each commit increases
<BtbN>
cause reading the commit that did the change might not match with what's actually on master, since the merge commit resolved conflicts and changed it
<wbs>
I usually leave out such bumps from patches until they're nearing completion. which works better as long as you know nobody else is going to grab and merge your branch, and of course is unclear to communicate to reviewers, that it isn't forgotten, just not added yet
<Traneptora>
I discovered that sometimes I needed to move a change from one commit earlier in my 20-commit tree
<Traneptora>
so I change it back to earliest state, commit that change, revert the commit (which is really a forward change), and then put the revert commit as a fixup after the commit that was supposed to change it, and then the undo commit as a fixup right *before* the one I didn't want to do it
<Traneptora>
this is a bit of a mess. patches would be conceptually simpler definitely
<haasn>
Traneptora: you mean e.g. commit 1 adds files A, B and commit 2 adds files C, D, E but you want commit 1 to add C instead of commit 2?
<haasn>
(ditto for line changes instead of files)
<Traneptora>
more like, adds an argument to a function. commit 1 adds function foo(), commit 2 gives it a new argument foo(avctx), because I screwed up when doing development, and it really should have had that argument the whole time
<Traneptora>
so like, I change the function signature to foo(), then I commit 3. then I revert 3, which is commit 4. then I order the commits so it goes 1 -> 4 -> 3 -> 2, and do a fixup which merges 4 into 1, and then 3 into 2.
<Traneptora>
fixup which melds* I should say, cause it's not a merge. that's a term
<haasn>
what I like to do here is: rebase -i HEAD~20; stop at commit #1; git checkout -p (commit #1); git commit --amend; git rebase --cont
<Traneptora>
I'm not familiar with git checkout -p
<haasn>
git checkout -p (commit #2) I mean
<haasn>
it's an interactive checkout that selectively cherry-picks from the diff between HEAD and the other commit you provide
<haasn>
(and stages it)
<haasn>
you can also checkout -p commit#2 -- path/to/file.c to cut down on noise
<haasn>
of course, this would still work better in a patch theory model where you could actually just cherry-pick the diff
<haasn>
git doesn't let you cherry-pick diffs despite that being immensely useful
<haasn>
git also doesn't let you compare commit ranges directly while discarding differences in the base, which would also be very easy in a patch theory vcs
<Traneptora>
yes it does? git cherry-pick commitID actually cherry picks the diff between it and its parent
<haasn>
there is no git cherry-pick -p to selectively cherry pick, I meant
<Traneptora>
oh that's what you mean
<Traneptora>
> rebase -i HEAD~20; stop at commit #1
<haasn>
so you have to work around it with cherry-pick + checkout -p + fixup
<Traneptora>
how do you "stop at commit #1" I didn't realize that git rebase -i lets you just stop somewhere. I figured if you removed the subsequent lines it just removes the commits
<haasn>
there are comments in the bottom no
<wbs>
Traneptora: change "pick" to "edit" in the task list
<haasn>
you can replace "pick" by e.g. "edit" to stop on that commit for editing
<haasn>
or include "break" after it
<Traneptora>
e, edit <commit> = use commit, but stop for amending
<Traneptora>
ye, I guess I missed that one
<Traneptora>
I mostly use pick, reword, fixup, and fixup -C
<Traneptora>
oh yea, break also works, huh
<Traneptora>
thanks
<Traneptora>
that seems way simper than my solution
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
^Neo has quit [Ping timeout: 272 seconds]
odrling has quit [Remote host closed the connection]
odrling has joined #ffmpeg-devel
odrling has quit [Remote host closed the connection]
odrling has joined #ffmpeg-devel
cone-922 has quit [Quit: transmission timeout]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
Guest59 has joined #ffmpeg-devel
Guest59 has quit [Client Quit]
Guest7833ss has joined #ffmpeg-devel
Guest7833ss has quit [Client Quit]
<kasper93>
haasn: while git rebase will flatten all merges, you need to beware that you will have to resolve all conflicts per commit
<kasper93>
hence why, I prefer to doing rebase and keeping feature branch mostly up to date. Resolving less/smaller conflicts is easier and less error prone imho
<kasper93>
rerere also doesn't help because git merge conflicts may be different than git rebase conflicts
minimal has joined #ffmpeg-devel
ShadowJK has quit [Ping timeout: 252 seconds]
<kasper93>
as for "version file conflicts" this is pain, that's why mpv now has each interface-change in separate file which is then merged into main file one each release
<kasper93>
none other PR have this button, I don't understand why
<JEEB>
ohhh
<JEEB>
since you have a conflict it lets you have a chance to tell that btw, this was merged as commit xyz
<JEEB>
have never seen you being able to manually specify the hash lol
<TheVibeCoder>
why bother, ffmpeg is full of hacks
<haasn>
kasper93: that's for when there are merge/rebase conflicts I guess, so if you merge it manually you can point it at the merge resolution? no idea
<kasper93>
hmm, so if you push to upstream, without rebasing feature branch
<kasper93>
I think this button should show up too?
<kasper93>
becasuse it would detect conflicts or empty commits in rebase resolution
cone-840 has joined #ffmpeg-devel
<cone-840>
ffmpeg Dariusz Frankiewicz master:9d8469e431a2: avcodec/apv: align APV color format support with latest liboapv version
<cone-840>
ffmpeg Dale Curtis master:2ddc3cbd98ea: avcodec/flacdsp: Fix integer-overflow in flac_lpc_33_c
novaphoenix has quit [Quit: i quit]
<kasper93>
it would make sense, then you can close as manually merged even if not autodetected as such
novaphoenix has joined #ffmpeg-devel
paulk has quit [Ping timeout: 260 seconds]
ShadowJK has quit [Ping timeout: 252 seconds]
ShadowJK has joined #ffmpeg-devel
paulk has joined #ffmpeg-devel
paulk has joined #ffmpeg-devel
<kasper93>
I'm not sure if timer auto merge bot is good idea.
<kasper93>
But could have a timer bot to add "ready to merge" label after X amount of time passes and if other conditions are met like passing fate and at least 1 approve.
<kasper93>
Additionally such bot could add "review needed" label, after there is no changes for X amount of time on PR and was not reviewed yet. (i.e. no approve or request for changes or open discussions)
<BtbN>
I only enabled "Rebase and ff", I guess we don't want to start with Merge Commit or Squashing
<wbs>
thanks, that sounds good
<wbs>
(that's also what videolan have been using)
<BtbN>
mirroring back to g.v.o is struggling right now, cause somehow a bunch of branches named remotes/origin/... have made it there, and deleting them is blocked by the hook scripts
<cone-840>
ffmpeg Dale Curtis origin/release/2.7:HEAD: avcodec/flacdsp: Fix integer-overflow in flac_lpc_33_c
<cone-840>
ffmpeg Dale Curtis origin/release/3.0:HEAD: avcodec/flacdsp: Fix integer-overflow in flac_lpc_33_c
<cone-840>
ffmpeg Dale Curtis origin/release/4.4:HEAD: avcodec/flacdsp: Fix integer-overflow in flac_lpc_33_c
<cone-840>
ffmpeg Dale Curtis origin/release/5.0:HEAD: avcodec/flacdsp: Fix integer-overflow in flac_lpc_33_c
<BtbN>
yeah, those. lol cone
<BtbN>
Weird that it logs their deletion
DauntlessOne498 has joined #ffmpeg-devel
DauntlessOne49 has quit [Ping timeout: 252 seconds]
DauntlessOne498 is now known as DauntlessOne49
iive has joined #ffmpeg-devel
<BtbN>
oh, the commit is just random nonsense (whatever last went to master)
ccawley2011 has quit [Ping timeout: 260 seconds]
DauntlessOne49 has quit [Ping timeout: 240 seconds]