3 ms·

Encoding speed right now is: either you have a computer cluster or you'll die before the encoding is done. But it will probably get better.

cesarb 9y ago
If they haven't tried optimizing encoding speed yet, how can they be sure there isn't some misfeature in the standard that will hinder high-speed encoding? Like IIRC with some old On2 codec, where the order of the tokens in the encoded stream was not ideal for an optimized implementation.
- ComputerGuru 9y ago
  They don’t care. It’s Google, Netflix, and Amazon and their concern is recurring bandwidth, not onetime cpu costs. http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/AV1-A-Status-Update-120214.aspx http://www.streamingmedia.com/Articles/Editorial/Featured-Ar... "We will be satisfied with 20% efficiency improvement over HEVC when measured across a diverse set of content and would consider a 3-5x increase in computational complexity reasonable."
  - xoa 9y ago
    I can see their point (and that of any other content provider) in that context, but I'm sure they do care. It would be fine even if it required a dedicated hardware encoding bloc, but lack of reasonable RT encoding (including low wattage) would create a significant technical impediment to full general adoption, so I can't believe that optimization hasn't been at least somewhat considered. There is of course still plenty of real time streaming that's important, though in those cases reduction in quality would often be an acceptable tradeoff. However, Apple and Google both have a quite reasonable and absolute need for real time (or a close enough cheat), high quality offline encoding on mobile systems within the physical constraints of a handheld form factor. End users will also want to (again, quite reasonably) be able to immediately share what they make without the need for a lengthy reencoding stage or trip through a middleman. So if there wasn't at least a timeline for 4k+ RT on iPhone or Android devices I can't see how HEVC wouldn't stick around for a very long time. That a live stream has already been demonstrated should mean that this has been considered and they do care though, and thus won't be a problem. Ideally of course at least the high end of current generation devices would be capable of AV1 recording through software updates, which would enable moving on much more rapidly from HEVC. For that at least though I think it'd be an acceptable tradeoff to have those become legacy if that's what it takes to get us into a patent-unencumbered future afterwards. A pity software patents couldn't have just been eliminated entirely but I guess that remains politically infeasible for now.
  - ZeroGravitas 9y ago
    Some of the Alliance members want to use it for video chat (e.g. Cisco, Google) or live streaming (e.g. Twitch/Amazon, Google) so it'll get done at some point.
  - earenndil 9y ago
    It's not onetime CPU costs, at least for Google. Netflix and amazon don't process that much video (relatively), so they can afford slow encode times, but youtube gets tons of video uploaded every minute, they want fast and cheap encoding.
    - Whitestrake 9y ago
      For each individual video, it is a onetime CPU cost, but not a onetime bandwidth cost. For ongoing operation of the platform, at scale, you might argue that it's an ongoing CPU cost as more and more videos are added constantly, but the bandwidth to distribute those videos goes up at an equal rate on average. I don't know any actual numbers, but it seems very plausible to me that a vast increase in CPU cost for a minor decrease of bandwidth cost could still be a welcome trade-off. If you're making an argument that availability of CPU power at that scale is a concern, it seems like YouTube has the option of Google's cloud services as an excellent candidate for massive, interruptible compute power.
      - ZeroGravitas 9y ago
        It's not just bandwidth cost. Google suggests their big win with VP9 deployment is reaching people across the globe with relatively powerful computers but terrible internet connections. By using more powerful compression (paying for it with more computing work at both ends) they can get higher quality video to these users. And from a blunt business perspective: Higher quality videos = more watch time = platform dominance = more ads viewed.
      - earenndil 9y ago
        > vast increase in CPU cost for a minor decrease of bandwidth cost could still be a welcome trade-off I don't think that this would be true, though. Recall the 80-20 rule. They have to encode (CPU) a lot of videos, which will get very few views (bandwidth).
        ComputerGuru 9y ago
        Not really. It’s the long tail. The most popular videos are (in addition to likely being ultra resolution like vevo media’s) watched many (8-10?) orders of magnitude more times than the least popular videos. Bandwidth matters, cpu doesn’t. It’s actually the same 80-20 rule. Eighty percent of the costs come fro serving twenty percent of their videos:)
- TD-Linux 9y ago
  That is a real risk - however, this time around people are already working on their own fast implementations (both software and hardware versions), so a lot of the dumb mistakes will already be avoided. There is also the risk of a lot of features being too slow to use at all in a fast encoder, but that's not a risk exclusive to AV1. HM (the reference H.265 encoder) was far too slow to be practical, and given the current speeds of H.265 encoders compared to H.264 at their best quality settings, it's not clear that they totally succeeded.
clouddrover 9y ago
It's true that the encoder is very slow at the moment, but it's also true that Bitmovin managed to produce a live AV1 stream 9 months ago: https://bitmovin.com/bitmovin-supports-av1-encoding-vod-live-joins-alliance-open-media/ https://bitmovin.com/bitmovin-supports-av1-encoding-vod-live... They also have an AV1 demo page which works with Firefox Nightly: http://demo.bitmovin.com/public/firefox/av1/ http://demo.bitmovin.com/public/firefox/av1/
gribbly 9y ago
Until the bitstream is frozen, there is basically zero work on optimization.

