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
psykose has quit [Ping timeout: 256 seconds]
<cosminaught>
is trac down?
stevenliu has joined #ffmpeg-devel
marinko has quit [Quit: Lost terminal]
<jamrial>
cosminaught: no
psykose has joined #ffmpeg-devel
iive has quit [Quit: They came for me...]
psykose has quit [Remote host closed the connection]
psykose has joined #ffmpeg-devel
bcheng has quit [Remote host closed the connection]
bcheng has joined #ffmpeg-devel
<Sean_McG>
Lynne: as someone who will probably never buy an nVidia again, this news is very disappointing
<cosminaught>
at a minimum trac seems to be unreliable, it periodically returns 503s trying to create a new ticket, or sometimes trying to search or sort tickets. Maybe it's running slow and a proxy is timing out
lexano has quit [Ping timeout: 256 seconds]
jamrial has quit []
Kei_N has quit [Ping timeout: 256 seconds]
Kei_N has joined #ffmpeg-devel
AbleBacon has quit [Read error: Connection reset by peer]
Traneptora has quit [Quit: Quit]
Traneptora has joined #ffmpeg-devel
<Traneptora>
Lynne: I'm getting segfaults with vulkan hwdec on nvidia 550
Krowl has quit [Read error: Connection reset by peer]
<haasn>
TIL our av1dec doesn't actually decode av1
<haasn>
it's just a hwdec wrapper
<JEEB>
yea
<JEEB>
that's why forever we had the matrix coefficients bug
<BBB>
:D
jamrial has joined #ffmpeg-devel
cone-066 has quit [Quit: transmission timeout]
Sean_McG has joined #ffmpeg-devel
<haasn>
this awkwardly gives me no way of actually testing this code
<haasn>
given that there's no software capable of producing afgs1 bitstreams (yet) and I don't want to verify a decoder written by me against an encoder written by me (lest they just cancel out each other's bugs)
<haasn>
and we don't have a native av1 decoder I could plug it into
<JEEB>
I made my AV1 side data checking FATE test just require dav1d :<
<JEEB>
but yea if you wrote the dav1d code then \o/
<haasn>
JEEB: wait which fate test is that
<JEEB>
not yet in master
<haasn>
ah
<haasn>
I also have an AV1 side data checking FATE test..
<Lynne>
-25kb binary size right now thanks to deduplication
<jdek>
nice
<mkver>
Nice, but a new subfolder while checkheaders doesn't work in subfolders?
<mkver>
ping elenril on this one
<mkver>
Lynne: The problematic thing with sharing AAC decoder stuff is that we actually have two AACDecContexts, one fixed-point and one floating point. It mostly happens to work, because sizeof(INTFLOAT) is either sizeof(int) or sizeof(float) and also sizeof(AVFloatDSPContext *) == sizeof(AVFixedDSPContext *), but this is not true for AAC_FLOAT; therefore sizeof(ChannelElement) is bigger for the fixed-point decoder.
<mkver>
Besides that, even in case the sizeof coincides it is UB, because the type of AACDecContext is different for the fixed-point caller than for the callee.
<Lynne>
didn't think of that
<mkver>
This is also the reason why deduplicating aacdec is on my "I'll do it tomorrow" stash.
<Lynne>
well, it would be a bit messy, but the float/fixed dsp contexts can be allocated on heap
<mkver>
They already are! Separately, so they don't cause problems.
<mkver>
Everything but the AAC_FLOAT stuff can be fixed by using (anonymous) unions.
<Lynne>
oh, okay, so is the issue with the tmp buffers then?
<mkver>
It's a problem with the sbr.h buffers.
<mkver>
I might have an idea on how to fix the AAC_FLOAT stuff.
<JEEB>
would jpeg files most likely end up as jpeg_pipe when being probed by ffprobe?
<JEEB>
just thinking if image2 or so would pop up :D
<Lynne>
mkver: what did you think of?
<mkver>
Lynne: Luckily, all AAC_FLOATs are only in SpectralBandReplication which is at the end of ChannelElement. So we split this off from ChannelElement and add a new struct, that is equivalent to the current ChannelElement. It will be allocated in the current (templated!) ff_aac_sbr_init where the actual size of it is known.
dionisis has quit [Quit: WeeChat 3.8]
dionisis has joined #ffmpeg-devel
<Lynne>
mkver: want to help with my branch, or should I do that instead?
<mkver>
I am currently writing some patches for this.
<mkver>
Do you insist on the subfolder?
<mkver>
Wait, it is actually quite a lot.
<Lynne>
I don't insist on the subfolder, but I would prefer the subfolder
<Lynne>
my xhe-aac patchset is built on top of this one
AbleBacon has joined #ffmpeg-devel
kasper93_ is now known as kasper93
System_Error has quit [Ping timeout: 260 seconds]
System_Error has joined #ffmpeg-devel
cone-259 has joined #ffmpeg-devel
<cone-259>
ffmpeg James Almer master:ec7937f4a56e: avformat/iamf: remove duplicated function
hamzah has joined #ffmpeg-devel
<Lynne>
mkver: so did you decide?
<mkver>
Yes, I kept your subfolder.
rvalue has quit [Ping timeout: 272 seconds]
* Sean_McG
waves
Poorvagaikar2003 has joined #ffmpeg-devel
<JEEB>
jamrial: there, posted v7 on the ML
j45_ has joined #ffmpeg-devel
compnn has quit [Read error: Connection reset by peer]
j45 has quit [Ping timeout: 268 seconds]
j45_ is now known as j45
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
compn has joined #ffmpeg-devel
<philipl>
Lynne: vulkan hwdec continued to work for me on the new 550 driver. av1 decode doesn't work despite the extension being exposed. I haven't had a chance to dig into why.
<Traneptora>
philipl: h264?
<Traneptora>
JEEB: matrix coefficients bug?
<Traneptora>
is this the one where GBR is marked as yuv444p instead of gbrp?
<JEEB>
av1dec literally used to do matrix_coefficients = primaries
<Traneptora>
oops
<Traneptora>
I still need to take a look at the whole yuv444p for gbr issue
<Traneptora>
av1 spec says that in the case where the matrix coefficients are 0 in the header, it means it's actually rgb, and subsampling is forbidden
<JEEB>
this was the fix
<Traneptora>
but we export it as yuv444p with gbr matrix coeffs, which screws with things
<JEEB>
right, since that and XYZ case require a pix_fmt change
<JEEB>
both are under the identity value for matrix
<JEEB>
so if you have XYZ primaries value it's XYZ, else RGB
<JEEB>
or well, whatever the primaries mean but usually that ends up meaning RGB :)
<Traneptora>
JEEB: the awkward part is I'm not really sure where to assign the pixel format change
<Traneptora>
because hardware formats exist
<Traneptora>
yuv444p with identity matrix has never worked well with ffmpeg and I'm not really sure why. if we could fix that, it would be fine too
<JEEB>
a whole bunch of stuff expects RGB and XYZ pix_fmts, unfortunately
<JEEB>
anyways the logic is a) get pix_fmt descriptor b) check flags for the HWACCEL one c) if hwaccel, sw_format in AVFrame. if sw, format in AVFrame
<JEEB>
the information might already be in the point where pix_fmt is determined originally
<JEEB>
since usually headers come first
<JEEB>
and then bit stream frame start
<jdek>
feel like these doxygen changes would be better served in a branch somewhere and submitted in one go
<Traneptora>
JEEB: issue is that yuv444p with a GBR matrix doesn't seem to work well even when autoconverting to gbrp
<Traneptora>
for example, swscale could theoretically be used to convert yuv444p with id matrix to gbrp without doing much
<Traneptora>
but that doesn't work
<Traneptora>
it also doesn't work with zscale or libplacebo, and I'm not sure why
<cone-259>
ffmpeg James Almer master:194414f62d98: avcodec/av1dec: implement FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM
Poorvagaikar2003 has quit [Ping timeout: 268 seconds]
<philipl>
Traneptora: yes. h264 worked for me. I checked explicitly after seeing the crash reports
<Traneptora>
interesting, I'm not sure why it's crashing for me on git master of everything and nvidia 550
<Traneptora>
rtx 3050 is my gpu, possibly relevant?
<philipl>
Hmm. I updated yesterday and it worked. I'll check more samples tonight.
<philipl>
Traneptora: maybe. There are enough hardware differences that things like this can break on only some models. I've got Ada hardware
<Traneptora>
ah, okay
iive has joined #ffmpeg-devel
<courmisch>
yay, Debian, breaking everything just to support 64-bit time on non-x86 32-bit platforms
<Sean_McG>
\o/
<courmisch>
so like 0.1% of uses
<JEEB>
o_O
<Sean_McG>
well, I mean 2038 is coming sooner than people think
* Sean_McG
runs
<courmisch>
that's not the point
<courmisch>
they specifically stick to 32-bit time on 386
<courmisch>
so all this noise is only for ARMv7. And they break packages on *all* platforms for this.
<Sean_McG>
well hey, look at FreeBSD chucking 32-bit in the dumpster now
<courmisch>
FreeBSD is doing the same as Linux distros: dropping support for 32-bit kernel and leaf packages
<courmisch>
you can still run legacy 32-bit binaries
<courmisch>
coincidentally, that's exactly why Debian keeps 32-bit time on 386 - backward compatibility
<Lynne>
courmisch: apt broke for me and started segfaulting, had to download .debs to fix it
<Lynne>
I'm surprised it took **THIS** long to support
<courmisch>
uh, on amd64, it's really just a change in the name of some library packages
<courmisch>
the SONAME does not change, the ABI does not change (since amd64 had 64-bit all along)
<courmisch>
the problem is that apt gets really confused about the dependencies and wants to remove hafl of the world
<JEEB>
ah that classic
<BBB>
fwiw I've had issues with trac returning errors also
<BBB>
over the past few days
<Sean_McG>
same
<courmisch>
> Trac
ocrete2 has quit [Ping timeout: 256 seconds]
MisterMinister has joined #ffmpeg-devel
<kasper93>
could lavc tag decoded webp images with chroma_loc?
<kasper93>
mpv does limited ? left : center. Which works for most content, jpegs has center. But not really for webp which is also often center. but without getting this info, we cannot really guess
<JEEB>
of course nothing seems to specify it
<JEEB>
anyways, if either a metadata spec, format spec or something like "99% of all implementations when they have to do subsampling do it via this chroma sample location" would lead to some chroma location, we should tag it
<JEEB>
I think the problem mostly is figuring out the basis for that.
System_Error has quit [Remote host closed the connection]
<JEEB>
or if you can see that most browsers etc utilize a library that does YCbCr -> RGB with a specific chroma location always
System_Error has joined #ffmpeg-devel
<JEEB>
that also should be a good enough backup if specification says zero
cone-259 has quit [Quit: transmission timeout]
HarshK23 has quit [Quit: Connection closed for inactivity]
hamzah has quit [Ping timeout: 250 seconds]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
hamzah has joined #ffmpeg-devel
odrling has quit [Remote host closed the connection]
odrling has joined #ffmpeg-devel
hamzah has quit [Ping timeout: 250 seconds]
<kasper93>
JEEB: I agree, though I;m not sure myself, I just got report from user that image created with IM renders incorrectly in mpv
<kasper93>
though IM works with images, so they probably asume center chroma loc always
hamzah has joined #ffmpeg-devel
hamzah has quit [Client Quit]
hamzah has joined #ffmpeg-devel
<JEEB>
I would look at actual production deployments of webp, which for decoding/display is mostly in browsers etc I think. for encoding the reference implementation and some other stuff could probably be checked? probably means you would have to look at the math since they most likely don't spell it out nicely that "oh yea we use XYZ chroma location when going back and forth between 4:2:0 and 4:4:4"
<JEEB>
at least in theory newer formats like HEIF (and any of its sub-formats like HEIC or AVIF) have the capability to note the chroma location (and the video formats themselves default to a specific one). although I do wonder how many image writers actually write that metadata :P
hamzah has quit [Ping timeout: 250 seconds]
<Lynne>
mkver: could you put your patches in a repo so I can pull from them?
kurosu has quit [Quit: Connection closed for inactivity]
Traneptora_ has joined #ffmpeg-devel
<Lynne>
mkver: very nice
<Lynne>
I'm guessing the channel mapping split was a bit too dirty to work from, right?
<mkver>
Which version do you like better?
<Lynne>
I didn't like how I did it either
<Lynne>
I like this one, it's nicer to work from
<mkver>
Your second commit was the first bad one (it moved the allocation of the struct whose size depends upon USE_FIXED to common code which is just not possible).