TECHNIQUES FOR SIGNALING AND IDENTIFYING ACCESS UNIT BOUNDARIES CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority from U.S. Provisional Patent Application No.

62/980,659, filed February 24, 2020, and U.S. Patent Application No. 17/026,781, filed September 21, 2020, the entirety of which are incorporated herein.

FIELD

[0002] The disclosed subject matter relates to network protocol(s) for delivering video over IP network(s), and more specifically, to the signaling of access unit (frame) boundary information for supporting individual access of frame(s) in the video payload format.

BACKGROUND

[0003] Referring to FIG. 1, a network connected system may comprise one or more endpoints (101, 102, 103) communicating with each other over an IP network (104), such as the Internet, using real-time media such as voice, video, and/or other media. The system may further comprise one or more media-aware network element(s) (105) configured, for example, to manipulate the media sent by an endpoint before forwarding it to another endpoint.

[0004] In certain such system designs, the endpoint(s) and/or Mobile Ad-hoc Network

Emulator (MANE) may comprise a Real-time Transport Protocol (RTP) packetizer that sends RTP packets over a network to an RTP receiver located in, for example, another endpoint or MANE. In some cases, the sending endpoint may compromise a video camera, functionally coupled to a video encoder, which in turn may be coupled to the packetizer, such that video captured by the video camera may be transported using RTP packets from the sending endpoint, for example, endpoint (101), over the network (104) to a receiving endpoint for example 102). [0005] In some cases, the sending endpoint may not comprise a video encoder. Instead, video may be obtained from a file stored on a hard drive or the like (106) coupled to the endpoint

(101).

[0006] Certain real-time communication techniques for video over the Internet and other

IP networks may rely on the Real-Time Transport Protocol (RTP), specified in RFC 3550. In some cases, RTP packets may be transported over User Datagram Protocol (UDP) over IP from one endpoint or MANE to another. Referring to FIG. 2, shown is an RTP header structure as specified in RFC3550. Here, each RTP packet may start with the RTP packet header. FIG. 2 illustrates the format of the RTP header as specified in RFC3550.

[0007] As illustrated in Fig. 2, Version (V) field (201) may identify the version of RTP and may be equal to 2. The Padding (P) field (202) may specify whether the packet contains one or more additional padding octets at the end. The Extension (X) field (203) may indicate whether the fixed header is followed by exactly one header extension. The CSRC count (CC) field (204) may contain the number of CSRC identifiers that follows the fixed header. The Marker (M) field (205) may allow marking of significant events such as AU boundaries in the packet stream. The Payload Type (PT) field may indicate the payload type (206) — the type of media in use, such as video encoded according ITU-T Recommendation H.264 using RTP payload format RFC 6184 with a certain set of RFC3984 parameters. PT may be, in many cases, selected by a call control protocol. The RTP sequence number (207) may increase by one for each RTP packet being sent until wrap-around. The RTP timestamp (208) may be indicative of a time instant when the first sample of a packet has been sampled (capture time) and may commonly be used as a presentation time. The timestamp for at least some video codecs may be 90 kHz, whereas for many audio codecs, the timestamp may be equal to the sampling rate such as 8kHz, 44.1 kHz, or 48 kHz. The synchronization source (209) and contributing source (210) are introduced below. [0008] RTP may follow the general approach of application layer framing, and hence the adaptation to certain payloads, such as coded video formats specified according to certain video coding standards, can be specified by helper specifications outside of the main RTP specification known as RTP payload formats. Certain RTP payload formats may re-use the bits of the Network Abstraction Header, as present in certain video coding standards, such as H.264 or H.265, as their payload header. In such RTP payload formats and video coding standards, a Network Abstraction Layer Unit (NAL unit or NALU) may be a bitstream of finite size, covering one coded picture or a well-defined part thereof, such as, for example, a slice, tile, GOB, and so forth.

[0009] The bitstream can include, at its beginning, a comparatively short data structure of, for example 8 or 16 bits in length, that contains minimal information related to the type of the bitstream included and, in some scenarios, layering information.

[0010] At least some video coding standards recognize the concept of an Access Unit

(AU). In a single-layer case, an access unit can be composed of a single coded picture. In other cases, especially those related to layered coding and Multiview coding, an AU can comprise multiple coded pictures sharing certain timing information, for example having the same presentation time. [0011] The RTP header may include a so-called “Marker” bit (M-bit) (205). By convention, in substantially all RTP payload formats that recognize the concept of an AU, the M- bit is specified to equal to one, for the RTP packet carrying the last bitstream of the AU, and may otherwise to be set to zero. When a receiver receives the RTP packet with the M-bit set, it typically knows that this RTP packet is the last packet of an AU and can handle it accordingly. Some details of such handling can be found in the RTP specification.

