michaelni changed the topic of #ffmpeg-devel to: Welcome to the FFmpeg development channel | Questions about using FFmpeg or developing with libav* libs should be asked in #ffmpeg | This channel is publicly logged | FFmpeg 7.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
<names_are_hard> Yeah, I would say it's a very low prio bug :)
mkver has quit [Ping timeout: 246 seconds]
arch1t3cht5 has joined #ffmpeg-devel
arch1t3cht has quit [Ping timeout: 248 seconds]
arch1t3cht5 is now known as arch1t3cht
thilo has quit [Ping timeout: 260 seconds]
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
thilo has joined #ffmpeg-devel
cone-288 has quit [Quit: transmission timeout]
System_Error has quit [Remote host closed the connection]
jamrial has quit []
System_Error has joined #ffmpeg-devel
pross has quit [Ping timeout: 260 seconds]
<compnnn> names_are_hard, that .5 second timer, what is your ffmpeg command? i mean, are you just testing decoder? if yes, then that code to show statistics should only be on the encode side, are you encoding as well?
<compnnn> said another way, why not just decode and dump to raw, then that .5 second thing shouldnt be activated ?
<compnnn> or its a bug that its being activated for things that dont need it? well just a theory. i'm stabbing in the dark
<compnnn> names_are_hard, and if you can keep track of tricks to speed up ffmpeg fuzzing/testing that would be nice to have as well
<compnnn> send fuzzing-speedup.patch later on...
pross has joined #ffmpeg-devel
Marth64 has quit [Quit: Leaving]
<elenril> names_are_hard: I don't see any forced pause here
<elenril> time ./ffmpeg -i /tmp/video.mkv -frames 1 -f null -
<elenril> real 0m0.159s
<elenril> the sch_wait() call should return immediately when all outputs finish
<names_are_hard> compnnn: ffmpeg -i sample -f null -
<names_are_hard> It does only do it on some samples. Guessing, ones with low reliability format / codec detection
<elenril> can you share one?
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 260 seconds]
<names_are_hard> https://0x0.st/X5mj.b64
<names_are_hard> Had to base64 it because 0x0.st tried to display it as an image and choked
<compnnn> names_are_hard, internet says since stats_period is an avopt, you can disable it with -nostats instead of changing the code
<compnnn> but no idea if it does what it says it do
<names_are_hard> Thanks. I did find that in the docs, but only after I'd already restarted fuzzer with patched binary
<elenril> oh wait, I need to deb64 it
<names_are_hard> md5 of restored file should be 9ceb934737a4c13ed9586a979f5fa0b3
<elenril> I can see it now
<names_are_hard> "slow" for you too?
<elenril> yes
<names_are_hard> Obviously what I'm doing doesn't represent what ffmpeg is used for, it's an extreme edge case
<names_are_hard> So it may well not matter at all
<elenril> no it does seem like a bug
<elenril> I'll have a closer look
<names_are_hard> Thanks, I'm curious as to why it's only some samples
<compnnn> maybe gets stuck on one detection?
<compnnn> we have had issues like that in the past , adjusting the probe scale for said format fixes it usually
<names_are_hard> Didn't look like it looped from callgrind graph, but I didn't dig hard
<names_are_hard> It's time consuming doing real root cause analysis on unfamiliar code. I just wanted to hack it as fast as I could to improve fuzzer throughput
^Neo has quit [Ping timeout: 255 seconds]
<compnnn> no worries, thanks for the sample
<compnnn> and your fuzz reports
<names_are_hard> If you were feeling very kind, you could poke someone who might be able to answer my questions, here: https://ffmpeg.org//pipermail/ffmpeg-devel/2024-November/335790.html
<names_are_hard> Mainly the one about "how much fuzzing am I supposed to do?". Michael asked me to do it, but didn't give any criteria for determining an adequate amount
<compnnn> probably resubmit patch as v3 , ask for someone to apply it if there are no other issues. link to samples.
<compnnn> not many devs work on bayer, its unlikely to get a review
<names_are_hard> Eh, it's not done many execs yet, the ability for jpeg decoding to both crash ffmpeg, and commonly run 50x slower than expected, has delayed things :)
<names_are_hard> Currently 11k samples (this will reduce down, haven't done corpus minimisation yet, guesstimate 4k samples?)
<compnnn> number of people who even fuzz test before submitting patch = very slim...
<names_are_hard> Understandable, it's time consuming, and a bit of an art
<compnnn> did you grab our image samples for testing?
<compnnn> although i dont remember having many bayer formats either
<compnnn> bayer samples*
<names_are_hard> I downloaded FATE samples, but they're all very large
<compnnn> but i dont see any bayer specific stuff so nevermind
<names_are_hard> Inefficient for fuzzing, so I seeded it with a handcrafted minimal file, just the ff d8 ff header bytes used in ffmpeg detection
<names_are_hard> Fuzzer evolves samples from there by instrumenting ffmpeg and keeping only samples that improve coverage, it discovered the bayer + progressive crash in a few hours
<names_are_hard> It's running much more smoothly now, I'll leave it over the weekend, should have done 40 million execs by then (slow; only a single core on a laptop)
<names_are_hard> Perhaps that will be enough to satisfy the mailing list gods
<compnnn> maybe ping pross . maybe he can review
<names_are_hard> Thanks, will try Mon most likely
<compnnn> (i mean hes in the channel and i just mentioned him so maybe he'll see it)
<compnnn> ehe but ok see ya monday
<names_are_hard> Oh, one question :) Is there a way to get ffmpeg to decode a large number of input files (too large for shell expansion) to null?
<elenril> why would you want to do that in a single process?
<names_are_hard> Saves initialisation time with valgrind
<elenril> you could try one of the playlist formats
<elenril> also, I now see why your delay is happening
<elenril> but no simple way of avoiding it
<elenril> or maybe....
<names_are_hard> Playlist is a good idea, thanks
<names_are_hard> Quick analysis on the mysterious problem - what's the cause?
<elenril> the exit criterion is driven by muxing threads finishing
<elenril> but in your case no muxing threads are ever started
<compnnn> names_are_hard, you can use pipe as input https://ffmpeg.org/ffmpeg-protocols.html#pipe , but i thought there was an input playlist too lets see
<compnnn> hmm
<names_are_hard> Ahh, that makes some sense, an easy assumption to make that a valid muxer is found. But some of these samples are too stupid
<compnnn> elenril, if -f null | then set mux threads = 0 ? or add -nomux option?
<compnnn> tooooo easy /s
<elenril> fixed, will send a patch in a sec
<elenril> names_are_hard: how do you want to be credited in the commit message?
<names_are_hard> As in what name? names_are_hard is fine
<compnnn> like "patch to fix slowdown, found by jimmy james"
<compnnn> if you want to be credited anyhow
<compnnn> some people like being credited w/ name so it adds to their internet point system rank. https://openhub.net/p/ffmpeg/contributors/19252191079585
<frankplow> names_are_hard: There is no AFL build in the Git, but you can adapt the decoder fuzzer in tools/target_dec_fuzzer.c to use AFL instead of libfuzzer with only a few line changes. I have a patch which quite cleanly allows building either libfuzzer or AFL builds, with the core code shared, but haven't gotten round to cleaning it up to send it to the ML yet.
<frankplow> names_are_hard: Something like this: https://files.frankplowman.com/ffmpeg-libfuzzer2afl.diff
Cheetahze has joined #ffmpeg-devel
lemourin has quit [Read error: Connection reset by peer]
lemourin has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
Cheetahze has quit [Quit: Connection closed for inactivity]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
mkver has quit [Ping timeout: 272 seconds]
mkver has joined #ffmpeg-devel
blb has quit [Ping timeout: 244 seconds]
blb has joined #ffmpeg-devel
Workl has joined #ffmpeg-devel
Krowl has quit [Ping timeout: 252 seconds]
Workl has quit [Ping timeout: 248 seconds]
Krowl has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
Krowl has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
<BBB> michaelni: " Moderators’ Authority: Moderators have the final say on rule enforcement. Non-compliance may result in warnings, moderated posts, or removal from the list." - but what about the CC? :)
Krowl has quit [Quit: Krowl]
Krowl has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
<kurosu> Quis custodiet ipsos custodes?
System_Error has joined #ffmpeg-devel
\\Mr_C\\ has joined #ffmpeg-devel
Workl has joined #ffmpeg-devel
Krowl has quit [Ping timeout: 252 seconds]
Krowl has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
Krowl has quit [Read error: Connection reset by peer]
Workl has quit [Ping timeout: 255 seconds]
rvalue- has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 260 seconds]
rvalue- is now known as rvalue
Everything has joined #ffmpeg-devel
<compnnn> why would anyone want to move to github
<compnnn> yeesh
<JEEB> it's *an* option. definitely not the first one for me, but it is workflow-wise still an improvement (plus the simplicity of CI flows). so if someone is listing alternatives, it being on the list would not be surprising.
<compnnn> fair enough
\\Mr_C\\ has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
Everything has quit [Ping timeout: 245 seconds]
Everything has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
\\Mr_C\\ has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
<names_are_hard> From an outsider perspective, your current dev workflow is a significant pain in the ass
<BtbN> It's not THAT bad, just super outdated and new generations never learned how to email
<names_are_hard> You use separate systems for bug reports (but only some classes of bugs!), code review, VCS, various tests, and comms. Integrating those would have benefits. Github is only one way to do that (there's a decent case to be made to use some self-hosted, open source solution, given the project)
<names_are_hard> Oh, if I thought it was THAT bad, I'd have used stronger language. It's annoying, and old fashioned, but not atrocious
<BtbN> There's plenty of projects that have all of that separated and use Github-Like stuff
<BtbN> So that doesn't seem like valid critique
<BtbN> Separating that kind of stuff also has advantages, like making migration of one of the tools much easier
<BtbN> instead of having to find a new solution for everything at once
<names_are_hard> I didn't deny that
<names_are_hard> I said integration has benefits, not that it's lacking in downsides, or that other systems don't also have benefits
<names_are_hard> Your community gets to debate the pros and cons and whatever approaches you want to consider
<BtbN> The main issue really is that a mailing list for patches is incredibly hard to properly keep track of. Both for a human reading the mails, and a tool like patchwork trying to offer CI
<names_are_hard> (but, the majority of the dev world agrees that having tickets integrated with code is pretty damn useful, and that tickets are far superior to email)
<BtbN> Not sure how much more you want to integrate an issue tracker with the code?
<names_are_hard> Yeah, ticket system allows you to assign someone. Stuff happens faster if someone is responsible. And contributors can ask on the ticket, not spam everyone on the list
<BtbN> On what website the issues are tracked seems largely irrelevant to me
<BtbN> You can assign someone on trac just fine
<names_are_hard> No, it's nice to have some integration
<BtbN> It's just that nobody cares
<names_are_hard> E.g. on GH if you put a short commit hash in the text of a ticket, it will auto expand it to a link to the commit
<BtbN> same thing happens on trac.
<names_are_hard> Okay, so you've integrated that part of those systems
<names_are_hard> I said "integrating those would have benefits" - not that they couldn't be "separate" systems; although of course all integration is by definition a reduction in separation
<BtbN> You can even have github-like verbs in commit messages, and trac will react to them
<BtbN> Just that nobody makes use of it
<names_are_hard> compnnn: pick a description that you like, and names_are_hard is best for this find, I use that name with Magic Lantern dev work, which is what the fix is (indirectly!) for
Workl has joined #ffmpeg-devel
<names_are_hard> elenril did the work, I just pointed at something that looked suspicious
Krowl has quit [Ping timeout: 265 seconds]
Krowl has joined #ffmpeg-devel
Workl has quit [Ping timeout: 244 seconds]
<ePirat> BtbN, the verb stuff does not seem to work fwiw
<ePirat> BtbN, see cd9ceaef22ecc25278c771169d179dbfdb24a355
<ePirat> ticket is still open
<BtbN> "Fixes"
<BtbN> Or "Closes"
<BtbN> https://trac.edgewall.org/wiki/CommitTicketUpdater#Usage has the list of what it can do
<ePirat> BtbN, can you add Fix #… to the regex?
<BtbN> I'm not sure if it's configurable
<ePirat> IIRC it is
<ePirat> if I remember correctly from my time administrating the xiph trac
elvis_a_presley has joined #ffmpeg-devel
<BtbN> I can also manually feed in all existing commits. Might be a good idea, maybe it closes some random stuff
<ePirat> probably, yeah
Krowl has quit [Read error: Connection reset by peer]
System_Error has joined #ffmpeg-devel
Everything has quit [Quit: leaving]
<compnnn> names_are_hard, we could use microsoft teams...
<compnnn> its an option...
Marth64 has joined #ffmpeg-devel
<names_are_hard> I've used Teams, the interface is awful and functionality is janky. Github works and the interface is nice
<names_are_hard> frankplow: thanks for the AFL example; I spent a little time on trying to do this but didn't find a good place to put the AFL_LOOP. Will test and see if it's an improvement
<Marth64> irc4life
gnafu has quit [Quit: "Rebooting for kernel update..."]
gnafu has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
<frankplow> names_are_hard: It needs a bit of fixing. The codec context is initialised for each test case while it should be possible to initialise it once, which really slows it down. I can't remember exactly why I had to do this to be honest, it's been a while since I've had a look at it.
<names_are_hard> Oh, that context is general enough that it doesn't matter if you swap the file content around?
Marth64 has quit [Quit: Leaving]
<frankplow> names_are_hard: Yes I believe so
Marth64 has joined #ffmpeg-devel
<frankplow> I'm really not the best person to ask though
<frankplow> I'm just making that assumption from the fact that the same FFCodec is used over multiple testcases in the libfuzzer implementation.
keith has quit [Ping timeout: 255 seconds]
keith has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
Krowl has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
iive has joined #ffmpeg-devel
<Lynne> that's about as fast as ffv1enc_vulkan is going to get
ccawley2011 has joined #ffmpeg-devel
Everything has joined #ffmpeg-devel
<fflogger> [editedticket] Balling: Ticket #6609 ([avformat] SamplingRateBox should be used if the value is greater than INT16_MAX) updated https://trac.ffmpeg.org/ticket/6609#comment:11
Everything has quit [Quit: leaving]
Everything has joined #ffmpeg-devel
<pross> it seems calling avio_rXXX/avio_read functions in avformat write_trailer function is bad idea
jamrial has joined #ffmpeg-devel
mkver has quit [Ping timeout: 265 seconds]
darkapex has quit [Remote host closed the connection]
darkapex has joined #ffmpeg-devel
av500 has quit [Quit: Konversation terminated!]
av500 has joined #ffmpeg-devel
ccawley2011 has quit [Read error: Connection reset by peer]