In-Inventory Update Event

Abstract

The present disclosure relates to methods, apparatuses, and storage media for video streaming. An apparatus includes computer code configured to cause one or more processors to perform: publishing media presentation description data including main live program data; and signaling, to a client device, advertisement data and in-manifest data, wherein the advertisement data indicates an initial end time at which the client device ends display of an advertisement by switching display at the client device from the advertisement to the main live program data, and wherein the in-manifest data indicates that the client device determines, during streaming of the advertisement to the client device, an updated end time before the end time at which the client device ends the streaming of the advertisement by switching the streaming at the client device from the advertisement to the main live program data.

Description

[0001] Cross-references to related applications

[0002] This application claims priority to provisional application US62 / 897,228, filed September 6, 2019, and U.S. application No. 17 / 008,898, filed September 1, 2020, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure relates to signaling to streaming clients an in-list update event that necessitates an in-list update. Background Technology

[0004] In HTTP-based Dynamic Adaptive Streaming (DASH), such as in MPEG-DASH, in-band Media Presentation Description (MPD) validity expiration events can be used to signal to clients that the manifest needs to be updated. However, because in-band events are even bound to media segments, such events can only be received from the server providing the content. Therefore, when a client is streaming content from a separate server (e.g., an ad server), the main server cannot add in-band events to media segments originating from the separate server, resulting in a technical drawback.

[0005] During live content streaming, advertisements may be inserted at certain times (e.g., during ad-breaks). The nominal duration of the ad is determined by the content server and inserted into the manifest. During this time, the client switches to the ad server and streams and / or replays the ad. When, for example, during a live content event, the ad server must serve the ad content for the exact duration indicated in the original manifest, and in practice, the live server may want to terminate the ad early because the event resumes from where it was interrupted, so the client needs to stop streaming the ad and switch back to the live content, which complicates matters. However, since in-band MPD validity expiration events are included in the media segment, and since the client does not stream content from the live server at least during the ad period, even if the live server inserts an MPD validity event, the client will not receive the update for at least the reasons mentioned above.

[0006] Therefore, technical solutions are needed to address these problems. Summary of the Invention

[0007] The methods and apparatus presented herein can be used individually or in any combination in any order. Furthermore, each of the features, encoders, and decoders can 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-volatile computer-readable medium.

[0008] This disclosure also introduces an in-list event, equivalent to an in-band MPD validity expiration event, and other aspects inserted into the MPD. This in-list event may have the same properties as the in-band MPD validity expiration event, and therefore the DASH client can process the in-list event in a certain way. How to use the in-list event for early termination of any ad in pre-roll and mid-roll ads is also disclosed herein.

[0009] This includes a method and an apparatus comprising a memory and one or more processors, the memory being configured to store computer program code, and the processors being configured to access and operate in accordance with the computer program code. The computer program code includes publishing code configured to cause at least one processor to publish Media Presentation Description Data (MPD) including main live program data, and signaling code configured to cause at least one processor to signal to a client device advertising data and in-list data, wherein the advertising data indicates an initial end time for the client device, at which the display of the advertisement ends by switching the display at the client device from the advertisement to the main live program data, and wherein the in-list data indicates an updated end time for the client device prior to the initial end time during the advertisement streaming to the client device, at which the streaming of the advertisement ends by switching the streaming at the client device from the advertisement to the main live program data.

[0010] According to an exemplary embodiment, signaling the client device to the advertising data and the list of data includes instructing the client device to transmit the advertising stream as an in-stream advertisement between segments of the main live program data.

[0011] According to an exemplary embodiment, signaling the client device to the advertising data and the list data further includes: instructing the client device to switch from the source server providing the main live program data to an advertising server separate from the source server, and obtaining the in-roll ad from the advertising server.

[0012] According to an exemplary embodiment, the data in the manifest includes the following instructions: the client device determines the end time of the update by accessing a remote element during the streaming of the in-roll advertisement by the client device, and determines whether the remote element indicates the end time of the update.

[0013] According to an exemplary embodiment, the data in the manifest includes further instructions: the client device accesses the remote element at a predetermined frequency before the end time.

[0014] According to an exemplary embodiment, the instructions in the inventory data instruct the client device to access the remote element via xlink data.

[0015] According to an exemplary embodiment, signaling the client device to the advertising data and the list of data includes instructing the client device to transmit the advertising stream as a pre-roll ad before streaming the main live program data.

[0016] According to an exemplary embodiment, the data in the manifest includes the following instructions: the client device determines the end time of the update by accessing a remote element during the streaming of the pre-roll ad by the client device, and determines whether the remote element indicates the end time of the update.

[0017] According to an exemplary embodiment, the data in the manifest includes further instructions: the client device accesses the remote element at a predetermined frequency before the end time. Attached Figure Description

[0018] Other features, properties, and various advantages of the disclosed subject matter will become further apparent from the following detailed description and accompanying drawings, wherein:

[0019] Figures 1 to 5 This is an illustrative description based on the illustrations of an embodiment.

[0020] Figure 6 and Figure 7 This is a simplified flowchart based on an embodiment.

[0021] Figure 8 This is an illustrative description based on the illustrations of an embodiment. Detailed Implementation

[0022] The features discussed below can be used individually or in any combination in any order. Furthermore, embodiments can 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-volatile computer-readable medium.

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

