BAB I

PENDAHULUAN

1.1 Latar Belakang
Dengan keberhasilan situs , seperti YouTube dan Vimeo , video streaming melalui Internet telah
menjadi semakin populer . Sebuah laporan baru-baru ini [ 19 ] perkiraan bahwa bisnis media streaming
akan tumbuh sebesar 27 % per tahun , menghasilkan lebih US $ 78 miliar pada pendapatan di AS sendiri
selama enam tahun ke depan . mengingat cakupan luas data rate Nirkabel Wide Area Networks ( WWAN
) dan munculnya perangkat mobile pribadi dengan menampilkan resolusi tinggi dan kecepatan
pemrosesan yang cepat ( misalnya , smartphone dan tablet ) , multimedia streaming sekarang salah satu
aplikasi mobile dengan pertumbuhan tercepat . Hingga saat ini, teknologi video streaming sebagian besar
telah mengadopsi adaptif pendekatan , dimana bit-rate dan kualitas video yang dipilih sebelum
dimulainya streaming , dan tetap selama sesi streaming. ini adalah biasanya cukup ketika pemirsa
terhubung melalui koneksi kabel , yang memiliki kapasitas bandwidth yang tinggi dan cukup stabil .
Namun, dalam konteks kendaraan mobilitas , di mana penampil pada kendaraan yang bergerak
menyaksikan video streaming pada perangkat mobile ( ponsel , tablet atau laptop ) yang terhubung ke
Internet melalui WWAN koneksi , solusi non - adaptif mungkin tidak optimal . Hal ini karena, Kondisi
bandwidth WWAN di lingkungan seperti itu berfluktuasi secara signifikan , bahkan di skala waktu yang
lebih kecil . Hal ini disebabkan karakteristik radio heterogen dan kondisi beban jaringan WWAN di lokasi
yang berbeda sebagai kendaraan membuat jalan sepanjang rute [ 7 ] . The berikutnya fluktuasi bandwidth
seperti lingkungan yang dinamis secara serius dapat membahayakan QoS dialami tradisional aplikasi
streaming. Sebagai contoh, selama sesi live streaming , jika bandwidth yang theWWAN tiba-tiba turun
jauh di bawah streaming yang dipilih tingkat , penampil video yang bisa menderita terlihat " gangguan "
yang disebabkan oleh frame loss atau sering jeda dalam pemutaran disebabkan oleh kelelahan buffer
playout . Untuk mengurangi dampak dari dinamika bandwidth dan mencapai halus pengalaman
streaming, adaptif streaming yang muncul sebagai solusi yang menjanjikan [ 2-4 , 9-12 , 16 , 18 , 20 ] .
Dalam adaptif streaming, server streaming dan / atau klien terus-menerus memonitor real-time kondisi
jaringan end-to -end . berdasarkan informasi ini , video bit-rate dan kualitas secara dinamis disesuaikan
dengan beradaptasi dengan perubahan kondisi jaringan yang mendasarinya . Akibatnya , adaptif
streaming yang memberikan aliran video kualitas yang lebih baik dibandingkan dengan konvensional
pendekatan non - adaptif . Prinsip adaptif streaming telah dimasukkan dengan protokol tradisional
streaming, seperti RTSP [ 11 ] , dan dievaluasi dalam berbagai karya sebelumnya [ 16 , 18 , 20 ] . Namun,
karena popularitas menggunakan HTTP dalam video streaming, tren umum di industri adalah dengan
menggunakan adaptif
HTTP download progresif [ 2-4 , 9-12 ] . Beberapa produk tersebut bahkan telah dirilis oleh Jaringan
Pindah, Microsoft , Adobe dan Apple. Meskipun popularitas , evaluasi empiris komprehensif HTTP
adaptif streaming kurang . di tertentu , kinerja adaptif HTTP Streaming di bawah kecepatan tinggi
mobilitas kendaraan belum dilaporkan .
Tujuan kami dalam makalah ini adalah untuk mengatasi masalah di atas dan empiris
mengevaluasi kinerja HTTP adaptif streaming bawah mobilitas kendaraan . Namun, melakukan " hidup "
eksperimen di mana klien streaming yang beroperasi pada perangkat mobile yang terhubung ke jaringan
WWAN dan bepergian dalam kendaraan memiliki beberapa masalah . Untuk secara komprehensif
mengevaluasi pengaruh berbagai parameter tertentu pada kinerja streaming, kita perlu melakukan
perjalanan terpisah, masing-masing dengan nilai yang berbeda dari parameter. Namun, jaringan WWAN
bandwidth yang diketahui bervariasi dari perjalanan ke perjalanan [ 21 ] . Dengan demikian , tidak
mungkin untuk mempelajari pengaruh perubahan parameter dalam isolasi . Selanjutnya , melakukan tes
cukup dengan statistik hasil yang dapat diandalkan akan memerlukan membuat sejumlah besar perjalanan
, yang mahal di jam kerja dan biaya moneter ( bahan bakar dan WWAN bandwidth yang berlangganan ) .
Dalam tulisan ini , kami telah memilih maka untuk melakukan percobaan dalam lingkungan laboratorium
terkendali , tetapi menggunakan " nyata" Jejak bandwith WWAN yang empiris dikumpulkan dari
kendaraan yang bergerak . Dalam percobaan kami , kami melaporkan kinerja HTTP adaptif streaming di
bawah pengaruh berbagai parameter , seperti ambang batas penyangga dan video yang sepotong ukuran .
Hasil kami menunjukkan bahwa adaptif HTTP streaming efektif dalam bereaksi dengan fluktuasi luas
yang melekat dalam mobilitas kendaraan dan akhirnya mencapai pengalaman penampil ditingkatkan oleh
lebih dari empat kali lipat . Berdasarkan kami evaluasi , kita membuat rekomendasi tentang nilai-nilai
yang sesuai dari parameter kunci pengaturan untuk mencapai kinerja yang optimal , yang dapat berguna
bagi industri
praktisi . Sisa dari makalah ini diorganisasikan sebagai berikut .
Bagian 2 membahas latar belakang dan karya-karya yang terkait . Dalam Bagian 3 kami
menyajikan pengukuran kendaraan berkampanye untuk mengumpulkan jejak bandwidth yang digunakan
dalam makalah ini . Kami menyajikan setup kami percobaan - jejak didorong dalam Bagian 4 . Temuan
percobaan kami disajikan dalam Bagian 5 . Bagian 6 menyimpulkan makalah ini .
1.2 Rumusan Masalah
Berdasarkan latar belakang tersebut di atas, dapat dirumuskan beberapa permasalahan sebagai berikut
:
Bagaimana penggunaan aplikasi DASHencoder sebagai media streaming ?
Bagaimana Qualitas of Service (QoS) pada streaming memakai aplikasi DASHencoder?
1.3 Tujuan Penelitian
Adapun tujuan dari penulisan penelitian ini adalah untuk mengetahui bahwa DASHencoder dapat
dijadikan media streaming untuk meningkatkan kualitas streaming supaya tidka terjadi buffer pada saat
menonton video streaming.
1.4 Batasan Masalah
Melihat luasnya permasalahan yang ada pada penelitian ini, maka dapat dibatasi permasalahan pada :
Pengujian DASHencoder sebagai aplikasi media streaming.
Pengujian dalam bentuk contoh nyata implementasi pada sebuah http menggunakan aplikasi
DASHencoder.
















