draft-ietf-rtcweb-video-05.txt		draft-ietf-rtcweb-video-06.txt
	Network Working Group A.B. Roach		Network Working Group A.B. Roach
	Internet-Draft Mozilla		Internet-Draft Mozilla
	Intended status: Standards Track March 17, 2015		Intended status: Standards Track June 12, 2015
	Expires: September 18, 2015		Expires: December 14, 2015
	WebRTC Video Processing and Codec Requirements		WebRTC Video Processing and Codec Requirements
	draft-ietf-rtcweb-video-05		draft-ietf-rtcweb-video-06
	Abstract		Abstract
	This specification provides the requirements and considerations for		This specification provides the requirements and considerations for
	WebRTC applications to send and receive video across a network. It		WebRTC applications to send and receive video across a network. It
	specifies the video processing that is required, as well as video		specifies the video processing that is required, as well as video
	codecs and their parameters.		codecs and their parameters.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 33		skipping to change at page 1, line 33
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on September 18, 2015.		This Internet-Draft will expire on December 14, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 12		skipping to change at page 2, line 12
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
	3. Pre and Post Processing . . . . . . . . . . . . . . . . . . . 2		3. Pre and Post Processing . . . . . . . . . . . . . . . . . . . 2
	3.1. Camera Source Video . . . . . . . . . . . . . . . . . . . 3		3.1. Camera Source Video . . . . . . . . . . . . . . . . . . . 3
	3.2. Screen Source Video . . . . . . . . . . . . . . . . . . . 3		3.2. Screen Source Video . . . . . . . . . . . . . . . . . . . 3
	4. Stream Orientation . . . . . . . . . . . . . . . . . . . . . 3		4. Stream Orientation . . . . . . . . . . . . . . . . . . . . . 4
	5. Mandatory to Implement Video Codec . . . . . . . . . . . . . 4		5. Mandatory to Implement Video Codec . . . . . . . . . . . . . 4
	6. Codec-Specific Considerations . . . . . . . . . . . . . . . . 5		6. Codec-Specific Considerations . . . . . . . . . . . . . . . . 5
	6.1. VP8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		6.1. VP8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	6.2. H.264 . . . . . . . . . . . . . . . . . . . . . . . . . . 6		6.2. H.264 . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 7		7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	10.1. Normative References . . . . . . . . . . . . . . . . . . 7		10.1. Normative References . . . . . . . . . . . . . . . . . . 7
	10.2. Informative References . . . . . . . . . . . . . . . . . 8		10.2. Informative References . . . . . . . . . . . . . . . . . 8
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	One of the major functions of WebRTC endpoints is the ability to send		One of the major functions of WebRTC endpoints is the ability to send
	and receive interactive video. The video might come from a camera, a		and receive interactive video. The video might come from a camera, a
	screen recording, a stored file, or some other source. This		screen recording, a stored file, or some other source. This
	specification defines how the video is used and discusses special		specification provides the requirements and considerations for WebRTC
	considerations for processing the video. It also covers the video-		applications to send and receive video across a network. It
	related algorithms WebRTC devices need to support.		specifies the video processing that is required, as well as video
			codecs and their parameters.
	Note that this document only discusses those issues dealing with		Note that this document only discusses those issues dealing with
	video codec handling. Issues that are related to transport of media		video codec handling. Issues that are related to transport of media
	streams across the network are specified in		streams across the network are specified in
	[I-D.ietf-rtcweb-rtp-usage].		[I-D.ietf-rtcweb-rtp-usage].
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	3. Pre and Post Processing		3. Pre and Post Processing
	This section provides guidance on pre- or post-processing of video		This section provides guidance on pre- and post-processing of video
	streams.		streams.
	Unless specified otherwise by the SDP or codec, the color space		Unless specified otherwise by the SDP or codec, the color space
	SHOULD be sRGB [SRGB]. For clarity, this the color space indicated		SHOULD be sRGB [SRGB]. For clarity, this is the color space
	by codepoint 1 from "ColourPrimaries" as defined in [IEC23001-8].		indicated by codepoint 1 from "ColourPrimaries" as defined in
			[IEC23001-8].
	Unless specified otherwise by the SDP or codec, the video scan		Unless specified otherwise by the SDP or codec, the video scan
	pattern for video codecs is Y'CbCr 4:2:0.		pattern for video codecs is Y'CbCr 4:2:0.
	3.1. Camera Source Video		3.1. Camera Source Video
	This document imposes no normative requirements on camera capture;		This document imposes no normative requirements on camera capture;
	however, implementors are encouraged to take advantage of the		however, implementors are encouraged to take advantage of the
	following features, if feasible for their platform:		following features, if feasible for their platform:
	skipping to change at page 4, line 48		skipping to change at page 4, line 51
	"WebRTC-Compatible Endpoint" as they are used in this section, please		"WebRTC-Compatible Endpoint" as they are used in this section, please
	refer to [I-D.ietf-rtcweb-overview].		refer to [I-D.ietf-rtcweb-overview].
	WebRTC Browsers MUST implement the VP8 video codec as described in		WebRTC Browsers MUST implement the VP8 video codec as described in
	[RFC6386] and H.264 Constrained Baseline as described in [H264].		[RFC6386] and H.264 Constrained Baseline as described in [H264].
	WebRTC Non-Browsers that support transmitting and/or receiving video		WebRTC Non-Browsers that support transmitting and/or receiving video
	MUST implement the VP8 video codec as described in [RFC6386] and		MUST implement the VP8 video codec as described in [RFC6386] and
	H.264 Constrained Baseline as described in [H264].		H.264 Constrained Baseline as described in [H264].
	To promote the use of non-royalty bearing video codecs,		NOTE: To promote the use of non-royalty bearing video codecs,
	participants in the RTCWEB working group, and any successor		participants in the RTCWEB working group, and any successor
	working groups in the IETF, intend to monitor the evolving		working groups in the IETF, intend to monitor the evolving
	licensing landscape as it pertains to the two mandatory-to-		licensing landscape as it pertains to the two mandatory-to-
	implement codecs. If compelling evidence arises that one of the		implement codecs. If compelling evidence arises that one of the
	codecs is available for use on a royalty-free basis, the working		codecs is available for use on a royalty-free basis, the working
	group plans to revisit the question of which codecs are required		group plans to revisit the question of which codecs are required
	for Non-Browsers, with the intention being that the royalty-free		for Non-Browsers, with the intention being that the royalty-free
	codec will remain mandatory to implement, and the other will		codec will remain mandatory to implement, and the other will
	become optional.		become optional.
	skipping to change at page 5, line 36		skipping to change at page 5, line 38
	this attribute by limiting the encoded resolution to the indicated		this attribute by limiting the encoded resolution to the indicated
	maximum size, as the receiver may not be capable of handling higher		maximum size, as the receiver may not be capable of handling higher
	resolutions.		resolutions.
	Additionally, codecs may include codec-specific means of signaling		Additionally, codecs may include codec-specific means of signaling
	maximum receiver abilities with regards to resolution, frame rate,		maximum receiver abilities with regards to resolution, frame rate,
	and bitrate.		and bitrate.
	Unless otherwise signaled in SDP, recipients of video streams MUST be		Unless otherwise signaled in SDP, recipients of video streams MUST be
	able to decode video at a rate of at least 20 fps at a resolution of		able to decode video at a rate of at least 20 fps at a resolution of
	at least 320x240. These values are selected based on the		at least 320 pixels by 240 pixels. These values are selected based
	recommendations in [HSUP1].		on the recommendations in [HSUP1].
	Encoders are encouraged to support encoding media with at least the		Encoders are encouraged to support encoding media with at least the
	same resolution and frame rates cited above.		same resolution and frame rates cited above.
	6.1. VP8		6.1. VP8
	For the VP8 codec, defined in [RFC6386], endpoints MUST support the		For the VP8 codec, defined in [RFC6386], endpoints MUST support the
	payload formats defined in [I-D.ietf-payload-vp8].		payload formats defined in [I-D.ietf-payload-vp8].
	In addition to the [RFC6236] mechanism, VP8 encoders MUST limit the		In addition to the [RFC6236] mechanism, VP8 encoders MUST limit the
	streams they send to conform to the values indicated by receivers in		streams they send to conform to the values indicated by receivers in
	the corresponding max-fr and max-fs SDP attributes.		the corresponding max-fr and max-fs SDP attributes.
			Unless otherwise signaled, implementations that use VP8 MUST encode
			and decode pixels with a implied 1:1 (square) aspect ratio.
	6.2. H.264		6.2. H.264
	For the [H264] codec, endpoints MUST support the payload formats		For the [H264] codec, endpoints MUST support the payload formats
	defined in [RFC6184]. In addition, they MUST support Constrained		defined in [RFC6184]. In addition, they MUST support Constrained
	Baseline Profile Level 1.2, and they SHOULD support H.264 Constrained		Baseline Profile Level 1.2, and they SHOULD support H.264 Constrained
	High Profile Level 1.3.		High Profile Level 1.3.
	Implementations of the H.264 codec have utilized a wide variety of		Implementations of the H.264 codec have utilized a wide variety of
	optional parameters. To improve interoperability the following		optional parameters. To improve interoperability the following
	parameter settings are specified:		parameter settings are specified:
	skipping to change at page 7, line 11		skipping to change at page 7, line 13
	ITU-T T.35" and "User data unregistered" messages. Even if they do		ITU-T T.35" and "User data unregistered" messages. Even if they do
	not act on them, implementations MUST be prepared to receive such		not act on them, implementations MUST be prepared to receive such
	messages without any ill effects.		messages without any ill effects.
	Unless otherwise signaled, implementations that use H.264 MUST encode		Unless otherwise signaled, implementations that use H.264 MUST encode
	and decode pixels with a implied 1:1 (square) aspect ratio.		and decode pixels with a implied 1:1 (square) aspect ratio.
	7. Security Considerations		7. Security Considerations
	This specification does not introduce any new mechanisms or security		This specification does not introduce any new mechanisms or security
	concerns beyond what the other documents it references. In WebRTC,		concerns beyond what is in the other documents it references. In
	video is protected using DTLS/SRTP. A complete discussion of the		WebRTC, video is protected using DTLS/SRTP. A complete discussion of
	security can be found in [I-D.ietf-rtcweb-security] and		the security considerations can be found in
	[I-D.ietf-rtcweb-security-arch]. Implementors should consider		[I-D.ietf-rtcweb-security] and [I-D.ietf-rtcweb-security-arch].
	whether the use of variable bit rate video codecs are appropriate for		Implementors should consider whether the use of variable bit rate
	their application, keeping in mind that the degree of inter-frame		video codecs are appropriate for their application, keeping in mind
	change (and, by inference, the amount of motion in the frame) may be		that the degree of inter-frame change (and, by inference, the amount
	deduced by an eavesdropper based on the video stream's bit rate.		of motion in the frame) may be deduced by an eavesdropper based on
			the video stream's bit rate.
	Implementors making use of H.264 are also advised to take careful		Implementors making use of H.264 are also advised to take careful
	note of the "Security Considerations" section of [RFC6184], paying		note of the "Security Considerations" section of [RFC6184], paying
	special regard to the normative requirement pertaining to SEI		special regard to the normative requirement pertaining to SEI
	messages.		messages.
	8. IANA Considerations		8. IANA Considerations
	This document requires no actions from IANA.		This document requires no actions from IANA.
	9. Acknowledgements		9. Acknowledgements
	The author would like to thank Gaelle Martin-Cocher, Stephan Wenger,		The author would like to thank Gaelle Martin-Cocher, Stephan Wenger,
	and Bernard Aboba for their detailed feedback and assistance with		and Bernard Aboba for their detailed feedback and assistance with
	this document. Thanks to Cullen Jennings for providing text and		this document. Thanks to Cullen Jennings for providing text and
	review. This draft includes text from draft-cbran-rtcweb-codec.		review, and to Russ Housley for a careful final review. This draft
			includes text from draft-cbran-rtcweb-codec.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[H264] ITU-T Recommendation H.264, "Advanced video coding for		[H264] ITU-T Recommendation H.264, "Advanced video coding for
	generic audiovisual services (V9)", February 2014,		generic audiovisual services (V9)", February 2014,
	<http://www.itu.int/rec/T-REC-H.264-201304-I>.		<http://www.itu.int/rec/T-REC-H.264>.
	[HSUP1] ITU-T Recommendation H.Sup1, "Application profile - Sign		[HSUP1] ITU-T Recommendation H.Sup1, "Application profile - Sign
	language and lip-reading real-time conversation using low		language and lip-reading real-time conversation using low
	bit rate video communication", May 1999,		bit rate video communication", May 1999,
	<http://www.itu.int/rec/T-REC-H.Sup1>.		<http://www.itu.int/rec/T-REC-H.Sup1>.
	[I-D.ietf-payload-vp8]		[I-D.ietf-payload-vp8]
	Westin, P., Lundin, H., Glover, M., Uberti, J., and F.		Westin, P., Lundin, H., Glover, M., Uberti, J., and F.
	Galligan, "RTP Payload Format for VP8 Video", draft-ietf-		Galligan, "RTP Payload Format for VP8 Video", draft-ietf-
	payload-vp8-11 (work in progress), February 2014.		payload-vp8-16 (work in progress), June 2015.
	[I-D.ietf-rtcweb-overview]		[I-D.ietf-rtcweb-overview]
	Alvestrand, H., "Overview: Real Time Protocols for		Alvestrand, H., "Overview: Real Time Protocols for
	Browser-based Applications", draft-ietf-rtcweb-overview-12		Browser-based Applications", draft-ietf-rtcweb-overview-13
	(work in progress), October 2014.		(work in progress), November 2014.
	[IEC23001-8]		[IEC23001-8]
	ISO/IEC 23001-8:2013/DCOR1, "Coding independent media		ISO/IEC 23001-8:2013/DCOR1, "Coding independent media
	description code points", 2013, <http://standards.iso.org/		description code points", 2013, <http://standards.iso.org/
	ittf/PubliclyAvailableStandards/		ittf/PubliclyAvailableStandards/
	c062088_ISO_IEC_23001-8_2013.zip>.		c062088_ISO_IEC_23001-8_2013.zip>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	skipping to change at page 8, line 47		skipping to change at page 9, line 6
	Project; Technical Specification Group Services and System		Project; Technical Specification Group Services and System
	Aspects; IP Multimedia Subsystem (IMS); Multimedia		Aspects; IP Multimedia Subsystem (IMS); Multimedia
	Telephony; Media handling and interaction (Release 12)",		Telephony; Media handling and interaction (Release 12)",
	December 2014, <http://www.3gpp.org/DynaReport/26114.htm>.		December 2014, <http://www.3gpp.org/DynaReport/26114.htm>.
	10.2. Informative References		10.2. Informative References
	[I-D.ietf-rtcweb-rtp-usage]		[I-D.ietf-rtcweb-rtp-usage]
	Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time		Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time
	Communication (WebRTC): Media Transport and Use of RTP",		Communication (WebRTC): Media Transport and Use of RTP",
	draft-ietf-rtcweb-rtp-usage-06 (work in progress),		draft-ietf-rtcweb-rtp-usage-24 (work in progress), May
	February 2013.		2015.
	[I-D.ietf-rtcweb-security-arch]		[I-D.ietf-rtcweb-security-arch]
	Rescorla, E., "WebRTC Security Architecture", draft-ietf-		Rescorla, E., "WebRTC Security Architecture", draft-ietf-
	rtcweb-security-arch-09 (work in progress), February 2014.		rtcweb-security-arch-11 (work in progress), March 2015.
	[I-D.ietf-rtcweb-security]		[I-D.ietf-rtcweb-security]
	Rescorla, E., "Security Considerations for WebRTC", draft-		Rescorla, E., "Security Considerations for WebRTC", draft-
	ietf-rtcweb-security-06 (work in progress), January 2014.		ietf-rtcweb-security-08 (work in progress), February 2015.
	Author's Address		Author's Address
	Adam Roach		Adam Roach
	Mozilla		Mozilla
	\		\
	Dallas		Dallas
	US		US
	Phone: +1 650 903 0800 x863		Phone: +1 650 903 0800 x863
End of changes. 18 change blocks.
	31 lines changed or deleted		38 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/