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
___nick___ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
___nick___ has joined #ffmpeg-devel
___nick___ has quit [Client Quit]
___nick___ has joined #ffmpeg-devel
wyatt8740 has quit [Ping timeout: 265 seconds]
rvalue- has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 252 seconds]
^Neo has quit [Ping timeout: 245 seconds]
rvalue- is now known as rvalue
Marth64 has joined #ffmpeg-devel
wyatt8740 has joined #ffmpeg-devel
wyatt8740 has quit [Ping timeout: 252 seconds]
darkapex has joined #ffmpeg-devel
wyatt8740 has joined #ffmpeg-devel
jamrial has quit []
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 252 seconds]
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 248 seconds]
mkver has joined #ffmpeg-devel
<elenril> mkver: did you have any plans to convert h264 to threadprogress?
<mkver> elenril: Yes.
<elenril> did they go anywhere?
<elenril> or were there any major blockers?
<mkver> The aim was to share H264Pictures directly between threads, just like MPVPicture: https://github.com/mkver/FFmpeg/commit/4a1a3039238dd91f989e3113011e484ce3e22c6d (https://github.com/mkver/FFmpeg/commits/h264_sharedframe/)
<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).
<elenril> grmbl
<elenril> owner needs to die
<elenril> this will need to be resolved somehow for https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2024-November/336003.html
<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
<Lynne> make clean fixed it
System_Error has joined #ffmpeg-devel
cone-561 has joined #ffmpeg-devel
<cone-561> ffmpeg Lynne master:eb8f3b8460dd: hwcontext_vulkan: fix planar RGB images
<cone-561> ffmpeg Lynne master:c918b42dcdb7: vulkan: retrieve Vulkan 1.1 properties
<cone-561> ffmpeg Lynne master:a516b2da2256: vulkan: add support for 10-bit planar RGB
<cone-561> ffmpeg Lynne master:16fa7103402b: vulkan: fix printing descriptors to shader for shaders with no descriptors
<cone-561> ffmpeg Lynne master:1876026f83bd: vulkan: add ff_vk_exec_add_dep_sw_frame
<cone-561> ffmpeg Lynne master:d0ab49e3e74e: hwcontext_vulkan: add the mapped software frame as an upload dependency
<cone-561> ffmpeg Lynne master:91a4f1539fa4: .gitignore: add exclusions for shader .c files
<cone-561> ffmpeg Lynne master:a13ef376dadb: ffv1enc: split off encoder initialization into a separate function
<cone-561> ffmpeg Lynne master:f4b5068c3b66: ffv1enc: expose ff_ffv1_write_extradata
<cone-561> ffmpeg Lynne master:12ea1cde5717: ffv1enc: move plane info init into a separate function
<cone-561> ffmpeg Lynne master:a6c58353ac03: ffv1enc: move slice allocation out of generic encode init
<cone-561> ffmpeg Lynne master:ed2391d3410e: ffv1enc: add a Vulkan encoder
<Lynne> first new encoder ffmpeg has had in a long time?
<Lynne> as usual, go ahead and test it, its surprisingly stable
<Lynne> on my usual vulkan branch is a patch to add support for an RCT coefficient search
<cone-561> ffmpeg Lynne master:970d57988d20: lavc: bump minor version for FFv1 Vulkan encoder
<fflogger> [newticket] wywh: Ticket #11309 ([undetermined] ffmpeg 7.1 fails to write color_primaries and color_trc) created https://trac.ffmpeg.org/ticket/11309
putacho has joined #ffmpeg-devel
microchip_ has quit [Ping timeout: 244 seconds]
Krowl has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
___nick___ has quit [Ping timeout: 260 seconds]
System_Error has quit [Ping timeout: 260 seconds]
Krowl has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
Arnaud1602 has joined #ffmpeg-devel
<fflogger> [editedticket] MasterQuestionable: Ticket #11301 ([avformat] Support "smpl" chunk in WAV) updated https://trac.ffmpeg.org/ticket/11301#comment:1
<fflogger> [editedticket] MasterQuestionable: Ticket #11222 ([avfilter] Suboptimal auto-format selection for filter-chain) updated https://trac.ffmpeg.org/ticket/11222#comment:1
<fflogger> [editedticket] Disjt: Ticket #11301 ([avformat] Support "smpl" chunk in WAV) updated https://trac.ffmpeg.org/ticket/11301#comment:2
cone-561 has quit [Quit: transmission timeout]
ngaullier has joined #ffmpeg-devel
<elenril> Lynne: tests would be nice
<Lynne> yeah, they would, wouldn't it?
<Lynne> is there a way to only test an encoder if its present? afaik we always test everything
<JEEB> yea, we do that for x264 and svt-av1
<JEEB> for example > FATE_ENC_EXTERNAL-$(call ENCDEC, LIBSVTAV1 HEVC, MOV, HEVC_DEMUXER LIBDAV1D_DECODER) += fate-libsvtav1-hdr10
Krowl has quit [Read error: Connection reset by peer]
putacho has quit [Quit: There is no spoon!]
microchip_ has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
microchip_ has quit [Quit: There is no spoon!]
microchip_ has joined #ffmpeg-devel
<nevcairiel> every test is only run if its components are actually build
<nevcairiel> or at least should be, otherwise its technically a bug
<JEEB> yea
microchip_ has quit [Quit: There is no spoon!]
microchip_ has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
<fflogger> [newticket] microchip: Ticket #11310 ([avcodec] [bsf filter] Cannot copy eac3_core) created https://trac.ffmpeg.org/ticket/11310
<fflogger> [editedticket] heleppkes: Ticket #11310 ([avcodec] [bsf filter] Cannot copy eac3_core) updated https://trac.ffmpeg.org/ticket/11310#comment:1
<fflogger> [editedticket] microchip: Ticket #11310 ([avcodec] [bsf filter] Cannot copy eac3_core) updated https://trac.ffmpeg.org/ticket/11310#comment:2
jamrial has joined #ffmpeg-devel
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%
<Sean_McG> (damn thing is LOUD)
Workl has quit [Ping timeout: 252 seconds]
Traneptora has quit [Ping timeout: 264 seconds]
<fflogger> [editedticket] Balling: Ticket #11310 ([avcodec] [bsf filter] Cannot copy eac3_core) updated https://trac.ffmpeg.org/ticket/11310#comment:3
<compnn> :\
Krowl has quit [Read error: Connection reset by peer]
<BBB> very actively maintained :)
psykose has quit [Remote host closed the connection]
psykose has joined #ffmpeg-devel
<wbs> it has mostly moved to github these days though
<wbs> (but it's not extremely active there either TBH)
<compnn> ah yeah ccache does assembler .s files , its been so long since i set it up
<compnn> jamrial, you using ccache ?
<jamrial> yes
HarshK23 has quit [Quit: Connection closed for inactivity]
Krowl has joined #ffmpeg-devel
<Lynne> is there anyone who would be up for helping me getting frame threading for ffv1_vulkan working?
<Lynne> I hacked something up for frame_thread_encoder but it was far too hacky to use sanely
<Lynne> jamrial: maybe you?
<jamrial> no, sorry
Raz- has joined #ffmpeg-devel
averne has quit [Quit: quit]
averne has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
cone-891 has joined #ffmpeg-devel
<cone-891> ffmpeg Rémi Denis-Courmont master:e29432e6bbb6: lavu/riscv: fix compilation without Vector support
<cone-891> ffmpeg Rémi Denis-Courmont master:b75dff0e201e: lavc/h264dsp: fix R-V V weight_pixels pointer arithmetic
<cone-891> ffmpeg Rémi Denis-Courmont release/7.1:20c8a3f5ff83: lavu/riscv: fix compilation without Vector support
Krowl has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
<courmisch> forget nasm, x86 is deprecated
<courmisch> general purpose instruction sets with fewer than 24 GPRs should be illegal
<Lynne> anything that doesn't use x86's addressing model should be illegal
<Lynne> 16 gprs have never actually been an issue in any of my code, thought 8 are definitely too low
ngaullier has quit [Ping timeout: 276 seconds]
<courmisch> the x86 addressing model is a pile of hacks, that should be illegal as well
<courmisch> and desiging boot protocols after x86 too, looking at you UEFI
<Sean_McG> wasn't UEFI originally on Itanium?
<JEEB> I think yea
<courmisch> you're confusing EFI and UEFI
<Sean_McG> oh, OK
<courmisch> though they're both Intel abominations
<courmisch> well, software interfaces defined by hardware companies. That never ended well
<Sean_McG> BTW the recent JPEG2000 changes trigger UBsan on both x86 and ppc
<courmisch> that code obviously needs to be converted to Rust
<pal> Sean_McG: this is getting fixed
<Sean_McG> OK cool
Traneptora has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
<BBB> Lynne: sounds like we want 11 GPRs
<BBB> not 12, that would be too logical, and 13 is n unlucky number
<BBB> so 11 it is?
<BBB> 8)
* Sean_McG sighs
Traneptora has quit [Client Quit]
<courmisch> only logical number is a power of two minus one
Traneptora has joined #ffmpeg-devel
<Sean_McG> so... 4095?
<courmisch> you might have better use for SRAM than that many
<cone-891> ffmpeg Lynne master:66093c5b9449: ffv1enc_vulkan: restrict number of execution contexts to 1
<Lynne> gprs shouldn't exist
<Lynne> CPUs should just convert sequential operations on memory to operations on internal registers and store them as they see fit
<Lynne> going full CISC like its a lisp machine and the year is 1981
<fflogger> [editedticket] Zenitram: Ticket #11310 ([avcodec] [bsf filter] Cannot copy eac3_core) updated https://trac.ffmpeg.org/ticket/11310#comment:4
<Sean_McG> do you want magtape storage back as well?
* Sean_McG runs
<Lynne> zen 2 and 4 had such a system too
<pal> FATE topic: any objection/concerns to adding about 10 MB worth of files to FATE so that FATE tests mimic the conformance tests in the standard?
<Lynne> these days fate samples also get used for fuzzing transparently afaik
<JEEB> I think for AAC and H.264 etc we are utilizing conformance test samples
<Lynne> so you don't want too large samples since fuzzer complexity explodes
<pal> ... the J2K standard specifies conformance in terms of maximum PSNR from source images
<fflogger> [editedticket] microchip: Ticket #11310 ([avcodec] [bsf filter] Cannot copy eac3_core) updated https://trac.ffmpeg.org/ticket/11310#comment:5
<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
<fflogger> [editedticket] courmisch: Ticket #11306 ([undetermined] fate-rv40 fails on RVV) updated https://trac.ffmpeg.org/ticket/11306#comment:3
<fflogger> [newticket] courmisch: Ticket #11311 ([undetermined] fate-ffmpeg-loopback-decoding regression) created https://trac.ffmpeg.org/ticket/11311
rvalue has quit [Read error: Connection reset by peer]
Workl has joined #ffmpeg-devel
rvalue has joined #ffmpeg-devel
Krowl has quit [Ping timeout: 248 seconds]
Chagall has joined #ffmpeg-devel
<Marth64> beat me to ticket. TY
<Marth64> will hold on push on that enum fix
<courmisch> So many CRCs and not one CRC DSP function. Incredible
<cone-891> ffmpeg Rémi Denis-Courmont master:607d4cca8e21: riscv/h264dsp: remove spurious instruction
<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
<Daemon404> hmmmm gitlab ci you say
<JEEB> https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=13315 so these failures were just not visible enough
<kasper93> hmmmm gitlab ci you say
<Daemon404> patchwork emails you doesnt it
<Daemon404> unless that also broke
<JEEB> I was using such wording just in case it didn't email
<BtbN> It can't E-Mail anymore. No idea why.
<JEEB> but yes, it is supposed to email
<Daemon404> glorious
<Daemon404> girlab ci you say...
<kasper93> if the checks are not in the merge pipeline, it is easy to forget/ignore such failures.
<JEEB> kasper93: that
<BtbN> Poardiy just sees a connect and disconnect, no attempt to deliver a mail
<BtbN> no idea what it's doing
witchymary has quit [Remote host closed the connection]
witchymary has joined #ffmpeg-devel
ccawley2011_ has joined #ffmpeg-devel
ccawley2011__ has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 252 seconds]
ccawley2011_ has quit [Ping timeout: 252 seconds]
<jamrial> JEEB, Lynne: https://pastebin.com/raw/QJB2z4b3 this fixes the failures
<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
<fflogger> [editedticket] Balling: Ticket #9569 ([avformat] spdifenc: Unusual frame timing (TrueHD)) updated https://trac.ffmpeg.org/ticket/9569#comment:24
mkver has joined #ffmpeg-devel