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
<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)
<Yalda>
To be fair, I would like to check it once more with antoher sample but I am not near it tonight
<Yalda>
I will send the latest updates tomorrow morning although probably I will not beat 8.0 cut
<Yalda>
(different sample from earlier :) )
<Yalda>
it is good news if true but i just want to know why
GewoonLeon has quit [Ping timeout: 252 seconds]
<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
<Yalda>
i have been testing all day sorry for the delayed updates
<jkqxz>
Lynne: Your cbs_vp9 change broke passthrough.
<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.
<Lynne>
which are the passthrough tests?
<jkqxz>
fate-cbs-vp9
<jkqxz>
You regenerated all the outputs to be wrong.
<jkqxz>
Does your VP9 decoder actually match the standard output?
<jkqxz>
That's a filtering change, so it might not propagate to something visible in most tests.
<Lynne>
yes, it does, all except the odd-dimension tests pass
<Lynne>
(the odd-dimension streams require cropping on the side of vulkan/drivers)
<Lynne>
is loop_filter_ref_deltas the only field that changes?
<jkqxz>
That was just one input. Not sure in general.
<jkqxz>
The infer() lines are not right. They are overwriting the values from the bitstream
<jkqxz>
Also update_ref_delta is a flag, -1 is not a good value to be writing to it.
GewoonLeon has joined #ffmpeg-devel
<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.
<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
<jkqxz>
Trying now.
<fflogger>
[editedticket] mfcc64: Ticket #11640 ([avfilter] Specific combination of timeclamp, fps, and count on showcqt causing crash) updated https://trac.ffmpeg.org/ticket/11640#comment:6
<philipl>
Lynne: So not sure what to say. My vulkan decode is completely busted right now on Blackwell. I'd swear it worked when I first put the hardware in but that might be a false memory. Immediately gets "Unable to submit command buffer: VK_ERROR_DEVICE_LOST"
<Lynne>
philipl: git master too?
<philipl>
This is latest build with your change to disable threading
<philipl>
Lynne: vulkan validation produces a long stream of errors. Can it tell us anything meaningful right now?
<Sean_McG>
I tried that command with an H264-encoded MPEG4 file on my Radeon and it worked OK, so I guess this might be particular to Intel?
<Sean_McG>
actually, which version of Vulkan do you have? I'm on Debian stable (bookworm) which has 1.3.239.0
<philipl>
This is nvidia
<Sean_McG>
ahhh sorry, my brain for some reason connected Blackwell to Intel
<philipl>
Lynne: https://0x0.st/8FSB.txt I assume that all the validation warnings about image views and profile lists are noise, based on what you've said in the past. But then it complains about the command buffer submission and then we get the submission error.
<BtbN>
kasper93: I've bumped the base image to 25.10 now, from 24.04, maybe lld 20 fixed whatever 18 was unhappy about. Now only need to wait 4h or whatever it takes CI to rull a full set of new images from 0
<kasper93>
you are not using llvm-mingw from wbs there?
<kasper93>
it should ship own lld, no?
<BtbN>
It's crosstools-ng
<kasper93>
ah, it's not llvm version
<kasper93>
nvm then
<BtbN>
A lot of packages hate being built with clang
<BtbN>
winarm64 is using it, and I had to disable a bunch of stuff simply cause it does not configure or build with clang
<kasper93>
so, ff 8.0 is not major api bump?
<BtbN>
It should be? Otherwise it'd be 7.2
<kasper93>
that's my understanding
<kasper93>
michaelni did minor bump only in release commits though
<kierank>
Lol we're doing plugins now
welder has quit [Quit: WeeChat 3.8]
welder has joined #ffmpeg-devel
<TheVibeCoder>
kierank: ban self
mkver has quit [Ping timeout: 244 seconds]
<michaelni>
BtbN, we have never bumped major during release branching.
<BtbN>
Never observed it. So it's just done later?
<michaelni>
people always discussed and then someone bumped on master
<michaelni>
if people want major to be bumped, its no big deal, people can bump major now on master and we just fast forward release/8.0
<michaelni>
this is something people / the community must decide, personally i never saw the sense in frequent major bumps
<kasper93>
could we merge #20182 to unblock FATE?
<michaelni>
also I clearly said "I intend to create the release/8.0 branch in the next 1-2 weeks", so if people want a major bump in this release why do they raise this now after the branch is made ?
<kasper93>
I was only asking. I don't want to impose any ideas to versioning
<michaelni>
iam not sure why a major version change on ffmpeg would need to imply a major version change on the libs
<BtbN>
Hm, I had kinda assumed that's the default
<michaelni>
about 20182, if its reviewed, sure should be applied
ccawley2011 has joined #ffmpeg-devel
microlappy has joined #ffmpeg-devel
<michaelni>
send a RFC to the ML about the 8.0 and bumping thing
<TheVibeCoder>
do it with AI help
<michaelni>
Its really just a question what the community prefers, the release isnt made yet
<BtbN>
When was the large major bump? It feels like it's about time for one.
<BtbN>
I also feel like it's either now or not for a long while, cause doing a major API bump in an 8.x release will confuse people
<michaelni>
yes
<michaelni>
do we need a bump ?
<michaelni>
actually kasper93 did you check the versions ?
microlappy has quit [Remote host closed the connection]
<toots5446>
Hi! michaelni: what's the recommended way to deal with the API bump related to ogg/flac and ogg/opus? I'm not sure if I did it right.
<toots5446>
The commit changing ogg/ogg/flac is 2fb6416dd06b5e66eca035458bb91b7956760d7c and ogg/opus is 9c5ed57f94a271b07176f068ff7c07b3139f7a3d both commited on May 6th.
<toots5446>
Shall I add a API change entry retrospectively for them? Or shall it be simply done at the top of the changelog?
ccawley2011 has quit [Read error: Connection reset by peer]