Method, apparatus and storage medium for providing video content

Abstract

A method and apparatus for providing video content in a dynamic adaptive streaming over hypertext transfer protocol (DASH) streaming session is provided. The method can include obtaining pre-session based description (PreSBD) information for the DASH streaming session, the PreSBD information indicating that a PreSBD client generates a customized session based description (SBD) document uniform resource locator (URL) for a plurality of SBD descriptors of the DASH streaming session. The method can further include instantiating the PreSBD client and passing the PreSBD descriptor information. The method can then include controlling generation of the customized SBD document URL associated with a first SBD descriptor from the plurality of SBD descriptors of the DASH streaming session. The method can further include launching a first SBD client based on the customized SBD document URL and passing the first SBD descriptor.

Description

Methods, apparatus and storage media for providing video content

[0001] Cross-references to related applications

[0002] This application is based on and claims priority to U.S. Provisional Patent Application No. 63 / 177,788, filed April 21, 2021, and U.S. Patent Application No. 17 / 702,874, filed March 24, 2022, the disclosure of which is incorporated herein by reference in its entirety. Background Technology

[0003] The Moving Picture Experts Group (MPEG) has recently shown increasing interest in DASH standardization for session-based Dynamic Adaptive Streaming over HTTP (DASH) operations. During discussions of DASH standardization sessions, while the media presentation description (MPD) is generic for all clients, clients can obtain a supplementary file called a session-based description (SBD), which provides instructions to the client to make the MPD specific to that session.

[0004] Session-based DASH operations are an important approach for each session and potentially for customizing the MPD for each client. The current design allows one or more SBD documents to be applied to the Uniform Resource Locator (URL) portion or queries for various requests. However, the current design does not allow SBD documents to be applied to queries requesting SBD documents. That is, the current design does not allow customization of the SBD document URL that can be used in the SBD descriptor. It is necessary to be able to customize the SBD document URL within the same manifest file. Summary of the Invention

[0005] According to embodiments of this disclosure, a method for providing video content may include: obtaining pre-session-based description (PreSBD) information of a session, the PreSBD information instructing a PreSBD client to generate a custom session-based description (SBD) document Uniform Resource Locator (URL) for a plurality of SBD descriptors of the session; instantiating a PreSBD client and passing the PreSBD descriptor information; controlling the generation of a custom SBD document URL associated with a first SBD descriptor among the plurality of SBD descriptors from the session; and launching a first SBD client based on the custom SBD document URL and passing the first SBD descriptor.

[0006] According to an embodiment, the method may further include: controlling the generation of a segment URL based on a first SBD descriptor and a customized SBD document URL, and processing a request for a segment of video content by at least modifying the segment URL; and providing a segment of video content based on the modified segment URL.

[0007] According to the method of the embodiment, the multiple SBD descriptors of the session include: an SBD descriptor in the same Media Presentation Description (MPD) element having PreSBD descriptor information, or an SBD descriptor in an MPD element at a lower level compared to an MPD element having PreSBD descriptor information.

[0008] According to the method of the embodiment, the PreSBD descriptor information includes a @urlclass attribute with a value of "sbd".

[0009] According to the method of the embodiment, the PreSBD descriptor information includes a type of Hypertext Transfer Protocol (HTTP) retrieval request, which is generated by a customized SBD document URL.

[0010] According to the method of the embodiment, there is no more than one PreSBD descriptor information in the Media Presentation Description (MPD) element.

[0011] According to the method of the embodiment, PreSBD descriptor information is not present in the lower-level elements of the Media Presentation Description (MPD) element that has PreSBD descriptor information.

[0012] According to the method of the embodiment, the PreSBD client is instantiated before starting the first SBD client or any non-PreSBD client.

[0013] According to the method of the embodiment, before processing a corresponding request for a segment of video content, the corresponding SBD document URL associated with a plurality of SBD descriptors of the session is sent to the PreSBD client.

