order implies that no frames are dependent on subsequent frames, as
discussed in section 3.4. When a video frame consists of a single
picture, the presentation time of the frame is identical to the
presentation time of the picture. When the VC-1 interlace coding
mode is used, frames may contain two pictures, one for each field.
In that case, the presentation time of a frame is the presentation
time of the field that is displayed first.
The RTP timestamp field MUST be set to the presentation time of the
video frame contained in the first AU in the RTP packet. The
presentation time can be used as the timestamp field in the RTP
header because it differs from the sampling instant of the frame only
by an arbitrary constant offset.
If the video frame in an AU has a presentation time that differs from
the RTP timestamp field, then the presentation time MUST be specified
using the PTS Delta field in the AU header. Since the RTP timestamp
field must be identical to the presentation time of the first video
frame, this can only happen if an RTP packet contains multiple AUs.
The syntax of the PTS Delta field is defined in section 5.2.
The decode time of a VC-1 frame is always monotonically increasing
when the video frames are transmitted in the coded order. If neither
B- nor BI-pictures are present in the coded bit stream, then the
decode time of a frame SHALL be equal to the presentation time of the
frame. A BI-picture is a special kind of B-picture, and in the
remainder of this section the terms B-picture and B-frame also apply
to BI-pictures and BI-frames, respectively.
If B-pictures may be present in the coded bit stream, then the decode
times of frames are determined as follows:
- B-frames:
The decode time SHALL be equal to the presentation time of the
B-frame.
- First non-B frame in the coded order:
The decode time SHALL be at least one frame period less than the
decode time of the next frame in the coded order. A frame period
is defined as the inverse of the frame rate used in the coded bit
stream (e.g., 100 milliseconds if the frame rate is 10 frames per
seconds.) For bit streams with a variable frame rate, the maximum
frame rate SHALL determine the frame period. If the maximum frame
is not specified, the maximum frame rate allowed by the profile
and level SHALL be used.
- Non-B frames (other than the first frame in the coded order):
The decode time SHALL be equal to the presentation time of the
previous non-B frame in the coded order.
As an example, consider Figure 1 in section 3.4. To determine the
decode time of the first frame, I0, one must first determine the
decode time of the next frame, P1. Because P1 is a non-B frame, its
decode time is equal to the presentation time of I0, which is 3 time
units. Thus, the decode time of I0 must be at least one frame period
less than 3. In this example, the frame period is 1, because one
frame is displayed every time unit. Consequently, the decode time of
I0 is chosen as 2 time units. The decode time of the third frame in
the coded order, P4, is 4, because it must be equal to the
presentation time of the previous non-B frame in the coded order, P1.
On the other hand, the decode time of B-frame B2 is 5 time units,
which is identical to its presentation time.
If the decode time of a video frame differs from its presentation
time, then the decode time MUST be specified using the DTS Delta
field in the AU header. The syntax of the DTS Delta field is defined
in section 5.2.
Receivers are not required to use the DTS Delta field. However,
possible uses include buffer management and pacing of frames prior to
decoding. If RTP packets are lost, it is possible to use the DTS
Delta field to determine if the sequence of lost RTP packets
contained reference frames or only B-frames. This can be done by
comparing the decode and presentation times of the first frame
received after the lost sequence against the presentation time of the
last reference frame received prior to the lost sequence.
Knowing if the stream will contain B-pictures may help the receiver
allocate resources more efficiently and can reduce delay, as an
absence of B-pictures in the stream implies that no reordering of
frames will be needed between the decoding process and the display of
the decoded frames. This may be important for interactive
applications.
The receiver SHALL assume that the coded bit stream may contain
B-pictures in the following cases:
- Advanced profile:
If the value of the "bpic" media type parameter defined in section
6.1 is 1, or if the "bpic" parameter is not specified.
- Main profile:
If the MAXBFRAMES field in STRUCT_C decoder initialization
parameter has a non-zero value. STRUCT_C is conveyed in the
"config" media type parameter, which is defined in section 6.1.
Simple profile does not use B-pictures.
4.4. Random Access Points
The entry-point header contains information that is needed by the
decoder to decode the frames in that entry-point segment. This means
that in the event of lost RTP packets, the decoder may be unable to
decode frames until the next entry-point header is received.
The first frame after an entry-point header is a random access point
into the coded bit stream. Simple and Main profiles do not have
entry-point headers, so for those profiles, each I-picture is a
random access point.
To allow the RTP receiver to detect that an RTP packet that was lost
contained a random access point, this RTP payload format defines a
field called "RA Count". This field is present in every AU, and its
value is incremented (modulo 256) for every random access point. For
additional details, see the definition of "RA Count" in section 5.2.
To make it easy to determine if an AU contains a random access point,
this RTP payload format also defines a bit called the "RA" flag in
the AU Control field. This bit is set to 1 only on those AU’s that
contain a random access point. The RA bit is defined in section 5.3.
4.5. Removal of HRD Parameters
The sequence layer header of Advanced profile may include up to 31
leaky bucket parameter sets for the Hypothetical Reference Decoder
(HRD). Each leaky bucket parameter set specifies a possible peak
transmission bit rate (HRD_RATE) and a decoder buffer capacity
(HRD_BUFFER). See section 3.3 for additional discussion about the
HRD.
If the actual peak transmission rate is known by the RTP sender, the
RTP sender MAY remove all leaky bucket parameter sets except for the
one corresponding to the actual peak transmission rate.
For each leaky bucket parameter set in the sequence layer header,
there is also a parameter in the entry-point header that specifies
the initial fullness (HRD_FULL) of the leaky bucket.
If the RTP sender has removed any leaky bucket parameter sets from
the sequence layer header, then for any removed leaky bucket
parameter set, it MUST also remove the corresponding HRD_FULL
parameter in the entry-point header.
Removing leaky bucket parameter sets, as described above, may
significantly reduce the size of the sequence layer headers and the
entry-point headers.
4.6. Repeating the Sequence Layer Header
To improve robustness against loss of RTP packets, it is RECOMMENDED
that if the sequence layer header changes, it should be repeated
frequently in the bit stream. In this case, it is RECOMMENDED that
the number of leaky bucket parameters in the sequence layer header
and the entry-point headers be reduced to one, as described in
section 4.5. This will help reduce the overhead caused by repeating
the sequence layer header.
Any data in the VC-1 bit stream, including repeated copies of the
sequence header itself, must be accounted for when computing the
leaky bucket parameter for the HRD. See section 3.3 for a discussion
about the HRD.
If the value of TFCNTRFLAG in the sequence layer header is 1, each
picture header contains a frame counter field (TFCNTR). Each time
the sequence layer header is inserted in the bit stream, the value of
this counter MUST be reset.
To allow the RTP receiver to detect that an RTP packet that was lost
contained a new sequence layer header, the AU Control field defines a
bit called the "SL" flag. This bit is toggled when a sequence layer
header is transmitted, but only if that header is different from the
most recently transmitted sequence layer header. The SL bit is
defined in section 5.3.
4.7. Signaling of Media Type Parameters
When this RTP payload format is used with SDP, the decoder
initialization parameters described in section 3.3 MUST be signaled
in SDP using the media type parameters specified in section 6.1.
Section 6.2 specifies how to map the media type parameters to SDP
[5], section 6.3 defines rules specific to the SDP Offer/Answer
model, and section 6.4 defines rules for when SDP is used in a
declarative style.
When Simple or Main profiles are used, it is not possible to change
the decoder initialization parameters through the coded bit stream.
Any changes to the decoder initialization parameters would have to be
done through out-of-band means, e.g., by a SIP [14] re-invite or
similar means that convey an updated session description.
When Advanced profile is used, the decoder initialization parameters
MAY be changed by inserting a new sequence layer header or an entry-
point header in the coded bit stream.
The sequence layer header specifies the VC-1 level, the maximum size
of the coded frames and optionally also the maximum frame rate. The
media type parameters "level", "width", "height", and "framerate"
specify upper limits for these parameters. Thus, the sequence layer
header MAY specify values that are lower than the values of the media
type parameters "level", "width", "height", or "framerate", but the
sequence layer header MUST NOT exceed the values of any of these
media type parameters.
4.8. The "mode=1" Media Type Parameter
In certain applications using Advanced profile, the sequence layer
header never changes. This MAY be signaled with the media type
parameter "mode=1". (The "mode" parameter is defined in section
6.1.) The "mode=1" parameter serves as a "hint" to the RTP receiver
that all sequence layer headers in the bit stream will be identical.
If "mode=1" is signaled and a sequence layer header is present in the
coded bit stream, then it MUST be identical to the sequence layer
header specified by the "config" media type parameter.
Since the sequence layer header never changes in "mode=1", the RTP
sender MAY remove it from the bit stream. Note, however, that if the
value of TFCNTRFLAG in the sequence layer header is 1, each picture
header contains a frame counter field (TFCNTR). This field is reset
each time the sequence layer header occurs in the bit stream. If the
RTP sender chooses to remove the sequence layer header, then it MUST
ensure that the resulting bit stream is still compliant with the VC-1
specification (e.g., by adjusting the TFCNTR field, if necessary.)
4.9. The "mode=3" Media Type Parameter
In certain applications using Advanced profile, both the sequence
layer header and the entry-point header never change. This MAY be
signaled with the media type parameter "mode=3". The same rules
apply to "mode=3" as for "mode=1", described in section 4.8.
Additionally, if "mode=3" is signaled, then the RTP sender MAY
"compress" the coded bit stream by not including sequence layer
headers and entry-point headers in the RTP packets.
The RTP receiver MUST "decompress" the coded bit stream by
re-inserting the entry-point headers prior to delivering the coded
bit stream to the VC-1 decoder. The sequence layer header does not
need to be decompressed by the receiver, as it never changes.
If "mode=3" is signaled and the RTP receiver receives a complete AU
or the first fragment of an AU, and the RA bit is set to 1 but the AU
does not begin with an entry-point header, then this indicates that
the entry-point header has been "compressed". In that case, the RTP
receiver MUST insert an entry-point header at the beginning of the
AU. When inserting the entry-point header, the RTP receiver MUST use
the one that was specified by the "config" media type parameter.
5. RTP Payload Format Syntax
5.1. RTP Header Usage
The format of the RTP header is specified in RFC 3550 [3] and is
reprinted in Figure 3 for convenience.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. RTP header according to RFC 3550
The fields of the fixed RTP header have their usual meaning, which is
defined in RFC 3550 and by the RTP profile in use, with the following
additional notes:
Marker bit (M): 1 bit
This bit is set to 1 if the RTP packet contains an Access Unit
containing a complete VC-1 frame or the last fragment of a VC-1
frame.
Payload type (PT): 7 bits
This document does not assign an RTP payload type for this RTP
payload format. The assignment of a payload type has to be
performed either through the RTP profile used or in a dynamic
way.
Sequence Number: 16 bits
The RTP receiver can use the sequence number field to recover
the coded order of the VC-1 frames. A typical VC-1 decoder
will require the VC-1 frames to be delivered in coded order.
When VC-1 frames have been fragmented across RTP packets, the
RTP receiver can use the sequence number field to ensure that
no fragment is missing.
Timestamp: 32 bits
The RTP timestamp is set to the presentation time of the VC-1
frame in the first Access Unit. A clock rate of 90 kHz MUST be
used.
5.2. AU Header Syntax
The Access Unit header consists of a one-byte AU Control field, the
RA Count field, and 3 optional fields. All fields MUST be written in
network byte order. The structure of the AU header is illustrated in
Figure 4.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AU | RA | AUP | PTS | DTS |
|Control| Count | Len | Delta | Delta |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. Structure of AU header
AU Control: 8 bits
The usage of the AU Control field is defined in section 5.3.
RA Count: 8 bits
Random Access Point Counter. This field is a binary modulo 256
counter. The value of this field MUST be incremented by 1 each
time an AU is transmitted where the RA bit in the AU Control
field is set to 1. The initial value of this field is
undefined and MAY be chosen randomly.
AUP Len: 16 bits
Access Unit Payload Length. Specifies the size, in bytes, of
the payload of the Access Unit. The field does not include the
size of the AU header itself. The field MUST be included in
each AU header in an RTP packet, except for the last AU header
in the packet. If this field is not included, the payload of
the Access Unit SHALL be assumed to extend to the end of the
RTP payload.
PTS Delta: 32 bits
Presentation time delta. Specifies the presentation time of
the frame as a 2’s complement offset (delta) from the timestamp
field in the RTP header of this RTP packet. The PTS Delta
field MUST use the same clock rate as the timestamp field in
the RTP header.
This field SHOULD NOT be included in the first AU header in the
RTP packet, because the RTP timestamp field specifies the
presentation time of the frame in the first AU. If this field
is not included, the presentation time of the frame SHALL be
assumed to be specified by the timestamp field in the RTP
header.
DTS Delta: 32 bits
Decode time delta. Specifies the decode time of the frame as a
2’s complement offset (delta) between the presentation time and
the decode time. Note that if the presentation time is larger
than the decode time, this results in a value for the DTS Delta
field that is greater than zero. The DTS Delta field MUST use
the same clock rate as the timestamp field in the RTP header.
If this field is not included, the decode time of the frame
SHALL be assumed to be identical to the presentation time of
the frame.
5.3. AU Control Field Syntax
The structure of the 8-bit AU Control field is shown in Figure 5.
0 1 2 3 4 5 6 7
+----+----+----+----+----+----+----+----+
| FRAG | RA | SL | LP | PT | DT | R |
+----+----+----+----+----+----+----+----+
Figure 5. Syntax of AU Control field.
FRAG: 2 bits
Fragmentation Information. This field indicates if the AU
payload contains a complete frame or a fragment of a frame. It
MUST be set as follows:
0: The AU payload contains a fragment of a frame other than the
first or last fragment.
1: The AU payload contains the first fragment of a frame.
2: The AU payload contains the last fragment of a frame.
3: The AU payload contains a complete frame (not fragmented.)
RA: 1 bit
Random Access Point indicator. This bit MUST be set to 1 if
the AU contains a frame that is a random access point. In the
case of Simple and Main profiles, any I-picture is a random
access point.
In the case of Advanced profile, the first frame after an
entry-point header is a random access point.
If entry-point headers are not transmitted at every random
access point, this MUST be indicated using the media type
parameter "mode=3".
SL: 1 bit
Sequence Layer Counter. This bit MUST be toggled, i.e.,
changed from 0 to 1 or from 1 to 0, if the AU contains a
sequence layer header and if it is different from the most
recently transmitted sequence layer header. Otherwise, the
value of this bit must be identical to the value of the SL bit
in the previous AU.
The initial value of this bit is undefined and MAY be chosen
randomly.
The bit MUST be 0 for Simple and Main profile bit streams or if
the sequence layer header never changes.
LP: 1 bit
Length Present. This bit MUST be set to 1 if the AU header
includes the AUP Len field.
PT: 1 bit
PTS Delta Present. This bit MUST be set to 1 if the AU header
includes the PTS Delta field.
DT: 1 bit
DTS Delta Present. This bit MUST be set to 1 if the AU header
includes the DTS Delta field.
R: 1 bit
Reserved. This bit MUST be set to 0 and MUST be ignored by
receivers.
6. RTP Payload Format Parameters
6.1. Media type Registration
This registration uses the template defined in RFC 4288 [7] and
follows RFC 3555 [8].
Type name: video
Subtype name: vc1
Required parameters:
profile:
The value is an integer identifying the VC-1 profile. The
following values are defined:
0: Simple profile
1: Main profile
3: Advanced profile
If the profile parameter is used to indicate properties of a
coded bit stream, it indicates the VC-1 profile that a
decoder has to support when it decodes the bit stream.
If the profile parameter is used for capability exchange or
in a session setup procedure, it indicates the VC-1 profile
that the codec supports.
level:
The value is an integer that specifies the level of the VC-1
profile.
For Advanced profile, valid values are 0 through 4, which
correspond to levels L0 through L4, respectively. For
Simple and Main profiles, the following values are defined:
1: Low Level
2: Medium Level
3: High Level (only valid for Main profile)
If the level parameter is used to indicate properties of a
coded bit stream, it indicates the highest level of the VC-1
profile that a decoder has to support when it decodes the
bit stream. Note that support for a level implies support
for all numerically lower levels of the given profile.
If the level parameter is used for capability exchange or in
a session setup procedure, it indicates the highest level of
the VC-1 profile that the codec supports. See section 6.3