[0024] Figure 1 The illustration shows a second pair of terminals 101 and 104, which are provided to support bidirectional transmission of encoded video, for example, that may occur during a video conference. For bidirectional data transmission, each terminal 101 and 104 can encode video data captured at a local location for transmission to the other terminal via network 105. Each terminal 101 and 104 can also receive encoded video data transmitted from the other terminal, decode the encoded data, and display the recovered video data on a local display device.

[0025] exist Figure 1 In this application, terminals 101, 102, 103, and 104 can be servers, personal computers, and smartphones, but the principles disclosed herein are not limited thereto. The embodiments disclosed herein are applicable to laptop computers, tablet computers, media players, and / or dedicated video conferencing equipment. Network 105 refers to any number of networks transmitting encoded video data between terminals 101, 102, 103, and 104, including, for example, wired (connected) and / or wireless communication networks. Communication network 105 can exchange data in circuit-switched and / or packet-switched channels. This network may include telecommunications networks, local area networks, wide area networks, and / or the Internet. For the purposes of this application, unless explained below, the architecture and topology of network 105 may be irrelevant to the operation of this application.

[0026] As an example of the application of the disclosed subject matter, Figure 2 This illustrates the placement of video encoders and decoders in a streaming environment. The disclosed subject matter is equally applicable to other video-enabled applications, including, for example, video conferencing, digital TV, storing compressed video on digital media including CDs, DVDs, memory sticks, etc.

[0027] The streaming system may include an acquisition subsystem 203, which may include a video source 201, such as a digital camera, which creates, for example, an uncompressed video sample stream 213. The sample stream 213 may be emphasized as having a high data volume compared to the encoded video stream and may be processed by an encoder 202 coupled to the camera 201. The encoder 202 may include hardware, software, or a combination of hardware and software to implement or enforce aspects of the disclosed subject matter as described in more detail below. The encoded video stream 204, which may be emphasized as having a lower data volume compared to the sample stream, may be stored on a streaming server 205 for future use. One or more streaming clients 212 and 207 may access the streaming server 205 to retrieve copies 208 and 206 of the encoded video stream 204. Client 212 may include a video decoder 211 that decodes an incoming copy of the encoded video stream 208 and produces an output video sample stream 210 that may be displayed on a display 209 or another presentation device (not depicted). In some streaming systems, video streams can be encoded according to certain video coding / compression standards of 204, 206, and 208. Implementations of these standards have been mentioned above and will be described further herein.

[0028] Figure 3 This can be a functional block diagram of a video decoder 300 according to an embodiment of the present invention.

[0029] Receiver 302 may receive one or more encoded video sequences to be decoded by decoder 300; in the same embodiment or another embodiment, one encoded video sequence is received at a time, wherein the decoding of each encoded video sequence is independent of the others. Encoded video sequences may be received from channel 301, which may be a hardware / software link to a storage device storing the encoded video data. Receiver 302 may receive encoded video data as well as other data, such as encoded audio data and / or auxiliary data streams that may be forwarded to their respective user entities (not indicated). Receiver 302 may separate the encoded video sequences from other data. To prevent network jitter, buffer memory 303 may be coupled between receiver 302 and entropy decoder / parser 304 (hereinafter referred to as "parser"). Buffer 303 may not be necessary or may be made smaller when receiver 302 receives data from a store / forward device with sufficient bandwidth and controllability or from an isochronous synchronization network. Of course, in order to be used on packet networks such as the Internet, a buffer 303 may also be required, and the buffer memory may be relatively large and have an adaptive size.

[0030] Video decoder 300 may include parser 304 to reconstruct symbols 313 from an entropy-encoded video sequence. These symbols may include information for managing the operation of decoder 300, and potential information for controlling a display device (such as display 312), which is not part of the decoder but may be coupled to it. Control information for the display device may be fragments of parameter sets (not indicated) of Supplemental Enhancement Information (SEI messages) or Video Usability Information (VUI). Parser 304 may perform parsing / entropy decoding on the received encoded video sequence. The encoding of the encoded video sequence may be based on video coding techniques or standards and may follow principles well known to those skilled in the art, including variable-length coding, Huffman coding, arithmetic coding with or without context sensitivity, etc. Parser 304 may extract a subset of parameters from the encoded video sequence for use in the video decoder, based on at least one parameter corresponding to a group. Subgroups can include Group of Pictures (GOP), pictures, tiles, slices, macroblocks, coding units (CU), blocks, transform units (TU), prediction units (PU), and so on. The entropy decoder / parser can also extract information from the encoded video sequence, such as transform coefficients, quantizer parameter values, motion vectors, and so on.

[0031] The parser 304 can perform entropy decoding / parsing operations on the video sequence received from the buffer 303 to create symbols 313. The parser 304 can receive encoded data and selectively decode specific symbols 313. In addition, the parser 304 can determine whether a specific symbol 313 is intended to be provided to the motion compensation prediction unit 306, the scaler / inverse transform unit 305, the intra-frame prediction unit 307, or the loop filter 311.

[0032] Depending on the type of encoded video frames or a subset of encoded video frames (e.g., inter-frame and intra-frame frames, inter-frame and intra-frame blocks) and other factors, the reconstruction of symbol 313 may involve multiple different units. Which units are involved and how they are involved can be controlled by subgroup control information parsed from the encoded video sequence by parser 304. For brevity, the flow of such subgroup control information between parser 304 and the various units described below is not described.