[0014] According to embodiments of this disclosure, an apparatus for providing video content 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 according to the instructions of the computer program code. The computer program code may include: acquisition code configured to cause at least one processor to acquire pre-Session-Based Description (PreSBD) information of a session, the PreSBD information instructing a PreSBD client to generate a custom Session-Based Description (SBD) document Uniform Resource Locator (URL) for a plurality of SBD descriptors of the session; instantiation code configured to cause at least one processor to instantiate a PreSBD client and pass PreSBD descriptor information; first control code configured to cause at least one processor to control the generation of a custom SBD document URL associated with a first SBD descriptor among a plurality of SBD descriptors from the session; and startup code configured to cause at least one processor to launch the first SBD client based on the custom SBD document URL and pass the first SBD descriptor.

[0015] According to embodiments of this disclosure, a non-transitory computer-readable medium for providing video content stores instructions that, when executed by at least one processor, cause the at least one processor to perform the following operations: acquire pre-Session-Based Description (PreSBD) information of a session, the PreSBD information instructing a PreSBD client to generate a custom session-based description (SBD) document Uniform Resource Locator (URL) for a plurality of SBD descriptors of the session; instantiate a PreSBD client and pass the PreSBD descriptor information; control the generation of a custom SBD document URL associated with a first SBD descriptor among the plurality of SBD descriptors from the session; and launch a first SBD client based on the custom SBD document URL and pass the first SBD descriptor. Attached Figure Description

[0016] The features, advantages, and significance of exemplary embodiments of the present disclosure will now be described with reference to the accompanying drawings, in which similar reference numerals denote similar elements.

[0017] Figure 1 is a simplified schematic diagram of a communication system according to an embodiment.

[0018] Figure 2 is a simplified schematic diagram of components in a streaming environment according to an embodiment.

[0019] Figure 3 is a simplified block diagram of an exemplary decoder according to an embodiment.

[0020] Figure 4 is a simplified block diagram of an exemplary encoder according to an embodiment.

[0021] Figure 5 is a simplified block diagram of an exemplary architecture for session-based DASH operations according to an embodiment.

[0022] Figure 6 is a simplified flowchart of the process for customizing a session-based descriptive URL according to an embodiment.

[0023] Figure 7 is a simplified schematic diagram of a call flow for session-based description URL customization according to an embodiment.

[0024] Figure 8 is a schematic diagram of a computer system according to an embodiment. Detailed Implementation

[0025] 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, one or more processors execute a program stored in a non-transitory computer-readable medium.

[0026] Figure 1 shows a simplified block diagram of a communication system 100 according to an embodiment of this application. 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 at its local location 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.

[0027] Figure 1 illustrates a second pair of terminals 101 and 104 configured to support bidirectional transmission of encoded video, which may occur, for example, during a video conference. For bidirectional data transmission, each terminal 101 and 104 can encode video data captured at its local location for transmission to the other terminal via network 105. Each terminal 101 and 104 can also receive encoded video data transmitted by the other terminal, decode the encoded data, and display the recovered video data on a local display device.

[0028] In Figure 1, terminals 101, 102, 103, and 104 may be shown as servers, personal computers, and smartphones, but the principles of this disclosure are not limited thereto. Embodiments of this disclosure are applicable to laptop computers, tablet computers, media players, and / or dedicated video conferencing equipment. Network 105 refers to any number of networks, including, for example, wired and / or wireless communication networks, that transmit encoded video data between terminals 101, 102, 103, and 104. Communication network 105 may exchange data in circuit-switched and / or packet-switched channels. Representative networks include telecommunications networks, local area networks (LANs), wide area networks (WANs), and / or the Internet. For the purposes of this discussion, the architecture and topology of network 105 may be irrelevant to the operation of this disclosure unless explained below.

[0029] As an example of the application of the disclosed subject matter, Figure 2 illustrates the placement of a video encoder and a video decoder 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.

[0030] The streaming system may include an acquisition subsystem 203, which may include a video source 201, such as a digital camera, that creates, for example, an uncompressed video sample stream 213. The sample stream 213 may be highlighted with a high data volume compared to an encoded video bitstream 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 bitstream 204, highlighted with 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 bitstream 204. Client 212 may include a video decoder 211 that decodes an incoming copy of the encoded video bitstream 208 and creates 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 bitstream 204, video bitstream 206, and video bitstream 208 can be encoded according to certain video encoding / compression standards. Examples of these standards are pointed out above and described further here.

[0031] Figure 3 can be a functional block diagram of a video decoder 300 according to an embodiment of this application.

