laporanta 13510024 nicholas rio

BROWSER BASED LIVE STREAMING

Laporan Tugas Akhir

Disusun sebagai syarat kelulusan tingkat sarjana

Oleh

NICHOLAS RIO

NIM : 13510024

PROGRAM STUDI TEKNIK INFORMATIKA

SEKOLAH TEKNIK ELEKTRO & INFORMATIKA

INSTITUT TEKNOLOGI BANDUNG

September 2014


Laporan Tugas Akhir

disusun sebagai syarat kelulusan tingkat sarjana

Oleh

NICHOLAS RIO

NIM : 13510024

Program Studi Teknik Informatika

Sekolah Teknik Elektro dan Informatika

Institut Teknologi Bandung

Telah disetujui dan disahkan sebagai Laporan Tugas Akhir

di Bandung, pada tanggal …………. 2014

Pembimbing I, Pembimbing II,

Dr. Ir. MM. Inggriani Achmad Imam K, S.T. Msc, PhD

NIP. 19530116-197903-2-001 NIP. 19730809-200604-1-001

i

LEMBAR PERNYATAAN

Dengan ini saya menyatakan bahwa:

1. Pengerjaan dan penulisan Tugas Akhir ini dilakukan tanpa menggunakan

bantuan yang tidak dibenarkan.

2. Segala bentuk kutipan dan acuan terhadap tulisan orang lain yang

digunakan di dalam penyusunan Laporan Tugas Akhir ini telah dituliskan

dengan baik dan benar.

3. Tugas Akhir ini belum pernah diajukan pada program pendidikan di

perGuruan tinggi mana pun.

Jika terbukti melanggar hal-hal di atas, saya bersedia dikenakan sanksi sesuai

dengan Peraturan Akademik dan Kemahasiswa Institut Teknologi Bandung

bagian Penegakan Norma Akademik dan Kemahasiswaan khususnya Pasal 2.1

dan Pasal 2.2.

Bandung,

Nicholas Rio

NIM 13510024

ii

ABSTRAK


Oleh

NICHOLAS RIO

NIM : 13510024

Seiring dengan berkembangnya teknologi dan kecepatan internet, telah tercipta

berbagai layanan live streaming pada berbagai perangkat. Namun, masih ada

beberapa masalah pada aplikasi-aplikasi live streaming yang tersedia. Masalah –

masalah yang ada antara lain adalah masih diperlukan suatu aplikasi khusus untuk

melakukan live streaming, tidak ada protokol standar antar aplikasi dan integrasi

antar aplikasi masih sulit dilakukan.

Sebagai solusi dari masalah ini, dapat dikembangkan sebuah modul live streaming

yang menggunakan teknologi HTML5. Oleh karena itu, tujuan akhir dari Tugas

Akhir ini adalah sebuah modul live streaming yang digunakan pada aplikasi web.

Dalam rangka pembuatan sebuah modul live streaming, penulis melakukan

berbagai studi literatur mengenai streaming, software library, WebSocket, dan

WebRTC. serta eksplorasi pada aplikasi – aplikasi terkait. Modul aplikasi live

streaming dibuat dengan arsitektur jaringan peer to peer dengan sebuah signaling

server. Hasil testing menunjukkan bahwa signaling server yang dibuat dapat

menangani 1000 koneksi signaling konkuren, dan jumlah maksimal user dalam

satu room adalah 8 pengguna. Modul aplikasi juga sudah digunakan pada tiga

buah studi kasus yang berbeda, yaitu One to One Chat, Online Class, dan Video

Conference.

Kata kunci : live streaming, peer to peer, modul, media.

iii

KATA PENGANTAR

Puji dan syukur penulis sampaikan ke hadirat Tuhan YME, karena dengan rahmat

dan karunia-Nya penulis dapat menyelesaikan Tugas Akhir ini. Tugas Akhir ini

dapat diselesaikan berkat bantuan dan dukungan dari berbagai pihak. Untuk itu

penulis ingin menyampaikan terima kasih kepada :

1. Bapak Dr. tech. Saiful Akbar, S.T., M.T. dan Bapak Dr. techn. Wikan

Danar Sunindyo, S.T., M.Sc selaku dosen penguji atas masukan dan

evaluasi yang telah diberikan pada saat seminar dan sidang.

2. Ibu Dr. Ir. M. M. Inggriani dan Bapak Achmad Imam Kistijantoro, S.T.,

M.Sc, Ph.D selaku dosen pembimbing untuk segala nasihat, pelajaran,

cerita dan dukungan semangat yang diberikan selama pelaksanaan Tugas

Akhir.

3. Seluruh dosen dari Program Studi Teknik Informatika ITB untuk didikan,

bimbingan, dan ilmu yang telah diberikan selama perkuliahan.

4. Ibu Titi Ratri Purnomo Wulan, A.Md. dan Ibu Sri Rahayu Setianingsih,

A.Md. dan seluruh pegawai Teknik Informatika ITB untuk bantuannya

selama proses pengerjaan Tugas Akhir.

5. Kedua orang tua dan adik atas doa, dukungan, perhatian dan semangat

yang diberikan.

6. Martha, Sharon, Jordan, Irfan, Edward, dan Kevin sebagai teman satu

bimbingan yang telah saling mendukung saat proses pengerjaan Tugas

Akhir.

7. Stefan, Endi dan Jeremy sebagai teman sekelas selama kuliah di Program

Studi Teknik Informatika.

8. Teman – teman lain dari berbagai organisasi di luar ITB untuk dorongan

semangatnya selama proses pengerjaan Tugas Akhir.

9. Semua pihak yang tidak dapat disebutkan satu per satu, yang telah

membantu pengerjaan Tugas Akhir baik secara langsung maupun secara

tidak langsung.

Semoga hasil Tugas Akhir ini dapat bermanfaat dan berguna bagi kemajuan ilmu

informatika. Penulis menerima dengan terbuka segala kritik dan saran

membangun dari pembaca. Terima kasih.

Bandung, September 2014

Nicholas Rio

13510024

iv

DAFTAR ISI

ABSTRAK .......................................................................................................... ii

KATA PENGANTAR ....................................................................................... iii

DAFTAR ISI ..................................................................................................... iv

DAFTAR LAMPIRAN .................................................................................... vii

DAFTAR GAMBAR ....................................................................................... viii

DAFTAR TABEL ............................................................................................. xi

BAB I. PENDAHULUAN .................................................................................. 1

I.1. Latar Belakang ........................................................................................ 1

I.2. Rumusan Masalah ................................................................................... 3

I.3. Tujuan .................................................................................................... 3

I.4. Batasan Masalah ..................................................................................... 3

I.5. Metodologi ............................................................................................. 4

I.6. Sistematika Pembahasan ......................................................................... 4

BAB II. STUDI LITERATUR DAN EKSPLORASI ........................................ 6

II.1. Streaming ............................................................................................ 6

II.1.1. Definisi Streaming ......................................................................... 6

II.1.2. Cara Kerja Streaming .................................................................... 6

II.2. Eksplorasi Terhadap Aplikasi - Aplikasi Terkait .................................. 7

II.2.1. Skype ........................................................................................... 7

II.2.2. Google Hangouts ........................................................................ 8

II.3. Software Library .................................................................................. 9

v

II.3.1. Definisi Software Library ............................................................ 10

II.4. HTML5 .............................................................................................. 10

II.4.1. WebSocket ................................................................................ 11

II.4.2. Web Real Time Communication .................................................. 14

BAB III. ANALISIS ......................................................................................... 16

III.1. Analisis pada Aplikasi Streaming yang Telah Ada ............................. 16

III.1.1. Analisis Kapabilitas ..................................................................... 16

III.2. Analisis Jaringan Peer to Peer dan Client - Server ............................. 17

III.3. Arsitektur Aplikasi Live Streaming .................................................... 19

III.4. Analisis Kebutuhan Modul Aplikasi ................................................... 22

III.5. Software Requirements ...................................................................... 22

III.6. Operational Requirements ................................................................. 23

III.7. Analisis Metode Pengiriman Data Media ........................................... 24

BAB IV. Pengembangan modul aplikasi live streaming................................. 28

IV.1. Platform Implementasi dan ................................................................ 28

IV.2. Perancangan dan Implementasi Modul Aplikasi Live Streaming ......... 28

IV.2.1. Perancangan dan Implementasi Kelas pada Modul Aplikasi Live

Streaming 29

IV.3. Collaboration Diagram pada Web Based Live Streaming Application 32

IV.4. Perancangan Pengujian Modul Aplikasi Live Streaming ..................... 37

IV.4.1. Tools Pengujian Modul Aplikasi Live Streaming ......................... 37

IV.4.2. Unit Testing Aplikasi Live Streaming .......................................... 37

IV.4.3. Load Test Aplikasi Live Streaming .............................................. 38

BAB V. STUDI KASUS ................................................................................... 40

vi

V.1. Studi Kasus Pembuatan Aplikasi Web untuk One to One Chat ........ 40

V.1.1. Kebutuhan Fungsional ................................................................. 40

V.1.2. Rancangan Aplikasi ..................................................................... 41

V.1.3. Skenario Pengujian ...................................................................... 42

V.1.4. Hasil Benchmark ......................................................................... 45

V.1.5. Kesimpulan Studi Kasus .............................................................. 48

V.2. Studi Kasus Pembuatan Web Application untuk Online Class .......... 48






V.3. Studi Kasus Pembuatan Web Application untuk Video Conference.. 57






V.4. Kesimpulan Studi Kasus Keseluruhan ................................................ 75

BAB VI. Kesimpulan dan Saran ..................................................................... 76

VI.1. Kesimpulan ........................................................................................ 76

VI.2. Saran ................................................................................................. 76

DAFTAR REFERENSI ................................................................................... 78

vii

DAFTAR LAMPIRAN

Lampiran A. MediaStream Processing API ..................................................... 79

Lampiran B. Hasil Unit Testing ....................................................................... 81

Lampiran C. Sequence Diagram ...................................................................... 82

viii

DAFTAR GAMBAR

Gambar I-1 Ilustrasi Cara Kerja Streaming........................................................... 1

Gambar II-1 Aplikasi Skype ............................................................................... 8

Gambar II-2 Aplikasi Google Hangouts .......................................................... 9

Gambar II-3 Cara Kerja WebSocket (Wang, 2013). ........................................ 12

Gambar II-4 Sequence Diagram Siklus Hidup WebSocket .............................. 13

Gambar II-5 Pembentukan koneksi antar pengguna (Johnston, 2013). ................ 15

Gambar III-1 Ilustrasi Arsitektur peer to peer .................................................... 18

Gambar III-2 Ilustrasi Arsitektur client-server ................................................... 18

Gambar III-3 Arsitektur aplikasi live streaming Google Hangouts ................ 19

Gambar III-4 Arsitektur Modul Aplikasi Live Streaming Skype ....................... 20

Gambar III-5 Arsitektur Aplikasi dengan Modul Live Streaming ........................ 21

Gambar IV-1 Rancangan Arsitektur Aplikasi Live Streaming ............................. 29

Gambar IV-2 Diagram kelas modul aplikasi live streaming ................................ 31

Gambar IV-3 Collaboration Diagram Antar Node Pada Konfigurasi Node One to

One .................................................................................................................... 33

Gambar IV-4 Collaboration Diagram Antar Node dengan Konfigurasi Node One

To Many ............................................................................................................ 34

Gambar IV-5 Collaboration Diagram Antar Node pada Konfigurasi Jaringan

Many to Many .................................................................................................... 36

Gambar V-1 Diagram Kelas Aplikasi One to One Chat ................................. 41

Gambar V-2 Bitrate Video Pengguna Pertama ................................................... 45

Gambar V-3 Framerate Video Pengguna Pertama ............................................. 46

ix

Gambar V-4 Bitrate Audio Pengguna Pertama ................................................... 46

Gambar V-5 Bitrate Video Pengguna Kedua ...................................................... 47

Gambar V-6 Framerate Video Pengguna Kedua ................................................ 47

Gambar V-7 Bitrate Audio Pengguna Kedua...................................................... 48

Gambar V-8 Diagram Kelas Aplikasi Online Class ........................................ 50

Gambar V-9 Bitrate Video Murid Pertama ......................................................... 54

Gambar V-10 Framerate Video Murid Pertama ................................................. 54

Gambar V-11 Bitrate Audio Murid Pertama ....................................................... 55

Gambar V-12 Bitrate Video Murid Kedua ......................................................... 56

Gambar V-13 Framerate Video Murid Kedua .................................................... 56

Gambar V-14 Bitrate Audio Murid Kedua ......................................................... 57

Gambar V-15 Diagram Kelas Aplikasi Video Conference ............................. 58

Gambar V-16 Bitrate Video Pengguna Pertama dari Pengguna Kedua ............... 64

Gambar V-17 Framerate Video Pengguna Pertama dari Pengguna Kedua ......... 64

Gambar V-18 Bitrate Audio Pengguna Pertama dari Pengguna Kedua ............... 65

Gambar V-19 Bitrate Video Pengguna Pertama dari Pengguna Ketiga ............... 65

Gambar V-20 Framerate Video Pengguna Pertama dari Pengguna Ketiga ......... 66

Gambar V-21 Bitrate Audio Pengguna Pertama dari Pengguna Ketiga ............... 67

Gambar V-22 Bitrate Video Pengguna Kedua dari Pengguna Pertama ............... 67

Gambar V-23 Framerate Video Pengguna Kedua dari Pengguna Pertama ......... 68

Gambar V-24 Bitrate Audio Pengguna Kedua dari Pengguna Pertama ............... 69

Gambar V-25 Bitrate Video Pengguna Kedua dari Pengguna Ketiga.................. 69

Gambar V-26 Framerate Video Pengguna Kedua dari Pengguna Ketiga ............ 70

Gambar V-27 Bitrate Audio Pengguna Kedua dari Pengguna Ketiga ................. 70

