Method, apparatus, and medium for auxiliary MPD for MPEG DASH to support pre-roll, mid-roll, and end-roll with stacking characteristics

Abstract

A method and apparatus may be provided for signaling audio media content over a DASH media stream. The method may include receiving one or more auxiliary descriptors, each of the one or more auxiliary descriptors including a Uniform Resource Locator (URL) that references one or more auxiliary media presentation descriptions (MPDs) and a stacking mode value that indicates a stacking operation supported by the main DASH media stream. The method may also include obtaining one or more auxiliary media segments based on the URL referenced in each of the one or more auxiliary descriptors; and playing the one or more auxiliary media segments and the one or more main DASH media segments at least once and in at least one order from a media source extension (MSE) source buffer based on the one or more auxiliary descriptors and the stacking mode value.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Provisional Patent Application No. 63 / 298,919, filed January 12, 2022, and U.S. Patent Application No. 18 / 065,154, filed December 13, 2022, the contents of which are expressly incorporated by reference in their entireties into this application.

[0002] Field Embodiments of the present disclosure are directed to streaming media content, and more particularly, to streaming media, advertisements, and live content that conforms to the Moving Picture Experts Group (MPEG) dynamic adaptive streaming over hypertext transfer protocol (DASH). [Background technology]

[0003] MPEG DASH provides a standard for streaming media content over IP networks. In MPEG DASH, media presentation descriptions (MPDs) and events are used to deliver media timeline related events to clients. The ISO / IEC 23009-1 DASH standard allows streaming of multi-rate content. The DASH standard provides a single linear timeline, where periods are continuations of each other in a single timeline. ISO / IEC 23009-1 also provides tools for MPD chaining, i.e., signaling the URL of the next MPD to be played in an MPD that can be used for pre-roll ad insertion.

[0004] MPEG DASH provides a standard for streaming multimedia content over IP networks. The standard deals with linear playback of media content, but the standard cannot address situations of non-linear behavior, for example, situations where media segments are associated with different timelines independent of each other. MPD chaining and pre-roll ad insertion can be used to overcome the above mentioned shortcomings.

[0005] However, when a DASH player uses the W3C Media Source Extensions, even MPD chaining and pre-roll ad insertion fails, since it is very difficult to deal with such non-linear playback using a single MSE source buffer.

[0006] Thus, there is a need for a method of combining auxiliary content that is distinct from or independent of the main media content. Specifically, there is a need for methods and apparatus for combining auxiliary content with the main media content as pre-roll, mid-roll, or end-roll playback. There is a need for a method of stacking auxiliary content. Additionally, there is a need for a method of conveying information related to the auxiliary content and stacking the information. Summary of the Invention [Problem to be solved by the invention]

[0007] The present disclosure addresses one or more technical problems. The present disclosure includes methods, processes, apparatus, and non-transitory computer-readable media for implementing a new concept: auxiliary presentations and auxiliary MPDs for the DASH standard that may allow describing a media presentation that is auxiliary or independent from a main media presentation. Embodiments of the present disclosure are also directed to auxiliary presentations that include auxiliary media content that may be presented as pre-roll, mid-roll, or end-roll content within other auxiliary presentations. Embodiments also relate to stacking multiple auxiliary presentations. [Means for solving the problem]

[0008] An embodiment of the present disclosure may provide a method for signaling chained auxiliary media content, including pre-roll media content, mid-roll media content, and end-roll media content, in a main Dynamic Adaptive Streaming over HTTP (DASH) media stream. The method may include receiving one or more auxiliary descriptors, each of the one or more auxiliary descriptors including a Uniform Resource Locator (URL) that references one or more auxiliary media presentation descriptions (MPDs) and a stacking mode value that indicates a stacking operation supported by the main DASH media stream; retrieving one or more auxiliary media segments based on the URL referenced in each of the one or more auxiliary descriptors, the one or more auxiliary media segments being independent from the one or more main DASH media segments; and playing the one or more auxiliary media segments and the one or more main DASH media segments at least once and in at least one order from a media source extension (MSE) source buffer based on the one or more auxiliary descriptors and the stacking mode value.

