EP2454863A1 - Steuerung der datenrate eines medien-downloads anhand von client-wiedergabestatusinformation - Google Patents

Steuerung der datenrate eines medien-downloads anhand von client-wiedergabestatusinformation

Info

Publication number
EP2454863A1
EP2454863A1 EP10731736A EP10731736A EP2454863A1 EP 2454863 A1 EP2454863 A1 EP 2454863A1 EP 10731736 A EP10731736 A EP 10731736A EP 10731736 A EP10731736 A EP 10731736A EP 2454863 A1 EP2454863 A1 EP 2454863A1
Authority
EP
European Patent Office
Prior art keywords
server
client
media file
download
file
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP10731736A
Other languages
English (en)
French (fr)
Inventor
Bengt Skogvall
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
iTV solutions GmbH
Original Assignee
iTV solutions GmbH
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 iTV solutions GmbH filed Critical iTV solutions GmbH
Publication of EP2454863A1 publication Critical patent/EP2454863A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/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/23805—Controlling the feeding rate to the network, e.g. by controlling the video pump
    • 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/613—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for the control of the source by the destination
    • 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/75—Media network packet handling
    • H04L65/752—Media network packet handling adapting media to network capabilities
    • 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/75—Media network packet handling
    • H04L65/756—Media network packet handling adapting media to device capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/44004—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving video buffer management, e.g. video decoder buffer or video display buffer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/637—Control signals issued by the client directed to the server or network components
    • H04N21/6377—Control signals issued by the client directed to the server or network components directed to server
    • 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/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks

Definitions

  • the present invention relates to a server method for transferring a movie-playable media file from a server to a client, a client method for downloading such a media file from a server to a client, and a client device and a server device. Finally, the invention relates to a computer program for controlling a client device and to a computer program for controlling one or more server machines.
  • VoD video-on-demand
  • the received file sections of the media file are first buffered in the reproduction method known from DE 10 2008 020 807.8.
  • the client will start playing the buffered file sections of the media file at the client for a user of the client at a certain time when the download is not yet completed, but there is a reasonable likelihood that continuing to download the media file will continue until the download is completed to abort the playback of the complete media file without interruption.
  • An increasing demand for video-on-demand services requires a distribution of the transfer capacity available between the server side and the client side at any given time to many parallel download processes for a large number of clients, without the quality of the client rendering being compromised. wishes to suffer interruptions.
  • the technical problem underlying the present invention is therefore to specify a server method, a client method and corresponding server-side and client-side apparatuses and computer programs that make it possible to provide a method for downloading a film-playable media file from a Server to a client of the type described above for a media file to improve so that the one-time available total transmission capacity can be used particularly effective in view of a variety of parallel download processes.
  • a server method for transmitting a movie-playable media file from a server to a client comprising: Providing the media file in the form of a plurality of separate file sections, each comprising a plurality of contiguous blocks of data;
  • the server receives from the client playback status information during the download process.
  • the playback status information indicates the current state of the media file playback at the client.
  • This information allows the server to adaptively set a data rate for downloading the media file to the respective client, the currently set value of the data rate depending on the playback status information received before, that is, until the time of setting. In this way, it is possible to improve a server method for transmitting a media file to a respective client in such a way that the total available transmission capacity at a time can be used particularly effectively with regard to a multiplicity of parallel active download processes for different clients , In comparison with the known server method described above, with the same total transmission capacity, a higher number of clients can be operated in parallel, ie simultaneously.
  • an equal number of clients served in parallel can also be supplied using a lower overall transmission capacity, that is, for example, with fewer server machines.
  • a VoD service provider can save costs in this way.
  • a user of a respective VoD client will not experience a reduction in the quality of the playback of the media file, such as interruption or halting playback.
  • the proposed adaptivity for setting the data rate relates to each individual client and the playback status information received by this client and can thus assign to each client the data rate that it individually and currently requires for uninterrupted playback.
  • the inventive method is based on the recognition that users of a video-on-demand service statistically considered a media file is not uninterrupted play from beginning to end.
  • the server method of the present invention opens up new reserves of transmission capacity from this user behavior without causing the user of the client a noticeable impairment of the playback quality due to undesired stalling of the playback.
  • the transmission capacity not currently required by a first client can advantageously be made available to at least one second client, which currently needs it.
  • the server method of the first aspect of the present invention utilizes secure downloading of the media file as a plurality of separate file sections, each comprising a plurality of contiguous blocks of data.
  • the secured download ensures that each file section of the media file, when requested by the client, reaches the client completely from the server by the client sending a corresponding receipt to the server. Secured downloading further implies that on the client side, the received file section is also checked for freedom from errors and that the server takes appropriate precautions, for example inserting checksums in the file sections.
  • the replay status information used in the server process may be a single current replay status, such as "Media file is currently playing” (without additional information), "Media file is currently playing at play location xy,” or "Media file is not currently playing.”
  • Differentiation of the latter status information can be advantageous, for example in “play pause” if the playback is stopped at a certain point, and “play stop” if the playback is interrupted, in the case of a pause the probability is greater that playback resumes at short notice, which can be answered with a smaller reduction in data rate than in the case of "Play Stop”.
  • a playback speed can be determined which is less than or greater than when playing the movie in normal speed. This can be taken into account when adaptively setting the data rate.
  • the data rate setting server adjusts a time delay between receiving a file section download request and starting to download the file section concerned.
  • the data rate decreases accordingly with increasing time delay.
  • the time delay disappears, it reaches its theoretical maximum. This theoretical maximum is actually reached when disturbances or delays on the transmission link between the server and the client do not reduce the data rate.
  • the server may set the timeout for such client downloading processes to a high value that currently indicates no progress in the media file's rendering.
  • the time delay for such clients may be set to a small or even fading value, starting the download of a media file or notifying the server that the media file is playing on the client.
  • An increase or decrease of the time delay is preferably set differentiated depending on the reproduction status information for the respective downloading process of a client.
  • a mean time delay is assumed as the normal value, which can be regulated up or down.
  • the value range for the time delay can be selected depending on the circumstances. For example, a mean delay time can range between 100 and one thousand (1000) milliseconds (ms). For example, a large delay time may be 2000 ms or more. If an additional download process requested in a situation in which the server is already at the upper limit of its transmission capacity, in another embodiment, the new download process starts, but delay with a first large or very large Zertverz ⁇ 'which in nuancesren course, for example, depending after development of the load of the server, if necessary lowered. This variant is particularly useful in connection with an embodiment of a client-side rendering process, in which the client initially buffers the media file at the beginning of a download process. Therefore, the download process is not very time critical at this stage.
  • the data rate may be adjusted by using a variable-length character encoding, wherein the length of the character encoding is adjusted to adjust the data rate.
  • the character encoding is set shorter, for a desired lower data rate, the character encoding is set longer.
  • the use of a Zei 'chenko ⁇ réelle variable length as such is known, for example in Unicode Transformation Format UTF-8.
  • UTF-8 makes it possible to encode the same information in different ways. Notwithstanding the rule given in UTF-8 to use only the shortest possible coding, the server method of the present embodiment uses the appropriate coding length as needed.
  • the server method according to the invention is particularly suitable for the management of a multiplicity of parallel download processes. These download processes can be performed in parallel on a server machine.
  • a server arrangement is used with a plurality of server machines, each managing a plurality of parallel download processes.
  • a load distribution between the plurality of server machines is advantageous in order to optimize the server-side transmission capacity.
  • load sharing and downloading are performed as separate processes on different, interconnected server machines, the load distribution process controlling download processes on a plurality of dedicated server machines.
  • load distribution is performed in several stages.
  • the load distribution preferably includes a selection of one or more server machines that transmit a media file, using existing data about the current workload of each server machine, or the length of a data path between a respective server machine and a respective client, or one Combining different such information to select for a given client such a server machine that can best serve the client.
  • a plurality of copies of a particular media file are made available for download on a plurality of server machines, the number of server machines, which provide a copy of the media file depending on an expected or determined frequency of requests to download the media file.
  • the storage space required by a server arrangement is distributed in terms of the actual or expected usage of the stored media files. This is particularly advantageous for a relatively small server arrangement, on the order of 10 download servers.
  • the load distribution process comprises a method option in the event of the failure of a server machine which performs a load distribution process.
  • the method provides that in the absence of response of a load distribution process, the request is automatically made to a load distribution process at a next higher level.
  • the corresponding server machine is bypassed for further requests and the corresponding requests are routed to other server machines that perform load balancing processes of the same level.
  • a second, client-related aspect of the present invention is a client method for downloading a movie-playable media file from a server to a client, comprising securely downloading the media file from a server to the client, the client including the media file in the form of a plurality of separate media files File sections, respectively include a plurality of contiguous blocks of data, individually request, download from the server and acknowledged;
  • Playback of the media file from a certain point in time during the download - repeatedly transmitting playback status information from the client to the server during download, the playback status information indicating a current state of the media file at the client;
  • the client method of the present aspect of the present invention includes repeatedly transmitting reproduction status information from the client to the server during download, the reproduction status information indicating a current status of the client's media file playback.
  • the client receives the media file from the server at a data rate whose current value depends on the previously transmitted playback status information.
  • the client method according to the invention and the server method according to the invention thus require each other. One can not do the other.
  • the additional features of the above-described embodiments of the server method according to the invention are perceptible to the client.
  • the time delay that the server adjusts to adjust the data rate can be determined by the client by a correspondingly changed data rate when receiving the media file.
  • the client will receive and decode the variable-length coded file sections. In decoding, the client method uniquely assigns a coded character received at a respective length to a corresponding uncoded character.
  • the decoding method differs from methods known in the art such as UTF-8 in that the client is capable of clearly encoding two or more encoded characters exactly one respective uncoded one Assign characters and makes such a unique assignment depending on the currently decoded character.
  • UTF-8 encoding error provides in this embodiment, the advantage of a set screw for the data rate.
  • Buffer received file sections at the client Determining a file size of the media file
  • This embodiment of the client process ensures that the playback of the media file is started at the earliest possible time, at which it is foreseeable that the uninterrupted playback of the media file is possible in parallel with the progress of the download. Further embodiments of the client method result from the disclosure of the earlier patent application DE 10 2008 020 807.8 of the present applicant, the disclosure of which is incorporated by reference into the present application in the sense of Incorporation-by-Reference.
  • the client preferably determines a required buffer volume on the basis of the determined data rate and reserves it.
  • the buffer volume can be adjusted in a variant if necessary.
  • the current data rate determined by the client is transmitted to the server in one embodiment. This is especially useful if the client calculates the data rate itself. If the server in an alternative embodiment already has a current value of the data rate, this transmission is not provided by the client to the server in one embodiment.
  • the client performs a form of load distribution. In this embodiment, for downloading the media file or a respective file section of the media file, the client selects a server from a plurality of predetermined server addresses according to a load-distribution algorithm. The load distribution algorithm may be executed by the client itself in this embodiment.
  • the actual execution of the load distribution algorithm is performed by an external load balancing server and the client is provided with a variety of server addresses to choose from.
  • the client selects to download a media file a server address from this plurality, for example, according to a statistical load distribution algorithm.
  • the load-distribution server additionally sends a prioritization of the server addresses, in the sense that the client responds to downloading servers in a specific order, and in the event of overloading of a server addressed addresses the server with the next lower priority.
  • the client has stored server addresses without prior notification, with or without prioritization.
  • the server addresses preferably identify load distribution servers that serve to select another load distribution server of a next higher level.
  • the file sections of the media file preferably carry a data amount of between 0.3 and a maximum of 2 MB. At present, the range of 0.5 to 1 MB is preferred.
  • IP intemet protocol
  • the download speed is reduced as the amount of time that is required to signal the receipt of a particular piece of data from the client to the client Server is needed.
  • IP intemet protocol
  • a receive receipt must be sent from the client to the server before the server begins the next file section.
  • the file sections of a media file of at least about the same size facilitates a more accurate prediction of the time required for downloading the media file, because the calculation can be based on a precise assumption about the time portion of the signaling.
  • a further increase in the effective download speed can be achieved if the downloading of the file sections is carried out simultaneously in at least two parallel download processes, wherein in the downloading processes different file sections of the media file are downloaded.
  • Such a so-called multithreaded method with, for example, three parallel download processes can make better use of the available transmission bandwidth, because during the waiting times of a download process in the course of the necessary signaling, the or the other download processes continue to run in parallel and use the available transmission capacity.
  • a third aspect of the present invention is a computer program for controlling one or more server machines for carrying out a server method according to the first aspect of the invention or one of the embodiments of this server method disclosed therein.
  • the computer program is embodied as a directly executable file or as a group of executable files or as an installation package in which the executable files implementing the server method are only available after an installation process on a server arrangement.
  • a fourth aspect of the present invention is a computer program for controlling a client device for carrying out a client method according to the second aspect of the invention or one of the embodiments of this client method disclosed therein.
  • This computer program is embodied in various exemplary embodiments as a directly executable file or as a group of executable files or as an installation package in which the executable files implementing the client method are only available after an installation process on a client device.
  • the invention may also be embodied in a server arrangement or in a client device.
  • a fifth aspect of the present invention is a server arrangement.
  • the server arrangement according to the invention is designed to perform the server method of the first aspect of the invention or one of the disclosed embodiments of the server method.
  • the server arrangement of the fourth aspect of the invention therefore shares the advantages of the above-described server method according to the first aspect of the invention.
  • the server arrangement comprises at least one server machine.
  • a server machine can be understood to mean a computer set up for independent execution of the server method or a computer set up to participate in the execution of the server method.
  • the server arrangement can be set up, for example, so that the execution of one or more parallel instances of the server method according to the invention is distributed, ie shared by a plurality of computers, without the implementation of a respective instance of the server method necessarily being permanently exactly one Computer is assigned.
  • the latter variant has the advantage of hardware-near load distribution and increased reliability in case of failure of a computer of the server arrangement.
  • Storage means such as a storage device, for providing at least one media file that can be displayed as a movie; and Download control means, such as a control unit, adapted to safely download the media file to a client in the form of a plurality of separate file sections, each comprising a plurality of contiguous data blocks,
  • a sixth aspect of the present invention is a client device for downloading a movie-playable media file from a server.
  • the client device according to the invention is designed for carrying out the client method according to the second aspect of the invention or for carrying out one of the disclosed embodiments of this client method.
  • the client device of the present aspect of the invention shares the advantages of the client method described above according to the second aspect of the invention.
  • the client device includes a downloading unit configured to securely download the media file from a server, wherein the downloading unit is configured
  • Media file in the form of a large number of separate file sections, each a variety contiguous blocks of data include requesting individually, downloading and acknowledging from the server, a playback control unit adapted to generate and output signals from the media file which control the playback of the media file at a replay device from a certain point in time during the download ; wherein the download unit is configured to repeatedly transmit playback status information to the server during download, the playback status information indicating a current state of the media file at the client; and - receive the media file from the server at a variable data rate that depends on the transmitted playback status information.
  • the above-described embodiment of the client method in which the downloaded file sections are first buffered prior to playback is preferably performed with a client device including a buffer memory for buffering received file sections prior to commencing playback, the playback control unit being adapted for Determine a file size of the media file. Furthermore, the reproduction control unit is configured to control the start of reproduction of the buffered file portions of the media file at a time when the download is not yet completed, but in view of a current value of a data rate of downloading and in view of the file size of the media file predetermined minimum likelihood is reached that the further playback of the media file in parallel with the progress of the download until the completion of the playback of the complete media file will run without interruption.
  • Fig. 1 shows a simplified flow diagram of a server method for transferring a media file from the server to a client.
  • FIG. 2 shows a simplified block diagram of a load distribution process executable in the context of a server method.
  • 3 is a schematic block diagram of a server arrangement according to an embodiment of the present invention.
  • FIG. 4 shows a simplified flow diagram of a small method for downloading a media file from a server to the client.
  • a simplified flow diagram of a server method for transferring a media file from the server to a client is shown in FIG.
  • a request for secure download of a media file is received from a client.
  • the server process then starts a download process in a step 102. It makes sense that the request for downloading the media file is preceded by a logon procedure (authentication) performed by the server and the client. However, this is not shown here.
  • the server method is also simplified in that it can be distributed among multiple servers and executed in interaction with a load sharing method. This will be explained in more detail below.
  • the start of the download process in step 102 triggers the server to determine the availability of the requested media file and, where appropriate, its storage location.
  • step 104 if the result of the partial steps executed in connection with the process start is positive, in step 102 the client is presented with the readiness to download the media file.
  • the server method may, for example, transmit an address of a download server machine responsible for the download process and identification data for the download process to be performed ("ticket") . This ticket is associated with the client in the subsequent course of the download process with its requests to download file sections of the relevant media file to the assigned server machine.
  • the server or server arrangement receives a corresponding request from the client to download a first file portion of the requested media file.
  • steps for transferring file parameters of the media file from the server to the client may include the file size, the playback time, the size of file sections of the media file, the number of file sections of the media file, information about Digital Rights Management (DRM), information about available index files, or other information.
  • DRM Digital Rights Management
  • the server method additionally includes a data rate control process associated with the download process that operates in parallel with and exchanges information with the download process, as described in more detail below.
  • the data rate control process is started in a step 152.
  • the data rate control process is usefully started only once for each download process of a media file, and is not retried on every received request to download a file portion of the same media file.
  • the data rate control process determines current playback status information for the particular download process (step 154).
  • the playback status information in one embodiment relates to the current state of the rendering process at the client or a change in that state.
  • the condition can be described, for example, by playing (playback, engl. Play), canceling the playback (stop), interrupting the playback (pause), fast forwarding (fast forward), rewinding (fast reverse).
  • Other playback modes, such as slow motion playback, etc. can also be specified.
  • a special playback status information is characterized in that during the download process of the media file when playing at a client enters a state in which a predetermined minimum number of buffered file sections at the client is exceeded. This causes the server in the data rate control process to give the affected download process a higher priority and thus a higher data rate.
  • step 154 may be skipped.
  • the client also sends the server, as playback status information, a buffer phase before the start of the playback of the media file.
  • This phase typically begins immediately with a request to download the media file in step 100.
  • the data rate to be assigned to the respective download process is determined server-side in step 156 and passed on to the download process in a subsequent step 158.
  • the assigned data rate depends on the determined playback status information.
  • the calculation of the data rate for a respective download process is performed in a variant of a load distribution server and transmitted to a download server as control information. This will be explained in more detail below with reference to FIG. 3.
  • the download process (at the download server) receives the data rate information in a corresponding step 108.
  • the data rate may be controlled by varying the duration of a server-inserted transmission delay (waiting period) before sending a file section. Starting from an average transmission delay of, for example, 100 ms before each file section is sent, increasing or decreasing this time interval can result in a reduction or increase in the data rate of the download.
  • An addition or alternative is the use of a variable encoding of the media file when sending. This variant has already been explained in more detail above.
  • the download process in the server process thus takes place by downloading the file sections with the currently assigned data rate.
  • the file sections will be downloaded separately, file section for file section. Each file section is therefore individually requested, downloaded and acknowledged by the client.
  • the downloading of the media file is performed with file sections of a data amount of 0.5 to 1 MByte.
  • the file sections therefore deliver a data volume of 0.5 to 1 MByte "in one go.” This is a significantly increased amount of data compared to conventional download processes (64 kByte) and requires a very high efficiency of the download process, as also explained in more detail above wherein the data rate is adaptively set by the data rate control process during the download process ..
  • the server receives a receive receipt from the client at a step 112, respectively.
  • the download process uses a best-effort network, preferably an IP (Intended Protocol) -based network because of its high prevalence.
  • IP IP
  • the secure download is performed in the embodiment of Figure 1 using the protocol http (Hypertext Transfer Protocol).
  • http Hypertext Transfer Protocol
  • An approximate measure of packet transit time is the "ping time.”
  • the background to speeding down the download process in the prior art is that the client must acknowledge correct receipt for each 64 kbyte block before the server sends the next block
  • the download data rate reduces to about 1.5 Mbit / s, which corresponds to a speed loss of about 25%
  • data transfer is possible at a data rate of 4.5 Mbps, which is only 29% of the nominal data rate of 16 Mbps.
  • the download process of a media file according to FIG. 1 can be carried out in parallel for a plurality of file sections, ie as a multithreaded process. For example, three file sections of the same media file can be downloaded in parallel.
  • This has the advantage that transmission gaps, during which acknowledgment packets from the client to the server can be used by the transfer of other file sections in other threads.
  • Using three threads, for a nominal data rate of 2 Mbit / s an effective transmission rate can be very close to 100% of this theoretical maximum, and at a nominal data rate of 16 Mbit / s, an effective data rate of almost 13.6 Mbit / s can be achieved 87% of the theoretical maximum can be achieved.
  • These data rates are high enough to transmit video files in HD (high definition) resolution without imposing a long waiting time for a client to start playing.
  • a cost reduction over known streaming processes can be achieved.
  • the use of web servers to deliver media files for a given volume of data is a factor of two to three times lower than servers for streaming processes.
  • Second, using a download process, unlike a streaming process, allows the use of variable bit rates when encoding the media file.
  • the use of variable bit rates saves 25% to 50% of the data volume to be transmitted, compared to a constant bit rate as used in the streaming process. Overall, a cost fraction reduced by a factor of five can therefore be achieved for each hour of the playback time of a media file with a download process.
  • the reproduction status information received by the client and transmitted to the data rate control process may be transmitted from the client to the server in connection with the acknowledgment of a respective file section, for example.
  • the time between successive transmissions of playback status information is not necessarily tied to intervals between downloading file portions of the media file.
  • the playback status information can also be sent to the server independently of the acknowledgment from the client.
  • Replay status information may be transmitted by the client to the server only if changes occur in the replay process on the client side.
  • FIG. 2 shows a simplified flowchart of a server-side load distribution process. The load distribution process steps illustrated in Figure 2 are typically performed by a server machine involved in downloading the requested media files to active clients.
  • Such a server machine is also referred to here as a download (DL) server.
  • the server load distribution process local to the download server is started in a step 202. Thereafter, current play information associated with active download processes is received (step 204).
  • the replay information of the various active download processes are evaluated server-side to determine the individual data rates of the various download processes taking into account the total capacity of the respective server machine for operating the download processes (step 206) and assign (step 208). ,
  • the available bandwidth that a respective download server can handle is not constant. Their current value depends on many factors that can not be controlled by the server. When determining the new data rates for the active download processes, therefore, the currently available bandwidth of the respective download processes is additionally taken into account in the present example.
  • the determined new data rates for the active download processes are communicated to the associated active data rate control processes (see Fig. 1) in step 208.
  • a current load information of the relevant download server is determined and transmitted to an allocated load-balancing server (English: loadbalancing (LB) server) (step 210).
  • the load information may, for example, be determined by means of delay times which are assigned to the individual download processes for controlling the respective data rates. The smaller the sum of the assigned delay times of all active downlinks de-processes, the greater the load currently being handled by the download server. This will be explained in more detail below with reference to a specific example.
  • the download server must provide a high data rate for at least one client that is in the media file replay, thus ensuring a download time delay of less than 100 milliseconds.
  • this request is assigned a startup data rate determined from the current load information and / or the playback information.
  • the delay time for the new request during client buffering is set to a high value, for example 2000 milliseconds.
  • the resulting delay time for the relevant new download process is kept high until lower load information of the download server is determined in subsequent process loops. This is achieved, for example, if all active clients currently playing the partially downloaded media file have a delay time of more than 100 milliseconds.
  • the described method ensures that, in the case of a large number of requests, the download server continues to preferentially serve those clients who are currently playing the media file. An interruption in the playback of these clients can be avoided. In contrast, those clients that are still in the buffer phase are served at a reduced data rate.
  • FIG. 1 An embodiment of a server arrangement according to the invention with a structure for effective load distribution is shown in FIG.
  • the load distribution for request processes is explained.
  • the subsequent distribution for the download processes is shown schematically.
  • a plurality of clients CL is symbolized in the lowest level of the left subfigures by a number of blocks.
  • Each of the blocks shown and labeled with the common reference numeral CL is an individual client device.
  • a client device may be a set-top box for connection to a TV or a user's computer.
  • the client device may also be constituted by a computer equipped with software for performing a client download process (see the example of FIG.
  • Each client device has a number of server addresses to which a download request for a media file can be directed. For example, each client can have a list of 10 different server addresses.
  • the selection of a respective server for a request is made with a statistical load distribution procedure carried out by the client. For this purpose, for example, a round-robin method can be used.
  • the aim of the run-round procedure executed in each client is to make the utilization of the L1 server provided for the requests of the respective client as uniform as possible.
  • the L1 servers are used to distribute the incoming requests to download a media file to a respective number of associated L2 servers, which in turn each manage a larger number of download servers in the load-distribution process.
  • each L1 server can control load balancing for up to 100 L2 servers.
  • Each L2 server can control up to 100 download servers in such a scenario. Assuming a rate of, for example, 10,000 requests per second received by each L1 server, each L2 server controlled by that server must process about 100 load-distribution requests per second. This task can be accomplished without special hardware expenditure, thus with standard commercial servers. If high-performance high-end servers were used, for example in the form of blade servers, the performance could be increased even further.
  • a respective download server When downloading, the allocation of download processes to a respective download server DL via the load distribution servers L1 and L2.
  • a respective download server performs a load distribution procedure for the various download processes assigned to it, as described with reference to FIG.
  • a media file is downloaded to a client using a plurality of parallel download processes (multi-threading). This is symbolized on the right edge of the right partial image of the figure in a schematized magnifying glass as an "enlargement" of the download processes for a single client.
  • Each download server can download requests up to a respective upper limit of bandwidth. This limit is around 50 to 80 Mbit / s for low-cost servers.
  • a total data rate of about 8 GBit / s can be achieved at the present time.
  • 200 parallel download processes with about 400 kbps can be managed by a simple server.
  • This number weighs one High-end L2 server is not off. So, such L2 servers are able to deliver more requests to a simple download server than it can handle.
  • high-end L2 servers can be fully utilized even when transferring media files with higher bandwidth, such as those required for HD format videos.
  • the load distribution system described with reference to Figure 3 unfolds its advantages even in case of failure of server machines.
  • a server fails at a level in the load distribution chain in one embodiment, the associated server is addressed at the next higher level to obtain the assignment of a new server.
  • Figure 4 shows a simplified flow diagram of a client method for downloading a media file from a server to the client.
  • the download process at the client is started in a step 402.
  • the download process at the client can be started, for example, due to a manual user input on the client device.
  • any other common triggering techniques may be used, such as a pre-programmed start of a query to a corresponding server of a VoD provider.
  • a corresponding L1 server of the VoD provider is selected at the client.
  • a load distribution method executed by the client is carried out, as described in connection with FIG.
  • the request to download a desired media file is sent to the selected servers (step 406).
  • the client When using a load distribution method, the client receives in a subsequent step 408, for example in the signaling exchange with a server arrangement according to FIG. 3, the address of the download server assigned to him for downloading the media file. The client then sends its request to download the desired media file to the download server to be assigned (Step 410). After receipt of a readiness message from the download server (step 412), with the usefully also the file size and / or possibly other useful information about the downloaded media file are transmitted, the download of the media file, file section for file section begins, as mentioned, preferably at least two file sections are downloaded in parallel download processes (threads). For this purpose, the client sends a respective request to download a respective file section to the assigned download server (step 414) and then receives and buffers the received file feed. Upon complete receipt of the relevant file section, the client sends a receipt to the download server.
  • the client sends a next request to download another file section to the download server.
  • This loop of steps 414 and 416 is repeated until complete completion of downloading the media file in the multiple parallel processes simultaneously. This effectively uses latencies between each transfer during secure download of file sections.
  • a playback process is performed parallel to the download process. This can for example be started after receiving the first file section.
  • a manual start, interruption or termination of the playback process is of course also possible, as is common in the operation of playback devices such as video recorders.
  • the client's playback process does not immediately begin with the actual playback (play, play) of the already downloaded file sections of the media file. Instead, after the start in section 418, a current playback status information for the relevant media file in the client is first determined and sent to the download server active in the download process (step 420). Conceivable, of course, is the transmission to another server, the server arrangement described in Figure 3. The client further checks in a step 422 the status of the buffering process for the particular media file being downloaded.
  • the start of playback is waited until the time at which in view of the current amount of buffered file sections, the previously achieved data rate in the download process, and the total size of the media file has reached a predetermined minimum probability that the further replay of the media file will be uninterrupted in parallel with the progress of the download until the completion of the replay of the complete media file (step 424).
  • the current playback status information "buffering" is sent to the download server DL (step 420) and checked again (steps 422 and 424) .
  • This loop is run until after the described criterion the playback can be started ( The playback of the media file is then continued until a change occurs, ie the user of the client stops playback (pause), aborts (stop) or makes other inputs that affect the playback process.A corresponding test runs during playback Continuously in the background (step 428) If such a change in playback status occurs over the previous state, a new playback status information is sent to the download server, so the process branches back to step 420. If the playback is completely aborted, at this point the download process is aborted (not shown in Figure 4.)
  • the A Breakthrough download can be linked, for example, to the condition that the user explicitly confirms the cancellation by an input.
  • step 424 If the playback has been interrupted or aborted without aborting the download process, the sequence of process steps 420 to 424 is subsequently run through and the user is waited for an input signal to continue the playback. If so, playback continues in step 426. If not, a holding pattern is executed, which is not shown in FIG.
  • the method is preferably carried out with the aid of an appropriate software.
  • an appropriate software Of course, it can also be implemented in terms of hardware.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

Das Übertragen einer als Film wiedergebbaren Mediendatei von einem Server an einen Client wird durch abgesichertes Herunterladen getrennter größerer Dateiabschnitte bewerkstelligt, wobei der Client während des Herunterladens Information zum Status der Wiedergabe des Films an den Server überträgt. Die Datenrate der Übertragung der Mediendatei wird vom Server adaptiv an die empfangene Wiedergabestatusinformation angepasst. Das Verfahren ermöglicht in verschiedenen Ausführungsformen eine verbesserte Kapazitätsausnutzung auf der Serverseite, ohne die clientseitige Wiedergabe durch Unterbrechungen zu beeinträchtigen.

Description

Steuerung der Datenrate eines Medien-Downloads anhand von Client-Wiedergabestatusinformation
Die vorliegende Erfindung betrifft ein Server-Verfahren zum Übertragen einer als Film wiedergebbaren Mediendatei von einem Server an einen Client, ein Client-Verfahren zum Herunterladen einer solchen Mediendatei von einem Server an einen Client, sowie ein Clientgerät und eine Server-Anordnung. Schließlich betrifft die Erfindung ein Computer- programm zum Steuern eines Clientgeräts sowie ein Computerprogramm zum Steuern einer oder mehrerer Servermaschinen.
Bei im Stand der Technik für Video-on-Demand(VoD)-Dienste bekannten Streaming- Technologien hängt die Güte der Wiedergabe einer Mediendatei davon ab, dass auf dem gesamten Übertragungspfad von VoD-Server zum VoD-Client, nachfolgend kurz als Server bzw. Client bezeichnet, stets eine ausreichende Übertragungskapazität (Bandbreite) vorliegt.
Aus der am Prioritätstag der vorliegenden Patentanmeldung noch unveröffentlichten DE 10 2008 020 807.8 sind, im Gegensatz zu bekannten Streaming-Verfahren, Verfahren zum Herunterladen einer als Film wiedergebbaren Mediendatei von einem Server an einen Client und zum Wiedergeben der Mediendatei durch den Client bekannt. Bei diesen Verfahren erfolgt serverseitig das Herunterladen der Mediendatei durch Übertragen einer Vielzahl getrennter Dateiabschnitte der Mediendatei vom Server an den Client. Das Herunterladen (engl. Download) einer Mediendatei ist also ein sowohl vom Server als auch vom Client betriebener Prozess, in dem Sinne, dass einerseits der Client die Mediendatei„vom Server herunterlädt", indem er eine entsprechende Anfrage an den Server sendet und die übertragene Datei empfängt und speichert, und andererseits der Server die Mediendatei„an den Client herunterlädt", indem er auf entsprechende Anfrage hin die Mediendatei wie beschrieben an den Client übertragt.
Auf der Seite des Clients werden bei dem aus der DE 10 2008 020 807.8 bekannten Wiedergabeverfahren die empfangenen Dateiabschnitte der Mediendatei zunächst gepuf- fert. Die Wiedergabe der gepufferten Dateiabschnitte der Mediendatei beim Client für einen Nutzer des Clients startet der Client zu einem bestimmten Zeitpunkt, bei dem das Herunterladen noch nicht beendet ist, an dem jedoch eine hinreichende Wahrscheinlichkeit besteht, dass unter Fortführung des Herunterladens die weitere Wiedergabe der Mediendatei bis zum Abschiuss der Wiedergabe der vollständigen Mediendatei unterbre- chungsfrei verlaufen wird.
Eine steigende Nachfrage nach Video-on-Demand-Diensten erfordert eine Verteilung der zwischen der Serverseite und Clientseite zu einem jeweiligen Zeitpunkt zur Verfügung stehenden Übertragungskapazität auf viele parallele Herunterlade-Prozesse für eine große Anzahl Clients, ohne dass die Wiedergabequalität bei den Clients durch uner- wünschte Unterbrechungen leidet.
Das der vorliegenden Erfindung zugrunde liegende technische Problem ist es daher, ein Server-Verfahren, ein Client- Verfahren sowie entsprechende Server-seitige und Client- seitige Vorrichtungen und Computerprogramme anzugeben, die es ermöglichen, ein Verfahren zum Herunterladen einer als Film wiedergebbaren Mediendatei von einem Server an einen Client der vorstehend beschriebenen Art für eine Mediendatei so zu verbessern, dass die zu einem Zeitpunkt zur Verfügung stehende gesamte Übertragungskapazität mit Blick auf eine Vielzahl paralleler Herunterlade-Prozesse besonders effektiv genutzt werden kann.
In einem ersten, Server-bezogenen Aspekt der vorliegenden Erfindung wird das genann- te technische Problem gelöst durch ein Server-Verfahren zum Übertragen einer als Film wiedergebbaren Mediendatei von einem Server an einen Client, umfassend: Bereitstellen der Mediendatei in Form einer Vielzahl getrennter Dateiabschnitte, die jeweils eine Vielzahl zusammenhängender Datenblöcke umfassen;
Abgesichertes Herunterladen der Mediendatei an den Client, wobei jeder Dateiabschnitt der Mediendatei auf Empfang einer individuellen Anforderung hin vom Server an den Client heruntergeladen wird und das Herunterladen des jeweiligen Dateiabschnitts mit Empfang einer Quittung vom Client endet;
Wiederholtes Empfangen vom Client gesendeter Wiedergabestatusinformation während des Herunterladens, wobei die Wiedergabestatusinformation einen jeweils aktuellen Stand der Wiedergabe der Mediendatei beim Client angibt; - Adaptives Einstellen einer Datenrate für das Herunterladen der Mediendatei, wobei der aktuelle Wert der Datenrate von der zuvor empfangenen Wiedergabestatusinformation abhängt.
Bei dem erfindungsgemäßen Verfahren empfängt der Server vom Client Wiedergabestatusinformation während des Herunterlade-Prozesses. Die Wiedergabestatusinformation gibt einen jeweils aktuellen Stand der Wiedergabe der Mediendatei beim Client an. Diese Information ermöglicht es dem Server, eine Datenrate für das Herunterladen der Mediendatei an den jeweiligen Client adaptiv einzustellen, wobei der jeweils aktuell eingestellte Wert der Datenrate von der zuvor, also bis zum Zeitpunkt des Einsteilens, empfangenen Wiedergabestatusinformation abhängt. Auf diese Weise gelingt es, ein Server-Verfahren zum Übertragen einer Mediendatei an einen jeweiligen Client so zu verbessern, dass die zu einem Zeitpunkt zur Verfügung stehende gesamte Übertragungskapazität mit Blick auf eine Vielzahl parallel aktiver Herunterlade-Prozesse für unterschiedliche Clients besonders effektiv genutzt werden kann. Im Vergleich mit dem oben beschriebenen bekannten Server-Verfahren kann bei gleicher Gesamt-Übertragungskapazität eine höhere Anzahl Clients parallel, also gleichzeitig bedient werden. Anders betrachtet kann auch eine gleiche Anzahl parallel bedienter Clients unter Verwendung einer geringeren Gesamt-Übertragungskapazität, also beispielsweise mit weniger Server-Maschinen versorgt werden. Ein VoD-Service-Anbieter kann auf diese Weise Kosten sparen. In jedem Fall wird ein Nutzer eines jeweiligen VoD- Clients keine Verringerung der Wiedergabequalität beim Abspielen der Mediendatei, etwa durch Unterbrechung oder stockende Wiedergabe erfahren. Denn die erfindungsgemäße vorgesehene Adaptivität beim Einstellen der Datenrate bezieht sich auf jeden individuellen Client und die von diesen Client empfangene Wiedergabestatusinformation und kann so jedem Client die von ihm individuell und aktuell zur unterbrechungsfreien Wiedergabe benötigte Datenrate zuweisen. Das erfindungsgemäße Verfahren beruht auf der Erkenntnis, dass Nutzer eines Video- on-Demand-Dienstes eine Mediendatei statistisch betrachtet mit großer Wahrscheinlichkeit nicht unterbrechungsfrei von Anfang bis Ende abspielen. Es werden bei der Wiedergabe Pausen eingelegt, oder die Wiedergabe wird sogar vollständig abgebrochen, beispielsweise wenn ein Film einem Nutzer nicht gefällt. Das Server-Verfahren der vorlie- genden Erfindung erschließt aus diesem Nutzerverhalten neue Reserven der Übertragungskapazität, ohne beim Nutzer des Clients eine wahrnehmbare Beeinträchtigung der Wiedergabequalität durch unerwünschtes Stocken der Wiedergabe hervorzurufen. Die von einem ersten Client aktuell nicht benötigte Übertragungskapazität kann vorteilhaft mindestens einem zweiten Client zur Verfügung gestellt werden, der diese aktuell benö- tigt.
Das Server-Verfahren des ersten Aspekts der vorliegenden Erfindung verwendet ein abgesichertes Herunterladen der Mediendatei in Form einer Vielzahl getrennter Dateiabschnitte, die jeweils eine Vielzahl zusammenhängender Datenblöcke umfassen. Das abgesicherte Herunterladen (engl, secured download) stellt sicher, dass jeder Dateiab- schnitt der Mediendatei nach entsprechender Anforderung durch den Client vom Server vollständig zum Client gelangt, indem der Client eine entsprechende Empfangsquittung an den Server schickt. Abgesichertes Herunterladen impliziert weiterhin, dass auf Clientseite auch eine Prüfung des empfangenen Dateiabschnitts auf Fehlerfreiheit vorgenommen wird und der Server hierzu entsprechende Vorkehrungen trifft, beispielsweise Prüf- summen in die Dateiabschnitte einbaut. Techniken und Server- wie clientseitige Prozesse im Rahmen des abgesicherten Herunterladens von Dateien sind dem Fachmann an sich geläufig und werden hier ohne Beschränkung auf bestimmte dieser Techniken oder Prozesse allgemein unter dem Begriff„Abgesichertes Herunterladen" zusammengefasst. Durch das abgesicherte Herunterladen kann garantiert werden, dass die Dateiabschnitte der Mediendatei dann beim Client nach dem Herunterladeprozess vollständig und fehlerfrei vorliegen und eine perfekte Wiedergabequalität ermöglichen. Dies gilt selbst dann, wenn ein eine temporäre Verzögerung oder sonstige Störung der Übertragung eintritt. In der nachfolgenden Beschreibung wird auch kurz von „Herunterladen" gesprochen, wenn ein abgesichertes Herunterladen gemeint ist. Sollte in einem Zusammenhang ein nicht abgesichertes Herunterladen gemeint sein, wird dies ausdrücklich als solches bezeichnet. Zusammenfassend ermöglicht das Server-Verfahren der vorliegenden Erfindung die Server-seitige Steuerung der Datenrate beim abgesicherten Herunterladen einer Mediendatei in Abhängigkeit von Wiedergabestatusinformation, die der Server vom Client empfängt. Dies eröffnet die Möglichkeit zu einem nachfolgend in Ausführungsbeispielen beschriebenen verbesserten Übertragungskapazitäts-Management durch adaptives Einstellen der Datenrate paralleler Herunterlade-Prozesse für unterschiedliche Clients, ohne dass der Nutzer eines jeweiligen Clients irgendwelche Qualitätseinbußen bei der Wiedergabe eines Films hinnehmen muss. Das Verfahren erschließt so bisher ungenutzte Kapazitätsreserven für die Übertragung von Mediendateien.
Nachfolgend werden Ausführungsbeispiele des erfindungsgemäßen Server-Verfahrens beschrieben. Die zusätzlichen Merkmale der jeweiligen Ausführungsbeispiele im Vergleich mit dem erfindungsgemäßen Verfahren können miteinander kombiniert werden, um weitere Ausführungsbeispiele zu bilden, soweit sie nicht Alternativen zueinander bilden.
Die im Server-Verfahren herangezogene Wiedergabestatusinformation kann beispiels- weise ein einzelner aktueller Wiedergabestatus sein, wie beispielsweise„Mediendatei wird aktuell abgespielt" (ohne weitere Zusatzinformation),„Mediendatei wird aktuell bei Abspielposition xy abgespielt" oder „Mediendatei wird aktuell nicht abgespielt". Eine Differenzierung der letzteren Statusinformation kann vorteilhaft sein, etwa in„Abspiel- Pause", wenn die Wiedergabe an einer bestimmten Stelle angehalten wird, und„Wieder- gabe-Stopp", wenn die Wiedergabe abgebrochen wird. Im Fall einer Pause ist die Wahrscheinlichkeit größer, dass die Wiedergabe kurzfristig wiederaufgenommen wird, was mit einer geringeren Reduzierung der Datenrate als im Falle„Wiedergabe-Stopp" beantwortet werden kann.
Es kann zum adaptiven Einstellen der Datenrate zusätzlich oder alternativ auch auf den aktuellen und mehrere zurückliegende und ggf. zwischengespeicherte Übertragungen von Wiedergabestatusinformation zurückgegriffen werden. Auf diese Weise kann beispielsweise eine Abspielgeschwindigkeit ermittelt werden, die geringer oder größer ist als beim Abspielen des Films in Normalgeschwindigkeit. Dies kann beim adaptiven Einstellen der Datenrate berücksichtigt werden.
Bei einer Ausführungsform des Server-Verfahrens passt der Server zum Einstellen der Datenrate eine Zeitverzögerung zwischen einem Empfang einer Anfrage zum Herunterla- den eines Dateiabschnitts und einem Beginn des Herunterladens des betreffenden Dateiabschnitts an. Die Datenrate sinkt demnach mit zunehmender Zeitverzögerung. Bei verschwindender Zeitverzögerung erreicht sie ihr theoretisches Maximum. Dieses theoretische Maximum wird dann tatsächlich erreicht, wenn Störungen oder Verzögerungen auf der Übertragungsstrecke zwischen dem Server und dem Client die Datenrate nicht redu- zieren.
Bei Verwendung dieses Verfahrens zum Einstellen der Datenrate kann der Server beispielsweise die Zeitverzögerung für solche Herunterlade-Prozesse von Clients auf einen hohen Wert setzen, die aktuell keinen Fortschritt bei der Wiedergabe der Mediendatei melden. Weiterhin kann die Zeitverzögerung für solche Clients auf einen geringen oder sogar verschwindenden Wert gesetzt werden, die das Herunterladen einer Mediendatei beginnen oder dem Server melden, dass die Wiedergabe der Mediendatei beim Client läuft. Darüber hinaus ist es in einer Ausführungsform auch möglich, zugunsten der Hinzunahme eines neuen Herunterlade-Prozesses, der anfänglich mit einer geringen oder verschwindenden Zeitverzögerung arbeiten soll, bei einem oder mehreren anderen Herunterlade-Prozessen eine erhöhte Zeitverzögerung einzustellen. Auf diese Weise gelingt es, das Server-Verfahren bei Bedarf auch ohne Erhöhung der benötigten Übertragungskapazität um einen zusätzlichen parallelen Herunterladeprozess zu erweitern.
Eine Erhöhung oder Verringerung der Zeitverzögerung wird vorzugsweise in Abhängigkeit von der Wiedergabestatusinformation für den jeweiligen Herunterlade-Prozess eines Clients differenziert eingestellt. In einem Ausführungsbeispiel wird dabei von einer mittleren Zeitverzögerung als Normalwert ausgegangen, die hoch- oder heruntergeregelt werden kann.
Der Wertebereich für die Zeitverzögerung kann je nach den Gegebenheiten gewählt werden. Eine mittlere Verzögerungszeit kann beispielsweise im Bereich zwischen 100 und eintausend (1000) Millisekunden (ms) liegen. Eine große Verzögerungszeit kann beispielsweise um 2000 ms oder mehr betragen. Wird ein zusätzlicher Herunterladeprozess in einer Situation angefordert, in der der Server bereits an der Obergrenze seiner Übertragungskapazität ist, wird in einer anderen Ausführungsform der neue Herunterladeprozess gestartet, jedoch mit einer zunächst großen oder sehr großen Zertverzό'gerung, die im werteren Verlauf, beispielsweise je nach Entwicklung der Auslastung des Servers, ggf. gesenkt wird. Diese Variante ist insbesondere in Verbindung mit einer Ausführungsform eines Client-seitigen Wiedergabeprozesses sinnvoll, bei der der Client zu Beginn eines Herunterlade-Prozesses die Mediendatei zunächst puffert. Daher ist der Herunterladeprozess in diesem Stadium wenig zeitkritisch. Zusätzlich oder alternativ zum Einstellen der Datenrate durch Einfügen einer anpassbaren Zeitverzögerung vor dem Herunterladen eines Dateiabschnitts kann die Datenrate angepasst werden durch Verwendung einer Zeichenkodierung variabler Länge, wobei die Länge der Zeichenkodierung zum Einstellen der Datenrate entsprechend eingestellt wird. Für eine gewünschte hohe Datenrate wird die Zeichenkodierung kürzer eingestellt, für eine gewünschte geringere Datenrate wird die Zeichenkodierung länger eingestellt. Die Verwendung einer Zei'chenkoόierung variabler länge als solches ist beispielsweise im Unicode Transformation Format UTF-8 bekannt. UTF-8 ermöglicht es, ein und dieselbe Information auf verschiedene Weisen zu kodieren. Abweichend von der im UTF-8 gegebenen Vorschrift, jeweils nur die kürzest mögliche Kodierung zu verwenden, nutzt das Server-Verfahren des vorliegenden Ausführungsbeispiels je nach Bedarf die passende Kodierungslänge.
Das erfindungsgemäße Server-Verfahren eignet sich insbesondere zum Management einer Vielzahl paralleler Herunterlade-Prozesse. Diese Herunterlade-Prozesse können parallel auf einer Server-Maschine durchgeführt werden. Typischerweise wird eine Ser- ver-Anordnung mit einer Vielzahl von Server-Maschinen verwendet, die jeweils eine Vielzahl paralleler Herunterlade-Prozesse betreuen. In einer solchen Server-Anordnung ist eine Lastverteilung zwischen der Vielzahl von Server-Maschinen vorteilhaft, um die Server-seitige Übertragungskapazität zu optimieren. Vorzugsweise werden die Lastverteilung und das Herunterladen als getrennte Prozesse auf unterschiedlichen, miteinander verbundenen Server-Maschinen durchgeführt, wobei der Lastverteilungs-Prozess Herunterlade-Prozesse auf einer Vielzahl zugeordneter Server-Maschinen steuert. Eine solche arbeitsteilige Durchführung von Lastverteilung und Herunterladen ermöglicht eine skalierbare Server-Anordnung, die je nach Bedarf eine praktisch unbegrenzte Anzahl an Clients bedienen kann. Bevorzugt wird die Lastverteilung in mehreren Stufen durchgeführt. In einer ersten Stufe werden beispielsweise statistische Lastverteilungsverfahren und DNS- Rundlauf (engl. Round Robin) durchgeführt. In dieser ersten Stufe ist eine hohe Geschwindigkeit der Lastverteilungsprozesse von großer Bedeutung. Die Lastverteilung beinhaltet vorzugsweise eine Auswahl einer oder mehrerer Server-Maschinen, die eine Mediendatei übertragen, unter Verwendung vorliegender Daten über die aktuelle Arbeitslast jeder Server-Maschine, oder über die Länge eines Datenpfades zwischen einer betreffenden Server-Maschine und einem betreffenden Client, oder eine Kombination unterschiedlicher solcher Informationen, um für einen jeweiligen Client eine solche Server-Maschine auszuwählen, die den Client am besten bedienen kann. Um sicherzustellen, dass der Ausfall einer bestimmten Server-Maschine keinen Verlust von Daten verursacht, wird bei einem Ausführungsbeispiel des erfindungsgemäßen Server-Verfahrens eine Vielzahl Kopien einer bestimmten Mediendatei auf einer Vielzahl Server-Maschinen zum Herunterladen bereitgestellt, wobei die Anzahl der Server- Maschinen, die eine Kopie der Mediendatei bereitstellen, in Abhängigkeit von einer erwarteten oder ermittelten Häufigkeit von Anfragen zum Herunterladen der Mediendatei bestimmt wird. Auf diese Weise wird der von einer Server-Anordnung benötigte Speicherplatz im Hinblick auf die tatsächliche oder zu erwartende Nutzung der gespeicherten Mediendateien verteilt. Dies ist insbesondere für eine relativ kleine Server-Anordnung vorteilhaft, etwa von der Größenordnung von 10 Download-Servern. In einem weiteren Ausführungsbeispiel des erfindungsgemäßen Server-Verfahrens umfasst der Lastverteilungsprozess eine Verfahrensoption für den Fall des Ausfalls einer Server-Maschine, die einen Lastverteilungsprozess durchführt. Das Verfahren sieht vor, dass bei ausbleibender Reaktion eines Lastverteilungsprozesses die Anfrage automatisch an einen Lastverteilungsprozess auf einer nächsthöheren Stufe gestellt wird. Vor- zugsweise wird in einem solchen Fall die entsprechende Server-Maschine bei weiteren Anfragen umgangen und die entsprechenden Anfragen an andere Server-Maschinen geleitet, die Lastverteilungsprozesse derselben Stufe durchführen.
Ein zweiter, Client-bezogener Aspekt der vorliegenden Erfindung ist ein Client- Verfahren zum Herunterladen einer als Film wiedergebbaren Mediendatei von einem Server an einen Client, umfassend abgesichertes Herunterladen der Mediendatei von einem Server zum Client, wobei der Client die Mediendatei in Form einer Vielzahl getrennter Dateiabschnitte, die jeweils eine Vielzahl zusammenhängender Datenblöcke umfassen, individuell anfordert, vom Server herunterlädt und quittiert;
Wiedergabe der Mediendatei ab einem bestimmten Zeitpunkt während des Herunterladens; - wiederholtes Übermitteln von Wiedergabestatusinformation vom Client an den Server während des Herunterladens, wobei die Wiedergabestatusinformation einen jeweils aktuellen Stand der Wiedergabe der Mediendatei beim Client angibt;
Empfangen der Mediendatei vom Server her mit einer Datenrate, deren aktueller Wert von der zuvor übermittelten Wiedergabestatusinformation abhängt. Das erfindungsgemäße Client- Verfahren des vorliegenden Aspekts beinhaltet ein wiederholtes Übermitteln von Wiedergabestatusinformation vom Client an den Server während des Herunterladens, wobei die Wiedergabestatusinformation einen jeweils aktuellen Stand der Wiedergabe der Mediendatei beim Client angibt. Durch dieses Übermitteln der Wiedergabestatusinformation an den Server erhält der Client die Mediendatei vom Server her mit einer Datenrate, deren aktueller Wert von der zuvor übermittelten Wiedergabestatusinformation abhängt.
Das erfindungsgemäße Client-Verfahren und das erfindungsgemäße Server-Verfahren bedingen einander also. Eines kann das andere nicht ausgeführt werden.
Dementsprechend sind auch die zusätzlichen Merkmale der oben beschriebenen Ausfüh- rungsbeispiele des erfindungsgemäßen Server-Verfahrens beim Client wahrnehmbar. So ist beispielsweise die Zeitverzögerung, die der Server zur Anpassung der Datenrate einstellt, beim Client durch eine entsprechend veränderte Datenrate beim Empfang der Mediendatei feststellbar. Ebenso wird bei zusätzlicher oder alternativer serverseitiger Verwendung einer Kodierung mit variabler Länge der Client in einem Ausführungsbeispiel des erfindungsgemäßen Client-Verfahrens die mit variabler Länge kodierten Dateiabschnitte empfangen und dekodieren. Bei der Dekodierung ordnet das Client-Verfahren ein mit jeweiliger Länge empfangenes kodiertes Zeichen eindeutig einem entsprechenden unkodierten Zeichen zu. Das Dekodierungsverfahren unterscheidet sich also von aus dem Stand der Technik bekannten Verfahren wie UTF-8 darin, dass der Client in der Lage ist, zwei oder mehr kodierte Zeichen eindeutig genau einem jeweiligen unkodierten Zeichen zuzuordnen und je nach aktuell zu dekodierendem Zeichen eine solche eindeutige Zuordnung vornimmt. Was also unter UTF-8 als Kodierungsfehler betrachtet wird, liefert in diesem Ausführungsbeispiel den Vorteil einer Stellschraube für die Datenrate.
Das Client-Verfahren enthält in einem bevorzugten Ausführungsbeispiel die folgenden zusätzlichen Schritte:
Puffern empfangener Dateiabschnitte beim Client; Ermitteln einer Dateigröße der Mediendatei;
Wiederholtes Ermitteln einer aktuellen Datenrate des Herunterladens der Mediendatei vom Server zum Client während des Pufferns; - Beginn der Wiedergabe der gepufferten Dateiabschnitte der Mediendatei beim Client zu einem Zeitpunkt, an dem das Herunterladen noch nicht beendet ist, an dem jedoch angesichts der ermittelten Werte der Datenrate und der Dateigröße eine vorbestimmte Mindestwahrscheinlichkeit erreicht ist, dass die weitere Wiedergabe der Mediendatei parallel zum Fortgang des Herunterladens bis zum Abschluss der Wiedergabe der vollständigen Mediendatei unterbrechungsfrei verlaufen wird.
Diese Ausführungsform des Client-Verfahrens stellt sicher, dass die Wiedergabe der Mediendatei zu einem frühestmöglichen Zeitpunkt begonnen wird, an dem absehbar ist, dass die unterbrechungsfreie Wiedergabe der Mediendatei parallel zum Fortgang des Herunterladens möglich ist. Weitere Ausführungsformen des Client-Verfahrens ergeben sich aus der Offenbarung der früheren Patentanmeldung DE 10 2008 020 807.8 der vorliegenden Anmelderin, deren Offenbarung im Sinne einer Incorporation-by-Reference vollständig in die vorliegende Anmeldung mit einbezogen wird.
Bei dem zuletzt beschriebenen Ausführungsbeispiel ermittelt der Client vorzugweise anhand der ermittelten Datenrate ein benötigtes Pufferspeichervolumen und reserviert dieses. Das Pufferspeichervolumen kann in einer Variante bei Bedarf angepasst werden.
Die vom Client ermittelte aktuelle Datenrate wird in einer Ausführungsform an den Server übertragen. Dies ist insbesondere dann sinnvoll, wenn der Client die Datenrate selbst berechnet. Wenn der Server in einer alternativen Ausführungsform bereits über einen aktuellen Wert der Datenrate verfügt, ist diese Übertragung vom Client zum Server in einer Ausführungsform nicht vorgesehen. In einer Variante des erfindungsgemäßen Client-Verfahrens führt der Client eine Form der Lastverteilung durch. Der Client wählt bei dieser Ausführungsform für das Herunterladen der Mediendatei oder eines jeweiligen Dateiabschnitts der Mediendatei einen Server aus einer Vielzahl vorgegebener Server- Adressen nach einem Lastverteilungs-Algorithmus aus. Der Lastverteilungs-Algorithmus kann bei dieser Ausführungsform vom Client selbst ausgeführt werden.
Alternativ wird die tatsächliche Ausführung des Lastverteilungs-Algorithmus von einem externen Lastverteilungs-Server ausgeführt und dem Client eine Vielzahl von Serverad- ressen zur Auswahl mitgeteilt. Der Client wählt zum Herunterladen einer Mediendatei eine Serveradresse aus dieser Vielzahl aus, beispielsweise nach einem statistischen Lastverteilungs-Algorithmus. Der Lastverteilungs-Server sendet in einer Variante zusätzlich eine Priorisierung der Serveradressen mit, in dem Sinne, dass der Client zum Herunterladen Server in einer bestimmten Reihenfolge anspricht, und bei Überlastung eines angesprochenen Servers den Server mit der nächstniedrigeren Priorität anspricht. In einer anderen Variante verfügt der Client ohne vorherige Mitteilung über gespeicherte Serveradressen, mit oder ohne Priorisierung. Die Serveradressen identifizieren bevorzugt Lastverteilungs-Server, die dazu dienen, einen weiteren Lastverteilungs-Server einer nächsthöheren Stufe auszuwählen. Nachfolgend werden Ausführungsbeispiele beschrieben, deren zusätzliche Merkmale sowohl das Server-Verfahren nach dem ersten Aspekt der vorliegenden Erfindung als auch das Client-Verfahren nach dem zweiten Aspekt der vorliegenden Erfindung ergänzen können. Die jeweiligen zusätzlichen Merkmale der nachfolgend beschriebenen Ausführungsbeispiele können mit den Merkmalen der in dieser Anmeldung beschriebe- nen Ausführungsformen des Server-Verfahrens oder des Client-Verfahrens kombiniert werden.
Die Dateiabschnitte der Mediendatei transportieren vorzugsweise eine Datenmenge von zwischen 0,3 und maximal 2 MByte. Bevorzugt ist derzeit der Bereich von 0,5 bis 1 MByte. Damit wird insbesondere bei Übertragung der Mediendatei über ein Best-Effort- Netzwerk wie das Internet eine Erhöhung der effektiven Herunterlade-Geschwindigkeit erreicht. Bei bekannten lntemet-Protokoll(IP)-basierten Best-Effort-Netzwerken wird die Herunterlade-Geschwindigkeit dann reduziert, wenn die Zeitspanne wächst, die für die Signalisierung der Empfangsquittung eines jeweiligen Datenabschnitts vom Client an den Server benötigt wird. Wird beispielsweise das Protokoll http verwendet, so muss beim Stand der Technik für Dateiabschnitte in einer Größe von nur 64 kByte eine Empfangsquittung vom Client an den Server gesendet werden, bevor der Server mit dem nächsten Dateiabschnitt beginnt. Durch Reduzierung der Anlässe für die Signalisierung einer Empfangsquittung wird der hierfür benötigte Anteil der Signalisierung an der Übertragung der gesamten Mediendatei und der mit der Signalisierung verbundenen Wartezeiten reduziert und somit die effektive Herunterlade-Geschwindigkeit erhöht.
Vorzugsweise sind bei dieser Verfahrensführung die Dateiabschnitte einer Mediendatei von zu mindest ungefähr gleicher Größe. Dies erleichtert eine genauere Vorausberech- nung der für das Herunterladen der Mediendatei benötigten Zeit, weil der Berechnung eine genaue Annahme über den Zeitanteil der Signalisierung zugrunde gelegt werden kann.
Eine weitere Erhöhung der effektiven Herunterlade-Geschwindigkeit kann erzielt werden, wenn das Herunterladen der Dateiabschnitte in mindestens zwei parallelen Herunterlade- Prozessen gleichzeitig durchgeführt wird, wobei in den para))e)en HerunterJade- Prozessen unterschiedliche Dateiabschnitte der Mediendatei heruntergeladen werden. Ein solches sog. Multithread-Verfahren mit beispielsweise drei parallelen Herunterlade- Prozessen kann die zur Verfügung stehende Übertragungsbandbreite noch besser nutzen, weil während der Wartezeiten eines Herunterlade-Prozesses im Zuge der notwendi- gen Signalisierung der oder die anderen Herunterlade-Prozesse parallel weiter laufen und die zur Verfügung stehende Übertragungskapazität nutzen.
Die vorstehend beschriebenen Aspekte der Erfindung können auch in Computerprogramm-Produkten verkörpert sein.
Einen dritten Aspekt der vorliegenden Erfindung bildet ein Computerprogramm zum Steuern einer oder mehrerer Servermaschinen zur Durchführung eines Server- Verfahrens nach dem ersten Aspekt der Erfindung oder einem der hier offenbaren Ausführungsbeispiele dieses Server- Verfahrens. Das Computerprogramm ist in unterschiedlichen Ausführungsbeispielen als direkt ausführbare Datei oder als Gruppe ausführbarer Dateien oder als Installations-Paket ausgebildet, bei dem die das Server-Verfahren implementierenden ausführbaren Dateien erst nach einem Installationsprozess auf einer Server-Anordnung vorliegen. Einen vierten Aspekt der vorliegenden Erfindung bildet ein Computerprogramm zum Steuern eines Clientgeräts zur Durchführung eines Client- Verfahrens nach dem zweiten Aspekt der Erfindung oder einem der hier offenbaren Ausführungsbeispiele dieses Client- Verfahrens. Auch dieses Computerprogramm ist in unterschiedlichen Ausführungsbei- spielen als direkt ausführbare Datei oder als Gruppe ausführbarer Dateien oder als Installations-Paket ausgebildet, bei dem die das Client- Verfahren implementierenden ausführbaren Dateien erst nach einem Installationsprozess auf einem Clientgerät vorliegen.
Die Erfindung kann auch in einer Server-Anordnung oder in einem Clientgerät verkörpert sein.
Einen fünften Aspekt der vorliegenden Erfindung bildet eine Server-Anordnung. Die erfindungsgemäße Server-Anordnung ist ausgebildet, das Server-Verfahren des ersten Aspekts der Erfindung oder eines der offenbarten Ausführungsbeispiele des Server- Verfahrens durchzuführen. Die Server-Anordnung des vierten Aspekts der Erfindung teilt daher die Vorteile des oben beschriebenen Server-Verfahrens gemäß dem ersten Aspekt der Erfindung.
Die Server-Anordnung umfasst mindestens eine Servermaschine. Als Servermaschine kann ein zur eigenständigen Durchführung des Server-Verfahrens eingerichteter Computer oder ein zur Beteiligung an der Durchführung des Server-Verfahrens eingerichteter Computer verstanden werden. Die Server-Anordnung kann beispielsweise so eingerichtet sein, dass die Ausführung einer Instanz oder mehrerer paralleler Instanzen des erfindungsgemäßen Server-Verfahrens verteilt ist, also von einer Vielzahl Computer geteilt wird, ohne dass die Durchführung einer jeweiligen Instanz des Server-Verfahrens notwendigerweise dauerhaft genau einem Computer zugeordnet ist. Letztere Variante hat den Vorteil einer Hardware-nahen Lastverteilung und einer erhöhten Ausfallsicherheit bei einem Ausfall eines Computers der Server-Anordnung.
Eine solche Server-Anordnung in ihrer Gesamtheit umfasst in einem Ausführungsbeispiel
Speichermittel, etwa in Form eines Speichergeräts, zum Bereitstellen mindestens einer als Film wiedergebbaren Mediendatei; und Herunterlade-Steuermittel, etwa in Form einer Steuereinheit, die ausgebildet sind zum abgesicherten Herunterladen der Mediendatei an einen Client in Form einer Vielzahl getrennter Dateiabschnitte, die jeweils eine Vielzahl zusammenhängender Datenblöcke umfassen,
Herunterladen jedes Dateiabschnitts der Mediendatei an den Client auf Empfang einer individuellen Anforderung hin
Beenden des Herunterladens des jeweiligen Dateiabschnitts mit Empfang einer Quittung vom Client. - Wiederholten Empfangen vom Client gesendeter Wiedergabestatusinformation während des Herunterladens, wobei die Wiedergabestatusinformation einen jeweils aktuellen Stand der Wiedergabe der Mediendatei beim Client angibt;
Adaptiven Einstellen einer zeitlich gemittelten Datenrate des Herunterladens der Mediendatei in Abhängigkeit von der empfangenen Wiedergabestatusinforma- tion.
Einen sechsten Aspekt der vorliegenden Erfindung bildet ein Clientgerät zum Herunterladen einer als Film wiedergebbaren Mediendatei von einem Server. In unterschiedlichen Ausführungsbeispielen ist das erfindungsgemäße Clientgerät ausgebildet zur Ausführung des Client-Verfahrens gemäß dem zweiten Aspekt der Erfindung oder zur Ausführung eines der offenbarten Ausführungsbeispiele dieses Client-Verfahrens.
Das Clientgerät des vorliegen Aspekts der Erfindung teilt die Vorteile des oben beschriebenen Client-Verfahrens gemäß dem zweiten Aspekt der Erfindung.
Das Clientgerät umfasst in einem Ausführungsbeispiel eine Herunterlade-Einheit, die zum abgesicherten Herunterladen der Mediendatei von einem Server ausgebildet ist, wobei die Herunterlade-Einheit ausgebildet ist, die
Mediendatei in Form einer Vielzahl getrennter Dateiabschnitte, die jeweils eine Vielzahl zusammenhängender Datenblöcke umfassen, individuell anzufordern, vom Server herunterzuladen und zu quittieren, eine Wiedergabe-Steuereinheit, die ausgebildet ist, anhand der Mediendatei Signale zu erzeugen und auszugeben, die die Wiedergabe der Mediendatei an einem Wieder- gabegerät ab einem bestimmten Zeitpunkt während des Herunterladens steuern; wobei die Herunterlade-Einheit ausgebildet ist, während des Herunterladens wiederholt Wiedergabestatusinformation an den Server zu übermitteln, wobei die Wiedergabestatusinformation einen jeweils aktuellen Stand der Wiedergabe der Mediendatei beim Client angibt; und - die Mediendatei vom Server her mit einer veränderlichen Datenrate, die von der übermittelten Wiedergabestatusinformation abhängt, zu empfangen.
Das oben beschriebene Ausführungsbeispiel des Client-Verfahrens, beim dem die heruntergeladenen Dateiabschnitte vor der Wiedergabe zunächst gepuffert werden, wird vorzugsweise mit einem Clientgerät ausgeführt, das einen Pufferspeicher zum Puffern empfangener Dateiabschnitte vor dem Beginn ihrer Wiedergabe enthält, wobei die Wiedergabe-Steuereinheit ausgebildet ist zum Ermitteln einer Dateigröße der Mediendatei. Weiterhin ist die Wiedergabe-Steuereinheit ausgebildet zum Steuern des Beginns einer Wiedergabe der gepufferten Dateiabschnitte der Mediendatei zu einem Zeitpunkt, an dem das Herunterladen noch nicht beendet ist, an dem jedoch angesichts eines aktuellen Wertes einer Datenrate des Herunterladens, und angesichts der Dateigröße der Mediendatei eine vorbestimmte Mindestwahrscheinlichkeit erreicht ist, dass die weitere Wiedergabe der Mediendatei parallel zum Fortgang des Herunterladens bis zum Abschluss der Wiedergabe der vollständigen Mediendatei unterbrechungsfrei verlaufen wird.
Nachfolgend werden weitere Ausführungsbeispiele der verschiedenen Aspekte der Erfindung unter Bezugnahme auf die beiliegenden Figuren beschrieben.
Fig. 1 zeigt ein vereinfachtes Flussdiagramm eines Server-Verfahrens zum Übertragen einer Mediendatei vom Server an einen Client.
Fig. 2 zeigt ein vereinfachtes Blockschaltbild eines im Rahmen eines Server-Verfahrens ausführbaren Lastverteilungs-Prozesses. Fig. 3 zeigt ein schematisches Blockdiagramm einer Server-Anordnung nach einem Ausführungsbeispiel der vorliegenden Erfindung.
Fig. 4 zeigt ein vereinfachtes Flussdiagramm eines kleinen Verfahrens zum Herunterladen einer Mediendatei von einem Server an den Client. Ein vereinfachtes Flussdiagramm eines Server-Verfahrens zum Übertragen einer Mediendatei vom Server an einen Client ist in Fig. 1 dargestellt.
In einem Schritt 100 wird von einem Client her eine Anfrage zum abgesicherten Herunterladen einer Mediendatei empfangen. Das Server-Verfahren startet darauf hin einen Herunterlade-Prozess in einem Schritt 102. Sinnvollerweise wird der Anfrage zum Download der Mediendatei ein von Server und Client durchgeführtes Anmeldeverfahren (logon, Authentifizierung) vorgeschaltet. Dies jedoch hier nicht näher dargestellt. Das Server-Verfahren auch insofern vereinfacht dargestellt, als es auf mehrere Server verteilt und in Wechselwirkung mit einem Lastverteilungsverfahren ausgeführt werden kann. Dies wird weiter unten näher erläutert. Der Start des Herunterlade-Prozesses im Schritt 102 löst serverseitig das Ermitteln der Verfügbarkeit der angefragten Mediendatei sowie gegebenenfalls ihres Speicherorts aus. Diese Schritte sind hier der Einfachheit halber nicht dargestellt. In einem Schritt 104 wird bei positivem Ergebnis der im Zusammenhang mit dem Prozessstarts ausgeführten Teilschritte im Schritt 102 dem Client die Bereit- schaft zum Herunterladen der Mediendatei angezeigt. Hierbei kann das Server-Verfahren beispielsweise eine Adresse einer für den Herunterlade-Prozess verantwortlichen Download-Server-Maschine und Identifikationsdaten für den durchzuführenden Herunterlade- Prozess („Ticket") übermitteln. Dieses Ticket wird der Client im nachfolgenden Verlauf des Herunterlade-Prozesses im Zusammenhang mit seinen Anfragen zum Herunterladen von Dateiabschnitten der betreffenden Mediendatei der zugewiesenen Server-Maschine übersenden.
In einem Schritt 106 empfängt der Server oder die Server-Anordnung dann eine entsprechende Anfrage des Clients zum Herunterladen eines ersten Dateiabschnitts der angefragten Mediendatei. Hier nicht dargestellt und in einer vorausgehenden Kommunikation durchführbar sind Schritte zur Übermittlung von Dateiparametern der Mediendatei vom Server an den Client. Beispielsweise können diese Parameter die Dateigröße, die Wiedergabe Zeit, die Größe von Dateiabschnitten der Mediendatei, die Anzahl von Dateiabschnitten der Me- diendatei, Informationen über Kopierschutzeigenschaften (Digital Rights Management, DRM), Angaben zu verfügbaren Indexdateien oder andere Informationen beinhalten.
Das Server-Verfahren beinhaltet zusätzlich einen dem Herunterlade-Prozess zugeordneten Datenraten-Steuerungsprozess, der parallel zum Herunterlade-Prozess arbeitet und mit diesen Informationen austauscht, wie nachfolgend näher beschrieben. Der Datenra- ten-Steuerungsprozess wird in einem Schritt 152 gestartet. Der Datenraten- Steuerungsprozess wird sinnvollerweise für jeden Herunterlade-Prozess einer Mediendatei nur einmal gestartet, und nicht bei jeder empfangenen Anfrage zum Herunterladen eines Dateiabschnitts derselben Mediendatei erneut aufgerufen.
Nachdem der Herunterlade-Prozess die Bereitschaft zum Herunterladen im Schritt 104 bestätigt und im Schritt 106 eine Anfrage zum Herunterladen eines Dateiabschnitts empfangen hat, ermittelt der Datenraten-Steuerungsprozess aktuelle Wiedergabestatusinformationen für den betreffenden Herunterlade-Prozess (Schritt 154). Die Wiedergabestatusinformation betrifft in einem Ausführungsbeispiel den aktuellen Zustand des Wiedergabeprozesses beim Client oder eine erfolgte Änderung dieses Zustands. Der Zu- stand kann beispielsweise durch Abspielen (Wiedergabe, engl, play), Abbrechen der Wiedergabe (stop), Unterbrechung der Wiedergabe (pause), Vorwärtsspulen (fast for- ward), Zurückspulen (fast reverse) beschrieben werden. Weitere Wiedergabemodi wie beispielsweise verlangsamte Wiedergabe (slow motion) etc. können ebenfalls angegeben werden. Eine besondere Wiedergabestatusinformation ist dadurch charakterisiert, dass während des Herunterlade-Prozesses der Mediendatei beim Abspielen bei einem Client ein Zustand eintritt, in dem eine vorgegebene Mindestanzahl an gepufferten Dateiabschnitten beim Client unterschritten wird. Dies veranlasst den Server, im Datenraten- Steuerungsprozess dem betroffenen Herunterlade-Prozess eine höhere Priorität und damit eine höhere Datenrate zuzuweisen.
In bestimmten Ausführungsformen ist vorgesehen, dass nur eine Auswahl der genannten Wiedergabeprozesse kommuniziert wird. In einer Verfahrensvariante wird an dieser Stelle nur auf das Vorliegen neuer Wiedergabestatusinformation, also eine Änderung gegenüber der zuletzt gültigen Wiedergabestatusinformation geprüft.
Handelt es sich um den ersten Dateiabschnitt einer Mediendatei, kann der Schritt 154 übersprungen werden.
In einer weiteren Variante übermittelt der Client dem Server als Wiedergabestatusinformationen auch eine Pufferphase vor dem Beginn der Wiedergabe der Mediendatei. Diese Phase beginnt typischerweise unmittelbar mit einer Anfrage zum Herunterladen der Mediendatei im Schritt 100. Die an den jeweiligen Herunterlade-Prozess zuzuweisende Datenrate wird in einem Schritt 156 serverseitig ermittelt und in einem darauf folgenden Schritt 158 dem Herunterlade-Prozess übergeben. Die zugewiesene Datenrate ist von der ermittelten Wiedergabestatusinformation abhängig.
Die Berechnung der Datenrate für einen jeweiligen Herunterlade-Prozess wird in einer Variante von einem Lastverteilungs-Server durchgeführt und einem Download-Server als Steuerinformation übermittelt. Dies wird weiter unten anhand von Fig. 3 näher erläutert.
Der Herunterlade-Prozess (beim Download-Server) empfängt die Datenrateninformation in einem entsprechenden Schritt 108.
Einzelheiten zur Ermittlung der zuzuweisenden Datenrate im Schritt 156 werden nachfol- gend erläutert. Die Datenrate kann über eine Variation der Dauer einer serverseitig eingefügten Sendeverzögerung (Wartezeitspanne) vor dem Versenden eines Dateiabschnittes gesteuert werden. Ausgehend von einer mittleren Sendeverzögerung von beispielsweise 100ms vor jedem Versenden eines Dateiabschnitts, kann durch Erhöhung oder Verringerung dieser Zeitspanne eine Verringerung oder Erhöhung der Datenrate des Herunterladens erzielt werden. Eine Ergänzung oder Alternative ist die Verwendung einer variablen Kodierung der Mediendatei beim Übersenden. Diese Variante wurde oben bereits näher erläutert.
Der Herunterlade-Prozess im Server-Verfahren erfolgt also durch das Herunterladen der Dateiabschnitte mit der aktuell zugewiesenen Datenrate. Die Dateiabschnitte werden getrennt heruntergeladen, Dateiabschnitt für Dateiabschnitt. Jeder Dateiabschnitt wird also individuell angefragt, heruntergeladen und vom Client quittiert.
Bei dem Server-Verfahren wird das Herunterladen der Mediendatei mit Dateiabschnitten einer Datenmenge von 0,5 bis 1 MByte durchgeführt. Die Dateiabschnitte liefern also„am Stück" eine Datenmenge von 0,5 bis 1 MByte. Dies ist eine gegenüber üblichen Download-Prozessen (64 kByte) wesentlich erhöhte Datenmenge und bedingt eine sehr hohe Effizienz des Herunterlade-Prozesses, wie ebenfalls bereits oben näher erläutert wurde. wobei die Datenrate während des Herunterlade-Prozesses durch den Datenraten- Steuerungsprozess adaptiv eingestellt wird. Pro Dateiabschnitt empfängt der Server in einem Schritt 112 jeweils eine Empfangsquittung vom Client.
Der Herunterlade-Prozess verwendet ein Best-Effort-Netzwerk, wegen seiner hohen Verbreitung vorzugsweise ein IP(lntemet Protocol)-basiertes Netzwerk. Das abgesicherte Herunterladen wird bei dem Ausführungsbeispiel der Figur 1 mit Hilfe des Protokolls http (Hypertext Transfer Protocol) durchgeführt. Mit diesem Verfahren gelingt es, Mediendateien wie beispielsweise Video-Dateien in einem Video-on-Demand-Dienst mit großer Geschwindigkeit und geringen Kosten bei höchster Datenqualität zu übermitteln. Hierbei ist zu beachten, dass die Datenrate des Herunterladens normalerweise sinkt, wenn die Paketlaufzeit zwischen Server und Client ansteigt. Ein ungefähres Maß für die Paketlaufzeit ist die„Ping-Zeit". Hintergrund der Geschwindigkeitsreduzierung des Herunterlade-Prozesses beim Stand der Technik ist, dass der Client für jeden 64-kByte-Block den korrekten Empfang bestätigen muss, bevor der Server den nächsten Block versenden kann. Bei einer Datenverbindung über DSL mit einer Bandbreite von 2 Mbit/s und einer Ping-Zeit von 80 ms reduziert sich die Datenrate des Herunterladens auf etwa 1 ,5 Mbit/s, was einem Geschwindigkeitsverlust von etwa 25% entspricht. Bei einer Datenrate von 16 Mbit/s und gleicher Ping-Zeit ist eine Datenübertragung mit einer Datenrate von 4,5 Mbit/s möglich. Dies entspricht jedoch nur 29 % der nominellen Datenrate von 16 Mbit/s.
Der Herunterlade-Prozess einer Mediendatei gemäß Fig. 1 kann für mehrere Dateiabschnitte parallel, also als Multithread-Prozess durchgeführt werden. Beispielsweise können drei Dateiabschnitte ein und derselben Mediendatei parallel heruntergeladen werden. Dies hat den Vorteil, dass Übertragungslücken, während derer Quittungspakete vom Client zum Server gesendet werden, durch die Übertragung anderer Dateiabschnitte in anderen Threads genutzt werden können. Bei Verwendung von drei Threads kann für eine nominelle Datenrate von 2 Mbit/s eine effektive Übertragungsrate sehr nah an 100% dieses theoretischen Maximums, und bei einer nominellen Datenrate von 16 Mbit/s eine effektive Datenrate von fast 13,6 Mbit/s, enstprechend 87 % des theoretischen Maximums erreicht werden. Diese Datenraten sind hoch genug, um Videodateien in HD(high definition)-Auflösung zu übertragen, ohne einem Client eine lange Wartezeit vor dem Beginn der Wiedergabe aufzuerlegen.
Mit einem abgesicherten Herunterlade-Prozess auf der Basis des Protokolls http kann darüber hinaus eine Kostenreduktion gegenüber bekannten Streaming-Prozessen erreicht werden. Zum einen ist die Verwendung von Web-Servern zur Lieferung der Mediendateien für ein gegebenes Datenvolumen um einen Faktor von zwei bis drei geringer im Vergleich mit Servern für Streaming-Prozesse. Zum anderen ermöglicht die Verwendung eines Herunterlade-Prozesses im Gegensatz zu einem Streaming-Prozess die Verwendung variabler Bitraten beim Kodieren der Mediendatei. Die Verwendung variabler Bitraten erspart 25 % bis 50 % des zu übertragenden Datenvolumens, im Vergleich mit einer konstanten Bitrate, wie sie im Streaming-Verfahren verwendet wird. Insgesamt kann daher für jede Stunde der Wiedergabezeit einer Mediendatei mit einem Herunterlade- Prozess ein um den Faktor fünf reduzierter Kostenanteil erzielt werden. Die vom Client her empfangene und an den Datenraten-Steuerungsprozess übergebene Wiedergabestatusinformation (Schritt 154) kann beispielsweise im Zusammenhang mit der Quittung eines jeweiligen Dateiabschnittes vom Client an den Server übermittelt werden. Die Zeitspanne zwischen aufeinanderfolgenden Übertragungen von Wiedergabestatusinformationen ist jedoch nicht notwendigerweise an Zeitabstände zwischen dem Herunterladen von Dateiabschnitten der Mediendatei gebunden. Die Wiedergabestatusinformation kann auch unabhängig von der Quittung vom Client an den Server gesendet werden. Wiedergabestatusinformation kann beispielsweise vom Client nur dann an den Server übertragen werden, wenn beim Wiedergabeprozess auf der Seite des Clients Änderungen eintreten. Figur 2 zeigt ein vereinfachtes Flussdiagramm eines serverseitigen Lastverteilungs- Prozesses. Die in Figur 2 dargestellten Schritte des Lastverteilungs-Prozesses werden typischer Weise von einer Server-Maschine durchgeführt, die mit dem Herunterladen der angefragten Mediendateien an aktive Clients befasst ist. Eine solche Server-Maschine wird hier auch als Download(DL)-Server bezeichnet. Der für den Download-Server lokale Server-Lastverteilungs-Prozess wird in einem Schritt 202 gestartet. Anschließend werden aktuelle Wiedergabeinformationen empfangen, die aktiven Herunterlade-Prozessen zugeordnet sind (Schritt 204). Die Wiedergabeinformationen der verschiedenen aktiven Herunterlade-Prozesse werden serverseitig ausgewertet, um die einzelnen Datenraten der verschiedenen Herunterlade-Prozesse unter Be- rücksichtigung der Gesamtkapazität der betreffenden Server-Maschine zum Betreiben der Herunterlade-Prozesse zu ermitteln (Schritt 206) und zuzuweisen (Schritt 208).
Statistiken zeigen, dass viele Mediendateien nur teilweise wiedergegeben werden und bis zu 50% des heruntergeladenen Datenvolumens tatsächlich nicht benötigt wird. Bei der Ermittlung der neuen Datenraten wird berücksichtigt, dass alle vom der jeweiligen Server- Maschine betreuten Clients eine ausreichende Datenmenge gepuffert halten können, um die Wiedergabe ohne Unterbrechung fortsetzen zu können. Dieser Puffer- Vorsprung wird jedoch begrenzt und nicht beliebig ausgebaut, um das Volumen übertragener, letztlich aber nicht wiedergegebener Daten gering zu halten.
Die zur Verfügung stehende Bandbreite, die ein jeweiliger Download-Server bedienen kann, ist nicht konstant. Ihr aktueller Wert hängt von vielen Faktoren ab, die serverseitig nicht gesteuert werden können. Bei der Ermittlung der neuen Datenraten für die aktiven Herunterlade-Prozesse wird daher im vorliegenden Beispiel zusätzlich die aktuell zur Verfügung stehende Bandbreite der jeweiligen Herunterlade-Prozesse berücksichtigt. Die ermittelten neuen Datenraten für die aktiven Herunterlade-Prozesse werden im Schritt 208 an die zugeordneten aktiven Datenraten-Steuerungsprozesse (vgl. Fig. 1 ) übermittelt.
Anhand der zugewiesenen Datenraten wird eine aktuelle Lastinformation des betreffenden Download-Servers bestimmt und an einen zugeordneten Lastverteilungs-Server (engl, loadbalancing (LB) Server) übermittelt (Schritt 210). Die Lastinformation kann beispielsweise mit Hilfe von Verzögerungszeiten ermittelt werden, die den einzelnen Herunterlade-Prozessen zur Steuerung der jeweiligen Datenraten zugewiesen werden. Je geringer die Summe der zugewiesenen Verzögerungszeiten aller aktiven Herunteria- de-Prozesse ist, desto größer ist die vom Download-Server aktuell zu bewältigende Last. Dies wird nachfolgend an einem konkreten Beispiel näher erläutert. Typischer Weise muss bei hoher Last der Download-Server für mindestens einen Client, der sich in der Wiedergabe der Mediendatei befindet, eine hohe Datenrate bereitstellen, also eine Ver- zögerungszeit im Herunterlade-Prozess von weniger als 100 Millisekunden sicherstellen. Wenn in dieser Situation im nachfolgenden Schritt 212 ermittelt wird, dass eine neue Anfrage dem betreffenden Download-Server zugewiesen wurde, wird im Schritt 214 dieser Anfrage eine Startdatenrate zugewiesen, die anhand der aktuellen Lastinformation und/oder der Wiedergabeinformationen ermittelt wird. Bei der gegebenen hohen Auslas- tung wird die Verzögerungszeit für die neue Anfrage während des Pufferns beim Client auf einen hohen Wert gesetzt, beispielsweise 2000 Millisekunden betragen. Die resultierende Verzögerungszeit für den betreffenden neuen Herunterlade-Prozess wird hoch gehalten, bis in nachfolgenden Verfahrensschleifen eine geringere Lastinformation des Download-Servers ermittelt wird. Dies ist beispielsweise dann erreicht, wenn alle aktiven Clients, die aktuell die teilweise heruntergeladen Mediendatei abspielen, eine Verzögerungszeit von mehr als 100 Millisekunden haben.
Mit dem beschriebenen Verfahren wird sichergestellt, dass im Falle einer großen Anzahl von Anfragen der Download-Server diejenigen Clients weiterhin bevorzugt bedient, die die Mediendatei aktuell abspielen. Eine Unterbrechung der Wiedergabe bei diesen Clients kann so vermieden werden. Dagegen werden diejenigen Clients, die sich noch in der Pufferphase befinden, mit einer reduzierten Datenrate bedient.
Ein Ausführungsbeispiel einer erfindungsgemäßen Server-Anordnung mit einer Struktur zur effektiven Lastverteilung ist in Figur 3 dargestellt. Im linken Teil der Figur 3 ist die Lastverteilung für Anfrage-Prozesse erläutert. Im rechten Teil der Figur ist die sich an- schließende Verteilung für die Herunterlade-Prozesse schematisch dargestellt.
Zunächst wird auf den linken Teil der Figur 3 Bezug genommen. Eine Vielzahl Clients CL ist in der untersten Ebene der linken Teilfiguren durch eine Anzahl von Blöcken symbolisiert. Jeder der dargestellten und mit dem gemeinsamen Bezugszeichen CL gekennzeichneten Blöcke ist ein individuelles Client-Gerät. Ein Client-Gerät kann als Set-Top- Box zum Anschluss an ein TV-Gerät oder einen Computer des Nutzers sein. Das Clientgerät kann auch durch einen mit einer Software zur Durchführung eines Client- Herunterlade-Verfahrens (vgl. hierzu das Beispiel der Fig. 4) eingerichteten Computer gebildet werden. Jedes Client-Gerät verfügt über eine Anzahl von Server-Adressen, an die eine Anfrage zum Herunterladen einer Mediendatei gerichtet werden kann. Beispielsweise kann jeder Client über eine Liste von insgesamt 10 unterschiedlichen Server-Adressen verfügen. Die Auswahl eines jeweiligen Servers für eine Anfrage erfolgt mit einem vom Client ausge- führten statistischen Lastverteilungsverfahren. Hierzu kann beispielsweise ein Rundlauf- Verfahren (engl. Round-Robin) verwendet werden. Ziel des in jedem Client ausgeführten Rundlauf-Verfahrens ist es, die Auslastung der für die Anfragen des jeweiligen Clients bereitgestellten L1 -Server möglichst gleichmäßig zu gestalten.
Die L1 -Server dienen zur Verteilung der eingehenden Anfragen zum Herunterladen einer Mediendatei auf eine jeweilige Anzahl zugeordneter L2-Server, die wiederum jeweils eine größere Anzahl von Download-Servern im Lastverteilungsprozess verwalten. Beispielsweise kann jeder L1 -Server eine Lastverteilung für bis zu 100 L2-Server steuern. Jeder L2-Server kann in einem solchen Szenario bis zu 100 Download-Servern steuern. Geht man von einer Rate von beispielsweise 10.000 Anfragen pro Sekunde aus, die ein jewei- liger L1 -Server empfängt, so muss jeder von diesem Server gesteuerte L2-Server pro Sekunde etwa 100 Lastverteilungs-Anfragen verarbeiten. Diese Aufgabe kann ohne besonderen Hardware-Aufwand, also mit handelsüblichen Standard-Servern bewältigt werden. Würden hoch performante High-End-Server verwendet, beispielsweise in Form von Blade-Servern, könnte die Leistung noch weiter gesteigert werden. Beim Herunterladen erfolgt die Zuweisung von Herunterlade-Prozessen an einen jeweiligen Download-Server DL über die Lastverteilungs-Server L1 und L2. Ein jeweiliger Download-Server führt für die verschiedenen, ihm zugewiesenen Herunterlade-Prozesse ein Lastverteilungsverfahren durch, wie es anhand von Figur 2 beschrieben wurde. Typischerweise wird dabei eine Mediendatei an einen Client mit einer Mehrzahl paralleler Herunterlade-Prozesse (Multi Thread-Verfahren) heruntergeladen. Dies ist am rechten Rand des rechten Teilbildes der Figur in einer schematisierten Lupe als„Vergrößerung" der Herunterlade-Prozesse für einen einzelnen Client symbolisiert.
Jeder Download-Server kann Anfragen bis zu einer jeweiligen oberen Grenze der Bandbreite herunterladen. Diese Grenze liegt für kostengünstige Server bei etwa 50 bis 80 Mbit/s. Unter Verwendung von High-End-Servem mit besonders hoher Arbeitskapazität kann nach derzeitigem Stand eine Gesamtdatenrate von etwa 8 GBit/s erzielt werden. Bei dieser Kapazität können beispielsweise 200 parallele Herunterlade-Prozesse mit etwa 400 kBit/s von einem einfachen Server verwaltet werden. Diese Anzahl lastet einen High-End-L2-Server nicht aus. Solche L2-Server sind also in der Lage, mehr Anfragen an einen einfachen Download-Server zu liefern, als dieser handhaben kann. Mit aufwändigeren Download-Servern, die eine höhere Übertragungskapazität haben, können High-End- L2-Server voll ausgelastet werden, selbst wenn Mediendateien mit größerer Bandbreite übertragen werden, wie es beispielsweise für Videos mit HD-Format erforderlich ist.
Das anhand von Figur 3 beschriebene Lastverteilungssystem entfaltet auch bei Ausfällen von Server-Maschinen seine Vorteile. Wenn auf einem Niveau in der Lastverteilungskette ein Server ausfällt, wird in einer Ausführungsform der zugeordnete Server auf dem nächsthöheren Niveau angesprochen, um die Zuweisung eines neuen Servers zu erhal- ten.
Figur 4 zeigt ein vereinfachtes Flussdiagramm eines Client-Verfahrens zum Herunterladen einer Mediendatei von einem Server an den Client.
Der Download-Prozess beim Client wird in einem Schritt 402 gestartet. Der Download- Prozess beim Client kann beispielsweise aufgrund einer manuellen Nutzereingabe am Client-Gerät gestartet werden. Jedoch sind auch beliebige andere übliche Auslösetechniken verwendbar, wie beispielsweise ein vorprogrammierter Start einer Abfrage an einen entsprechenden Server eines VoD-Providers. In einem nachfolgenden Schritt 404 wird beim Client ein entsprechender L1 -Server des VoD-Providers ausgewählt. Hierbei wird beispielsweise ein vom Client ausgeführtes Lastverteilungsverfahren ausgeführtt, wie es im Zusammenhang mit Figur 3 beschrieben wurde. Die Anfrage zum Herunterladen einer gewünschten Mediendatei wird an den ausgewählten Servern gesendet (Schritt 406).
Es versteht sich, dass bei einer anderen Serveranordnung als der in Figur 3 beschriebenen, die Ausführung eines Lastverteilungsverfahrens mit der Auswahl eines Lastvertei- lungs-Servers auch wegfallen kann. Beispielsweise kann in einer Variante des Client- Verfahrens auch stets ein einzelner, fest vorgegebener Download-Server angesprochen werden.
Bei Verwendung eines Lastverteilungsverfahrens empfängt der Client in einem nachfolgenden Schritt 408, beispielsweise im Signalisierungsaustausch mit einer Server- Anordnung gemäß Figur 3, die Adresse des ihm zugewiesenden Download-Servers für das Herunterladen der Mediendatei. Anschließend sendet der Client seine Anfrage zum Herunterladen der gewünschten Mediendatei an den zugewiesenden Download-Server (Schritt 410). Nach Erhalt einer Bereitschaftsnachricht vom Download-Server (Schritt 412), mit der sinnvollerweise auch die Dateigröße und/oder ggf. weitere nützliche Informationen über die herunterzuladende Mediendatei übermittelt werden, beginnt das Herunterladen der Mediendatei, Dateiabschnitt für Dateiabschnitt, wobei wie erwähnt vor- zugsweise mindestens zwei Dateiabschnitte in parallelen Herunterlade-Prozessen (threads) heruntergeladen werden. Hierfür sendet der Client jeweils eine Anfrage zum Herunterladen eines betreffenden Dateiabschnitts an den zugewiesenen Download- Server (Schritt 414) und empfängt sowie puffert anschließend den empfangenen Dateianschnitt. Nach vollständigem Empfang des betreffenden Dateiabschnitts sendet der Client eine Empfangsquittung an den Download-Server. Diese Prozessschritte im Zusammenhang mit dem Empfang eines Dateiabschnitts sind in Fig. 4 im Schritt 416 zu- sammengefasst.
Anschließend sendet der Client eine nächste Anfrage zum Herunterladen eines weiteren Dateiabschnitts an den Download-Server. Diese Schleife der Schritte 414 und 416 wird bis zum vollständigen Abschluss den Herunterladens der Mediendatei in den mehreren parallelen Prozessen gleichzeitig wiederholt. Auf diese Weise werden Wartezeiten zwischen den einzelnen Übertragungen beim abgesicherten Herunterladen von Dateiabschnitten effektiv genutzt.
Beim Client wird parallel zum Herunterladeprozess ein Wiedergabe-Prozess durchge- führt. Dieser kann beispielsweise nach dem Empfang des ersten Dateiabschnitts gestartet werden. Ein manuelles Starten, Unterbrechen oder Beenden des Wiedergabe- Prozesses ist selbstverständlich auch möglich, wie bei der Bedienung von Abspielgeräten wie Videorecordern üblich.
Der Wiedergabe-Prozess beim Client beginnt nicht sofort mit dem tatsächlich Abspielen (Wiedergabe, Play) der bereits heruntergeladenen Dateiabschnitte der Mediendatei. Vielmehr wird nach dem Start im Schnitt 418 zunächst eine aktuelle Wiedergabestatusinformation für die betreffende Mediendatei im Client ermittelt und an den im Download- Prozess aktiven Download-Server gesendet (Schritt 420). Denkbar ist natürlich auch die Übersendung an einen anderen Server, der in Figur 3 beschriebenen Server-Anordnung. Der Client prüft weiterhin in einem Schritt 422 den Status des Pufferprozesses für die betreffende Mediendatei, die gerade heruntergeladen wird. Mit dem Start des Abspielens wird im vorliegenden Ausführungsbeispiel bis zu dem Zeitpunkt gewartet, bei dem ange- sichts der aktuellen Menge gepufferter Dateiabschnitte, der bisher erzielten Datenrate im Herunterlade-Prozess und der Gesamtgröße der Mediendatei eine vorbestimmte Mindestwahrscheinlichkeit erreicht ist, dass die weitere Wiedergabe der Mediendatei parallel zum Fortgang des Herunterladens bis zum Abschluss der Wiedergabe der vollständigen Mediendatei unterbrechungsfrei verlaufen wird (Schritt 424). Ist dies nicht der Fall, wird die aktuelle Wiedergabestatusinformation„Puffern" an den Download-Server DL gesendet (Schritt 420) und erneut geprüft (Schritte 422 und 424). Diese Schleife wird durchlaufen, bis nach dem beschrieben Kriterium die Wiedergabe gestartet werden kann (Schritt 426). Anschließend wird die Wiedergabe der Mediendatei fortgesetzt, bis eine Änderung eintritt, also der Nutzer des Clients die Wiedergabe anhält (Pause), abbricht (Stopp) oder sonstige Eingaben macht, die den Wiedergabeprozess betreffen. Eine entsprechende Prüfung läuft während des Abspielens kontinuierlich im Hintergrund (Schritt 428). Tritt eine solche Änderung des Wiedergabestatus gegenüber dem bisherigen Zustand ein, wird eine neue Wiedergabestatusinformation an den Download-Server gesendet. Das Verfahren verzweigt also zurück zu Schritt 420. Wird die Wiedergabe vollständig abgebrochen, kann an dieser Stelle der Herunterlade-Prozess abgebrochen werden (nicht in Fig. 4 dargestellt). Der Abbruch des Herunterladens kann beispielsweise an die Bedingung geknüpft werden, dass der Nutzer den Abbruch durch eine Eingabe ausdrücklich bestätigt.
Wurde die Wiedergabe unterbrochen oder abgebrochen, ohne dass der Herunterlade- Prozess abgebrochen wurde, wird im weiteren Verlauf die Sequenz der Verfahrensschritte 420 bis 424 durchlaufen und darauf gewartet, dass vom Nutzer ein Eingabesignal zur Fortsetzung der Wiedergabe gegeben wird. Ist dies der Fall, wird die Wiedergabe in Schritt 426 fortgesetzt. Falls nicht, wird eine Warteschleife ausgeführt, die in Figur 4 nicht dargestellt ist.
Mit dem vorstehend beschriebenen Client-Verfahren wird eine besonders effektive, auf den tatsächlichen Wiedergabeprozess abgestimmte Handhabung des Download- Prozesses in der Server-Anordnung des Providers, also des Anbieters der Mediendatei ermöglicht.
Das Verfahren wird vorzugsweise mit Hilfe einer entsprechenden Software ausgeführt. Es kann jedoch natürlich auch rein hardwaremäßig implementiert werden.

Claims

Ansprüche
1. Server-Verfahren zum Übertragen einer als Film wiedergebbaren Mediendatei von einem Server an einen Client, umfassend: - Bereitstellen der Mediendatei in Form einer Vielzahl getrennter Dateiabschnitte, die jeweils eine Vielzahl zusammenhängender Datenblöcke umfassen;
Abgesichertes Herunterladen der Mediendatei an den Client, wobei jeder Dateiabschnitt der Mediendatei auf Empfang einer individuellen Anforderung hin vom Server an den Client heruntergeladen wird und das Herunterladen des jeweiligen Dateiabschnitts mit Empfang einer Quittung vom Client endet;
Wiederholtes Empfangen vom Client gesendeter Wiedergabestatusinformation während des Herunterladens, wobei die Wiedergabestatusinformation einen jeweils aktuellen Stand der Wiedergabe der Mediendatei beim Client angibt;
Adaptives Einstellen einer Datenrate für das Herunterladen der Mediendatei, wobei der aktuelle Wert der Datenrate von der zuvor empfangenen Wiedergabestatusinformation abhängt.
2. Server-Verfahren nach Anspruch 1 , bei dem der Server zum Einstellen der Datenrate eine Zeitverzögerung zwischen einem Empfang einer Anfrage zum Herunterladen eines Dateiabschnitts und einem Beginn des Herunterladens des betreffenden Dateiab- Schnitts anpasst.
3. Server-Verfahren nach Anspruch 1 oder 2, bei dem der Server beim Herunterladen der Mediendatei eine Zeichenkodierung variabler Länge verwendet und zum Einstellen der Datenrate die Länge der Zeichenkodierung anpasst.
4. Server-Verfahren nach Anspruch 1 oder 2, bei dem der Server die Datenrate anhand einer zeitlichen Änderung der Wiedergabestatusinformation anpasst.
5. Server-Verfahren nach einem der vorstehenden Ansprüche, bei dem durch eine Verringerung der Datenrate des Herunterladens einer ersten Mediendatei zu einem ersten Client frei werdende Übertragungskapazität für eine Erhöhung der Datenrate des Herunterladens mindestens einer zweiten Mediendatei an mindestens einen zweiten Client oder für mindestens einen angefragten neuen Herunterlade-Prozesses einer dritten Mediendatei an einen dritten Client genutzt wird.
6. Server-Verfahren nach einem der vorstehenden Ansprüche, bei dem eine Vielzahl von Mediendateien von einer Vielzahl Servermaschinen parallel an eine Vielzahl Clients heruntergeladen werden und eine Lastverteilung zwischen der Vielzahl von Server- Maschinen durchgeführt wird.
7. Server-Verfahren nach Anspruch 6, bei dem die Lastverteilung und das Herunterladen als getrennte Prozesse auf unterschiedlichen, mit einander verbundenen Server- Maschinen durchgeführt werden und der Lastverteilungs-Prozess Herunterlade-Prozesse auf einer Vielzahl zugeordneter Server-Maschinen steuert.
8. Server- Verfahren nach einem der vorstehenden Ansprüche, bei dem eine Vielzahl Kopien einer bestimmten Mediendatei auf einer Vielzahl Server-Maschinen zum Herunterladen bereitgestellt wird, wobei die Anzahl der Server-Maschinen, die eine Kopie der Mediendatei bereitstellen, in Abhängigkeit von einer erwarteten oder ermittelten Häufigkeit von Anfragen zum Herunterladen der Mediendatei bestimmt wird.
9. Client-Verfahren zum Herunterladen einer als Film wiedergebbaren Mediendatei von einem Server an einen Client, umfassend
Abgesichertes Herunterladen der Mediendatei von einem Server zum Client, wobei der Client die Mediendatei in Form einer Vielzahl getrennter Dateiabschnitte, die jeweils eine Vielzahl zusammenhängender Datenblöcke umfassen, individuell anfordert, vom Server herunterlädt und quittiert;
Wiedergabe der Mediendatei ab einem bestimmten Zeitpunkt während des Herunterladens; Wiederholtes Übermitteln von Wiedergabestatusinformation vom Client an den Server während des Herunterladens, wobei die Wiedergabestatusinformation einen jeweils aktuellen Stand der Wiedergabe der Mediendatei beim Client angibt;
Empfangen der Mediendatei vom Server her mit einer Datenrate, deren aktueller Wert von der zuvor übermittelten Wiedergabestatusinformation abhängt.
10. Client- Verfahren nach Anspruch 9, oder Server-Verfahren nach einem der Ansprüche 1 bis 8, bei dem die Dateiabschnitte der Mediendatei eine Datenmenge von zwischen 0,3 und maximal 2 MByte transportieren.
11. Client- Verfahren nach Anspruch 9 oder 10, oder Server- Verfahren nach einem der Ansprüche 1 bis 8 oder 10, bei dem die Mediendatei über ein Best-Effort-Netzwerk heruntergeladen wird.
12. Client-Verfahren nach Anspruch 9 bis 11 , oder Server-Verfahren nach einem der Ansprüche 1 bis 8 oder 10 bis 11 , bei dem das Herunterladen der Dateiabschnitte in mindestens zwei parallelen Herunterlade-Prozessen gleichzeitig durchgeführt wird, wobei in den parallelen Herunterlade-Prozessen unterschiedliche Dateiabschnitte der Mediendatei heruntergeladen werden.
13. Client-Verfahren nach einem der Ansprüche 9 bis 12, mit den zusätzlichen Schritten
Puffern empfangener Dateiabschnitte beim Client; - Ermitteln einer Dateigröße der Mediendatei;
Wiederholtes Ermitteln einer aktuellen Datenrate des Herunterladens der Mediendatei vom Server zum Client während des Pufferns;
Beginn der Wiedergabe der gepufferten Dateiabschnitte der Mediendatei beim Client zu einem Zeitpunkt, an dem das Herunterladen noch nicht beendet ist, an dem jedoch angesichts der ermittelten Werte der Datenrate und der Dateigröße eine vorbestimmte Mindestwahrscheinlichkeit erreicht ist, dass die weitere Wiedergabe der Medien- datei parallel zum Fortgang des Herunterladens bis zum Abschluss der Wiedergabe der vollständigen Mediendatei unterbrechungsfrei verlaufen wird.
14. Client-Verfahren nach Anspruch 13, bei dem der Client anhand der ermittelten Datenrate ein benötigtes Pufferspeichervolumen ermittelt und reserviert.
15. Client- Verfahren nach Anspruch 13 oder 14, bei dem der Client die ermittelte aktuelle Datenrate an den Server überträgt.
16. Client- Verfahren nach einem der Ansprüche 9 bis 15, bei dem der Client für das Herunterladen der Mediendatei oder eines jeweiligen Dateiabschnitts der Mediendatei einen Server anhand einer Vielzahl vorgegebener Serveradressen nach einem Lastver- teilungs-Algorithmus auswählt.
17. Clientgerät zum Herunterladen einer als Film wiedergebbaren Mediendatei von einem Server, umfassend eine Herunterlade-Einheit, die zum abgesicherten Herunterladen der Mediendatei von einem Server ausgebildet ist, wobei die Herunterlade-Einheit ausgebildet ist, die Mediendatei in Form einer Vielzahl getrennter Dateiabschnitte, die jeweils eine Vielzahl zusammenhängender Datenblöcke umfassen, individuell anzufordern, vom Server herunterzuladen und zu quittieren, eine Wiedergabe-Steuereinheit, die ausgebildet ist, anhand der Mediendatei Signale zu erzeugen und auszugeben, die die Wiedergabe der Mediendatei an einem Wieder- gabegerät ab einem bestimmten Zeitpunkt während des Herunterladens steuern; wobei die Herunterlade-Einheit ausgebildet ist, während des Herunterladens wiederholt Wiedergabestatusinformation an den Server zu übermitteln, wobei die Wiedergabestatusinformation einen jeweils aktuellen Stand der Wiedergabe der Mediendatei beim Client angibt; und - die Mediendatei vom Server her mit einer veränderlichen Datenrate, die von der übermittelten Wiedergabestatusinformation abhängt, zu empfangen.
18. Clientgerät nach Anspruch 17, das einen Pufferspeicher zum Puffern empfangener Dateiabschnitte vor dem Beginn ihrer Wiedergabe enthält, wobei die Wiedergabe- Steuereinheit ausgebildet ist zum Ermitteln einer Dateigröße der Mediendatei, zum Steuern des Beginns einer Wiedergabe der gepufferten Dateiabschnitte der Mediendatei zu einem Zeitpunkt, an dem das Herunterladen noch nicht beendet ist, an dem jedoch angesichts eines aktuellen Werts einer Datenrate des Herunterladens und der Dateigröße eine vorbestimmte Mindestwahrscheinlichkeit erreicht ist, dass die weitere Wiedergabe der Mediendatei parallel zum Fortgang des Herunterladens bis zum Abschluss der Wiedergabe der vollständigen Mediendatei unterbrechungsfrei verlaufen wird.
19. Server-Anordnung mit mindestens einer Servermaschine, umfassend
Speichermittel zum Bereitstellen mindestens einer als Film wiedergebbaren Mediendatei;
Herunterlade-Steuermittel, die ausgebildet sind zum abgesicherten Herunterladen der Mediendatei an einen Client in Form einer Vielzahl getrennter Dateiabschnitte, die jeweils eine Vielzahl zusammenhängender
Datenblöcke umfassen,
Herunterladen jedes Dateiabschnitts der Mediendatei an den Client auf Empfang einer individuellen Anforderung hin
Beenden des Herunterladens des jeweiligen Dateiabschnitts mit Empfang einer Quittung vom Client.
Wiederholten Empfangen vom Client gesendeter Wiedergabestatusinformation während des Herunterladens, wobei die Wiedergabestatusinformation einen jeweils aktuellen Stand der Wiedergabe der Mediendatei beim Client angibt;
Adaptiven Einstellen einer zeitlich gemittelten Datenrate des Herunterladens der Mediendatei in Abhängigkeit von der empfangenen Wiedergabestatusinformation.
20. Computerprogramm zum Steuern einer oder mehrerer Servermaschinen zur Durchführung eines Server- Verfahrens nach einem der Ansprüche 1 bis 8 oder 10 bis 12.
21. Computerprogramm zum Steuern eines Clientgeräts zur Durchführung eines Client- Verfahrens nach einem der Ansprüche 9 bis 16 .
EP10731736A 2009-07-16 2010-07-08 Steuerung der datenrate eines medien-downloads anhand von client-wiedergabestatusinformation Withdrawn EP2454863A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102009027773A DE102009027773A1 (de) 2009-07-16 2009-07-16 Steuerung der Datenrate eines Medien-Downloads anhand von Client-Wiedergabestatusinformation
PCT/EP2010/059826 WO2011006834A1 (de) 2009-07-16 2010-07-08 Steuerung der datenrate eines medien-downloads anhand von client-wiedergabestatusinformation

Publications (1)

Publication Number Publication Date
EP2454863A1 true EP2454863A1 (de) 2012-05-23

Family

ID=43221893

Family Applications (1)

Application Number Title Priority Date Filing Date
EP10731736A Withdrawn EP2454863A1 (de) 2009-07-16 2010-07-08 Steuerung der datenrate eines medien-downloads anhand von client-wiedergabestatusinformation

Country Status (3)

Country Link
EP (1) EP2454863A1 (de)
DE (1) DE102009027773A1 (de)
WO (1) WO2011006834A1 (de)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106412636A (zh) * 2015-07-29 2017-02-15 中兴通讯股份有限公司 播放控制方法和装置
CN113382287B (zh) * 2020-03-09 2023-06-09 阿里巴巴集团控股有限公司 媒体文件的播放方法及装置和系统
CN112738270B (zh) 2021-01-07 2022-12-30 苏州浪潮智能科技有限公司 一种文件传输方法、装置、设备及存储介质
US11973823B1 (en) * 2023-01-11 2024-04-30 Dell Products L.P. Offloading namespace redirection to backup clients in a scale out cluster

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100420601B1 (ko) 2001-11-22 2004-03-02 에스케이 텔레콤주식회사 비디오 데이터 스트리밍 서비스 방법
KR100427143B1 (ko) 2003-01-17 2004-04-14 엔에이치엔(주) 스트리밍 데이터 전송 및 다운로드 방법
DE102008020807A1 (de) 2008-04-23 2009-10-29 Itv Solutions Gmbh Client und Server für ein Video on demand-System

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2011006834A1 *

Also Published As

Publication number Publication date
DE102009027773A1 (de) 2011-01-27
WO2011006834A1 (de) 2011-01-20

Similar Documents

Publication Publication Date Title
DE60103005T2 (de) Datenstrom in einer peer-to-peer Architektur
JP5181031B2 (ja) 管理型マルチメディア配信ネットワーク内の回復力の高いサービス品質
DE69930127T2 (de) Kostengünstiger, skalierbarer medienserver mit offener architektur
DE602004006981T2 (de) Datenabrufende und -übertragende vorrichtungen und verfahren
DE60207381T2 (de) Verfahren und system zum puffern von stream-daten
DE60210733T2 (de) System und Verfahren zur Überlastregelung in Netzwerken
DE102012214245B4 (de) Multistream-Datenübertragung
DE112012002159T5 (de) Kontextsensitive Client-Pufferschwellenwerte
DE112012001770T5 (de) Auf Echtzeitverarbeitungsfähigkeit basierende Qualitätsanpassung
US20020175998A1 (en) Data-on-demand digital broadcast system utilizing prefetch data transmission
DE112013002247T5 (de) Kombinierte Broadcast- und Unicast-Übermittlung
WO2008119954A2 (en) Bandwidth allocation control in multiple video streaming
EP2454863A1 (de) Steuerung der datenrate eines medien-downloads anhand von client-wiedergabestatusinformation
EP2938085B1 (de) Verfahren und vorrichtung zur übermittlung von kodierten mediendaten
EP2938047A1 (de) Verfahren, vorrichtung, computerprogramm, softwareprodukt und digitales speichermedium zur übermittlung und adaption von daten
DE102009012992A1 (de) Verfahren und System zum Bereitstellen von Medieninhalten für eine Mehrzahl von Knoten in einem Datennetz
DE10004829B4 (de) Verfahren und Vorrichtung zum Übertragen von Dateneinheiten eines Datenstroms
EP3051769B1 (de) Dynamische schaltung zur rundfunkübertragung von multimedia-inhalt über ein mobiles kommunikationsnetzwerk
EP3114787A1 (de) Vorrichtung und verfahren zur datenübertragung
EP3585059B1 (de) Übertragung von echtzeitdatenpaketen von sendungen aus dem internet
EP2159985A1 (de) Verfahren, Vorrichtung und System zur Ablaufkoordination von Inhalten
CN106792216A (zh) 分布式文件系统中流媒体读取方法及服务器
KR100686395B1 (ko) 패킷 필터링을 통한 네트워크 적응적 생방송 멀티미디어스트리밍 시스템 및 그 방법
Mancuso et al. Improved support for streaming services in vehicular networks
DE10104961A1 (de) Verfahren zur bandbreiteneffizienten Übertragung von Datenströmen in einem IP-Netz

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20120216

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO SE SI SK SM TR

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20161010

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20170421