Live data from Hacker News

Dav2d

code.videolan.org

121–130 of 199 posts

Re: Dav2d

#121

Earlier quoted context omitted.

Cryptography and video codecs are notable exceptions, they put a lot of effort to making the code provably memory safe: no recursion, limited use of stack variables, no dynamic allocations, etc. As a result, memory safe languages bring nothing but trouble by making it non deterministic, that’s especially true for crypto where compiler “optimisations” guarantee you side channels attacks.

What in the world do you mean by “non-deterministic”? C compilers, Rust compilers, and assemblers are all deterministic.

> C compilers, Rust compilers, and assemblers are all deterministic.

Within a version, yes, but not cross version. Different versions of GCC/Clang etc can give you completely different code.

Re: Dav2d

#122
Mostly ASM for performance critical paths is a pattern that never gets old. The VideoLAN team did the same with dav1d and it paid off. Curious how much of dav2d ends up staying C as AV2 matures.

Re: Dav2d

#124

Earlier quoted context omitted.

It sounds like your second statement contradicts your first. But also, WUFFS exists and it looks like the Google Chrome GIF decoder ships in it: https://github.com/google/wuffs

It does not contradict it, and also, a gif is not a video.

> a gif is not a video.

They're not that different; the image codec WebP is derived from VP8's intra-frame coding.

Re: Dav2d

#125

Earlier quoted context omitted.

It’s not Rust, therefore it’s bad. Or something. This is getting rather tedious.

I don’t think it’s unfounded. Media codecs have been one of the top sources for serious vulnerabilities. The code is incredibly complex, and takes complex input from untrusted sources. Decoders are one of the best places for rust because they are both performance critical and security critical. JPEG-XL couldn’t get off the ground until they recreated the decoder in Rust since none of the browsers wanted to touch it.…

> JPEG-XL couldn’t get off the ground until they recreated the decoder in Rust since none of the browsers wanted to touch it.

This is extremely misleading. Before they even started work on the Rust-based decoder, experimental JPEG XL support was added to Chrome and Firefox using the reference C++ implementation. Chrome later removed this support for very dubious claims of lack of interest and improvement over previous generation of codecs.

Around that time, Safari shipped JPEG XL support in production, still without the Rust implementation. So the assertion no one wanted to touch it is plain false.

It was actually Mozilla who, a long time after stating they were ambivalent on JPEG XL, brought up memory safety as a major consideration, for the very first time. That’s when the work on the Rust implementation started.

Since the format continued to be more and more supported and talked about, it’s hard to say what exactly were the factors which made Google reconsider their stance. The notion that somehow everyone was super worried about memory safety from the very beginning, and once the JXL team fixed that, everyone was happy to embrace it, seems to come up a lot lately, but it’s terribly distorted and simply not true.

Re: Dav2d

#126
post #87
post #86

Earlier quoted context omitted.

We need a more efficient way to eliminate bullshit patents or bullshit patent infringement claims than "violate them then spend millions on lawyers to fight them in court".

Sure, and at the same time we need a more efficient way to ensure big companies can’t just take what they want and bury anyone who complains. It’s not an easy problem.

Stop big companies from ever forming. They are not a natural force that cannot be reckoned with. We allow them to exist. Revoke the charters of any business over 500 employees.

Re: Dav2d

#127

Earlier quoted context omitted.

Cryptography and video codecs are notable exceptions, they put a lot of effort to making the code provably memory safe: no recursion, limited use of stack variables, no dynamic allocations, etc. As a result, memory safe languages bring nothing but trouble by making it non deterministic, that’s especially true for crypto where compiler “optimisations” guarantee you side channels attacks.

What in the world do you mean by “non-deterministic”? C compilers, Rust compilers, and assemblers are all deterministic.

In cryptography, you want operations to run in constant time, even if it’s wasteful, otherwise an attacker could guess information about the key or plaintext by measuring execution times.

Modern compilers are extremely clever and will produce machine code that takes full advantage of modern CPU branch predictors, and reorder instructions to better take advantage of pipelining. This in itself will make the same code run at different speeds depending on the input data.

Then there is the whole issue of compiler version roulette. As a developer you have no idea which version of compilers your users and distros will use, and what new and wonderful optimisation they will bring.

Re: Dav2d

#128
post #74

Earlier quoted context omitted.

Maybe I’m naive about this, but I didn’t expect AI scrapers to be that big of a load? I mean, it’s not that they need to scrape the same at 1000+ QPS, and even then I wouldn’t expect them to download all media and images either? What am I missing that explains the gap between this and “constant DDoS” of the site?

I think there's a few things at play here - AI scrapers will pull a bunch of docs from many sites in parallel (so instead of a human request where someone picks a single Google result, it hits a bunch of sites) - AI will crawl the site looking for the correct answer which may hit a handful of pages - AI sends requests in quick succession (big bursts instead of small trickle over longer time) - Personal assistants may…

Also, relevant for forges: AI doesn't understand what it's clicking on. Git forges tend to e.g. have a lot of links like “download a tarball at this revision” which are super-expensive as far as resources go, and AI crawlers will click on those because they click on every link that looks shiny. (And there are a lot of revisions in a project like VLC!) Much, much more often than humans do.

Re: Dav2d

#129
post #87

Earlier quoted context omitted.

Sure, and at the same time we need a more efficient way to ensure big companies can’t just take what they want and bury anyone who complains. It’s not an easy problem.

Stop big companies from ever forming. They are not a natural force that cannot be reckoned with. We allow them to exist. Revoke the charters of any business over 500 employees.

I can see a number of ways to work around that limitation, without even lobbying and bribing. And I'm not even a lawyer or an accountant.

Eventually all the money and power will converge in a few sub 500, or sub 50, companies and nothing will change.

Re: Dav2d

#130

Earlier quoted context omitted.

What are you even implying?

It’s not Rust, therefore it’s bad. Or something. This is getting rather tedious.

you're falling for and/or playing along with astroturfing, that's what's tedious

can't people coping about rust come up with something fresh? always the same dance:

- fake annoyance about not being written in rust (bonus points if nonsensical, like here)

- if merely insinuated, fake question about what do they mean exactly

- fake surprise about omg why are people like this, the rust community is so bad, wah wah wah

yawn

oh yeah, let's not forget the other classic:

- the rust community is so dumb for thinking

- yeah ikr haha so stupid

every fucking rust thread is like this, and it's unreadable. by intention of course, obviously.

but it's ai / corporations / the government ruining the internet guys! totally...

Post reply on HN