WO2010075743A1 - 一种网络电视显示时间的方法及设备 - Google Patents

一种网络电视显示时间的方法及设备 Download PDF

Info

Publication number
WO2010075743A1
WO2010075743A1 PCT/CN2009/075834 CN2009075834W WO2010075743A1 WO 2010075743 A1 WO2010075743 A1 WO 2010075743A1 CN 2009075834 W CN2009075834 W CN 2009075834W WO 2010075743 A1 WO2010075743 A1 WO 2010075743A1
Authority
WO
WIPO (PCT)
Prior art keywords
media stream
time information
time
playing
media
Prior art date
Application number
PCT/CN2009/075834
Other languages
English (en)
French (fr)
Inventor
欧雄兵
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2010075743A1 publication Critical patent/WO2010075743A1/zh

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/61Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast

Definitions

  • the present invention relates to the field of communication applications, and in particular, to a method and a device for displaying time on a network television. Background technique
  • IPTV Internet Protocol Television
  • IPTV Internet Protocol Television
  • set-top boxes and TVs as terminals
  • broadband IP as the transmission technology
  • audio-visual services as the mainstay, integrating instant messaging, games and information services. Value-added services.
  • IPTV has some different characteristics from ordinary broadcast TV, cable TV, and satellite TV.
  • all the program playing time is completely controlled by the TV station, and the user can only watch the designated program at a specified time, and the repeated viewing of the wonderful clips that have been missed cannot be realized;
  • IPTV IPTV
  • users can order the programs of interest at any time, and during the viewing process, they can pause and rewind through the Trick-mode mode. They can watch the pasted highlights repeatedly, so it is more convenient to provide personalized services. And interactive business, bringing users a new business experience.
  • the Trick-mode operation refers to fast forward, rewind, slow backward, slow forward, etc. during the user watching the program. Compared to traditional TV, Trick-mode operation provides users with flexible interactive control, resulting in a new business experience.
  • the Trick-mode operation includes two application scenarios:
  • the Trick-mode operation of the on-demand service that is, the user can pause, rewind, fast forward, slow backward, slow forward, etc. during the process of watching the on-demand program.
  • the Trick-mode operation of the live broadcast service that is, the user can operate the pause or the back button to enter the live Trick-mode state during the process of watching the live broadcast program to realize the live broadcast program.
  • the media server that records the live program in real time can provide services to the user according to the unicast mode based on the locally recorded program content, and the user can also pause, rewind, and Fast forward, slow back, slow forward, etc.
  • the user In the process of playing the program in the IPTV system, in order to provide a better service experience for the user, the user usually displays the progress of the current program, so that the user can know the current playing progress.
  • the user also needs to prompt the user for the current playback progress:
  • NPT Normal Play Time
  • the user needs to know the playback progress of the current playback position relative to the start position of the program, that is, NPT (Normal Play Time) Play time);
  • NPT Normal Play Time
  • the user needs to know the absolute time corresponding to the currently played program content, SPUTC
  • audio/video media data is encapsulated in an RTP (Real-time Transport Protocol) stream, and the RTP timestamp can be used to calculate the current actual playing time during normal playback, or according to the frame rate and already The number of frames played to calculate the current actual playback time.
  • the RTP time stamp corresponds to the time when the current frame is played back, and does not correspond to the actual playback time of the program.
  • the prior art generally uses a method of extracting a specific frame and sending it to a terminal to implement fast forward/rewind, etc., for example, only extracting I frames and transmitting them to the terminal for playing, or N times speed fast forwarding from N GPs.
  • the embodiments of the present invention provide a method and a device for displaying time of a network television, so that the terminal can accurately obtain the time information of the currently played program during the Trick-mode operation, thereby making The user can know exactly the current playback progress.
  • an embodiment of the present invention provides a method for displaying time of a network television, including:
  • the media server And receiving, by the media server, a media stream, where the media stream includes playing time information corresponding to the playing of the media stream, where the playing time information specifically includes time information corresponding to the image frame included in the media stream received after performing the trick mode operation. ;
  • a user terminal provided by the embodiment of the present invention includes:
  • a sending unit sending a skill mode operation request to the media server
  • a receiving unit configured to receive a media stream sent by the media server, where the media stream includes playing time information corresponding to playing the media stream, where the playing time information specifically includes an image frame included in the media stream received after performing the trick mode operation Corresponding time information;
  • An obtaining unit configured to acquire playing time information corresponding to the media stream received by the receiving unit
  • a display unit configured to display, when the media stream is played, a play time corresponding to the media stream acquired by the acquiring unit.
  • the embodiment of the invention further provides a method for transmitting time information on a network television, comprising: receiving a skill mode operation request sent by a user terminal;
  • the current media stream is sent to the user terminal.
  • a media server provided by the embodiment of the present invention includes:
  • a receiving unit configured to receive a skill mode operation request sent by the user terminal
  • An analyzing unit configured to analyze, according to the skill mode operation request received by the receiving unit, time information corresponding to an image frame included in the current media stream;
  • the adding unit is configured to add the time information analyzed by the analyzing unit to the current media stream
  • the sending unit is configured to send the current media stream in the adding unit to the user terminal.
  • the user When the user performs the trick mode operation, the user analyzes the time information corresponding to the image frame corresponding to the skill mode operation according to the received skill mode operation request; and adds the analyzed time information to the current media. And sending the current media stream to the user terminal, the user terminal receiving the media stream that is sent by the media server and containing the playing time information corresponding to the current media stream, acquiring the playing time information corresponding to the media stream, and playing The media stream displays the playing time corresponding to the media stream, so that the terminal can accurately obtain the time information of the currently played program, so that the user can accurately know the current playing progress of the program.
  • 1 is a system structural diagram of realizing network television display time in an embodiment of the present invention
  • FIG. 2 is a flow chart of a method for implementing a network television display time in an embodiment of the present invention
  • FIG. 3 is a flowchart of a method for implementing network television transmission time information in an embodiment of the present invention
  • FIG. 4 is a schematic mode operation scenario for implementing an on-demand service in an embodiment of the present invention
  • FIG. 5 is a schematic diagram of a trick mode operation scenario for realizing a live broadcast service according to an embodiment of the present invention. detailed description
  • the embodiment of the invention provides a method, device and system for displaying time of a network television, so that the user terminal can accurately know the time information of the currently played program when playing the media stream, so that the user can accurately know the current playing time.
  • the system for displaying time of the network television includes: a user terminal and a media server, where:
  • the terminal When the user performs the trick mode operation, the terminal sends a skill mode operation request to the media server; and receives the media stream sent by the media server, where the media stream includes playing time information corresponding to the playing of the media stream, and the playing time information is specific.
  • the time information corresponding to the image frame included in the media stream received after performing the trick mode operation; acquiring the play time information corresponding to the media stream, and displaying the play time corresponding to the media stream when playing the media stream;
  • a media server configured to receive a trick mode operation request sent by the user terminal; analyze, according to the trick mode operation request, time information corresponding to the image frame included in the current media stream; add the analyzed time information to the current media stream; The current media stream is sent to the user terminal.
  • the user terminal here is further configured to receive a media stream sent by the media server, where the media stream is a media stream sent after the media server switches to a normal playing state; according to the last real-time received in the trick mode operation.
  • the time information corresponding to the protocol packet is obtained, and the playing time information corresponding to the media stream is obtained, and the playing time corresponding to the media stream is displayed when the media stream is played.
  • the user terminal includes a sending unit 14, a receiving unit 15, an obtaining unit 16, and a display.
  • the unit 17 is configured to: send the skill mode operation request to the media server; the receiving unit 15 is configured to receive the media stream sent by the media server, where the media stream includes playing time information corresponding to playing the media stream, and the playing The time information specifically includes the time information corresponding to the image frame included in the media stream received after the trick mode operation is performed.
  • the obtaining unit 16 is configured to obtain the play time information corresponding to the media stream received by the receiving unit 15 , and the playing The time information includes the NPT and/or the UTC.
  • the display unit 17 is configured to display the play time corresponding to the media stream acquired by the obtaining unit 16 when the media stream is played. It should be noted that the play time information is encapsulated in a real-time transport protocol message, and the play time information is represented by a numerical mode or a character manner in a real-time transport protocol message.
  • the user terminal may further include a receiving processing unit, configured to receive a media stream sent by the media server, where the media stream is a media stream that is sent after the media server switches to a normal playing state; and receives according to the trick mode operation.
  • the time information corresponding to the last real-time transport protocol packet is obtained, the play time information corresponding to the media stream is obtained, and the play time corresponding to the media stream is displayed when the media stream is played.
  • the media server includes a receiving unit 10, an analyzing unit 11, an adding unit 12, and a sending unit 13, wherein: the receiving unit 10 is configured to receive a trick mode operation request sent by the user terminal, and the analyzing unit 11 is configured to receive according to the receiving unit 10.
  • the trick mode operation request analyzes the time information corresponding to the image frame included in the current media stream; the adding unit 12 is configured to add the play time information corresponding to the current media stream in the media stream; the sending unit 13 is configured to send the media stream to the User terminal.
  • the network television service request includes a service type selected by the user and/or a skill mode operation type, and the service type includes an on-demand service and a live broadcast service, and the skill mode operation type includes fast forward, fast reverse, and slow backward. Slow forward and so on.
  • the media server when the user performs the trick mode operation, analyzes the time information corresponding to the image frame corresponding to the skill mode operation according to the received skill mode operation request; and adds the analyzed time information to The current media stream is sent to the user terminal, and the user terminal receives the media stream that is sent by the media server and includes the playing time information corresponding to the current media stream, and obtains the playing time information corresponding to the media stream, and The playing time corresponding to the media stream is displayed when the media stream is played, so that the terminal can accurately obtain the time information of the currently played program, so that the user can accurately know the current playing progress of the program.
  • FIG. 2 is a flowchart of a method for implementing a network television display time in an embodiment of the present invention, and the specific steps include: Step S20: Send a skill mode operation request to the media server;
  • the user may select the media stream to be played by fast-forward, or rewind, or slow-back, or slow-forward in the trick mode.
  • Step S21 receiving a media stream sent by the media server
  • the media stream includes playing time information corresponding to when the media stream is played, and the playing time information is encapsulated in a real-time transport protocol message, including NPT and/or UTC.
  • the play time information includes, for example, time information corresponding to an image frame included in the media stream received after the trick mode operation.
  • Step S22 Obtain playing time information corresponding to the media stream.
  • Step S23 Display a play time corresponding to the media stream when playing the media stream.
  • the user can accurately know the current play position of the program.
  • the user terminal receives the media stream that is sent by the media server and includes the play time information corresponding to the current media stream, and obtains the play time information corresponding to the media stream, and When the media stream is played, the playing time corresponding to the media stream is displayed, so that the terminal can accurately obtain the time information of the currently played program, so that the user can accurately know the current playing progress of the program.
  • FIG. 3 is a flowchart of a method for implementing network television transmission time information in an embodiment of the present invention, and the specific steps include:
  • Step S30 Receive a trick mode operation request sent by the user terminal
  • Step S31 Analyze time information corresponding to the image frame included in the current media stream according to the trick mode operation request
  • Step S32 adding the analyzed time information to the current media stream
  • Step S33 Send the current media stream to the user terminal.
  • the trick mode operation types here include fast forward, fast reverse, slow backward, slow forward, and so on.
  • the user selects a play mode of the network television, and the play mode of the network television includes on-demand and live broadcast, and the media server receives the trick mode operation request sent by the user terminal, and adds the current media stream to the media stream.
  • the corresponding play time information is encapsulated in the real-time transport protocol message, including NPT and/or UTC.
  • the media server sends the media stream to the user terminal, and the user terminal receives the media stream, obtains the play time information corresponding to the media stream, and displays the play time corresponding to the media stream when the media stream is played.
  • the user When the user performs the trick mode operation, the user analyzes the time information corresponding to the image frame corresponding to the skill mode operation according to the received skill mode operation request; and adds the analyzed time information to the current media. And sending the current media stream to the user terminal, so that the terminal can accurately obtain the time information of the currently played program, so that the user can accurately know the current playing progress of the program.
  • Fig. 4 shows a Trick-mode operation scenario for implementing an on-demand service in an embodiment of the present invention.
  • This embodiment is a Trick-mode operation scenario of an on-demand service.
  • the media server has stored program content that can provide an on-demand service to the user, and the program listing information has been posted to an EPG (Electronic Program Guide) server.
  • EPG Electronic Program Guide
  • the media data of this embodiment is based on RTP transmission.
  • the specific steps include:
  • Step S401 The user terminal and the application server perform authentication, and if the authentication is passed, proceed to step S202;
  • the user terminal first interacts with the application server to perform necessary authentication to ensure the legitimate use of the service.
  • Step S402 The user terminal interacts with the EPG server to obtain the on-demand program list information.
  • the user terminal acquires the on-demand program list information, and presents the on-demand program list information to the user for the user to select.
  • Step S403 The user terminal queries the application server for the media server where the program content selected by the user is located;
  • Step S404 The user terminal establishes a connection with the selected media server and requests the media server to play the on-demand program content;
  • the user terminal negotiates the destination IP address and port number of the media stream in the process of establishing a connection with the selected media server.
  • the user terminal may not specify the initial playback progress when requesting playback, and the media server may start data transmission from the file header by default; or may specify the location where the file needs to transmit data, and the media server starts data transmission from the specified location.
  • the terminal uses RTP negotiation to start playback from the 1.125 second of the program as follows:
  • the media server After receiving the request message sent by the user terminal, the media server analyzes the media file, and locates the nearest 1.120 seconds of the media file to have an I frame, and responds to the following message, starting from 1.120 seconds. Play media stream:
  • Step S405 The media server processes the content of the program requested by the user to generate a media stream.
  • the media server processes the content of the program requested by the user according to the negotiated IP address and the port number, that is, the media content is in accordance with RTP/UDP.
  • /IP is encapsulated and sent to the terminal according to a certain timing.
  • the sequence number and time stamp of the initial RTP message are consistent with the parameters seq and rtptime in the header field RTP-Info.
  • Step S406 The user terminal receives the media stream sent by the media server.
  • the terminal After receiving the media stream sent by the media server, the terminal decodes the output, and the user can see the program content of the on-demand program.
  • the terminal calculates the actual playing time of the current media stream according to the received media stream by using the following two methods: 1.
  • the terminal associates the image frame corresponding to the first received packet with the normal playing time NPT of the program, that is, establishes an initial The correspondence between the time stamp and the starting NPT.
  • the current actual playing time can be calculated according to the difference between the time stamp of the currently decoded RTP packet and the initial time stamp; 2.
  • the terminal uses the image frame corresponding to the packet initially received as the initial image.
  • the number of frames that have been played can be calculated, according to the frame rate, the number of frames played, and the starting NPT. Calculate the current actual playback time.
  • Step S407 The user terminal initiates a skill mode operation request to the media server.
  • the trick mode operation types include fast forward, fast reverse, slow backward, or slow forward.
  • the user terminal sends a fast forward/rewind, slow backward/slow forward request message to the media server as an example. If the user terminal initiates 8 times fast forward, the request message is as follows:
  • the media server After receiving the 8x fast forward request message sent by the user terminal, the media server returns a response message to the user terminal as follows:
  • Step S408 The media server adds an NPT of the current media stream to the media stream.
  • the media server adds the NPT of the current media stream to the media stream when the media stream is sent, and the NPT is placed in the extended RTP packet header.
  • the format of the RTP packet when the NPT time information is transmitted by using the extended packet header of the RTP packet is as follows: Fixed RTP packet Extended RTP packet header RTP packet payload
  • the format of the fixed RTP header is as follows:
  • Version (V) The 2bit version number is set to 2.
  • P Used to indicate whether the end of the package is accompanied by non-load information.
  • Load Type (PT): Describe the data type such as audio or video, and explain the encoding side of the data.
  • Marker-M The flag is defined by the specific application framework.
  • the server starts with a random initialization value and increments by one for each RTP packet sequence number sent.
  • the client can rearrange the order of the packets based on the serial number and detect missing, corrupted, and duplicate packets.
  • the RTP timestamp provides sampling time for different media streams, which is used to re-establish the timing of the original audio or video. In addition, it can help the receiver determine the consistency or change in data arrival time (sometimes referred to as jitter).
  • SSRC Simultaneous Source Identification
  • CSRC Function Identification
  • Extension-X 1 bit. If the extension bit is set, it indicates that there is a variable-length extended RTP header behind the RTP packet.
  • the format of the field is as follows:
  • the extended RTP packet header is used to transmit the offset position of the image frame corresponding to the payload of the RTP packet in the entire media file, and the terminal can accurately output the NPT according to the information, and remind the user of the progress of the current program.
  • the extended RTP header consists of three parts:
  • the defined by profile field contains 16 bits, which can be regarded as the ID of the header extension field, which is used to indicate various types of header extension fields for different applications. There is no special definition in the RTP protocol, which can be defined by the user according to the application; the length field of 16 bits indicates the length of the header extension, the unit is 32_bit; the header extension is the real parameter information of the extension header, and the specific meaning of the parameter is defined by profile Domain to decide.
  • the extended RTP header can be exemplified as follows: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  • the definition of defined by prof ile is 1 means that the extended RTP header is transmitted with NPT time information, the header extension is NPT in milliseconds, the length is set to 1, indicating that the header extension is 32 bits wide, and the maximum length can be 1193 hours.
  • the program should be able to satisfy most applications. If it is not enough, consider using 64bit width. In this case, length should be 2.
  • the NPT is represented numerically. You can also consider the character to represent the NPT. The example is as follows:
  • the defined by profile is 2 to indicate that the extended RTP header is transmitted in character format NPT time information.
  • the header extension is a character-based NPT, and the length is set to 2, indicating that the header extension occupies two 32-bit widths.
  • the media server needs to analyze the time offset of each frame of the transmitted image relative to the start of the program, that is, NPT, and the NPT time corresponding to the frame image is as described above.
  • the mode is filled in the extension header of the RTP message used to transmit the frame image.
  • the method for specifically analyzing the NPT time corresponding to each frame of image may be scanning from the program media file to the current playing position, and calculating the NPT corresponding to the current image frame according to the frame rate and the number of image frames before the confirmed current playing position.
  • Time may pre-analyze the entire program when injecting the program content for the first time, determine the NPT time corresponding to each frame image and the position in the program media file, and save the pre-analysis information, so that during the playback process, The played image frame is directly confirmed according to the current play position, thereby determining the NPT time corresponding to the image frame. If it is fast forward, the NPT time is incremented. If it is fast rewind, the NPT time is decremented, and the RTP time stamp is gradually increasing. After the terminal receives the RTP packet The actual playback time of the image frame containing the RTP packet relative to the entire program is obtained from the NPT information in the RTP packet extension header.
  • Step S409 The user terminal receives the media stream that is sent by the media server and includes the current media stream NPT.
  • Step S410 The user terminal acquires the media stream NPT and displays the media stream NPT when playing the media stream;
  • the user terminal after receiving the media stream sent by the media server, the user terminal extracts the NPT of the media stream from the extended RTP packet header, and displays the media stream NPT when the media stream is played.
  • Step S411 The user terminal requests normal play from the media server.
  • Step S412 The user terminal receives the media stream generated by the streamed processing of the normally played program content sent by the media server;
  • the media stream received by the user terminal is an RTP packet sent by the media server in a normal manner after being switched to the normal play state.
  • the time stamp of the RTP packet is normally incremented according to the frame interval, and the extended RTP packet header may not be carried.
  • the user terminal can use the time stamp to calculate the actual playing time.
  • the user terminal calculates the actual playing time of the current media stream according to the received media stream, which can be implemented by the following two methods: 1.
  • the NTP time corresponding to the RTP packet of the information is used as the initial NPT, and the time stamp of the RTP packet is used as the initial time stamp.
  • the RTP packet sent by the media server in the normal play state without carrying the NTP time information After receiving the RTP packet sent by the media server in the normal play state without carrying the NTP time information, it is decoded according to the current time.
  • the difference between the time stamp of the RTP packet and the initial time stamp can calculate the current actual playing time; 2.
  • the image frame corresponding to the RTP packet of the information is used as the initial image frame, and the difference between the image frame corresponding to the currently decoded RTP packet carrying the NTP time information and the initial image frame can be calculated and played in the normal playing process.
  • the number of frames, according to the frame rate and the number of frames played and the starting NPT can also calculate the current actual playing time.
  • the last RTP packet received in the trick mode may be determined by whether the received RTP packet includes an extended RTP header, that is, the last RTP packet including the extended RTP header is received
  • Step S413 End playback, release resources.
  • the media server after playing to the end position of the file, notifies the terminal to end the play, deletes the session, and releases the resource.
  • FIG. 5 shows a Trick-mode operation scenario for implementing a live broadcast service in the embodiment of the present invention.
  • An embodiment of the present invention is a Trick-mode operation scenario of a live broadcast service, where media is set in this embodiment.
  • the data is based on RTP transmission, and the live program listing information has been posted to the EPG server.
  • the specific steps include:
  • Step S501 The media server records and stores the live program in real time, and records the UTC corresponding to the live image frame;
  • the media server records and stores the live program broadcasted from the head end in real time, and provides a program source for subsequent users to view, that is, the media server joins the multicast group of the multicast message sent from the head end during deployment, and receives And saving the program content of the live channel, and recording the image frame data while recording the UTC time corresponding to when the image frame is played from the head end.
  • Step S502 The access device receives a live program.
  • the live broadcast program is also directly pushed to the access device during the deployment of the program, that is, the access device also joins the multicast group to receive the multicast packet, and the actual common access is Equipment includes IP-DSLAM and GEP0N.
  • Step S503 the user terminal and the application server perform authentication, if the authentication is passed, proceed to step S304;
  • the user terminal After the user terminal is powered on, it interacts with the application server for authentication to ensure the legitimate use of the service.
  • Step S504 The user terminal obtains live channel list information from the EPG server.
  • the live channel list information includes a multicast IP address of the live program and codec parameter information for decoding the live program audio and video code stream.
  • Step S505 The user terminal requests to establish a connection with the media server.
  • the terminal when the user selects to watch a program of a certain channel, the terminal sends an IGMP Join message to the access device to join the multicast group corresponding to the channel specified by the user.
  • Step S506 The user terminal receives the media stream forwarded by the access device.
  • the access device forwards the multicast packet of the specified channel to the terminal, and the terminal decodes and outputs the received media packet, and the user can view the specified channel.
  • Step S507 The user terminal initiates a fast rewind to the application server, and queries a media server that provides a live rewind service;
  • the terminal stops receiving the multicast stream by sending an IGMP Leave message to the access device, and notifies the application server of the status change and the query to provide the live broadcast.
  • Trick-mode business media server application After the server queries, it returns a message containing the media server information of the live trick-mode service to the terminal.
  • Step S508 The user terminal establishes a connection with the media server that provides the trick-mode service, and instructs the media server to provide a fast-return service.
  • the message establishing the connection initiated by the user terminal carries the time information corresponding to the playing position of the current terminal, and the media server determines the current playing position of the terminal according to the time information.
  • the live trick-mode service requested by the user terminal is similar to the on-demand request initiated by the terminal at the specified location.
  • Header field Range parameter clock 20080916T123020. 120Z indicates that the media server plays the program starting from September 16, 2008 at 12:30:20:120.
  • the media server After receiving the message, the media server analyzes the media file, locates the I frame closest to the specified playback location in the media file, responds to the following message, and starts playing the media stream from there:
  • the header field here The parameter of Range 20080906T123020. 150Z- indicates that the media server corresponds
  • the serial number and time stamp of the first RTP packet is given by the media server corresponding to the location.
  • Step S509 The media server adds a UTC of the current media stream to the media stream;
  • the media server starts to play the media data of the locally saved corresponding live channel to the terminal according to the terminal requirement according to the terminal position.
  • the media server adds the UTC of the current media stream to the media stream, and the UTC is placed in the extended RTP header.
  • the format of the RTP message when the UTC time information is transmitted by using the extended RTP header is as follows: Fixed RTP message extended RTP header RTP payload
  • the extended RTP header is used to transmit the UTC time corresponding to the image frame corresponding to the RTP message payload being played back from the head end, and the terminal can accurately output the UTC time information according to the information, and remind the user to play the current program. schedule.
  • the extended RTP header can be exemplified as follows:
  • Header extension ⁇ 3 ⁇ 4 32 bits
  • the defined definition by prof ile is 3 for the extended RTP header to transmit UTC time information, and the header extension is the UTC time in milliseconds, which is relative to 00:00:00 on January 1, 1970.
  • the elapsed time, length is set to 2, indicating that the header extension is 64-bit wide.
  • the UTC time is numerically represented in the extended RTP header definition. You can also consider the character mode to represent the UTC time. The example is as follows: 20080906T123020.150Z
  • Header extension 'V '0, ⁇ 0, ⁇ 8,
  • Header extension 0, (terminator)
  • definition defined by prof ile 2 indicates that the extended RTP header is transmitted in character format UTC time information, header extension is UTC time expressed in characters, length is set to 6, indicating that the header extension occupies 6 32-bit width.
  • the media server needs to analyze the UTC time corresponding to each frame of the transmitted image, and fill the UTC time corresponding to the frame image into the extension header of the RTP message used to transmit the frame image in the manner described above.
  • the method for specifically analyzing the UTC time corresponding to each frame of image may be pre-analysis of the recorded content when recording the program, determining the UTC time corresponding to each frame image and the position in the program media file, and pre-analysing the information. Then, in the playing process, the played image frame can be directly confirmed according to the current playing position, thereby determining the UTC time corresponding to the image frame.
  • the UTC time is decremented, and the RTP timestamp is gradually increasing. If it is fast forward, the UTC time is incremented.
  • the terminal After receiving the RTP packet, the terminal obtains the UTC time corresponding to the currently played content according to the UTC information in the RTP packet extension header.
  • Step S510 The user terminal receives the media stream that is sent by the media server and includes the media stream UTC.
  • Step S511 the user terminal extracts the media stream UTC and displays the media stream UTC when displaying the media stream;
  • the user terminal after receiving the media stream sent by the media server, the user terminal extracts the UTC time information of the media stream from the extended RTP packet header, and displays the UTC corresponding to the media stream when the media stream is played.
  • Step S512 The user terminal requests normal play from the media server.
  • Step S513 The user terminal receives the normally played media stream sent by the media server.
  • the media stream received by the user terminal is an RTP message sent by the media server in a normal manner after the media server switches to the normal play state, and the RTP message is sent.
  • the time stamp is normally incremented according to the frame interval, and may not carry the extended RTP message header, and the user terminal may use the time stamp to determine the actual play time.
  • the user terminal calculates the actual playing time of the current media stream according to the received media stream by using the following two methods: 1.
  • the timestamp of the RTP packet is used as the initial timestamp, and after receiving the RTP packet sent by the media server in the normal playing state without carrying UTC time information, according to the timestamp and initial time of the currently decoded RTP packet.
  • the difference between the stamps can be used to calculate the playback time corresponding to the currently played content.
  • the user terminal uses the image frame corresponding to the last RTP packet containing the UTC time information received during the fast rewind as the initial image frame.
  • the number of frames that have been played can be calculated, according to The frame rate and the number of frames played and the starting UTC can also calculate the playback time corresponding to the currently played content.
  • the last RTP packet received in the trick mode may be determined by whether the received RTP packet includes an extended RTP header, that is, the last RTP packet including the extended RTP header is received in the trick mode. The last RTP package.
  • the media server can bring the NPT and/or UTC to the user terminal through the extended RTP packet header during normal playback or during the Trick-mode.
  • the media server adds the NPT/UTC information of the media stream to the media stream to be sent, so that the user terminal receives the NPT/ containing the media stream.
  • the user terminal directly extracts the NPT/UTC of the media stream and displays the NPT/UTC of the media stream when playing the media stream, thereby reducing the processing complexity of the user terminal and making the user accurate. Know the current playback position of the program.
  • the media server analyzes time information corresponding to the image frame corresponding to the skill mode operation, Adding a current media stream NPT/UTC to the media stream by using the media server, and transmitting the media stream containing the current media stream NPT/UTC to the user terminal, where the user terminal receives the current media stream sent by the media server
  • the media stream of the NPT/UTC extracts the media stream NPT/UTC, and displays the media stream NPT/UTC when the media stream is played, so that the user terminal can accurately obtain the playing time information of the currently played program. Thereby, the user can accurately know the current play position of the program.

