One document matched: draft-schierl-mmusic-layered-codec-02.txt
Differences from draft-schierl-mmusic-layered-codec-01.txt
MMUSIC Working Group T. Schierl
Internet Draft S. Wenger
Document: draft-schierl-mmusic-layered-codec-02
Expires: June 2007
December 2006
Signaling media decoding dependency
in Session Description Protocol (SDP)
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 28, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This memo defines semantics that allow for signaling the decoding
dependency of different media descriptions with the same media type in
the Session Description Protocol (SDP). This is required, for example,
if media data is separated and transported in different network streams
INTERNET-DRAFT draft-schierl-mmusic-layered-codec-02 December 2006
as a result of the use of a layered or multiple descriptive media coding
process.
A new grouping type "DDP" -- decoding dependency -- is defined, to be
used in conjunction with RFC 3388 entitled "Grouping of Media Lines in
the Session Description Protocol". In addition, an attribute is
specified describing the relationship of the media streams in a "DDP"
group.
Schierl Standards Track [page 2]
INTERNET-DRAFT draft-schierl-mmusic-layered-codec-02 December 2006
Table of Content
1. Introduction.................................................4
2. Terminology..................................................4
3. Definitions..................................................4
4. Motivation, Use Cases, and Architecture......................6
4.1. Motivation.................................................6
4.2. Use cases..................................................7
5. Signaling Media Dependencies.................................8
5.1. Design Principles..........................................8
5.2. Semantics..................................................8
5.2.1. SDP grouping semantics for decoding dependency............8
5.2.2. Attribute for dependency signaling per media-stream.......8
6. Usage of new semantics in SDP................................9
6.1.1. Usage with the SDP Offer/Answer Model.....................9
6.1.2. Declarative usage.........................................9
6.2. Examples..................................................10
7. Security Considerations.....................................11
8. IANA Consideration..........................................11
9. Acknowledgements............................................11
10. References..................................................11
10.1. Normative References......................................11
10.2. Informative References....................................12
11. Author's Addresses..........................................12
12. Intellectual Property Statement.............................12
13. Disclaimer of Validity......................................13
14. Copyright Statement.........................................13
15. RFC Editor Considerations...................................13
16. Change Log:.................................................13
Schierl Standards Track [page 3]
INTERNET-DRAFT draft-schierl-mmusic-layered-codec-02 December 2006
1. Introduction
An SDP session description may contain one or more media
descriptions, each identifying a single media stream. A media
description is identified by one "m=" line. Today, if more than one
"m=" lines exist that indicate the same media type, a receiver cannot
identify a specific relationship between those media.
A layered or Multiple Description Coded (MDC) Media Bitstream
contains, by definition, one or more Media Partitions that are
conveyed in their own media stream. The only case we are interested
in is a non-degraded layered/MDC Bitstream with two or more Media
Partitions. Carrying more than one Media Partition in its own
session is one of the key use cases for employing layered or MDC
coded media. Senders, network elements, or receivers can suppress
sending/forwarding/subscribing /decoding individual Media Partitions
and still preserve perhaps suboptimal, but useful media quality.
One property of all Media Bitstreams relevant to this memo is that
their Media Partitions have a well-defined usage relationship. For
example, in layered coding, "higher" Media Partitions are useless
without "lower" ones. In MDC coding, Media Partitions are
complementary -- the more Media Partitions one receives, the better
the reproduced quality gets. At present, SDP and its supporting
infrastructure of RFCs lack the means to express such a usage
relationship.
Trigger for the present memo has been the standardization process of
the RTP payload format for the Scalable Video Coding extension to
ITU-T Rec. H.264 / MPEG-4 AVC [SVCpayld]. When drafting [SVCpayld],
it was observed that the aforementioned lack in signaling support is
one that's not specific to SVC, but applies to all layered or MDC
codecs. Therefore, this memo presents a generic solution.
The mechanisms defined herein are media transport protocol
independent, i.e. applicable beyond the use of RTP [RFC3550].
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119].
3. Definitions
Media stream:
As per [RFC4466].
Schierl Standards Track [page 4]
INTERNET-DRAFT draft-schierl-mmusic-layered-codec-02 December 2006
Media Bitstream:
A valid, decodable stream, containing ALL media partitions generated
by the encoder. An Media Bitstream normally conforms to a media
coding standard.
Media Partition:
A subset of a Media Bitstream indented for independent
transportation. An integer number of Media Partitions form a Media
Bitstream. In layered coding, a Media Partition represents one or
more layers, that are handled as one unit. In MDC coding, a Media
Partition represents one or more descriptions that are handled as a
unit.
Decoding dependency:
The class of relationships media partitions have to each other. At
present, this memo defines two decoding dependencies: layering and
multiple description.
Layered/hierarchical coding dependency:
Each Media Partition is only useful (i.e. can be decoded) when ALL of
the Media Partitions it depends on are available. The dependencies
between the Media Partitions create a directed graph. Note:
normally, in layered/hierarchical coding, the more Media Partitions
are employed (following the rule above), the better a reproduced
quality is possible.
Multi description coding (MDC) dependency:
N of M Media Partitions are required to form a Media Bitstream, but
there is no hierarchy between these Media Partitions. Most MDC
schemes aim at an increase of reproduced media quality when more
media partitions are decoded than are necessarily required to form an
Operation Point.
Operation point:
In layered coding, a subset of a layered Media Bitstream that
includes all Media Partitions required for reconstruction at a
certain point of quality or error resilience, and does not include
any other Media Partitions. In MDC coding, a subset of a MDC Media
Bitstream that is compliant with the MDC coding standard in question.
The following terms are included for clarification on RTP [RFC3550]
multiplexing techniques. Further discussion can be found in section
5.2 of [RFC3550].
Session multiplexing: The Media Bitstream is distributed onto
different RTP sessions, whereby each RTP session carries one RTP
packet stream with one or more Media Partitions of the Media
Bitstream. Each RTP session requires a separate signaling and has a
Schierl Standards Track [page 5]
INTERNET-DRAFT draft-schierl-mmusic-layered-codec-02 December 2006
separate Timestamp, Sequence Number, and SSRC space. Dependency
between sessions MUST be signaled according to this memo.
4. Motivation, Use Cases, and Architecture
4.1. Motivation
Two types of dependencies are discussed in the following in more
detail: layered or hierarchical decoding dependency, and multi-
description decoding dependency. The transport of
layered/hierarchical and multi description coding share as key
motivators the desire for media adaptation to network conditions,
i.e. related to bandwidth, error rates, connectivity of endpoints in
multicast or broadcast scenarios, and similar.
o Layered/hierarchical decoding dependency:
In layered coding, the partitions of a Media Bitstream are known as
media layers or simply layers. One or more layers may be transported
in different network streams. A classic use case is known as
receiver-driven layered multicast, in which a receiver selects a
combination of media streams in response to quality or bit-rate
requirements.
Back in the mid 1990s, the then available layered media formats and
codecs envisioned primarily (or even exclusively) a one-dimensional
hierarchy of layers. That is, each so-called enhancement layer
referred to exactly one layer "below". The single exception has been
the base layer, which is self-contained. Therefore, the
identification of one enhancement layer fully specifies the operation
point of a layered decoding scheme, including knowledge about all the
other layers that need to be decoded.
[RFC4466] contains rudimentary support for exactly this use case and
media formats, in that it allows for signaling a range of transport
addresses for a certain media description. By definition, a higher
transport address identifies a higher layer in the one-dimensional
hierarchy. A receiver needs only to decode data conveyed over this
transport address and lower transport addresses to decode this
Operation Point.
Newer media formats depart from this simple one-dimensional
hierarchy, in that highly complex (at least tree-shaped) dependency
hierarchies can be implemented. Compelling use cases for these
complex hierarchies have been identified by industry. Support for it
is therefore desirable. However, SDP in its current form does not
allow for the signaling of these complex relationships. Therefore,
receivers cannot make an informed decision on which layers to
subscribe (in case of layered multicast).
Schierl Standards Track [page 6]
INTERNET-DRAFT draft-schierl-mmusic-layered-codec-02 December 2006
o Multi descriptive decoding dependency:
In the most basic form of multiple description coding (MDC), each
partition forms an independent representation of the media. That is,
decoding of any of the Media Partition yields useful reproduced media
data. When more than one Media Partition is available, then a
decoder can process them jointly, and the resulting media quality
increases. The highest reproduced quality is available if all
original Media Partitions are available for decoding.
More complex forms of multiple description coding can also be
envisioned, i.e. where, as a minimum, N out of M total Media
Partitions need to be available to allow meaningful decoding.
MDC has not yet been embraced heavily by the media standardization
community, though it is subject of a lot of academic research. As an
example, we refer to [MDC].
We cover MDC in this memo because we a) envision that MDC media
formats will come into the picture within the lifetime of this memo,
and b) the solution for its signaling is very similar to the one of
layered coding.
4.2. Use cases
o Receiver driven layered multicast
This technology is discussed in [RFC3550] and references therein. We
refrain from elaborating further; the subject is well known and
understood.
o Multiple end-to-end transmission with different properties
Assume a unicast and point-to-point topology, wherein one endpoint
sends media to another. Assume further that different forms of media
transmission are available. The difference may lie in the cost of
the transmission (free, charged), in the available protection
(unprotected/secure), in the quality of service (guaranteed quality /
best effort), or other factors.
Layered and MDC coding allow to match the media characteristics to
the available transmission path(s). For example, in layered coding
it makes sense to convey the base layer over high QoS and/or over an
encrypted transmission path. Enhancement layers, on the other hand,
can be conveyed over best effort, as they are "optional" in their
characteristic -- nice to have, but non-essential for media
consumption. Similarly, while it is essential that the base layer is
encrypted, there is (at least conceptually) a lesser need to encrypt
the enhancement layer, as the enhancement layer is less important and
useful without the (encrypted) base layer in terms of resulting video
Schierl Standards Track [page 7]
INTERNET-DRAFT draft-schierl-mmusic-layered-codec-02 December 2006
quality. (This, of course depends highly on the media coding
technology involved -- if the enhancement layer has some value in its
own right, then it perhaps needs as strong encryption as the base
layer.) In a different scenario, the base layer may be offered in a
non-encrypted session as a free preview. An encrypted enhancement
layer references this base layer and allows optimal quality play-
back; however, it is only accessible to users who have the key, which
may have been distributed by a conditional access mechanism.
5. Signaling Media Dependencies
5.1. Design Principles
The dependency signaling is only feasible between media descriptions
described with an "m="-line and with an assigned media identification
attribute ("mid"), as defined in RFC3388.
5.2. Semantics
5.2.1. SDP grouping semantics for decoding dependency
This specification defines the new grouping semantics
Decoding Dependency "DDP":
DDP associates a media stream, identified by its mid attribute, with
a DDP group. Each media stream MUST be composed of an integer number
of Media Partitions. All media streams of a DDP group MUST have the
same type of coding dependency (as signaled by attribute defined in
5.2.2) and MUST belong to one media bitstream. All media streams
MUST contain at least one operation point. The DDP group type
informs a receiver about the requirement for treating the media
streams of the group according to the new media level attribute
"depend", as defined in 5.2.2.
5.2.2. Attribute for dependency signaling per media-stream
This memo defines a new media-level value attribute, "depend", with
the following BNF [RFC2234]. The "identification-tag" (if used) is
defined in [RFC3388]:
depend-attribute = "a=depend:" dependency-type-tag
*(space identification-tag)
dependency-type-tag = dependency
dependency = "lay" / "mdc"
The "depend"-attribute describes the decoding dependency. The
"depend"-attribute may be followed by a sequence of identification-
tag(s) which identify all related media streams. The attribute MAY
Schierl Standards Track [page 8]
INTERNET-DRAFT draft-schierl-mmusic-layered-codec-02 December 2006
be used with multicast as well as with unicast transport addresses.
The following types of dependencies are defined:
o lay: Layered decoding dependency -- identifies the described media
stream as one or more partitions of a layered media bitstream. When
lay is used, all media streams MUST be identified by the following
identification-tag(s) that are required for a successful use of the
media stream. The identification-tag(s) MUST be present when lay is
in use. Further the described media stream represents one operation
point of the layered media bitstream. As a result, all other media
streams belonging to the same dependency group, but not identified by
an identification-tag in the media description, are not required for
a successful reproduction of the operation point represented by the
media stream in question. Hence, a media sender MAY omit sending
them when that is advantageous from a scalability or transport
viewpoint.
o mdc: Multi descriptive decoding dependency -- signals that the
described media stream is or one more partitions of a multi
description coding (MDC) media bitstream. By definition, at least N
out of M streams of the group MUST be received for allowing decoding
the media, whereby N and M are media stream dependent and not
signaled. Receiving more than one media stream of the group may
enhance the decodable quality of the media bitstream. This type of
dependency does not require the signaling of the depended media
streams.
6. Usage of new semantics in SDP
6.1.1. Usage with the SDP Offer/Answer Model
If an Answerer does not understand the decoding dependency signaling,
it should be able to detect the 'base' media only for a layered media
session or should be able to detect only one partition of MDC media
session. That is, the session description SHOULD offer a backward
compatible partition of the media stream with a separate media
description. This media description MAY point to the same transport
address as used for an extended media session description using the
features defined in this memo. Following this reasoning, an Answerer
can obtain minimum service quality (by decoding the base layer or a
single description) even when it does not understand the mechanisms
of this memo.
Edt. note: need more text here.
6.1.2. Declarative usage
Edt. note: To be written
Schierl Standards Track [page 9]
INTERNET-DRAFT draft-schierl-mmusic-layered-codec-02 December 2006
6.2. Examples
a.) Example for signaling transport of operation points of a layered
video bitstream in different network streams:
v=0
o=svcsrv 289083124 289083124 IN IP4 host.example.com
s=LAYERED VIDEO SIGNALING Seminar
t=0 0
c=IN IP4 224.2.17.12/127
a=group:DDP 1 2 3 4
m=video 40000 RTP/AVP 94
b=AS:96
a=framerate:15
a=rtpmap:94 h264/90000
a=mid:1
m=video 40002 RTP/AVP 95
b=AS:64
a=framerate:15
a=rtpmap:95 svc1/90000
a=mid:2
a=depend:lay 1
m=video 40004 RTP/AVP 96
b=AS:128
a=framerate:30
a=rtpmap:96 svc1/90000
a=mid:3
a=depend:lay 1
m=video 40004 RTP/SAVP 100
c=IN IP4 224.2.17.13/127
b=AS:512
k=uri:conditional-access-server.example.com
a=framerate:30
a=rtpmap:100 svc1/90000
a=mid:4
a=depend:lay 1 3
b.) Example for signaling transport of streams of a multi
description (MDC) video bitstream in different network streams:
v=0
o=mdcsrv 289083124 289083124 IN IP4 host.example.com
s=MULTI DESCRIPTION VIDEO SIGNALING Seminar
Schierl Standards Track [page 10]
INTERNET-DRAFT draft-schierl-mmusic-layered-codec-02 December 2006
t=0 0
c=IN IP4 224.2.17.12/127
a=group:DDP 1 2 3
m=video 40000 RTP/AVP 94
a=mid:1
a=depend:mdc
m=video 40002 RTP/AVP 95
a=mid:2
a=depend:mdc
m=video 40004 RTP/AVP 96
c=IN IP4 224.2.17.13/127
a=mid:3
a=depend:mdc
7. Security Considerations
8. IANA Consideration
9. Acknowledgements
Funding for the RFC Editor function is currently provided by the
Internet Society. Further, the author Thomas Schierl of Fraunhofer
HHI is sponsored by the European Commission under the contract number
FP6-IST-0028097, project ASTRALS.
10. References
10.1. Normative References
[RFC4466] Handley, M., Jacobson, V, and C. Perkins, "SDP: Session
Description Protocol", IETF work in progress, July
2006.
[RFC3388] Camarillo, G., Holler, J., and H. Schulzrinne, "Grouping of
Media Lines in the Session Description Protocol (SDP)",
RFC 3388, December 2002.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997
Schierl Standards Track [page 11]
INTERNET-DRAFT draft-schierl-mmusic-layered-codec-02 December 2006
10.2. Informative References
[SVCpayld] Wenger,S., Wang, Y.-K., and T. Schierl, "RTP Payload Format
for SVC Video", "draft-ietf-avt-rtp-svc-00.txt",
December 2006
[MDC] Vitali, A., Borneo, A., Fumagalli, M., and R. Rinaldo,
"Video over IP using Standard-Compatible Multiple
Description Coding: an IETF proposal", Packet Video
Workshop, April 2006, Hangzhou, China
11. Author's Addresses
Thomas Schierl Phone: +49-30-31002-227
Fraunhofer HHI Email: schierl@hhi.fhg.de
Einsteinufer 37
D-10587 Berlin
Germany
Stephan Wenger Phone: +358-50-486-0637
Nokia Research Center Email: stewe@stewe.org
P.O. Box 100
FIN-33721 Tampere
Finland
12. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Schierl Standards Track [page 12]
INTERNET-DRAFT draft-schierl-mmusic-layered-codec-02 December 2006
13. Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
14. Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
15. RFC Editor Considerations
none
16. Change Log:
19Dec06 / TS:
removed SSRC multiplexing and with that various information about RTP
draft title correction
corrected SDP reference
editorial modifications throughout the document
added Stephan Wenger to the list of authors
removed section "network elements not supporting dependency
singaling"
20-28Dec06 / TS, StW: Editorial improvements
Schierl Standards Track [page 13]
| PAFTECH AB 2003-2026 | 2026-04-22 21:51:47 |