[0009] Embodiments of the present disclosure may provide an apparatus for signaling chained auxiliary media content, including pre-roll, mid-roll, and end-roll media content, in a main Dynamic Adaptive Streaming over HTTP (DASH) media stream, the apparatus may include at least one memory configured to store computer program code; and at least one processor configured to access the computer program code and operate as instructed by the computer program code. The program code may include: receiving code configured to cause the at least one processor to receive one or more auxiliary descriptors, each of the one or more auxiliary descriptors including a Uniform Resource Locator (URL) that references one or more auxiliary media presentation descriptions (MPDs) and a stacking mode value that indicates a stacking operation supported by a main DASH media stream; acquiring code configured to cause the at least one processor to acquire one or more auxiliary media segments based on the URL referenced in each of the one or more auxiliary descriptors, the one or more auxiliary media segments being independent from the one or more main DASH media segments; and playing code configured to cause the at least one processor to play the one or more auxiliary media segments and the one or more main DASH media segments from a Media Source Extension (MSE) source buffer at least once in at least one order based on the one or more auxiliary descriptors and the stacking mode value.

[0010] An embodiment of the present disclosure may provide a non-transitory computer-readable medium storing instructions that, when executed by one or more processors of a device for signaling chained auxiliary media content including pre-roll media content, mid-roll media content, and end-roll media content in a main Dynamic Adaptive Streaming over HTTP (DASH) media stream, may include the steps of receiving, by the one or more processors, one or more auxiliary descriptors, each of the one or more auxiliary descriptors including a Uniform Resource Locator (URL) that references one or more auxiliary media presentation descriptions (MPDs) and a stacking operation that indicates a stacking operation supported by the main DASH media stream. and a stacking mode value; obtaining one or more auxiliary media segments based on a URL referenced in each of the one or more auxiliary descriptors, the one or more auxiliary media segments being independent from the one or more main DASH media segments; and playing the one or more auxiliary media segments and the one or more main DASH media segments from a media source extension (MSE) source buffer at least once in at least one order based on the one or more auxiliary descriptors and the stacking mode value. [Brief description of the drawings]

[0011] Further features, nature and various advantages of the disclosed subject matter will become more apparent from the following detailed description and the accompanying drawings. [Figure 1] 1 is a simplified diagram of a communication system according to an embodiment.

[0012] [Diagram 2] FIG. 2 is an exemplary diagram of an arrangement of components in a streaming environment, according to an embodiment.

[0013] [Diagram 3] FIG. 1 is a simplified block diagram of a DASH processing model, according to an embodiment.

[0014] [Figure 4] FIG. 1 illustrates an exemplary flowchart diagram for signaling chained auxiliary media content including pre-roll, mid-roll, and end-roll media content within a main Dynamic Adaptive Streaming over HTTP (DASH) media stream according to an embodiment.

[0015] [Diagram 5] 1 is a simplified diagram of a computer system according to an embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0016] The proposed features discussed below may be used separately or combined in any order. Furthermore, the embodiments may be implemented by processing circuitry (e.g., one or more processors or one or more integrated circuits). In one example, the one or more processors execute a program stored on a non-transitory computer-readable medium.

[0017] 1 illustrates a simplified block diagram of a communication system 100 according to an embodiment of the present disclosure. The communication system 100 may include at least two terminals 102 and 103 interconnected via a network 105. For a unidirectional transmission of data, a first terminal 103 may encode video data at a local location for transmission to the other terminal 102 via the network 105. A second terminal 102 may receive the encoded video data of the other terminal from the network 105, decode the encoded data, and display the recovered video data. Unidirectional data transmission may be common in media serving applications, etc.

[0018] 1 shows a second pair of terminals 101 and 104 provided to support bidirectional transmission of encoded video, such as may occur during a video conference. For the bidirectional transmission of data, each terminal 101 and 104 may encode video data captured at a local location for transmission to the other terminal over network 105. Each terminal 101 and 104 may also receive encoded video data transmitted by the other terminal, may decode the encoded data, and may display the recovered video data on a local display device.

