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
jamrial_ has joined #ffmpeg-devel
jamrial has quit [Ping timeout: 252 seconds]
guest102 has joined #ffmpeg-devel
<fflogger> [editedticket] yuhongl: Ticket #11158 ([avcodec] "hevc_cuvid" did not correctly decode H.265 video) updated https://trac.ffmpeg.org/ticket/11158#comment:4
iive has quit [Quit: They came for me...]
thilo has quit [Ping timeout: 265 seconds]
thilo has joined #ffmpeg-devel
arch1t3cht3 has joined #ffmpeg-devel
arch1t3cht has quit [Ping timeout: 252 seconds]
arch1t3cht3 is now known as arch1t3cht
\\Mr_C\\ has quit [Remote host closed the connection]
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 265 seconds]
^Neo has quit [Ping timeout: 248 seconds]
Teukka has quit [Read error: Connection reset by peer]
Teukka has joined #ffmpeg-devel
Teukka has quit [Changing host]
Teukka has joined #ffmpeg-devel
jamrial_ has quit []
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 252 seconds]
Sean_McG has quit [Quit: Lost terminal]
zsoltiv has quit [Ping timeout: 252 seconds]
<pross> names_are_hard: see ml for alternate patch that adds dng header to the lj92 frames
Sean_McG has joined #ffmpeg-devel
bilboed has quit [Quit: The Lounge - https://thelounge.chat]
bilboed has joined #ffmpeg-devel
ngaullier has joined #ffmpeg-devel
<names_are_hard> pross: block skipping seems uncontroversial. DNG header as default might not be desirable. As option it's definitely good
<names_are_hard> The main thing people want to do with MLV files is transform them into something that loses no information but allows existing video processing software to handle them
<names_are_hard> We don't use MLV for stills; the cams can natively record stills as raw / bayer format
<names_are_hard> Being able to benefit from efficient ffmpeg decoding / transcoding to video formats would be highly appreciated
cone-133 has joined #ffmpeg-devel
<cone-133> ffmpeg Martin Storsjö master:eb79c316c7b2: fate: Add a dependency on ffprobe for fate-flcl1905
<fflogger> [editedticket] Balling: Ticket #11158 ([avcodec] "hevc_cuvid" did not correctly decode H.265 video) updated https://trac.ffmpeg.org/ticket/11158#comment:5
<fflogger> [editedticket] yuhongl: Ticket #11158 ([avcodec] "hevc_cuvid" did not correctly decode H.265 video) updated https://trac.ffmpeg.org/ticket/11158#comment:6
<pross> names_are_hard: this approach looses/changes no pixel information
<names_are_hard> That's a requirement, so that's good
<names_are_hard> It's a bit tricky for me, because while I'm a dev for ML project, I don't deal with MLV files. I didn't write any of that code, or the ffmpeg demuxer
<pross> about 10 years ago, I wrote the MLV demuxer, hence my interest
<names_are_hard> Hah, okay :) There's one app, MLVApp, which expects MLV files directly. I'm unsure how we should interact with that
<names_are_hard> Would this dng header approach make it easy to deal with mlv files as video, in existing NLE software?
<pross> i am not sure, i have no experience with editing
feiw has quit [Quit: WeeChat 2.8]
guest102 has quit [Quit: Leaving]
<names_are_hard> Have you ever used ffmpegfs? That seemed like a useful approach; we'd like to be cross platform, and editor agnostic
bilboed0 has joined #ffmpeg-devel
bilboed has quit [Ping timeout: 252 seconds]
bilboed0 is now known as bilboed
<names_are_hard> I haven't tested, but I assume ffmpegfs allows on the fly conversion between supported formats. If so, people could config it to do mlv -> some format their editor likes
<pross> sounds novel
<names_are_hard> If the dng header hack worked for that, I think people would be broadly happy (being able to output as bayer as an option would be ideal)
<fflogger> [editedticket] Balling: Ticket #11158 ([avcodec] "hevc_cuvid" did not correctly decode H.265 video) updated https://trac.ffmpeg.org/ticket/11158#comment:7
haihao has quit [Quit: WeeChat 4.1.1]
bilboed has quit [Quit: Ping timeout (120 seconds)]
bilboed has joined #ffmpeg-devel
mateo` has quit [Quit: WeeChat 4.4.3]
mateo` has joined #ffmpeg-devel
mkver has quit [Ping timeout: 244 seconds]
<fflogger> [newticket] skorpion98: Ticket #11346 ([avcodec] signed integer overflow in libavformat/demux.c) created https://trac.ffmpeg.org/ticket/11346
<fflogger> [newticket] skorpion98: Ticket #11347 ([avformat] signed integer overflow in libavformat/rpl.c) created https://trac.ffmpeg.org/ticket/11347
cone-133 has quit [Quit: transmission timeout]
<fflogger> [newticket] skorpion98: Ticket #11348 ([avcodec] signed integer overflow in libavcodec/g723_1_parser.c) created https://trac.ffmpeg.org/ticket/11348
<fflogger> [newticket] skorpion98: Ticket #11349 ([undetermined] signed integer overflow in libavformat/icodec.c) created https://trac.ffmpeg.org/ticket/11349
Raz- has joined #ffmpeg-devel
<fflogger> [newticket] skorpion98: Ticket #11350 ([avcodec] signed integer overflow in libavcodec/h264_parser.c) created https://trac.ffmpeg.org/ticket/11350
<fflogger> [newticket] maxmanus: Ticket #11351 ([undetermined] Native AAC-enocoder doesn't create constant bitrate.) created https://trac.ffmpeg.org/ticket/11351
Raz- has quit [Ping timeout: 244 seconds]
Lynne has quit [Read error: Connection reset by peer]
j45_ has joined #ffmpeg-devel
j45 has quit [Ping timeout: 248 seconds]
j45_ is now known as j45
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
<elenril> brussels arilines thinks a first name must have at least 2 characters
<elenril> and an email address cannot have a + in it
<elenril> stopping public flogging was a mistake
<JEEB> the + not allowed thing is unfortunately common
<fflogger> [editedticket] Balling: Ticket #11351 ([undetermined] Native AAC-enocoder doesn't create constant bitrate.) updated https://trac.ffmpeg.org/ticket/11351#comment:3
<fflogger> [editedticket] maxmanus: Ticket #11351 ([undetermined] Native AAC-enocoder doesn't create constant bitrate.) updated https://trac.ffmpeg.org/ticket/11351#comment:4
<thardin> there we go, a test for the number of seek performed by mov.c
<thardin> let's see that it works with everything but the mov demuxer disabled
<fflogger> [editedticket] maxmanus: Ticket #11351 ([undetermined] Native AAC-enocoder doesn't create constant bitrate.) updated https://trac.ffmpeg.org/ticket/11351#comment:5
^Neo has joined #ffmpeg-devel
^Neo has quit [Changing host]
^Neo has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
Raz- has joined #ffmpeg-devel
^Neo_ has joined #ffmpeg-devel
^Neo has quit [Ping timeout: 246 seconds]
Raz- has quit [Ping timeout: 260 seconds]
Raz- has joined #ffmpeg-devel
<haasn> michaelni: is there a way to run checkasm against a bunch of platforms (loongarch, aarch64, riscv) etc automatically? IIRC submitting patches to the ML used to imply this but it seems that's no longer the case these days
<haasn> maybe we could set up something like a staging git repo with CI runners so that I can create MRs and have them automatically trigger CI jobs on every push before submitting a series to the ML
<haasn> it would certainly remove a lot of the current delay in the send->test->fix cycle
Lynne has joined #ffmpeg-devel
Lynne has quit [Remote host closed the connection]
Lynne has joined #ffmpeg-devel
<michaelni> haasn, patchwork used to test patches automatically, I think BtbN did some upgrades maybe something broke, but i dont remember what it tested, Andriy should know
<michaelni> and yes, we need better automated testing
<michaelni> the easy thing might be just to use github pull requests for testing and set github up to test things
<JEEB> as long as something like qemu works, indeed
<JEEB> I guess macOS runners get you aarch64 at least
<JEEB> loongarch and riscv needs some sort of arch emulation
<JEEB> loongarch is on patchwork but I think it only runs FATE
<JEEB> not checkasm
<michaelni> if github and patchwork dont work conveniently for this, maybe its time for someone (btbn ;) ) to setup forgejo on ffmpeg.org. Really depends on what tool the community wants
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 252 seconds]
<wbs> github has lots of free cpu for runners on the mainstream OSes for this, and I have a github actions config for testing most relevant cases for aarch64, that I refer the regular aarch64 contributors to
<wbs> the three topmost commits on https://github.com/mstorsjo/ffmpeg/commits/gha-aarch64; feel free to use as basis for test matrices for loongarch etc; qemu isn't very fast, but if it's enough to run e.g. checkasm, it's quite ok
<JEEB> :)
<wbs> (to use, just grab that commit and push to your github fork, and check the actions tab. you may possibly need to press some button there the first time to activate it)
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
<haasn> thanks
Sean_McG has quit [Quit: leaving]
<fflogger> [editedticket] Balling: Ticket #11351 ([undetermined] Native AAC-enocoder doesn't create constant bitrate.) updated https://trac.ffmpeg.org/ticket/11351#comment:6
<BtbN> patchwork was still testing patches fine until very recently, haasn, michaelni
<BtbN> just scroll down a bit on the front page, the last few patches still have a few tests
<BtbN> it would seem all runners have died. They are all hosted by third parties
<BtbN> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20241205113026.427482-17-ffmpeg@haasn.xyz/ is the last patch which still had one surviving runner
IndecisiveTurtle has joined #ffmpeg-devel
<JEEB> &22
<JEEB> whoops
mkver has joined #ffmpeg-devel
ngaullier has quit [Remote host closed the connection]
Traneptora has quit [Quit: Quit]
System_Error has quit [Remote host closed the connection]
\\Mr_C\\ has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
zenmov has quit [Ping timeout: 252 seconds]
zenmov has joined #ffmpeg-devel
signalhunter has quit [Quit: Ping timeout (120 seconds)]
signalhunter has joined #ffmpeg-devel
<fflogger> [editedticket] maxmanus: Ticket #11351 ([undetermined] Native AAC-enocoder doesn't create constant bitrate.) updated https://trac.ffmpeg.org/ticket/11351#comment:7
<BtbN> "A good aac encoder should'nt be a big deal in my eyes." dude should go ahead and write one then :D
<wbs> understatement of the century? :P
<Lynne> d'you know, I was compiling ffmpeg today and I was trying to think whether we had a single actually good lossy audio encoder at all
<Lynne> yeah, we do, its the one lossy audio codec with no encoder spec where its impossible to write a bad encoder
<BtbN> It's just not easy to write good audio encoders. Or encoders in general.
<Marth64> i accept it for what it is
<courmisch> aren't our 8-bit and 16-bit PCM "encoders" good?
<courmisch> they loose precision from float, so they're lossy in my book
<courmisch> elenril: trolling me into applying for CC is still trolling
<elenril> successful troll is successful
<BtbN> jamrial: any further comments on the hevc alpha patches? I'd just go ahead and push at least the libx265 one, to get the ball rolling
<jamrial> i replied to the hevc.c one and lgtm'd
<BtbN> Then I sent a v2
<courmisch> elenril: so you admit to sabotaging my NVIDIA blob to prevent me from gaming?
<elenril> which reminds me, I need to review the decoder
<elenril> courmisch: switch to the red team
<courmisch> ain't happening, my little bro just handed me out his RTX2060
<jamrial> BtbN: huh, i don't see
<BtbN> let me double check
<BtbN> I swear I sent it
<BtbN> I also don't see it on Patchwork
<courmisch> elenril: and the true Red team makes only NPU, not GPU, AFAIK: https://e.huawei.com/ph/products/computing/ascend
<BtbN> Oh ffs I sent it to ffmpeg-devel-bounces@ffmpeg.org
<BtbN> hit copy on the wrong address...
<BtbN> It should be on its way now
<jamrial> BtbN: did your mailer mangle the patch? i see a stray whitespace at the beginning of one line
<BtbN> Hm, I just hit "Send as new message" on the copy I sent to myself in Thunderbird
<BtbN> Not entirely impossible Thunderbird then proceeds to mangle it...
<jamrial> i actually see the same thing in the first version
<BtbN> That came from send-email
<BtbN> I see what you mean, but the v1 mail does not have that
<BtbN> https://github.com/BtbN/FFmpeg/tree/nvenc_hevc_alpha_hack patch is on here as well otherwise
funman has quit [Changing host]
funman has joined #ffmpeg-devel
<jamrial> in any case, patch 1/2 looks good
<BtbN> No idea who even maintains the libx265 wrapper
zenmov has quit [Ping timeout: 252 seconds]
zenmov_ has joined #ffmpeg-devel
<JEEB> BtbN: so you always iterate over four planes even if your input AVFrame only has three? basing on that our allocators should be putting nulls/zeroes into data and linesize?
<BtbN> libx265 does not touch the 4th plane at all if alpha is disabled
<BtbN> So it doesn't matter if there's zero or garbage there
<JEEB> yea, that is what one would hope. also did we always allocate N planes worth of stuff in AVFrames?
<JEEB> AV_NUM_DATA_POINTERS it is :)
<BtbN> That's 8 though?
<JEEB> yea, so larger than 4
<JEEB> so it's always there
<fflogger> [editedticket] Balling: Ticket #11351 ([undetermined] Native AAC-enocoder doesn't create constant bitrate.) updated https://trac.ffmpeg.org/ticket/11351#comment:8
<BtbN> Yeah, it has to be compile time static
<BtbN> so there is (and I think always was) at least 4 array elements
<BtbN> not sure where the 8 come from. Some audio format?
<JEEB> yea
<JEEB> then you got extended data for more
<BtbN> I can change it to only iterate to 4 if alpha is enabled, just as extra precaution. Not sure if it's even zero-initialized then
<BtbN> it's a stack variable that's never explicitly zeroed
<JEEB> yea, I think I'd prefer that. also lol at two very similar variables, MAX_SCALABLE_LAYERS and MAX_LAYERS
<BtbN> That's not the best part about those
<JEEB> did they rename or have two separate vars there upstream?
<JEEB> uhhh, not vars but defines
<BtbN> They are in fact two different things
<BtbN> The main problem is... their value depends on configure time defines, that are not exported
<JEEB> vOv
<jamrial> BtbN, JEEB: AV_VIDEO_MAX_PLANES
<fflogger> [editedticket] Balling: Ticket #11014 ([undetermined] ac3 demux and/or decode problem) updated https://trac.ffmpeg.org/ticket/11014#comment:5
<BtbN> So the patch just assumes it's 2 for >=210, which might support alpha layer encoding
<JEEB> yea
<BtbN> Though I have locally changed to just ALWAYS set at least 2
<BtbN> Cause it's the only way to always be safe, and someone swapping libx265.so doesn't explode
<BtbN> i.e. realizing they built it without alpha support, enabling it, but not rebuilding ffmpeg
<BtbN> Since the changed ABI does not change the soname...
<JEEB> yup :D
<JEEB> the ifdeffery is getting messy but that's kind of not our fault (other than us trying to support multiple versions), otherwise by initial look seems fine
<BtbN> We could just defuse the ifdeffery by eventually bumping the minimum version
<BtbN> but so far it ain't tooo bad imo
<fflogger> [editedticket] Balling: Ticket #11351 ([undetermined] Native AAC-enocoder doesn't create constant bitrate.) updated https://trac.ffmpeg.org/ticket/11351#comment:9
<JEEB> yup :)
<BtbN> And is also technically more correct, since there are formats it supports with only 1 component
cone-086 has joined #ffmpeg-devel
<cone-086> ffmpeg James Almer master:d255f9024286: avformat/iamf_parse: add support for expanded channel layouts
<cone-086> ffmpeg James Almer master:21d3dab31c3f: avutil/channel_layout: simplify the 22.2 layout definition
<cone-086> ffmpeg James Almer master:6eb4bf04e921: avutil/channel_layout: add a 9.1.6 layout
<cone-086> ffmpeg James Almer master:cc9843dc33bc: avformat/iamf_writer: add support for expanded channel layouts
<cone-086> ffmpeg James Almer master:b164dea68c27: fate/iamf: add a test for expanded layouts
<cone-086> ffmpeg James Almer master:2d33f66f9ac8: avformat/iamfdec: don't set individual streams as dependent
___nick___ has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
<BtbN> dafuq, I wanted to do one last rounds of testing, and then it suddenly segfaulted when encoding yuva420p10
<BtbN> But only once. Now it works fine again every time
System_Error has joined #ffmpeg-devel
<BtbN> What on earth is that mail that I and virtually every other ffmpeg dev just got? Did AMD/Xilinx just leak some project? All the git repos in there are private.
<jamrial> probably
<jamrial> was wondering the same thing
<BtbN> glad the build is fixed tho
<BtbN> This is madness. It's just not crashing anymore. with the exact same command that crashes minutes ago. Twice.
<wbs> valgrind, asan?
<BtbN> It's crashing inside of libx265
___nick___ has quit [Ping timeout: 248 seconds]
<courmisch> did some test engineer at AMD just spam half of FFmpeg-devel with build logs?
<BtbN> welp, valgrind does not work for me. Illegal instruction in ld-linux oO
<jamrial> try compiling with -O0. --disable-optimizations for ffmpeg, no idea for libx265
<jamrial> and no --arch
<BtbN> This is a Gentoo system fully built with -march=native
<BtbN> If valgrind does not understand AVX512 or something, this will never work
<BtbN> It's also odd where the illegal instruction supposedly is: at 0x401D356: _dl_start (in /usr/lib64/ld-linux-x86-64.so.2)
<BtbN> Which makes no sense. That's during encoder init
<BtbN> At this point I'm ready to class this as cosmic ray type of event
<fflogger> [newticket] Brainiarc7: Ticket #11352 ([avcodec] On the state of FFmpeg's ffv1_vulkan encoder implementation on Intel & NVIDIA) created https://trac.ffmpeg.org/ticket/11352
klaxa_ is now known as klaxa
<BtbN> "Even with identical parameters, the file sizes produced by Intel's and NVIDIA's ffv1_vulkan instances differ significantly." Is not all that odd really
System_Error has quit [Remote host closed the connection]
cone-086 has quit [Quit: transmission timeout]
System_Error has joined #ffmpeg-devel
<nevcairiel> its not? you would think the math in a lossless codec is pretty identical
<BtbN> oh, _ffv1_. I somehow took it as av1
<jamrial> if it's about file size, it could be different compression levels?
<nevcairiel> they said identical settings
<BtbN> It's the same commandline though
<BtbN> So for a fully shader-based implementation, that is VERY surprising