x

Gambar V-28 Bitrate Video Pengguna Ketiga dari Pengguna Pertama ............... 71

Gambar V-29 Framerate Video Pengguna Ketiga dari Pengguna Pertama ......... 71

Gambar V-30 Bitrate Audio Pengguna Ketiga dari Pengguna Pertama ............... 72

Gambar V-31 Bitrate Video Pengguna Ketiga dari Pengguna Kedua .................. 73

Gambar V-32 Framerate Video Pengguna Ketiga dari Pengguna Kedua ............ 73

Gambar V-33 Bitrate Audio Pengguna Ketiga dari Pengguna Kedua ................. 74

xi

DAFTAR TABEL

Tabel III-1 Perbandingan kapabilitas Skype dan Google Hangouts .............. 16

Tabel III-2 Perbandingan arsitektur peer to peer dan client - server.................... 17

Tabel III-3 Tabel Kompabilitas Browser dengan WebSocket .......................... 24

Tabel III-4 Tabel Kompabilitas Browser dengan API WebRTC ........................ 24

Tabel III-5 Analisis Metode Pengiriman Data Media.......................................... 25

Tabel III-6 Analisis Metode Sinkronisasi Media ................................................ 27

Tabel IV-1 Tabel Traceability Modul Live Streaming ........................................ 31

Tabel V-1 Tabel Kebutuhan Fungsional Aplikasi One to One Chat ................ 40

Tabel V-2 Skenario Normal Aplikasi One to One Chat .................................. 42

Tabel V-3 Skenario Alternatif Aplikasi One to One Chat ............................... 43

Tabel V-4 Kebutuhan Fungsional Aplikasi Online Class ................................ 49

Tabel V-5 Skenario Pertama Aplikasi Online Class ........................................ 51

Tabel V-6 Skenario Kedua Aplikasi Online Class ........................................... 52

Tabel V-7 Kebutuhan Fungsional Aplikasi Video Conference ....................... 58

Tabel V-8 Skenario Pertama Aplikasi Video Conference ............................... 60

Tabel V-9 Skenario Kedua Aplikasi Video Conference ................................. 62

1

BAB I.

PENDAHULUAN

I.1. Latar Belakang

Streaming adalah pengiriman dan penampilan data multimedia secara langsung

dari penyedia layanan multimedia. Streaming menjadi persoalan yang khusus

karena selama data multimedia dikirim, data multimedia yang telah sampai

kepada pengguna layanan juga langsung ditampilkan tanpa menunggu data

menjadi lengkap. Data multimedia yang diterima ataupun dikirimkan dapat berupa

data video, audio, atau bahkan gambar dan teks saja.

Salah satu layanan streaming yang populer adalah live streaming. Pada layanan

streaming biasa, penyedia layanan telah menyimpan data multimedia yang akan

disajikan. Pada layanan live streaming, data multimedia disajikan secara real time.

Seiring dengan meningkatnya teknologi dan kecepatan internet dewasa ini, telah

dikembangkan berbagai layanan live streaming pada berbagai macam perangkat.

Contoh-contoh aplikasi live streaming yang sering digunakan antara lain adalah

Skype dan Google Hangouts yang telah tersedia baik pada PC maupun perangkat

mobile seperti smartphone dan tablet.

Gambar I-1 Ilustrasi Cara Kerja Streaming

2

Masih ada masalah pada aplikasi-aplikasi live streaming yang tersedia. Masalah

pertama adalah bahwa suatu aplikasi khusus harus dipasang pada setiap

perangkat. Aplikasi-aplikasi tersebut hanya dapat beroperasi pada perangkat-

perangkat yang memenuhi spesifikasi tertentu. Sebagai contoh, untuk memasang

Skype for Android, diperlukan smartphone yang mempunyai prosesor ARM v7

(Skype, 2013).

Kedua, tidak ada protokol tertentu antar aplikasi live streaming. Seperti dikutip

dari jurnal Mobile Video Chat – Issues and Challenges (Shraboni Jana et al.,

2013): “Currently, end users using different video chat applications cannot

communicate with each other. This is because video chat applications use

different video codecs and technologies for system negotiation, which have not

been standardized yet.” (Jana, S. et al., 2013) . Sebagai akibat dari tidak adanya

protokol yang tetap antar aplikasi live streaming, tidak mungkin terjadi

komunikasi antar aplikasi live streaming yang berbeda.

Ketiga, aplikasi-aplikasi yang tersedia belum menyediakan cara yang mudah

untuk melakukan integrasi antara aplikasi tersebut dengan aplikasi-aplikasi lain.

Akibatnya, aplikasi-aplikasi lain yang hendak melakukan live streaming akan

menemui kesulitan untuk mengimplementasikan live streaming dengan mudah.

Keempat, pada aplikasi-aplikasi yang telah ada, walaupun tidak diperlukan

aplikasi khusus untuk dipasang pada perangkat yang hendak dipakai melakukan

live streaming, tetap dibutuhkan sebuah plug-in untuk memakai aplikasi yang

bersangkutan. Plug-in dapat menyebabkan masalah baru, antara lain ketika plug –

in yang sudah diunduh harus diperbarui jika ada perubahan pada aplikasi, atau

masalah kompatibilitas antara plug-in dan perangkat yang bersangkutan.

Untuk menyelesaikan seluruh masalah yang telah disebutkan tadi, dapat dirancang

suatu modul aplikasi live streaming yang dibuat di atas teknologi web dan HTML5.

Keunggulan implementasi di atas web adalah bahwa di hampir seluruh piranti

telah tersedia sebuah browser yang dapat membuka web. Selain itu, penggunaan

langsung kamera dan microphone komputer dari browser yang dahulu sulit

dilakukan, sekarang telah dapat dilakukan dengan cukup mudah. Sebagai

3

hasilnya, penggunaan web dapat mengeliminasi beberapa masalah yang

ditimbulkan karena perbedaan perangkat.

Pada pembuatan modul aplikasi live streaming terdapat kebutuhan bahwa modul

live streaming harus bersifat reliable. Reliable dalam konteks ini berarti selama

koneksi internet tidak terputus dan tidak ada permintaan pemutusan koneksi dari

pengguna, modul aplikasi live streaming harus dapat menyajikan data secara

kontinu. Lebih jauh lagi, jika terjadi gangguan pada koneksi internet, modul live

streaming harus dapat menghubungkan kembali pengguna – pengguna yang

terlibat ketika koneksi internet kembali lancar. Selain itu, modul aplikasi live

streaming juga harus dapat digunakan pada berbagai piranti yang berbeda, seperti

smartphone dan komputer. Modul live streaming juga harus dapat di-reuse

dengan mudah pada berbagai aplikasi yang tersedia.

I.2. Rumusan Masalah

Untuk melakukan live streaming, satu-satunya cara yang tersedia saat ini adalah

dengan memasang aplikasi khusus yang menyediakan kapabilitas live streaming.

Pengembang juga belum mempunyai suatu cara yang mudah untuk memasukkan

kemampuan live streaming ke dalam aplikasi yang dibuat. Bagaimana cara

mengembangkan modul aplikasi live streaming berbasis web yang dapat

memudahkan pengembang memasukkan kemampuan live streaming ke dalam

aplikasinya?

I.3. Tujuan

Tujuan akhir dari Tugas Akhir ini adalah untuk mengkaji pembuatan modul

aplikasi live streaming berbasis web yang reliable dan reusable.

I.4. Batasan Masalah

Sejauh ini, belum ada batasan-batasan dalam pengerjaan Tugas Akhir ini.

4

I.5. Metodologi

Metodologi pengerjaan Tugas Akhir ini mencakup studi literatur, eksplorasi

berbagai aplikasi live streaming yang telah ada, perancangan, implementasi, dan

pengetesan modul aplikasi live streaming pada aplikasi berbasis web.

Studi literatur dilakukan dengan cara membaca berbagai jurnal yang tersedia

mengenai live streaming, software library, HTML5, WebSocket dan berbagai topik

pendukung lainnya.

Eksplorasi berbagai aplikasi live streaming yang telah ada diperlukan untuk

mengetahui kemampuan dan arsitektur dari masing-masing aplikasi. Aplikasi-

aplikasi yang telah ada tersebut akan menjadi salah satu acuan dari perancangan

modul aplikasi live streaming yang akan dibuat.

Perancangan moudl aplikasi live streaming dimulai setelah studi literatur dan

eksplorasi aplikasi-aplikasi terkait dilakukan. Pertama-tama spesifikasi dari

aplikasi yang akan dibangun akan disusun terlebih dahulu. Kemudian dilakukan

perancangan arsitektur aplikasi live streaming.

Implementasi aplikasi live streaming akan dilakukan dengan mengacu pada

rancangan yang telah dihasilkan sebelumnya. Modul aplikasi live streaming akan

digunakan pula secara langsung pada suatu aplikasi berbasis web di server lokal.

Terakhir, akan dilakukan pengujian aplikasi live streaming yang telah dibuat.

Pengujian dilakukan untuk mengetahui apakah seluruh kebutuhan yang

dibutuhkan dari aplikasi tersebut telah dipenuhi. Pengujian juga dilakukan untuk

mengetahui reusability dan reliability modul aplikasi pada penggunaan nyata.

I.6. Sistematika Pembahasan

Pada Bab I, akan dibahas mengenai latar belakang, dasar permasalahan, tujuan

dan batasan masalah Tugas Akhir ini. Metodologi pengerjaan Tugas Akhir juga

dipaparkan pada bab I.

Pada Bab II, akan dibahas mengenai dasar teori yang diperlukan untuk dapat

memahami isi dokumen Tugas Akhir ini secara keseluruhan. Pertama-tama akan

dibahas tentang definisi dan cara kerja dari live streaming. Lalu akan dibahas pula

kapabilitas dan arsitektur dari aplikasi-aplikasi streaming yang telah tersedia.

5

Kemudian akan dibahas tentang apa itu software library. Setelah itu, akan

dilakukan pembahasan yang berhubungan dengan teknis pengerjaan Tugas Akhir

seperti WebSocket dan WebRTC (Web Real Time Comunications).

Pada Bab III, akan dibahas mengenai analisis yang meliputi berbagai macam

kesulitan yang ada dalam pembuatan aplikasi live streaming. Pertama, akan

dilakukan pembahasan mengenai kapabilitas dan arsitektur aplikasi yang akan

dibuat, mengacu pada aplikasi-aplikasi serupa yang telah ada. Selanjutnya akan

dilakukan pembahasan mengenai analisis metode-metode pengiriman data

streaming. Terakhir akan dilakukan pembahasan mengenai metode sinkronisasi

berbagai channel yang ada pada data live streaming.

Pada Bab IV, akan dibahas mengenai perancangan, implementasi serta pengujian

dari aplikasi live streaming yang telah dibuat. Akan dikaji pula arsitektur aplikasi

live streaming yang dibuat serta rancangan kelas-kelas yang perlu dibuat. Pada

bab ini pula seluruh rancangan tersebut akan diimplementasikan menjadi sebuah

modul aplikasi live streaming. Setelah itu, akan dilakukan pengujian terhadap

reliabilitas aplikasi yang telah dibuat.

Pada Bab V, akan dibahas mengenai tentang studi kasus yang dilakukan untuk

membuat aplikasi web yang menggunakan modul live streaming. Studi kasus

dilakukan untuk mengetahui lebih lanjut apakah modul live streaming yang telah

dibuat dapat berfungsi dengan baik pada berbagai macam kondisi.

Pada Bab VI, akan dibahas kesimpulan yang didapat dari implementasi dan

pengujian aplikasi. Pada bab ini disimpulkan apakah aplikasi yang telah dibuat

dapat membantu berjalannya live streaming pada aplikasi berbasis web. Pada bab

ini akan dituliskan pula saran untuk pengembangan live streaming pada aplikasi

berbasis web di masa depan.

6

BAB II.

STUDI LITERATUR DAN EKSPLORASI

Bab ini berisi hasil studi literatur maupun eksplorasi yang akan digunakan sebagai

referensi untuk mengembangkan aplikasi untuk melakukan live streaming pada

aplikasi berbasis web.

Pertama-tama, pada bab ini akan dibahas mengenai apa itu streaming. Kemudian

akan dijelaskan pula eksplorasi dari aplikasi-aplikasi live streaming yang telah

tersedia. Lalu, pada bab ini akan dijelaskan pula mengenai software library.

Terakhir, pada bab ini akan dijelaskan beberapa topik yang terkait pada teknis

implementasi aplikasi live streaming seperti WebSocket dan WebRTC.

II.1. Streaming

Pada subbab ini, akan dijelaskan tentang definisi streaming, dan bagaimana

streaming dilakukan.

II.1.1. Definisi Streaming

Streaming adalah suatu proses untuk mengirimkan dan menampilkan suatu konten

(Simpson, Wes. 2008). Konten yang dikirimkan dapat berupa video, gambar,

audio, atau bahkan hanya teks saja.

II.1.2. Cara Kerja Streaming

Secara umum, streaming dapat dilakukan dengan dua cara, yaitu : live streaming

dan progressive download and play.

Pada Live Streaming, sinyal media datang secara real-time dan ditampilkan juga

secara real-time. Live streaming yang dilakukan pada jaringan IP dilakukan

dengan cara mengambil data sinyal media, kemudian melakukan splitting pada

data tersebut sehingga data terbagi menjadi bagian-bagian yang lebih kecil. Data

tersebut kemudian dikirimkan sesuai dengan framerate dari media yang

dikirimkan.

7

Pada Progressive download and play, media yang akan ditampilkan oleh server

harus terlebih dahulu tersedia. Media tersebut kemudian dibagi menjadi chunk-

chunk kecil dan dikirimkan kepada client. Data media tersebut kemudian

dikirimkan kepada client sesuai dengan urutannya.

