5 ms·

> And they didn't mention in the Moscow State University test, AV1 was 300x to 1000x slower. Reference implementations of codecs are always slower. AV1 hasn't

> And they didn't mention in the Moscow State University test, AV1 was 300x to 1000x slower. Reference implementations of codecs are always slower. AV1 hasn't had the benefit of years of optimizations yet, so this slowness is to be expected.

okket 8y ago
If the codec can not be implemented efficiently on existing battery powered handheld devices, it is pretty useless. That is the only metric that counts. Even if, it will take many years to a decade to spread, considering the replacement rates of those devices.
- aseipp 8y ago
  HEVC/H265 implementations were initially very poor also, but it doesn't mean much now. Plus, mobile devices will use embedded fixed-block ASICs for this, just like they already do for every existing codec. All codecs are completely impractical on mobile devices if you're basing your estimates off software numbers, even extremely well optimized software will kill your battery. So it's basically meaningless to try and extrapolate from optimized numbers, much less preliminary ones. Besides, encoding AV1 is what's expensive, but mobile devices also do not necessarily need AV1 encode support anyway. They will need decode support. Slow encode support is going to be a problem for people creating and serving video. But better compression rates from AV1 substantially help mobile devices, too, by reducing bandwidth needs for providers. You're likely to see major video content providers taking the hit of AV1 encoding, while users only need to decode, and this will largely be how it is used.
  - threeseed 8y ago
    > but mobile devices also do not necessarily need AV1 encode So people aren't using Snapchat, Instagram Stories, FaceTime, IGTV ? Because pretty sure encoding is just as important as decoding.
    - aseipp 8y ago
      Whether or not they use it is a completely different matter from whether AV1 is useful for those scenarios. Assuming a gargantuan encoding slowdown, even in the face of hardware-based encoders on mobile devices (which, again: hardware decoding/encoding is the fact of the matter on how it will happen), then there's no reason to support AV1 encoders since it will hurt battery. You're better off with something else, because users care more about their battery than compression ratios or minor artifacts on their Insta videos. Assuming no gargantuan slowdown, and devices are equipped with AV1 encoders that perform admirably, then your problem is solved. Just use the hardware encoder. (Personally, it's unclear to me how much of AV1 encode support is fundamental slowness that can't be mitigated by hardware and implementation, but I suspect a lot of this fear is tied up in early-stage numbers. I bet it can go much faster, even if it's still slower overall.) If you're a media provider like Netflix for example, though, the bandwidth savings will utterly dwarf the cost of the more expensive encoding process. They encode once and serve thousands of times, and they don't run Netflix (the company) on old mobile phones. So they'll do it anyway, because they want their users to use AV1. It saves them bandwidth on a high quality video, and it saves users on their data plans and their battery. This isn't really very hard to think about. Either AV1 encoding is fundamentally too inefficient for mobile, or it isn't. If it isn't, users can still get fast decoders (that wasn't the bottleneck), since the bandwidth savings are going to be highly desirable for everyone, basically, and they'll be pushed for. If they can be efficient enough, then there's no problem.
      - threeseed 8y ago
        The problem is that reference implementations of AV1 are 100x slower than HEVC at encoding. And so hardware decoding may ether be (a) impossible on current devices or (b) likely to destroy battery life. The only option is some breakthrough in the complexity of the encoding algorithm. These issues unless solved relegates AV1 to being a Youtube and Netflix format and pretty much irrelevant for everyone else.
        1ris 8y ago
        I means that the reference implementation is slower. Nothing more. Reference implementations are not about performance, they are documentation. They are not supposed to be used for anything else but documentation. Your conclusion is ridiculous. There is absolutely not reason assume that av1 is fundamentaly more power consuming that HEVC. A tank uses more gasoline that a VW Beetle. This statement is true, and as irrelevant as your statement.
  - clouddrover 8y ago
    > All codecs are completely impractical on mobile devices if you're basing your estimates off software numbers I have an iPhone 7 which has no hardware VP9 support but VP9 video works well at 720p in VLC. I'm sure the battery won't last as long as playing H.264 video in hardware but I wouldn't call VP9 playback impractical.
    - conradev 8y ago
      Your iPhone has hardware support for encoding and decoding HEVC, too!
      - clouddrover 8y ago
        Yes, but my point was don't underestimate software decoders on modern mobile devices. As an experiment, I left a local 720p30 VP9 video with Opus audio running in a loop in VLC on my iPhone 7 for 3 hours. Both video and audio are being decoded in software. My battery started at 90% and at the end of three hours it was at 55%. I think that's pretty good for software decoding. I'm not sure which VP9 decoder VLC uses on iOS. I presume it's ffvp9: https://blogs.gnome.org/rbultje/2014/02/22/the-worlds-fastest-vp9-decoder-ffvp9/ https://blogs.gnome.org/rbultje/2014/02/22/the-worlds-fastes...
  - untog 8y ago
    > mobile devices also do not necessarily need AV1 encode support anyway I wouldn't be so quick to dismiss it - video chat is a great use case for an improved codec.
    - sjwright 8y ago
      It will come—once encoding silicon is available. Until then, phones will necessarily use whatever codec they have hardware encoding support for.
  - devwastaken 8y ago
    >but mobile devices also do not necessarily need AV1 encode support anyway I would highly, highly argue that they do. There is no reason in modern day that we need to all be uploading the full size of images and videos to servers to be re-compressed. It creates a significant barrier to entry for any social media platform when it should be as simple as the device itself being able to encode it, with the server checking it and creating other sizes. If AV1 becomes the great standard we can reduce a lot of costs. We already could do it with jpeg compression, but hasn't seemed to happen. Slightly less compression rates for faster compression is perfectly acceptable. I would hope theres profiling options for that.