[0019] In FIG. 1, terminals 101, 102, 103, and 104 may be depicted as servers, personal computers, and smartphones, although the principles of the present disclosure are not so limited. Embodiments of the present disclosure find application in laptop computers, tablet computers, media players, and / or dedicated video conferencing equipment. Network 105 represents any number of networks that convey encoded video data between terminals 101, 102, 103, and 104, including, for example, wired and / or wireless communication networks. Network 105 may exchange data in circuit-switched and / or packet-switched channels. Representative networks include telecommunications networks, local area networks, wide area networks, and / or the Internet. For purposes of the present discussion, the architecture and topology of network 105 may not be important to the operation of the present disclosure unless otherwise described herein below.

[0020] 2 shows, by way of example, the arrangement of video encoders and decoders in a streaming environment. Embodiments may be applicable to other video-enabled applications including, for example, video conferencing, digital TV, storage of compressed video on digital media including CDs, DVDs, memory sticks, etc.

[0021] The streaming system may include a video source 201, a capture subsystem 203 that may include, for example, a digital camera, that creates an uncompressed video sample stream 213. The sample stream 213 may be emphasized as a high amount of data when compared to an encoded video bitstream and may be processed by an encoder 202 coupled to the video source 201. The encoder 202 may include hardware, software, or a combination thereof to enable or implement aspects of the embodiments as described in more detail below. The encoded video bitstream 204 may be emphasized as a lower amount of data compared to the sample stream and may be stored on the streaming server 205 for future use. One or more streaming clients 212 and 207 may access the streaming server 205 to obtain encoded video bitstreams 208 and 206, which may be copies of the encoded video bitstream 204. The client 212 may include a video decoder 211 that decodes the incoming copy of the encoded video bitstream 208 and creates an outgoing video sample stream 210 that may be rendered on a display 209 or other rendering device. In some streaming systems, the encoded video bitstreams 204, 206, and 208 may be encoded according to some video encoding / compression standard, examples of which are mentioned above and further described herein.

[0022] 3 illustrates a sample DASH processing model 300, such as a sample client architecture for processing DASH and CMAF events. In the DASH processing model 300, a client's requests for media segments (e.g., advertisement media segments and live media segments) can be based on addresses described in a manifest 303. The manifest 303 also describes the metadata tracks from which the client can access the segments of the metadata tracks, parse them, and send them to the application 301.

[0023] The manifest 303 contains the MPD event(s), and the in-band event and "moof" parser 306 can parse the MPD event segment(s) and append the event segments to the event and metadata buffer 330. The in-band event and "moof" parser 306 may also fetch media segments and append them to the media buffer 340. The event and metadata buffer 330 can send event and metadata information to an event and metadata synchronizer and dispatcher 335. The event and metadata synchronizer and dispatcher 335 can dispatch certain events to the DASH player control, selection, and heuristic logic 302 and dispatch application related event and metadata tracks to the application 301.

[0024] According to some embodiments, the MSE may include a pipeline including a file format parser 350, a media buffer 340, and a media decoder 345. The MSE 320 is a logical buffer(s) of media segments, where the media segments may be tracked and ordered based on the presentation time of the media segments. The media segments may include, but are not limited to, advertisement media segments associated with an advertisement MPD and live media segments associated with a live MPD. Each media segment may be added or appended to the media buffer 340 based on a timestamp offset of the media segment, where the timestamp offset may be used to order the media segments in the media buffer 340.

[0025] Since embodiments of the present application may be directed to constructing a linear Media Source Extension (MSE) buffer from two or more non-linear media sources using MPD chaining, where the non-linear media sources may be an advertising MPD and a live MPD, the file format parser 350 may be used to handle different media and / or codecs used by the live media segments included in the live MPD. In some embodiments, the file format parser may issue a change type based on the codec, profile, and / or level of the live media segments.

[0026] As long as a media segment is present in the media buffer 340, the event and metadata buffer 330 maintains the corresponding event segment and metadata. The exemplary DASH processing model 300 may include a timed metadata track parser 325 for tracking metadata associated with in-band events and MPD events. According to FIG. 3, the MSE 320 includes only a file format parser 350, a media buffer 340, and a media decoder 345. The event and metadata buffer 330 and the event and metadata synchronizer and dispatcher 335 are not native to the MSE 320, which prohibits the MSE 320 from natively processing events and sending them to applications.

