WO2011106930A1 - Procédé, équipement et système pour mettre en œuvre une opération de magnétoscope (vcr) pour flux média enrichi - Google Patents

Procédé, équipement et système pour mettre en œuvre une opération de magnétoscope (vcr) pour flux média enrichi Download PDF

Info

Publication number
WO2011106930A1
WO2011106930A1 PCT/CN2010/070838 CN2010070838W WO2011106930A1 WO 2011106930 A1 WO2011106930 A1 WO 2011106930A1 CN 2010070838 W CN2010070838 W CN 2010070838W WO 2011106930 A1 WO2011106930 A1 WO 2011106930A1
Authority
WO
WIPO (PCT)
Prior art keywords
client
rich media
scene
stream data
server
Prior art date
Application number
PCT/CN2010/070838
Other languages
English (en)
Chinese (zh)
Inventor
汤博
彭展
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to PCT/CN2010/070838 priority Critical patent/WO2011106930A1/fr
Priority to CN2010800016230A priority patent/CN102860002A/zh
Publication of WO2011106930A1 publication Critical patent/WO2011106930A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • H04N7/17309—Transmission or handling of upstream communications
    • H04N7/17336—Handling of requests in head-ends
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2387—Stream processing in response to a playback request from an end-user, e.g. for trick-play
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H04N21/47202—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for requesting content on demand, e.g. video on demand

