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 8.0 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
<averne>
indecisiveturtle: I'm looking at your encoder, do you have an example of a working invocation? I'm launching with this ./ffmpeg -init_hw_device vulkan -f lavfi -i testsrc2=size=1920x1080:rate=30:duration=10 -pix_fmt yuv422p10le -vf hwupload=derive_device=vulkan,format=vulkan -c:v prores_ks_vulkan -c:a copy -y test.mkv
<averne>
But I have some weird bug where the chroma plane seems overlaid on top of luma: https://files.catbox.moe/0i7u3j.jpg. FWIW ffv1_vulkan has the same issue so I think it's either from my command of from the transfer code
<averne>
Otherwise it seems to be working well :) about 2x as fast on my 6700xt than on my cpu (5800x)
ngaullier has quit [Remote host closed the connection]
<indecisiveturtle>
averne: I have been testing it mostly with ./ffmpeg -init_hw_device vulkan=vk:0,debug=0 -i <input> -filter_hw_device vk -vf format=yuv444p10,hwupload -c:v prores_ks_vulkan -y <output.mov>
kurosu has quit [Quit: Connection closed for inactivity]
<indecisiveturtle>
The command seems okay and format is from the ones supported hmm, not sure why it would overlay like that. I remember vulkan needed manual handling of some formats like nv2 cause they werent autoconverted but this is not that
AntwonTheDamaja has quit [Ping timeout: 250 seconds]
<averne>
indecisiveturtle: Thanks, working now. Seems like adding format= to the filterchain fixes it
<averne>
I'll see if I can break something ;)
<averne>
By the way I think you're missing vulkan/common.o in your deps. I tried a minimal config initially (without other vk stuff) and it failed to build
<indecisiveturtle>
Ah thanks I'll add it
<beastd>
JEEB: For mov fragmented TTML muxing I would say one week after last discussion (if not maintainer approved earlier). The changes are over 500 lines (test sample excluded) and touch multiple areas lavf/movenc and lavc/packet
<JEEB>
right'o. just wanted to check what the OK time range would be. since generally this patch set has not been too interesting to people :D the ttml in mp4 code in general is my earlier stuff, and this has gone on-off from review since something like 2022 :)
<JEEB>
just want to be cautious since while it's an actual production-used function, it also doesn't get too much interest :D
<beastd>
JEEB: if no more stuff is open and a week has passed, i would support you to push it (assuming you will stay around and act should problems with it arise)
<JEEB>
yea, I will be around. definitely not a passion patch, so that's why I'm in general /really/ careful with them :)
<JEEB>
(at least if the future ends up being similar to the past... 13 years?
ccawley2011 has joined #ffmpeg-devel
minimal has joined #ffmpeg-devel
<beastd>
JEEB: Yes, I have noticed that. Thanks for participating and contributing to FFmpeg for more than a decade.
<beastd>
JEEB: Also I want to especially mention that I have seen you helping users in #ffmpeg countless times
<beastd>
Damn, we are always talking about the "bad and the ugly"... feels really good to speak out about good things that are happening and are amazing :)
<JEEB>
hehe :) thanks, and yea. it's good to remember the positive bits.
<averne>
Lynne: I think you talked about using the radeon profiler profiler thing, how do you do that exactly? I'm trying with MESA_VK_TRACE=rgp MESA_VK_TRACE_PER_SUBMIT=1 RADV_THREAD_TRACE_BUFFER_SIZE=536870912 <ffmpeg command>, but the trace is missing all the juicy stuff
<Lynne>
what stuff?
<averne>
Ie instruction timings
<Lynne>
you get an approx percentage of function runtime, not cycles I think
<Lynne>
you need to use the profiler, and then from the profiler open the analyzer
<Lynne>
I think
<averne>
I mean I'm not getting anything, the tab is literally grayed out
<averne>
I'm on radv, is that why?
<Lynne>
no, radv has everything
<Lynne>
what tab?
<Lynne>
you downloaded the whole compiled RGP from github, right?
ccawley2011 has joined #ffmpeg-devel
<averne>
I used the AUR package. Seems like it pulls from the gpuopen site
<averne>
Tried on the github build, same thing
<averne>
Guess I'll have to boot windows
<Lynne>
make sure to select the right dispatch, not the wrong one
<Lynne>
you'll have a couple since we run compute in hwcontext_vulkan too
<averne>
Yeah I disabled the transfer code
<averne>
When I right click on the dispatch it says data unavailable for the instruction view /shrug
witchymary has joined #ffmpeg-devel
<averne>
Somehow it works for a vkcube capture. I'm probably doing something wrong
Kimapr_ has quit [Remote host closed the connection]
Kimapr has joined #ffmpeg-devel
<BtbN>
We don't support variable-length-arrays, do we?
<BtbN>
Hm, configure sets -Werror=vla, but I thought we were using something much more modern than C90 now
<BtbN>
Yeah, we compile with -std=c17. Why can't I use vla's?
<BtbN>
Hm, that -Werror=vla apparently wins
<BtbN>
Is there any reason we don't support this? Any compiler we care about should long support those.
indecisiveturtle has quit [Ping timeout: 245 seconds]
witchymary has joined #ffmpeg-devel
<jkqxz_>
VLAs are optional in C11, a compiler need not support them.
<jkqxz_>
More generally, you don't want to use them because the semantics are not helpful for ffmpeg cases.
<jkqxz_>
If an stack array is always small then just take the fixed size and avoid the messing around with VLAs.
<jkqxz_>
If a stack array can sometimes be large then you can't use a VLA because overflow will fail with undefined behaviour rather than as a well-defined allocation failure if you use the heap.
<jkqxz_>
(And remember that some platforms have very constrained stack sizes, never put anything large on the stack.)
jkqxz_ is now known as jkqxz
jluthra has quit [Server closed connection]
jluthra has joined #ffmpeg-devel
kasper93 has quit [Read error: Connection reset by peer]