[0027] auxiliary presentation

[0028] Embodiments of the present disclosure define an auxiliary media presentation to be a media presentation that is independent of the main media presentation of the MPD. As an example, an advertisement media segment or a live media segment that is independent of the main media segment may be an auxiliary presentation. Any auxiliary media presentation or updates to the auxiliary media segment do not affect the main media segment. Similarly, updates to the main media segment do not affect the auxiliary media segment. Thus, an auxiliary media segment (also referred to as an auxiliary media presentation or auxiliary presentation) may be completely independent of the main media segment (also known in this disclosure as a main media presentation and a media presentation).

[0029] Auxiliary MPD

[0030] An MPD is a media presentation description that may contain a media presentation in a hierarchical organization. An MPD may contain one or more sequences of periods, and each period may contain one or more adaptation sets. Each adaptation set in an MPD may contain one or more representations, and each representation contains one or more media segments. These one or more media segments carry the actual media data and associated metadata being encoded, decoded, and / or played. An auxiliary MPD may contain one or more auxiliary media segments.

[0031] As mentioned above, embodiments of the present disclosure define auxiliary MPDs that represent auxiliary content independent of the main media content. According to an aspect, the main MPD may include a reference to at least one MPD, or in some embodiments, each auxiliary MPD, using an auxiliary descriptor. The auxiliary descriptor may have a particular syntax. As an example, the auxiliary descriptor may include a descriptor known as a mandatory descriptor, or may include a descriptor known as a supplemental descriptor, which may describe or identify the auxiliary MPD.

[0032] According to an aspect of the disclosure, the main MPD may include URL links to one or more auxiliary MPDs, the auxiliary MPD having references to one or more auxiliary media content. A departure point during playback of the main MPD may be configured. A departure point may be a point at which the auxiliary media segment is played by departing from the main media segment. In some embodiments, the departure point may be before the start of the main media segment or the current auxiliary media segment. This may be referred to as pre-roll playback. In some embodiments, the departure point may be at the end of the current auxiliary media segment or the main media segment. This may be referred to as end-roll playback. In some embodiments, the departure point may be any point during playback of the main media segment or the current media segment. This may be referred to as mid-roll playback. In some embodiments, the mid-roll playback may be indicated using an offset indicating a departure point from a currently available start time for the main media segment.

[0033] Rejoin points during playback may also be configured. In some embodiments, the rejoin point may be at the end of playback of one or more auxiliary media segments. In some embodiments, the rejoin point may be at a live edge of the main media segment. In some embodiments, the rejoin point may be at the departure point where the main media segment was stopped. In some embodiments, the rejoin point may be after a certain duration from the departure point where the main media segment was stopped.

[0034] In embodiments where one or more auxiliary MPDs are stacked, i.e., one or more MPDs are played in sequence, multiple stacking modes may be supported by the main MPD. These stacking modes may execute or process the MPDs in a particular order or manner, and may be referred to as stacking operations. The first stacking mode may be a "unidirectional" mode. In this stacking mode, the MPD of the first URL in the stack (the main MPD) is played after the MPD of the last URL is played. In some embodiments, the MPDs in a stack of MPDs, including the main MPD and auxiliary MPDs, may be played in the order in which they should be presented. An example of a unidirectional mode is MPD1 → MPD2 → ... → MPDn → MPD1, where MPDn is the nth MPD, starting with n=0 for the main MPD and n>0 for the auxiliary MPDs.

[0035] A second stacking mode may be a "play once" mode. In the play once mode, the MPD of each URL in the stack is played only once, and when going back in the stack, if that URL has already been played, chaining and / or stacking is not considered again. An example of a play once mode is MPD1 → MPD2 → MPD3 → MPD2 → MPD1, where MPDn is the nth MPD, starting with n=0 for the main MPD and n>0 for the auxiliary MPDs. A third stacking mode may be a "play every time" mode. In the play every time mode, each auxiliary descriptor (also called a chaining descriptor) may be re-evaluated at each stack level, regardless of the playing of the stack. An example of a play every time mode is MPD1 → MPD2 → MPD3 → MPD2 → MPD3 → MPD2 → MPD3, where MPDn is the nth MPD, starting with n=0 for the main MPD and n>0 for the auxiliary MPDs.

