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.0 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
<compn> or facebook/twitch etc
<compn> or swscale
<BtbN> Twitch does not encode the heavy stuff mostly
<BtbN> YouTube however... You'd think they'd want libvpx to be absolutely amazing. And yet it stinks.
<compn> a lot of cpu opts have been added since the codecs were written
<BtbN> libvpx still sucks. You need to do two-pass encoding for it to be any good at all
<BtbN> Commercial VP9 encoders run circles around it
<compn> ehe yes i remember libvpx sucking
<compn> and yeah i guess twitch is just doing h264 ingress mostly
<compn> i dunno i'm out of the loop
<BtbN> they only allow 6Mbps h264
<compn> ah
<BtbN> So 1080p for any serious footage is out of the question anyway
<compn> 6mbps should be enough for everyone
<BtbN> a lot of people still do it, but it looks like dogcrap
<BtbN> And then Twitch transcodes it to 720p, 480p, 360p and 144p (and audio only)
<BtbN> At pretty poor quality
lexano has quit [Ping timeout: 268 seconds]
thilo has quit [Ping timeout: 268 seconds]
thilo has joined #ffmpeg-devel
cone-610 has quit [Quit: transmission timeout]
SystemError has quit [Remote host closed the connection]
SystemError has joined #ffmpeg-devel
lemourin has quit [Quit: The Lounge - https://thelounge.chat]
lemourin has joined #ffmpeg-devel
Wenbin_Chen_ has joined #ffmpeg-devel
Wenbin_Chen__ has quit [Read error: Connection reset by peer]
arch1t3cht6 has joined #ffmpeg-devel
arch1t3cht has quit [Ping timeout: 256 seconds]
arch1t3cht6 is now known as arch1t3cht
Wenbin_Chen__ has joined #ffmpeg-devel
Wenbin_Chen_ has quit [Ping timeout: 252 seconds]
jamrial_ has quit []
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 256 seconds]
Wenbin_Chen_ has joined #ffmpeg-devel
Wenbin_Chen__ has quit [Remote host closed the connection]
Wenbin_Chen_ has quit [Read error: Connection reset by peer]
Wenbin_Chen__ has joined #ffmpeg-devel
SystemError has quit [Remote host closed the connection]
SystemError has joined #ffmpeg-devel
Traneptora has quit [Quit: Quit]
SystemError has quit [Remote host closed the connection]
SystemError has joined #ffmpeg-devel
AbleBacon_ has joined #ffmpeg-devel
AbleBacon has quit [Ping timeout: 264 seconds]
Wenbin_Chen_ has joined #ffmpeg-devel
Wenbin_Chen__ has quit [Read error: Connection reset by peer]
AbleBacon_ 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
Wenbin_Chen__ has quit [Read error: Connection reset by peer]
chainik1 has quit [Quit: (╯°□°)╯︵ ┻━┻]
chainik1 has joined #ffmpeg-devel
Wenbin_Chen__ has joined #ffmpeg-devel
Wenbin_Chen_ has quit [Remote host closed the connection]
Wenbin_Chen__ has quit [Read error: Connection reset by peer]
Wenbin_Chen__ has joined #ffmpeg-devel
Wenbin_Chen_ has joined #ffmpeg-devel
Wenbin_Chen__ has quit [Ping timeout: 268 seconds]
cone-215 has joined #ffmpeg-devel
<cone-215> ffmpeg Zhao Zhili master:65c1c83ca425: avformat/tls_mbedtls: Pass FLAG_NONBLOCK to underlying transport
Krowl has joined #ffmpeg-devel
zsoltiv_ has quit [Quit: Left]
zsoltiv_ has joined #ffmpeg-devel
Wenbin_Chen__ has joined #ffmpeg-devel
Wenbin_Chen_ has quit [Ping timeout: 256 seconds]
Raz- has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
<thardin> does vf_pixdesctest just copy the input to the output? and why might it fail if I add streamid as metadata to a stream?
<thardin> let's see what GEN=1 spits out
<thardin> oh it's probably due to using nut
Krowl has quit [Read error: Connection reset by peer]
<thardin> deleting "id" after successfully parsing and applying it fixes the issue
<thardin> perhaps it'd be a good idea to put these into some kind of namespace, and delete all of them. say ffmpeg:id instead of just id
<thardin> TAG:language=ger-at
<thardin> TAG:stereo_mode=left_right
<thardin> -TAG:DESCRIPTION-ger=Deutsch
<thardin> TAG:DESCRIPTION-fre=Francais
<thardin> +TAG:DESCRIPTION-ger=Deutsch
<thardin> TAG:DURATION=00:00:10.000000000
<thardin> are tags not sorted or something?
<JEEB> I think it's just an AVDictionary underneath?
<thardin> strange that the order changes. if I put the streamid thing before -metadata are applied then there is no change. but then you can't use -metadata to set streamid >_<
<thardin> afaict avdictionary isn't a hashmap. I think.
<thardin> ohhh I think I know. it's because deleting an entry just sets it to NULL
<thardin> so there's a free space in there, causing the order to change
<thardin> the namespace clearing idea could be implemented with a loop that deletes dictionary entries with key=ffmpeg: and AV_DICT_IGNORE_SUFFIX
<wbs> elenril: spurious errors (multithreading induced?) in the tscc-15bit test again: http://fate.ffmpeg.org/report.cgi?slot=aarch64-linux-clang-trunk&time=20240412030046
kurosu has joined #ffmpeg-devel
<thardin> I don't see how av_dict_set() is actually doing the right thing when deleting entries
Krowl has joined #ffmpeg-devel
<thardin> *tag = m->elems[--m->count]; for example this line only decrements m->count
<thardin> I'd expect at last a swap between the current element and the last element
<thardin> nm I'm dumb
<thardin> patch sent
cone-215 has quit [Quit: transmission timeout]
<haasn> mkver: re: splitting up dovi_rpu.c into decode and encode functions, should I split up the header file as well or do you think it's fine to just have dovi_rpu_enc.o and dovi_rpu_dec.o with codecs depending on the corresponding object files?
<haasn> (speaking of which, I forgot to add those dependencies to the encoders)
<mkver> haasn: Splitting up the header file does not seem warranted atm.
<haasn> hmm actually it seems we currently have CONFIG_DOVI_RPU as its own configuration option
<mkver> (It would be different if you were to add encoder or decoder specific stuff (like GetBitContext/PutBitContext) in there).)
<haasn> maybe it would make more sense to delete that option and instead have the relevant decoders directly depend on dovi_rpu_{enc,dec}.o unconditionally
<mkver> I don't care if you make it two subsystems or add Makefile dependencies directly.
<mkver> Just don't forget those dependencies this time.
rajivharlalka has quit [Quit: Ping timeout (120 seconds)]
<BtbN> https://patchwork.ffmpeg.org/project/ffmpeg/list/?submitter=776 why does Patchwork think he submitted every patch under the sun? huh?
<BtbN> He just sent his first patch (new Nvidia employee working with FFmpeg), and somehow patchworks likes him a lot.
<Daemon404> something something gitlab
* Daemon404 runs
<JEEB> slowly we should be going that way
<Lynne> we've been here before, someone just has to do the work
<Lynne> I'd prefer a forgejo instance we run with manual account creation, because I can't review patches waiting for gitlab to load 50 megabytes of js to render green and red diffs
<JEEB> ok, then if it's just about the work then we just add an FFmpeg org on videolan's gitlab (since I don't think we want to duplicate the hosting effort, and our git repos are already on videolan.org).
<Lynne> we need to have a vote first
<Daemon404> sasuga
<beastd> Dumb question: How is gitlab related to patchwork? Does it have mailing list patch tracking features? Or was the implication to move to a pull request workflow?
<JEEB> yea, to a MR flow
<JEEB> so that I don't need to look around for the latest patch set and the diff between patch sets
<Daemon404> even just finding anything on patchwork.is pain
<BtbN> I'd be happy to set up and maintain a Gitlab instance, as long as I'm not the one sitting on the cost.
<BtbN> Not a fan of any of the other alternatives, cause they come and go way too quickly. Gitlab at least is rather unlikely to just be gone or forked in a few years.
<JEEB> also jdek tested the cli tools for one of the alternatives
<BtbN> And it has well established CI tools
<Daemon404> gitlab is pretty welp accepted
<Lynne> it's accepted because its shit
<jdek> the gitlab cli was better than the gitea/forgejo one
<beastd> Without having compared the implementation deeper I think forgejo would be a bit lighter in complexity.
<jdek> By quite a bit
<Daemon404> perfect is the enemy of good
<Lynne> it's not good
<Lynne> it's shit
<Daemon404> picking some "i think its better but noone has ever heard of" thing is a poor choice
<jdek> + we can piggy back on videolan infra
<Daemon404> yeah and this is why well never move to anything
<Lynne> it's just the new name for gittea
<jdek> With an unproven track record
<Lynne> I'm not saying gitlab is unsuitable, just that it's dogshit
<BtbN> Didn't forgejo also fork git, and claims it's the best thing since sliced bread?
<Lynne> no?
<jdek> Its just a gitea fork
<BtbN> Ah, the git fork was called... fork
<jdek> Since gitea went commercial
<BtbN> So it's already happening before I predicted it, great
<BtbN> Yeah, my vote is on Gitlab or Github
<Gramner> i can add that an advantage of using the videolan gitlab is that CI runners can be shared with vlc/dav1d/x264 etc. for better resource utilization
<JEEB> ^
<jdek> gitlab significantly better, videolan already solved many problems we would have to solve
<jdek> We can pool our runners
<jdek> Etc
jamrial has joined #ffmpeg-devel
<BtbN> Yeah, Videolan Gitlab would be my favourite by an order of Magnitude. Then Github, then ffmpeg self hosted Gitlab.
<beastd> The beginning was gogs. At some point that diverted into gitea. and lately there was a split into forgejo.
<Daemon404> sounds stable
<jdek> Would also prefer github over ffmpeg-run gitlab
<Daemon404> "someone just needs to do the work" -> proceed to have every single person express their own specific preference that isnt gitlab
<Daemon404> the classic path
<beastd> andrewrk: IIRC you lately posted a codeberg link here. Sorry if i misremember! If not do you have experience to share in regards of working with forgejo?
<jdek> I mean videolan gitlab is ‘the work’
<beastd> The discussion is kind of running wild at this point. It's cool from time to time on IRC. We are discussing to many things at once :)
Traneptora has joined #ffmpeg-devel
<beastd> Just to clarify the points I wanted to make: 1) If we set it up from scratch I would consider forgejo. If we use the gitlab from videolan then it is probably only a matter of configuration. So that's fine as well. 2) before doing anythings related to point 1, it must be discussed and decided to move away from patches on the mailing list and the related workflow changes
<BBB> kierank: I'm trying to give more detailed lists for the tasks you put up
<BBB> kierank: feel free to make it prettier, I'm mostly trying to generate information :)
<BBB> style isn't really my thing for this sort of stuff
lexano has joined #ffmpeg-devel
<BtbN> We wouldn't instantly move away from the ML. It would coexist for an arbitrary amount of time.
<Daemon404> videolan still has a ml
<Daemon404> ml-based development does feel a bit like that boomer who prints off their emails to read in 2024.
<Sean_McG> ^
<Sean_McG> and hi everybody
<Lynne> it may be helsinki syndrome, but I've grown to somewhat understand mailing lists
<Lynne> nah, it's just github and gitlab and everyone else turning into social platforms
<Lynne> how many achevements do you have on github? have you tried gitlab's new AI chatbot?
<BtbN> I'd hope Videolan just turns that shit off
* psykose hands Lynne a gold medal
<Sean_McG> same, BtbN
<BBB> lol Daemon404
<thardin> oh yeah do we need the ml is we use gitlab?
<thardin> could just use gitlab and irc
<jamrial> the ml needs to stay for discussion purposes
<Lynne> ^^
<jamrial> lots of people that don't use IRC
<Lynne> we have user channels too, there's no other way to help users other than IRC
<Lynne> *other than ML and IRC
<Lynne> plus, there's ffmpeg-cvs for commit discussions
<Lynne> you can discuss commits on gitlab or github, but because they're not real discussions, you can't get notified and they're forgotten
<BBB> kierank: I think if we want to have a more understandable page, we should create matrices like what we have for dav1d: what functions exist, for what platform/instruction set (32bit, 64bit, etc.) are they optimizable and optimized
<BBB> that's a ton of work obviously...
<JEEB> yea, ML for discussions makes sense
<Lynne> and whether they have checkasm
<BBB> Lynne: yes, agreed
Krowl has quit [Read error: Connection reset by peer]
abhay has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
qeed has quit [Quit: qeed]
qeed has joined #ffmpeg-devel
SystemError has quit [Remote host closed the connection]
SystemError has joined #ffmpeg-devel
<JEEB> > Multi NVENC Split Frame Encoding in HEVC and AV1 > multiple horizontal strips
<JEEB> does this not sound like slices?
<kasper93> Oneric: The 57c5450 commit breaks zvbi conversion to ass. Specifically because it does strstr(..., "\r\n[Events]\r\n");
<kasper93> but also the problem remains for all other subtitle decoders that convert to ass, because they all still use \r\n, so the above commit introduce mixed line endings
<kasper93> Would you please fix it? At least the failure of zvbi, thanks
<kasper93> (maybe not all, but at least arib and dvb teletext ones, haven't change all of them)
abhay has quit [Quit: Leaving]
Krowl has quit [Read error: Connection reset by peer]
psykose has quit [Remote host closed the connection]
psykose has joined #ffmpeg-devel
<Lynne> jkqxz: ping on your av1 patches and the nvidia patch they sent
unlord has quit [Remote host closed the connection]
unlord has joined #ffmpeg-devel
<Lynne> they've admitted that the spec/ctx/drivers all have an issue and they'll all have to be fixed
<Lynne> but for now we should at least make ffmpeg av1 decode work on nvidia, until the changes trickle in
AbleBacon has joined #ffmpeg-devel
Gramner has quit [Ping timeout: 264 seconds]
Wenbin_Chen_ has joined #ffmpeg-devel
Wenbin_Chen__ has quit [Read error: Connection reset by peer]
Gramner has joined #ffmpeg-devel
Livio has joined #ffmpeg-devel
Livio has quit [Ping timeout: 240 seconds]
<jkqxz> Lynne: We should do "if (nvidia && driver_version <= most_recent_known_broken_version)" around it so that fixed versions don't break in the other direction later, but other than that I think yes.
<Lynne> yup, thankfully we can
<Lynne> nvidia should release a new beta driver next week, so this should only concern the release version
IndecisiveTurtle has joined #ffmpeg-devel
<Lynne> could you combine your patch with nvidia's patch and produce something which will be correct?
<Lynne> I'll write the driver checking code and the +1 offset for the saved order hints on top of it
<jkqxz> Yep, might be tomorrow.
<Lynne> thanks
Traneptora has quit [Quit: Quit]
<j-b> good morning
Traneptora has joined #ffmpeg-devel
<another|> is it?
<j-b> it is.
<j-b> haasn: <3 on you
<haasn> wha?
<j-b> haasn: are you not the one that posted "[TC] Technical decision on S302M non-PCM decoding"?
<haasn> I did
<j-b> therefore ^^
<Lynne> that was a good decision
<JEEB> also it helps that you get the word "unanimously" there
<JEEB> since there are people with different viewpoints in TC, but they agreed on the overall sentiment
ccawley2011 has quit [Ping timeout: 272 seconds]
ccawley2011 has joined #ffmpeg-devel
sudden has quit [Ping timeout: 240 seconds]
Livio has joined #ffmpeg-devel
Livio has quit [Ping timeout: 264 seconds]
sudden has joined #ffmpeg-devel
MisterMinister has quit [Ping timeout: 252 seconds]
MisterMinister has joined #ffmpeg-devel
kasper93 has quit [Ping timeout: 260 seconds]
IndecisiveTurtle has quit [Ping timeout: 256 seconds]
kasper93 has joined #ffmpeg-devel
microchip_ has quit [Quit: There is no spoon!]
microchip_ has joined #ffmpeg-devel
Wenbin_Chen__ has joined #ffmpeg-devel
Wenbin_Chen_ has quit [Remote host closed the connection]
unlord has quit [Changing host]
unlord has joined #ffmpeg-devel
Livio has joined #ffmpeg-devel
jess has quit []
<BtbN> That v2 patch from the Nvidia Guy confused me for a moment
<BtbN> It's a patch to the patch
<JEEB> fun
Raz- has quit [Ping timeout: 255 seconds]
<jamrial> BtbN: github/gitlab MR (pre squashing) style of development
<BtbN> Yeah, I'm actually surprised that's not a more common mistake
<BtbN> At least I have never seen it before
<andrewrk> beastd: I've been trying it for the first time. First impressions are that it works smoothly. It's clearly intended to be a GitHub clone so it will be comfortable and familiar to GitHub users (such as myself)
<andrewrk> for me the key feature is that it's operated by a non-profit so I don't have to worry about moving away from the platform in 5-10 years when the company decides to sell its soul
<andrewrk> I haven't tried the CI features yet
<andrewrk> with GitHub Actions I'm kind of at the limit of its usefulness (with zig) because I have more hardware and operating systems I want to add CI runners onto but they only support {aarch64,x86_64}x{Windows,macOS,Linux}
<JEEB> yea, although they finally enabled virtualization on linux apparnetly
<JEEB> until then macOS runners were the only thing capable of virtualization
<JEEB> which was quite hilarious
<andrewrk> ironic
<JEEB> (you needed to utilize the most expensive runners to get some random systems tested)
<andrewrk> the runners they offer are ridiculously expensive, compared to getting a 100 euro/month machine from hetzner and putting runners on it yourself
Krowl has joined #ffmpeg-devel
<BtbN> hmm? You get 20 parallel free runners from github
<BtbN> that's quite substantial power for absolutely free
<JEEB> for OSS, yea.
<andrewrk> yeah the free runners is substantial power. but for example if you pay for an aarch64-macos runner
<JEEB> yea, as soon as you go paid it starts making sense to self-host
<wbs> andrewrk: the github aarch64 macos runners are available for free these days
<wbs> (it became available a couple months ago)
<wbs> just set "runner: macos-14" and you'll get one of them
<andrewrk> oh neat
<JEEB> and here I thought he was talking about some corporate project outside of his OSS stuff :D
<wbs> a different case where one might want to pay for it, is if the 6 hours on relatively slow runners isn't enough
<wbs> although they were bumped from 2 cores to 4 cores at the end of last year
<andrewrk> I do OSS full time! :)
<BtbN> hmm? The m1 osx runner is free as well, isn't it?
<wbs> yes, but it's only been free for a couple of months iirc
<BtbN> The pricing for the large ones seems insane though
<BtbN> 16 cents per _minute_
<Oneric> > kasper93: because they all still use \r\n, so the above commit introduce mixed line
<Oneric> what does ths decoder do and can you add tests/samplefiles? line endings are already supposed to be normalised since 7bf1b9b35769b37684dd2f18a54f01d852a540c8
b50d has joined #ffmpeg-devel
HarshK23 has quit [Quit: Connection closed for inactivity]
Krowl has quit [Read error: Connection reset by peer]
b50d has quit [Remote host closed the connection]
ccawley2011 has quit [Read error: Connection reset by peer]
b50d has joined #ffmpeg-devel
Livio has quit [Ping timeout: 252 seconds]
b50d has quit [Remote host closed the connection]
b50d has joined #ffmpeg-devel
iive has joined #ffmpeg-devel
b50d has quit [Remote host closed the connection]
IndecisiveTurtle has joined #ffmpeg-devel
SystemError has quit [Remote host closed the connection]
SystemError has joined #ffmpeg-devel
Wenbin_Chen_ has joined #ffmpeg-devel
Wenbin_Chen__ has quit [Ping timeout: 264 seconds]
Wenbin_Chen__ has joined #ffmpeg-devel
Wenbin_Chen_ has quit [Ping timeout: 260 seconds]
iive has quit [Ping timeout: 256 seconds]
Livio has joined #ffmpeg-devel
iive has joined #ffmpeg-devel
IndecisiveTurtle has quit [Remote host closed the connection]
<beastd> andrewrk: Ah ok, so you tested forgejo for the first time. Thanks for sharing!
SystemError has quit [Remote host closed the connection]
SystemError has joined #ffmpeg-devel
<kasper93> Oneric: Like said before it does strstr(..., "\r\n[Events]\r\n") which no longer works after change to default style
<kasper93> I don't feel responsible for adding test for this decoder, I can send you a sample if you want
<Oneric> where are the mixed line endings you mentioned supposed to come from, where did you observe them? Because as mention, they are supposed to get normalised for longer already
<kasper93> It fails on strstr(..., "\r\n[Events]\r\n") that's all
<Oneric> so no mixed line endings afterall?
mkver has quit [Ping timeout: 240 seconds]
<kasper93> they are mixed internally, yes
<kasper93> obviously I don't get the output, because the decoder fails to init, so whether they are normalized or not later makes little difference
<Oneric> well, i could sent a patch to blindly change the strstr to use \n, but i have no knowledge or samples of/from that format so idk if this will actually resolve things
<kasper93> it is enough to finish what you started and "fix"/change line endings to \n consistently across the styles in the decoders
<Oneric> did you test this already?
<kasper93> you can use this file, it has some teletext https://github.com/zapping-vbi/zvbi/files/14250628/sub.zip
<kasper93> with txt_format set to 2
<kasper93> and yes, I changed it localy to unblock my work, but I didn't touch other files like arib ones
NotWarcop has joined #ffmpeg-devel