- yoz-y 8y ago
  h265 had the exact same problems too. AV1 is not implemented on mobile, yet. Both Apple and Google are on board with this, as soon as it is completed I believe it will spread quite quickly.
  - squarefoot 8y ago
    Also TV boxes and embedded SBCs. Having an AV1 decoder on board of say a Raspberry PI or other similar board would make a difference. There's a lot of them around playing movies through Kodi.
- threeseed 8y ago
  Not sure why this was down voted. It really is the only thing that matters. The trend is overwhelmingly towards mobile being the dominant platform for video. And if your videos can't play on the majority of the iOS and Android it's simply a non-starter. Look at what happened to Flash once Apple banned it on iOS.
  - stouset 8y ago
    It’s downvoted because this comment appears in literally every discussion about new codecs, is misguided and trivially countered every time, and yet it persists. People enjoyed this discussion the first, second, and maybe even third time. By the twentieth time, people get tired of commenters making these kinds of baseless assertions that fundamentally boil down to an accusation of staggering incompetence on those involved in designing the codec. Yes, the reference implementation of encoding is slow. Being fast is not a high priority for a reference implementation. Optimized implementations will come later. ASIC implementations will come later. The H.265 reference implementation was similarly slow, and it’s not a problem. And mobile devices primarily care about decode performance.
    - threeseed 8y ago
      > The H.265 reference implementation was similarly slow, Please provide evidence. Because all other data has shown it to be 100x slower. There is a reason why people are obsessing over encode speed.
      - gsich 8y ago
        Slower compared to what?
      - BurningCycles 8y ago
        Encode speed hasn't seen much optimization, the bitstream was frozen just weeks ago. Also there are already an alternative AV1 encoder in the works, RAV1E, written by Mozilla in Rust, so there will be competition which will likely speed development, and the x265 developers have stated that they will create an AV1 encoder if that's where the market goes, which at this point seems very likely given that all the major players are backing this codec, coupled with the fact that it's royalty free and thus can be implemented anywhere.

okket 8y ago

If the codec can not be implemented efficiently on existing battery powered handheld devices, it is pretty useless. That is the only metric that counts. Even if, it will take many years to a decade to spread, considering the replacement rates of those devices.

aseipp 8y ago
HEVC/H265 implementations were initially very poor also, but it doesn't mean much now. Plus, mobile devices will use embedded fixed-block ASICs for this, just like they already do for every existing codec. All codecs are completely impractical on mobile devices if you're basing your estimates off software numbers, even extremely well optimized software will kill your battery. So it's basically meaningless to try and extrapolate from optimized numbers, much less preliminary ones. Besides, encoding AV1 is what's expensive, but mobile devices also do not necessarily need AV1 encode support anyway. They will need decode support. Slow encode support is going to be a problem for people creating and serving video. But better compression rates from AV1 substantially help mobile devices, too, by reducing bandwidth needs for providers. You're likely to see major video content providers taking the hit of AV1 encoding, while users only need to decode, and this will largely be how it is used.
- threeseed 8y ago
  > but mobile devices also do not necessarily need AV1 encode So people aren't using Snapchat, Instagram Stories, FaceTime, IGTV ? Because pretty sure encoding is just as important as decoding.
  - aseipp 8y ago
    Whether or not they use it is a completely different matter from whether AV1 is useful for those scenarios. Assuming a gargantuan encoding slowdown, even in the face of hardware-based encoders on mobile devices (which, again: hardware decoding/encoding is the fact of the matter on how it will happen), then there's no reason to support AV1 encoders since it will hurt battery. You're better off with something else, because users care more about their battery than compression ratios or minor artifacts on their Insta videos. Assuming no gargantuan slowdown, and devices are equipped with AV1 encoders that perform admirably, then your problem is solved. Just use the hardware encoder. (Personally, it's unclear to me how much of AV1 encode support is fundamental slowness that can't be mitigated by hardware and implementation, but I suspect a lot of this fear is tied up in early-stage numbers. I bet it can go much faster, even if it's still slower overall.) If you're a media provider like Netflix for example, though, the bandwidth savings will utterly dwarf the cost of the more expensive encoding process. They encode once and serve thousands of times, and they don't run Netflix (the company) on old mobile phones. So they'll do it anyway, because they want their users to use AV1. It saves them bandwidth on a high quality video, and it saves users on their data plans and their battery. This isn't really very hard to think about. Either AV1 encoding is fundamentally too inefficient for mobile, or it isn't. If it isn't, users can still get fast decoders (that wasn't the bottleneck), since the bandwidth savings are going to be highly desirable for everyone, basically, and they'll be pushed for. If they can be efficient enough, then there's no problem.
    - threeseed 8y ago
      The problem is that reference implementations of AV1 are 100x slower than HEVC at encoding. And so hardware decoding may ether be (a) impossible on current devices or (b) likely to destroy battery life. The only option is some breakthrough in the complexity of the encoding algorithm. These issues unless solved relegates AV1 to being a Youtube and Netflix format and pretty much irrelevant for everyone else.
      - 1ris 8y ago
        I means that the reference implementation is slower. Nothing more. Reference implementations are not about performance, they are documentation. They are not supposed to be used for anything else but documentation. Your conclusion is ridiculous. There is absolutely not reason assume that av1 is fundamentaly more power consuming that HEVC. A tank uses more gasoline that a VW Beetle. This statement is true, and as irrelevant as your statement.