[0012] Briefly referring again to FIG. 1, assuming that sending endpoint (101) obtains its sending video bitstream from storage device/hard drive (106), such file may not include easily accessible meta information concerning access unit boundaries, for example because the bitstream may be stored, for example, in a format commonly known as “Annex B bitstream”. In such a scenario, there may be no Application Programmer’s Interface (API) information from the encoder to the RTP packetizer available that signals that a bitstream of the bitstream is the final bitstream of an AU. Instead, an RTP packetizer may have to identify the bitstream that includes the end of an AU without side information usually obtainable by the encoder.

SUMMARY

[0013] Disclosed are techniques for signaling and identifying of access unit boundary in video RTP payload format.

BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Further features, the nature, and various advantages of the disclosed subject matter will be more apparent from the following detailed description and the accompanying drawings in which: [0015] FIG.l is a schematic illustration of a media transmission system using RTP.

[0016] FIG. 2 is a schematic illustration of a an RTP header.

[0017] FIG. 3 is a schematic illustration of a NAL Unit Header of VVC with a bit boundary embodiment.

[0018] FIG. 4 is a schematic illustration of a simplified block diagram access unit boundary detection.

[0019] Fig. 5 is a schematic illustration of a computer system in accordance with an embodiment.

PROBLEM TO BE SOLVED

[0020] The Real-time Transport Protocol (RTP), can be used in a communication system utilizing streaming media. An RTP payload format for carrying the video data compliant with coding standard ITU-T Recommendation [H.266] and ISO/IEC International Standard [IS023090-3], both also known as Versatile Video Coding (VVC), and developed by the Joint Video Experts Team (JVET), have recently received attention. The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload as well as fragmentation of a NAL unit into multiple RTP packets. The VVC video coding may be stored in a file as one long bitstream, without framing information beyond start codes. Without parsing substantially all details of this bistream, an RTP packetizer is unable to correctly set the M-bit as required by the RTP and RTP payload specifications.

DETAILED DESCRIPTION

[0021] In an embodiment, when the marker bit is set equal to 1, it may indicate that the current packet may be the last packet of the access unit (AU) in the current RTP stream. When the marker bit is set equal to 0, it may indicate that the current packet may not be the last packet of the access unit. Such use of the marker bit is in line with the common use of the marker bit in substantially all currently specified RTP payload formats for video.

[0022] Referring to FIG. 3, in the same or another embodiment, an VVC NAL unit header may be composed of two bytes (16 bits). Here, 5 bits represent the NAL unit type (304). As a result, there can be up to 32 types of NAL units. Video Coding Layer (VCL) NAL units can have a type in a numerical range between 0 and 12, and non-VCL NAL units can have a type in a range between 13 and 31. The forbidden zero bit (F-bit, 301) may be required to be set to zero for the prevention of start code emulation. The nuh -reserved-bit (Z-bit, 302), may be required to be set to zero and reserved for future extension by ITU and ISO/IEC. The nuh-layer-id (LayerlD, 303) may be used to identify the layer a NAL unit belongs to, such as a spatial scalable layer, or a quality scalable layer. The nal -unit-type (Type, 304) field may specify the NAL type and semantics based off VVC specification. The last nuh-temporal -id-plus 1 (TID, 305) field may be the value of Temporalld plus 1 since A TID value of 0 may be illegal. This is to ensure one NAL must at least be one bit for code emulation.

[0023] In the same or another embodiment, the content of a NAL unit may not tell whether or not the NAL unit is the last NAL unit, in decoding order, of an AU — at least not without parsing potentially many other NAL units. Accordingly, without side information, a packetizer cannot trivially obtain that information from the video bitstream in isolation In, for example, a real-time encoding context, an RTP sender implementation may obtain this information from the video encoder or other system element(s) through, for example, an API. However, there can be scenarios where no such API is available either, including the one mentioned above where an Annex B bitstream is stored on a hard drove before streaming. When this information cannot be explicitly obtained from the encoder or other system element, then the sender implementation may be required to interpret NAL unit headers (and potentially also the payload data of NAL units) in decoding in order to determine whether the NAL unit is the last NAL unit of an access unit. This and other novel techniques used to obtain such information are described below.

[0024] The Techniques for signaling and identifying the access unit boundary is illustrated in FIG.4. Referring to FIG 4, in the same or another embodiment, a NAL unit may be determined to be the last NAL unit of an AU if it is the last NAL unit of the bitstream.