[0033] In addition to the functional blocks already mentioned, the decoder 300 can be conceptually subdivided into several functional units as described below. In practical embodiments operating under commercial constraints, many of these units interact closely with each other and can be integrated with one another. However, for the purposes of describing the disclosed subject matter, it is appropriate to conceptually subdivide them into the functional units described below.

[0034] The first unit is the scaler / inverse transform unit 305. The scaler / inverse transform unit 305 receives quantization transform coefficients as symbols 313 from the parser, along with control information including the transform mode used, block size, quantization factor, and quantization scaling matrix. It can output blocks containing sample values, which can be input into the aggregator 310.

[0035] In some cases, the output samples of the scaler / inverse transform unit 305 may belong to intra-coded blocks; that is, blocks that do not use predictive information from previously reconstructed images, but can use predictive information from previously reconstructed portions of the current image. Such predictive information may be provided by the intra-picture prediction unit 307. In some cases, the intra-picture prediction unit 307 uses reconstructed information extracted from the current (partially reconstructed) image 309 to generate surrounding blocks of the same size and shape as the block being reconstructed. In some cases, the aggregator 310 adds the predictive information generated by the intra-picture prediction unit 307 to the output sample information provided by the scaler / inverse transform unit 305 based on each sample.

[0036] In other cases, the output samples of the scaler / inverse transform unit 305 may belong to inter-frame coding and latent motion compensation blocks. In this case, the motion compensation prediction unit 306 can access the reference image memory 308 to extract samples for prediction. After motion compensation is performed on the extracted samples according to symbol 313, these samples can be added by the aggregator 310 to the output of the scaler / inverse transform unit (referred to in this case as residual samples or residual signals) to generate output sample information. The motion compensation unit's retrieval of predicted samples from addresses in the reference image memory can be controlled by motion vectors, and these motion vectors are provided to the motion compensation unit in the form of symbol 313 (which includes, for example, X, Y, and reference image components). Motion compensation may also include interpolation of sample values ​​extracted from the reference image memory when using subsample precise motion vectors, motion vector prediction mechanisms, etc.

[0037] The output samples of aggregator 310 can be employed by various loop filtering techniques in loop filter unit 311. Video compression techniques may include in-loop filtering techniques controlled by parameters included in the encoded video bitstream, and these parameters can be used as symbols 313 from parser 304 in loop filter unit 311. However, in other embodiments, video compression techniques may also respond to metadata obtained during decoding of a previous (in decoding order) portion of an encoded picture or encoded video sequence, and to previously reconstructed and loop-filtered sample values.

[0038] The output of the loop filter unit 311 can be a sample stream, which can be output to the rendering device 312 and stored in the reference image memory 557 for subsequent inter-frame image prediction.

[0039] Once fully reconstructed, certain encoded images can be used as reference images for future predictions. Once the encoded images have been fully reconstructed and are identified as reference images (e.g., by parser 304), the current reference image 309 can become part of the reference image buffer 308, and new current image memory can be reallocated before the reconstruction of subsequent encoded images begins.

[0040] The video decoder 300 can perform decoding operations according to a predetermined video compression technique (e.g., ITU-T H. 265) that can be documented in a standard. The encoded video sequence may conform to the syntax specified by the video compression technique or standard used, in the sense that it follows the video compression technique or standard document or, particularly, the syntax specified in its configuration file. For compliance, the complexity of the encoded video sequence is also required to be within the limits defined by the hierarchy of the video compression technique or standard. In some cases, the hierarchy limits the maximum image size, maximum frame rate, maximum reconstruction sampling rate (measured in megasamples per second, for example), maximum reference image size, etc. In some cases, the limitations set by the hierarchy can be further defined by the Hypothetical Reference Decoder (HRD) specification and the metadata managed by the HRD buffer, which is represented by signals in the encoded video sequence.

[0041] In this embodiment, receiver 302 may receive additional (redundant) data along with the encoded video. The additional data may be a portion of the encoded video sequence. The additional data may be used by video decoder 300 to properly decode the data and / or more accurately reconstruct the original video data. The additional data may take the form of, for example, temporal, spatial, or signal-to-noise ratio (SNR) enhancement layers, redundant slices, redundant images, forward error correction codes, etc.

[0042] Figure 4 This may be a functional block diagram of a video encoder 400 according to an embodiment of the present disclosure.

[0043] The encoder 400 can receive video samples from a video source 401 (not part of the encoder), which can capture video images that will be encoded by the encoder 400.

[0044] Video source 401 can provide a source video sequence in the form of a digital video sample stream to be encoded by encoder (303), the digital video sample stream having any suitable bit depth (e.g., 8-bit, 10-bit, 12-bit, etc.), any color space (e.g., BT.601YCrCb, RGB, etc.), and any suitable sampling structure (e.g., YCrCb4:2:0, YCrCb4:4:4). In a media service system, video source (401) can be a storage device storing previously prepared video. In a video conferencing system, video source (401) can be a camera that captures local image information as a video sequence. Video data can be provided as multiple individual pictures, which are given motion when viewed sequentially. The pictures themselves can be constructed as spatial pixel arrays, where each pixel may include one or more samples depending on the sampling structure, color space, etc., used. Those skilled in the art can easily understand the relationship between pixels and samples. The following focuses on describing samples.

