Video srauto šifravimas yra pagrindinis intelektinės nuosavybės užtikrinimo metodas šiuolaikinėse skaitmeninių teisių valdymo sistemose (DRM). Egzistuojantys šifravimo metodai užtikrina labai aukštą apsaugos lygį, bet tuo pat metu reikalauja labai didelių skaičiavimo resursų ir yra sunkiai pritaikomi ribotų skaičiavimo resursų mobiliems vartotojų įrenginiams. Šiame straipsnyje pristatomas dalinis MPEG-2 transporto srauto šifravimo metodas, kuris yra tinkamas tokiems ribotų resursų terminaliniams vartotojų įrenginiams. Siūlomo metodo eksperimentinio įvertinimo rezultatai rodo, kad šifravimo ir dešifravimo laikai, lyginant su standartiniu pilnu šifravimu, yra sumažinami apie 7 kartus, todėl šis metodas yra tinkamas ribotų skaičiavimo resursų dešifravimo įrenginiams. / Video stream encryption is the main method for the protection of intellectual property in modern digital rights management systems (DRM). Existing encryption methods ensure very high protection level of encrypted content, but at the same time are very resources demanding, making them hardly suitable for low processing power mobile end-user devices. This paper presents partial MPEG-2 transport stream encryption method, which is suitable for such low power user terminals. The experimental evaluation of proposed method show that encryption and decryption times, comparing with standard full encryption, are reduced about 7 times, making proposed method a good choice for low processing power decryption devices.

Användningen av strömmande video ökar snabbt just nu. Ett populärt konceptär adaptive bitrate streaming som går ut på att en video kodas i flera olikabithastigheter. Dessa videor tas sedan och delas upp i små filer och görstillgänglig via internet. När du vill spela upp en sådan video laddar du först hemen fil som beskriver vart filerna finns och i vilka bithastigheter de är kodade i.Mediaspelaren kan där efter börja ladda hem filerna och spela upp dom. Om defysiska förutsättningarna, som exempelvis nedladdningshastighet eller CPUbelastning,ändras under uppspelningen kan mediaspelaren enkelt byta kvalitépå videon genom att börja ladda filer av en annan bithastighet och slippa attvideon laggar. Denna rapport tar därför en närmare titt på fyra tekniker inomadaptive bitrate streaming. De som undersöks är HTTP Live Streaming,Dynamic Adaptive Streaming over HTTP, HTTP Dynamic Streaming ochSmooth Streaming med avseende på vilka protokoll som dom använder.Rapporten undersöker även hur Apple och FFmpeg har implementerat HTTPLive streaming med avseende på hur mycket data som behövs läsas i en filinnan videon kan börja spelas upp. Rapporten visar att det inte är så storaskillnader mellan de fyra teknikerna. Dock sticker Dynamic AdaptiveStreaming over HTTP ut lite genom att vara helt oberoende av vilket ljud ellervideoprotokoll som används. Rapporten visar också på en brist i specificeringenav HTTP Live Streaming då det inte är specificerat att första komplettabildrutan i videoströmmen bör ligga i början av filen. I Apples implementationbehövs upp till 30 kB data läsas innan uppspelning kan påbörjas medan iFFmpegs implementation är det ca 600 byte. / The use of streaming video is growing rapidly at the moment. A popular conceptis adaptive bitrate streaming, which is when a video gets encoded in severaldifferent bit rates. These videos are then split into small files and made availablevia the internet. When you want to play such a video, you first download afile that describes where the files are located and in what bitrates they are encodedin. The media player then begin downloading the files and play them. Ifthe physical conditions, such as the download speed or CPU load, changes duringplayback, the media player can easily change the quality of the video bystarting to downloading files of a different bit rate and avoid that the video lags.This report will take a closer look at four techniques in adaptive bitrate streaming.They examined techniques are HTTP Live Streaming, Dynamic AdaptiveStreaming over HTTP, HTTP Dynamic Streaming and Smooth Streaming andwhich protocols they use. The report also examines how Apple and FFmpeg hasimplemented HTTP Live Streaming with respect to how much data is needed toread a file before the video can begin to be played. The report shows that thereare no large differences between the four techniques. However, Dynamic AdaptiveStreaming over HTTP stood out a bit by being completely independent ofany audio or video protocols. The report also shows a shortcoming in the specificationof HTTP Live Streaming as it is not specified that the first completeframe of the video stream should be at the beginning of the file. In Apple's implementationits needed to read up to 30 KB of data before playback can bestarted while in FFmpeg's implementation its about 600 bytes.