idnits 2.17.1 draft-moffitt-netvc-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 09, 2015) is 3335 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Moffitt 3 Internet-Draft Mozilla 4 Intended status: Informational M. Zanaty 5 Expires: September 10, 2015 Cisco 6 March 09, 2015 8 Video Codec Requirements 9 draft-moffitt-netvc-requirements-00 11 Abstract 13 This document provides specific requirements for an Internet video 14 codec. These requirements address quality, bit-rate, and packet-loss 15 robustness, as well as other desirable properties. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 10, 2015. 34 Copyright Notice 36 Copyright (c) 2015 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Applications . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2.1. Point-to-Point Calls . . . . . . . . . . . . . . . . . . 3 54 2.2. Broadcast . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.3. Conferencing . . . . . . . . . . . . . . . . . . . . . . 3 56 2.4. Telepresence . . . . . . . . . . . . . . . . . . . . . . 3 57 2.5. Teleoperation . . . . . . . . . . . . . . . . . . . . . . 3 58 2.6. Screencasting . . . . . . . . . . . . . . . . . . . . . . 4 59 2.7. Video Storage . . . . . . . . . . . . . . . . . . . . . . 4 60 2.8. Other Applications . . . . . . . . . . . . . . . . . . . 4 61 3. Constraints Imposed by the Internet on the Codec . . . . . . 4 62 4. Detailed Basic Requirements . . . . . . . . . . . . . . . . . 5 63 5. Additional Considerations . . . . . . . . . . . . . . . . . . 5 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Introduction 70 This document provides requirements for a video codec designed 71 specifically for use over the Internet. The requirements attempt to 72 address the needs of the most common streaming and interactive video 73 transmission applications and ensure good quality when operating in 74 typical Internet conditions. These requirements also address issues 75 of quality, frame rate, bit-rate, and packet-loss robustness. Other 76 desirable but not required video codec properties are also 77 considered. 79 2. Applications 81 The following applications should be considered for Internet video 82 codecs, along with their requirements: 84 o Point-to-point calls 86 o Broadcast 88 o Conferencing 90 o Telepresence 92 o Teleoperation 94 o Screencasting 96 o In-game video chat 97 o Video storage 99 o Other applications 101 2.1. Point-to-Point Calls 103 One-to-one video chat applications are proliferating. These 104 interactive uses of a video codec involve two connected participants 105 sending and receiving encoded video to each other. Frame sizes will 106 typically be 360p to 720p and bandwidth used around 1 Mbit/s. 108 The endpoints will need to negotiate and change session details 109 during the call. For example, one endpoint may request higher 110 resolution video when the size of the display window is increased. 112 2.2. Broadcast 114 Broadcasting is live or pre-recorded video being sent to many 115 participants at the same time. This will typically involve frame 116 sizes up to 1080p and bandwidth requirements as high as 6 Mbit/s. 118 Example applications in this area include on-demand video service 119 like Netflix and YouTube as well as digital transmission of live 120 sporting events. 122 2.3. Conferencing 124 Video conferencing requires many of the same things as point-to-point 125 calls, but involves more than 2 participants. It is more complicated 126 due to the shifting focus of attention among the participants. For 127 example, when one participant is speaking, the user may prefer to 128 have their video appear larger and the other participants smaller, 129 which may have consequences for codec parameters. 131 Frame sizes and bitrates are similar to point-to-point applications. 133 2.4. Telepresence 135 Telepresence tries to use high fidelity reproduction to make remote 136 video conference participants feel like they are real people in the 137 same room. This requires high resolutions and large amounts of 138 bandwidth. It is otherwise very similar to video conferencing 139 applications. 141 2.5. Teleoperation 142 Teleoperation requires the high fidelity of telepresence, but 143 includes increased requirements for low latency. Remote control of 144 surgical tools is one example application. 146 2.6. Screencasting 148 Screencasting is the sharing of the contents of some or all of a 149 computer or mobile display. It is commonly used to send the visual 150 output of applications to other endpoints. For example, a speaker at 151 a conference might share the window for their presentation program 152 and a mobile app developer might want to record a demo of their 153 application. 155 Two main features distinguish this application. First, since the 156 inputs are often RGB, it is important to preserve the color 157 information at a higher fidelity than normal video. Second, the 158 input for the encoder is potentially higher level than raw pixels or 159 contains both pixels and higher level objects such as text along with 160 font and positioning information. 162 2.7. Video Storage 164 Archival video brings several unique requirements. Many applications 165 will want lossless compression or very high rates, and others will 166 want low complexity. Examples of the former include archival storage 167 of film masters; examples of the latter would be surveillance gear or 168 video camera capture systems. 170 2.8. Other Applications 172 The preceding list of application is by no means complete. The 173 requirements needed to enable these applications should be sufficient 174 to meet the needs of many other applications that were not listed. 176 3. Constraints Imposed by the Internet on the Codec 178 o must be able to interpret packets when previous packets are lost 180 o prediction across frames is reasonable but must allow for resync 182 o keyframes and other features for dynamic resync 184 o ability to vary bandwidth because of internet best-effort 186 o ECN 188 o use with other multimedia standards 190 4. Detailed Basic Requirements 192 o variable frame rate 194 o variable resolution 196 o any resolution from 1x1 to 4k? 198 o 8bit to 12bit 200 o loss robustness 202 o loss concealment? 204 o error recovery 206 o 420, 444, 422 208 o color spaces: req 709 and 2020 210 o alpha plane 212 o parallelism considerations (entropy coder in separate thread, 213 wavefront parallel, etc.) 215 o hardware feasibility 217 o software feasibility 219 explicit non-requirements: 221 o multiview 223 o scalable video coding 225 o bit-error robustness 227 5. Additional Considerations 229 The features described in this section are potentially desirable but 230 are not part of the strict requirements. Their benefits should be 231 weighed against their costs before including them in the codec. 233 o lossless 235 o RGB mode 237 o aux planes (depth, etc.) 239 6. Security Considerations 241 Although this document itself does not have security considerations, 242 this section describes the security requirements for the codec. 244 As for any protocol to be used over the Internet, security is a very 245 important aspect to consider. This goes beyond the obvious 246 considerations of preventing buffer overflows and similar attacks 247 that can lead to denial-of-service (DoS) or remote code execution. 248 One very important security aspect is to make sure that the decoders 249 have a bounded and reasonable worst-case complexity. This prevents 250 an attacker from causing a DoS by sending packets that are specially 251 crafted to take a very long (or infinite) time to decode. 253 7. References 255 Authors' Addresses 257 Jack Moffitt 258 Mozilla 260 Email: jack@metajack.im 262 Mo Zanaty 263 Cisco 265 Email: mzanaty@cisco.com