BAB II
TINJAUAN PUSTAKA
2.1 Non - adaptif Streaming
Kebanyakan layanan streaming yang tradisional bergantung pada protokol khusus yang secara
khusus dirancang untuk streaming. RTSP ( Real Time Streaming Protocol ) [ 17 ] adalah contoh khas dari
protokol tersebut. Setelah sesi streaming yang telah ditetapkan , file media dikirim sebagai aliran paket
tetap berukuran kecil . Server biasanya mengirimkan data cukup untuk mengisi buffer klien ( biasanya
kurang dari 10 detik ) . ini Pendekatan tradisional streaming yang dapat digunakan untuk melakukan
streaming baik on-demand dan hidup video. Namun, itu memerlukan penyebaran dedicated server media
dan penggunaan pelabuhan khusus . Ini mungkin memiliki masalah dengan skalabilitas , caching dan
penetrasi firewall client [ 11 ] . Metode lain yang populer untuk video mengukus adalah HTTP progresif
men-download . Idenya mirip dengan download file normal dari HTTP Server . Satu-satunya perbedaan
adalah bahwa video dapat diputar ulang secara bersamaan saat itu sedang di-download . Ini juga berarti
bahwa bahkan jika pengguna jeda yang media, server akan melanjutkan pengiriman data sampai seluruh
file di-download . Perhatikan bahwa , ini berbeda dengan pendekatan pertama dijelaskan sebelumnya , di
mana server berhenti transmisi paket jika buffer client diisi . Kelemahan jelas metode HTTP adalah
bahwa jika pengguna memutuskan untuk mengakhiri sesi , maka semua disimpan (tapi un - dilihat ) video
dalam buffer akan dibuang , sehingga membuang-buang bandwidth yang digunakan dalam mentransfer
data ini . Selain itu, signifikan Kerugian dari HTTP download progresif adalah bahwa ia tidak dapat
mendukung hidup Streaming , sebagai ukuran dari seluruh video yang telah ditentukan dan tetap selama
sesi Streaming [ 11 ] . Namun, pendekatan HTTP merupakan solusi biaya efektif untuk pengiriman
video on -demand , seperti menggunakan kembali ada cache HTTP / proxy tanpa perlu server khusus .
Selain itu, penggunaan protokol HTTP menghilangkan masalah dengan firewall [ 4 , 11 ] . Saat ini, video
sharing paling popular website , misalnya , Youtube dan Vimeo , secara eksklusif menggunakan
pendekatan ini . Kedua teknik tersebut adalah non - adaptif , dalam streaming kualitas dan bit-rate tetap
tidak berubah selama seluruh durasi streaming.
Pemilihan parameter ini adalah salah ditentukan secara otomatis atau berdasarkan preferensi
pengguna pada awal sesi . Ini dapat melayani baik dalam lingkungan jaringan stasioner dan kabel , di
mana bandwidth relatif konstan . Namun, dalam konteks mobilitas kendaraan ( yang merupakan fokus
dari makalah ini ) , bandwidth nirkabel diketahui berfluktuasi secara signifikan sebagai kendaraan
perubahan lokasi . Oleh karena itu pendekatan non - adaptif dapat secara signifikan dipengaruhi oleh
fluktuasi bandwidth dan mengarah ke pemutaran video dendeng dan akhirnya berdampak pada pengguna
pengalaman menonton (lihat hasil dalam Bagian 5.1 ) .
2.2 Adaptive Streaming
Berbeda dengan metode tradisional , adaptif streaming memungkinkan dinamis penyesuaian
dalam bit-rate streaming ( dan kualitas ) untuk beradaptasi dengan berbagai endto - mengakhiri kondisi
bandwidth, selama sesi hidup . Gambar 1 menggambarkan khas skenario . Sebuah server streaming
adaptif host video yang telah dikodekan di berbagai tingkat - bit . File-file ini dibuat oleh encoding video
sumber yang sama beberapa kali dengan memvariasikan pengaturan kuantisasi dan frame rate , atau
menggunakan maju teknik encoding , seperti Scalable Video Coding ( SVC ) [ 10 ] . masing-masing
video stream dikodekan kemudian dibagi menjadi urutan kecil " potongan " , misalnya , Kelompok
Pictures ( GOP ) , yang dapat diterjemahkan secara independen [ 10 ] . karena potongan video yang
dipartisi di bawah kualitas yang berbeda disinkronisasi , ada berbagai bit -rates yang tersedia untuk setiap
potongan video. Selama streaming, server dapat mulus beralih kualitas streaming yang menggunakan - bit
rate yang berbeda untuk setiap video chunk . Misalnya, server dapat beralih ke mengirimkan potongan
dengan rendah bit-rate ketika mendeteksi bahwa bandwidth yang tersedia mengurangi , sehingga anggun
merendahkan yang melihat kualitas kedua protokol streaming spesifik dan HTTP streaming.






