WO2003045030A1

WO2003045030A1 - Transmission and playing of media data

Info

Publication number: WO2003045030A1
Application number: PCT/EP2002/013136
Authority: WO
Inventors: Ibrahim Evsan
Original assignee: Ibrahim Evsan
Priority date: 2001-11-23
Filing date: 2002-11-22
Publication date: 2003-05-30
Also published as: AU2002352099A1

Abstract

A method for transmitting and playing media data (M), wherein the following steps are at least partially carried out in a parallel manner by a client (16): the media data (M) divided into sections (X1, X2, X3, ... XN) is successively downloaded onto the client (16) and the downloaded sections (X1, X2, X3, ... XN) are played by the client (16) in multimedia mode. Playing begins as soon as possible after the first section (X1, X2, X3, ... XN) has been fully downloaded. The sections (X1, X2, X3, ... XN) are reproduced in a coherent manner when played. A client (16), method for providing media data (M) and a server (12, 14, 14', 14'', ...) exhibit corresponding features. The aim of the invention is to avoid problems arising with known streaming methods.

Description

Transfer and playback of media data

The invention relates to techniques for the transmission and multimedia playback of media data.

In methods known as "streaming", the media data is transmitted in a data stream via a communication medium (e.g. the Internet). However, these methods are complex because they must take into account the possibility of disturbed communication. Precautions must be taken to be able to restart communication after the data stream has been torn off.

The object of the invention is to avoid these problems. Preferably, the invention is also intended to provide good protection against inadmissible copying and / or playback of the media data.

The invention is defined by the independent claims. The dependent claims relate to preferred embodiments of the invention. The enumeration order of the steps in the process claims should not be interpreted as a restriction of the scope. Rather, embodiments of the invention are provided in which these steps are carried out in a different order and / or in whole or in part in parallel and / or in whole or in part interleaved.

The invention is based on the basic idea of dividing media files to be transmitted into sections. These sections are transferred to a client and played there. The transfer of each section takes place like an ordinary file download. Special streaming technologies are not required. This considerably simplifies the method according to the invention, because conventional and widespread protocols can be used.

In preferred embodiments of the invention, the sections are in encrypted form and are only decrypted when they are played. Before deciding The playback authorization can also be checked first by means of a server query. The transferred sections are preferably stored as normal files in a customary file system of the client. Provision can furthermore be made to automatically delete the sections from the file system after a predetermined period of time.

In preferred embodiments, administrative and special information that is at the end of the original media data is extracted and timed at least in the first half of the entire transmission of the sections (preferably earlier, for example within the first 20% of the total transmission or even in the first section or before the first section). Furthermore, a part list can be created and transmitted, which contains information about the individual parts (e.g. their file names). The file names are particularly necessary if the transfer of the sections is to take place as a normal file download.

The client according to the invention, the method according to the invention for providing media data and the server according to the invention are preferably further developed with features which correspond to the features described above and / or mentioned in the dependent claims.

Further features, objects and advantages of the invention will become apparent from the following description of an exemplary embodiment and several alternative embodiments. Reference is made to the schematic drawings, in which:

1 shows an overview of the components and communication paths provided in one embodiment of the invention,

2 shows a representation of the data present in the processing computer and the master server during a sequence of processing steps in the exemplary embodiment of FIG. 1,

FIG. 3 shows an exemplary flow diagram of the data transmission between a cache server and the client in the exemplary embodiment from FIG. 1, and FIG. 4 shows an exemplary flow chart of steps associated with the playback process in the exemplary embodiment from FIG. 1.

In the overall system shown in FIG. 1, a processing computer 10 is provided which has access to media data M. The media data M are, for example, video films or sound data or video films with additional sound components that are independent of the film content and are available in a format known per se (e.g. one of the formats avi, mpg, mp3, ...). In Fig. 1 only one set of media data M is shown as an example, while in the practical implementation of the system there are many further media data records (corresponding to the content of an entire film or audio archive).

The processing computer 10 converts the media data M into individual, encrypted sections X1, X2 XN, which are transmitted to one or more servers (upload). In the present exemplary embodiment, a master server 12 is provided, which receives the N sections X1, X2, ..., XN from the processing computer 10 and in turn forwards them to a number of cache servers 14, 14 ', 14 ", .... In alternative embodiments a different server configuration is used, it is only important that the N encrypted sections X1, X2, ..., XN are available for download with sufficient bandwidth.

A client 16 is designed as a home computer known per se, for example as a PC or Macintosh®. The client 16 is set up to successively download the sections X1, X2,..., XN from one or more of the cache servers 14, 14 ', 14 ",... And the media data via a communication network (for example the Internet) M on a connected screen 18 with loudspeakers (not shown separately in FIG. 1) For this purpose, the client 16 has an operating system known per se (for example Microsoft® Windows® or Apple® MacOS®), which among other things has a file system 20 for The sections X1, X2, ..., XN and other files are saved The sections X1, X2, ..., XN are stored in the file system as normal files. The client 16 executes a playback program 22 which has a filter 24, a decoder 26 and an erase module 28. The filter 24 serves to load the encrypted sections X1, X2,..., XN from the file system 20 during playback, to decrypt them and to assemble them into a playable version M 'of the media data M. The decoder 26 converts the playable version M 'in a manner known per se into an image sequence and one or more sound channels which are output via the screen 18 or the loudspeakers.

There is no reduction in quality in the entire transmission process; The multimedia playback of the decrypted and reassembled sections X1, X2, ..., XN does not differ from a playback of the original media data M. To prevent unauthorized copying, the encrypted sections X1, X2, ..., XN are first decrypted and composed when playing. Before playing, the authorization of the client 16 to play is checked by a request from a server (in the present example, the cache server 14 ').

The decoder 26 is adapted to the playable file format M 'of the media data M. If, for example, the media data M are in avi format, a decoder 26 similar to the decoder used in the Windows® Media Player ™ can be used, but which takes into account the changes in the playable version M 'compared to the original media data M. In the present exemplary embodiment, the playable version M ¹ differs from the original media data M only in that some management information required for playback (indicated by vertical hatching in FIG. 1) from its original position at the end of the media data M at the beginning of the playable version M 'are moved. The content-bearing parts of the formats M and M 'are identical.

The playback process and the downloading of the sections X1, X2, ..., XN preferably takes place at least partially in parallel; In the exemplary embodiment described here, provision is made for the playback to begin only after the first section N1 has been completely received. In alternative embodiments, possibly depending on the transmission speed between the cache server 14, 14 ', 14 ", ... and the client 16 - two or more sections X1, X2, ..., XN are loaded into the client 16 before the start of the playback in order to provide sufficient data for buffering transmission bottlenecks.

The deletion module 28 is set up to delete the portions X1, X2,..., XN stored in the file system 20 of the client 16 after a predetermined period of time (24 hours in the present exemplary embodiment).

2 illustrates in the first five lines the steps of the division and encryption of the media data M carried out by the processing computer 10 in order to obtain the N encrypted sections X1, X2,..., XN and further auxiliary information.

In a first step 30, certain administrative and special information that is at the end of the original media data M is extracted and stored separately. The data sequence M ', which begins with the extracted information and then contains the actual image and sound contents of the media data M, is divided into N sections D1, D2, D3, ..., DN in a next step 32, all sections up to the same size on the last one. The first section D1 begins with the extracted administrative and special information, which is represented in FIG. 2 by vertical hatching. This rearrangement is necessary because the administrative and special information is required at the start of the playback process and thus, if the media data M were to be transmitted in the original order, playback would only be possible after all parts had been received.

In step 34, the N sections D1, D2, D3,..., DN are encrypted according to an algorithm known per se and a newly generated one-time key KEY, which is used only for this process, in order to encode the N encrypted sections X1, X2 , X3, ..., XN (the encryption is indicated in FIG. 2 by an oblique hatching). The KEY key is required for later playback of the media data. The key KEY is therefore stored so that it can first be passed on to the servers 12, 14, 14 ', 14 ", ... and finally (after successful authentication) to the client 16. In a subsequent step 36, the processing computer 10 creates an exact part list in XML format ("LIST.XML"). The part list is used to control the later data transmission from the master server 12 to the cache server 14, 14 ', 14 ", ... and further to the client 16 and for error control. In addition to the number, size and name of the individual sections X1, X2, X3 , ..., XN, the part list contains a CRC checksum for each section X1, X2, X3, ..., XN, which can be used to clearly verify whether or not the respective file has been changed since it was created X1, X2, X3, ..., XN defective, they can be reloaded or, if necessary, the undamaged sections X1, X2, X3, ..., XN can be used for data reconstruction.

The sections X1, X2, X3,..., XN and further data (key KEY and part list LIST.XML) present in the processing computer 10 as a result of step 36 are first transferred to the master server 12 in step 38 and then to the cache server 14, 14 ', 14 ", ... transfer (upload). The l / p / σa process is first carried out via ftp (file transfer protocol) to the master server 12. The master server 12 then controls the further distribution to the cache Server 14, 14 ', 14 ", ... by means of automated processes (cronjobs) initiated at regular times. After each complete upload, the respective recipient (master server 12 and cache server 14, 14 ', 14 ", ...) carries out a consistency check of the uploaded files on the basis of the data transmitted in the part list. If an error is detected, this is immediately reported reported to the administrator.

If the uploading process is correctly completed, an administration data record 42 for the transmitted media data is created in an administration database 40. In addition to the file information of the part list listed above, the administrative data record 42 contains billing-relevant information such as game length and IDs of the digitization technicians responsible for this media entry. Furthermore, chapter information is entered, which, like the DVD chapters, enables the user to navigate easily. In some configurations, the administrative data record 42 also has content data, such as names of authors or images relating to the media entry. In execution alternatives it is provided that the administrative and special information extracted in step 30 not to be encrypted in the first section X1, but unencrypted as a separate file. In this case, this information can also be included in the administrative data record 42.

After the entries in the administration database 40 have been completed, an extended validity check of the transmitted data is carried out. In addition to being complete, the data is also checked for conclusiveness. If no error is found, the administrative data record 42 is activated and can therefore be called up by the client 16. In various embodiments of the invention, the administration database 40 is managed centrally by the master server 12 or distributed by the cache servers 14, 14 ', 14 ", ... or by further computers, not shown in FIG. 1. In addition to the administration database 40 ^~ a billing database 44 is provided, in which a billing data record 46 is created and maintained during playback. The billing database 44 is shown in dashed lines in FIG. 2 because it does not follow steps 30-38, which are the actual subject matter of FIG is involved.

3 shows, using an example sequence, the successive downloading (download) of the N encrypted sections X1, X2, X3, ..., XN and further data to the client 16. This downloading is started by a user action 50, for example a mouse click on a Control panel of a user interface displayed on the screen 18. In the present exemplary embodiment, the user interface is represented by an Internet browser known per se (e.g. Microsoft® Explorer® or Netscape® Navigator®), which is equipped with a Flash® plug-in. In contrast, in alternative embodiments, functions for displaying the user interface are integrated in the playback program 22 executed by the client 16.

Each control panel of the user interface assigned to load a media offering is assigned a unique identifier MEDIA-ID of the media offering. If the user requests the media offer through the action 50, the client 16 sends a request 54 to the cache server 14 in step 52 (or another cache server 14 ′, 14 ″, ... that has the same function) In an exemplary embodiment, request 54 is a GET request according to the HTTP 1.1 standard. In addition to the unique identifier MEDIA-ID des, request 54 contains desired media offer also a client identifier CLIENT-ID of the client 16 and a corresponding client password CLIENT-PW to prove the authorization of the client 16.

In step 56, the cache server 14 (or in another embodiment another server entrusted with this task) checks the client identifier CLIENT-ID for admissibility and the client password CLIENT-PW for correctness. Failed logon attempts are noted in files that are only accessible to the system administrators (logging). If the registration is successful, a server address ADR, the part list and the chapter information entered in the administrative data record 42 are transmitted to the client 16 in step 58. The server address ADR designates the server (usually one of the cache servers 14, 14 ', 14 ", ...) on which the client 16 can call up the individual sections X1, X2, X3, ..., XN. The chapter information is used by the user for navigation purposes.

Following the correctness check, the billing data record 46 is also created in the billing database 44 in step 60. In the present exemplary embodiment, this billing data record 46 allows the client 16 to download the sections X1, X2, X3, ..., XN within a period of 24 hours. In addition, a one-time password TR-PW is generated randomly, which the client 16 needs for all further operations relating to this transaction. This transaction password TR-PW is transmitted to the client 16 in step 62.

In the following steps, the client 16 downloads the encrypted sections X1, X2, X3, ..., XN one after the other from the cache server 14, 14 ', 14 ", ... designated by the server address ADR Client 16 for each section X1, X2, X3 XN (or only once or a few times in alternative embodiments) by means of its transaction password TR-PW. Step 64 relates to the cache server 14, 14 ', 14 ", ... with the server address ADR request for the first section X1. In step 66, this section X1 is transmitted to the client 16. Steps 68 and 70 relate to downloading the second section X2. The request-response interplay continues until all sections X1, X2, X3 XN in the file system 20 of the client 16 are stored (indicated by three points in FIG. 3). Overall, each section X1, X2, X3, ..., XN is downloaded like a normal file download according to the HTTP protocol.

After the complete download of the first section X1, the client 16 is ready to play (in FIG. 3 and FIG. 4 this time is indicated by a dashed line). In alternative versions, on the other hand, readiness to play is only provided after receiving several sections (e.g. the first two sections X1 and X2). The steps carried out in connection with the playback process are illustrated in FIG. 4. These steps are carried out in parallel with the downloading of the remaining sections (shown by the dashed line in FIG. 3) if the playback process is started by the user immediately after the readiness for playback has started. The download process then takes place in the background, so that a continuous view of the media data M is ensured.

The readiness to play is symbolized to the user by a suitable display on the screen 18. In response to a user input 72 (for example, a mouse click), the authorization of the client 16 is first checked by a server request. The server request can be directed to the cache server 14 also used for downloading the sections X1, X2, X3 XN or to another cache server 14 ', 14 ", ... or to a further administration computer (not shown in the figures) his.

The server request begins in step 74 with an HTTP request generated by the play program 22, which signals the play request to the cache server 14. With this request, the unique transaction password TR-PW is again used to prevent manipulation. If the cache server 14 has received a valid transaction password TR-PW, it first enters a note in the billing data record 46 about the start of the playback (step 76) and then transmits in step 78 that when the sections X1, X2, X3 are encrypted , ..., XN used one-time key KEY to the client 16, more precisely, to the filter 24 of the playback program 22. The key KEY is used by the filter 24 to decrypt the sections X1, X2, X3, ..., XN. The filter 24 also assembles the decrypted sections D1, D2, D3,..., DN into the playable version M 'of the media data M and transmits the version M' to the decoder 26, which in turn transmits the image desired by the user. and generates sound information. This playback process, which is controlled by the filter 24 using the information contained in the part list, is identified in FIG. 4 by the reference symbol 80. During playback, the filter successively accesses the encrypted sections X1, X2, X3,..., XN stored in the file system 20. However, these sections are only decrypted in the working memory so that there is no security hole. The transitions between the sections X1, X2, X3 XN are at

Play 80 not visible to the user. Overall, the multimedia playback of the decrypted and reassembled sections X1, X2, X3, ..., XN does not differ from the playback of the original data.

To protect against pirated copies, care is taken in the exemplary embodiment described here that neither the decrypted sections D1, D2, D3,..., DN nor the composite media data M 'are completely available. Only the sections X1, X2, X3, ..., XN that are currently accessible are decrypted and put together on demand ("on the fly"). This only happens in the main memory, which is blocked for access by other programs. The key KEY is also only kept in the working memory of the current instance of the filter 24 and is not stored in the file system 20 or on a hard disk. Unauthorized duplication of the media data by the user is therefore not possible.

A special feature of the exemplary embodiment described here is that the processes described are quality-neutral. In other words, only a reorganization or redistribution takes place when the media data M is divided. Neither the volume increases nor the performance is negatively affected. Another advantage is that playback is not possible without the filter 24, which also performs the decryption. Data security is therefore guaranteed firstly by encrypting the data and secondly by that playback without the filter 24, which cannot function without authentication, is not possible.

As soon as the playback process has ended, the client 16 sends a corresponding message in step 82 to the cache server 14, which stores this in the corresponding accounting data record 46 (step 84). For each further playback process, the client 16 has to authenticate again with the cache server 14 using the steps shown in FIG. 4. The cache server 14 then checks whether the film may be played again, which is permitted or prohibited depending on the loan period.

The encryption ensures that the data present in the file system 20 of the client 16 cannot be started again at one of the cache servers 14, 14 ', 14 ",... Without re-authentication. It is therefore possible to start the to store encrypted sections X1, X2, X3, ..., XN in the local file system 20 of the client 16. Therefore, if the user wants to watch the film again, no further down / download process is required.

In the exemplary embodiment described here, however, it is provided that the encrypted sections X1, X2, X3, ..., XN are not stored locally in the client 16, but only for a predetermined period of time. In order to make this possible, the deletion module 28 sets a lifetime variable to a predetermined value, for example 24 hours, for each section X1, X2, X3, ..., XN upon completion of the download process shown in FIG. 3. The lifetime variable runs independently of the system clock of the client 16. If this lifetime has dropped to 0, the deletion module 28 causes the respective section X1, X2, X3, ..., XN in the file system 20 to be irrevocably deleted (step 86 in FIG. 4).

To prevent tampering, 22 monitoring mechanisms are provided in the playback program, which discover unauthorized modifications and transmit them directly to one of the servers 12, 14, 14 ', 14 ", ... As soon as a tampering attempt is detected, the complete playback system in the Client 16 deactivated until it is reactivated by a technician from the service provider (for example by a new installation).

Claims

claims

1. Method for transmitting and playing media data (M), with the steps carried out at least partially in parallel by a client (16): successively downloading the media data (M) divided into sections (X1, X2, X3, ... XN) the client (16), and multimedia playback (80) of the downloaded sections (X1, X2, X3, ... XN) by the client (16), the playback beginning at the earliest after the first section (X1, X2, X3 , ... XN) has been completely downloaded, and wherein the sections (X1, X2, X3, ... XN) are played together during playback (80).

2. The method according to claim 1, wherein the sections (X1, X2, X3, ... XN) are in encrypted form and are only decrypted when played (80).

3. The method according to claim 2, in which the playback authorization is checked by a server request (74) before decoding the sections (X1, X2, X3, ... XN) during playback (80).

4. The method according to claim 2 or claim 3, wherein the encrypted sections (X1, X2, X3, ... XN) are stored as files in a file system (20) of the client (16).

5. The method according to claim 4, wherein the sections are automatically deleted from the file system (20) of the client (16) after a predetermined period of time.

6. The method according to any one of claims 1 to 5, in which administrative and special information, which are located at the end of the original media data (M), extracted and at least in the first half of the transmission of the sections (X1, X2, X3, .. . XN) and preferably in the first section (X1) or in connection with the transmission of the first section (X1).

7. The method according to any one of claims 1 to 6, wherein a part list containing information about the individual sections (X1, X2, X3, ... XN) at least in the first half of the transmission of the sections (X1, X2, X3,. .. XN) and preferably before the transfer of the sections (X1, X2, X3, ... XN).

8. Client (16) which is set up to carry out a method according to one of claims 1 to 7.

9. Method for providing media data (M), in which the media data (M) is converted into encrypted sections (X1, X2, X3, ... XN) and on a server or multiple servers (12, 14, 14 ', 14 ", ...) are provided, the one or more servers (12, 14, 14 ', 14", ...) being / are set up to transmit the encrypted sections (X1, X2, X3, .. . XN) to provide a client according to claim 8.

10. Server (12, 14, 14 ', 14 ", ...) which is set up to carry out a method according to claim 9.