Judul Paper Abstraksi Metodologi Solusi Kelebihan &

Kekurangan
ANALISA KINERJA DAN
IMPLEMENTASI ADAPTIVE
TRANSCODER PADA
JARINGAN LAN (LOCAL AREA
NETWORK)
Tujuan dari paper ini adalah merancang
sebuah sistem adaptive transcoding yang
mampu membaca kondisi bandwidth yang
dilewati oleh data multimedia streaming
sehingga memenuhi standar Quality of Service
(QoS) untuk data multimedia streaming. Pada
sistem adaptive transcoding tersebut proses
transcoding yang digunakan, sesuai dengan
kapasitas dari bandwidth yang dilewati oleh
data multimedia streaming pada jaringan
Local Area network (LAN). Transcoding sendiri
adalah sebuah suatu proses untuk
mengkoversi file dengan bit rate yang tinggi
ke file dengan bit rate yang lebih rendah dan
sebaliknya berdasarkan penurunan dari
bandwidth consumer sampai dengan
bandwidth efficient. Sistem adaptive
transcoding dirancang dengan menggunakan
algoritma prioritas yang melakukan proses
pengecekan jumlah bit loss dan packet loss
yang diterima oleh pengguna (client). Untuk
menghitung jumlah bit loss adalah mencari
nilai selisih dari bit data yang dikirim oleh
server dengan bit data yang di terima oleh
client. Jika didapatkan bit loss lebih besar dari
10% dari total data bit yang dikirimkan oleh
server, maka sistem adaptive transcoding
akan melakukan penurunan prioritas
transcoding ke level yang lebih rendah.
Dimana kualitas format encoding video dan
audio dari hasil transcoding lebih rendah dari
Pada testbed yang dilakukan server
mendapatkan data multimedia
berupa data video dan data suara
dengan cara melakukan capturing.
Data tersebut kemudian di
distribusikan kepada pengguna
(client), apabila client sudah
melakukan prosedur yang harus
dilakukan dalam sistem
pendistribusian data pada sistem
client server. Prosedur
pelaksanaannya adalah sebagai
berikut; Pada skenario ini semua
pengguna pada jaringan test bed
mendapatkan bentuk format
encoding yang sama dengan
kualitas yang baik waktu pertama
kali data multimedia dikirimkan
dari server ke semua client tanpa
memandang bandwidth yang
dilewati. Setiap pengguna
mempunyai kapasitas bandwidth
yang beragam. Kemungkinan
terjadi packet loss ada, terutama
pada pengguna yang memiliki
kapasitas bandwidth yang rendah.
Untuk itulah dibutuhkan peran
serta transcoder untuk mengubah
fornat data yang memerlukan
kapasitas bandwidth yang besar ke
format data yang memerlukan
Protokol yang menghubungkan
pengiriman data streaming dari
server ke client menggunakan
protokol UDP dan IP. UDP
sangat baik sekali digunakan
untuk aplikasi video streaming.
Kemudian Adaptive transcoder
dilakukan pada saat bandwidth
yang dilewati data multimedia
mengalami fluktuasi sehingga
data yang sampai ke tujuan
mengalami packet loss di
jaringan.
Transcoder mendapatkan
jumlah paket data yang
terkirim dari tempat tujuan
dalam waktu asumsi tiap 5
detik sehingga dari data
tersebut dilakukan
perbandingan jumlah paket,
antara paket data yang dikirim
oleh server berbanding dengan
jumlah paket data yang
diterima oleh receiver. Jika
terjadi kehilangan paket data
yang cukup banyak maka
transcoder melakukan proses
transcoding dengan format data
multimedia yang dikirim
mempunyai kapasitas file yang
lebih rendah. Jika tidak terjadi
Kelebihan:
- Sistem adaptive
transcoder bekerja
cukup baik apabila
bandwidth yang
dilewati oleh data
multimedia streaming
mencapai 1024 kbps
atau sebesar 1 Mbps
walaupun dari hasil
capturing dan hasil
streaming oleh server
hanya mempuyai nilai
maksimum frame rate
sebesar 10 fps.