Gambar 3.1 Skenario Adaptive Video Streamingpada Keadaan Berjalan
Perhatikan bahwa , prinsip adaptif dapat segera diterapkan untuk Karya sebelumnya [16,18,20]
telah mengusulkan mekanisme untuk menerapkan adaptif Streaming dengan memperluas protokol
streaming tradisional. Konsep dasar melibatkan server dan / atau klien mengandalkan pada beberapa
tingkat kontrol algoritma / protokol untuk menyimpulkan kondisi bandwidth yang sebenarnya.
Berdasarkan perkiraan ini, memilih server yang potongan berikutnya dengan kualitas yang sesuai dari
pilihan yang tersedia. diskusi pada beberapa algoritma adaptasi tingkat tersebut telah diusulkan [8, 10].
Secara umum, kondisi jaringan yang disimpulkan dalam menanggapi perubahan metrik diamati, seperti
hunian buffer video yang playout atau tertentu end-to-end parameter jaringan (yaitu delay, packet loss
dan throughput).
Karena kelebihan yang disebutkan dalam Bagian 2.1 menggunakan HTTP dalam video
pengiriman , berbasis HTTP adaptif streaming telah menarik minat yang signifikan dalam industri .
Dalam HTTP adaptif streaming, seluruh video streaming dibagi menjadibanyak download progresif kecil
, dimana setiap transaksi HTTP memberikan satu potongan video ke klien . Setelah sesi didirikan , server
mengembalikan
mewujudkan berkas ke klien . File manifest daftar tersedia - bit rates ( biasanya 4-5 ) untuk setiap
potongan video yang [ 4 , 11 ] . Pada menerima setiap potongan , langkah-langkah klien throughput untuk
memperkirakan kondisi bandwidth end-to -end . Berdasarkan diperkirakan bandwidth dan playout kondisi
buffer , klien menentukan bit-rate dan permintaan potongan video yang sesuai melalui HTTP cocok GET
permintaan. Perhatikan bahwa , karena setiap potongan video secara individual dikodekan dan
ditransmisikan , ukuran video yang streaming bisa tak terbatas . Dengan demikian , tidak seperti
pendahulunya ( HTTP download progresif ) , HTTP adaptif streaming juga sepenuhnya mendukung untuk
streaming acara live . Baru-baru ini , Adaptive HTTP Streaming ( AHS ) memiliki telah diintegrasikan ke
dalam 3GPP Transparan end-to -end Packet -switched Streaming Service ( PSS ) [ 2 ] . 3GPP AHS juga
telah diadopsi oleh IPTV Forum Terbuka ( OIPF ) sebagai komponen inti streaming adaptif mereka solusi
[ 14 ] . MPEG juga menyusun standar baru disebut Dynamic Adaptive Streaming melalui HTTP ( DASH
) [ 9 ] . Didorong oleh popularitas , komersial HTTP adaptif streaming produk , seperti Move Networks [
12 ] , Microsoft Halus Streaming [ 11 ] , Apple HTTP live streaming [ 5 ] dan Adobe Dinamis HTTP
Streaming [ 3] , telah tersedia . Teknik ini telah berhasil digunakan oleh NBC dalam penyiaran Olimpiade
Beijing pada tahun 2008 [ 11 ] .
Kinerja non - HTTP teknik streaming yang adaptif telah dievaluasi dan dipelajari dalam karya-
karya sebelumnya [ 16 , 18 , 20 ] . Namun, evaluasi yang dilakukan dengan menggunakan simulasi
dengan bandwidth data sintetik . Meskipun popularitas , evaluasi empiris rinci HTTP adaptif streaming
kurang , untuk yang terbaik dari pengetahuan kita . Dalam tulisan ini , kami bermaksud untuk mengisi
kesenjangan ini dan menyelidiki kinerja HTTP adaptif streaming bawah mobilitas kendaraan.





