Will AV1, or even VP9 for that matter, ever be suitable for realtime encoding, or is that just not their target market?
AFAIK realtime encoding is a design consideration for AV1.
FREE Classifieds
http://www.f1mint.com/
Rav1e: An experimental AV1 video encoder, designed to be fast and safe
11–20 of 76 posts
Re: Rav1e: An experimental AV1 video encoder, designed to be fast and safe
#12Will AV1, or even VP9 for that matter, ever be suitable for realtime encoding, or is that just not their target market?
Well eventually we'll get AV1 hardware encoding so I'd say in 5 years smartphones will encode AV1 in real time
Re: Rav1e: An experimental AV1 video encoder, designed to be fast and safe
#13Re: Rav1e: An experimental AV1 video encoder, designed to be fast and safe
#14> ~5 fps encoding @ 480p How does this compare with the reference encoder?
The readme didn't specify the --release flag in the cargo run command, this should make a pretty big difference
Re: Rav1e: An experimental AV1 video encoder, designed to be fast and safe
#15Earlier quoted context omitted.
"Written in Rust"
I'm trying to get my insurance discounted on my car. I should slap a "written in Rust" sticker on it. Safe driver discount?
It makes sense. If your car is covered with rust, you should be almost sure that no one will even try to steal it. :)
Re: Rav1e: An experimental AV1 video encoder, designed to be fast and safe
#16Will 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, and it's performance is in no way indicative of the performance optimised encoders will see".
As but one example: media encoding is pretty close to being "embarrassingly parallel" in principle, making the first three orders of magnitude easy wins for a straightforward GPU implementation.
Re: Rav1e: An experimental AV1 video encoder, designed to be fast and safe
#17Will AV1, or even VP9 for that matter, ever be suitable for realtime encoding, or is that just not their target market?
Their target market is "negotiating with MPEG for lower royalties"
Re: Rav1e: An experimental AV1 video encoder, designed to be fast and safe
#18> ~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.
Many thanks!
Re: Rav1e: An experimental AV1 video encoder, designed to be fast and safe
#19Will 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.
Re: Rav1e: An experimental AV1 video encoder, designed to be fast and safe
#20Will 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…
> media encoding is pretty close to being "embarrassingly parallel" in principle
My understanding is that there are some fairly tight feedback loops in the encoders that make it difficult to offload things to the GPU, at least if you want to maximize the quality per byte metric. If you want to target realtime and don't need optimal compression it probably gets easier.