[0045] According to an embodiment, encoder 400 can encode and compress images of a source video sequence into an encoded video sequence 410 in real time or under any other time constraints required by the application. Implementing an appropriate encoding rate is a function of controller 402. Controller 402 controls and is functionally coupled to other functional units described below. For simplicity, coupling is not shown in the figures. Parameters set by the controller may include rate control related parameters (image skipping, quantizer, λ value of rate-distortion optimization techniques, etc.), image size, group of pictures (GOP) layout, maximum motion vector search range, etc. Those skilled in the art will readily recognize other functions of controller 402, which may relate to a video encoder 400 optimized for a particular system design.

[0046] Some video encoders operate within an “encoding loop” readily recognized by those skilled in the art. In a simplified description, the encoding loop may consist of the encoding portion of encoder 402 (hereinafter referred to as the “source encoder”) (responsible for creating symbols based on the input image to be encoded and the reference image) and a (local) decoder 406 embedded in encoder 400, which reconstructs the symbols to create sample data in the same manner as the (remote) decoder creates sample data (because in the video compression techniques considered in this application, any compression between the symbols and the encoded video stream is lossless). The thus reconstructed sample stream is input to reference image memory 405. Since the decoding of the symbol stream produces bit-accurate results independent of the decoder location (local or remote), the contents of the reference image buffer are also bit-accurately corresponding between the local encoder and the remote encoder. In other words, the reference image samples “seen” by the encoder’s prediction portion are exactly the same as the sample values ​​that the decoder will “see” during prediction. This fundamental principle of reference image synchronization (and the drift that occurs, for example, due to channel errors) is well known to those skilled in the art.

[0047] The operation of the "local" decoder 406 can be combined with, for example, the above. Figure 3 The "remote" decoder 300 is described in detail. However, a brief additional reference is provided. Figure 4 When symbols are available and the entropy encoder 408 and the parser 304 are able to encode / decode the symbols into an encoded video sequence without loss, the entropy decoding portion of the decoder 300, including the channel 301, receiver 302, buffer 303 and parser 304, may not be fully implemented in the local decoder 406.

[0048] It can then be observed that any decoder technique other than parsing / entropy decoding, which exists in the decoder, must also exist in the corresponding encoder in essentially the same functional form. The description of encoder techniques can be simplified because encoder techniques are inverses of the fully described decoder techniques. More detailed descriptions are only required in certain areas, and are provided below.

[0049] As part of its operation, the source encoder 403 performs motion-compensated predictive coding. The motion-compensated predictive coding predictively encodes the input frame with reference to one or more previously encoded frames from the video sequence designated as "reference frames." In this manner, the encoding engine 407 encodes the differences between pixel blocks in the input frame and pixel blocks in the reference frame, which can be selected as a predictive reference for the input frame.