BAB III
METODE

3.1 Bandwidth Jejak Collection
Tujuan dari penelitian ini adalah untuk mengevaluasi adaptif HTTP Streaming di dunia nyata
skenario mobilitas kendaraan . Pendekatan jelas adalah untuk mengimplementasikan klien nyata dan
Server dan melakukan tes hidup saat mengemudi . Namun, ada beberapa masalah dalam melakukan
eksperimen tersebut . Untuk secara komprehensif mengevaluasi pengaruh mengubah parameter tertentu
(seperti playout penyangga threshold , video yang ukuran chunk ) pada kinerja streaming, kita perlu
melakukan perjalanan terpisah , masing-masing dengan nilai yang berbeda dari parameter. Namun,
diketahui bahwa jaringan WWAN bandwidth yang dapat bervariasi dari perjalanan ke perjalanan bahkan
ketika perjalanan berturut-turut yang dibuat satu demi satu (lihat [ 21 ] untuk penyelidikan rinci tentang
variabilitas bandwidth) . Dengan demikian , tidak mungkin untuk mempelajari pengaruh perubahan
parameter dalam isolasi . Selanjutnya , bahkan jika bandwidth cukup stabil di berbagai perjalanan ,
melakukan semua tes yang kami lakukan dalam Pasal 5 sampai mencapai signifikansi statistik yang
memadai akan membutuhkan kita untuk membuat ratusan perjalanan . Jelas, jumlah jam kerja dan biaya (
bahan bakar , langganan WWAN ) terlibat sangat tinggi untuk melakukan tes tersebut . Oleh karena itu ,
kami telah memilih untuk melakukan - jejak didorong evaluasi dalam lingkungan laboratorium terkendali.
Untuk ini , kita menggunakan jejak bandwidth yang terkumpul dari kampanye wardriving kami
sebelumnya [ 21 ] di Sydney . Berikut ini, kita meninjau secara singkat rincian kampanye .
Untuk pengukuran , sistem pengukuran client-server sederhana ( lebih lanjut Rincian dapat
ditemukan dalam [ 21 ] ) dikembangkan dengan menggunakan hardware off-the -shelf . itu Server
bertempat di laboratorium kami di University of New South Wales ( UNSW ) . sebagai ditunjukkan pada
Gambar . 2 ( a) , klien terdiri dari dua papan Soekris Net4521 saling berhubungan melalui 10 Mbps
Ethernet . Papan yang tertutup dalam casing pelindung dan bertempat di bagasi mobil . Tiga modem
seluler PCMCIA ditempatkan di sistem . Untuk meningkatkan penerimaan sinyal wireless , modem
seluler yang terhubung ke antena eksternal dipasang di kaca depan mobil . Kami mengukur dua HSDPA [
1 ] jaringan dan satu iBurst [ 6 ] jaringan . Sebuah sensor GPS Garmin adalah terhubung ke sistem untuk
merekam lokasi kendaraan.
Kami mengembangkan sebuah utilitas packet - kereta ringan untuk mengukur theWWAN
bandwidth. Kita lihat pembaca untuk [ 21 ] untuk informasi lebih lanjut dan validasi . Kami
mengumpulkan satu sampel bandwidth untuk kira-kira setiap 200m bagian dari rute . itu sampel dengan
koordinat lokasi dan waktu tagged , dan disimpan dalam repositori . Pada kesempatan, beberapa sampel
bandwith yang hilang akibat meledak packet loss . Untuk menutupi efek dari sampel yang hilang , kita
menggunakan bandwidth rata-rata semua sampel mentah yang dikumpulkan dalam setiap segmen 500m
untuk mewakili bandwidth untuk segmen . Oleh karena itu granularity bandwidth jejak adalah 500 m .
Kami telah mengumpulkan sampel bandwidth dengan mengendarai mobil bersama dua
perwakilan rute komuter sehari-hari di wilayah metropolitan Sydney . selama periode pengukuran delapan
bulan , kami telah mengumpulkan 75 jejak WWAN bandwith di kedua rute . Gambar . 2 ( b ) menyajikan
lintasan rute yang digunakan dalam penelitian evaluasi ini . Rute yang dipilih ( 16,5 Km ) berjalan dari
Sydney CBD ke Macquarie University ( MQ ) . Dalam percobaan kami , kami menggunakan bandwidth
jejak dari ke-75 perjalanan untuk salah satu jaringan HSDPA .
3.2 Pengaturan Percobaan
Tujuan dari penelitian ini adalah untuk mengevaluasi kinerja HTTP adaptif streaming di bawah
dunia nyata kondisi bandwidth dalam mobilitas kendaraan berkecepatan tinggi . kami mempertimbangkan
skenario bahwa seorang penumpang di dalam kendaraan menonton video streaming di perangkat mobile-
nya (telepon, tablet atau laptop) saat mengemudi dari lokasi A ke B. Kami berasumsi bahwa pemirsa
menonton video untuk seluruh perjalanan.
Kami menerapkan HTTP Streaming prototipe client-server adaptif dalam JAVA dan percobaan
yang dilakukan menggunakan bandwidth yang jejak empiris kami di lingkungan laboratorium terkendali
(lihat diskusi pada Bagian 3). Gambar 3 menyajikan konfigurasi percobaan. Penelitian ini melibatkan 3
Linux (Ubuntu 12.04) mesin. Server HTTP dan file video yang di-host pada mesin server. bandwidth
pembentuk mengemulasi perubahan bandwidth link HSDPA sesuai dengan bandwidth melacak file.
Klien memulai sesi streaming dan permintaan potongan video menggunakan HTTP dari server seperti
yang dibahas dalam Bagian 2.2.

















