WO2009140888A1 - 一种实现录制业务的方法、装置及系统 - Google Patents

一种实现录制业务的方法、装置及系统 Download PDF

Info

Publication number
WO2009140888A1
WO2009140888A1 PCT/CN2009/071513 CN2009071513W WO2009140888A1 WO 2009140888 A1 WO2009140888 A1 WO 2009140888A1 CN 2009071513 W CN2009071513 W CN 2009071513W WO 2009140888 A1 WO2009140888 A1 WO 2009140888A1
Authority
WO
WIPO (PCT)
Prior art keywords
recording
server
request
client
function information
Prior art date
Application number
PCT/CN2009/071513
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 WO2009140888A1 publication Critical patent/WO2009140888A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/765—Interface circuits between an apparatus for recording and another apparatus
    • 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/27—Server based end-user applications
    • H04N21/274—Storing end-user multimedia data in response to end-user request, e.g. network recorder
    • H04N21/2747—Remote storage of video programs received via the downstream path, e.g. from the server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/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/47214—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 content reservation or setting reminders; for requesting event notification, e.g. of sport results or stock market
    • 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/17318—Direct or substantially direct transmission and handling of requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast

Definitions

  • the embodiments of the present invention relate to the field of communications, and in particular, to a method, device, and system for implementing a recording service. Background technique
  • network side recording refers to the network to record the media content that the user wants to record.
  • the source of the media content to be recorded may be a broadcast program, an on-demand program, or even a user's own video.
  • This technology can bring many benefits to the user, such as reducing the dependence of the recording service on the user terminal, expanding the storage space, and the like.
  • both the client and the server can issue requests for real-time data transmission via IP (Internet Protocol) network, such as two-way transmission of audio and video files.
  • IP Internet Protocol
  • the client may send a control request for playing, pausing, fast forwarding, fast rewinding, etc. of the media stream to the server, and the server may play the specified media content for the user after the corresponding processing according to the specific operation request, and during the playing process.
  • the corresponding operation is performed according to the user's control request.
  • IP Internet Protocol
  • the embodiments of the present invention provide a method, an apparatus, and a system for implementing a recording service, so as to implement network side recording under the client and server side architecture.
  • the method for implementing a recording service provided by the embodiment of the present invention includes:
  • the server receives the recording service request sent by the client, and the recording service request carries the recording function information
  • the server performs a recording service operation according to the recording function information.
  • a first receiving unit configured to receive a recording service request sent by the client, where the recording service request carries the recording function information
  • a system for implementing a recording service includes: a client, configured to send a recording service request to a server, where the recording service request carries a recording function information;
  • the server is configured to receive the recording service request, and perform a recording service operation according to the recording function information.
  • the method, system, and device for implementing the recording service provided by the embodiment of the present invention, after receiving the recording service request that carries the recording function information sent by the client, the server performs the recording service according to the recording function information. Operation, which enables network side recording under the client and server side architecture.
  • FIG. 1 is an exemplary flowchart of a method for implementing a recording service according to an embodiment of the present invention
  • FIG. 2 is a flowchart of a method in an embodiment of the present invention
  • FIG. 3 is a flow chart of a method according to another embodiment of the present invention.
  • FIG. 5 is a schematic structural diagram of a system for implementing a recording service according to an embodiment of the present invention
  • FIG. 6 is a schematic structural diagram of a server end according to an embodiment of the present invention. detailed description An application scenario of the embodiment of the present invention is described below.
  • the Real Time Streaming Protocol (RTSP) is an application layer protocol that controls the transmission of real-time data. It provides an extensible framework for controlled and on-demand delivery of real-time data such as audio and video files.
  • This protocol can be used to establish and negotiate real-time streaming sessions on the client and server side.
  • the client's task is to submit the user's request to the server, and the result returned by the server is displayed to the user in a specific form; and the server is responsible for receiving the service request from the client, and correspondingly Process and return the result to the client.
  • both the client and the server can issue requests for bidirectional data transfer.
  • FIG. 1 is an exemplary flowchart of a method for implementing a recording service according to an embodiment of the present invention. As shown in Figure 1, the process includes:
  • Step 101 The server receives a recording service request sent by the client, where the recording service request carries the recording function information.
  • the recording function information may include one or a combination of the following information: recording content identification, recording mode information, request recording duration, requested recording capacity, and recording file storage format.
  • the recording content identifier is used to indicate the physical storage location of the recorded content;
  • the recording mode information indicates the storage manner when recording the specified recording content, for example, it may be the recording content before the overlay, or may be the previous recording.
  • the content of the requested recording time indicates the length of time the recording request is recorded;
  • the requested recording capacity indicates the size of the recording of the recording request;
  • the recording file storage format indicates the storage format of the file, such as
  • the above-mentioned representation of the recording function information can be realized by extending the existing RTSP (Real Time Streaming Protocol) protocol.
  • RTSP Real Time Streaming Protocol
  • this representation effect can also be achieved by other means.
  • the extension of the protocol in the embodiment of the present invention is only a specific example, and the name of the message and the name of the parameter mentioned may also take other names.
  • the following is an extension of the RTSP header and recording function information parameters.
  • Action-info which can contain the following description of the recording function: 1.
  • the identifier of the recorded content: RecURL: This identifier can be specified by the client or by the server. In the recording service request sent by the client, if RecURL empty identifier (such as $) (of course, it can be set to other special identifiers, as long as the client and the server agree on it), indicating that the identifier will be served by the server. To perform the assignment, you need to include this parameter when you start recording normally. This parameter is optional when you resume recording and restart recording.
  • Record mode mode The value can be overwrite or append, etc., and the other way is the cover mode and the search port mode.
  • the display mode: mode "overwrite'7"append"roy This parameter is optional.
  • the storage format of the recording file format such as 3gp format, wav format.
  • Example: format "wav”, this parameter is optional.
  • Step 102 The server performs a recording service operation according to the recording function information carried in the recording service request.
  • the server can perform different operations according to the recording function information carried in the recording service request:
  • the recording function information can include: Recording content identification, and can further include one or a combination of request recording duration, request recording capacity, and recording file storage format.
  • the server After the recording is started normally, after receiving the recording service request, the server starts recording, and saves the obtained media content to be recorded in the location specified by the recording content identifier. If the recording content of the recording service request sent by the client is an empty identifier, the server allocates a recording content identifier to the session after receiving the request, and may carry the server end in the start recording request response message returned to the client. Assigned Recording content identification. Of course, in the case that the server side does not allocate the recording content identifier, the recording content identifier may be carried in the response message of the server to indicate confirmation.
  • the recording function information may include: recording mode information, and may further include: one or a combination of a recording content identification, a request recording duration, a request recording capacity, and a recording file storage format.
  • the recording mode information can be specifically covered.
  • the server After restarting the recording, after receiving the recording service request, the server stops the ongoing recording operation, restarts the recording from the current time point, and saves the obtained media content to be recorded in the previously recorded recording position. Cover the original recording valley.
  • the recording function information may include: recording mode information, and may further include: one or a combination of a recording content identification, a request recording duration, a request recording capacity, and a recording file storage format.
  • the recording mode information can be an additional method.
  • the server resumes recording from the current time point, and additionally saves the acquired media content to be recorded after the previous recording content.
  • the recording of the content identification in the recording service request is not mandatory. Since the system is assigned a session ID sessionID when the RTSP session is established, a unique session is identified. During the recording process, the server maintains the session ID state, and each recording control operation is associated with the ID. Therefore, when the recording is restarted, the server can record the content according to the sessionID without re-declaring where the content of the subsequent recording is overwritten. Overwrites the location specified by the recording content identifier saved in the previous recording operation. This recording should belong to the same session as the previous recording operation. Similarly, for the resume recording, when the content of the subsequent recording is not re-declared, the server is added.
  • the end can additionally save the recorded content according to the sessionID to the location specified by the recording content identifier in the previous recording operation, and the current recording and the previous recording operation should belong to the same session.
  • the recording service request carries the recording content identifier
  • the server will save the obtained media content to be recorded in the recording position specified by the recording content identifier, overwriting the original recording content; for the recovery recording, the server side will obtain the obtained recorded content.
  • the media content is additionally saved in the recording location specified by the recording content identifier, and is added after the previously recorded content.
  • the server side has the following operations after receiving the recording service request:
  • the server end stops the recording operation when the recorded recording time reaches the requested recording duration
  • the server stops the recording operation when the recorded storage capacity reaches the requested recording capacity
  • the server side acquires the obtained media content to be saved according to the recording file storage format.
  • the server can send a recording completion request to the client, and the request includes the recording result.
  • the recording result can be either the recording completed successfully or the recording failed. Recording completed successfully, which means that the server-side recording reaches the length of the request recording, and/or the capacity of the requested recording.
  • the recording failed to complete which refers to internal server-side errors, and/or insufficient server-side storage space.
  • the recording completion request includes: recording completion related information, such as actual recording duration and/or actual recording capacity; when the recording result is that the recording failure is completed, the recording completion request includes: recording failure the reason.
  • the work of reporting completion can be achieved by extending the existing RTSP protocol.
  • the extended event type 4001 Record-success Completed indicates that the recording is successfully completed, and 4002 Record-fail Completed indicates that the recording failure is completed, so that when the recording is completed
  • the server can notify the recording completion event.
  • the event type is 4001 Record-success Completed.
  • the specific example can be described as follows:
  • Event- type 4001 Record-success Completed
  • the event type is 4002 Record-fail Completed, and the following error code can be extended to explain the reason for the failure:
  • Extended parameter description used to indicate the actual length (s) actualdur and/or actual recorded capacity actualsize (KB) information of the actual recording on the server side when the recording is successfully completed.
  • the above parameters can be included in the entity part of the RTSP message. In use, you need to specify the Content-type and Content-length header information in the RTSP message, and then describe the parameter information in text form.
  • statistics-info Indicates the actual recording duration (s) actualdur and / or the actual recorded capacity actualsize (KB) information when the recording is successfully completed. The examples are described below:
  • the server receives the cancel recording request sent by the client, stops the ongoing recording operation, and deletes the already recorded content.
  • Extended Cancel recording method cancel This method can stop recording in progress and delete the recorded media content.
  • the server After the server starts recording based on the recorded business request, you can pause the recording in progress.
  • the server receives the pause recording request sent by the client and suspends the recording operation in progress.
  • the pause recording function can be implemented by extending the existing RTSP protocol: Extended pause recording method halt, this method can suspend the ongoing recording operation. For example, in order to save cyberspace, you can pause recording when there is advertising content, and resume recording after the advertisement. After the pause, the recovery of the recording can be seen in the above-mentioned resume recording operation.
  • the server After the server starts recording based on the recorded service request, you can stop the recording in progress.
  • the server receives the stop recording request sent by the client, stops the recording operation in progress, and the server can send a stop recording request response message to the client, where the message can carry the recording statistics related information, that is, the actual recording duration and/or actual Record the valley.
  • the stop recording function can be realized by extending the existing RTSP protocol: Extended Stop recording method stop, This method can stop the recording operation in progress.
  • Extended Stop recording method stop This method can stop the recording operation in progress.
  • the recorded content is saved in the location specified in the recording service request or specified by the server-assigned recording ID.
  • the representation method of the recording completion related information refer to the related protocol extension method when the previous recording is successfully completed.
  • the server after receiving the recording service request that carries the recording function information sent by the client, the server performs the recording service operation according to the recording function information, thereby realizing the network side recording under the client and server side architecture, further, Can realize COV (Consumer Originated Video) business, N-PVR (Network Personal Video Recorder), etc.
  • COV Consumer Originated Video
  • N-PVR Network Personal Video Recorder
  • an RTSP session has been established between the client and the server, and the server has obtained the media content to be recorded.
  • the user first requests to start normal recording, and finds that the recorded content does not meet the requirements during the recording process, and cancels the recording.
  • FIG. 2 it is a flowchart of the method of the embodiment.
  • Step 201 The client sends a recording service request message to the server, instructing to start recording.
  • the client requests the server to start the recording operation. It carries some recording function information: Recording content identification information http://Mserver/rec.ord/aa.wav means that the specified recording will be stored in this location. At the same time, it also carries the time required to record for 3000s. Of course, it can also carry the requested recording capacity and recording file storage format parameter information, which is not shown here.
  • the specific message can be as follows:
  • the identifier will be assigned by the server and then reported to the client.
  • Step 202 The server receives the recording service request message and starts recording.
  • the server determines that the recording operation is started normally, and the recording starts. Server can send a response to start recording Interest to the Client.
  • the recording content identifier may also be carried in the response message, which is the same as specified in the request message.
  • the format of the response message can be:
  • An example of the message format of the corresponding step 202 is:
  • RecURL "httpJ/I iserver/record/bb.wav"
  • the above response message indicates that the server has completed the assignment of the recorded content identifier, and the recorded content will be saved in the location specified by "http://Mserver/record/bb.wav”. .
  • Step 203 The client sends a cancel recording request message to the server, indicating that the recording is cancelled.
  • the client requests the server to cancel the recording that is in progress.
  • Step 204 The server stops recording, and deletes part of the content that has been recorded.
  • the server can send a response message to cancel the recording request to the client.
  • the specific message format can be:
  • an RTSP session has been established between the client and the server, and the server has obtained the media content to be recorded.
  • the user first requests to start normal recording.
  • the recording is paused, and the recording is resumed after the advertisement ends.
  • the recording result is fed back.
  • the recording result may be that the recording is successfully completed.
  • the network side stops recording and feedbacks the recording completion information, such as the actual recording duration and/or the actual recording capacity; the recording result may be completed by the recording failure. At this time, the network side feedback recording failed.
  • FIG. 3 it is a flowchart of the method of the embodiment.
  • Step 301 The client sends a recording service request message to the server, instructing to start recording.
  • the client requests the server to start the recording operation. It carries some recording function information: Recording content identification information http://Mserver/rec(3rcl/aa.wav, indicating that the specified recording content will be stored in this location. At the same time, it also carries the time required to record for 3000s, of course. Carrying the capacity of the requested recording and the recording file storage format parameter information are not shown here.
  • the specific message can be as follows:
  • Step 302 The server receives the recording service request message and starts recording.
  • Sever judges that the recording operation is started normally, and the recording starts.
  • Server can send a response message to start recording to the Client.
  • the recording content identifier may also be carried in the response message, which is the same as specified in the request message.
  • the format of the response message can be:
  • Step 303 The client sends a pause recording request message to the server, indicating that the recording is suspended.
  • the format of the message can be:
  • the client requests the server to pause the recording.
  • Step 304 Server pauses the ongoing recording.
  • the server can send a response message to the client to pause the recording request.
  • the format of the message can be:
  • Step 305 The client sends a recording service request message to the server, indicating that the recording starts from the current time point.
  • the resumed recording operation after the pause is indicated by the extended RTSP record method and the recording mode parameter information carried in the Action-info header information.
  • the specific message format can For:
  • the recording mode information carried by the extended RTSP record method indicates recovery recording.
  • the recording mode mode in the Action-info header information is appended with "append", indicating that the next content to be recorded will be appended to the previously recorded content for storage.
  • Step 306 The server receives the recording service request message, and starts the recovery recording operation from the current time point.
  • the recording mode mode takes the value of append, and the server determines that the recording operation is resumed.
  • the server can additionally save the recorded content in the previous recording operation according to the session identifier session1D allocated when the RTSP session is established (that is, the recording operation in steps 301 to 302).
  • the recording in the ID identifies the location specified.
  • the server can send a response message to the recovery record to the Client.
  • the specific message format is:
  • Step 307 After the recording is completed, the server sends a request message for recording completion to the client.
  • this request is implemented by the extended RTSP ANNOUNCE method.
  • the recording completion request message includes information related to the recording completion, that is, the actual recording duration and/or the actual recording capacity.
  • Event-Type 4001 Record-success Completed Statistics-info: actualdur: 3000
  • the Server announces that the recording is completed, and according to the Statistics-info header information, it indicates that the media content of 3000s is actually recorded, and the size is 2000 KB.
  • Event-Type 4001 Record-success Completed Content-Type: text/parameters
  • the server announces that the recording is completed, and the extended text parameter information, the actual recording duration, and the actual recorded capacity are described in the entity part. 4
  • the recording is recorded. 3000s of media content, the size is 2000KB.
  • the request message for recording completion can be as follows:
  • Event-Type 4002 Record-fail Completed 1
  • the event type is 4002 Recording failure completion event, "1" can indicate that the reason for this recording failure is a server-side error.
  • Step 308 After receiving the request message of the recording completion, the client may send a response message of the completion of the recording to the server.
  • the specific message format can be as follows:
  • an RTSP session has been established between the client and the server, and the server has obtained the media content to be recorded.
  • the user first requests to start normal recording, the user restarts the recording during recording, and stops recording after recording to the desired content.
  • FIG. 4 it is a flowchart of the method of the embodiment.
  • Step 401 The client sends a recording service request message to the server, instructing to start recording.
  • the client requests the server to start the recording operation. It carries some recording function information: Recording Content identification information http://Mserver/rec(3rcl/aa.wav, which means that the specified recording will be stored in this location. It also carries the capacity of 2000KB for recording.
  • the specific message can be as follows:
  • Step 402 The server receives the recording service request message and starts recording.
  • Sever judges that the recording operation is started normally, and the recording starts.
  • Server can send a response message to start recording to the Client.
  • the recording content identifier may also be carried in the response message, which is the same as specified in the request message.
  • the format of the response message can be:
  • Step 403 The client sends a recording service request message to the server, indicating that the recording starts again from the current time point.
  • the recording operation is restarted by the extended RTSP record method and the recording mode parameter information carried in the Action-info header information.
  • the specific message format can be: CLIENT->SERVER: RECORD rtsp: ⁇ server.example.com/movie RTSP/2.0
  • the client can initiate a request to restart recording.
  • the extended RTSP record method carries the recording mode parameter information, and the client requests the server to restart recording.
  • the recording mode mode in the Action-info header information is overwritten with "overwrite", indicating that the new recording will be stored in such a way as to overwrite the original recording.
  • Step 404 The server receives the recording service request message, and stops the ongoing recording. Resume recording from the current point in time.
  • the recording mode mode value is overwritten "overwrite", and Sever determines that the recording operation is restarted.
  • the recording service request message may also carry other recording function information, such as a recording content identifier, a request recording duration, a request recording capacity, and a recording file storage format.
  • the server may overwrite the recorded content in the recording operation before the same session according to the session identifier session1D allocated when the RTSP session is established (that is, the recording operation in steps 401 to 402).
  • the recording in the ID identifies the location specified.
  • the Server can send a response message to restart the recording to the Client.
  • the specific message format is:
  • Step 405 The client sends a stop recording request message to the server, indicating that the recording is stopped.
  • the specific message format can be:
  • the client requests the server to stop the recording in progress.
  • Step 406 After receiving the stop recording request message, the server stops the ongoing recording.
  • the Server can count the related information recorded, that is, the actual recording duration and/or actual recording capacity.
  • the server can send a response message to the client to stop the recording request message to the client, and report the related information actually recorded.
  • This information reporting there are two ways to implement this information reporting: 1) Expand the statistics-info header to report the actual recording duration and actual recording capacity.
  • the specific message format can be:
  • the media content of 3000s is actually recorded according to the indication of the Statistics-info header information, and the size is 2000 KB.
  • FIG. 5 it is a schematic structural diagram of a system for implementing a recording service according to an embodiment of the present invention.
  • the system may include: a client 501, configured to send a recording service to a server. Requesting, the recording service request carries recording function information;
  • the server 502 is configured to receive the recording service request, and perform a recording service operation according to the recording function information.
  • FIG. 6 is a schematic structural diagram of a server 502 according to an embodiment of the present invention.
  • the server 502 may include:
  • the first receiving unit 601 is configured to receive a recording service request sent by the client 501, where the recording service request carries the recording function information;
  • the recording unit 602 is configured to perform a recording service operation according to the recording function information.
  • the recording unit may further include at least one of the first recording unit 6021, the second recording unit 6022, and the third recording unit 6023.
  • the first recording unit 6021 is configured to start recording after receiving the recording service request, and save the obtained media content to be recorded in the location specified by the recording content identifier.
  • the second recording unit 6022 is configured to stop the ongoing recording operation after receiving the recording service request, and start re-recording from the current time point, The obtained media content to be recorded is saved in the previous recording position, overwriting the original recording content.
  • the third recording unit 6023 is configured to resume the recording from the current time point after receiving the recording service request, and the acquired media to be recorded is obtained. The content is additionally saved after the previous recording.
  • the server 502 can further include the following units:
  • the upper unit 603 is configured to send a recording completion request to the client after the recording unit is completed, and the request includes the recording result.
  • the second receiving unit 604 is configured to receive a cancel recording request sent by the client, and the canceling unit 605 is configured to: when receiving the cancel recording request, stop the recording operation being performed by the recording unit, and delete the already recorded content.
  • the third receiving unit 606 is configured to receive a pause recording request sent by the client, and the suspension unit 607 is configured to pause the recording operation being performed by the recording unit after receiving the pause recording request.
  • the fourth receiving unit 608 is configured to receive a stop recording request sent by the client, and the stopping unit 609 is configured to stop the recording operation being performed by the recording unit after receiving the stop recording request.
  • the server After receiving the recording service request carrying the recording function information sent by the client, the server performs the recording service operation according to the recording function information, thereby implementing the method, system, and device for implementing the recording service provided by the foregoing embodiment of the present invention.
  • the network can record various emerging services that require network-side recording technology, such as COV services and network-side personal recording services, to meet the needs of users for various recording services.
  • the present invention can be implemented by hardware or by software plus a necessary general hardware platform. Based on such understanding, the technical solution of the present invention can be embodied in the form of a software product that can be stored in a non-volatile storage medium.
  • a computer device (may be a personal computer, server, or network device, etc.) to perform the methods described in various embodiments of the present invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Databases & Information Systems (AREA)
  • Human Computer Interaction (AREA)
  • Television Signal Processing For Recording (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Description

一种实现录制业务的方法、 装置及系统 本申请要求于 2008 年 5 月 19 日提交中国专利局， 申请号为 200810067175.9, 发明名称为 "一种实现录制业务的方法、 装置及系 统"的中国专利申请的优先权，其全部内容通过引用结合在本申请中。 技术领域
本发明实施例涉及通信领域， 尤其涉及一种实现录制业务的方 法、 装置及系统。 背景技术
随着多媒体技术的发展， 业界提出了网络侧录制的概念， 指的是 由网络来记录用户要录制的媒体内容。 其中， 要录制的媒体内容的来 源，可以是广播节目，也可以是点播节目，甚至是用户自己的视频等。 该技术对于用户来说， 可以为用户带来很多好处， 如减少录制业务对 用户终端的依赖， 扩展存储空间等。
在现有的客户端和服务器端架构下，客户端和服务器端都可以发 出请求， 通过 IP ( Internet Protocol, 互联网协议 ) 网络实现双向的实 时数据传输， 如音频与视频文件的双向传输。客户端可以将用户对媒 体流的播放、 暂停、 快进、 快退等控制请求发送到服务器端， 服务器 端根据具体的操作请求经过相应处理后， 为用户播放指定的媒体内 容， 并在播放过程中根据用户的控制请求执行相应操作。 但是， 在客 户端和服务器端架构下，如何根据客户端和服务器端的信息交互实现 网络侧录制， 目前尚未有完善的解决方案。
发明内容
本发明实施例提供一种实现录制业务的方法、 装置及系统， 以实 现在客户端和服务器端架构下的网络侧录制。 为达到上述目的， 本发明实施例所提供的实现录制业务的方法， 包括：
服务器端接收客户端发送的录制业务请求，所述录制业务请求携 带录制功能信息；
服务器端根据所述录制功能信息进行录制业务操作。
本发明实施例所提供的一种服务器， 包括：
第一接收单元， 用于接收客户端发送的录制业务请求， 所述录制 业务请求携带录制功能信息；
录制单元， 用于根据所述录制功能信息进行录制业务操作。 本发明实施例所提供的一种实现录制业务的系统， 包括： 客户端， 用于向服务器端发送录制业务请求， 所述录制业务请求 携带录制功能信息；
服务器端， 用于接收所述录制业务请求， 根据所述录制功能信息 进行录制业务操作。
与现有技术相比， 本发明实施例提供的实现录制业务的方法、 系 统及装置，在接收到客户端发送的携带录制功能信息的录制业务请求 后， 服务器端根据该录制功能信息进行录制业务操作， 从而实现了在 客户端和服务器端架构下的网络侧录制。 附图说明
图 1为本发明一个实施例中实现录制业务方法的示例性流程图； 图 2为本发明一个实施例中的方法流程图；
图 3为本发明另一个实施例的方法流程图；
图 4为本发明再一个实施例的方法流程图；
图 5为本发明实施例实现录制业务的系统的结构示意图； 图 6为本发明实施例中服务器端的结构示意图。 具体实施方式 下面先介绍本发明实施例的一个应用场景， RTSP ( Real Time Streaming Protocol , 实时流协议 )是应用层协议， 控制实时数据的传 送。 它提供了一个可扩展框架， 实现实时数据（如音频与视频文件） 的受控和按需传送。
该协议可以用于在客户端和服务器端建立和协商实时流会话。根 据该协议的要求， 客户端的任务是将用户的请求提交给服务器端， 并 将服务器端返回的结果以特定的形式显示给用户；而服务器端则负责 接收客户端提出的服务请求， 进行相应的处理， 再将结果返回给客户 端。 基于该模型， 客户端和服务器端都可以发出请求， 实现了双向的 数据传输。
参见图 1 , 图 1为本发明一个实施例中实现录制业务的方法的示 例性流程图。 如图 1所示， 该流程包括：
步骤 101、 服务器端接收客户端发送的录制业务请求， 该录制业 务请求携带录制功能信息。
录制功能信息可以包括以下信息之一或其组合： 录制内容标识、 录制模式信息、 请求录制时长、 请求录制容量及录制文件存储格式。 其中， 录制内容标识用来指示被录制内容的物理存放位置； 录制模式 信息表示对于指定的录制内容进行录制时的保存方式， 如， 可以是覆 盖之前的录制内容， 也可以是追加在之前的录制内容的后面； 请求录 制时长表示本次录制请求录制的时间长短；请求录制容量表示本次录 制请求录制的容量大小； 录制文件存储格式表示文件的存储格式， 如
3gp格式、 wav格式等。
可以通过对现有的 RTSP ( Real Time Streaming Protocol , 实时流 传输协议）协议的扩展来实现上述对录制功能信息的表示， 当然也可 以通过其他方式来达到这种表示效果。 需要说明的是， 本发明的实施 例中对协议的扩展只是一个具体的示例，其中提到的消息名及参数名 等亦可取其他名称。以下是 RTSP header及录制功能信息参数的扩展。
扩展一个动作信息头 Action-info,可以包含下面的录制功能信息 描述： 1、 录制内容的标识 RecURL: 该标识可以由客户端指定， 也可 以由服务器端分配。在客户端发送的录制业务请求中，如果 RecURL= 空标识（如 $ ) 时 （当然也可以设定为其他特殊标识， 只要是客户端 和服务器约定好的即可）， 表明该标识将由服务器端进行分配， 正常 开始录制时需要包含该参数，恢复录制、重新开始录制时该参数可选。
2、 录制模式 mode: 取值可以为 overwrite或 append等, 分另 ll表 示覆盖方式和追力口方式, 示列： mode="overwrite'7" append"„ 该参数 可选
Figure imgf000006_0001
5、 录制文件的存储格式 format: 如 3gp格式、 wav格式等。 示 例： format="wav", 该参数可选。
下面是录制业务请求中采用上述扩展方法携带录制功能信息的 一个示例：
Action-info: RecURL="http://foo.com/test.wav";
recdur=3000; mode="overwrite"； format="wav" 步骤 102、 服务器端根据录制业务请求携带的录制功能信息进行 录制业务操作。
根据录制业务请求中携带的录制功能信息不同，服务器可以进行 不同的操作：
1、 正常开始录制： 指一般的录制开始， 录制功能信息可以包括： 录制内容标识， 也可进一步包括请求录制时长、请求录制容量及录制 文件存储格式中一个或组合。
对于正常开始录制， 服务器端在接收到录制业务请求后， 服务器 端开始录制，将获取到的所要录制的媒体内容保存在录制内容标识所 指定的位置。如果客户端发送的录制业务请求中的录制内容标识为空 标识， 则服务器端在接收到请求后， 为会话分配录制内容标识， 并可 以在向客户端返回的开始录制请求响应消息中携带服务器端所分配 的录制内容标识。当然，对于不是服务器端分配录制内容标识情况下 , 也可以在服务器的响应消息中携带录制内容标识表示确认。
2、 重新开始录制： 指停止正在进行的录制， 已经录制的内容将 被重新录制的内容覆盖。 录制功能信息可以包括： 录制模式信息， 还 可进一步包括： 录制内容标识、 请求录制时长、 请求录制容量及录制 文件存储格式中一个或组合。 录制模式信息具体可以为覆盖方式。
对于重新开始录制， 在接收到所述录制业务请求后， 服务器端停 止正在进行的录制操作， 从当前时间点开始重新录制， 将获取到的所 要录制的媒体内容保存在在前录制的录制位置， 覆盖原有的录制内 谷。
3、 恢复录制： 该操作将录制业务的状态由暂停转换为录制， 恢 复录制后录制的内容将追加存储在暂停时保存的内容之后。录制功能 信息可以包括： 录制模式信息， 还可进一步包括： 录制内容标识、 请 求录制时长、请求录制容量及录制文件存储格式中一个或组合。 录制 模式信息具体可以为追加方式。
对于恢复录制， 在接收到所述录制业务请求后， 服务器端从当前 时间点开始恢复录制，将获取到的所要录制的媒体内容追加保存在在 前录制内容之后。
对于重新开始录制和恢复录制而言，在录制业务请求中录制内容 标识不是必须携带的。 由于在 RTSP会话建立时， 系统即分配了会话 标识 sessionID, 标识一个唯一的会话。 录制过程中， 服务器端保持 该 sessionID状态， 每次的录制控制操作都和该 ID关联， 所以对于重 新开始录制， 在不重新声明后续录制的内容覆盖在哪里时， 服务器可 以根据 sessionID将录制的内容覆盖保存在之前录制操作中的录制内 容标识所指定的位置， 本次录制与之前的录制操作应属于同一会话； 同理， 对于恢复录制， 在不重新声明后续录制的内容追加在哪里时， 服务器端可以根据 sessionID将录制的内容追加保存之前录制操作中 的录制内容标识所指定的位置，本次录制与之前的录制操作应属于在 同一会话。当然如果录制业务请求中携带录制内容标识，也是可以的： 对于重新开始录制，服务器端将把获取到的所要录制的媒体内容保存 在该录制内容标识所指定的录制位置， 覆盖原有的录制内容； 对于恢 复录制，服务器端将把获取到的所要录制的媒体内容追加保存在该录 制内容标识所指定的录制位置， 追加在之前录制的内容之后。
以上几种录制中， 如果录制功能信息进一步包括请求录制时长、 请求录制容量及录制文件存储格式中一个或其组合，则服务器端在收 到录制业务请求后， 有以下操作：
当录制功能信息包括请求录制时长时，服务器端在录制的时间长 度达到该请求录制时长时， 停止录制操作；
当录制功能信息包括请求录制容量时，服务器端在录制的存储容 量达到该请求录制容量时， 停止录制操作；
当录制功能信息包括所述录制文件存储格式时，服务器端将获取 到的所要录制的媒体内容按照该录制文件存储格式保存。
可以通过对现有的 RTSP协议的扩展来实现录制操作：
扩展录制方法 record, 通过携带不同的参数信息， 完成不同的录 制操作。 如： 使用录制模式参数 mode可以实现重新开始录制或恢复 录制操作的指示。 如前所述， 录制过程中， 客户端发起重新开始录制 请求时， 可以通过 record方法携带录制模式参数进行指示， 此时录制 模式参数的取值为覆盖。 对于暂停后进行恢复录制的操作， 可以通过 record方法携带录制模式参数进行指示， 此时录制模式参数的取值为 追力口。
在服务器端完成录制后，服务器端可以向客户端发送录制完成请 求， 该请求包括录制结果。 录制结果可以是录制成功完成， 也可以是 录制失败完成。录制成功完成，指服务器端录制达到请求录制的时长， 和 /或达到请求录制的容量等。 录制失败完成， 指服务器端内部错误， 和 /或服务器端存储空间不足等。 当录制结果为录制成功完成时， 该 录制完成请求包括： 录制完成相关信息， 如， 实际录制时长和 /或实 际录制容量； 当录制结果为录制失败完成时， 该录制完成请求包括： 录制失败的原因。 可以通过对现有的 RTSP 协议的扩展来实现上报完成情况的功
1、对于录制结果的上报，可以通过对 RTSP ANNOUNCE方法中 的事件进行扩展实现， 如扩展事件类型 4001 Record-success Completed表示录制成功完成， 4002 Record-fail Completed表示录制 失败完成， 这样在录制完成时， 服务器端便可通告录制完成事件。
录制成功完成时， 事件类型为 4001 Record-success Completed, 具体示例可以如下描述：
Event- type: 4001 Record-success Completed
Statistics-info: actualdur: 3000
actualsize: 2000
录制失败完成时， 事件类型为 4002 Record-fail Completed, 可以 扩展以下错误码用以说明失败的原因：
0 服务器端空间不足
1 服务器端内部错误 示例： Event-type :4002 Record-fail Completed 0
以上表示录制失败完成， 失败的原因是服务器端空间不足。
2、 对于在录制成功时， 录制完成相关信息的表示方法有很多， 这里举两种扩展方法：
1 )扩展参数描述， 用于录制成功完成时服务器端对于实际录制 的时长 (s) actualdur和 /或实际录制的容量 actualsize(KB)信息的指示。 以上参数可包含在 RTSP 消息的实体部分。 在使用时， 需要先指定 RTSP消息中的 Content-type和 Content-length头信息， 然后以文本形 式描述参数信息。
2 )扩展一个统计信息头 statistics-info: 在录制成功完成时， 指示 实际录制的时长 (s) actualdur 和 /或实际录制的容量 actualsize(KB)信 息。 示例描述如下：
Statistics-info: actualdur: 3000 actualsize: 2000
对于服务器端根据录制业务请求开始录制后，可以取消正在进行 的录制。 服务器端接收到客户端发送的取消录制请求， 停止正在进行 的录制操作， 并删除已经录制的内容。
可以通过对现有的 RTSP协议的扩展来实现取消录制功能： 扩展 取消录制的方法 cancel, 该方法可以实现停止正在进行的录制， 删除 已经录制的媒体内容。
对于服务器端根据录制业务请求开始录制后，可以暂停正在进行 的录制。 服务器端接收到客户端发送的暂停录制请求， 暂停正在进行 的录制操作。 同样， 可以通过对现有的 RTSP协议的扩展来实现暂停 录制功能： 扩展暂停录制的方法 halt, 该方法可以实现暂停正在进行 的录制操作。 例如， 为了节省网络空间， 可以在有广告内容时， 进行 录制的暂停， 广告过后， 进行录制的恢复。 暂停后， 录制的恢复可以 参见上述的恢复录制操作。
对于服务器端根据录制业务请求开始录制后，可以停止正在进行 的录制。 服务器端接收到客户端发送的停止录制请求， 停止正在进行 的录制操作， 服务器端可以向客户端发送停止录制请求响应消息， 该 消息中可以携带录制统计相关信息， 即实际录制时长和 /或实际录制 谷里。
可以通过对现有的 RTSP协议的扩展来实现停止录制功能： 扩展 停止录制的方法 stop, 该方法可以实现停止正在进行的录制操作。 停 止录制时， 已经录制的内容保存在录制业务请求中指定的或服务器端 分配的录制内容标识所指定的位置。 录制完成相关信息的表示方法， 可以参考前面录制成功完成时的相关协议扩展方法。
可见，由于在接收到客户端发送的携带录制功能信息的录制业务 请求后， 服务器端根据该录制功能信息进行录制业务操作， 从而实现 了在客户端和服务器端架构下的网络侧录制，进一步，可以实现 COV ( Consumer Originated Video , 消费者发起录制） 业务、 N-PVR ( Network Personal Video Recorder , 网络侧个人录制业务）等需要网 络侧录制技术的各种新兴业务， 满足用户对于各种录制业务的需求。 下面通过具体实施例对上述方案作进一步详细说明。需要说明的 是： 以下实施例中的 Client即 RTSP的客户端， Server即 RTSP的服 务器端。
本发明一个具体实施例：
本实施例中， 在 Client和 Server之间已经建立了 RTSP会话， 并 且 Server 已经获取到所要录制的媒体内容。 用户先请求开始正常录 制， 在录制过程中发现录制内容不合其要求， 取消录制。
如图 2所示， 为本实施例的方法流程图。
步骤 201、 Client向 Server发送录制业务请求消息， 指示开始录 制。
通过扩展的 RTSP RECORD方法以及 Action-info头信息， 客户 端请求服务器端开始录制操作。 其中携带了一些录制功能信息： 录制 内容标识信息 http://Mserver/rec.ord/aa.wav ,表示将把指定录制内容存 储在该位置。 同时还携带了请求录制的时长 3000s, 当然也可携带请 求录制的容量和录制文件存储格式参数信息， 这里没有示出。
具体的消息可以如下所示：
Client->Server: RECORD rtsp：〃 server.example.com/movie
RTSP/2.0
CSeq: 455
Session: 12345678
Action-info:
RecURL="http://Mserver/record/aa.wav"；
recdur=3000
如果 Action-ifno头中的录制内容的标识 RecURL="$" ,那么该标 识将由服务器端进行分配， 然后上报给客户端。
步骤 202、 Server收到录制业务请求消息， 开始录制。
根据录制业务请求消息中携带的录制功能信息， Server判断出为 正常开始录制操作， 便开始录制。 Server可以发送开始录制的响应消 息给 Client。
本步骤中也可以在响应消息中携带录制内容标识，该标识和请求 消息中指定的相同。 响应消息的格式具体可以为：
SERVER -> CLIENT: RTSP/2.0 200 OK
CSeq: 455
RecURL: "http:/ server/record/aa.wav" 如果步骤 201中录制内容标识 RecURL="$ "时， 则由 Sever分配 录制内容标识， 并通过响应消息中的 RecURL头上报给 Client。 相应 的步骤 202的消息格式示例为：
SERVER -> CLIENT: RTSP/2.0 200 OK
CSeq: 455
RecURL: "httpJ/I iserver/record/bb.wav" 上述响应消息表明服务器端完成了录制内容标识的分配，录制的 内容将保存在" http://Mserver/record/bb.wav"指定的位置。
在录制业务请求消息中也可以指定录制开始的时间点， Server将 在该时间点开始录制。
在开始录制后， 用户发现录制的内容不符合其要求， 决定取消录 制。
步骤 203、 Client发送取消录制请求消息给 Server, 指示取消录 制。
相应的消息格式示例为：
CLIENT->SERVER: CANCEL rtsp：〃 server.example.com/movie RTSP/2.0
CSeq: 1
Session: 12345678
通过扩展的 RTSP cancel方法， 客户端请求服务器端取消正在进 行的录制。
步骤 204、 Server停止录制， 并删除已经录制的部分内容。
Server可以发送取消录制请求的响应消息给 Client。 具体的消息格式可以为：
SERVER->CLIENT: RTSP/2.0 200 OK
CSeq: 1
可以看到， 对于用户的正常开始录制及取消录制的请求， 通过本 实施例的流程可以有效地进行操作， 实现各种录制业务。
本发明另一个具体实施例：
本实施例中， 在 Client和 Server之间已经建立了 RTSP会话， 并 且 Server 已经获取到所要录制的媒体内容。 用户先请求开始正常录 制，为了避开节目中的广告，暂停了录制，广告结束后又恢复了录制， 网络侧录制完成后， 反馈录制结果。 录制结果可能为录制成功完成， 如在达到请求录制的时长 3000s后， 网络侧停止了录制， 并反馈录制 完成相关信息， 如， 实际录制时长和 /或实际录制容量； 录制结果可 能为录制失败完成， 这时网络侧反馈录制失败的原因。
如图 3所示， 为本实施例的方法流程图。
步骤 301、 Client向 Server发送录制业务请求消息， 指示开始录 制。
通过扩展的 RTSP RECORD方法以及 Action-info头信息， 客户 端请求服务器端开始录制操作。 其中携带了一些录制功能信息： 录制 内容标识信息 http://Mserver/rec(3rcl/aa.wav,表示将把指定录制内容存 储在该位置。 同时还携带了请求录制的时长 3000s, 当然也可携带请 求录制的容量和录制文件存储格式参数信息， 这里没有示出。
具体的消息可以如下所示：
Client->Server: RECORD rtsp：〃 server.example.com/movie
RTSP/2.0
CSeq: 455
Session: 12345678
Action-info:
RecURL="http:/ server/record/aa.wav"；
recdur=3000 步骤 302、 Server收到录制业务请求消息， 开始录制。
根据录制业务请求消息中携带的录制功能信息， Sever判断出为 正常开始录制操作， 便开始录制。 Server可以发送开始录制的响应消 息给 Client。
本步骤中也可以在响应消息中携带录制内容标识，该标识和请求 消息中指定的相同。 响应消息的格式具体可以为：
SERVER -> CLIENT: RTSP/2.0 200 OK
CSeq: 455
RecURL: "http://Mserver/record/aa.wav" 在录制业务请求消息中也可以指定录制开始的时间点， Server将 在该时间点开始录制。
步骤 303、 Client发送暂停录制请求消息给 Server, 指示暂停录 制。
消息的格式具体可以为：
CLIENT- >SERVER： HALT rtsp：〃 server.example.com/movie
RTSP/2.0
CSeq: 4
Session: 12345678
通过扩展的 RTSP halt方法， 客户端请求服务器端进行暂停录制 的操作。
步骤 304、 Server暂停了正在进行的录制。
Server可以发送暂停录制请求的响应消息给 Client。
消息的格式具体可以为：
SERVER->CLIENT: RTSP/2.0 200 OK
CSeq: 4
步骤 305、 Client发送录制业务请求消息给 Server, 指示从当前 时间点开始， 继续录制。
通过扩展的 RTSP record方法及 Action-info头信息中携带的录制 模式参数信息指示进行暂停后的恢复录制操作。具体的消息格式可以 为：
CLIENT->SERVER: RECORD rtsp：〃 server.example.com/movie RTSP/2.0
CSeq: 5
Session: 12345678
Action-info: mode="append"
通过扩展的 RTSP record 方法携带的录制模式信息指示恢复录 制。 Action-info头信息中的录制模式 mode取值为追加" append" , 表 示接下来要录制的内容将追加在之前录制的内容后面进行存储。
步骤 306、 Server收到录制业务请求消息， 从当前时间点开始进 行恢复录制操作。
根据录制业务请求消息中携带的录制功能信息： 录制模式 mode 取值为追加" append", Server判断出为恢复录制操作。
由于录制业务请求消息中没有携带录制内容标识，服务器端可以 根据在 RTSP会话建立时分配的会话标识 sessionlD将录制的内容追 加保存在同一会话的之前录制操作 (也就是步骤 301 ~步骤 302的录 制操作 ) 中的录制内容标识所指定的位置。
Server可以发送恢复录制的响应消息给 Client。 具体的消息格式 为：
SERVER->CLIENT: RTSP/2.0 200 OK
CSeq: 5
步骤 307、 录制完成， Server向 Client发送录制完成的请求消息。 如前所述， 该请求通过扩展的 RTSP ANNOUNCE方法来实现。 当实际录制的时长达到请求录制的时长 3000s时，录制成功完成， 录制完成的请求消息中包含录制完成相关信息， 即实际录制时长和 / 或实际录制容量。 对于实际录制的相关信息的上报， 如上所述， 可以 有两种实现方法：
1 )扩展 statistics-info头， 用于 Server在录制成功完成时， 报告 如实际录制的时长 /容量信息。 具体的消息格式可以为： SERVER- >CLIENT:ANNOUNCE rtsp：〃 server.example.com/movie RTSP/2.0
CSeq: 457
Session: 12345678
Event- Type: 4001 Record-success Completed Statistics-info: actualdur: 3000
actualsize: 2000
通过扩展事件类型 4001 录制成功完成事件， Server通告录制完 成， 并且根据 Statistics-info头信息， 指示实际录制了 3000s的媒体内 容， 大小为 2000KB。
2 )扩展参数描述， 通过在消息的实体部分携带文本参数描述信 息， 上报实际录制的时长 /容量。 具体的消息格式可以为：
SERVER- >CLIENT:ANNOUNCE rtsp：〃 server.example.com/movie RTSP/2.0
CSeq: 457
Session: 12345678
Event- Type: 4001 Record-success Completed Content-Type: text/parameters
Content-Length: 1000
Actualdur: 3000
Actualsize: 2000
同样， 通过扩展事件类型 4001 录制成功完成事件， Server通告 录制完成， 通过扩展的文本参数信息， 实际录制的时长、 实际录制的 容量在实体部分进行描述， 4艮告 Client录制成功完成时，录制了 3000s 的媒体内容， 大小为 2000KB。
当由于服务器端内部错误或服务器端存储空间不足等原因致使 录制失败完成， 录制完成的请求消息具体可以如下：
SERVER->CLIENT:ANNOUNCE
rtsp://mediaserver/rec/exaServerle.3gp RTSP/2.0 CSeq: 457
Session: 12345678
Event- Type: 4002 Record-fail Completed 1 事件类型为 4002 录制失败完成事件， "1" 可以指示本次录制失 败的原因是服务器端内部的错误。
步骤 308、 Client接收到录制完成的请求消息后， 可以发送录制 完成的响应消息给 Server。 具体的消息格式可以如下所述：
CLIENT->SERVER: RTSP/2.0 200 OK
CSeq: 457
可以看到， 对于录制过程中的正常开始录制、 暂停、 恢复录制及 录制完成， 通过本实施例的流程可以有效地进行操作， 实现各种录制 业务。
本发明的再一个实施例：
本实施例中， 在 Client和 Server之间已经建立了 RTSP会话， 并 且 Server 已经获取到所要录制的媒体内容。 用户先请求开始正常录 制， 录制过程中用户重新开始了录制， 并在录制到需要的内容后停止 了录制。
如图 4所示， 为本实施例的方法流程图。
步骤 401、 Client向 Server发送录制业务请求消息， 指示开始录 制。
通过扩展的 RTSP RECORD方法以及 Action-info头信息， 客户 端请求服务器端开始录制操作。 其中携带了一些录制功能信息： 录制 内容标识信息 http://Mserver/rec(3rcl/aa.wav,表示将把指定录制内容存 储在该位置。 同时还携带了请求录制的容量 2000KB。
具体的消息可以如下所示：
Client->Server: RECORD rtsp：〃 server.example.com/movie
RTSP/2.0
CSeq: 455
Session: 12345678 Action-info:
RecURL="http:/ server/record/aa.wav"；
recsize=2000
步骤 402、 Server收到录制业务请求消息， 开始录制。
根据录制业务请求消息中携带的录制功能信息， Sever判断出为 正常开始录制操作， 便开始录制。 Server可以发送开始录制的响应消 息给 Client。
本步骤中也可以在响应消息中携带录制内容标识，该标识和请求 消息中指定的相同。 响应消息的格式具体可以为：
SERVER -> CLIENT: RTSP/2.0 200 OK
CSeq: 455
RecURL: "http:/ server/record/aa.wav" 在录制业务请求消息中也可以指定录制开始的时间点， Server将 在该时间点开始录制。
步骤 403、 Client发送录制业务请求消息给 Server, 指示从当前 时间点开始， 重新开始录制。
通过扩展的 RTSP record方法及 Action-info头信息中携带的录制 模式参数信息指示进行重新开始录制操作。 具体的消息格式可以为： CLIENT->SERVER: RECORD rtsp：〃 server.example.com/movie RTSP/2.0
CSeq: 6
Session: 12345678
Action-info: mode="overwrite"
正在录制的过程中， 客户端可以发起重新开始录制的请求。
通过扩展的 RTSP record方法携带录制模式参数信息， 客户端请 求服务器端重新开始录制。 Action-info头信息中的录制模式 mode取 值为覆盖 "overwrite" , 表示新的录制内容将以覆盖原有的录制内容 的方式进行存储。
步骤 404、 Server收到录制业务请求消息，停止正在进行的录制， 从当前时间点重新开始录制。
根据录制业务请求消息中携带的录制功能信息： 录制模式 mode 取值为覆盖 "overwrite" , Sever判断出为重新开始录制操作。
当然， 该录制业务请求消息中还可以携带其他录制功能信息， 如 录制内容标识、请求录制时长、请求录制容量及录制文件存储格式等。
当录制业务请求消息中没有携带录制内容标识，服务器端可以根 据在 RTSP会话建立时分配的会话标识 sessionlD将录制的内容覆盖 保存在同一会话之前的录制操作 (也就是步骤 401 ~步骤 402的录制 操作 ) 中的录制内容标识所指定的位置。
Server可以发送重新开始录制的响应消息给 Client。 具体的消息 格式为：
SERVER->CLIENT: RTSP/2.0 200 OK
CSeq: 6
步骤 405、 Client发送停止录制请求消息给 Server, 指示停止录 制。
具体的消息格式可以为：
CLIENT->SERVER: STOP rtsp：〃 server.example.com/movie
RTSP/2.0
CSeq: 2
Session: 12345678
通过扩展的 RTSP stop方法， 客户端请求服务器端停止正在进行 的录制。
步骤 406、 Server接收到停止录制请求消息后， 停止正在进行的 录制。
Server可以统计录制的相关信息，即实际录制的时长和 /或实际录 制容量。
Server可以向 Client发送停止录制请求消息的响应消息给 Client, 同时报告实际录制的相关信息。 如前所述， 该信息的上报可以有两种 实现方法： 1 )扩展 statistics-info头， 报告实际录制的时长和实际录制容量。 具体的消息格式可以为：
SERVER->CLIENT: RTSP/2.0 200 OK
CSeq:2
Statistics-info: actualdur: 3000
Actualsize: 2000
停止录制时，根据 Statistics-info头信息的指示，实际录制了 3000s 的媒体内容， 大小为 2000KB。
2 )扩展参数描述， 通过在实体部分携带文本参数描述信息， 上 报实际录制的时长和实际录制容量。 具体的消息格式可以为：
SERVER->CLIENT: RTSP/2.0 200 OK
CSeq:2
Content-Type: text/parameters
Content-Length: 40
Actualdur: 3000
Actualsize: 2000
停止录制时， 实际录制了 3000s的媒体内容， 大小为 2000KB。 可以看到， 对于录制过程中的正常开始录制、 重新开始录制及停 止录制， 通过本实施例的流程可以有效地进行操作， 实现各种录制业 务。
下面介绍本发明实施例中的系统及装置实施例， 请参阅图 5 , 为 本发明实施例实现录制业务的系统的结构示意图， 该系统可以包括： 客户端 501 , 用于向服务器端发送录制业务请求， 所述录制业务 请求携带录制功能信息；
服务器端 502, 用于接收所述录制业务请求， 根据所述录制功能 信息进行录制业务操作。
图 6为本发明实施例中服务器端 502的结构示意图，如图 6所示， 该服务器 502可以包括： 第一接收单元 601 , 用于接收客户端 501发送的录制业务请求， 该录制业务请求携带录制功能信息；
录制单元 602, 用于根据该录制功能信息进行录制业务操作。 录制单元进一步可以包括第一录制单元 6021、 第二录制单元 6022及第三录制单元 6023中至少一个。
当录制功能信息包括录制内容标识时， 第一录制单元 6021用于 在接收到录制业务请求后， 开始录制， 将获取到的所要录制的媒体内 容保存在该录制内容标识所指定的位置。
当录制功能信息包括录制模式信息，且该录制模式信息为覆盖方 式时， 第二录制单元 6022用于在接收到录制业务请求后， 停止正在 进行的录制操作， 从当前时间点开始重新录制， 将获取到的所要录制 的媒体内容保存在在前的录制位置， 覆盖原有的录制内容。
当录制功能信息包括录制模式信息，且该录制模式信息为追加方 式时， 第三录制单元 6023用于在接收到录制业务请求后， 从当前时 间点开始恢复录制，将获取到的所要录制的媒体内容追加保存在在前 录制内容之后。
该服务器 502进一步可以包括以下单元：
上才艮单元 603 , 用于在录制单元录制完成后， 向客户端发送录制 完成请求， 该请求包括录制结果。
第二接收单元 604, 用于接收客户端发送的取消录制请求； 取消 单元 605 , 用于在接收到该取消录制请求， 停止录制单元正在进行的 录制操作， 并删除已经录制的内容。
第三接收单元 606, 用于接收客户端发送的暂停录制请求； 暂停 单元 607, 用于在接收到该暂停录制请求， 暂停录制单元正在进行的 录制操作。
第四接收单元 608, 用于接收客户端发送的停止录制请求； 停止 单元 609, 用于在接收到该停止录制请求， 停止录制单元正在进行的 录制操作。 通过本发明上述实施例提供的实现录制业务的方法、 系统及装 置， 在接收到客户端发送的携带录制功能信息的录制业务请求后， 服 务器端根据该录制功能信息进行录制业务操作，从而实现了在客户端 和服务器端架构下的网络侧录制， 进一步， 可以实现 COV业务、 网 络侧个人录制业务等需要网络侧录制技术的各种新兴业务，满足用户 对于各种录制业务的需求。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解 到本发明， 可以通过硬件实现， 也可以借助软件加必要的通用硬件平 台的方式来实现。基于这样的理解， 本发明的技术方案可以以软件产 品的形式体现出来， 该软件产品可以存储在一个非易失性存储介质
(可以是 CD-ROM, U盘， 移动硬盘等） 中， 包括若干指令用以使 得一台计算机设备（可以是个人计算机， 服务器， 或者网络设备等） 执行本发明各个实施例所述的方法。
总之， 以上所述仅为本发明的较佳实施例而已， 并非用于限定本 发明的保护范围。 凡在本发明的精神和原则之内所作的任何修改、 等 同替换、 改进等， 均应包含在本发明的保护范围之内。

Claims

权利要求
1、 一种实现录制业务的方法， 其特征在于， 该方法包括： 服务器端接收客户端发送的录制业务请求，所述录制业务请求携 带录制功能信息；
服务器端根据所述录制功能信息进行录制业务操作。
2、 如权利要求 1所述的方法， 其特征在于， 所述录制功能信息 包括录制内容标识；
所述服务器端根据所述录制功能信息进行录制业务操作包括：在 接收到所述录制业务请求后， 服务器端开始录制， 将获取到的所要录 制的媒体内容保存在所述录制内容标识所指定的位置。
3、 如权利要求 2所述的方法， 其特征在于， 所述录制内容标识 为空标识；
所述在接收到所述录制业务请求后进一步包括：服务器端为会话 分配录制内容标识。
4、 如权利要求 2或 3所述的方法， 其特征在于， 所述服务器端 开始录制之后进一步包括：服务器端向客户端返回录制业务请求响应 消息， 所述消息携带所述录制内容标识。
5、 如权利要求 1或 2所述的方法， 其特征在于， 所述录制功能 信息包括录制模式信息。
6、 如权利要求 5所述的方法， 其特征在于， 所述录制模式信息 为覆盖方式；
所述服务器端根据所述录制功能信息进行录制业务操作包括：在 接收到所述录制业务请求后， 服务器端停止正在进行的录制操作， 从 当前时间点开始重新录制，将获取到的所要录制的媒体内容保存在在 前录制的录制位置， 覆盖原有的录制内容。
7、 如权利要求 5所述的方法， 其特征在于， 所述录制模式信息 为追加方式；
所述服务器端根据所述录制功能信息进行录制业务操作包括：在 接收到所述录制业务请求后， 服务器端从当前时间点开始恢复录制， 将获取到的所要录制的媒体内容追加保存在在前录制内容之后。
8、 如权利要求 2、 3或 6所述的方法， 其特征在于， 所述录制功 能信息进一步包括以下信息中的至少一个： 请求录制时长、请求录制 容量及录制文件存储格式；
当录制功能信息包括所述请求录制时长时，所述服务器端根据所 述录制功能信息进行录制业务操作包括：服务器端在录制的时间长度 达到所述请求录制时长时， 停止录制操作；
当录制功能信息包括所述请求录制容量时，所述服务器端根据所 述录制功能信息进行录制业务操作包括：服务器端在录制的存储容量 达到所述请求录制容量时， 停止录制操作；
当录制功能信息包括所述录制文件存储格式时，所述服务器端根 据所述录制功能信息进行录制业务操作包括：服务器端将获取到的所 要录制的媒体内容按照所述录制文件存储格式保存。
9、 如权利要求 1至 3或 6至 7任意一项所述的方法， 其特征在 于，所述服务器端根据所述录制功能信息进行录制业务操作之后进一 步包括： 录制完成， 所述服务器端向客户端发送录制完成请求， 所述 请求包括录制结果。
10、 如权利要求 9所述的方法， 其特征在于， 所述录制结果包括 录制成功完成， 所述录制完成请求包括： 录制完成相关信息， 所述录 制完成相关信息包括： 实际录制时长和 /或实际录制容量。
11、 如权利要求 9所述的方法， 其特征在于， 所述录制结果包括 录制失败完成， 所述录制完成请求包括： 录制失败的原因。
12、如权利要求 1至 3或 6至 7任意一项所述的方法， 其特征在 于，所述服务器端根据所述录制功能信息进行录制业务操作之后进一 步包括： 服务器端接收到客户端发送的取消录制请求， 停止正在进行 的录制操作， 并删除已经录制的内容。
13、如权利要求 1至 3或 6至 7任意一项所述的方法， 其特征在 于，所述服务器端根据所述录制功能信息进行录制业务操作之后进一 步包括： 服务器端接收到客户端发送的暂停录制请求， 暂停正在进行 的录制操作。
14、如权利要求 1至 3或 6至 7任意一项所述的方法， 其特征在 于，所述服务器端根据所述录制功能信息进行录制业务操作之后进一 步包括： 服务器端接收到客户端发送的停止录制请求， 停止正在进行 的录制操作。
15、 如权利要求 14所述的方法， 其特征在于， 所述服务器端接 收到客户端发送的停止录制请求之后进一步包括：服务器端向客户端 发送停止录制请求响应消息， 所述消息携带录制统计相关信息， 所述 录制统计相关信息包括： 实际录制时长和 /或实际录制容量。
16、 一种服务器， 其特征在于， 所述服务器包括：
第一接收单元， 用于接收客户端发送的录制业务请求， 所述录制 业务请求携带录制功能信息；
录制单元， 用于根据所述录制功能信息进行录制业务操作。
17、 如权利要求 16所述的服务器， 其特征在于， 所述录制功能 信息包括录制内容标识； 所述录制单元包括：
第一录制单元， 用于在接收到所述录制业务请求后， 开始录制， 将获取到的所要录制的媒体内容保存在所述录制内容标识所指定的 位置。
18、 如权利要求 16或 17所述的服务器， 其特征在于， 所述录制 功能信息包括录制模式信息， 且所述录制模式信息为覆盖方式； 所述 录制单元包括：
第二录制单元， 用于在接收到所述录制业务请求后， 停止正在进 行的录制操作， 从当前时间点开始重新录制， 将获取到的所要录制的 媒体内容保存在在前的录制位置， 覆盖原有的录制内容。
19、 如权利要求 16或 17所述的服务器， 其特征在于， 所述录制 功能信息包括录制模式信息， 且所述录制模式信息为追加方式； 所述 录制单元包括：
第三录制单元， 用于在接收到所述录制业务请求后， 从当前时间 点开始恢复录制，将获取到的所要录制的媒体内容追加保存在在前录 制内容之后。
20、 如权利要求 16或 17所述的服务器， 其特征在于， 所述服务 器进一步包括：
上报单元， 用于在所述录制单元录制完成后， 向客户端发送录制 完成请求， 所述请求包括录制结果。
21、 如权利要求 16或 17所述的服务器， 其特征在于， 所述服务 器进一步包括：
第二接收单元， 用于接收客户端发送的取消录制请求； 取消单元， 用于在接收到所述取消录制请求， 停止所述录制单元 正在进行的录制操作， 并删除已经录制的内容。
22、 如权利要求 16或 17所述的服务器， 其特征在于， 所述服务 器进一步包括：
第三接收单元， 用于接收客户端发送的暂停录制请求； 暂停单元， 用于在接收到所述暂停录制请求， 暂停所述录制单元 正在进行的录制操作。
23、 如权利要求 16或 17所述的服务器， 其特征在于， 所述服务 器进一步包括：
第四接收单元， 用于接收客户端发送的停止录制请求； 停止单元， 用于在接收到所述停止录制请求， 停止所述录制单元 正在进行的录制操作。
24、 一种实现录制业务的系统， 其特征在于， 该系统包括： 客户端， 用于向服务器端发送录制业务请求， 所述录制业务请求 携带录制功能信息；
服务器端， 用于接收所述录制业务请求， 根据所述录制功能信息 进行录制业务操作。
PCT/CN2009/071513 2008-05-19 2009-04-28 一种实现录制业务的方法、装置及系统 WO2009140888A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200810067175.9 2008-05-19
CN200810067175.9A CN101588342A (zh) 2008-05-19 2008-05-19 一种实现录制业务的方法、装置及系统

Publications (1)

Publication Number Publication Date
WO2009140888A1 true WO2009140888A1 (zh) 2009-11-26

Family

ID=41339767

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2009/071513 WO2009140888A1 (zh) 2008-05-19 2009-04-28 一种实现录制业务的方法、装置及系统

Country Status (2)

Country Link
CN (1) CN101588342A (zh)
WO (1) WO2009140888A1 (zh)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105791951A (zh) * 2014-12-26 2016-07-20 Tcl海外电子（惠州）有限公司 音视频码流的录制方法和装置
CN105516485B (zh) * 2015-12-04 2019-03-01 小米科技有限责任公司 录音方法及装置
CN107040639A (zh) * 2017-03-23 2017-08-11 申瓯通信设备有限公司 数字通信录音方法及系统
CN108270768A (zh) * 2017-11-28 2018-07-10 北京文香信息技术有限公司 一种基于rtsp/rtmp协议的单端口双向交互协议
CN108377413A (zh) * 2018-04-18 2018-08-07 深圳佳力拓科技有限公司 一种支持同时三路节目录制的机顶盒系统和方法

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1652602A (zh) * 2005-02-23 2005-08-10 乐金电子（沈阳）有限公司 利用网络的多媒体服务器系统及其服务方法
CN101068340A (zh) * 2007-06-08 2007-11-07 华为技术有限公司 节目网络录制方法和媒体处理服务器及网络录制系统
WO2007132165A1 (en) * 2006-05-04 2007-11-22 Nds Limited Scrambled digital data item
KR20080054088A (ko) * 2006-12-12 2008-06-17 정영덕 네트워크 ｐｖｒ 시스템, 네트워크 ｐｖｒ 구현방법 및이에 사용되는 ｐｖｒ 디바이스
CN101247512A (zh) * 2008-03-19 2008-08-20 天柏宽带网络科技（北京）有限公司 一种网络个人视频录制的方法和系统
CN101262583A (zh) * 2007-03-05 2008-09-10 华为技术有限公司 媒体流的录制方法、实体及系统
CN101378492A (zh) * 2007-08-27 2009-03-04 华为技术有限公司 一种实现网络录制的方法、系统及实体
CN101409659A (zh) * 2007-10-08 2009-04-15 华为技术有限公司 一种网络录制的控制方法、系统及实体
CN101409823A (zh) * 2007-10-10 2009-04-15 华为技术有限公司 一种网络个人录像机的实现方法、装置和系统

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1652602A (zh) * 2005-02-23 2005-08-10 乐金电子（沈阳）有限公司 利用网络的多媒体服务器系统及其服务方法
WO2007132165A1 (en) * 2006-05-04 2007-11-22 Nds Limited Scrambled digital data item
KR20080054088A (ko) * 2006-12-12 2008-06-17 정영덕 네트워크 ｐｖｒ 시스템, 네트워크 ｐｖｒ 구현방법 및이에 사용되는 ｐｖｒ 디바이스
CN101262583A (zh) * 2007-03-05 2008-09-10 华为技术有限公司 媒体流的录制方法、实体及系统
CN101068340A (zh) * 2007-06-08 2007-11-07 华为技术有限公司 节目网络录制方法和媒体处理服务器及网络录制系统
CN101378492A (zh) * 2007-08-27 2009-03-04 华为技术有限公司 一种实现网络录制的方法、系统及实体
CN101409659A (zh) * 2007-10-08 2009-04-15 华为技术有限公司 一种网络录制的控制方法、系统及实体
CN101409823A (zh) * 2007-10-10 2009-04-15 华为技术有限公司 一种网络个人录像机的实现方法、装置和系统
CN101247512A (zh) * 2008-03-19 2008-08-20 天柏宽带网络科技（北京）有限公司 一种网络个人视频录制的方法和系统

Also Published As

Publication number Publication date
CN101588342A (zh) 2009-11-25

Similar Documents

Publication Publication Date Title
JP5261785B2 (ja) コンテンツ配信システム、キャッシュサーバ及びキャッシュ管理サーバ
US8260947B2 (en) Media delivery arrangements including time information provided together with media data
JP5647133B2 (ja) マルチメディアセッションを再開、転送、又はコピーするための方法及びシステム
JP5022929B2 (ja) コンテンツ管理システムおよびコンテンツ管理方法
US7725557B2 (en) Client-side caching of streaming media content
KR100848128B1 (ko) 실시간 스트리밍 프로토콜을 이용한 프로그래시브 스트리밍방법
JP5536779B2 (ja) 移動体デバイス上で映像を再生するための方法及びシステム
CN102347943B (zh) 基于rtsp会话发送和接收流传输数据的方法和设备
WO2009140888A1 (zh) 一种实现录制业务的方法、装置及系统
WO2013174266A1 (zh) 一种iptv服务器和录制内容的播放方法
WO2009015611A1 (fr) Procédé, système et appareil pour une commutation rapide de source multimédia
WO2007104236A1 (en) Method of providing vedio-on-demand, method, server and terminal for video-on-demand
CN112839238B (zh) 投屏播放方法、装置和存储介质
WO2010045811A1 (zh) 流媒体业务的处理方法、装置及系统
WO2009012701A1 (en) A notification method, apparatus and system of real time streaming protocol event
WO2010057377A1 (zh) 前端设备、录像文件备份方法及其控制方法、装置及系统
JP2005244605A (ja) ストリーミングコンテンツ配信制御システム、プログラム及び該プログラムを格納した記録媒体
JP2009089019A (ja) マルチキャスト配信制御装置、コンピュータプログラム、マルチキャスト配信制御システム及びマルチキャスト配信制御方法
WO2011134258A1 (zh) 一种网络电视播放节目的录制方法、系统及终端
WO2010057391A1 (zh) 一种流媒体播放控制方法、设备及系统
WO2009092302A1 (zh) 一种录制业务的实现方法和设备
JP4809153B2 (ja) 連携コンテンツ同期ストリーミング配信サーバ、連携コンテンツ同期ストリーミング配信方法、その方法を実装したプログラム及びそのプログラムを格納した記録媒体
JP3799607B2 (ja) 情報配信システム、情報処理装置および方法、記録媒体、並びにプログラム
WO2012149868A1 (zh) 一种媒体内容分发和点播的方法、机顶盒及系统
JP2005269411A (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: 09749431

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

Country of ref document: EP

Kind code of ref document: A1