CN1471317A

CN1471317A - Burst audio-video flow transmission and reception technique for video-on-demand system

Info

Publication number: CN1471317A
Application number: CNA021253242A
Authority: CN
Inventors: 梁肇新
Original assignee: Individual
Current assignee: Individual
Priority date: 2002-07-25
Filing date: 2002-07-25
Publication date: 2004-01-28

Abstract

The key point of the invention is as follows. The server sends data only when player needs data. if sending data, the server sends it in the shortest time possibly. When a player is playing data obtained, the server will not send data to it, and the server can serve other players. Thus, each playing request uses network bandwidth in intermittent mode and burst mode. Player can plays back files on VOD server without changing architecture of players through API functions of file manipulation in hook system. Thus, the invention can use network bandwidth effectively without influencing quality of playing audio and video.

Description

Bursting audio/video flow transmission and reception technique in the video on-demand system

1 technical field

The invention belongs to the network multimedia data transmits and the broadcast field.The present invention relates to a kind of technology that on network, effectively transmits audio, and be particularly related to a kind of method that realizes video request program (hereinafter to be referred as VOD) broadcast under the situation that has the broadcast system that do not change.

2 technical backgrounds

VOD technology experience years of development, original technology has not really met new network environment.Present network forward broadband development, the first generation and second generation VOD system generally adopt User Datagram Protoco (UDP) (hereinafter to be referred as UDP) to transmit, the network environment before this method has adapted to.But under broadband network, UDP transmits data can not well save the network bandwidth; Elsewhere, the teletransmission data of UDP need the cooperation of router and fire compartment wall.Being transmitted under the broadband environment of transmission control protocol (hereinafter to be referred as TCP) can well transmit data flow, but it needs the cooperation of router and fire compartment wall equally when the teletransmission data.In fact, most routers and fire compartment wall are all opened HTML (Hypertext Markup Language) (hereinafter to be referred as HTTP) packet and port, if can adopt http protocol effectively to transmit data flow, then can make the strength with better function of VOD system, make its range of application wider.

Http protocol designs for transmitting the WEB service, if make it well transmit multimedia data stream, then must transform it.The present invention can address this problem.

3 summary of the invention

Particular content of the present invention is as follows:

● when player requests, just send the method for data;

● adopt PUT method (a kind of form of http protocol) the request audio frequency of specific form/look

The frequency program;

● video server is responded the method for player requests;

● the method for player and video server collaborative work;

● do not change and realize the method that VOD plays under the situation that has the broadcast system;

4 description of drawings

What Fig. 1 provided is the process that player sends request packet header and receiving data stream;

What Fig. 2 provided is the process of server response player requests;

What Fig. 3 provided is not change to realize the process that VOD plays under the situation that has the broadcast system.

5 embodiments

The core concept of bursting audio/video flow transmission and reception technique is: player is just request server transmission in the time will needing data, player asks to send the data block of as far as possible few (but not influencing broadcast) at every turn, and server guarantees in the shortest time corresponding data block to be sent to player.

Player adopts the PUT method of http protocol to the server requests program stream.Player is when the position of the program of the program request appointment first time and reorientation program stream, has any different slightly in information requested packet header.

Solicited message tabulation during the program of program request appointment for the first time:

● the program stream path of program request (may be virtual route)

● the program start position of program request

● the program final position of program request

● the sign of program request for the first time (sign is program request for the first time)

● program request person's account number

● program request person's password

Solicited message tabulation during the program of reorientation appointment:

● the program stream path (true path) of program request

● the program start position of program request

● the program final position of program request

● the sign of program request for the first time (sign is not program request for the first time)

● program request person's account number

● program request person's password

Because what server of the present invention adopted is bursting transmission, in order to reduce the computing expense of server, when the reorientation program stream, the program path that player is sent to server is a true path, and the sign program is the non-program request first time, like this, and after server receives request, with the name of program stream of request not being resolved again, also no longer the user is authenticated.In addition, to both requests, the processing of server is identical.

The HTTP that player sends to server asks form as follows:

CHAR?szRequestStreamHttpHeader[]＝{

" USERAGENT:HEROVODPLAY r n " ∥ player proof mark

" VODUSERIP:%u r n " ∥ user's local ip address

" PROIRITY:%u r n " sends priority when ∥ is used for reorientation

" FILMID:%u r n " ∥ film ID

" STARTPOS:%u r n " ∥ start position (starting position byte number of request)

" STOPPOS:%u r n " ∥ end position (the end position byte number of request)

" USERNAME:%s r n " ∥ user's name

" PASSWORD:%s r n " ∥ password

Whether " FIRSTPLAY:%s r n " ∥ starts

" FILMPATH:%s r n " ∥ file path

" USERLANG:%s r n " ∥ client character set

" USERSN:%u r n " ∥ user's time sequence number

" STARTTIME:%s r n "; ∥ flows the starting time, obtains from server

“\r\n”}；

Server sends the header packet information tabulation of player to:

● the program stream true path of program request

● the program start position of program request

● the length of the program of program request (byte)

● send the length of data in server stream to

● the time started of transmission

● the type of program

● the answer code of server

● the response character string of server etc.

Fig. 1 has provided the process of player requests (or heavy position) program stream and program receiving stream.This process may further comprise the steps:

● player is organized into request on the HTTP head of szRequestStreamHttpHeader form;

● player is delivered to corresponding server ((1) among Fig. 1) to this HTTP hair; If send failure,

Then this playing request stops ((4) among Fig. 1); If send successfully, then player is waited for service

The data packet head of the response fixed length of device ((2) among Fig. 1);

● if server is not got data packet head, and then this playing request stops ((4) among Fig. 1); As

Fruit is got data packet head information, the then return information of Analysis server.Comprise service in the return information

Whether device accepts information such as the name of the request of player and request data stream and size;

● if server is accepted the request of player, then can send back the information of corresponding program stream, and

And then can transmit data flow;

● player receives a blocks of data, plays then; In playing process, player no longer receives data,

Server does not transmit data to it yet; After this blocks of data had transmitted, player was asked a number again

According to playing ((3) among Fig. 1);

● interrupt playing process up to receiving all data or user, this time playing process finishes (among Fig. 1

(4)).

Fig. 2 has provided the processing procedure of server after the request that receives player.This process may further comprise the steps:

● server has an intercepting thread to receive the link information of player ((5) among Fig. 2);

● after the request that receives a player, start a thread and be the player service (among Fig. 2

(6))；

● the server receiving thread receives the request header information of player; If reception information is made mistakes, then refuse

Service; If receive correctly, then further analyze the request of player;

● if player is the program stream of asking appointment for the first time, then program names is handled; Work as broadcast

When device was asked for the first time, the program path of its request may be a virtual route, therefore will carry out the path

Conversion ((7) among Fig. 2);

● if the conversion program path is correct, then prepares and send it back the head of packet of answering player (among Fig. 2

(8)); If send incorrectly, then service thread withdraws from, and server is the end of service of player;

● if head of packet sends correct, and the request of server approval player, then sends out to player

Send data flow ((9) among Fig. 2);

● when server sends data, adopt the block type send mode; If player does not receive, then service

Device just can not send data;

● server sends a blocks of data at every turn, and guarantees in the shortest time this blocks of data to be sent to

Player;

● server sends data and finishes, and perhaps data send and do not go out then service in the process that sends

The service thread of device withdraws from, and no longer is the player service.

The transmission and the reception technique of audio/video flow finished in the collaborative work that player and server have been set forth in the front.The key that data of the present invention transmit is just to transmit data when needing, if transmit data, then finishes with transmitting in the shortest time.Because player is when playing acquired data, server can not transmit data to it.And this moment, server can be other player service.Each playing request is not to take the network bandwidth in playing process always like this, but step, bursting takies, thereby can make full use of the network bandwidth.

