Xevgenis_Michail_CI7120 Multimedia Communications

FACULTY OF ENGINEERING

DEPARTMENTS OF ELECTRONICS ENGINEERING AND AUTOMATION ENGINEERING

PIRAEUS UNIVERSITY OF APPLIED SCIENCES

MSc IN NETWORKING AND DATA COMMUNICATIONS

COURSEWORK

MODULE:

CI7120: Multimedia Communications

ID: _K1465167_

Module Coordinator:

Dr. Kalivas Dimitrios , Dr. Papadakis Andreas

Date of Module:

22/01/2016

Module: Module Coordinator:

Kingston University London




Name of Student:

Michael Xevgenis

Subject: Dailymotion: A survey of a Video in Demand service and a video quality assessment.

Submission Date: 22/01/2016___________________________________

Grade (%):__________________________________________________

% Grade reduction because of submission delay: _____ (5% Grade reduction per every day of Cwk delay).

Final Grade (%): ________________________________________


Kingston University London




Dailymotion: A survey of a Video on Demand service and a video quality assessment.

Xevgenis MichaelEgaleo, Athens, Greece

[email protected]

Abstract— Nowadays the number of multimedia users increases rapidly. Almost everyone who has an internet connection visits οn a daily basis a site that contains multimedia applications such as videos, songs or photographic material. As a result, the users’ requirements are constantly increasing. These requirements should be fulfilled by those services. In this paper we will focus on a video on demand service called Dailymotion. It is a service where users are able to upload their videos or watch video contents. It is critical for our survey to understand how that application works, what are the technical solutions that are adopted in this application and what are the key performance criteria that should be fulfilled. Furthermore, we will proceed to an experiment where we will compare two different kinds of containers, mkv (Matroska) and mp4 (MPEG-4), in different bit rates using the same codec H.264-AVC. In addition, we will perform a video quality assessment using the MSU VQMT (subjective and objective method) in order to realize if the users’ criteria are satisfied.

Keywords— mkv, mp4, PSNR, SSIM, VQM, HVS

I. INTRODUCTION It is a fact that the Internet is a part of our daily routine. On a daily basis a great percentage of

internet users visit social networking sites, video on demand sites, music on demand sites, etc. Almost any internet user has visit at least ones a site that offers multimedia content. The majority of people prefer to spend many hours on the internet watching videos rather than surfing on the web. Nowadays social networking services cooperate with multimedia services such as YouTube and Dailymotion in order to increase their visits and their users. The users of those services are able to listen songs or watch videos and also publish them. Also the ability of the user to access the web from mobile devices such as tablet and mobile phones is a factor that the industry should consider.

The multimedia sector is evolving rapidly due to the users’ requirements. The number of multimedia users increases and the multimedia content should be delivered according to users’ needs. High quality, availability and no interruption of the service are some of the users’ demands. In order to fulfill those requirements the field of multimedia developed compression and transmission techniques considering the human visual system (HVS). In order to achieve the desirable quality result we perform objective tests of the processed videos using participants who rate those videos. Also we perform subjective tests of the processed videos using several metrics (PSNR, SSIM, and VQM) that give us numerical information about the video quality.

In this paper we will focus on video on demand services and specially Dailymotion. In section 1, we will describe how the video on demand service called Dailymotion works and we will mention its





requirements. In section 2 , we will analyze the technical solutions that are adopted in our video on demand service as it concerns compression and transmission(streaming).More specifically, we will analyze how the H.264-AVC codec works and what purpose the mkv container and mp4 container serve. In addition, we will proceed to an analysis of the streaming technologies that the application uses and how they behave during the streaming.

In section 3, we will set and describe the key performance indicators that we choose in association with QoE of the user and QoS. In section 4, we will perform our experiment focusing on matters of compression and we will compare two different videos using two different kinds of containers in numerous bit rates using the objective method concerning quality by using the MSU VQMT. Finally, we will discuss our experimental results and we will come up with the conclusions of our paper.

II. DESCRIPTION OF DAILYMOTION SERVICE AND ITS REQUIREMENTS

