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
<cone-914> ffmpeg Andreas Rheinhardt master:1093b402183c: avcodec/libvpxenc: Only search for side data when intending to use it
<cone-914> ffmpeg Andreas Rheinhardt master:8d1093a78413: avcodec/libvpxenc: Remove obsolete av_unused
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
<Lynne> IndecisiveTurtle: lower what?
<IndecisiveTurtle> In the compute shader change local_size_x = local_size_y = 8 and in main.c / 32 -> / 8
<Lynne> that works
<IndecisiveTurtle> Yay
rvalue has quit [Ping timeout: 268 seconds]
<JEEB> so these are all the tests now failing with f40 and its usage of zlib-ng :D http://up-cat.net/p/3e47c26c
Sean_McG has joined #ffmpeg-devel
lexano has quit [Ping timeout: 264 seconds]
rvalue has joined #ffmpeg-devel
<IndecisiveTurtle> Lynne: Any more suggestions to implement before considering this qualification task complete? The deadline for proposals is starting to close in, so wanna make sure I have time to prepare it, when you give your approval.
<Lynne> could you hack up a simple deinterleave function? would help with debugging
<Lynne> the task is complete, I think, but it's up to you
MisterMinister has quit [Ping timeout: 268 seconds]
<IndecisiveTurtle> Yeah shouldn't be hard to make a simple second for it, though I will have it write to a different image, otherwise its a lot harder
MisterMinister has joined #ffmpeg-devel
<IndecisiveTurtle> I wonder if we can alias the same descriptor as storage and sampled to get clamp to edge behaviour for free while sampling
<IndecisiveTurtle> I've seen aliasing of UBOs in shaders before but not textures
<Lynne> not sure what you mean
<IndecisiveTurtle> Basically do layout(location = 0) uniform image2D tex0; layout(location = 0) uniform sampler2D tex1;
<IndecisiveTurtle> Same texture but read through a sampler and written as a storage image
<Lynne> in the encoder, you'll be saving them to a storage buffer, not the same image
<Lynne> images given to encoders are immutable
<IndecisiveTurtle> Ah that's irrelevant then, we can just use a sampler
zsoltiv_ has joined #ffmpeg-devel
<Lynne> IndecisiveTurtle: btw, it's possible that there may be another student who qualified for the same task as well, and since it wouldn't make sense to have two students working on the same project, one of you may want to do either a vc-2 decoder or an ffv1 encoder instead
<Lynne> do you have any preference on what you'd like to work on? they're mostly all similar in scope
<Lynne> (jpeg2000-ht and prores are also an option)
System_Error has quit [Remote host closed the connection]
<Lynne> if both of you would like to work on vc-2 it's still not a problem, the encoder still needs a good analysis and rate control systems
System_Error has joined #ffmpeg-devel
thilo has quit [Ping timeout: 268 seconds]
thilo has joined #ffmpeg-devel
lemourin has quit [Quit: The Lounge - https://thelounge.chat]
cone-914 has quit [Quit: transmission timeout]
lemourin has joined #ffmpeg-devel
jamrial has quit []
kurosu has joined #ffmpeg-devel
mkver has quit [Ping timeout: 256 seconds]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
Pheo has quit [Quit: Lost terminal]
IndecisiveTurtle has quit [Remote host closed the connection]
kierank has quit [Ping timeout: 256 seconds]
kierank has joined #ffmpeg-devel
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 256 seconds]
MisterMinister has quit [Ping timeout: 264 seconds]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
AbleBacon has quit [Read error: Connection reset by peer]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
HarshK23 has quit [Quit: Connection closed for inactivity]
cone-180 has joined #ffmpeg-devel
<cone-180> ffmpeg Anton Khirnov master:af81788f303a: fftools/ffmpeg_sched: move sch_stop() to the bottom of the file
<cone-180> ffmpeg Anton Khirnov master:24b9f29ff2e0: fftools/ffmpeg_sched: make sure to always run task cleanup
<cone-180> ffmpeg Anton Khirnov release/7.0:da903c558bb1: fftools/ffmpeg_sched: move sch_stop() to the bottom of the file
<cone-180> ffmpeg Anton Khirnov release/7.0:536443919f59: fftools/ffmpeg_sched: make sure to always run task cleanup
Krowl has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
Raz- has joined #ffmpeg-devel
<cone-180> ffmpeg Anton Khirnov master:1d843ae6c7b0: lavc: rename avpacket.c to packet.c
<cone-180> ffmpeg Anton Khirnov master:c240ff98b3db: lavc/packet: schedule AV_PKT_DATA_QUALITY_FACTOR for removal
ngaullier has joined #ffmpeg-devel
<cone-180> ffmpeg Anton Khirnov master:f121d954ac89: lavf/vf_setpts: unset output framerate
<cone-180> ffmpeg Anton Khirnov master:fa110c32b516: lavfi/setpts: unset frame durations
Krowl has quit [Ping timeout: 264 seconds]
Krowl has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
Krowl has joined #ffmpeg-devel
IndecisiveTurtle has joined #ffmpeg-devel
<IndecisiveTurtle> Lynne: Don't have any particular preference
<IndecisiveTurtle> Would be nice if it had similarity with the transforms this task has, but since we have 3 months time, it's plenty to research and understand any particular codec
<IndecisiveTurtle> jpeg2000-ht also looks interesting, when I was researching wavelet transforms it came up
HarshK23 has joined #ffmpeg-devel
<Lynne> IndecisiveTurtle: jpeg2000-ht is more related... but ffv1 is a lot more important (and harder), I would say
<Lynne> but, fortune and glory
j45 has quit [Quit: ZNC 1.8.2 - https://znc.in]
j45 has joined #ffmpeg-devel
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
MajorBiscuit has joined #ffmpeg-devel
andream has joined #ffmpeg-devel
<andream> hi, could someone take a look at my patch 7c123da1-cb8c-4b35-96c2-7569cacd75e6@polimi.it?
novaphoenix has quit [Quit: i quit]
novaphoenix has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
andream has quit [Quit: leaving]
andream has joined #ffmpeg-devel
MajorBiscuit has quit [Ping timeout: 256 seconds]
cone-180 has quit [Quit: transmission timeout]
MajorBiscuit has joined #ffmpeg-devel
andream_ has joined #ffmpeg-devel
andream has quit [Read error: Connection reset by peer]
<Lynne> IndecisiveTurtle: mmm, nevermind about ffv1, will be way too hard for a gsoc project
jamrial has joined #ffmpeg-devel
<Lynne> decoding-wise, I can more easily see how you'd parallelize it, but encoding-wise, all I can figure out from a superficial look is "it's definitely possible, but messy"
Krowl has joined #ffmpeg-devel
MajorBiscuit has quit [Ping timeout: 255 seconds]
Krowl has quit [Read error: Connection reset by peer]
MajorBiscuit has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
* Sean_McG peeks in
Krowl has joined #ffmpeg-devel
MajorBiscuit has quit [Ping timeout: 255 seconds]
<mkver> Sean_McG: There are some patches for UB/PPC on the ML for you.
Marth64 has joined #ffmpeg-devel
Workl has joined #ffmpeg-devel
System_Error has quit [Ping timeout: 260 seconds]
MajorBiscuit has joined #ffmpeg-devel
Krowl has quit [Ping timeout: 255 seconds]
System_Error has joined #ffmpeg-devel
System_Error has quit [Ping timeout: 260 seconds]
<jamrial> mkver: do you know why bf011695fd3 was even added for?
<jamrial> it's 4k of seemingly unused data, that is also compared between parsed structs
<mkver> I know that at least the videotoolbox hwaccel needs the raw data.
<jamrial> oh, i see it now
<mkver> See ff_videotoolbox_hvcc_extradata_create
<jamrial> no point in comparing it though, right?
System_Error has joined #ffmpeg-devel
<mkver> We could actually compare it before allocating anything and return directly if both new and old VPS fit into the data buffer and are equal.
MajorBiscuit has quit [Ping timeout: 260 seconds]
<mkver> jamrial: It has been added for mediacodec: https://ffmpeg.org/pipermail/ffmpeg-devel/2016-September/199059.html
<mkver> (These two caused some complications during the migration to RefStruct, because stuff like "(const HEVCVPS*)ps.vps_list[i]->data" compiles for both, but is only valid for one.
<jamrial> i don't know if comparing bitstream data is ok. you could have certain fields coded in different ways but still decoding to the same value
<jamrial> i don't know with hevc, but on av1 you have leb128 which lets you code any value with a arbitrary amount of bytes up to 8
<Sean_McG> mkver: re: your other UB patches, thanks and I will have a look later today or possibly tomorrow.
<jamrial> 0x01 is a 1, and so is 0x80808081
rajivharlalka has quit [Ping timeout: 256 seconds]
<mkver> jamrial: H26x does not use such stuff. E.g. exponential golomb encoding is unique.
<mkver> But it is possible for two different parameter sets to decode to the same HEVCPS struct if the data field is ignored (for the simple reason that we ignore certain stuff).
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
<ePirat> Maybe stupid question, but how do I pass options to a demuxer in ffmpeg CLI?
<Marth64> ePirat: -f my_demuxer -opt1 1 -opt2 2 -i .....
<JEEB> before `-i INPUT` options apply to the input things, such as demuxers or decoders
<ePirat> Oh well… something is broken then it seems
<ePirat> Error opening output files: Invalid argument
<Marth64> full cmd?
<ePirat> ./ffmpeg -ss 6.3 -f webm -bandwidth 12 -live -i pipe:0 -y -f null -
<Marth64> -live needs value
<Marth64> try -live 1
<ePirat> Ah, thanks…
<Marth64> ;D
<ePirat> I keep forgetting that bool opts are weird ffmpeg
<ePirat> uh well now it just hangs… fun
<Marth64> it still gets me sometimes
<Marth64> is your pipe not getting data?
<ePirat> should it not anyway honor ctrl-c? or is it expected that it just keeps waiting uninterruptible?
<ePirat> also even with the proper input now I just get: Option bandwidth not found.
<ePirat> and my debug logs for the options values that I added in the demux still show 0 for the live option…
<Marth64> hmm..... does it hang after "Option bandwidth not found."? i wonder if this is ticket #10916 again
<Marth64> (which was recently fixed)
<ePirat> Marth64, no longer hangs now when I actually give it data, I had messed up the pipe before
<ePirat> I can look into the no-data hang case a bit more later, but right now my main issue is that matroskadec is not seeing any options I set…
<ePirat> huh even changing the default value does not affect the structs value… so it seems something is very wrong
<Marth64> If you run with loglevel trace, at the start of the execution it should print exactly how it parsed each option and what it did with it
<Marth64> (debug might do it too)
<ePirat> oh only "WebM DASH Manifest demuxer" has the options assigned…
MajorBiscuit has joined #ffmpeg-devel
Workl has quit [Read error: Connection reset by peer]
cone-851 has joined #ffmpeg-devel
<cone-851> ffmpeg Tong Wu master:6bf17136a2bc: avcodec/hevc_ps: fix the problem of memcmp losing effectiveness
<jamrial> jkqxz: just sent a patch to stop memcmp-ing the structs
Krowl has joined #ffmpeg-devel
MajorBiscuit has quit [Quit: WeeChat 4.2.1]
Marth64 has quit [Ping timeout: 268 seconds]
Marth64 has joined #ffmpeg-devel
___nick___ has joined #ffmpeg-devel
IndecisiveTurtle has quit [Remote host closed the connection]
ramiro has quit [Ping timeout: 260 seconds]
Warcop has joined #ffmpeg-devel
ramiro has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 268 seconds]
Krowl has quit [Read error: Connection reset by peer]
MikhailAMD has quit [Quit: Leaving]
rvalue has quit [Ping timeout: 252 seconds]
IndecisiveTurtle has joined #ffmpeg-devel
<IndecisiveTurtle> Lynne: Noted, I'm open to anything really the goal of this was to get a taste of how the compression magic works xD You will be the one to decide how the projects are partitioned, though I would like some help on how to structure/fill the proposal of the final project if we can go ahead with it
MikhailAMD has joined #ffmpeg-devel
MikhailAMD has quit [Client Quit]
ngaullier has quit [Ping timeout: 260 seconds]
rajivharlalka has joined #ffmpeg-devel
rvalue has joined #ffmpeg-devel
<thardin> liblzma 5.6.0 och 5.6.1 are backdoored
<JEEB> yea
<thardin> like all CVEs it boils down to parsing
<JEEB> although unfortunately it seems like that one of the maintainers was doing it intentionally
<JEEB> so this is not just "parsing boogs be bad"
___nick___ has quit [Ping timeout: 252 seconds]
___nick___ has joined #ffmpeg-devel
<thardin> yes and no. part of the problem is that sh is very flexible
<cone-851> ffmpeg Tong Wu release/7.0:7fa569e34d44: avcodec/hevc_ps: fix the problem of memcmp losing effectiveness
<jamrial> elenril: don't forget to backport the setpts commits to 7.0
<mkver> Sean_McG: avid meridian does not fail with cpuflags=0 on ppc64be for me.
rajivharlalka has quit [Ping timeout: 268 seconds]
<mkver> Only fails when the altivec specific idct is used.
<kierank> thardin: it's as if we shouldn't have random people in bulgaria hosting ffmpeg.org
<thardin> I have heard of the bulgarian question before
<thardin> but I don't have full understanding of the issue
___nick___ has quit [Ping timeout: 260 seconds]
___nick___ has joined #ffmpeg-devel
<cone-851> ffmpeg James Almer master:547c9201933f: avcodec/hevc_ps: don't use a fixed sized buffer for parameter set raw data
<BBB> that's a fun backdoor
<JEEB> ye, utilizing the fact that you're included through libsystemd
<BBB> also the fact that it uses a unit test binary file as generator for the backdoor executable
<BBB> I mean, that's ... special
<JEEB> of course it's simpler when that test file isn't actually utilized by the tests :)
<BBB> imagine we did that by cutting and pasting some mp3 and ogg together to start crypto mining
<BBB> right that was a bit imperfect
<BBB> so close
Livio has joined #ffmpeg-devel
<JEEB> added all the JVET doc references since ITU has this pre-publishing phase where you need to pay for it :P
IndecisiveTurtle has quit [Ping timeout: 268 seconds]
<JEEB> haasn: ^ this should add the DoVi Profile 5 identifier for matrix coefficients. other patches in the set add it to places where ICtCp was added as well.
sfan5 has quit [Quit: Quit]
sfan5 has joined #ffmpeg-devel
Marth64 has joined #ffmpeg-devel
Livio has quit [Ping timeout: 272 seconds]
Livio has joined #ffmpeg-devel
<Marth64> thardin: hi, just realized you were here too. happy to help validate/test your SRT patch if needed, will have some downtime this weekend. cheers
<BtbN> lol, I dodged the xz thing by using a dead mirror that died before stuff got commited
<thardin> Marth64: great
<thardin> BtbN: running debian stable also works
___nick___ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
___nick___ has joined #ffmpeg-devel
___nick___ has quit [Client Quit]
Marth64 has quit [Ping timeout: 260 seconds]
Marth64 has joined #ffmpeg-devel
<kierank> should we make a tweet about liblzma
___nick___ has joined #ffmpeg-devel
<Daemon404> nah
<kierank> ok
<kierank> do the daily builds have this
<JEEB> BtbN: also it was not in the git repo apparently, only in the tarballs
<Daemon404> we dont do builds, and certaly not for linux
<Daemon404> windows is unnaffected
<kierank> ok
<JEEB> also the backdoor was xz -> libsystemd -> sshd
<kierank> do we say something is un affected
<BBB> so does that mean it's in the system of the person making the tarballs?
<Daemon404> the server itself
<BBB> although the test data in the repo was infected, right? even if the m4 was from the build system
<Daemon404> hosting them
<BBB> hm, right
<Daemon404> lennart on hn trying to downply
<Daemon404> (by being an ass)
<Daemon404> lol
<BBB> should've checked hn earlier this is fun
<JEEB> BBB: yea, the unused payload was in the repo. then the author added the m4 stuff to tarballs knowing that distros would utilize them
<BBB> do we know what the code does by now?
<Daemon404> no
<BBB> lol
<Daemon404> but it replaces some RSA funcs
<Daemon404> so uh
<Daemon404> cant be good
<Marth64> oh no. new cve?
<thardin> so which three letter agency is behind this? place your bets!
<Daemon404> prob china
<Daemon404> based on: nothing
<thardin> agatha christie twist: it's all of them
psykose has quit [Remote host closed the connection]
<BtbN> JEEB: partially
<Daemon404> Marth64, well prob more than CVE
<Marth64> just saw it. guess its patching time
<Lynne> what a thing to wake up to
<BtbN> unless you are on the bleeding edge, there is nothing to do
<BBB> hm... it does show how dangerous unmaintained core infrastructure can be
<BBB> another argument against micro-libxyz projects
<JEEB> BBB: this was (apparently) the maintainer doing it :D
<BBB> better it all be in ffmpeg or other umbrella projects
<Daemon404> not the maintainer, a contributor
<BBB> new contributor, not maintainer
<JEEB> uhh, apparently he was added to maintainers in 2022
<Daemon404> LOL homebrew
<BBB> added to maintainers is not "the maintainer"
<Daemon404> yea
<BBB> I'm in ffmpeg's maintainers
<JEEB> well when you have two :)
<BBB> I'm not the final person responsible
<Daemon404> it is possible he wasnt originally a plant
<BBB> the bdfl is ... uh ... I don't actually know
<BBB> I guess it's elenril now?
<Daemon404> could be e.g. "oh look we have your family"
<Daemon404> etc
<JEEB> yea
<JEEB> there's a lot of possibilities
<Daemon404> supposedly reported too CISO
<Daemon404> CISA*
<Daemon404> not much good if it was the US anyway =p
AbleBacon has joined #ffmpeg-devel
<Marth64> i never trusted brew to begin with. i think it's one of my biggest frustrations with macOS. there should have been a real package manager, or even ports from the bsd heritage
<BtbN> What got this have to do with brew anyway?
<Marth64> but brew/homebrew feels weird to me everytime i use it. no offense
<Marth64> the twitter link above
<BtbN> You can't expect packagers to spot something like that
<Daemon404> brew suffers from gentoo bleeding edge sydnrome
<Daemon404> is what.
<Marth64> i don't. it was an unrelated rant
<Marth64> lol
<BtbN> Gentoo was only affected if you opted into unstable packages
<Daemon404> ok so it's even more bleedy
<BtbN> No idea what's with the hate for Gentoo. At least it doesn't patch FS destroying stuff into filesystems, and then go "tough luck, we ain't fixing it, yell at upstream for something we did"
<elenril> BBB: only according to paul, and without the b
<BBB> sure, that's what they all say :)
<BBB> <3
<BBB> I think you're a good bdfl candidate. jamrial too but I fear he wouldn't want it
<elenril> i don't want to be a d though
<Daemon404> my note is nicolas
<Daemon404> he hs vision
<elenril> >openssh does not directly use liblzma. However debian and several other distributions patch openssh to support systemd notification, and libsystemd does depend on lzma.
<elenril> i love this part best
<JEEB> elenril: yea, it's xz->libsystemd->sshd
<JEEB> someone actually thought of that chain
<JEEB> checking that argv[0] is sshd
<Marth64> wow
Marth64 has quit [Ping timeout: 272 seconds]
Marth64 has joined #ffmpeg-devel
<jamrial> Daemon404: your china guess may be right, seeing this guy has written patches for loongson
<Daemon404> well, if you were china, would you have your agent use a chinese nme
<Daemon404> namee*
<Daemon404> bah spelling
<Daemon404> though the "we have your family" sorta case could still be it
<BtbN> It's only Debian and RHEL derivates that patch ssh that way it seems
<BtbN> So you're not affected anywhere else, even if you pull the malicious xz
<BtbN> Though I'd still clean up any system that had the malicious code ran on them
<BtbN> who knows what else it does
<Marth64> >There are other checks I have not fully traced.
<Daemon404> safe to say the whole world is currently doing that
<elenril> heh, libelogind does not link to liblzma
<Daemon404> so many easters will be missed.
<elenril> systemd haters win yet again
<Daemon404> "sorry grandma, have to RE this sploit"'
<BtbN> This is not out in prouction in any realistic production setup though
<Daemon404> doesnt matter, people will race to RE it
<Daemon404> for clout
<BtbN> Only Debian testing and Fedora Rawhide are affected. And Arch I guess?
<Daemon404> arch users arent people who no damage
<Lynne> your typing is on point today
<Daemon404> as opposed to every other day where it is just as bad
<another|> Arch doesn't patch
<BtbN> so?
<BtbN> There is no patch needed, just use of a release tarball
<jamrial> arch uses a git tag
<BtbN> It does now
<jamrial> not tarball
<BtbN> I believe they switched to that in response to the incident
Marth64 has quit [Ping timeout: 268 seconds]
<jamrial> mmh, you're right
Marth64 has joined #ffmpeg-devel
<Daemon404> imagine if it was gmp compromised instead of xz, theyd complan their git server is being ddos'd
<jamrial> lol
<another|> BtbN: AFAIUI debian, rhel patch openssh-portable to support some systemd thing
<another|> which pulls in liblzma
<BtbN> That's irrelevant
<another|> no?
<BtbN> I consider every system with xz-utils 5.6.* installed compromised
<BtbN> no matter if sshd was patched or not
<another|> ogge...
<BtbN> Or did you fully reverse engineer the exploit, and can confidently confirm that that's the literal only thing it does?
<another|> fair
<Marth64> install plan 9. permanent solution
<another|> by pure happenstance I updated my system this morning
<BtbN> What amazes me is that the exploit code is STILL in their git
<BtbN> They did not remove it yet
<Marth64> i saw that too. the debian one is still there too
<Marth64> on the build-to-host script for the tarball
<llyyr> They discouraged packagers from using the github generated source tarball, and use the "signed tarball" instead which contains the exploit all the way back in december
<llyyr> this probably isn't the only thing it does
<another|> BtbN: hey, the lastest commit simplifies security! https://github.com/tukaani-project/xz/commit/af071ef7702debef4f1d324616a0137a5001c14c
<another|> /s
<Marth64> icing on the cake
<BtbN> Well, with them pulling from git, it'd be a non-issue
<Marth64> yes but to be a point of contact...they could socially engineer lies
<another|> primary contact + kernel maintainer contact
<Marth64> or intercept/manipulate concerns just by being aware of them as the primary poc
<jamrial> moral of the story, don't use custom tarballs. only git tags or automated tarballs
<BtbN> Issue with automated tarballs is lack of submodules
<elenril> moral of the story: critical infrastructure shouldn't depend on libraries maintained by a single person nobody knows
<BtbN> This was not "a single person"
<BtbN> It's a whole team, which happened to recruit a malicious maintainer
<JEEB> to my understanding the team was two people, and the initial maintainer more or less moved to being less active?
<Marth64> sad
<BtbN> The codebase of xz will need an audit all together
<BtbN> who knows if that's the ONLY exploit that was added
<BtbN> also, with the original maintainer out of the picture... is the project just dead now?
<wbs> I wouldn't say the original maintainer is entirely out of the picture, he probably just have handed over more maintainance to this contributor
<wbs> I interacted with Lasse around an xz issue within the last year
<wbs> (the original maintainer)
<JEEB> ye
Livio has quit [Ping timeout: 255 seconds]
IndecisiveTurtle has joined #ffmpeg-devel
___nick___ has quit [Ping timeout: 268 seconds]
Livio has joined #ffmpeg-devel
<Marth64> i should get pgp key
<Marth64> thinking of new laptop and it comes with smartcard reader. i don't want it but if it's included might be fun to play with
<elenril> i can mail you one
<elenril> guaranteed random
<elenril> (slightly used)
<JEEB> :D
<JEEB> just slightly
<Marth64> ;D pls send to 123 Noob Dr
<JEEB> only visual damage
<Marth64> like the beaten used car ads. "ICE COLD A/C. EVERYTHING RUNS PERFECT"
<Marth64> (everything is broken and all fluids leaking)
<Marth64> just last year i was surveying compression choice for a project and xz was an option
<Marth64> i narrowly said no
<Marth64> anyways done rambling about this
<jamrial> all the cool kids use zst nowadays
<Marth64> i like zstd
<Marth64> the fast decompression is awesome. for that project settled with gzip cause it was good enough and timeless
<Lynne> brotli is unfortunately more efficient on text than zstd, since that's what it was made for
<Lynne> not enough to be significant, but it is more widely supported on the web than zstd
<Marth64> my fear with both is ultra long-term survivability (for the use case of backups). there's the chance in 10 years they will be research projects swept away by time. probably on a rotting sourceforge page with ads.
<Marth64> doesn't look like they are heading that way though which is good
<Marth64> and iirc kernel comes zstd compressed now too
<Marth64> or initramfs does, something
<BtbN> If you configure it to be so
sr55 has joined #ffmpeg-devel
s55 has quit [Ping timeout: 256 seconds]
s55 has joined #ffmpeg-devel
ngaullier has joined #ffmpeg-devel
Raz- has quit [Ping timeout: 264 seconds]
sr55 has quit [Ping timeout: 268 seconds]
cone-851 has quit [Quit: transmission timeout]
ngaullier has quit [Ping timeout: 240 seconds]
andream_ has quit [Quit: Lost terminal]
Livio has quit [Ping timeout: 264 seconds]
Marth64 has quit [Remote host closed the connection]
cone-465 has joined #ffmpeg-devel
<cone-465> ffmpeg Timo Rothenpieler master:e99c273feca1: avcodec/nvdec: reset bitstream_len/nb_slices when resetting bitstream pointer
<cone-465> ffmpeg Timo Rothenpieler release/7.0:515949a15a94: avcodec/nvdec: reset bitstream_len/nb_slices when resetting bitstream pointer
<cone-465> ffmpeg Timo Rothenpieler release/6.1:f4a6db1222ea: avcodec/nvdec: reset bitstream_len/nb_slices when resetting bitstream pointer
<cone-465> ffmpeg Timo Rothenpieler release/6.0:a39e922fb770: avcodec/nvdec: reset bitstream_len/nb_slices when resetting bitstream pointer
<cone-465> ffmpeg Timo Rothenpieler release/5.1:82abc7af817e: avcodec/nvdec: reset bitstream_len/nb_slices when resetting bitstream pointer
<cone-465> ffmpeg Timo Rothenpieler release/5.0:201d0e6fc17a: avcodec/nvdec: reset bitstream_len/nb_slices when resetting bitstream pointer
<cone-465> ffmpeg Timo Rothenpieler release/4.4:5d07afd48253: avcodec/nvdec: reset bitstream_len/nb_slices when resetting bitstream pointer
<cone-465> ffmpeg Timo Rothenpieler release/4.3:fa9a0e7f3e83: avcodec/nvdec: reset bitstream_len/nb_slices when resetting bitstream pointer
<cone-465> ffmpeg Timo Rothenpieler release/4.2:197f7eacf674: avcodec/nvdec: reset bitstream_len/nb_slices when resetting bitstream pointer
<Lynne> if this was left undiscovered for a year (next debian stable), it would have been worse than heartbleed
<Lynne> or even a month (ubuntu 24.04)
<cone-465> ffmpeg Timo Rothenpieler release/4.1:835453fbd8a9: avcodec/nvdec: reset bitstream_len/nb_slices when resetting bitstream pointer
kurosu has quit [Quit: Connection closed for inactivity]
<cone-465> ffmpeg Timo Rothenpieler release/4.0:d1275f8a77fa: avcodec/nvdec: reset bitstream_len/nb_slices when resetting bitstream pointer
AbleBacon has quit [Read error: Connection reset by peer]