Definitions

  • the server may initiate a scene flow jump. For example, the server sends a seek scene command to the client to instruct the client to perform a jump of the corresponding scene stream.
  • the server sends different access packets according to requirements, for example, normal random access point (Normal RAP), redundant random access point. (Redundant RAP) and Distributed Random Access Point (DRAP).
  • Normal RAP normal random access point
  • redundant random access point redundant random access point
  • DRAP Distributed Random Access Point
  • a method for implementing a VCR operation of a rich media stream video cassette recorder comprising:
  • FIG. 10 is a schematic diagram of a fast rewind/slow operation of a rich media stream according to an embodiment of the present invention
  • FIG. 11 is a schematic structural diagram of a server end according to an embodiment of the present invention
  • FIG. 12 is a schematic structural diagram of another server end according to an embodiment of the present disclosure
  • FIG. 13 is a schematic structural diagram of a client device according to an embodiment of the present disclosure.
  • the client After receiving the data, the client obtains or calculates the scene rendering time according to the type of the VCR operation and the corresponding time information (such as a timestamp), and parses and presents the corresponding scene. After completing the above VCR operation, the client returns to the normal state.
  • the technical solutions provided by the embodiments of the present invention are described in detail below.
  • An embodiment of the present invention provides a method for implementing a VCR operation of a video cassette recorder by using a rich media stream. As shown in FIG. 1, the method includes:
  • the server end can be based on the state of the client and
  • the sent VCR operation request information sends the corresponding rich media scene stream data to the client, thereby ensuring that the corresponding VCR operation can be successfully implemented on the client.
  • the client can process the normal rich media scene stream data, and the type of the rich media scene stream data sent to the client is normal rich media scene stream data, and the method further includes :
  • the server encapsulates the data that needs to be sent to the client into normal rich media scene stream data; or
  • the redundant rich media scene stream data includes at least one of the following: a distributed random access point, a redundant random access point, redundant rich media scene stream update data, and converted redundant rich media scene stream update data.
  • the method of encapsulating data sent to the client by the server side includes at least the following two types:
  • the jump request information includes information for indicating a jump time point, and the server determines the location before the server sends the corresponding rich media scene stream data to the client. Whether the rich media scene stream data packet corresponding to the jump time point contains the complete scene description, and if yes, the jump time point and its subsequent rich media scene stream data are sent to the client; if not, the distance is The time point at which the full scene description exists in the jump time point is used as the determined jump time point, and the determined jump time point and its subsequent rich media scene stream data packet are sent to the client.
  • the server determines the rich media scene stream data delivery policy according to the update frequency and the scene size.
  • the specific manner in which the server is aware of the state of the client is not limited.
  • the server sends a special data packet to control the change of the client state, and the special data packet includes: an empty rich media stream data packet or a rich media stream data packet with the identifier bit D being 1; may be determined in advance when the client performs the VCR operation.
  • the status of the state or the state of the hop, and the server is notified.
  • the client carries the status of the VCR operation request information, and the server uses the VCR operation request information to know the current state of the client.
  • the above steps 21 to 23 can be implemented by a related device of the client, such as a mobile phone.
  • the client needs to perform VCR operation on the rich media stream
  • the client sends the VCR operation request information to the server.
  • the rich media stream is a rich media scene stream
  • the client after the client sends the VCR operation request information, it will switch to the corresponding state or maintain the current state.
  • the server may be controlled by a special packet, or the client may automatically switch to notify the server.
  • first”, “second”, and third” are used to mark similar items having corresponding relationships, and "first”, “second”, and third” are not performed in the order or quantity of operations. limited. The same description applies equally to the following.
  • the method for realizing the VCR operation of the video cassette recorder by the rich media stream provided by the embodiment of the present invention will be separately described below according to different states of the client and specific types of VCR operations.
  • Normal RAP Contains complete scene description information, used when switching scenes and access, error recovery. According to the DIMS protocol, the Normal RAP implies an attribute with zero scene time. That is, after the scene is switched and accessed, the scene time will be set to zero. Normal RAP is processed in both normal and redundant processing states.
  • DIMS defines the DRAP mechanism, which is a redundant random access point.
  • the content required by DRAP to provide random access is not completely contained in its own DIMS package.
  • Some of the elements used will be included in a subsequent series of resource bundles (redundant DIMS packets), and DRAP packets are only given. Access required elements and reference relationships to certain elements in subsequent redundant packages.
  • the feature of DRAP is that it can smooth the bandwidth and avoid the peak bandwidth effect caused by the transmission of large RAP packets.
  • the type of DIMS packet can be known according to the header of the DIMS packet. See the table for the header format of the DIMS packet.
  • Flag S When this flag is 1, the information in the packet is the scene description; when this flag is 0, it indicates that the information contained in the packet is a scene command.
  • the client and the server can adopt the following two processing methods:
  • the first way the client jumps between the VCR processing state and the normal state
  • the normal state in the first mode refers only to the normal state in the second state described above, and specifically includes the following processing:
  • the client is in the second state. In this state, the client only processes normal DIMS packets and parses the rendering.
  • the client maintains the normal state during the normal play and the VCR play.
  • the normal state may refer to the normal state in the second state or the normal state in the third state, and the processing flow is as follows:
  • the client only processes normal DIMS packets and parses the presentation.
  • the client can handle any type of DIMS packet under this normal state.
  • the server does not modify the DIMS packets that it needs to deliver.
  • the processing process of the client is as follows:
  • the client calculates the scene presentation time according to the scene time, the media time, and the type of the VCR operation performed during the VCR operation, and presents the received DIMS data packet according to the scene presentation time.
  • the user initiates normal broadcast to the server through the client using RTSP. Put request information to continue playing the suspended rich media stream data;
  • the server After receiving the normal play request information, the server sends a play request response and corresponding rich media stream data to the client.
  • mediaTime(z) refers to the media time that the client receives the first DIMS packet since the replay is performed.
  • the media time can be RTP timestamp information.
  • the mediaTime(y) is the media time when the client initiates replay, and the media time can be carried in the response fed back by the server, as carried in the above playback request response. Jump
  • the rich media stream service usually contains three streams of scene, audio and video. If all three streams need to be redirected and the three streams are synchronized, the client will use RTSP to send three jump request messages at the same time, as shown in the figure. 5 is shown. However, it is not limited to this. For example, the client can also implement three kinds of stream jumps through a jump request message.
  • the normal play time (NPT) indicating that the jump request information is initiated is S1.
  • the server side parses the jump request information, and when the corresponding jump can be implemented at the jump time point, sends the rich media stream data required to implement the corresponding jump at the jump time point to the client; When the corresponding jump is not performed at the jump time point, a new jump time point is determined, and the rich media stream data required for the corresponding jump is sent to the client at the determined jump time point.
  • the corresponding rich media scene stream data may not have key data packets to implement the corresponding jump, such as I frame in the video stream, DIMS RAP in the scene stream, then
  • the jump time point indicated by the client will not be able to implement the jump.
  • the server must relocate the new jump time point of each media stream according to the client's jump request information.
  • the new jump time point is the time closest to the jump time point indicated by the client and has the key data packet time. point.
  • VCR processing status After the server finishes processing, it can send the data after the jump, first send an empty rich media data packet, cut the state of the client back to the normal state through the data packet, and then continue to send the required normal
  • the client needs to obtain the current scene presentation time. Since the jump of the scene stream is implemented by the normal/redundant RAP, the scene presentation time after the jump is 0 (for normal RAP), or the value of the currentSceneTime attribute in the redundant RAP, that is, the scene presentation time can be expressed as follows :
  • the client presents three media streams according to the presentation relationship of the scene stream, the video stream and the audio stream.
  • the client starts parsing after receiving the three media streams received;
  • the fast forward/slow forward operations provided by the embodiments of the present invention are described in the following two cases in which the VCR processing request information is sent after the client sends the VCR operation request information and the VCR operation request information is sent to the client.
  • the client sends fast forward/slow forward request information to the rich media stream, and the fast forward/slow forward request information indicates that the first play speed (P1AY Scale ) of the rich media stream is VI, in this example, The scene stream and the video stream are described as an example. At this time, the client can fast forward or slow forward the scene stream and the video stream by sending two fast: 3 ⁇ 4/slow-in request information.
  • the playback rate of the fast/slow incoming request can be set in advance on the client, so that the first playback speed initiated by the client is within the range that the server can withstand, and the server does not need to adjust the playback speed.
  • the first playback speed is the same as the second playback speed.
  • Scenario size In the scene stream fast forward playback operation, when the server continuously accelerates the RAP, since each RAP is a complete scene description, the size of the RAP is closely related to the scene size. If the scene itself is large, the RAP that is continuously accelerated will cause the DIMS scene to flow out of a series of peaks. In order to solve this problem, the DRAP mechanism can be used to transmit the entire scene through multiple DIMS packets to provide random access points, reduce bandwidth peaks, and smooth bandwidth. In the case where the scenario itself is relatively small, it does not have a large impact on the server load, and can directly accelerate the transmission of the RAP.
  • the method of decelerating the update can be implemented.
  • the RAP can be directly decelerated, and when the scene is relatively large, the DRAP mechanism can also be used.
  • the distributed random access point is accelerated to the client at the second playback speed according to the fast forward/slow forward request information
  • the random access point is accelerated to the client at the second play speed
  • the accelerated transmission scenario update is sent to the client at the second playback speed
  • the first rich media scene stream data corresponds to the first update frequency and the first scene; and the second rich media scene stream data corresponds to the second update frequency and the second scene, deal with:
  • the first update frequency corresponding to the first rich media scene stream data is denser and the scene is larger, and the second update frequency corresponding to the second rich media scene stream data is denser and the scene is smaller, that is, when the first update frequency is greater than the first
  • the frequency is updated (the comparison step is not necessary)
  • the first rich media scene stream data or the second rich media scene stream data is sent to the client at the second playback speed, where the The rich media scene stream data is DRAP, and the second rich media scene stream data is RAP.
  • the second playback speed is The client sends the second rich media scene stream data, and the second rich media scene stream data scene is updated; for the slow forward operation:
  • the deceleration transmission scenario update may be sent to the client at the second playback speed according to the fast forward/slow forward request information
  • the distributed random access point is decelerated to the client at the second playback speed
  • the first rich media scene stream data corresponds to the first scene; and the second rich media scene stream data corresponds to the second scene, the following processing may be performed:
  • the client receives the rich media stream data sent by the server at the second playback speed V2 and presents the data at the second playback speed V2.
  • the client For the scene stream, the client needs to calculate the scene rendering time. As shown in Figure 8, the client can calculate the scene rendering time SceneTime ( z ) by the following formula:
  • SceneTime(z) . + scalex [mediaTime(z) - mediaTime(y)]
  • the client receives the rich media scene stream data packet from the VCR operation request information at the z point, where the y point is the time point at which the client initiates the fast forward, slow forward operation request or the previous scene stream data packet z
  • the time point of the adjacent scene stream packet, T s Indicates the scene time corresponding to the y point, scale Indicates the playback speed, mediaTime(z) represents the media time corresponding to z, and mediaTime(y) represents the media time corresponding to y;
  • the client initiates a normal play request, and plays the scene stream and the video stream at normal speed.
  • the server end ends the fast: 3 ⁇ 4/slow operation according to the normal play request, and sends corresponding data to the client at a normal speed.
  • the client receives the redundant DIMS packet with the D bit of 1, parses the presentation, and jumps to the normal state to start processing the normal DIMS packet.
  • the server can deliver the key packet by sending a fast packet: 3 ⁇ 4/slow forward, such as sending a RAP to the scene stream, and sending an I frame to the video stream.
  • a fast packet 3 ⁇ 4/slow forward
  • the server can deliver the key packet by sending a fast packet: 3 ⁇ 4/slow forward, such as sending a RAP to the scene stream, and sending an I frame to the video stream.
  • the following specifically includes the following processing: (In this case, the method of all the data packets is also sent. The following is only the method for sending the key data packets. The method for delivering all the scene data packets is specified. Rate all normal packets at the rate.)
  • the client obtains the scene presentation time according to the normal RAP delivered by the server.
  • the normal RAP is the original normal RAP that has not been converted by the server.
  • the client initiates a normal play request, and plays the scene stream and the video stream at normal speed.
  • the client initiates a fast rewind/slow rewind request message, indicating that the third playback speed V3 is used to rewind/slow back and enter the VCR processing state.
  • the scene stream and the video stream are taken as an example.
  • the client can fast forward or slow forward the scene stream and the video stream by sending two fast it/reverse request information.
  • the client enters the VCR processing state, in which the client can only process redundant DIMS packets.
  • the server sends the video stream and the reversed scene stream (RAP) according to the playback rate and the scene characteristics requested by the client, and the fourth playback speed V4 acceptable to the server.
  • the third playback speed and the fourth playback speed may be the same or different.
  • all RAPs are set to redundant RAPs (including DRAP) during transmission.
  • the server may use corresponding operations to perform state switching through the client in a subsequent process. For example, the server end notifies the client to perform state switching by using the identifier bit D in the packet header, where the server end Set the flag bit D in the header of the RAP to 0.
  • the server can use the DRAP or RAP to accelerate/decelerate the scene data.
  • the selection of the delivery strategy is shown in the following table:
  • the client receives the redundant RAP/DRAP sent at speed V4, calculates the scene time, and presents the scene (still), and plays the video in reverse order.
  • the client initiates a normal play request, and plays the scene stream and the video stream at normal speed. 5.
  • the server end ends the fast rewind/slow operation according to the normal play request.
  • the server notifies the client to switch the status when the fast forward/slow forward operation is ended.
  • the server After receiving the normal play request, if the resource packet referenced by the currently sent redundant RAP or DRAP has not been sent, the server needs to speed up the transmission and complete the packet in the header of the last DIMS packet.
  • the flag bit D is set to 1.
  • the client receives a redundant DIMS packet with a D bit of 1, parses the presentation, and jumps to the normal state.
  • the server sends the rich media stream data to the client at normal speed.
  • the method of operation is basically the same as the above.
  • the main difference is that when the server sends the RAP, the redundant RAP/DRAP needs to be converted into a normal RAP.
  • the technical solution provided by the method embodiment of the present invention when the client needs to perform a VCR operation on the rich media stream, sends the VCR operation request information to the server and determines the current state described by itself, and the server end is based on the VCR.
  • the operation request information sends corresponding rich media stream data to the client, and the client parses and receives the received rich media stream data.
  • the technical solution provided by the embodiment of the present invention uniquely creates a complete set of VCR operation control technology for rich media stream data, can realize VCR operation on rich media stream data, satisfies user needs, enhances user experience, and has high practicality. Sexuality and broader application prospects. As shown in FIG.
  • the first sending unit 112 is configured to send the rich media scene stream data of the type to the client according to the VCR operation request information.
  • the server includes a packaging unit 114, a jump time point determining unit 115, and a sending policy determining unit 116.
  • the first sending unit 112 is further configured to send an empty media stream data packet to the client, and set the state of the client to a first state; or
  • the first sending unit 112 is further configured to receive a normal play request sent by the client, send a redundant rich media stream data packet with the identifier bit D to the client, and set the state of the client to the second state.
  • the encapsulating unit 114 is configured to, after the type determining unit 113 determines the type of the rich media scene stream data sent to the client, encapsulate the data that needs to be sent to the client according to the type,
  • the client when the client is in the first state, that is, the VCR processing state, the client can process the redundant rich media scene stream data, and the encapsulating unit 114 is specifically configured to encapsulate the data that needs to be sent to the client into the redundant rich media scene stream. Data; or,
  • the client can process the normal rich media scene stream data, and the encapsulating unit 114 is specifically configured to encapsulate the data that needs to be sent to the client into the normal rich media scene stream data; or
  • the client can process the normal rich media scene stream data and the redundant rich media scene stream data, and the encapsulating unit 114 is specifically configured to encapsulate the data that needs to be sent to the client into a normal or redundant rich media scenario.
  • Stream data is specifically configured to encapsulate the data that needs to be sent to the client into a normal or redundant rich media scenario.
  • the encapsulating unit 114 is specifically configured to The identification bit I and the identification bit D of the header in the redundant rich media scene stream packet are set to zero.
  • a jump time point determining unit 115 configured to: when the VCR operation request information is a jump request letter If the information about the jump time point includes the information of the jump time point, it is determined whether the rich media scene stream data packet corresponding to the jump time point contains a complete scene description, and if yes, the jump time is The point and its subsequent rich media scene stream data are sent to the client; if not, the time point of the complete scene description that is closest to the jump time point is taken as the determined jump time point, and the determined The jump time point and its subsequent rich media scene stream packets are sent to the client.
  • the server side further includes: a delivery policy determining unit 116, configured to determine a rich media scene stream data delivery policy according to the update frequency and the size of the scene.
  • the server side provided by the embodiment of the present invention sends a VCR operation request information to the server side when the client needs to perform a VCR operation on the rich media scene stream, and the server end operates according to the state of the client and the VCR.
  • the request information sends the corresponding rich media scene stream data to the client, and the client parses the received rich media scene stream data and presents the rich media scene stream data.
  • the VCR operation control technology for the rich media scene stream data proposed by the technical solution provided by the embodiment of the present invention can implement the VCR operation on the rich media scene stream data, satisfies the needs of the user, and enhances the user body. High practicality and wide application prospects.
  • an embodiment of the present invention further provides a client 12, which includes: a second sending unit 121, configured to send, to a server, VCR operation request information for a rich media scene stream;
  • the second receiving unit 122 is configured to receive the rich media scene stream data sent by the server, where the rich media scene stream data is specifically determined by the server end according to the current state of the client and the VCR operation request information;
  • the parsing presentation unit 123 is configured to parse and render the rich media scene stream data.
  • the second receiving unit 122 is further configured to receive an empty rich media scene stream data packet sent by the server, and set the state to a first state, where the first state is a VCR processing state, where In the first state, the client can process redundant rich media scene stream data;
  • the parsing presentation unit 123 is further configured to calculate a scene presentation time according to a scene time when the VCR operation is initiated, a media time, and a type of the VCR operation performed; or
  • the parsing presentation unit 123 is further configured to use the scene time carried in the received rich media scene stream data as the scene presentation time; or
  • the parsing presentation unit 123 is further configured to determine that the scene presentation time is zero.
  • the client provided by the embodiment of the present invention sends a VCR operation request message to the server when the VCR operation needs to be performed on the rich media scene stream, and the server side according to the state of the client and the VCR operation request information.
  • Sending corresponding rich media stream data to the client the client device parses the received rich media scene stream data and presents the rich media scene stream data.
  • the technical solution provided by the embodiment of the present invention provides a VCR operation control technology for rich media scene stream data, which can implement VCR operation on rich media stream data, meets user needs, enhances user experience, and has high practicability. And a wider application prospect.
  • the embodiment of the present invention further provides a system for implementing a VCR operation by a rich media stream.
  • the server includes a server 131 and a client 132.
  • the server side 131 is configured to receive VCR operation request information sent by the client 132 to the rich media scene stream; and determine, according to the current state of the client 132, the type of rich media scene stream data sent to the client 132. Transmitting the type of rich media scene stream data to the client 132 according to the VCR operation request information;
  • the client 132 is configured to send VCR operation request information to the rich media scene stream to the server 131, and receive the rich media scene stream data sent by the server end 131; parse and present the rich media scene stream data.
  • the technical solution provided by the embodiment of the present invention when the client needs to target the rich media field When the VCR operation is performed, the VCR operation request information is sent to the server, and the server sends the corresponding rich media scene stream data to the client according to the state of the client and the VCR operation request information, and the client parses the received rich information.
  • the media scene stream data and presents the rich media scene stream data.
  • the technical solution provided by the embodiment of the present invention provides a VCR operation control technology for rich media scene stream data, which can implement VCR operation on rich media scene stream data, satisfies user needs, enhances user experience, and has high practicality. Sexuality and broader application prospects.

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

