CN115442666A - IPTV video double-speed playing method and system - Google Patents
IPTV video double-speed playing method and system Download PDFInfo
- Publication number
- CN115442666A CN115442666A CN202211059259.4A CN202211059259A CN115442666A CN 115442666 A CN115442666 A CN 115442666A CN 202211059259 A CN202211059259 A CN 202211059259A CN 115442666 A CN115442666 A CN 115442666A
- Authority
- CN
- China
- Prior art keywords
- key frame
- video
- double
- speed
- playing
- 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 45
- 230000002457 bidirectional effect Effects 0.000 claims abstract description 43
- 230000008569 process Effects 0.000 claims abstract description 15
- 238000011144 upstream manufacturing Methods 0.000 claims description 13
- 238000002347 injection Methods 0.000 claims description 4
- 239000007924 injection Substances 0.000 claims description 4
- 230000008859 change Effects 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000002452 interceptive effect Effects 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000009432 framing Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 238000012552 review Methods 0.000 description 1
- 238000012360 testing method 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/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/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/433—Content storage operation, e.g. storage operation in response to a pause request, caching operations
- H04N21/4332—Content storage operation, e.g. storage operation in response to a pause request, caching operations by placing content in organized collections, e.g. local EPG data repository
-
- 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/433—Content storage operation, e.g. storage operation in response to a pause request, caching operations
- H04N21/4334—Recording operations
-
- 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
- H04N21/6437—Real-time Transport Protocol [RTP]
-
- 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/6587—Control parameters, e.g. trick play commands, viewpoint selection
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Databases & Information Systems (AREA)
- Human Computer Interaction (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
The invention relates to the technical field of multimedia, and provides an IPTV video double-speed playing method and system. According to the IPTV video speed-doubling playing method and system, speed-doubling files do not need to be generated and stored, only the index file corresponding to the video file needs to be generated and stored, the index file only contains video basic information and all key frame information of the video file, and does not contain video frame information, so that the storage space is saved; meanwhile, the index file is not limited by the speed playing direction and size, the speed playing of any speed in different directions can be supported, in the speed playing process, the stream server only needs to use the index file containing all key frame information and form a key frame bidirectional queue, so that the video data corresponding to the key frames are dynamically read and sent to the terminal according to the speed playing direction and size, the video pictures are rich, the display is smooth, the stream server does not need to analyze the video file in real time during playing, and the playing efficiency is improved.
Description
Technical Field
The invention relates to the technical field of multimedia, in particular to an IPTV video double-speed playing method and system.
Background
IPTV (interactive network television) is a technology that provides a plurality of interactive services including digital television to home users by using a broadband cable television network and integrating a plurality of technologies such as internet, multimedia, and communication, and the services provided by IPTV include, but are not limited to, a plurality of video services such as on-demand, live, review, and double-speed playing.
In the IPTV system at the present stage, in order to support fast-forward and fast-backward play of RTSP protocol, when injecting the on-demand content into a CDN central Server, it is often necessary to generate forward and reverse double-speed files with different double speeds, where a double-speed file is a video file including a closed-loop GOP obtained by framing an original video file, in an actual service, it is usually necessary to support fast-forward and fast-backward play at 2, 4, 8, 16, and 32 double speeds, that is, it is necessary to generate 10 double-speed files in two directions, however, since the double-speed file occupies a large storage space, the existing method is to store only the double-speed files with 2-3 double speeds, and when a terminal requests a streaming Server (Media Server, that is, a streaming Media Server) to play at an unsupported speed, the streaming Server returns the closest double-speed file to the terminal, which results in a situation of picture skipping during the double-speed play, and a user experience is not good.
Disclosure of Invention
The invention aims to provide an IPTV video double-speed playing method and system, and aims to solve the technical problems that a double-speed file occupying a large amount of storage space needs to be generated for realizing double-speed playing in the existing IPTV system, and the picture is easy to jump during double-speed playing.
The purpose of the invention is realized by the following technical scheme:
on one hand, the invention provides an IPTV video double-speed playing method, which comprises the following steps:
s1, generating an index file corresponding to the video file, wherein the index file comprises video basic information and all key frame information of the video file, and storing the index file in a same-level directory of the video file;
s2, after receiving an RTSP playing request sent by a terminal, a streaming server firstly reads an index file corresponding to a video file and loads all key frame information in the index file to an internal memory to form a key frame bidirectional queue; secondly, the streaming server searches the corresponding key frame along the key frame bidirectional queue according to the RTSP playing request, reads the video data corresponding to the key frame and sends the video data to the terminal.
In some possible embodiments, in step S1, the process of generating the index file corresponding to the video file includes:
s11, analyzing the video file to extract basic video information and all key frame information in the video file;
s12, creating an index file, wherein the index file comprises header information;
and S13, writing the header information of the index file, the video basic information in the video file and all the key frame information into the index file to generate the index file.
In some possible embodiments, in step S2, the RTSP play request received by the streaming server from the terminal includes an RTSP play request at a specified time point and a forward or reverse RTSP double-speed play request;
the streaming server sends no more than 4 key frames per second.
In some possible embodiments, the terminal specifies a time point for starting playing through the npt parameter, so as to send an RTSP playing request of the specified time point to the streaming server;
when the streaming server receives an RTSP playing request of a specified time point sent by a terminal, the streaming server reads an index file corresponding to a video file and loads all key frame information in the index file to a memory to form a key frame bidirectional queue;
secondly, the stream server searches a first key frame meeting the condition that delta pcr is larger than npt along the forward direction of the key frame bidirectional queue, and judges whether the key frame is a first frame or not, wherein the delta pcr represents a difference value between a current frame pcr and the first frame pcr of the key frame bidirectional queue; and if the key frame is the first frame, the streaming server sends video data to the terminal from the starting position of the video file, and if the key frame is not the first frame, the streaming server sends the video data to the terminal from the offset position of the video file where the previous key frame of the key frame in the key frame bidirectional queue is located.
In some possible embodiments, the terminal specifies the direction and the size of the double-speed playing through the scale parameter, so as to send a forward or reverse RTSP double-speed playing request to the streaming server;
when the streaming server receives a forward or reverse RTSP (real time streaming protocol) double-speed playing request sent by a terminal, the streaming server reads an index file corresponding to a video file and loads all key frame information in the index file to a memory to form a key frame bidirectional queue;
secondly, the streaming server searches the last key frame or the next key frame closest to the current playing position in the key frame bidirectional queue according to the current playing position, reads the video data corresponding to the key frame from the video file and sends the video data to the terminal;
and then, according to the speed playing direction and size in the forward or reverse RTSP speed playing request, the streaming server searches the next key frame meeting the speed playing size forward or reversely along the key frame bidirectional queue, reads the video data corresponding to the key frame from the corresponding position of the video file and sends the video data to the terminal, and the like until the speed playing is quitted.
In some possible embodiments, in the double-speed playing process, when the streaming server receives a new forward or reverse RTSP double-speed playing request sent by the terminal, according to the direction and size of the double-speed playing in the double-speed playing request, the streaming server searches the next key frame meeting the new double-speed playing size from the position of the key frame currently being sent along the forward or reverse direction of the key frame bidirectional queue, reads the video data corresponding to the key frame from the corresponding position of the video file, and sends the video data to the terminal, and so on until the double-speed playing exits.
In some possible embodiments, in the double-speed playing process, when the streaming server receives an RTSP base-speed playing request sent by the terminal, the streaming server sequentially reads the remaining video data from the position of the key frame currently being sent and sends the remaining video data to the terminal.
In some possible embodiments, when the streaming server receives a forward or reverse RTSP double-speed play request sent by the terminal, if the streaming server does not have video data locally, the streaming server needs to return to the source from the upstream CDN central server.
On the other hand, the invention provides an IPTV video double-speed playing system, which is used to implement the double-speed playing method, and the double-speed playing system includes:
the injection module is used for generating an index file corresponding to the video file when the video file is injected into the CDN central server and storing the index file into a peer directory of the video file in the CDN central server;
and the playing module is used for providing a double-speed playing service by the streaming server when the RTSP playing request is sent by the terminal, and the streaming server supports the double-speed playing method.
In some possible embodiments, the multiple speed playing system further comprises:
and the source returning module is used for returning the source from the upstream CDN central server in real time when the terminal sends an RTSP playing request and the streaming server has no video data.
The technical scheme of the embodiment of the invention at least has the following advantages and beneficial effects:
1. according to the IPTV video speed-doubling playing method and system, speed-doubling files do not need to be generated and stored, only the index file corresponding to the video file needs to be generated and stored, the index file only contains video basic information and all key frame information of the video file, and does not contain video frame information, so that the storage space is saved; meanwhile, the index file is not limited by the speed-doubling playing direction and size, the speed-doubling playing of any speed in different directions can be supported, in the speed-doubling playing process, the stream server only needs to read the video data corresponding to the key frames dynamically and send the video data to the terminal by means of the index file containing all key frame information and form a key frame bidirectional queue according to the speed-doubling playing direction and size, the video pictures are rich and displayed smoothly, the stream server does not need to analyze the video file in real time during playing, and the playing efficiency is improved.
2. According to the IPTV video double-speed playing method and system provided by the invention, for the playing request of the appointed time point sent by the terminal, the position of the key frame can be quickly positioned, and the corresponding video data is sent to the terminal from the position of the key frame, so that the terminal can load the video picture more quickly, and the user experience is improved.
Drawings
Fig. 1 is a flowchart of an IPTV video double-speed playing method according to an embodiment of the present invention;
FIG. 2 is a flowchart of generating an index file according to an embodiment of the present invention;
fig. 3 is a flowchart of playing at a specific time point according to an embodiment of the present invention;
fig. 4 is a schematic flowchart of an RTSP play request at a specific time point executed when a first key frame satisfying Δ pcr > npt is a non-first frame according to an embodiment of the present invention;
fig. 5 is a flowchart of forward or reverse RTSP double-speed playing according to an embodiment of the present invention;
fig. 6 is a schematic flowchart illustrating a process of executing a forward RTSP double-speed play request according to an embodiment of the present invention;
fig. 7 is a back-to-source interaction diagram of the streaming server when there is no video data according to the embodiment of the present invention;
fig. 8 is a block diagram of a double-speed playing system of an IPTV video according to an embodiment of the present invention.
Detailed Description
Referring to fig. 1 to 7, the present embodiment provides a method for playing an IPTV video at a double speed, which aims to solve the technical problems that a double-speed file occupying a large amount of storage space needs to be generated to implement double-speed playing in the existing IPTV system, and a screen is likely to jump during double-speed playing. Specifically, the double-speed playing method comprises the following steps:
s1, generating an index file corresponding to the video file, wherein the index file comprises video basic information and all key frame information of the video file, and storing the index file in a peer directory of the video file.
Referring to fig. 2, in step S1, the process of generating the index file corresponding to the video file includes:
s11, analyzing the video file to extract basic video information and all key frame information in the video file; the video basic information includes but is not limited to information such as the size of a video file, video duration, code rate, audio and video coding parameters and the like, the key frame information includes but is not limited to information such as a frame starting position, a frame size, pcr time and the like, and the frame starting position is an offset position of a frame relative to the video file;
s12, creating an index file, wherein the index file comprises header information, and the header information of the index file comprises but is not limited to information such as file identification, version number and reserved field, so as to facilitate expansion;
and S13, writing the header information of the index file, the video basic information in the video file and all the key frame information into the index file to generate the index file, and storing the index file in a peer directory of the video file.
It should be noted that the storage format of the index file may be, but is not limited to, a text file or a binary file.
S2, after receiving an RTSP playing request sent by a terminal, a streaming server firstly reads an index file corresponding to a video file and loads all key frame information in the index file to an internal memory to form a key frame bidirectional queue; secondly, the streaming server searches the corresponding key frame along the key frame bidirectional queue according to the RTSP playing request, reads the video data corresponding to the key frame and sends the video data to the terminal.
In step S2, the streaming server receives an RTSP play request sent by the terminal, where the RTSP play request includes an RTSP play request at a specified time point and a forward or reverse RTSP double-speed play request. The process of the streaming server executing the RTSP play request when the terminal sends different RTSP play requests will be further described below.
Referring to fig. 3, for an RTSP play request at a specified time point, the terminal specifies a time point for starting playing through an npt parameter, so as to send the RTSP play request at the specified time point to the streaming server;
when the streaming server receives an RTSP playing request of a specified time point sent by a terminal, the streaming server reads an index file corresponding to a video file and loads all key frame information in the index file to a memory to form a key frame bidirectional queue;
secondly, the stream server searches a first key frame meeting the condition that delta pcr is larger than npt along the forward direction of the key frame bidirectional queue, and judges whether the key frame is a first frame or not, wherein the delta pcr represents a difference value between a current frame pcr and the first frame pcr of the key frame bidirectional queue; if the key frame is the first frame, the streaming server sends video data to the terminal from the starting position of the video file until all the video data are sent or the playing is quitted; and if the key frame is not the first frame, the streaming server sends video data to the terminal from the offset position of the video file where the previous key frame of the key frame in the key frame bidirectional queue is located until all the video data are sent or the playing is quitted. For example, fig. 4 shows a flowchart of performing an RTSP play request at a specific time point when the first key frame satisfying Δ pcr > npt is a non-first frame.
Referring to fig. 5, for the forward or reverse RTSP play request, the terminal specifies the direction and size of the double-speed play through the scale parameter, so as to send the forward or reverse RTSP double-speed play request to the streaming server;
when the streaming server receives a forward or reverse RTSP speed-doubling playing request sent by a terminal, the streaming server reads an index file corresponding to a video file and loads all key frame information in the index file to a memory to form a key frame bidirectional queue;
secondly, the streaming server searches the last key frame or the next key frame closest to the current playing position in the key frame bidirectional queue according to the current playing position, reads the video data corresponding to the key frame from the video file and sends the video data to the terminal;
then, according to the speed playing direction and size in the forward or reverse RTSP speed playing request, the streaming server searches the next key frame meeting the speed playing size forward or reverse along the key frame bidirectional queue, reads the video data corresponding to the key frame from the corresponding position of the video file, and sends the video data to the terminal, and so on (i.e., the streaming server continues to search the next key frame meeting the speed playing size forward or reverse along the key frame bidirectional queue, reads the video data corresponding to the key frame from the corresponding position of the video file, and sends the video data to the terminal), until the speed playing exits.
It should be noted that the forward RTSP play request or the reverse RTSP play request refers to a fast forward play request or a fast reverse play request, where the forward RTSP play request corresponds to the fast forward play request, and the reverse RTSP play request corresponds to the fast reverse play request. When the terminal sends a forward RTSP playing request, the streaming server searches the last key frame closest to the current playing position in the key frame bidirectional queue according to the current playing position, and then the streaming server searches the key frame meeting the double-speed playing size in the forward direction along the key frame bidirectional queue; when the terminal sends a reverse RTSP playing request, the streaming server searches the next key frame closest to the current playing position in the key frame bidirectional queue according to the current playing position, and then the streaming server searches the key frame meeting the double-speed playing size reversely along the key frame bidirectional queue. For example, fig. 6 shows a flowchart when a forward RTSP double-speed play request is performed.
In addition, in the double-speed playing process, there may occur a case where the terminal sends a new forward or reverse RTSP double-speed playing request (for example, the terminal sends a request for changing the size of double-speed playing) and the terminal sends an RTSP base-speed playing request (i.e., scale =1, or PLAY request without scale parameter), and at this time, the streaming server has a different processing flow.
In the double-speed playing process, when the streaming server receives a new forward or reverse RTSP double-speed playing request sent by the terminal, according to the direction and the size of the double-speed playing in the double-speed playing request, the streaming server searches the next key frame meeting the new double-speed playing size from the position of the key frame currently sent along the forward or reverse direction of the key frame bidirectional queue, reads the video data corresponding to the key frame from the corresponding position of the video file and sends the video data to the terminal, and so on (namely, the streaming server continues to search the next key frame meeting the new double-speed playing size along the forward or reverse direction of the key frame bidirectional queue and reads the video data corresponding to the key frame from the corresponding position of the video file and sends the video data to the terminal) until the double-speed playing exits.
In the double-speed playing process, when the streaming server receives an RTSP basic speed playing request sent by the terminal, the streaming server sequentially reads the residual video data of the video file from the current key frame position being sent and sends the video file to the terminal so as to realize the playing of the video at the basic speed.
It should be noted that, during the forward multiple speed playing (i.e. fast forward), when the video file is fast forwarded to the end, the streaming server needs to notify the terminal and stop sending the video data to the terminal, and similarly, during the reverse multiple speed playing (i.e. fast backward), when the video file is fast backward to the header, the streaming server needs to notify the terminal and wait for the terminal to send a new playing request.
In addition, in practice, when the streaming server receives a forward or reverse RTSP double-speed play request sent by the terminal, the streaming server may not have corresponding video data, and at this time, the streaming server needs to return to the source to obtain the corresponding video data. Specifically, referring to fig. 7, if the streaming server does not have video data locally, the streaming server needs to return the source from the upstream CDN central server, first, the streaming server returns the source of the index file corresponding to the video file in the upstream CDN central server, after the index file is successfully obtained, load all the key frame information in the index file into the memory to form a key frame bidirectional queue, then, the streaming server finds the last key frame or the next key frame closest to the current playing position in the key frame bidirectional queue according to the current playing position, returns the video data corresponding to the key frame from the upstream CDN central server and sends the video data to the terminal, then, according to the direction and size of the double-speed playing in the forward or reverse RTSP double-speed playing request, the streaming server searches the next key frame meeting the double-speed playing size forward or reverse along the key frame bidirectional queue, returns the video data corresponding to the key frame from the upstream CDN central server, and sends the video data to the terminal, and so on the upstream CDN central server (that the streaming server continues to search the next key frame meeting the double-speed playing size forward or reverse direction) along the key frame bidirectional queue or reverse direction, and returns the video data from the upstream CDN central server to the upstream CDN central server.
Meanwhile, considering that an existing video file usually contains a key frame in 1-2 seconds, and too few or too many key frames will affect the user experience, wherein too few key frames will cause pictures to jump and be not rich enough, and too many key frames will cause pictures to change too fast and affect the decoding performance of a player, therefore, when a streaming server sends video data to a terminal, besides the need to jump frames according to the double speed, the sending speed of the key frames also needs to be reasonably controlled. Tests show that the number of key frames sent by the streaming server per second is controlled to be not more than 4, so that the optimal double-speed playing effect can be achieved, and compared with the conventional double-speed playing, the number of discarded key frames is less. Preferably, when the playback speed is less than 8 times, the streaming server does not skip frames and transmits all the key frames, and when the playback speed is greater than or equal to 8 times, the streaming server appropriately skips frames and transmits no more than 4 key frames per second on the premise that the playback speed is satisfied.
For example, in the existing double-speed playing method based on double-speed files, the number of frames extracted is independent of the key frame interval, and is usually: the 2 × speed file contains all key frames; extracting 1 frame from every 2 key frames of the 4-time speed file; extracting 1 frame from every 4 key frames of the 8-time speed file; extracting 1 frame from each 8 key frames of the 16-time speed file; the 32 x-speed file decimates every 16 key frames.
In the multiple speed playing method based on this embodiment, the frame number may change with the key frame interval, which specifically includes:
assuming 1 second and 1 key frame of an original video file, when 2 times speed playing is carried out, sending 2 key frames in 1 second and sending all the key frames; when 4-time speed playing is carried out, 4 key frames are sent in 1 second, and all the key frames are sent; when 8 times speed playing is carried out, 4 key frames are sent in 1 second, and 1 frame is sent every 2 frames; when 16 times speed playing is carried out, 4 key frames are sent in 1 second, and 1 frame is sent every 4 frames; when 32-time speed playing is carried out, 4 key frames are sent in 1 second, and 1 frame is sent every 8 frames;
assuming that an original video file has 2 seconds and 1 key frame, when 2 times speed playing is carried out, 1 key frame is sent in 1 second, and all key frames are sent; when 4 times speed playing is carried out, 2 key frames are sent for 1 second, and all the key frames are sent; when playing at 8 times speed, sending 4 key frames in 1 second and sending all the key frames; when 16 times speed playing is carried out, 4 key frames are sent in 1 second, and 1 frame is sent every 2 frames; at 32 times speed playback, 4 key frames are sent for 1 second, and 1 frame is sent every 4 frames.
On the other hand, referring to fig. 8, this embodiment provides an IPTV video double-speed playing system for implementing the double-speed playing method described above, where the double-speed playing system includes an injection module, a playing module, and a source returning module.
In this embodiment, the injection module is configured to generate an index file corresponding to the video file when the video file is injected into the CDN center server, and store the index file in a peer directory of the video file in the CDN center server for a subsequent streaming server to read.
In this embodiment, the playing module is configured to provide a double-speed playing service by a streaming server when the terminal sends an RTSP playing request, where the streaming server supports the double-speed playing method.
In this embodiment, the source returning module is configured to, when the terminal sends an RTSP play request and the streaming server has no video data, return an index file corresponding to the video file from the upstream CDN central server in real time, and return corresponding video data from the upstream CDN central server according to the index file to send the video data to the terminal.
In summary, the IPTV video double-speed playing method and system provided by this embodiment do not need to generate and store a double-speed file, but only need to generate and store an index file corresponding to a video file, where the index file only includes video basic information and all key frame information of the video file, and does not include video frame information, thereby saving storage space; meanwhile, the index file is not limited by the speed-doubling playing direction and size, the speed-doubling playing of any speed in different directions can be supported, in the speed-doubling playing process, the stream server only needs to read the video data corresponding to the key frames dynamically and send the video data to the terminal by means of the index file containing all key frame information and form a key frame bidirectional queue according to the speed-doubling playing direction and size, the video pictures are rich and displayed smoothly, the stream server does not need to analyze the video file in real time during playing, and the playing efficiency is improved.
The IPTV video double-speed playing and system provided by this embodiment can realize fast positioning of the position of the key frame for the playing request at the specified time point sent by the terminal, and send the corresponding video data from the key frame position to the terminal, so that the terminal can load the video picture faster, and the user experience is improved.
The above is only a preferred embodiment of the present invention, and is not intended to limit the present invention, and various modifications and changes will occur to those skilled in the art. Any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.
Claims (10)
1. An IPTV video double-speed playing method is characterized by comprising the following steps:
s1, generating an index file corresponding to the video file, wherein the index file comprises video basic information and all key frame information of the video file, and storing the index file in a peer directory of the video file;
s2, after receiving an RTSP playing request sent by a terminal, a streaming server firstly reads an index file corresponding to a video file and loads all key frame information in the index file to an internal memory to form a key frame bidirectional queue; secondly, the streaming server searches the corresponding key frame along the key frame bidirectional queue according to the RTSP playing request, reads the video data corresponding to the key frame and sends the video data to the terminal.
2. The IPTV video double-speed playing method of claim 1, wherein in step S1, the process of generating the index file corresponding to the video file comprises:
s11, analyzing the video file to extract basic video information and all key frame information in the video file;
s12, creating an index file, wherein the index file comprises header information;
and S13, writing the header information of the index file, the video basic information in the video file and all the key frame information into the index file to generate the index file.
3. The IPTV video double-speed playing method of claim 1, wherein in step S2, the RTSP playing request received by the streaming server from the terminal includes an RTSP playing request at a specific time point and a forward or reverse RTSP double-speed playing request;
the streaming server sends no more than 4 key frames per second.
4. The IPTV video double-speed playing method of claim 3, wherein the terminal specifies the time point for starting playing by the npt parameter, so as to send the RTSP playing request of the specified time point to the streaming server;
when the streaming server receives an RTSP playing request of a specified time point sent by a terminal, the streaming server reads an index file corresponding to a video file and loads all key frame information in the index file to a memory to form a key frame bidirectional queue;
secondly, the stream server searches a first key frame meeting the condition that delta pcr is larger than npt along the forward direction of the key frame bidirectional queue, and judges whether the key frame is a first frame or not, wherein the delta pcr represents a difference value between a current frame pcr and the first frame pcr of the key frame bidirectional queue; and if the key frame is the first frame, the streaming server sends video data to the terminal from the starting position of the video file, and if the key frame is not the first frame, the streaming server sends the video data to the terminal from the offset position of the video file where the previous key frame of the key frame is located in the key frame bidirectional queue.
5. The IPTV video double-speed playing method according to claim 3, wherein the terminal specifies the direction and size of the double-speed playing through scale parameters to realize sending a forward or reverse RTSP double-speed playing request to the streaming server;
when the streaming server receives a forward or reverse RTSP speed-doubling playing request sent by a terminal, the streaming server reads an index file corresponding to a video file and loads all key frame information in the index file to a memory to form a key frame bidirectional queue;
secondly, the streaming server searches the last key frame or the next key frame closest to the current playing position in the key frame bidirectional queue according to the current playing position, reads the video data corresponding to the key frame from the video file and sends the video data to the terminal;
then, according to the speed playing direction and size in the forward or reverse RTSP speed playing request, the streaming server searches the next key frame meeting the speed playing size forward or reversely along the key frame bidirectional queue, reads the video data corresponding to the key frame from the corresponding position of the video file and sends the video data to the terminal, and the like until the speed playing is quitted.
6. The IPTV video double-speed playing method of claim 5, wherein in the double-speed playing process, when the streaming server receives a new forward or reverse RTSP double-speed playing request sent by the terminal, according to the direction and size of the double-speed playing in the double-speed playing request, the streaming server searches the next key frame satisfying the new double-speed playing size from the current key frame position along the key frame bidirectional queue forward or reverse, and reads the video data corresponding to the key frame from the corresponding position of the video file and sends the video data to the terminal, and so on until exiting the double-speed playing.
7. The IPTV video double-speed playing method according to claim 5, wherein in the double-speed playing process, when the streaming server receives an RTSP basic speed playing request sent by the terminal, the streaming server sequentially reads the remaining video data from the key frame position currently being sent and sends the remaining video data to the terminal.
8. The IPTV video double-speed playing method according to claim 5, wherein when the streaming server receives a forward or reverse RTSP double-speed playing request sent by the terminal, if the streaming server has no video data locally, the streaming server is required to go back from the upstream CDN central server.
9. An IPTV video double-speed playing system for implementing the double-speed playing method of any one of claims 1-8, wherein the double-speed playing system comprises:
the injection module is used for generating an index file corresponding to the video file when the video file is injected into the CDN central server, and storing the index file into a peer directory of the video file in the CDN central server;
a playing module, for providing a double speed playing service by a streaming server when the terminal sends an RTSP playing request, the streaming server supporting the double speed playing method of any one of claims 1 to 8.
10. The IPTV video double-speed playing system of claim 9, wherein the double-speed playing system further comprises:
and the source returning module is used for returning the source from the upstream CDN central server in real time when the terminal sends an RTSP playing request and the streaming server has no video data.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211059259.4A CN115442666A (en) | 2022-08-31 | 2022-08-31 | IPTV video double-speed playing method and system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211059259.4A CN115442666A (en) | 2022-08-31 | 2022-08-31 | IPTV video double-speed playing method and system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN115442666A true CN115442666A (en) | 2022-12-06 |
Family
ID=84245269
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211059259.4A Pending CN115442666A (en) | 2022-08-31 | 2022-08-31 | IPTV video double-speed playing method and system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115442666A (en) |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2008095387A1 (en) * | 2007-02-08 | 2008-08-14 | Huawei Technologies Co., Ltd. | A method for fast forward and fast backward playing video data and stream media server |
| CN102780919A (en) * | 2012-08-24 | 2012-11-14 | 乐视网信息技术（北京）股份有限公司 | Method for carrying out video location and displaying through key frame |
| CN103369351A (en) * | 2012-03-29 | 2013-10-23 | 深圳市龙视传媒有限公司 | Streaming media fast-forward and fast-backward processing method, video server and system |
| CN105049881A (en) * | 2014-12-03 | 2015-11-11 | 武汉市烽视威科技有限公司 | Method and system for fast forward and fast backward play based on streaming media server |
-
2022
- 2022-08-31 CN CN202211059259.4A patent/CN115442666A/en active Pending
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2008095387A1 (en) * | 2007-02-08 | 2008-08-14 | Huawei Technologies Co., Ltd. | A method for fast forward and fast backward playing video data and stream media server |
| CN103369351A (en) * | 2012-03-29 | 2013-10-23 | 深圳市龙视传媒有限公司 | Streaming media fast-forward and fast-backward processing method, video server and system |
| CN102780919A (en) * | 2012-08-24 | 2012-11-14 | 乐视网信息技术（北京）股份有限公司 | Method for carrying out video location and displaying through key frame |
| CN105049881A (en) * | 2014-12-03 | 2015-11-11 | 武汉市烽视威科技有限公司 | Method and system for fast forward and fast backward play based on streaming media server |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR100492567B1 (en) | Http-based video streaming apparatus and method for a mobile communication system | |
| RU2622621C2 (en) | System and method for flow transfer of reproduced content | |
| CN103559165B (en) | Comprise the video distribution system of broadcasting continuously | |
| KR101737325B1 (en) | Method and apparatus for reducing decreasing of qualitly of experience in a multimedia system | |
| US20120246335A1 (en) | Method, terminal, and server for implementing fast playout | |
| JP4936751B2 (en) | Rapid media channel switching mechanism and access network node including the mechanism | |
| US10701417B2 (en) | Systems and methods for providing audio content during trick-play playback | |
| US20020161739A1 (en) | Multimedia contents providing system and a method thereof | |
| JPH07284042A (en) | Frame sampling system for video scanning in video on demand system | |
| KR20130133266A (en) | Systems and methods for adaptive bitrate streaming of media including subtitles | |
| CN105052160A (en) | Method and apparatus for streaming media content to client devices | |
| CN102487458A (en) | Method for broadcasting and processing TS (Transport Stream) document and device thereof | |
| CN112839238B (en) | Screen projection playing method and device and storage medium | |
| US8665963B2 (en) | Communication terminal, content reproduction method, content reproduction program, and content reproduction system for distributing and reproducing video contents with reduced stress | |
| WO2001082163A1 (en) | A multimedia contents providing system and a method thereof | |
| JP2003111048A (en) | Server and program for contents reproduction | |
| KR100770908B1 (en) | Apparatus and method for tricking playing of a digital broadcasting stream | |
| EP3902276A1 (en) | Video stream control | |
| JP2016072858A (en) | Media data generation method, media data reproduction method, media data generation device, media data reproduction device, computer readable recording medium and program | |
| KR101731829B1 (en) | Device and method for processing digital contents in digital video receiver | |
| CN115442666A (en) | IPTV video double-speed playing method and system | |
| KR100767307B1 (en) | Method for playing media player of mobile device and computer-readable medium for recoding the method | |
| KR100687416B1 (en) | Multimedia contents providing system and method using reproduction section information on the contents | |
| CN113132806B (en) | Playing terminal and program playing method thereof | |
| CN115623237B (en) | List live broadcast method, device, equipment and computer readable storage medium |
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 |