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
navi has quit [Quit: WeeChat 4.1.2]
mkver has quit [Ping timeout: 256 seconds]
<cone-366>
ffmpeg Michael Niedermayer master:6c5048295143: avfilter/signature_lookup: dont leave uncleared pointers in sll_free()
<cone-366>
ffmpeg Michael Niedermayer master:98ae1ad7cf16: avfilter/signature_lookup: Do not dereference NULL pointers after malloc failure
<cone-366>
ffmpeg Michael Niedermayer master:66f60a235541: avcodec/ac3enc_template: add fbw_channels assert
<cone-366>
ffmpeg Michael Niedermayer master:f465badb062c: avutil/rational: Document what is to be expected from av_d2q() of doubles representing rational numbers
<cone-366>
ffmpeg Michael Niedermayer master:3be80ce299d0: avcodec/indeo3: Round dimensions up in allocate_frame_buffers()
bencoh has quit [Ping timeout: 256 seconds]
MisterMinister has quit [Ping timeout: 272 seconds]
rvalue has quit [Ping timeout: 268 seconds]
rvalue has joined #ffmpeg-devel
<cone-366>
ffmpeg rcombs master:98eeef44aad8: lavf/avio_internal: add ffio_write_lines for line ending normalization
<cone-366>
ffmpeg rcombs master:7bf1b9b35769: lavf/assenc: normalize line endings to \n
iive has quit [Quit: They came for me...]
jdarnley has quit [Remote host closed the connection]
funman has quit [Ping timeout: 260 seconds]
funman has joined #ffmpeg-devel
jdarnley has joined #ffmpeg-devel
thilo has quit [Ping timeout: 256 seconds]
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
thilo has joined #ffmpeg-devel
qeed has quit [Remote host closed the connection]
lexano has quit [Ping timeout: 264 seconds]
Marth64 has joined #ffmpeg-devel
bencoh has joined #ffmpeg-devel
sdc has joined #ffmpeg-devel
<Lynne>
finally started writing the FFT blog post
<Lynne>
it's going to be far too long, and the only people that would care to read it are other hopeless cases that I already talk to
lemourin has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 264 seconds]
Marth64 has joined #ffmpeg-devel
MrZeus has joined #ffmpeg-devel
qeed has joined #ffmpeg-devel
MrZeus_ has joined #ffmpeg-devel
MrZeus has quit [Ping timeout: 260 seconds]
Marth64 has quit [Remote host closed the connection]
jamrial has quit []
sdc has quit [Ping timeout: 256 seconds]
qeed has quit [Remote host closed the connection]
cone-366 has quit [Quit: transmission timeout]
qeed has joined #ffmpeg-devel
<compn>
Lynne, ah theres gotta be one student out there working on an fft homework that would appreciate your technical post
<rodeo>
I might care to read it
<rodeo>
Although I would also need the URL to the blog which I didn’t know of specifically
qeed has quit [Remote host closed the connection]
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 256 seconds]
AbleBacon has quit [Read error: Connection reset by peer]
Marth64 has joined #ffmpeg-devel
averne has quit [Ping timeout: 256 seconds]
averne has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 264 seconds]
Marth64 has joined #ffmpeg-devel
Marth64 has quit [Remote host closed the connection]
Krowl has joined #ffmpeg-devel
blb has quit [Ping timeout: 240 seconds]
blb has joined #ffmpeg-devel
MrZeus_ has quit [Ping timeout: 255 seconds]
Krowl has quit [Read error: Connection reset by peer]
stevenliu_ has joined #ffmpeg-devel
stevenliu has quit [Ping timeout: 264 seconds]
Krowl has joined #ffmpeg-devel
rooisnoek has joined #ffmpeg-devel
rooisnoek has quit [Quit: Leaving]
ccawley2011 has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
<haasn>
I don't know much about the technical details of fft so it might be interesting to me also
<haasn>
mkver: did you have any chance to read my replies to you on the AVCodec.color_ranges series?
<mkver>
Yes, replying to you is on my to-do list.
<mkver>
But I needed to finish the hwcontext stuff first.
<mkver>
Sorry for the delay.
<haasn>
No worries
<haasn>
what hwcontext stuff, out of curiosity?
Krowl has quit [Read error: Connection reset by peer]
<mkver>
See my new patchset.
<mkver>
It intends to remove these AVHWDeviceInternal and AVHWFramesInternal structures to keep the internals out of public headers.
<JEEB>
ah, more cleanup :)
<mkver>
2f9936e446d56f6e8da9f179143d3ac5a4546afc added an AVCodecContext on the stack in a decode callback.
BetweenUs has joined #ffmpeg-devel
<elenril>
naughty
<mkver>
BtbN: Why does AVCUDADeviceContext have its own AVCUDADeviceContextInternal* in its public structure instead of reusing the existing device_priv_size mechanism?
<haasn>
oh, neat
<mkver>
(Or even better: Allocating it jointly with AVCUDADeviceContext (as my new patchset does for all other internal contexts).
<BtbN>
mkver: it might have been because other libraries access that internal struct
<jamrial>
elenril: wtf
<BtbN>
Unless that's possible with the device_priv_size?
<mkver>
It is always possible to avoid the separate allocation, but if this is accessed from other libraries, then the pointer to the struct will stay public.
<elenril>
if other libraries access it, it should not be private
<mkver>
Yeah.
<BtbN>
The stuff that's in that struct is not easily made public.
<BtbN>
If you find a way to do so, go ahead. But specially the cuda_dl functions are a problem.
<elenril>
drop dlopen() support
<elenril>
problem solved
* elenril
runs away from hordes of windows users
<BtbN>
That's straight up impossible
<BtbN>
It's either dlopen or nothing at all
<elenril>
shouldn't be using cuda anyway, it's proprietary and thus evil
<BtbN>
It's only using the driver API for that reason
<elenril>
why did we ever add support for it anyway
lexano has joined #ffmpeg-devel
<Lynne>
transcoding?
<elenril>
overrated
<jamrial>
elenril: can i list the group types the disposition field is *not* meaningful for? because right now it applies to all, and will still after i add the tile grid one
<jamrial>
so right now i'd just add a line that says "this fields applies to all currently defined groups" instead of listing all existing groups
<elenril>
then someone adds a new group and forgets to update the line
<jamrial>
they will either way
<elenril>
I prefer having it explicit, but as you like
<elenril>
can also change the docs when adding a type it does not apply to
<jamrial>
yeah, i can add the "this fields applies to all currently defined groups" line now and then once a group where it doesn't apply shows up we decide what to list
klaxa has quit [Quit: Quit.]
klaxa has joined #ffmpeg-devel
bencoh has quit [Changing host]
bencoh has joined #ffmpeg-devel
sdc has joined #ffmpeg-devel
sdc has left #ffmpeg-devel [#ffmpeg-devel]
Krowl has quit [Read error: Connection reset by peer]
<elenril>
Daemon404: do you have a sample for side data breakage?
MrZeus_ has joined #ffmpeg-devel
<elenril>
hmm, we actually have three sources of side data, not two
<elenril>
possibly four
<elenril>
global container headers, container per-packet, extradata, codec bytestream
<jamrial>
where does extradata get exported as side data?
navi has quit [Quit: WeeChat 4.1.2]
<elenril>
not sure, are there no cases?
<wbs>
if there are changes to extradata during a stream, that gets passed as side data as an extradata change
Krowl has joined #ffmpeg-devel
<elenril>
that does not apply to what we're discussing, which is side data that gets propagated to output frames
<wbs>
ok
<JEEB>
wtf did SMPTE just go public with quite a lot of things o_O
<kierank>
yes
<kierank>
there is a new boss
<JEEB>
yea I just checked that for example 322M is now public?
<kierank>
and he seems to not live in an alternate universe
<JEEB>
niice
<kierank>
i told him directly smpte was the embarassement of the technology industry
<JEEB>
although -20 seems to be uncompressed active video specifically
<kasper93>
the recent version of 2094-2 is also paid (https://ieeexplore.ieee.org/document/10181025), but like I noted in the other channel, most of this stuff is not publicly available
<kasper93>
s/not/now/
<JEEB>
yeh
<JEEB>
your post is where I noticed this originally :) then started poking at various things like 2084/2086 etc
<courmisch>
how did Sweden end up calling brown sugar farinsoker. It's sugar, not flour FFS.
<courmisch>
and Finns not only stupidly copied the name, but violated their own language pronounciation rules in doing so
<Daemon404>
13:15 <@elenril> Daemon404: do you have a sample for side data breakage? <-- yes, i attached it on the trac ticket i just filed
<courmisch>
yes this is off topic but tomorrow is shrove tuesday
<courmisch>
I wish I could troll Kostya's love of Sweden
<thardin>
wut, socker is sugar
<courmisch>
yeah farinsocker. still a stupid name
<courmisch>
farin is latin word for flour
derpydoo has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
<Lynne>
bcheng: I am in a murderous mood towards nvidia right now
<Lynne>
my nvidia shitbox rejects new kernels and refuses to boot, nvidia fucked with their drivers again so they don't compile on 6.6 or 6.7 (everyone's favorite gpl-only symbols), their open modules don't compile due to linking issues
<courmisch>
<insert Torvalds meme here>
epony has quit [Remote host closed the connection]
<courmisch>
incidentally that meme picture was taken very close to my apartment
<Lynne>
I literally only need to test it once, then I'm moving the GPU to my main machine and running nvk, which is up to 1.3
<Lynne>
but I'm on my 9th kernel compilation today
<Lynne>
and somehow even kernel compilation broke now, the build system looks for modules that don't exist
<courmisch>
I only use green blobby drivers from DKMS, not feeling BDSM enough to build them manually
<courmisch>
but of course if you need literal bleeding edge,...
<Lynne>
dkms breaks more often than a fresh up to date nvim install with freshly pulled packages
<courmisch>
dkms breaks maybe once a year on unstable, if you try the newest kernel
<bcheng>
I've never had nvim break so that doesn't say much to me
<courmisch>
whenever that happens I just sit with the previous kernel until the dust settles
<Lynne>
nvim package devs are more fanatical at using bleeding edge features than rust devs when a new release is made
<haasn>
at least you don't depend on gpl-incompatible out-of-tree modules to load your root filesystem
<courmisch>
Rust is unusable without unstable features, as far as I am concerned
* haasn
curses in zfs
MikhailAMD has joined #ffmpeg-devel
MikhailAMD has quit [Client Quit]
<courmisch>
allocator_api stabilisation, any decade
<courmisch>
so Rust releases are pretty much irrelevant then
averne has quit [Quit: quit]
averne has joined #ffmpeg-devel
<courmisch>
elenril: I CAN HAS C11?
<Lynne>
no, C17
<Lynne>
in lieu of c23 not being ready yet
<courmisch>
even I think you should wait for the next Ubuntu LTS and Debian releases to update to C23
<courmisch>
"A client (...) are looking for: 1x network engineer"
<courmisch>
I don't like to be treated as a "1x"
<jdarnley>
They don't have money for a 10x developer?
<Daemon404>
jamrial, btw i found more and different breakage from you :)
<Daemon404>
it specifically checks size if the bug is null
<Daemon404>
buf*
<elenril>
it's happened to me more than once that i needed to rescue a partially working grub install
<haasn>
what I want from my filesystem: logarithmic snapshotting, incremental send, ability to scale up/down as needed (e.g. adding more drives, resizing drives), checksumming/resilvering, atomic writes, split metadata (e.g. metadata & small files on SSD, data on HDD), and hierarchical properties :o)
b50d has joined #ffmpeg-devel
<haasn>
I think that limits it to exactly zfs and btrfs and last time I used btrfs it did not have the administrative tools that zfs did, but that was 5-10 years ago
<jamrial>
Daemon404: no, it only checks size if *data is not NULL
<Daemon404>
jamrial, re-read.
<courmisch>
I'm only using btrfs as a more flexible LVM really
<jamrial>
Daemon404: if (!data) { set size } else if (*data /* not NULL */ ) { check size } else { nothing }
<nevcairiel>
*size is only read once in that whole function, and only if *data is not null
<Daemon404>
jamrial, look at the line i linked
<Daemon404>
if ((!data || *data) && !size)
<nevcairiel>
size is a pointer
<Daemon404>
ack, pointers
<Daemon404>
this commit is still breaking my code (and valgrind)
<Daemon404>
lemme look closer
Krowl has joined #ffmpeg-devel
<Lynne>
I still use ext2 on my /boot, because it lacks journaling
<Lynne>
haasn: bcachefs is now in mainline
<courmisch>
haasn: mkinitramfs is not liking vfat very much
<haasn>
courmisch: dracut works for me
<haasn>
not sure what mkinitramfs is
<courmisch>
the main constituent of Debian's initramfs-tools
b50d has quit [Remote host closed the connection]
<courmisch>
Hello sirs. Can I talk to you about the godly wonders of C11 <stdalign.h> ?
<kierank>
courmisch: does c11 guarantee aligned stack
<kierank>
because then we could remove all these HAVE_ALIGNED_STACK hacks for x86-32
<Lynne>
courmisch: according to c17, c11's stdalign is not portable
<Daemon404>
jamrial, my mistake, must be a newer commit breaking
<courmisch>
Lynne: uh, I think the only "nonportable" bit is use of nonstandard alignments, but that's no worse that what FFmpeg already does
<courmisch>
kierank: that sounds like an ABI issue, not a C language issue
<courmisch>
C11/C17 requires the compiler to align objects, but only from the ABI-specified stack alignment to the typedef alignment
b50d has joined #ffmpeg-devel
<Daemon404>
jamrial, i see whats happened
<Daemon404>
it did break - but was fixed in ffms2, i had not updated
<Lynne>
finally got my second machine to boot, seems like it hates the living crap of having its EFI buffer reused for kernel console, despite the monitor being attached to AMD
<Lynne>
but guess fucking what? nvidia's piece of shit drivers refuse to compile, and their open kernel modules aren't ported yet to 6.8
<Lynne>
I'm not fixing their shit, I hereby officially proclaim that **NO** other implementation of av1_decode exists
<Marth64>
I'm sorry you have to compile nvidia drivers. Difficult experience even with DKMS.
b50d has joined #ffmpeg-devel
<Marth64>
I'm honestly terrified to even update them. I think I withheld the packages from apt
<nevcairiel>
maybe your life would be easier if you didnt use pre-release kernels
deus0ww has quit [Ping timeout: 256 seconds]
deus0ww has joined #ffmpeg-devel
<Traneptora>
JEEB> Traneptora: since you worked on TIFF apparently people want to stick TIFF data into SEI > AHG9: TIFF data SEI message
<Traneptora>
ugh, tiff offsets are a pain
<Daemon404>
find those people
<Daemon404>
and kill them
<Daemon404>
for the greater good
<Traneptora>
it's like ICC profiles but it's relative to the beginning of the file, not relative to the beginning of the relevant block
<Traneptora>
so you can't move them around, unlike ICC profiles
<Daemon404>
why would you want tiff in an sei
<Daemon404>
idgi
<Marth64>
horror
<JEEB>
Daemon404: no idea why but jvet experts document listing has stuff like that in there :D
<Marth64>
SEI evil vector for vulnerabilities and hacks
<JEEB>
apparently they want to add all of the major image metadata header formats into SEI
<JEEB>
apparently InterDigital decided that having those separately specified (and having to refer to non-SDO bodies like CIPA and JEITA) is not a bad idea
<JEEB>
*is a bad idea
<JEEB>
so the one I linked is just "JPEG segments"
<JEEB>
conveniently stuffing "what is there inside" under the rug :D
<JEEB>
> This contribution proposes specifications for the carriage of popular image metadata formats in SEI messages to facilitate access to additional information about the content source and context of image the capture process for use by, e.g., generative AI applications.
<JEEB>
NNs everywhere
<JEEB>
apparently tencent wrote that proposal and then interdigital just went for "why define those when you can just put generic JPEG blocks in there ^_^"
<Daemon404>
sounds like someone had to justify their job to the execs
<Daemon404>
sure boss im woking on AI
b50d has joined #ffmpeg-devel
<Lynne>
6.7 doesn't work either
Krowl has quit [Read error: Connection reset by peer]
b50d has quit [Remote host closed the connection]
<Marth64>
Lynne: not sure if it will help, but in the past I had used SR-IOV to pass the card to a VM in order to troubleshoot driver issues with sanity
<Marth64>
requires compatible CPU and a spare GPU but yeah
<Marth64>
i am nowhere near educated on this as you are just a suggestion
<BtbN>
Does the kernel/driver HAVE to be such bleeding edge?
<Lynne>
the driver has to be, since it's what implements av1
<BtbN>
I'd just stick to an LTS kernel then
<Lynne>
the kernel no, but it's weird, I've used the exact kernel version before with no issues
<BtbN>
And I _think_ the GPU open module is still quite incomplete
<Lynne>
I've used that before too, it works just fine
<Marth64>
happy to test stuff for you if needed, i have an ada card
<Marth64>
and a turing somewhere
<BtbN>
For decoding, you don't even need that recent of a card
<Lynne>
I'll give 6.4 a try
<Marth64>
i have 6.5 and no issues decoding av1 nvdec
<Marth64>
driver 525.147.05
<Marth64>
but i am also not on wayland so idk if that changes things
<BtbN>
nvdec/cuda is fully headless in itself
<Marth64>
ahh
<Lynne>
I don't even run anything display related on the machine
<Lynne>
"error: initialization of 'int (*)(struct drm_gem_object *, struct iosys_map *)' from incompatible pointer type 'void * (*)(struct drm_gem_object *)' [-Wincompatible-pointer-types]"
<Lynne>
still the same
<BtbN>
looks like the kernel changed some callback and backported the patch
<Lynne>
yeah... in 2020!
<BtbN>
that seems unlikelz
<Lynne>
that's what it says
<BtbN>
Then they changed something else that breaks the check for it
<Lynne>
something's causing the drivers to pick that antique path
<Lynne>
NV_DRM_GEM_OBJECT_VMAP_HAS_MAP_ARG fails
<BtbN>
sounds like the check is written the wrong way around really
<Marth64>
i thought dkms deals with this and you can give it header path for kernel you want
<Marth64>
it has been long time since i've touched it
<BtbN>
The configure script of the module deals with it
<BtbN>
dkms just compile modules
<BtbN>
And apparently something changed that broke it
<Marth64>
got it
<Marth64>
frustrating
<BtbN>
just normal things for out of tree modules
<BtbN>
look at why it fails, and patch it
<BtbN>
can't be that big of a change
<Lynne>
"could not insert module ... Unknown symbol in module"
<BtbN>
dmesg will have details
<Lynne>
**now I remember**, there was a specific loading order
<BtbN>
that's not normally something you need to care about
<BtbN>
modprobe resolves dependencies
<Lynne>
I use the open modules which don't get that, you have to manually load them
<BtbN>
yes, with modprobe
<Lynne>
"Failed to initialize NVML: Driver/library version mismatch" hahahaha, it never ends
Marth64 has quit [Ping timeout: 256 seconds]
<BtbN>
Did you grab the module from github or something?
<Lynne>
oh, right, wrong open modules version
<BtbN>
The modules have to match the driver exactly sadly
Marth64 has joined #ffmpeg-devel
<elenril>
I'm so happy to be rid of this shit after moving to an amd gpu
<BtbN>
The experience with AMD GPUs isn't much better
<Marth64>
yeah i do remember that, everything has to match
<BtbN>
At least with Nvidia GPUs you only have to deal with one driver
<elenril>
my experience with AMD GPUs certainly is MUCH better
<BtbN>
AMD you got to pick one of three, and on each of them other stuff doesn't work
<Lynne>
amdgpus are fine if you stick to opengl or don't run your own code
<Lynne>
and very very disable adaptive sync
<BtbN>
I had an AMD GPU for about a month, and had nothing but issues
<BtbN>
They are far from the promised land.
<BtbN>
Nvidias stuff is horribly proprietary, but you can't say it doesn't work
<Marth64>
i've found AMD to be extremely picky on chipset
<Marth64>
if it's happy it's happy, if it's not random weird panics
<BtbN>
On Windows, every time I updated the driver, I had to reboot. Cause it forgot how to output red each time.
<BtbN>
Weirdly specific, but happened consistenyl
<Lynne>
"No devices were found"
<Lynne>
oh, rm_init_adapter failed, of course
<Lynne>
right, OpenRmEnableUnsupportedGpus must be enabled
<Lynne>
finally, it works!
ccawley2011 has quit [Read error: Connection reset by peer]
BetweenUs_ has joined #ffmpeg-devel
BetweenUs_ has quit [Client Quit]
BetweenUs has quit [Read error: Connection reset by peer]
psykose has quit [Remote host closed the connection]
<Lynne>
jkqxz: green screen on nvidia
<Lynne>
at least it doesn't crash in the nvidia drivers
b50d has joined #ffmpeg-devel
<Lynne>
but they did the implementation with their own closed source av1 decode test program, and in the past they've had strong (and incorrect opinions, it took 3 vendors and a reading of the h264 spec at a meeting to convince them otherwise) opinions on bitstream values
<Lynne>
so I still wouldn't count them in
<Lynne>
IIRC they did say they'll release another beta driver which will fix isses they identified with their implementation "soon"
<Lynne>
but still, what now?
<bcheng>
Lynne: FYI, your current handling of pTileOffsets is broken. ap->tile_offsets is populated by ff_vk_decode_add_slice after the pointer is copied to pTileOffsets, so the driver ends up recieving pTileOffsets = NULL
<bcheng>
Was gonna point this out with a more throuough review later but just to prevent ur headache now
HarshK23 has joined #ffmpeg-devel
b50d has quit [Remote host closed the connection]
b50d has joined #ffmpeg-devel
b50d has quit [Remote host closed the connection]
b50d has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
epony has joined #ffmpeg-devel
<Lynne>
bcheng: thanks
<Lynne>
fixing that leads to... a segfault in their drivers
Marth64 has quit [Ping timeout: 264 seconds]
Marth64 has joined #ffmpeg-devel
<courmisch>
hmm, why are checkasm blockdsp tests not showing?
cone-943 has joined #ffmpeg-devel
<cone-943>
ffmpeg sunyuechi master:0748d2bbc79a: lavc/blockdsp: R-V V clear_block
<mkver>
When I wrote this, I actually wanted to apply this after the typical waiting period and not wait for a bump (after all, only a fork ever used these, and we don't care about breaking a fork), therefore it was not a reply to your bump series.
cone-943 has quit [Quit: transmission timeout]
Marth64 has quit [Remote host closed the connection]