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
Everything has quit [Ping timeout: 246 seconds]
<fflogger>
[editedticket] MasterQuestionable: Ticket #8385 ([avformat] libavformat/aviobuf: A part of conditional expression is always true: whence != 2) updated https://trac.ffmpeg.org/ticket/8385#comment:6
rvalue- has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 252 seconds]
rvalue- is now known as rvalue
<Lynne>
the bitexact flag should definitely not be used by any DSP code
witchymary has quit [Remote host closed the connection]
witchymary has joined #ffmpeg-devel
witchymary has quit [Remote host closed the connection]
witchymary has joined #ffmpeg-devel
cone-544 has quit [Quit: transmission timeout]
wyatt8740 has joined #ffmpeg-devel
thilo has quit [Ping timeout: 252 seconds]
thilo has joined #ffmpeg-devel
arch1t3cht1 has joined #ffmpeg-devel
arch1t3cht has quit [Ping timeout: 252 seconds]
arch1t3cht1 is now known as arch1t3cht
<fflogger>
[editedticket] Balling: Ticket #8385 ([avformat] libavformat/aviobuf: A part of conditional expression is always true: whence != 2) updated https://trac.ffmpeg.org/ticket/8385#comment:7
<fflogger>
[editedticket] Balling: Ticket #8385 ([avformat] libavformat/aviobuf: A part of conditional expression is always true: whence != 2) updated https://trac.ffmpeg.org/ticket/8385#comment:8
<mkver>
The problem was that H.264 not only uses "owner" to set the owner of different fields, but also uses it to check whether a a field is completed or not (line 1451 in h264_slice.c).
<mkver>
The ref_poc also seems weird; when not using frame threading, ff_h264_direct_ref_list_init() is called for every slice, but when using frame threading, it is no longer called after update_thread_context.
<Lynne>
weird, the latest dirac_obmc fixes break checkasm for me
Krowl has quit [Read error: Connection reset by peer]
Arnaud99 has joined #ffmpeg-devel
Arnaud1602 has quit [Quit: Client closed]
Krowl has joined #ffmpeg-devel
Sean_McG has quit [Quit: Lost terminal]
paulk-bis has quit [Quit: WeeChat 3.0]
paulk has joined #ffmpeg-devel
paulk has quit [Changing host]
paulk has joined #ffmpeg-devel
<jamrial>
BBB: if you're ever bored, one thing you could do is try to split libavcodec/x86/vp9itxfm.asm into two or more files
<jamrial>
because right now, it alongside libavutil/x86/tx_float.asm take more time to assemble than every other file takes to compile if you run make with several jobs :p
<BBB>
hm... yes
<BBB>
if I'm ever to touch that code, I'd likely A) split it per instruction set, and B) implement 2ds like in dav1d, instead of ricing it
<BBB>
vp9itxfm is the worst, but generally speaking, vp9*.asm is overly riced
<jamrial>
the rising was nice, right? it make your vp9 decoder the fastest
<jamrial>
s/make/made
<BBB>
the fastestest everest
<BBB>
I can make it a goal for sometime in the near future
Arnaud99 has quit [Quit: Client closed]
mkver has quit [Ping timeout: 255 seconds]
DauntlessOne has quit [Remote host closed the connection]
<Daemon404>
clearly you should add parallelism to nasm instead
Sean_McG has joined #ffmpeg-devel
<compnn>
nasm-cache
DauntlessOne4 has joined #ffmpeg-devel
<compnn>
do people still use ccache?
<Sean_McG>
I do, it makes a lot of difference on my G5
Workl has joined #ffmpeg-devel
Krowl has quit [Ping timeout: 245 seconds]
<Sean_McG>
getting an actual physical machine helped too, went from 2+ hour FATE runs to a little over 30 minutes
<Lynne>
I don't, its never made anything faster in my experience while working
<Lynne>
meson uses it by default, I think, though
<wbs>
it's very much essential if working on llvm, where compiling the tree can take multiple hours. you don't want to wait 2 hours before continuing, if you check out a branch that ends up touching a central header that requires rebuilding every file
Krowl has joined #ffmpeg-devel
<wbs>
(like, if you change such a file you obviously will need to rebuild anyway, but with ccache you can check out the previous state and rebuild quite quickly)
<Sean_McG>
got a bit of a scare this morning, had a kernel upgrade on it and after rebooting the fans cranked to 100%
<pal>
... this is important in the case of J2K because the standard does not mandate a specific fixed point implementation for dequantization
<pal>
... and so, for example, the FFMPEG J2K decoder results in slightly different results on 32 and 64 bit platforms (apparently_
<Lynne>
then the assembly is wrong, I've said it before, non-bitexact DSP code simply shouldn't exist
<Marth64>
Speaking of fate. Is tests/data/fate/ffmpeg-loopback-decoding.err failing for anyone else? -> [ffv1 @ 0x646467a3db00] Invalid version in global header
<Sean_McG>
yes
<Sean_McG>
32- and 64-bit PPC anyways
<Marth64>
x86 here
<Marth64>
x86_64*
<Sean_McG>
also my x86_64 Address Sanitizer node
Traneptora has quit [Quit: Quit]
Krowl has joined #ffmpeg-devel
<courmisch>
Marth64: it fails on the glorious RISC-V of the future too
<Sean_McG>
also some vsynth1-ffv1-* tests
<courmisch>
FATE has not seen a successful full run in the past twelve hours on anything
<courmisch>
Lynne: that DSP is using floats, so it's bound to vary. Though I agree that varying between bitness is dubious
<JEEB>
yea, that did raise my eyebrow as well
<JEEB>
I was OK with "different implementations"
HarshK23 has joined #ffmpeg-devel
<Lynne>
courmisch: I did try to add an API for lavu/crc at a few points, but decided I had something better I could be doing
<courmisch>
also, fun fact, checkasm does not test the supposedly bit-exact version
Krowl has joined #ffmpeg-devel
<Chagall>
I can't get past the ffmpeg-loopback-decoding test case when trying to run FATE locally, the ffv1 decoder complains about an invalid version in the global header. Has anyone seen this before?
<courmisch>
Even Linux has CRC DSP!!! So lamez
<courmisch>
Chagall: everyone is seeing it for the past half day
<cone-891>
ffmpeg Brad Smith master:f3eca3f38709: libavutil/riscv: Make use of elf_aux_info() on FreeBSD / OpenBSD riscv
Workl has quit [Ping timeout: 260 seconds]
<Chagall>
courmisch: oh right I see the failures on fate.ffmpeg, thanks
Krowl has quit [Read error: Connection reset by peer]
<pal>
Lynne: the files would be used to compare against the output of the decoder, not as an input to the decoder, so it should no impact on the fuzzer
<JEEB>
91a4f1539fa40db12b08d97e88ab7e031ae40bdd still has loopback work
<JEEB>
a6c58353ac033798fb799cd761e6a78b4fb12d60 is broken, so time to step back
<JEEB>
ok, so literally going one back to 12ea1cde571757ff7219d40eb478f3f8d5f7a371 made it work
<JEEB>
so a6c58353ac033798fb799cd761e6a78b4fb12d60 is the culprit?
<courmisch>
a13ef376dadb1410deb12c5b153bf3d5a781d431 is the test-suite-completion-challenged change
<JEEB>
fate-ffmpeg-loopback-decoding works in 12ea1cde571757ff7219d40eb478f3f8d5f7a371 still here
<JEEB>
focused on that one for now
<JEEB>
just in case, make clean it is
<JEEB>
still succeeds
<JEEB>
and then a6c58353ac fails
<JEEB>
so I'd say a6c58353ac is the turning point for the loopback test
<JEEB>
and yea, `git revert a6c58353ac033798fb799cd761e6a78b4fb12d60` makes that test pass again
<courmisch>
about jp2k, not sure if 32-bit multiply-add is faster than a single widening multiply
<courmisch>
and even less so shift-multiply-add instead of single widening multiply
<JEEB>
right, just looking at the diff the fact that it was in an else was missed in the commit
<JEEB>
for whatever reason I cannot just `curl -L "URL" | git apply` that patch to verify it locally, but given that this re-adds the condition that was there as the else, LGTM
<another|>
pastebin.com converts ALL line endings to CRLF aka \r\n
<cone-891>
ffmpeg James Almer master:d6b39373a23c: avcodec/ffv1enc: restore header writing behavior for version > 1
<Daemon404>
... why
<Daemon404>
is pastebin on windows servers
<JEEB>
I've seen that with a few things, including perl based cgi-bin
<another|>
dunno. but this is why you should never use pastebin.com for any code
<another|>
personally I just never use it. there are tons of other, saner paste services
<Marth64>
jamrial: TY
ccawley2011 has joined #ffmpeg-devel
ccawley2011_ has joined #ffmpeg-devel
ccawley2011__ has quit [Ping timeout: 276 seconds]
ccawley2011 has quit [Ping timeout: 248 seconds]
ccawley2011_ has quit [Ping timeout: 252 seconds]
soleil has joined #ffmpeg-devel
<cone-891>
ffmpeg Eugene Zemtsov master:e9c3698ed23a: avcodec/decode: Fix incorrect enum type used in side_data_map()
soleil is now known as msoleil
msoleil has quit [Remote host closed the connection]
msoleil has joined #ffmpeg-devel
msoleil is now known as msooleil
msooleil has quit [Remote host closed the connection]
<BtbN>
Hm, the more I dig into the mail issue, it seems like Patchwork is simply not sending the mail
<BtbN>
it connects to the mailserver, successfully. And then disconnects again, cleanly.
Everything has joined #ffmpeg-devel
System_Error has quit [Ping timeout: 260 seconds]
<compnn>
lol
<thardin>
TIL GIMP does not support writing the tRNS chunk in PNG, for RGBA palettes
<thardin>
or at least the version I'm using doesn't. seems to read them fine though
iive has joined #ffmpeg-devel
<fflogger>
[editedticket] Balling: Ticket #11307 ([avcodec] [truehd_core] Application provided invalid, non monotonically increasing dts to muxer in stream 0) updated https://trac.ffmpeg.org/ticket/11307#comment:2
secondcreek has quit [Remote host closed the connection]
secondcreek has joined #ffmpeg-devel
<fflogger>
[editedticket] Balling: Ticket #10948 ([ffmpeg] [ffmpeg] spdif: Unusual frame timing 40 samples/frame is not implemented.) updated https://trac.ffmpeg.org/ticket/10948#comment:3