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
<durandal_1707> we live in simulation
<Lynne> we don't, it's impossible to make the laws of physics as messed up as this intentionally
<Lynne> otherwise there would've been mass interalien protests against how slow the speed of light is
<Lynne> and I'm pretty sure no one's ever said this before
<durandal_1707> physics uses math
<durandal_1707> just because laws of physics are bollocks and not elegant as math itself means we live in simulation
<Lynne> they are elegant, just not when we try to fit in the proton never decaying or try to do gravity on a quatum level
<durandal_1707> because its simulation
<Lynne> I'll only accept CP violation in your theory's favor, because it does sound like a genuine bug, like someone forgot to implement the rotation operator for an obscure particle
<durandal_1707> what is 'time' ? what is 'space' ?
<durandal_1707> if this is simulation, what am I ? just some dumb process? thread?
<Lynne> union { struct val { float space[3], float time }, float spacetime[4] };
<durandal_1707> isnt time global variable?
<Lynne> nnnope
<durandal_1707> why?
<durandal_1707> with local time - there is unlimited number of worlds/outcomes
<durandal_1707> which points out there is only one observer
<Lynne> the simplest explanation is that time can only be local because the maximum speed (that of light) is not infinite
<durandal_1707> if time can only be local there is only one observer
<Lynne> so you need a framework to synchronize events happening, which is done via lorentz transforms, in the context of special relativity
<durandal_1707> or infinite observers each in own simulation
<durandal_1707> special relativity only works at macro level
dellas has joined #ffmpeg-devel
<durandal_1707> just because exceeding/reaching speed of light at bigger levels is virtually impossible
<Marth64> i added chapter seletion to dvd so you can pick e.g. i want chapters 3-4 at exact cutpoints
eldowan has quit []
<Marth64> all thats left now is some samples i have some ac3 tracks starting too early wrecking timestamp calculation
<Marth64> once i fix will valgrind and submit
<Lynne> nah, all the quantum equations work just fine in a non-flat spacetime metric
<durandal_1707> imagine how would ffmpeg program find laws of outside world?
<durandal_1707> it could only speculate about CPU/RAM even if it could come at such concepts
<durandal_1707> when simulation's kernel panics than mandela-effect/deja-vu happens
<durandal_1707> or how would you program human coming with some new ideas?
<Lynne> if this was a simulation, and you transformed every single piece of matter into computronium, exploiting all the laws of physics as if they were just an ISA, then you could take over
<Lynne> and if it wasn't, you can still just take over and do whatever you wanted
<Lynne> not even heat death would stop it
<kierank> PaulGPT is learning empathy
<durandal_1707> you are mixing reality
<durandal_1707> and experience
<Lynne> go to mars and bring ffmpeg to mars again!
<durandal_1707> everyhing what is done is experience
<kierank> Touch grass
<durandal_1707> you cant make clear distinction between reality and experience, thus its simulation
<kierank> Valgrind is simulation
<kierank> Qemu is simulation
<frankplow> > kasper93: Speaking of VVC, I tried some file and it failed (32 shift of int https://0x0.st/HGv_.txt) and (null deref https://0x0.st/HGvL.txt) if someone is interested (compiled ac06190a5a)
<frankplow> I posted a patch earlier today fixing the 32 shift of int (gives a ubsan error but no actual failures though AFAICT). Which is the sample producing the null deref? Doom9 seems to have a lot of invalid samples floating around produced by uvg266
<durandal_1707> even with invalid samples null deref is not good
dellas has quit [Remote host closed the connection]
<kasper93> frankplow: I got a file from this post https://forum.doom9.org/showpost.php?p=1996384&postcount=901 Chicago Fire one crashes. I posted before download link https://we.tl/t-ztfQeVjxNP
<frankplow> kasper93: Thanks
<drv> there we go, the old irc logs come through: https://www.flickr.com/photos/av500/albums/72157624309805057/
<kasper93> btw. it doesn't crash everytime, so it probably is memory corruption or threading issue, not simple missing null check
thilo has quit [Ping timeout: 256 seconds]
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
thilo has joined #ffmpeg-devel
deus0ww has quit [Quit: Textual IRC Client: www.textualapp.com]
deus0ww has joined #ffmpeg-devel
navi has quit [Quit: WeeChat 4.0.4]
lexano has quit [Ping timeout: 264 seconds]
Marth64 has quit [Quit: Leaving]
epony has joined #ffmpeg-devel
MrZeus has quit [Ping timeout: 276 seconds]
kasper93 has quit [Remote host closed the connection]
kasper93 has joined #ffmpeg-devel
durandal_1707 has quit [Ping timeout: 260 seconds]
durandal_1707 has joined #ffmpeg-devel
lemourin has quit [Read error: Connection reset by peer]
lemourin6 has joined #ffmpeg-devel
lemourin6 is now known as lemourin
jamrial has quit []
compnn has quit [Read error: Connection reset by peer]
compnn has joined #ffmpeg-devel
cone-315 has joined #ffmpeg-devel
<cone-315> ffmpeg Tong Wu master:8b41e9cfbe64: avcodec/d3d12va_decode: check existance before assigning a new index
<cone-315> ffmpeg Tong Wu master:8c99a1429a19: avcodec/d3d12va_mpeg2|vc1: remove the unused macros
epony has quit [Remote host closed the connection]
epony has joined #ffmpeg-devel
qeed has quit [Ping timeout: 264 seconds]
qeed has joined #ffmpeg-devel
Marth64 has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
taniey has quit [Read error: Connection reset by peer]
taniey has joined #ffmpeg-devel
Wenbin_Chen_ has quit [Remote host closed the connection]
Wenbin_Chen_ has joined #ffmpeg-devel
jarthur has quit [Quit: jarthur]
Wenbin_Chen_ has quit [Read error: Connection reset by peer]
Wenbin_Chen has joined #ffmpeg-devel
Wenbin_Chen has quit [Read error: Connection reset by peer]
Wenbin_Chen_ has joined #ffmpeg-devel
cone-315 has quit [Quit: transmission timeout]
Krowl has joined #ffmpeg-devel
AbleBacon has quit [Read error: Connection reset by peer]
Wenbin_Chen_ has quit [Remote host closed the connection]
Wenbin_Chen has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
<elenril> meh, moving devices into lavf creates a circular dependency between lavfi and lavf
Wenbin_Chen_ has joined #ffmpeg-devel
Wenbin_Chen has quit [Read error: Connection reset by peer]
<elenril> wbs haasn JEEB jkqxz: just in case you didn't notice, I pinged an old TC issue yesterday
<wbs> elenril: yes - I just replied to it, didn't I?
<elenril> oh, didn't notice that, sorry
Krowl has joined #ffmpeg-devel
<JEEB> elenril: yea I noticed but being in between of a flu and bleeding
<elenril> yeah no hurry, it just happened in the past that people just didn't notice the email
<elenril> and try not to bleed too much, I hear it's bad for you in large quantities
<JEEB> yea thankfully it's been rather limited
<JEEB> also I should check if filter-overlay-dvdsub-2397 still fails on current master if the dca decoder is disabled
<JEEB> and if so, the audio stream should probably be disabled?
<JEEB> when you don't have the decoder the container provided channel count is all that is left (6), and that ends up being interpreted by the framecrc muxer as 5.1 (as opposed to "5.1(side)")
<JEEB> since the test should only be testing dvdsub overlay, not sure the audio part is too essential?
<JEEB> (if -an is added to it, the stream 0 packets' output doesn't change)
<elenril> so do that then?
Wenbin_Chen_ has quit [Remote host closed the connection]
Wenbin_Chen has joined #ffmpeg-devel
<JEEB> yea
<JEEB> just wanted to note it to see whether there would be some reason the audio is also being handled there
<elenril> could ask michaelni, as he added that test
<elenril> but I'd expect no
<JEEB> yeh
<elenril> wbs: also, do you have any experience with circular dependencies between SOs on weird platforms like windows?
<wbs> elenril: yes, the simple answer is that circular dependencies aren't allowed
<elenril> that sucks
<elenril> can we kill the lavfi device then
<elenril> and the movie filter source too
<wbs> (the long answer is that it's somehow possible by jumping through hoops, but it's quite a severe mess and I don't remember how widespread the toolchain support for it is)
kurosu has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
taniey has quit [Quit: Leaving]
HarshK23 has quit [Quit: Connection closed for inactivity]
Martchus has joined #ffmpeg-devel
<av500> drv: you are welcome :)
paulk-bis has quit [Ping timeout: 268 seconds]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
paulk-bis has joined #ffmpeg-devel
<elenril> a wild av500 appears
<kierank> woah
<kierank> old school
<JEEB> :)
dellas has joined #ffmpeg-devel
<elenril> can anyone here build the avisynth demuxer?
<JEEB> i think ever since it went avisynth+ it became cross platform?
<elenril> it's not in debian, so...
Krowl has quit [Read error: Connection reset by peer]
Wenbin_Chen has quit [Remote host closed the connection]
Wenbin_Chen has joined #ffmpeg-devel
Wenbin_Chen has quit [Remote host closed the connection]
Wenbin_Chen has joined #ffmpeg-devel
HarshK23 has joined #ffmpeg-devel
<elenril> mkver: I'm wondering why didn't you make ff_toupper4() inline
<elenril> it seems simpler and smaller
<mkver> Size binary size increase in cold code.
<mkver> Inlining it is supposed to 6560B from libavformat.so? Am I supposed to believe this?
<elenril> it's what I get
<mkver> Or are there other differences between these builds.
<elenril> https://up.khirnov.net/5x should be the only diff
<elenril> the difference persists after a clean rebuild of each
<mkver> Probably due to page-padding.
<mkver> Non-inlined .text f6d4e5, inlined f6d585
<mkver> elenril: I am actually surprised that you avprived this in 0842d58998f441768b5e4376aa0c1d7be0e07a8b.
<elenril> it was a different time
<elenril> that was when avpriv was created in the first place
<elenril> see 65d3176aaf8f876e0769f200abe95cac42151c89 right after it
<wbs> frankplow: any luck with the other asan findings?
<frankplow> wbs: I haven't had much time to look at it yet, but initially have been unable to reproduce the underflow you sent yesterday.
<frankplow> wbs: Is there any chance https://patchwork.ffmpeg.org/project/ffmpeg/patch/20240125170518.61211-1-post@frankplowman.com/ fixes it? That patch reduces stack usage enough to fix the other errors on my system.
<wbs> frankplow: that's weird then. in the worst case, it could be a compiler bug on my side - definitely possible but I find it less plausible here
<wbs> frankplow: how does that reduce stack usage? Isn't it doing the same after rounding a float log2 back to an integer?
Krowl has joined #ffmpeg-devel
<wbs> frankplow: (also, the other fixes you posted as a patch yesterday, which did fix issues on armv7, are they ready to be posted for review?)
<frankplow> wbs: No `ff_log2` is defined with bit hacks in intmath.h
<wbs> frankplow: do you mean that the implementation of log2() itself uses a lot of stack, while ff_log2() uses less?
<frankplow> wbs: Yes, my theory is that the clobbering was occuring inside the log2 call as its implementation uses a lot of stack. Guessing this wasn't coming up on ASAN because the standard library isn't instrumented? Maybe you have to set extra flags for this I'm not sure.
<durandal_1707> hacks
<wbs> frankplow: that's really weird - are we using huge amounts of stack to begin with in the vvc decoder? Anyway, I'll try and see if it makes a difference
<frankplow> wbs: Yeah I think there are some large stack allocations, but the patch I sent yesterday was a hack by reusing memory allocated for a different task stage. I will polish it up and send a better version I think. The av_log2 patch fixed all the errors in the two FATE tests you sent the day before last on my system.
<wbs> frankplow: indeed, the av_log2 patch does fix things for the i686 clang case
Wenbin_Chen_ has joined #ffmpeg-devel
Wenbin_Chen has quit [Read error: Connection reset by peer]
navi has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
MrZeus has joined #ffmpeg-devel
<wbs> frankplow: I know what the issue is now, and it's not the fault of the vvc decoder
<wbs> it's old ffmpeg sins
<JEEB> \o/
dellas has quit [Remote host closed the connection]
<wbs> patch posted
<kierank> wbs: lol
<wbs> frankplow: the real reason was that something, somewhere, called AV_ZERO128, which was inline MMX assembly, which clobbered the FPU state. so the first call to a float log2() returned NAN
Wenbin_Chen_ has quit [Read error: Connection reset by peer]
<wbs> but an integer log2() works fine
<wbs> sorry, AV_ZERO64
Wenbin_Chen_ has joined #ffmpeg-devel
<wbs> whoever called AV_ZERO64 didn't know to check FF_COPY_SWAP_ZERO_USES_MMX and call emms_c() conditionally after that
lexano has joined #ffmpeg-devel
<frankplow> wbs: Ah I see. Do you know why the patch I sent yesterday worked?
<wbs> frankplow: because av_log2() is implemented with integer math and doesn't care about the FPU state
<wbs> while the real math log2() on i686 returns NAN in this case, if the FPU state wasn't cleared after the MMX
<frankplow> wbs: Sorry, not the log2 patch I sent to the ML, the one I sent you on IRC.
<wbs> frankplow: ah, I have no idea about that one, but it fixed the issue on armv7 as such, and the av_log2() fix isn't enough to fix things on i686 either
<wbs> so the fix from irc yesterday is necessary in both cases
<frankplow> wbs: Ah ok.
Krowl has joined #ffmpeg-devel
beastd has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
dellas has joined #ffmpeg-devel
MrZeus has quit [Read error: Connection reset by peer]
<durandal_1707> just opened firefox and it welcomed me with stupid animation
<durandal_1707> this simulation is going to fail
<Lynne> browsers think of themselves as being operating systems more than emacs ever did
<durandal_1707> emacs compared to browsers is like ed compared to vim
<frankplow> kasper93: Does https://0x0.st/HGIS.patch fix your null deref? I haven't been able to reproduce it.
Wenbin_Chen has joined #ffmpeg-devel
Wenbin_Chen_ has quit [Read error: Connection reset by peer]
<kasper93> frankplow: nope, still have it. Honestly from quick try I cannot reproduce with ffmpeg.c either.
<kasper93> I can consistently reproduce it through mpv
<kasper93> I may have time in the evening to minimize reproducer
<frankplow> kasper93: Great
Wenbin_Chen_ has joined #ffmpeg-devel
Wenbin_Chen has quit [Read error: Connection reset by peer]
<BBB> slight variations in api usage could cause that...
<BBB> different threading setup etc
Krowl has quit [Read error: Connection reset by peer]
<durandal_1707> hacks
<kasper93> frankplow: but if you want to try yourself before, simple `mpv --no-config <file>` is enough to trigger the issue. mpv itself is easy to build against latest ffmpeg.
AbleBacon has joined #ffmpeg-devel
<kierank> how do we get vvc into oss-fuzz
<Lynne> with av1, do we have extradata, and does it contain the sequence header?
<BBB> agree with kierank, please add vvc to ossfuzz
<nevcairiel> it can exist, does not have to, not really different to other codecs
<JEEB> ^
<nevcairiel> (re: av1)
<kierank> I dunno how we update oss-fuzz
<BBB> I assume michaelni has sekret permissions for that?
<mkver> Why would VVC need updates to ossfuzz at all?
<mkver> Aren't all codecs automatically fuzzed through ossfuzz? (With the caveat that nested codecs mostly don't work...)
<wbs> I think it could be beneficial if we could update some initial seed sample set to contain VVC samples
<wbs> so we don't need to wait for a random permutator to accidentally produce valid-ish VVC bitstreams
<JEEB> yup
<kasper93> couldn't it periodically update corpus from the (new) fate samples? Although automating that might be overenginering. But new codecs should indeed be included to kick-start fuzzing.
<kasper93> speaking of Last Successful build: 1/8/2024
<kasper93> or in normal date format 08.01.2024
Krowl has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
Wenbin_Chen has joined #ffmpeg-devel
Wenbin_Chen_ has quit [Ping timeout: 256 seconds]
epony has quit [Remote host closed the connection]
epony has joined #ffmpeg-devel
rvalue has quit [Remote host closed the connection]
rvalue has joined #ffmpeg-devel
jarthur has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
zsoltiv_ has joined #ffmpeg-devel
<kasper93> out of curiosity I've taken a look at last successful oss-fuzz build log
<kasper93> ffmpeg_AV_CODEC_ID_VVC_fuzzer failed "build check" because it broke instantly https://0x0.st/HGUK.txt
<kasper93> and there is no newer build, because anything after 8th failed to build at all
<kasper93> so VVC is not fuzzed indeed, even ignoring the seeding data
sudden has quit [Quit: leaving]
sudden has joined #ffmpeg-devel
<durandal_1707> hacks
qeed has quit [Quit: qeed]
qeed has joined #ffmpeg-devel
<kasper93> we call them specially crafted optimizations, not hacks
<durandal_1707> ffmpeg started as hack, and will remain hack.
<kierank> sparkling hacks
<kierank> from the hack valley
<kierank> 16:56:46 <kasper93> ffmpeg_AV_CODEC_ID_VVC_fuzzer failed "build check" because it broke instantly https://0x0.st/HGUK.txt
<kierank> lol
<JEEB> ah yes, that nullptr access case
<durandal_1707> JEEB goes nuclear
<kierank> kasper93: where did you find the last working build
<kierank> I was looking at that
<kierank> ah yeah
<kierank> michaelni: can you share the vvc crash samples with frankplow
<JEEB> durandal_1707: oh yes, the MGS V song. nice of you to remind me of it.
philipl_ has quit [Quit: leaving]
Krowl has joined #ffmpeg-devel
philipl has joined #ffmpeg-devel
dellas has quit [Remote host closed the connection]
dellas has joined #ffmpeg-devel
kurosu has quit [Quit: Connection closed for inactivity]
MrZeus has joined #ffmpeg-devel
cone-387 has joined #ffmpeg-devel
<cone-387> ffmpeg Frank Plowman master:cb7b4ee02491: lavc/vvc: Use av_log2 when destination is integer
<cone-387> ffmpeg Frank Plowman master:763e31a8d3e3: lavc/vvc: Clamp shift RHS
Krowl has quit [Read error: Connection reset by peer]
deus0ww has quit [Ping timeout: 256 seconds]
deus0ww has joined #ffmpeg-devel
iive has joined #ffmpeg-devel
___nick___ has joined #ffmpeg-devel
___nick___ has quit [Client Quit]
___nick___ has joined #ffmpeg-devel
___nick___ has quit [Client Quit]
___nick___ has joined #ffmpeg-devel
Helenah has joined #ffmpeg-devel
Helenah has left #ffmpeg-devel [#ffmpeg-devel]
<durandal_1707> JEEB: WOW, i mostly only fan of tubular bells
<Traneptora> oops, something went wrong https://0x0.st/HGG6.txt
<Traneptora> lemme see if I can valgrind it
Krowl has joined #ffmpeg-devel
<cworley> noob demuxer question... i'm looking at https://wiki.multimedia.cx/index.php/Actimagine_Video_Codec which says > Audio data is stored immediately after video data aligned to 16 bits so in order to decode audio you need to decode video frame first.
<cworley> this seems to be true, packets go straight into macroblocks without any indication of where audio data starts
<durandal_1707> looks live DV
<durandal_1707> DV have audio interleaved or something....
<Traneptora> ugh, don't you hate when a segfault doesn't occur in valgrind
<Traneptora> but it occurs outside of valgrind
<Marth64> yess i ran into that few weeeks back
<cworley> any tricks for splitting the audio stream, besides handling the video codec in the demuxer?
<durandal_1707> cworley: if there is no way to fast skip video data its big mess
<JEEB> most formats have the size of the video
<cworley> unfortunte
<Traneptora> I'll have to reproduce it on a minimal debug build
<durandal_1707> Traneptora: similar happens with -fsanitize=*****
<Traneptora> well atm it's ???? in libavfilter.so, so I'll see what can happen
<Traneptora> it's possibly an nvidia bug but it's also possible that libplacebo isn't checking an error message properly
<kasper93> frankplow: I've taken a look at my case, but as of now I would start with `make tools/target_dec_vvc_fuzzer` and make this not crash instantly. Right now it crashes with one byte input `0xa`.
<kasper93> baby steps, we need to establish baseline to reject obvious incorrect data in clean way
mkver has quit [Ping timeout: 276 seconds]
<Marth64> all outstanding DVD issues are fixed. I have looked everywhere for SDDS sample but can't find one, so convinced SDDS on DVD-video is vaporware, can't implement it without testing.
<Marth64> added a bunch of documentation as well
<Marth64> rebasing w/ master and sending
<Traneptora> durandal_1707: testing now with -fsanitize=address, see if I can diagnose it that way
<Traneptora> may be a race condition which causes it to not fail in valgrind
<durandal_1707> in my case it was not race but more stack corruption
<durandal_1707> or heap wrong access
<frankplow> kasper93: yes boss
Goedix has joined #ffmpeg-devel
<Goedix> hi
<Goedix> I am having problems with reading subtitles with avcodec_decode_subtitle2
Goedix_ has joined #ffmpeg-devel
<Goedix_> I am having problems with reading subtitles with avcodec_decode_subtitle2
Goedix has quit [Remote host closed the connection]
<Goedix_> I can't get the end display time from the subs, always 0 in the AVSubtitle struct
<Traneptora> aight, triggered it with asan
<JEEB> Goedix_: which subtitle format?
<Traneptora> I'll try with git master libplacebo as well
<Goedix_> JEEB: SRT, I can get the text, but the start and end time is always 0
<JEEB> also compare with `ffprobe -of json -show_frames -select_stream s -i INPUT > sub_frames.json`
<JEEB> (or was it select_streams)
___nick___ has quit [Ping timeout: 246 seconds]
<JEEB> but if it's just an srt file, then no selection needed since it's a single stream there
<Goedix_> is a mp4 file that includes the srt, i can get the srt file with ffmpeg correctly, but i need to use avcodec_decode_subtitle2
<Goedix_> With the CLI works*
<JEEB> mp4 does not have a mapping for srt :D
Krowl has quit [Read error: Connection reset by peer]
<Goedix_> I tried with mkv too and doesn't work
<JEEB> but in any case, test against ffprobe. ffprobe is a minimal API client
<Goedix_> I will try
Marth64 has quit [Quit: Leaving]
durandal_1707 has quit [Quit: leaving]
<Goedix_> With ffprobe i could get the correct data about the mkv file but AVSubtitle.start_display_time and end_display_time are always 0 in my code (but the subtitle text is shown in the AVSubtitle.ass)
<Goedix_> start_display_time is 0 in the json and in my case, but end_display_time is not the correct value, also AVSubtitle.pts returns a negative value against the correct positive value
<Traneptora> hm, why is ffmpeg.c calling pixman and other g_malloc() functions on the CLI?
<Traneptora> glib leaks memory
MrZeus has quit [Ping timeout: 246 seconds]
<Lynne> yup, it does
<Lynne> I believe it's because of either librsvg or something like libpulse bringing it in
___nick___ has joined #ffmpeg-devel
<Traneptora> why'd it being loaded though?
<Traneptora> or rather, why'd code in it being called
<Traneptora> even if it's linked, it should load the lib into memory but I don't see why any of it symbols are being called for a function like this one
<Lynne> probably to detect whether pulse is available to capture or play into
<Lynne> I just have "export G_SLICE=always-malloc" in my bash config
<Lynne> which silences the errors somewhat
<Traneptora> >probably to detect whether pulse is available to capture or play into
<Traneptora> why is it doing that?
<Lynne> to be able to list available devices if needed
<Traneptora> why is ffmpeg.c doing that
<Traneptora> I don't see why ffmpeg.c is initializing the pulse avdevice
<Lynne> probably because it's too early in the init process
<Lynne> it's not ffmpeg.c doing it intentionally
hpkn has joined #ffmpeg-devel
<Lynne> just ffmpeg.c doing it through lavf doing it through lavd
<Traneptora> like, I get that glib shouldn't leak memory, but somewhere somebody is calling an init function for glib on a command that doesn't need it
<Traneptora> and that feels like an ffmpeg bug
<BtbN> I doubt ffmpeg does that, more like some external library
<Lynne> yup, libpulse or libcdio or librsvg are the ones I know
<Traneptora> sure, but why is ffmpeg calling anything in those libraries at all
<Traneptora> for a command that doesn't need it
<Lynne> ffmpeg.c does this for other stuff too, like libx264 being unconditionally called during init even if no video is going to be played
<Traneptora> that sounds like an ffmpeg bug
<BtbN> That's just how probing works
<BtbN> specify the format explicitly
<Traneptora> I do
<Traneptora> ffmpeg -f lavfi -i testsrc -t 1 -f null -
<Traneptora> this is the command
<Goedix_> What is the stacktrace of ffprobe when using for example -show_frames? I know that it ends in int process_frame -> void show_frame
<BtbN> It's also possible some external library has a static initializer that calls stuff
<Traneptora> that may be the case
<Lynne> for x264, it's rather unavoidable, since lavc needs to know what formats the library supports upfront, so we have a preinit mechanism
<Traneptora> naturally this wouldn't actually be a problem if glib didn't leak memory
<Traneptora> but I'm just wondering where it's coming from
<BtbN> should be pretty trivial to just set a breakpoint and see
cone-387 has quit [Quit: transmission timeout]
<Lynne> for me, librsvg brings it in
<Lynne> doesn't happen under standard configure
<Lynne> and since that decoder doesn't have an init function, and librsvg_decode_frame is never called, the glibc code probably gets inserted during linking or compilation time somehow
<Lynne> I've said it before, glibc is poison
<Traneptora> glibc or glib-2.0
<Traneptora> not the same thing
<Lynne> glib, sorry, I often mistake them
<Traneptora> ye glibc might be "lol glibc" but glib-2.0 is what leaks memory
<Traneptora> I think BtbN is probably correct that a static initialization is happening
<Lynne> yup
<Traneptora> Lynne> I just have "export G_SLICE=always-malloc" in my bash confi
<Traneptora> what does this do?
<Lynne> turns off their NIH malloc which is slower than glibc
<BtbN> I didn't add rsvg to my builds, purely because it alone would double the binary size with all its dependencies
<Lynne> you also need "export G_DEBUG=gc-friendly" to make it stop leaking memory
<Traneptora> I thought g_malloc just called malloc
<Lynne> haha no
<Traneptora> valgrind says it does
<Lynne> maybe they've changed that, it wasn't the case in the past
<Traneptora> implementing your own malloc pool is one of the dumbest things you can do
<Lynne> mimalloc, jemalloc too, all of these old libraries surviving only on cargo cult because glibc wasn't fast enough a few years ago
<Traneptora> remember that openssl used to do that and memory debuggers never found use-after-free and the like cause its free never actually freed
<Traneptora> literally how heartbleed happened
<Traneptora> <Lynne> maybe they've changed that, it wasn't the case in the pas
<Traneptora> they'd have to, otherwise valgrind wouldn't be able to tell
<BtbN> jemalloc still is a speedup over glibc/win32 malloc
<Traneptora> what about the infamous tcmalloc
<BtbN> Its build system is a mess, so I never managed to test
<BtbN> Even jemalloc I only managed to get to work when doing shared linking
<BtbN> Somehow even making ffmpeg explicitly call je_malloc, it fails when statically linking
<Lynne> yeah, I wish ffmpeg had regular callback interface for alloc/free to monitor how much is used
<thardin> gemalloc
cone-885 has joined #ffmpeg-devel
<cone-885> ffmpeg James Almer master:eb4584f994fb: avcodec/vvc_ps: remove duplicated enum
hpkn has quit [Remote host closed the connection]
<cone-885> ffmpeg Anton Khirnov release/5.1:dd885ab2f506: fftools/ffmpeg_enc: apply -top to individual encoded frames
___nick___ has quit [Ping timeout: 264 seconds]
jnbek has joined #ffmpeg-devel
jnbek has quit [Quit: kthx]
jnbek has joined #ffmpeg-devel
ccawley2011 has quit [Read error: Connection reset by peer]
jnbek has quit [Quit: kthx]
jnbek has joined #ffmpeg-devel
MikhailAMD has quit [Read error: Connection reset by peer]
MikhailAMD has joined #ffmpeg-devel