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
<beastd> ePirat: Thanks for your long write up on Gitlab! I read it just now hours after sending my vote and reasons.
<beastd> Some of my points seem to line up with your details: state of the code base, ease of contributing, and skepticism about open core model
secondcreek has joined #ffmpeg-devel
iive has quit [Quit: They came for me...]
programmerjake has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
<programmerjake> I'm wanting to build a vanc smpte 436m to eia-608 conversion bitstream filter, however I also want to just invoke its internals directly from the mxf and mcc demuxers for backwards compatibility.
<programmerjake>  since the bitstream filters are in libavcodec but the demuxers are in libavformat, what should I do? just export a new ff_vanc_to_eia_608 function from libavcodec?
Gramner has joined #ffmpeg-devel
realies9 has quit [Read error: Connection reset by peer]
Traneptora has quit [Quit: Quit]
minimal has quit [Quit: Leaving]
cone-050 has quit [Quit: transmission timeout]
libra811 has joined #ffmpeg-devel
libra811 has quit [Client Quit]
libra811 has joined #ffmpeg-devel
TheVibeCoder has quit [Ping timeout: 276 seconds]
jamrial has quit []
libra811 has quit [Quit: Client closed]
jarthur_ has joined #ffmpeg-devel
jarthur_ has quit [Client Quit]
jarthur_ has joined #ffmpeg-devel
jarthur has quit [Ping timeout: 276 seconds]
jarthur_ is now known as jarthur
jarthur has quit [Read error: Connection reset by peer]
jarthur has joined #ffmpeg-devel
\\Mr_C\\ has quit [Remote host closed the connection]
acryo has quit [Remote host closed the connection]
acryo has joined #ffmpeg-devel
acryo has quit [Changing host]
acryo has joined #ffmpeg-devel
TheVibeCoder has joined #ffmpeg-devel
<Lynne> TheVibeCoder: its a stepped function!
<Lynne> blue is the rate of change in the dequant output per quantized input for HQ, purple is for non-HQ
<Lynne> those kinks I see in the red and (obscured) green line for dequant:quant graphs are real
grillo_0 has quit [Quit: The Lounge - https://thelounge.chat]
grillo_0 has joined #ffmpeg-devel
<TheVibeCoder> is that DC only?
<TheVibeCoder> this makes nosense
<Lynne> yes, DC only
<Lynne> but AC looks the same
programmerjake has quit [Quit: Client closed]
<Lynne> nevermind, AC looks like a rollercoaster
<Lynne> and I've already proven that DC quant is same as AC quant
<Lynne> and version 0 files lack any steps - https://0x0.st/8keD.png
<Lynne> green = version0 dc deq:q graph, blue - rate of change of deq per unit q
<Lynne> red = same for non-HQ, purple - rate of change of red
<Lynne> I'm guessing stairsteps may be a camera encoding artifact
System_Error has quit [Remote host closed the connection]
bcheng has quit [Ping timeout: 248 seconds]
bcheng has joined #ffmpeg-devel
ngaullier has joined #ffmpeg-devel
Teukka has quit [Read error: Connection reset by peer]
Kwiboo has quit [Quit: .]
Kwiboo has joined #ffmpeg-devel
Teukka has joined #ffmpeg-devel
Teukka has quit [Changing host]
Teukka has joined #ffmpeg-devel
cone-916 has joined #ffmpeg-devel
<cone-916> ffmpeg Lynne master:bedfb6eca402: aacenc_tns: clamp filter direction energy measurement
<cone-916> ffmpeg Lynne release/7.1:c2184b65d214: aacenc_tns: clamp filter direction energy measurement
<cone-916> ffmpeg Lynne release/7.0:f98f142da571: aacenc_tns: clamp filter direction energy measurement
khrbtxyz has quit [Ping timeout: 260 seconds]
MisterMinister has quit [Ping timeout: 268 seconds]
khrbtxyz has joined #ffmpeg-devel
jarthur has quit [Quit: jarthur]
System_Error has joined #ffmpeg-devel
microlappy has joined #ffmpeg-devel
microlappy has quit [Client Quit]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
linkmauve has left #ffmpeg-devel [not in this room]
linkmauve has joined #ffmpeg-devel
linkmauve has left #ffmpeg-devel [Error from remote client]
linkmauve has joined #ffmpeg-devel
cone-916 has quit [Quit: transmission timeout]
realies9 has joined #ffmpeg-devel
<haasn> I'm also a bit unhappy that we just map the entire buffer here
<haasn> for reference, libplacebo calculates how many bytes it actually needs for the transfer and only maps that much
indecisiveturtle has quit [Quit: indecisiveturtle]
BradleyS_ has joined #ffmpeg-devel
BradleyS_ has quit [Read error: Connection reset by peer]
BradleyS has quit [Read error: Connection reset by peer]
BradleyS has joined #ffmpeg-devel
indecisiveturtle has joined #ffmpeg-devel
cone-629 has joined #ffmpeg-devel
<cone-629> ffmpeg Niklas Haas master:053a113ad8f8: avutil/hwcontext_vulkan: don't over-map buffers with prior padding
jamrial has joined #ffmpeg-devel
Traneptora has joined #ffmpeg-devel
frankplow_ has joined #ffmpeg-devel
frankplow has quit [Ping timeout: 248 seconds]
frankplow_ is now known as frankplow
<fflogger> [newticket] guest: Ticket #11670 ([undetermined] Allow partial matching for audio input device names in DirectShow) created https://trac.ffmpeg.org/ticket/11670
<cone-629> ffmpeg James Almer master:307983b292ad: avformat/tls_schannel: add check for Windows 10 only types and defines
<cone-629> ffmpeg James Almer master:9c55f22ef234: avcodec/ffv1dec: don't add offsets to NULL pointers
beastd has quit [Ping timeout: 244 seconds]
<haasn> Is it safe to hard-code the assumption that the luma plane has idx 0? (for planar YUV formats)
<haasn> I don't see any formats existing any time soon that somehow put the chroma plane first, it would make no sense to do so
beastd has joined #ffmpeg-devel
<jamrial> yeah, should be safe
<jamrial> alpha will also always be idx 2 on planar formats. there can't be a hole so formats like YA are forced to be packed
<BtbN> There is A LOT of places that hardcode even stronger assumptions
<BtbN> like, plane 1 and 2 containing chroma
<jamrial> yeah, planes 1 and 2 will always be chroma, but chroma may not always be in planes 1 and 2
minimal has joined #ffmpeg-devel
<Lynne> wish we had a generic library that handled accessing pixels
<Lynne> bitpacked conversions too, but really something that handled reordering planar gbrp and planar rgb without needing to handle it yourself
<TheVibeCoder> pf2pf
<haasn> jamrial: I set idx_a = (desc->nb_components - 1)
<haasn> since it's always the last plane
<jamrial> for planar, yes
<haasn> plane_a = desc->comp[desc->nb_components - 1].plane rather
<haasn> Lynne: so, libswscale?
<haasn> I mostly just wish we had an AVPixFmtDescriptor that was more, well, descriptive (rather than *prescriptive*)
<TheVibeCoder> patch welcom
<TheVibeCoder> e
MisterMinister has joined #ffmpeg-devel
<Lynne> haasn: no, its too heavy, you don't want to do a conversion
<Lynne> you'd like something that just gives you a list of pointers to a region from a frame
<Lynne> if you're doing something like decoding
ccawley2011 has joined #ffmpeg-devel
ngaullie has joined #ffmpeg-devel
ngaullie has quit [Quit: Leaving]
DauntlessOne49 has quit [Ping timeout: 252 seconds]
ngaullier has quit [Remote host closed the connection]
cone-629 has quit [Ping timeout: 252 seconds]
thardin has quit [Ping timeout: 252 seconds]
quietvoid has quit [Ping timeout: 252 seconds]
quietvoid has joined #ffmpeg-devel
thardin has joined #ffmpeg-devel
<Lynne> TheVibeCoder: finally figured it out
<TheVibeCoder> cool
<Lynne> that single sample you had was the key
<Lynne> it was recorded via atomos via RAW bayer over HDMI, so I thought that it was linear and skipped doing colorspace conversion
<Lynne> the lumix s1ii for example outputs linear raw over HDMI was my single ref
<Lynne> but no, its very clearly log
<Lynne> and by some chance, the gamma conversion function I had matches exactly the gamma of the camera
<Lynne> so it ends up being perfectly linear, which confused me, but after I realized what was happening it made sense
<Lynne> this is the final quantization curve, top one is DC, bottom line is AC - https://0x0.st/8kx7.png
<Lynne> the DC curve is more aggressive since it has to map larger values
<Lynne> the kink at the bottom of the DC curve is from the gamma conversion routine
<Lynne> qscale is literally just a simple multiplication that changes the slope of the curve
<Lynne> I just need to figure out the constants now
<Lynne> I scoured the internet looking for more samples, but no, publically, there's literally just that single sample you had
<Traneptora> kasper93: just saw the ping about jxl
<Traneptora> investigating rn
<Traneptora> guessing it's some kind of overflow error, I think adding bounds checking might work
<Traneptora> stay tuned for patch (tm)
<kasper93> I don't remember what I said back then, but I think it eventually finishes, it just takes long
<kasper93> maybe can be fixed with sanity check for some values? dunno
<kasper93> thanks for looking into it
bsFFFFFF has joined #ffmpeg-devel
<Traneptora> kasper93: I figured out the issue. the problem is that the frame itself has an absolutely massive dimensions, and signals a permuted TOC, which requires an entropy stream with a crazy high number of elements
<Traneptora> because ANS can have far lower than 1bit per symbol, it just decodes the stream until it hits EOF, which takes a while
vriska has quit [Read error: Connection reset by peer]
vriska has joined #ffmpeg-devel
<Traneptora> basically the inital section of the stream is valid (except for the F16 thing, which is a red herring), but very questionable
<Traneptora> sanity check on frame width and height is the best way to do it, probably
<fflogger> [editedticket] Balling: Ticket #11418 ([undetermined] stack-buffer-overflow on libavcodec/aacenc_tns.c) updated https://trac.ffmpeg.org/ticket/11418#comment:5
<TheVibeCoder> ● Audio --aid=1 (wwvorbis 12ch 48000 Hz 673 kbps)
<TheVibeCoder> Stream #0:0: Audio: pcm_s24le (lpcm / 0x6D63706C), 48000 Hz, 92 channels, s32 (24 bit), 105984 kb/s
<TheVibeCoder> Lynne: i have more samples, aprn/aprh
<TheVibeCoder> do you have v0 aprn?
<Lynne> yeah, only the v0 sample you had
<TheVibeCoder> i gave you only aprh v0?
<Lynne> yeah, only that one
<Lynne> I don't think I need any more samples though
<Lynne> once I fix the DC quant, the stairsteps should disappear
lemourin has quit [Quit: Ping timeout (120 seconds)]
lemourin has joined #ffmpeg-devel
<TheVibeCoder> Lynne: https://0x0.st/8kge.7z
bsFFFFFF has quit [Ping timeout: 260 seconds]
<TheVibeCoder> its very good samples, big dynamic range
___nick___ has joined #ffmpeg-devel
___nick___ has quit [Client Quit]
___nick___ has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 244 seconds]
iive has joined #ffmpeg-devel
__nick__ has joined #ffmpeg-devel
___nick___ has quit [Ping timeout: 276 seconds]
TheVibeCoder has quit [Ping timeout: 268 seconds]
SuperFashi has joined #ffmpeg-devel
SuperFashi has quit [Client Quit]
SuperFashi has joined #ffmpeg-devel
__nick__ has quit [Ping timeout: 252 seconds]
realies9 has quit [Read error: Connection reset by peer]
realies9 has joined #ffmpeg-devel
iive has quit [Quit: They came for me...]