As per Relevance of the word specific, we have this rfc below:











Network Working Group K.
Request for Comments: 3189 Communication Research
Category: Standards Track A.
Keio
S.
Packet
C.
Universitaet Bremen
January 2002


RTP Payload Format for DV (IEC 61834)

Status of this

This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited

Copyright

Copyright (C) The Internet Society (2002). All Rights Reserved



This document specifies the packetization scheme for
the compressed digital video data streams commonly known as "DV"
a payload format for the Real-Time Transport Protocol (RTP).

1.

This document specifies payload formats for encapsulating
consumer- and professional-use DV format data streams into the Real
time Transport Protocol (RTP), version 2 [6]. DV compression
and video formats were designed for helical-scan magnetic tape media
The DV standards for consumer-market devices, the IEC 61883 and 61834
series, cover many aspects of consumer-use digital video,
mechanical specifications of a cassette, magnetic recording format
error correction on the magnetic tape, DCT video encoding format,
audio encoding format [1]. The digital interface part of IEC 61883
defines an interface on an IEEE 1394 network [2,3].
specification set supports several video formats: SD-VCR (
Definition), HD-VCR (High Definition), SDL-VCR (Standard Definition -
Long), PALPlus, DVB (Digital Video Broadcast) and ATV (
Television). North American formats are indicated with a number
lines and "/60", while European formats use "/50". DV



Kobayashi, et al. Standards Track [Page 1]

RFC 3189 RTP Payload Format for DV (IEC 61834) Video January 2002


extended for professional use were published by SMPTE as 306M
314M, for different sampling systems, higher color resolution,
faster bit rates [4,5].

There are two kinds of DV, one for consumer use and the other
professional. The original "DV" specification designed
consumer-use digital VCRs is approved as the IEC 61834 standard set
The specifications for professional DV are published as SMPTE 306
and 314M. Both encoding formats are based on consumer DV and used
SMPTE D-7 and D-9 video systems. The RTP payload format specified
this document supports IEC 61834 consumer DV and professional
306M and 314M (DV-Based) formats

IEC 61834 also includes magnetic tape recording for digital
broadcasting systems (such as DVB and ATV) that use MPEG2 encoding
The payload format for encapsulating MPEG2 into RTP has already
defined in RFC 2250 [7] and others

Consequently, the payload specified in this document will support
video formats of the IEC standard: SD-VCR (525/60, 625/50), HD-
(1125/60, 1250/50) and SDL-VCR (525/60, 625/50), and six of the
standards: 306M (525/60, 625/50), 314M 25Mbps (525/60, 625/50)
314M 50Mbps (525/60, 625/50). In the future it can be extended
other high-definition formats

Throughout this specification, we make extensive use of
terminology of IEC and SMPTE standards. The reader should
the original references for definitions of these terms

1.1

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119 [8].

2. DV format

The DV format only uses the DCT compression technique within
frame, contrasted with the interframe compression of the MPEG
standards [9,10]. All video data, including audio and other
data, are managed within the picture frame unit of video

The DV video encoding is composed of a three-level
structure. A picture frame is divided into rectangle- or clipped
rectangle-shaped DCT super blocks. DCT super blocks are divided
27 rectangle- or square-shaped DCT macro blocks





Kobayashi, et al. Standards Track [Page 2]

RFC 3189 RTP Payload Format for DV (IEC 61834) Video January 2002


Audio data is encoded with PCM format. The sampling frequency is 32
kHz, 44.1 kHz or 48 kHz and the quantization is 12-bit non-linear
16-bit linear or 20-bit linear. The number of channels may be up
8. Only certain combinations of these parameters are
depending upon the video format; the restrictions are specified
each document

A frame of data in the DV format stream is divided into several "
sequences". A DIF sequence is composed of an integral number of 80-
byte DIF blocks. A DIF block is the primitive unit for all
of DV streams. Each DIF block contains a 3-byte ID header
specifies the type of the DIF block and its position in the
sequence. Five types of DIF blocks are defined: DIF sequence header
Subcode, Video Auxiliary information (VAUX), Audio, and Video.
DIF blocks are composed of 5 bytes of Audio Auxiliary data (AAUX)
72 bytes of audio data

Each RTP packet starts with the RTP header as defined in RFC 1889
[6]. No additional payload-format-specific header is required
this payload format

2.1 RTP header

The RTP header fields that have a meaning specific to the DV
are described as follows

Payload type (PT): The payload type is dynamically assigned by
outside the scope of this document. If multiple DV encoding
are to be used within one RTP session, then multiple dynamic
types MUST be assigned, one for each DV encoding format. The
MUST change to the corresponding payload type whenever the
format is changed

Timestamp: 32-bit 90 kHz timestamp representing the time at which
first data in the frame was sampled. All RTP packets within the
video frame MUST have the same timestamp. The timestamp
increment by a multiple of the nominal interval for one frame time
as given in the following table

Mode Frame rate (Hz) Increase of one
in 90kHz

525-60 29.97 3003
625-50 25 3600
1125-60 30 3000
1250-50 25 3600





Kobayashi, et al. Standards Track [Page 3]

RFC 3189 RTP Payload Format for DV (IEC 61834) Video January 2002


