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
navi has quit [Quit: WeeChat 4.0.4]
iive has quit [Quit: They came for me...]
avaatk has quit [Remote host closed the connection]
thilo has quit [Ping timeout: 256 seconds]
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
thilo has joined #ffmpeg-devel
dellas has quit [Remote host closed the connection]
<Traneptora>
kasper93: officially ffmpeg does not allow tv-range RGB
<Traneptora>
in any part of its pipeline
<Traneptora>
thats' the answer
qeed has quit [Quit: Leaving]
cone-777 has quit [Quit: transmission timeout]
Xaldafax has quit [Quit: Bye...]
lemourin has quit [Read error: Connection reset by peer]
lemourin has joined #ffmpeg-devel
<aaabbb>
i'm trying to reproduce a libswscaler segfault but i can only trigger it from within mpv, anyone know if there's anything i can do with -vf with ffplay to make it match the behavior of mpv?
<JEEB>
amd64 optimizations include sse2 and the C result is now faster than manual sse2 simd?
<courmisch>
yes but of course, it could be unreal benchmark w.r.t. caching
<elenril>
float SIMD is easier than integer
<courmisch>
I mean it's hard on the hardware
<courmisch>
otherwise, where's that quad precision AVX instruction set
<courmisch>
you're supposed to do float on the GPGPU, obviously
<courmisch>
sorry, the AI accelerator in 202x speak
<elenril>
the numbernator
<elenril>
the computator
<courmisch>
sounds chuuni
<elenril>
s/or$/r/ then
<courmisch>
oooh, so outdoortastic weather on Thursday
<courmisch>
15 km walking commute is going to be fuuuuuun
<elenril>
it's spring here
<kasper93>
Traneptora_: I just don't understand what there is to support. You decode the data and tag it correctly. I don't care about swscale or any other thing. Also if you feel like this is the way to go, pngenc.c should also ignore color_range.
<courmisch>
elenril: 180mm of frozen hydroxyde monoxyde on the floor here
<elenril>
nice
<elenril>
we had recordbreaking amounts of snow ~10 days ago
<courmisch>
no, not nice
<elenril>
(by local standards)
<courmisch>
at the same time as public transport strike, not nice
<elenril>
it was +10 today
* JEEB
did a nice run in the snowy woods
<JEEB>
and yea will be fun how to get around on Thursday :3
<mindfreeze>
Orange site is having Ffmpeg multithreading as trending
<courmisch>
the closest heliport to my lair is also the closest to my office, I think
<courmisch>
so not sure how helicopter helps
<JEEB>
<helicopter flies after a single dog in a snowy area>
<elenril>
>in the near future LLM will be able to do that refactoring in seconds
<elenril>
lmao
<courmisch>
it's okay, you'll have graduated to middle management by then
* courmisch
equips stab-proof vest
<JEEB>
kasper93: I think just reading the flag and not failing should be 100% fine (if it is allowed by the PNG spec's CICP handling). if it isn't allowed by the spec, then it shouldn't be allowed by the encoder, either :)
<elenril>
courmisch: of fflabs?
<courmisch>
elenril: oops
<JEEB>
he's already a chief xyz
<courmisch>
t'is what you get for not joining Big Corporate
<courmisch>
okay, time to beat x86
<elenril>
I keep being surprised how many people want to broadcast their lack of clue on the internet
<elenril>
probably should stop
<courmisch>
how you know they're people and not some AI bot?
<courmisch>
ChatGPT could probably write better articles than Moronix
ccawley2011 has quit [Remote host closed the connection]
ccawley2011 has joined #ffmpeg-devel
ccawley2011 has quit [Read error: Connection reset by peer]
ccawley2011 has joined #ffmpeg-devel
<Traneptora_>
kasper93: there's various places in the code where RGB is assumed to be full-range, atm all the decoder does is print a warning
<Traneptora_>
it still allows it to decode, so I'm not sure there should be anything else done here?
ccawley2011 has quit [Read error: Connection reset by peer]
ccawley2011 has joined #ffmpeg-devel
<kasper93>
is there a downside of not stripping CICP metadata? Sure, some places might assume full range rgb, but those wouldn't work correctly anyway. And places that support it would work. *shrug*
<elenril>
is this about limited range rgb?
<kasper93>
yes
<Lynne>
courmisch: not in general, the FFT SIMD I wrote was quite difficult, though 90% of the difficulty came from doing everything in-place and eliminating stores
<elenril>
why do you want limited range rgb?
<elenril>
it's heretical
<JEEB>
elenril: he doesn't really want it :D pngenc apparently can write those flags and he just wants it to go input-to-output
<JEEB>
without any processing
<kasper93>
what JEEB said
<another|>
elenril: out of curiosity: what software do you run for up.k.n and files.k.n ?
<elenril>
I never cared enough to find out how exactly
dellas has quit [Remote host closed the connection]
dellas has joined #ffmpeg-devel
<courmisch>
Lynne: sorry?
<Traneptora_>
kasper93: I see what you mean, you think we should keep the warning but still tag it?
<kurosu>
courmisch: again checkasm timings are imo untrustworthy if there are not enough iterations. I think dav1d did 1<<12 at one point
<courmisch>
"they have all the control"
<kasper93>
Traneptora_: is this warning actionable? I mean it should warn whenever we try to interpret the data and is unexpected/unsupported format (i.e. swscale or in encoders)
<courmisch>
lizard people have won
<jamrial>
elenril: valgrind seems to complain a lot after the thread set
<kasper93>
I don't mind the warning though, just saying
<Traneptora_>
I see, I think it's more helpful to have it than not to have it
<Traneptora_>
but I see what you're saying about tagging it anyway. I can send a patch to fix that
Traneptora_ has quit [Quit: Quit]
Traneptora has joined #ffmpeg-devel
<Lynne>
courmisch: about float SIMD being less complex than fixed-point
<Lynne>
fixed point is 99% prepwork to make sure you don't overflow under normal conditions while balancing how many bits of precision you retain
<courmisch>
Lynne: I think typical CPU has fewer float units than ALUs though
<courmisch>
Lynne: also fixed point properly speaking takes a hit from all the shifts, narrowings and widenings. I meant plain integers
<Lynne>
I can't think of a CPU with less float units than int units (just that float units are 4x slower normally)
<Lynne>
at least for arm64 and modern x86 (and GPUs, which have less int units than floats, unless you count tensor int units as units)
<elenril>
slower?
<elenril>
float? on x86?
<microchip_>
what I'm seeing after threading stuff pushed.... time=N/A bitrate=N/A speed=N/A
<elenril>
works for me
Oneric has quit [Quit: Connection lost]
<microchip_>
not worky here when encoding audio with libfdk_aac
<microchip_>
works fine with libx264
Oneric has joined #ffmpeg-devel
<elenril>
huh
<elenril>
okay, will investigate, thanks
<jamrial>
elenril: https://pastebin.com/raw/8KfPYj5N does that not fix it? you set have_unchoked to 1 conditionally, but never 0, and you check if it's 0
<Lynne>
elenril: yeah, 4 cycles for a SIMD multiply (3 for an add on newer CPUs) vs 1 for integers
<Lynne>
pretty much the same everywhere
<elenril>
jamrial: i should probably --enable-extra-warnings in my builds
PAUL007 has quit [Ping timeout: 250 seconds]
<elenril>
...or maybe not
dellas has quit [Remote host closed the connection]
<jamrial>
mingw64 gcc 13 does not warn about this, at least
<jamrial>
and curious how ubsan also didn't trip on it
qeed has joined #ffmpeg-devel
<elenril>
anyway, patch obviously LGTM
<cone-714>
ffmpeg James Almer master:7cc4b306eb8a: ffmpeg_sched: initialize have_unchoked
<jamrial>
now we wait, because valgrind is insanely slow
___nick___ has joined #ffmpeg-devel
___nick___ has quit [Client Quit]
___nick___ has joined #ffmpeg-devel
___nick___ has quit [Client Quit]
___nick___ has joined #ffmpeg-devel
dellas has joined #ffmpeg-devel
kierank has quit [Ping timeout: 260 seconds]
haasn has quit [Ping timeout: 260 seconds]
kierank has joined #ffmpeg-devel
drv has quit [Ping timeout: 260 seconds]
drv has joined #ffmpeg-devel
haasn has joined #ffmpeg-devel
<elenril>
i tried so hard to emphasise what exactly is being paralellised
<elenril>
and in the end it didn't even matter, because people cannot read
<jamrial>
"Why is my single output encode not going faster??? I bet AI could have done a better job"
Krowl has joined #ffmpeg-devel
Owner__ has joined #ffmpeg-devel
Marth64[m] has quit [Ping timeout: 240 seconds]
<Traneptora>
I don't see what people really expect to change when encoders are already multithreaded
<Traneptora>
for most use cases
<elenril>
people expect magic animated ponies, because they have no idea how things work and cannot be bothered to find out
ccawley2011 has quit [Read error: Connection reset by peer]
ccawley2011 has joined #ffmpeg-devel
<courmisch>
well, Phoronix made it sound like it was the biggest invention since sliced H.264
<courmisch>
so of course the people demand goodness
<courmisch>
lpc_compute_autocorr for VL < 256 bits is going to be pains and sufferings
<elenril>
slices are overrated
<elenril>
it's all about tiles now
<courmisch>
elenril: the joke doesn't work with tiled[3~
<elenril>
your keyboard sounds tiled
<courmisch>
how do you know how my keyboard sounds? this is creepy
<Lynne>
courmisch: did you figure out the lpc and if you could take that shortcut?
<kierank>
elenril: oh my god the hn comments
Krowl has quit [Read error: Connection reset by peer]
<Lynne>
do they think that ffmpeg had no threading before (I'm not even going to go to read)
<elenril>
it's mostly people with strong opinions, zero clue, and even less reading comprehension
<elenril>
...and astrange, for some reason
<courmisch>
Lynne: the shortcut works, but I need 256-bit vectors for 16 < lag <= 32
<courmisch>
it wouldn't be too hard to do 128-bit for exactly lag == 32
<courmisch>
but for 17-31, it's going to be paiiinful
<kylophone>
once you read something on hn about something your familiar with, its easy to extrapolate
<kylophone>
and then you realize its all bs
<kylophone>
*you're *it's
<j-b>
good morning
kurosu has quit [Quit: Connection closed for inactivity]
<Lynne>
courmisch: do no emulators support 256bit vectors still?
Sk0tik has joined #ffmpeg-devel
<Lynne>
I'm eagerly awaiting the second rev of the c920, it's going to have 256bit vectors, and most chips will have lots of those cores, may be the first real practical risc-v cpu I'd like
<courmisch>
Lynne: sure, I can verify that it works
<courmisch>
Lynne: QEMU supports 128, 256, 512 and 1024
<thilo>
jamrial: thx looking into it
MrZeus_ has joined #ffmpeg-devel
MrZeus has quit [Ping timeout: 260 seconds]
<Lynne>
courmisch: is the issue with specialcasing 256-bit vectors for those lag range?
<courmisch>
Lynne: RVV lets you pick double, quadruple or octuple scaled vector sizes, at the cost of half, quarter or eighth the number of actual vectors
<courmisch>
but you can't do 16x
<courmisch>
so with 256-bit vectors, you can get vlenb*8 / sizeof (double) = 32 double elements per vector
ccawley2011 has quit [Ping timeout: 260 seconds]
AbleBacon has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
dellas has quit [Remote host closed the connection]
ccawley2011 has quit [Read error: Connection reset by peer]
ccawley2011 has joined #ffmpeg-devel
dellas has joined #ffmpeg-devel
dellas has quit [Remote host closed the connection]
dellas has joined #ffmpeg-devel
iive has joined #ffmpeg-devel
uau has quit [Ping timeout: 240 seconds]
ccawley2011 has quit [Read error: Connection reset by peer]
dellas has quit [Remote host closed the connection]
dellas has joined #ffmpeg-devel
kurosu has quit [Quit: Connection closed for inactivity]
uau has joined #ffmpeg-devel
uau has quit [Client Quit]
uau has joined #ffmpeg-devel
uau has quit [Client Quit]
uau has joined #ffmpeg-devel
uau has quit [Remote host closed the connection]
uau has joined #ffmpeg-devel
uau_ has joined #ffmpeg-devel
uau has quit [Ping timeout: 260 seconds]
uau_ is now known as uau
<ubitux>
so, which bitrate control do you guys prefer? prores_aw or prores_ks?
<ubitux>
i'm trying to find a way to make them behave the same but obviously that's not straightforward
<ubitux>
elenril: btw you asked for features in one and not the other, there is also slice threading supported in _ks
<ubitux>
(not sure how useful this is given frame threading, but it's there)