[0032] 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 decoding of other encoded video sequences. 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 can be forwarded to their respective user entities (not depicted). Receiver 302 may separate 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. To maximize usability on business packet networks such as the Internet, a buffer 303 may be required, which can be relatively large and advantageously have an adaptive size.

[0033] 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 presentation device (e.g., display 312), which is not part of the decoder but may be coupled to it. Control information for the presentation device may be in the form of supplemental enhancement information (SEI messages) or fragments of video availability information parameter sets (not depicted). 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 various principles 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.

[0034] 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 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.

[0035] 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 the subgroup control information parsed by the parser 304 from the encoded video sequence. For brevity, the flow of such subgroup control information between the parser 304 and the various units described below is not depicted.

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

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

[0038] 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 surrounding reconstructed information extracted from the current (partially reconstructed) image 309 to generate blocks of the same size and shape as the blocks 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.

[0039] 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 the symbols 313 belonging to the block, these samples can be added by the aggregator 310 to the output of the scaler / inverse transform unit (referred to as residual samples or residual signals in this case) to generate output sample information. The address in the reference image memory from which the motion compensation unit obtains the predicted samples can be controlled by motion vectors and made available to the motion compensation unit in the form of symbols 313, which may have, 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.

[0040] The output samples of aggregator 310 can be subjected to 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 available to loop filter unit 311 as symbols 313 from parser 304. However, video compression techniques may also respond to metadata obtained during decoding of previous (in decoding order) portions of encoded pictures or encoded video sequences, and to previously reconstructed and loop-filtered sample values.

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

[0042] 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.

[0043] The video decoder 300 can perform decoding operations according to predetermined video compression techniques that can be recorded in, for example, ITU-T Recommendation H.265. An encoded video sequence may conform to the syntax specified by the video compression technique or standard used, in the sense that the encoded video sequence follows the syntax of the video compression technique or standard specified in, particularly its configuration file. For compliance, the complexity of the encoded video sequence may also be 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, for example, megasamples per second), maximum reference image size, etc. In some cases, the limitations set by the hierarchy can be further limited by the Hypothetical Reference Decoder (HRD) specification and metadata managed by the HRD buffer, which is signaled in the encoded video sequence.

[0044] In one embodiment, receiver 302 may receive additional (redundant) data along with the received encoded video. This additional data may be included as part 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.

[0045] Figure 4 can be a functional block diagram of a video encoder 400 according to an embodiment of this application.

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

[0047] Video source 401 can provide a source video sequence in the form of a digital video sample stream to be encoded by encoder 400. This digital video sample stream can have 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., YCrCb 4:2:0, YCrCb 4: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 capturing 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 can include one or more samples depending on the sampling structure, color space, etc., used. Those skilled in the art will readily understand the relationship between pixels and samples. The following focuses on describing samples.

[0048] According to one 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. The controller controls and is functionally coupled to other functional units described below. For simplicity, the coupling is not depicted 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 images (GOP) layout, maximum motion vector search range, etc. Other functions of controller 402 can be readily determined by those skilled in the art, as these functions may relate to a video encoder 400 optimized for a particular system design.

[0049] Some video encoders operate within an "encoding loop," as readily apparent to those skilled in the art. In a simplified description, the encoding loop may include 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 a reference image, and a (local) decoder 406 embedded in encoder 400, which reconstructs the symbols to create sample data in a manner similar to how a (remote) decoder can also create sample data (since any compression between the symbols and the encoded video bitstream is lossless in the video compression techniques considered in the disclosed subject matter). The reconstructed sample stream is input to reference image memory 405. Since decoding the symbol stream produces bit-accurate results independent of the decoder's location (local or remote), the contents of the reference image buffer are also bit-accurately corresponding between the local and remote encoders. In other words, the reference image samples "seen" by the encoder's prediction portion are exactly the same 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, when synchronization cannot be maintained) is well known to those skilled in the art.

[0050] The operation of the “local” decoder 406 is the same as that of the “remote” decoder 300, which has been described in detail above in conjunction with Figure 3. However, referring briefly to Figure 4, when symbols are available and the entropy encoder 408 and the parser 304 can losslessly encode / decode the symbols into an encoded video sequence, 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.

[0051] 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.