Kedua cara tersebut membutuhkan sebuah streaming server yang bertanggung

jawab untuk mendistribusikan seluruh media yang di-stream kepada client. Salah

satu pekerjaan utama server adalah membuat paket yang berbeda untuk masing-

masing client. Setiap paket data yang terbentuk harus mengandung informasi IP

asal dan IP tujuan yang jelas agar sampai kepada client yang dituju. Selain itu,

stream yang dikirim dari server harus datang dalam aliran waktu yang stabil.

Kecepatan stream dari server tidak boleh berubah-rubah secara drastis karena

berpotensi merusak data media yang dikirimkan. Selain itu, streaming server yang

baik juga dapat mengatur besar data yang dikirimkan sesuai bandwith dari

penyedia dan pengguna layanan.

Contoh aplikasi yang menggunakan streaming adalah Skype dan Google

Hangouts.

II.2. Eksplorasi Terhadap Aplikasi - Aplikasi Terkait

Pada subbab ini dijabarkan beberapa aplikasi live streaming yang telah ada

beserta cara kerja dan fitur-fiturnya.

II.2.1. Skype

Skype pertama kali diluncurkan pada Agustus 2003. Beberapa kemampuan yang

ada pada aplikasi ini antara lain Video Call, menggunakan VoIP ataupun PSTN,

Video Conference, Desktop Sharing, Live chat, dan File transfer.

8

Gambar II-1 Aplikasi Skype

Skype menggunakan suatu sistem yang menggabungkan konsep peer-to-peer dan

client-server. Sistem client-server digunakan untuk menghubungkan pengguna

saat pengguna akan memulai suatu panggilan, sedangkan sistem peer-to-peer

digunakan untuk komunikasi antar pengguna secara real-time. Untuk pengiriman

data, Skype menggunakan sebuah proprietary protocol yang disebut Skype

protocol. Codec audio yang digunakan adalah G.729, SVOPC dan SILK.

Sedangkan codec video yang digunakan adalah VP8 dan H.264.

II.2.2. Google Hangouts

Google Hangouts pertama kali diluncurkan pada Mei 2013. Beberapa fitur yang

ada pada aplikasi ini antara lain :

1. Video Call

2. Video Conference

3. Desktop Sharing

4. Live Chat

5. Short Messaging Service (hanya pada Android 4.4)

9

Gambar II-2 Aplikasi Google Hangouts

Sebelum terbentuknya Google Hangouts, Google telah terlebih dahulu membuat

suatu produk yang disebut Google Talk. Google Talk menggunakan protokol

XMPP (Extensible Mesaging and Presence Protocol) untuk menangani data

komunikasinya. Namun, Google Hangouts menggunakan protokol tersendiri yang

bersifat proprietary.

Arsitektur aplikasi Google Hangouts bersifat client-server. Data yang dikirimkan

oleh masing-masing client dikirimkan kepada server terlebih dahulu. Server

kemudian melakukan sinkronisasi data dan mengirimkan kembali data media

kepada masing-masing client. Pendekatan ini dilakukan dengan pertimbangan

server yang dimiliki Google mampu menangani beban load yang cukup besar.

Untuk dapat menggunakan Google Hangouts, pengguna harus terlebih dahulu

mengunduh sebuah plug-in yang akan berjalan pada komputer masing-masing

pengguna. Plug-in tersebut digunakan untuk mendapatkan akses menuju

perangkat keras yang dimiliki komputer pengguna layanan.

II.3. Software Library

Pada subbab ini akan dijabarkan berbagai literatur mengenai definisi software

library, dan jenis-jenis software library.

10

II.3.1. Definisi Software Library

Menurut Meyer (1997), Software Library adalah kumpulan dari implementasi

sejumlah class, functions, events dan behaviors. Tujuan utama pembuatan suatu

software library adalah untuk menciptakan kode yang reusable. Reusable berarti

library yang telah dibuat dapat digunakan ulang pada berbagai macam aplikasi

lainnya (Meyer, 1997).

Berdasarkan cara suatu library diakses oleh aplikasi yang menggunakannya, ada 2

jenis library yaitu static library dan dynamic library. Static library adalah library

yang diakses pada saat kompilasi program. Sedangkan dynamic library adalah

library yang diakses pada saat program berjalan.

Keunggulan dari static library adalah aplikasi yang menggunakan static library

tidak perlu khawatir mengenai versi dari library yang dipakai. Karena library

diakses ketika kompilasi program, seluruh kode library yang diperlukan telah

dimasukkan ke dalam program. Namun, hal ini juga berakibat pada besarnya hasil

kompilasi program.

Di sisi lain, dynamic library di sisi lain mempunyai keunggulan karena sifatnya

yang diakses pada saat program berjalan. Pada umumnya, dynamic library dapat

diakses oleh banyak aplikasi sekaligus. Selain itu, dynamic library juga lebih

mudah untuk di-update karena berada di luar aplikasi / program yang berjalan.

Dynamic library juga memungkinkan suatu aplikasi untuk memanggil sebuah

routine hanya ketika routine tersebut dibutuhkan.

II.4. HTML5

HTML5 adalah versi terbaru dari standar HTML (Hypertext Markup Language).

Menurut van Kesteren (2011), tujuan utama dari pengembangan HTML5 adalah

untuk meng-upgrade teknologi HTML agar mendukung teknologi multimedia

terbaru. Fitur – fitur yang menjadi tambahan pada HTML5 antara lain :

1. Canvas Element, berfungsi untuk mengambarkan grafik secara langsung

pada aplikasi web.

11

2. Media Playback, berfungsi untuk menampilkan data media secara

langsung di dalam aplikasi web, tanpa melalui plug-in apapun. Dalam

implementasinya, ada dua tag HTML baru untuk melakukan media

playback. Tag baru tersebut adalah <video> untuk menampilkan video,

dan <audio> untuk menampilkan audio.

3. WebSocket, berfungsi untuk melakukan komunikasi dua arah antara client

dan server pada aplikasi web. Penjelasan lebih lanjut dijabarkan pada Bab

II.4.1.

4. Local Storage, berfungsi untuk menyimpan data secara lokal di dalam

browser milik client.

5. Drag and Drop, berfungsi untuk melakukan interaksi drag and drop pada

aplikasi web.

6. Geolocation, berfungsi untuk mengetahui lokasi dari client.

7. WebRTC (Web Real Time Communication), berfungsi untuk melakukan

komunikasi secara real time antar pengguna. Penjelasan lebih lanjut

dijabarkan pada Bab II.4.2.

Fitur-fitur HTML5 yang akan digunakan pada Tugas Akhir ini adalah WebSocket

dan Web Real Time Communication. Penjelasan lebih lanjut mengenai kedua fitur

tersebut dapat dibaca pada Bab II.4.1 dan Bab II.4.2.

II.4.1. WebSocket

Pada subbab ini dijelaskan tentang protokol WebSocket yang akan digunakan

pada Tugas Akhir ini.

II.4.1.1. Definisi WebSocket

Menurut Vanessa Wang (2013), WebSocket adalah sebuah API baru yang

diperkenalkan oleh HTML5. Sifat-sifat dari koneksi WebSocket adalah sebagai

berikut :

12

1. Full-duplex : Trafik data pada suatu waktu berlangsung secara bersamaan

dari kedua arah (client dan server).

2. Bidirectional : Kedua belah pihak dapat mengirimkan data.

3. Single-socket connection : Hanya diperlukan satu socket untuk melakukan

koneksi dan komunikasi.

WebSocket dirancang untuk mengurangi latensi yang ditimbulkan oleh overhead

dari HTTP Request. Header dari sebuah HTTP Request berukuran lebih besar dari

800 byte, sedangkan header dari sebuah WebSocket berukuran tidak lebih dari 8

byte. Selain itu, berbeda dengan koneksi HTTP Request yang bersifat half-duplex,

koneksi dari WebSocket bersifat full-duplex yang memungkinkan terjadinya

interaksi yang lebih baik antara client dan server.

Gambar II-3 Cara Kerja WebSocket (Wang, 2013).

II.4.1.2. Siklus Hidup WebSocket

Untuk membuat koneksi dengan host tertentu, sebuah aplikasi web perlu

mengkonstruksi sebuah objek WebSocket dan mengkonfigurasi objek tersebut

dengan sebuah URL yang menyatakan domain host yang akan dihubungi. Koneksi

ke sebuah WebSocket server kemudian dilakukan dengan cara melakukan

upgrade protokol dari HTTP Protocol menjadi WebSocket Protocol. Upgrade ini

dilakukan dengan cara membuat sebuah HTTP Request untuk melakukan

handshake antara aplikasi web dengan host-nya. Setelah terkoneksi, aplikasi web

dengan host-nya dapat saling berkirim pesan dengan menggunakan fungsi-fungsi

yang telah didefinisikan oleh interface WebSocket.

13

Ketika koneksi telah terbentuk, aplikasi web yang menggunakan WebSocket tidak

perlu mengirimkan request secara berkala kepada host. Aplikasi web dapat

memasang sebuah event listener pada objek WebSocket sehingga ketika didapat

pesan apapun dari server, aplikasi web akan mendapatkan notifikasi dari event

listener.

Koneksi antara aplikasi web dengan host-nya dapat kemudian dimatikan dengan

menggunakan fungsi close() pada objek WebSocket yang digunakan. Secara lebih

detil, siklus hidup dari sebuah WebSocket dapat dilihat pada Gambar II-4.

Gambar II-4 Sequence Diagram Siklus Hidup WebSocket

14

II.4.2. Web Real Time Communication

Pada subbab ini dijelaskan tentang protokol Web Real Time Communications

(WebRTC) yang akan digunakan pada Tugas Akhir ini.

II.4.2.1. Definisi Web Real Time Communication

Menurut Johnston(2013), WebRTC adalah sebuah API yang digunakan untuk

melakukan real-time communication di dalam browser. WebRTC membuat real-

time communication dapat dilakukan hanya dengan menggunakan tag HTML5

standar dan Javascript, tanpa harus memasang sebuah perangkat lunak atau plug-

in. Fungsi-fungsi dari WebRTC berinteraksi dengan aplikasi berbasis web dengan

menggunakan API-API standar seperti HTML5 dan Javascript. Sedangkan untuk

berkomunikasi dengan sistem operasi, WebRTC bergantung pada aplikasi browser

yang digunakan. (Johnston, 2013).

II.4.2.2. Standar WebRTC

Hingga saat ini, standar resmi WebRTC masih dikembangkan bersama oleh dua

organisasi besar yaitu World Wide Web Consortium (W3C), dan Internet

Engineering Task Force (IETF). Proses ini diperkirakan akan selesai dan siap

dipublikasikan pada tahun 2014. Sejauh ini, fitur yang telah diimplementasikan

dengan sukses pada browser adalah fitur untuk mendapatkan data media dari user.

(Johnston, 2013).

II.4.2.3. Penggunaan WebRTC pada Pengolahan Data Media

Untuk memperoleh dan mengolah data dari kamera dan mikrofon secara langsung

di sebuah browser, tersedia fungsi interface MediaStream dan

NavigatorUserMedia yang telah distandardisasi oleh protokol WebRTC.

Spesifikasi dari interface MediaStream dan NavigatorUserMedia dituliskan pada

lampiran A.

15

II.4.2.4. Koneksi dengan WebRTC

Untuk membuat koneksi WebRTC dengan client lain, diperlukan 4 langkah yaitu

(Johnston, 2013):

1. Mengambil data media pengguna,

2. Melakukan koneksi dengan pengguna lain,

3. Meng-attach data media ke dalam koneksi yang terbentuk,

4. Melakukan pertukaran data session description antara masing-masing

pengguna.

Gambar II-5 Pembentukan koneksi antar pengguna (Johnston, 2013).

Salah satu masalah yang muncul ketika ingin memulai sebuah koneksi dengan

pengguna lain adalah sedikitnya penguna yang mempunyai sebuah static public IP

Address. IP Address dari pengguna biasanya adalah sebuah private IP yang di-

assign dengan menggunakan DHCP server. Padahal untuk melakukan sebuah

koneksi, diperlukan public IP address. Oleh karena itu, dibutuhkan juga sebuah

STUN (Session Traversal Utilities for NAT) server untuk mengetahui public IP

seorang pengguna. Data STUN server dapat dimasukkan sebagai salah satu

konfigurasi ketika membentuk koneksi dengan pengguna lain.

16

BAB III.

ANALISIS

Sebelum membangun sebuah aplikasi live streaming, perlu dilakukan berbagai

analisis terlebih dahulu. Pertama-tama, analisis akan dilakukan pada aplikasi live

streaming Skype dan Google Hangouts. Analisis ini dilakukan untuk mengetahui

fitur – fitur dari masing – masing aplikasi. Setelah itu, analisis berikutnya yang

dilakukan adalah mengenai arsitektur jaringan yang akan digunakan. Dua

alternatif jaringan yang dapat digunakan adalah Peer to Peer dan Client – Server.

Lalu, analisis akan dilakukan pada kemungkinan konfigurasi node yang berbeda –

beda. Barulah kemudian analisis akan dilakukan pada arsitektur modul aplikasi

live streaming dan metode pengiriman data.

III.1. Analisis pada Aplikasi Streaming yang Telah Ada

Analisis dilakukan pada Skype dan Google Hangouts. Analisis dilakukan pada

kapabilitas masing-masing aplikasi.

III.1.1. Analisis Kapabilitas

Berdasarkan aplikasi-aplikasi yang telah dipelajari pada Bab II.2, maka

kapabilitas masing-masing aplikasi dapat dilihat pada Tabel III-1.

Tabel III-1 Perbandingan kapabilitas Skype dan Google Hangouts

Fitur Skype Google Hangouts

Video Call Ya Ya

Video Conference Ya Ya

PSTN Ya Tidak

Short Messaging Service Tidak Ya (Android 4.4)