[0036] According to an aspect of the present disclosure, auxiliary MPD support for the main MPD may be signaled and implemented using mandatory or supplemental descriptors. The descriptors may be signaled at the MPD level. [Table 1]

[0037] According to an aspect of the present disclosure, the auxiliary MPD support may be implemented using MPD events. In this embodiment, event stream semantics may be used. [Table 2] [Table 3] TIFF0007658660000004.tif135170

[0038] According to one aspect, the event scheme may be in on_receive dispatch mode since the alternate MPD needs to be downloaded before the presentationTime of the event. In some embodiments, the event instances may be repeated at various periods, particularly if pre-roll playback is desired along with playback of any period. If only one pre-roll playback is desired (i.e., the pre-roll at the beginning of playback of the first period played) even if the player plays multiple periods, then the equivalency rule may be applied to all event instances across periods representing that pre-roll playback.

[0039] An embodiment of the present disclosure relates to a method for signaling auxiliary media presentations from a main media presentation defined in an MPD for inserting pre-roll, mid-roll, and end-roll auxiliary media content in the media presentation, where the auxiliary MPD URL, the leave and rejoin times, and stacking behavior between various levels of auxiliary MPD are signaled. In some embodiments, the main content may be left at the beginning, middle, or end before the start of its playback. In some embodiments, after playing the auxiliary content or a particular duration thereof, the player may be instructed to continue playing the main content from the point where it was interrupted, from the current time, or any time in between. When a sequence of auxiliary MPDs is present, various stacking operation modes supported may also be signaled.

[0040] In some embodiments, auxiliary mod support may be signaled using mandatory or supplemental descriptors at the MPD level, which in some embodiments include the required information for leaving and rejoining the main media content playback, as well as the auxiliary MPD URL.

[0041] In some embodiments, auxiliary mod support may be signaled using MPD events. These MPD events contain all the information needed to leave and rejoin the main media content playback, as well as the auxiliary MPD URL. Additionally, in some embodiments, repeating equivalent and non-equivalent events may be used with varying periodicity based on the playback of the auxiliary media content.

[0042] FIG. 4 illustrates an example flowchart of a process 400 for signaling chained auxiliary media content, including pre-roll media content, mid-roll media content, and end-roll media content, in a main Dynamic Adaptive Streaming over HTTP (DASH) media stream.

[0043] At operation 410, one or more auxiliary descriptors may be received. In an embodiment, each auxiliary descriptor of the one or more auxiliary descriptors may include a Uniform Resource Locator (URL) that references one or more auxiliary MPDs and a stacking mode value that indicates stacking operations supported by the main DASH media stream.

[0044] In some embodiments, the stack mode value may include a first stack mode value that may indicate a circular replay or ordered playback of the one or more auxiliary media segments in a stack. A second stack mode value may indicate playing an auxiliary media segment of the one or more auxiliary media segments in a stack only once. A third stack mode value may indicate that an auxiliary descriptor of the one or more auxiliary descriptors is evaluated at each level of a stack. As an example, the first stack mode value may be "oneWay", the second stack mode value may be "playOnce", and the third stack mode value may be "playEverytime".

[0045] In some embodiments, the one or more auxiliary descriptors further include departure information and rejoining information. The departure information may include a first value for playing the one or more auxiliary media segments. The first value may be relative to an MPD availability start time (AST) of a main MPD. In some embodiments, the departure information may include a first departure value indicating that the one or more auxiliary media segments are played immediately upon acquisition. As an example, the first departure value may be 0. A second departure value may indicate that the one or more auxiliary media segments are played at an end of a current MPD, where the current MPD may be the main MPD or one of the auxiliary MPDs of the one or more auxiliary MPDs. As an example, the second departure value may be end. A third departure value may indicate that the one or more auxiliary media segments are played at a particular offset from an MPD availability start time. As an example, the third departure value may be an offset time.

