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 (%): ________________________________________
Module:
Module Coordinator:
Kingston University London

Module:
Module Coordinator:

Dailymotion: A survey of a Video on Demand service and a video quality
assessment.
Xevgenis Michael
Egaleo, Athens, Greece
mxevgenis@outlook.com.gr
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
Module:
Module Coordinator:

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]
Module:
Module Coordinator:

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]
Module:
Module Coordinator:

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]
Module:
Module Coordinator:

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
Module:
Module Coordinator:

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
Module:
Module Coordinator:

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 MKV
Developer MPEG CoreCodec ,Inc
Video 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 players
Portable devices supported All the portable devices Not all the portable devices
Quality 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.
Module:
Module Coordinator:

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 QOS
In 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 values
Availability of the service Very important ~ 99.999% availability
Latency at the beginning Less important ~ 3 sec
Interruption of video Very important. Users demand 0
interruption.
Module:
Module Coordinator:

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 values
Available bandwidth 1-7 Mbps
Packet 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.
Module:
Module Coordinator:

Experimental results:
For the bus video the results are displayed in the following charts:
Figure 5. PSNR metric
Figure 6. SSIM metric
Module:
Module Coordinator:

Figure 7. VQM metric
For the akiyo video the results are displayed in the following charts:
Figure 8. PSNR metric
Module:
Module Coordinator:

Figure 9. SSIM metric
Figure 10. VQM metric
Module:
Module Coordinator:

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.8939
SSIM(average) 0.7458 0.4101 0.8312 0.3226 0.8578 0.3916
VQM(average) 4.5012 11.0365 3.4746 11.33874 3.1613 11.3452
File 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.6381
SSIM(average) 0.9749 0.9774 0.9786 0.9792 0.9793 0.9796
VQM(average) 0.7353 1.0779 0.6712 1.0429 0.6600 1.0368
File 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.
Module:
Module Coordinator:

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 XXVII
Special 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é alex@alexander-noe.com 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
Module:
Module Coordinator:

Xevgenis_Michail_CI7120 Multimedia Communications

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Xevgenis_Michail_CI7120 Multimedia Communications

Ähnlich wie Xevgenis_Michail_CI7120 Multimedia Communications (20)

Xevgenis_Michail_CI7120 Multimedia Communications