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
Wenbin_Chen__ has joined #ffmpeg-devel
Wenbin_Chen_ has quit [Remote host closed the connection]
<Sean_McG>
jkqxz: VA-API 1.x removal probably deserves a Changelog entry if it is merged
thilo has quit [Ping timeout: 268 seconds]
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
thilo has joined #ffmpeg-devel
AbleBacon has quit [Read error: Connection reset by peer]
arch1t3cht4 has joined #ffmpeg-devel
arch1t3cht has quit [Ping timeout: 268 seconds]
arch1t3cht4 is now known as arch1t3cht
rvalue has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 260 seconds]
jamrial has quit []
rvalue has joined #ffmpeg-devel
cone-336 has joined #ffmpeg-devel
<cone-336>
ffmpeg Andreas Rheinhardt master:9309b5bc64a9: avcodec/vvc/vvc_inter_template: Fix left shift of negative number
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 246 seconds]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
<mkver>
Lynne: Did you actually test PPC BE? This code is BE only.
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 264 seconds]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
<Lynne>
ah, no, was testing on an LE machine back then
rvalue has joined #ffmpeg-devel
IndecisiveTurtle has joined #ffmpeg-devel
mkver has quit [Ping timeout: 264 seconds]
IndecisiveTurtle has quit [Ping timeout: 255 seconds]
kurosu has joined #ffmpeg-devel
<elenril>
does anyone have strong feelings about adding SO constructors that would enforce compatible library versions?
<andrewrk>
yes, strong negative feelings
<andrewrk>
this is slightly non-portable and relies on problematic linker features
<elenril>
problematic?
<elenril>
I know it wouldn't work everywhere, but better than nothing
<andrewrk>
for example c++'s Static Initialization Order Fiasco essentially boils down to the problem of running global constructors at runtime. it's kinda the same thing. it's much simpler for many parts of the tool chain if they can assume that loading is only memcpy
<andrewrk>
I get it though, the desire to automate avoiding erroneous bug reports
cone-336 has quit [Quit: transmission timeout]
<andrewrk>
but as an application author, I don't want any of my library dependencies stealing the program counter until I offer it with consent
<elenril>
I still don't see what the actual problem for this case would be
<andrewrk>
succintly: not strictly necessary additional work for the library to perform on startup. additional work for the compiler toolchain. false positive version mismatches. occasional FTBFS due to linker bugs or weird interactions with C++
<psykose>
what kind of compatible library version check would it be? 99% of the time if you build against some version and have some older version at runtime it doesn't work anyway because of missing symbols
<psykose>
and newer is also fine pretty much almost always
<Lynne>
elenril: for intra-ffmpeg libraries, for external libraries, or for API users linking to ffmpeg libs?
<elenril>
Lynne: the first
<psykose>
huh, what kind of packaging are people doing that those get mixed up
<Lynne>
elenril: sure, I've been bitten by that a couple of times, I'd like that
<psykose>
that sounds much more ok, though also funny
<elenril>
psykose: there aren't always missing symbols
<elenril>
so I've been wondering if we should have a more robust way of detecting it
<cone-568>
ffmpeg Wenbin Chen master:478d97f3034f: libavfilter/dnn_io_proc: Take step into consideration when crop frame
<Sebastinas>
elenril: If such checks are added, please ensure that SONAMES are bumped for all or none of the lbraries.
<elenril>
how is that related?
<Sebastinas>
Otherwise it is hard for us (and I'd probably just remove the check) to ensure consistent dependencies.
<andrewrk>
Lynne: I'm still debugging it but I have completed the implementation of chromaprint. it's 499 lines of zig (compared to 6,496 lines of C++)
<wbs>
elenril: which inconsistencies specifically are you trying to avoid?
<elenril>
Sebastinas: I don't quite follow, the check failing means UB
<elenril>
wbs: e.g. lavc being run with an older lavu
<Lynne>
andrewrk: nice
<Sebastinas>
elenril: We had for some time ffmpeg 5.x dependencies having libavutil from ffmpeg 6.x since that didn't get bumped.
<wbs>
elenril: newer lavc with older lavu, but same major soname? I see
<Sebastinas>
elenril: Okay, that wouldn't be a problem for Debian, but also doesn't add anything.
<andrewrk>
hi Sebastinas, it's been long time
<Sebastinas>
Hi :)
<andrewrk>
still doing the Lord's work in Debian land, I see?
<wbs>
Sebastinas: that's good. we've gotten requests from people who interpret sonames/symbol versions very literally, assuming that you should be able to use the latest libavcodec with the oldest libavutil as long as the libavutil has the same soname and no symbol versions missing
Krowl has joined #ffmpeg-devel
<Sebastinas>
andrewrk: I try to at least keep some of the pieces together. How's it going with zig?
<andrewrk>
pretty well. I've started an earnest effort to rewrite my music player project with it :)
<andrewrk>
I've been drawing on my debian packaging experience - thanks to your mentorship! - to help guide making the zig package manager be both useful to upsteram authors, but also importantly to distro maintainers
ngaullier has joined #ffmpeg-devel
<elenril>
Sebastinas: by "add anything" you mean in addition to existing constraints in the packages?
<Sebastinas>
elenril: Exactly, our package constraints are already at "libav* package from the same build" and for ffmpeg 5.x -> ffmpeg 6.x we had it relaxed in the ffmpeg 5.x packages to >= $upstream_version.
<elenril>
right, but not everybody is using debian and not every debian user is using the packages
<Sebastinas>
Well, it adds runtime overhead where we already have people complaining about constructor side effects of libraries linked by libav*
<Sebastinas>
Sure
<elenril>
I can't imagine this single check having a measurable runtime cost
<elenril>
unless there's some significant overhead from having a constructor at all
alien_lappy has left #ffmpeg-devel [#ffmpeg-devel]
<jdek>
when are we getting zig in ffmpeg
<elenril>
what you say
Krowl has quit [Read error: Connection reset by peer]
Krowl has joined #ffmpeg-devel
Raz- has joined #ffmpeg-devel
<JEEB>
j-b: will respond on the patch, but it still mentions libaom
<JEEB>
unless the patch was sent before I commented, o' course
<JEEB>
(with a MR/PR I would have seen what the current state is)
<j-b>
JEEB: there is a v2
<j-b>
JEEB: it says "HDR10 metadata passthrough when encoding with libx264, libx265 and SVT-AV1"
Krowl has quit [Read error: Connection reset by peer]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
cone-568 has quit [Quit: transmission timeout]
<JEEB>
j-b: alrighty then
Krowl has joined #ffmpeg-devel
<haasn>
elenril: have you ever thought about possible ways to make 2pass stuff work in a single ffmpeg.c invocation?
<elenril>
no
<elenril>
why?
<elenril>
is 2pass even useful today?
<haasn>
not too sure about encoding but there are several use cases for filters that want to first analyze the stream before filtering it
<haasn>
but currently they're fairly awkward to use, e.g. palettegen, encode that out to a temporary file, then use paletteuse
<haasn>
ditto for e.g. scene detection / color volume measurements + tone mapping
<elenril>
right, I guess that makes sense
<elenril>
I have not thought about it much, but I imagine it'd be either incredibly hacky, or involve massive changes to lavfi architecture
<haasn>
I was wondering if we could somehow just 'restart' the filter graph and send all the same frames again for a second time
<haasn>
yeah
<haasn>
probably not worth the effort
<elenril>
but then I'm generally of the opinion that lavfi architecture could benefit from some massive changes
<haasn>
I was staring at AVFilterNegotiation today and wondering why it even exists
<haasn>
deleting this abstraction and expanding out all of the individual checks would probably be simpler and shorter than the supporting code to use this abstraction
<elenril>
I have a guess why it exists, but voicing it is probably a CoC violation
<Lynne>
practically every time I do twopass, I have to trial and error the second pass to get a filesize I want
jamrial has joined #ffmpeg-devel
dykai has joined #ffmpeg-devel
* Sean_McG
peeks in
lexano has joined #ffmpeg-devel
dykai has quit [Quit: dykai]
<haasn>
elenril: do you have a strong preference for unsigned *num_configs vs the list just being terminated (as currently)?
<haasn>
the latter seems a lot easier to implement both on the client and the codec side
dykai has joined #ffmpeg-devel
dykai has quit [Client Quit]
<haasn>
and you can still recover the length with a trivial loop, whereas you can't add a terminator without memcpy
<haasn>
y'know
<haasn>
the whole proposal for this API's existence was to cut down on the sizeof(AVCodec) for largely unused fields
<haasn>
but are we really gaining anything by having every compiled codec instead implement a custom overload for this get_supported_config() API
<haasn>
surely the size of a compiled function is larger than the fields we're saving
<Sean_McG>
yes, llauddsp seems to fail sporadically
<mkver>
Notice that both of these tests also trigger errors with ubsan.
<mkver>
I always hesitate to simply fix signed overflow errors by using unsigned, because this might hide bugs; therefore I did not "fix" the remaining ubsan issues.
<mkver>
Notice that with the patches on the ml, the list of ubsan failures on ppc should equal the list on x86.
<Sean_McG>
I think I can close my 2 Trac tickets, at the very least the one for 'filter-metadata-signalstats-yuv420p10'?
<mkver>
Just did.
<Sean_McG>
oh, cheers
<Sean_McG>
I'm still looking for a Mac G4 so I don't have to emulate -- all the listings I have seen on eBay seem sketchy, like I might get a machine that does not boot
<Marth64>
I've been keeping an eye out for you, Sean_McG. Haven't run into any yet
System_Error has quit [Ping timeout: 260 seconds]
<Marth64>
Just been seeing intels in our used electronics stores
<Sean_McG>
it's been so long that this should not be all that surprising, last G4 was made in.... 2005/6?
<Marth64>
yeah hahaha
<Marth64>
like once a quarter I see them around
<galad>
the powermac got a g5 in 2003, so the latest with the g4 were the notebooks and mac minis
<Marth64>
correction: I saw a PowerBook. but it was destroyed
<Marth64>
oh wow, they made g5 minis?
<galad>
no
<Marth64>
g4*
<galad>
yes
<Marth64>
:)
<galad>
the g5 was too hot to handle :)
Krowl has quit [Read error: Connection reset by peer]
<Sean_McG>
galad: and sounded like a jetplane when the fans got going
<galad>
I only had the 1.6 Ghz single-core
<Marth64>
like the 2019 intels
<galad>
but I don't doubt the dual cpu model were a wind tunnel
<Sean_McG>
I had a Quicksilver G4 733MHz, but gave it to an e-recycler some years ago.
<Sean_McG>
I still have a G4 Mini (forget what speed), but I think I mentioned it let out the magic smoke when I plugged it in a few months ago... sad day.
frabazz has joined #ffmpeg-devel
mkver has quit [Remote host closed the connection]
mkver has joined #ffmpeg-devel
<cone-001>
ffmpeg Marth64 master:e3335e9e9ebf: Changelog: fix typos for 7.0 section
<Marth64>
<3
<cone-001>
ffmpeg Marth64 release/7.0:4866aaf7c50a: Changelog: fix typos for 7.0 section
<JEEB>
wbs: oh, emsg. might check that out since I think I looked into those specs at one point
<cone-001>
ffmpeg Antoine Soulier via ffmpeg-devel master:240fd04db231: avcodec/liblc3: add encoding/decoding support of LC3 audio codec
<nevcairiel>
why is the ML not using SRS to rewrite senders, rather then this scuffed system? let me guess, because mailman doesnt know any better, and is also a major version behind? :D
<jamrial>
mailman is old, yeah
<jamrial>
it also mangles gpg signatures as generated by thunderbird
<jamrial>
mkver: length in extradata has a precedent, FLAC
<elenril>
haasn: I'd think the vast majority of encoders wouldn't need a custom callback
<mkver>
jamrial: For flac, it is more necessary, because it says that the md5 in the header applies to this number of samples.
<mkver>
And if I am not mistaken, then the last frame of a flac stream contains the number of samples explicitly coded in the bitstream, so it can be decoded without knowing the value in the header.
<jamrial>
actually, is this a length for the whole stream, or a per frame length?
<mkver>
Whole stream.
<elenril>
mkver: i just noticed you didn't finish the part of your refstruct set that fixed those vp9 races
<elenril>
any plans to continue that?
<mkver>
I am doing it.
<mkver>
I needed to redo wavpack a bit in light of your comment.
<jamrial>
speaking of races or general threading issues, vvcdec seems to have a lot of them
<mkver>
The wavpack patches on the ML are part of this.
<elenril>
ah, nice
<mkver>
tsan warns about potential lock-order-inversions, not about actual races.
<jamrial>
i know
<elenril>
I tried to resurrect the frame-threaded receive_frame patch and got hit by ffv1 races
<mkver>
FFV1 is special and evil.
<mkver>
New ffv1 races?
<elenril>
existing ones, but they become visible
<elenril>
(I think)
AbleBacon has joined #ffmpeg-devel
<mkver>
FFV1 is different from all other frame threaded decoders, because the other decoders only interact with the earlier threads in update_thread_context and when waiting on frames; this decoder actually looks at the last threads context.
<mkver>
Therefore there is special check in pthread_frame.c for it that ensures that with only nb_threads - 1 threads are actually running at any time.
<mkver>
They would fix all races, but would not fix the issue I just mentioned.
<raven4Get>
is there still plans on ditching mailing list?
<mkver>
The decoder should use some refcounting to share the common objects for this.
<mkver>
Btw: For a long time, ubitux's tsan boxes used a thread count of two and therefore did not show FFV1 races, because the decoder is single-threaded when using two threads.
<JEEB>
<3
<haasn>
18:30 <@elenril> haasn: I'd think the vast majority of encoders wouldn't need a custom callback <- are you proposing we keep the existing pix_fmts etc. fields?
<elenril>
wow, that's seriously evil
<haasn>
(maybe moved to FFCodec after a deprecation period)
<haasn>
otherwise I'm not sure how you wouldn't need a custom callback for every single AVCodec that needs to set a pix_fmts list
<elenril>
haasn: yes, I'm proposing we move them to FFCodec and have the default implementation forward that to the caller
<haasn>
although I can see something like a union { pix_fmts; sample_fmts } in FFCodec to replace the current AVCodec fields
<elenril>
could be a union for all video/audio exclusive fields
<elenril>
mkver: any fundamental you didn't finish that set, or just lack of time?
<elenril>
+reasons
<mkver>
michaelni asked me to separate the FFV1 contexts into main and slice context before the rest.
<mkver>
I intend to do it.
<elenril>
well, it's blocking my work
<elenril>
so I could also try doing it myself
<mkver>
Then it's priority just increased.
<elenril>
much appreciated
<mkver>
Are decoders actually supposed to set channel_layouts and sample_fmts at all?
<mkver>
Lots of them do, especially the latter.
<jamrial>
for query reasons maybe
<cone-001>
ffmpeg James Almer master:45d2110fc726: avcodec/liblc3dec: sanitize channel count in avctx
<cone-001>
ffmpeg James Almer master:3db674614d52: avcodec/liblc3enc: don't force unspec channel layouts
<elenril>
mkver: I think it's all cargo cult
<mkver>
The only reason I know why this could be useful is to distinguish the floating-point from the fixed point decoders for the few formats where we have both.
<mkver>
But actually maybe a get_format callback (or codec options) would be better for this.
<elenril>
I agree
ngaullier has quit [Ping timeout: 260 seconds]
Krowl has quit [Read error: Connection reset by peer]
Livio has quit [Ping timeout: 260 seconds]
<cone-001>
ffmpeg Michael Niedermayer master:28c7094b25b6: avcodec/wavarc: fix signed integer overflow in block type 6/19
<cone-001>
ffmpeg Michael Niedermayer master:4593cf7ab3f0: avformat/iamf_parse: Check sound_system
<cone-001>
ffmpeg Michael Niedermayer master:1a9eda65d027: swscale/utils: Fix xInc overflow
<cone-001>
ffmpeg Michael Niedermayer master:ed4939196199: avformat/mxfdec: Check index_edit_rate
<cone-001>
ffmpeg Michael Niedermayer master:bf3b74142e44: avformat/pcm: Use 64bit in bitrate computation
<beastd>
nevcairiel: Do you have experience with mailman 3 or possible alternatives?
<nevcairiel>
no, i live a happy life
<jamrial>
lol
<Sean_McG>
hahah
_whitelogger has joined #ffmpeg-devel
Livio has joined #ffmpeg-devel
<JEEB>
> Elapsed (wall clock) time (h:mm:ss or m:ss): 43:05.46
<JEEB>
cbs_h2645.c threw gcc 14's -fanalyzer into a loop :D
<mkver>
JEEB: Jackpot!
<JEEB>
unfortunately it did actually finish, and not get killed after 40+ min
<Sean_McG>
was it close to an OOM?
<JEEB>
> Maximum resident set size (kbytes): 3788136
<JEEB>
not really :)
raven4Get has quit [Ping timeout: 260 seconds]
BtbN has quit [Remote host closed the connection]
BtbN has joined #ffmpeg-devel
Livio has quit [Ping timeout: 256 seconds]
BtbN has quit [Remote host closed the connection]
BtbN has joined #ffmpeg-devel
Livio has joined #ffmpeg-devel
<mateo`>
hello there ! is Leo Izen on IRC ?
<JEEB>
yea
<JEEB>
I couldn't tab-autocomplete the nickname they last seemed to utilize so I guess they aren't online atm
<cone-001>
ffmpeg Michael Niedermayer release/7.0:d918d9afe0d4: avformat/isom: Uninit layout in ff_mp4_read_dec_config_descr()
<cone-001>
ffmpeg Michael Niedermayer release/7.0:839e8baa2078: doc/developer: (security) researchers should be credited
<cone-001>
ffmpeg Michael Niedermayer release/7.0:1ef084f91092: avcodec/wavarc: fix signed integer overflow in block type 6/19
<cone-001>
ffmpeg Michael Niedermayer release/7.0:97751fda3eb4: avformat/iamf_parse: Check sound_system
<cone-001>
ffmpeg Michael Niedermayer release/7.0:e0dd533ad6ef: swscale/utils: Fix xInc overflow
<cone-001>
ffmpeg Michael Niedermayer release/7.0:3736130e5b25: avformat/mxfdec: Check index_edit_rate
<cone-001>
ffmpeg Michael Niedermayer release/7.0:abaa747ee5db: avformat/pcm: Use 64bit in bitrate computation
<mateo`>
JEEB: as a last resort, is it acceptable if I apply the patch ?
<JEEB>
if it seems like 7.0 release is imminent I'd say it's acceptable
<mateo`>
thx, will apply and backport
<cone-001>
ffmpeg Leo Izen master:7c338f470f86: avcodec, avformat/ffjni: fix duplicate JNI symbols
kasper93_ is now known as kasper93
<cone-001>
ffmpeg Leo Izen release/7.0:9a4c7b937f4b: avcodec, avformat/ffjni: fix duplicate JNI symbols
Raz- has quit [Ping timeout: 240 seconds]
BtbN has quit [Remote host closed the connection]
Krowl has joined #ffmpeg-devel
BtbN has joined #ffmpeg-devel
kasper93_ has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
kasper93 has quit [Ping timeout: 268 seconds]
Livio has quit [Ping timeout: 268 seconds]
System_Error has joined #ffmpeg-devel
marcj has quit [Ping timeout: 268 seconds]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
System_Error has quit [Read error: Connection reset by peer]
System_Error has joined #ffmpeg-devel
marcj has joined #ffmpeg-devel
kasper93 has joined #ffmpeg-devel
kasper93_ has quit [Ping timeout: 260 seconds]
kasper93 has quit [Ping timeout: 256 seconds]
<cone-001>
ffmpeg Andreas Rheinhardt master:e54696bcaa08: avcodec/ppc/h264dsp: Fix left shifts of negative numbers
<cone-001>
ffmpeg Andreas Rheinhardt master:a4800643bba4: avcodec/lossless_videoencdsp: Don't presume alignment in diff_bytes
<cone-001>
ffmpeg Andreas Rheinhardt master:2f59648aed8b: avcodec/wavpack: Fix leak and segfault on reallocation error
<cone-001>
ffmpeg Andreas Rheinhardt master:c720c691889b: avcodec/dsd: Use double for LUTs
<cone-001>
ffmpeg Andreas Rheinhardt master:1c2860e8152e: fate/wavpack: Add test for DSD
<cone-001>
ffmpeg Andreas Rheinhardt master:e81fa9f48212: avcodec/wavpack: Only initialize DSD data when encountering DSD
<cone-001>
ffmpeg Andreas Rheinhardt master:6d38c260e57d: avcodec/dsddec: Fix decoding LSBF samples
<cone-001>
ffmpeg Andreas Rheinhardt master:aecd63478e32: avcodec/dsd: Hoist branch out of loop
<cone-001>
ffmpeg Andreas Rheinhardt master:d307aca184a1: avcodec/wavpack: Remove always-false check
<andrewrk>
hmmm my chromaprint implementation is working in that it generates fingerprints that produce the correct results from api.acoustid.org but the match score is significantly lower than when I try the same song with fpcalc
<andrewrk>
I also noticed that the compressed fingerprint is longer than the corresponding one generated by fpcalc
<andrewrk>
$ fpcalc --help
<andrewrk>
> -length SECS Restrict the duration of the processed input audio (default 120)
<andrewrk>
oh.
paulk has quit [Ping timeout: 256 seconds]
paulk has joined #ffmpeg-devel
paulk has quit [Changing host]
paulk has joined #ffmpeg-devel
paulk has quit [Ping timeout: 268 seconds]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
paulk has joined #ffmpeg-devel
kasper93 has joined #ffmpeg-devel
HarshK23 has quit [Quit: Connection closed for inactivity]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
<cone-001>
ffmpeg Michael Niedermayer release/7.0:4f0e9457d661: Update for 7.0
<cone-001>
ffmpeg Michael Niedermayer release/7.0:083443d67cb1: RELEASE_NOTES: Based on the version from 5.1
System_Error has quit [Remote host closed the connection]
<psykose>
yeah i usually reach for hyperfine but immediately noticed the other counters
<andrewrk>
yeah the other counters are nice
<andrewrk>
especially cache_misses
<andrewrk>
and instructions, which is immune to system load
<andrewrk>
a big difference between min and max is typical for pointer heavy C++ code that introduces nondeterminism through heap allocation. the zig code is much more consistent
<andrewrk>
not to mention less than half as much memory used
<andrewrk>
now if I could only get it to produce more accurate results :P
<psykose>
optimising the optimisation tool :)
<andrewrk>
ah I meant my audio fingerprinting code
<andrewrk>
I guess I'll pick somewhere in the audio processing pipeline and try to understand the difference between fpcalc's data and this code's data
psykose has quit [Remote host closed the connection]
psykose has joined #ffmpeg-devel
psykose has quit [Remote host closed the connection]
psykose has joined #ffmpeg-devel
<cone-001>
ffmpeg Andreas Rheinhardt n7.0:HEAD: avcodec/wavpack: Remove always-false check
kasper93 has quit [Remote host closed the connection]
<cone-001>
ffmpeg Andreas Rheinhardt release/7.0:0e3a46720af8: avcodec/ppc/h264dsp: Fix left shifts of negative numbers
<cone-001>
ffmpeg Andreas Rheinhardt release/7.0:82aa18828185: avcodec/lossless_videoencdsp: Don't presume alignment in diff_bytes
<cone-001>
ffmpeg Andreas Rheinhardt release/7.0:607fca80b770: avcodec/wavpack: Fix leak and segfault on reallocation error