31–40 of 76 posts
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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.
Plus the point was to talk about safe systems programming languages in general.
Or should we ignore history just because UNIX won on the server?
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?
> 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.
I don't think it's particular likely, but there are always trade-offs.
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? 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.
Or, the way you eliminated one class opens up or makes more likely a different class. Maybe avoiding pointers makes it more likely to introduce logic bugs. It could also make some algorithm too slow, which one could call a performance bug. I don't think it's particular likely, but there are always trade-offs.
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…
Which part? 90% of what you're doing is context or inter-frame dependent. Video encoders that live on graphics cards today use dedicated ASIC hardware.
Earlier quoted context omitted.
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…
> As but one example: media encoding is pretty close to being "embarrassingly parallel" in principle Which part? 90% of what you're doing is context or inter-frame dependent. Video encoders that live on graphics cards today use dedicated ASIC hardware.
https://medium.com/netflix-techblog/high-quality-video-encod...
https://medium.com/netflix-techblog/dynamic-optimizer-a-perc...
Works well when you're doing video at the scale of Netflix, but not necessarily much help to the individual user who just wants to encode a video.
Do different video encoders, for the same codec, and input produce different outputs, or is the algorithm specified in a way where it produces the same results for two given inputs, no matter what?
Just curious, what's the memory footprint on the encoder in real life? Do different video encoders, for the same codec, and input produce different outputs, or is the algorithm specified in a way where it produces the same results for two given inputs, no matter what?
Different encoders produce different outputs, the algorithm isn't specified.
Earlier quoted context omitted.
> As but one example: media encoding is pretty close to being "embarrassingly parallel" in principle Which part? 90% of what you're doing is context or inter-frame dependent. Video encoders that live on graphics cards today use dedicated ASIC hardware.
You can divide the video into chunks and encode the chunks in parallel. This is what Netflix does: https://medium.com/netflix-techblog/high-quality-video-encod... https://medium.com/netflix-techblog/dynamic-optimizer-a-perc... Works well when you're doing video at the scale of Netflix, but not necessarily much help to the individual user who just wants to encode a video.
What about live encoding?