[0046] The rejoining information may include a second value for rejoining to the main MPD. The first rejoining value may indicate a return to the main MPD upon a departure from the main MPD to one or more auxiliary MPDs. The first rejoining value may be 0. The second rejoining value may indicate a return to the main MPD at the end of the one or more auxiliary MPDs. The second rejoining value may be end. The third rejoining value may indicate a return to a live edge of the main MPD, which may be live. The fourth rejoining value may indicate a return to the main MPD at a certain offset of the departure time from the main MPD to the one or more auxiliary MPDs. The fourth rejoining value may be a certain offset time relative to the MPD AST.

[0047] At operation 415, one or more auxiliary media segments may be obtained based on a URL referenced in each of the one or more auxiliary descriptors. The one or more auxiliary media segments may be separate from the one or more main DASH media segments.

[0048] At operation 420, the one or more auxiliary media segments and the one or more main DASH media segments may be played from a media source extension (MSE) source buffer based on the one or more auxiliary descriptors and a stack mode value.

[0049] In some embodiments, the one or more auxiliary descriptors may be signaled in a mandatory descriptor at the MPD level or a supplemental descriptor at the MPD level. In some embodiments, the one or more auxiliary descriptors may be signaled as an MPD event. An MPD event may have an event type with an on_receive dispatch mode. In some embodiments, an MPD event may have an equivalence rule that applies to all instances of an MPD event. In some embodiments, an MPD event may have an equivalence rule that applies to a particular instance of an MPD event. [i.e., one or more separate instances] An MPD event may include leave information, rejoin information, and a stack mode value.

[0050] 4 illustrates example blocks of process 400, in embodiments, process 400 may include additional, fewer, different, or differently arranged blocks than those illustrated in FIG 4. In embodiments, any of the blocks of process 400 may be combined or arranged in any amount or order as desired. In embodiments, two or more of the blocks of process 400 may be performed in parallel.

[0051] The techniques described above may be implemented as computer software using computer readable instructions, physically stored on one or more computer readable media, or implemented by one or more specially configured hardware processors. For example, Figure 5 illustrates a computer system 500 suitable for implementing various embodiments.

[0052] The computer software can be coded using any suitable machine code or computer language that can be subjected to assembly, compilation, linking, or similar mechanisms to create code containing instructions that can be executed by a computer central processing unit (CPU), graphics processing unit (GPU), etc., directly, or through interpretation, microcode execution, etc.

[0053] The instructions may be executed on various types of computers or components thereof including, for example, personal computers, tablet computers, servers, smart phones, gaming devices, Internet of Things devices, and the like.

[0054] 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 the embodiments of the present disclosure. Neither the arrangement of components should be interpreted as having any dependency or requirement regarding any one or combination of components illustrated in the exemplary embodiment of computer system 500.

[0055] The computer system 500 may include certain human interface input devices that may respond to input by one or more human users through, for example, tactile input (e.g., keystrokes, swipes, data glove movements), audio input (e.g., voice, clapping), visual input (e.g., gestures), and olfactory input. Human interface devices may also be used to capture certain media that are not necessarily directly related to conscious human input, such as audio (e.g., speech, music, ambient sounds), images (e.g., scanned images, photographic images obtained from still image cameras), and video (e.g., two-dimensional video, three-dimensional video including stereoscopic video).

[0056] The input human interface devices may include one or more of a keyboard 501, a mouse 502, a trackpad 503, a touch screen 510, a joystick 505, a microphone 506, a scanner 507, and a camera 508 (only one of each is shown).

[0057] The computer system 500 may also include some type of human interface output device. Such human interface output devices may stimulate one or more of the human user's senses, for example, through haptic output, sound, light, and smell / taste. Such human interface output devices may include haptic output devices (e.g., haptic feedback via a touch screen 510 or joystick 505; however, there may be haptic feedback devices that do not act as input devices), audio output devices (e.g., speakers 509, headphones), visual output devices (e.g., screens 510, including CRT screens, LCD screens, plasma screens, OLED screens; each may or may not have touch screen input capabilities, each may or may not have haptic feedback capabilities, some of which may output two-dimensional visual output or higher than three-dimensional output through means such as stereoscopic output; virtual reality glasses, holographic displays, and smoke tanks), and printers.