Desktop Sharing Ya Ya

Live Chat Ya Ya

File Transfer Ya Tidak

17

Ada 4 fitur yang diimplementasi baik oleh Skype maupun Google Hangouts yaitu

Video Call, Video Conference, Desktop Sharing dan Live Chat. Seluruh fitur

tersebut dapat diimplementasi pada aplikasi live streaming. Oleh karena itu,

aplikasi live streaming akan mengimplementasi fitur Video Call, Video

Conference, Desktop Sharing dan Live Chat.

III.2. Analisis Jaringan Peer to Peer dan Client - Server

Dalam pengembangan aplikasi live streaming, arsitektur jaringan yang umum

digunakan adalah peer to peer dan client - server. Pada arsitektur jaringan peer to

peer, para pengguna saling terhubung dan mengirimkan data media secara

langsung pada pengguna lainnya. Sedangkan pada arsitektur jaringan client –

server, para pengguna terhubung ke sebuah server, menerima data media dari

server dan mengirimkan data media hanya kepada server saja. Tabel III-2

memperlihatkan perbandingan antara arsitektur jaringan peer to peer dan client –

server.

Tabel III-2 Perbandingan arsitektur peer to peer dan client - server

Aspek Peer to peer Client - server

Beban jaringan Ringan Berat

Kemudahan Sinkronisasi Sulit Mudah

Implementasi Mudah Sulit

Kelebihan penggunaan arsitektur peer to peer antara lain adalah berkurangnya

beban pada server. Selain itu, dengan kualitas jaringan yang semakin baik dewasa

ini, koneksi antar pengguna dapat berjalan dengan baik. Namun, penggunaan

arsitektur peer to peer antar pengguna menimbulkan masalah baru. Penggunaan

arsitektur peer to peer berarti kualitas perangkat keras dan jaringan pengguna

mengakibatkan pengaruh yang sangat besar.

18

Gambar III-1 Ilustrasi Arsitektur peer to peer

Arsitektur client-server mengharuskan aplikasi web dibagi bebannya pada server

yang tersebar merata di berbagai lokasi agar beban yang ditimbulkan oleh aplikasi

streaming dapat ditangani oleh berbagai server yang tersedia. Masalah baru akan

muncul ketika beberapa server mengalami gangguan, yang menyebabkan

terjadinya overload pada server-server yang lainnya. Selain itu, dengan API

WebRTC yang tersedia, penggunaan model client-server mengakibatkan beban

yang besar pada client untuk memproses data media dan mengolahnya sebelum

siap dikirimkan kepada server.

Gambar III-2 Ilustrasi Arsitektur client-server

Dari segi pengembangan aplikasi, pengembangan aplikasi dengan menggunakan

arsitektur peer to peer mempunyai tingkat kesulitan yang lebih mudah. Pada

arsitektur peer to peer, koneksi antar pengguna dapat dilakukan hanya dengan

menggunakan signaling server dan API dari WebRTC. Proses pengiriman data

19

dapat dilakukan dengan menggunakan API RTCPeerConnection dan

MediaStream dari WebRTC. Namun, diperlukan pembuatan kelas Initiator

tersendiri karena ada beberapa parameter yang berbeda di browser yang berbeda.

(Johnston, 2013).

Penggunaan arsitektur jaringan client – server memungkinkan penulisan aplikasi

yang tidak bergantung pada browser yang digunakan. Namun, pemrosesan

pengambilan dan pengolahan data secara manual sangat sulit dilakukan

berdasarkan API yang tersedia. Hal ini disebabkan karena browser mengenkripsi

data media yang telah tersedia, sehingga untuk mengolahnya secara lebih lanjut

diperlukan proses dekripsi terlebih dahulu, yang pada akhirnya membuat waktu

pengolahan menjadi sangat panjang. Oleh karena itu, pembuatan aplikasi live

streaming akan menggunakan arsitektur jaringan peer to peer dan sebuah

signaling server.

III.3. Arsitektur Aplikasi Live Streaming

Arsitektur aplikasi live streaming pada aplikasi Google Hangouts digambarkan

seperti pada gambar III-3.

Gambar III-3 Arsitektur aplikasi live streaming Google Hangouts

20

Aplikasi Google Hangouts menggunakan sebuah server untuk melakukan

streaming kepada pengguna-pengguna yang terhubung. Setiap pengguna

terhubung kepada server Google, kemudian mengirimkan dan menerima data

stream dari Google. Arsitektur aplikasi live streaming pada aplikasi Skype dapat

dilihat pada Gambar III.4.

Gambar III-4 Arsitektur Modul Aplikasi Live Streaming Skype

Dari Gambar III-3 dan Gambar III-4, dapat disimpulkan bahwa ada beberapa

perbedaan antara arsitektur aplikasi live streaming yang umum dipakai dengan

arsitektur aplikasi live streaming pada Tugas Akhir ini. Perbedaan-perbedaan

antara kedua arsitektur tersebut adalah sebagai berikut.

1. Pada Gambar III-3, terdapat sebuah streaming server. Sedangkan pada

Gambar III-4, terdapat sebuah signaling server.

2. Pada Gambar III-3, semua client tidak saling terhubung satu dengan yang

lain. Sedangkan pada Gambar III-4, semua client saling terhubung secara

peer to peer.

3. Pada Gambar III-3, semua proses pengolahan dan encoding data media

dilakukan pada server. Sedangkan pada Gambar III-4, semua proses

21

pengolahan dan encoding data media dilakukan pada masing-masing

client.

Seperti telah dibahas pada Bab III.2, modul aplikasi live streaming akan dibuat

dengan menggunakan koneksi peer to peer dan sebuah signaling server. Signaling

server digunakan untuk menginisialisasi koneksi antar node, sedangkan

komunikasi dan pengiriman data antar node akan dilakukan secara peer to peer.

Maka, arsitektur yang dipakai dalam Tugas Akhir ini hampir sama dengan Skype.

Namun, terdapat perbedaan bahwa modul aplikasi yang dibuat berjalan

sepenuhnya sebagai aplikasi web. Secara lebih detil, rancangan arsitektur modul

aplikasi live streaming pada Tugas Akhir ini digambarkan pada Gambar III – 5.

Gambar III-5 Arsitektur Aplikasi dengan Modul Live Streaming

Modul yang berada pada area arsir merah adalah modul-modul yang menangani

live streaming pada aplikasi yang dibuat.

22

Server side module berfungsi sebagai sarana client untuk memulai koneksi peer to

peer dengan client lainnya. Selain menghubungkan client, server juga berfungsi

untuk memvalidasi request dari client.

Client side module berfungsi untuk mengambil dan mengirimkan data media

tersebut kepada client – client lain yang saling terhubung. Modul – modul pada

sisi client berjalan di atas browser yang kompatibel dengan HTML5 dan WebRTC.

III.4. Analisis Kebutuhan Modul Aplikasi

Aplikasi web pada Tugas Akhir ini terdiri dari 2 modul besar, yang masing-

masing adalah server side module dan client side module. Modul pertama yang

dibuat adalah implementasi server WebSocket. Sebuah server WebSocket harus

mempunyai skalabilitas yang tinggi agar dapat menangani banyak client secara

bersamaan dalam suatu waktu. Selain itu, untuk mendukung pengembangan

aplikasi server ini, diperlukan suatu library / framework / bahasa pemrograman

yang sudah cukup dikenal, dan terdapat basis massa pengguna yang cukup tinggi.

Oleh karena itu, Tugas Akhir ini akan menggunakan NodeJS untuk

mengimplementasi pembuatan server WebSocket. NodeJS dipilih karena selain

mempunyai basis massa penguna yang tinggi, NodeJS memang secara khusus

didesain untuk menangani koneksi konkuren dalam jumlah yang besar.

Modul kedua yang dibuat adalah client side module, yang berbentuk script dan

diaktifkan oleh browser. Modul ini akan mengambil data dengan menggunakan

interface NavigatorUserMedia dan MediaStream yang telah tersedia, kemudian

mengirimkannya dengan menggunakan protocol RTCPeerConnection.

III.5. Software Requirements

Ada dua modul aplikasi pada aplikasi live streaming, yaitu pada server side

module dan client side module. Kapabilitas dari server side module adalah aplikasi

live streaming dapat menginisialisasi koneksi antar node melalui signaling server

atas permintaan pengguna.

23

Software Requirements dari client side module adalah sebagai berikut.

1. Aplikasi live streaming dapat mengirimkan dan menerima data media dari

satu node ke node lainnya. Satu node adalah satu aplikasi yang membuka

browser untuk menjalankan aplikasi live streaming, dan sudah terdaftar

pada server.

2. Satu node yang telah terdaftar dapat berhubungan dengan node lain secara

one to one, one to many, dan many to many.

3. Aplikasi live streaming dapat melakukan terminasi koneksi antar node atas

permintaan pengguna.

III.6. Operational Requirements

Piranti yang digunakan harus mempunyai kapabilitas untuk mengakses jaringan

internet. Hal ini karena kedua modul yang dibuat hanya dapat berkomunikasi

melewati jaringan internet. Selain itu, piranti yang digunakan bukan hanya

desktop maupun laptop, melainkan juga piranti mobile seperti smartphone dan

tablet. Penggunaan berbagai macam piranti tersebut digunakan untuk menguji

apakah modul-modul tersebut sudah dapat digunakan dengan baik pada berbagai

macam perangkat. Perbedaan User Interface antar piranti diimplementasi pada

berkas CSS aplikasi.

Perangkat lunak yang digunakan adalah browser yang telah mendukung protokol

WebSocket serta API WebRTC yaitu MediaStream dan NavigatorUserMedia.

Browser yang telah mendukung protokol WebSocket dapat dilihat pada

Tabel III-3.

24

Tabel III-3 Tabel Kompabilitas Browser dengan WebSocket

Nama Browser Mengimplementasi WebSocket Versi Minimum

Internet Explorer Ya 10.0

Mozilla Firefox Ya 21.0

Google Chrome Ya 21.0

Safari Ya 6.0

Opera Ya 12.1

Browser yang telah mendukung API WebRTC dapat dilihat pada Tabel III-4.

Tabel III-4 Tabel Kompabilitas Browser dengan API WebRTC

Nama Browser Mengimplementasi WebRTC Versi Minimum

Internet Explorer Tidak -

Mozilla Firefox Ya 30.0

Google Chrome Ya 27.0

Safari Tidak -

Opera Ya 23.0

Oleh karena itu, dapat disimpulkan bahwa browser yang dapat digunakan untuk

menggunakan modul aplikasi live streaming adalah Mozilla Firefox, Google

Chrome dan Opera.

Pada sisi client, aplikasi dikembangkan dengan menggunakan bahasa HTML5 dan

Javascript. Sedangkan pengembangan modul untuk server akan menggunakan

bahasa Javascript yang telah dikustomisasi khusus untuk pembuatan aplikasi

berbasis web yaitu NodeJS.

III.7. Analisis Metode Pengiriman Data Media

Pada implementasi live streaming, data media harus dikirimkan secara real time

antar pengguna selama pengguna masih saling terhubung. Agar data media dapat

dikirim dengan cepat, data yang dikirimkan sebisa mungkin berukuran kecil.

Selain itu, metode pengiriman data yang digunakan harus mempunyai

25

kompatibilitas yang baik dengan browser, dan tidak membebani server ketika

jumlah pengguna bertambah.

Ada tiga metode pengiriman data media yang dapat dipakai untuk melakukan live

streaming dari browser.

1. Menggunakan HTTP Polling

HTTP Polling dilakukan dengan cara mengumpulkan data media,

kemudian dikirimkan melalui AJAX request. Pada setiap request, header

HTTP Request berukuran sebesar 800 byte.

2. Menggunakan WebSocket

Koneksi WebSocket bersifat full-duplex, sedangkan header-nya berukuran

maksimal 8 byte. WebSocket merupakan salah satu bagian dari protokol

standar HTML5 yang baru. Untuk mengimplementasikan WebSocket,

diperlukan juga server WebSocket yang beroperasi dengan baik.

Pengiriman data dilakukan dengan cara mengumpulkan data media,

kemudian dikirimkan langsung ke server WebSocket.

3. Menggunakan RTCPeerConnection

RTCPeerConnection menggunakan API yang disediakan pada WebRTC.

Protokol ini memungkinkan terjadinya koneksi peer to peer antar browser.

Pengiriman data dilakukan dengan cara mengumpulkan data media,

kemudian dikirimkan ke masing-masing browser yang saling terkoneksi

satu sama lain.

Kelebihan dan kekurangan masing-masing metode dijabarkan pada Tabel III-5 :

Tabel III-5 Analisis Metode Pengiriman Data Media

Faktor HTTPPolling WebSocket RTCPeerConnection

Besar header data Minimal 800 byte 8 byte 8 byte

Kompatibilitas

dengan browser

Mudah Sedikit Sulit Sulit

Skalabilitas Buruk Baik Sangat Baik

26

Maka berdasarkan pertimbangan pada Tabel III-5, pengiriman data akan

dilakukan dengan menggunakan metode RTCPeerConnection.

Selain metode pengiriman data, cara penerimaan dan pengiriman media juga perlu

dikaji untuk memperhitungkan kecepatan streaming, waktu yang dibutuhkan

untuk melakukan sinkronisasi serta reliabilitas dari server streaming. Ada tiga

cara penerimaan dan pengiriman media yang dapat dilakukan.

1. Aplikasi meminta data video dari client, kemudian mengirimkannya

kepada client – client lain yang saling terhubung,

2. Aplikasi meminta data gambar dan audio dari client secara terpisah,

kemudian digabungkan dan dijadikan data video sebelum kembali

dikirimkan ke client,

3. Aplikasi meminta data gambar dan audio dari client secara terpisah,

kemudian digabungkan secara terpisah dan dikirimkan dalam dua saluran

yang berbeda pada client.