[0050] The local video decoder 406 can decode encoded video data of frames that can be designated as reference frames, based on symbols created by the source encoder 403. The encoding engine 407 can operate as a lossy process. When encoded video data can be decoded by the video decoder (… Figure 4 When the source video sequence (not shown) is decoded, the reconstructed video sequence can typically be a copy of the source video sequence with some errors. The local video decoder 406 replicates the decoding process, which can be performed by the video decoder on the reference frame, and allows the reconstructed reference frame to be stored in the reference image cache 405. In this way, the encoder 400 can locally store a copy of the reconstructed reference frame that shares common content (no transmission errors) with the reconstructed reference frame to be obtained by the remote video decoder.

[0051] Predictor 404 can perform a prediction search against encoding engine 407. That is, for a new frame to be encoded, predictor 404 can search the reference image memory 405 for sample data (as candidate reference pixel blocks) or certain metadata, such as reference frame motion vectors, block shapes, etc., that can serve as appropriate prediction references for the new frame. Predictor 404 can operate pixel-by-pixel based on the sample blocks to find suitable prediction references. In some cases, based on the search results obtained by predictor 404, it can be determined that the input frame may have prediction references obtained from multiple reference frames stored in the reference image memory 405.

[0052] The controller 402 can manage the encoding operations of the video encoder 403, including, for example, setting parameters and subgroup parameters for encoding video data.

[0053] The outputs of all the aforementioned functional units can be entropy encoded in the entropy encoder 408. The entropy encoder performs lossless compression on the symbols generated by the various functional units using techniques known to those skilled in the art, such as Huffman coding, variable-length coding, and arithmetic coding, thereby converting the symbols into an encoded video sequence.

[0054] Transmitter 409 can buffer the encoded video sequence created by entropy encoder 408 in preparation for its transmission via communication channel 411, which may be a hardware / software link to a storage device storing the encoded video data. Transmitter 409 can combine the encoded video data from video encoder 403 with other data to be transmitted, such as encoded audio data and / or auxiliary data streams (source not shown).

[0055] Controller 402 manages the operation of encoder 400. During encoding, controller 405 can assign a specific encoded image type to each encoded image, but this may affect the encoding techniques applicable to the corresponding images. For example, images can typically be assigned to any of the following frame types:

[0056] An intra-frame picture (I-picture) is a picture that can be encoded and decoded without using any other frames in the sequence as a prediction source. Some video codecs allow different types of intra-frame pictures, including, for example, Independent Decoder Refresh (IDR) pictures. Those skilled in the art will understand variations of I-pictures and their corresponding applications and characteristics.

[0057] A predictive image (P-image) can be an image that can be encoded and decoded using intra-frame prediction or inter-frame prediction, which uses at most one motion vector and a reference index to predict sample values ​​for each block.

[0058] A bidirectional predictive image (B-image) can be an image that can be encoded and decoded using intra-frame prediction or inter-frame prediction, which uses at most two motion vectors and a reference index to predict sample values ​​for each block. Similarly, multiple predictive images can use more than two reference images and associated metadata to reconstruct a single block.

[0059] Source images are typically spatially subdivided into multiple sample blocks (e.g., 4×4, 8×8, 4×8, or 16×16 sample blocks), and encoded block by block. These blocks can be predictively encoded with reference to other (already encoded) blocks, which are determined based on the encoding assignment of the corresponding images applied to the blocks. For example, blocks of an I-image can be non-predictively encoded, or the blocks can be predictively encoded (spatial prediction or intra-frame prediction) with reference to already encoded blocks of the same image. Pixel blocks of a P-image can be predictively encoded with reference to a non-previously encoded reference image via spatial prediction or temporal prediction. Blocks of a B-image can be predictively encoded with reference to one or two non-previously encoded reference images via spatial prediction or temporal prediction.

[0060] The video codec 400 can perform encoding operations according to a predetermined video coding technique or standard, such as ITU-T H.265 Recommendation. In operation, the video codec 400 can perform various compression operations, including predictive coding operations that utilize temporal and spatial redundancy in the input video sequence. Therefore, the encoded video data can conform to the syntax specified by the video coding technique or standard used.

[0061] In this embodiment, transmitter 409 may transmit additional data while transmitting encoded video. Source encoder 403 may include such data as part of the encoded video sequence. Additional data may include other forms of redundant data such as temporal / spatial / SNR enhancement layers, redundant pictures and slices, Supplementary Enhancement Information (SEI) messages, fragments of Visual Usability Information (VUI) parameter sets, etc.

[0062] Figure 5 This is a schematic illustration of the overall flow 500 including interactions IF1 and IF2 between source server 501, client 502, and ad server 503, respectively. This general and simplified architecture illustrates an embodiment corresponding to the signaling notification configurations described herein, which include in-list update events that overcome the technical drawbacks discussed above. Of course, interactions IF1 and IF2 do not need to be directly connected, but can simply be one or more networked connections between the illustrated elements.

[0063] Figure 6 This is a simplified flowchart 600 relating to various embodiments including one or more mid-roll ads that have a technical advantage in early termination via features at least those listed herein.

[0064] At S60, it is determined that the process will proceed to S61. At S61, the source server (such as...) Figure 5 The source server (501) publishes an MPD containing programs (such as a main live program that may occur in real time or near real time). At S62, it is considered whether an ad intrusion has occurred, and if so, when it is determined that an ad intrusion has occurred, the source server inserts at least one in-list / in-band MPD validity expiration event (also referred to herein as an "event") via in-patch signaling (such as with MPEG-DASH), for example at S63, to signal the need for an MPD update, and at S64, when a client receives such an event, the client parses the event and calculates the expiration time for updating the MPD data or checking for an MPD data update in the timeline based on the timing information in the event (such as one or more timers indicating the duration of the initial ad intrusion and the time or frequency of checking for updates, which will be described further below).

[0065] Therefore, additionally at S64, when the time, frequency, or signal occurs otherwise according to the event, before the expiration time of the overall ad intrusion MPD initially reported to the client, the client requests an MPD update from the source server or otherwise from the resource indicated by the event (described below), and in response, the client receives such an update (if any) and updates the client's expected MPD information as illustrated at S65. Such features of S63 to S65 can occur before or after at least a partial ad playback, such as when the client switches from the source server to the ad server (e.g., via a client switch). Figure 5 (A simplified diagram of the advertising server 503).

[0066] At S65, the client switches to ad intrusion and begins streaming from the ad server. The new MPD here contains an MPD validity expiration event stream from the manifest, which has remote elements using xlink, and the new MPD also has one or more minimumUpdatePeriod values, which are values ​​used for this event stream or inherited from MPD@minimumUpdatePeriod (described further below). At S67, when streaming content from the ad server, the client requests the MPD validity expiration event stream from at least the resources mentioned above and defined by, for example, xlink at a frequency equal to or greater than minimumUpdatePeriod. Whenever the client receives a new MPD validity expiration event from this event stream, such as at S68, the client parses the new event and processes it according to the MPD validity expiration timing model, and the client updates the MPD before the expiration time set by the MPD validity expiration (such as the previously indicated end (termination) of ad intrusion). The update can signal the end of an ad intrusion and, as at S69, switch back to the stream (e.g., a live stream) via a client switching back from the ad server to the source server, or can signal one or more new parameters of the event. That is, at S69, the new MPD update can be determined to include an updated ad duration that instructs the client to switch back to the live stream server at a new early termination time in the timeline, or to switch back to the live stream server immediately as an early termination time for one or more such mid-roll ads in a single ad or series of mid-roll ads.

[0067] Figure 7 This is a simplified flowchart 700 relating to various embodiments including one or more mid-roll ads that have a technical advantage in early termination via features at least those listed herein.

[0068] At S71, the source server (such as...) Figure 5 The source server (501) publishes an MPD containing pre-roll ads and programs (such as a main live program that may occur in real-time or near real-time). At S72, the client begins streaming the pre-roll ads from the ad server. According to an exemplary embodiment, the MPD contains a list of MPD validity expiration event streams, which has removal elements using xlink, such as those mentioned above. Figure 6 Similar to the description above, the new MPD also has one or more minimumUpdatePeriod values, which are values ​​used for the event stream or inherited from MPD@minimumUpdatePeriod (described further below). At S77, when content is streamed from the ad server, the client requests the MPD validity expiration EventStream from at least the resources mentioned above and defined by, for example, xlink at a frequency equal to or greater than minimumUpdatePeriod. Whenever the client receives a new MPD validity expiration event from the EventStream, such as at S78, the client parses the new event and processes it according to the MPD validity expiration timing model, and the client updates the MPD before the expiration time set by the MPD validity expiration (such as the previously indicated end (termination) of an ad intrusion). This update may signal the end of the ad intrusion, and as at S79, may signal one or more new parameters of the event by switching to the stream (e.g., a live stream) via a client switching back from the ad server to the origin server. That is, at 79, a new MPD update can be identified as including an updated ad duration that instructs the client to switch to the live server at a new early termination time in the timeline, or as an immediate switch to the live server for one or more such pre-roll ads, for a single ad or a series of pre-roll ads. Figure 7 The diagram showing the end at S79 will be interpreted as also linking to... Figure 6 S60, at S60, can be as described above (such as...) Figure 6 The text also mentions further possible content delivery for one or more in-line advertisements. That is, Figure 7 The features can be immediately followed by Figure 7 Before the characteristics.

[0069] According to an exemplary embodiment, such signaling can be defined, for example, using in-manifest MPD validity expiration. A scheme is defined here, including a specific schemeIDUri, which can be defined for in-manifest MPD validity expiration, such as: "urn:mpeg::dash:manifest-event:2020", and EventStream elements carrying such events can use this URI in their @schemeIDUri.

[0070] Furthermore, regarding this type of signaling, similar to in-band MPD validity expiration events, the same value can be used to signal the type of MPD update event, such as:

[0071] Table 1

[0072]

[0073]

[0074] Furthermore, events with the same id value can be considered equivalent, and therefore, receiving multiple such events can lead to checking whether the values ​​are the same, and then it is sufficient to process only one of them, such as processing one of such events according to each check or each time period as pre-determined with respect to the event and / or the client.

[0075] Furthermore, according to an exemplary embodiment, in-list MPD expiry events with MPD-level EventStreams can be used, and in order to fully unpack in-list MPD expiry events from a time period, these events can be used in EventStreams defined at the MPD level and independent of one or more time periods.

[0076] Therefore, the aforementioned technical problems can be advantageously improved by one or more of these technical solutions through the exemplary embodiments described herein, since this disclosure also introduces an in-list event, equivalent to an in-band MPD validity expiration event, and other aspects inserted into the MPD. This in-list event may have the same properties as the in-band MPD validity expiration event, and thus the DASH client can process the in-list event in a certain way. This document also discloses how to use in-list events to prematurely terminate arbitrary pre-roll and mid-roll ads, which has an advantageous technical effect in solving the aforementioned technical problem of the lack of desired early termination of such ads.

[0077] The above-described techniques can be implemented as computer software using computer-readable instructions and physically stored on one or more computer-readable media. Alternatively, they can be implemented using one or more specially configured hardware processors. For example, Figure 8A computer system 800 is shown, which is adapted to implement certain embodiments of the disclosed subject matter.

[0078] The computer software can be encoded using any suitable machine code or computer language, and code including instructions can be created through mechanisms such as assembly, compilation, and linking. These instructions can be executed directly by the computer's central processing unit (CPU), graphics processing unit (GPU), or through decoding, microcode, or other means.

[0079] The instructions can be executed on various types of computers or their components, including, for example, personal computers, tablets, servers, smartphones, gaming devices, Internet of Things devices, etc.

[0080] Figure 8 The components shown for computer system 800 are exemplary in nature and are not intended to limit the scope or functionality of the computer software used to implement the embodiments of this application. Nor should the configuration of the components be construed as having any dependency or requirement on any component or combination thereof shown in the exemplary embodiments of computer system 800.

[0081] Computer system 800 may include certain human-machine interface (HMI) input devices. Such HMI input devices may respond to input from one or more human users through tactile input (e.g., keyboard input, swiping, data glove movement), audio input (e.g., sound, applause), visual input (e.g., gestures), and olfactory input (not shown). The HMI device 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 sound), images (e.g., scanned images, photographic images obtained from still cameras), and video (e.g., two-dimensional video, three-dimensional video including stereoscopic video).

