draft-ietf-rtcweb-video-04.txt		draft-ietf-rtcweb-video-05.txt
	Network Working Group A.B. Roach		Network Working Group A.B. Roach
	Internet-Draft Mozilla		Internet-Draft Mozilla
	Intended status: Standards Track February 13, 2015		Intended status: Standards Track March 17, 2015
	Expires: August 17, 2015		Expires: September 18, 2015
	WebRTC Video Processing and Codec Requirements		WebRTC Video Processing and Codec Requirements
	draft-ietf-rtcweb-video-04		draft-ietf-rtcweb-video-05
	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 August 17, 2015.		This Internet-Draft will expire on September 18, 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 16		skipping to change at page 2, line 16
	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 . . . . . . . . . . . . . . . . . . . . . 3
	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 . . . . . . . . . . . . . . . . . . . . . . . . . . 5		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 . . . . . . . . . . . . . . . . . 9		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 defines how the video is used and discusses special
	considerations for processing the video. It also covers the video-		considerations for processing the video. It also covers the video-
	related algorithms WebRTC devices need to support.		related algorithms WebRTC devices need to support.
	skipping to change at page 4, line 37		skipping to change at page 4, line 37
	Further, some codecs support in-band signaling of orientation (for		Further, some codecs support in-band signaling of orientation (for
	example, the SEI "Display Orientation" messages in H.264 and H.265).		example, the SEI "Display Orientation" messages in H.264 and H.265).
	If CVO has been negotiated, then the sender MUST NOT make use of such		If CVO has been negotiated, then the sender MUST NOT make use of such
	codec-specific mechanisms. However, when support for CVO is not		codec-specific mechanisms. However, when support for CVO is not
	signaled in the SDP, then such implementations MAY make use of the		signaled in the SDP, then such implementations MAY make use of the
	codec-specific mechanisms instead.		codec-specific mechanisms instead.
	5. Mandatory to Implement Video Codec		5. Mandatory to Implement Video Codec
	For the definitions of "WebRTC Brower," "WebRTC Non-Browser", and		For the definitions of "WebRTC Browser," "WebRTC Non-Browser", and
	"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].
	skipping to change at page 5, line 23		skipping to change at page 5, line 23
	"WebRTC-compatible endpoints" are free to implement any video codecs		"WebRTC-compatible endpoints" are free to implement any video codecs
	they see fit. This follows logically from the definition of "WebRTC-		they see fit. This follows logically from the definition of "WebRTC-
	compatible endpoint." It is, of course, advisable to implement at		compatible endpoint." It is, of course, advisable to implement at
	least one of the video codecs that is mandated for WebRTC Browsers,		least one of the video codecs that is mandated for WebRTC Browsers,
	and implementors are encouraged to do so.		and implementors are encouraged to do so.
	6. Codec-Specific Considerations		6. Codec-Specific Considerations
	SDP allows for codec-independent indication of preferred video		SDP allows for codec-independent indication of preferred video
	resolutions using the mechanism described in [RFC6236]. If a		resolutions using the mechanism described in [RFC6236]. WebRTC
	recipient of video indicates a receiving resolution, the sender		endpoints MAY send an "a=imageattr" attribute to indicate the maximum
	SHOULD accommodate this resolution, as the receiver may not be		resolution they wish to receive. Senders SHOULD interpret and honor
	capable of handling higher resolutions.		this attribute by limiting the encoded resolution to the indicated
			maximum size, as the receiver may not be capable of handling higher
			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 320x240. These values are selected based on the
	recommendations in [HSUP1].		recommendations in [HSUP1].
	skipping to change at page 7, line 11		skipping to change at page 7, line 14
	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 the other documents it references. In WebRTC,
	video is protected using DTLS/SRTP. A complete discussion of the		video is protected using DTLS/SRTP. A complete discussion of the
	security can be found in [I-D.ietf-rtcweb-security] and		security can be found in [I-D.ietf-rtcweb-security] and
	[I-D.ietf-rtcweb-security-arch]. Implementers should consider		[I-D.ietf-rtcweb-security-arch]. Implementors should consider
	whether the use of variable bit rate video codecs are appropriate for		whether the use of variable bit rate video codecs are appropriate for
	their application based on [RFC6562].		their application, keeping in mind that the degree of inter-frame
			change (and, by inference, the amount 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.
	skipping to change at page 8, line 14		skipping to change at page 8, line 19
	[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.
	[RFC4175] Gharai, L. and C. Perkins, "RTP Payload Format for
	Uncompressed Video", RFC 4175, September 2005.
	[RFC4421] Perkins, C., "RTP Payload Format for Uncompressed Video:
	Additional Colour Sampling Modes", RFC 4421, February
	2006.
	[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
	"Codec Control Messages in the RTP Audio-Visual Profile
	with Feedback (AVPF)", RFC 5104, February 2008.
	[RFC6184] Wang, Y.-K., Even, R., Kristensen, T., and R. Jesup, "RTP		[RFC6184] Wang, Y.-K., Even, R., Kristensen, T., and R. Jesup, "RTP
	Payload Format for H.264 Video", RFC 6184, May 2011.		Payload Format for H.264 Video", RFC 6184, May 2011.
	[RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image		[RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image
	Attributes in the Session Description Protocol (SDP)", RFC		Attributes in the Session Description Protocol (SDP)", RFC
	6236, May 2011.		6236, May 2011.
	[RFC6386] Bankoski, J., Koleszar, J., Quillio, L., Salonen, J.,		[RFC6386] Bankoski, J., Koleszar, J., Quillio, L., Salonen, J.,
	Wilkins, P., and Y. Xu, "VP8 Data Format and Decoding		Wilkins, P., and Y. Xu, "VP8 Data Format and Decoding
	Guide", RFC 6386, November 2011.		Guide", RFC 6386, November 2011.
	[RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of
	Variable Bit Rate Audio with Secure RTP", RFC 6562, March
	2012.
	[SRGB] IEC 61966-2-1, "Multimedia systems and equipment - Colour		[SRGB] IEC 61966-2-1, "Multimedia systems and equipment - Colour
	measurement and management - Part 2-1: Colour management -		measurement and management - Part 2-1: Colour management -
	Default RGB colour space - sRGB.", October 1999, <http://		Default RGB colour space - sRGB.", October 1999, <http://
	www.colour.org/tc8-05/Docs/colorspace/61966-2-1.pdf>.		www.colour.org/tc8-05/Docs/colorspace/61966-2-1.pdf>.
	[TS26.114]		[TS26.114]
	3GPP TS 26.114 V12.8.0, "3rd Generation Partnership		3GPP TS 26.114 V12.8.0, "3rd Generation Partnership
	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)",
End of changes. 11 change blocks.
	28 lines changed or deleted		17 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/