Gambar 2.2 Setting untuk Uji Coba Aplikasi DASHencoder
Karena link kabel di Internet dan jaringan inti HSDPA memiliki bandwidth yang cukup tinggi
dan penundaan kecil dibandingkan dengan yang terakhir - hop HSDPA link, server dan pembentuk
bandwidth yang terhubung melalui statis 100 Mbps Ethernet link dengan delay 10 ms propagasi untuk
mewakili internet kabel . itu klien dan pembentuk bandwidth juga secara fisik terhubung dengan 100
Mbps Ethernet link . Namun, dalam rangka untuk meniru perubahan bandwidth kendaraan perjalanan
sepanjang rute , kami menggunakan tc sistem utilitas pada pembentuk bandwidth untuk throttle
bandwidth dari link antara pembentuk bandwidth dan klien . di setiap percobaan berjalan, kita meniru satu
perjalanan mengemudi , dimana pembentuk bandwidth yang bervariasi bandwidth di setiap lokasi sesuai
dengan empiris sesuai bandwith jejak untuk perjalanan ( dikumpulkan dalam Bagian 3 ) .
Untuk klip video, kami membuat video perulangan ( menggunakan gerakan menengah QCIF
urutan " Foreman " [ 10 ] ) yang berlangsung selama 40 menit , yang cukup lama dari durasi dari semua
perjalanan . Sebelum percobaan dimulai , video preencoded 31 kualitas kuantisasi yang berbeda ( sesuai
dengan bit - Harga mulai 80 Kbps sampai 1Mbps ) menggunakan MPEG - 4 codec . Perhatikan bahwa ,
produk komersial biasanya menggunakan sejumlah kecil bit -rates untuk menghemat ruang disk dan
memfasilitasi manajemen file .Video dikodekan dipartisi menjadi serangkaian ukuran yang sama
potongan video dibahas dalam Bagian 2.2 . Perhatikan bahwa , ukuran sepotong dikonfigurasi [ 11 ] . di
Bagian 5.3 , kita akan menyelidiki efek menggunakan ukuran potongan berbeda .
Pada awal perjalanan , klien memulai sesi dengan server . Server akan mengirimkan file manifest
dari seluruh video ke klien . File ini berisi semua ( 31 , dalam percobaan kami ) tersedia - bit rate untuk
setiap potongan video, yang dapat digunakan selama streaming. Klien selalu meminta untuk bit-rate
terendah tersedia untuk potongan pertama . Pada menerima sepotong dari server , client mengukur
throughput sesaat potongan untuk memperkirakan bandwidth kondisi . Klien menentukan bit-rate ( dari
yang tercantum dalam manifest file) yang akan digunakan untuk potongan video berikutnya , berdasarkan
bandwidth estimasi dan hunian buffer playout . Perhatikan bahwa , semua video yang potongan yang
diterima akan menjadi yang pertama disimpan ke dalam buffer playout sebelum dimainkan kembali .
Awalnya, video yang buffered perlu mencapai ambang bi playout penyangga awal sebelum pemutaran
dimulai . Perhatikan bahwa , rebuffering akan terjadi setiap kali buffer playout adalah underrun .
Pemutaran akan berhenti sampai hunian penyangga mencapai bi . untuk menjamin mulus streaming, bit-
rate strategi pemilihan yang paling sederhana adalah dengan selalu memilih sepotong dengan bit-rate
yang lebih rendah dari bandwidth yang diperkirakan saat ini . Namun, hal ini dapat mengakibatkan
peningkatan konstan dalam hunian penyangga, jika tingkat Video potongan kedatangan terus-menerus
lebih besar daripada tingkat pemutaran . terlalu banyak penyangga tidak diinginkan dalam adaptif
streaming, karena semua un - melihat video dalam buffer akan dibuang , jika pengguna mengakhiri sesi .
Hal ini tidak hanya limbah bandwidth yang tersedia untuk mentransfer data buffer tetapi juga merindukan
kesempatan untuk memberikan kualitas video yang lebih baik kepada klien , yaitu , dengan menggunakan
bitrate yang lebih tinggi . Oleh karena itu , HTTP komersial adaptif implementasi streaming yang dikenal
menerapkan beberapa mekanisme kontrol aliran untuk mempertahankan penyangga hunian wajar [ 4 , 11
] . Namun, mekanisme rinci adalah proprietary . Dalam tulisan ini , kita telah menggunakan skema
berbasis threshold sederhana untuk tujuan ini . Selama mengalir , klien berkonsultasi hunian penyangga
sebelum memilih bit-rate dari potongan video berikutnya . Ketika hunian penyangga lebih rendah dari
ambang batas bf , yang klien memilih bit-rate tertinggi yang lebih rendah dari bandwidth yang
diperkirakan saat ini .Jika tidak , klien memilih bit-rate terendah yang lebih tinggi dari bandwidth saat ini.
Dalam hal ini , tingkat kedatangan potongan video yang diharapkan menurun , karena bit-rate yang dipilih
lebih besar dari bandwidth yang tersedia . Kami telah diasumsikan ambang kendali penyangga , bf = 1,5
bi . Koefisien 1.5 dipilih berdasarkan percobaan pilot kami ( termasuk untuk alasan singkatnya ) .
Untuk mengevaluasi kualitas video, kita menggunakan kerangka Evalvid - RA [ 10 ] , yang
diterima dengan baik untuk evaluasi kualitas video yang dikirimkan melalui nyata atau simulasi jaringan
komunikasi. Selama streaming, kita log yang diperlukan informasi pada server dan klien sesuai dengan
kerangka . setelah percobaan selesai , file-file log yang digunakan untuk merekonstruksi urutan video
yang diterima. Ingat bahwa , selama kasus rebuffering , pemutaran akan dijeda. Untuk contoh-contoh ,
kita mengisi periode dijeda dengan menyalin frame yang terakhir diputar . Pendekatan serupa sering
digunakan oleh media player untuk menangani frame yang hilang . Kami menggunakan alat yang tersedia
dari Evalvid - RA untuk memproses sumber dan diterima video dan menghasilkan Puncak Signal - to-
Noise Ratio ( PSNR ) [ 10 ] untuk setiap frame . Untuk mendapatkan wawasan yang lebih baik tentang
pengalaman menonton yang sebenarnya , kami memperkirakan Mean Opinion Score ( MOS ) dari nilai
PSNR untuk setiap frame . Secara khusus , kami menggunakan model empiris [ 13 ] diperoleh untuk
urutan Foreman khusus yang digunakan dalam percobaan kami,


