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
<kasper93>
BtbN: I was looking around and apparently it should be possible to attach private key using a handle and prop CERT_NCRYPT_KEY_HANDLE_PROP_ID?
<kasper93>
have you tried this way?
<BtbN>
yes
<BtbN>
SChannel does not care, says no private key
<BtbN>
the literal only way I found that makes it work is to put the private key into the keystore and refer to it by name via its name in the store
<BtbN>
They do the exact same two things my code does from the look of it
<BtbN>
i.e. set CERT_NCRYPT_KEY_HANDLE_PROP_ID (which SChannel does not seem to care about), and store the key in the MS_KEY_STORAGE_PROVIDER by name, and then pass MS_KEY_STORAGE_PROVIDER + name to SChannel, which is how it finds the key
<BtbN>
i.e. that Qt code there also puts the unencrypted private key in plain-text into %APPDATA%
<kasper93>
what if you don't set the names at all? NCryptCreatePersistedKey at least says this way creates ephemeral key.
<BtbN>
It does, but then schannel fails to find it and returns an error
<BtbN>
I have tried every property related to the private key you can set on a cert by now
<BtbN>
and only referring to it by name in a store via CERT_KEY_PROV_INFO_PROP_ID works
<kasper93>
¯\_(ツ)_/¯
mkver has quit [Ping timeout: 276 seconds]
TheVibeCoder has quit [Ping timeout: 265 seconds]
TheVibeCoder has joined #ffmpeg-devel
Chagall has quit [Ping timeout: 260 seconds]
cone-934 has joined #ffmpeg-devel
<cone-934>
ffmpeg James Almer master:11d1b71c311d: doc/APIchanges: add missing entries for the recent changes
Chagall has joined #ffmpeg-devel
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 248 seconds]
ramiro has quit [Ping timeout: 248 seconds]
ramiro has joined #ffmpeg-devel
Chagall has quit [Ping timeout: 260 seconds]
jamrial has quit []
derpydoo has joined #ffmpeg-devel
derpydoo has quit [Client Quit]
mkver has joined #ffmpeg-devel
derpydoo has joined #ffmpeg-devel
Anthony_ZO has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
MisterMinister has quit [Ping timeout: 276 seconds]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
ubitux has quit [Ping timeout: 252 seconds]
ubitux has joined #ffmpeg-devel
<Lynne>
TheVibeCoder: got prores raw running flawlessly a few days ago, but its too slow
<JEEB>
nice
<Lynne>
writing a vulkan version just now, its a lot faster
<Lynne>
coeffs always being 12 bits is nice since you can losslessly put that in 16bit floats which GPUs love
<Lynne>
then you just have a simple matrix based float DCT and you write out floats, which the GPU converts to 16-bit ints during writeout
<TheVibeCoder>
you already had opencl kernels in binary in clear source code
<Lynne>
I ended up figuring out the issue without reverse engineering, so I didn't even look at it
<Lynne>
you can make a DCT 8x8 mult matrix in 3 lines of python though, or copy one from a JPEG decoder
<JEEB>
TheVibeCoder: sasuga apple, learned recently that they had the rights on the opencl name
<JEEB>
(was on my GTX 1080 packaging)
<JEEB>
thought they would no longer use opencl
<Lynne>
they have the trademark but they license it to khronos
<JEEB>
yea
<JEEB>
it was written like that and that's what I meant :)
<TheVibeCoder>
who owns vulkan trademark
<Lynne>
khronos does
<TheVibeCoder>
who owns ffmpeg trademark
<Lynne>
fabrice? I think
Guest87 has joined #ffmpeg-devel
<TheVibeCoder>
16bit floats, how many bits are reserved for exact number representation?
<TheVibeCoder>
when one compute only in 16bit floats
<Lynne>
4 bits
<TheVibeCoder>
really?
<Lynne>
not sure what the question is
<TheVibeCoder>
for 32bit floats number is 23
<JEEB>
mantissa and the other part?
<TheVibeCoder>
one bit is sign
<JEEB>
is that what you are talking about :D
<TheVibeCoder>
and rest is for exponents
<JEEB>
yea, exponent and mantissa
<TheVibeCoder>
i hope with 16bit float one can represent 12bit ints exactly
Guest87 has quit [Quit: Client closed]
<TheVibeCoder>
Lynne: when you sending patch to ml?
<Lynne>
when I get the GPU version working, C is really not fast enough, even with frame+slice threads
<Lynne>
I'm not putting the 12-bit ints directly into floats, but rather normalizing them (coeff/4096)
<kasper93>
wouldn't be easier to review and merge reference C only version first?
<Lynne>
I need to add a bunch of hooks and refactor the context
<TheVibeCoder>
the proresraw is slow, any DCT is slow, just use magicyuv, the apple products are barely realtime even with GPU
<TheVibeCoder>
the speed here is fine, just that debayering sws code is crappy slow
<JEEB>
how's the bayer format defined in prores raw? enum or something dumb like camera name string and the decoder has to have a mapping?
<Lynne>
cameras don't output magicyuv, they do either h264/hevc (not raw), prores (not raw), blackmagic raw (partial debayering), prores raw (lossily compressed raw), red raw (lossless raw, retarded patent trolls) and arriraw (uncompressed raw, on gear no one can buy, only rent)
<Lynne>
pretty sure the bayer order is fixed as bggr
<JEEB>
I was surprised arriraw actually had something spec-like on SMPTE
<JEEB>
ah, so prores raw specs it as bggr
<JEEB>
phew
<Lynne>
there is no prores raw spec, at least not a public one
<Lynne>
and it hasn't leaked to china yet, chinese companies like MAVO went with cinemadng
<Lynne>
which is raw, uncompressed, and is basically just one individual standard photo DNG per frame, and an XML file
<JEEB>
yea no spec, but at least if it seems hard-coded in the decoder
<Lynne>
though MAVO abandoned cinemadng years ago
<Lynne>
blackmagic also went with the cinemadng route, but then they came up with blackmagic raw because they too thought it was a really stupid idea
<Lynne>
oh, also, canon have their own canon raw format which is compressed lossless raw, and the only reason they're getting away with it is because they have a patent exchange agreement with red
<Lynne>
but canon are the fender or apple of the cinema/photo world, very expensive, years old, very contained and vertically integrated
<Lynne>
RF mount lens are very expensive, only canon make them, their sensors are fast but have barely 11 stops of dynamic range, and so extremely noisy you're lucky to get more than 9 in most cases
derpydoo has quit [Quit: derpydoo]
Guest93 has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
Guest93 has quit [Quit: Client closed]
Guest93 has joined #ffmpeg-devel
Guest93 is now known as sot
System_Error has joined #ffmpeg-devel
sot is now known as sott
IndecisiveTurtle has quit [Remote host closed the connection]
jamrial has joined #ffmpeg-devel
Chagall has joined #ffmpeg-devel
rvalue- has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 252 seconds]
rvalue- is now known as rvalue
microlappy has joined #ffmpeg-devel
vriska has joined #ffmpeg-devel
leo60228 has quit [Ping timeout: 272 seconds]
minimal has joined #ffmpeg-devel
Guest28 has joined #ffmpeg-devel
<TheVibeCoder>
send librempeg candidate logo!
<kierank>
TheVibeCoder: banhammer
<TheVibeCoder>
send real image logo!
<kierank>
TheVibeCoder: should be ffmpeg logo draped in pirate flag
<kierank>
ask ai to create
<TheVibeCoder>
no coins to have ai assistant
<kierank>
many are free
<JEEB>
yea, comfyui and look up stable diffusion models or something :P
witchymary has quit [Remote host closed the connection]
witchymary has joined #ffmpeg-devel
s55 has joined #ffmpeg-devel
<compnn>
yep
<compnn>
windows TLS certificates are baked into windows btw. only microsoft can fix it. i had to upgrade from windows vista when tls 1.2 wasnt supported in it hah
<BtbN>
the certificate can be perfectly in memory, never persisted, ironically
<BtbN>
it's specifically the bloody private key that has to be persisted, cause it's not marshalled along the certificate to their out-of-process, in-kernel, TLS stack