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
dellas has quit [Remote host closed the connection]
rvalue has quit [Ping timeout: 268 seconds]
rvalue has joined #ffmpeg-devel
navi has quit [Quit: WeeChat 4.0.4]
Frayk has joined #ffmpeg-devel
lexano has quit [Ping timeout: 264 seconds]
<Traneptora>
is it a bad idea to declare both av_foo and ff_bar functions in the same header?
jamrial has quit [Read error: Connection reset by peer]
mkver has joined #ffmpeg-devel
MrZeus has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
<durandal_1707>
profit
<jamrial_>
does fate-vvc-conformance-WP_A_3 crash for anyone else after that latest push?
<elenril>
always or randomly?
<jamrial_>
always
<elenril>
does not seem so
<jamrial_>
i'm on win64, so maybe that's why
<jamrial_>
but it's not crashing on an asm function
<elenril>
kinky
<jamrial_>
0x00007ff7369e3f1c in ciip_derive_intra_weight (lc=lc@entry=0x2b4b020, x0=x0@entry=40, y0=y0@entry=45613504, width=width@entry=8, height=height@entry=8) at K:/msys64/home/jamrial/FFmpeg/libavcodec/vvc/vvc_inter.c:536
<haasn>
cworley: my advice is to ignore balling
<wbs>
jamrial_: can you bisect at which commit it started breaking? does it stop breaking with -cpuflags none?
<wbs>
i.e. is the asm function breaking something somewhere, so that regular C code crashes afterwards?
<jamrial_>
wbs: yeah, cpuflags none fixes it
<jamrial_>
fun
<jamrial_>
gdb is not being useful
<wbs>
jamrial_: I was about to suggest asan, but that won't help catching things that assembly corrupts either
<wbs>
normally valgrind would help catching that, but doesn't work on windows
<jamrial_>
i never got asan to work on mingw
<jamrial_>
it's 326cc01de9
novaphoenix has quit [Quit: i quit]
<wbs>
it does work in clang setups; either the clang64 environment in msys2 (haven't tried asan there myself, but would expect it to work), or if you'd try llvm-mingw (where I know it works)
novaphoenix has joined #ffmpeg-devel
kurosu has quit [Quit: Connection closed for inactivity]
<haasn>
that seems orthogonal to the issue being fixed here
<haasn>
yes, the same issue will affect all callers but absent of a clear way to solve this in a universal way I don't see why we shouldn't solve it at least for ffplay
<haasn>
basically there are two issues here: 1. warning spam if you don't set metadata, and 2. not setting metadata in ffplay
<haasn>
this series solves #2 without solving #1
<haasn>
you are saying that #1 continues to be a problem, I don't disagree
<elenril>
is the issue just spam or does it actually break output
<haasn>
just spam
<elenril>
okay, that's not too bad then
Krowl has joined #ffmpeg-devel
<haasn>
the status quo was to not negotiate yuv colorspace at all
<elenril>
right
<haasn>
not setting metadata is basically just negotiating the list of all colorspaces as supported
<elenril>
my concern was that changing a caller to fix something cause by a library change is quite suspect
epony has quit [Remote host closed the connection]
<haasn>
correct me if I'm wrong but I don't think we have the ability to delay filter graph initialization until the first frame is sent to buffersrc
<haasn>
which is what would be required for us to somehow automatically know what colorspaces to advertise on the filter graph
<haasn>
maybe can *reconfigure* the filter grapy after specific metadata is known?
<elenril>
if you mean "can we postpone config_links until a frame is seen" then no
<jamrial_>
wbs: fixed it
<jamrial_>
one function was not saving a gpr
<wbs>
jamrial_: nice - how didn't checkasm catch that?
<elenril>
I wish we had proper separation between filters and filtergraphs, but...
<haasn>
I mean ultimately solving this will require changes on the caller side one way or the other
<haasn>
you either need to:
<jamrial_>
wbs: it evidently only broke win64, so the author didn't trigger it
<haasn>
1. send a frame to buffersrc before query_formats, which is the opposite order of how most callers are currently doing it (in fftools)
<haasn>
2. inform buffersrc during init time about the incoming frame metadata (what my above series does)
<elenril>
1. is in general unfeasible, because you can have multiple inputs
<haasn>
3. have buffersrc dynamically reconfigure the downstream filter graph if the incoming frame deviates from the previously settled link metadata, but this would raise the possibility of an error, which the user would then have to reasonably intercept
<haasn>
and in some cases might lead to a fundamental incompatibility: e.g. you pass a YUV frame to a filter that only accepts RGB input
<elenril>
dynamic reconfiguration in lavfi would be nice, but tons of work
<elenril>
not to mention the politics
<haasn>
agree, so 1 and 3 are basically off the table
<haasn>
which leaves 2 as the very simple and only slightly awkward solution of basically requiring downstream clients to add two extra lines to their buffersrc setup
<haasn>
(note the small size of linked patch)
<elenril>
sure, it's ok to require changes eventually
<haasn>
since downstream has to change _something_ to use the new API, and the new API is not _required_ for anything, and the implicit backwards compatible behavior is identical to the status quo (except for warn spam atm)
<elenril>
but we shouldn't break clients just with random commits
<cone-899>
ffmpeg James Almer master:bf62ddc7bf7a: x86/vvc/vvc_mc: set the correct number of used registers in vvc_w_avg functions
<haasn>
there's nothing we can do here except suppress error spam specifically
<haasn>
but I think this is the wrong layer to suppress error spam
<haasn>
don't we already suppress printing duplicate messages
<haasn>
fair
<elenril>
ffmpeg CLI does
<elenril>
or fftools in general
<haasn>
I mean I'm not against a patch to suppress duplicate warnings inside buffersrc specifically
<elenril>
random clients can do whatever they want with log messages
<haasn>
or at least special-case the colorspace and colormatrix warnings to only print once and kindly inform the user about these new additions to the API
ccawley2011 has quit [Ping timeout: 268 seconds]
epony has joined #ffmpeg-devel
<haasn>
(but that also doesn't change the fact that ffplay needs to set colorspace metadata which the above patch does)
<cone-899>
ffmpeg James Almer master:692e32a7dc1e: fate/checkasm: enable testing vvc_mc
<haasn>
int loglevel = c->prev_delta ? AV_LOG_WARNING : AV_LOG_DEBUG;\ seems like it should already be not spamming warnings at log level warning though
<Lynne>
I'll get the patch to update the API up in a few hours
<Lynne>
(I also wrote the introduction for the blog post)
kurosu has joined #ffmpeg-devel
dellas has joined #ffmpeg-devel
<kurosu>
jamrial: (replying to old message) can confirm using asan under a Msys clang terminal, and compiling using clang and proper options (maybe thx to wbs). Just doesn't track memory leaks
natto has joined #ffmpeg-devel
<kurosu>
Asan and ubsan, for that matter, if ubsan proves useful enough
Marth64 has joined #ffmpeg-devel
<JEEB>
FOOBARsan are <3
<another|>
Is that a japanese thing? foobar-san?
<JEEB>
lol
<JEEB>
that would HOGEsan
<courmisch>
inb4 somebody calls their sanitiser something something-kun for the joke
courmisch has quit [Read error: Connection reset by peer]
courmisch has joined #ffmpeg-devel
dellas has quit [Remote host closed the connection]
<kasper93>
ffmpeg no longer uses internal one and fails to compile
dellas has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
<Daemon404>
pal, congrats. i think.
<kasper93>
LSAN on Windows is indeed not available would neeed M$ to contribute it. There is memory profilining in VS so maybe they don't care. (and it is probably not trivial to port it to windows)
<gnafu>
Lynne: \o/
<kasper93>
(I should read previous msg before typing probably ;p)
<Daemon404>
interesing, C23 adds an official [[deprecated]]
<JEEB>
:D
<JEEB>
nice
<Daemon404>
cant wait to use it in 2054
<JEEB>
inorite
<gnafu>
Daemon404: Nonsense. The world is going to end in 2038.
<durandal_1707>
to all linux users using foobar2000 under wine:
<Daemon404>
gnafu, incorrect, it ended in 2012
<Daemon404>
and also 2000
<Daemon404>
we are in a post-world world
<kasper93>
that explains a lot
<durandal_1707>
lies
<courmisch>
by 2054, all the C code will have been replaced by Rust, no doubts
<durandal_1707>
there are many parallel Earths, once one of Earths get destroyed it get integrated into still living Earths in all multiple universes
<kasper93>
is ffmpeg in rust on ane of those earths?
<kasper93>
any*
<courmisch>
those Earths were OSS is funded properly?
<JEEB>
I definitely would like to poke into making a demuxer in rust :D
<Daemon404>
seek help
<durandal_1707>
kasper93: maybe, in that case they already have warp 10
<JEEB>
OS/Warp 10
<Daemon404>
so everyone in that world is a slug monster?
<Daemon404>
(i pray someone gets this)
<Daemon404>
well. lizard... thing
<courmisch>
not sure if there's any meaningful project getting funded Rust integration other than the Linux kernel?
<courmisch>
AFAICT, VLC's attempt pretty much died due to no funding
<durandal_1707>
Warp 10 - travel much faster than speed of light
<courmisch>
not sure if this is a Rick and Morty reference, as I don't have access to that series
<Daemon404>
oh fuck this made me realize i missed Theshold Day
<Daemon404>
it was 29 jan
<courmisch>
it should illegal to hold FOSDEM on 4 February. That's holy candlemas
<durandal_1707>
better read horoscope news for this day on Earth 666 in multiverse
<durandal_1707>
are there horoscope news for OSS projects?
<courmisch>
I can predit if there will be proper funding for OSS projects
<cone-131>
ffmpeg James Almer master:6b6eb7d74eb4: x86/Makefile: fix hevc and vvc dependency of h2656dsp.o
<cone-131>
ffmpeg James Almer master:b181868aba57: x86/h26x/h2656dsp: add missing preprocessor wrappers
<elenril>
>29/01 - 02/02-Perturbations in BE and LUX lines due to farmers' protest.
<elenril>
that will be fun
Marth64 has quit [Ping timeout: 240 seconds]
<Daemon404>
i enjoy that this vote is basically: A. do what the initial email said or B. give it up fully
<elenril>
feel welcome to suggest other alternatives, maybe I'd vote for one of them
<elenril>
but it seems to me the biggest obstacle is actually lack of projects
<Daemon404>
i want to point out that i specifically mentioned that we already had SPI money that noone use for projects, so i dont know why it would be different here.
<Daemon404>
the reply was there wasnt enough in SPI... but when i asked what project hit that issue
<Daemon404>
i was told to suggest one
<Daemon404>
insanity.
<elenril>
well, it is true in a way
<Daemon404>
true aside from total lack of evidence
<BtbN>
I think nobody would be willing to propose asking for money for working on a project, cause of the inevitable bikeshedding that E-Mail would cause.
<elenril>
SPI does not have enough money to fund someone continuously, which is what I'd think most potential candidates are interested in
<Daemon404>
BtbN, as opposed to this new way?
<Daemon404>
:D
<BtbN>
Well, "I have money, propose projects!" at least helps a little bit
<BtbN>
But out of nowhere asking for SPI money for a project is deffinitely a hurdle
<Daemon404>
i am also concerned this Merge Forks project is SDR in disguise.
<elenril>
I'm not actually concerned about that
<elenril>
there's enough opposition to SDR that it has no chance to go in
<Daemon404>
but more than anything i am bothered about the intentions of the individual involved here who kept is secret.
<BtbN>
Someone should just write a feature-equivalent sdr avdevice using one of the popular libraries at this point
<Daemon404>
and being forced to define all these projects RIGHT NOW
<Daemon404>
which is a terrible way to do it
<Daemon404>
famously healthy long term
<BtbN>
That's how corporate dev works. And why stuff usually fails so terribly
<Daemon404>
it feels very intentional to keep it secret until right before the deadline
Marth64 has joined #ffmpeg-devel
uau_ is now known as uau
dellas has joined #ffmpeg-devel
<courmisch>
I believe it's more about spiting FFlabs than forcing SDR
Marth64 has quit [Ping timeout: 256 seconds]
Marth64 has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
dellas has quit [Remote host closed the connection]
dellas 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.]
cosimone has joined #ffmpeg-devel
epony has quit [Remote host closed the connection]
Krowl has joined #ffmpeg-devel
APic has quit [Ping timeout: 268 seconds]
Marth64 has quit [Ping timeout: 246 seconds]
___nick___ has quit [Ping timeout: 264 seconds]
cosimone has quit [Remote host closed the connection]
cosimone has joined #ffmpeg-devel
MikhailAMD has quit [Quit: Leaving]
Krowl has quit [Read error: Connection reset by peer]