CN113630657A - Video playing optimization method and system based on hls protocol - Google Patents
Video playing optimization method and system based on hls protocol Download PDFInfo
- Publication number
- CN113630657A CN113630657A CN202110888274.9A CN202110888274A CN113630657A CN 113630657 A CN113630657 A CN 113630657A CN 202110888274 A CN202110888274 A CN 202110888274A CN 113630657 A CN113630657 A CN 113630657A
- Authority
- CN
- China
- Prior art keywords
- timestamp
- playing
- time
- player
- client
- Prior art date
- Legal status (The legal status 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 status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 59
- 238000005457 optimization Methods 0.000 title claims abstract description 32
- 230000008569 process Effects 0.000 claims abstract description 24
- 239000012634 fragment Substances 0.000 claims description 40
- 230000000694 effects Effects 0.000 abstract description 6
- 230000015654 memory Effects 0.000 description 29
- 230000009471 action Effects 0.000 description 5
- 230000008859 change Effects 0.000 description 5
- 230000005540 biological transmission Effects 0.000 description 3
- 241000282326 Felis catus Species 0.000 description 2
- 230000003111 delayed effect Effects 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 238000010586 diagram Methods 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 238000013467 fragmentation Methods 0.000 description 1
- 238000006062 fragmentation reaction Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000005192 partition Methods 0.000 description 1
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/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/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/643—Communication protocols
-
- 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/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs
- H04N21/4402—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display
-
- 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/47217—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 controlling playback functions for recorded or on-demand content, e.g. using progress bars, mode or play-point indicators or bookmarks
-
- 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/8547—Content authoring involving timestamps for synchronizing content
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Databases & Information Systems (AREA)
- Human Computer Interaction (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
The invention provides a video playing optimization method and a video playing optimization system based on an hls protocol, wherein the method comprises the following steps: creating a player and inquiring whether an ending time stamp exists; if the ending timestamp exists, the player searches a playing time node corresponding to the ending timestamp according to the ending timestamp to play; the end timestamp is a timestamp recorded by the last-created player at the video playing end moment; and the playing time node corresponding to the ending timestamp is the playing time node which is obtained and recorded as the timestamp by the player established last time in the video playing process. By saving the current time node as the end timestamp when the playing is finished, the corresponding playing time node is found for playing according to the saved end timestamp when the player is re-established, so that the increase of playing delay is avoided, and the playing effect is optimized.
Description
Technical Field
The invention relates to the field of video playing, in particular to a video playing optimization method based on hls protocol and a video playing optimization system based on hls protocol.
Background
HLS (HTTP Live Streaming, HTTP real-time Streaming) is a HTTP-based Streaming media network transport protocol proposed by apple inc. The protocol is largely used for live on-demand broadcasting in the current network environment. Although the hls Protocol has many advantages, the hls Protocol live broadcast delay Time cannot be less than 10 seconds, and the hls Protocol has a longer delay Time compared with the RTMP Protocol (Real Time Messaging Protocol) which has a minimum delay of about 3 to 4 seconds. hls, the delay is determined by the technical characteristics of the protocol, and the use of the protocol cannot avoid the delay or error of the live broadcast of 10 seconds.
hls the key of data transmission is index file, the actual file name is a file with suffix of ". m3u 8", and the file is requested when playing, but the fragmentation mechanism of hls divides the whole code stream into fragments, each fragment usually takes 10s, the client plays the code stream by downloading the fragment, so that the code stream needs to be recorded for 10s before forming a fragment, and then data transmission occurs, which leads to that the hls protocol has 10s delay, and if there is delay caused by network or other aspects, the delay is increased.
Disclosure of Invention
The embodiment of the invention aims to provide a video playing optimization method and system based on an hls protocol, the method saves the current time node as an end timestamp when playing is finished, and finds a corresponding playing time node for playing according to the saved end timestamp when a player is re-created, thereby avoiding the increase of playing delay and optimizing playing effect.
In order to achieve the above object, an embodiment of the present invention provides a video playing optimization method based on an hls protocol, which is executed at a client, and the method includes:
creating a player and inquiring whether an ending time stamp exists;
if the ending timestamp exists, the player searches a playing time node corresponding to the ending timestamp according to the ending timestamp to play;
the end timestamp is a timestamp recorded by the last-created player at the video playing end moment; and the playing time node corresponding to the ending timestamp is the playing time node which is obtained and recorded as the timestamp by the player established last time in the video playing process.
Optionally, the video playing ending time is a time when the client quits the video playing.
Optionally, the client sends an end message to the server at the moment when the player created last exits playing, where the end message includes a timestamp of the moment when the client exits playing;
the server acquires a time stamp of the playing quitting time of the client from the received ending message and stores the time stamp as the ending time stamp; and the server side sends the end time stamp to the server side when the player is established. The end timestamp is stored by the server, the end timestamp is sent to the client when the player is recreated by the server, and the client searches for the corresponding playing time node according to the end timestamp to play, so that the time delay increase caused by recreating the player when the player is played to the middle section of the fragment can be effectively avoided.
Optionally, the client stores a timestamp of a moment when the client exits from the video playing as the end timestamp. The end timestamp is stored by the client, when the player is created, if the end timestamp exists in the inquiry, the corresponding playing time node is found according to the end timestamp for playing, and the increase of time delay caused by re-creating the player when the player is played to the middle section of the fragment can be effectively avoided.
Optionally, the creating a player, querying whether there is an end timestamp, including:
if the end timestamp does not exist, the server only responds to the request of the client to create the player;
and the player requests the current fragment again and starts playing from the fragment head.
Optionally, the end timestamp stores only a preset time.
Optionally, in the video live broadcasting process, the preset time is 9-20 s; in the video-on-demand process, the preset time is customized according to the performance of the server. The preset time is set to be shorter, so that server resources can be saved, and the storage requirement of the action process of recreating the player from full screen quitting to small screen window playing on ending time stamp can be met.
The second aspect of the present invention provides a video playing optimization system based on hls protocol, the system includes:
the time stamp recording module is used for acquiring the playing time node record as a time stamp;
the end timestamp storage module is used for storing a timestamp of the moment when the client quits the video playing as the end timestamp;
and the player is used for inquiring whether the ending timestamp exists during the creation and searching the playing time node corresponding to the ending timestamp according to the ending timestamp for playing. The system is provided with an end timestamp storage module which is used for storing the current time node as an end timestamp when the playing is finished, and the player can find the corresponding playing time node for playing according to the stored end timestamp when the player is reestablished, so that the increase of playing delay is avoided, and the playing effect is optimized.
Optionally, the end time stamp storing module includes: the client end timestamp storage module and/or the server end timestamp storage module; the client end timestamp storage module is arranged at the client and used for storing a timestamp of the moment when the client quits the video playing as the end timestamp; the server end timestamp storage module is arranged at the server and used for acquiring a timestamp of the playing quitting time of the client from the received end message and storing the timestamp as the end timestamp. The end timestamp storage module can be arranged at the client side and the server side, and different user requirements are met.
The present invention also provides a machine-readable storage medium having stored thereon instructions for causing a machine to perform the hls protocol-based video playback optimization method described herein.
Through the technical scheme, the invention provides a video playing optimization method based on the hls protocol, which is characterized in that the method saves the current time node as the end timestamp when the playing is finished, and finds the corresponding playing time node for playing according to the saved end timestamp when the player is re-created, thereby avoiding the increase of playing delay and optimizing the playing effect.
On the other hand, the invention provides a video playing optimization system based on the hls protocol, the system is provided with an end timestamp storage module for storing the current time node as an end timestamp when playing is finished, and when a player is reestablished, the player can find the corresponding playing time node according to the stored end timestamp for playing, so that the increase of playing delay is avoided, and the playing effect is optimized.
Additional features and advantages of embodiments of the invention will be set forth in the detailed description which follows.
Drawings
The accompanying drawings, which are included to provide a further understanding of the embodiments of the invention and are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and together with the description serve to explain the embodiments of the invention without limiting the embodiments of the invention. In the drawings:
fig. 1 is a flowchart of a video playing optimization method based on the hls protocol according to an embodiment of the present invention;
fig. 2 is a flowchart of a video playing optimization method based on the hls protocol according to another embodiment of the present invention;
fig. 3 is a block diagram of a video playing optimization system based on the hls protocol according to the present invention.
Detailed Description
The following detailed description of embodiments of the invention refers to the accompanying drawings. It should be understood that the detailed description and specific examples, while indicating embodiments of the invention, are given by way of illustration and explanation only, not limitation.
In the actual live broadcasting of hls, except for 10s of delay in the start-up stage, in the subsequent use, if the network is not disconnected, the http connection is maintained, the network is smooth, and the transmission of the code stream itself is not problematic, and the delay is not increased theoretically, but there is a case that, if the client plays the current fragment (10 s is not played), the action of re-creating the player is performed within 10s (the actual scene is that the full screen exits to the small-screen window for playing), and the player will re-request the current fragment to play from 0s again, so that the delay is increased. For example, when the current segment is played for 5s, the same source is requested again, and the playing is started, the point of playing will be the picture before 5 s. For a total of 15 s.
Also in the on-demand process using hls, although there is no delay of the start-up phase 10s, since the server records the current download clip sequence in hls on-demand, if the playback is exited before the end of the playback in this clip 10s and then replayed, there is a problem of replaying the current clip. I.e. play to 5s, the replay is exited and the point of play will also be at 0s, not 5s of the slice.
This disadvantage is generally due to the fact that the client playing time node cannot be recorded, and there is a playing error within 10 s.
In order to solve the above problem, the present invention provides a video playing optimization method based on hls protocol, the method includes:
creating a player and inquiring whether an ending time stamp exists;
if the ending timestamp exists, the player searches a playing time node corresponding to the ending timestamp according to the ending timestamp to play;
the end timestamp is a timestamp recorded by the last-created player at the video playing end moment; and the playing time node corresponding to the ending timestamp is the playing time node which is obtained and recorded as the timestamp by the player established last time in the video playing process.
Example one
Fig. 1 is a flowchart of a video playing optimization method based on the hls protocol according to an embodiment of the present invention, and as shown in fig. 1, the video playing optimization method includes:
the player created last time acquires a playing time node in the video playing process and records the playing time node as a timestamp; the acquisition of the playing time node needs the cooperative implementation of the players, and the acquisition of the current playing time node is filled in the timestamp.
And the client quits the video playing, and a time stamp of the moment when the current client quits the video playing is saved as the ending time stamp.
The client reestablishes the player and inquires whether an ending time stamp exists;
if the ending timestamp exists, the player searches a playing time node corresponding to the ending timestamp according to the ending timestamp to play;
and if the ending timestamp does not exist, the player requests the current fragment again and starts playing from the fragment head. The end time stamp is stored by the client, when the player is reestablished, if the end time stamp exists in the inquiry, the corresponding playing time node is found according to the end time stamp for playing, and the time delay increase caused by reestablishing the player when the middle section of the fragment is played can be effectively avoided. That is to say, if the client quits from the full screen to the small video window for playing when playing the current segment, for example, playing to the current segment 5s, the client stores the timestamp of the current segment 5s as the end timestamp, when the client re-creates the player, the player re-requests the current segment and then queries whether the timestamp is stored, if so, re-requests the same segment source, finds the 5s of the current segment for playing, and the delay is still close to 10s and does not become 15 s.
In this embodiment, the end time stamp stores only a preset time.
In this embodiment, in the video live broadcast process, the preset time is 9-20 s; in the video-on-demand process, the preset time is customized according to the performance of the server. Preferably 10s, the preset time is set to 9-20s, so that server resources can be saved, and the storage requirement of the end timestamp in the action process of recreating the player from full-screen exit to small-screen window playing can be met. The end timestamp is only applied to the switching process of the full screen window and the small screen window, the switching process does not need to last for a long time, and therefore the storage time of the end timestamp is set to be 9-20s, on one hand, the storage space can be released quickly, on the other hand, if too long time is delayed in the switching process, for live broadcasting, the next fragment is played when the next fragment is played, and the live broadcasting progress can be met; for the on-demand, the live broadcast progress does not need to be attached, the delay of repeated playing is not critical, and the repetition of a short time can help a user to remember the previous plot.
When the player is reestablished, if the time interval between the last playing ending and the reestablishment of the player exceeds the preset time, the stored timestamp is automatically deleted, and server resources are saved for the system operation. At this time, the end timestamp does not exist in the client, and the player requests the current fragment again and starts playing from the fragment head.
Example two
Fig. 2 is a flowchart of a video playing optimization method based on the hls protocol according to another embodiment of the present invention, and as shown in fig. 2, the video playing optimization method includes:
the player created last time acquires a playing time node in the video playing process and records the playing time node as a timestamp; the acquisition of the playing time node needs the cooperative implementation of the players, and the acquisition of the current playing time node is filled in the timestamp.
The client quits the video playing, and an end message is sent to the server at the moment that the player established last quits the playing, wherein the end message comprises a timestamp of the moment that the client quits the playing;
the server acquires a time stamp of the playing quitting time of the client from the received ending message and stores the time stamp as the ending time stamp;
the client reestablishes the player;
the server side sends the end time stamp to the server side;
the client inquires whether an ending time stamp exists;
if the ending timestamp exists, the player searches a playing time node corresponding to the ending timestamp according to the ending timestamp to play;
and if the ending timestamp does not exist, the player requests the current fragment again and starts playing from the fragment head.
The end timestamp is stored by the server, the end timestamp is sent to the client when the player is recreated by the server, and the client searches for the corresponding playing time node according to the end timestamp to play, so that the time delay increase caused by recreating the player when the player is played to the middle section of the fragment can be effectively avoided.
That is to say, if the client plays the current segment, for example, plays the current segment at 5s, exits from a full screen to a small video window for playing, the client sends an end message to the server when exiting playing, the end message carries a timestamp 5s when ending playing, the server receives the end message, obtains the timestamp in the end message, and stores the timestamp as the end timestamp, when the client re-requests to create the player, the server sends the end timestamp to the client, and at the same time, correspondingly creates a player request, executes a player creating action, and when the player re-requests the current segment, it queries whether the timestamp is stored, and if so, re-requests the same segment source, finds the 5s of the current segment for playing, where the delay is still close to 10s, and does not become 15 s.
In this embodiment, the end time stamp stores only a preset time.
In this embodiment, in the video live broadcast process, the preset time is 9-20 s; in the video-on-demand process, the preset time is customized according to the performance of the server. Preferably 10 s. The preset time is set to 9-20s, so that server resources can be saved, and the storage requirement of the end timestamp in the action process of recreating the player from full-screen exit to small-screen window playing can be met. The end timestamp is only applied to the switching process of the full screen window and the small screen window, the switching process does not need to last for a long time, and therefore the storage time of the end timestamp is set to be 9-20s, on one hand, the storage space can be released quickly, on the other hand, if too long time is delayed in the switching process, for live broadcasting, the next fragment is played when the next fragment is played, and the live broadcasting progress can be met; for the on-demand, the live broadcast progress does not need to be attached, the delay of repeated playing is not critical, and the repetition of a short time can help a user to remember the previous plot.
When the player is reestablished, if the time interval between the last playing ending and the reestablishment of the player exceeds the preset time, the stored timestamp is automatically deleted, and server resources are saved for the system operation. At this time, the end timestamp does not exist in the server, the server only responds to the request of the client to create the player, and the player requests the current fragment again and starts playing from the fragment head.
To further optimize playback, the method further comprises:
and adjusting the buffer amount of the fragment cache according to the real-time memory change of the system. The amount of the replacement is adjusted according to the size of the memory, so that the normal operation of the system is not influenced.
In some embodiments, the adjusting the cache amount of the segment cache according to the real-time memory change of the system includes:
and adjusting the number of fragments cached in the fragments according to the size of the rest memory of the system. And for the system provided with the play memory, the replacing amount of the fragment cache is adjusted according to the size of the play memory.
In some embodiments, such as the haisi platform system, the memory information is obtained by a command method (cat/proc/media-mem; cat/proc/meminfo; dumpsys meminfo; top; ps), and the current remaining size of the memory is obtained by filtering the information, wherein the media-men is MMZ (media memory zone) information, which is the size of the main media playing memory, and if the remaining space is insufficient, the playing cannot be performed. The haisi platform divides the memory into two os (operating system) memories and MMZ memories, and when MMZ memory is initially set to be large, os memory is small and is fixed in size when the computer is started. As described above, the MMZ information is obtained, and if the other platforms do not distinguish the memories, the remaining memories of the system can be directly obtained.
In some embodiments, when the remaining memory is less than 10%, caching one fragment; when the residual memory is less than 30% and more than 10%, caching 3 fragments; and when the residual memory is more than 30%, caching 5 fragments. It should be noted that the cache partition has an upper limit to avoid affecting the space needed by users and other processes.
In some other embodiments, the adjusting the cache amount of the segment cache according to the change of the real-time memory of the system includes:
changing the size of the buffer area according to the size of the residual memory of the system, calculating the size of the fragments according to the frame number of the decoded code rate and the resolution, and dividing the size of the buffer area by the size of each fragment to obtain the number of the fragments to be cached (the size of the provided fragments in part of the m3u8 file). For a system with a buffer area, the size of the buffer area is changed according to memory change, and the number of the fragments capable of being cached is calculated.
The method can achieve the purpose of changing the fragment cache in real time, and has the advantages that when the memory is insufficient, the system can be ensured to operate normally without being jammed, can be played normally without being blocked, more data can be buffered when the memory is sufficient, so that the more complex network environment can be dealt with, the user experience is better, and when the user operates seek, the user does not need to buffer again for waiting.
A second aspect of the present invention provides a video playing optimization system based on the hls protocol, as shown in fig. 3, the system includes:
the time stamp recording module is used for acquiring the playing time node record as a time stamp;
the end timestamp storage module is used for storing a timestamp of the moment when the client quits the video playing as the end timestamp;
and the player is used for inquiring whether the ending timestamp exists during the creation and searching the playing time node corresponding to the ending timestamp according to the ending timestamp for playing. The system is provided with an end timestamp storage module which is used for storing the current time node as an end timestamp when the playing is finished, and the player can find the corresponding playing time node for playing according to the stored end timestamp when the player is reestablished, so that the increase of playing delay is avoided, and the playing effect is optimized.
Optionally, the end time stamp storing module includes: the client end timestamp storage module and/or the server end timestamp storage module; the client end timestamp storage module is arranged at the client and used for storing a timestamp of the moment when the client quits the video playing as the end timestamp, and the server end timestamp storage module is arranged at the server and used for acquiring the timestamp of the moment when the client quits the video playing from the received end message and storing the timestamp as the end timestamp. The end timestamp storage module can be arranged at the client side and the server side, and different user requirements are met.
Optionally, the system further includes: and the buffer memory amount adjusting module is used for adjusting the buffer memory amount of the fragment cache according to the real-time memory change of the system.
The present invention also provides a machine-readable storage medium having stored thereon instructions for causing a machine to perform the hls protocol-based video playback optimization method described herein.
Although the embodiments of the present invention have been described in detail with reference to the accompanying drawings, the embodiments of the present invention are not limited to the details of the above embodiments, and various simple modifications can be made to the technical solutions of the embodiments of the present invention within the technical idea of the embodiments of the present invention, and the simple modifications all belong to the protection scope of the embodiments of the present invention.
It should be noted that the various features described in the above embodiments may be combined in any suitable manner without departing from the scope of the invention. In order to avoid unnecessary repetition, the embodiments of the present invention do not describe every possible combination.
Those skilled in the art will understand that all or part of the steps in the method according to the above embodiments may be implemented by a program, which is stored in a storage medium and includes several instructions to enable a single chip, a chip, or a processor (processor) to execute all or part of the steps in the method according to the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes.
In addition, any combination of various different implementation manners of the embodiments of the present invention is also possible, and the embodiments of the present invention should be considered as disclosed in the embodiments of the present invention as long as the combination does not depart from the spirit of the embodiments of the present invention.
Claims (10)
1. A video playing optimization method based on hls protocol is characterized in that the method comprises:
creating a player and inquiring whether an ending time stamp exists;
if the ending timestamp exists, the player searches a playing time node corresponding to the ending timestamp according to the ending timestamp to play;
the end timestamp is a timestamp recorded by the last-created player at the video playing end moment; and the playing time node corresponding to the ending timestamp is the playing time node which is obtained and recorded as the timestamp by the player established last time in the video playing process.
2. The hls protocol-based video playback optimization method of claim 1, wherein the video playback end time is a time at which the client exits video playback.
3. The hls protocol-based video playback optimization method according to claim 2, wherein the client sends an end message to the server at the last-created playback exit time, the end message including a timestamp of the playback exit time of the client;
the server acquires a time stamp of the playing quitting time of the client from the received ending message and stores the time stamp as the ending time stamp; and the server side sends the end time stamp to the client side when the player is established.
4. The hls protocol-based video playback optimization method of claim 2, wherein the client stores a time stamp of the moment when the client exits video playback as the end time stamp.
5. The hls protocol-based video playback optimization method of claim 1, wherein the creating a player, querying whether there is an end timestamp, comprises:
if the end timestamp does not exist, the server only responds to the request of the client to create the player;
and the player requests the current fragment again and starts playing from the fragment head.
6. The hls protocol-based video playback optimization method of claim 1, wherein the end timestamp stores only a preset time.
7. The hls protocol-based video playback optimization method of claim 6, wherein the preset time is 9-20s during live video broadcast; in the video-on-demand process, the preset time is customized according to the performance of the server.
8. A video playback optimization system based on the hls protocol, the system comprising:
the time stamp recording module is used for acquiring the playing time node record as a time stamp;
the end timestamp storage module is used for storing a timestamp of the moment when the client quits the video playing as the end timestamp;
and the player is used for inquiring whether the ending timestamp exists during the creation and searching the playing time node corresponding to the ending timestamp according to the ending timestamp for playing.
9. The hls protocol-based video playback optimization system of claim 8, wherein the end timestamp storage module comprises:
the client end timestamp storage module and/or the server end timestamp storage module; the client end timestamp storage module is arranged at the client and used for storing a timestamp of the moment when the client quits the video playing as the end timestamp; the server end timestamp storage module is arranged at the server and used for acquiring a timestamp of the playing quitting time of the client from the received end message and storing the timestamp as the end timestamp.
10. A machine-readable storage medium having stored thereon instructions for causing a machine to perform the hls protocol-based video playback optimization method of any one of claims 1-7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110888274.9A CN113630657A (en) | 2021-08-03 | 2021-08-03 | Video playing optimization method and system based on hls protocol |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110888274.9A CN113630657A (en) | 2021-08-03 | 2021-08-03 | Video playing optimization method and system based on hls protocol |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113630657A true CN113630657A (en) | 2021-11-09 |
Family
ID=78382561
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110888274.9A Pending CN113630657A (en) | 2021-08-03 | 2021-08-03 | Video playing optimization method and system based on hls protocol |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113630657A (en) |
Citations (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20060019100A (en) * | 2004-08-26 | 2006-03-03 | 주식회사 케이티 | Surveillance system over internet protocol and its method using real time transfer |
| WO2014186638A2 (en) * | 2013-05-15 | 2014-11-20 | Aliphcom | Smart media device ecosystem using local and remote data sources |
| CN106993231A (en) * | 2017-04-01 | 2017-07-28 | 锐达互动科技股份有限公司 | Method and system that a kind of video clip is played |
| CN106998396A (en) * | 2017-03-30 | 2017-08-01 | 申瓯通信设备有限公司 | Phone key switch relaying turns relay function and realizes system and its method for realization |
| WO2018080722A1 (en) * | 2016-10-31 | 2018-05-03 | Google Inc. | Anchors for live streams |
| US20180261256A1 (en) * | 2016-05-25 | 2018-09-13 | Tencent Technology (Shenzhen) Company Limited | Video play method and device, and computer storage medium |
| US20190069047A1 (en) * | 2017-08-25 | 2019-02-28 | Volley Media, Llc | Methods and systems for sharing live stream media content |
| US10715871B1 (en) * | 2019-03-27 | 2020-07-14 | Verizon Patent And Licensing, Inc. | Determining an end screen time for displaying an end screen user interface |
| US20200267437A1 (en) * | 2019-02-19 | 2020-08-20 | Apple Inc. | Low latency streaming media |
| EP3726835A1 (en) * | 2003-01-28 | 2020-10-21 | OpenTV, Inc. | System and method for streaming media enhancement |
| CA3091449A1 (en) * | 2019-08-29 | 2021-02-28 | Comcast Cable Communications, Llc | Methods and systems for intelligent content controls |
-
2021
- 2021-08-03 CN CN202110888274.9A patent/CN113630657A/en active Pending
Patent Citations (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP3726835A1 (en) * | 2003-01-28 | 2020-10-21 | OpenTV, Inc. | System and method for streaming media enhancement |
| KR20060019100A (en) * | 2004-08-26 | 2006-03-03 | 주식회사 케이티 | Surveillance system over internet protocol and its method using real time transfer |
| WO2014186638A2 (en) * | 2013-05-15 | 2014-11-20 | Aliphcom | Smart media device ecosystem using local and remote data sources |
| US20180261256A1 (en) * | 2016-05-25 | 2018-09-13 | Tencent Technology (Shenzhen) Company Limited | Video play method and device, and computer storage medium |
| WO2018080722A1 (en) * | 2016-10-31 | 2018-05-03 | Google Inc. | Anchors for live streams |
| CN106998396A (en) * | 2017-03-30 | 2017-08-01 | 申瓯通信设备有限公司 | Phone key switch relaying turns relay function and realizes system and its method for realization |
| CN106993231A (en) * | 2017-04-01 | 2017-07-28 | 锐达互动科技股份有限公司 | Method and system that a kind of video clip is played |
| US20190069047A1 (en) * | 2017-08-25 | 2019-02-28 | Volley Media, Llc | Methods and systems for sharing live stream media content |
| US20200267437A1 (en) * | 2019-02-19 | 2020-08-20 | Apple Inc. | Low latency streaming media |
| US10715871B1 (en) * | 2019-03-27 | 2020-07-14 | Verizon Patent And Licensing, Inc. | Determining an end screen time for displaying an end screen user interface |
| CA3091449A1 (en) * | 2019-08-29 | 2021-02-28 | Comcast Cable Communications, Llc | Methods and systems for intelligent content controls |
Non-Patent Citations (1)
| Title |
|---|
| 许众威;钱小红;: "基于DirectShow实现多路视频播放控制", 盐城工学院学报(自然科学版), no. 03, 15 September 2008 (2008-09-15) * |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111135569B (en) | Cloud game processing method and device, storage medium and electronic equipment | |
| EP3520420B1 (en) | Viewer importance adaptive bit rate delivery | |
| US6792449B2 (en) | Startup methods and apparatuses for use in streaming content | |
| US11757965B2 (en) | Low latency streaming media | |
| KR100492567B1 (en) | Http-based video streaming apparatus and method for a mobile communication system | |
| CN107690073B (en) | Video live broadcast method and video live broadcast server | |
| CN110022482B (en) | Video playing starting method, video service system and storage medium | |
| CN110933517B (en) | Code rate switching method, client and computer readable storage medium | |
| US20100299443A1 (en) | Method, System and Device for Playing Streaming Media | |
| WO2011100901A2 (en) | Method, device and system for transmitting and processing media content | |
| JP2013021574A (en) | Generation device, distribution server, generation method, reproduction device, reproduction method, reproduction system, generation program, reproduction program, recording medium, and data structure | |
| EP3520421B1 (en) | Viewer importance adaptive bit rate delivery | |
| US20040010613A1 (en) | Storage and distribution of segmented media data | |
| WO2011054319A1 (en) | Method, device and system for realizing hierarchically requesting content in http streaming system | |
| EP3873101A1 (en) | Selective pre-caching of media streams | |
| CN112839238B (en) | Screen projection playing method and device and storage medium | |
| US11496536B2 (en) | Method of requesting video, computing device, and computer-program product | |
| JP7259056B2 (en) | METHOD, APPARATUS, SYSTEM AND DEVICE FOR MEDIA STREAM TRANSMISSION | |
| CN113630657A (en) | Video playing optimization method and system based on hls protocol | |
| CN109194678B (en) | Distributed streaming media service system based on redis message queue | |
| JP3860957B2 (en) | Multimedia data transmission device | |
| JP2002094560A (en) | Method for providing information | |
| CN113992956A (en) | Method for fast switching network audio and video | |
| CN112738616A (en) | Program sharing method based on set top box and related equipment | |
| KR20070024747A (en) | Network linkage model used switching system and method |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| TA01 | Transfer of patent application right |
Effective date of registration: 20231208 Address after: 516000, No. 5 Huitai Road, Huinan High tech Industrial Park, Hui'ao Avenue, Huizhou City, Guangdong Province Applicant after: Unionman Technology Co.,Ltd. Applicant after: Guangdong Jiulian Kaihong Technology Development Co.,Ltd. Address before: 516007 No.5, huitai Road, Huinan hi tech Industrial Park, huiao Avenue, Huizhou City, Guangdong Province Applicant before: Unionman Technology Co.,Ltd. |
|
| TA01 | Transfer of patent application right |