[0082] Human-machine interface input devices may include one or more of the following (only one is shown): keyboard 801, mouse 802, touchpad 803, touch screen 810, data glove (not shown), joystick 805, microphone 806, scanner 808, and camera 807.

[0083] The computer system 800 may also include certain human-machine interface (HMI) output devices. Such HMI output devices can stimulate the senses of one or more human users through, for example, tactile output, sound, light, and smell / taste. These HMI output devices may include tactile output devices (e.g., tactile feedback via a touchscreen 810, a data glove (not shown), or a joystick 805, but may also include tactile feedback devices that are not used as input devices), audio output devices (e.g., speakers 809, headphones (not shown)), visual output devices (e.g., screen 810 including cathode ray tube screens, liquid crystal screens, plasma screens, organic light-emitting diode screens, each with or without touchscreen input functionality, each with or without tactile feedback functionality—some of which may output two-dimensional or higher-dimensional visual outputs through means such as stereoscopic image output; virtual reality glasses (not shown), holographic displays, and smoke boxes (not shown)), and printers (not shown).

[0084] The computer system 800 may also include human-accessible storage devices and related media, such as optical media including high-density read-only / rewritable optical discs (CD / DVD ROM / RW) (1220) or similar media (1221), thumb drives (1222), removable hard disk drives or solid-state drives (1223), conventional magnetic media such as magnetic tapes and floppy disks (not shown), dedicated devices based on ROM / ASIC / PLD such as security software protectors (not shown), and so on.

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