Description

一种网络电视显示时间的方法及设备 本申请要求了 2008年 12月 31日递交的申请号为 200810220733. 0, 发明 名称为 "一种网络电视显示时间的方法及设备和系统" 的中国专利申请的优 先权, 其全部内容通过引用结合在本申请中。 技术领域
本发明涉及通信应用领域, 尤其涉及一种网络电视显示时间的方法及设 备。 背景技术
IPTV ( Internet Protocol Television , 网络电视) 业务是以机顶盒加电 视机为终端、 以宽带 IP作为传输技术、 以视听业务为主, 集即时通讯、 游戏、 信息服务为一体的为用户提供多媒体服务的宽带增值业务。
IPTV与普通的广播电视、 有线电视、 卫星电视存在一些不同的特点。 在传 统的电视系统中, 所有的节目播放时间完全由电视台控制, 用户只能在指定的 时间观看指定的节目, 对于已经放过的精彩片段无法实现重复观看; 而对于
IPTV , 用户可以随时点播感兴趣的节目, 并且在观看的过程中可以通过 Trick-mode (技巧模式) 操作暂停和后退, 可以对放过的精彩片段反复观看, 因此可以更方便地提供个性化业务和交互式业务, 给用户带来全新的业务体 验。
Trick-mode操作指在用户观看节目的过程中进行的快进, 快退, 慢退, 慢 进等操作。相对于传统电视, Trick-mode操作能给用户提供灵活的交互式控制, 从而带来全新的业务体验。
Trick-mode操作包括两种应用场景:
1、 点播业务的 Trick-mode操作, 即用户在观看点播节目的过程中可以暂 停、 快退、 快进、 慢退、 慢进等。
2、 直播业务的 Trick-mode操作, 即用户在观看直播节目的过程中可以操 作暂停或者后退键进入直播 Trick-mode状态实现直播节目的回看。 在直播 Trick-mode业务状态下,对直播节目进行实时录制的媒体服务器基于本地录制 保存的节目内容按照单播方式为用户提供服务, 这时用户也可以暂停、 快退、 快进、 慢退、 慢进等等。
在 IPTV系统播放节目的过程中, 为了给用户提供更好的业务体验, 通常都 给用户显示当前节目的播放进度, 从而让用户能知道当前的播放进度。 在
Trick-mode操作期间同样也需要提示用户当前的播放进度: 对于点播业务的 Trick-mode操作, 用户需要知道当前播放位置相对于节目起始位置的播放进 度, 即 NPT ( Normal Play Time , 相对节目起点的播放时间) ; 对于直播业务 的 Trick-mode操作,用户需要知道当前播放的节目内容对应的绝对时间, SPUTC
( Coordinated Universal Time , 世界标准时间) 。
现有技术中音 /视频媒体数据封装在 RTP ( Real-time Transport Protocol , 实时传送协议)流中传输, 在正常播放时可利用 RTP时戳来计算当前的实际播 放时间, 或者根据帧频和已经播放的帧数来计算当前的实际播放时间。 在快进 /快退、 慢退 /慢进时, RTP时戳对应当前帧被回放显示的时间, 和节目的实际 播放时间对应不上。现有技术通常使用抽取特定帧发送给终端的方式来实现快 进 /快退等, 例如只抽取 I帧发送给终端播放, 或者 N倍速快进时从 N个 G0P
( Group of Pictures , 连续的画面) 系列中抽取一个 G0P系列来播放。 由于 节目源本身 I帧间隔的不均匀和抽取的非线性, 以及图像帧大小的差异导致发 送时刻的随机变化, 使得终端在进行 Trick一 mode操作时, 终端无法获知当前 播放的节目内容对应的时间。 发明内容
鉴于上述现有技术所存在的问题, 本发明实施例提供了一种网络电视显示 时间的方法及设备, 使得终端在 Trick-mode操作时也能准确地获取当前播放 的节目的时间信息, 从而使得用户可以准确地知道当前播放进度。
为了解决上述技术问题, 本发明实施例提供了一种网络电视显示时间的方 法, 包括:
向媒体服务器发送技巧模式操作请求;
接收媒体服务器发送的媒体流, 该媒体流包括播放该媒体流时所对应的播 放时间信息, 该播放时间信息具体包括进行技巧模式操作后接收的该媒体流中 包含的图像帧所对应的时间信息;
获取该媒体流所对应的播放时间信息, 并在播放该媒体流时显示该媒体流 所对应的播放时间。 相应地, 本发明实施例提供的一种用户终端, 包括:
发送单元, 向媒体服务器发送技巧模式操作请求;
接收单元, 用于接收媒体服务器发送的媒体流, 该媒体流包括播放该媒体 流时所对应的播放时间信息, 该播放时间信息具体包括进行技巧模式操作后接 收的该媒体流中包含的图像帧所对应的时间信息;
获取单元, 用于获取该接收单元接收到的该媒体流所对应的播放时间信 息;
显示单元,用于在播放该媒体流时显示该获取单元获取到的该媒体流所对 应的播放时间。
本发明实施例还提供了一种网络电视传输时间信息的方法, 包括: 接收用户终端发送的技巧模式操作请求;
根据该技巧模式操作请求分析当前媒体流包含的图像帧所对应的时间信 息;
将该分析出的时间信息添加在该当前媒体流;
将该当前媒体流发送给用户终端。
相应的, 本发明实施例提供的一种媒体服务器, 包括:
接收单元, 用于接收用户终端发送的技巧模式操作请求;
分析单元,用于根据该接收单元接收的该技巧模式操作请求分析当前媒体 流包含的图像帧所对应的时间信息;
添加单元, 用于将该分析单元分析出的时间信息添加在当前媒体流; 发送单元, 用于将该添加单元中的当前媒体流发送给用户终端。
实施本发明实施例, 在用户进行技巧模式操作时, 根据接收的技巧模式操 作请求分析该进行技巧模式操作后所对应的图像帧所对应的时间信息; 将该分 析出的时间信息添加在当前媒体流; 并将该当前媒体流发送给用户终端, 用户 终端接收媒体服务器发来的包含有当前媒体流所对应的播放时间信息的媒体 流, 获取该媒体流所对应的播放时间信息, 并在播放该媒体流时显示出该媒体 流所对应的播放时间, 使得终端能准确地获取当前播放的节目的时间信息, 从 而使得用户可以准确地知道节目的当前播放进度。 附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案, 下面将对实施 例或现有技术描述中所需要使用的附图作简单地介绍, 显而易见地, 下面描述 中的附图仅仅是本发明的一些实施例, 对于本领域普通技术人员来讲, 在不付 出创造性劳动性的前提下, 还可以根据这些附图进行组合或改进, 得到其它的 实现方式。
图 1是本发明实施例中实现网络电视显示时间的系统结构图;
图 2是本发明实施例中实现网络电视显示时间的方法流程图;
图 3是本发明实施例中实现网络电视传输时间信息的方法流程图; 图 4是本发明实施例中实现点播业务的技巧模式操作场景;
图 5是本发明实施例中实现直播业务的技巧模式操作场景。 具体实施方式
本发明实施例提供了一种网络电视显示时间的方法及设备和系统, 使得用 户终端在播放媒体流时能准确地获知当前播放的节目的时间信息, 从而使得用 户可以准确地知道当前播放时间。
下面结合附图详细说明本发明的优选实施例。
图 1是本发明实施例中实现网络电视显示时间的系统结构图, 该网络电视 显示时间的系统包括: 用户终端和媒体服务器, 其中:
用于终端在用户进行技巧模式操作时, 向媒体服务器发送技巧模式操作请 求; 并接收媒体服务器发送的媒体流, 该媒体流包括播放该媒体流时所对应的 播放时间信息, 该播放时间信息具体包括进行技巧模式操作后接收的该媒体流 中包含的图像帧所对应的时间信息; 获取该媒体流所对应的播放时间信息, 并 在播放该媒体流时显示该媒体流所对应的播放时间;
媒体服务器, 用于接收用户终端发送的技巧模式操作请求; 根据该技巧模 式操作请求分析当前媒体流包含的图像帧所对应的时间信息; 将该分析出的时 间信息添加在该当前媒体流; 将该当前媒体流发送给用户终端。
还需要说明的是, 这里的用户终端还用于接收媒体服务器发送的媒体流, 该媒体流为媒体服务器切换到正常播放状态后发送的媒体流; 根据在技巧模式 操作中接收到的最后一个实时传送协议报文包所对应的时间信息, 获得该媒体 流所对应的播放时间信息, 并在播放该媒体流时显示该媒体流所对应的播放时 间。
具体的, 该用户终端包括发送单元 14、 接收单元 15、 获取单元 16和显示 单元 17, 其中: 发送单元 14用于向媒体服务器发送技巧模式操作请求; 接收 单元 15用于接收媒体服务器发送的媒体流, 该媒体流包括播放该媒体流时所 对应的播放时间信息, 该播放时间信息具体包括进行技巧模式操作后接收的该 媒体流中包含的图像帧所对应的时间信息; 获取单元 16用于获取该接收单元 15接收到的该媒体流所对应的播放时间信息, 该播放时间信息包括 NPT和 /或 UTC; 显示单元 17用于在播放该媒体流时显示该获取单元 16获取到的该媒体 流所对应的播放时间。 需要说明的是, 这里的播放时间信息封装在实时传送协 议报文中, 该播放时间信息通过实时传送协议报文中的数值方式或者字符方式 进行表示。
需要说明的是, 该用户终端还可以包括一接收处理单元, 用于接收媒体服 务器发送的媒体流, 该媒体流为媒体服务器切换到正常播放状态后发送的媒体 流; 根据在技巧模式操作中接收到的最后一个实时传送协议报文包所对应的时 间信息, 获得该媒体流所对应的播放时间信息, 并在播放该媒体流时显示该媒 体流所对应的播放时间。
该媒体服务器包括接收单元 10、分析单元 11、添加单元 12和发送单元 13, 其中: 接收单元 10, 用于接收用户终端发送的技巧模式操作请求; 分析单元 11, 用于根据该接收单元 10接收的技巧模式操作请求分析当前媒体流包含的 图像帧所对应的时间信息; 添加单元 12用于在媒体流中添加当前媒体流所对 应的播放时间信息; 发送单元 13用于将该媒体流发送给用户终端。 需要说明 的是, 这里的网络电视业务请求包括用户选择的业务类型和 /或技巧模式操作 类型, 该业务类型包括点播业务和直播业务, 该技巧模式操作类型包括快进, 快退, 慢退, 慢进等等。
实施本发明实施例, 在用户进行技巧模式操作时, 媒体服务器根据接收的 技巧模式操作请求分析该进行技巧模式操作后所对应的图像帧所对应的时间 信息; 将该分析出的时间信息添加在当前媒体流; 并将该当前媒体流发送给用 户终端, 用户终端接收媒体服务器发来的包含有当前媒体流所对应的播放时间 信息的媒体流, 获取该媒体流所对应的播放时间信息, 并在播放该媒体流时显 示出该媒体流所对应的播放时间, 使得终端能准确地获取当前播放的节目的时 间信息, 从而使得用户可以准确地知道节目的当前播放进度。
相应的, 图 2是本发明实施例中实现网络电视显示时间的方法流程图, 具 体歩骤包括: 歩骤 S20: 向媒体服务器发送技巧模式操作请求;
用户在进行点播或者直播业务过程中, 可能通过技巧模式中的快进, 或者 快退, 或慢退, 或慢进来选择所需要播放的媒体流。
歩骤 S21 : 接收媒体服务器发送的媒体流;
此处, 该媒体流包含有在播放该媒体流时所对应的播放时间信息, 该播放 时间信息封装在实时传送协议报文中,包括 NPT和 /或 UTC。该播放时间信息具 体包括进行技巧模式操作后接收的该媒体流中包含的图像帧所对应的时间信 息。
歩骤 S22 : 获取所述媒体流所对应的播放时间信息;
歩骤 S23 : 在播放所述媒体流时显示出所述媒体流所对应的播放时间。 此处, 通过在播放该媒体流时显示出该媒体流所对应的播放时间, 用户可 以准确地知道节目的当前播放位置。
实施本发明实施例, 在用户进行技巧模式操作后, 用户终端接收媒体服务 器发来的包含有当前媒体流所对应的播放时间信息的媒体流, 获取该媒体流所 对应的播放时间信息, 并在播放该媒体流时显示出该媒体流所对应的播放时 间, 使得终端能准确地获取当前播放的节目的时间信息, 从而使得用户可以准 确地知道节目的当前播放进度。
相应的, 图 3示出了本发明实施例中实现网络电视传输时间信息的方法流 程图, 具体歩骤包括:
歩骤 S30: 接收用户终端发送的技巧模式操作请求;
歩骤 S31 : 根据技巧模式操作请求分析当前媒体流包含的图像帧所对应的 时间信息;
歩骤 S32 : 将所述分析出的时间信息添加在当前媒体流;
歩骤 S33 : 将当前媒体流发送给用户终端。
需要说明的是, 这里的技巧模式操作类型包括快进、 快退、 慢退、 慢进等 等。 具体实施时, 当用户终端开机后, 用户选择网络电视的播放模式, 该网络 电视的播放模式包括点播、 直播, 媒体服务器接收用户终端发送的技巧模式操 作请求, 在媒体流中添加当前媒体流所对应的播放时间信息, 该播放时间信息 封装在实时传送协议报文中,包括 NPT和 /或 UTC。媒体服务器将该媒体流发送 给用户终端, 该用户终端接收该媒体流, 获取该媒体流所对应的播放时间信息 并在播放该媒体流时显示出该媒体流所对应的播放时间。 实施本发明实施例, 在用户进行技巧模式操作时, 根据接收的技巧模式操 作请求分析该进行技巧模式操作后所对应的图像帧所对应的时间信息; 将该分 析出的时间信息添加在当前媒体流; 并将该当前媒体流发送给用户终端, 使得 终端能准确地获取当前播放的节目的时间信息, 从而使得用户可以准确地知道 节目的当前播放进度。
相应的, 图 4示出了本发明实施例中实现点播业务的 Trick-mode操作场 景。 本实施例是点播业务的 Trick-mode操作场景, 媒体服务器上已经存储了 可以对用户提供点播服务的节目内容, 并且节目列表信息已经发布到 EPG ( Electronic Program Guide , 电子节目菜单) 服务器上, 在该实施例媒体数 据是基于 RTP传输。 在该实施过程中, 具体歩骤包括:
歩骤 S401 : 用户终端与应用服务器进行鉴权, 如果鉴权通过, 进行歩骤 S202 ;
此处, 用户终端在开机后首先与应用服务器交互进行必要的鉴权, 确保业 务的合法使用。
歩骤 S402 : 用户终端与 EPG服务器交互获得点播节目列表信息; 此处, 用户终端获取点播节目列表信息, 将该点播节目列表信息展现给用 户供用户选择。
歩骤 S403 :用户终端向应用服务器查询用户所选择的节目内容所在的媒体 服务器;
歩骤 S404:用户终端与选定的媒体服务器建立连接并请求该媒体服务器播 放点播的节目内容;
此处,用户终端在与选定的媒体服务器建立连接的过程中协商发送媒体流 的目的 IP地址和端口号。 用户终端在请求播放时可以不指定起始播放进度, 媒体服务器默认从文件头开始进行数据传输; 或者也可以指定文件所需进行传 输数据的位置, 媒体服务器从指定位置开始进行数据传输。 例如用户指定从节 目的第 1. 125秒开始播放时, 终端使用 RTP协商从节目的第 1. 125秒开始播放 的示例如下:
C -> S: PLAY rtsp : //example. com/mediastream RTSP/1. 0
CSeq: 2
Session : 123456
Range: npt=l. 125- 媒体服务器接收到用户终端发来的请求消息后对媒体文件进行分析, 定位 出媒体文件中离 1. 125秒最近的 1. 120秒有 I帧,则回应如下消息,并从 1. 120 秒开始播放媒体流:
S -〉 C : RTSP/1. 0 200 0K
CSeq: 2
Session : 123456
Range: npt=l. 120-
RTP-Info : url=rtsp: / / example, com/mediastream; seq=1000; rtptime=5000 上述消息中, 头域 Range的参数 npt=l. 120-表明媒体服务器从媒体文件的 1. 120秒处开始播放媒体数据, 头域 RTP-Info的参数 seq=1000和 rtptime=5000 给出了媒体服务器发送的与该位置对应的第一个 RTP包的序列号和时戳。
歩骤 S405 : 媒体服务器对用户请求播放的节目内容进行处理生成媒体流; 此处, 媒体服务器按照协商的 IP地址和端口号, 对用户点播的节目内容 进行处理, 即对媒体内容按照 RTP/UDP/IP封装后按照一定的时序发送给终端, 起始 RTP报文的序列号和时戳与头域 RTP-Info中的参数 seq和 rtptime值一 致。
歩骤 S406: 用户终端接收媒体服务器发来的媒体流;
此处, 终端接收到媒体服务器发来的媒体流后解码输出, 用户就可以看到 点播的节目内容。终端根据接收到的媒体流计算当前媒体流的实际播放时间可 通过以下两种方法实现: 1、 终端将最开始收到的包对应的图像帧与节目的正 常播放时间 NPT对应起来, 即建立初始时戳和起始 NPT之间的对应关系。 在播 放过程中, 根据当前被解码的 RTP包的时戳和初始时戳之间的差值就可以计算 当前的实际播放时间; 2、 终端将最开始收到的包对应的图像帧作为初始图像 帧,在播放过程中根据当前被解码的 RTP包所对应的图像帧和初始图像帧之间 的差值就可以计算已经播放的帧数, 根据帧频和播放的帧数以及起始 NPT也可 以计算当前的实际播放时间。
歩骤 S407: 用户终端向媒体服务器发起技巧模式操作请求;
此处, 该技巧模式操作类型包括快进、 快退、 慢退、 或慢进等等。 以本实 施例中用户终端向媒体服务器发送快进 /快退、慢退 /慢进请求消息为例进行说 明, 如用户终端发起 8倍快进时, 请求消息如下:
C -> S: PLAY rtsp : //example. com/mediastream RTSP/1. 0 CSeq: 3
Session: 123456
Scale: 8
媒体服务器收到用户终端发来的 8倍快进的请求消息后, 向用户终端返回 应答消息如下:
S -〉 C: RTSP/1.0 200 0K
CSeq: 3
Session: 123456
Scale: 8
歩骤 S408: 媒体服务器在媒体流中添加当前媒体流的 NPT;
此处, 根据用户发起的点播业务的 Trick-mode, 媒体服务器在发送媒体流 时在该媒体流中添加当前媒体流的 NPT, 该 NPT放在扩展的 RTP报文头中。 利用 RTP报文的扩展报文头来传输 NPT时间信息时的 RTP报文格式如下: 固定 RTP报文 扩展 RTP报文头 RTP报文净荷
其中固定 RTP报文头的格式如下:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
V=21 P I X CC I M PT I sequence number
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
timestamp
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
synchronization source (SSRC) identifier
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
contributing source (CSRC) identifiers
+-+ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 固定 RTP报文头的各个字段的含义如下:
版本 (V): 2bit版本号置 2。
填充 (P): 用以说明包尾是否附有非负荷信息。
负载类型 (PT): 对音频或视频等数据类型予以说明, 并说明数据的编码方 标志位 (Marker-M): 标志位由具体的应用框架定义。
序列号(Sequence Number): 为了安全, 服务器从一个随机初始化值开始, 每发送一个 RTP数据包序列号增加 1。客户端可根据序列号重新排列数据包的顺 序, 并对丢失、 损坏和重复的数据包进行检测。
时间戳 (Timestamp): RTP时间戳为同歩不同的媒体流提供采样时间, 用于 重新建立原始音频或视频的时序。 另外, 它还可以帮助接收方确定数据到达时 间的一致性或变化 (有时被称为抖动)。
同歩源标识 (SSRC): 帮助接收方利用发送方生成的唯一的数值来区分多个 同时的数据流。 SSRC必须是一个严格的随机数。
作用标识 (CSRC): 网络中使用混合器时, 混合器会在 RTP报文头部之后插 入新的同歩源标识, 其作用是区分多个同时的数据流。 对于每个 RTP包都包含 前面的 12个字节, 对于 CSRC, 当使用混合器的时候才会出现。
扩展位(Extension-X): 1 bit, 如果扩展位被置位, 则表明在 RTP报文的 头后面有一个长度可变的扩展 RTP报文头, 该域的格式如下:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
defined by profile | length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I header extension
扩展 RTP报文头用来传输与 RTP报文净荷对应的图像帧在整个媒体文件中 的偏移位置, 终端根据该信息就可以准确地输出 NPT, 提醒用户当前节目的播 放进度。 扩展 RTP报文头由三个部分组成: 其中 defined by profile 域包含 16个 bit,可以看成是头扩展域的 ID,用于标示用于不同应用的各种不同类型 的头扩展域, 该域在 RTP协议中没有特殊定义, 可以由用户根据应用来自行定 义; 16bit的 length域指示了 header extension的长度,单位是 32_bit; header extension是扩展头的真正参数信息, 参数的具体含义由 defined by profile 域来决定。
扩展 RTP报文头可以示例定义如下: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
defined by profile = 1 | length = 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header extension = 600000 (10分钟)
这里定义 defined by prof ile为 1表示扩展 RTP报文头传输的是 NPT时间信 息, header extension是以毫秒为单位的 NPT, length设为 1, 表示 header extension为 32bit宽度, 最多可以表示时长为 1193小时的节目, 应该可以满足 绝大部分应用, 如果不够可以考虑用 64bit宽度, 这时 length应该为 2。
上面的扩展 RTP报文头定义中是按照数值方式表示 NPT, 也可以考虑用字符 方式来表示 NPT, 示例如下:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
defined by profile = 2 | length = 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header extension = ' ' . ' Ό' (10分钟)
header extension = '\0, (结束符)
这里定义 defined by profile为 2表示扩展 RTP报文头传输的是字符格 式的 NPT时间信息, header extension是以字符方式表示的 NPT, length设 为 2, 表示 header extension占用了 2个 32bit宽度。
在快进 /快退、 慢退 /慢进期间, 媒体服务器需要分析发送出去的每帧图像 相对于节目起点的时间偏移, 即 NPT, 并将该帧图像所对应的 NPT时间按照上 面描述的方式填充到用来传输该帧图像的 RTP报文的扩展头中。具体分析每帧 图像所对应的 NPT 时间的方法可以是从节目媒体文件开始扫描到当前播放位 置, 根据帧频和所确认的当前播放位置之前的图像帧数就可以计算当前图像帧 所对应的 NPT时间; 或者可以在初次注入节目内容时对整个节目进行预分析, 确定每帧图像所对应的 NPT时间和在节目媒体文件中的位置, 并将预分析信息 保存下来, 这样在播放过程中就可以直接根据当前播放位置确认所播放的图像 帧, 从而确定该图像帧所对应的 NPT时间。 如果是快进, 则 NPT时间递增, 如 果是快退, 则 NPT时间递减, 而 RTP时戳都是逐渐增长的。 终端收到 RTP包后 根据 RTP包扩展头中的 NPT信息获得包含该 RTP包的图象帧相对于整个节目的 实际播放时间。
歩骤 S409:用户终端接收媒体服务器发来的包含有当前媒体流 NPT的媒体 流;
歩骤 S410:用户终端获取该媒体流 NPT并在播放该媒体流时显示出该媒体 流 NPT;
此处, 用户终端在接收到媒体服务器发来的媒体流后, 从扩展的 RTP报文 头中提取该媒体流的 NPT, 并在播放该媒体流时显示出该媒体流 NPT。
歩骤 S411 : 用户终端向媒体服务器请求正常播放;
歩骤 S412 :用户终端接收媒体服务器发来的正常播放的节目内容经流化处 理后生成的媒体流;
此处,用户终端接收的媒体流是媒体服务器切换到正常播放状态后按照正 常方式发来的 RTP报文, 该 RTP报文的时戳按照帧间隔正常递增, 且可以不携带 扩展 RTP报文头, 用户终端可以利用时戳来计算实际播放时间。 用户终端根据 接收到的媒体流计算当前媒体流的实际播放时间可通过以下两种方法实现: 1、 用户终端以在快进 /快退、 慢退 /慢进期间收到的最后一个包含 NPT时间信息的 RTP包所对应的 NTP时间作为起始 NPT, 该 RTP包的时戳作为初始时戳, 在收到媒 体服务器在正常播放状态发送的不携带 NTP时间信息的 RTP包后, 根据当前被解 码的 RTP包的时戳和初始时戳之间的差值就可以计算当前的实际播放时间; 2、 用户终端将快进 /快退期、慢退 /慢进间收到的最后一个包含 NPT时间信息的 RTP 包对应的图像帧作为初始图像帧,在正常播放过程中根据当前被解码的不携带 NTP时间信息的 RTP包所对应的图像帧和初始图像帧之间的差值就可以计算已 经播放的帧数, 根据帧频和播放的帧数以及起始 NPT也可以计算当前的实际播 放时间。 具体的, 可以通过接收到的 RTP包是否包含扩展 RTP报文头来判断出技 巧模式中接收到的最后一个 RTP包, 即最后一个包含扩展 RTP报文头的 RTP包即 为技巧模式中接收到的最后一个 RTP包。
歩骤 S413 : 结束播放, 释放资源。
此处,在播放到文件结束位置后媒体服务器通知终端结束播放,删除会话, 释放资源。
相应的, 图 5示出了本发明实施例中实现直播业务的 Trick-mode操作场 景。 本发明实施例是直播业务的 Trick-mode操作情景, 在该实施例中设媒体 数据是基于 RTP传输, 设直播节目列表信息已经发布到 EPG服务器上, 具体歩 骤包括:
歩骤 S501 :媒体服务器实时录制和存储直播节目,并记录直播图像帧对应 的 UTC;
此处, 媒体服务器对从头端播出的直播节目进行实时录制和存储, 为后续 的用户回看提供节目源, 即媒体服务器在部署时加入从头端发送的组播报文 的组播组, 接收和保存直播频道的节目内容, 在保存图像帧数据的同时记录该 图像帧被从头端播放出来时所对应的 UTC时间。
歩骤 S502: 接入设备接收直播节目;
此处, 为了减少组播加入的时延, 在节目部署时同样将直播节目直接推送 到了接入设备上, 即接入设备也加入组播组接收组播报文, 实际中比较常见的 接入设备包括 IP-DSLAM和 GEP0N。
歩骤 S503 : 用户终端与应用服务器进行鉴权, 如果鉴权通过, 进行歩骤 S304;
此处, 用户终端开机后与应用服务器交互进行鉴权, 以确保业务的合法使 用。
歩骤 S504: 用户终端从 EPG服务器中获取直播频道列表信息;
此处, 该直播频道列表信息包含直播节目的组播 IP地址和用于对直播节 目音视频码流进行解码的编解码参数信息。
歩骤 S505: 用户终端向媒体服务器请求建立连接;
此处,当用户选定观看某个频道的节目时,终端向接入设备发送 IGMP Join 消息加入用户指定的频道所对应的组播组。
歩骤 S506: 用户终端接收接入设备转发的媒体流;
此处,接入设备完成 IGMP消息处理后将指定频道的组播报文转发给终端, 终端对收到的媒体报文进行解码和输出, 用户就可以观看到指定的频道的节 圈。
歩骤 S507:用户终端向应用服务器发起快退, 并查询提供直播快退业务的 媒体服务器;
此处, 当用户在观看直播的过程中通过操作后退键进入直播 trick-mode 状态, 终端通过向接入设备发送 IGMP Leave消息停止接收组播流, 并向应用 服务器通知状态的改变和查询提供直播 trick-mode业务的媒体服务器, 应用 服务器查询后向终端返回包含提供直播 trick-mode业务的媒体服务器信息的 消息。
歩骤 S508: 用户终端与该提供 trick-mode业务的媒体服务器建立连接, 并指示该媒体服务器提供快退业务;
此处,在用户终端发起的建立连接的消息中携带与当前终端的播放位置对 应的时间信息, 媒体服务器根据该时间信息确定终端当前的播放位置。 对于媒 体服务器而言, 用户终端请求的直播 trick-mode业务类似于终端发起了指定位 置的点播请求。
下面给出使用 RTSP协议协商从指定位置播放时的示例:
C -> S: PLAY rtsp : //example. com/mediastream RTSP/1. 0
CSeq: 2
Session : 123456
Range: clock=20080906T123020. 120Z- Scale : -8 〃示例为 8倍速快退
这里的头域(Header field) Range的参数 clock=20080916T123020. 120Z指 示媒体服务器播放从 2008年 9月 16日 12点 30分 20秒 120毫秒开始的节目。
媒体服务器收到消息后对媒体文件进行分析, 定位出媒体文件中与指定的 播放位置最近的 I帧, 则回应如下消息, 并从该处开始播放媒体流:
S -〉 C : RTSP/1. 0 200 0K
CSeq : 2
Session : 123456
Range : clock=20080906T123020. 150Z- Scale: -8
RTP-Info : url=rtsp: / / example, com/mediastream; seq=1000; rtptime=5000 这里的头域 Range的参数 20080906T123020. 150Z-表明媒体服务器从对应
2008年 9月 16日 12点 30分 20秒 150毫秒的媒体文件处开始播放媒体数据, 且头域 RTP-Info的参数 seq=1000和 rtptime=5000给出了媒体服务器发送的 与该位置对应的第一个 RTP包的序列号和时戳。
歩骤 S509 : 媒体服务器在媒体流中添加当前媒体流的 UTC;
此处,媒体服务器按照终端要求从指定位置按照后退方式开始给终端播放 本地保存的对应直播频道的媒体数据。 根据用户发起的直播业务的 Trick-mode, 媒体服务器在媒体流中添加当前媒体流的 UTC, 该 UTC放在扩展的 RTP报文头中。 利用扩展的 RTP报文头来传输 UTC时间信息时的 RTP报文格式如 下: 固定 RTP报文 扩展 RTP报文头 RTP 艮文净荷
其中扩展 RTP报文头用来传输与 RTP报文净荷对应的图像帧被从头端播放 出来时所对应的 UTC时间, 终端根据该信息就可以准确地输出 UTC时间信息, 提 醒用户当前节目的播放进度。
扩展 RTP报文头可以示例定义如下:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
defined by profile = 3 | length = 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header extension = ι¾ 32位
header extension =低 32位
这里定义 defined by prof ile为 3表示扩展 RTP报文头传输的是 UTC时间信 息, header extension是以毫秒为单位的 UTC时间, 该值表示的是相对于 1970 年 1月 1日 00:00:00已经过去的时间, length设为 2,表示 header extension为 64bit宽度。
上面的扩展 RTP报文头定义中按照数值方式表示 UTC时间, 也可以考虑用字 符方式来来表示 UTC时间, 示例如下: 20080906T123020.150Z
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
defined by profile = 4 | length = 6
+-+ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header extension = 'V '0, <0, <8,
header extension = 0, '9, '0,
header extension = T 'V 'V
header extension = '0, '2} '0,
header extension = T '5' '0, Ί
header extension = 0, (结束符) 这里定义 defined by prof ile为 2表示扩展 RTP报文头传输的是字符格式的 UTC时间信息, header extension是以字符方式表示的 UTC时间, length设为 6, 表示 header extension占用了 6个 32bit宽度。
在播放期间,媒体服务器需要分析发送出去的每帧图像所对应的 UTC时间, 并将该帧图像所对应的 UTC时间按照上面描述的方式填充到用来传输该帧图像 的 RTP报文的扩展头中。具体分析每帧图像所对应的 UTC时间的方法可以是在录 制节目时对录制的内容进行预分析, 确定每帧图像所对应的 UTC时间和在节目 媒体文件中的位置, 并将预分析信息保存下来, 这样在播放过程中就可以直接 根据当前播放位置确认所播放的图像帧, 从而确定该图像帧所对应的 UTC时间。 对于快退, 则 UTC时间递减, 而 RTP时戳都是逐渐增长的, 如果是快进则 UTC时 间是递增的。 终端收到 RTP包后根据 RTP包扩展头中的 UTC信息获得当前播放的 内容所对应的 UTC时间。
歩骤 S510: 用户终端接收媒体服务器发来的包含有媒体流 UTC的媒体流; 歩骤 S511 : 用户终端提取该媒体流 UTC并在显示该媒体流时显示出该媒体 流 UTC;
此处, 用户终端在接收到媒体服务器发来的媒体流后, 从扩展的 RTP报文 头中提取该媒体流的 UTC时间信息, 并在播放该媒体流时显示出该媒体流对应 的 UTC。
歩骤 S512: 用户终端向媒体服务器请求正常播放;
歩骤 S513: 用户终端接收媒体服务器发来的正常播放的媒体流; 此处,用户终端接收的媒体流是媒体服务器切换到正常播放状态后按照正 常方式发来的 RTP报文, 该 RTP报文的时戳按照帧间隔正常递增, 且可以不携带 扩展 RTP报文头, 用户终端可以利用时戳确定实际播放时间。 用户终端根据接 收到的媒体流计算当前媒体流的实际播放时间可通过以下两种方法实现: 1、 用户终端以在快退期间收到的最后一个包含 UTC时间信息的 RTP包所对应的 UTC 时间作为起始 UTC, 该 RTP包的时戳作为初始时戳, 在收到媒体服务器在正常播 放状态发送的不携带 UTC时间信息的 RTP包后, 根据当前被解码的 RTP包的时戳 和初始时戳之间的差值就可以计算当前播放的内容所对应的播放时间; 2、 用 户终端将快退期间收到的最后一个包含 UTC时间信息的 RTP包对应的图像帧作 为初始图像帧, 在正常播放过程中根据当前被解码的不携带 UTC时间信息的 RTP 包所对应的图像帧和初始图像帧之间的差值就可以计算已经播放的帧数, 根据 帧频和播放的帧数以及起始 UTC也可以计算当前播放的内容所对应的播放时 间。 具体的, 可以通过接收到的 RTP包是否包含扩展 RTP报文头来判断出技巧模 式中接收到的最后一个 RTP包, 即最后一个包含扩展 RTP报文头的 RTP包即为技 巧模式中接收到的最后一个 RTP包。
需要说明的是, 在用户显示时间信息过程中, 不管在正常播放期间还是在 Trick-mode期间, 媒体服务器都可以将 NPT和 /或 UTC通过扩展的 RTP报文头 带给用户终端。 在具体实施时, 在正常播放期间和 Trick-mode期间, 媒体服 务器均在要发送的媒体流中添加该媒体流的 NPT/UTC信息, 这样, 用户终端在 接收到该包含有媒体流的 NPT/UTC信息的媒体流时,用户终端直接提取该媒体 流的 NPT/UTC并在播放该媒体流时显示出该媒体流的 NPT/UTC, 从而可以减少 用户终端的处理复杂度, 也使得用户可以准确地知道节目的当前播放位置。
综上所述, 本发明实施例提供的网络电视显示时间的方法及设备和系统, 在用户进行技巧模式操作时, 媒体服务器分析出进行技巧模式操作后所对应的 图像帧所对应的时间信息, 通过媒体服务器在媒体流中添加当前媒体流 NPT/UTC, 并将所述包含有当前媒体流 NPT/UTC的媒体流发送给用户终端, 用 户终端接收所述媒体服务器发来的包含有当前媒体流 NPT/UTC的媒体流,提取 所述媒体流 NPT/UTC, 并在播放所述媒体流时显示出所述媒体流 NPT/UTC , 使 得用户终端能准确地获取当前播放的节目的播放时间信息, 从而使得用户可以 准确地知道节目的当前播放位置。
以上所揭露的仅为本发明一种较佳实施例而已, 当然不能以此来限定本发 明之权利范围, 因此依本发明权利要求所作的等同变化, 仍属本发明所涵盖的 范围。
通过以上的实施方式的描述, 本领域的技术人员可以清楚地了解到本发明 可借助软件加必需的硬件平台的方式来实现, 当然也可以全部通过硬件来实 施。 基于这样的理解, 本发明的技术方案对背景技术做出贡献的全部或者部分 可以以软件产品的形式体现出来, 该计算机软件产品可以存储在存储介质中, 如 R0M/RAM、 磁碟、 光盘等, 包括若干指令用以使得一台计算机设备 (可以是 个人计算机, 服务器, 或者网络设备等)执行本发明各个实施例或者实施例的 某些部分所述的方法。