[0052] During a portion of its operation, the source encoder 403 may perform motion-compensated predictive coding, referencing one or more previously encoded frames from the video sequence designated as "reference frames," to predictively encode the input frame. 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 the prediction reference for the input frame.

[0053] 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 operation of the encoding engine 407 can advantageously be a lossy process. When the encoded video data can be decoded at the video decoder (not shown in Figure 4), the reconstructed video sequence can typically be a copy of the source video sequence, but 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 frame cache 405. In this way, the encoder 400 can locally store a copy of the reconstructed reference frame that shares common content with the reconstructed reference frame that will be obtained by the remote video decoder (no transmission errors).

[0054] 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 image motion vectors, block shapes, etc., that can serve as appropriate prediction references for the new image. Predictor 404 can operate pixel-by-pixel based on sample blocks to find suitable prediction references. In some cases, as determined by the search results obtained by predictor 404, the input image may have prediction references obtained from multiple reference images stored in reference image memory 405.

[0055] 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.

[0056] 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 transforming the symbols into an encoded video sequence.

[0057] Transmitter 409 can buffer the encoded video sequence created by entropy encoder 408, thereby preparing it for transmission via communication channel 411, which may be a hardware / software link to a storage device that will store 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).

[0058] 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 image types:

[0059] An intra-frame picture (I-picture) is a picture that can be encoded and decoded without using any other pictures 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 these variations of I-pictures and their corresponding applications and characteristics.

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

[0061] A bidirectional predictive picture (B-picture) can be a picture 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 pictures can use more than two reference pictures and associated metadata to reconstruct a single block.

[0062] Source images are typically spatially subdivided into multiple sample blocks (e.g., 4×4, 8×8, 4×8, or 16×16 sample blocks), and each block is encoded sequentially. These blocks can be predictively coded with reference to other (already coded) blocks, which are determined by the coding assignment of the corresponding images applied to the block. For example, a block of an I image can be nonpredictively coded, or it can be predictively coded (spatial prediction or intra-frame prediction) with reference to already coded blocks of the same image. A pixel block of a P image can be nonpredictively coded with reference to a previously coded reference image via spatial prediction or temporal prediction. A block of a B image can be nonpredictively coded with reference to one or two previously coded reference images via spatial prediction or temporal prediction.

[0063] The video encoder 400 can perform encoding operations according to predetermined video coding techniques or standards, such as ITU-T Recommendation H.265. In operation, the video encoder 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.

[0064] In one 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, auxiliary enhancement information (SEI) messages, video availability information (VUI) parameter set fragments, etc.

[0065] Figure 5 shows a simplified block diagram of an exemplary architecture 500 for session-based DASH operations according to an embodiment.

[0066] Streaming media or video content can originate from source 501 and be provided to content delivery network (CDN) 502, which can provide MPD / fragments to DASH access client 503. Session client 506 can be controlled to request values ​​from DASH access client 503, which can be provided from session client 506 to DASH access client 503. As an example, a value such as that obtained by getValue(key,time) can be requested from DASH access client 503, which can be provided from session client 506 to DASH access client 503. Session client 506 can provide values ​​to DASH access client 503 by combining control from session controllers 504 and 505 and their respective SBD data SBD[0] and SBD[1] as shown in the example embodiments of Figures 6 and 7.

[0067] As an example, an element is introduced into the SBD descriptor for the URL template, and more specifically according to the embodiment, the SBD operation (e.g., query or URL customization) should enable session client 506 to apply its processing to the fragment URL generated by DASH access client 503 after retrieving sufficient information from MPD in DASH access client 503. However, in the example embodiment, the SBD operation should not intercept the operation of DASH access client 503, and although the example implementation can combine MPD and SBD processing, other embodiments believe that these features can therefore be accomplished. Therefore, an advantage is that the SBD operation can be added as an application to any DASH access client, rather than being integrated with DASH client logic. Therefore, embodiments that change the URL to a new value can be added.

[0068] According to embodiments of this disclosure, session-based DASH operation standards related to SBD (e.g., ISO / IEC 23009-8) can be extended to allow customization of SBD document URLs or SBD URLs. That is, SBD standards that allow multiple documents to be applied to queries or URLs for various requests can be extended to requests and apply additional SBD URL requests.