As we fore mentioned Dailymotion is a video on demand service where each user may perform a variety of actions. If the user does not have an account he has a small variety of actions. The user is able to watch only videos in every kind of definition he desires and is able to pause the video or move forth or back according to the duration of the video. The user also is able to watch the number of views of that video in accordance with time. If the user has an account, then by signing in he can unlock a variety of actions. These actions may be the following: simply watch a video, make a comment on a video, follow the user who uploaded a video if he finds his videos interesting and finally, the user is able to upload a video according to the upload guidelines that Dailymotion suggests.

The suggested upload guidelines, which are the requirements of our service, are very important for the error-free upload process of the service. The maximum file size that a user may upload is 2GB and the maximum video duration is 60 minutes. In addition, the video that will be uploaded should be processed following the technical guidelines that Dailymotion suggests. The video should be encoded using the following codec suggestions in descending order of preference: H.264, VC-1, DivX, WMV9, and progressive MPEG-2. Also, the aspect ratio should be 4:3 for 640x480 standard definition, 16:9 for 720x480 standard definition and 16:9 for 1280x720 and 1920x1080 high definition. Furthermore, the bitrate that controls the visual video quality and the size of the file should be among 1,2 Mbps and 4 Mbps (depends on the codec and resolution). Also the frame rate should be 25fps and the encoding should be progressive. If it is possible to control the pixel aspect ratio we should set it to 1:1(square pixels). Additionally, the service can support different kind of containers such as 3gp, avi, mkv, mov, mp4. Finally, if we follow the above guideline our video file should be less than 2GB. [1,2]

Nevertheless, the Dailymotion service can handle videos with frame rate 24fps and 30 fps and also can handle resolutions up to 3840 x 2160. Also the service suggests technical guidelines for audio. The audio codecs that we should use are the following: AAC, MP3, WMA9, MPEG Layer 2 (in descending order of preference) and the bitrate for the audio should be 256 Kbps AAC or 320 Kbps MP3 stereo (ideal), 128 Kbps AAC or 192 Kbps MP3 stereo (minimum) with sampling rate 44100 Hz. [1]





III. ANALYSIS OF TECHNICAL SOLUTIONS ADOPTED

In order to fulfill the requirements of our users we developed compression and transmission techniques. In this section we will analyze which are the technical solutions that are adopted in video on demand services. The file that will be uploaded should be compressed according to the services requirements. In our case the file should be encoded using the H.264-AVC codec using a container. The container may be either mp4 or mkv. Those two containers we choose in order to compare them in our experiment. After the compression and the uploading of the video any user of the service is able to watch that video via streaming. In this section we will also analyze how streaming works, which are the streaming technologies, how they work and what kind of connections between server and client are initiated.

a) An overview of H.264-AVC codec

The video compression process involves two components, the coder and the decoder, thereby the name codec. The video codec is a software program that is responsible for the encoding and decoding. It compresses the raw video into a small-sizes video that can be easily transmitted over network without consuming more bandwidth resources. In order to face the increase of video communication nowadays many video coding techniques have been developed so we can achieve high quality streams using the available bandwidth. [3]

The H.264-AVC codec is a compression technology that was developed and standardized by ITU-T (VCEG) and ISO/IEC(MPEG). It has been developed to cover the majority of video streaming services. The H.264-AVC is an evolvement of all prior digital video standards, therefore it is similar to them (H.261, MPEG-1, MPEG-2 / H.262, H.263 or MPEG-4 part 2). The encoder is based on motion-compensated DCT-like transform coding. Each picture is compressed by partitioning it as one or more slices; each slice consists of macroblocks,which are blocks of 16x16 luma samples with corresponding chroma samples. Each macroblock is divided into sub-macroblock partitions for motion-compensated prediction. The prediction partitions may have seven different sizes 16x16, 16x8, 8x16, 8x8, 8x4, 4x8 and 4x4. In comparison with the past standards that used entire macroblocks with sizes 16x16 and 8x8 the H.264-AVC has larger variety and thus it provides enhanced prediction accuracy. As a result, the spatial transform for the data is either 8x8 or 4x4 in contrast with past standards where the transform block size has always been 8x8, so the 4x4 block size offers an enhanced specifity in locating residual difference signals. The block size used for spatial transformation is always either the same or smaller than the block size used for prediction. [4,6]

