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 6.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
<kierank>
22:07:24 <• ubitux> ok i found the fix for prores
<kierank>
Was it padding?
<ubitux>
kierank: nah, badly terminated bitstream
<ubitux>
patch is on the ml
<kierank>
Ah
<kierank>
There is an FFmpeg M1 if you want it
<ubitux>
m1 doesn't have the issue, only m2/m3
<kierank>
Ah your commit message implies M1 does
<kierank>
Nice wokr
<kierank>
Work
<ubitux>
"This commit fixes glitchy playbacks on QuickTime with M2 and M3 hardware (but not M1 for some mysterious reason)"
<ubitux>
did i miswrite? 🤔
rvalue has quit [Ping timeout: 260 seconds]
<kierank>
It's ambiguous whether not applies to the fix or the glitch
<ubitux>
mmh ok
<ubitux>
feel free to propose a better wording, english bad
<ubitux>
BBB: still unclear to me what to do about the quantization heuristics; Lynne seemed to say that aw approach should be better in theory (ks is also significantly more complex due to prediction being done in advance and duplication of code)
mkver has quit [Ping timeout: 260 seconds]
rvalue has joined #ffmpeg-devel
kasper93 has quit [Ping timeout: 256 seconds]
<Lynne>
ubitux: do you want to see the encoder fully optimized or just working well enough to be useful?
<ubitux>
tbh i really don't give a damn, just tell me what to do and i'll execute myself
<Lynne>
if the latter, just targetting a constant bitrate through every slice's encoding would be good enough
<Lynne>
generally prores is expected to be CBR afaik
<Lynne>
add a setting to reencode if the budget is overshot to keep strict CBR
epony has quit [Remote host closed the connection]
epony has joined #ffmpeg-devel
<ubitux>
if you ask me to make a mix of both i won't though
<ubitux>
if you ask me to pick i can do that :D
feiw2 has quit [Ping timeout: 256 seconds]
feiw2 has joined #ffmpeg-devel
<Lynne>
it's aw, I think
<ubitux>
ok well then i guess i'll send a patch to drop ks after importing the remaining useful bits and i'll be sure to mention that you take responsibility for it :D
<Lynne>
sure, feel free to
thilo has quit [Ping timeout: 256 seconds]
thilo has joined #ffmpeg-devel
navi has quit [Quit: WeeChat 4.0.4]
lemourin has quit [Read error: Connection reset by peer]
lemourin1 has joined #ffmpeg-devel
lemourin1 is now known as lemourin
jamrial has quit []
HarshK23 has joined #ffmpeg-devel
elastic_dog has quit [Ping timeout: 260 seconds]
elastic_dog has joined #ffmpeg-devel
MisterMinister has joined #ffmpeg-devel
\\Mr_C\\ has quit [Remote host closed the connection]
Mista_D has joined #ffmpeg-devel
MisterMinister has quit [Ping timeout: 256 seconds]
tmm1_ has quit [Ping timeout: 252 seconds]
tmm1 has joined #ffmpeg-devel
AbleBacon has quit [Read error: Connection reset by peer]
epony has quit [Remote host closed the connection]
Mista_D has quit [Remote host closed the connection]
Krowl has joined #ffmpeg-devel
Raz- has quit [Quit: Leaving]
mkver has joined #ffmpeg-devel
tmm1_ has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
tmm1 has quit [Ping timeout: 245 seconds]
tmm1_ has quit [Ping timeout: 246 seconds]
Raz- has joined #ffmpeg-devel
philipl has quit [Remote host closed the connection]
philipl has joined #ffmpeg-devel
tmm1 has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
kasper93 has joined #ffmpeg-devel
navi has joined #ffmpeg-devel
lemourin7 has joined #ffmpeg-devel
lemourin is now known as Guest874
Guest874 has quit [Killed (silver.libera.chat (Nickname regained by services))]
lemourin7 is now known as lemourin
navi has quit [Ping timeout: 260 seconds]
navi has joined #ffmpeg-devel
mkver has quit [Ping timeout: 246 seconds]
kasper93 has quit [Ping timeout: 256 seconds]
Teukka has quit [Read error: Connection reset by peer]
dellas has joined #ffmpeg-devel
Teukka has joined #ffmpeg-devel
Teukka has quit [Changing host]
Teukka has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 276 seconds]
jamrial has joined #ffmpeg-devel
rvalue has joined #ffmpeg-devel
jamrial has quit []
jamrial has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
kasper93 has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
navi has quit [Ping timeout: 245 seconds]
navi has joined #ffmpeg-devel
<BBB>
ubitux: I believe from a compression pov, we typically compare a vs b and show that a is better than b in terms of bitrate vs quality [..] vs complexity vs whatever other metric you care about to differentiate
<BBB>
so dropping because lynne says so isn't a great metric, but because compression is identical but aw is less code is fine
<BBB>
not saying lynne is wrong, just that there's more objective metrics out there 8)
<Lynne>
I never said it's not optimal
<Lynne>
it's suboptimal by all accounts
<Lynne>
but it's prores, where you care more about CBR than the actual quality
<Lynne>
and ubitux said he just didn't care about it that much
<BBB>
but compression and quality-per-bit is still a goal, right? I mean, it would be silly not to
<Lynne>
it's prores, if you need more quality, you bump the bitrate, lol
Krowl has joined #ffmpeg-devel
AbleBacon has joined #ffmpeg-devel
dellas has quit [Read error: Connection reset by peer]
dellas has joined #ffmpeg-devel
<thardin>
hum.. I think I'd like to add some config-dependent tests
<thardin>
for codec2, which require --enable-libcodec2
<JEEB>
yup
<JEEB>
there's the x264 using test already
<JEEB>
and the avctx side data patch set I've been posting adds more x264, x265 and svt-av1
<thardin>
alright, I'll have a closer look
<thardin>
the present decoder is float. I think there may be a fixed decoder in the works
<thardin>
it might also require different tests for different versions, since they've been looking at changing the decoder to something more similar to LPCnet
<thardin>
different refs I should say
<thardin>
asynth-44100-2.wav unsurprisingly turns into nonsense mostly, except for the noise part of it
Krowl has quit [Read error: Connection reset by peer]
cone-743 has joined #ffmpeg-devel
<cone-743>
ffmpeg Leo Izen master:fb54c89a0df3: avcodec/jpegxl_parser: check ANS cluster alphabet size vs bundle size
epony has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
<cone-743>
ffmpeg Leo Izen release/6.1:1a3ec3f2f8b2: avcodec/jpegxl_parser: check ANS cluster alphabet size vs bundle size
derpydoo has joined #ffmpeg-devel
dellas has quit [Ping timeout: 256 seconds]
dellas has joined #ffmpeg-devel
dellas has quit [Remote host closed the connection]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
<Lynne>
meh, everyone uses glibc anyway, and if code is too sensitive to input conditions is probably better off being a noop
rvalue has quit [Ping timeout: 246 seconds]
dellas has joined #ffmpeg-devel
<Traneptora>
Lynne: in mpv we stopped using srand, and started using an in-house xorshiro
mkver has quit [Ping timeout: 260 seconds]
rvalue has joined #ffmpeg-devel
<Traneptora>
why do you ask, btw?
dellas has quit [Remote host closed the connection]
HarshK23 has quit [Quit: Connection closed for inactivity]
justache is now known as justResolute
justResolute is now known as justIrresolute
sandy-claws is now known as jess
<Lynne>
Traneptora: toying around with DCTs, writing some code to figure out if I can use the daala/av0 DCTs for jxl
<Traneptora>
not sure why srand is relevant for that
<Lynne>
overflow checking
<Traneptora>
iirc DCTs in JXL are straight DCT-II or DCT-III, (not really sure the names?)
<Traneptora>
how is srand relevant for overflow checking, out of curiosity
<Lynne>
fuzzing, figuring out how close the transforms approximate a DCT
<Traneptora>
ah, for random spot checking, ic
<Lynne>
I'm writing a fixed-point decoder, and while a DCT-II/I is very straightforward... ish in the float domain, int domain requires a lot of effort to make something optimal, with large enough precision, speed and overflow guarantees
<Lynne>
the transform naturally passes the IEEE spec from 1993 about DCT approximations (which the old JPEG spec references), but that's a fairly low bar to pass
<Traneptora>
in hydrium I approximated the forward DCT with integers but I'm not really sure how to write fixed-point DCT code efficiently
<Lynne>
microchip_: only the 4th time I've ever been asked, so clearly, far too much
lexano has joined #ffmpeg-devel
<thardin>
Traneptora: can't find it again.. I think it was some demoscene people checking what you could get out of jxl files below a certain size limit
<Traneptora>
is this related to JXL art?
<thardin>
possibly
<JEEB>
reminds me of animation compressed to a floppy
<Traneptora>
JXL art is producing interesting patterns with incredibly tiny files, based on the modular MA tree
<thardin>
none of the images display in my browser :o
<Traneptora>
most browsers do not support JXL
<thardin>
I'm just surprised no one has even implemented jpeg fully yet
<Traneptora>
well tbf the original JPEG standard was massive and well ahead of its time
<Traneptora>
by the time some of its ideas become useful, the de facto standard subset was already almost synonymous with "JPEG"
<thardin>
simple/dumb idea to get something similar to intra prediction following up on the discussion from yesterday: shear the pixels instead of modifying the transform
<thardin>
this avoid blocks depending on other blocks
<thardin>
the shear amount has to be stored though
<thardin>
certain old game formats use a similar idea. for example SCUMM uses this for efficiently storing dithered images
Krowl has joined #ffmpeg-devel
paulk has quit [Ping timeout: 245 seconds]
rossy has quit [Ping timeout: 245 seconds]
JEEB has quit [Quit: Lost terminal]
paulk has joined #ffmpeg-devel
lexano has quit [Remote host closed the connection]
rossy has joined #ffmpeg-devel
lexano has joined #ffmpeg-devel
Traneptora has quit [Quit: Quit]
lexano has quit [Remote host closed the connection]
<Lynne>
thardin: what opus did was it rotated the coefficients just before quantization, so you could also do that for video
<Lynne>
so if there was a single dominant frequency, its energy would spread out over the whole band and you'd avoid getting spectral holes like aac is still plauged with
kekePower has quit [Quit: Ping timeout (120 seconds)]