WO2020155961A1 - 视频请求方法、***、计算机设备及计算机可读存储介质 - Google Patents

视频请求方法、***、计算机设备及计算机可读存储介质 Download PDF

Info

Publication number
WO2020155961A1
WO2020155961A1 PCT/CN2019/128454 CN2019128454W WO2020155961A1 WO 2020155961 A1 WO2020155961 A1 WO 2020155961A1 CN 2019128454 W CN2019128454 W CN 2019128454W WO 2020155961 A1 WO2020155961 A1 WO 2020155961A1
Authority
WO
WIPO (PCT)
Prior art keywords
video
request
server
description information
byte
Prior art date
Application number
PCT/CN2019/128454
Other languages
English (en)
French (fr)
Inventor
范文杰
谭兆歆
丁建强
Original Assignee
上海哔哩哔哩科技有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 上海哔哩哔哩科技有限公司 filed Critical 上海哔哩哔哩科技有限公司
Priority to EP19912500.6A priority Critical patent/EP3883251A4/en
Publication of WO2020155961A1 publication Critical patent/WO2020155961A1/zh
Priority to US17/304,732 priority patent/US11496536B2/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H04N21/47202—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for requesting content on demand, e.g. video on demand
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26258—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for generating a list of items to be played back in a given order, e.g. playlist, or scheduling item distribution according to such list
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/2662—Controlling the complexity of the video stream, e.g. by scaling the resolution or bitrate of the video stream based on the client capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/437—Interfacing the upstream path of the transmission network, e.g. for transmitting client requests to a VOD server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server
    • H04N21/6581—Reference data, e.g. a movie identifier for ordering a movie or a product identifier in a home shopping application
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/8543—Content authoring using a description language, e.g. Multimedia and Hypermedia information coding Expert Group [MHEG], eXtensible Markup Language [XML]

