Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rav1e: An experimental AV1 video encoder, designed to be fast and safe

github.com

Post reply on HN
Print view View original

21–30 of 76 posts

Re: Rav1e: An experimental AV1 video encoder, designed to be fast and safe

#21

Post by pjmlp »

arez wrote: post #6
jabl wrote: post #4

Earlier quoted context omitted.

Presumably that it's implemented in Rust, and thus does not suffer from many of the usual bugs that C code bases suffer from? There seems to be some asm code as well, which obviously does not enjoy the safety advantages of Rust.

I always wondered if in practice it really checks out, is rust code really safer? Did the bugs just shift to different ones? Is there anyone who wrote about that already?

Yes, but not only Rust, rather any memory safe system programming language all the way back to ESPOL in 1961.

In those languages you have "Logic errors" to debug, in C and its direct descendants you have "Logic errors" + "UB errors" + "Memory corruption errors" to debug.

Also having the use of unsafe explicit in the type system, means that it is relatively easy to track down where such issues might occur, whereas in C every line of code can be a source of problems, depending on which compiler and flags are being used.

Again, this applies to all memory safe system programming language, not just Rust.

EDIT: Fixed the NEWP reference, as ESPOL came first and NEWP only replaced it in 1976.

Re: Rav1e: An experimental AV1 video encoder, designed to be fast and safe

#22

Post by derf_ »

masklinn wrote: post #9
zakk wrote: post #5

> ~5 fps encoding @ 480p How does this compare with the reference encoder?

You'd need to run them on the same machine to make sure you get a proper comparison but https://ffmpeg.zeranoe.com/forum/viewtopic.php?t=5601 has some runs. One of the users downthread ("entac") provides both libaom and libx264 numbers, they get 63fps for libx264 and 0.0924fps for libaom (r9028) Also this currently does delegates work to libaom.

> Also this currently does delegates work to libaom.

Currently just for the transforms and to initialize the probabilities for the entropy coder.

Re: Rav1e: An experimental AV1 video encoder, designed to be fast and safe

#23

Post by derf_ »

arez wrote: post #6
jabl wrote: post #4

Earlier quoted context omitted.

Presumably that it's implemented in Rust, and thus does not suffer from many of the usual bugs that C code bases suffer from? There seems to be some asm code as well, which obviously does not enjoy the safety advantages of Rust.

I always wondered if in practice it really checks out, is rust code really safer? Did the bugs just shift to different ones? Is there anyone who wrote about that already?

The "safest" comment is mostly tongue-in-cheek, but the advantages are real. I enjoyed this comment from someone contributing to the project for the first time:

atomnuker: I felt good when my patch was done and I had exactly what I set out to write.

I didn't enjoy the compiler forcing me to fix all my bugs upfront.

There are also advantages other than safety to using a modern systems language that has learned something from the last 30 years of programming language design but doesn't come with all of the baggage of C++.

Re: Rav1e: An experimental AV1 video encoder, designed to be fast and safe

#25

Post by masklinn »

sp332 wrote: post #19
skolemtotem wrote: post #8

Will AV1, or even VP9 for that matter, ever be suitable for realtime encoding, or is that just not their target market?

Yes, it's just that everyone is focusing on size/bandwidth optimization for now. Once they nail down the actual format, projects will start work on making it fast.

I believe the possibility of "making it fast" is taken in account in the existing design, to avoid designing a format which can't be cheaply optimised & hardware-implemented.

Re: Rav1e: An experimental AV1 video encoder, designed to be fast and safe

#26

Post by manmal »

derf_ wrote: post #23
arez wrote: post #6

Earlier quoted context omitted.

I always wondered if in practice it really checks out, is rust code really safer? Did the bugs just shift to different ones? Is there anyone who wrote about that already?

The "safest" comment is mostly tongue-in-cheek, but the advantages are real. I enjoyed this comment from someone contributing to the project for the first time: atomnuker: I felt good when my patch was done and I had exactly what I set out to write. I didn't enjoy the compiler forcing me to fix all my bugs upfront. There are also advantages other than safety to using a modern systems language that has learned somethi…

Having coded full-time in Swift for 2 years now, I can attest that strongly-typed languages really do a lot for code quality and especially reliability. Sure, you still have semantic bugs all over (that's what tests are for), but whole classes of bugs (null-pointer refs, dangling pointers) are at least greatly reduced. As long as I stay away from the no-nos (like implicitly unwrapped optionals) and use the goodies (immutable models; enums with attached values; generics), my apps hardly ever crash now, once out in the store.

Re: Rav1e: An experimental AV1 video encoder, designed to be fast and safe

#27

Post by pas »

matt4077 wrote: post #16
skolemtotem wrote: post #8

Will AV1, or even VP9 for that matter, ever be suitable for realtime encoding, or is that just not their target market?

Yes, of course. Anything else would be DOA. On a general note: there really seems to be an extremely inaccurate narrative regarding AV1 and speed taking hold. I can't understand why it isn't easier understood that a reference implementation is about accuracy only, completely ignoring performance considerations. Not in the usual "we'll now try to make it faster", but as in "this is never meant to be used in production…

People are pragmatic, at least in this regard. They don't really suffer from the bandwidth costs, they want fast encode speeds for offline storage.

And they are simply cautious. They don't really care about the hype x264 is good enough visually, now all visual comparisons are done on ridiculously low bitrate (which is a good thing, but people don't really care).

Re: Rav1e: An experimental AV1 video encoder, designed to be fast and safe

#28

Post by TD-Linux »

skolemtotem wrote: post #8

Will AV1, or even VP9 for that matter, ever be suitable for realtime encoding, or is that just not their target market?

I actually had a realtime rav1e demo running, with some modifications. There's nothing inherently less realtime about AV1 than, say H.264.

Re: Rav1e: An experimental AV1 video encoder, designed to be fast and safe

#29

Post by coldtea »

arez wrote: post #6
jabl wrote: post #4

Earlier quoted context omitted.

Presumably that it's implemented in Rust, and thus does not suffer from many of the usual bugs that C code bases suffer from? There seems to be some asm code as well, which obviously does not enjoy the safety advantages of Rust.

I always wondered if in practice it really checks out, is rust code really safer? Did the bugs just shift to different ones? Is there anyone who wrote about that already?

>I always wondered if in practice it really checks out, is rust code really safer? Did the bugs just shift to different ones?

Bugs don't magically "shift". If you eliminate a class of bugs, it's gone (e.g. memory bugs).

Whether you can still have other bugs (e.g. logic bugs) that's irrelevant, you could still have those in C as well.

Re: Rav1e: An experimental AV1 video encoder, designed to be fast and safe

#30

Post by coldtea »

pjmlp wrote: post #21
arez wrote: post #6

Earlier quoted context omitted.

I always wondered if in practice it really checks out, is rust code really safer? Did the bugs just shift to different ones? Is there anyone who wrote about that already?

Yes, but not only Rust, rather any memory safe system programming language all the way back to ESPOL in 1961. In those languages you have "Logic errors" to debug, in C and its direct descendants you have "Logic errors" + "UB errors" + "Memory corruption errors" to debug. Also having the use of unsafe explicit in the type system, means that it is relatively easy to track down where such issues might occur, whereas in…

>Yes, but not only Rust, rather any memory safe system programming language all the way back to ESPOL in 1961.

Yes, but now we're discussing only those that practically matter to more than 5 people today.

Post reply on HN