In figure 1 a detail diagram of the components is represented that H.264-AVC encoder uses. The decoder works in reverse way.

Figure 1. The H.264-AVC encoder [6]





1) Intra prediction

The intra prediction process is the process where the samples of macroblock are predicted by using only the information of already transmitted macroblocks of the same image. In H.264-AVC there are two different types of intra prediction for the luminance component Y. The first type is the INTRA_4X4 and the second type is the INTRA_16X16. When INTRA_4X4 is used the macroblock of size 16x16 is divided into sixteen 4x4 subblocks and for each 4x4 subblock a prediction of the luminance signal is applied individually. For the prediction purpose, nine different prediction modes are supported. When INTRA_16X16 is used four different prediction modes are supported: vertical prediction, horizontal prediction, DC-prediction and plane-prediction. Finally, for the chrominance signals Cb and Cr of a macroblock the intra prediction that is used is similar to INTRA_16x16 that we fore mentioned and it is performed on 8x8 blocks. [5]

2) Motion Compensated Prediction

In motion compensated prediction macroblocks are predicted from the image signal of already transmitted reference images. Each macroblock is divided into smaller partitions where the supported partitions have luminance block sizes of 16x16, 16x8, 8x16 and 8x8. If an 8x8 sub-macroblock is in a P-slice, one additional syntax element is used in order to specify if the corresponding 8x8 sub-macroblock is divided further into partitions with block sizes 8x4, 4x8 or 4x4. [5]

3) Transform coding

In order to code the prediction error, signal transform coding is applied. The purpose of the transform is to reduce the spatial redundancy of the prediction error. All prior standards such as MPEG-1 MPEG-2 applied a two dimensional Discrete Cosine Transform (DCT) of the size 8x8. The H.264-AVC uses different integer transforms, that their size is mainly 4x4 and in special cases 2x2. By using smaller block size, the encoder is able to adapt better the prediction error coding to the boundaries of moving objects, to match the transform block size with the smallest block size of the motion compensation and to generally better adapt the transform to the local prediction error signal. [5]

The H.264-AVC codec uses three different types of transforms. Those types of transform use a Hamard transform where the Hamard matrix changes according to the type of transform that is applied. The first type is applied to all samples of all prediction error blocks both for luminance and chrominance components regardless of whether motion compensated prediction or intra prediction was used. The size of that kind of transform is 4x4.The size of the transform changes if the macroblock is predicted using INTRA_16X16. In that case a Hamard transform is applied in addition to the first one, with different matrix where all 16 DC coefficients of the already transformed blocks of luminance signal are transforming. The size of that Hamard matrix is also 4x4. The third kind of transform is also Hamard where the matrix size is 2x2. This kind of transformation is used for the transform of the 4 DC coefficients of each chrominance component. [5]

Figure 2. Hamard matrices used according to the type of transformation [5]





4) Entropy coding

The H.264-AVC uses two alternative methods of entropy coding: a low-complexity technique that is based on the usage of context-adaptively switched sets of variable length codes called CAVLC and a more demanding algorithm, in matters of computation, of context-based adaptive binary arithmetic coding called CABAC. These two methods represent improvements in terms of coding efficiency in contrast to techniques of statistical coding used in prior video coding standards. [5]

b) The role of the containers.

The container formats are responsible for the identification and representation of different data types that are involved in one single file. A file may contain video and audio information, subtitles, chapter-information, meta-data and also synchronization information that is necessary in order to have a good playback quality of the content. The containers participate in the compression process. There are different kinds of container such as avi , flv, mp3,mp4, mkv, mov etc. In our scenario we will focus on mp4 and mkv container.

1) The mp4 container

The mp4 container was developed by MPEG (Moving Picture Experts Group). Quickly it became a very popular type of container and it is recommended for uploading video on web. The mp4 is a file that contains information about the file such as video and audio information, meta-data, synchronization and other features of the file. The following diagram represents an mp4 file and its functionality during streaming.