[0086] Computer system 800 may also include an interface 899 providing access to one or more communication networks 898. For example, network 898 may be wireless, wired, or optical. Network 898 may also be a local area network (LAN), wide area network (WAN), metropolitan area network (MAN), vehicular and industrial network, real-time network, latency-tolerant network, etc. Examples of network 898 include Ethernet, wireless LAN, cellular networks (GSM, 3G, 4G, 5G, LTE, etc.), cable or wireless wide area digital networks (including cable TV, satellite TV, and terrestrial broadcast TV), vehicular and industrial networks (including CANBus), etc. Some networks 898 typically require external network interface adapters for connection to certain general-purpose data ports or peripheral buses (850 and 851) (e.g., the USB port of computer system 800); other systems are typically integrated into the core of computer system 800 via a connection to a system bus as described below (e.g., an Ethernet interface integrated into a PC computer system or a cellular network interface integrated into a smartphone computer system). By using any of these networks, computer system 800 can communicate with other entities. The communication can be unidirectional, used only for receiving (e.g., wireless television), unidirectional, used only for sending (e.g., CAN bus to certain CAN bus devices), or bidirectional, such as through a local area or wide area digital network to other computer systems. Each of the above networks and network interfaces can use certain protocols and protocol stacks.

[0087] The aforementioned human-machine interface device, human-accessible storage device, and network interface can be connected to the core 840 of the computer system 800.

[0088] The core 840 may include one or more central processing units (CPUs) 841, graphics processing units (GPUs) 842, graphics adapters 817, dedicated programmable processing units in the form of field-programmable gate arrays (FPGAs) 843, task-specific hardware accelerators 844, etc. These devices, along with read-only memory (ROM) 845, random access memory 846, internal mass storage (e.g., internal non-user-accessible hard disk drives, solid-state drives, etc.) 847, can be connected via a system bus 848. In some computer systems, the system bus 848 can be accessed via one or more physical connectors to allow for expansion with additional CPUs, GPUs, etc. Peripheral devices may be directly attached to the core's system bus 848 or connected via a peripheral bus 851. Peripheral bus architectures include external controller interfaces (PCI), universal serial buses (USB), etc.

[0089] The CPU 841, GPU 842, FPGA 843, and accelerator 844 can execute certain instructions, which, when combined, constitute the aforementioned computer code. This computer code can be stored in ROM 845 or RAM 846. Transient data can also be stored in RAM 846, while permanent data can be stored, for example, in internal mass storage 847. Fast storage and retrieval of any memory device can be achieved through the use of a cache memory, which can be closely associated with one or more CPUs 841, GPUs 842, mass storage 847, ROM 845, RAM 846, etc.

[0090] The computer-readable medium may contain computer code for performing various computer-implemented operations. The medium and computer code may be specifically designed and constructed for the purposes of this application, or they may be media and code well-known and usable by those skilled in the art of computer software.

[0091] By way of example and not limitation, a computer system having architecture 1200, particularly core 840, can provide functionality as a processor (including CPU, GPU, FPGA, accelerator, etc.) to execute software contained in one or more tangible computer-readable media. Such computer-readable media can be media associated with the aforementioned user-accessible mass storage, as well as specific memory of the non-volatile core 840, such as core-internal mass storage 847 or ROM 845. Software implementing various embodiments of this application can be stored in such a device and executed by core 840. Depending on specific needs, the computer-readable medium may include one or more storage devices or chips. The software can cause core 840, particularly the processor therein (including CPU, GPU, FPGA, etc.), to execute a specific process or a specific portion of a specific process described herein, including defining data structures stored in RAM 846 and modifying such data structures according to a software-defined process. Alternatively or as an alternative, the computer system can provide functionality that is logically hardwired or otherwise included in circuitry (e.g., accelerator 844), which can replace or operate with the software to execute the specific process or a specific portion of a specific process described herein. Where appropriate, references to software may include logic, and vice versa. Where appropriate, references to computer-readable media may include circuitry storing the software (such as an integrated circuit (IC)), circuitry containing the execution logic, or both. This application includes any suitable combination of hardware and software.

[0092] While this application has described several exemplary embodiments, various modifications, arrangements, and equivalent substitutions of the embodiments are all within the scope of this application. Therefore, it should be understood that those skilled in the art can design various systems and methods that, although not explicitly shown or described herein, embody the principles of this application and are thus within its spirit and scope.

Claims

1. A video signaling method, characterized in that, The method includes: The release includes Media Presentation Description (MPD) data, which includes main live program data; and Signal the advertising data and list data to the client device. The advertising data indicates an initial end time for the client device, at which time the display of the advertisement ends by switching the display on the client device from the advertisement to the main live program data. The data in the list includes an MPD validity expiration event, which is used to instruct the client device to determine the end time of an update prior to the initial end time by accessing a remote element during the ad stream transmission to the client device, and to end the stream transmission of the ad by switching the stream transmission at the client device from the ad to the main live program data at the end time of the update. The MPD validity expiration event includes timing information, which is used by the client device to calculate the expiration time of updated MPD data in the timeline or to check the MPD data update.