[0069] An MPD element can have one or more SBD descriptors. However, as mentioned above, while the URL and request can be modified using the SBD descriptor, the SBD document URL used for the SBD descriptor cannot be modified using existing standards. Therefore, to address this technical problem and provide greater flexibility in customization, embodiments of this disclosure add an SBD descriptor called a pre-session-description (PreSBD), and PreSBD can be used to customize other SBD URL requests.

[0070] According to embodiments of this disclosure, the PreSBD descriptor can have the same syntax as a "regular" SBD descriptor, wherein the value "sbd" is assigned to its @urlclass attribute. The @urlclass attribute can specify which HPPT GET requests can be processed by SBD. Since the @urlclass attribute specifies which HPPT GET requests can be processed by SBD, the value "sbd" can indicate that the PreSBD descriptor information may include a type of Hypertext Transfer Protocol (HTTP) GET request, which is subject to customized SBD document URL generation.

[0071] The value associated with @urlclass can be a list of concatenated lists of allowed keys. For the PreSBD descriptor, the @urlclass attribute value can be a concatenated list containing at least "sbd". Other possible values ​​that can be included in the concatenated list are "segment", "xlink", "mpd", "callback", "chaining", and "fallback".

[0072] The properties of the PreSBD descriptor are not limited to the @urlclass property. Table 1 shows an example of MPD EssentialProperty descriptor properties for session-based DASH processing using the PreSBD descriptor.

[0073] Table 1 PreSBD MPD EssentialProperty Descriptor Attributes

[0074]

[0075]

[0076]

[0077]

[0078]

[0079]

[0080] According to embodiments of this disclosure, including a PreSBD descriptor in MPD processing may have one or more limitations.

[0081] While an MPD can have one or more PreSBD descriptors, according to some embodiments, an MPD element can have only one or more PreSBD descriptors. In some embodiments, an MPD can have more than one PreSBD, and no more than one PreSBD descriptor information can exist in an MPD element. In one embodiment, lower-level elements of an MPD element with PreSBD may not have PreSBD descriptors. Therefore, lower-level elements of an MPD element with PreSBD descriptor information may not have PreSBD descriptor information. Thus, according to some embodiments, an MPD element can have at most one PreSBD descriptor.

[0082] According to embodiments of this disclosure, for an MPD element, a PreSBD descriptor can be processed before any "regular" SBD descriptor in the MPD element. This disclosure aims to customize the SBD document URL using other SBD URLs. To achieve such a hierarchical structure and enable "regular" SBD descriptors to customize their SBD document URLs, the PreSBD descriptor can be processed before any other descriptor in the MPD element. Therefore, a PreSBD client can be instantiated before any other SBD client is instantiated in the MPD element.

[0083] According to embodiments of this disclosure, before making a request for an SBD document, the SBD document URL of any SBD descriptor can be sent to the corresponding PreSBD client for customization. In some embodiments, before making a request for an SBD document and the corresponding SBD client generates and / or modifies the segment URL for a segment of video content, the SBD document URL of any SBD descriptor can be sent to the corresponding PreSBD client for customization. Therefore, before processing a corresponding request for a segment of video content, the corresponding SBD document URLs associated with multiple SBD descriptors in the same MPD element used for the session can be sent to the PreSBD client.

[0084] Referring now to Figures 6 and 7, Figure 6 is a flowchart illustrating a process 600 for session-based description URL customization; Figure 7 is an exemplary illustration of a call flow 700 for session-based description URL customization according to an embodiment.

[0085] As shown in Figure 6, in operation 610, PreSBD information can be obtained, which instructs the PreSBD client to generate customized SBD document URLs for multiple SBD descriptors of the session. As an example, a DASH client, such as DASH access client 503, can parse an MPD, such as from CDN 502, and obtain PreSBD information for the session, which instructs the PreSBD client to generate customized SBD document URLs for multiple SBD descriptors of that session.

[0086] In operation 620, a PreSBD client can be instantiated, and PreSBD descriptor information can be passed to the PreSBD client. As an example, a DASH client such as DASH client 705 can perform a lookup of a PreSBD descriptor, which can be instantiated by a PreSBD client such as PreSBD client 710. In some embodiments, the PreSBD descriptor information may include an @urlclass attribute with the value "sbd," which can be used by DASH client 705. In some embodiments, the PreSBD descriptor information may include a type of HTTP GET request, which can be generated through a customized SBD document URL, and this information can be used by DASH client 705.

