Do
not
attempt
to
implement
this
version
of
the
specification.
Do
not
reference
this
version
as
authoritative
in
any
way.
Instead,
see
https://w3c.github.io/mse-byte-stream-format-webm/
for
the
Editor's
draft.
This
section
describes
the
status
of
this
document
at
the
time
of
its
publication.
A
list
of
current
W3C
publications
and
the
latest
revision
of
this
technical
report
can
be
found
in
the
W3C
technical
reports
index
at
https://www.w3.org/TR/.
Publication
as
an
Editor's
Draft
does
not
imply
endorsement
by
W3C
and
its
Members.
This
is
a
draft
document
and
may
be
updated,
replaced
or
obsoleted
by
other
documents
at
any
time.
It
is
inappropriate
to
cite
this
document
as
other
than
work
in
progress.
Implementations
SHOULD
support
all
of
the
codec
IDs
mentioned
in
the
table
above.
Note
Implementations
SHOULD
encourage
applications
to
prefer
the
"vp09..."
codec
ID
over
"vp9".
The
"vp09..."
format
provides
detailed
profile
and
color
information,
enabling
implementations
to
give
more
accurate
answers
for
codec
support.
Examples
of
valid
MIME-types
with
a
codecs
parameter.
The
size
value
in
the
Segment
header
MUST
signal
an
"unknown
size"
or
contain
a
value
large
enough
to
include
the
Segment
Information
and
Track
elements
that
follow.
The
Cluster
header
MAY
contain
an
"unknown"
size
value.
If
it
does
then
the
end
of
the
cluster
is
reached
when
another
Cluster
header
or
an
element
header
that
indicates
the
start
of
a
WebM
initialization
segment
is
encountered.
Note
Implementations
MAY
guess
the
coded
frame
presentation
duration
for
SimpleBlocks
at
the
end
of
a
HTML
Standard
.
Content
providers
are
recommended
to
use
BlockGroups
with
explicit
BlockDurations,
instead
of
SimpleBlocks,
for
the
last
block
for
each
track
in
a
HTML
Standard
to
avoid
variance
in
buffering
behavior
across
implementations.
Note
Implementations
MAY
introduce
buffering
latency
for
each
SimpleBlock
encountered
in
a
HTML
Standard
,
since
such
a
block's
coded
frame
presentation
duration
may
not
be
determinable
until
the
next
block
is
parsed.
To
avoid
such
latency,
content
providers
are
recommended
to
use
BlockGroups
with
explicit
BlockDuration
instead
of
SimpleBlocks
within
a
HTML
Standard
.
The
user
agent
MUST
run
the
append
error
algorithm
if
any
of
the
following
conditions
are
not
met:
The
Timecode
element
MUST
appear
before
any
Block
&
SimpleBlock
elements
in
a
Cluster
.
Block
&
SimpleBlock
elements
are
in
time
increasing
order
consistent
with
[
WEBM
].
If
the
most
recent
WebM
initialization
segment
describes
multiple
tracks,
then
blocks
from
all
the
tracks
MUST
be
interleaved
in
time
increasing
order.
At
least
one
block
from
all
audio
and
video
tracks
MUST
be
present.
Either
a
SimpleBlock
element
with
its
Keyframe
flag
set,
or
a
BlockGroup
element
having
no
ReferenceBlock
elements,
signals
the
location
of
a
random
access
point
for
that
track.
The
order
of
multiplexed
blocks
within
a
media
segment
MUST
conform
to
the
WebM
Muxer
Guidelines
.
6.
Conformance
As
well
as
sections
marked
as
non-normative,
all
authoring
guidelines,
diagrams,
examples,
and
notes
in
this
specification
are
non-normative.
Everything
else
in
this
specification
is
normative.
The
key
words
MAY
,
MUST
,
and
SHOULD
in
this
document
are
to
be
interpreted
as
described
in
BCP
14
[
RFC2119
]
[
RFC8174
]
when,
and
only
when,
they
appear
in
all
capitals,
as
shown
here.
7.
Acknowledgments
The
editors
would
like
to
thank
Chris
Cunningham,
Frank
Galligan,
and
Philip
Jägenstedt
for
their
contributions
to
this
specification.