Graphics Reference
In-Depth Information
erability
is enabled across a breadth of products made by different entities. The goal
of the HEVC standard is not just to compress video well, but also to enable the
design to be used in many different products and services across a very wide range
of application environments. No assumption is made that encoders and decoders
will all work the same way—in fact, a great deal of intentional flexibility is built
into the design. Indeed, strictly speaking, it is incorrect to refer to a standard such as
HEVC or AVC as a “codec”—since the standard does not specify an encoder and a
decoder. Instead, it specifies only a common format—a common
language
by which
encoding and decoding systems, each made separately using different computing
architectures and with different design constraints and priorities, can nevertheless
communicate effectively.
A great deal of what characterizes a product has been deliberately left outside the
scope of the standard, particularly including the following:
The entire encoding process
: Encoder designers are allowed to encode video
using any searching and decision criteria they choose—so long as the format of
their output conforms to the format specifications of the standard. This particu-
larly includes the relative prioritization of various bitstream characteristics—the
standard allows encoders to be designed primarily for low complexity, primarily
for high coding efficiency, primarily to enable good recovery from data losses,
primarily to minimize real-time communication latency, etc.
Many aspects of the decoding process
: When presented with a complete and
uncorrupted coded bitstream, the standard requires decoders to produce partic-
ular decoded picture data values at some processing stage as their theoretical
“output”; however, it does not require the decoders to use the same exact
processing steps in order to produce that data.
Data loss and corruption detection and recovery
: The standard does not
govern what a decoder will do if it is presented with incomplete or corrupted
video data. However, in real-world products, coping with imperfect input is a
fundamental requirement.
Extra functionalities
: Operations such as random access and channel switching,
“trick mode” operations like fast-forwarding and smooth rewind, and other
functions such as bitstream splicing are all left out of the scope of the standard to
allow products to use the coded data as they choose.
Pre-processing, post-processing, and display
: Deliberate alteration of encoder
input data and post-decoding picture modification is allowed for whatever reason
the designers may choose, and how the video is ultimately displayed (including
key aspects such as the accuracy of color rendering) is each product's own
responsibility.
All of this gives implementers a great deal of freedom and flexibility, while
governing only what is absolutely necessary to establish the ability for data that is
properly encoded by any “conforming” encoder to be decoded by any “conforming”
decoder (subject to profile/tier/level compatibility as further discussed below). It
does not necessarily make the job of the encoder and decoder designer especially
easy, but it enables products made by many different people to communicate