- clouddrover 8y ago
  > All codecs are completely impractical on mobile devices if you're basing your estimates off software numbers I have an iPhone 7 which has no hardware VP9 support but VP9 video works well at 720p in VLC. I'm sure the battery won't last as long as playing H.264 video in hardware but I wouldn't call VP9 playback impractical.
  - conradev 8y ago
    Your iPhone has hardware support for encoding and decoding HEVC, too!
    - clouddrover 8y ago
      Yes, but my point was don't underestimate software decoders on modern mobile devices. As an experiment, I left a local 720p30 VP9 video with Opus audio running in a loop in VLC on my iPhone 7 for 3 hours. Both video and audio are being decoded in software. My battery started at 90% and at the end of three hours it was at 55%. I think that's pretty good for software decoding. I'm not sure which VP9 decoder VLC uses on iOS. I presume it's ffvp9: https://blogs.gnome.org/rbultje/2014/02/22/the-worlds-fastest-vp9-decoder-ffvp9/ https://blogs.gnome.org/rbultje/2014/02/22/the-worlds-fastes...
- untog 8y ago
  > mobile devices also do not necessarily need AV1 encode support anyway I wouldn't be so quick to dismiss it - video chat is a great use case for an improved codec.
  - sjwright 8y ago
    It will come—once encoding silicon is available. Until then, phones will necessarily use whatever codec they have hardware encoding support for.
- devwastaken 8y ago
  >but mobile devices also do not necessarily need AV1 encode support anyway I would highly, highly argue that they do. There is no reason in modern day that we need to all be uploading the full size of images and videos to servers to be re-compressed. It creates a significant barrier to entry for any social media platform when it should be as simple as the device itself being able to encode it, with the server checking it and creating other sizes. If AV1 becomes the great standard we can reduce a lot of costs. We already could do it with jpeg compression, but hasn't seemed to happen. Slightly less compression rates for faster compression is perfectly acceptable. I would hope theres profiling options for that.
yoz-y 8y ago
h265 had the exact same problems too. AV1 is not implemented on mobile, yet. Both Apple and Google are on board with this, as soon as it is completed I believe it will spread quite quickly.
- squarefoot 8y ago
  Also TV boxes and embedded SBCs. Having an AV1 decoder on board of say a Raspberry PI or other similar board would make a difference. There's a lot of them around playing movies through Kodi.
threeseed 8y ago
Not sure why this was down voted. It really is the only thing that matters. The trend is overwhelmingly towards mobile being the dominant platform for video. And if your videos can't play on the majority of the iOS and Android it's simply a non-starter. Look at what happened to Flash once Apple banned it on iOS.
- stouset 8y ago
  It’s downvoted because this comment appears in literally every discussion about new codecs, is misguided and trivially countered every time, and yet it persists. People enjoyed this discussion the first, second, and maybe even third time. By the twentieth time, people get tired of commenters making these kinds of baseless assertions that fundamentally boil down to an accusation of staggering incompetence on those involved in designing the codec. Yes, the reference implementation of encoding is slow. Being fast is not a high priority for a reference implementation. Optimized implementations will come later. ASIC implementations will come later. The H.265 reference implementation was similarly slow, and it’s not a problem. And mobile devices primarily care about decode performance.
  - threeseed 8y ago
    > The H.265 reference implementation was similarly slow, Please provide evidence. Because all other data has shown it to be 100x slower. There is a reason why people are obsessing over encode speed.
    - gsich 8y ago
      Slower compared to what?
    - BurningCycles 8y ago
      Encode speed hasn't seen much optimization, the bitstream was frozen just weeks ago. Also there are already an alternative AV1 encoder in the works, RAV1E, written by Mozilla in Rust, so there will be competition which will likely speed development, and the x265 developers have stated that they will create an AV1 encoder if that's where the market goes, which at this point seems very likely given that all the major players are backing this codec, coupled with the fact that it's royalty free and thus can be implemented anywhere.