Claims

权利要求书
1、 一种网络电视显示时间的方法, 其特征在于, 包括:
向媒体服务器发送技巧模式操作请求;
接收媒体服务器发送的媒体流,所述媒体流包括播放所述媒体流时所对应 的播放时间信息,所述播放时间信息具体包括进行技巧模式操作后接收的所述 媒体流中包含的图像帧所对应的时间信息;
获取所述媒体流所对应的播放时间信息, 并在播放所述媒体流时显示所述 媒体流所对应的播放时间。
2、 如权利要求 1所述的网络电视显示时间的方法, 其特征在于, 技巧模 式操作结束后还包括:
接收媒体服务器发送的媒体流,所述媒体流为媒体服务器切换到正常播放 状态后发送的媒体流;
根据在技巧模式操作中接收到的最后一个实时传送协议报文包所对应的 时间信息, 获得所述媒体流所对应的播放时间信息, 并在播放所述媒体流时显 示所述媒体流所对应的播放时间。
3、 如权利要求 1或 2所述的网络电视显示时间的方法, 其特征在于, 所 述技巧模式为快进, 或快退, 或慢退, 或慢进。
4、 如权利要求 1或 2所述的网络电视显示时间的方法, 其特征在于, 所 述播放时间信息封装在实时传送协议报文中。
5、 如权利要求 1或 2所述的网络电视显示时间的方法, 其特征在于, 所 述播放时间信息包括世界标准时间和 /或相对节目起点的播放时间。
6、 如权利要求 4所述的网络电视显示时间的方法, 其特征在于, 所述播 放时间信息通过数值方式或者字符方式进行表示。
7、 一种网络电视传输时间信息的方法, 其特征在于, 包括:
接收用户终端发送的技巧模式操作请求;
根据所述技巧模式操作请求分析当前媒体流包含的图像帧所对应的时间 自 .
将所述分析出的时间信息添加在所述当前媒体流;
将所述当前媒体流发送给用户终端。
8、 如权利要求 7所述的网络电视传输时间信息的方法, 其特征在于, 所 述技巧模式为快进, 或快退, 或慢退, 或慢进。
9、 如权利要求 7所述的网络电视传输时间信息的方法, 其特征在于, 所 述播放时间信息封装在实时传送协议报文中。
10、 如权利要求 9所述的网络电视传输时间信息的方法, 其特征在于, 所 述播放时间信息通过数值方式或者字符方式进行表示。
11、 如权利要求 7所述的网络电视传输时间信息的方法, 其特征在于, 所 述播放时间信息包括世界标准时间和 /或相对节目起点的播放时间。
12、 一种用户终端, 其特征在于, 包括:
发送单元, 向媒体服务器发送技巧模式操作请求;
接收单元, 用于接收媒体服务器发送的媒体流, 所述媒体流包括播放所述 媒体流时所对应的播放时间信息,所述播放时间信息具体包括进行技巧模式操 作后接收的所述媒体流中包含的图像帧所对应的时间信息;
获取单元,用于获取所述接收单元接收到的所述媒体流所对应的播放时间 自 .
显示单元,用于在播放所述媒体流时显示所述获取单元获取到的所述媒体 流所对应的播放时间。
13、 如权利要求 12所述的用户终端, 其特征在于, 所述用户终端还包括: 接收处理单元, 用于接收媒体服务器发送的媒体流, 所述媒体流为媒体服 务器切换到正常播放状态后发送的媒体流; 根据在技巧模式操作中接收到的最 后一个实时传送协议报文包所对应的时间信息, 获得所述媒体流所对应的播放 时间信息, 并在播放所述媒体流时显示所述媒体流所对应的播放时间。
14、 一种媒体服务器, 其特征在于, 包括:
接收单元, 用于接收用户终端发送的技巧模式操作请求;
分析单元,用于根据所述接收单元接收的所述技巧模式操作请求分析当前 媒体流包含的图像帧所对应的时间信息;
添加单元, 用于将所述分析单元分析出的时间信息添加在当前媒体流; 发送单元, 用于将所述添加单元中的当前媒体流发送给用户终端。
PCT/CN2009/075834 2008-12-31 2009-12-22 一种网络电视显示时间的方法及设备 WO2010075743A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200810220733.0A CN101465996B (zh) 2008-12-31 2008-12-31 一种网络电视显示时间的方法及设备和系统
CN200810220733.0 2008-12-31

