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.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
rvalue has quit [Ping timeout: 264 seconds]
<psykose>
it does index the whole project, but you need compile_commands set in some way
<psykose>
unless you meant something else
<Marth64>
fate web server is working in docker container using lighttpd/cgi with the legacy code (on my local machine). now i will move on to the ssh part for result submission
<Marth64>
i wil put it on github in little bit
<Marth64>
of course Marth64 is taken on github lol
user23 has quit [Ping timeout: 250 seconds]
mkver has quit [Read error: Connection reset by peer]
mkver has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 252 seconds]
Marth64 has joined #ffmpeg-devel
user23 has joined #ffmpeg-devel
<Lynne>
psykose: meson even generates it by default
<psykose>
it does yes
<psykose>
but in ffmpeg i think nothing does
<psykose>
cmake also makes it with an env var
<michaelni>
baptiste fixed (rebooted) fate.ffmpeg.org. IIUC the problem was due to some maintaince
<Lynne>
but getting from A to B is still not exactly possible, even with meson
<Lynne>
because it's not like clangd knows which build dir you used
<jdek>
psykose: bear -- make -j180 works fine
<psykose>
ah right bear
<psykose>
of course :)
<jdek>
think it just loads some library to intercept the calls to compiler
Marth64 has quit [Remote host closed the connection]
jarthur has quit [Ping timeout: 272 seconds]
sgm has joined #ffmpeg-devel
lexano has quit [Ping timeout: 264 seconds]
AbleBacon has quit [Read error: Connection reset by peer]
wyatt8750 has joined #ffmpeg-devel
wyatt8740 has quit [Ping timeout: 264 seconds]
mkver has quit [Ping timeout: 272 seconds]
psykose has quit [Remote host closed the connection]
psykose has joined #ffmpeg-devel
thilo has quit [Ping timeout: 240 seconds]
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
thilo has joined #ffmpeg-devel
user23 has quit [Remote host closed the connection]
johnmcnuggets has quit [Remote host closed the connection]
qeed_ has joined #ffmpeg-devel
qeed has quit [Ping timeout: 264 seconds]
qeed_ has quit [Ping timeout: 268 seconds]
qeed has joined #ffmpeg-devel
jamrial has quit []
\\Mr_C\\ has quit [Remote host closed the connection]
\\Mr_C\\ has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 246 seconds]
Martchus has joined #ffmpeg-devel
compn has quit [Read error: Connection reset by peer]
compn has joined #ffmpeg-devel
<Lynne>
"why haven't you used our sample app to test your implementation?!?"
<Lynne>
"I, having written thousands of lines of x86 SIMD assembly, sadly, simply lack the ability to understand heavily abstracted C++ code to fix it enough to make it build"
<Lynne>
well, it's a way of avoiding how the sample app in question is the worst sample app in history at being an example
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
stevenliu has quit [Read error: Connection reset by peer]
stevenliu_ has joined #ffmpeg-devel
Marth64 has joined #ffmpeg-devel
Livio has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
Livio has quit [Ping timeout: 240 seconds]
<Marth64>
elenril: re- dvd subtitle colors. I think I'm starting to agree there is no point in making rgb vs. yuv an option
<Marth64>
it's not a lossless conversion but i also can't think of any muxer that wants it in yuv
<Marth64>
maybe force it RGB, log the original YUV in debug and move on
<Marth64>
is what I'm considering
<Marth64>
or better yet put it in a metadata tag so archivists can have it
<kasper93>
why introduce implicit conversions if we can avoid them?
<mkver>
kasper93: Because everyone else expects them in RGB (e.g. the vobsub subtitle format expects RGB).
<Marth64>
i am just thinking from user friendliness level. someone might try to keep the palette as YUV in say, a Matroska file, and realize it doesn't work later. certainly open to opinions. as it stands in current patch, the conversion is explicit but nobody benefits from it unfortunately
<Marth64>
no muxer benefits from YUV* to be exact. like mkver said
<Marth64>
the loss here for the samples I've tested is to me visually lossless, going from one perceptively ugly shade of yellow to the same ugly shade
<jamrial>
wbs: your clang git head fate machines found a lot of issues
hamzah has joined #ffmpeg-devel
<Sean_McG>
how likely are they just compiler issues?
<jamrial>
they are
<jamrial>
those machines use clang git head to find compiler issues
<Sean_McG>
fair enough :)
marcj has quit [Ping timeout: 240 seconds]
<Sean_McG>
looks like some of lavc/h264* made it sick to its stomach
lexano has joined #ffmpeg-devel
marcj has joined #ffmpeg-devel
iive has joined #ffmpeg-devel
<wbs>
jamrial: yes, I've found the faulty commit in llvm and reverted it, tomorrow should be green again hopefully
<BBB>
using ffmpeg to find bugs in clang... from a layman's point of view, that's quite crazy, but I guess it makes sense
<BBB>
fortunately I don't have to bisect clang so I'll just keep standing on the sidelines
<Sean_McG>
amen to that
<wbs>
it's one of the best codebases for triggering optimizer issues
<BBB>
do we have gcc experimental fate machines also?
<wbs>
not that I know of
<BBB>
I think it makes sense for someone (like you) who's somewhat aware of the development ongoings in clang as well as ffmpeg
<wbs>
would be kinda simple to set up, but for it to make sense, someone also would need to monitor it diligently and be able to fix (i.e. bisect, notify/revert) upstream quickly
<wbs>
I don't know what policy GCC has with that. with llvm it's simple - anything broke somewhere, push a revert
agrosant has joined #ffmpeg-devel
<wbs>
if the policy is "don't revert but spend a week discussing what the right fix is", it'd be worse
<wbs>
this time, the bug affected most archs (it was a bug in some vectorizer facility), on aarch64 it triggered failed asserts on build - really easy to notice, you know your build failed. for x86 it built fine but did the wrong thing at runtime; that's one order of magnitude more annoying to sort out. but luckily it was the same issue
<wbs>
and by doing this continuously, any git snapshot (modulo today or other days with breakage) should be fine wrt ffmpeg
<BBB>
I guess uato-vec is relevant for most non-optimized codecs, like koda's 100 different lossless variations etc.
<BBB>
*auto-vec
<BBB>
actually it's probably relevant everywhere but depends on what type of auto-vec
<BBB>
doing this for gcc is one of these "would be nice to have" but "probaly impossible to find a qualified volunteer for"
<BBB>
I agree it's very valuable to have this for clang, provides clear value for both projects
<wbs>
yep. fwiw, I do cover dav1d with nightly clang as well, that shows issues much more seldom as it's a much smaller codebase
<wbs>
but I have found a couple issues there as well
Livio has joined #ffmpeg-devel
<jamrial>
<@BBB> do we have gcc experimental fate machines also? <- every now and then i compile gcc head and run fate
<BBB>
*mind blown*
<BBB>
that's super cool
<Sean_McG>
110%
<BBB>
btw I know wbs has given a talk at vdd in the past on toolchain development. this sort of stuff would be cool to cover, in terms of "here's a clang bug we found one day"
<BBB>
or that sort of stuff
<BBB>
it's nerd-cool
<BBB>
I read somewhere someday that msvc devteam uses ffmpeg internally as one of their internal tests nowadays
<BBB>
(I guess it's a stress-test)
<BBB>
can't easily find it right now, sadly
<frankplow>
FFmpeg is also the quintessential “hairy” (read: difficult to fuzz) application in some fuzzer documentation
<Traneptora>
what makes it difficult to fuzz?
<BtbN>
I'd guess that your input needs to be rather non-random to work at all
<frankplow>
I think large sections of the codebase requiring very particular inputs
<BtbN>
99.99999% of randomized input would likely lead to a very early and unspectacular quit out due to "I got no idea what to do with this"
<BtbN>
or it'd just decode it as mp3
Marth64 has quit [Ping timeout: 264 seconds]
<frankplow>
I think what they mean particularly by "hairy" though, is you have very separate parts of the codebase, which are hard to go between with the typical transformations they apply to the input
<frankplow>
I think it applies to multimedia in general, I remember reading some analysis reckoning it was very improbable the libwebp zero day last summer was discovered through fuzzing
<Lynne>
decoders are best fuzzed using the API, not by invoking ffmpeg.c
<jamrial>
that's what the fuzzers in tools/ do
Marth64 has joined #ffmpeg-devel
<another|>
of
<Marth64>
there is a bug in scte closed captions decoding somewhere
<Marth64>
(unhlpeful statement, i know). i'll try to track it down next week
hamzah has quit [Ping timeout: 250 seconds]
Marth64 has quit [Ping timeout: 264 seconds]
Marth64 has joined #ffmpeg-devel
<Marth64>
How to do the PATCH 0 / "meta" patch thing to have a summary what changed before the actual patches? (so I don't clutter the cummit messages.)
rvalue has quit [Ping timeout: 252 seconds]
<Marth64>
e.g. [PATCH 0/3] i changed xyz blablabla thanks
<Marth64>
nvm think i got it
mkver has quit [Remote host closed the connection]
mkver has joined #ffmpeg-devel
rvalue has joined #ffmpeg-devel
derpydoo has joined #ffmpeg-devel
Traneptora has quit [Quit: Quit]
Traneptora has joined #ffmpeg-devel
<mkver>
Marth64: Actually, comments about a patch are best put between the --- delimiting the commit message and the diffstat.
<mkver>
The cover letter would then only contain comments that apply to multiple patches.
Marth128 has joined #ffmpeg-devel
Marth64 has quit [Killed (NickServ (GHOST command used by Marth128!~Marth128@188.215.95.221))]
Marth128 is now known as Marth64
<Marth64>
mkver: got it ... will stick to that regimen next time
Livio has quit [Ping timeout: 260 seconds]
hamzah has joined #ffmpeg-devel
<BBB>
I do remember the webp zeroday explanation and statements re: fuzzing
<BBB>
that's a fun research area if there ever was one
<BBB>
h264forge comes to mind
elastic_dog has quit [Ping timeout: 246 seconds]
hamzah has quit [Ping timeout: 250 seconds]
elastic_dog has joined #ffmpeg-devel
derpydoo has quit [Ping timeout: 260 seconds]
Marth64 has quit [Remote host closed the connection]