[0025] Also referring to FIG.4, an embodiment is illustrated for determining if a NAL unit is the last NAL unit of an AU. Here, the process may begin (401) when there are two NAL units in the decoding queue (402): A nalX unit and nalY unit. Here, a goal is to decide if nalX is the last bitstream of an AU, or if the nalY is the beginning of the next AU. If the nalX unit is the last NAL unit of this bitstream (~d03), the conclusion may be made that nalX is the last NAL unit of the current AU (407). However, if that is not the case, the following process may proceed. [0026] Specifically, If the nalX is of a type of AUD_NUT (404), with a NAL unit type value 20, it is certain that the nalX is the last NAL unit of the current AU. If the nalX is not of the AUD_NUT NAL type, and the nalY has a picture header type unit, and also all the NAL units between nalX and nalY are of the parameter set or SEI NAL type, then it is determined that the nalX is the last NAL unit of the current AU, otherwise it is determined that the nalX is not a last NAL unit (406). [0027] A NAL unit naluX may also be determined to be the last NAL unit of an AU if both the following conditions are true: 1) the next VCL NAL unit naluY in the decoding order has a high-order bit of the first byte after its NAL unit header is equal to 1 or nal unit type (304) is equal to 19, and 2) all NAL units between naluX and naluY, when present, have a nal unit type (304) in the range of 13 to 17, inclusive, equal to 20, equal to 23 or equal to 26. [0028] In the same or a different embodiment, a NAL unit naluX may also be determined to be the last NAL unit of an access unit if both the following conditions are true: 1) the next VCL NAL unit naluY in the decoding order has a picture header in slice header flag equal to 1 in a slice segment header or the nal unit type is set equal to PH NUT, and 2) all NAL units between naluX and naluY, when present, have a nal unit type set equal to DCI NUT,

VPS NUT, SPS NUT, PPS NUT, PREFIX APS NUT, AUD NUT, PREFIX SEI NUT. [0029] In the same or another embodiment, a NAL unit naluX may also be determined to be the last NAL unit of an access unit, when the next VCL NAL unit naluY in the decoding order has a nal unit type equal to AUD NUT.

[0030] The techniques for identifying an Access Unit (AU) boundary in a coded video bitstream described above, can be implemented as computer software using computer-readable instructions and physically stored in one or more computer-readable media. For example, FIG. 5 shows a computer system 500 suitable for implementing certain embodiments of the disclosed subject matter.

[0031] The computer software can be coded using any suitable machine code or computer language, that may be subject to assembly, compilation, linking, or like mechanisms to create code comprising instructions that can be executed directly, or through interpretation, micro-code execution, and the like, by computer central processing units (CPUs), Graphics Processing Units (GPUs), and the like.

[0032] The instructions can be executed on various types of computers or components thereof, including, for example, personal computers, tablet computers, servers, smartphones, gaming devices, internet of things devices, and the like.

[0033] The computer software can be coded using any suitable machine code or computer language, that may be subject to assembly, compilation, linking, or like mechanisms to create code comprising instructions that can be executed directly, or through interpretation, micro-code execution, and the like, by computer central processing units (CPUs), Graphics Processing Units (GPUs), and the like.

[0034] The instructions can be executed on various types of computers or components thereof, including, for example, personal computers, tablet computers, servers, smartphones, gaming devices, internet of things devices, and the like.

[0035] The components shown in FIG. 5 for computer system — 500 are exemplary in nature and are not intended to suggest any limitation as to the scope of use or functionality of the computer software implementing embodiments of the present disclosure. Neither should the configuration of components be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary embodiment of a computer system 500.

[0036] Computer system 500 may include certain human interface input devices. Such a human interface input device may be responsive to input by one or more human users through, for example, tactile input (such as: keystrokes, swipes, data glove movements), audio input (such as: voice, clapping), visual input (such as: gestures), olfactory input (not depicted). The human interface devices can also be used to capture certain media not necessarily directly related to conscious input by a human, such as audio (such as: speech, music, ambient sound), images (such as: scanned images, photographic images obtain from a still image camera), video (such as two-dimensional video, three-dimensional video including stereoscopic video).

[0037] Input human interface devices may include one or more of (only one of each depicted): keyboard 501, mouse 502, trackpad 503, touch screen 510, data-glove 504, joystick 505, microphone 506, scanner 507, camera 508.

[0038] Computer system 500 may also include certain human interface output devices.

Such human interface output devices may be stimulating the senses of one or more human users through, for example, tactile output, sound, light, and smell/taste. Such human interface output devices may include tactile output devices (for example tactile feedback by the touch-screen 510, data-glove 504, or joystick 505, but there can also be tactile feedback devices that do not serve as input devices), audio output devices (such as: speakers 509, headphones (not depicted)), visual output devices (such as screens 510 to include CRT screens, LCD screens, plasma screens,

OLED screens, each with or without touch-screen input capability, each with or without tactile feedback capability — some of which may be capable to output two dimensional visual output or more than three dimensional output through means such as stereographic output; virtual-reality glasses (not depicted), holographic displays and smoke tanks (not depicted)), and printers (not depicted).