Definitions

  • This application relates to the field of computer technology, and in particular to a video request method, system, computer equipment, and computer-readable storage medium.
  • DASH Dynamic Adaptive Streaming over HTTP, HTTP-based dynamic adaptive streaming
  • HTTP-based dynamic adaptive streaming is an adaptive bit rate streaming technology that can split a video into multiple segments, and each segment contains a certain length of playable content.
  • an XMLHttpRequest request is usually sent once for each fragment. For example, if a video has 3 fragments, at least 3 XMLHttpRequest requests must be sent.
  • the prior art has at least the following defects: in the prior art, when a video is played, multiple XMLHttpRequest requests need to be sent, and the request takes time, which leads to video streaming. The efficiency is reduced; in addition, between multiple XMLHttpRequest requests may be inserted by other programs to affect the parsing effect.
  • the purpose of this application is to provide a video request method, system, computer equipment, and computer-readable storage medium, which are used to solve the problem of time-consuming sending multiple requests for a video in the prior art and reducing the efficiency of video streaming. And the defects that seriously affect the analysis effect after being inserted by other programs among multiple requests.
  • This application provides a video request method.
  • the above method includes: in response to a video play instruction, sending a first video request to a server, wherein the server returns a video description information segment and a corresponding complete video according to the first video request,
  • the above-mentioned video includes multiple video segments, and the above-mentioned video description information segment is used to describe each of the above-mentioned video segments; parse the above-mentioned video description information segment; and in the process of downloading the above-mentioned video, according to the parsed above-mentioned video description information segment, The above video is played in segments.
  • this application also provides a video request system.
  • the above system includes: a first sending module, configured to send a first video request to a server in response to a video play instruction, wherein the server is based on the first video Request to return a video description information segment and a corresponding complete video.
  • the video includes multiple video segments, the video description information segment is used to describe each of the above video segments; the parsing module is used to parse the video description information segment; and play The module is used to play the video in segments according to the parsed description information segment of the video in the process of downloading the video.
  • the present application also provides a computer device, including a memory, a processor, and a computer program stored in the memory and running on the processor.
  • the processor is used to implement the foregoing computer program when the foregoing computer program is executed. Steps of the method.
  • Another aspect of the present application provides a computer-readable storage medium having a computer program stored thereon, and the computer program is used to implement the steps of the method described above when the computer program is executed by a processor.
  • the client after receiving a video playback instruction, the client will send a first video request to the server, and the server will return a byte stream to the client.
  • This byte stream includes the video description information segment and the A video request corresponds to all the video segments arranged in order.
  • the client will first download and parse the video description information segment, and then start to download the video, and in the process of downloading the video, the video segment can be downloaded after downloading a video segment.
  • the video segments are parsed and then played in sequence. In the whole process, the first video request only needs to be sent once to watch the complete video. That is, the embodiment of the present application avoids the time-consuming sending multiple requests for a video in the prior art.
  • Fig. 1 schematically shows a flowchart of a video playback method according to an embodiment of the present application
  • Figure 2 schematically shows a schematic diagram of a video playback solution in the prior art
  • Fig. 3 schematically shows a schematic diagram of a video playback solution according to an embodiment of the present application
  • FIG. 4 schematically shows a flowchart of a video playback method in the prior art
  • FIG. 5 schematically shows a flowchart of a video playback method according to another embodiment of the present application.
  • Fig. 6 schematically shows a block diagram of a video playback system according to an embodiment of the present application.
  • Fig. 7 schematically shows a schematic diagram of the hardware architecture of a computer device suitable for implementing a video playback method according to an embodiment of the present application.
  • the client after receiving a video playback instruction, the client will send a first video request to the server, and the server will return a byte stream to the client.
  • This byte stream includes the video description information segment and the A video request corresponds to all the video segments arranged in order.
  • the client will first download and parse the video description information segment, and then start to download the video, and in the process of downloading the video, the video segment can be downloaded after downloading a video segment.
  • the video segments are parsed and then played in sequence. In the whole process, the first video request only needs to be sent once to watch the complete video. That is, the embodiment of the present application avoids the time-consuming sending multiple requests for a video in the prior art.
  • Fig. 1 schematically shows a flowchart of a video playback method according to an embodiment of the present application.
  • the video playback method may include steps S101 to S103, where:
  • Step S101 In response to the video play instruction, send a first video request to the server, where the server returns a video description information segment and a corresponding complete video according to the first video request.
  • the video includes multiple video segments, and the video description information segment uses To describe each video segment.
  • DASH is a dynamic adaptive streaming based on HTTP, similar to the HLS protocol.
  • DASH uses an adaptive bit rate streaming technology to enable high-quality streaming media to be transmitted through the HTTP protocol.
  • DASH technology decomposes streaming media content into a series of small HTTP-based file fragments, each file fragment contains a short length of playable content, and the total length of the file content may be as long as several hours (such as live movies or sports events).
  • the content of the file will be made into candidate fragments of multiple bit rates to provide multiple bit rate versions for selection.
  • the client will automatically select which alternative to download and play according to the current network conditions.
  • the client will select the clip with the highest bit rate that can be downloaded in time for playback, so as to avoid playback jams or rebuffering events. Because of this, the client can seamlessly adapt to changing network conditions and provide a high-quality playback experience, with fewer stalls and rebuffering.
  • the server can divide the video content into multiple segments through the DASH technology, and the length of each segment can be customized, such as 2s, 5s, 10s, etc.
  • the video playback method can be applied to a client such as a web.
  • the first video request can include a Fetch request, and the first video request does not include a request header.
  • the corresponding byte stream can be returned, and the byte stream can include the video description information segment and the corresponding complete video. It should be noted that here only the server returns the byte stream to the client, and it does not mean that the client has completely received or downloaded the byte stream.
  • the video description information segment can include the Initialization segment and the Index segment.
  • the video can be divided into multiple video segments.
  • the Initialization segment can include the necessary metadata for the video, such as the width and height of the video; the Index segment can include all video segments.
  • the segment information includes the byte range, duration, and the correspondence between bytes and duration of the video segment corresponding to the segment information.
  • the server returns all the complete videos, and then the client downloads the video bit by bit, and parses a video segment after downloading it, and then plays it in order.
  • the video playback method may further include: before sending the first video request to the server, obtaining and parsing the MPD (Media Presentation Description) file of the video to obtain the byte corresponding to the video description information segment Range; and after sending the first video request to the server, download the video description information segment according to the byte range.
  • MPD Media Presentation Description
  • the MPD file is the description file of the video, which can be used to describe the composition of the entire MPEG DASH (also known as DASH) stream, which is equivalent to the M3U8 of the HLS (HTTP Live Streaming) protocol (M3U8 is a video format ) File
  • MPD file is an XML (Extensible Markup Language, Extensible Markup Language) Document (Document is a computer terminology, every HTML (Hyper Text Markup Language, Hyper Text Markup Language) document loaded into the browser will become a Document object ), the URL (Uniform Resource Locator, Uniform Resource Locator) download for HTTP GET request (HTTP GET request is a way of HTTP request) can be constructed from the content of the MPD file.
  • the MPD file can describe the segmentation information of each segment of the video, such as the definition, the length of the segment, and so on.
  • the MPD file can also include the byte range of the video description information segment.
  • the byte range of the video description information segment can be known.
  • the MPD file can be passed to the server Send other requests such as XMLHttpRequest request to obtain.
  • the server returns the byte stream, and the client first downloads the data in the range of 0-99Byte.
  • Step S102 Parse the video description information segment.
  • parsing the video description information segment can be parsing the Initialization segment and the Index segment.
  • the metadata of the video can be known, and the segment information of the video can be known by parsing the Index segment.
  • the embodiment of the present application may temporarily store the parsed video description information segment in the memory.
  • the segment information of the video can be obtained, for example: video segment 1 is 1-5s, corresponding to 100-299Byte, 1s corresponds to 100Byte, 5s corresponds to 299Byte; video segment 2 is 6-10s , Corresponding to 300-499Byte, 6s corresponding to 300Byte, 10s corresponding to 499Byte; video segment 3 is 11-15s, corresponding to 500-699Byte, 11s corresponds to 500Byte, 15s corresponds to 699Byte; video segment 4 is 16-20s, corresponding to 700-899Byte, 16s corresponds to 700Byte, 20s corresponds to 899Byte.
  • Step S103 in the process of downloading the video, the video is played in segments according to the parsed video description information segment.
  • the client downloads the remaining byte stream bit by bit. If the byte stream in the range of 100-299Byte is downloaded, it can be parsed and then played. If the byte stream in the range of 300-499Byte is downloaded, it can also be played. Perform analysis, and then play the video segment 2 after the video segment 1 is played, and so on.
  • FIG. 2 schematically shows a schematic diagram of a video playback solution in the prior art.
  • a video playback solution when requesting a video, first perform kernel initialization and http connection, and then send a request for each video segment (that is, request a data network, such as an XMLHttpRequest request), and respond to the data returned from each request Analyze.
  • request a data network such as an XMLHttpRequest request
  • Fig. 3 schematically shows a schematic diagram of a video playback solution according to an embodiment of the present application.
  • the server when requesting a video, first perform kernel initialization and http connection, and then only need to send a video request to the server (that is, request a data network, such as a Fetch request), the server can return all the videos, and then The client downloads the data bit by bit, and parses the data according to the segment information.
  • the embodiment of the present application only needs to send the first video request once when playing a video.
  • the client after receiving a video playback instruction, the client will send a first video request to the server, and the server will return a byte stream to the client.
  • This byte stream includes the video description information segment and the A video request corresponds to all the video segments arranged in order.
  • the client will first download and parse the video description information segment, and then start to download the video, and in the process of downloading the video, the video segment can be downloaded after downloading a video segment.
  • the video segments are parsed and then played in sequence. In the whole process, the first video request only needs to be sent once to watch the complete video. That is, the embodiment of the present application avoids the time-consuming sending multiple requests for a video in the prior art.
  • the video analysis method may further include: determining the byte length of the downloaded video corresponding to the first video request; determining whether the byte length of the downloaded video is greater than or equal to the first preset byte Length; and if the byte length of the downloaded video is greater than or equal to the first preset byte length, the first video request is disconnected.
  • the embodiment of the application can set a first preset byte length. If the byte length of the downloaded video is greater than or equal to the first preset byte length, the first video request is disconnected, and it is no longer The user downloads the remaining videos. Preferably, the first preset byte length is greater than the minimum byte length of the video segment.
  • the Fetch request can be disconnected.
  • the byte length (also known as the remaining buffer) of the video when the downloaded video is not played will gradually decrease.
  • the video is analyzed The method may further include: determining the byte length of the unplayed video in the downloaded video; determining whether the byte length of the unplayed video is less than or equal to the second preset byte length; and if the byte length of the unplayed video is less than or equal to the second If the byte length is preset, a second video request is sent to the server, where the second video request is used to request the remaining videos in the video except the downloaded videos.
  • the second preset byte length also called the minimum buffer length
  • a new Fetch request can be initiated, and the Fetch request includes a request header
  • the start byte of the range field of the request header is the byte corresponding to the end of the downloaded video.
  • the complete video corresponds to the byte range of 100-1899Byte
  • the corresponding byte range of the downloaded video is 100-999Byte
  • the second preset byte length is 300Byte. If the playback position is 699Byte at this time, the video is not played.
  • the client can send a new Fetch request to the server.
  • the start byte of the range field of the Fetch request is 999Byte, such as "999-", that is, the Fetch request is used to request the server for video data in the range of 999-1999Byte. .
  • the video analysis method may further include: in response to the skip instruction, determining the video node corresponding to the skip instruction; determining whether the video node is within the range of the downloaded video; and if the video node is not already available Within the range of the downloaded video, the first video request is disconnected, and a third video request is sent to the server, where the third video request is used to request the remaining video in the video starting from the byte corresponding to the video node.
  • the skip instruction may include a seek instruction, and judging whether the video node is within the range of the downloaded video may be judging whether the time node corresponding to the video node is within the duration of the downloaded video, or judging the video node Whether the corresponding byte is within the byte range of the downloaded video. If it is, no additional operation is required, just start playing the video from the video node. If not, disconnect the Fetch request and initiate a new Fetch request.
  • the Fetch request includes a request header, and the start byte of the range field of the request header is the start byte of the video segment corresponding to the video node.
  • the complete video is 40s
  • the corresponding byte range is 100-1899Byte
  • the length of the downloaded video is 20s
  • the corresponding byte range is 100-999Byte
  • the time node corresponding to the video node corresponding to the skip instruction is 30s
  • the byte of is 1449Byte, that is, the video node is not in the range of the downloaded video
  • the client can send a new Fetch request to the server.
  • the start byte of the range field of the Fetch request is 1449Byte, such as "1449-", that is The Fetch request is used to request video data in the range of 1449-1899Byte from the server.
  • the video analysis method may further include: in response to the definition switching instruction, determining the byte corresponding to the definition switching instruction; and sending a fourth video request to the server, where the fourth video request is For the remaining video starting from the byte corresponding to the definition switching instruction in the requested new definition video, the content of the new definition video is the same as the content of the video, and the definition of the new definition video is different from the definition of the video.
  • the video description information segments of videos of different definitions are different.
  • the range of the requested range field is the byte range of the video description information segment. Download and parse the video description information segment, and then send a fourth video request such as another Fetch request to the server.
  • the start byte of the range field of this Fetch request is the byte corresponding to the definition switching instruction.
  • the byte range corresponding to the complete video is 100-1899Byte
  • the byte corresponding to the definition switching command is 1200Byte.
  • the client can send a new Fetch request to the server.
  • the starting byte of the range field of the Fetch request is 1200Byte.
  • "1200-" that is, the Fetch request is used to request video data in the range of 1200-1899Byte from the server.
  • Fig. 4 schematically shows a flowchart of a video playback method in the prior art.
  • the video playback method in the prior art may include steps S401 to S406, where:
  • Step S401 playback is initialized.
  • Step S402 parse the MPD file.
  • Step S403 Request the Initialization section and Index section.
  • Step S404 parse the Initialization section and the Index section.
  • Step S405 request the next video segment.
  • Step S406 parse the video segment.
  • DASH will decompose the content into a series of small HTTP-based file segments, each segment contains video information or a short length of playable video content, the client will select the highest bit rate video that can be downloaded in time
  • the content fragments are played, thereby avoiding playback jams or rebuffering events.
  • the Initialization segment contains the metadata information necessary to present the video.
  • the Index segment contains the segmentation information for all video segments in the corresponding video.
  • the video segment contains the The range information of the played video content, Initialization section and Index section are known in MPD information.
  • the XMLHttpRequest used in the prior art can only read data after the request is completed.
  • the client first requests the Index segment and the Initialization segment, and after the request and analysis are completed, the segment information of the video segment can be obtained from the data in the Index segment, and a new video segment is used for each video segment.
  • the request address is the video address
  • the range field of the request header specifies the required byte range, such as "100-299”.
  • the server returns the byte data in the range specified by the range field. For example, the first video segment is requested according to the segment information, the first video segment is requested and parsed and then the second video segment is requested, and so on.
  • Fig. 5 schematically shows a flowchart of a video playback method according to another embodiment of the present application.
  • the video playback method may include steps S501 to S508, where:
  • Step S501 playback is initialized.
  • Step S502 parse the MPD file.
  • Step S503 Initiate a Fetch request.
  • Step S504 Read and parse the Initialization segment and Index segment.
  • Step S505 read and parse the next video segment
  • step S506 it is determined whether the stable buffer is exceeded, if it is, step S507 is executed, and if not, step S505 is executed.
  • Step S507 Interrupt the request.
  • Step S508 buffering ends.
  • the byte stream can be read cyclically during the request process by using the Fetch request, so all video segments can be requested only by establishing a connection once.
  • the client first actively initiates a Fetch request without a request header to the video address.
  • the server will return the complete video data, and the client will continue to download the video data, and read the byte stream cyclically during the download process.
  • the Index segment and Initialization segment are at the beginning of the byte stream, and the range is known. They will be downloaded and read by the client first. After obtaining the complete Index segment and Initialization segment data, they will be handed over to the parsing module for analysis, and the Index segment will be parsed.
  • the segment information can be obtained from the data, and only after obtaining the segment information can you identify which bytes are a complete video segment.
  • the Fetch request is actively disconnected.
  • Playing will cause the remaining buffer (also known as the byte length of the unplayed video) to decrease. If the remaining buffer is less than the minimum buffer length (also known as the second preset byte length), a new Fetch request is initiated. This request starts with the byte corresponding to the end of the remaining buffer, and the range field of the request header is shaped like "1000-".
  • the current request is interrupted when the seek time is outside the buffer (also known as the range of the downloaded video), and a new Fetch request starting from the byte corresponding to the seek time is re-initiated, seek No additional operations are required when the time is in the buffer; if there is no unfinished Fetch request, the same as the above playback scene.
  • the range of the range field is the byte range of the Index segment and the Initialization segment, and the shape is "0-1000" to obtain the segment of the new resolution.
  • Another Fetch request is initiated.
  • the beginning of the range field is the byte corresponding to the video switching instruction, which is in the form of "1000-”.
  • Fig. 6 schematically shows a block diagram of a video parsing system according to an embodiment of the present application.
  • the video analysis system 600 may include a first sending module 610, an analysis module 620, and a playback module 630, where:
  • the first sending module 610 is configured to send a first video request to the server in response to the video play instruction, where the server returns a video description information segment and a corresponding complete video according to the first video request.
  • the video includes multiple video segments.
  • the description information segment is used to describe each video segment.
  • the parsing module 620 is used for parsing the video description information segment.
  • the playing module 630 is configured to play the video in segments according to the parsed video description information segment during the process of downloading the video.
  • the client after receiving the video playback instruction, the client will send a first video request to the server, and the server will return a byte stream to the client.
  • This byte stream includes the video description information segment and the A video request corresponds to all the video segments arranged in order.
  • the client will first download and parse the video description information segment, and then start to download the video, and in the process of downloading the video, the video segment can be downloaded after downloading a video segment.
  • the video segments are parsed and then played in sequence. In the whole process, the first video request only needs to be sent once to watch the complete video. That is, the embodiment of the present application avoids the time-consuming sending multiple requests for a video in the prior art.
  • the video request system may further include: an acquisition module, configured to acquire and parse the MPD file of the video before sending the first video request to the server, so as to obtain the byte corresponding to the video description information segment Range; and a download module for downloading the video description information segment according to the byte range after sending the first video request to the server.
  • an acquisition module configured to acquire and parse the MPD file of the video before sending the first video request to the server, so as to obtain the byte corresponding to the video description information segment Range
  • a download module for downloading the video description information segment according to the byte range after sending the first video request to the server.
  • the video request system may further include: a first determining module, configured to determine the byte length of the downloaded video corresponding to the first video request; a first determining module, configured to determine the downloaded video Whether the byte length of the video is greater than or equal to the first preset byte length; and the disconnection module is used to disconnect the first video request when the byte length of the downloaded video is greater than or equal to the first preset byte length .
  • the video request system may further include: a second determining module, configured to determine the byte length of the unplayed video in the downloaded video; and a second determining module, configured to determine the word length of the unplayed video Whether the section length is less than or equal to the second preset byte length; and the second sending module is configured to send a second video request to the server when the byte length of the unplayed video is less than or equal to the second preset byte length, Wherein, the second video request is used to request the remaining videos in the video except the downloaded videos.
  • the video request system may further include: a third determination module, configured to determine the video node corresponding to the skip instruction in response to the skip instruction; and a third determination module, configured to determine whether the video node is Within the range of the downloaded video; and a processing module for disconnecting the first video request and sending a third video request to the server when the video node is not within the range of the downloaded video, where the third video request Used to request the remaining video in the video starting from the byte corresponding to the video node.
  • a third determination module configured to determine the video node corresponding to the skip instruction in response to the skip instruction
  • a third determination module configured to determine whether the video node is Within the range of the downloaded video
  • a processing module for disconnecting the first video request and sending a third video request to the server when the video node is not within the range of the downloaded video, where the third video request Used to request the remaining video in the video starting from the byte corresponding to the video node.
  • the video request system may further include: a fourth determining module, configured to determine the byte corresponding to the definition switching instruction in response to the definition switching instruction; and a third sending module, configured to send The server sends a fourth video request, where the fourth video request is used to request the remaining video in the new definition video starting from the byte corresponding to the definition switching instruction.
  • the content of the new definition video is the same as the content of the video, and the new definition The sharpness of the video is different from the sharpness of the video.
  • Fig. 7 schematically shows a schematic diagram of the hardware architecture of a computer device suitable for implementing a video playback method according to an embodiment of the present application.
  • the computer device 700 is a device that can automatically perform numerical calculation and/or information processing according to pre-set or stored instructions.
  • it can be a smart phone, a tablet computer, a notebook computer, a desktop computer, a rack server, a blade server, a tower server, or a rack server (including an independent server or a server cluster composed of multiple servers).
  • the computer device 700 at least includes but is not limited to: a memory 710, a processor 720, and a network interface 730 that can communicate with each other through a system bus. among them:
  • the memory 710 includes at least one type of computer-readable storage medium.
  • the readable storage medium includes flash memory, hard disk, multimedia card, card-type memory (for example, SD or DX memory, etc.), random access memory (RAM), and static random access memory.
  • SRAM read only memory
  • ROM read only memory
  • EEPROM electrically erasable programmable read only memory
  • PROM programmable read only memory
  • magnetic memory magnetic disks, optical disks, etc.
  • the memory 710 may be an internal storage module of the computer device 700, such as a hard disk or memory of the computer device 700.
  • the memory 710 may also be an external storage device of the computer device 700, such as a plug-in hard disk equipped on the computer device 700, a smart memory card (Smart Media Card, referred to as SMC), and a secure digital (Secure Digital). Digital, abbreviated as SD) card, flash card (Flash Card), etc.
  • the memory 710 may also include both an internal storage module of the computer device 700 and an external storage device thereof.
  • the memory 710 is generally used to store an operating system and various application software installed in the computer device 700, such as program code of a video playback method.
  • the memory 710 may also be used to temporarily store various types of data that have been output or will be output.
  • the processor 720 may be a central processing unit (Central Processing Unit, referred to as CPU for short) in some embodiments, a controller, a microcontroller, a microprocessor, or other data processing chips.
  • the processor 720 is generally used to control the overall operation of the computer device 700, such as performing data interaction or communication-related control and processing with the computer device 700.
  • the processor 720 is configured to run program codes stored in the memory 710 or process data.
  • the network interface 730 may include a wireless network interface or a wired network interface, and the network interface 730 is generally used to establish a communication connection between the computer device 700 and other computer devices.
  • the network interface 730 is used to connect the computer device 700 to an external terminal via a network, and to establish a data transmission channel and a communication connection between the computer device 700 and the external terminal.
  • the network can be Intranet, Internet, Global System of Mobile communication (GSM), Wideband Code Division Multiple Access (WCDMA), 4G network , 5G network, Bluetooth (Bluetooth), Wi-Fi and other wireless or wired networks.
  • FIG. 7 only shows a computer device with components 710-730, but it should be understood that it is not required to implement all the components shown, and more or fewer components may be implemented instead.
  • the video playback method stored in the memory 710 can also be divided into one or more program modules, and executed by one or more processors (the processor 720 in this embodiment) to complete this Application.
  • This embodiment also provides a computer-readable storage medium on which computer-readable instructions are stored.
  • the computer-readable instructions When the computer-readable instructions are executed by a processor, the following steps are implemented:
  • a first video request is sent to the server, where the server returns a video description information segment and a corresponding complete video according to the first video request, and the video includes a plurality of video segments.
  • the video description information segment is used to describe each of the video segments;
  • the video is played in segments according to the parsed video description information segment.
  • the computer-readable storage medium includes flash memory, hard disk, multimedia card, card-type memory (for example, SD or DX memory, etc.), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc.
  • the computer-readable storage medium may be an internal storage unit of a computer device, such as a hard disk or memory of the computer device.
  • the computer-readable storage medium may also be an external storage device of the computer device, such as a plug-in hard disk equipped on the computer device, a smart memory card (Smart Media Card, referred to as SMC), a secure digital ( Secure Digital, referred to as SD card, Flash Card, etc.
  • the computer-readable storage medium may also include both the internal storage unit and the external storage device of the computer device.
  • the computer-readable storage medium is generally used to store the operating system and various application software installed in the computer device, such as the program code of the video playback method in the embodiment.
  • the computer-readable storage medium can also be used to temporarily store various types of data that have been output or will be output.
  • modules or steps of the above-mentioned embodiments of the present application can be implemented by a general computing device, and they can be concentrated on a single computing device or distributed among multiple computing devices.
  • they can be implemented with program codes executable by a computing device, so that they can be stored in a storage device for execution by the computing device, and in some cases, can be different from here
  • the steps shown or described are performed in the order of, or they are respectively fabricated into individual integrated circuit modules, or multiple modules or steps of them are fabricated into a single integrated circuit module to achieve. In this way, the embodiments of the present application are not limited to any specific hardware and software combination.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Human Computer Interaction (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本申请提供了一种视频请求方法，所述方法包括：响应于视频播放指令，向服务器发送第一视频请求，其中，所述服务器根据所述第一视频请求返回视频描述信息段和对应的完整的视频，所述视频包括多个视频分段，所述视频描述信息段用于描述各个所述视频分段；解析所述视频描述信息段；以及在下载所述视频的过程中，根据解析后的所述视频描述信息段，对所述视频进行分段播放。本申请还提供了一种视频播放***、一种计算机设备及一种计算机可读存储介质。

Description

视频请求方法、***、计算机设备及计算机可读存储介质
本申请要求于2019年1月30日提交中国专利局、申请号为201910092651.0、发明名称为“视频请求方法、***、计算机设备及计算机可读存储介质”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及计算机技术领域，尤其涉及一种视频请求方法、***、计算机设备及计算机可读存储介质。
背景技术
DASH(Dynamic Adaptive Streaming over HTTP，基于HTTP的动态自适应流)是一种自适应比特率流技术，可以将一个视频分解为多个分片，每个分片包含一定长度的可播放内容。现有技术在播放视频时，通常是针对每一个分片要发送一次XMLHttpRequest请求，例如视频有3个分片，则至少要发送3次XMLHttpRequest请求。
然而，在实现本申请构思的过程中，发明人发现现有技术中至少存在如下缺陷：现有技术中在播放一个视频时需要发送多次XMLHttpRequest请求，由于请求需要耗费时间，进而导致视频拉流效率降低；另外，在多个XMLHttpRequest请求之间可能会被其他程序***从而影响解析效果。
发明内容
有鉴于此，本申请的目的是提供一种视频请求方法、***、计算机设备及计算机可读存储介质，用于解决现有技术中对一个视频发送多次请求会耗费时间、降低视频拉流效率以及多个请求之间被其他程序***后严重影响解析效果的缺陷。
本申请提供了一种视频请求方法，上述方法包括：响应于视频播放指令，向服务器发送第一视频请求，其中，上述服务器根据上述第一视频请求返回视频描述信息段和对应的完整的视频，上述视频包括多个视频分段，上述视频描述信息段用于描述各个上述视频分段；解析上述视频描述信息段；以及在下载上述视频的过程中，根据解析后的上述视频描述信息段，对上述视频进行分段播放。
为实现上述目的，本申请还提供了一种视频请求***，上述***包括：第一发送模块，用于响应于视频播放指令，向服务器发送第一视频请求，其中，上述服务器根据上述第一 视频请求返回视频描述信息段和对应的完整的视频，上述视频包括多个视频分段，上述视频描述信息段用于描述各个上述视频分段；解析模块，用于解析上述视频描述信息段；以及播放模块，用于在下载上述视频的过程中，根据解析后的上述视频描述信息段，对上述视频进行分段播放。
为实现上述目的，本申请还提供了一种计算机设备，包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，上述处理器执行上述计算机程序时用于实现如上所述的方法的步骤。
本申请的又一个方面提供了一种计算机可读存储介质，其上存储有计算机程序，上述计算机程序被处理器执行时用于实现如上所述的方法的步骤。
本申请提供的视频请求方法，在接收到视频播放指令后，客户端会向服务器发送一个第一视频请求，服务器会向客户端返回字节流，这个字节流包括视频描述信息段和与第一视频请求对应的所有按顺序排列的视频分段，客户端会先下载并解析这个视频描述信息段，然后开始下载视频，并且在下载视频的过程中，下载完一个视频分段就可以对该视频分段进行解析然后按序播放，整个过程中只需要发送一次第一视频请求就可以观看完整的视频，即本申请的实施例避免了现有技术中对一个视频发送多次请求会耗费时间、降低视频拉流效率以及多个请求之间被其他程序***后严重影响解析效果的缺陷，实现了减少请求时间、提高视频拉流效率的技术效果，并且本申请实施例的视频拉流是一个持续的过程，因此不会被其他程序***影响。
附图说明
图1示意性示出了根据本申请实施例的视频播放方法的流程图；
图2示意性示出了现有技术中视频播放方案的示意图；
图3示意性示出了根据本申请实施例的视频播放方案的示意图；
图4示意性示出了现有技术中视频播放方法的流程图；
图5示意性示出了根据本申请另一实施例的视频播放方法的流程图；
图6示意性示出了根据本申请实施例的视频播放***的框图；以及
图7示意性示出了根据本申请实施例的适于实现视频播放方法的计算机设备的硬件架构示意图。
具体实施方式
为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本 申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
本申请提供的视频请求方法，在接收到视频播放指令后，客户端会向服务器发送一个第一视频请求，服务器会向客户端返回字节流，这个字节流包括视频描述信息段和与第一视频请求对应的所有按顺序排列的视频分段，客户端会先下载并解析这个视频描述信息段，然后开始下载视频，并且在下载视频的过程中，下载完一个视频分段就可以对该视频分段进行解析然后按序播放，整个过程中只需要发送一次第一视频请求就可以观看完整的视频，即本申请的实施例避免了现有技术中对一个视频发送多次请求会耗费时间、降低视频拉流效率以及多个请求之间被其他程序***后严重影响解析效果的缺陷，实现了减少请求时间、提高视频拉流效率的技术效果，并且本申请实施例的视频拉流是一个持续的过程，因此不会被其他程序***影响。
图1示意性示出了根据本申请实施例的视频播放方法的流程图。
如图1所示，该视频播放方法可以包括步骤S101-步骤S103，其中：
步骤S101，响应于视频播放指令，向服务器发送第一视频请求，其中，服务器根据第一视频请求返回视频描述信息段和对应的完整的视频，视频包括多个视频分段，视频描述信息段用于描述各个视频分段。
本申请的实施例应用于DASH场景，在DASH场景下，视频可以分为多个视频分段。DASH是基于HTTP的动态自适应流，类似HLS协议，DASH通过一种自适应的比特率流技术，使高质量的流媒体可以通过HTTP协议进行传输。DASH技术会将流媒体内容分解成一系列小型的基于HTTP的文件片段，每个文件片段包含很短长度的可播放内容，而文件内容总长度可能长达数小时(例如电影或体育赛事直播)。文件内容将被制成多种比特率的备选片段，以提供多种比特率的版本供选用。当文件内容被用户端回放时，用户端将根据当前网络条件自动选择下载和播放哪一个备选方案。用户端将选择可及时下载的最高比特率片段进行播放，从而避免播放卡顿或重新缓冲事件。也因如此，用户端可以无缝适应不断变化的网络条件并提供高质量的播放体验，拥有更少的卡顿与重新缓冲发生率。在本申请的实施例，服务器可以通过DASH技术将视频内容切分为多个分片，每个分片的长度可以自定义，例如2s、5s、10s等。
在本申请的实施例中，视频播放方法可以应用在客户端例如web端，第一视频请求可以包括Fetch请求，且第一视频请求不包括请求头，服务器在接收到这个第一视频请求之后，可以返回对应的字节流，该字节流可以包括视频描述信息段和对应的完整的视频。需 要说明是，此处仅仅是服务器向客户端返回字节流，并不表示客户端已经完全接收或下载该字节流。视频描述信息段可以包括Initialization段和Index段，视频可以分为多个视频分段，其中，Initialization段可以包括视频必须的元数据，例如视频的宽度、高度等；Index段可以包括所有视频分段的分段信息，分段信息中包括与该分段信息对应的视频分段的字节范围、时长、以及字节和时长的对应关系。
本申请的实施例是由服务器将完整的视频全部返回，然后客户端再一点点下载这个视频，并且在下载完一个视频分段时便对其进行解析，然后按序播放。此时，便需要知道哪些字节构成一个视频分段，且播放时需要知道视频的元数据，即本申请的实施例中，在下载视频之前，需要先下载视频描述信息段。因此，根据本申请的实施例，该视频播放方法还可以包括：在向服务器发送第一视频请求之前，获取并解析视频的MPD(Media Presentation Description)文件，以获知视频描述信息段对应的字节范围；以及在向服务器发送第一视频请求之后，根据字节范围，下载视频描述信息段。
需要说明的是，MPD文件是视频的描述文件，可以用于描述整个MPEG DASH(又称为DASH)码流的构成，相当于HLS(HTTP Live Streaming)协议的M3U8(M3U8是视频的一种格式)文件，MPD文件是一个XML(Extensible Markup Language，可扩展标记语言)Document(Document是计算机专业术语，每个载入浏览器的HTML(Hyper Text Markup Language，超级文本标记语言)文档都会成为Document对象)，通过MPD文件的内容可以构造出用于HTTP GET请求(HTTP GET请求是HTTP请求的一种方式)下载的URL(Uniform Resource Locator，统一资源定位符)。MPD文件可以描述有视频的每一个分片的分片信息，例如有哪些清晰度、分片的长度等等。
在本申请的实施例中，MPD文件中还可以包括视频描述信息段的字节范围，通过获取并解析MPD文件，可以知道视频描述信息段的字节范围，其中，MPD文件可以是通过向服务器发送其他请求比如XMLHttpRequest请求获取的。
例如，通过解析MPD文件已知视频描述信息段的字节范围为0-99Byte，然后发起Fetch请求，服务器返回字节流，客户端首先下载0-99Byte范围内的数据。
步骤S102，解析视频描述信息段。
根据本申请的实施例，解析视频描述信息段可以是解析Initialization段和Index段，通过解析Initialization段可以知道视频的元数据，通过解析Index段可以知道视频的分段信息。本申请的实施例可以将解析后的视频描述信息段暂存在内存中。
例如，解析视频描述信息段后，可以获知视频的分段信息例如分别为：视频分段1为1-5s，对应100-299Byte，1s对应100Byte，5s对应299Byte；视频分段2为6-10s，对 应300-499Byte，6s对应300Byte，10s对应499Byte；视频分段3为11-15s，对应500-699Byte，11s对应500Byte，15s对应699Byte；视频分段4为16-20s，对应700-899Byte，16s对应700Byte，20s对应899Byte。
步骤S103，在下载视频的过程中，根据解析后的视频描述信息段，对视频进行分段播放。
例如，客户端一点点下载剩余的字节流，若下载完100-299Byte范围的字节流，即可以对其进行解析然后播放，若下载完300-499Byte范围的字节流，也可以对其进行解析，然后在视频分段1播放完之后，再播放该视频分段2，依次类推。
为了更清楚地理解本方案与现有技术的区别，现结合图2和图3进行详细说明。
图2示意性示出了现有技术中视频播放方案的示意图。如图2所示，在请求视频时，先进行内核初始化、http建联，然后对于每一个视频分段均发送一个请求(即请求数据网络，例如XMLHttpRequest请求)，并对每一次请求回来的数据进行解析。
图3示意性示出了根据本申请实施例的视频播放方案的示意图。如图3所示，在请求视频时，先进行内核初始化、http建联，然后只需要向服务器发送一个视频请求(即请求数据网络，例如Fetch请求)，服务器即可将全部的视频返回，然后客户端在一点点下载数据，并根据分段信息解析数据。显然，本申请的实施例相比于现有技术而言，在播放视频时，只需发送一次第一视频请求即可。
本申请提供的视频请求方法，在接收到视频播放指令后，客户端会向服务器发送一个第一视频请求，服务器会向客户端返回字节流，这个字节流包括视频描述信息段和与第一视频请求对应的所有按顺序排列的视频分段，客户端会先下载并解析这个视频描述信息段，然后开始下载视频，并且在下载视频的过程中，下载完一个视频分段就可以对该视频分段进行解析然后按序播放，整个过程中只需要发送一次第一视频请求就可以观看完整的视频，即本申请的实施例避免了现有技术中对一个视频发送多次请求会耗费时间、降低视频拉流效率以及多个请求之间被其他程序***后严重影响解析效果的缺陷，实现了减少请求时间、提高视频拉流效率的技术效果，并且本申请实施例的视频拉流是一个持续的过程，因此不会被其他程序***影响。
作为一种可选的实施例，该视频解析方法还可以包括：确定与第一视频请求对应的已下载视频的字节长度；判断已下载视频的字节长度是否大于等于第一预设字节长度；以及若已下载视频的字节长度大于等于第一预设字节长度，则断开第一视频请求。
具体地，有时用户并不会在同一时间看完整个视频，若是为用户缓冲完整个视频而用户只观看了其中一小部分，则会导致流量的浪费。本申请的实施例为了节省流量，可以设 置一个第一预设字节长度，若已下载视频的字节长度大于等于该第一预设字节长度，则断开第一视频请求，不再为用户下载剩余视频。优选地，该第一预设字节长度大于视频分段的最小字节长度。
例如，第一预设字节长度为3000Byte，则若是已经为用户下载了3000Byte的视频时，可以断开该Fetch请求。
进一步，断开第一视频请求之后，随着视频的播放，已下载视频中未播放时视频的字节长度(又称为剩余缓冲区)会逐渐减少，为了不影响用户正常观看，该视频解析方法还可以包括：确定已下载视频中未播放视频的字节长度；判断未播放视频的字节长度是否小于等于第二预设字节长度；以及若未播放视频的字节长度小于等于第二预设字节长度，则向服务器发送第二视频请求，其中，第二视频请求用于请求视频中除已下载视频之外的剩余视频。
具体地，在已下载视频中未播放时视频的字节长度小于等于第二预设字节长度(又称为最小缓冲区长度)时，可以发起新的Fetch请求，该Fetch请求包括请求头，且请求头的range字段的起始字节为已下载视频结尾对应的字节。
例如，完整的视频为对应的字节范围为100-1899Byte，已下载视频对应字节范围为100-999Byte，第二预设字节长度为300Byte，若是此时播放位置为699Byte，则未播放视频的字节长度为999-699＝300Byte。此时，客户端可以向服务器发送新的Fetch请求，该Fetch请求的range字段的起始字节为999Byte，例如“999-”，即该Fetch请求用于向服务器请求999-1999Byte范围的视频数据。
作为一种可选的实施例，该视频解析方法还可以包括：响应于跳播指令，确定跳播指令对应的视频节点；判断视频节点是否在已下载视频的范围内；以及若视频节点不在已下载视频的范围内，则断开第一视频请求，并向服务器发送第三视频请求，其中，第三视频请求用于请求视频中以视频节点对应的字节为起点的剩余视频。
在本申请的实施例中，跳播指令可以包括seek指令，判断视频节点是否在已下载视频的范围内可以是判断视频节点对应的时间节点是否在已下载视频的时长范围内，或者判断视频节点对应的字节是否在已下载视频的字节范围内。若是，则不需要执行额外的操作，只需要将视频从该视频节点开始播放即可。若不是，则断开Fetch请求，并发起一个新的Fetch请求，该Fetch请求包括请求头，且请求头的range字段的起始字节为视频节点对应视频分段的起始字节。
例如，完整的视频为40s，对应的字节范围为100-1899Byte，已下载视频的长度为20s，对应字节范围为100-999Byte，跳播指令对应的视频节点对应的时间节点为30s，对 应的字节为1449Byte，即视频节点不在已下载视频的范围内，则客户端可以向服务器发送新的Fetch请求，该Fetch请求的range字段的起始字节为1449Byte，例如“1449-”，即该Fetch请求用于向服务器请求1449-1899Byte范围的视频数据。
作为一种可选的实施例，该视频解析方法还可以包括：响应于清晰度切换指令，确定清晰度切换指令对应的字节；以及向服务器发送第四视频请求，其中，第四视频请求用于请求新清晰度视频中以清晰度切换指令对应的字节为起点的剩余视频，新清晰度视频的内容与视频的内容相同，新清晰度视频的清晰度与视频的清晰度不同。
在本申请的实施例中，不同清晰度视频的视频描述信息段不同，在切换清晰度场景下，可以先向服务器发送一个用于请求新清晰度视频的视频描述信息段的Fetch请求，该Fetch请求的range字段的范围为视频描述信息段的字节范围。下载并解析视频描述信息段，然后向服务器发送第四视频请求如另一个Fetch请求，这个Fetch请求的range字段的起始字节为清晰度切换指令对应的字节。
例如，完整的视频对应的字节范围为100-1899Byte，清晰度切换指令对应的字节为1200Byte，客户端可以向服务器发送新的Fetch请求，该Fetch请求的range字段的起始字节为1200Byte，例如“1200-”，即该Fetch请求用于向服务器请求1200-1899Byte范围的视频数据。
图4示意性示出了现有技术中视频播放方法的流程图。
如图4所示，现有技术中视频播放方法可以包括步骤S401-步骤S406，其中：
步骤S401，播放初始化。
步骤S402，解析MPD文件。
步骤S403，请求Initialization段和Index段。
步骤S404，解析Initialization段和Index段。
步骤S405，请求下一个视频分段。
步骤S406，解析视频分段。
需要说明的是，DASH会将内容分解成一系列小型的基于HTTP的文件分段，每个分段包含视频信息或很短长度的可播放视频内容，客户端将选择可及时下载的最高比特率视频内容片段进行播放，从而避免播放卡顿或重新缓冲事件。分段有三种类型，Initialization段、Index段、视频分段，Initialization段里包含了呈现视频必需的metadata信息，Index段里包含了对应视频中所有视频分段的分段信息，视频分段包含可播放的视频内容，Initialization段和Index段的范围信息在MPD信息里已知。
现有技术中使用的XMLHttpRequest请求只能在请求完成后读取数据。具体地，现有 技术中，客户端首先请求Index段和Initialization段，请求并解析完成后，可以从Index段的数据获取到视频分段的分段信息，对每个视频分段都使用一个新的XMLHttpRequest请求，请求地址是视频地址，请求头的range字段指定需要的字节范围，例如“100-299”,服务端返回range字段指定范围的字节数据。例如，根据分段信息请求第一个视频分段，第一个视频分段请求并解析完成再请求第二个视频分段，依此类推。
图5示意性示出了根据本申请另一实施例的视频播放方法的流程图。
如图5所示，该视频播放方法可以包括步骤S501-步骤S508，其中：
步骤S501，播放初始化。
步骤S502，解析MPD文件。
步骤S503，发起Fetch请求。
步骤S504，读取并解析Initialization段和Index段。
步骤S505，读取并解析下一个视频分段
步骤S506，判断是否超过稳定缓冲区，若是执行步骤S507，若否执行步骤S505。
步骤S507，中断请求。
步骤S508，缓冲结束。
在本申请的实施例中，使用Fetch请求可以在请求过程中循环读取字节流，所以只需要建立一次连接就可以请求所有视频分段。客户端先主动对视频地址发起没有请求头的Fetch请求，这时服务端会返回完整的视频数据，客户端持续下载视频数据，在下载过程中循环读取字节流。Index段和Initialization段在字节流开头的位置，且范围已知，会被客户端首先下载并读取到，取到完整的Index段和Initialization段数据后交给解析模块解析，解析完Index段的数据可以获取到分段信息，拿到分段信息后才可以识别哪些字节是一个完整的视频分段。解析完Index段和Initialization段数据再继续读取字节流，每读取到一个完整的视频分段后交给解析模块解析。已下载视频的字节长度超过预设的稳定缓冲区对应的字节长度(又称为第一预设字节长度)时主动断开Fetch请求。
播放会引起剩余缓冲区(又称为未播放视频的字节长度)减小，如果剩余缓冲区小于最小缓冲区长度(又称为第二预设字节长度)，则发起新的Fetch请求，此请求以剩余缓冲区结尾对应的字节为起点，请求头的range字段形如“1000-”。
seek时，如果有未结束的Fetch请求，seek时间在缓冲区(又称为已下载视频的范围)外时中断当前请求，重新发起以seek时间对应的字节为起点的新的Fetch请求，seek时间在缓冲区内时不需要执行额外操作；如果没有未结束的Fetch请求，同上述播放场景。
切换清晰度时会先对新清晰度视频地址发起一个Fetch请求，range字段的范围为 Index段和Initialization段两个段的字节范围，形如“0-1000”，得到新清晰度的分段信息后再发起另一个Fetch请求，range字段开头为视频切换指令对应的字节，形如“1000-”。
图6示意性示出了根据本申请实施例的视频解析***的框图。
如图6所示，该视频解析***600可以包括第一发送模块610、解析模块620和播放模块630，其中：
第一发送模块610用于响应于视频播放指令，向服务器发送第一视频请求，其中，服务器根据第一视频请求返回视频描述信息段和对应的完整的视频，视频包括多个视频分段，视频描述信息段用于描述各个视频分段。
解析模块620用于解析视频描述信息段。
播放模块630用于在下载视频的过程中，根据解析后的视频描述信息段，对视频进行分段播放。
本申请提供的视频请求***，在接收到视频播放指令后，客户端会向服务器发送一个第一视频请求，服务器会向客户端返回字节流，这个字节流包括视频描述信息段和与第一视频请求对应的所有按顺序排列的视频分段，客户端会先下载并解析这个视频描述信息段，然后开始下载视频，并且在下载视频的过程中，下载完一个视频分段就可以对该视频分段进行解析然后按序播放，整个过程中只需要发送一次第一视频请求就可以观看完整的视频，即本申请的实施例避免了现有技术中对一个视频发送多次请求会耗费时间、降低视频拉流效率以及多个请求之间被其他程序***后严重影响解析效果的缺陷，实现了减少请求时间、提高视频拉流效率的技术效果，并且本申请实施例的视频拉流是一个持续的过程，因此不会被其他程序***影响。
作为一种可选的实施例，该视频请求***还可以包括：获取模块，用于在向服务器发送第一视频请求之前，获取并解析视频的MPD文件，以获知视频描述信息段对应的字节范围；以及下载模块，用于在向服务器发送第一视频请求之后，根据字节范围，下载视频描述信息段。
作为一种可选的实施例，该视频请求***还可以包括：第一确定模块，用于确定与第一视频请求对应的已下载视频的字节长度；第一判断模块，用于判断已下载视频的字节长度是否大于等于第一预设字节长度；以及断开模块，用于在已下载视频的字节长度大于等于第一预设字节长度的情况下，断开第一视频请求。
作为一种可选的实施例，该视频请求***还可以包括：第二确定模块，用于确定已下载视频中未播放视频的字节长度；第二判断模块，用于判断未播放视频的字节长度是否小 于等于第二预设字节长度；以及第二发送模块，用于在未播放视频的字节长度小于等于第二预设字节长度的情况下，向服务器发送第二视频请求，其中，第二视频请求用于请求视频中除已下载视频之外的剩余视频。
作为一种可选的实施例，该视频请求***还可以包括：第三确定模块，用于响应于跳播指令，确定跳播指令对应的视频节点；第三判断模块，用于判断视频节点是否在已下载视频的范围内；以及处理模块，用于在视频节点不在已下载视频的范围内的情况下，断开第一视频请求，并向服务器发送第三视频请求，其中，第三视频请求用于请求视频中以视频节点对应的字节为起点的剩余视频。
作为一种可选的实施例，该视频请求***还可以包括：第四确定模块，用于响应于清晰度切换指令，确定清晰度切换指令对应的字节；以及第三发送模块，用于向服务器发送第四视频请求，其中，第四视频请求用于请求新清晰度视频中以清晰度切换指令对应的字节为起点的剩余视频，新清晰度视频的内容与视频的内容相同，新清晰度视频的清晰度与视频的清晰度不同。
图7示意性示出了根据本申请实施例的适于实现视频播放方法的计算机设备的硬件架构示意图。本实施例中，计算机设备700是一种能够按照事先设定或者存储的指令，自动进行数值计算和/或信息处理的设备。例如，可以是智能手机、平板电脑、笔记本电脑、台式计算机、机架式服务器、刀片式服务器、塔式服务器或机柜式服务器(包括独立的服务器，或者多个服务器所组成的服务器集群)等。如图7所示，计算机设备700至少包括但不限于：可通过***总线相互通信连接存储器710、处理器720、网络接口730。其中：
存储器710至少包括一种类型的计算机可读存储介质，可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，存储器710可以是计算机设备700的内部存储模块，例如该计算机设备700的硬盘或内存。在另一些实施例中，存储器710也可以是计算机设备700的外部存储设备，例如该计算机设备700上配备的插接式硬盘，智能存储卡(Smart Media Card，简称为SMC)，安全数字(Secure Digital，简称为SD)卡，闪存卡(Flash Card)等。当然，存储器710还可以既包括计算机设备700的内部存储模块也包括其外部存储设备。本实施例中，存储器710通常用于存储安装于计算机设备700的操作***和各类应用软件，例如视频播放方法的程序代码等。此外，存储器710还可以用于暂时地存储已经输出或者将要输出的各类数据。
处理器720在一些实施例中可以是中央处理器(Central Processing Unit，简称为 CPU)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器720通常用于控制计算机设备700的总体操作，例如执行与计算机设备700进行数据交互或者通信相关的控制和处理等。本实施例中，处理器720用于运行存储器710中存储的程序代码或者处理数据。
网络接口730可包括无线网络接口或有线网络接口，该网络接口730通常用于在计算机设备700与其他计算机设备之间建立通信连接。例如，网络接口730用于通过网络将计算机设备700与外部终端相连，在计算机设备700与外部终端之间的建立数据传输通道和通信连接等。网络可以是企业内部网(Intranet)、互联网(Internet)、全球移动通讯***(Global System of Mobile communication，简称为GSM)、宽带码分多址(Wideband Code Division Multiple Access，简称为WCDMA)、4G网络、5G网络、蓝牙(Bluetooth)、Wi-Fi等无线或有线网络。
需要指出的是，图7仅示出了具有部件710-730的计算机设备，但是应理解的是，并不要求实施所有示出的部件，可以替代的实施更多或者更少的部件。
在本实施例中，存储于存储器710中的视频播放方法还可以被分割为一个或者多个程序模块，并由一个或多个处理器(本实施例为处理器720)所执行，以完成本申请。
本实施例还提供一种计算机可读存储介质，计算机可读存储介质其上存储有计算机可读指令，计算机可读指令被处理器执行时实现以下步骤：
响应于视频播放指令，向服务器发送第一视频请求，其中，所述服务器根据所述第一视频请求返回视频描述信息段和对应的完整的视频，所述视频包括多个视频分段，所述视频描述信息段用于描述各个所述视频分段；
解析所述视频描述信息段；以及
在下载所述视频的过程中，根据解析后的所述视频描述信息段，对所述视频进行分段播放。
本实施例中，计算机可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，计算机可读存储介质可以是计算机设备的内部存储单元，例如该计算机设备的硬盘或内存。在另一些实施例中，计算机可读存储介质也可以是计算机设备的外部存储设备，例如该计算机设备上配备的插接式硬盘，智能存储卡(Smart Media Card，简称为SMC)，安全数字(Secure Digital，简称为SD)卡，闪存卡(Flash Card)等。当然，计算机可读存储介质还可以既包括计算机设备的内部存储单元也包括其外部存 储设备。本实施例中，计算机可读存储介质通常用于存储安装于计算机设备的操作***和各类应用软件，例如实施例中的视频播放方法的程序代码等。此外，计算机可读存储介质还可以用于暂时地存储已经输出或者将要输出的各类数据。
显然，本领域的技术人员应该明白，上述的本申请实施例的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本申请实施例不限制于任何特定的硬件和软件结合。
以上仅为本申请的优选实施例，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。

Claims (20)

  1. 一种视频请求方法，所述方法包括：
    响应于视频播放指令，向服务器发送第一视频请求，其中，所述服务器根据所述第一视频请求返回视频描述信息段和对应的完整的视频，所述视频包括多个视频分段，所述视频描述信息段用于描述各个所述视频分段；
    解析所述视频描述信息段；以及
    在下载所述视频的过程中，根据解析后的所述视频描述信息段，对所述视频进行分段播放。
  2. 根据权利要求1所述的方法，所述方法还包括：
    在所述向服务器发送第一视频请求之前，获取并解析所述视频的MPD文件，以获知所述视频描述信息段对应的字节范围；以及
    在所述向服务器发送第一视频请求之后，根据所述字节范围，下载所述视频描述信息段。
  3. 根据权利要求1所述的方法，所述方法还包括：
    确定与所述第一视频请求对应的已下载视频的字节长度；
    判断所述已下载视频的字节长度是否大于等于第一预设字节长度；以及
    若所述已下载视频的字节长度大于等于所述第一预设字节长度，则断开所述第一视频请求。
  4. 根据权利要求3所述的方法，所述方法还包括：
    确定所述已下载视频中未播放视频的字节长度；
    判断所述未播放视频的字节长度是否小于等于第二预设字节长度；以及
    若所述未播放视频的字节长度小于等于所述第二预设字节长度，则向所述服务器发送第二视频请求，其中，所述第二视频请求用于请求所述视频中除所述已下载视频之外的剩余视频。
  5. 根据权利要求3的方法，所述方法还包括：
    响应于跳播指令，确定所述跳播指令对应的视频节点；
    判断所述视频节点是否在所述已下载视频的范围内；以及
    若所述视频节点不在所述已下载视频的范围内，则断开所述第一视频请求，并向所述服务器发送第三视频请求，其中，所述第三视频请求用于请求所述视频中以所述视频节点对应的字节为起点的剩余视频。
  6. 根据权利要求1的方法，所述方法还包括：
    响应于清晰度切换指令，确定所述清晰度切换指令对应的字节；以及
    向所述服务器发送第四视频请求，其中，所述第四视频请求用于请求新清晰度视频中以所述清晰度切换指令对应的字节为起点的剩余视频，所述新清晰度视频的内容与所述视频的内容相同，所述新清晰度视频的清晰度与所述视频的清晰度不同。
  7. 一种视频请求***，所述***包括：
    第一发送模块，用于响应于视频播放指令，向服务器发送第一视频请求，其中，所述服务器根据所述第一视频请求返回视频描述信息段和对应的完整的视频，所述视频包括多个视频分段，所述视频描述信息段用于描述各个所述视频分段；
    解析模块，用于解析所述视频描述信息段；以及
    播放模块，用于在下载所述视频的过程中，根据解析后的所述视频描述信息段，对所述视频进行分段播放。
  8. 根据权利要求7所述的***，所述***还包括：
    获取模块，用于在所述向服务器发送第一视频请求之前，获取并解析所述视频的MPD文件，以获知所述视频描述信息段对应的字节范围；以及
    下载模块，用于在所述向服务器发送第一视频请求之后，根据所述字节范围，下载所述视频描述信息段。
  9. 一种计算机设备，包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机可读指令，所述处理器执行所述计算机可读指令时用于实现以下步骤：
    响应于视频播放指令，向服务器发送第一视频请求，其中，所述服务器根据所述第一视频请求返回视频描述信息段和对应的完整的视频，所述视频包括多个视频分段，所述视频描述信息段用于描述各个所述视频分段；
    解析所述视频描述信息段；以及
    在下载所述视频的过程中，根据解析后的所述视频描述信息段，对所述视频进行分段播放。
  10. 根据权利要求9所述的计算机设备，所述处理器执行所述计算机可读指令时还用于实现以下步骤：
    在所述向服务器发送第一视频请求之前，获取并解析所述视频的MPD文件，以获知所述视频描述信息段对应的字节范围；以及
    在所述向服务器发送第一视频请求之后，根据所述字节范围，下载所述视频描述信息段。
  11. 根据权利要求9所述的计算机设备，所述处理器执行所述计算机可读指令时还用于实现以下步骤：
    确定与所述第一视频请求对应的已下载视频的字节长度；
    判断所述已下载视频的字节长度是否大于等于第一预设字节长度；以及
    若所述已下载视频的字节长度大于等于所述第一预设字节长度，则断开所述第一视频请求。
  12. 根据权利要求11所述的计算机设备，所述处理器执行所述计算机可读指令时还用于实现以下步骤：
    确定所述已下载视频中未播放视频的字节长度；
    判断所述未播放视频的字节长度是否小于等于第二预设字节长度；以及
    若所述未播放视频的字节长度小于等于所述第二预设字节长度，则向所述服务器发送第二视频请求，其中，所述第二视频请求用于请求所述视频中除所述已下载视频之外的剩余视频。
  13. 根据权利要求11所述的计算机设备，所述处理器执行所述计算机可读指令时还用于实现以下步骤：
    响应于跳播指令，确定所述跳播指令对应的视频节点；
    判断所述视频节点是否在所述已下载视频的范围内；以及
    若所述视频节点不在所述已下载视频的范围内，则断开所述第一视频请求，并向所述服务器发送第三视频请求，其中，所述第三视频请求用于请求所述视频中以所述视频节点对应的字节为起点的剩余视频。
  14. 根据权利要求9所述的计算机设备，所述处理器执行所述计算机可读指令时还用于实现以下步骤：
    响应于清晰度切换指令，确定所述清晰度切换指令对应的字节；以及
    向所述服务器发送第四视频请求，其中，所述第四视频请求用于请求新清晰度视频中以所述清晰度切换指令对应的字节为起点的剩余视频，所述新清晰度视频的内容与所述视频的内容相同，所述新清晰度视频的清晰度与所述视频的清晰度不同。
  15. 一种计算机可读存储介质，其上存储有计算机可读指令，所述计算机可读指令被处理器执行时用于实现以下步骤：
    响应于视频播放指令，向服务器发送第一视频请求，其中，所述服务器根据所述第一视频请求返回视频描述信息段和对应的完整的视频，所述视频包括多个视频分段，所述视频描述信息段用于描述各个所述视频分段；
    解析所述视频描述信息段；以及
    在下载所述视频的过程中，根据解析后的所述视频描述信息段，对所述视频进行分段播放。
  16. 根据权利要求15所述的计算机可读存储介质，所述计算机可读指令被所述处理器执行时还用于实现以下步骤：
    在所述向服务器发送第一视频请求之前，获取并解析所述视频的MPD文件，以获知所述视频描述信息段对应的字节范围；以及
    在所述向服务器发送第一视频请求之后，根据所述字节范围，下载所述视频描述信息段。
  17. 根据权利要求15所述的计算机可读存储介质，所述计算机可读指令被所述处理器执行时还用于实现以下步骤：
    确定与所述第一视频请求对应的已下载视频的字节长度；
    判断所述已下载视频的字节长度是否大于等于第一预设字节长度；以及
    若所述已下载视频的字节长度大于等于所述第一预设字节长度，则断开所述第一视频请求。
  18. 根据权利要求17所述的计算机可读存储介质，所述计算机可读指令被所述处理器执行时还用于实现以下步骤：
    确定所述已下载视频中未播放视频的字节长度；
    判断所述未播放视频的字节长度是否小于等于第二预设字节长度；以及
    若所述未播放视频的字节长度小于等于所述第二预设字节长度，则向所述服务器发送第二视频请求，其中，所述第二视频请求用于请求所述视频中除所述已下载视频之外的剩余视频。
  19. 根据权利要求17所述的计算机可读存储介质，所述计算机可读指令被所述处理器执行时还用于实现以下步骤：
    响应于跳播指令，确定所述跳播指令对应的视频节点；
    判断所述视频节点是否在所述已下载视频的范围内；以及
    若所述视频节点不在所述已下载视频的范围内，则断开所述第一视频请求，并向所述服务器发送第三视频请求，其中，所述第三视频请求用于请求所述视频中以所述视频节点对应的字节为起点的剩余视频。
  20. 根据权利要求15所述的计算机可读存储介质，所述计算机可读指令被所述处理器执行时还用于实现以下步骤：
    响应于清晰度切换指令，确定所述清晰度切换指令对应的字节；以及
    向所述服务器发送第四视频请求，其中，所述第四视频请求用于请求新清晰度视频中以所述清晰度切换指令对应的字节为起点的剩余视频，所述新清晰度视频的内容与所述视频的内容相同，所述新清晰度视频的清晰度与所述视频的清晰度不同。
PCT/CN2019/128454 2019-01-30 2019-12-25 视频请求方法、***、计算机设备及计算机可读存储介质 WO2020155961A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP19912500.6A EP3883251A4 (en) 2019-01-30 2019-12-25 VIDEO REQUEST PROCESS AND SYSTEM, COMPUTER DEVICE AND COMPUTER READABLE INFORMATION MEDIA
US17/304,732 US11496536B2 (en) 2019-01-30 2021-06-24 Method of requesting video, computing device, and computer-program product

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910092651.0A CN111510790B (zh) 2019-01-30 2019-01-30 视频请求方法、***、计算机设备及计算机可读存储介质
CN201910092651.0 2019-01-30

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/304,732 Continuation US11496536B2 (en) 2019-01-30 2021-06-24 Method of requesting video, computing device, and computer-program product

Publications (1)

Publication Number Publication Date
WO2020155961A1 true WO2020155961A1 (zh) 2020-08-06

Family

ID=71840822

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/128454 WO2020155961A1 (zh) 2019-01-30 2019-12-25 视频请求方法、***、计算机设备及计算机可读存储介质

Country Status (4)

Country Link
US (1) US11496536B2 (zh)
EP (1) EP3883251A4 (zh)
CN (1) CN111510790B (zh)
WO (1) WO2020155961A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113301095B (zh) * 2020-12-08 2024-05-10 阿里巴巴集团控股有限公司 提供云端对象的数据的方法以及装置
CN113347471B (zh) * 2021-06-01 2023-05-02 咪咕文化科技有限公司 视频播放方法、装置、设备及存储介质
CN113794898B (zh) * 2021-08-13 2023-03-07 网宿科技股份有限公司 Dash媒体流传输方法、电子设备及存储介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102857794A (zh) * 2011-06-28 2013-01-02 上海聚力传媒技术有限公司 一种用于合并视频分段的方法与设备
CN103974147A (zh) * 2014-03-07 2014-08-06 北京邮电大学 一种基于mpeg-dash协议的带***率切换控制和静态摘要技术的在线视频播控***
CN104244079A (zh) * 2013-06-07 2014-12-24 腾讯科技（深圳）有限公司 一种视频下载方法及装置
CN106534946A (zh) * 2016-10-26 2017-03-22 腾讯科技（深圳）有限公司 视频播放的控制方法和装置
WO2017100769A1 (en) * 2015-12-11 2017-06-15 Vid Scale, Inc. Scheduling multiple-layer video segments
CN106921865A (zh) * 2017-05-11 2017-07-04 腾讯科技（深圳）有限公司 视频处理方法及装置

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2491495A4 (en) * 2009-11-04 2013-01-02 Huawei Tech Co Ltd SYSTEM AND METHOD FOR DIFFUSION OF CONTINUOUS MULTIMEDIA CONTENT
US9503490B2 (en) * 2012-02-27 2016-11-22 Qualcomm Incorporated Dash client and receiver with buffer water-level decision-making
CN103384236A (zh) * 2012-05-04 2013-11-06 华为技术有限公司 获取流媒体数据的方法、装置及***
AU2013288859B2 (en) * 2012-07-09 2016-05-19 Vid Scale, Inc. Power aware video decoding and streaming
CN104105012B (zh) * 2013-04-03 2018-04-20 华为技术有限公司 流媒体的片段准备方法和装置
IL231685A (en) * 2014-03-24 2015-09-24 Giraffic Technologies Ltd A system and method for predicting memory reduction and network design
US9860612B2 (en) * 2014-04-10 2018-01-02 Wowza Media Systems, LLC Manifest generation and segment packetization
CN105100172B (zh) * 2014-05-22 2018-03-27 华为技术有限公司 一种http协议的缓存状态更新方法和设备、处理机
KR102185876B1 (ko) * 2014-10-16 2020-12-02 삼성전자주식회사 무선 네트워크 환경에서 http 적응적 스트리밍 방법 및 장치
US9509742B2 (en) * 2014-10-29 2016-11-29 DLVR, Inc. Configuring manifest files referencing infrastructure service providers for adaptive streaming video
US9426543B1 (en) * 2015-12-18 2016-08-23 Vuclip (Singapore) Pte. Ltd. Server-based video stitching
CN106961630B (zh) * 2017-03-24 2019-08-16 西安理工大学 一种基于dash优化的p2p流媒体视频播放方法
CN106993237B (zh) * 2017-04-13 2019-05-10 中北大学 基于mpeg-dash协议的动态自适应码率选择方法

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102857794A (zh) * 2011-06-28 2013-01-02 上海聚力传媒技术有限公司 一种用于合并视频分段的方法与设备
CN104244079A (zh) * 2013-06-07 2014-12-24 腾讯科技（深圳）有限公司 一种视频下载方法及装置
CN103974147A (zh) * 2014-03-07 2014-08-06 北京邮电大学 一种基于mpeg-dash协议的带***率切换控制和静态摘要技术的在线视频播控***
WO2017100769A1 (en) * 2015-12-11 2017-06-15 Vid Scale, Inc. Scheduling multiple-layer video segments
CN106534946A (zh) * 2016-10-26 2017-03-22 腾讯科技（深圳）有限公司 视频播放的控制方法和装置
CN106921865A (zh) * 2017-05-11 2017-07-04 腾讯科技（深圳）有限公司 视频处理方法及装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3883251A4 *

Also Published As

Publication number Publication date
CN111510790A (zh) 2020-08-07
EP3883251A1 (en) 2021-09-22
CN111510790B (zh) 2021-10-15
US20210320957A1 (en) 2021-10-14
EP3883251A4 (en) 2021-12-15
US11496536B2 (en) 2022-11-08

Similar Documents

Publication Publication Date Title
CN108391179B (zh) 直播数据处理方法、装置、服务器、终端及存储介质
WO2020155961A1 (zh) 视频请求方法、***、计算机设备及计算机可读存储介质
WO2020155960A1 (zh) 视频播放方法、***、计算机设备及计算机可读存储介质
CN110933517B (zh) 码率切换方法、客户端和计算机可读存储介质
TWI470983B (zh) 用以更新超文件傳輸協定內容描述之方法及裝置
WO2020155959A1 (zh) 切换清晰度的方法、装置、计算机设备及可读存储介质
CN106572358A (zh) 一种直播时移方法及客户端
JP6314252B2 (ja) ネットワークビデオ再生方法及び装置
CN108933764B (zh) 一种实现快速起播的方法和装置
US11490173B2 (en) Switch of audio and video
US20150172353A1 (en) Method and apparatus for interacting with a media presentation description that describes a summary media presentation and an original media presentation
US11863841B2 (en) Video playing control method and system
US20210021655A1 (en) System and method for streaming music on mobile devices
EP3175599A1 (en) Systems and methods for selective transport accelerator operation
WO2020155956A1 (zh) 首帧均衡限流方法、装置、计算机设备及可读存储介质
WO2023284428A1 (zh) 直播视频的播放方法、装置、电子设备、存储介质及程序产品
WO2024082688A1 (zh) 礼物特效资源播放方法及装置
WO2020155962A1 (zh) 清晰度切换算法的选择方法、***、设备及介质
WO2020155963A1 (zh) 视频清晰度确定方法、***、计算机设备及存储介质
US20230388590A1 (en) Playback optimization method and system
CN113691886B (zh) 流媒体文件的下载方法和装置
CN113438313B (zh) 视频续播处理方法、相关装置及可读存储介质
WO2020155957A1 (zh) 播放音视频的方法、装置、计算机设备及可读存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19912500

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 19912500.6

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2019912500

Country of ref document: EP

Effective date: 20210615

NENP Non-entry into the national phase

Ref country code: DE