Meminta data video dari pengguna tidak sulit dilakukan, karena sudah tersedia

secara default pada protokol WebRTC yang telah diimplementasi. Data video dari

pengguna kemudian dapat dikirimkan kepada setiap pengguna lain yang saling

berhubungan.

Pengiriman data dapat pula dilakukan dengan cara meminta data gambar dan

audio dari client secara terpisah, kemudian digabungkan dan dijadikan data video

sebelum kembali dikirimkan ke client. Sebagai akibat dari terpisahnya data

gambar dan data audio yang dikirimkan dari client, data gambar dan data audio

menjadi saling independen. Ketika salah satu saluran (gambar atau audio)

mengalami gangguan, saluran yang lain masih tetap dapat berjalan dengan baik.

Namun penggabungan menjadi satu data video dari beberapa data gambar dan

audio juga masih memerlukan waktu komputasi yang cukup lama sehingga sulit

dilakukan secara real time.

Metode terakhir adalah meminta data gambar dan audio dari client secara terpisah,

kemudian digabungkan secara terpisah dan dikirimkan melalui dua saluran yang

27

berbeda pada client. Keunggulan dari cara ini adalah data gambar dan audio dapat

dikirimkan secara terpisah dan tidak saling menunggu. Selain itu, penggabungan

data gambar dan audio secara terpisah membutuhkan waktu komputasi yang

relatif lebih sedikit ketimbang mengolahnya menjadi video terlebih dahulu.

Namun, penggabungan dan pengiriman data secara terpisah memungkinkan suatu

paket data gambar dan audio yang terjadi pada waktu yang sama, sampai ke

tujuan dalam waktu yang jauh berbeda.

Rangkuman dari analisis cara pengiriman data media dapat dilihat pada

Tabel III-6.

Tabel III-6 Analisis Metode Sinkronisasi Media

Cara Waktu

komputasi

Kesulitan

sinkronisasi

Reliabilitas

Meminta data video dari

client

cepat mudah Baik

Meminta data gambar dan

audio, kemudian

dijadikan video

lama sedang Baik

Meminta data gambar dan

audio, kemudian

dikirimkan terpisah

sedang mudah Baik

Berdasarkan hasil analisis pada Tabel III-6, maka metode yang dipilih adalah

dengan meminta data video dari client, kemudian mengirimkannya kepada

masing-masing client yang terhubung.

28

BAB IV.

PENGEMBANGAN MODUL APLIKASI LIVE STREAMING

Pengembangan aplikasi live streaming terdiri atas beberapa tahap, yaitu

perancangan dan implementasi modul aplikasi dan pengujian modul pada aplikasi

berbasis web.

IV.1. Platform Implementasi dan

Implementasi aplikasi live streaming akan dilakukan menggunakan bahasa

pemrograman Javascript pada client side dan NodeJS pada server side.

Lingkungan perangkat keras yang digunakan untuk pengembangan adalah sebagai

berikut.

1. Prosesor Intel Core i5-2500 @ 3.3 GHz (4 CPU)

2. RAM 8096 MB

3. Harddisk 1 TB + SSD 128 GB

Lingkungan perangkat lunak untuk pengembangan sebagai berikut :

1. Sistem Operasi Ubuntu 13.10 64-bit

2. Sublime Text 2 (free edition)

IV.2. Perancangan dan Implementasi Modul Aplikasi Live Streaming

Implementasi modul aplikasi live streaming dilakukan dengan menggunakan fitur

RTCPeerConnection yang telah diimplementasikan sebagai fitur WebRTC.

WebSocket digunakan untuk membuat koneksi antar client yang akan saling

berhubungan. Setelah koneksi terbentuk, RTCPeerConnection akan dapat

mengirimkan data dari kamera dan mikrofon kepada client lain yang terhubung

dengannya.

Pada koneksi one to one, handshake antar client hanya perlu dilakukan satu kali.

Namun pada koneksi one to many, handshake dan pertukaran session description

harus dilakukan sesuai dengan jumlah koneksi. Sebagai contoh, bila ada hubungan

29

antara 1 dengan 3 node lainnya, maka akan dilakukan 3 kali handshake dan 3 kali

pertukaran session description.

Pada koneksi many to many, handshake dan pertukaran session description harus

dilakukan sesuai dengan total jumlah koneksi yang terjadi. Sebagai contoh, bila

empat node saling berhubungan satu sama lain, maka setiap node akan melakukan

tiga kali handshake dan tiga kali pertukaran session description.

IV.2.1. Perancangan dan Implementasi Kelas pada Modul Aplikasi Live

Streaming

Rancangan arsitektur dari aplikasi yang menggunakan modul live streaming

digambarkan pada Gambar IV-1.

Gambar IV-1 Rancangan Arsitektur Aplikasi Live Streaming

Dari rancangan pada Gambar IV-1, aplikasi pada Tugas Akhir ini terdiri atas dua

modul besar yaitu server side module dan client side module. Ada satu buah kelas

30

pada sisi server yaitu kelas Server. Sedangkan pada client side module, ada

empat buah kelas yaitu Initiator, Media, Peer dan Main.

Kelas pada server side module adalah sebagai berikut.

1. Kelas Server adalah kelas yang bertanggung jawab untuk saling berkirim

pesan dengan client. Server juga bertanggung jawab untuk memvalidasi

setiap pesan yang masuk dari client sebelum dikirimkan kepada client lain.

Sedangkan kelas-kelas pada client side module adalah sebagai berikut.

1. Kelas Initiator adalah kelas yang bertanggung jawab untuk melakukan

penyesuaian parameter-parameter WebRTC pada browser yang berbeda –

beda. Sebelum melakukan penyesuaian, kelas Initiator juga akan

melakukan pengecekan kompatibilitas browser untuk memastikan browser

yang dipakai sudah mendukung fitur WebRTC.

2. Kelas Media adalah kelas yang bertanggung jawab untuk mendapatkan

data media dari kamera dan mikrofon pengguna. Data ini diperoleh dengan

menggunakan fitur WebRTC yang telah diimplementasi pada browser.

Kelas ini bertanggung jawab juga untuk menampilkan data media yang

diterima, baik dari pengguna atau pengguna lainnya.

3. Kelas Peer adalah kelas yang bertanggung jawab untuk melakukan

koneksi, baik dengan signaling server maupun dengan client lain. Selain

melakukan koneksi, kelas ini juga bertanggung jawab untuk mengirimkan

data media dan menangani pesan – pesan yang datang dari server atau

client lainnya.

4. Kelas Main adalah kelas utama yang akan menjalankan kelas – kelas lain

yang ada pada client side module.

Diagram kelas dari modul aplikasi live streaming dapat dilihat pada Gambar IV-2.

31

Gambar IV-2 Diagram kelas modul aplikasi live streaming

Ada sedikit perbedaan antara diagram kelas dengan rancangan arsitektur pada

Gambar IV-2, yaitu pada kelas Peer. Kelas Peer dijadikan sebuah interface

karena adanya perbedaan konfigurasi node yang memerlukan perlakuan berbeda.

Pada konfigurasi node yang berbeda (antara one to one, one to many, atau many to

many), maka akan ada perbedaan penanganan koneksi pada method createOffer

dan createAnswer di kelas Peer. Oleh karena itu, kelas-kelas berikutnya harus

mengimplementasikan method pada kelas Peer. Interaksi antar kelas akan dibahas

lebih lanjut melalui collaboration diagram pada Bab IV.3.

Secara lebih detil, pada Tabel IV-1 diperlihatkan traceability dari kemampuan live

streaming yang tersedia pada Bab III.1 dengan kelas yang ada.

Tabel IV-1 Tabel Traceability Modul Live Streaming

Kapabilitas Kelas Penanggung Jawab

Video Call Initiator, Media, Peer, Main

Video Conference Initiator, Media, Peer, Main

Desktop Sharing Initiator, Peer, Main

Live Chat Initiator, Peer, Main

32

IV.3. Collaboration Diagram pada Web Based Live Streaming Application

Ada dua kondisi pada aplikasi live streaming pada saat live streaming dilakukan.

Kondisi pertama adalah ketika pengguna menjadi inisiator dimulainya live

streaming. Ketika pengguna menjadi inisiator, pengguna harus mengirimkan

sebuah offer kepada pengguna – pengguna lain yang telah terdaftar. Sebelum offer

dibuat, sebuah session local description harus terlebih dahulu diset pada browser

pengguna. Session local description ini kemudian akan dikirimkan bersamaan

dengan offer yang dibuat.

Server kemudian akan memvalidasi offer yang diterima. Jika valid, server akan

mengirimkan offer tersebut kepada pengguna-pengguna lain yang dituju.

Pengguna-pengguna lain kemudian akan menyiapkan sebuah answer yang berisi

session local description mereka kepada pengguna yang memberikan offer.

Setelah answer diterima oleh server dan diteruskan kepada pengguna yang

memberikan offer, maka session dari answer akan disimpan sebagai session

remote description oleh pengguna yang memberikan offer. Koneksi terjalin dan

kemudian pengiriman data media dimulai.

Ketika pengguna bukan merupakan inisiator dari live streaming, session remote

description harus terlebih dahulu diisi dengan session local description dari

inisiator. Kemudian, barulah session local description dapat diset dan dikirimkan

untuk menjadi session remote description dari inisiator. Proses terbentuknya

koneksi dapat dilihat lebih lanjut pada Offer Sequence Diagram dan Answer

Sequence Diagram pada Lampiran C.

Ketika koneksi terjadi dengan konfigurasi jaringan one to one, hubungan antar

node dapat dilihat melalui Collaboration Diagram pada Gambar IV-3.

33

Gambar IV-3 Collaboration Diagram Antar Node Pada Konfigurasi Node One to

One

Pada konfigurasi jaringan one to many, kelas Peer yang berhubungan dengan

beberapa node lain harus mempertahankan koneksi sejumlah banyaknya node

yang berhubungan dengannya. Maka, offer diberikan kepada masing-masing node

yang hendak menjalin koneksi. Pengiriman data kemudian dilakukan secara peer

to peer antar pengguna. Kolaborasi antar node dapat dilihat pada

Gambar IV-4 (di halaman 34).

34

Gambar IV-4 Collaboration Diagram Antar Node dengan Konfigurasi Node One To Many

35

Pada konfigurasi jaringan many to many, kelas Peer harus mempertahankan

koneksi sejumlah banyaknya node yang berhubungan dengannya. Maka, offer

diberikan kepada seluruh node yang hendak saling menjalin koneksi. Begitu pula

answer harus diterima dari seluruh node yang hendak saling menjalin koneksi.

Ketika salah satu node hendak memutuskan koneksi, maka hanya koneksi dengan

node tersebut yang terputus. Sedangkan koneksi antar node – node lainnya tetap

terjalin dengan baik.

Kolaborasi antar node dapat dilihat pada Gambar IV-5. (di halaman 36).

36

Gambar IV-5 Collaboration Diagram Antar Node pada Konfigurasi Jaringan Many to Many

37

IV.4. Perancangan Pengujian Modul Aplikasi Live Streaming

Pada subbab ini dijelaskan mengenai pengujian aplikasi live streaming. Pengujian

akan dilakukan dengan 2 metode, yaitu unit testing dan use case testing. Unit

testing akan dilakukan dengan menggunakan tools Karma.js dan Jasmine pada

setiap kelas yang dibuat, sedangkan use case testing dilakukan dengan cara

penggunaan dan pengamatan langsung dari modul aplikasi yang dibuat. Tools

Karma.js dan Jasmine akan dijelaskan pada Bab IV.4.1.

Selain itu, untuk menguji kegunaan modul aplikasi, akan dilakukan studi kasus

dengan membuat 3 buah aplikasi web yang menggunakan modul live streaming

yang telah dibuat. Studi kasus ini akan dibahas lebih lanjut pada Bab V.

IV.4.1. Tools Pengujian Modul Aplikasi Live Streaming

Ada dua buah tools yang digunakan dalam pengujian modul aplikasi live

streaming, yaitu Karma.js dan Jasmine.

Karma.js adalah sebuah tool yang dapat mengaktifkan berbagai browser secara

otomatis, kemudian menjalankan berbagai kode pada masing-masing browser dan

mengembalikan hasilnya kepada pengembang. Salah satu framework testing yang

dapat digunakan oleh Karma.js adalah Jasmine.

Jasmine adalah sebuah behavior driven framework yang dapat digunakan untuk

menguji aplikasi web. Untuk menggunakan Jasmine, pengembang cukup

menuliskan beberapa script testing untuk masing – masing kasus dan halaman

web yang hendak diuji.

IV.4.2. Unit Testing Aplikasi Live Streaming

Unit Testing bertujuan untuk membuktikan setiap rancangan kelas dapat berfungsi

dengan baik secara unit. Pengujian pada setiap kelas dilakukan dengan

menggunakan tools Karma.js untuk mengotomasi tes serta Jasmine untuk

penulisan script testing. Kelas – kelas yang diuji adalah : Initiator, Media,

Main, OneToOne (implementasi dari interface Peer), OneToMany (implementasi

38

dari interface Peer), dan ManyToMany (implementasi dari interface Peer). Hasil

dari unit testing dapat dilihat pada Lampiran B.

IV.4.3. Load Test Aplikasi Live Streaming

Load test bertujuan untuk mengetahui kapabilitas maksimal dari modul aplikasi

live streaming yang dibuat. Load test yang dilakukan adalah load test pada server

module dan load test pada client module.

Pada server module, load test dilakukan untuk mengetahui berapa banyak client

yang dapat menggunakan signaling server secara bersamaan. Sedangkan pada

client module, load test dilakukan untuk mengetahui berapa banyak user yang

dapat berada dalam room yang sama.

IV.4.3.1. Server Module Load Test

Spesifikasi server yang diujicoba adalah sebagai berikut.

1. Processor : Intel 1 Core, 2.399 GHz

