The next-generation High Efficiency Video codec (HEVC), H.265, has hit a major public milestone thanks to the work of the developer MultiCoreWare. MCW is launching a new commercial open-source venture around x265, and the source code for its x265 encoder is now available. Right now, the project is very much in early days — pre-alpha level code — but the x265 encoder is already impressively parallelized and supports all of the major instruction sets including AVX/AVX2 and FMA3/FMA4.
The benefits of H.265
H.264 has been a huge
success. It’s a flexible
codec standard that’s used by streaming services, satellite providers, and for
Blu-ray discs. It’s scaled remarkably well since it was first proposed and is
capable of handling 3D, 48-60 fps encodes, and even 4K. The Blu-ray disc
standard doesn’t currently include provisions for some of these technologies,
but the H.264 codec itself is capable of handling them.
The problem with
H.264, however, is that while it can handle these types of
encodes, it can’t do so while simultaneously keeping file sizes low. A new standard is necessary to push file/stream sizes
back down while driving next-generation adoption, and that’s where H.265 comes
in. It’s designed to utilize substantially less bandwidth thanks to advanced
encoding techniques and a more sophisticated encode/decode model.
Unlike H.264, which
can extend to cover 4K television but wasn’t designed with the feature in mind, H.265 was built to
match the capabilities of future screens and includes support for 10-bit color and high frame rates. This is
early days — support and capability of the current alpha are limited to 8-bit
color and YUV output, but we still wanted to take the alpha technology out for
a spin. Armed with a freshly compiled version and some test clips, we set out
to see what we could build.
First up — file
sizes. What we’re comparing here is actually the size of the elementary video
stream. Note that these are video streams only — audio isn’t encoded in either
instance. Encode sizes were defined by the quantizer setting, with lower
q-values equaling a higher quality (and larger file size). The base encoded
file is 500 frames of a 1.5GB, YUV 4:2:0 file at 50 fps. The elementary stream
file size is used for comparison here because it represents what’s transmitted
to the decoder to create the final output. We’re working with elementary
streams because, at this stage of the project (pre-alpha), the decoded video
file always comes back at 1.5GB, regardless of the stream quality used to
create it.
This gives a good
basic idea of what sorts of benefits H.265 can offer compared to H.264. While
it’s not hitting 50% bandwidth savings in most cases, it’s close — quantizer 24
is 57% the size, q=30 is 59%, and q=40 is just 47%. Granted, at a quantizer of
40, the final output is wretched — but it’s wretched at less than half the
bandwidth.
Performance &
image quality
The next area we
wanted to consider was performance. H.265 is known for taking more horsepower
to encode and decode than H.264, though the team developing the standard
continues to emphasize the role of parallel computing in speeding the
encode/decode process. It’s implied that OpenCL support will materialize
sooner, rather than later, which means initiatives like AMD’s HSAcould get a boost from x265 support
early in 2014.
Right now, we’re
limited to CPU support, but Multi-CoreWare spokesperson Tom Vaughan emphasized
that the team has already been working on strong multithreading. We decided to
test the alpha decoder using Sandy Bridge-E, Ivy Bridge, and Haswell. We
experimented with different levels of parallelization but settled on options
that stuck to the number of physical cores in a system (6, 4, and 4).
Hyper-Threading was enabled, but setting for 12/8-thread parallelization
actually increased encode time slightly.
The parallelization
performance looks good — Sandy Bridge-E, with six cores, is somewhat ahead of
Ivy Bridge with four. Similarly, Ivy Bridge is beaten out by Haswell, thanks to the new core’s AVX2 support
and better performance characteristics. Compared to x264, even on the –veryslow
preset, x265 encodes take noticeably longer — our Ivy Bridge 3770K encoded the
same file in H.264 in 129 seconds as compared to 247 seconds for H.265. Keep in
mind, however, that this is very, very early software.
Of more interest is
the quality question — how does the H.265 output compare to the uncompressed
original? We chose a basketball clip because, at 50 fps, it’s full of the sort
of fast motion that often gives encoders fits. H.265’s smaller sizes won’t be
worth much if the final output isn’t as good.
To that end, here’s
the original uncompressed YUV output, the H.265 encode at q=24, and the H.264
output at q=24. Click on each image to enlarge it.
The variance here is
minimal. The hardwood floor underneath the the leaping player is slightly less
blurry in the H.264 variant, but the H.265 image quality is phenomenal
considering it’s half the size. What about lower qualities? Here’s H.265 and
H.264 at q=30; H.265 is first.
At q=30 (file sizes of
6.39MB and 10.87MB), the H.265 video stream is arguably better than the H.264
encode stream. We’re not trying to claim this is an absolute — as always,
encode settings matter a great deal and are sensitive to tweaking. But after
waiting more than a year for H.265 to break cover, it’s clear that the new
standard is going to offer what its proponents have claimed.
Encode/decode support, meanwhile, is already
going to be possible on a vast range of products. Modern CPUs are more than
capable of decoding H.265 in software, OpenCLsupport is coming in future
iterations, and hardware GPU support, while not formally guaranteed by AMD,
Intel, or Nvidia for next-generation products, is a mid-term certainty. All
three companies have previously leapt to include advanced video pipelines in
their products — as the H.265 presentation notes, video is something that’s
become ubiquitous across every type of device.
Long-term, H.265 will likely succeed H.264’s
position as the premier solution for advanced video, though that may depend on
whether or not battery consumption while decoding can match H.264’s levels in
the long term. That’s something we’ll only be able to evaluate once hardware is
available, but for now we’re optimistic. H.265’s explicitly parallel model
should map well against multi-core devices of the future.
Established in 2000, the Soukacatv.com main
products are modulators both in analog and digital ones, amplifier and
combiner. We are the very first one in manufacturing the headend system in
China. Our 16 in 1 and 24 in 1 now are the most popular products all over the
world.
For more, please access to
https://www.soukacatv.com.
CONTACT US
Dingshengwei Electronics Co., Ltd
Company Address: Building A, the first
industry park of Guanlong, Xili Town, Nanshan, Shenzhen, Guangdong, China
Tel : +86 0755 26909863
Fax : +86 0755 26984949
Phone: +86 13410066011
Email:ken@soukacatv.com
Skype: soukaken
Source：extremetech
没有评论:
发表评论