Kekurangan:
- Pada sistem adaptive
transcoder dan jaringan
testbed yang dirancang
terjadi delay yang cukup
besar apabila
bandwidth mengalami
penurunan kapasitas
yang drastis
prioritas sebelumnya. kapasitas bandwidth yang lebih
kecil. Uji coba di dalam testbed
memerlukan bandwidth yang
mempunyai kapasitas beragam.
Untuk itu diperlukan keberadaan
Traffic Shaping yang difungsikan
agar dapat merubah bandwidth
yang dimiliki oleh pengguna.
Sehingga seakan- akan bandwidth
semua pengguna pada test bed
tersebut terlihat dinamis. Untuk
melakukan proses transcoder
diperlukan adanya service broker
yang difungisikan sebagai interface
antara client, server dan
transcoder. 3.2 Prioritas untuk
Format Transcoding Prioritas untuk
format transcoding sangat
dibutuhkan, karena satu format
boleh mempunyai kualitas yang
lebih baik dari format yang lain.

packet loss maka tidak
dilakukan proses transcoding.
Sistem adaptive transcoder
menggunakan pemilihan
prioritas yang. Apabila terjadi
packet loss lebih dari 10% paket
yang dikirimkan server, maka
dilakukann proses transcoding
dengan prioritas yang lebih
rendah. Salah satu contoh
apabila proses dari transcoding
yang sedang berjalan adalah
prioritas 2, jika terjadi lagi
packet loss lebih dari 10%.
Maka akan dilakukan proses
transcoding dengan prioritas
yang ke 3. Untuk data
multimedia yang diterima oleh
client mempunyai packet loss
kurang dari 10% dari jumlah
packet data multimedia yang
dikirimkan oleh server. Maka
prioritas dari proses
transcoding akan dinaikan 1
tingkat dari prioritas yang
sebelumnya. Sebagai contoh
proses pengiriman data yang
dikirimkan berada pada
prioritas ke 3, dan data
multimedia streaming yang
diterima oleh client mengalami
packet loss kurang dari 10
persen dari data yang
dikirimkan server maka
dilakukan proses transcoding
dengan prioritas yang ke 2.
DESAIN DAN IMPLEMENTASI
SISTEM VIDEO ON DEMAND
(VOD) BERBASIS WEB
MENGGUNAKAN HTTP
PSEUDOSTREAMING
Video merupakan komponen yang penting
dalam teknologi multimedia. Video yang
merepresentasikan gambar bergerak dan
suara, layak untuk dijadikan sebagai alat
bantu dalam proses belajar, ataupun karya
berupa film, dan lain sebagainya. Diperlukan
sebuah sistem khusus untuk menampung
video karena kapasitasnya yang besar
sehingga dapat meringankan beban platform
e-learning seperti Moodle. Selain itu,
pembangunan aplikasi yang dibuat dari awal
dapat membuat pengembangan aplikasi
menjadi lebih lama.
Oleh karena itu, pada penelitian Desain dan
Implementasi Sistem Video On Demand (VOD)
Berbasis Web Menggunakan HTTP
Pseudostreaming akan dirancang sistem VOD
berbasis web dengan menggunakan
pendekatan Component Based Software
Engineering (CBSE). Salah satu fitur utama
yang dikembangkan dalam sistem ini adalah
penggunaan HTTP Pseudostreaming yang
memanfaatkan proses pemilihan acak pada
video sehingga memudahkan pengguna
dalam proses kontrol video.
Penelitian ini dilakukan dengan menguji fitur
pseudostreaming serta menguji performa
aplikasi terhadap transfer rate dan kualitas
video pada sistem yang telah terhubung
dengan Internet. Hasil menunjukkan bahwa
Langkah awal adalah studi literatur
untuk mendapatkan dasar teori
yang menunjang penelitian. Dari
teori pendukung tersebut akan
didapatkan asumsi awal. Pada
analisis kebutuhan, tindakan yang
dilakukan adalah mengidentifikasi
semua kebutuhan yang diperlukan
dari sistem yang akan dibangun
meliputi kebutuhan antarmuka,
analisis basis data, kebutuhan non
fungsional, dan kebutuhan
fungsional Perancangan sistem
berisi rancangan sistem sebelum
diimplementasikan. Perancangan
meliputi perancangan infrastruktur,
perangkat lunak, serta pengujian
sistem sebelum diimplementasikan.
Pada implementasi, tindakan yang
dilakukan adalah
mengimplementasikan apa yang
telah dibahas pada perancangan
implementasi meliputi pembuatan
database, pembuatan program
konten Video on Demand, lalu
integrasi database dan program
VoD. Setelah implementasi,
dilakukan pengujian fungsional
dengan black box dan pengujian
transfer rate dan kualitas video