Experiment showed, on the 100MBPS network of (MBPS refers to per second 1M bit), adopt technology of the present invention, can transmit the program stream of the MPEG1 of 80 1.5MBPS, and guarantee to play smooth; That is to say, adopt technology of the present invention, the audio and video data streams of transmission 120MBPS that can be stable on the network of 100MBPS, and guarantee that they can smooth broadcast.

The reason that can accomplish this point is not the network bandwidth that increases physics, but bursting tranmission techniques of the present invention is suitable for the transmission of network multimedia data stream.This technology makes full use of characteristics that audio/video flow fetches data while playing to save the network bandwidth.

In the elaboration in front, also have a bit and need further illustrate and solve, this also is a part of the present invention simultaneously.Here it is, and existing player majority is to read local file to play, if support the document flow on the playing network, then needs player is transformed.The MEDIAPLAYER of MICROSOFT and the REALPLAYER of REALNETWORD can playing network on stream file.But they can not play file such as AVI, WAV, the MIDI etc. of non-stream arbitrarily.But if these files are local files, then they can well be by most data player plays.Following technology of the present invention can be so that player as playing local file playing network file, and need not changed original broadcast system of player.

The central idea of this technology is: the system that does not as far as possible change original player; The api function of the file operation by hook system, the new api function that articulates can read network file; When player calls the file operation api function and opens the network file that has articulated, new file operation api function will remove to open network file, concerning player, operate as opening local file.

It is as follows not change the step that realizes the VOD broadcast under the situation that has the broadcast system:

● the player of existing broadcast system of packing into, and the module of the hook file operation api function of packing into,

Articulate corresponding api function ((10) among Fig. 3) simultaneously;

● call the player plays file ((11) among Fig. 3) of packing into; If what play is the VOD file,

Then articulate operation ((12) among Fig. 3) to this document;

● player is operated the file that will play as playing local file, as opens the audio/video flow file,

Reading of data from file is reorientated ((13) among Fig. 3) such as files;

● if what open is local file, and the api function of the new file operation that is then articulated can call and be

The corresponding function of system comes operation file ((14) among Fig. 3); If the VOD file, then these

New can be read corresponding VOD file (Fig. 3 automatically by the hanging API function to the VOD server

In (15)); For player, what it did not know present broadcast is the VOD file like this

Or local file;

● the program stream that the operation of the api function that the player utilization newly articulates will be play ((16) among Fig. 3) is straight

Finish to playing;

If ● finish playing, then remove hook (if the front articulates), and then this is broadcast this document

Let slip journey and finish ((17) among Fig. 2).

Claims

1. bursting audio/video flow transmission of video request program (hereinafter to be referred as VOD) system and reception technique are realized that under the situation that does not change existing broadcast system VOD plays, and can effectively save the network bandwidth when playing audio-video are flowed by certain method; This method may further comprise the steps:

The player of existing broadcast system of packing into, and the module of hook file operation application programming interface (hereinafter to be referred as the API) function of packing into articulate corresponding api function simultaneously;

Articulate the VOD file that to play, and call the player plays this document of packing into;

Player is organized into HTTP (hereinafter to be referred as HTTP) request packet header to solicited message, and sends to corresponding server; The data packet head of the fixed length of the response of waiting for server then;

The information that the player Analysis server is passed back, server is by the request that is subjected to player in this way, and then player prepares to receive data and broadcast;

Player receives a blocks of data, plays then; In playing process, player no longer receives data, and server does not transmit data to it yet; After this blocks of data had transmitted, player asked a blocks of data to be play again;

Interrupt playing process up to receiving all data or user, this time playing process finishes;

If finish playing, then remove hook (if the front articulates), and then this playing process finishes to this document.

2. the method for claim 1 also comprises step:

When server sends data, adopt the block type send mode; If player does not receive, then server just can not send data;

Server is each to send a blocks of data, and guarantees in the shortest time this blocks of data to be sent to player;

3. the method for claim 1 also comprises:

Do not change the system of original player as far as possible; The api function of the file operation by hook system, the new api function that articulates can read network file; When player calls the file operation api function and opens the network file that has articulated, new file operation api function will remove to open network file, concerning player, operate as opening local file.