Figure 3. The structure of an mp4 file [7]

MP4 files mostly contain MPEG-4 media. That media may be audio and/or video and also MPEG-4 presentations. However, when a partial or complete presentation is stored there are specific structures that constitute that presentation. The MPEG-4 presentations are scenes described by the scene language MPEG-4 BIFS [7]. Audio, video or entire sub-scenes may compose media objects that can be placed within scenes. Each object is described by an object descriptor. Within the object descriptor the streams that make up that object are described. The initial object descriptor (IOD) describes the entire scene [8]. This is stored in a special box within the movie atom in MP4 files. The scene and the object descriptor it uses are stored in tracks. If the files include a full MPEG-4 presentation the IOD and these two tracks are required. In addition, each stream is described by an elementary stream descriptor. When a complete scene is delivered, these are delivered as part of the object descriptor stream. Nevertheless, in order to enable the composition





and to manage files that contain only media streams, these elementary stream descriptors are stored with the media streams themselves, in MP4 files. [9]

2) The mkv container

The mkv container was developed by CoreCodec Inc. and it is an open standard project. The goal of Matroska is to become one of the standards of multimedia container formats. It was derived from a project called MCF. However, the mkv differentiates from it because it is based on EBML (Extensible Binary Meta Language) [11], a binary derivative of XML. EBML enables the Matroska Development Team to gain significant advantages in terms of future format extensibility and simultaneously maintains the backwards compatibility. [10] The mkv container offers the following features: a) fast seeking in the file, b) chapter entries, c) full metadata (tags) support, d) selectable subtitle/audio/video streams, e) modularly expandable, f) error resilience (able to recover playback even when the stream is damaged), g) streamable over the internet and local networks (HTTP, CIFS, FTP, etc), h) menus [10]. The following diagram represents an mkv file.

Figure 4. The structure of an mkv file. [12]

Based on the above diagram we will proceed to an overview of the partitions of which an mkv file is composed. The header contains information about the version of EBML that was used in order to create the file as well as the type of the EBML file, in our case Matroska. The metaseek part contains an index regarding the location of other groups such as track information, tags ,cues, attachments and so on. The segmentation information section contains the basic information regarding the whole file. This information may be the title of the file, a unique ID so that the file can be identified anywhere and if it is a part of a series of files , the ID of the next file. The track section includes basic information about each of the tracks. For example, if it is an audio or video, type of resolution, sample rate (audio), type of codec. The chapters part lists all the chapters included in the file. The clusters part includes all the clusters which contain all of the video frames and audio for each track. In addition, the cueing data section includes all of the cues that are the index for each of the tracks. It is similar to metaseek , but this is used for seeking in a specific time when playing back the file. This element is not mandatory but without it its more difficult to seek because the player has to search the whole file until it finds the correct timecode. The attachment part is for attaching any type of file the user wants to a Matroska file and finally the tagging section includes all of the tags related to the file and each of the tracks. It is worth





mentioning that EBML allows elements of the same level to be in no particular order in order to have better use in streaming contexts. [12]

3) Comparison: MKV vs MP4

During the experimental section of this paper we will compare those two types of containers that we analyzed previously. In this part we will summarize the key differences of those containers regarding to the impact that they have during usage. The differences are displayed above in a table form. The following table will be our reference during the experimental section in order to compare our experimental results with our reference table.

Table 1. MP4 vs MKV

Container Format MP4 MKVDeveloper MPEG CoreCodec ,IncVideo formats supported MPEG-2 Part 2, MPEG-4

ASP, H.264/MPEG-4 AVC, H.263, VC-1, Dirac, others.

Virtually anything.

Audio formats supported MPEG-2/4 (HE)-AAC, MPEG-1/2 Layers I, II, III (MP3), AC-3, Apple Lossless, ALS, SLS, Vorbis, others.

Virtually anything.

Media player supported Almost all media players All the major media playersPortable devices supported All the portable devices Not all the portable devicesQuality of video and audio Good quality in SD. Not so

good quality in HD videos and Blu-ray rips.