La présente invention porte sur un procédé, un équipement et un système pour mettre en œuvre l'opération de magnétoscope (VCR) pour flux média enrichi la présente invention concerne le domaine de la technologie média enrichi mobile, peut mettre en œuvre l'opération VCR pour flux média enrichi, satisfait les besoins de l'utilisateur, améliore l'expérience de l'utilisateur et implique une plus grande possibilité de mise en œuvre et de plus larges perspectives d'application. Le procédé décrit par les modes de réalisation de l'invention comprend les étapes suivantes : un terminal serveur reçoit les informations de requête d'opération VCR pour flux de scène média enrichi, les informations étant envoyées par un terminal client ; le serveur détermine le type pour les données de flux de scène média enrichi devant être envoyées au terminal client conformément à l'état présent dans lequel se trouve le terminal client ; et le terminal serveur envoie les données de flux de scène média enrichi dudit type conformément aux informations de requête d'opération VCR. Dans l'état correspondant, le terminal client reçoit les données de flux média enrichi correspondantes qui sont envoyées par le terminal serveur, analyse et affiche les données de flux média enrichi. La présente invention est appliquée à la situation dans laquelle l'opération VCR pour flux média enrichi est traitée.
PCT/CN2010/070838 2010-03-03 2010-03-03 Procédé, équipement et système pour mettre en œuvre une opération de magnétoscope (vcr) pour flux média enrichi WO2011106930A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/CN2010/070838 WO2011106930A1 (fr) 2010-03-03 2010-03-03 Procédé, équipement et système pour mettre en œuvre une opération de magnétoscope (vcr) pour flux média enrichi
CN2010800016230A CN102860002A (zh) 2010-03-03 2010-03-03 一种富媒体流实现盒式录像机操作的方法、设备和系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2010/070838 WO2011106930A1 (fr) 2010-03-03 2010-03-03 Procédé, équipement et système pour mettre en œuvre une opération de magnétoscope (vcr) pour flux média enrichi

