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 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
<BtbN>
I now added a sed hack to fate.sh, that after configure, replaced DEPHOSTCC and DEPCC with /bin/true
<BtbN>
It's a one-shot compile anyway, so the dependencies are irrelevant. It makes the build a bit faster as well, and un-breaks it :D
thilo has quit [Ping timeout: 272 seconds]
iive has quit [Quit: They came for me...]
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
thilo has joined #ffmpeg-devel
<cone-872>
ffmpeg Michael Niedermayer master:fb4a1eaadfbf: tools: add target_enc_fuzzer.c
<cone-872>
ffmpeg Michael Niedermayer master:25cb66369e7b: avfilter/signature_lookup: Fix 2 differences to the refernce SW
<cone-872>
ffmpeg Michael Niedermayer master:e7174e66ac60: avfilter/signature_lookup: Dont copy uninitialized stuff around
<cone-872>
ffmpeg Michael Niedermayer master:02301017d284: avfilter/vf_thumbnail_cuda: Set ret before checking it
<cone-872>
ffmpeg Michael Niedermayer master:b91e3c4c9082: avcodec/cbs_h2645: Check NAL space
<ePirat>
JEEB, so turns out drop frame is enabled when the frame separator in the string is any other character other than :
<ePirat>
which is what this comment tries to suggest… which is not documented properly _anywhere_
Krowl has quit [Read error: Connection reset by peer]
SystemError has quit [Ping timeout: 260 seconds]
Krowl has joined #ffmpeg-devel
Martchus_ is now known as Martchus
microchip_ has quit [Quit: There is no spoon!]
microchip_ has joined #ffmpeg-devel
microchip_ has quit [Quit: There is no spoon!]
microchip_ has joined #ffmpeg-devel
muiz has joined #ffmpeg-devel
microchip_ has quit [Quit: There is no spoon!]
microchip_ has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
<Lynne>
why aren't the CONFIG_<DECODER> macros defined in config.h?
Krowl has joined #ffmpeg-devel
<wbs>
Lynne: they're split to config_components.h - just because someone added a new decoder, it feels unnecessary to require rebuilding every single file in the project
<wbs>
so config_components.h is included only in the files that really needs to know if a specific different component is enabled or not (most don't really need to know or care)
* Lynne
looks at list of #include "config_components.h"
<Lynne>
that's a lot
<wbs>
indeed, it's clearly more than I remembered
<wbs>
still much less than rebuilding every single file
<wbs>
many of the cases seem to be one single .c file that contains e.g. two AVCodec instances, with ifdefs around each. it would be mostly harmless to leave out those ifdefs, we'd just have an extra unused AVCodec instance for the ones that are disabled
<Lynne>
yeah, I'm wondering whether to guard the aac_fixed/float avcodec structs behind one
<Lynne>
I need to include the header anyway for xhe-aac which is float-only
rvalue has quit [Ping timeout: 256 seconds]
<BtbN>
stupid solution of the day to get WSL build working: ln -s /mnt/c C:
<BtbN>
Cause my god fate is super inconsistent with how it refers to stuff. There is target_samples, but that path is not used for samples that are generated on the fly, those use the path to the build tree, which is in Linux-Style
<BtbN>
There is target_path, but if I set that, it'll also try to invoke stuff from it, which WSL won't like. Unless I set that symlink
<BtbN>
I'm at this point half tempted to cook up an LD_PRELOAD library that intercepts open() and replaces X: with /mnt/x
<BtbN>
open and a few exec calls I guess
Guest3678 is now known as ringo
<BtbN>
And something that'd be nice in general(if it doesn't already exist?) would be an equivalent to autotools --disable-dependency-tracking
<BtbN>
It's a free speedup of one-time builds like fate
<wbs>
indeed, for msvc builds it would speed things up massively. (for tools that support the GCC like -M options, it wouldn't make any difference though)
<wbs>
I don't think it would be hard to add that to our configure script
jamrial has joined #ffmpeg-devel
rvalue has joined #ffmpeg-devel
<BtbN>
I've basically implemented it by virtue of sed now
<BtbN>
By just setting the DEPCC and DEPHOSTCC to /bin/true
mkver has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 268 seconds]
rvalue has joined #ffmpeg-devel
Traneptora has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 268 seconds]
rvalue has joined #ffmpeg-devel
michaelni has quit [Ping timeout: 260 seconds]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
michaelni has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
pmozil has joined #ffmpeg-devel
Livio has joined #ffmpeg-devel
Workl has joined #ffmpeg-devel
Krowl has quit [Ping timeout: 268 seconds]
<BtbN>
I wonder what's slower... amd64 emulated bash, or WSL bash via their plan9 network fs
Krowl has quit [Read error: Connection reset by peer]
Krowl has joined #ffmpeg-devel
pmozil has quit [Remote host closed the connection]
ccawley2011 has joined #ffmpeg-devel
mateo` has quit [Quit: WeeChat 4.2.2]
mateo` has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
cone-827 has joined #ffmpeg-devel
<cone-827>
ffmpeg Mark Thompson release/7.0:9963b9e3c9e5: av1dec: Fix RefFrameSignBias calculation
Krowl has joined #ffmpeg-devel
AbleBacon has joined #ffmpeg-devel
Livio has quit [Ping timeout: 268 seconds]
* Sean_McG
peeks in
* another|
peeks out
* another|
peeks at the ML
* another|
reads "Cease and desist"
* another|
closes the ML
<Sean_McG>
brb, rebooting
Sean_McG has quit [Quit: leaving]
Sean_McG has joined #ffmpeg-devel
<BtbN>
MSYS2 is somehow even worse than WSL
<BtbN>
Works fine when I run script manually. But when run from another script, fails to load vcvars...
iive has joined #ffmpeg-devel
Workl has joined #ffmpeg-devel
Krowl has quit [Ping timeout: 256 seconds]
deus0ww has quit [Ping timeout: 272 seconds]
deus0ww has joined #ffmpeg-devel
deus0ww has quit [Ping timeout: 245 seconds]
<BtbN>
MSYS also calls cl.exe with as "cl.exe -I. -I/home/Timo/fate-runner/workdir/src/" when doing out of tree builds...
deus0ww has joined #ffmpeg-devel
<BtbN>
But it somehow works. How does it know to translate a path in the middle of some random argument?
<Gramner>
iirc there are explicit hacks for -I and -l followed by a path to do path conversion
<BtbN>
how horrible
<BtbN>
wonder if those hacks will also safe ffmpeg.exe during fate runs
<BtbN>
One thing is for sure though: it's somehow even slower than WSL on the network fs
<BtbN>
turns out an emulated bash ain't fast.
Workl has quit [Read error: Connection reset by peer]
<Sean_McG>
bash isn't even fast natively
<BtbN>
well, configure via WSL takes ~30 seconds
<BtbN>
4~5 minutes via MSYS
<BtbN>
I am somewhat tempted now to write an LD_PRELOAD monster that does the same kind of translation in WSL
<wbs>
yeah, msys2 has some tricks for translating paths in any argument as long as it's [-/][a-zA-Z] or something like that, but it didn't work for options like -Fo<path> since that's two chars
<wbs>
but since we messed around with that 12 years ago, MSVC has extended it so you can do "-Fo <path>" in two args
<BtbN>
It shouldn't be too crazy to write an LD_PRELOAD wrapper that gives the same treatment to any exec call that ends with .exe
<BtbN>
I'm honestly surprised Microsoft hasn't built something like that into their Kernel even
<wbs>
they have some sort of translation via WSLENV at least, but it's not quite as extensive as what msys2 does
<wbs>
the msys2 stuff is quite crazy heuristics, but also works pretty well
<BtbN>
WSLENV is for translating environment variables
<wbs>
yep
tanay has joined #ffmpeg-devel
<wbs>
(msys2 also does that to some extent)
<wbs>
but it probably doesn't do much argument translation, no
<BtbN>
It does none I think
<wbs>
yeah... as long as one can manage so that all arguments are relative paths, the issue mostly goes away (this is primarily what we did for the initial msvc support in ffmpeg)
<wbs>
at least for the cases that msys2 didn't handle, like -Fo<path>
<BtbN>
The main issue with msvc via WSL is that MSVC writes absolute windows paths into the .d files
<BtbN>
And then when trying to run fate, it goes absolutely bonkers, and mixes path schemes left and right
<wbs>
ah, but MSVC doesn't write the .d files itself at all - it just prints stuff with /showIncludes on stdout, and our own shell script does a big awk(?) soup that reformats it into .d form
Livio has joined #ffmpeg-devel
<BtbN>
Yeah, but MSVC still prints exclusively absolute paths
<BtbN>
Which is fine. If make understands Windows paths :D
<wbs>
yeah, that's true
<wbs>
msvc used to have a fun bug where it sometimes lowercased some path elements in the output of /showIncludes - which isn't an issue on a case insensitive file system, but when MSVC is wrapped in wine, and make is a native unix make, the case mismatches was a horror for any project with mixed case file names/directories
<BtbN>
WSL doesn't care about THAT at least
<BtbN>
drvfs/p9 is in case-insensitive mode
<BtbN>
I now have a completed fate run, which has some failures. Hard to tell if those are genuine failures, or environment issues from my side
<BtbN>
Basically all of vvc is failing, and those look genuine to me
<wbs>
MSVC 17.9 had a regression that manifested in vvc
<wbs>
it's fixed in the latest 17.10 previews
<wbs>
17.7 and 17.8 are the only versions that run all of FATE without any misoptimizations on arm64
<BtbN>
ah. Sadly 17.10 would be a fully separate install. Can't just upgrade to it
<wbs>
with older versions, it usually was 1 or 2 tests failing, which I could ignore with e.g. -ignore-tests="filter-pixfmts-scale"
<wbs>
sorry, --ignore-tests="..."
Marth64 has joined #ffmpeg-devel
<cone-827>
ffmpeg James Almer master:8c0045f013be: fate/iamf: add a remux test with stream group copying
<wbs>
I chased them for years, trying to get it to not misoptimize our code... I tested most preview versions, but they react too slowly to feedback for it to work properly; e.g. if there was a new regression in 17.0 preview 1, it usually wouldn't be fixed by 17.0 RTM (which usually came like 3 months later), but usually around 17.1 preview 1-2, and at that time, something else had always regressed instead
<JEEB>
\o/
<BtbN>
no idea who fate-admin is, but you got mail
<wbs>
contrary to clang, where I build the latest nightly every night, run fate (for i686, x86_64, armv7 and aarch64), and if there are any failures, I bisect down and pinpoint the error and revert the offending commit, so that it usually is fixed the next day
<JEEB>
yea, clang seems like a nice project in that sense
rvalue- has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 256 seconds]
rvalue- is now known as rvalue
<frankplow>
BtbN: Are those VVC failures with MSYS or WSL?
<BtbN>
I have not managed to get WSL working at all for running fate
<wbs>
frankplow: they're a known miscompile in MSVC for arm64
<BtbN>
It might actually be even easier to intercept in WSL than LD_PRELOAD.
<BtbN>
It uses binfmt_misc to run .exe files
<BtbN>
so one can just install a custom wrapper, and fiddle with the CLI
Krowl has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
<ePirat>
Is there a reason we still have "mixing declarations and code is incompatible with standards before C99" even though we upped to C11 now?
tanay has quit [Quit: Leaving]
<wbs>
ePirat: iirc some want that for code style reasons
<ePirat>
Ah… unfortunate
<ePirat>
IMHO especially in long functions it makes thins way harder to reason about
<ePirat>
*things
<BtbN>
It's already fine to declare new variables at the top of new blocks
<beastd>
Could also often be a hint that the function should be split. Not sure what is best, but for C code I tend to prefer to not mix decls with code. IMHO it adds a bit of clarity for this low-level high-level language ;-)
System_Error has joined #ffmpeg-devel
Workl has joined #ffmpeg-devel
Krowl has quit [Ping timeout: 268 seconds]
Workl has quit [Read error: Connection reset by peer]
Krowl has joined #ffmpeg-devel
<BtbN>
hm, is there any reason not to add fate-rsync to the fate_targets?
<BtbN>
If the samples are already there, that sync will be a near no-op anyway
Krowl has quit [Read error: Connection reset by peer]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
<BtbN>
wbs: how do you deal with fate tests where the path translation fails?
<BtbN>
There's quite a few of those
<wbs>
BtbN: I dunno, I haven't had any issues with that? for my public fate setups, I run things on linux with wine (both wrapping msvc, and wrapping the built ffmpeg), but I would think it builds and runs just fine in msys2 as well (although I don't build/run all of fate myself in that config, but I presume nevcairiel does)
<cone-827>
ffmpeg James Almer master:1a8d50e379df: fate/iamf: add a demux text
<wbs>
llvm-mingw should work just as well as MSVC in WSL; either with llvm-mingw as native windows executables, just like MSVC, or with a linux build of llvm-mingw (dunno if that makes it better or worse wrt WSL); but the msys2 setup probably is the most "reference" setup here
<nevcairiel>
for msys/mingw, i use an absolute path in unix syntax for everything, except samples, which is relative, that seems to somehow be all the right combinations :D
<BtbN>
compiling I got to work in WSL in the end
<BtbN>
running fate was the issue
<BtbN>
Using samples + target_samples with absolute paths each makes it go crazy somehow
<BtbN>
a lot of failure, and I'm not sure what they want to tell me: https://bpa.st/Y3LA
<BtbN>
nevcairiel: how did you get a relative path to work? For me that fails due to the fact that fate.sh and the ultimate build run at different paths.
<BtbN>
i.e. fate.sh just dies with "die 'samples location not specified'"
<BtbN>
hm, gonna have to cd all the way up to workdir/src I guess
<nevcairiel>
i think i'm cheating the if exists check by having an empty folder in some strategic place =P
<nevcairiel>
i set this up ages ago and it kept working
<BtbN>
Yeah, relative path seems to have been the magic trick
<cone-827>
ffmpeg James Almer release/7.0:96d941b30ea1: avutil/iamf: fix mix_gain_class name
<thardin>
>ffchat
<thardin>
please no
<gnafu>
When is ffmpeg getting native XMPP support?
<ePirat>
do i understand correctly that even though there is a avdevice device enumeration API , it has no API to specify the device's device so various devices have various conventions of special stuff to put in the input name?