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
<kasper93>
can add allow list for some common names
<kasper93>
tests/ref could also be excluded from all checks
<kasper93>
though why some ref files have like 5 new lines at the end
<kasper93>
tbh, it's not as bad as I would though it be
<kasper93>
it's probably possible to set it as not fatal errors
<kasper93>
but then might as well disable it, because people generally don't pay attention to CI unless its failing
<BtbN>
nope, for all I can tell, non-fatal is not an option
<fjlogger>
[FFmpeg/FFmpeg] Pull request opened: #20070 avformat/movenc: look for the Intra profile flag before assuming a stream is AVC-Intra (https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20070) by jamrial
<kasper93>
running it only against changes in PR it also possible without `--all-files`
<kasper93>
though it's annoying if you change a line and it complains about unrelated thing, because master branch has issues
<BtbN>
I don't think it'd be able to figure out what the PR changed, would it?
<kasper93>
--from-ref is an option
<kasper93>
this will run against files changed
<BtbN>
It's trying really hard to spell-check crazy asm instructions
<kasper93>
but as I understand it runs on whole files anyway, so kinda pointless
<BtbN>
I also wonder how annoying this will be, given if you make up a new variable name, it'll hate it
DauntlessOne498 has quit [Read error: Connection reset by peer]
<kasper93>
it's double edged sword, there will be times when you need to update ignore list
DauntlessOne498 has joined #ffmpeg-devel
<BtbN>
It found a lot of typos
<kasper93>
typo in copyright line cought me off guard, I would expect you always copy it from somewhere else ;)
iive has quit [Quit: They came for me...]
<kasper93>
I haven't figured out if there is a way to run codespell also on commit message / description
<BtbN>
It also is highly confused by tools/clean-diff, and so is my text editor
<kasper93>
because while you can fix code, typos in commits are forever to stay
<jamrial>
BtbN: g.v.o isn't synced
<BtbN>
I know
<jamrial>
ah ok
<BtbN>
nothing I can do until thresh comes back.
<BtbN>
Almost first thing someone did after the migration was push something the VLC hooks reject
<kasper93>
ah, clean-diff is replacing \n with 0xB0 and later replace it back. 0xB0 is not valid utf-8, so it fails
<kasper93>
murphy's law
<kasper93>
literally first merge after enabling "merge button" and it broke ;p
<jamrial>
BtbN: tabs?
<BtbN>
missing new line at end of file
<BtbN>
it's also not like we can just add the missing new line. We'd have to force-push it into the commit
<BtbN>
the hooks on g.v.o should probably just be disabled
<BtbN>
if someone sees thresh before me in #videolan, please tell him
<BtbN>
for out repos at least
<BtbN>
I think I got the ignore list so far that everything left is a legit typo
BradleyS has quit [Read error: Connection reset by peer]
BradleyS has joined #ffmpeg-devel
indecisiveturtle has quit [Read error: Connection reset by peer]
indecisiveturtle has joined #ffmpeg-devel
<kasper93>
could also fix whitespaces in ref files actually
<kasper93>
still pasess without them
<BtbN>
they're all auto-generated though, aren't they? So enforcing that will annoy anyone who adds new ones
<kasper93>
that worry me more, why generated files have trailing whitespaces
<BtbN>
Probably because chained printfs, and not printing the final \n or " " would be annoying
<kasper93>
it's exif code, for some reason it adds formated values to avdict. I would say it's not the layer to do formating like `%7"PRId32":%-7"PRId32` for rational and others
indecisiveturtle has quit [Ping timeout: 260 seconds]
TheVibeCoder has joined #ffmpeg-devel
realies93 has quit [Quit: ~]
mkver has joined #ffmpeg-devel
realies93 has joined #ffmpeg-devel
^Neo_ has quit [Read error: Connection reset by peer]
^Neo has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
mkver has quit [Ping timeout: 244 seconds]
<haasn>
How would people feel about removing hwframe formats from enum AVPixelFormat?
<haasn>
and instead adding them to a separate enum AVHWFormat
<haasn>
with AV_HW_FMT_CPU = 0 as the default option
<haasn>
of course, this would break all downstream clients unless we find some really clever backwards compatibility scheme
<haasn>
specifically filter negotiation would be tricky to support in a backwards compatible way
<TheVibeCoder>
go for it! more stuff breaks - more better
<haasn>
well, not too difficult - you can provide helpers to infer the correct sw/hw formats, make those helpers use the new fields if they are set, and otherwise fall back to the old fields
<haasn>
and use this helper for everything internally
System_Error has quit [*.net *.split]
hpkn has quit [*.net *.split]
<haasn>
nah, I don't think there is a solution that doesn't break all downstream
<haasn>
what if we split hwfmt and swfmt but only internally inside libavfilter
<haasn>
why are hwupload and hwupload_cuda separate filters? their implementations seem to be virtually identical
<haasn>
can somebody explain what I'm missing?
<TheVibeCoder>
hack
<jkqxz>
The cuda one always creates a new device context ex nihilo. I think it relies on some sort of global state to work, and that helps if you are too lazy to program the devices properly into the filter graph.
paulk has quit [Ping timeout: 260 seconds]
paulk has joined #ffmpeg-devel
paulk has quit [Changing host]
paulk has joined #ffmpeg-devel
<haasn>
jkqxz: but that's basically the exact same as hwupload=derive_device=cuda no
<haasn>
I mean I suppose we could do some logic like if (!strcmp(ctx->name, "hwupload_cuda")) { ... }
<haasn>
Lynne: the other checks for nvidia could be replaced by `p->dev_is_nvidia` right?
Kei_N_ has joined #ffmpeg-devel
Kei_N has quit [Ping timeout: 276 seconds]
Kei_N_ has quit [Remote host closed the connection]
Kei_N has joined #ffmpeg-devel
<BtbN>
haasn: hwupload_cuda still exists because otherwise you can't have one filterchain that has multiple hwuploads of different kinds
<BtbN>
If that can be achieved with the normal hwupload now, hwupload_cuda should probably be turned into an alias of hwlupload that automatically sets the neccesary flags
<BtbN>
But last time I checked there were still edge-cases where hwupload could not do what hwupload_cuda can
<BtbN>
Otherwise, it simply pre-dates the generic hwupload, in a lot of cases they're interchangeable
jamrial has joined #ffmpeg-devel
<jkqxz>
libavfilter supported that from the start. The filter works around the lack of being able to configure it in the ffmpeg utility only.
<BtbN>
It largely exists now to keep old commandlines alive, and because nobody is motived enough to sort out all the edge cases where it breaks
<BtbN>
imo right now in front of 8.0 is a great time to just get rid of it and make it an alias that forces hwupload into cuda mode
xvaclav has quit [Quit: Ping timeout (120 seconds)]
xvaclav has joined #ffmpeg-devel
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
minimal has joined #ffmpeg-devel
DauntlessOne498 has quit [Ping timeout: 244 seconds]
<haasn>
do I *have* to use ff_get_video_buffer() in a filter or could I allocate output frames myself?
<haasn>
maybe only if the downstream link doesn't have a get_buffer() implementation?
<haasn>
I suppose this is always a moot point, because filters can never *rely* on incoming frames being allocated by their own get_buffer() callback, simply because of metadata only filters that just passthrough frames (and hence have no get_buffer() impl either)
<haasn>
but that actually means get_buffer() is considerably less useful than it ought to be
<haasn>
seems like we first need to fix ff_default_get_video_buffer() to forward the get_buffer() call downstream
DauntlessOne498 has joined #ffmpeg-devel
<Lynne>
haasn: sure, get rid of the hardware pixfmts
<Lynne>
its always clumsy to work with them
<haasn>
how to not break all users
<Lynne>
_v2
<Lynne>
enum AVPixelFormat2 :)
<Lynne>
whilst you're at it, could you add fields to hold pointers to frame state for hardware (what currently goes into avframe->data)?
<Lynne>
the avframe->data fields could be set to host-mapped pointers if possible
<Lynne>
just daydreaming, that's all
<kasper93>
go for it! more stuff breaks - more better
<haasn>
Lynne: how to not require every single AVFrame user in history to update to new fields
<haasn>
we also need a mechanism for allowing hwcontexts to associate their own extra data with data buffers
<haasn>
e.g. a persistent mapping of the existing buffer, which would be tied to the lifetime of the AVBuffer
<haasn>
or, correction, Vulkan on nvidia requires this mechanism
<haasn>
on all other platforms mapping and unmapping a pointer is basically free
<Lynne>
err, what?
<Lynne>
how expensive is it to unmap?
<Lynne>
is that the reason why hwupload with vulkan is slow?
<BtbN>
hm, I might have to go on a typo squatting spree later
<BtbN>
codespell found so much stuff
<BtbN>
Also, reminder: If you have push access on Forgejo, please enable 2FS
<BtbN>
*2FA
<BtbN>
we will eventually enforce it
<BtbN>
It's just way too easy to compromise an account if all that in the way is a plain old password
System_Error has joined #ffmpeg-devel
indecisiveturtle has quit [Ping timeout: 245 seconds]
indecisiveturtle has joined #ffmpeg-devel
<Lynne>
*how* is it easy to compromise an account with a plain old password?
<haasn>
what if I store my 2FA token in the same password manager as the password
<BtbN>
All it needs is the password to get compromised in some way
<BtbN>
If you do that you have poor security practises
<BtbN>
Maybe YOU use a strong password that's always coming from a password manager, never types, anything.
<BtbN>
But sadly that's not the norm
<haasn>
so I should, what, carry around a second phone just to use it as a 2FA?
<BtbN>
2FA is absolutely essential
<BtbN>
In theory that would be the absolute best practise
<BtbN>
Though a bit over the top
<Lynne>
what's wrong with typing a long and secure password?
<BtbN>
That people don't use long and secure passwords, and re-use them left and right
<Lynne>
only that?
<BtbN>
"only" that?
<BtbN>
That's the main problem with passwords.
<Lynne>
are we yahoo users in the mid 90's?
<BtbN>
Again, maybe YOU have have good practises
<BtbN>
There is no way to enforce good practises
<BtbN>
But there is a way to enforce 2FA
<BtbN>
So 2FA will be enforced in the future
<BtbN>
GitHub even enforces 2FA for every user it deems somewhat important enough. And the barrier to be considered that is fairly low.
<Lynne>
tbh I feel like phones, which what everyone commonly uses, basically degrade 2fa to just a password
<Lynne>
every maker spies on phones and every agency has access
<Lynne>
sms 2fa is by far the worst, anyone can socially engineer a telecom company to switch your phone number and essentially gain full access to services which use the second factor of 2fa for password recovery
<BtbN>
And because it's not perfect that's an argument to not make stuff more secure at all?
<BtbN>
There is zero doubt about 2FA greatly improving account security
<BtbN>
Even if implemented poorly by the user
<Lynne>
I fail to see it as imperfect, more as unfortunately compromised
<BtbN>
And passwords are not "unfortunately compromised"? Could just remove passwords then, and only username is enough, since any agency knows your password anyway.
<BtbN>
Sorry, but that argument is ridiculous
<Lynne>
passwords are not unfortunately compromised, by design they're meant to only exist in plaintext form in the user's head
<Lynne>
again, I'll use 2fa, begrugingly
<Lynne>
but don't make the argument that they are more secure
<Lynne>
they're not
<Lynne>
assuming the user never reuses the password, and its a very long and secure password, and only ever types it on trusted machines
<BtbN>
You are completely missing the point
<BtbN>
_people have shit security practises_
<fjlogger>
[FFmpeg/FFmpeg] New comment on pull request #20070 avformat/movenc: look for the Intra profile flag before assuming a stream is AVC-Intra (https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20070) by kierank
<Lynne>
I know
<BtbN>
They re-use passwords left and right, write them in text-files on their google drive, everything
<haasn>
do we even need passwords with 2FA
<Lynne>
yes
<BtbN>
If you only do OTP, it's 1FA again, just not with a password :D
<Lynne>
like I said in my list of conditions
<Lynne>
passwords are secure to that extent
<kierank>
I used a shit password on forgejo in the beginning
<kierank>
because it was originally a test
<kierank>
I have changed it to a password from password manager
<BtbN>
If you do proper security practises, of course passwords would be much better
<BtbN>
But even with the best practises, shit can still go wrong
<BtbN>
and having a strong second factor that's not immediately accessible if your PC gets compromised is a huge upgrade
<BtbN>
The requirement is not "It's not enough to keep the NSA out, so it's useless"
<kierank>
and if you press it it's "schedule to merge"
<kierank>
and if you press it it's "scheduled to merge"
<BtbN>
The missing check is the missing approval
<kierank>
the sentences are contradictory
<BtbN>
They're not?
<kierank>
" All checks were successful
<kierank>
"
<kierank>
no they were not
<kierank>
the check for approval failed
<BtbN>
Yeah, that heading there seems to only count the CI runs
<BtbN>
If you hit approve, it should get auto merged now though
<fjlogger>
[FFmpeg/FFmpeg] Pull request review approved: [#20070 avformat/movenc: look for the Intra profile flag before assuming a stream is AVC-Intra](https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20070) by kierank
<fjlogger>
[FFmpeg/FFmpeg] Pull request merged: #20070 avformat/movenc: look for the Intra profile flag before assuming a stream is AVC-Intra (https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20070) by kierank
<haasn>
on my end perf is basically unchanged, maybe slightly faster with host mapping disabled
<fjlogger>
[FFmpeg/FFmpeg] Issue opened: #20073 Same videos (frame-to-frame wise) written by different applications produce different PSNR/SSIM/VMAF scores. (https://code.ffmpeg.org/FFmpeg/FFmpeg/issues/20073) by DimkaTsv
<fjlogger>
[FFmpeg/FFmpeg] Issue edited: #20073 Same videos (frame-to-frame wise) written by different applications produce different PSNR/SSIM/VMAF scores. (https://code.ffmpeg.org/FFmpeg/FFmpeg/issues/20073) by DimkaTsv
<kasper93>
BtbN: I think we should have custom bot, where we can control both what we show and how we show it
<kasper93>
current bot is bit... simple
<Lynne>
haasn: its a workaround
<haasn>
well firstly it's a debug option, that libplacebo also has, for exactly this reason (also because we still technically violate the spec by over-mapping)
<haasn>
that aside, if you have an idea of a different solution, I'm all ears
<BtbN>
kasper93: feel free to write one, I have too many other things to do
<BtbN>
the current one can probably be relatively easily extended to behave like that, but it needs to be written first
<kasper93>
sure thing, not expecting you have to do it, just making observation
<BtbN>
I want the bot to at the same time send E-Mails to the ML
<BtbN>
so it's on my agenda nevertheless, but it's one of the more involved things
<wbs>
an activity feed to mails, that can go to e.g. ffmpeg-devel, is probably nice too, so one can unfollow the repo overall. so then one could follow e.g. the mailing list for getting to know about new PRs to look at, and keep the feed of direct notifications from forgejo for the ones that I'm directly involved in
<wbs>
^ exactly :-)
<BtbN>
If you want a full unfiltered activity feed right to your inbox, just subscribe to notifications, we already have that
<BtbN>
Problem is, it's WAY too noisy to go straight to the ML
<wbs>
yeah, I don't want that
<wbs>
or isn't that pretty much what you get as long as you have the repo followed already as is?
<BtbN>
Forgejo calls it "Watching"
<wbs>
ah, that's the word yeah
<kasper93>
hmm, maybe I can ask mia about gh-mpv bot
DauntlessOne498 has quit [Remote host closed the connection]
indecisiveturtle has quit [Ping timeout: 265 seconds]
<BtbN>
Apparently I also need to rig up the CI to do windows-builds at least
<JEEB>
yea, you pretty quickly notice that the primary supported targets should be CI'd
<JEEB>
otherwise things fall between the cracks
<kasper93>
windows fate is ultra slow though, it's so annoying
<wbs>
cross compilation + wine is fairly quick, and covers many although not all aspects
<kasper93>
JEEB: do you know what's the deal with ffmpeg-fix_sub_duration_heartbeat ?
<kasper93>
I've seen your name in the last comment touching it
<kasper93>
it works 50/50 on CI, I cannot really reproduce locally though
<wbs>
kasper93: it's known to have race conditions since ffmpeg.c was made multithreaded, and afaik the race condition is a nontrivial design thing regarding how subtitles work
<BtbN>
I wouldn't even want to run fate yet, just compile
<BtbN>
cause this is a pure compilation error
<JEEB>
kasper93: it is something that I wrote to get live subtitles out when random access points happen (because various web subtitle stuff doesn't have a concept of "show until next")
<wbs>
yeah you can catch many issues just by compile testing
<BtbN>
is the output at least deterministic to flip-flop between a few known outputs, which are all valid?
<JEEB>
but yes, after ffmpeg.c was made multithreaded the exact timing of how far output has gotten will depend
<BtbN>
Cause that could still be tested
<wbs>
the other output is clearly invalid, with some subtitle line being repeated iirc
<JEEB>
but the repeat isn't overlapping ,right?
<BtbN>
Doesn't it just flat out sometimes emit an extra line?
<JEEB>
if it isn't overlapping it's being split because of a random access point being output at that point, before the actual end of the subtitle was found out
<BtbN>
It looked to me like it just went on for a bit longer
<JEEB>
basically, it depends on the latency of output to input
<BtbN>
i.e. one extra subtitle "frame" made it out
<wbs>
that's possible
jarthur has joined #ffmpeg-devel
<kasper93>
BtbN: this compilation error, was not caught by fate?
<kasper93>
I don't see any reds
<BtbN>
It only happens on gcc-15
<BtbN>
and clang 20+
<BtbN>
Also was only merged 19 hours ago, so good chance fate just didn't run on it yet
<kasper93>
I don't think we have jobs with those compilers
<kasper93>
wbs probably has nightly ;p
<wbs>
I have nightly clang yeah
<wbs>
which runs fate also just once nightly
<kasper93>
and regarding this subtitle testcase, I figured this might be race, but fate is running with -threads 1 and it still is an issue
<kasper93>
or ffmpeg.c has separate thread regardless
<kasper93>
?
<JEEB>
yea it has
<JEEB>
it's a latency thing
<kasper93>
thanks, seems to be known issue at least
<JEEB>
if we consider a subtitle line that is currently buffered by fix_sub_duration and waiting for its end, then if you have enough latency that before the next output random access point happens you get the end -> you get one subtitle line with the actual end. if your encoder did indeed output that random access point with not enough latency to get the end, you get a split of A-B,B-end
<JEEB>
in live streams you generally want to get subtitles out there
<JEEB>
if the web formats had a concept of "show until next", I would have preferred that
<JEEB>
and yes, I wasn't able to repro that test failure either. basically unless you can lock in the latency from input to output, the only way to fix it is to check that the correct lines are output across the correct time range, even if split
<JEEB>
since it's the same lines, they just get split into multiple continuing parts when the latency is small enough
<JEEB>
back before the fully threaded situation how far input was read compared to output was pretty stable
<jamrial>
BtbN: did you intend to include a workflow commit in 20075?
<BtbN>
jamrial: yeah
<BtbN>
Probably will split it out before merge tho
<BtbN>
Though it thematically fits the PR
<jamrial>
true
<BtbN>
wbs: your latest clang rc update broke a bunch of stuff btw., it seems to be buggy
<BtbN>
randomly fails compilation because "return from noreturn function", for a function that's clearly not noreturn
<JEEB>
as a fun note, I did - back when I developed fix_sub_duration_heartbeat - also look into whether it made sense to do that splitting on the muxer side (since f.ex. mp4 fragmentation already requires you to split subtitles, which is what's done in TTML-in-MP4), but alas there was no way to differentiate between AVPackets that had zero duration and unknown duration
<JEEB>
and thus it became part of fix_sub_duration stuff in ffmpeg cli
<wbs>
BtbN: can you post a reproducer somewhere and I can try to look into it
<BtbN>
It looks like a flat out compiler bug to me
<BtbN>
About to report it upstream
<wbs>
sure
<BtbN>
I have no minimal reproducer, it's the vvenc codebase
indecisiveturtle has quit [Ping timeout: 276 seconds]
fjlogger has quit [Remote host closed the connection]
fjlogger has joined #ffmpeg-devel
fjlogger has quit [Remote host closed the connection]
fjlogger has joined #ffmpeg-devel
minimal has joined #ffmpeg-devel
kurosu has quit [Quit: Connection closed for inactivity]
<nevcairiel>
how does a windows-only feature not work on windows, testing is dead eh
<TheVibeCoder>
hacks
<kasper93>
those are warnings, but I think BtbN build it with Werror, so it failed for him
<BtbN>
I don't build anything with Werror.
<BtbN>
That's vvenc putting Werror into their defaults
<BtbN>
nevcairiel: they didn't test it with gcc-15
<wbs>
BtbN: yeah that's what I meant - them building with -Werror by default is fragile as fuck
<wbs>
building with -Werror for an internal CI build or something like that is probably good, but imposing -Werror on any external use, with any potential future compiler, is always going to break
<BtbN>
even on a CI build you want ALL the warnings, not one and then an error
<kasper93>
not really, because people never look at CI output, unless it's red
<kasper93>
unless you have scripts that parses output for warnings, Werror is gating warnings pretty good
<kasper93>
of course it's not realistic to fix warnings for every compiler version, but having one clean baseline build is good to have
<kasper93>
even if sometimes annyoing that you need to fix some compiler bs
^Neo19 has joined #ffmpeg-devel
indecisiveturtle has joined #ffmpeg-devel
iive has joined #ffmpeg-devel
rvalue- has joined #ffmpeg-devel
<BtbN>
nono, the CI should still turn red when there's warning
<BtbN>
but not by means of Werror, but by means of a "new warnings" detector
rvalue has quit [Ping timeout: 248 seconds]
rvalue- is now known as rvalue
<BtbN>
wbs: is github-actions-bot angry at llvmbot for having a private E-Mail address? :D
<wbs>
BtbN: lol, good question
<wbs>
BtbN: apparently it's the cherrypicked commit which uses a github private email address - a little late to try to fix that at this point
<BtbN>
This got unearthed cause I added python3-pip to my builds base image (which is used for the CI on Forgejo), which invalidated all cache, and installed latest clang
BradleyS has quit [Quit: quit]
BradleyS has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
<jamrial>
BtbN: CI seems to be stuck?
<BtbN>
no? Looks happily working through jobs to me
<BtbN>
Lots of PRs and pushes
<jamrial>
ah
<jamrial>
it's taking a long time to start on a job for the latest pr
<BtbN>
The typo fixes are largely done by codespell writing out what it thought. I cross-checked it once already, but more eyes would definitely be good.
jamrial has quit []
jamrial has joined #ffmpeg-devel
<jamrial>
BtbN: vertical alignment in libavcodec/arm/ac3dsp_armv6.S is broken
<jamrial>
actually, you're breaking the function since you're changing an instruction :p
<BtbN>
Yeah, I noticed that too
mkver has quit [Ping timeout: 260 seconds]
<jamrial>
BtbN: also, dericed is correct in libavfilter/vf_signalstats.c
<jamrial>
it's an alias
jamrial has quit []
jamrial has joined #ffmpeg-devel
<jamrial>
just remove it so the script doesn't complain, and leave dave's name only
<BtbN>
I mean, it's also a valid word, if someone riced some code too much :D
<indecisiveturtle>
Lynne: Got the prores encoder working yesterday for slice aligned videos, now doing some bugfixes on various edge cases. Would it be okay to retouch the optimization questions after that
<BtbN>
I was wondering if I should make the spellcheck/linting commits into one commit per file/logical unit, but that'd have been an intense commit spam