[0058] The computer system 500 may also include human accessible storage and associated media, such as optical media including CD / DVD 511 or similar media along with CD / DVD ROM / RW 520, thumb drives 522, removable hard drives or solid state drives 523, legacy magnetic media such as tapes and floppy disks, specialized ROM / ASIC / PLD based devices such as security dongles, etc.

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

[0060] The computer system 500 may also include an interface 599 to one or more communication networks 598. The network 598 may be, for example, wireless, wired, optical. The network 598 may further be local, wide area, metropolitan, in-vehicle and industrial, real-time, delay tolerant, etc. Examples of networks 598 include Ethernet, WLAN, cellular networks including GSM, 3G, 4G, 5G, LTE, etc., TV wired or wireless wide area digital networks including cable television, satellite television, terrestrial broadcast television, in-vehicle and industrial including CANBus, etc. Some networks 598 typically require an external network interface adapter that is attached to some general purpose data port or peripheral bus (750 or 551) (e.g., USB port of the computer system 500, etc.). Others are typically integrated into the core of the computer system 500 by attachment to a system bus as described below (e.g., an Ethernet interface to a PC computer system or a cellular network interface to a smartphone computer system). Using any of these networks 598, computer system 500 can communicate with other entities. Such communications may be unidirectional, receive only (e.g., broadcast television), unidirectional transmit only (e.g., CANbus to certain CANbus devices), or bidirectional, for example, to other computer systems using local or wide area digital networks. Certain protocols and protocol stacks may be used with each of these networks and network interfaces as described above.

[0061] The aforementioned human interface devices, human accessible storage, and network interfaces may be attached to the core 540 of the computer system 500.

[0062] The core 540 may include one or more central processing units (CPUs) 541, graphics processing units (GPUs) 542, graphics adapters 517, specialized programmable processing units in the form of field programmable gate arrays (FPGAs) 543, hardware accelerators for certain tasks 544, etc. These devices may be connected through a system bus 548, along with read only memory (ROM) 545, random access memory 546, and internal mass storage device 547 such as an internal non-user accessible hard drive, SSD, etc. In some computer systems, the system bus 548 may be accessible in the form of one or more physical plugs to allow expansion with additional CPUs, GPUs, etc. Peripheral devices may be attached directly to the core's system bus 548 or through a peripheral bus 551. Architectures for peripheral buses include PCI, USB, etc.

[0063] The CPU 541, GPU 542, FPGA 543, and accelerator 544 may execute certain instructions that may combine to constitute the computer code described above. The computer code may be stored in ROM 545 or RAM 546. Temporary data may also be stored in RAM 546, while persistent data may be stored, for example, in internal mass storage device 547. Rapid storage and retrieval to any of the memory devices may be enabled through the use of cache memory, which may be closely associated with one or more of the CPU 541, GPU 542, mass storage device 547, ROM 545, RAM 546, etc.

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

[0065] As a non-limiting example, the illustrated architecture, specifically computer system 500 having core 540, may provide functionality as a result of processors (including CPUs, GPUs, FPGAs, accelerators, etc.) executing software embodied in one or more tangible computer readable media. Such computer readable media may be user accessible mass storage as introduced above as well as media associated with some storage of core 540 of a non-transitory nature such as core internal mass storage 547 or ROM 545. Software implementing various embodiments of the present disclosure may be stored in such devices and executed by core 540. Computer readable media may include one or more memory devices or chips depending on particular needs. The software may cause core 540, and specifically the processors therein (including CPUs, GPUs, FPGAs, etc.) to execute certain processes or certain portions of certain processes described herein, including defining data structures stored in RAM 546 and modifying such data structures according to processes defined by the software. Additionally or alternatively, a computer system may provide functionality as a result of logic hardwired or otherwise embodied in circuitry (e.g., accelerator 544), which may operate in place of or together with software to perform particular processes or portions of particular processes described herein. Reference to software includes logic, and vice versa, as appropriate. Reference to a computer-readable medium may encompass circuitry (e.g., an integrated circuit (IC)) that stores software for execution, circuitry that embodies logic for execution, or both, as appropriate. The present disclosure encompasses any suitable combination of hardware and software.

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

