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
<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
<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)
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
<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]
<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?
<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>
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