di mana k = 0,56, a = 14,2 dan b = 280,5. Perhatikan bahwa, MOS berkisar dari 0 sampai 5. A
MOS dari 5 menunjukkan "sangat bagus" pengalaman menonton, sementara yang benar-benar 0 tidak
dapat diterima. Oleh karena itu MOS ditetapkan untuk 0 untuk frame beku selama buffering.














DAFTAR PUSTAKA

1. 3GPP: High Speed Downlink Packet Access - Overall description - Stage 2
2. 3GPP TS 26.234: Transparent end-to-end packet switched streaming service (PSS); Protocols and
codecs (2010)
3. Adobe Systems Incorporated: Dynamic Streaming
4. Akamai: Akamai HD for iPhone Encoding Best Practices - Akamai HD Network
5. Apple Inc.: HTTP Live Streaming Overview
6. Arracomm Inc.: iBurst Broadband Wireless - System Overview
7. Derksen, J., Jansen, R., Maijala, M., Westerberg, E.: HSDPA Performance and
8. Evolution. Ericsson Review (03), 117120 (2006)
9. Floyd, S., Handley, M., Padhye, J., Widmer, J.: TCP Friendly Rate Control (TFRC): Protocol
Specification. RFC5348 (Sep 2008)
10. ISO/IEC CD 23001-6: Information technology MPEG systems technologies Part 6: Dynamic
adaptive streaming over HTTP (DASH) (2011)
11. Lie, A., Klaue, J.: Evalvid-RA: Trace Driven Simulation of Rate Adaptive MPEG-4 VBR Video.
ACM/Springer Multimedia Systems Journal 14 (Nov 2007)
12. Microsoft Corporation: IIS Smooth Streaming Technical Overview Move Networks:
http://www.movenetworks.com/