Publications (1)

Publication Number Publication Date
WO2010075743A1 true WO2010075743A1 (zh) 2010-07-08

Family

ID=40806318

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2009/075834 WO2010075743A1 (zh) 2008-12-31 2009-12-22 一种网络电视显示时间的方法及设备

Country Status (2)

Country Link
CN (1) CN101465996B (zh)
WO (1) WO2010075743A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9197913B2 (en) 2012-03-29 2015-11-24 Sony Corporation System and method to improve user experience with streaming content
WO2018036109A1 (zh) * 2016-08-24 2018-03-01 中兴通讯股份有限公司 媒体信息封装方法及装置、封装文件解析方法及装置

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101465996B (zh) * 2008-12-31 2013-04-24 华为技术有限公司 一种网络电视显示时间的方法及设备和系统
CN102314148B (zh) * 2010-07-06 2014-11-05 康佳集团股份有限公司 网络电子时钟系统及其对时方法
CN102377963B (zh) * 2010-08-19 2014-08-20 深圳Tcl新技术有限公司 一种电视节目显示方法
CN102291432A (zh) * 2011-07-05 2011-12-21 广东威创视讯科技股份有限公司 网络信息共享方法、装置及客户端
KR101974077B1 (ko) * 2013-05-22 2019-08-23 한화테크윈 주식회사 Rtp 패킷을 이용한 재생 영상의 시간 표시 방법
CN103716706A (zh) * 2013-12-06 2014-04-09 乐视致新电子科技(天津)有限公司 一种多媒体文件播放进度与显示进度同步的方法及装置
CN104735552A (zh) * 2013-12-23 2015-06-24 北京中传数广技术有限公司 一种直播视频标签插入的方法与系统
CN104320386B (zh) * 2014-10-11 2018-03-27 北京凌云光技术有限责任公司 基于实时流传输协议的数据发送、接收方法及相应装置
CN104468623B (zh) * 2014-12-27 2017-12-29 广州华多网络科技有限公司 一种基于在线直播的信息展示方法、相关装置及系统
CN105898524A (zh) * 2015-11-02 2016-08-24 乐视致新电子科技(天津)有限公司 一种节目回看方法、一种播放器及一种终端
JP2018005358A (ja) * 2016-06-29 2018-01-11 カシオ計算機株式会社 コンテンツ出力装置、通信装置、コンテンツ出力方法、時間表示方法及びプログラム

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1801929A (zh) * 2005-12-08 2006-07-12 复旦大学 一种网络互动电视系统实现时移功能的方法
US20070101012A1 (en) * 2005-10-31 2007-05-03 Utstarcom, Inc. Method and apparatus for automatic switching of multicast/unicast live tv streaming in a tv-over-ip environment
CN1976440A (zh) * 2006-12-11 2007-06-06 中山大学 一种在iptv中精确定位播放进度的方法及系统
CN101465996A (zh) * 2008-12-31 2009-06-24 华为技术有限公司 一种网络电视显示时间的方法及设备和系统

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7400653B2 (en) * 2004-06-18 2008-07-15 Dolby Laboratories Licensing Corporation Maintaining synchronization of streaming audio and video using internet protocol
CN101179484A (zh) * 2006-11-09 2008-05-14 华为技术有限公司 一种不同媒体流间的同步方法及系统

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070101012A1 (en) * 2005-10-31 2007-05-03 Utstarcom, Inc. Method and apparatus for automatic switching of multicast/unicast live tv streaming in a tv-over-ip environment
CN1801929A (zh) * 2005-12-08 2006-07-12 复旦大学 一种网络互动电视系统实现时移功能的方法
CN1976440A (zh) * 2006-12-11 2007-06-06 中山大学 一种在iptv中精确定位播放进度的方法及系统
CN101465996A (zh) * 2008-12-31 2009-06-24 华为技术有限公司 一种网络电视显示时间的方法及设备和系统

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9197913B2 (en) 2012-03-29 2015-11-24 Sony Corporation System and method to improve user experience with streaming content
WO2018036109A1 (zh) * 2016-08-24 2018-03-01 中兴通讯股份有限公司 媒体信息封装方法及装置、封装文件解析方法及装置