Publications (1)

Publication Number Publication Date
WO2011106930A1 true WO2011106930A1 (fr) 2011-09-09

Family

ID=44541615

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2010/070838 WO2011106930A1 (fr) 2010-03-03 2010-03-03 Procédé, équipement et système pour mettre en œuvre une opération de magnétoscope (vcr) pour flux média enrichi

Country Status (2)

Country Link
CN (1) CN102860002A (fr)
WO (1) WO2011106930A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001069929A1 (fr) * 2000-03-15 2001-09-20 Load Media Networks, Inc. Systeme et procede d'assemblage de flux video codes destines a une lecture en continu
CN1437826A (zh) * 1999-12-28 2003-08-20 诺基亚有限公司 移动电话中图像快进重放功能的方法装置和系统
CN101540768A (zh) * 2009-04-23 2009-09-23 深圳市融创天下科技发展有限公司 一种富媒体系统的多终端自适应运行方法

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101998142A (zh) * 2009-08-10 2011-03-30 华为技术有限公司 一种实现盒式录像机操作的方法、设备和系统

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1437826A (zh) * 1999-12-28 2003-08-20 诺基亚有限公司 移动电话中图像快进重放功能的方法装置和系统
WO2001069929A1 (fr) * 2000-03-15 2001-09-20 Load Media Networks, Inc. Systeme et procede d'assemblage de flux video codes destines a une lecture en continu
CN101540768A (zh) * 2009-04-23 2009-09-23 深圳市融创天下科技发展有限公司 一种富媒体系统的多终端自适应运行方法