[0087] According to an embodiment, a PreSBD client can be instantiated before launching the first SBD client in an MPD element or any non-PreSBD client in an MPD element. As an example, referring to FIG7, in operation 755 of call flow 700, DASH client 705 can perform a lookup of a PreSBD descriptor, which can instantiate a PreSBD client such as PreSBD client 710, and pass the PreSBD descriptor to PreSBD client 710.

[0088] In operation 630 of process 600, the generation of a custom SBD document URL associated with a first SBD descriptor among a plurality of SBD descriptors from the session can be controlled. As an example, in operation 760 of call flow 700, DASH client 705 can control the generation of a custom SBD document URL associated with a first SBD descriptor such as SBD1. In operation 765, DASH client 705 can receive the custom SBD document URL associated with the first SBD descriptor SBD1. In some embodiments, PreSBD client 710 can generate the custom SBD document under the guidance of DASH client 705.

[0089] According to an embodiment, multiple SBD descriptors for a session for which a customized SBD document URL can be generated may include: SBD descriptors in the same MPD element that have PreSBD descriptor information, or SBD descriptors in an MPD element that has a lower level compared to the MPD element with PreSBD descriptor information. As mentioned above, the PreSBD processing may have some limitations, including: no more than one PreSBD descriptor information may exist in an MPD element, and PreSBD descriptor information may not exist in lower-level elements of the MPD element that has PreSBD descriptor information.

[0090] Because a PreSBD descriptor is required to instantiate the PreSBD client and generate a custom SBD document URL associated with one of the multiple SBD descriptors from the session, according to an embodiment, the PreSBD client can be instantiated before launching the first SBD client or any non-PreSBD client. Similarly, according to an embodiment, the corresponding SBD document URLs associated with the multiple SBD descriptors of the session are sent to the PreSBD client before processing a corresponding request for a segment of video content.

[0091] In operation 640 of process 600, a first SBD client can be launched based on a customized SBD document URL, and a first SBD descriptor can be passed to the first SBD client. As an example, in operation 770 of call stream 700, DASH client 705 can launch SBD1 client 715 based on a customized SBD document URL associated with the first SBD descriptor SBD1 received in operation 765.

[0092] In operation 650 of process 600, the generation of the segment URL can be controlled based on the first SBD descriptor and a customized SBD document URL, and requests for video content segments can be processed by at least modifying the segment URL. As an example, in operations 770 and 775, the DASH client 705 can control the generation of the segment URL based on the PreSBD descriptor and the SBD1 descriptor. In some embodiments, the SBD1 client 715 can generate the segment URL under the guidance of the DASH client 705.

[0093] Furthermore, in operation 650, requests for segments of video content can be processed by at least modifying the segment URL. According to an embodiment, before processing a corresponding request for a segment of video content, the corresponding SBD document URLs associated with multiple SBD descriptors of the session can be sent to the PreSBD client.

[0094] In operation 660, a segment of video content based on a modified segment URL can be provided. As an example, in operation 780 of calling process 700, DASH client 705 can provide a segment of video content based on a modified segment URL received from SBD1 client 715. In some embodiments, in operation 780 of calling process 700, DASH client 705 can process a request for a segment of video content by at least modifying the segment URL received from SBD1 client 715, and provide a segment of video content based on the modified segment URL.

[0095] The above-described techniques can be implemented as computer software that uses computer-readable instructions and is physically stored in one or more computer-readable media, or implemented by one or more specially configured hardware processors. For example, Figure 8 illustrates a computer system 800 suitable for implementing certain embodiments of the disclosed subject matter.

[0096] Computer software can be coded using any suitable machine code or computer language. Any suitable machine code or computer language can be assembled, compiled, linked, or similarly processed to create code containing instructions that can be executed directly by one or more computer central processing units (CPUs), graphics processing units (GPUs), etc., or executed through interpretation, microcode, etc.

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