sistem VOD yang dirancang dapat melakukan
pseudostreaming, serta dapat mendeteksi
transfer rate pengguna. Berdasarkan transfer
rate tersebut, sistem akan memilih kualitas
video yang direkomendasikan untuk pengguna
sehingga mendapatkan kualitas streaming
yang sesuai.
melalui traffic shaping, serta
pengujian non-fungsional yaitu
pengujian kinerja aplikasi tehadap
transfer rate dan kualitas video
pada sistem yang sudah terkoneksi
Internet. Tahap terakhir adalah
analisis hasil dari pengujian, lalu
diambil kesimpulan.
A VIDEO STREAMING
APPLICATION USING MOBILE
MEDIA APPLICATION
PROGRAMMING INTERFACE
perkembangan teknologi telepon selular
berkembang dengan pesat.
Perkembangan ini mengarah pada lahirnya
mobile multimedia phone yang mendukung
koneksi
Wireless Local Area Network (WLAN). Akan
tetapi penggunaan teknologi WLAN pada
telepon
seluler untuk mengakses video secara
streaming sangat jarang ditemui. Sedangkan
Symbian
S60 saat ini sebagai sistem operasi mobile
multimedia phone sangat handal dalam
menangani
berbagai macam media seperti video.
Pembahasan dalam penelitian ini menyajikan
pembuatan
aplikasi video streaming pada mobile
phone melalui koneksi WLAN dengan
menggunakan
teknologi JSR 135 atau lebih dikenal
dengan Mobile Media API (MMAPI).
This research built an
application called Pocket
VidStream used to play
streaming
videos on mobile devices. To run
the video streaming, the software
on a mobile device that acts
as a client should connect to a
server that functions as a provider
of video streaming services.
We used Mobile Media API
(MMAPI) of Java 2
Microedition to handle data
transmission
protocol (protocol handling) and
handling the contents of the
data (content handling). The
handling protocol reads data
from source (such as files,
streaming servers, captured
device)
and then processes them in
the media processing system.
While the content handling
processes the media data (such
Experiments are conducted
to observe the system's
functionality, compatibility,
and
performance.
Compatibility
Experiment
Compatibility
testing is done to
observe the
compatibility of the
system to other devices
that uses the same
application. This
experiment also
observes the maximum
range of mobile
devices that can be
reached. Compatibility
is measured by the
functioning of all the
features and
functionality of the
system. This
compatibility test
measured the
functions of the
system in
running the protocol
and playing video
MMAPI digunakan
untuk mengontrol proses video
streaming dan fitur-fitur pendukungnya.
Aplikasi ini akan
menggunakan 2 pilihan protokol yaitu
RTSP dan HTTP. Hasil uji coba
menunjukkan bahwa
penggunaan MMAPI pada telepon
seluler berbasis Symbian 60 untuk
melakukan video
streaming dapat diterapkan dan mempunyai
kehandalan yang baik. Hal ini ditunjukkan
dengan
nilai paket loss 0% pada koneksi yang reliable
dan waktu yang dibutuhkan untuk memutar
file
multimedia tidak terpengaruh oleh besar file
yang dibuka.
as parsing or decoding) and
then renders to output devices
such as audio speakers or
video displays. At the API,
there are two high-level
objects used;
they are data source and player.
Each object represents one of the
multimedia processing. Data
source object represents the
protocol handling, while the player
object represents the content
handling.
In this application, video
streaming uses on-demand
streaming concept. The protocol
used in on-demand streaming
protocol is HTTP and RTSP. On-
demand streaming is activated
by user request and can be
presented at any time in
accordance with requests from the
client.
In other words, on-demand
streaming is similar to seeing video
tapes where we can pause and
play the video.
The concept of client server
used is as follows. Server: a
computer that is used as a
server streaming (RTSP servers and
HTTP servers), and client: a mobile
device that performs
content over the
WLAN connection.
There are two
protocols used in this
experiment, i.e. HTTP
and RTSP. This
experiment is shown in
Table 1.
Table 2 shows that this
system runs well on
mobile phones with
Symbian operating
system 5th
Edition. However, this
application cannot run
the RTSP protocol over
a WLAN connection.