Also Published As

Publication number Publication date
CN102860002A (zh) 2013-01-02

Similar Documents

Publication Publication Date Title
KR101737325B1 (ko) 멀티미디어 시스템에서 멀티미디어 서비스의 경험 품질 감소를 줄이는 방법 및 장치
FI116816B (fi) Median suoratoisto
RU2622621C2 (ru) Система и способ для потоковой передачи воспроизводимого контента
JP4799661B2 (ja) ストリーム配信システム、呼制御サーバ装置及びストリーム配信制御方法
EP2391086B1 (fr) Procédé et appareil pour la lecture d'un contenu en direct
EP2184893B1 (fr) Procédé, système et appareil pour une commutation rapide de source multimédia
CN108347622B (zh) 多媒体数据推送方法、装置、存储介质及设备
US20090106288A1 (en) Method and system for supporting media data of various coding formats
US20060195884A1 (en) Interactive multichannel data distribution system
CN112399190B (zh) 音视频数据获取方法及其装置
JP5366107B2 (ja) メディア遅延を低減するための方法、装置およびシステム
WO2010066135A1 (fr) Procédé, dispositif et système de commutation de canal
US10499094B2 (en) Transmission apparatus, transmitting method, reception apparatus, and receiving method
US8959240B2 (en) Method, apparatus and system for rapid acquisition of multicast realtime transport protcol sessions
JP4308555B2 (ja) 受信装置および情報閲覧方法
JP5322518B2 (ja) 通信方法
US20070160048A1 (en) Method for providing data and data transmission system
CN111447503A (zh) 一种多视点视频的视点切换方法、服务器和系统
WO2009012701A1 (fr) Procédé de notification, appareil et système d'évenement de protocole de diffusion en continu en temps réel
CN106572383A (zh) 一种基于多屏互动的视频切换方法及系统
KR102137858B1 (ko) 송신 장치, 송신 방법, 수신 장치, 수신 방법 및 프로그램
WO2012083841A1 (fr) Procédé, terminal et système pour changer de canal
WO2014036873A1 (fr) Procédé de partage de flux de transport
WO2011106930A1 (fr) Procédé, équipement et système pour mettre en œuvre une opération de magnétoscope (vcr) pour flux média enrichi
US20070122123A1 (en) Data Transmission Method And Apparatus

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 201080001623.0

Country of ref document: CN

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

Ref document number: 10846849

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: 10846849

Country of ref document: EP

Kind code of ref document: A1