When the DV stream is obtained from an IEEE 1394 interface,
progress of video frame times MAY be monitored using the
timestamp carried in the CIP header as specified in IEC 61883 [2].

Marker bit (M): The marker bit of the RTP fixed header is set to
on the last packet of a video frame, and otherwise, must be zero
The M bit allows the receiver to know that it has received the
packet of a frame so it can display the image without waiting for
first packet of the next frame to arrive to detect the frame change
However, detection of a frame change MUST NOT rely on the marker
since the last packet of the frame might be lost. Detection of
frame change MUST be based on a difference in the RTP timestamp

2.2 DV data encapsulation into RTP

Integral DIF blocks are placed into the RTP payload
immediately after the RTP header. Any number of DIF blocks may
packed into one RTP packet, except that all DIF blocks in one
packet must be from the same video frame. DIF blocks from the
video frame MUST NOT be packed into the same RTP packet even if
payload space remains. This requirement stems from the fact that
transition from one video frame to the next is indicated by a
in the RTP timestamp. It also reduces the processing complexity
the receiver. Since the RTP payload contains an integral number
DIF blocks, the length of the RTP payload will be a multiple of 80
bytes

Audio and video data may be transmitted as one bundled RTP stream
in separate RTP streams (unbundled). The choice MUST be indicated
part of the assignment of the dynamic payload type and MUST
unchanged for the duration of the RTP session to avoid
procedures of sequence number synchronization. The RTP sender
omit DIF-sequence header and subcode DIF blocks from a stream
the information is either known out-of-band or may not be
for RTP transport. When sending DIF-sequence header and subcode
blocks, both types of blocks MUST be included in the video stream

DV streams include "source" and "source control" packs that
information indispensable for proper decoding, such as aspect ratio
picture position, quantization of audio sampling, number of
channels, audio channel assignment, and language of the audio
However, describing all of these attributes with a signaling
would require large descriptions to enumerate all the combinations
Therefore, no Session Description Protocol (SDP) [13] parameters
these attributes are defined in this document. Instead, the
sender MUST transmit at least those VAUX DIF blocks and/or audio
blocks with AAUX information bytes that include "source" and "
control" packs containing the indispensable information for decoding



Kobayashi, et al. Standards Track [Page 4]

RFC 3189 RTP Payload Format for DV (IEC 61834) Video January 2002


In the case of one bundled stream, DIF blocks for both audio
video are packed into RTP packets in the same order as they
encoded

In the case of an unbundled stream, only the header, subcode,
and VAUX DIF blocks are sent within the video stream. Audio is
in a different stream if desired, using a different RTP payload type
It is also possible to send audio duplicated in a separate stream,
addition to bundling it in with the video stream

When using unbundled mode, it is RECOMMENDED that the audio
data be extracted from the DIF blocks and repackaged into
corresponding RTP payload format for the audio encoding (DAT12, L16,
L20) [11,12] in order to maximize interoperability with non-DV
capable receivers while maintaining the original source quality

In the case of unbundled transmission where both audio and video
sent in the DV format, the same timestamp SHOULD be used for
audio and video data within the same frame to simplify the
synchronization effort on the receiver. Lip synchronization may
be achieved using reference timestamps passed in RTCP as described
RFC 1889 [6].

The sender MAY reduce the video frame rate by discarding the
data and VAUX DIF blocks for some of the video frames. The
timestamp must still be incremented to account for the
frames. The sender MAY alternatively reduce bandwidth by
video data DIF blocks for portions of the image which are
from the previous image. To enable this bandwidth reduction
receivers SHOULD implement an error concealment strategy
accommodate lost or missing DIF blocks, e.g., repeating
corresponding DIF block from the previous image

3. SDP Signaling for RTP/

When using SDP (Session Description Protocol) [13] for negotiation
the RTP payload information, the format described in this
SHOULD be used. SDP descriptions will be slightly different for
bundled stream and an unbundled stream

When a DV stream is sent to port 31394 using RTP payload
identifier 111, the m=?? line will be like

m=video 31394 RTP/AVP 111

The a=rtpmap attribute will be like

a=rtpmap:111 DV/90000



Kobayashi, et al. Standards Track [Page 5]

RFC 3189 RTP Payload Format for DV (IEC 61834) Video January 2002


"DV" is the encoding name for the DV video payload format defined
this document. The "90000" specifies the RTP timestamp clock rate
which for the payload format defined in this document is a 90
clock

In SDP, format-specific parameters are defined as a=fmtp, as below

a=fmtp: specific parameters

In the DV video payload format, the a=fmtp line will be used to
the encoding type within the DV video and will be used as below

a=fmtp: encode=encoding

The required parameter encoding> specifies which type of
format is used. The DV format name will be one of the following

SD-VCR/525-60
SD-VCR/625-50
HD-VCR/1125-60
HD-VCR/1250-50
SDL-VCR/525-60
SDL-VCR/625-50
306M/525-60
306M/625-50
314M-25/525-60
314M-25/625-50
314M-50/525-60
314M-50/625-50

In order to show whether the audio data is bundled into the DV
or not, a format specific parameter is defined as below

a=fmtp: audio=




if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.




RFC documents can be found at I.E.T.F.



Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX







Spectrum