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
<michaelni>
jamrial, it is i nthe thread "Subject: Re: [FFmpeg-devel] [PATCH] avcodec/parser: Check next against buffer index"
<jamrial>
ok
jess has quit []
lexano has quit [Ping timeout: 255 seconds]
<Sean_McG>
List<Blah> = new ArrayList<>(Integer.MAX_VALUE);
<Sean_McG>
and I hate that I know that off by heart.
<Sean_McG>
*mumble mumble* $DAYJOB
<mkver>
Sean_McG: Sent even more patches for you.
jarthur has quit [Quit: jarthur]
<Sean_McG>
I wish this wasn't so slow to build
<mkver>
Do you always have to do a full recompile?
<Sean_McG>
I didn'
<Sean_McG>
I didn't have a local build with AltiVec & ubsan enabled
iive has quit [Quit: They came for me...]
<mkver>
Sean_McG: And another patch. That's the last for today.
<Sean_McG>
thanks a bunch
thilo has quit [Ping timeout: 255 seconds]
<Sean_McG>
I wonder if this is the first time the word "guesstimated" has been used in a patch comment ;)
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
thilo has joined #ffmpeg-devel
mkver has quit [Ping timeout: 268 seconds]
MisterMinister has quit [Ping timeout: 255 seconds]
<Sean_McG>
errr the reverse of "out-of-date", if that patch works :)
<Lynne>
ran into that one too
<BtbN>
Yeah, patch applies cleanly and fixes it.
<cone-636>
ffmpeg Rémi Denis-Courmont release/4.4:01fc3034ee8e: avcodec/x86/mathops: clip constants used with shift instructions within inline assembly
<cone-636>
ffmpeg Rémi Denis-Courmont release/5.0:b0e2146b06f2: avcodec/x86/mathops: clip constants used with shift instructions within inline assembly
<BtbN>
It can probably be backported even further, but those are the ones I'm set up to test
<Sean_McG>
cool
<Sean_McG>
Debian oldoldstable has 4.1.x and oldstable has 4.3.x
<Sean_McG>
stable (bookworm) is 5.1.x
<Marth64>
that's a big ArrayList
<Sean_McG>
very big
<Marth64>
i used to run a billing system once...abysmal codebase...we had real world gc problems like this
<Marth64>
we ended up just buying a !#@%ton of ram
<Marth64>
max out all the jvm settings and let the thing run on life support till its last days
<Sean_McG>
we've been doing a lot of profiling in VisualVM to see where leaks are recently
<Marth64>
neat tool. this replaces jconsole?
<Sean_McG>
I believe so, yes... unaware of the history.
<Marth64>
*bookmarks*
MisterMinister has joined #ffmpeg-devel
jamrial has quit []
AbleBacon has quit [Read error: Connection reset by peer]
Sean_McG has quit [Quit: leaving]
Martchus_ has quit [Ping timeout: 255 seconds]
Martchus has joined #ffmpeg-devel
<cone-636>
ffmpeg Gyan Doshi master:9e8be937fc49: configure: add threads dep for vulkan
hamzah has quit [Ping timeout: 250 seconds]
<aaabbb>
would there be any desire for an fft vocoder to be an ffmpeg audio filter? i am thinking about re-implementing audacity's nyquist vocoder plugin (https://github.com/audacity/audacity/blob/master/plug-ins/vocoder.ny) as an ffmpeg filter. takes two inputs, a voice and a carrier wave
<aaabbb>
i didn't look at the audacity plugin well enough lol, it's not what i was thinking
wcpan has quit [Quit: No Ping reply in 180 seconds.]
wcpan has joined #ffmpeg-devel
pzy has quit [Ping timeout: 268 seconds]
pzy_ has joined #ffmpeg-devel
pzy_ has quit [Client Quit]
dykai has joined #ffmpeg-devel
rodeo_ has joined #ffmpeg-devel
rodeo has quit [Ping timeout: 268 seconds]
rodgort has quit [Quit: Leaving]
rodeo_ is now known as rodeo
jkhsjdhjs has quit [Ping timeout: 268 seconds]
q66 has quit [Ping timeout: 268 seconds]
rodgort has joined #ffmpeg-devel
jkhsjdhjs has joined #ffmpeg-devel
wcpan has quit [Ping timeout: 268 seconds]
blb has quit [Ping timeout: 268 seconds]
kepstin has quit [Ping timeout: 268 seconds]
bcheng has quit [Ping timeout: 268 seconds]
wcpan has joined #ffmpeg-devel
blb has joined #ffmpeg-devel
kepstin has joined #ffmpeg-devel
q66 has joined #ffmpeg-devel
<Lynne>
compilers allow you to initialize variables to themselves?
<Lynne>
didn't know that, until just now
bcheng has joined #ffmpeg-devel
kurosu has joined #ffmpeg-devel
dykai has quit [Read error: Connection reset by peer]
dykai1 has joined #ffmpeg-devel
zsoltiv_ has quit [Ping timeout: 252 seconds]
zsoltiv_ has joined #ffmpeg-devel
<Lynne>
does anyone have any opinions on whether a structure containing functions for aac DSP that also includes two bitstream parsing functions AACDecProc (for prodecures)
dykai1 has quit [Ping timeout: 264 seconds]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 268 seconds]
Marth64 has joined #ffmpeg-devel
<cone-636>
ffmpeg Anton Khirnov master:ddaedde7a81e: fftools/cmdutils: fix printing group name in split_commandline()
<cone-636>
ffmpeg Anton Khirnov master:daca5d1241f3: fftools/ffmpeg_filter: refactor setting input timebase
<cone-636>
ffmpeg Anton Khirnov master:6f2acd7a9c5a: fftools/ffmpeg_filter: drop unused InputFilterPriv.ist
<cone-636>
ffmpeg Anton Khirnov master:48c39a9c71f8: fftools/ffmpeg_dec: move scheduler registration from dec_open() to dec_alloc()
<cone-636>
ffmpeg Anton Khirnov master:c4de5778bcea: fftools/ffmpeg_dec: factor opening the decoder out of dec_open()
<cone-636>
ffmpeg Anton Khirnov master:7b51523f12dc: fftools/ffmpeg_opt: merge init_complex_filters() and check_filter_outputs()
<cone-636>
ffmpeg Anton Khirnov master:cb0ec854fd2c: fftools/ffmpeg_filter: move filtergraph input type check to a better place
<cone-636>
ffmpeg Anton Khirnov master:cabeac912387: fftools/ffmpeg_filter: add logging for binding inputs to demuxer streams
<cone-636>
ffmpeg Anton Khirnov master:f5d03b972c49: fftools/ffmpeg: simplify propagating fallback parameters from decoders to filters
<cone-636>
ffmpeg Anton Khirnov master:2ee9362419bc: fftools/ffmpeg: remove unncessary casts for *_thread() return values
<cone-636>
ffmpeg Anton Khirnov master:2f5c570dd67f: fftools/ffmpeg_enc: drop unnecessary parameter from forced_kf_apply()
<cone-636>
ffmpeg Anton Khirnov master:3febc84e5e8a: fftools/ffmpeg_enc: merge do_{audio,video}_out into frame_encode()
<cone-636>
ffmpeg Anton Khirnov master:6ccbff2631ab: fftools/ffmpeg_sched: allow encoders to send to multiple destinations
<cone-636>
ffmpeg Anton Khirnov master:da17c4d24a35: fftools/ffmpeg_sched: factor initializing nodes into separate function
<cone-636>
ffmpeg Anton Khirnov master:efab83c1561c: fftools/ffmpeg_sched: allow connecting encoder output to decoders
<cone-636>
ffmpeg Anton Khirnov master:b98af440c575: fftools/ffmpeg: prepare FrameData for having allocated fields
<cone-636>
ffmpeg Anton Khirnov master:a9193f7b7d65: fftools/ffmpeg: add loopback decoding
<cone-636>
ffmpeg Anton Khirnov master:8996945d459c: fftools/ffmpeg_enc: set AV_PKT_FLAG_TRUSTED on encoded packets
Krowl has joined #ffmpeg-devel
MisterMinister has quit [Ping timeout: 255 seconds]
System_Error has quit [Ping timeout: 260 seconds]
System_Error has joined #ffmpeg-devel
cubicibo has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 264 seconds]
Marth64 has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 240 seconds]
Marth64 has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
cubicibo has quit [Quit: Client closed]
Marth64 has quit [Ping timeout: 268 seconds]
Marth64 has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 264 seconds]
Marth64 has joined #ffmpeg-devel
agrosant has joined #ffmpeg-devel
agrosant has quit [Ping timeout: 264 seconds]
cubicibo has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
cubicibo has quit [Client Quit]
mkver has joined #ffmpeg-devel
MrZeus has joined #ffmpeg-devel
rajivharlalka has joined #ffmpeg-devel
MrZeus has quit [Read error: Connection reset by peer]
Marth64 has quit [Ping timeout: 268 seconds]
Marth64 has joined #ffmpeg-devel
<rajivharlalka>
Hi again, I recently recieved a reply on the mailing list, "I've tested it locally -- looks good to me, feel free to apply and push." was doubtful was it meant for me or committers of the ffmpeg git repository, If it is meant for me, where do I need to push ?
<rajivharlalka>
kierank: Thanks for the push. Though my question still remains, how does the ffmpeg project address the patches, what's the next step for the submitter once the patch is approved.
<kierank>
ask someone with push access to push it
paulk has quit [Ping timeout: 255 seconds]
<rajivharlalka>
That makes sense, thanks again.
<kierank>
Not a great situation imo but it is what it is
paulk has joined #ffmpeg-devel
paulk has quit [Changing host]
paulk has joined #ffmpeg-devel
agrosant has quit [Ping timeout: 264 seconds]
Krowl has quit [Read error: Connection reset by peer]
<rajivharlalka>
True, have been in the PostgreSQL community for quite a time and knew how things work there. Hence was trying to understand how the ffmpeg community works.
<JEEB>
just close it with a comment noting that a specific commit hash fixes it
Traneptora has quit [Quit: Quit]
Marth64 has quit [Ping timeout: 268 seconds]
Marth64 has joined #ffmpeg-devel
MrZeus has joined #ffmpeg-devel
kasper93 has joined #ffmpeg-devel
<haasn>
how *should* scale2ref behave if one stream is shorter than the other?
<haasn>
some possible scenarios I can imagine: [logo][video]scale2ref[logo-scaled][video-out] <- if [logo] here has only a single frame, should scale2ref be continuously re-sending it for every frame in [video-out]?
paulk has quit [Ping timeout: 268 seconds]
paulk has joined #ffmpeg-devel
paulk has joined #ffmpeg-devel
paulk has quit [Changing host]
MrZeus has quit [Read error: Connection reset by peer]
<haasn>
I guess the answer is probably "it should be configurable", cf. vf_overlay
<haasn>
via "shortest" and "repeatlast", specifically
<haasn>
what is the difference between repeatlast=1 and eof_action=repeat
agrosant has quit [Ping timeout: 264 seconds]
MrZeus has joined #ffmpeg-devel
MrZeus has quit [Read error: Connection reset by peer]
agrosant has joined #ffmpeg-devel
ramiro__ has joined #ffmpeg-devel
ramiro has quit [Ping timeout: 252 seconds]
psilokos has quit [Read error: Connection reset by peer]
psilokos_ has joined #ffmpeg-devel
<haasn>
apparently none
Krowl has quit [Read error: Connection reset by peer]
System_Error has quit [Remote host closed the connection]
omegatron has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
agrosant has quit [Ping timeout: 264 seconds]
agrosant has joined #ffmpeg-devel
cubicibo has joined #ffmpeg-devel
Xaldafax has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
<haasn>
man, it's so easy to accidentally generate EOM loops using scale2ref
<JEEB>
\o/
jamrial has joined #ffmpeg-devel
lexano has joined #ffmpeg-devel
novaphoenix has quit [Quit: i quit]
cubicibo has quit [Quit: Client closed]
novaphoenix has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 272 seconds]
agrosant has quit [Ping timeout: 264 seconds]
pzy_ has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 268 seconds]
Marth64 has joined #ffmpeg-devel
rvalue has joined #ffmpeg-devel
System_Error has quit [Ping timeout: 260 seconds]
agrosant has joined #ffmpeg-devel
<ePirat>
haasn, '[b][a]scale2ref[sub];[a][sub]overlay' this won't work though, no? as a is already consumed by scale2ref
<haasn>
really? I thought we had the ability to re-use input pins for multiple filters
<ePirat>
only for ffmpeg inputs not if the input is the output of another filter, iirc
<haasn>
ah
<haasn>
that explains why it worked in my testing
<ePirat>
its really confusing tbh
<haasn>
do we have a "duplicate" filter that sends its input frames to two outputs?
<ePirat>
yes, the confusingly named split filter
<ePirat>
[in] split [splitout1][splitout2];
Marth64 has quit [Ping timeout: 252 seconds]
Marth64 has joined #ffmpeg-devel
<haasn>
what would it take to make lavfi smart enough to auto-insert the split filter if you re-use a filter pin?
<ePirat>
no clue, it would be really neat from a usability perspective though…
cone-636 has quit [Quit: transmission timeout]
clarkh_ has joined #ffmpeg-devel
MrZeus has joined #ffmpeg-devel
rajivharlalka has quit [Quit: Connection closed for inactivity]
Krowl has quit [Read error: Connection reset by peer]
tufei has quit [Remote host closed the connection]
tufei has joined #ffmpeg-devel
dykai has joined #ffmpeg-devel
tufei has quit [Remote host closed the connection]
tufei has joined #ffmpeg-devel
<BtbN>
I hate libraries.
<BtbN>
dec.c:(.text+0x2a0): multiple definition of `dec_init'; fftools/ffmpeg_dec.o:ffmpeg_dec.c:(.text+0x2120): first defined here: libbluray.a(libbluray_la-dec.o)
<ePirat>
more like hate static linking
<ePirat>
do partial linking to hide the non-exported symbols
<elenril>
haasn: the graphparser api could use some more love
<elenril>
it shouldn't be particularly hard to do it at that level
<jamrial>
elenril: i suppose it's not worth the work using recon_frame when available for the loopback decoding feature?
<BtbN>
ePirat: I'm already building everything with hidden symbol visibility, but sometimes it still happens.
<ePirat>
hidden symbol visibility does nothing for static libs though?
<jamrial>
i mean, complexity and work to implement it vs speed gain by skipping decoding
<BtbN>
It avoids the libav* libs having half a million random public functions from other libs
<BtbN>
I don't immediately see how partial linking would help here
<ePirat>
BtbN, you do partial linking for libbluray for example so it only exposes the symbols it actually does. so no symbols conflicts.
<BtbN>
But I'm never actually linking libbluray?
<BtbN>
It only produces an .a archive
<ePirat>
yes you do static linking so that .a only has the symbols it needs to have to be usable
<elenril>
jamrial: I have considered it
<ePirat>
and not _all_ the symbols of libbluray
MrZeus_ has joined #ffmpeg-devel
MrZeus has quit [Ping timeout: 240 seconds]
<BtbN>
Yes, but the first time a linker sees those object files is when building the final ffmpeg binary/.so
<BtbN>
I'm not aware of partial linking for static archives?
<ePirat>
there is definitely on macOS, I used it before and my colleague did for linux so there must be a way
<elenril>
jamrial: probably not for loopback decoding, rather to allow encoder nodes to have avframe output links in addition to packet ones
<elenril>
but that's for later
<BtbN>
ePirat: also, this clash is between a symbol in an fftool and the library.
<elenril>
BtbN: can you stab libbluray authors?
<ePirat>
elenril, why?
<ePirat>
we did nothing wrong as far as I can see
MrZeus_ has quit [Read error: Connection reset by peer]
<elenril>
exporting un-namespaced symbols is naughty
<ePirat>
as I just said we do not export this
<ePirat>
this is static linking being shit
<BtbN>
The weird thing also is... this only happens on arm
<BtbN>
x86_64 is perfectly happy somehow
<ePirat>
that is _ver_ weird
<elenril>
if static linking is supposed to be supported, then you must use namespacing for non-static symbols
<elenril>
that's why we prefix everything with ff_
<BtbN>
The symbol is also not new. I just updated the toolchain, and suddenly this error pops up.
<ePirat>
objcopy --localize-hidden will not work correctly with C++ though
<BtbN>
That should be a non-issue, mostly. Given ffmpeg uses barely any C++ symbols
<BtbN>
I'm also not sure if "--localize-hidden" would work in general. Since ALL symbols have hidden visibility, so wouldn't it just make all of them vanish?
<ePirat>
the idea is you use that on the library, like libbluray, to hide the non-exported symbols
<BtbN>
yes, but a lot of libraries, in static linking mode, stop exporting anything, and mark everything as hidden
<ePirat>
oh ok thats news to me
<BtbN>
Cause otherwise, if you linked that static lib into another shared lib, the symbols from the random other static lib would appear on it
<BtbN>
And since there is no reason for a static library to export ANYTHING, at least autotools defaults to default-visibility=hidden
<BtbN>
I mean, one way to deal with this would be to pretend you're doing a shared build, and then inject that partial-linking mode into the ldflags.
<BtbN>
But I'd highly assume that to GREATLY confuse most build systems
<ePirat>
probably, yeah
<JEEB>
I've for a while wished for a more intelligent static lib format
<BtbN>
So yeah, CPPFLAGS="-Ddec_init=libbr_dec_init" it is
<ePirat>
JEEB, apple kinda made one recently iirc
<BtbN>
I mean, this "partial linking" thing basically is one, no?
<BtbN>
It produces one singular .o file of the whole static library
<BtbN>
Just needs a bunch of new tooling around it
<JEEB>
the other bit is to have dynamic library deps noted there, too
<JEEB>
but yea, that sounds like fixing one part of it
<BtbN>
pkg-config generally solves that
<BtbN>
But a lot of project do a poor job of maintaing it
<JEEB>
it gets fun when for some deps you want to utilize --static pkg-config flag and for others - not
dykai has quit [Quit: dykai]
Marth64 has quit [Ping timeout: 252 seconds]
dykai has joined #ffmpeg-devel
Marth64 has joined #ffmpeg-devel
MrZeus has joined #ffmpeg-devel
<Marth64>
bdmvdec 2025
<nevcairiel>
blu-ray is a lot saner then DVD
<BtbN>
nevcairiel: btw., do you happen to know if D3D11 needs any synchronization when copying a resource? I'd have imagined it pipelines stuff on its own, but apparently not always?
<BtbN>
The only way I could see that breaking is if something doesn't wait for ID3D11DeviceContext_CopyResource to actually do its thing before using the texture
<JEEB>
(56
<nevcairiel>
if you share it between devices you need to synchrionize manually, if you stay on the same device it was usually fine for me
<nevcairiel>
not sure if ffmpeg by itself creates two devices in such a command
<elenril>
nevcairiel: don't you need some js crap for proper bd playback?
<nevcairiel>
its java, not js
<BtbN>
elenril: Full on Java
<Marth64>
old version too
<BtbN>
nevcairiel: it should all be on the same device. I don't see how it's not.
<nevcairiel>
but thats "only" for menus, the file structure and media storage is a lot better then dvd
<ePirat>
nevcairiel, except bdplus
<BtbN>
But if you look at that demo video in the issue... It's clearly lagging behind with that buffer texture
<Marth64>
by miles, leaps ahead
<nevcairiel>
we dont do decryption here
<BtbN>
The main issue also is, I can't reproduce it.
<BtbN>
It works perfectly on all of my machines
<JEEB>
libbluray handles that for you thankfully if you have the necessary libs
<BtbN>
So this must be some quirk of some old intel GPU with DDA
<BtbN>
Time to investigate D3D11 fences...
MrZeus has quit [Read error: Connection reset by peer]
sudden has quit [Ping timeout: 264 seconds]
sudden has joined #ffmpeg-devel
agrosant has quit [Ping timeout: 264 seconds]
AbleBacon has joined #ffmpeg-devel
<Marth64>
Oneric: I'll test more of your v4 set tonight and report validation results...thanks!
<Marth64>
I wouldn't be able to merge it but it could help having a validation/review lgtm
<Marth64>
they seem like positive changes to me
MrZeus has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 268 seconds]
Marth64 has joined #ffmpeg-devel
MrZeus has quit [Read error: Connection reset by peer]
dykai has quit [Ping timeout: 268 seconds]
Krowl has quit [Read error: Connection reset by peer]
dykai has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 252 seconds]
Marth64 has joined #ffmpeg-devel
MrZeus has joined #ffmpeg-devel
dykai has quit [Ping timeout: 268 seconds]
MrZeus has quit [Read error: Connection reset by peer]
Krowl has joined #ffmpeg-devel
<BtbN>
Hm, yeah. This _does_ happen on the Intel driver here too. But not Nvidia. But I don't see how it could possibly happen.
<BtbN>
Like, it does ANOTHER subregion copy, and _then_ draws the mouse on it
<BtbN>
and yet there's frames with a mouse-cursor trail. How??
<JEEB>
funky
<JEEB>
driver implementation details galore, I guess?
agrosant has joined #ffmpeg-devel
<BtbN>
If I turn of mouse cursoe drawing, and then do a selection-rect on the desktop, that rect flickers in and out of the recording. How is that even possible?
<BtbN>
I don't see this on Nvidia. But on Intel Iris Xe. The reporter also sees it on Nvidia.
<BtbN>
But I just don't see how this output is even remotely possible, outside of the driver severely mixing unrelated textures.
MisterMinister has joined #ffmpeg-devel
<BtbN>
The only explanation for the flickering is that CopyResource has not yet happened, and it uses an outdated texture which didn't yet have the selection-rect in it
<BtbN>
But add in the mouse cursor trail, and I'm completely stumped how THAT would ever happen
<BtbN>
Like, I could see that happen if the CopySubresourceRegion ALSO does not execute, and the frame returned by ff_get_video_buffer contains old data, which then gets a mouse cursor drawn onto it.
<BtbN>
But then again, that sounds SUPER broken, driver wise?!
<BtbN>
Or is it possible that the Copy-Commands fail? They only return void, so I'm not sure how to monitor for failure.
<nevcairiel>
its an async gpu command, you cant really get a proper return value, could hook up the error logging callbacks
<BtbN>
if I reduce the amounts of threads, it gets even worse
<BtbN>
like, the most logical explanation for that really is the CopySubresourceRegion call straight up failing
<BtbN>
But... why?
qeed has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 252 seconds]
Marth64 has joined #ffmpeg-devel
<BtbN>
no idea how to get any debug logging out of d3d11, hm
<BtbN>
debug=1 seems to do nothing
agrosant has quit [Ping timeout: 264 seconds]
<Lynne>
jkqxz: posted a new version of the av1 patchset
clarkh_ has quit [Quit: Connection closed for inactivity]
tufei has quit [Quit: Leaving]
<Lynne>
mkver: do you have any opinion on what a struct of function pointers for aac DSP/decoding should be called?
<Lynne>
I went with AACDecProc (for procedures)
<mkver>
AACDecDSPContext?
tufei has joined #ffmpeg-devel
<Lynne>
yeah, but it does have decode functions for cce + spectral coeffs (couldn't abstract away dequant)
<Lynne>
though dsp is more appropriate and we don't have an aacdec_dsp(_template) file
<jamrial>
Lynne: please bump lavc minor with the vulkan av1 change. no need for an apichanges entry
<mkver>
IMO the DSP functions should not be mixed in the same struct as the non-dsp functions; AACDecProc seems fine for the non-dsp stuff.
<Lynne>
ok, doesn't make a difference, but I'd prefer to keep them in the same file to avoid needing to template twice
<Lynne>
what should I go with? proc, or just include both aacdec_proc and aacdec_dsp in the same fixed/float .c files?
<Lynne>
jamrial: will do when it's time to push
<mkver>
My concern is that the asm dsp code-init code (as well as checkasm) only sees the dsp context and not the complete decoder structs.
dykai has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
Marth64 has quit [Ping timeout: 252 seconds]
Marth64 has joined #ffmpeg-devel
<Lynne>
we don't do checkasm on that level
<Lynne>
we do checkasm on real dsp functions, not templated type functions, for that, we test the entire decoder
<mkver>
Yes, and therefore the checkasm code should not see these non-dsp functions.
<Lynne>
yeah, but why would it, unless you make it?
<Lynne>
it's not really practical, as each function gets a pointer to the entire aac decode context
MrZeus has joined #ffmpeg-devel
dykai has quit [Ping timeout: 268 seconds]
iive has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 268 seconds]
Marth64 has joined #ffmpeg-devel
qeed has quit [Quit: Leaving]
MisterMinister has quit [Ping timeout: 255 seconds]
Traneptora has joined #ffmpeg-devel
omegatron has quit [Quit: Power is a curious thing. It can be contained, hidden, locked away, and yet it always breaks free.]
MisterMinister has joined #ffmpeg-devel
hamzah has joined #ffmpeg-devel
<BtbN>
nevcairiel: how do you get to the debug messages? Everything I find online is just "In your Visual Studio output window, duh."
<JEEB>
any debugger does them, also there was either procmon or some other tool that let you view them. with command line apps the stuff should end up in stdout or stderr
<BtbN>
It explicitly does not end up on stdout/err, is what my terminal and google says at least
MrZeus has quit [Read error: Connection reset by peer]
<BtbN>
You can apparently manually dig them out via ID3D11InfoQueue, but there is no callback, only polling
<nevcairiel>
you could try DebugView
<nevcairiel>
visual studio will capture the debug output for you, but that should also show it
<iive>
DebugView is part of Sysinternals package, available on microsoft site, isn't it?
<nevcairiel>
yes
Livio has joined #ffmpeg-devel
<BtbN>
hm, it displays nothing. But I'm at home, where it works
agrosant has joined #ffmpeg-devel
agrosant has quit [Ping timeout: 264 seconds]
<BtbN>
huh, it works if I specify adapter=-1, but with adapter=0, it fails. This is weird. I'd have expected that to be equivalent.
<BtbN>
nevcairiel: in case this tells you anything: [640] D3D11 ERROR: ID3D11Device::CreateTexture2D: D3D11_RESOURCE_MISC_SHARED_KEYEDMUTEX is only available for devices created off of Dxgi1.1 factories or later.
<BtbN>
The error goes away if I GetProcAddress CreateDXGIFactory1 instead of CreateDXGIFactory in load_functions() of the hwcontext, but not sure what the implications of that would be
<BtbN>
like, would there be any downside to trying to load the 1.1 function first, and on failure try the 1.0 one?
<BtbN>
It also seems a bit dicey that there is never any error checking done on the results of those function loads
<nevcairiel>
in reality you should always use dxgi 1.1+
<BtbN>
well, it disagrees :D
<nevcairiel>
unless you care for like early windows 7 versions without the d3d11 platform update
<nevcairiel>
which noone should be
<BtbN>
Oh, you mean it should really be using the 1.1 function no matter what?
<nevcairiel>
yes, our code should use the 1 version
<nevcairiel>
anything else is stupid
<BtbN>
Is there any downside to a fallback solution?
<nevcairiel>
i highly doubt anything will really work on lower versions anyway
<nevcairiel>
on systems that dont have it, i mean
<nevcairiel>
because as said, thats like unpatched windows 7 only
<BtbN>
fair. But there is zero error checking, so loading the old one seems better than calling a NULL-Function-Pointer
<BtbN>
Asked the initial reporter for debug info, let's see if anything comes back
hamzah has quit [Quit: Client closed]
MrZeus has quit [Read error: Connection reset by peer]
MrZeus has joined #ffmpeg-devel
agrosant has quit [Ping timeout: 264 seconds]
b50d has joined #ffmpeg-devel
man84 has joined #ffmpeg-devel
MrZeus has quit [Read error: Connection reset by peer]
MrZeus has joined #ffmpeg-devel
MrZeus has quit [Read error: Connection reset by peer]
MrZeus has joined #ffmpeg-devel
cubicibo has quit [Quit: Client closed]
cone-640 has joined #ffmpeg-devel
<cone-640>
ffmpeg James Almer master:5cd8db306076: fftools/ffprobe: export Tile Grid Stream Group parameters
<cone-640>
ffmpeg James Almer master:394abd8458cb: fftools/ffprobe: export IAMF Stream Group parameters
cubicibo has joined #ffmpeg-devel
MrZeus has quit [Read error: Connection reset by peer]
MrZeus has joined #ffmpeg-devel
averne has quit [Quit: quit]
b50d has quit [Remote host closed the connection]
agrosant has joined #ffmpeg-devel
averne has joined #ffmpeg-devel
agrosant has quit [Ping timeout: 264 seconds]
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 255 seconds]
averne_ has joined #ffmpeg-devel
averne has quit [Ping timeout: 268 seconds]
averne_ is now known as averne
hamzah has joined #ffmpeg-devel
averne has quit [Quit: quit]
averne has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
<Traneptora>
Marth64: libavformat/dvdvideodec.c:426:83: warning: format ‘%d’ expects argument of type ‘int’, but argument 5 has type ‘ssize_t’ {aka ‘long int’} [-Wformat=]
<jamrial>
i don't know if that should be a blocker for 7.0, though. it can be fixed and backported
<Marth64>
how many more days for 7.0?
<Marth64>
(to expedite above ^patch and rcwtdec). can have both within 24hrs.
<jamrial>
Marth64: soon(tm)
<jamrial>
elenril: guess it's that setpts doesn't set duration?
<jkqxz>
elenril: Do you have any further thoughts on how to fix fixed-pool decoders not working in the ffmpeg utility?
<jkqxz>
That feels like a blocker for a release as well.
<jkqxz>
I noticed that my previous patch fails in the case where a filter chain has the same pool on input and output (say it only messes with metadata), and would need two queue-fulls of frames of additional frames to work.
<jkqxz>
I don't see any way to detect that. Hacky answer is to just take two queue-fulls of extra frames in all cases, but that seems unfortunate.
<Marth64>
jamrial: thx...i will submit last of my patches within 24h. (1) PRid64 include (2) rcwt demuxer with feedback addressed (3) very minor dvd bug, duration is wrong when selecting 1 chapter - no impact on output file
<Marth64>
the demuxer is very small
<Marth64>
but it is weird to have the muxer and not the demuxer. and i think lot of people can benefit to be able to archive/remux closed captions
<Lynne>
jkqxz: could you review the av1 patch soon? I'd rather it makes it into 7.0, rather than the old implementation (with no corresponding drivers released) staying for the release
<Lynne>
the only change from the previous version are 10 lines to deduplicate the references in the list
<cone-640>
ffmpeg Mark Thompson master:98a2ade63063: avcodec: Fix doxygen comment marker
<jkqxz>
Lynne: I'll try to get to it in the next few days.
<jkqxz>
And yeah, it really wants replace the pre-standard one for the release.
<Lynne>
thanks
<Lynne>
btw, nvidia did actually have issues with their drivers, only the most recent ones work
<Lynne>
if you want to test on RADV, you'll have to revert mesa commit f3ab454 since that exposed multiple queues, which ffmpeg tries to use, but the driver doesn't support yet, so the kernel rejects the CS
<jkqxz>
I'm mildly disturbed that the answer to the FeatureEnabled thing was "oh it was just an irrelevant typo which completely changed the meaning of the normative text, swap the indices and it'll be fine".
agrosant has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 272 seconds]
Marth64 has joined #ffmpeg-devel
<cone-640>
ffmpeg Andreas Rheinhardt master:c1cdaef5cef7: avcodec/hevc_cabac: Let compiler count offsets
Marth64 has quit [Ping timeout: 252 seconds]
Marth64 has joined #ffmpeg-devel
agrosant has quit [Ping timeout: 264 seconds]
averne has quit [Quit: quit]
averne has joined #ffmpeg-devel
agrosant has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 252 seconds]
Marth64 has joined #ffmpeg-devel
agrosant has quit [Ping timeout: 264 seconds]
Marth64 has quit [Ping timeout: 268 seconds]
Marth64 has joined #ffmpeg-devel
agrosant has joined #ffmpeg-devel
agrosant has quit [Ping timeout: 264 seconds]
qeed has joined #ffmpeg-devel
dykai has joined #ffmpeg-devel
<cone-640>
ffmpeg Kieran Kunhya master:110d8549d575: avcodec/vvcdec: Mark as experimental
Marth64 has quit [Ping timeout: 252 seconds]
Marth64 has joined #ffmpeg-devel
<kierank>
jamrial: thx
Marth64 has quit [Remote host closed the connection]