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 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
<haasn>
compn: I want to try and make both float and int backends
<haasn>
should we have a cpu flag for platforms with slow floats?
<haasn>
I'll start with float for now though since it's way easier
<haasn>
wbs: I will test on RISC-V as well
<haasn>
though only out of curiosity since it's just a devboard
abdu64 has quit [Quit: Client closed]
Kei_N_ has joined #ffmpeg-devel
Kei_N has quit [Ping timeout: 252 seconds]
System_Error has quit [Remote host closed the connection]
iive has quit [Quit: They came for me...]
<Compn>
haasn, possible to have both side by side during runtime ? i mean -vf scale and -vf scale2 or -sws 1 -sws 2
<Compn>
well maybe no one would like this idea but if its not bitexact some people would
<Compn>
haasn, its possible that i'm thinking of just ancient technology that we've all moved on from and float is the way to go.
* Compn
has to go interrupt his irq port
<haasn>
It should be bitexact with floats
<haasn>
They have more precision in their mantissa than even fixed point ints
<haasn>
And can accurately represent anything up to 2^24
<haasn>
Also easier to do correct rounding with floats
<Compn>
i mean bitexact to what we have now
<haasn>
Okay I think I’ve decided that floats are just superior
<Compn>
not bitexact to itself
<Compn>
:D
<haasn>
Right
<Compn>
just checking :)
<haasn>
Well, I think that the current code is not bit exact when scaling; since it uses 15 bit internal precision
<haasn>
For 8 bit input
<haasn>
And iirc it is based on the input depth only, not the output depth
<Compn>
i dont really have strongk opinions either way
<Compn>
i just like more bloat
<haasn>
I will write a convolution benchmark before committing to it
<haasn>
Tomorrow
<Compn>
if both are compiled at same time, it makes things much easier to test
<Compn>
and find bugs.
<Compn>
then can rm -rf it later...
<Compn>
bugreports come in with md5sum of frames in each scaler. otherwise we only get md5sum of one or the other. and then we test and its 'no problem here'
<Marth64>
I think something is wrong with ffpreset. Doc says this:
<Marth64>
>For the vpre, apre, and spre options, the options specified in a preset file are applied to the currently selected codec of the same type as the preset option.
<Marth64>
but I pass an ffpreset with -vpre, and set "profile=high". and this gets picked up by the audio encoder (libfdk_aac) which does not accept that profile
<Marth64>
point is why would something passed in -vpre apply to audio encoder
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
<fflogger>
[newticket] Marth64: Ticket #11447 ([undetermined] ffpreset functionality does not work as advertised) created https://trac.ffmpeg.org/ticket/11447
Guest3393 has quit [Remote host closed the connection]
secondcreek has quit [Ping timeout: 245 seconds]
zsoltiv_ has joined #ffmpeg-devel
zsoltiv has joined #ffmpeg-devel
Guest3393 has joined #ffmpeg-devel
cone-146 has quit [Quit: transmission timeout]
ngaullier has joined #ffmpeg-devel
HarshK23 has joined #ffmpeg-devel
<Guest3393>
Hello guys. I am trying to submit a patch but cannot get my patch to show up on Patchwork. I followed the guide on submitting patches, which suggested that I could use `git format-patch -s -o "outputfolder" --add-header "X-Unsent: 1" --suffix .eml --to ffmpeg-devel@ffmpeg.org -1 1a2b3c4d` as an alternative to `git send-email`. I opened the generated .eml file with Outlook and clicked Send
<Guest3393>
But that did not seem to work
<haasn>
wbs: I updated the benchmarks to test vertical convolutions as an example (using a ring buffer and columnar access order): https://0x0.st/8KLM.c
<haasn>
now on my end, floats are _substantially_ faster than the fixed precision code
<haasn>
like almost 2x
<haasn>
so I will definitely write the float version first, only question at this point is if we still need an int version or not
<haasn>
probably it can be added later in any case
jarthur has quit [Quit: jarthur]
^Neo has joined #ffmpeg-devel
^Neo has quit [Changing host]
^Neo has joined #ffmpeg-devel
Guest3393 has quit [Remote host closed the connection]
<wbs>
haasn: I do see that float is faster than fixed, but specifically only when compiled with Clang, and only on some HW
<haasn>
wbs: try adding -mavx2 on the Zen builds
<wbs>
haasn: updated with that
<haasn>
those results are indeed a bit worrying, I am currently redesigning my template organization such that we can easily support both
<haasn>
okay
<wbs>
that helped GCC make the int16 codepath even faster, but not for floats. on Clang it gave good speedup for both cases
<haasn>
what I noticed is that vectorization quality changes massively from one version of gcc/clang to the next
<wbs>
yes
<wbs>
this is why we normally stick to handwritten asm :-)
<haasn>
even clang trunk produces significantly better code than the latest stable release (per godbolt)
<haasn>
right :)
<haasn>
tell that to the dozens of C slow paths in swscale atm :p
<wbs>
:P
<haasn>
what we can do for now is take the output of clang master and dump that into an asm file
<haasn>
and then go from there
<haasn>
I wanted to merge the new design _before_ spending month writing asm
<haasn>
but I suppose focusing on 20% of worst cases probably gives 80% of the speedup
<haasn>
we can also still fall back to existing already written asm routines in compatible cases
<Lynne>
you can't really optimize or touch compiler written asm
<haasn>
for example we already have a routine for changing the order of bytes in a uint8_t plane
<Lynne>
so I don't agree with "we can go from there"
<Lynne>
I'd rather either rely on the compiler, or write simd
<haasn>
fair
<wbs>
if the setup does allow mixing handwritten asm for the cases we care a lot about, with compiler generated backups for the rest, I guess that's reasonable. especially if the compiler generated backups can be both compiler baseline and separate builds with more instruction sets enabled by default
cone-680 has joined #ffmpeg-devel
<cone-680>
ffmpeg James Almer master:873204e6e417: avcodec/nvenc: add compile time check for outputRecoveryPointSEI for HEVC
<haasn>
wbs: that is exactly the idea
<Lynne>
compiler generated simd should definitely not exist within the first patchset
<Lynne>
it should be added as a separate patch and discussed separately
<haasn>
I agree
<haasn>
the only thing I will do in v1 is enable SIMD in auto-vectorization on supported platforms
<haasn>
but not dumping compiler output or anything crazy
<Lynne>
it already is, on clang, just not on gcc
<haasn>
yes but not with AVX2
<Lynne>
is it because on compile time we assume no extensions are supported?
<haasn>
exactly
mkver has joined #ffmpeg-devel
<haasn>
so we need to compile the template twice, once with -mavx2 and then pick the right table at runtime
<haasn>
it's not a big deal except for increasing object size
<haasn>
and can be disabled on CONFIG_SMALL
<Lynne>
that's... suboptimal
<haasn>
why?
<Lynne>
its generally why we write simmd
<Lynne>
the template would end up disappearing
<Lynne>
I reckon users should decide what extensions to enable when compiling, with us providing SIMD for when we have such available
<Lynne>
the code will be merged regardless of what sort of speedup or slowdown it offers, so IMO you're worrying a bit too much about performance rather than design
<Lynne>
after all, the lavu/tx code still lacks full optimizations, and when it was initially merged, had none
<ePirat>
> I reckon users should decide what extensions to enable when compiling
<ePirat>
That doesnt really work when you dont know where the final binary runs on?
<nevcairiel>
all our acceleration is runtime detected, derivating from that and making a true universal binary impossible would be a terrible idea
<Lynne>
no one's mentioned removing this
<Lynne>
I'm simply arguing that spending so much time on templating to generate compiler SIMD is generally not the way we do optimizations
<nevcairiel>
this is also true, we generally write ASM SIMD, and x86inc templating can also do a lot of work
Thul is now known as Thulinma
UndeadLeader has joined #ffmpeg-devel
<UndeadLeader>
you have 0 skills to write SIMD
<Lynne>
I have some skills to write SIMD, otherwise supernatural entities with no way to know what I wrote wouldn't join a channel to tell me I have no skills
<UndeadLeader>
stealing SIMD from compiler explorer is not skill
<UndeadLeader>
instead fixing integer overflows in code is rocket science
<haasn>
Lynne: it is a trivial amount of extra work, maybe 10 lines in total
<Lynne>
for ./configure, probably, but it still requires templating a file
rvalue has quit [Remote host closed the connection]
<jamrial>
(unsigned)UndeadLeader
<UndeadLeader>
do not give kid a fish, teach kid how to fish a fish
<UndeadLeader>
same applies to C compilers
rvalue has joined #ffmpeg-devel
ngaullier has quit [Remote host closed the connection]
ngaullier has joined #ffmpeg-devel
rvalue has quit [Quit: 'checking conn']
rvalue has joined #ffmpeg-devel
<haasn>
is floating point YUV a thing? how is YCbCr normalized? 0-1 with 0.5 neutral or -0.5 to 0.5?
<JEEB>
yea it is
<JEEB>
BT.2100 uses float as the input values when describing the full/limited range stuff
<JEEB>
For RGB and luma planes such as Y in YCbCr and I in ICtCp, 'E' is the original value in range of 0.0 to 1.0.
<JEEB>
For chroma planes such as Cb,Cr and Ct,Cp, 'E' is the original value in range of -0.5 to 0.5.
<JEEB>
so luma is 0.0 to 1.0, chroma is -0.5 to 0.5
<haasn>
that contradics the formale
<haasn>
no?
<haasn>
nvm
<JEEB>
well this is from BT.709, BT.2020 and BT.2100
<JEEB>
I gave the references in the definition of AVColorRange when I rewrote the docs
<JEEB>
we can of course have our own internal representation, but since you asked if float YCbCr is a thing :)
rvalue has quit [Ping timeout: 252 seconds]
rvalue has joined #ffmpeg-devel
srikanth has joined #ffmpeg-devel
<haasn>
wbs: can you try with -ffast-math?
<haasn>
to allow the compiler to reassociate the reduction
<wbs>
haasn: on GCC 13 on x86_64, that makes GCC come much closer to Clang numbers, anf then float is faster than int16
<haasn>
okay, that will have been the difference, I was testing with -ffast-math
<haasn>
I think it's a good idea to enable for the inner loops specifically, it's just an accumulation
<wbs>
-ffast-math in itself is semi dangerous though, but there are smaller scope flags that may give you what you need, without the dangerous parts
<haasn>
specifically we want -fassociative-math and probably -freciprocal-math
Flat_ has quit [Quit: Rip internet]
Flat has joined #ffmpeg-devel
rvalue has quit [Remote host closed the connection]
rvalue has joined #ffmpeg-devel
srikanth has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
srikanth has joined #ffmpeg-devel
Labnan- has left #ffmpeg-devel [Leaving]
Labnan- has joined #ffmpeg-devel
<kurosu>
Is that 4 platforms where clang 18 always outperforms, all else being equal, gcc 13? Maybe just a coincidence for that specific type of code. Autovectorization would be the same I imagine
<kurosu>
(wbs tests)
Moon_Rabbit has joined #ffmpeg-devel
srikanth has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
rvalue has quit [Excess Flood]
rvalue has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
<cone-170>
ffmpeg James Almer master:a8595dae0fa3: doc/ffmpeg: update example command line for IAMF muxing
abdu46 has joined #ffmpeg-devel
jarthur has joined #ffmpeg-devel
abdu has joined #ffmpeg-devel
abdu46 has quit [Ping timeout: 240 seconds]
UndeadLeader has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
<jamrial>
BtbN: mastering metadata in av1 doesn't seem to work with the current driver. i see no metadata obu in the output
<jamrial>
it does work for hevc, where the generated SEI message has the correct values (so at least better than what happens with the mv stuff)
<BtbN>
it working for HEVC is a pretty good indication that we're not doing anything wrong tho. So to me it's still fine to include support like this, and then tell Nvidia about it
<jamrial>
but it's not all working great for it either, because if hevc->outputMasteringDisplay is set to true, even if a NV_ENC_PIC_PARAMS has no pointer set to a MASTERING_DISPLAY_INFO struct, it will still output a SEI message but with all zeroes
<BtbN>
so it needs to be set on every single frame?
<jamrial>
IMO, it should only write a SEI message if the pointer is set
<BtbN>
Yeah, absolutely
System_Error has joined #ffmpeg-devel
<wbs>
jamrial: if I understood BtbN's latest message, one can't use newer major versions of the headers without also updating to a matching version of the drivers
<BtbN>
the headers impose a minimum driver version
<BtbN>
And some really old ones also a maximum driver major version
Raz- has quit [Quit: Leaving]
<Marth64>
I use NVENC a lot and can't live without that backward capability by going to an older version of the headers (thank you for setting it up in this way)
<BtbN>
I'll eventually want to drop 8.1 support, since that adds a lot of extra ifdefery
<BtbN>
maybe in 8.0
<Marth64>
I use only sdk/12.0 and above personally
<Marth64>
when I was dealing with driver shenanigans more so (things are better now)
<BtbN>
old nvidia drivers are riddled with known security issues at this point, including some exploitable via shaders from JavaScript
<BtbN>
So if you can, you should be up to date
Pratham_24 has joined #ffmpeg-devel
<cone-170>
ffmpeg James Almer master:1fbe9deee349: avcodec/nvenc: add support for writing mastering metadata SEI messages
<Marth64>
yep, I am now. had a situation where I was stuck on 535 for a while
<BtbN>
What I usually do is look which API levels the still supported legacy drivers support, and then use that as the minimum
Pratham_24 is now known as Xavier24
srikanth has joined #ffmpeg-devel
Xavier24 has quit [Ping timeout: 252 seconds]
<Marth64>
I was thinking to add CLI switches to fftools/ffmpeg to be able to set crop sidedata. For example if I want to author an MKV now and set crop tags, I have to apply them with mkvtoolnix (or add side data via API). Am I missing any switches that already exists to do this?
<Marth64>
s/set/set+override/
<Marth64>
(container level crop sidedata)
<JEEB>
I don't think anyone got into proper generic strings to side data mapping code
<JEEB>
which is one of the bigger problems with side data still
<JEEB>
I think the only thing is the rotation etc stuff that I made to replace stuff that was used in a FATE test
<JEEB>
having a generic string to filled side data struct API has been something on my eternal todo list
<JEEB>
so we could do it either through filter chain in a side data addition filter or so for AVFrame(s), or otherwise for container level stuff
<Marth64>
I was thinking some opportunity for container level setting that is compatible with stream copy
<Marth64>
I can go the hack route in a local patch, with options on the muxer directly but that's no fun :D
<JEEB>
you want an option that probably overrides input information, and then hooks it into some sort of string->filled side data sort of API
<JEEB>
*hook it
<Marth64>
yeah that sounds like the reasonable way
ngaullier has quit [Remote host closed the connection]
<BtbN>
https://bpa.st/PBUA hm, SVT broke something, or just gcc-14 shenanagans?
<JEEB>
and the API doesn't have to support all of the side data types yet, but we already have a list of names (used by ffprobe to get side data name), and textual formatting examples if you look at -of json etc. probably will end up as some sort of name plus dict
<JEEB>
BtbN: yea they changed the definition without a value you can check for
<Marth64>
BtbN, compn: are you ok with me removing -r flag from #ffmpeg? This would solve for users unable to join #ffmpeg on the web client but still able to join #ffmpeg-devel and allow the broken KiwiIRC link patch to move forward.
<Marth64>
(also open to +r'ing both and documenting that users need to register, or just +r #ffmpeg-devel)
<BtbN>
ah, yes. I forgot
<BtbN>
not sure if you can, ChanServ might put it back
<Marth64>
ya if mlocked
srikanth has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<Marth64>
-ChanServ- Mode lock : +ntcrC
<Marth64>
is mlocked
srikanth has joined #ffmpeg-devel
<Marth64>
not urgent
<Marth64>
TY BtbN
<BtbN>
compn: you don't need to add people to the #ffmpeg ACL, it's set up so that everyone who has op here also has it over there
<UndeadLeader>
if you add +r to #ffmpeg-devel Leader will leave ffmpeg for ever
darkapex has quit [Ping timeout: 245 seconds]
darkapex has joined #ffmpeg-devel
<Compn>
Marth64, its fine with me
<Marth64>
thank you compn
<Compn>
BtbN, freenode access confuses the hell out of me
<Compn>
er, i mean libera uses a slightly different system than i remember on freenode*
<Marth64>
yea libera services are a little strange
<BtbN>
It's largely the same though
System_Error has quit [Remote host closed the connection]
srikanth has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
System_Error has joined #ffmpeg-devel
Marth64 has quit [Remote host closed the connection]
Marth64 has joined #ffmpeg-devel
srikanth has joined #ffmpeg-devel
Teukka has quit [Read error: Connection reset by peer]
Teukka has joined #ffmpeg-devel
Teukka has quit [Changing host]
Teukka has joined #ffmpeg-devel
<cone-170>
ffmpeg James Almer master:84ad9146e2c3: avutil/Makefile: fix SKIPHEADERS for AMF
<cone-170>
ffmpeg James Almer master:a750bcb237bc: avfilter/Makefile: add missing SKIPHEADERS for AMF
<BtbN>
hm, I can't really come up with an elegant way to deal with those MV-HEVC requirements
<BtbN>
Having to pass in an even number of frames, or stuff goes bad. Needing to combine multiple packets, ...
<BtbN>
That's quite a bit overhaul of the encoding logic if actually implemented
<jamrial>
are the timestamps on the currently-split output packets correct?
<BtbN>
They're just forwarded from the input frames as-is
<jamrial>
because, supposedly, there should be slices for both layers sharing a timestamp, thus belonging to the same temporal AU
<BtbN>
How do timestamps even work with a stereo frameseq? Do just two frames come in with the same timestamp?
<jamrial>
yes
<jamrial>
by default, only one view is output
<jamrial>
(with the native hevc decoder)
<BtbN>
That would work out okay then. The merging-logic would just discard the second timestamp
<nevcairiel>
does anyone care enough for that effort? make them send a patch then :P
<UndeadLeader>
what is the problem?
<BtbN>
Nvidia rushed a feature, and now it's a bit of a mess
<UndeadLeader>
write CPU-only MVC
<jamrial>
BtbN: honestly, nvidia should fix the driver and make it output one packet per two input pictures, which would be a proper AU as containers expect them
<jamrial>
they can be strict regarding only accepting interleaved views as input frames if needed (otherwise they'd need to buffer stuff)
<BtbN>
granted, if they did that, it would also break nvenc.c, but in a way that can be more sanely fixed
<jamrial>
but the even frame requirement is not something that can be avoided
<BtbN>
well, if could just discard the half-finished frame on flush
<BtbN>
*it
<BtbN>
or throw an error
<BtbN>
all better than entering an infinite busy-loop
<jamrial>
true
UndeadLeader has quit [Quit: Client closed]
UndeadLeader has joined #ffmpeg-devel
abdu has quit [Quit: Client closed]
abdu has joined #ffmpeg-devel
abdu7 has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
abdu has quit [Ping timeout: 240 seconds]
<fflogger>
[newticket] electron.rotoscope: Ticket #11449 ([undetermined] Current timecode in drawtext timecode) created https://trac.ffmpeg.org/ticket/11449