In this section we will have a look at how the proposed schemes of multiplexing works. We will use the files that are pre processed as the ”best” solution, and compare the other solutions to this. The CPU and bandwidth usage results from this tests are found in appendixC.
4.2.1 Files assembled on the server
The goal here is to create a custom package that will be delivered to the user. In order to create this package, we used MVKmerge to assemble the files into one package. We then ended up with a package containing only the audio and video track that we wanted. The results of doing this was that we had an optimized package, containing as little information as possible. This will also lead to the existence of several versions of the same media if we were to distribute several versions with almost the same content.
4.2.2 Files multiplexed in advance
As these files have already been processed, we will use this as the ideal condition for our tests. The common property for these files is that they contain all the data that we want to move to the client. Since we will not want to add or remove data from these files, we will be able to use a multi pass compression that will ensure that the files are as small as possible.
Unfortunately, this will not be feasible to do on demand due to the long processing time and amount of CPU power required. The bandwidth used for this configuration will be the same as in the previous section, Files assembled on the server (4.2.1), but will require a little less CPU power from the server. This is due to the fact that we are only going to transmit a file without doing any pre processing, such as assembling the files the first time the client requests it.
4.2.3 Files assembled on the client
In order to maintain maximum flexibility, and ease of changing the content, we could attempt to deliver the content as several separate streams. The testing with 2 separate streams were done using Videolan on the client, and Apache 2 on the server side. The test where done in a environment that minimized the chance of desynchronization of the streams. We have therefore not implemented a system for handling synchronization. The synchronization part would add a little extra overhead to the client CPU usage as it will need to check if the streams are synchronized properly. We could also see a little more network traffic, but this
4.2. MULTIPLEXING DATA AND ITS INFLUENCE ON PERFORMANCE
31
will depend on how often a desynchronization occurs as well as the caching method we are using.
4.2.4 Watermarking
Due to few free implementations of a watermarking scheme, and the fact that we have no expertise when it comes to video processing, we had to use existing tools in order to do the performance testing of the watermarking scheme. As the computation and insertion of the watermark should take a lot less time than the decoding and reencoding of the video stream, we decided to do the test with a static watermark. The test where performed using FFmpeg∗ to place a image over the original video, as this will give us a indication of the speed we can achieve if we are to do on demand watermarking on the server by fully decompressing and compressing the video. According to the results from the experiments[27] done by G.C.
Langelaar, we should be able to add a DEW watermark† to a video more than 50 times faster than the time decompression and reencoding takes‡.
∗ffmpeg.mplayerhq.hu
†Differential Energy Watermarks
‡see Figure 6.4.1
Chapter 5
Discussion
5.1 DRM
5.1.1 Methods for internationalization
According to the data we have collected from the multiplexing tests, it is clear that the data should be pre processed before delivering it to the client if we have little bandwidth available.
We would however recommend that all tracks, video, audio and subtitles, should be saved as separate tracks.
Having separate tracks will ensure that international users can get an audio track and subtitles in their native language, or any other language that they prefer. They can also get a choice on what kind of quality they want depending on their connection. This will also enable a distribution model where the customer could be charged differently depending on the features they want. This will probably require that the stream is saved to RAM, or to disk. Depending on the system, it should then be possible to add encryption to the stream, or to watermark it, thus hopefully preventing unauthorized distribution. The fact that pre multiplexing a HD stream will reduce the processor usage by 2 % on a quad 2,6 GHz processor, also means that more customers will be able to use the content without having to upgrade their equipment.
5.1.2 Watermarking
Since we would like to reduce the load on the server in order to be able to deliver video on demand to a large amount of customers simultaneously, we need to speed up the process of watermarking. Our recommendation for this will be to add the watermark to parts of the movie. By only processing small parts, and adding watermarks onto this, we should be able to handle fairly large amounts of data at the same time. By replacing a few frames of
the video now and then, we should be able to identify users that have uploaded the movie without permission, but we could also lose the ability to detect those who only upload a small part of the content. We could also try to use the DEW watermarking of the video, but this will require that we are using H.264 streams. It will therefore make it less versatile than the approach where we decode and reencode the video. Another option is to embed the watermark in the audio signal, but as this does not protect the visual content in any way, it will probably not be accepted as a good enough solution for the movie companies.
As this is a drm scheme created on the basis of making the user act legitimate of his own free will, as opposed to schemes that are restricting the access rights, this solution should be easier to use for most people, and will also be platform independent.
5.1.2.1 Suggestions for increasing the security
Since a attacker will be able to frame a person for distributing the data if he is able to intercept the communication between the seller and customer, we need a way of making sure that nobody are able to steal the data while it is being transmitted. Since the content could be rented from an online store we should also try to protect it from the user. As we have previously stated, most DRM systems will be possible to bypass with enough time and effort.
We would therefore like to have a system that removes the easiest ways of attacking the content. By creating a player that is embedded into software that runs in the web browser we should be able to create a secured connection from the application to the streaming host.
This will reduce the risk of people being able to read the data that is transmitted, and it will also be possible to hide communication between the server and client software. Another measure that we could implement are hidden URLs. In order to make sure that nobody are able to use a download software to download the files, we will recommend hiding the URL inside the application, and if possible, generate a new URL each time a customer accesses a file. By doing this, and requesting a new URL from the server each time, we will also be able to prevent people from reading the URL and using it later in order to be able to replay the files in another player.
5.1.3 Performance
In our tests Windows Media DRM added a ∼1.6% increase in CPU usage compared to an un-encrypted file. This is a bigger increase than FMS introduces, although Windows Media DRM is a traditional DRM and encrypts the media itself, instead of the stream. The small increase in CPU usage has no noticeable effect on our test systems, and won’t require enough resources to a be a problem for low-end systems. Windows DRM has been in use by many video on demand services over the world, and as far as we have heard this has not limited the customer base due to demands to the processor.