Performance
Experiments
Performance
testing was
conducted to
observe the effect
of several scenarios
on
system
performance.
System performance
can be observed
from execution
time. This
experiment is still using
requests to a Server.
The device used to run this
application has to support the
necessary infrastructure and
support the type of media
files to be played. To play a
media, it takes two objects,
namely:
DataSource and Player. DataSource
handles details of how to
obtain data from sources that
are available. Source comes from
servers that provide streaming
service. Player need not be
too concerned about where the
data originated from or how to get
it. The player only needs to
read data from DataSource,
processes, displays and plays
media playback on the output
device. There is a third party in this
scenario, i.e. the Manager. The
manager creates Player
from the DataSource. It creates a
Player from the media source
location (URL), DataSource and
InputStreams.
HTTP and RSTP
protocols.
ADAPTATION ALGORITHM
FOR ADAPTIVE STREAMING
OVER HTTP
Internet video makes up a signicant part of
the
Internet trafc and its fraction is constantly
growing. In order
to guarantee best user experience throughout
different network
Fast home broadband connections,
the growing popularity
of connected TV sets, and the
spread of WiFi/3G enabled
mobile terminals are among the
key drivers for the growing
Figure 1 shows the convergence
properties of the algorithm
on a link with unlimited
bandwidth (local loop). The
upper
subgure shows the selected
This work has been
partially supported by
the FP7 COAST
project (FP7-ICT-
248036), funded by the
European Commu-
access technologies with dynamically varying
network conditions,
it is fundamental to adopt technologies
enabling a proper delivery
of the media content. One of such
technologies is adaptive stream-
ing. It allows to dynamically adapt the bit-rate
of the stream to
varying network conditions. There are various
approaches to
adaptive streaming. In our work, we focus on
the receiver-driven
approach where the media le is subdivided
into segments, each
of the segments is provided at multiple bit-
rates, and the task
of the client is to select the appropriate bit-
rate for each of the
segments. With this approach, the challenges
are (i) to properly
estimate the dynamics of the available
network throughput, (ii)
to control the lling level of the client buffer
in order to avoid
underows resulting in playback
interruptions, (iii) to maximize
the quality of the stream, while avoiding
unnecessary quality
uctuations, and, nally, (iv) to minimize the
delay between
the users request and the start of the
playback. During our
work, we designed and implemented a
popularity of Internet video. In
addition to faster connections,
technological improvements in
video coding and video de-
livery are making it possible for
more consumers to watch
video content online. In order to
guarantee best user expe-
rience throughput different
network access technologies with
dynamically varying network
conditions, it is fundamental to
adopt technologies enabling a
proper delivery of the media
content. One of such technologies
is adaptive video streaming.
The concept of adaptive video
streaming is based on the
idea to adapt the bandwidth
required by the video stream
to the throughput available on the
network path from the
stream source to the client. The
adaptation is performed by
varying the quality of the streamed
video and thus its bit-rate,
that is, the number of bits required
to encode one second of playback.
One of the approaches here is to
divide the video
stream into segments and to
encode each of the segments
in multiple quality levels, called
bit-rate ri, the lower subgure
the dynamics of buffer level
(t). The playback started ap-
proximately 250 ms after the
begin of the download. After
1.25 s, the algorithm reached
the maximum available bit-rate.
Figure 2 shows the reaction of
the algorithm to persistent
throughput changes. The upper
subgure shows the articial
throughput limitation, the
measured segment throughput
i
and the selected bit-rate ri. The
lower subgure shows the
dynamics of buffer level (t).
After the initial phase, where
the throughput was limited to
1000 kbit/s, the throughput
limitation was shifted to 2000
kbit/s for 200 seconds, and then
back to 1000 kbit/s. The
algorithm reacted by adapting
the bit-
rate of the stream after a
moderate delay.
Figure 3 shows the results of a
run, where the client was
exposed to periodic short-term
throughput spikes lasting for 5 s
each. The desired behavior here
is not to follow the individual
nity
receiver-driven adaptation
algorithm for adaptive streaming that does
not rely on cross-layer
information or server assistance. We
integrated the algorithm
with a prototype implementation of a
streaming client based
on the MPEG DASH (Dynamic Adaptive
Streaming over HTTP)
standard. We evaluated the implemented
prototype in real-world
scenarios and found that it performes
remarkably well even
under challenging network conditions.
Further, it exhibits stable
and fair operation if a common link is shared
among multiple
clients.
representations. Based on
his estimation of the available
throughput, a client might
request subsequent segments at
different quality levels in order
to cope with varying network
conditions. The algorithmic
process of deciding the optimal
representation for each of
the segments in order to optimize
the viewing experience is
a key element and one of the major
challenges in adaptive
streaming systems. In particular,
the challenges for the client
are (i) to properly estimate the
dynamics of the available
throughput, (ii) to control the lling
level of the local buffer in
order to avoid underows resulting
in playback interruptions,
(iii) to maximize the quality of the
stream, while avoiding
unnecessary quality uctuations,
and, nally, (iv) to minimize
the delay between the users
request and the start of the
playback.
Recent years have seen the advent
and widespread of
streaming technologies based on
the HTTP/TCP protocols.
The use of HTTP/TCP offers several
spikes but rather to stay with a
bit-rate that is feasible with
the available average
throughput. This is also the
behavior
exhibited by the algorithm.
Figure 4 shows an experiment
in a domestic WiFi network
with a high level of interference
and heavy cross-trafc. We
observe that the algorithm is
able to follow the dynamics of
the average available
throughput in a robust manner.
The last two gures 5 and 6
show an articial and a real-
world scenario where two
players share a common link. In
the rst scenario, the test is run
over the local loop with total
throughput restricted to 2000
kbit/s. In the second scenario,
the clients stream over the
domestic WiFi. In both
scenarios,
we observe that the clients are
able to share the available
bandwidth in a stable and fair
manner.
Finally, we remark that in all the
runs, no buffer underruns
occured.
advantages. It is cost-
effective since standard web
servers and caches can be used.
Furthermore, it is rewall-friendly
since almost all rewalls
are congured to support HTTP
connections. Finally, HTTP
is stateless and the streaming
session is managed by the client,
reducing the load on the server and
thus allowing for better
scalability. On the other hand,
operation on top of HTTP/TCP
reveals additional challenges since
adaptation on top of TCPs
congestion control algorithm
creates nested control loops.
In our study, we designed an
algorithm for dynamic selec-
tion of segment bit-rate based on
the network conditions. We
implemented the algorithm as a
platform independent software
library. Further, based on the
GStreamer framework [1], we
implemented a client for the
recently adopted standard for
adaptive streaming over HTTP:
MPEG DASH [2]. We inte-
grated the developed algorithm
with the client and evaluated
its performance in real-world
scenarios.
The outline of the paper is as
follows. Section II contains
references to related work. In
section III we describe our
system model, assumptions and
notation. Section IV describes
the adaptation algorithm including
adaptation goals, input
arguments and conguration
parameters. It also provides the
pseudo-code of the algorithm.
Section V presents the results
of the evaluation. Finally, section VI
concludes the paper.
DYNAMIC ADAPTIVE
STREAMING OVER HTTP
DESIGN PRINCIPLES AND
STANDARDS
In this paper, we provide some insight and
background into the
Dynamic Adaptive Streaming over HTTP
(DASH) specifications
as available from 3GPP and in draft version
also from MPEG.
Specifically, the 3GPP version provides a
normative description
of a Media Presentation, the formats of a
Segment, and the deliv-
ery protocol. In addition, it adds an
informative description on
how a DASH Client may use the provided
information to establish
a streaming service for the user. The solution
supports different
service types (e.g., On-Demand, Live, Time-
Shift Viewing),
different features (e.g., adaptive bitrate
HTTP-based progressive download
does have significant market
adoption. Therefore, HTTP-based
streaming should be as closely
aligned to HTTP-based progressive
download as possible, but
take into account the above-
mentioned deficiencies.
The solution supports features
such as
fast initial startup and
seeking,
bandwidth-efficiency,
adaptive bitrate switching,
adaptation to CDN
properties,
re-use of HTTP-server and
caches,
re-use of existing media
playout engines,
support for on-demand, live
and time-shift delivery services,
simplicity for broad
adoption.
3GPP has also sought alignment
with other organizations and
industry fora that work in the
Specifically the solution
is designed
to support delivery of
media components
encapsulated in
ISO base media file
format box structure,
to address delivery
whereas presentation,
annotation and user
interaction is largely
out-of-scope,
to permit integration
in different
presentation
frameworks.
The 3GPP sub-group
SA4 working on codecs
and protocols for
switching, multiple lan-
guage support, ad insertion, trick modes,
DRM) and different
deployment options. Design principles and
some forward-looking
considerations are provided.
area of video distribution. For
ex-
ample, as the Open IPTV Forum
(OIPF) based their HTTP Adap-
tive Streaming (HAS) solution
[8] on 3GPP. 3GPP recently also
addressed certain OIPF
requirements and integrated
appropriate
features in the Release-9 3GPP
Adaptive HTTP Streaming speci-
fication. Also MPEGs draft
DASH solution is heavily based
on
3GPPs AHS. Finally, 3GPP has
ongoing work in Release-10,
now also referred to as DASH.
This work will extend the
Release-
9 3GPP AHS specification in a
backward-compatible way.
Close
coordination with the ongoing
MPEG DASH activities is orga-
nized.
media delivery started
the HTTP streaming
activity in April 2009
and completed the
Release-9 specification
work early March
2010. The 3GPP
Adaptive HTTP
Streaming (AHS) has
been
integrated into 3GPP
Transparent end-to-end
Packet-switched
Streaming Service (PSS).
Specifically, 3GPP TS
26.234 [1] (PSS
Codecs and Protocols)
clause 12 specifies the
3GPP Adaptive
HTTP Streaming
solution, and 3GPP TS
26.244 [2] (3GP File
Format) clauses 5.4.9,
5.4.10, and 13 specify
the encapsulation
formats for segments.
The Release-9 work is
now under mainte-
nance mode and some
minor bug fixes and
clarifications were
agreed during the year
2010 and have been
integrated into the
latest versions of 3GPP
TS 26.234 and 3GPP TS
26.244.