Claims

1. 1. A processor-implemented method for signaling chained auxiliary media content over a Dynamic Adaptive Streaming over Hypertext Transfer Protocol (DASH) media stream, the method comprising: receiving one or more auxiliary descriptors, each of the one or more auxiliary descriptors including a Uniform Resource Locator (URL) referencing one or more auxiliary Media Presentation Descriptions (MPDs) and a stacking mode value indicating a stacking operation supported by the main DASH media stream; retrieving one or more auxiliary media segments based on a URL referenced in each of the one or more auxiliary descriptors, the one or more auxiliary media segments being separate from the one or more main DASH media segments; and playing the one or more auxiliary media segments and the one or more main DASH media segments at least once and in at least one order from a media source extension (MSE) source buffer based on the one or more auxiliary descriptors and the stacking mode value; The stack mode value is: a first stack mode value indicating circular or ordered playback of the one or more auxiliary media segments in a stack; a second stack mode value indicating to play an auxiliary media segment of the one or more auxiliary media segments in the stack only once; and a third stack mode value indicating that an auxiliary descriptor of the one or more auxiliary descriptors is evaluated at each level of the stack. Contains one of the following: method.

2. A processor-implemented method for signaling chained auxiliary media content over a Dynamic Adaptive Streaming over Hypertext Transfer Protocol (DASH) media stream, the method comprising: receiving one or more auxiliary descriptors, each of the one or more auxiliary descriptors including a Uniform Resource Locator (URL) referencing one or more auxiliary Media Presentation Descriptions (MPDs) and a stacking mode value indicating a stacking operation supported by the main DASH media stream; retrieving one or more auxiliary media segments based on a URL referenced in each of the one or more auxiliary descriptors, the one or more auxiliary media segments being separate from the one or more main DASH media segments; and playing the one or more auxiliary media segments and the one or more main DASH media segments at least once and in at least one order from a media source extension (MSE) source buffer based on the one or more auxiliary descriptors and the stacking mode value; The one or more auxiliary descriptors further include: leaving information, the leaving information including a first value for playing the one or more auxiliary media segments, the first value being a value for an MPD Availability Start Time (AST) of a main MPD; rejoin information, the rejoin information including a second value for rejoining to the main MPD. method.

3. The withdrawal information: a first departure value indicating that the one or more auxiliary media segments are to be played immediately upon acquisition; a second departure value indicating that the one or more auxiliary media segments are to be played at an end of a current MPD, the current MPD being one of the main MPD and the one or more auxiliary MPDs; and a third departure value indicating that the one or more auxiliary media segments are played at a particular offset from the MPD availability start time. The method of claim 2 , comprising one of:

4. The rejoining information includes: a first rejoining value indicative of a return to the main MPD at a leaving time from the main MPD to the one or more auxiliary MPDs; a second rejoin value indicating a return to the main MPD at the end of the one or more auxiliary MPDs; a third rejoin value indicating a return to a live edge of the main MPD; and a fourth rejoining value indicating a return to the main MPD at an offset of the leaving time from the main MPD to the one or more auxiliary MPDs. The method of claim 2 , comprising one of:

5. The method of claim 1 , wherein the one or more auxiliary descriptors are signaled in a mandatory descriptor at an MPD level or a supplemental descriptor at the MPD level.

6. The method of claim 1 , wherein the one or more auxiliary descriptors are signaled as an MPD event.

7. The method of claim 6 , wherein the MPD event has an event scheme with an on_receive dispatch mode.

8. The method of claim 6 , wherein the MPD event has an equivalence rule that applies to all instances of the MPD event.

9. The method of claim 6 , wherein the MPD event has an equivalence rule that applies to one or more individual instances, but not all, of the MPD event.

10. The method of claim 6 , wherein the MPD events include leave information, rejoin information, and the stack mode value.

11. Apparatus configured to carry out the method according to any one of claims 1 to 10.

12. A storage medium storing a computer program for causing a computer to execute the method according to any one of claims 1 to 10.

Images