Patent Application
20140036999
Various video formats, such as High Efficiency Video Coding (HEVC), generally include features for providing enhanced video quality. These video formats may provide enhanced video quality by encoding, decoding, and/or transmitting video packets differently based on their level of importance. More important video packets may be handled differently to mitigate loss and provide a greater quality of experience (QoE) at a user device. Current video formats and/or protocols may improperly determine the importance of different video packets and may not provide enough information for encoders, decoders, and/or the various processing layers therein to accurately distinguish the importance of different video packets for providing an optimum QoE.
Priority information may be used by an encoder, a decoder, or other network entities, such as a router or a gateway, to distinguish between different types of video data. The different types of video data may include video packets, video frames, or the like. The different types of video data may be included in temporal levels in a hierarchical structure, such as a hierarchical-B structure. The priority information may be used to distinguish between different types of video data having the same temporal level in the hierarchical structure. The priority information may also be used to distinguish between different types of video data having different temporal levels. A different priority level may be determined for different types of video data at the encoder and may be indicated to other processing layers at the encoder, the decoder, or other network entities, such as a router or a gateway.
The priority level may be based on an effect on the video information being processed. The priority level may be based on a number of video frames that reference the video frame. The priority level may be indicated in a header of a video packet or a signaling protocol. If the priority level is indicated in a header, the header may be a Network Abstraction Layer (NAL) header of a NAL unit. If the priority level is indicated in a signaling protocol, the signaling protocol may be a supplemental enhancement information (SEI) message or an MPEG media transport (MMT) protocol.
The priority level may be determined explicitly or implicitly. The priority level may be determined explicitly by counting a number of referenced macro blocks (MBs) or coding units (CUs) in a video frame. The priority level may be determined implicitly based on a number of times a video frame is referenced in a reference picture set (RPS) or a reference picture list (RPL).
The priority level may be indicated relative to another priority or using a priority identifier that indicates the priority level. The relative level of priority may be indicated as compared to the priority level of another video frame. The priority level for the video frame may be indicated using a one-bit index or a plurality of bits that indicates a different level of priority using a different bit sequence.
A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings.
As shown in
The communications systems 100 may also include a base station 114a and a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the core network 106, the Internet 110, and/or the networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.
The base station 114a may be part of the RAN 104, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers (e.g., one for each sector of the cell). The base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell.
The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).
The communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and/or the like. For example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 116 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).
In another embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A).
In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and/or the like.
The base station 114b in
The RAN 104 may be in communication with the core network 106, which may be any type of network configured to provide voice, data (e.g., video), applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication. Although not shown in
The core network 106 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 112 may include wired or wireless communications networks owned and/or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.
Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links). For example, the WTRU 102c shown in
The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing (e.g., encoding/decoding), power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While
The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116. For example, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. The transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. The transmit/receive element 122 may be configured to transmit and receive both RF and light signals. The transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.
Although the transmit/receive element 122 is depicted in
The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. The WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.
The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. The processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, and/or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and/or the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).
The processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and/or the like.
The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. The WTRU 102 may acquire location information by way of any suitable location-determination method.
The processor 118 may be further coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and/or the like.
As shown in
The core network 106 shown in
The RNC 142a in the RAN 104 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices.
The RNC 142a in the RAN 104 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between and the WTRUs 102a, 102b, 102c and IP-enabled devices.
As noted above, the core network 106 may also be connected to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.
The RAN 104 may include eNode-Bs 160a, 160b, 160c, though the RAN 104 may include any number of eNode-Bs. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. The eNode-Bs 160a, 160b, 160c may implement MIMO technology. The eNode-Bs 160a, 160b, 160c may each use multiple antennas to transmit wireless signals to, and/or receive wireless signals from, the WTRUs 102a, 102b, 102c.
Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and/or downlink, and/or the like. As shown in
The core network 106 shown in
The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and/or the like. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.
The serving gateway 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the S1 interface. The serving gateway 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The serving gateway 164 may also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and/or the like.
The serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.
The core network 106 may facilitate communications with other networks. For example, the core network 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the core network 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core network 106 and the PSTN 108. In addition, the core network 106 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.
As shown in
The air interface 116 between the WTRUs 102a, 102b, 102c and the RAN 104 may be defined as an R1 reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs 102a, 102b, 102c may establish a logical interface (not shown) with the core network 106. The logical interface between the WTRUs 102a, 102b, 102c and the core network 106 may be defined as an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and/or mobility management.
The communication link between each of the base stations 180a, 180b, 180c may be defined as an R8 reference point that includes protocols for facilitating WTRU handovers and the transfer of data between base stations. The communication link between the base stations 180a, 180b, 180c and/or the ASN gateway 182 may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.
As shown in
The MIP-HA 184 may be responsible for IP address management, and may enable the WTRUs 102a, 102b, 102c to roam between different ASNs and/or different core networks. The MIP-HA 184 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The AAA server 186 may be responsible for user authentication and for supporting user services. The gateway 188 may facilitate interworking with other networks. For example, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. The gateway 188 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.
Although not shown in
The subject matter disclosed herein may be used, for example, in any of the networks or suitable network elements disclosed above. For example, the frame prioritization described herein may be applicable to a WTRU 102a, 102b, 102c or any other network element processing video data.
In video compression and transmission, frame prioritization may be implemented to prioritize the transmission of frames over a network. Frame prioritization may be implemented for Unequal Error Protection (UEP), frame dropping for bandwidth adaptation, Quantization Parameter (QP) control for enhanced video quality, and/or the like. High Efficiency Video Coding (HEVC) may include next-generation high definition television (HDTV) displays and/or internet protocol television (IPTV) services, such as for error resilient streaming in HEVC-based IPTV. HEVC may include features such as extended prediction block sizes (e.g., up to 64×64), large transform block sizes (e.g., up to 32×32), tile and slice picture segmentations for loss resilience and parallelism, adaptive loop filter (ALF), sample adaptive offset (SAO), and/or the like. HEVC may indicate frame or slice priority in a Network Abstraction Layer (NAL) level. A transmission layer may obtain priority information for each frame and/or slice by digging into a video coding layer and may indicate frame and/or slice priority-based differentiated services to improve Quality of Service (QoS) in video streaming.
Layer information of video packets may be used for frame prioritization. Video streams, such as the encoded bitstream of H.264 Scalable Video Coding(SVC) for example, may include a base layer and one or more enhancement layers. The reconstruction pictures of the base layer may be used to decode the pictures of the enhancement layers. Because the base layer may be used to decode the enhancement layers, losing a single base layer packet may result in severe error propagation in both layers. The video packets of the base layer may be processed with higher priority (e.g., the highest priority). The video packets with higher priority, such as the video packets of the base layer, may be transmitted with greater reliability (e.g., on more reliable channels) and/or lower packet loss rates.
The frame type information may be related to temporal reference dependency for frame prioritization. For example, the I-frame 202 may be given higher priority than other frame types, such as the B-frame 204 and/or the P-frame 206. This may be because the B-frame 204 and/or the P-frame 206 may rely on the I-frame 202 for being decoded.
The video frames at a lower temporal level may be given higher priority than the video frames at higher temporal level that may reference the frames at the lower levels. For example, the video frames T0 at temporal level 210 may be given higher priority (e.g., highest priority) than the video frames T1 or T2 at temporal levels 212 and 214, respectively. The video frame T1 at temporal level 212 may be given higher priority (e.g., medium priority) than the video frames T2 at level 214. The video frames T2 at level 214 may be given a lower priority (e.g., low priority) than the video frames T0 at level 210 and/or the video frame T1 at level 212, to which the video frames T2 may refer.
Each SVC layer may be given a different priority level. The base layer 218 may be given a higher priority level (e.g., high priority) than the enhancement layer 220 and/or 222. This may be because the base layer 218 may be used to provide the video at a base resolution and the enhancement layers 220 and/or 222 may add on to the base layer 218. The enhancement layer 220 may be given a higher priority level than the enhancement layer 222 and a lower priority level (e.g., medium priority) than the base layer 218. This may be because the enhancement layer 220 may be used to provide the next layer of video resolution and may add on to the base layer 218. The enhancement layer 222 may be given a lower priority level (e.g., low priority) than the base layer 218 and the enhancement layer 220. This may be because the enhancement layer 222 may be used to provide an additional layer of video resolution and may add on to the base layer 218 and/or the enhancement layer 220.
As shown in
Frame prioritization may be used for QoS handling in video streaming
Frame priorities may be used for several QoS purposes 304, 306, 308, 310, 312. Frames F1, F2, F3, . . . Fn may be prioritized at 304 for frame dropping for bandwidth adaptation. At 304, the frames F1, F2, F3, . . . Fn that are assigned a lower priority may be dropped in a transmitter or a scheduler of a transmitting device for bandwidth adaptation. Frames may be prioritized at 306 for selective channel allocation where multiple channels may be implemented, such as when multiple-input and multiple-output (MIMO) is implemented for example. Using the frame prioritization at 306, frames that are assigned a higher priority may be allocated to more stable channels or antennas. At 308, unequal error protection (UEP) in the application layer or the physical layer may be distributed according to priority. For example, frames that are assigned a higher priority may be protected with larger overhead of Forward Error Correction (FEC) code in the application layer or the physical layer. If a video server or transmitter protects the higher priority video frame with larger overhead of FEC, the video packet may be decoded with the error correction codes even if there are many packet losses in the wireless network.
Selective scheduling may be performed at 310 in the application layer and/or the medium access control (MAC) layer based on frame priority. Frames with a higher priority may be scheduled in the application layer and/or MAC layer before frames with a lower priority. At 312, different frame priorities may be used to differentiate services in a Media Aware Network Element (MANE), an edge server, or a home gateway. For example, the MANE smart router may drop the low priority frames when it is determined when there is network congestion, route the high priority frames to more a stable network channel/channels, apply higher FEC overhead to high priority frames, and/or the like.
Technologies such as MPEG media transport (MMT) and Internet Engineering Task Force (IETF) H.264 over a real-time transport protocol (RTP) may implement frame priority at the system level, which may enhance a scheduling device (e.g., a video server or router) and/or a MANE smart router for QoS improvement by differentiating among packets with various priorities when congestion occurs in networks.
The smart router 514 may receive the video frames from the video server 500 and may send them through the network 512. The edge server 516 may be included in the network 512 and may receive the video frame from the smart router 514. The edge server 516 may send the video frame to a home gateway 518 for being handed over to a client device, such as a WTRU.
An example technique for assigning frame priority may be based on frame characteristics analysis. For example, layer information (e.g., base and enhancement layers), frame type (e.g., I-frame, P-frame, and/or B-frame), the temporal level of a hierarchical structure, and/or the frame context (e.g., important visual objects in frame) may be common factors in assigning frame priority. Examples are provided herein for hierarchical structure (e.g., hierarchical-B structure) based frame prioritization. The hierarchical structure may be a hierarchical structure in HEVC.
Video protocols, such as HEVC, may provide priority information for prioritization of video frames. For example, a priority ID may be implemented that may identify a priority level of a video frame. Some video protocols may provide a temporal ID (e.g., temp_id) in the packet header (e.g., Network Abstraction Layer (NAL) header). The temporal ID may be used to distinguish frames on different temporal levels by indicating a priority level associated with each temporal level. The priority ID may be used to distinguish frames on the same temporal level by indicating a priority level associated with each frame in a temporal level.
A hierarchical structure, such as a hierarchical B structure, may be implemented in the extension of H.264/AVC to increase coding performance and/or provide temporal scalability.
The hierarchical structure 620 may include temporal levels 612, 614, 616, 618. Frames 600 and/or 608 may be included in temporal level 618, frame 604 may be included in temporal level 616, frames 602 and 606 may be included in temporal level 614, and frames 601, 603, 605, and 607 may be included in temporal level 612. The frames in a lower temporal level may have higher priority than frames in a higher temporal level. For example, the frames 600 and 608 may have a higher priority (e.g., highest priority) than frame 604, frame 604 may have a higher priority (e.g., high priority) than frames 602 and 606, and frames 602 and 606 may have a higher priority (e.g., low priority) than frames 601, 603, 605, and 607. The priority level of each frame in the GOP 610 may be based on the temporal level of the frame, the number of other frames from which the frame may be referenced, and/or the temporal level of the frames that may reference the frame. For example, the priority of a frame in a lower temporal level may have a higher priority because the frame in a lower temporal level may have more opportunities to be referenced by other frames. Frames at the same temporal level of the hierarchical structure 620 may have equal priority, such as in an example HEVC system that may have multiple frames in a temporal level for example. When the frames in a lower temporal level have a higher priority and the frames at the same temporal level have the same priority, this may be referred to as uniform prioritization.
Various types of frame referencing may be implemented when a frame is referenced by one or more other frames. To compare the importance of frames located in the same temporal level, such as frame 602 and frame 606, a position may be defined for each frame in a GOP, such as GOP 610. Frame 602 may be in Position A within the GOP 610. Frame 606 may be at Position B within the GOP 610. Position A for each GOP may be defined as the POC 2+N×GOP and Position B for each GOP may be defined as the POC 6+N×GOP, where, as shown in
Table 1 shows a number of characteristics associated with each frame in an Intra Period of thirty-two frames. The Intra Period may include four GOPs, with each GOP including eight frames having consecutive POCs. Table 1 shows the QP offset, the reference buffer size, the RPS, and the reference picture lists (e.g., L0 and L1) for each frame. The reference picture lists may indicate the frames that may be referenced by a given video frame. The reference picture lists may be used for encoding each frame, and may be used to influence video quality.
Table 1 illustrates the frequency with which the frames in Position A and Position B appear in the reference picture lists (e.g., L0 and L1). Position A and Position B may appear in the reference picture lists (e.g., L0 and L1) at different times during each Intra Period. The frames in Position A and Position B may be determined by counting the number of times a POC for a frame in Position A or Position B appears in the reference picture lists (e.g., L0 and L1). Each POC may be counted once for each time it appears in a reference picture list (e.g., L0 and/or L1) for a given frame in Table 1. If a POC was referenced in multiple picture lists (e.g., L0 and L1) for a frame, the POC may be counted once for that frame. In Table 1, the frames in Position A (e.g., at POC 2, POC 10, POC 18, and POC 26) are referenced 12 times and the frames in Position B (e.g., at POC 6, POC 14, POC 22, and POC 30) are referenced 16 times during the Intra Period. Compared to the frames in Position A, the frames in Position B may have more chances to be referenced. This may indicate that the frames in Position B may be more likely to cause error propagation if they are dropped during transmission. If a frame is more likely to cause error propagation than another frame, the frame may be given higher priority than frames that are less likely to cause error propagation.
Error propagation may be effected when packets or frames are dropped. To quantify video quality degradation, frame dropping tests may be performed with encoded bitstreams (e.g., binary video files). Frames in different positions within a GOP may be dropped to determine the effect of a dropped packet at each position. For example, a frame in Position A may be dropped to determine the effect of the loss of the frame at Position A. A frame in Position B may be dropped to determine the effect of the loss of the frame at Position B. There may be multiple dropping periods. A dropping period may occur in each GOP. One or more dropping periods may occur in each Intra Period.
Video coding, via H.264 and/or HEVC for example, may be used to encapsulate a compressed video frame in NAL unit(s). An NAL packet dropper may analyze the video packet type with the encoded bitstream and may distinguish each frame. A NAL packet dropper may be used to consider the effect of error propagation. To illustrate, to measure the difference of objective video quality in two tests (e.g., one dropped frame in Position A and one dropped frame in Position B), the video decoder may decode a damaged bitstream using an error concealment, such as frame copy for example, and may generate a video file (e.g., a YUV-formatted raw video file).
After frame 803 in Position A or frame 806 in Position B is lost or dropped during transmission, the decoder may copy a previous reference frame. For example, if frame 803 is lost or dropped, frame 800 may be copied to the location of frame 803. Frame 800 may be copied because frame 800 may be referenced by frame 803 and may be temporally advanced. If frame 806 is lost, frame 804 may be copied to the location of frame 806. The copied frame may be a frame on a lower temporal level.
After the error concealed frame is copied, error propagation may continue until the decoder may have an intra-refresh frame. The intra-refresh frame may be in the form of an instantaneous decoder refresh (IDR) frame or a clean random access (CRA) frame. The intra-refresh frame may indicate that frames after the IDR frame may be unable to reference any frame before it. Because the error propagation may be continued until the next IDR or CRA frame, the loss of important frames may be prevented for video streaming.
Table 2 and
To measure the difference in video quality between two packet dropping tests (e.g., one dropped frame in Position A and one dropped frame in Position B), a decoder (e.g., an HM v6.1 decoder) may be used. The decoder may conceal lost frames using frame copy. The testing may use three test sequences from HEVC common test conditions. The resolution of the pictures being analyzed may be 2560×1600 and/or 1920×1080.
The same or similar results may be illustrated in the rate-distortion curves shown in the graphs in
As shown in
As shown in Table 2, and
The frame Fn 1002 may be received at a motion estimation module 1012. The frame may be sent from the motion estimation module 1012 to a frame prioritization module 1014. The priority may be determined at the frame prioritization module 1014 based on the number of MBs or CUs referenced in the frame Fn 1002. The frame prioritization module may update the number of referenced MBs or CUs using information from the motion estimation module 1012. For example, the motion estimation module 1012 may indicate which MBs or CUs in the reference frame match the current MB or CU in the current frame. The priority information for frame Fn 1002 may be stored as the SVB at 1010.
There may be multiple prediction modes for encoding video frames. The prediction modes may include intra-frame prediction and inter-frame prediction. The intra-frame prediction module 1020 may be conducted in the spatial domain by referring to neighboring samples of previously-coded blocks. The inter-frame prediction may use the motion estimation module 1012 and/or motion compensation module 1018 to find the matched blocks between the current frame and the reconstructed frame number n−1 (RFn-1 1016) that was previously-coded, reconstructed, and/or stored. Because the video encoder 1000 may use the reconstructed frame RFn 1022 as the decoder does, the encoder 1000 may use the inverse quantization module 1028 and/or the inverse transform module 1026 for reconstruction. These modules 1028 and 1026 may generate the reconstructed frame RFn 1022 and the reconstructed frame RFn 1022 may be filtered by the loop filter 1024. The reconstructed frame RFn 1022 may be stored for later use.
Prioritization may be conducted using the counted numbers periodically, which may update the priorities of the encoded frames (e.g., the priority field in NAL header). A frame prioritization period may be decided by the absolute number of maximum value in an RPS. If the RPS is set as shown in Table 3, the frame prioritization period may be 16 (e.g., for two GOPs), and the encoder may update the priorities for encoded frames once every 16 frames or any suitable number of frames. A priority update using explicit prioritization may cause a delay in transmission compared to implicit prioritization. Explicit frame prioritization may provide more precise priority information than implicit frame prioritization, which may calculate priorities implicitly using the RPS and/or reference picture list size. Explicit frame prioritization and/or implicit frame prioritization may be used for video streaming scenario, video conferencing, and/or any other video scenario.
In implicit frame prioritization, the given RPS and reference buffer size may be used to determine frame priority implicitly. If a POC number is observed more often in the reference picture lists (e.g., reference picture lists L0 and L1), the POC may earn a higher priority because the observed time may imply the opportunity of being referenced in motion estimation module 1012. For example, Table 1 shows that POC 2 in the reference picture lists L0 and L1 may be observed three times and that POC 6 may be observed five times. Implicit frame prioritization may be used to assign the higher priority to POC 6.
At 1208, it may be determined whether the size of the counter uiReadPOC is greater than a maximum size (e.g., maximum absolute size) of the reference table. For example, the maximum size of the reference table in Table 1 may be 16. If the size of the counter uiReadPOC is less than the maximum size of the reference table, the method 1200 may return to 1202. The number of referenced MBs or CUs may be read and/or updated until the size of the counter uiReadPOC is greater than the maximum size of the POC reference table. When the size of the counter uiReadPOC is greater than the maximum size of the table (e.g., each MB or CU in the table has been read), the priority for one or more POCs may be updated. The method 1200 may be used to determine the number of times the MBs or CUs of each POC may be referenced by other POCs and may use the reference information to assign the frame prioritization. The priority for POC(s) maybe updated and/or the counter uiReadPOC may be initialized to zero at 1210. At 1212, it may be determined whether the end of a frame sequence has been reached. The frame sequence may include an Intra Period for example. If the end of the frame sequence has not been reached at 1212, the method 1200 may return to 1202 to encode the frame at the next POC. If the end of the frame sequence has been reached at 1212, the method 1200 may end at 1214. After the end of method 1200, the priority information may be signaled to the transmission layer for being transmitted to the decoder or another network entity, such as a router or gateway.
As illustrated by methods 1100 and 1200, implicit frame prioritization may derive priority by looking at the prediction structure of a frame in advance, which may cause less delay on the transmission side. If the POC includes multiple slices, the priority may be assigned to each slice of a frame based on the prediction structure. Implicit frame prioritization may be combined with other codes, such as Raptor FEC codes, to show its performance gain. In an example, Raptor FEC codes, a NAL packet loss simulator, and/or the implicit frame prioritization may be implemented.
Each frame may be encoded and/or packetized. The frames may be encoded and/or packetized within a NAL packet. Packets may be protected with selected FEC redundancy as shown in Table 4. The FEC redundancy may be applied to frames with the same priority. According to Table 4, frames with the highest priority may be protected with 44% FEC redundancy, frames with high priority may be protected with 37% FEC redundancy, frames with medium-high priority may be protected with 32% FEC redundancy, frames with medium priority may be protected with 30% FEC redundancy, frames with medium-low priority may be protected with 28% FEC redundancy, and/or frames with low priority may be protected with 24% FEC redundancy.
When implicit frame prioritization is combined with UEP, frames in the same temporal level may be assigned different priorities and/or receive different FEC redundancy protection. For example, when the frames in Position A and the frames in Position B are in the same temporal level, the frames in Position A may be protected with 28% FEC redundancy (e.g., medium-low priority) and/or the frames in Position B may be protected with 32% FEC redundancy (e.g., medium-high priority). When uniform prioritization is combined with UEP, frames in the same temporal level may be assigned the same priority and/or receive the same FEC redundancy protection. For example, frames at Position A and at Position B may be protected with 30% FEC redundancy (e.g., medium priority). In hierarchical B pictures with a GOP of eight and four temporal levels, frames in the lowest temporal level (e.g., POC 0 and 8) may be protected with the highest priority, frames in temporal level 1 (e.g., POC 4) may be protected with the high priority, and/or frames in the highest temporal level (e.g., POC 1, 3, 5, 7) may be protected with the lowest priority.
In
As shown in
As shown in
The graphs in
The priority of a frame may be indicated in a video packet, a syntax of a video stream including a video file, and/or an external video description protocol. The priority information may indicate the priority of one or more frames. The priority information may be included in a video header. The header may include one or more bits that may be used to indicate the level of priority. If a single bit is used to indicate priority, the priority may be indicated as being high priority (e.g., indicated by a ‘1’) or low priority (e.g., indicated by a ‘0’). When more than one bit is used to indicate a level of priority, the levels of priority may be more specific and may have a broader range (e.g., low, medium-low, medium, medium-high, high, etc.). The priority information may be used to distinguish the level of priority of frames in different temporal levels and/or the same temporal level. The header may include a flag that may indicate whether the priority information is being provided. The flag may indicate whether a priority identifier is provided to indicate the priority level.
The temporal_id field 1408 may include one or more bits (e.g., a three-bit field) that may indicate the temporal level of one or more frames in the video packet. For Instantaneous Decoder refresh (IDR) pictures, Clean Random Access (CRA) pictures, and/or I-frames, the temporal_id field 1408 may include a value equal to zero. For temporal level access (TLA) pictures and/or predictively coded pictures (e.g., B-frames or P-frames), the temporal_id field 1408 may include a value greater than zero. The priority information may be different for each value in the temporal_id field 1408. The priority information may be different for frames having the same value in the temporal_id field 1408 to indicate a different level of priority for frames within the same temporal level.
Referring to
Referring to
The header 1412 may include a priority_id field 1418 for indicating the priority identifier of the video packet. The priority_id field 1418 may be indicated in one or more bits of the reserved_one—5 bits field 1410. The priority_id field 1418 may use four bits and leave a reservedone—1bit field 1420. For example, the priority_id field 1418 may indicate a highest priority using a series of bits 0000 and may set the lowest priority to 1111. When the priority_id field 1418 uses four bits, it may provide 16 levels of priory. If the priority_id field 1418 is used with the temporal_id field 1408, the temporal_id field 1408 and the priority_id field 1418 may provide 2′7 (=128) levels of priority. Any other number of bits may be used to provide different levels of priority. The reserved_one—1bit field may be used for an extension flag, such as a nal_extension_flag for example. The priority_id field 1418 may indicate a level of priority for one or more video frames in a video packet. The priority level may be indicated for video frames having the same or different temporal levels. For example, the priority_id field 1418 may be used to indicate a different level of priority for video frames within the same temporal level.
Table 5 shows an example for implementing a NAL unit using a priority_id_enabled_flag and a priority_id.
As shown in Table 5, a header may include a forbidden_zero_bit field, a nal_priority_id_enabledflag field, a nal_unit_type field, and/or a temporal_id field. If the nal_priority_id_enabled_flag field indicates that the priority identification is enabled (e.g., nal_priority_id_enabledflag field=1), the header may include the priority_id field and/or the reservedone—1bit field. The priority_id field may indicate a level of priority of one or more video frames associated with the NAL unit. For example, the priority_id field may distinguish between video frames on different temporal levels and/or the same temporal level of a hierarchical structure. If the nal_priority_id_enabled_flag field indicates that the priority identification is disabled (e.g., nal_priority_id_enabled_flag field=0), the header may include the reserved_one—5 bit field. While Table 5 may illustrate an example NAL unit, similar fields may be used to indicate priority in another type of data packet.
Fields in Table 5 may have a descriptor f(n) or u(n). The descriptor f(n) may indicate a fixed-pattern bit string using n bits. The bit string may be written from left to right with the left bit first. The parsing process for f(n) may be specified by a return value of the function read_bits(n). The descriptor u(n) may indicate an unsigned integer using n bits. When n is “v” in the syntax table, the number of bits may vary in a manner dependent on the value of other syntax elements. The parsing process for u(n) descriptor is specified by the return value of the function read_bits(n) interpreted as a binary representation of an unsigned integer with most significant bit written first.
The header may initialize the number of bytes in the raw byte sequence payload (RBSP). The RBSP may be a syntax structure that may include an integer number of bytes that may be encapsulated in a data packet. An RBSP may be empty or may have the form of a string of data bits that may include syntax elements followed by an RBSP stop bit. The RBSP may be followed by zero or more subsequent bits that may be equal to zero.
When the frames have different temporal levels, the frames in lower temporal level may have a higher priority than the frames in higher temporal level. Frames in the same temporal level may be distinguished from each other based on their priority level. The frames within the same temporal level may be distinguished using a header field that may indicate whether a frame has a higher or lower priority than other frames in same temporal level. The priority level may be indicated using a priority identifier for a frame, or by indicating a relative level of priority. The relative priority of frames within the same temporal level within a GOP may be indicated using a one-bit index. The one bit index may be used to indicate a relatively higher and/or lower level of priority for frames within the same temporal level. Referring back to
The header may be used to indicate the relative priority between frames in the same temporal level. A field that indicates a relatively higher or lower priority than another frame in the same temporal level may be referred to as a priority_idc field. If the header is a NAL header, the priority_idc field may be referred to as a nal priority_idc field. The priority_idc field may use a 1-bit index. The priority_idc field may be located in the same location as the ref_flag field 1404 and/or the priority_id_enabled_flag field 1416 illustrated in
Table 6 shows an example for implementing a NAL unit with the priority_idc field.
Table 6 includes similar information to the Table 5 illustrated herein. As shown in Table 6, a header may include a forbidden_zero_bit field, a nal_priority_idc field, a nal_unit_type field, a temporal_id field, and/or a reserved_one—5 bits field. While Table 6 may illustrate an example NAL unit, similar fields may be used to indicate priority in another type of data packet.
The priority information may be provided using a supplemental enhancement information (SEI) message. An SEI message may assist in processes related to decoding, display, or other processes. Some SEI may include data, such as picture timing information, which may precede the primary coded frame. The frame priority may be included in an SEI message as shown in Table 7 and/or Table 8.
As shown in Table 7, the payload of the SEI may include a payload type and/or a payload size. The priority information may be set to the payload size of the SEI payload. For example, if the payload type is equal to a predetermined type ID, the priority information may be set to the payload size of the SEI payload. The predetermined type ID may include a predetermined value (e.g., 131) for setting the priority information.
As shown in Table 8, the priority information may include a priority identifier that may be used to indicate the priority level. The priority identifier may include one or more bits (e.g., 4 bits) that may be included in the SEI payload. The priority identifier may be used to distinguish the priority level between frames within the same temporal level and/or different temporal levels. The bits in the priority info that are unused to indicate the priority identifier may be reserved for other use.
The priority information may be provided in an Access Unit (AU) delimiter. The decoding of each AU may result in a decoded picture. Each AU may include a set of NAL units that together may compose a primary coded frame. It may also be prefixed with an AU delimiter to aid in locating the start of the AU.
Table 9 shows an example for providing the priority information in an AU delimiter.
As shown in Table 9, the AU delimiter may include a picture type, a priority identifier, and/or RBSP trailing bits. The picture type may indicate the type of picture following the AU delimiter, such as an I-picture/slice, a P-picture/slice, and/or a B-picture/slice. The RBSP trailing bits may fill the end of payload with zero bits to align the byte. The priority identifier may be used to indicate the priority level of one or more frames having the indicated picture type. The priority identifier may be indicated using one or more bits (e.g., 4 bits). The priority identifier may be used to distinguish the priority level between frames within the same temporal level and/or different temporal levels.
While the fields described herein may be provided for a NAL syntax and/or the HEVC, similar fields may be implemented for other video types. For example, Table 10 illustrates an example of an MPEG Media Transport (MMT) packet that includes a priority field.
An MMT packet may include a digital container that may support HEVC video. Because the MMT includes the video packet syntax and file format for transmission, the MMT packet may include a priority field. The priority field in Table 10 is labeled loss_priority. The loss_priority field may include one or more bits (e.g., three bits) and may be included in the QoS classifier( ). The loss_priority field may be a bit string with the left bit being the first bit in the bit string, which may be indicated by the mnemonic bslbf for “Bit String, Left Bit First.” The MMT packet may include other functions, such as a service classifier( ) and/or a flow identifier( ) that may include one or more fields that may each include one or more bits that are bslbf. The MMT packet may be also include a sequence number, a time stamp, a RAP flag, a header extension flag, and/or a padding flag. These fields may each include one or more bits that may be an unsigned integer having the most significant bit first, which may be indicated by the mnemonic uimsbf for “Unsigned Integer Most Significant Bit First.”
Table 11 provides an example description of the loss_priority field in the MPEG Media Transport (MMT) packet illustrated in Table 10.
As shown in Table 11, the loss_priority field may indicate a level of priority using a bit sequence (e.g., three bits). The loss_priority field may use consecutive values in the bit sequence to indicate different levels of priority. The loss_priority field may be used to indicate a level of priority between and/or amongst different types of data (e.g., audio, video, text, etc.). The loss_priority field may indicate different levels of priority for different types of video data (e.g., I-frames, P-frames, B-frames). When the video data is provided in different temporal levels, the loss priority field may be used to indicate different levels of priority for video frames within the same temporal level.
The loss_priority field may be mapped to a priority field in another protocol. The MMT may be implemented for transmission and the transport packet syntax may carry various types of data. The mapping may be for compatibility purposes with other protocols. For example, the loss_priority field may be mapped to a NAL Reference Index (NRI) of NAL and/or a Differentiated Services Code Point (DSCP) of IETF. The loss_priority field may be mapped to a temporal_id field of NAL. The loss_priority field in the MMT Transport Packet may provide an indication or explanation regarding how the field may be mapped to the other protocols. The priority_id field described herein (e.g., for HEVC) may be implemented in a similar manner to or have a connection with the loss_priority field of the MMT Transport Packet. The priority_id field may be directly mapped to the loss_priority field, such as when the number of bits for each field are the same. If the number of bits of the priority_id field and the loss_priority field are different, the syntax that has a greater number of bits may be quantized to the syntax having a lower number of bits. For example, if the priority_id field includes four bits, the priority_id field may be divided by two and may be mapped to a three-bit loss_priority field. The frame priority information may be implemented by other video types. For example, MPEG-H MMT may implement a similar form of frame prioritization as described herein.
The header may include a packet sequence number 1504, 1506 and/or a timestamp 1508, 1510 for each packet in the sequence. The packet sequence number 1504, 1506 may be an identification number of a corresponding packet. The timestamps 1508 and 1510 may correspond to a transmission time of the packet having the respective packet sequence numbers 1504 and 1506.
The header may include a flow identifier flag (F) 1522. The F 1522 may indicate the flow identifier. The F 1522 may include one or more bits that may indicate (e.g., when set to ‘1’) that flow identifier information is implemented. Flow identifier information may include a flow label 1514 and/or an extension flag (e) 1516, which may be included in the header. The flow label 1514 may identify a quality of service (QoS) (e.g., a delay, a throughput, etc.) that may be used for each flow in each data transmission. The e 1516 may include one or more bits for indicating an extension. When there are more than a predefined number of flows (e.g., 127 flows), the e 1516 may indicate (e.g., by being set to ‘1’) that one or more bytes may be used for extension. Per-flow QoS operations may be performed in which network resources may be temporarily reserved during the session. A flow may be a bitsream or a group of bitstreams that have network resources that may be reserved according to transport characteristics or ADC in a package.
The header may include a private user data flag (P) 1524, a forward error correction type (FEC) field 1526, and/or reserved bits (RES) 1528. The P 1524 may include one or more bits that may indicate (e.g., when set to ‘1’) that private user data information is implemented. The FEC field 1526 may include one or more bits (e.g., 2 bits) that may indicate an FEC related type information of an MMT packet. The RES 1528 may be reserved for other use.
The header may include a type of bitrate (TB) 1530, reserved bits 1518 (e.g., a 5-bit field) and/or a reserved bit (S) 1536 that may be reserved for other use, private user data 1538, and/or payload data 1540. The TB 1530 may include one or more bits (e.g., 3 bits) that may indicate the type of bitrate. The type of bitrate may include a constant bitrate (CBR, a non-CBR, or the like.
The header may include a QoS classifier flag (Q) 1520. The Q 1520 may include one or more bits that may indicate (e.g., when set to ‘1’) that QoS classifier information is implemented. A QoS classifier may include a delay sensitivity (DS) field 1532, a reliability flag (R) 1534, and/or a transmission priority (TP) field 1512, which may be included in the header. The delay sensitivity field may indicate the delay sensitivity of the data for a service. An example description of the R 1534 and the transmit priority field 1512 are provided in Table 12. The Q 1520 may indicate the QoS class property. Per-class QoS operations may be performed according to the value of a property. The class values may be universal to each independent session.
Table 12 provides an example description of the reliability flag 1534 and the TP field 1512.
As shown in Table 12, the reliability flag 1534 may include a bit that may be set to indicate that the data (e.g., media data) in the packet 1500 is loss tolerant. For example, the reliability flag 1534 may indicate that one or more frames in the packet 1500 are loss tolerant. For example, the packets may be dropped without severe quality degradation. The reliability flag 1534 may indicate that the data (e.g., signaling data, service data, programing data, etc.) in the packet 1500 is not loss tolerant. The reliability flag 1534 may be followed by one or more bits (e.g., 3 bits) that may indicate a priority of the lost frames.
The reliability flag 1534 may indicate whether to use the priority information in the TP 1512 or to ignore the priority information in the TP 1512. The TP 1512 may be a priority field of one or more bits (e.g., 3-bit) that may indicate the priority level of the packet 1500. The TP 1512 may use consecutive values in a bit sequence to indicate different levels of priority. In the example shown in Table 12, the TP 1512 uses values from zero (e.g., 0002) to seven (e.g., 1112) to indicate different levels of priority. The value of seven may be the highest priority level and the value of zero may be the lowest priority value. While the values from zero to seven are used in Table 12, any number of bits and/or range of values may be used to indicate different levels of priority.
The TP 1512 may be mapped to a priority field in another protocol. For example, the TP 1512 may be mapped to an NRI of NAL or a DSCP of IETF. The TP 1512 may be mapped to a temporal_id field of NAL. The TP 1512 in the packet 1500 may provide an indication or explanation regarding how the field may be mapped to the other protocols. While the TP 1512 shown in Table 12 indicates that the TP 1512 may be mapped to the NRI of NAL, which may be included in H.264/AVC, the priority mapping scheme may be provided and/or used to support mapping to HEVC or any other video coding type.
The priority information described herein, such as the nal_priority_idc, may map to the corresponding packet header field so that the packet header may provide more detailed frame priority information. When H.264 AVC is used, this priority information TP 1512 may be mapped to the NRI value (e.g., 2-bit nal ref idc) in the NAL unit header. When HEVC is used, this priority information TP 1512 may be mapped to the temporalID value (e.g., nuh_temporal_id_plus1−1) in the NAL unit header.
In H.264 or HEVC, a majority of the frames may be B-frames. The temporal level information may be signaled in the packet header to distinguish frame priorities for the same B-frames in a hierarchical B structure. The temporal level may be mapped to the temporal ID, which may be in the NAL unit header, or derived from the coding structure if possible. Examples are provided herein for signaling the priority information to a packet header, such as the MMT packet header.
The frame priority flag 1564 may indicate whether the priority identifier field 1562 is being signaled. For example, the frame priority flag 1564 may be a one-bit field that may be switched to indicate whether the priority identifier field 1562 is being signaled or not (e.g., the frame priority flag 1564 may be set to ‘1’ to indicate that the priority identifier field 1562 is being signaled and may be set to ‘0’ to indicate that the priority identifier field 1562 is not being signaled). When a frame_priority_flag 1564 indicates that the priority identifier field 1562 is not being signaled, the TP field 1512 and/or the flow label 1514 may be formatted as shown in
The temporal_id in the MMT format may be mapped to the temporalID of NAL. The temporal_id in the MMT format may be included in a multi-layer information function (e.g., multiLayerInfo( )). The priority_id in MMT may be a priority identifier of the Media Fragment Unit (MFU). The priority_id may specify the video frame priority within the same temporal level. A Media Processing Unit (MPU) may include media data which may be independently and/or completely processed by an MMT entity and maybe consumed by the media codec layer. The MFU may indicate the format identifying fragmentation boundaries of a Media Processing Unit (MPU) payload to allow the MMT sending entity to perform fragmentation of MPU considering consumption by the media codec layer.
The temporal level field may be derived from the temporal ID of the header (e.g., 3-bit) of the frame carried in the MMT packet (e.g., the temporal ID of HEVC NAL header) or derived from the coding structure. The priority_idc may be derived from the supplementary information generated from the video encoder, streaming server, or the protocols and signals developed for the MANE. The priority_id and/or priority_idc may be used for the priority field of an MMT hint track and UEP of the MMT application level FEC as well.
An MMT package may be specified to carry complexity information of a current video bitstream as supplemental information. For example, a DCI table of an MMT may define the video_codec_complexity fields that may include video_average_bitrate, video_maximum_bitrate, horizontal_resolution, vertical_resolution, temporal_resolution, and/or video_minimum_buffer_size. Such video_codec_complexity fields may not be accurate and/or enough to present the video codec characteristics. This may be because different standard video coding bitstreams with the same resolution and/or bitrate may have different complexities. Parameters, such as video codec type, profile, level (e.g., which may be derived from embedded video packets or from the video encoder) may be added into the video_codec_complexity field. A decoding complexity level may be included in the video_codec_complexity fields to provide decoding complexity information.
Priority information may be implemented in 3GPP. For example, frame prioritization may apply to a 3GPP Codec. In 3GPP, rules may be provided for derivation of the authorized Universal Mobile Telecommunications System (UMTS) QoS parameters per Packet Data Protocol (PDP) context from authorized IP QoS parameters in a Packet Data Network-Gateway (P-GW). The traffic handling priority that may be used in 3GPP may be decided by QCI values. The priority may be derived from the priority information of MMT. The example priority information described herein may be used for the UEP described in 3GPP that may provide the detailed information of SVC-based UEP technology. As shown in
An IETF RTP Payload Format may implement frame prioritization as described herein.
The IETF may indicate that the value of the NRI field 1604 may be the maximum of the NAL units carried in the aggregation packet. As such, the NRI field of the RTP payload may be used in a similar manner as the priority_id field described herein. To implement a four-bit priority_id in a two-bit NRI field, the value of the four-bit priority_id may be divided by four to be assigned to the two-bit NRI field. Additionally, the NRI field may be occupied by a temporal ID of the HEVC NAL header, which may be able to distinguish the frame priority. The priority_id may be signaled in the RTP payload format for the MANE when such priority information may be derived.
The examples described herein may be implemented at an encoder and/or a decoder. For example, a video packet, including the headers, may be created and/or encoded at an encoder for transmission to a decoder for decoding, reading, and/or executing instructions based on the information in the video packet. Although features and elements are described above in particular combinations, each feature or element may be used alone or in any combination with the other features and elements. The methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.
This application claims the benefit of U.S. Provisional Patent Application No. 61/666,708, filed on Jun. 29, 2012, and U.S. Provisional Patent Application No. 61/810,563, filed on Apr. 10, 2013, the contents of which are incorporated by reference herein in their entirety.
| Number | Date | Country | |
|---|---|---|---|
| 61666708 | Jun 2012 | US | |
| 61810563 | Apr 2013 | US |