2. 512 MB RAM

3. 20 GB SSD

Lokasi server berada di Singapura, melalui penyedia layanan DigitalOcean.

Pengujian dilakukan dengan cara melakukan spawn proses yang meminta request

kepada signaling server. Setelah 1000 koneksi, server mengalami crash karena

memory usage yang terlalu besar.

IV.4.3.2. Client Module Load Test

Spesifikasi client yang diujicoba adalah sebagai berikut.

1. Processor : Intel i3 – 380M, 1.33 GHz

2. 4 GB RAM

3. 320 GB Harddisk

39

Pengujian dilakukan dengan cara melakukan koneksi dengan sebanyak mungkin

pengguna pada room yang sama. Pada saat pengujian, lag mulai terasa ketika ada

8 pengguna pada room yang sama. Hasil observasi menunjukkan bahwa untuk

setiap peer connection yang terbentuk, memory usage dari browser bertambah

sebanyak 4 MB. Tidak terjadi crash pada browser, namun lag yang terjadi setelah

8 pengguna berada pada room yang sama mengakibatkan aplikasi tidak dapat

digunakan dengan baik.

40

BAB V.

STUDI KASUS

Pada bab ini dijelaskan mengenai studi kasus yang dilakukan dengan

menggunakan modul live streaming. Studi kasus dilakukan pada tiga buah

aplikasi web dengan konfigurasi node yang berbeda. Setiap studi kasus dirancang

untuk menguji kegunaan aplikasi yang telah dicantumkan pada Bab III.1.1, juga

untuk menguji perilaku modul yang telah dibuat pada berbagai jenis konfigurasi

node. Pada akhir setiap studi kasus, dibuat kesimpulan mengenai hasil studi kasus.

Pada akhir bab ini dibuat kesimpulan umum mengenai kebergunaan modul live

streaming.

V.1. Studi Kasus Pembuatan Aplikasi Web untuk One to One Chat

Studi kasus pertama dilakukan dengan membuat sebuah aplikasi web untuk

melakukan chatting antara 2 pengguna. Pada aplikasi web yang dibuat, pengguna

pertama-tama harus membuat sebuah room, kemudian menunggu pengguna lain

untuk memasuki room dan kemudian mulai melakukan video dan textual chatting.

Tujuan dari studi kasus ini adalah untuk menguji penggunaan modul live

streaming dalam mengambil data media dari pengguna, melakukan koneksi

dengan satu pengguna saja (konfigurasi one to one), serta mengirimkan dan

menampilkan data.

V.1.1. Kebutuhan Fungsional

Kebutuhan fungsional dari aplikasi One to One Chat dapat dilihat pada Tabel V-1.

Tabel V-1 Tabel Kebutuhan Fungsional Aplikasi One to One Chat

ID

Requirement

Deskripsi Requirement

FR-01 Aplikasi dapat menerima permintaan inisialisasi koneksi

FR-02 Aplikasi dapat memvalidasi permintaan inisialisasi koneksi

dan meneruskannya kepada user lain yang dituju

FR-03 Aplikasi dapat mengirimkan data media kepada user lain

dengan benar

FR-04 Aplikasi dapat menutup koneksi antar user

41

ID

Requirement


FR-05 Aplikasi dapat memberikan peringatan penutupan koneksi

kepada user lain yang ada di room yang sama

V.1.2. Rancangan Aplikasi

Diagram kelas dari aplikasi One to One Chat dapat dilihat pada Gambar V-1 :

Gambar V-1 Diagram Kelas Aplikasi One to One Chat

Penggunaan modul aplikasi live streaming pada pengembangan aplikasi ini

dilakukan dengan beberapa langkah berikut :

1. Pada sisi server, sertakan modul live streaming ke dalam aplikasi dengan

kode sebagai berikut :

var Server = require('Server');

2. Memulai signaling server dengan kode sebagai berikut :

Server.start(8080); //8080 is the socket port

3. Pada sisi client, sertakan modul live streaming ke dalam aplikasi dengan


<script type="text/Javascript" src="main.js"></script>

var Main = require('Main');

var ls = new Main();

4. Mengatur domain server live streaming dengan kode sebagai berikut :

ls.setServer('http://live.nicholasrio.com:1128');

5. Membuka sebuah ruangan baru dengan kode sebagai berikut :

42

ls.createRoom('example');

6. Bergabung ke dalam sebuah ruangan yang telah ada dengan kode sebagai

berikut :

ls.joinRoom('example');

7. Menutup koneksi dengan kode sebagai berikut :

ls.closeConnection('example');

V.1.3. Skenario Pengujian

Pengujian aplikasi One to One Chat dilakukan dengan dua buah skenario.

Skenario pertama adalah skenario normal ketika tidak ada gangguan pada koneksi

internet, sedangkan skenario kedua adalah skenario alternatif ketika terjadi

gangguan koneksi pada salah satu pengguna.

Skenario normal dan hasil pengujiannya dapat dilihat pada Tabel V-2.

Tabel V-2 Skenario Normal Aplikasi One to One Chat

No Langkah Hasil yang

diharapkan

Hasil yang dicapai

1 Pengguna pertama

mengakses aplikasi

dengan browser

Google Chrome 35.

Aplikasi dapat diakses

pada browser


pada browser

2 Pengguna kedua

mengakses aplikasi

dengan browser

Mozilla Firefox 34

di komputer lain.


pada browser


pada browser

3 Pengguna pertama

membuat room

dengan nama

“Example”.

Room Example

terbentuk, pengguna

pertama berada dalam

status menunggu

pengguna berikutnya.

Room Example

terbentuk, pengguna


status menunggu


4 Pengguna kedua

memasuki room

“Example”.

Pengguna kedua masuk

ke dalam room

Example dan

menginisialisasi

koneksi dengan

pengguna pertama.

Koneksi peer to peer

antar pengguna terjalin.


ke dalam room Example

dan menginisialisasi

koneksi dengan

pengguna pertama.



43


diharapkan

Hasil yang dicapai

5 Pengguna pertama

dan kedua saling

berkomunikasi.

Pengguna pertama dan

kedua dapat saling

melihat data media

lawan bicaranya.


kedua dapat saling

melihat data media

lawan bicaranya.

6 Pengguna pertama

menutup room

“Example”.

Room Example

tertutup, baik pada

pengguna pertama

maupun pada pengguna

kedua.

Room Example tertutup,

baik pada pengguna

pertama maupun pada

pengguna kedua.

Skenario alternatif dan hasil pengujiannya ketika terjadi gangguan koneksi dapat

dilihat pada Tabel V-3.

Tabel V-3 Skenario Alternatif Aplikasi One to One Chat


diharapkan

Hasil yang dicapai

1 Pengguna pertama

mengakses aplikasi

dengan browser

Google Chrome 35.


pada browser


pada browser

2 Pengguna kedua

mengakses aplikasi

dengan browser

Mozilla Firefox 34

di komputer lain.


pada browser


pada browser

3 Pengguna pertama

membuat room

dengan nama

“Example”.

Room Example

terbentuk, pengguna


status menunggu


Room Example

terbentuk, pengguna


status menunggu


4 Pengguna kedua

memasuki room

“Example”.


ke dalam room

Example dan

menginisialisasi

koneksi dengan

pengguna pertama.




ke dalam room Example


koneksi dengan

pengguna pertama.



5 Pengguna pertama

dan kedua saling

berkomunikasi.


kedua dapat saling

melihat data media

lawan bicaranya.


kedua dapat saling

melihat data media

lawan bicaranya.

6 Internet pengguna Pengguna pertama Pengguna pertama tidak

44


diharapkan

Hasil yang dicapai

kedua dimatikan. tidak dapat melihat data

media pengguna kedua.

dapat melihat data

media pengguna kedua.

7 Internet pengguna

kedua menyala.

Terjadi rekoneksi

antara pengguna

pertama dan kedua.

Kedua pengguna

kemudian dapat

melihat data media

lawan bicaranya.

Terjadi rekoneksi antara

pengguna pertama dan

kedua. Kedua pengguna

kemudian dapat melihat

data media lawan

bicaranya.

8 Pengguna pertama

menutup room

“Example”.

Room Example

tertutup, baik pada

pengguna pertama

maupun pada pengguna

kedua.

Room Example tertutup,

baik pada pengguna

pertama maupun pada

pengguna kedua.

45

V.1.4. Hasil Benchmark

Besar data video yang diterima oleh pengguna pertama setiap detiknya dapat

dilihat pada Gambar V-2. Terlihat adanya peningkatan bitrate video hingga

menjadi stabil sekitar detik 34. Ini terjadi karena dibutuhkan waktu untuk

perlahan–lahan meningkatkan kualitas koneksi peer to peer antar node.

Gambar V-2 Bitrate Video Pengguna Pertama

Framerate adalah jumlah frame pada satu detik. Framerate video pada pengguna

pertama setiap detiknya dapat dilihat pada Gambar V-3. Dari hasil benchmark,

terlihat bahwa framerate cukup stabil berkisar antara 16 – 19 fps. Terjadi lonjakan

tajam pada detik pertama karena koneksi baru mulai terjalin pada detik pertama.

46

Gambar V-3 Framerate Video Pengguna Pertama

Besar data audio yang diterima oleh pengguna pertama setiap detiknya dapat

dilihat pada Gambar V-4. Fluktuasi dari data audio yang diterima akibat input

audio yang berbeda seiring dengan waktu. Terjadi peningkatan tajam pada detik

pertama karena koneksi baru terjalin pada detik pertama.

Gambar V-4 Bitrate Audio Pengguna Pertama

Besar data video yang diterima oleh pengguna kedua setiap detiknya dapat dilihat

pada Gambar V-5. Terlihat adanya peningkatan bitrate video hingga menjadi

47

stabil sekitar detik 34. Ini terjadi karena dibutuhkan waktu untuk perlahan – lahan

meningkatkan kualitas koneksi peer to peer antar node.

Gambar V-5 Bitrate Video Pengguna Kedua

Framerate adalah jumlah frame pada satu detik. Framerate video pada pengguna

kedua setiap detiknya dapat dilihat pada Gambar V-6. Framerate video cukup

stabil pada kisaran 16 – 20 fps. Terjadi lonjakan tajam pada detik pertama karena

koneksi baru mulai terjalin pada detik pertama.

Gambar V-6 Framerate Video Pengguna Kedua

48

Besar data audio yang diterima oleh pengguna kedua setiap detiknya dapat dilihat

pada Gambar V-7. Fluktuasi dari data audio yang diterima akibat input audio yang

berbeda seiring dengan waktu. Terjadi peningkatan tajam pada detik pertama

karena koneksi baru terjalin pada detik pertama.

Gambar V-7 Bitrate Audio Pengguna Kedua

V.1.5. Kesimpulan Studi Kasus

Studi kasus ini menunjukkan bahwa :

1. Modul live streaming dapat digunakan untuk mengimplementasikan

sebuah aplikasi web One to One Chat.

2. Studi kasus menunjukkan bahwa modul live streaming dapat mengambil

data media, melakukan koneksi dengan satu pengguna, mengirimkan data

media kepada pengguna dan menampilkan data media.

V.2. Studi Kasus Pembuatan Web Application untuk Online Class

Studi kasus kedua dilakukan dengan membuat sebuah aplikasi web Online Class.

Pada aplikasi web yang dibuat, pengguna pertama-tama harus melakukan

registrasi sebagai user. Pengguna dapat kemudian memulai sebuah pelajaran

secara online, atau mengikuti sebuah pelajaran yang sedang berlangsung.

Pengguna yang mengikuti sebuah pelajaran akan melihat pengajar melalui

49

streaming media dan dapat berinteraksi langsung dengan pengajar dan pengguna

lain yang berada di dalam pelajaran itu. Namun, pengguna yang mengikuti

pelajaran tersebut tidak akan mengirimkan data medianya kepada pengajar dan

pengguna lainnya. Tujuan dari studi kasus ini adalah untuk menguji penggunaan

modul live streaming ketika salah satu pengguna (pengajar) harus

mempertahankan koneksi dengan banyak pengguna lainnya (konfigurasi node one

to many).


Kebutuhan fungsional dari aplikasi Online Class dapat dilihat pada Tabel V-4.

Tabel V-4 Kebutuhan Fungsional Aplikasi Online Class

ID

Requirement





FR-03 Aplikasi dapat mempertahankan koneksi dengan banyak

pengguna


dengan benar




50


Diagram kelas dari aplikasi Online Class dapat dilihat pada Gambar V-8.

Gambar V-8 Diagram Kelas Aplikasi Online Class















5. Khusus pada sisi pengguna yang menjadi murid, ubah konfigurasi agar

pengguna hanya menerima data media dengan kode sebagai berikut :

ls.setOfferVideo(false);

ls.setOfferAudio(false);

51




berikut :





Pengujian aplikasi Online Class dilakukan dengan 2 skenario. Skenario pertama

adalah ketika salah satu murid menutup koneksinya di tengah kelas. Sedangkan

skenario kedua adalah ketika Guru menutup kelas dengan sejumlah murid yang

masih terkoneksi.

Skenario pertama dan hasil pengujiannya dapat dilihat pada Tabel V-5.

Tabel V-5 Skenario Pertama Aplikasi Online Class


diharapkan

Hasil yang dicapai

1 Guru mengakses

aplikasi dengan

browser Google

Chrome 35.


pada browser


pada browser

2 Murid pertama

mengakses aplikasi

dengan browser

Mozilla Firefox 34

di komputer lain.


pada browser


pada browser

3 Murid kedua

mengakses aplikasi

dengan browser

Mozilla Firefox di

komputer lain.


pada browser


pada browser

4 Guru membuat

kelas

“Matematika”.

Kelas Matematika

terbuka, Guru

menunggu koneksi dari

murid.

Kelas Matematika

terbuka, Guru menunggu

koneksi dari murid.