[0039] Computer system 500 can also include human accessible storage devices and their associated media such as optical media including CD/DVD ROM/RW 520 with CD/DVD or the like media 521, thumb-drive 522, removable hard drive or solid state drive 523, legacy magnetic media such as tape and floppy disc (not depicted), specialized ROM/ASIC/PLD based devices such as security dongles (not depicted), and the like.

[0040] Those skilled in the art should also understand that term “computer readable media” as used in connection with the presently disclosed subject matter does not necessarily encompass transmission media, carrier waves, or other transitory signals.

[0041] Computer system 500 can also include interface to one or more communication networks. Networks can for example be wireless, wireline, optical. Networks can further be local, wide-area, metropolitan, vehicular and industrial, real-time, delay-tolerant, and so on. Examples of networks include local area networks such as Ethernet, wireless LANs, cellular networks to include GSM, 3G, 4G, 5G, LTE and the like, TV wireline or wireless wide area digital networks to include cable TV, satellite TV, and terrestrial broadcast TV, vehicular and industrial to include CANBus, and so forth. Certain networks commonly require external network interface adapters that attached to certain general purpose data ports or peripheral buses (549) (such as, for example USB ports of the computer system 500; others are commonly integrated into the core of the computer system 500 by attachment to a system bus as described below (for example Ethernet interface into a PC computer system or cellular network interface into a smartphone computer system). Using any of these networks, computer system 500 can communicate with other entities. Such communication can be uni-directional, receive only (for example, broadcast TV), uni-directional send-only (for example CANbus to certain CANbus devices), or bi-directional, for example to other computer systems using local or wide area digital networks. Certain protocols and protocol stacks can be used on each of those networks and network interfaces as described above.

[0042] Aforementioned human interface devices, human-accessible storage devices, and network interfaces can be attached to a core 540 of the computer system 500.

[0043] The core 540 can include one or more Central Processing Units (CPU) 541,

Graphics Processing Units (GPU) 542, specialized programmable processing units in the form of Field Programmable Gate Areas (FPGA) 543, hardware accelerators for certain tasks 544, and so forth. These devices, along with Read-only memory (ROM) 545, Random-access memory 546, internal mass storage such as internal non-user accessible hard drives, SSDs, and the like 547, may be connected through a system bus 548. In some computer systems, the system bus 548 can be accessible in the form of one or more physical plugs to enable extensions by additional CPUs, GPU, and the like. The peripheral devices can be attached either directly to the core’s system bus 548, or through a peripheral bus 549. Architectures for a peripheral bus include PCI, USB, and the like.

[0044] CPUs 541, GPUs 542, FPGAs 543, and accelerators 544can execute certain instructions that, in combination, can make up the aforementioned computer code. That computer code can be stored in ROM 545 or RAM 546. Transitional data can be also be stored in RAM 546, whereas permanent data can be stored for example, in the internal mass storage 547. Fast storage and retrieve to any of the memory devices can be enabled through the use of cache memory, that can be closely associated with one or more CPU 541, GPU 542, mass storage 547,

ROM 545, RAM 546, and the like. [0045] The computer readable media can have computer code thereon for performing various computer-implemented operations. The media and computer code can be those specially designed and constructed for the purposes of the present disclosure, or they can be of the kind well known and available to those having skill in the computer software arts.

[0046] As an example and not by way of limitation, the computer system 500, and the core 540 can provide functionality as a result of processor(s) (including CPUs, GPUs, FPGA, accelerators, and the like) executing software embodied in one or more tangible, computer- readable media. Such computer-readable media can be media associated with user-accessible mass storage as introduced above, as well as certain storage of the core 540 that are of non- transitory nature, such as core-internal mass storage 547 or ROM 545. The software implementing various embodiments of the present disclosure can be stored in such devices and executed by core 540. A computer-readable medium can include one or more memory devices or chips, according to particular needs. The software can cause the core 540 and specifically the processors therein (including CPU, GPU, FPGA, and the like) to execute particular processes or particular parts of particular processes described herein, including defining data structures stored in RAM 546 and modifying such data structures according to the processes defined by the software. In addition or as an alternative, the computer system can provide functionality as a result of logic hardwired or otherwise embodied in a circuit (for example: accelerator 544), which can operate in place of or together with software to execute particular processes or particular parts of particular processes described herein. Reference to software can encompass logic, and vice versa, where appropriate. Reference to a computer-readable media can encompass a circuit (such as an integrated circuit (IC)) storing software for execution, a circuit embodying logic for execution, or both, where appropriate. The present disclosure encompasses any suitable combination of hardware and software.

[0047] While this disclosure has described several exemplary embodiments, there are alterations, permutations, and various substitute equivalents, which fall within the scope of the disclosure. It will thus be appreciated that those skilled in the art will be able to devise numerous systems and methods which, although not explicitly shown or described herein, embody the principles of the disclosure and are thus within the spirit and scope thereof.