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.0.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
<Lynne>
free fuzzing
<Lynne>
they can exceed 16, but why did you mention it?
tufei_ has quit [Remote host closed the connection]
tufei_ has joined #ffmpeg-devel
cone-961 has joined #ffmpeg-devel
<cone-961>
ffmpeg James Almer master:4d59d58ea68a: avcodec/aac/aacdec_usac: remove unnecessary cast
thilo_ has quit [Ping timeout: 268 seconds]
thilo_ has joined #ffmpeg-devel
<Lynne>
ah, I see the issue
lexano has quit [Ping timeout: 268 seconds]
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 268 seconds]
IndecisiveTurtle has quit [Ping timeout: 268 seconds]
<Lynne>
I'm surprised at how well the seeking works
<Lynne>
also wow exhale sounds really bad, I mean our native aac encoder levels of bad
<Sean_McG>
courmisch: for the 1/2 -- I can remove the other Super-H files sure, but as to the other concern ummmm, it's liternally removing README files.
<Sean_McG>
and I thought 2/2 was genuinely dead code -- so I didn't attempt to build it.
<Sean_McG>
I'm also loath to write anything explanatory for AVR32 because it is not even a platform I care about.
<Lynne>
"The AVR32 primitives were added to the repository in 2009. They contain limited inline assembly for swap and inter-endian reads. The latter in particular warns of compatibility issues with different models. There is no written evidence the code was ever ran and compiled, neither in development logs, nor on the internet in general. Remove it."
<Lynne>
done
<Sean_McG>
...maybe you should take over that removal.
<Lynne>
I'll send a patch with more research after I sleep
<mkver>
Sean_McG: I'll take over.
Kei_N has quit [Read error: Connection reset by peer]
<jamrial>
Lynne: "libavcodec/aac/aacdec_lpd.c:102:9: warning: variable 'idx' set but not used" and "libavcodec/aac/aacdec_lpd.c:148:9: warning: variable 'first_tcx_flag' set but not used"
cone-961 has quit [Quit: transmission timeout]
jamrial has quit []
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 252 seconds]
mkver has quit [Ping timeout: 252 seconds]
AbleBacon has quit [Read error: Connection reset by peer]
HarshK23 has joined #ffmpeg-devel
System_Error has quit [Ping timeout: 260 seconds]
System_Error has joined #ffmpeg-devel
scat117 has joined #ffmpeg-devel
rvalue- has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 252 seconds]
rvalue- is now known as rvalue
Krowl has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
Krowl has quit [Read error: Connection reset by peer]
tufei_ has quit [Remote host closed the connection]
tufei_ has joined #ffmpeg-devel
System_Error has quit [Ping timeout: 260 seconds]
System_Error has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
Livio has quit [Ping timeout: 268 seconds]
<BBB>
courmisch: gpac at ibc? did you mean nab?
<BBB>
("it was not appropriate for GPAC to use an FFmpeg booth at IBC")
<haasn>
Do we want nu-swscale to be capable of supporting: trc/prim conversions, DCDM XYZ, Dolby Vision, HDR/SDR tone mapping, YCgCo, BT.2020-CL/ICtCp/IPT-C2, ... ?
<haasn>
The more of these we answer "yes" to, the more swscale will need to be rewritten from the ground up to accomplish those goals
<haasn>
currently swscale supports none of the above
<JEEB>
yea I think currently swscale just has matrix coefficients?
<haasn>
I fear at some point morphing it into just a carbon copy of zimg/zscale
<JEEB>
I mean, for a CPU implementation that is the current example of something that does that kind of stuff
<haasn>
well, ultimately, a lot of the logic is already present in ffmpeg in some form or another, it's just split up into different filters (vf_colorspace, vf_tonemap, vf_scale, ...)
<haasn>
so a naive implementation of a general conversion framework might just turn into a sequence of calls to those existing functions, and we can go on optimizing things from there
<haasn>
I think that means we should at least _try_ and support everything that currently exists
<BBB>
haasn: yes to all of that
<BBB>
and it's an insane project, especially if you intend to continue supporting what it currently does
<BBB>
in terms of scope
<BBB>
so this is work for years :)
<haasn>
yes, that's what I fear
<haasn>
well
<haasn>
the way I see it can be done like this
<haasn>
1. implement high-level framework that decomposes the above into a sequence of calls to the existing libswscale + other filters and helpers
<haasn>
2. over time, replace these "black box" libswscale calls by more optimized routines for those specific tasks
<BBB>
for 1, that's why I wrote colorspace in lavfi :)
<haasn>
so basically, implement something now that is, at minimum, no slower than the existing libswscale (for existing use cases)
<haasn>
but which will devolve into slow general case paths when you do something that current libswscale cannot do at all
<haasn>
this way it will not represent a regression
<BBB>
I guess so, yes
<haasn>
oh, and of course, I forgot to add "ICC profiles" to the list :)
ngaullie has joined #ffmpeg-devel
<haasn>
most of these things are pretty easy in terms of the low-level implementation, because we can decompose almost all of the above into a series of primitive operations including "3x3 matrix", "3x1D LUT", and "3DLUT"
ngaullier has quit [Ping timeout: 246 seconds]
<courmisch>
BBB: yes
<haasn>
and then of course there is HLG which makes everything awkward by not being decomposable into 1DLUTs
<haasn>
grr
lexano has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
<elenril>
haasn: it would be nice to have some boundaries beyond which swscale does not go
<elenril>
e.g. why not have it handle spherical projection while at it
<haasn>
well, there are three operations swscale currently does:
<haasn>
1. input decoding (e.g. packed yuyv to planar yuv)
<haasn>
2. yuv/rgb conversion (naive 3x3 matrix)
<haasn>
3. general plane scaling (i.e. arbitrary horizontal/vertical convolution)
<wbs>
4. writing back to the right packed/subsampled form
<haasn>
well yes, that's the inverse of 1
<wbs>
yeah
<haasn>
in general, the problem is, the more you separate concerns, the less room there is for optimizing special cases
<haasn>
for example swscale wants special cases for 1+3, when no yuv/rgb conversion is needed
<elenril>
obviously the proper solution is to JIT the kernel perfectly optimized for the specific conversion being done
<haasn>
this but unironically is what I do in libplacebo
<elenril>
I'm only semi-joking
Livio has joined #ffmpeg-devel
<BBB>
three hurrays for our new swscale overlord: haasn!
<BBB>
he-who-shall-never-do-anything-else-again
<elenril>
nb_swscale_victims++;
<haasn>
I think what we want to happen is for libswscale to handle only scaling
<haasn>
and not do yuv/rgb conversions at all, outsourcing that instead to a "line pulling" callback
<haasn>
(the internal design of swscale is to only pull lines on demand, as needed, to minimize memory)
Teukka has quit [Read error: Connection reset by peer]
<haasn>
the line pulling callback can then go through whatever hoops it wants to do all manner of special input handling (HDR, ICC, dolby, you name it)
Teukka has joined #ffmpeg-devel
Teukka has quit [Changing host]
Teukka has joined #ffmpeg-devel
<haasn>
the hard part is figuring out how to do this in a way that doesn't slow down the micro-optimized special cases like nv12 -> rgb24
<thardin>
is it just me or does av_image_get_buffer_size() return int when image size is only capped by INT64_MAX?
<elenril>
it's just you, image size is limited to an inet
<elenril>
*int
<elenril>
properly it should be size_t of course, but hysterical raisins...
<elenril>
jamrial: are you ok with me pushing the hevc subdir patch as is?
<jamrial>
yes
<elenril>
also I think the question of subdirs for arch files could use some discussion
<elenril>
it's not clear to me so many layers of subdirs is an improvement
<jamrial>
i probably would have liked it more if the asm files were inside the relevant decoder subdir
<elenril>
so libavcodec/hevc/x86?
<jamrial>
yeah
<elenril>
that also seems reasonable to me
<elenril>
but it's largely a bikeshed question
<wbs>
I'm actually less in favour of that setup
<elenril>
which is why I wanted to avoid it for now
<elenril>
^see
<jamrial>
every relevant file together. as is, for vvc i need to check libavcodec/vvc* , libavcodec/vvc/*, and libavcodec/x86/vvc/*
<wbs>
often when dealing with asm stuff, it's convenient to be able to do look at libavcodec/<arch>/*, for a small number of libraries
<elenril>
most shells let you do it with globs rather easily
<thardin>
elenril: I don't see such a limit in there. but maybe it's checked elsewhere
<wbs>
elenril: yeah I know, but it's an extra thing to do. and if it involves any aspect of manually looking at files, it's splits the focus quite a bit
<thardin>
docs mention av_check_image_size() which no longer exists
<elenril>
IIRC it's in av_image_check_size()
<elenril>
wbs: time for a vote then!
<thardin>
yeah and it limits it to.. INT64_MAX
<elenril>
the condition is stride*(uint64_t)(h+128) >= INT_MAX
<thardin>
yeah, stride
<thardin>
a 16384x16384 RGBA64 image will pass that check easily
<elenril>
I don't follow, stride >= width
<thardin>
yeah
<elenril>
so that check implies width * height < INT_MAX
<thardin>
ohh there's an h in there
IndecisiveTurtle has joined #ffmpeg-devel
<thardin>
yeah that's fine
<thardin>
except if h > INT_MAx-128
<elenril>
but really we should get rid of that limitation
<elenril>
av_patches_welcome();
<thardin>
returning size_t instead of int would help
<elenril>
first you'd have to change AVFrame.linesize to ptrdiff_t
<elenril>
and that's probably a pretty big quest
<thardin>
the jpeg2000 gods demand it
<elenril>
strides for the stride god?
<thardin>
UBs for the UB throne
<thardin>
running fate, will push speedhq patches after it finishes
<haasn>
clearly we need a tag based filesystem
<haasn>
libavcodec/vvc/x86 should commute with x86/vvc/libavcodec
cone-068 has quit [Quit: transmission timeout]
<thardin>
I've had the same thought, but mostly because I can never decide what subfolders to archive my memes under
<elenril>
kind sir, do you have a minute to talk about our lord and saviour, the symbolic link?
<haasn>
real men only use hard links
<thardin>
symlinks are even worse
<JEEB>
elenril: I need to thank you for implementing multiple filter_complexes, it lets me handle outputs that have completely different latency cleanly now that filter chain behavior is standardized
<elenril>
that's been there since the beginning though
<JEEB>
the ballooning has been there since ages when you don't have an input, but when having an actual input defined in addition to the filter_complex it didn't
<JEEB>
now it's at least the same behavior for both
<JEEB>
with two -filter_complex things I'm able to split the once-per-minute output from the semi-stable fps output
<elenril>
I think you could also fix it with chaining
<JEEB>
maybe, for me it's pretty clear where first filter chain generates an output that is then utilized as input for the lol-latent output.
<JEEB>
so you have one filter chain which is supposed to be rolling all the time and you shouldn't wait for all outputs to be at the same time (as a minute worth of content is a lot of gigabytes with 2160p)
<JEEB>
and then another which outputs stuff every now and then
Krowl has quit [Read error: Connection reset by peer]
<sfan5>
JEEB: if you have some time would you mind checking the v2 of my mbedtls patches I posted on the ML?
<sfan5>
could then do the "will push if no objections" thing
cone-335 has joined #ffmpeg-devel
<cone-335>
ffmpeg Tomas Härdin master:017a18b02617: lavc/speedhqdec: Reindent
<cone-335>
ffmpeg Tomas Härdin master:42d5ddb2de8f: lavc/speedhqdec: Add AV_CODEC_CAP_SLICE_THREADS
<cone-335>
ffmpeg Tomas Härdin master:4037d5e10376: lavc/speedhqenc: Require width to be a multiple of 16
<courmisch>
so I've been writing the VC1 inverse tx
<courmisch>
but it's confusing if 32-bit is needed or not
<courmisch>
the checkasm comments say yes and no
mateo` has quit [Ping timeout: 256 seconds]
mkver has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
<mkver>
elenril: The libvvenc wrapper intends to use option names that are options of the ffmpeg cli. You might want to take a look at this.
Traneptora has joined #ffmpeg-devel
<courmisch>
is the rgb24 to yuv so bad because of 3 bytes / misalignment?
<nevcairiel>
it doesnt help
<courmisch>
do I understand the swscale code right that it's separately converting Y vs UV. That sounds like it'll cause a lot of unnecessary memory loads
Livio has quit [Ping timeout: 268 seconds]
<cone-335>
ffmpeg Andreas Rheinhardt master:87a13986bc08: avformat/nutdec: Don't create inconsistent side data
<cone-335>
ffmpeg Andreas Rheinhardt master:bb3c50b46d50: avcodec/tiff: Suppress unused variable warnings
Livio has joined #ffmpeg-devel
<JEEB>
sfan5: lessee, I did notice you posted that patch set some time ago
System_Error has quit [Remote host closed the connection]
microchip__ has joined #ffmpeg-devel
microchip_ has quit [Ping timeout: 255 seconds]
ccawley2011 has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
Krowl has joined #ffmpeg-devel
AbleBacon has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
<beastd>
haasn: sws plans sound plausible. regarding the limits it would occur to me to be best to align it with what can benefit by being integrated and doesn't cause to much binary bloat. such things are in my experience often determined better with bottom up approaches.
microchip__ is now known as microchip_
<kepstin>
courmisch: for planar YUV or semi-planar stuff like NV12 it might actually be beneficial for locality to do the Y and UV separately? One of those things were it needs to actually be benchmarked.
microchip_ has quit [Quit: There is no spoon!]
tufei_ has quit [Remote host closed the connection]
tufei_ has joined #ffmpeg-devel
microchip_ has joined #ffmpeg-devel
arch1t3cht has joined #ffmpeg-devel
ngaullie has quit [Ping timeout: 272 seconds]
IndecisiveTurtle has quit [Ping timeout: 268 seconds]
<courmisch>
kepstin: hard to see how loading the same input twice would be faster. especially when it's packed in an incovenient format, and slow to load
microchip_ has quit [Quit: There is no spoon!]
microchip_ has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
Livio has quit [Ping timeout: 256 seconds]
microchip__ has joined #ffmpeg-devel
microchip_ has quit [Ping timeout: 255 seconds]
microchip__ is now known as microchip_
Quackdoc has joined #ffmpeg-devel
<elenril>
mkver: thanks, I will
<elenril>
mkver: btw, any progress on ffv1 races?
cone-335 has quit [Quit: transmission timeout]
Quackdoc has quit [Quit: Client closed]
ccawley2011 has quit [Read error: Connection reset by peer]
HarshK23 has quit [Quit: Connection closed for inactivity]
tufei_ has quit [Remote host closed the connection]
tufei_ has joined #ffmpeg-devel
<JEEB>
> fedora 40 still on mbedtls 2.28.8
<Lynne>
you use it on non-embedded systems?
<JEEB>
I just want to build it looking at sfan5's patch set
<elenril>
mbedtls used to be cool, since it had no global state
<elenril>
but not anymore :(
<JEEB>
o_O huh, symbol misses
<JEEB>
time to reset the build root
<Lynne>
openssl got a lot better
<Lynne>
everyone hates on 3.0 because of the buffer i/o with its big overhead, but I like it, you can actually use it while handling all i/o yourself, so you can use io_uring with it
<elenril>
openssl has global init
<elenril>
global init is evil
<elenril>
whoever writes a library with global init shall surely be reborn as a rock
IndecisiveTurtle has joined #ffmpeg-devel
<JEEB>
not bread?
<Lynne>
err, no it doesn't?
<Lynne>
unless its some old API I don't care about
<JEEB>
sfan5: lemme just double check against master... but there's a possibility that there are some missing symbols issues :)
<Lynne>
OSSL_LIB_CTX_new is the context from which all other contexts is made, you get a pointer which you have to call OSSL_LIB_CTX_free on
<sfan5>
I didn't compile-test with 2.28 so could be my fault...
<JEEB>
at least you have not touched that symbol
<JEEB>
so I expect master is bork as well
<JEEB>
ayup, master is bork
<JEEB>
> /usr/bin/ld: libavformat/libavformat.a(tls_mbedtls.o): undefined reference to symbol 'mbedtls_x509_crt_init'
tufei_ has quit [Remote host closed the connection]
tufei_ has joined #ffmpeg-devel
<mkver>
elenril: openssl's global init only applies to version < 1.1.0. I recently #if'ed the whole code away if we use a newer version (see 583c3d45fab6).
<elenril>
oh, really
<mkver>
Feel free to remove support for the old versions altogether.
<elenril>
great news
<BtbN>
I wonder if ffmpeg should start verifiying TLS certs whenever possible at some point
<mkver>
I also nuked ff_lock_avformat
<BtbN>
OpenSSL 3.2 added a mode that should enable that.
<BtbN>
And schannel should support it already
<JEEB>
BtbN: there were patch sets for that
<JEEB>
but looking at the responses, it would have to be in parts... first warning users that "btw, this will be switched" soon. then next switch the default or something.
<Lynne>
shit will break when you start verifying certs
<BtbN>
yes, it'd have to be something that happens on a major bump, and warn-only before that
<Lynne>
though curl and wget have been verifying certs for ages now
<JEEB>
yea
<JEEB>
and the option wouldn't be removed
<JEEB>
so you would still be able to do the same as with those tools
<JEEB>
to just accept the cert
<BtbN>
Also, there seem to be issues with the schannel plugin, but nobody has reported it yet, despite me asking multiple times...
<Lynne>
btw, I found out that a lot of self-hosted emails have self-signed certificates, which annoyingly breaks if your server starts verifying them
<BtbN>
makes me wonder if that nonblock-switcheroo thing it's doing there simply does not work with the schannel (and mbedtls) wrapper
cubicibo has quit [Ping timeout: 250 seconds]
<JEEB>
sfan5: as an initial look, things look fine. I'd just probably move the MBEDTLS_ERR_X509_CERT_VERIFY_FAILED logging diff into the first commit that adds error codes (also probably "messages" in the commit message there?), as adding that error's logging really doesn't have anything to do with the verify=0 + TLS 1.3 workaround.
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
<JEEB>
sfan5: posted the review on the ML too
<sfan5>
the X509_CERT_VERIFY error code only happens due to the tls1.3 thing
<JEEB>
sure, but the workaround is unrelated to whether it gets properly logged in the TLS 1.3 code path? since there is a commit adding various errors there for better readability
<BtbN>
hm, non-block writing in TLS mode is odd. Do you just re-encrypt the message every re-try? Is there a way to check "would block" ahead of time?
<sfan5>
if tls1.3 properly respected MBEDTLS_SSL_VERIFY_OPTIONAL (or NONE) then this error logging path would never be taken. that's the idea behind putting it in this commit.
<JEEB>
yea, for me it's mostly because the commit message is `add workaround for X`, and only the second diff is the workaround. and there is already a commit adding useful errors into handle_handshake_error in the set. I know that debugging/dev wise that error being useful to log probably was figured out when figuring out wtf was going with TLS 1.3.
<BtbN>
anyway, fixed rtmps-over-schannel
<BtbN>
the schannel wrapper simply didn't forward the nonblocking-flag to the tcp stream
<JEEB>
sfan5: if you feel strongly about it, feel free to mention in another paragraph of the commit message something a la "Additionally, log TLS 1.3 certificate verification failures as they are now known to occur." or something
<JEEB>
but it just felt like the set nicely had a commit that added error messages found useful during the development of that patch set.
<sfan5>
I guess I can move it
Krowl has quit [Read error: Connection reset by peer]
microchip_ has quit [Ping timeout: 256 seconds]
microchip_ has joined #ffmpeg-devel
mateo` has quit [Ping timeout: 268 seconds]
kasper93 has quit [Ping timeout: 260 seconds]
tufei_ has quit [Remote host closed the connection]
tufei_ has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
<BtbN>
Does rtmps work with mbedtls now? I had people complain about that as well.
<BtbN>
sfan5: are you currently set up to test that?
<BtbN>
I can provide a server
<sfan5>
if it's just plugging an url into ffmpeg or mpv, sure
<BtbN>
Yeah, you need a random sample file with h264+aac, and then run an ffmpeg command