2. The method according to claim 1, characterized in that, The data in the list further includes instructions configured to perform the following steps: the client device accesses the remote element at a predetermined frequency before the initial end time.

3. The method according to claim 1, characterized in that, Signaling the client device to the advertising data and the data in the list includes instructing the client device to transmit the advertising stream as an in-stream advertisement between segments of the main live program data.

4. The method according to claim 1, 2, or 3, characterized in that, Signaling the client device to the advertising data and the data in the list includes: instructing the client device to switch from the source server providing the main live program data to an advertising server separate from the source server, and obtaining in-roll ads from the advertising server.

5. The method according to claim 4, characterized in that, The data in the list includes instructions configured to perform the following steps: the client device determines the end time of the update by accessing a remote element during the streaming of the in-roll advertisement by the client device, and determines whether the remote element indicates the end time of the update.

6. The method according to claim 1, characterized in that, The instructions in the list data instruct the client device to access the remote element via xlink data.

7. The method according to claim 1, 2, or 3, characterized in that, Signaling the client device to the advertising data and the data in the list includes instructing the client device to transmit the advertising stream as a pre-roll ad before streaming the main live program data.

8. The method according to claim 7, characterized in that, The data in the list includes instructions configured to perform the following steps: the client device determines the end time of the update by accessing a remote element during the streaming of the pre-roll ad by the client device, and determines whether the remote element indicates the end time of the update.

9. The method according to claim 1, characterized in that, The timing information represents one or more timers for the initial ad intrusion duration or the time or frequency for checking for updates.

10. An apparatus for video signaling, characterized in that, The apparatus includes a processing circuit configured to perform the method according to any one of claims 1 to 9.

11. An apparatus for video signaling, characterized in that, The device includes: At least one memory is configured to store computer program code; At least one processor is configured to access and operate in accordance with the instructions of the computer program code, the computer program code comprising: Publishing code, configured to cause the at least one processor to publish Media Presentation Description (MPD) data including main live program data; and Signaling codes are configured to cause the at least one processor to signal advertising data and list data to the client device; The advertising data indicates an initial end time for the client device, at which time the display of the advertisement ends by switching the display on the client device from the advertisement to the main live program data. The data in the list includes an MPD validity expiration event, which is used to instruct the client device to determine the end time of an update prior to the initial end time by accessing a remote element during the ad stream transmission to the client device, and to end the stream transmission of the ad by switching the stream transmission at the client device from the ad to the main live program data at the end time of the update. The MPD validity expiration event includes timing information, which is used by the client device to calculate the expiration time of updated MPD data in the timeline or to check the MPD data update.

12. An apparatus for video signaling, characterized in that, The device includes: The publishing module is configured to enable at least one processor to publish Media Presentation Description (MPD) data, which includes the main live program data. The signaling module is configured to cause the at least one processor to signal the advertising data and the list data to the client device; The advertising data indicates an initial end time for the client device, at which time the display of the advertisement ends by switching the display on the client device from the advertisement to the main live program data. The data in the list includes an MPD validity expiration event, which is used to instruct the client device to determine the end time of an update prior to the initial end time by accessing a remote element during the ad stream transmission to the client device, and to end the stream transmission of the ad by switching the stream transmission at the client device from the ad to the main live program data at the end time of the update. The MPD validity expiration event includes timing information, which is used by the client device to calculate the expiration time of updated MPD data in the timeline or to check the MPD data update.

13. The apparatus according to claim 12, characterized in that, The data in the list includes further instructions: the client device accesses the remote element at a predetermined frequency before the initial end time.

14. The apparatus according to claim 13, characterized in that, Signaling the client device to the advertising data and the data in the list includes instructing the client device to transmit the advertising stream as an in-stream advertisement between segments of the main live program data.

15. The apparatus according to claim 12, 13, or 14, characterized in that, Signaling the client device to the advertising data and the data in the list further includes: instructing the client device to switch from the source server providing the main live program data to an advertising server separate from the source server, and obtaining in-roll ads from the advertising server.

16. The apparatus according to claim 15, characterized in that, The data in the list includes the following instructions: the client device determines the end time of the update by accessing a remote element during the streaming of the in-roll advertisement by the client device, and determines whether the remote element indicates the end time of the update.

17. The apparatus according to claim 12, characterized in that, The instructions in the list data instruct the client device to access the remote element via xlink data.

18. The apparatus according to claim 12, 13, or 14, characterized in that, Signaling the client device to the advertising data and the data in the list includes instructing the client device to transmit the advertising stream as a pre-roll ad before streaming the main live program data.

19. The apparatus according to claim 18, characterized in that, The data in the list includes the following instructions: the client device determines the end time of the update by accessing a remote element during the streaming of the pre-roll ad by the client device, and determines whether the remote element indicates the end time of the update.

20. The apparatus according to claim 12, characterized in that, The timing information represents one or more timers for the initial ad intrusion duration or the time or frequency for checking for updates.

21. A non-transitory computer-readable storage medium storing a program configured to cause a computer to perform the method of any one of claims 1 to 9.

Images