Also Published As

Publication number Publication date
CN101465996A (zh) 2009-06-24
CN101465996B (zh) 2013-04-24

Similar Documents

Publication Publication Date Title
WO2010075743A1 (zh) 一种网络电视显示时间的方法及设备
JP5363473B2 (ja) 改善されたメディア・セッション管理の方法と装置
EP2036350B1 (en) Media channel management
US20080151885A1 (en) On-Demand Multi-Channel Streaming Session Over Packet-Switched Networks
EP2101500A1 (en) A video on demand controlling method, a client device and a switch controlling equipment
EP3515083B1 (en) Method and apparatus for performing synchronization operation on contents
US20090222873A1 (en) Multimedia Channel Switching
WO2008055420A1 (fr) Procédé de synchronisation entre différents flux de média et un système
EP2472799B1 (en) Method, apparatus and system for rapid acquisition of multicast realtime transport protocol sessions
WO2011000253A1 (zh) 一种媒体流处理方法及通讯系统以及相关设备
JP4308555B2 (ja) 受信装置および情報閲覧方法
WO2009067935A1 (fr) Procédé, dispositif et système de mise en œuvre de services de télévision sur ip
CN108366044B (zh) 一种VoIP远程音视频共享方法
KR101642380B1 (ko) 디지털 콘텐츠 스트림의 송신 방법 및 대응하는 수신 방법
WO2008141542A1 (fr) Procédé, dispositif vidéo et système pour l&#39;affichage d&#39;informations au moment d&#39;une commutation de canaux
WO2011137848A1 (zh) 广告拼接处理方法和系统以及拼接器和头端设备
WO2014036873A1 (zh) 一种传输流的共享方法
EP2479984A1 (en) Device and method for synchronizing content received from different sources
KR102271686B1 (ko) 이종 네트워크 기반의 멀티미디어 자원 동기화 푸시 방법
WO2010105550A1 (zh) 一种播放模式切换的方法和装置
CN107801103B (zh) 异构网络下基于网络状况的多媒体资源自适应同步方法
WO2011022983A1 (zh) 组播视频数据的方法、装置及系统
JP2001320686A (ja) ビデオコンテンツ配信システム、ビデオコンテンツ配信方法、ビデオコンテンツ配信サーバ及びビデオコンテンツ受信端末
US9124921B2 (en) Apparatus and method for playing back contents
JP2009134747A (ja) 送信装置およびメディアデータ送信方法

Legal Events

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

Ref document number: 09836030

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09836030

Country of ref document: EP

Kind code of ref document: A1