? QUANTIF YING THE BANDWIDTH SAVINGS
Of course, any company paying significant
bandwidth charges may decide to roll the dice
and opt for the savings that HEVC can provide.
Here, it’s critical to remember that just because
HEVC is 40% more efficient than H.264 doesn’t
mean that switching to HEVC will shave 40%
from your delivery costs.
Why not? Consider Figure 4, which shows
an encoding ladder and three different stream
distribution patterns, A, B, and C. Each pattern shows the percentage of each stream actually delivered from the adaptive group, as
you should be able to derive from your log files.
In pattern A, all of the streams delivered are
3000Kbps or below, perhaps representative of
distribution in a third-world country. In this
case, switching to HEVC would have no impact
on bandwidth cost because you’d just be switching an HEVC stream for an H.264 stream. The
quality would be improved, of course, but you’d
be distributing the same bandwidth stream;
you’d just be sending HEVC rather than H.264.
In distribution pattern B, 100% of the delivered streams are the 7800Kbps stream, perhaps representative of distributing via direct
fiber to the home in Scandinavia. Here, converting to HEVC would drop the effective bitrate to
the 4500Kbps shown in Figure 2, a bandwidth
savings of about 42% for 100% of your viewers.
Absent concerns about content royalties, this
situation would be a no-brainer for HEVC.
Pattern C shows a high concentration in
the top rungs and a decent spread in the other
rungs, perhaps a mix of mobile and broadband.
Here, converting to HEVC would drop the 7800
and 6000Kbps streams down to 4500Kbps, reducing overall delivery bandwidth by about 31%.
The obvious point is that your bandwidth
savings depends upon your distribution pattern, which is data you’ll have to mine from your
log files. After figuring this out, you can easily
normalize encoding costs and bandwidth savings to a common unit, like an hour of video.
Divide savings per hour into cost per hour to
compute the number of hours of video you have
to stream to recover the costs associated with
supporting the new format.
Clearly, the greater the reach, the more deploying HEVC makes sense. If you’re already
encoding HEVC for other platforms, exploring
how to transmux these streams to HLS (if needed) is a no-brainer.
HEVC CURRENT STATUS
Although many producers are working with
HEVC, the codec still comprises a small percentage of total encoded streams. For example,
in Bitmovin’s “Video Developer Report 2017”
( go2sm.com/bitmovinsurvey), which incorporated 380 global survey submissions, 28% of
respondents reported that they were currently
deploying HEVC streams. However, a different
report for the same time period—the “Global
Media Format Report 2018” from the cloud-encoding vendor called Encoding.com (go2sm
.com/encodingsurvey)—reported that only 9%
of the streams produced by the service in 2017
were encoded with HEVC. Most of that usage
related to testing, although Encoding.com expects to see a substantial increase in HEVC deployments in 2018. Why? Because Apple added
HEVC to HLS, which likely represents the most
significant opportunity for HEVC adoption in
2018 and beyond.
HEVC’S SIGNIFICANT OPPORTUNITY
Specifically, in June 2017, Apple added HEVC
to HLS for delivery to iOS, tvOS, and macOS.
Although Apple provided the usual direction
in the form of suggested encoding ladders and
detailed configuration recommendations (see
go2sm.com/hevcapple), the new format raised
multiple uncomfortable questions for publishers seeking to deploy it.
For example, how would different iOS, tvOS,
and macOS devices perform when switching
between H.264 and HEVC streams in an encoding ladder? Would HEVC playback swamp
the CPU of older devices, and result in poor
quality playback? How would legacy devices
handle a hybrid ladder with HEVC and HLS?