Very good quality. Preferred format for HD videos and Blue-ray rips.

File size Small file size. Larger file size compared to MP4.

Streaming Most popular file format. Rarely used file format.Storage media (DVD, Blu-ray)

Rarely used. Most popular file format for storage media.

c) Streaming technologies adopted

In this part of the paper we will proceed to an analysis of the streaming technologies adopted. In order to understand how streaming works in our use case we should first give a definition of streaming. Streaming means watching video or listening to music on line instead of downloading a file that contains the video or audio and watching it later. The Dailymotion service can support live and on demand content. In our case we will focus on the on demand section.

The video on demand is based on progressive download technology. The Daylimotion service by using CDNs (Content Delivery Network) is able to provide multimedia content in all over the world in association with their partners such as Akamai, Edgecast and Level3 [13]. In addition, the service supports progressive download with adaptive streaming. HDS, HLS, Smooth Streaming and Dash are also supported by Dailymotion [13]. The scope of this part is to understand how the progressive download works and which protocols are used when a user chooses to watch a video.





The progressive download technology uses a quite popular protocol due to its simplicity, called HTTP over TCP. In progressive download the playout can start as soon as enough necessary data is retrieved and buffered. Nevertheless, this kind of technology does not offer the flexibility and features of streaming. In case of limited bandwidth, it is possible to occur problems during streaming. These problems may be related to the resolution that the user may have select and the viewer may experience frequent freezes and rebuffering. In addition, sometimes the fast-forward, seek/play or rewind may be unavailable or limited. These limitations are likely to inhibit the growth of large volume (and HD) movie distribution on the Internet. [14]

The answer to the aforementioned limitations is the adaptive streaming that is a hybrid of progressive download and streaming. On the one hand, adaptive streaming is pull-based as is progressive download: the adaptive streaming client sends HTTP request messages to retrieve particular segments of the content from an HTTP server and then renders the media while the content is being transferred. On the other hand, these segments are short, enabling the client to download only what is necessary and use trick modes much more efficiently, giving the impression that the client is streaming. Those important short-duration segments are available in multiple bitrates in accordance to different resolutions and quality levels, so the client is able to switch between different bitrates at each request. The client player always tries to retrieve the next best segment considering a variety of parameters related to available network resources, such as available bandwidth, the state of the TCP connections, the device capabilities and the current stream conditions. The goal is to provide the best quality of experience (QoE) by displaying the highest achievable quality, starting up faster, enabling quicker seeking and reducing skips, freezes and stutters. [14]

The advantages of adaptive bitrate are based on the usage of HTTP. Practically any connected device supports HTTP. In addition, HTTP is a pull-based protocol, thus it easily traverses middleboxes (firewalls, NAT, etc.). It also keeps minimal state information on the server side, which makes HTTP servers more scalable than conventional push-based streaming servers. Finally, to the existing HTTP infrastructure there is no difference between adaptive streaming and any other HTTP applications and this allows distributed CDNs to greatly enhance the scalability of content distribution. [14]

IV. KEY PERFORMANCE INDICATORS IN ASSOCIATION WITH QOE AND QOSIn previous sections of this paper we described how this application works and we analyzed the

technologies adopted by the service in matters of compression and transmission. In this part we will set key performance indicators that are associated with the quality of experience of the user and the quality of service.

Quality of experience is the perceived QoS and is defined as the degree of annoyance or delight of the user of the service. In our use case we will set key performance indicators that influence the QoE according to our video on demand service corresponding to values that are acceptable. The key performance indicators and the acceptable values in matters of quality of experience are displayed in the following table.

Table 2. QoE parameters.

Key performance indicators Acceptable valuesAvailability of the service Very important ~ 99.999% availabilityLatency at the beginning Less important ~ 3 secInterruption of video Very important. Users demand 0

interruption.





Quality of video No pixelization. No blocking. High resolutions. Synchronized video and audio.

Advertisements Users are annoyed by advertisements at the beginning and during the video.

Difficulty of application The application should be user friendly.Tolerance of users Most of the users have zero tolerance in

technical problems.

