2025-03-03 01:04
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
00:42
<
kasper93 >
btw. is this normal to rush merge everything "before branching release"?
00:43
<
kasper93 >
I though with forgejo at least could wait for CI to pass.
00:49
<
Lynne >
nah, we rush stuff in every time
00:50
<
Lynne >
we have like 1 release a year these days, so /shrug
01:11
iive has quit [Quit: They came for me...]
01:51
<
kierank >
TIL about fate-build
02:03
<
Yalda >
kasper93: so far 1 sample that is supposed to have this issue, it does not appear to have the issue. I wonder if it is possible our parser is handling it already? (mlp_parser.c looks like it has logic dealing with this)
02:03
<
Yalda >
To be fair, I would like to check it once more with antoher sample but I am not near it tonight
02:05
<
Yalda >
I will send the latest updates tomorrow morning although probably I will not beat 8.0 cut
02:06
<
Yalda >
(different sample from earlier :) )
02:14
<
Yalda >
it is good news if true but i just want to know why
02:18
GewoonLeon has quit [Ping timeout: 252 seconds]
02:26
<
Yalda >
alternatively I can mark the demuxer experimental and send it when i wake up, and can continue to work on seeking before the release and backport when fixed
02:32
<
Yalda >
i have been testing all day sorry for the delayed updates
02:34
GewoonLeon has joined #ffmpeg-devel
02:46
GewoonLeon has quit [Ping timeout: 276 seconds]
02:53
^Neo has quit [Quit: Client closed]
03:25
jamrial has quit []
03:35
ShadowJK has quit [Ping timeout: 260 seconds]
04:45
mkver has joined #ffmpeg-devel
04:55
mkver has quit [Ping timeout: 248 seconds]
05:16
TheVibeCoder has joined #ffmpeg-devel
06:41
GewoonLeon has joined #ffmpeg-devel
06:45
<
TheVibeCoder >
Lynne: when in decoder you assign different profile?
06:45
<
TheVibeCoder >
*where
06:45
<
Lynne >
TheVibeCoder: I do it in the parser
06:46
<
Lynne >
should've done it in the decoder too, but forgot about it
06:56
GewoonLeon has quit [Quit: GewoonLeon]
07:01
<
frankplow >
kierank: Jealous
07:20
<
jkqxz >
Lynne: Your cbs_vp9 change broke passthrough.
07:21
<
jkqxz >
The point of the tests there is that the bitstream passes through unchanged; you should absolutely not be regnerating the test output with something different.
07:24
<
Lynne >
which are the passthrough tests?
07:25
<
jkqxz >
fate-cbs-vp9
07:25
<
jkqxz >
You regenerated all the outputs to be wrong.
07:30
<
jkqxz >
Does your VP9 decoder actually match the standard output?
07:31
<
jkqxz >
That's a filtering change, so it might not propagate to something visible in most tests.
07:31
<
Lynne >
yes, it does, all except the odd-dimension tests pass
07:32
<
Lynne >
(the odd-dimension streams require cropping on the side of vulkan/drivers)
07:33
<
Lynne >
is loop_filter_ref_deltas the only field that changes?
07:33
<
jkqxz >
That was just one input. Not sure in general.
07:34
<
jkqxz >
The infer() lines are not right. They are overwriting the values from the bitstream
07:34
<
jkqxz >
Also update_ref_delta is a flag, -1 is not a good value to be writing to it.
07:37
GewoonLeon has joined #ffmpeg-devel
07:40
<
jkqxz >
Hmm, you've embedded the propagation of the deltas inside the parsing and that messes with the bistream values. I think it would be better separate - the update flags are exactly what you need to know what to update.
07:51
<
Lynne >
if you have something in mind and time, could you write a patch up? I won't be able to take a look at it for another 7 hours
07:52
<
jkqxz >
Trying now.
08:09
<
jkqxz >
(Looks more sensible as a diff against state before you patch rather than after.)
08:23
<
jkqxz >
michaelni: Oops, didn't notice that the 14-bit formats weren't filled (and there are no streams to test). That seems fair.
08:24
<
jkqxz >
Maybe request_sample on the 14-bit 4:4:4:4 case rather than silently rejecting it?
08:25
<
jkqxz >
(Note that 0 for 4:2:0 is already rejected by CBS, so chroma_format_idc can't be 1 when you get there.)
09:57
_whitelogger has joined #ffmpeg-devel
10:16
mateo` has joined #ffmpeg-devel
10:39
GewoonLeon has quit [Quit: GewoonLeon]
10:39
GewoonLeon has joined #ffmpeg-devel
10:43
GewoonLeon has quit [Client Quit]
10:44
GewoonLeon has joined #ffmpeg-devel
10:47
GewoonLeon has quit [Remote host closed the connection]
10:48
GewoonLeon has joined #ffmpeg-devel
10:51
GewoonLeon has quit [Client Quit]
10:53
GewoonLeon has joined #ffmpeg-devel
10:54
GewoonLeon has quit [Client Quit]
10:55
GewoonLeon has joined #ffmpeg-devel
10:59
GewoonLeon has quit [Client Quit]
10:59
GewoonLeon has joined #ffmpeg-devel
11:02
GewoonLeon has quit [Client Quit]
11:03
GewoonLeon has joined #ffmpeg-devel
11:05
GewoonLeon has quit [Remote host closed the connection]
11:05
lemourin has quit [Ping timeout: 252 seconds]
11:05
GewoonLeon has joined #ffmpeg-devel
11:06
GewoonLeon has quit [Client Quit]
11:06
GewoonLeon has joined #ffmpeg-devel
11:13
lemourin has joined #ffmpeg-devel
11:19
lemourin4 has joined #ffmpeg-devel
11:19
lemourin is now known as Guest4785
11:19
lemourin4 is now known as lemourin
11:20
Guest4785 has quit [Ping timeout: 240 seconds]
11:24
lemourin has joined #ffmpeg-devel
11:29
lemourin2 has joined #ffmpeg-devel
11:29
lemourin is now known as Guest3847
11:29
lemourin2 is now known as lemourin
11:32
Guest3847 has quit [Ping timeout: 276 seconds]
11:57
ngaullier has joined #ffmpeg-devel
11:59
lemourin has joined #ffmpeg-devel
12:03
Kei_N_ has joined #ffmpeg-devel
12:03
<
TheVibeCoder >
ffmpeg is full of regressions and bugs
12:05
ngaullier has quit [Ping timeout: 248 seconds]
12:06
Kei_N has quit [Ping timeout: 248 seconds]
12:40
<
Lynne >
jkqxz: looks fine
12:40
<
Lynne >
could you submit a PR on code.ffmpeg.org?
12:46
<
BtbN >
kasper93: I'm building a set of new CI base images with mold in them. Maybe that speeds up those ridiculous link-times
13:02
<
Lynne >
--disable-stripping may help a little too
13:09
<
BtbN >
Lynne: the problem is that I just used my builds images, cause they already have everything under the sun. But as static libs
13:09
<
BtbN >
so linking takes bloody forever
13:09
<
BtbN >
Might need to have to roll a spinoff set of images with the same stuff but shared libs
13:09
lemourin4 has joined #ffmpeg-devel
13:09
lemourin has quit [Killed (zirconium.libera.chat (Nickname regained by services))]
13:09
lemourin4 is now known as lemourin
13:11
lemourin has quit [Client Quit]
13:24
lemourin has joined #ffmpeg-devel
13:28
<
BtbN >
It's not using LTO.
13:28
<
BtbN >
And also not using clang.
13:28
<
BtbN >
With LTO linking takes over an hour
13:28
<
Lynne >
no, but you can cache linking
13:28
<
Lynne >
and thinlto is really fast
13:29
<
BtbN >
But it's not even doing LTO
13:30
<
Lynne >
I know, but perhaps LTO with caching may be faster
13:30
<
BtbN >
LTO without cachine takes way over an hour, so that's even worse
13:30
<
BtbN >
Keep in mind this is statically linking _everything_, every single library. So LTO is also incredibly brittle
13:31
<
Lynne >
I know, but perhaps it can be worth it to experiment
13:31
<
Lynne >
IIRC kernel devs run thinlto when bisecting because it can be cached
13:32
<
BtbN >
I have already experienced with LTO
13:32
<
BtbN >
and deemed it not worth the trouble
13:32
<
BtbN >
takes forever, defers a lot of errors from other projects to only pop up during link-time of FFmpeg, and breaks every other day
13:33
<
BtbN >
The proper way to speed this up is to not use static libs
13:38 ___nick___ has joined #ffmpeg-devel
13:39
ShadowJK has joined #ffmpeg-devel
13:39
microlappy has joined #ffmpeg-devel
13:39
<
kasper93 >
thinlto can be fast, becasue compile time are very fast and link is cached. but not sure if I ever seen it faster than normal link
13:40
<
kasper93 >
though not like I'm benchmarking it on every project
13:41
<
kasper93 >
(I wouldn't expect it help in ffmepg case tho)
13:42
<
kasper93 >
BtbN: I use lld, but yes, using gnu ld can be painful
13:42
<
BtbN >
Keep in mind caching itself is also a cost on CI
13:43
<
BtbN >
it has to be downloaded first, and in this case it can easily be gigabytes worth of cache
14:01
microlappy has quit [Remote host closed the connection]
14:02
<
kasper93 >
though using lld is giving nice speed-up already. I never compared directly to mold, but should be even faster
14:02
microlappy has joined #ffmpeg-devel
14:09
<
BtbN >
mold also does not support windows, so it's kinda out anyway
14:14
<
kasper93 >
searching `mold windows` is not the right way
14:16
<
BtbN >
There was a fork od mold for Windows at some point, called "sold"
14:16
<
BtbN >
yes, that's fun to google for as well
14:17
microlappy has quit [Remote host closed the connection]
14:17
<
BtbN >
Apparently its focus was apple stuff though, and apple fixed their linker, so it was abandoned?
14:18
<
BtbN >
lld doesn't work either: ld.lld: error: undefined symbol: svt_av1_enc_init_handle
14:18
<
BtbN >
bfd finds the symbol fine
14:18
microlappy has joined #ffmpeg-devel
14:21
<
kasper93 >
hmm, I use lld with svtav1 and works for me
14:21
<
BtbN >
With a static one?
14:21
<
kasper93 >
it's shared build though
14:21
<
BtbN >
doing static builds unearthes a lot of weirdness and build system sloppyness, cause it's not well tested
14:21
<
BtbN >
weird though how bfd is happy, and just switching to lld breaks it
14:22
<
kasper93 >
true, mostly you find those dllimport/dllexport issues
14:22
<
kasper93 >
speaking of we still haven't merged libplacebo fix for that
14:22
microlappy has quit [Remote host closed the connection]
14:22
<
BtbN >
I'll just try to spin some images which are shared
14:22
<
BtbN >
it should speed up CI a lot
14:23
<
BtbN >
We don't plan to release builds from them anyway
14:23
microlappy has joined #ffmpeg-devel
14:23
<
kasper93 >
yeah, shared make sense
14:23
<
another| >
BtbN: sold was the paid version of mold. But that apparently didn't work out
14:24
microlappy has quit [Remote host closed the connection]
14:25
microlappy has joined #ffmpeg-devel
14:26 ___nick___ has joined #ffmpeg-devel
14:27 ___nick___ has quit [Client Quit]
14:28
<
kasper93 >
BtbN: if it's a problem, we can for now enable fate-build on linux jobs only
14:28
<
BtbN >
You mean the ones that don't have all the fat deps
14:28
<
BtbN >
that should be fine, yeah
14:28
<
BtbN >
and doesn't take half an hour
14:28
microlappy has quit [Remote host closed the connection]
14:29 ___nick___ has joined #ffmpeg-devel
14:35
<
kasper93 >
is this only an issue with svtav1?
14:35
<
kasper93 >
this can be also fixed for mold
14:37
<
BtbN >
Well, it's the first thing it trips over
14:37
<
BtbN >
no idea what would crop up after that one is fixed
14:38
<
BtbN >
but identifying why one linker is upset but the other isn't sounds like an annoying task
14:46
<
kasper93 >
it generally is obvious, after you look at source code, generally there is something weird done
14:46
<
kasper93 >
though it's not our job to fix others bugs
14:46
<
BtbN >
well, it works with bfd, so it can't be that weird
14:53
<
kasper93 >
have you tried gold? I know it's deprecated, but maybe this do the trick for now
14:54
<
BtbN >
gold mis-links the whole thing and it then crashes randomly at runtime
15:01
<
JEEB >
yea, gold is just so little used during the past XYZ years