5 Murid pertama

memasuki kelas

“Matematika”.

Murid pertama masuk

ke kelas Matematika,

koneksi peer to peer

Murid pertama masuk ke

kelas Matematika,


52


diharapkan

Hasil yang dicapai

terjalin antara murid

pertama dan Guru.


pertama dan Guru.

6 Murid kedua

memasuki kelas

“Matematika”.

Murid kedua masuk ke

kelas Matematika,



kedua dan Guru.


kelas Matematika,



kedua dan Guru.

7 Guru dan murid

saling

berkomunikasi.

Murid pada kelas

Matematika dapat

melihat data media dari

Guru. Sedangkan Guru

dapat melihat

pertanyaan –

pertanyaan dalam

bentuk teks dari murid

– murid di kelas

Matematika.

Murid pada kelas

Matematika dapat



dapat melihat pertanyaan

– pertanyaan dalam

bentuk teks dari murid –

murid di kelas

Matematika.

8 Murid pertama

menutup koneksi.

Murid pertama keluar

dari kelas Matematika.

Guru memutuskan


dengan murid pertama.

Guru dan murid kedua

tetap terkoneksi.

Murid pertama keluar

dari kelas Matematika.

Guru memutuskan


dengan murid pertama.

Guru dan murid kedua

tetap terkoneksi.

Skenario kedua dan hasil pengujiannya dapat dilihat pada Tabel V-6.

Tabel V-6 Skenario Kedua Aplikasi Online Class


diharapkan

Hasil yang dicapai

1 Guru mengakses

aplikasi dengan

browser Google

Chrome 35.


pada browser


pada browser

2 Murid pertama

mengakses aplikasi

dengan browser

Mozilla Firefox 34

di komputer lain.


pada browser


pada browser

3 Murid kedua

mengakses aplikasi

dengan browser

Mozilla Firefox 34

di komputer lain.


pada browser


pada browser

53


diharapkan

Hasil yang dicapai

4 Guru membuat

kelas

“Matematika”.

Kelas Matematika

terbuka, Guru

menunggu koneksi dari

murid.

Kelas Matematika

terbuka, Guru menunggu

koneksi dari murid.

5 Murid pertama

memasuki kelas

“Matematika”.

Murid pertama masuk

ke kelas Matematika,



pertama dan Guru.

Murid pertama masuk ke

kelas Matematika,



pertama dan Guru.

6 Murid kedua

memasuki kelas

“Matematika”.


kelas Matematika,



kedua dan Guru.


kelas Matematika,



kedua dan Guru.

7 Guru dan murid

saling

berkomunikasi.

Murid pada kelas

Matematika dapat



dapat melihat

pertanyaan-pertanyaan

dalam bentuk teks dari

murid-murid di kelas

Matematika.

Murid pada kelas

Matematika dapat



dapat melihat

pertanyaan-pertanyaan

dalam bentuk teks dari

murid-murid di kelas

Matematika.

8 Guru menutup

kelas.

Guru memutuskan


dengan murid pertama

dan murid kedua.

Semua murid secara

otomatis keluar dari

kelas.

Guru memutuskan


dengan murid pertama

dan murid kedua. Semua

murid secara otomatis

keluar dari kelas.


Besar data video yang diterima oleh murid pertama setiap detiknya dapat dilihat

pada Gambar V-9. Bitrate video relatif stabil pada kisaran 1700000 – 2300000

bits / second.

54

Gambar V-9 Bitrate Video Murid Pertama

Framerate adalah jumlah frame pada satu detik. Framerate data video yang

diterima oleh murid kedua setiap detiknya dapat dilihat pada Gambar V-13. Pada

awalnya framerate video berada pada kisaran 15 – 16 fps, namun setelah koneksi

membaik, framerate video meningkat menjadi 19 – 20 fps. Terjadi lonjakan tajam

pada detik pertama karena koneksi baru mulai terjalin pada detik pertama.

Gambar V-10 Framerate Video Murid Pertama

55

Besar data audio yang diterima oleh murid pertama setiap detiknya dapat dilihat

pada Gambar V-11. Fluktuasi dari data audio yang diterima akibat input audio

yang berbeda seiring dengan waktu. Terjadi peningkatan tajam pada detik pertama


Gambar V-11 Bitrate Audio Murid Pertama

Besar data video yang diterima oleh murid kedua setiap detiknya dapat dilihat

pada Gambar V-12. Terlihat peningkatan bitrate video hingga menjadi stabil

sekitar detik 13. Ini terjadi karena dibutuhkan waktu untuk perlahan – lahan

meningkatkan kualitas koneksi peer to peer antar node.

56

Gambar V-12 Bitrate Video Murid Kedua

Framerate adalah jumlah frame pada satu detik. Framerate data video yang

diterima oleh murid kedua setiap detiknya dapat dilihat pada Gambar V-13. Pada

awalnya framerate video berada pada kisaran 15 – 16 fps, namun setelah koneksi

membaik, framerate video meningkat menjadi 19 – 20 fps. Terjadi lonjakan tajam

pada detik pertama karena koneksi baru mulai terjalin pada detik pertama.

Gambar V-13 Framerate Video Murid Kedua

Besar data audio yang diterima oleh murid kedua setiap detiknya dapat dilihat

pada Gambar V-14. Fluktuasi dari data audio yang diterima akibat input audio

57

yang berbeda seiring dengan waktu. Terjadi peningkatan tajam pada detik pertama


Gambar V-14 Bitrate Audio Murid Kedua



1. Modul aplikasi live streaming dapat digunakan ulang untuk

mengimplementasikan sebuah aplikasi web Online Class.

2. Modul aplikasi live streaming dapat mempertahankan koneksi dengan

beberapa pengguna sekaligus.

V.3. Studi Kasus Pembuatan Web Application untuk Video Conference

Studi kasus ketiga dilakukan dengan membuat sebuah aplikasi web untuk

melakukan Video Conference. Pada aplikasi web yang dibuat, pengguna pertama-

tama harus melakukan registrasi sebagai user, kemudian membuat sebuah room

untuk mulai melakukan Video Conference. Pengguna lain kemudian dapat

memasuki room yang telah dibuat untuk melakukan Video Conference. Tujuan

dari studi kasus ini adalah untuk menguji penggunaan modul live streaming,

dalam mengambil data media dari pengguna, melakukan koneksi dengan satu atau

lebih pengguna, mengirimkan data media kepada pengguna dan menampilkan

58

data media. Selain itu, pada studi kasus ini pengaksesan aplikasi web yang telah

dibuat dilakukan melalui berbagai platform untuk melihat apakah modul aplikasi

ini dapat berjalan pada platform yang berbeda-beda.


Kebutuhan fungsional dari aplikasi Video Conference dapat dilihat pada

Tabel V-7.

Tabel V-7 Kebutuhan Fungsional Aplikasi Video Conference

ID

Requirement


FR-01 Aplikasi dapat melakukan registrasi user

FR-02 Aplikasi dapat melakukan log in user




FR-05 Aplikasi dapat mempertahankan koneksi dengan banyak

pengguna


dengan benar





Diagram kelas dari aplikasi Video Conference dapat dilihat pada Gambar V-15.

Gambar V-15 Diagram Kelas Aplikasi Video Conference

59















5. Mengatur username dengan kode sebagai berikut :

ls.setUser("nicholas");




berikut :





Pengujian aplikasi Video Conference dilakukan dengan 2 skenario. Skenario

pertama adalah ketika semua pengguna menggunakan desktop untuk mengakses

aplikasi. Skenario kedua adalah ketika ada pengguna yang menggunakan mobile

phone dan sistem operasi yang berbeda-beda untuk mengakses aplikasi.

Skenario pertama dan hasil pengujiannya dapat dilihat pada Tabel V-8.

60

Tabel V-8 Skenario Pertama Aplikasi Video Conference


diharapkan

Hasil yang dicapai

1 Pengguna pertama

mengakses

aplikasi dengan

browser Google

Chrome 35.


pada browser


pada browser

2 Pengguna kedua

mengakses

aplikasi dengan

browser Mozilla

Firefox 34 di

komputer lain.


pada browser


pada browser

3 Pengguna ketiga

mengakses

aplikasi dengan

browser Mozilla

Firefox 34 di

komputer lain.


pada browser


pada browser

4 Pengguna pertama

membuat room

“Example”.

Room Example

terbentuk, pengguna


status menunggu


Room Example terbentuk,

pengguna pertama berada

dalam status menunggu


5 Pengguna kedua

memasuki room

“Example”.

Pengguna kedua

memasuki Room

Example dan

menginisialisasi


dengan pengguna

pertama. Koneksi peer

to peer terbentuk antara


pengguna kedua.

Pengguna kedua

memasuki Room Example



dengan pengguna

pertama. Koneksi peer to

peer terbentuk antara


pengguna kedua.

61


diharapkan

Hasil yang dicapai

6 Pengguna ketiga

memasuki room

“Example”.

Pengguna ketiga

memasuki Room

Example dan

menginisialisasi


dengan pengguna

pertama dan kedua.


terbentuk antara

pengguna ketiga dan

pertama, serta

pengguna ketiga dan

kedua.

Pengguna ketiga

memasuki Room Example



dengan pengguna pertama

dan kedua. Koneksi peer


pengguna ketiga dan

pertama, serta pengguna

ketiga dan kedua.

7 Seluruh pengguna

saling

berkomunikasi.

Pengguna pertama,

kedua, dan ketiga dapat

saling melihat data

media lawan bicaranya.

Pengguna pertama, kedua,

dan ketiga dapat saling

melihat data media lawan

bicaranya.

8 Pengguna pertama

menutup room

“Example”.

Pengguna pertama

menutup koneksi peer

to peer dengan

pengguna kedua dan

ketiga. Pengguna kedua

dan ketiga menutup


dengan pengguna

pertama. Pengguna

pertama keluar dari

Room Example, namun

pengguna kedua dan

ketiga masih

berkomunikasi dengan

normal pada Room

Example.

Pengguna pertama

menutup koneksi peer to

peer dengan pengguna

kedua dan ketiga.

Pengguna kedua dan

ketiga menutup koneksi

peer to peer dengan

pengguna pertama.

Pengguna pertama keluar

dari Room Example,

namun pengguna kedua

dan ketiga masih


normal pada Room

Example.

62

Skenario kedua dan hasil pengujiannya dapat dilihat pada Tabel V-9.

Tabel V-9 Skenario Kedua Aplikasi Video Conference


diharapkan

Hasil yang dicapai

1 Pengguna pertama

mengakses aplikasi

dengan browser

Google Chrome 35

dengan sistem

operasi Windows

7.


pada browser


pada browser

2 Pengguna kedua

mengakses aplikasi

dengan browser

Mozilla Firefox 34

di komputer lain

dengan sistem

operasi Ubuntu.


pada browser


pada browser

3 Pengguna ketiga

mengakses aplikasi

dengan browser

Mozilla Firefox 34

di ponsel Samsung

Galaxy Note 2.


pada browser


pada browser

4 Pengguna pertama

membuat room

“Example”.

Room Example

terbentuk, pengguna


status menunggu


Room Example

terbentuk, pengguna


status menunggu


5 Pengguna kedua

memasuki room

“Example”.

Pengguna kedua

memasuki Room

Example dan

menginisialisasi


dengan pengguna

pertama. Koneksi peer



pengguna kedua.

Pengguna kedua

memasuki Room

Example dan

menginisialisasi koneksi

peer to peer dengan

pengguna pertama.


terbentuk antara


pengguna kedua.

63


diharapkan

Hasil yang dicapai

6 Pengguna ketiga

memasuki room

“Example”.

Pengguna ketiga

memasuki Room

Example dan

menginisialisasi


dengan pengguna

pertama dan kedua.


terbentuk antara

pengguna ketiga dan

pertama, serta

pengguna ketiga dan

kedua.

Pengguna ketiga

memasuki Room

Example dan

menginisialisasi koneksi

peer to peer dengan


kedua. Koneksi peer to

peer terbentuk antara

pengguna ketiga dan

pertama, serta pengguna

ketiga dan kedua.

7 Seluruh pengguna

saling

berkomunikasi.

Pengguna pertama,


saling melihat data

media lawan bicaranya.

Pengguna pertama,


saling melihat data media

lawan bicaranya.

8 Pengguna pertama

menutup room

“Example”.

Pengguna pertama

menutup koneksi peer

to peer dengan

pengguna kedua dan

ketiga. Pengguna kedua

dan ketiga menutup


dengan pengguna

pertama. Pengguna

pertama keluar dari

Room Example, namun

pengguna kedua dan

ketiga masih


normal pada Room

Example.

Pengguna pertama

menutup koneksi peer to

peer dengan pengguna

kedua dan ketiga.

Pengguna kedua dan

ketiga menutup koneksi

peer to peer dengan

pengguna pertama.

Pengguna pertama keluar

dari Room Example,

namun pengguna kedua

dan ketiga masih


normal pada Room

Example.


Besar data video yang diterima oleh pengguna pertama dari pengguna kedua

setiap detiknya dapat dilihat pada Gambar V-16. Terlihat adanya peningkatan

bitrate video hingga menjadi stabil sekitar detik ke 28. Ini terjadi karena

dibutuhkan waktu untuk perlahan – lahan meningkatkan kualitas koneksi peer to

peer antar node.

64

Gambar V-16 Bitrate Video Pengguna Pertama dari Pengguna Kedua

Framerate adalah jumlah frame pada satu detik. Framerate video yang diterima

oleh pengguna pertama dari pengguna kedua setiap detiknya dapat dilihat pada

Gambar V-17. Framerate video terlihat cukup berfluktuasi sesuai dengan kondisi

jaringan, beriksar antara 16 – 25 fps. Terjadi lonjakan tajam pada detik pertama

karena koneksi baru mulai terjalin pada detik pertama.