Quality of service is defined as the level of the performance needed for the application or service in order to function properly. According to our service we will set key performance indicators that influence the QoS corresponding to acceptable values. The following table displays those key performance indicators corresponding to acceptable values.[15]

Table 3. QoS parameters.

Key performance indicators Acceptable valuesAvailable bandwidth 1-7 MbpsPacket loss No more than 5%Jitter Zero jitter (due to buffering)Sync skew 120 ms (video proceeds voice) , 20

ms(voice proceeds video)Latency at the beginning No more than 4-5 sec

V. EXPERIMENT

In section 2 we described the compression and transmission process that take place in order to perform video on demand streaming. In this part of the paper we focus on the compression process. The experimental scenario is the following: we use two different videos, the bus video and the akiyo video [16]. The bus video contains a lot of movement in contrast to akiyo video. Each video is compressed using the codec H.264-AVC with different containers using mkv and mp4 in three different coding bit rates, 384 kbps, 768 kbps and 1024 kbps. The video size in all cases remains stable, so does the aspect ratio and the frames per second (fps). The goal of our experiment is to understand how the different videos with different containers, in different bit rates, behave in matters of quality and to understand where is the difference. In this part of our experiment we use the MSU VQMT in order to purchase metric such as PSNR(higher is better), SSIM(precise)(higher is better) and VQM (lower is better).

In order to perform our experiment, we downloaded those two videos from xiph.org and we used the FFMPEG with WinFF (GUI) and the Format Factory in order to convert those videos. For the bus video, the size is 352 x 288, the aspect ratio is 4:3 and the frames per second 30. For the akiyo video, the size is 352 x 288, the aspect ratio is 4:3 and the frames per second 29.97. The aforementioned values are constant during our experiment. The variable in our experiment are the video context, the bit rate and the containers (mkv, mp4). In the MSU VQMT we compare the raw video with the compressed video in every case in order to purchase the aforementioned metrics. The csv files that MSU gives us are processed using the excel in order to create useful charts.





Experimental results:

For the bus video the results are displayed in the following charts:

Figure 5. PSNR metric

Figure 6. SSIM metric





Figure 7. VQM metric

For the akiyo video the results are displayed in the following charts:

Figure 8. PSNR metric





Figure 9. SSIM metric

Figure 10. VQM metric





Table 4. bus video

Metrics vs Videos

mkv_384 mp4_384 mkv_768 mp4_768 mkv_1024 mp4_1024

PSNR(average) 25.2976 17.1439 27.6005 16.9048 28.4831 16.8939SSIM(average) 0.7458 0.4101 0.8312 0.3226 0.8578 0.3916VQM(average) 4.5012 11.0365 3.4746 11.33874 3.1613 11.3452File size (KB) 235 229 464 451 617 607

Table 5. akiyo video

Metrics vs Videos

mkv_384 mp4_384 mkv_768 mp4_768 mkv_1024 mp4_1024

PSNR(average) 40.7665 36.5379 41.8454 36.6303 42.0173 36.6381SSIM(average) 0.9749 0.9774 0.9786 0.9792 0.9793 0.9796VQM(average) 0.7353 1.0779 0.6712 1.0429 0.6600 1.0368File size (KB) 456 450 917 907 1,221 1,212

Considering the experimental results that are plotted in the above charts as also the tables above that contain the average values of the metrics and the file size, we come up with some interesting conclusions. In the case of video with movement (bus) the mkv container behaves more effectively than the mp4 container. However, in the case of video with little movement (akiyo) the mp4 container is more effective than the mp4 container. So, the content of the video is a factor that we should consider in order to choose the preferred container. In addition, as the bit rate increases the quality gets better but there is a tradeoff because the file size increases. Furthermore, the claim that mkv files are larger than the mp4 files is true but in our experiment there is a little difference, almost 10KB. Finally, in the case of bus video we clearly see that PSNR and SSIM is better when the container is mkv than mp4. Nevertheless, the VQM metric is better when the container is mp4 than mkv. It is widely known that represents better the subjective judgment. So in order to realize which container behaves more effectively we should perform a subjective evaluation.

VI. CONCLUSIONS AND FUTURE WORK

