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.0 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
System_Error has quit [Remote host closed the connection]
_whitelogger has quit [Ping timeout: 260 seconds]
_whitelogger has joined #ffmpeg-devel
<elenril>
sigh, is mbedtls full of global state now as well
<elenril>
it didn't seem to have any when I looked at it a few years back
<JEEB>
Lynne: I'll try to get to it
<JEEB>
the zlib-ng thing is just annoying me
<JEEB>
*zlib-ng FATE failures are
<JEEB>
since it's something that it's something fixable by removing bitexactness for the full files in various tests (as it doesn't seem to be helping check what the tests actually are testing)
<nevcairiel>
make a configure test for bitexactness, blacklist otherwise, let fedora figure it out :P
<JEEB>
just disable the header for specific transcode tests
<JEEB>
the one which logs exact packet sizes is harder
<JEEB>
and yea I thought how to check whether the zlib development files come from zlib-ng in case it would be a useful check
<nevcairiel>
its funny how more files get bigger then smaller, and those that get bigger also get bigger by a lot more then theo thers get smaller
<nevcairiel>
why exactly are they doing this? :P
<JEEB>
nevcairiel: so far the two notes were "plz write our internal zlib replacement" and "can we try no-compression mode?", where the first one isn't something I want to do and the second one would stop testing code paths actually utilized by end users
System_Error has joined #ffmpeg-devel
<JEEB>
elenril: how did they end up regressing like that?
<elenril>
reads very much like "I can't be bothered to do things correctly"
ngaullie has joined #ffmpeg-devel
<nevcairiel>
i was about to say that after skimming through it
<JEEB>
nevcairiel: and yea, the defaults or whatever we utilize seem to be doing funky stuff in zlib-ng, which is touted as having more SIMD and more compression
<JEEB>
(also they seem to believe that they will have their own superior API and being able to remove the zlib compat API, but "lol" is all I can say for that)
<JEEB>
so many old apps use zlib
<nevcairiel>
even new stuff is unlikely to use a replacement API until such a point where its available _everywhere_
<nevcairiel>
the benefit seems dubious
<JEEB>
yea
ngaullier has joined #ffmpeg-devel
ngaullie has quit [Ping timeout: 268 seconds]
<llyyr>
nevcairiel: do I need to resend the vp9 update_map/segmentation switch patch with a comment?
<nevcairiel>
that might be easier to get a final confirmation
Krowl has quit [Read error: Connection reset by peer]
mkver has joined #ffmpeg-devel
<llyyr>
nevcairiel: should we also reset the temporal field?
<nevcairiel>
not sure if its required, but maybe cleaner to do both
<llyyr>
yeah
<llyyr>
nevcairiel: sent a new one
IndecisiveTurtle has joined #ffmpeg-devel
feiwan1 has quit [Ping timeout: 264 seconds]
feiwan1 has joined #ffmpeg-devel
<llyyr>
I replied to a reply to it but I don't see it anywhere, how can I check if Thunderbird managed to not shit itself or not?
cone-141 has joined #ffmpeg-devel
<cone-141>
ffmpeg Andreas Rheinhardt master:35e7fa0a2e6d: avfilter/af_atempo: Properly check av_tx_init()
<cone-141>
ffmpeg Andreas Rheinhardt master:ece95dc3dc82: avfilter/af_atempo: Fix indentation
<cone-141>
ffmpeg Andreas Rheinhardt master:42e0e05834ba: avfilter/af_atempo: Simplify resetting
<mkver>
llyyr: I received your reply
<llyyr>
is there a list you can spam just to set stuff up and confirm things actually work? I have no idea if everything is misconfigured or gmail sucks or thunderbird sucks or all of the above
<mkver>
And IMO, you should just have sent a v3 instead of asking me what to do.
<llyyr>
I have no idea if it's bad manners to send a new version of a patch just to fix a url in the commit description
<JEEB>
it's not, people who have commit access often also note that they will just fix that locally (and thus if the thing is otherwise OK it will be fixed in the pushed version, otherwise you get next version which then will have that fix included)
<JEEB>
or the person applying does that change if they are OK with it
<courmisch>
wild elenril spotted on ML.
Gramner has quit [Ping timeout: 256 seconds]
Gramner has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
<jamrial>
>the RPU syntax has been extended in an as of yet undocumented way
<jamrial>
wtf
paulk has joined #ffmpeg-devel
paulk has quit [Changing host]
paulk has joined #ffmpeg-devel
kurosu has joined #ffmpeg-devel
IndecisiveTurtle has quit [Ping timeout: 255 seconds]
<JEEB>
jamrial: the whole thing is without a real spec, it's all been figured out through various documents on the interwebs. quietvoid is another person who's been implementing it.
<JEEB>
I think even D internally for the longest time didn't have a "spec" for RPUs
<jamrial>
i see
<quietvoid>
afaik there's just the verifier and some patent that mention it
<quietvoid>
i've been waiting for more info but nothing, so maybe i'll copy ffmpeg naming when it's merged
<BBB>
jamrial: my personal opinion is that it's better to branch within the function rather than having a table of functions
<BBB>
jamrial: re:vvc_sad
<jamrial>
BBB: with the table i was able to not only remove one branch from the smallest widths but also reduce gpr usage
<BBB>
yes, but the table itself leads to more complex c code that you're not accounting for
<BBB>
(in the caller)
<jamrial>
the table index is calculated once for a function that's called >20 times in dmvr_mv_refine()
<sdc>
why I not have had that error? is this a nasm/yasm thing?
<jamrial>
sdc: yasm 1.3.0 specifically
<nevcairiel>
shouldnt use yasm anymore, its a dead project now unfortunately
<sdc>
ahh okay I'll have to check that next time then, thank you!
acidtonic has joined #ffmpeg-devel
<acidtonic>
(originally posted in wrong room) If I pass av_frame to another thread and unref/free it there is that safe?
<acidtonic>
trying to track down a tearing problem with h264 rendering when the threads get loaded. I think it may be that I send the frames to another thread for rendering/unref/destruction.
cubicibo has joined #ffmpeg-devel
qeed_ has joined #ffmpeg-devel
qeed has quit [Ping timeout: 252 seconds]
<Lynne>
yes, unreffing is all safe
<acidtonic>
is it safe if there become multiple av_frames alive if the rendering thread slows down? It almost seems as if the memory is trashed if the rendering lags. I am using the hardware cuda decoder and going thru sw_scale if it matters. I free the sw_frame after copying everything to a bgr_frame that I pass along. Still sound okay?
<acidtonic>
obviously I keep the lag from being more than a few frames behind by catching up the renderer but curious
<JEEB>
acidtonic: fyi the #ffmpeg channel is correct for developing with FFmpeg. development within the FFmpeg project is what this channel is generally for :)
<acidtonic>
oh my apologies, I figured the opposite
<JEEB>
Lynne: I'll go do a jog, will then try to check out your branch
<JEEB>
(it's probably linked in some of your patch sets)
Krowl has quit [Read error: Connection reset by peer]
AbleBacon has joined #ffmpeg-devel
cone-811 has quit [Quit: transmission timeout]
ngaullier has quit [Quit: Leaving]
<JEEB>
Lynne: thanks
Krowl has joined #ffmpeg-devel
cubicibo has quit [Quit: Client closed]
ccawley2011 has quit [Ping timeout: 256 seconds]
q66 has quit [Ping timeout: 260 seconds]
ccawley2011 has joined #ffmpeg-devel
q66 has joined #ffmpeg-devel
<jdarnley>
Perhaps one of you people can answer this. Is it possible to get nvcc installed without an oversized driver package or installing an entire gui on a server?
<JEEB>
is that the cuda compiler?
<jdarnley>
yeah I think so
<JEEB>
if yes, we in FFmpeg default to clang for cuda compilation :)
<JEEB>
so you don't need nvcc for cuda
<jdarnley>
This isn't for ffmpeg but maybe I'll see if I can trick it.
<JEEB>
looking at nvidia's driver PDFs it also seems like nvcc to begin with bases on clang :D
<JEEB>
so yea, I'd expect for compilation it would work. closed source SDK is a separate thing, though
System_Error has quit [Remote host closed the connection]
<jdarnley>
A tool straight from NVIDIA is probably gonna need that
<jdarnley>
Even if it doesn't go anywhere near a video card
qeed_ has quit [Quit: qeed_]
qeed has joined #ffmpeg-devel
<BtbN>
You very much need the CUDA SDK to get nvcc
uau has quit [Remote host closed the connection]
uau has joined #ffmpeg-devel
AbleBacon has quit [Read error: Connection reset by peer]
System_Error has joined #ffmpeg-devel
<jdarnley>
yeah that seems to be what I read online
Dariusz has quit [Ping timeout: 252 seconds]
novaphoenix has quit [Quit: i quit]
novaphoenix has joined #ffmpeg-devel
canjar has joined #ffmpeg-devel
novaphoenix has quit [Quit: i quit]
novaphoenix has joined #ffmpeg-devel
dellas has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
TheSashmo has quit [Quit: Leaving...]
iive has joined #ffmpeg-devel
qeed_ has joined #ffmpeg-devel
qeed has quit [Ping timeout: 264 seconds]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
<JEEB>
Lynne: looking at bsOutputChannelPos and I think I'm getting flashbacks related to channel mapping mess.
<JEEB>
since we are based on WAVE dwChannelMask for the stuff that fits within it, but then trying to translate back&forth into spec related naming scheme
<Lynne>
yeah, I can't blame you, but I'm reasonably confident in it now
<Lynne>
with doing it canonically and then switching the layout to native
<Lynne>
the two missing ones are suspicious, do you think I should add them to channel_layouts.h?
<JEEB>
I think those may be added. funny enough even Apple doesn't define Lvs|TpLS and Rvs|TpRS
<JEEB>
while it has a metric crapload of everything else
<JEEB>
but yea, the "ugh, so which one is this in reality" starts already with Ls|Rs (4,5) :D
System_Error has quit [Remote host closed the connection]
<JEEB>
anyways will check 13-16
dellas has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
<JEEB>
Lss was already part of 22.2 so I wonder how I mapped that in 2020
<JEEB>
oh right there were some new 7POINT1 things added
<JEEB>
so 22.2 is now 7POINT1POINT4 based :)
<JEEB>
*7POINT1POINT4_BACK
<JEEB>
which is 7POINT1 with top channels added
<JEEB>
thank goodness I did it in a simple/dumb way in 34de0abbe71fa90e874ff902200e5c6c466ba2f6
<JEEB>
since 22.2 used to be matching with 5.1
<JEEB>
or well, it matches up until 5.1 with "standard" 5.1
<JEEB>
so that's what I based off, and anything further from that came in order
<Lynne>
so what should I change? 4/5 s/SIDE/BACK?
<JEEB>
wait a bit, I'm trying to unmangle the different namings :D
<JEEB>
because IEC BL/BR are then 9/10 for all the funzies
<Lynne>
alright, send me a diff
<Lynne>
also, there are new preset channel layout indices that used to be reserved
<Lynne>
Table 73
<JEEB>
yea
<JEEB>
1-7 should in theory be the same as MPEG-4 channelConfiguration, but then I see that effectively 13 is still 22.2, so I wonder what the differences are
Livio has joined #ffmpeg-devel
<JEEB>
OK, so ITU calls +/-135 as BL|BR , and then 23091-3 calls it Lsr|Rsr... and I mapped BL and BR to 5POINT1_BACK , which thus means that with 22.2 I mapped 8|9 to BACK_LEFT|RIGHT. thus 4|5 (LS|RS, Left|Right Surround) which should be +/-110 would be... ┐(´д｀)┌
<JEEB>
the only thing I learned of 13/14 is that they are supposed to be +/-90 so at exactly sides
<JEEB>
that's how Lss|Rss are defined in 23091-3
<JEEB>
(also clearly 22.2 being a superset of 5.1 was a lie, 135 vs 110 degrees :P)
<JEEB>
anyways, Lynne - do you want a draft piece of 23091-3 from 2021 that contains the definitions of OutputChannelPositions as well as ChannelConfiguration definitions which then map ISO channel abbreviations to geometric positions? in case you find a geometric position to wave mappings?
<JEEB>
wish there was an ITU or whatever document mapping BS.2051-3 stuff to WAVE dwChannelMask
TheSashmo has joined #ffmpeg-devel
<jamrial>
JEEB: yes, it's a mess
<Lynne>
JEEB: a diff would be better, then I can say "JEEB wrote this" :)
<jamrial>
JEEB: there's also the surround direct channels where our api doesn't match quicktime's
<JEEB>
the definitions probably should go to channel_layout, but that's mostly to note you got them right
<JEEB>
left|right side surround needs a new define
<JEEB>
jamrial: if I had contacts at apple I'd ask if the WAVE mapping where surround direct = side left is a troll
ccawley2011 has quit [Read error: Connection reset by peer]
<Lynne>
surround direct == side left sounds correcct
<Lynne>
after all fronts and backs are mixed with the assumption of being at an offset angle and thus leakage, but directs should be more or less like headphones
<Lynne>
what about top left/right surround?
<JEEB>
those also require new definitions I'm pretty sure. anyways, I will have to sleep.
<JEEB>
also surround direct is something really specific apparently
<JEEB>
only utilized in cinema/D specs, and if you look at that audiosciencereview.com link which actually leads to a D PDF, they don't map directs anywhere
<JEEB>
I will have to tomorrow after work check rcombs's apple audio PR again, if it matches what I more or less figured out now. but that IIRC removed that side left == surround direct mapping
<JEEB>
since it did indeed lead to incorrect audio
<JEEB>
but yea, will have to sleep, work and then double-check.