Gambar V-17 Framerate Video Pengguna Pertama dari Pengguna Kedua

Besar data audio yang diterima oleh pengguna pertama dari pengguna kedua

setiap detiknya dapat dilihat pada Gambar V-18. Fluktuasi dari data audio yang

65

diterima akibat input audio yang berbeda seiring dengan waktu. Terjadi

peningkatan tajam pada detik pertama karena koneksi baru terjalin pada detik

pertama.

Gambar V-18 Bitrate Audio Pengguna Pertama dari Pengguna Kedua

Besar data video yang diterima oleh pengguna pertama dari pengguna ketiga

setiap detiknya dapat dilihat pada Gambar V-19. Terlihat peningkatan bitrate

video hingga menjadi stabil sekitar detik ke 22. Ini terjadi karena dibutuhkan

waktu untuk perlahan – lahan meningkatkan kualitas koneksi peer to peer antar

node.

Gambar V-19 Bitrate Video Pengguna Pertama dari Pengguna Ketiga


oleh pengguna pertama dari pengguna ketiga setiap detiknya dapat dilihat pada

66

Gambar V-20. Framerate yang rendah disebabkan oleh keterbatasan piranti

kamera pada pengguna ketiga yang hanya dapat menghasilkan framerate

maksimum 10 fps. Terjadi lonjakan tajam pada detik pertama karena koneksi baru

mulai terjalin pada detik pertama.

Gambar V-20 Framerate Video Pengguna Pertama dari Pengguna Ketiga

Besar data audio yang diterima oleh pengguna pertama dari pengguna ketiga




pertama.

67

Gambar V-21 Bitrate Audio Pengguna Pertama dari Pengguna Ketiga

Besar data video yang diterima oleh pengguna kedua dari pengguna pertama

setiap detiknya dapat dilihat pada Gambar V-22. Terlihat peningkatan pada bitrate

video hingga menjadi stabil sekitar detik ke-28. Ini terjadi karena dibutuhkan

waktu untuk perlahan – lahan meningkatkan kualitas koneksi peer to peer antar

node.

Gambar V-22 Bitrate Video Pengguna Kedua dari Pengguna Pertama

68


oleh pengguna kedua dari pengguna pertama setiap detiknya dapat dilihat pada

Gambar V-23. Framerate video berfluktuasi sesuai dengan kondisi jaringan, di

antara 16 – 25 fps. Terjadi lonjakan tajam pada detik pertama karena koneksi baru


Gambar V-23 Framerate Video Pengguna Kedua dari Pengguna Pertama

Besar data audio yang diterima oleh pengguna kedua dari pengguna pertama




pertama.

69

Gambar V-24 Bitrate Audio Pengguna Kedua dari Pengguna Pertama

Besar data video yang diterima oleh pengguna kedua dari pengguna ketiga setiap

detiknya dapat dilihat pada Gambar V-25. Terlihat peningkatan bitrate video

hingga menjadi stabil sekitar detik ke-16 yang terjadi karena dibutuhkan waktu

untuk perlahan-lahan meningkatkan kualitas koneksi peer to peer antar node.

Gambar V-25 Bitrate Video Pengguna Kedua dari Pengguna Ketiga


oleh pengguna kedua dari pengguna ketiga setiap detiknya dapat dilihat pada

70

Gambar V-26. Framerate video yang rendah disebabkan oleh keterbatasan piranti

kamera pada pengguna ketiga yang hanya dapat menghasilkan framerate

maksimum 10 fps. Terjadi lonjakan tajam pada detik pertama karena koneksi baru


Gambar V-26 Framerate Video Pengguna Kedua dari Pengguna Ketiga

Besar data audio yang diterima oleh pengguna kedua dari pengguna ketiga setiap

detiknya dapat dilihat pada Gambar V-27. Fluktuasi dari data audio yang diterima

akibat input audio yang berbeda seiring dengan waktu. Terjadi peningkatan tajam

pada detik pertama karena koneksi baru terjalin pada detik pertama.

Gambar V-27 Bitrate Audio Pengguna Kedua dari Pengguna Ketiga

71

Besar data video yang diterima oleh pengguna ketiga dari pengguna pertama

setiap detiknya dapat dilihat pada Gambar V-28. Peningkatan bitrate video baru

mulai terjadi pada detik 19. Ini terjadi karena dibutuhkan waktu untuk perlahan –

lahan meningkatkan kualitas koneksi peer to peer antar node.

Gambar V-28 Bitrate Video Pengguna Ketiga dari Pengguna Pertama


oleh pengguna ketiga dari pengguna pertama setiap detiknya dapat dilihat pada

Gambar V-29. Framerate video berfluktuasi sesuai dengan kondisi jaringan di

kisaran 6 – 25 fps. Terjadi lonjakan tajam pada detik pertama karena koneksi baru


Gambar V-29 Framerate Video Pengguna Ketiga dari Pengguna Pertama

72

Besar data audio yang diterima oleh pengguna ketiga dari pengguna pertama




pertama.

Gambar V-30 Bitrate Audio Pengguna Ketiga dari Pengguna Pertama

Besar data video yang diterima oleh pengguna ketiga dari pengguna kedua setiap

detiknya dapat dilihat pada Gambar V-31. Peningkatan bitrate video baru mulai

terjadi pada detik ke-19, sebelum menjadi stabil sekitar detik ke-58. Ini terjadi

karena dibutuhkan waktu untuk perlahan – lahan meningkatkan kualitas koneksi

peer to peer antar node.

73

Gambar V-31 Bitrate Video Pengguna Ketiga dari Pengguna Kedua


oleh pengguna ketiga dari pengguna kedua setiap detiknya dapat dilihat pada

Gambar V-32. Framerate video berfluktuasi sesuai dengan kondisi jaringan pada

kisaran 9 – 25 fps. Terjadi lonjakan tajam pada detik pertama karena koneksi baru


Gambar V-32 Framerate Video Pengguna Ketiga dari Pengguna Kedua

74

Besar data audio yang diterima oleh pengguna ketiga dari pengguna kedua setiap

detiknya dapat dilihat pada Gambar V-33. Fluktuasi dari data audio yang diterima

akibat input audio yang berbeda seiring dengan waktu. Terjadi peningkatan tajam

pada detik pertama karena koneksi baru terjalin pada detik pertama.

Gambar V-33 Bitrate Audio Pengguna Ketiga dari Pengguna Kedua



1. Modul live streaming dapat digunakan untuk mengimplementasikan

sebuah aplikasi web Video Conference.

2. Studi kasus menunjukkan bahwa modul live streaming dapat mengambil

data media, melakukan koneksi dengan satu atau lebih pengguna,

mengirimkan data media kepada pengguna dan menampilkan data media.

3. Modul live streaming dapat berjalan pada platform Windows, Ubuntu dan

Android yang digunakan untuk mengakses aplikasi web yang dibuat.

4. Performa modul live streaming dapat dipengaruhi juga oleh kualitas

perangkat keras yang kurang baik, ditunjukkan oleh rendahnya framerate

video yang dikirimkan oleh pengguna ketiga.

75

V.4. Kesimpulan Studi Kasus Keseluruhan

Beberapa kesimpulan yang dapat ditarik dari studi kasus yang telah dilakukan :

1. Modul aplikasi live streaming dapat digunakan pada pengembangan

berbagai aplikasi web.

2. Modul aplikasi live streaming dapat mengambil data media, melakukan

koneksi dengan satu atau lebih pengguna, mengirimkan data media dan

menampilkan data media.

3. Modul aplikasi live streaming berjalan dengan baik pada berbagai

platform yang diuji.

4. Modul aplikasi live streaming dapat mempertahankan koneksi dengan satu

atau lebih pengguna.

76

BAB VI.

KESIMPULAN DAN SARAN

Pada bab ini akan dijelaskan mengenai kesimpulan dari pengerjaan Tugas Akhir

dan saran untuk pengembangan lebih lanjut terhadap modul aplikasi live

streaming yang telah dipaparkan.

VI.1. Kesimpulan

Kesimpulan yang didapat dari pengembangan Tugas Akhir ini adalah :

1. Modul aplikasi live streaming dapat dibuat dengan menggunakan

teknologi HTML5, yaitu WebSocket dan WebRTC.

2. Modul aplikasi live streaming yang dibuat bersifat reusable. Hal ini sudah

dibuktikan dengan penggunaan modul tersebut pada 3 studi kasus yang

dilakukan. Pada 3 studi kasus yang telah dilakukan, modul aplikasi yang

dibuat sudah dapat digunakan tanpa banyak perubahan.

3. Modul aplikasi live streaming yang dibuat bersifat reliable. Hal ini dapat

disimpulkan dari simulasi putusnya jaringan pada studi kasus pertama,

serta dari hasil benchmark pada seluruh studi kasus yang telah dilakukan.

4. Masih terjadi performa yang kurang baik pada modul aplikasi ini, yang

disebabkan antara lain oleh kualitas perangkat keras yang kurang baik.

VI.2. Saran

Saran untuk pengembangan selanjutnya terhadap Tugas Akhir ini adalah :

1. Modul aplikasi live streaming mungkin juga dilakukan dengan membuat

sebuah extention pada browser. Metode ini dapat diteliti lebih lanjut pada

penelitian berikutnya.

2. Ada metode – metode lain yang dapat digunakan dalam mengirimkan data,

antara lain dengan menggunakan HTTP Polling. Metode ini dapat diteliti

lebih lanjut pada penelitian berikutnya.

77

3. Signaling server pada Tugas Akhir ini dapat pula dibuat dengan

menggunakan Session Initiation Protocol (SIP). Pembuatan signaling

server dengan menggunakan SIP beserta kelebihan – kelebihannya dapat

diteliti lebih lanjut pada penelitian berikutnya.

78

DAFTAR REFERENSI

[1] Diambil pada tanggal 25 Oktober 2013, pukul 15.00 sore :

https://support.Skype.com/en/faq/FA12309/what-are-the-minimum-requirements-

for-running-Skype-for-android

[2] Jana, S., Amit Pande, Jack Chan dan Prasant Mohaputra. 2013. Mobile Video

Chat : Issues and Challenges.

[3] Johnston, Alan B., Daniel C. Burnett. 2013. APIs and RTCWeb Protocols of

the HTML5 Real-Time Web, 2nd

edition.

[4] Wang, Vanessa, Frank Salim, dan Peter Moskovits. 2013. The Definitive

Guide to HTML5 WebSocket.

[5] Diambil pada tanggal 15 November 2013, pukul 01.24 pagi :

http://www.w3schools.com/browsers/browsers_stats.asp

[6] Simpson, Wes. 2008. Video Over IP: IPTV, Internet Video, H.264, P2P, Web

TV, and Streaming: A Complete Guide to Understanding the Technology.

[7] Meyer, Benhard. 1997. Object-Oriented Software Construction, 2nd

edition.

[8] Diambil pada tanggal 13 Januari 2014, pukul 12.39 siang :

http://www.memoireonline.com/05/08/1075/m_ip-packet-charging-multimedia-

services8.html.

[9] Diambil pada tanggal 1 Maret 2014, pukul 9.36 pagi :

http://www.codeproject.com/Articles/614028/Peer-to-Peer-File-Sharing-Through-

WCF.


http://pt.wikipedia.org/wiki/Ficheiro:Server-based-network.svg


https://www.WebSocket.org/quantum.html

[12] van Kesteren, Anna. 2011. HTML5 differences from HTML4.

https://support.skype.com/en/faq/FA12309/what-are-the-minimum-requirements-for-running-skype-for-android

https://support.skype.com/en/faq/FA12309/what-are-the-minimum-requirements-for-running-skype-for-android

http://www.w3schools.com/browsers/browsers_stats.asp

https://www.websocket.org/quantum.html

79

Lampiran A. MediaStream Processing API

Stream Processing API and Description Tipe

MediaStream

Represents a collection of MediaStreamTrack, currently

only audio and video.

Interface

new MediaStream(MediaStream or

MediaStreamTrackSequence)

Captures a new MediaStream consisting of tracks of

audio and video from other MediaStream objects. The

input parameter is either a single MediaStream or a

MediaStreamTrackSequence, which is an array of

MediaStreamTrack.

Constructor

MediaStream.id

A unique, browser generated identifier string for this

MediaStream defined in the “Media Capture and

Streams” document. The “Web RTC 1.0” document

explains how the remote-originated stream labels are

created.

Attribute

MediaStream.getAudioTracks()

Returns an array of all the AudioMediaStreamTrack in

this MediaStream.

Method

MediaStream.getVideoTracks()

Returns an array of all the VideoMediaStreamTrack in

this MediaStream.

Method

MediaStream.clone()

Returns a clone of the MediaStream that has a different

id and clones of all tracks in the MediaStream.

Method

MediaStream.ended

Set by the browser, this attribute has the value true if and

if only the stream has finished.

Attribute

80

MediaStream.onended

Application-settable to a function or method that will be

called when MediaStream finishes.

Attribute

Stream Processing API and Description Tipe

NavigatorUserMedia

Pre-existing interface in all web browsers.

Interface

NavigatorUserMedia.getUserMedia()

Returns a MediaStream containing one or more media

tracks that satisfy the constraints (see

MediaStreamConstraints) given as input.

Method

NavigatorUserMediaSuccessCallback

Application-settable to a function/method that accepts a

MediaStream as a parameter. Used by

NavigatorUserMedia.getUserMedia().

Callback

81

Lampiran B. Hasil Unit Testing

Nama Kelas Hasil

Initiator 100% passed.

Media 100% passed.

Main 100% passed.

OneToOne (implements Peer) 100% passed.

OneToMany (implements Peer) 100% passed.

ManyToMany (implements Peer) 100% passed.

82

Lampiran C. Sequence Diagram

Gambar C-1. Offer Sequence Diagram

83

Gambar C-2. Answer Sequence Diagram

laporanta 13510024 nicholas rio

Documents