Summarizing, in this paper we focused on a video on demand service called Dailymotion and we analyzed the technical solutions that are adopted in video on demand services. We analyzed how video compression is achieved and how the user is able to stream videos via Internet. Finally, we performed an experiment were our goal was to find how different containers behave according to the content of the video and the different bit rates, in matters of quality where we used the objective method. Finally, we came up with some interesting conclusions after we finished our experiment. Some of those conclusions can be used for future work where a subjective method could be performed in order to realize if the differences that we see in the experimental results can be perceived by the user.





References

[1] daylimotion upload guidelines: http://www.dailymotion.com/upload/ , Accessed on 10/11/2015[2] https://faq.dailymotion.com/hc/en-us/articles/203790706-Upload-specifications-and- encoding-settings Accessed on 13/11/2015[3] Effect of Codec Performance on Video QoE for videos encoded with Xvid, H.264 and WebM/VP8 , Raj Kiran Addu and Kumar Potuvardanam,School of

Computing Blekinge Insitute of Technology SE-371 79 Karlskrona Sweden, Master Thesis Electrical Engineering August 2014 [4] The H.264/AVC Advanced Video Coding Standard: Overview and Introduction to the Fidelity Range Extensions, Gary J. Sullivan*, Pankaj Topiwala†, and

Ajay Luthra‡, * Microsoft Corporation, One Microsoft Way, Redmond, WA 98052 †FastVDO LLC, 7150 Riverwood Dr., Columbia, MD 21046, ‡Motorola Inc., BCS, 6420 Sequence Dr., San Diego, CA 92121, Presented at the SPIE Conference on Applications of Digital Image Processing XXVIISpecial Session on Advances in the New Emerging Standard: H.264/AVC, August, 2004

[5] Video coding with H.264/AVC: Tools, Performance, and Complexity , Jörn Ostermann, Jan Bormans, Peter List, Detlev Marpe, Matthias Narroschke, Fernando Pereira, Thomas Stockhammer, and Thomas Wedi, IEEE CIRCUITS AND SYSTEMS MAGAZINE, FIRST QUARTER 2004

[6] INTERNATIONAL STANDARD ISO/IEC 14496-14 First edition2003-11-15 Information technology — Coding of audio-visual objects —Part 14:MP4 file format

[7] http://mpeg.chiariglione.org/faq/what-bifs , Accessed on 16/11/2015[8] http://mpeg.chiariglione.org/faq/whats-mpeg-4-initial-object-descriptor-iod , Accessed on 18/11/2015[9] http://www.tansee.com/what-is-mp4-video.html , Accessed on 20/11/2015[10] http://matroska.org/technical/whatis/index.html , Accessed on 24/11/2015[11] Matroska File Format (under construction!) Alexander Noé [email protected] Last change: January 11, 2009y[12] http://matroska.org/technical/diagram/index.html , Accessed on 27/11/2015[13] https://www.dmcloud.net/features/video-lifecycle , Accessed on 7/12/2015[14] Watching Video over the Web Part 1: Streaming Protocols Ali C. Begen, Tankut Akgul, and Mark Baugher • Cisco, IEEE INTERNET COMPUTING,

Published by the IEEE Computer Society, 089-7801/11/$26.00 © 2011 IEEE[15] http://www.ciscopress.com/articles/article.asp?p=357102&seqNum=2 , Accessed on 13/12/2015[16] https://media.xiph.org/video/derf/ , Accessed on 15/12/2015


https://media.xiph.org/video/derf/

http://www.ciscopress.com/articles/article.asp?p=357102&seqNum=2

https://www.dmcloud.net/features/video-lifecycle

http://matroska.org/technical/diagram/index.html

http://mpeg.chiariglione.org/faq/whats-mpeg-4-initial-object-descriptor-iod

http://mpeg.chiariglione.org/faq/what-bifs

https://faq.dailymotion.com/hc/en-us/articles/203790706-Upload-specifications-and-

Xevgenis_Michail_CI7120 Multimedia Communications

Documents

Transcript of Xevgenis_Michail_CI7120 Multimedia Communications