[0098] The components of the computer system 800 shown in Figure 8 are exemplary in nature and are not intended to impose any limitation on the scope or functionality of the computer software implementing the embodiments of this application. The configuration of the components should also not be construed as having any dependency or requirement relating to any one or a combination of components shown in the exemplary embodiments of the computer system 800.

[0099] Computer system 800 may include certain human-machine interface input devices. Such human-machine interface input devices may respond to input from one or more human users, for example, through input such as: tactile input (e.g., keystrokes, swipes, data glove movement), audio input (e.g., voice, clapping), visual input (e.g., gestures), and olfactory input (not depicted). The human-machine interface device may also be used to capture certain media that are not necessarily directly related to human conscious input, such as audio (e.g., voice, music, ambient sound), images (e.g., scanned images, photographic images acquired from a still image camera), and video (e.g., two-dimensional video, three-dimensional video including stereoscopic video).

[0100] The input human-machine interface device may include one or more of the following (only one of each is shown): keyboard 801, mouse 802, touchpad 803, touch screen 810, joystick 805, microphone 806, scanner 808, and camera 807.

[0101] Computer system 800 may also include certain human-machine interface output devices. Such human-machine interface output devices may, for example, stimulate the senses of one or more human users through tactile output, sound, light, and smell / taste. Such human-machine interface output devices may include tactile output devices (e.g., tactile feedback of touch screen 810 or joystick 805, but may also be tactile feedback devices that are not input devices), audio output devices (e.g., speakers 809, headphones (not depicted)), and visual output devices (e.g., screen 810 including CRT screens, LCD screens, plasma screens, OLED screens, each screen may or may not have touch screen input functionality, each screen may or may not have tactile feedback functionality—some of these screens are capable of outputting two-dimensional or more three-dimensional visual outputs through devices such as stereoscopic image output, virtual reality glasses (not depicted), holographic displays and smoke boxes (not depicted), and printers (not depicted).

[0102] The computer system 800 may also include human-accessible storage devices and their associated media, such as optical media including CD / DVD ROM / RW 820 having media such as CD / DVD 811, finger drives 822, removable hard disk drives or solid-state drives 823, conventional magnetic media such as magnetic tapes and floppy disks (not depicted), devices based on dedicated ROM / ASIC / PLD such as security dongles (not depicted), etc.

[0103] 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 cover transmission media, carrier waves, or other transient signals.

[0104] Computer system 800 may also include an interface 899 providing access to one or more communication networks 898. Network 898 may be, for example, a wireless network, a wired network, or an optical network. Network 898 may further be a local area network, a wide area network, a metropolitan area network, a vehicle and industrial network, a real-time network, a latency-tolerant network, etc. Examples of network 898 include local area networks such as Ethernet, wireless LANs, cellular networks including GSM, 3G, 4G, 5G, LTE, etc., cable or wireless wide area digital television networks including cable television, satellite television, and terrestrial broadcast television, vehicle and industrial television including CANbus, etc. Some networks 898 typically require an external network interface adapter (e.g., a USB port of computer system 800) to connect to certain general-purpose data ports or peripheral buses (850 and 851); other network interfaces are typically integrated into the core of computer system 800 by connecting to a system bus (e.g., an Ethernet interface connected to a PC computer system or a cellular network interface connected to a smartphone computer system). Computer system 800 can use any of these networks 898 to communicate with other entities. Such communication can be one-way receiving (e.g., broadcast television), one-way transmitting (e.g., CANbus connected to certain CANbus devices), or bidirectional, such as connecting to other computer systems using a local area network (LAN) or wide area network (WAN) digital network. As mentioned above, certain protocols and protocol stacks can be used on each of those networks and network interfaces.

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

[0106] 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 areas (FPGAs) 843, hardware accelerators 844 for certain tasks, etc. These devices, along with read-only memory (ROM) 845, random access memory 846, and internal mass storage 847 such as internal non-user-accessible hard disk drives (SDs), etc., 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 connected to the core's system bus 848 or connected via a peripheral bus 851. Peripheral bus architectures include PCI, USB, etc.

[0107] The CPU 841, GPU 842, FPGA 843, and accelerator 844 can execute certain instructions, which can be combined to form 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 to any storage device can be achieved using a cache, which can be closely associated with one or more CPUs 841, GPUs 842, mass storage 847, ROM 845, RAM 846, etc.

[0108] Computer-readable media may have computer code thereon for performing various computer-implemented operations. The media and computer code may be media and computer code specifically designed and constructed for the purposes of this disclosure, or the media and computer code may be of a type known and available to those skilled in the art of computer software.

[0109] As a non-limiting example, a computer system having architecture 800, particularly core 840, can be made functional by one or more processors (including CPUs, GPUs, FPGAs, accelerators, etc.) executing software contained in one or more tangible computer-readable media. Such computer-readable media can be media associated with user-accessible mass storage as described above, as well as some non-transitory memory of core 840, such as internal mass storage 847 or ROM 845. Software implementing various embodiments of this application can be stored in such means 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 processors therein (including CPUs, GPUs, FPGAs, etc.), to execute a particular process or a particular portion of a particular process described herein, including defining data structures stored in RAM 846 and modifying such data structures according to a software-defined process. Additionally or alternatively, the computer system can be made functional by hard-wired or otherwise embodied logic in circuitry (e.g., accelerator 844) that may replace or operate with the software to execute the particular process or a particular portion of a particular process described herein. Where appropriate, references to software may include logic, and vice versa. Where appropriate, references to computer-readable media may include circuitry (e.g., integrated circuits, ICs) storing software for execution, circuitry embodying logic for execution, or both. This application includes any suitable combination of hardware and software.

[0110] Although several exemplary embodiments have been described in this application, modifications, substitutions, and various equivalent substitutions that fall within the scope of this application are possible. Therefore, it should be understood that those skilled in the art will be able to design many systems and methods that, while not explicitly shown or described herein, embody the principles of this application and thus fall within its spirit and scope.

Claims

1. A method for providing video content in a dynamic adaptive streaming media transmission DASH stream session based on Hypertext Transfer Protocol, characterized in that, The method includes: acquiring pre-session-based description (PreSBD) information for a DASH streaming session, the PreSBD information instructing a PreSBD client to generate a customized session-based description SBD document Uniform Resource Locator (URL) for a plurality of SBD descriptors of the DASH streaming session; instantiating the PreSBD client and passing the PreSBD descriptor information before launching a first SBD client or any non-PreSBD client; controlling the generation of a customized SBD document URL associated with a first SBD descriptor among the plurality of SBD descriptors from the DASH streaming session; and launching the first SBD client based on the customized SBD document URL and passing the first SBD descriptor to the first SBD client.

2. The method according to claim 1, characterized in that, The method further includes: controlling the generation of a segment URL based on the first SBD descriptor and the customized SBD document URL, and processing requests for segments of the video content by at least modifying the segment URL; and providing the segments of the video content based on the modified segment URL.

3. The method according to claim 1, characterized in that, The plurality of SBD descriptors of the DASH streaming session include: an SBD descriptor in the same media presentation describing an MPD element having the PreSBD descriptor information, or an SBD descriptor in an MPD element at a lower level compared to an MPD element having the PreSBD descriptor information.

4. The method according to claim 1, characterized in that, The PreSBD descriptor information includes a @urlclass attribute with a value of "sbd".

5. The method according to claim 1, characterized in that, The PreSBD descriptor information includes a type of Hypertext Transfer Protocol (HTTP) GET request, which is generated by a customized SBD document URL.

6. The method according to claim 1, characterized in that, The media presentation describes that the MPD element contains no more than one PreSBD descriptor.

7. The method according to claim 1, characterized in that, The PreSBD descriptor information is not present in elements at lower levels compared to the Media Presentation Description (MPD) element that has the PreSBD descriptor information.

8. The method according to any one of claims 1 to 7, characterized in that, Before processing a request for a segment of the video content, the corresponding SBD document URL associated with the plurality of SBD descriptors of the DASH streaming session is sent to the PreSBD client.

9. An apparatus for providing video content, characterized in that, The apparatus includes: at least one memory configured to store computer program code; and at least one processor configured to access the computer program code and operate in accordance with the instructions of the computer program code to perform the method according to any one of claims 1 to 8.

10. A non-transitory computer-readable storage medium storing instructions that, when executed by at least one processor, cause the at least one processor to perform the method according to any one of claims 1 to 8.

Images