cesarb 9y ago

If they haven't tried optimizing encoding speed yet, how can they be sure there isn't some misfeature in the standard that will hinder high-speed encoding? Like IIRC with some old On2 codec, where the order of the tokens in the encoded stream was not ideal for an optimized implementation.

ComputerGuru 9y ago
They don’t care. It’s Google, Netflix, and Amazon and their concern is recurring bandwidth, not onetime cpu costs. http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/AV1-A-Status-Update-120214.aspx http://www.streamingmedia.com/Articles/Editorial/Featured-Ar... "We will be satisfied with 20% efficiency improvement over HEVC when measured across a diverse set of content and would consider a 3-5x increase in computational complexity reasonable."
- xoa 9y ago
  I can see their point (and that of any other content provider) in that context, but I'm sure they do care. It would be fine even if it required a dedicated hardware encoding bloc, but lack of reasonable RT encoding (including low wattage) would create a significant technical impediment to full general adoption, so I can't believe that optimization hasn't been at least somewhat considered. There is of course still plenty of real time streaming that's important, though in those cases reduction in quality would often be an acceptable tradeoff. However, Apple and Google both have a quite reasonable and absolute need for real time (or a close enough cheat), high quality offline encoding on mobile systems within the physical constraints of a handheld form factor. End users will also want to (again, quite reasonably) be able to immediately share what they make without the need for a lengthy reencoding stage or trip through a middleman. So if there wasn't at least a timeline for 4k+ RT on iPhone or Android devices I can't see how HEVC wouldn't stick around for a very long time. That a live stream has already been demonstrated should mean that this has been considered and they do care though, and thus won't be a problem. Ideally of course at least the high end of current generation devices would be capable of AV1 recording through software updates, which would enable moving on much more rapidly from HEVC. For that at least though I think it'd be an acceptable tradeoff to have those become legacy if that's what it takes to get us into a patent-unencumbered future afterwards. A pity software patents couldn't have just been eliminated entirely but I guess that remains politically infeasible for now.
- ZeroGravitas 9y ago
  Some of the Alliance members want to use it for video chat (e.g. Cisco, Google) or live streaming (e.g. Twitch/Amazon, Google) so it'll get done at some point.
- earenndil 9y ago
  It's not onetime CPU costs, at least for Google. Netflix and amazon don't process that much video (relatively), so they can afford slow encode times, but youtube gets tons of video uploaded every minute, they want fast and cheap encoding.
  - Whitestrake 9y ago
    For each individual video, it is a onetime CPU cost, but not a onetime bandwidth cost. For ongoing operation of the platform, at scale, you might argue that it's an ongoing CPU cost as more and more videos are added constantly, but the bandwidth to distribute those videos goes up at an equal rate on average. I don't know any actual numbers, but it seems very plausible to me that a vast increase in CPU cost for a minor decrease of bandwidth cost could still be a welcome trade-off. If you're making an argument that availability of CPU power at that scale is a concern, it seems like YouTube has the option of Google's cloud services as an excellent candidate for massive, interruptible compute power.
    - ZeroGravitas 9y ago
      It's not just bandwidth cost. Google suggests their big win with VP9 deployment is reaching people across the globe with relatively powerful computers but terrible internet connections. By using more powerful compression (paying for it with more computing work at both ends) they can get higher quality video to these users. And from a blunt business perspective: Higher quality videos = more watch time = platform dominance = more ads viewed.
    - earenndil 9y ago
      > vast increase in CPU cost for a minor decrease of bandwidth cost could still be a welcome trade-off I don't think that this would be true, though. Recall the 80-20 rule. They have to encode (CPU) a lot of videos, which will get very few views (bandwidth).
      - ComputerGuru 9y ago
        Not really. It’s the long tail. The most popular videos are (in addition to likely being ultra resolution like vevo media’s) watched many (8-10?) orders of magnitude more times than the least popular videos. Bandwidth matters, cpu doesn’t. It’s actually the same 80-20 rule. Eighty percent of the costs come fro serving twenty percent of their videos:)
TD-Linux 9y ago
That is a real risk - however, this time around people are already working on their own fast implementations (both software and hardware versions), so a lot of the dumb mistakes will already be avoided. There is also the risk of a lot of features being too slow to use at all in a fast encoder, but that's not a risk exclusive to AV1. HM (the reference H.265 encoder) was far too slow to be practical, and given the current speeds of H.265 encoders compared to H.264 at their best quality settings, it's not clear that they totally succeeded.

clouddrover 9y ago

It's true that the encoder is very slow at the moment, but it's also true that Bitmovin managed to produce a live AV1 stream 9 months ago: https://bitmovin.com/bitmovin-supports-av1-encoding-vod-live-joins-alliance-open-media/ https://bitmovin.com/bitmovin-supports-av1-encoding-vod-live... They also have an AV1 demo page which works with Firefox Nightly: http://demo.bitmovin.com/public/firefox/av1/ http://demo.bitmovin.com/public/firefox/av1/

gribbly 9y ago

Until the bitstream is frozen, there is basically zero work on optimization.