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
<Lynne>
linkmauve: the validation layer says nothing
secondcreek has quit [Quit: secondcreek]
derpydoo has joined #ffmpeg-devel
thilo has quit [Ping timeout: 244 seconds]
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
thilo has joined #ffmpeg-devel
iive has quit [Quit: They came for me...]
HideoSugai has quit [Ping timeout: 240 seconds]
secondcreek has joined #ffmpeg-devel
minimal has quit [Quit: Leaving]
zsoltiv_ has quit [Quit: Left]
zsoltiv has quit [Ping timeout: 252 seconds]
zsoltiv_ has joined #ffmpeg-devel
zsoltiv has joined #ffmpeg-devel
<Lynne>
linkmauve: what are you trying to do?
<Lynne>
VK_COMMAND_POOL_CREATE_RESET_COMMAND_BUFFER_BIT allows resetting of buffers via a begin call
jamrial has quit []
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 252 seconds]
cone-663 has joined #ffmpeg-devel
<cone-663>
ffmpeg llyyr master:db0e4eb84583: avcodec/vulkan_{av1, h264, hevc}: demote per frame logs to AV_LOG_DEBUG
MisterMinister has quit [Ping timeout: 244 seconds]
<linkmauve>
Lynne, oops, I hadn’t noticed that flag, so without it a command buffer can’t ever be re-recorded, and with it vkResetCommandBuffer() is unneeded? That makes vkResetCommandBuffer() quite useless doesn’t it?
<Lynne>
not quite, if something happens between you starting to record and you want to cancel it, you can use reset
<Lynne>
but yeah
<linkmauve>
Alright thanks, I’ll fix my driver then.
<linkmauve>
And maybe fix Gstreamer to avoid that extra reset call.
<Lynne>
what driver are you working on?
<linkmauve>
A from-scratch driver layering above V4L2, so that Vulkan video can also be used on embedded Linux.
<Lynne>
sounds miserable
<Lynne>
can the hardware not be used like any other hardware, with userspace sending command buffers to the kernel via ioctls
<linkmauve>
That’s exactly what V4L2 is.
<linkmauve>
And so far I’m having fun. :)
Grimmauld has joined #ffmpeg-devel
kepstin has quit [Remote host closed the connection]
kepstin has joined #ffmpeg-devel
derpydoo has quit [Quit: derpydoo]
<Lynne>
linkmauve: but it isn't, is it?
<Lynne>
it keeps state, handles the refs for you, etc.
<linkmauve>
No, you’re thinking about the old m2m API, with the stateless API there is, well, no state.
<frankplow>
jkqxz Lynne: Late reply but I’d have thought libaom can’t be agnostic to chroma sample positions because of CfL
<frankplow>
I suppose it’s not built into the codex like for VVC because the model parameters are explicitly signaled IIRC, but libaom still needs to be aware of
<frankplow>
codec*
<Lynne>
no, the codec does not ask of implementations to care
<jkqxz>
It can be ignored, it just makes CfL less good and you pick other things more.
<jkqxz>
I recall there have been some fixes in AVM around improving those sorts of tools in non-4:2:0 cases, but I don't remember the details.
<jkqxz>
(Whether AV1 was wrong or whether later cross-component things got added which didn't think about it.)
<Lynne>
it wouldn't really improve results all that much if encoders correctly interpolated the luma to generate a good ref for the chroma
<linkmauve>
Lynne, I’m only aware of Qualcomm still using the old stateful API, but I wonder if it could get moved over the stateless one.
<linkmauve>
But first, I’m testing with AllWinner and Verisilicon.
<jkqxz>
That interpolation has to be a normative part of the codec, though.
<Lynne>
yup
<Lynne>
linkmauve: aren't qualcomm the nvidia of the SoC world?
<Lynne>
in other words, an unholy combination worse than pineapple on pizza?
<linkmauve>
I’d say Nvidia is the Nvidia of the SoC world, but yeah I could see the similarities. :D
<Lynne>
fair point, the jetson uses an API hybrid between v4l2 and cuda
<kurosu>
frankplow: right, CfL is what I meant by AV1/AV2 tools. That aspect had already been considered for HEVC though
<kurosu>
(also: interlacing shits chroma location on a per field basis)
<frankplow>
kurosu: Ah I didn't see your message
<kurosu>
np, didn't want to name it, but jkqxz should be aware
<frankplow>
In ECM, around half the chroma gain disappears if you do something which screws up the chroma sample positioning I believe. Model derivation goes skewiff as well as the prediction there though.
<kurosu>
JCTVC-I0188 was for HEVC's LM
rvalue has quit [Read error: Connection reset by peer]