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]
<haasn>
Lynne: can nvenc be used with the open source nvidia drivers?
<haasn>
or do I need to uninstall them and install the closed nvidia-compute-G06
<BtbN>
nvenc is an official nvidia API
<BtbN>
nouveau implements a pretty shoddy and half-broken vaapi interface, that's it
<haasn>
seems I get only [hevc_nvenc @ 0x5591ead4aa40] Cannot load libcuda.so.1
<haasn>
with nvidia-open-driver-G06-signed-cuda-kmp-longterm installed
<BtbN>
That's still the proprietary nvidia driver
<haasn>
hm
<BtbN>
only the kernel module is open source, and pretty much contains no notable code
mkver has joined #ffmpeg-devel
<haasn>
I think the problem is that nvidia-compute-G06 is only available from the NVIDIA repo, but it requires the nvidia-driver-G06-kmp-longterm driver (also from that repo)
<haasn>
and it conflicts with the open-driver-*-kmp-longterm from the main repo (openSuSE)
<haasn>
I will try to install it anyway (ignoring the dependency) and see what happens
<haasn>
different driver version also, 570.144 from the nvidia repo vs 570.124 from the opensuse repo..
<haasn>
they sensibly include a check to see if the kernel module and the client driver version are identical
<BtbN>
I don't know what "nvidia-compute-G06" is even supposed to mean
<BtbN>
Normally you just install the Nvidia driver, with either kernel module, and it works
witchymary has quit [Remote host closed the connection]
<BtbN>
sounds more like your distro royally messed up its packaging
<haasn>
I think they simply don't package cuda, or something
witchymary has joined #ffmpeg-devel
<haasn>
there's no package that provides libcuda.so.1, other than the one from the (unofficial) nvidia repository
<haasn>
but that one isn't compatible with the kernel module from the official repo
<BtbN>
libcuda.so.1 is part of the Nvidia driver
<BtbN>
not of any CUDA SDK or anything
<BtbN>
so if they don't have it, they botched their packaging
<Lynne>
haasn: the open source kernel modules have feature parity with the proprietary ones
<Lynne>
these days they package both when installing and ask you to choose
<Lynne>
I just use the .run files they distribute on a dirty machine I don't care about
<BtbN>
Using the .run file is a reallz bad idea if you care about that machine surviving the next system update
<BtbN>
it's famously known for making a huge mess that conflicts with package managers
<BtbN>
Is SuSE one of those "freedom purists", that cripple stuff to the point of uselessness?
<haasn>
nvm, I'm stupid, the nvidia repo actually provides all versions, I just had to install the 570.124 instead of 570.144 to make it match the kernel module
<BtbN>
Or why is CUDA missing?
<haasn>
BtbN: no, I actually think this is just a packaging bug
<haasn>
seems the reason I couldn't install it is because the repos are out of sync somehow
<haasn>
the nvidia repo packages only 570.124.04 but the kernel module is on 570.124.06 somehow
<BtbN>
So the repo is messed up?
<BtbN>
kernel and userland need to match exactly
<haasn>
for some reason it only affects the nvidia-open-driver-G06-signed-cuda-kmp-longterm driver
<haasn>
the nvidia-open-driver-G06-signed-kmp-longterm (missing -cuda) has the correct version
<haasn>
odd
<haasn>
I don't know why there are two
<haasn>
seems cuda works just fine with the non-cuda kernel driver
<haasn>
definitely some fishy packaging going on there
Grimmauld has quit [Quit: Client closed]
DodoGTA has quit [Remote host closed the connection]
DodoGTA has joined #ffmpeg-devel
<BtbN>
I prefer the Gentoo way of packaging the driver a lot
<BtbN>
exactly one package
<BtbN>
no chances for mismatches or chaos
<haasn>
Gentoo gets away with a lot by virtue of being a source based distro
<haasn>
but I'm very happy not to be using a source based distro for many, many other reasons
<haasn>
ramiro: one of my not-so-crazy ideas for how to approach subsampled conversions is to keep track of interchannel dependencies during optimization; and then at the end, if we have a subsampled pipeline where luma and chroma do not interdepend, we can dispatch them as two separate passes
uau has quit [Ping timeout: 276 seconds]
cone-313 has quit [Quit: transmission timeout]
uau has joined #ffmpeg-devel
<haasn>
(and in the case that the channels interdepend, we would have no choice but to upsample/downsample them anyway; this would be the case for e.g. RGB conversions)
minimal has joined #ffmpeg-devel
rvalue- has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 248 seconds]
rvalue- is now known as rvalue
beastd has joined #ffmpeg-devel
<jamrial>
jkqxz: you forgot to add full_range_flag
HideoSugai has joined #ffmpeg-devel
<jkqxz>
What do you mean? In the decoder avctx->color_range is set with the other fields.
<jkqxz>
Oh, the colour properties are in codecpar so the demuxer can also fill them in.
<jamrial>
jkqxz: i mean in cbs
<jamrial>
the decoder setting the relevant avctx value is fine, regardless of what the demuxer exported
<jkqxz>
Hmm, true. I need some real streams for this.
<jkqxz>
I had tried those properties through the metadata bsf but obvious cbs read and write match there.
cone-421 has joined #ffmpeg-devel
<cone-421>
ffmpeg Andreas Rheinhardt master:685f65852431: avcodec/magicyuvenc: Fix setting nb_slices
<cone-421>
ffmpeg Andreas Rheinhardt master:0e4d513f99de: avcodec/magicyuvenc: Restrict number of slice-planes to 256
<cone-421>
ffmpeg Andreas Rheinhardt master:01bb7421a0ee: fate/vcodec: Add MagicYUV tests
<cone-421>
ffmpeg Andreas Rheinhardt master:a6c2c463c76b: avcodec/magicyuvenc: Fix Huffman element probabilities
<cone-421>
ffmpeg Andreas Rheinhardt master:4e0a29d2f63c: avcodec/magicyuvenc: Only keep in Slice what is used
<cone-421>
ffmpeg Andreas Rheinhardt master:05bda9d3dfdd: avcodec/magicyuvenc: Store slice width and height
<cone-421>
ffmpeg Andreas Rheinhardt master:6e6e4e0e7bde: avcodec/magicyuvenc: Check in advance whether to encode a slice raw
<cone-421>
ffmpeg Andreas Rheinhardt master:e8b97b74ddf0: avcodec/magicyuvenc: Avoid intermediate buffer
<cone-421>
ffmpeg Andreas Rheinhardt master:3a90bbe4b76b: avcodec/magicyuvenc: Simplify padding slice
<cone-421>
ffmpeg Andreas Rheinhardt master:9c69e943546a: avcodec/magicyuvenc: Avoid PutBitContext for byte-aligned writes
<cone-421>
ffmpeg Andreas Rheinhardt master:1ab50cced5a0: avcodec/magicyuvenc: Calculate proper packet size in advance
<cone-421>
ffmpeg Andreas Rheinhardt master:cf288000e54b: avcodec/magicyuvenc: Switch to unchecked bytestream2 API
<cone-421>
ffmpeg Andreas Rheinhardt master:d42ba1384a03: avcodec/magicyuvenc: Avoid excessive logmessages
<cone-421>
ffmpeg Andreas Rheinhardt master:bad3f308d39d: avcodec/magicyuvenc: Hoist check out of loop
<cone-421>
ffmpeg Andreas Rheinhardt master:3acc3b0b5040: avcodec/dvbsubenc: Sanity check num_rects
<cone-421>
ffmpeg Andreas Rheinhardt master:3cf21217b506: avcodec/dvbsubenc: Check nb_colors before using it
<cone-421>
ffmpeg softworkz master:9e1162bdf145: avutil/hwcontext: Add item_name function for AVHWDeviceContext
mkver has quit [Ping timeout: 245 seconds]
<ramiro>
haasn: on subsampled yuv -> rgb, you can save the uv multiplications for multiple output pixels. so having separate upsample and linear steps makes things slower