4 ms·
Encoding time is 667x compared to VP9. How can it be used in production ? 667 TIMES LONGER
by formatkaka 8y ago
Encoding time is 667x compared to VP9. How can it be used in production ? 667 TIMES LONGER
- akmittal 8y agoHow about decoding performance, which is much more important.
- bufferoverflow 8y agoBoth are important, especially in the age of user-generated content and 4K camera in every new smartphone.
- akmittal 8y agoMost people spend lot more time decoding than encoding.
- vanderZwan 8y agoYesterday's xiph.org thread had the same discussion - for live-streaming, encoding is the bottleneck. If the encoder drops frames, all recipients drop frames. - for other purposes, decoding is likely the "bottleneck", although even then: the slower and more CPU intensive an encoder is, the more times a video has to be downloaded and viewed to "break even" through the "savings" on the decoder side. So there still is a trade-off to be made with how slow an encoder is allowed to be.
- opencl 8y agoDecoding is going to have be supported in hardware for any sort of mass adoption anyway.
- deleted 8y ago[deleted]
- akmittal 8y agoIsn't same true for encoding. I don't see hardware support hardware support coming in next 2-3 years. Then also everyone is not going to change their hardware immediately. Good Software performance is quite important.
- ncmncm 8y agoThis is just the reference implementation. Its purpose is as a check for production versions to verify they produce the right bits, and to make clear what all the protocol options are. Production performance will be comparable to software implementations of the other protocols; and then hardware will be real-time, soon enough, and there will be expensive way-faster-than hardware for transcoding services. If you have much transcoding to do, you farm it to them. The performance of the first x264 software implementations was no better, although you never saw them.
- Ace17 8y ago> The performance of the first x264 software implementations was no better, although you never saw them. Yeah, the JM was ridiculously slow. Didn't stop people from making fast H.264 encoders.
- ZeroGravitas 8y agoNetflix (who are part of the group developing this) have stated they'll roll it out in production once it's less than 5x slower than VP9 so we can assume they are planning on it getting at least 134x faster than it currently is.
- akmittal 8y agoShouldn't they be concerned about decoding speed more than encoding.
- mfjordvald 8y agoI think them accepting a 5x encoding slow-down means they are mostly concerned about decoding speed.
- ZeroGravitas 8y agoI don't think anyone is worried about the decoding requirements, which will be higher than the previous generation but only a factor of 2 or so. Obviously, they won't be able to roll out high resolution content to phones, TVs or set top boxes until devices support it with hardware, which will be a couple of years from now. But, there's plenty of people in the world with decent desktop power and terrible bandwidth who can benefit immediately from squeezing better video through their connection at the cost of more CPU at both ends. Generally you won't hear those people commenting on forums like this, but they show up in companies like Netflix's business plans. YouTube has produced maps showing which countries had greater usage due to VP9.
- Radle 8y agoBecause it doesn't matter when you server the video 3 Billion times. Keep in mind that Gangnam Style views resulted in an int32 overflow. For companies like Netflix, Facebook, Youtube and many more it just makes more sense to handle increased rendering time. In addition to this, this is just a test implementation that's yet to be performance optimized. Also currently there's no hardware encoders, which will also give a serious boost to encoding performance.
- formatkaka 8y agoValid point.. But I was skeptical about it's adoption in the live streaming arena !!
- MayeulC 8y agoXilinx's statement [1] hints at FPGAs getting deployed in datacenters to accelerate AV1 encoding, which should tremendously improve performance (it seems more likely to me that the quoted 10x improvement is against a mature/optimized encoder, although I could be wrong). Google has (will?) published a verilog implementation, so in theory, you could put that on a FPGA you have lying around. [1] https://aomedia.org/the-alliance-for-open-media-kickstarts-video-innovation-era-with-av1-release/ https://aomedia.org/the-alliance-for-open-media-kickstarts-v... (scroll down)