5 ms·

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

by 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.
      - ksec 8y ago
        >Reference implementations are not about performance, they are documentation. They are not supposed to be used for anything else but documentation. That is valid for all H.262 , H.263, H.264 and H.265, as well as the up coming H.266 VVC. The current Av1 isn't a documentation. Nor it is a Reference Implementation in the regards of all MEPG codec. The AV1 is built on a working, professionally made libvpx encoder built on VP9. >There is absolutely not reason assume that av1 is fundamentaly more power consuming that HEVC. It definitely will be more complex, both encoding and decoding. Its fundamental complexity is much higher then HEVC, how far could they optimise so they are close to 5 - 10x of HEVC is a different story.
    - aseipp 8y ago
      > Youtube and Netflix and pretty much irrelevant for anyone else I like it when the goalposts move in such a way that "used by services in over 50% of US households and services where 70% of all video usage come from mobile, and offers excellent bandwidth improvements for millions of users" apparently means AV1 is a failure, somehow, based on preliminary numbers for a use case (encoding) that largely isn't relevant to mobile devices (and will improve dramatically over time making encoding more usable, anyway, as all prior codecs did.) Unfortunately for the AV1 designers, they could have realized this fatal flaw sooner, had they only consulted the grand expertise of..... a random internet forum user.
- tux3 8y ago
  They sure are, but what AV1 currently excels at is making one expensive encode to save bandwidth costs on hundreds of thousands of views later on. It's maybe a little early in terms of available computing power (and how optimized encoders currently are) to think about AV1 mobile encoding.
- vetinari 8y ago
  Encoding on mobile does not have to use the most efficient profiles though. H.264 and HEVC mobile encoders do not use the higher profiles either.
  - tfha 8y ago
    The most computationally efficient encoding algorithms can do hundreds of frames per second at 720p even on mobile. The price you pay is quality and filesize - it'll be large and look awful.
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.

by aseipp 8y ago

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.
    - ksec 8y ago
      >Reference implementations are not about performance, they are documentation. They are not supposed to be used for anything else but documentation. That is valid for all H.262 , H.263, H.264 and H.265, as well as the up coming H.266 VVC. The current Av1 isn't a documentation. Nor it is a Reference Implementation in the regards of all MEPG codec. The AV1 is built on a working, professionally made libvpx encoder built on VP9. >There is absolutely not reason assume that av1 is fundamentaly more power consuming that HEVC. It definitely will be more complex, both encoding and decoding. Its fundamental complexity is much higher then HEVC, how far could they optimise so they are close to 5 - 10x of HEVC is a different story.
  - aseipp 8y ago
    > Youtube and Netflix and pretty much irrelevant for anyone else I like it when the goalposts move in such a way that "used by services in over 50% of US households and services where 70% of all video usage come from mobile, and offers excellent bandwidth improvements for millions of users" apparently means AV1 is a failure, somehow, based on preliminary numbers for a use case (encoding) that largely isn't relevant to mobile devices (and will improve dramatically over time making encoding more usable, anyway, as all prior codecs did.) Unfortunately for the AV1 designers, they could have realized this fatal flaw sooner, had they only consulted the grand expertise of..... a random internet forum user.
tux3 8y ago
They sure are, but what AV1 currently excels at is making one expensive encode to save bandwidth costs on hundreds of thousands of views later on. It's maybe a little early in terms of available computing power (and how optimized encoders currently are) to think about AV1 mobile encoding.
vetinari 8y ago
Encoding on mobile does not have to use the most efficient profiles though. H.264 and HEVC mobile encoders do not use the higher profiles either.
- tfha 8y ago
  The most computationally efficient encoding algorithms can do hundreds of frames per second at 720p even on mobile. The price you pay is quality and filesize - it'll be large and look awful.

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.