MOBILE LIVE VIDEO STREAMING PADA ANDROID DENGAN MENGGUNAKAN RTMP DAN FLASH LITE 4

SEMINAR TUGAS AKHIR PERIODE JANUARI 2011

1 Nanang Andri Hidayat ‐ 5106100129

MOBILE LIVE VIDEO STREAMING PADA ANDROID DENGAN MENGGUNAKAN RTMP DAN FLASH LITE 4

Nanang Andri Hidayat – Ary Mazharuddin Shiddiqi, S.Kom, M.Comp.Sc Jurusan Teknik Informatika

Fakultas Teknologi Informasi Institut Teknologi Sepuluh Nopember

Jl. Raya ITS - Gedung Teknik Informatika ITS Surabaya 60111 Telp : +62 (031)5939214, Fax : +62 (031)5913804

Abstrak

Pada saat ini, teknologi telekomunikasi mengalami kemajuan yang sangat pesat. Perkembangan teknologi telekomunikasi tentu tidak dapat dilepaskan dari perkembangan hardware yang memungkinkan adanya komunikasi dengan cara yang lebih modern. Salah satu teknologi telekomunikasi yang sekarang berkembang sangat pesat adalah telepon pintar (smart phone). Satu ciri perkembangan smartphone adalah kemampuan memproses datanya yang semakin meningkat. Tidak hanya digunakan untuk telekomunikasi konvensional saja, namun juga mampu menjalankan aplikasi-aplikasi yang sebelumnya tidak terpikirkan dapat berjalan di telepon genggam.

Dengan memanfaatkan fasilitas protocol streaming yang diciptakan oleh adobe untuk Flash Player, Real Time Messaging protocol, kita dapat membangun sebuah aplikasi live streaming yang mampu memutar video streaming pada smartphone.

Uji coba aplikasi ini dilakukan untuk dengan membandingkan antara video sebelum dan sesudah dipancarkan. Dari uji coba dapat disimpulkan bahwa semakin tinggi kualitas gambar, semakin besar delay. Maka untuk mendapatkan kepuasan maksimal penggunaan aplikasi, harus diatur sedemikian rupa hingga seimbang antara kualitas gambar dan delay.

Kata Kunci: Telepon pintar, Live Streaming, klien, server

1. Pendahuluan Pada era sekarang, teknologi komunikasi

berkembang sangat pesat. Salah satu teknologi yang kita sadari telah banyak ada di sekitar kita adalah banyaknya smartphone atau telepon genggam berteknologi tinggi. Smartphone ini tidak hanya mampu untuk melakukan tugas telepon genggam biasa, namun juga tugas-tugas yang biasa dilakukan oleh computer pada umumnya. Hal ini dimungkinkan karena prosesor berteknologi tinggi yang ditanamkan ke dalam smartphone tersebut.

Kelebihan inilah yang coba dimanfaatkan untuk membangun sebuah aplikasi yang tidak dapat

dibangun untuk telepon genggam biasa. Aplikasi ini adalah sebuah aplikasi client/server yang memungkinkan dilakukannya live video streaming secara mobile.

Mobile live video streaming adalah sebuah teknologi aplikasi yang memungkinkan pengguna mengakses layanan video streaming yang disediakan server streaming langsung melalui Handset Smartphone-nya. Penerapan teknologi mobile live video streaming dapat diaplikasikan secara luas. Contohnya adalah, dengan pengembangan lebih lanjut dapat dikembangkan menjadi sebuah web conferencing via Handset Smartphone dan PC biasa yang tersambung ke dalam jaringan. 2. Dasar Teori 2.1. Java

Java adalah bahasa pemrograman berbasis objek. Kelebihan utama dari Java ialah dapat dijalankan di beberapa platform / sistem operasi komputer, sesuai dengan prinsip tulis sekali, jalankan di mana saja. Dengan kelebihan ini pemrogram cukup menulis sebuah program Java dan dikompilasi (diubah, dari bahasa yang dimengerti manusia menjadi bahasa mesin / bytecode) sekali lalu hasilnya dapat dijalankan di atas beberapa platform tanpa perubahan.

2.2. ActionScript

ActionScript adalah bahasa pemrograman berorientasi objek yang pada mulanya dikembangkan oleh Macromedia .Inc. yang sekarang dimiliki oleh Adobe System. ActionScript berdialek ECMAScript (yang berarti ActionScript mempunyai sintaksis dan semantic yang sama dengan JavaScript yang lebih terkenal), dan digunakan utamanya untuk pembangunan website dan aplikasi yang menarget platform Adobe Flash Player, yang digunakan halaman web dalam bentuk file .swf yang ditanam didalamnya. ActionScript sendiri adalah open‐source yang maksudnya adalah spesifikasi‐spesifikasi didalamnya adalah tidak berbayar dan juga tersedia compiler tidak berbayar (menjadi



salah satu bagian Adobe Flex) dan virtual machine tidak berbayar (Mozilla Tamarin).

2.3. Flash Lite 4

Flash Lite 4 adalah versi ActionScript 3.0 yang disesuaikan dengan keterbatasan perangkat mobile. Oleh karena itu, ada beberapa fitur ActionScript 3.0 yang tidak diperlukan pada Flash Lite 4, dan sengaja untuk dihilangkan atau hanya didukung hanya sebagian fiturnya.

2.4. Video Streaming

Video streaming adalah suatu teknologi yang mampu mengirimkan file berupa video secara on-demand maupun real time pada jaringan Internet maupun Intranet. Video Streaming dapat dimainkan ketika file video sedang ditransfer. Video Streaming juga menawarkan user control pada saat stream (ketika file dimainkan).

2.5. Protokol RTMP

RTMP (Real Time Messaging Protocol) adalah sebuah protokol yang dipakai oleh Flash Player untuk mengirimkan objek secara real time, video dan audio ke klien menggunakan koneksi binary TCP atau polling HTTP tunnel. Protokol tersebut adalah sebuah container untuk membungkus data yang mungkin berbentuk AMF, atau audio/video mentah seperti ditemukan pada format video FLV.

3. Perancangan Perangkat Lunak

Berikut akan dijelaskan rancangan perangkat lunak.

3.1. Deskripsi Umum Sistem

Dalam tugas akhir ini, dibangun sebuah

aplikasi yang bernama MobileLiveStream. Aplikasi ini digunakan untuk menampilkan video live streaming dan berjalan pada perangkat mobile dengan spesifikasi minimal harus mendukung Flash Player 10 atau Flash Lite 4. Untuk dapat memutar video live streaming ini, maka klien harus dapat terhubung ke sebuah server live streaming yang berfungsi sebagai penghubung antara broadcaster dan klien penerima. Video streaming menggunakan konsep live streaming dimana video direkam dan disaksikan secara real time. Protokol yang digunakan dalam live streaming ini adalah RTMP. Konsep klien-server yang digunakan adalah sebagai berikut :

Broadcaster : Sebuah device yang memiliki kamera yang digunakan untuk merekam video yang kemudian dipancarkan ke server. Dalam kasus ini,

broadcaster adalah PC berkamera yang didalamnya dijalankan aplikasi pemancar video.

Server : Sebuah PC yang bertugas sebagai server streaming. Client : Sebuah perangkat mobile yang

dapat memutar file Flash.

3.2 Arsitektur Umum Sistem

Aplikasi MobileLiveStream ini dapat terjadi dengan perantara wireless LAN. Berdasarkan Gambar 3.1, pertama kali broadcaster akan merekam gambar yang ditangkap oleh kamera secara berkala. Setelah itu, broadcaster akan melakukan koneksi ke server streaming dengan melakukan proses RTMP handshaking dan menyepakati versi protokol yang akan dipakai. Setelah proses handshaking selesai dan komunikasi telah tercapai, maka akan dilanjutkan dengan mengirim paket-paket RTMP dari broadcaster ke server streaming.

Setelah meneima paket-paket dari broadcaster, server akan menunggu klien yang akan berkomunikasi dengannya. Ketika ada paket handshaking dari klien, dan kemudian server membalas dan terjadi komunikasi, secara berkala server akan mengirimkan paket-paket RTMP secara berkala kepada klien.

3.3 Perancangan Proses

3.3.1 Proses Pengiriman Video dari Broadcaster ke Server

Proses ini dilakukan oleh broadcaster untuk mengirimkan video yang ditangkap oleh kamera ke server. Proses ini diawali dengan inisialisasi koneksi, apabila berhasil terhubung dengan server, maka broadcaster akan menginisialisasi stream yang kemudian mem-publish videonya menggunakan stream tersebut. Gambar 3.2 menggambarkan proses tersebut.

Gambar 3.1 Arsitektur Umum Sistem



Gambar 3.2 Flowchart proses pengiriman video

dari Broadcaster ke Server

3.3.2 Proses Pembuatan Scope Aplikasi Server

Gambar 3.3 Flowchart proses pembuatan scope aplikasi server

Scope pada aplikasi server Red5 bisa diibaratkan dengan Room yaitu sebuah abstraksi hierarki dimana klien bisa terhubung dengan aplikasi server tersebut. Ketika pertama kali aplikasi dipanggil, aplikasi akan membuat scope tersebut. Namun ketika permintaan akan aplikasi

ini tidak ada, maka aplikasi akan dimatikan. Gambar 3.3 menjelaskan proses tersebut.

3.3.3 Proses Koneksi Client ke Aplikasi Server

Gambar 3.4 (a) Flowchart proses koneksi client ke aplikasi server. (b) Flowchart proses pemutusan koneksi client ke aplikasi server

Gambar 3.4 (a) menggambarkan proses ini. Ketika aplikasi klien ingin terhubung dengan server, ia akan terhubung dengan scope sebuah aplikasi server. Klien diharuskan menggunakan parameter koneksi yang benar untuk dihubungkan dengan scope yang benar.

3.3.4 Proses Pemutusan Koneksi Client ke Aplikasi Server

Proses pemutusan koneksi klien ke server dilakukan atas permintaan aplikasi broadcaster. Ketika klien meminta untuk pemutusan koneksi, maka server pertama kali mengecek apakah scope yang ingin ditinggalkan merupakan scope yang benar. Jika ya, maka akan dipastikan lagi apakah serverStream sedang berjalan. Jika ya, maka koneksi akan diputus, jika tidak, berarti klien telah terputus dari koneksi. Proses ini ditunjukkan flowchart pada Gambar 3.4 (b).

(a) (b)



3.3.5 Proses Request dan Penayangan Video

Gambar 3.5 Flowchart proses request dan

penayangan video

Proses ini dilakukan oleh klien untuk mendapatkan data stream dari server. Setelah terkoneksi dengan server, klien dapat mulai menerima data stream gambar dan menayangkannya. Selengkapnya dapat dilihat pada Gambar 3.5.

3.4 Perancangan Antar Muka perangkat Lunak

Gambar 3.6 Gambar rancangan antar muka

3.4.1 Perancangan Antar Muka Broadcaster

Antarmuka broadcaster yang ditunjukkan pada Gambar 3.6 (a) akan menampilkan video yang sedang ditangkap oleh kamera yang digunakan broadcaster. Kemudian terdapat dua tombol broadcast untuk mulai mengirimkan data stream ke server, dan stop untuk menghentikan pengiriman data stream tersebut.

3.4.2 Perancangan Antar Muka Klien

Antarmuka Klien yang ditunjukkan pada Gambar 3.6 (b) akan menampilkan video yang

dikirimkan oleh broadcaster. Terdapat dua tombol yaitu subscribe yang jika ditekan, klien akan mulai memainkan video live streamingnya, dan stop yang ketika ditekan akan menghentikan klien dari memainkan video tersebut.

4. Uji Coba Semua fitur dalam aplikasi ini berhasil dilakukan. Berikut hasil ujicoba yang dilakukan beserta kesimpulan hasil yang didapatkan.

4.1. Uji Coba Fungsionalitas

Uji coba fungsionalitas dilakukan untuk melihat apakah fungsi-fungsi dasar aplikasi berjalan sebagaimana mestinya. Hasil uji coba ditunjukkan dengan hasil screen shot Flash Player ada pada Gambar 5.1.

Gambar 4.1 Gambar ujicoba klien

4.2. Kualitas vs Delay Uji coba performa ini dilakukan untuk

melihat pengaruh beberapa perubahan parameter kualitas terhadap performa sistem. Performa sistem bisa dilihat dari besarnya delay yang terjadi akibat perubahan beberapa parameter dalam skenario. Delay diukur dengan menghitung jeda selisih waktu ketika broadcaster dan klien memainkan playhead yang sama. Sedangkan parameter-parameter kualitas adalah frame rate dan kualitas gambar dalam persen.

Broadcaster terhubung dengan jaringan lokal melalui WiFi dengan kekuatan sinyal 95 persen. Sedangkan klien terhubung ke jaringan lokal melalui WiFi dengan kekuatan sinyal 82 persen. Hal ini bertujuan untuk memudahkan pengukuran delay.

4.2.1 Skenario 1

Pada skenario ini, ujicoba dilakukan dengan menggunakan parameter kualitas yang diset tetap pada 100 persen, sedangkan parameter frame rate diubah bergantian pada 100, 70, dan 50 frame



per second. Playhead adalah progress klien atau broadcaster dalam memainkan videonya.

Tabel 4.1 Tabel Skenario 1 Framerate 100

Posisi Playhead (Menit)

Waktu Play broadcaster

Waktu Play klien

1 0:32:46 0:32:48 2 0:33:47 0:33:48 3 0:34:47 0:34:47 4 0:35:46 0:35:49 5 0:36:47 0:36:47 6 0:37:47 0:37:49 7 0:38:47 0:38:50 8 0:39:47 0:39:47 9 0:40:47 0:40:47 10 0:41:47 0:41:53

Dari Tabel 4.1, dapat dihitung rata-rata delay yang terjadi adalah 1,7 detik. Dengan demikian delay yang terjadi tidak terlalu signifikan.




Waktu Play klien

1 4:23:29 4:23:30 2 4:24:30 4:24:30 3 4:25:29 4:25:304 4:26:29 4:26:30 5 4:27:29 4:27:30 6 4:28:29 4:28:307 4:29:29 4:29:30 8 4:30:29 4:30:30 9 4:31:29 4:31:30 10 4:32:29 4:32:30

Dari tabel 4.2, dapat dihitung rata-rata delay yang terjadi adalah 0,9 detik. Dengan demikian delay yang terjadi tidak terlalu signifikan.




Waktu Play klien

1 3:52:54 3:52:54 2 3:53:54 3:53:54 3 3:54:54 3:54:54 4 3:55:54 3:55:54 5 3:56:54 3:56:55 6 3:57:54 3:57:54 7 3:58:54 3:58:54 8 3:59:54 3:59:54 9 4:0:54 4:0:54 10 4:1:54 4:1:54

Dari tabel 4.3, dapat dihitung rata-rata delay yang terjadi adalah 0,1 detik. Dengan demikian delay yang terjadi cukup signifikan.

4.2.1 Skenario2

Pada skenario ini, ujicoba dilakukan dengan menggunakan parameter kualitas yang diset tetap pada 70 persen, sedangkan parameter frame rate diubah bergantian pada 100, 70, dan 50 frame per second.




Waktu Play klien

1 23:18:27 23:18:27 2 23:19:27 23:19:28 3 23:20:27 23:20:27 4 23:21:27 23:21:28 5 23:22:27 23:22:27 6 23:23:27 23:23:29 7 23:24:27 23:24:31 8 23:25:27 23:25:319 23:26:27 23:26:30 10 23:27:27 23:27:28

Dari tabel 4.4, dapat dihitung rata-rata delay yang terjadi adalah 1,6 detik. Dengan demikian delay yang terjadi tidak terlalu signifikan




Waktu Play klien

1 4:7:12 4:7:13 2 4:8:13 4:8:13 3 4:9:12 4:9:13 4 4:10:13 4:10:13 5 4:11:12 4:11:13 6 4:12:12 4:12:13 7 4:13:13 4:13:14 8 4:14:13 4:14:14 9 4:15:12 4:15:13

10 4:16:13 4:16:14 Dari tabel 4.5, dapat dihitung rata-rata

delay yang terjadi adalah 0,9 detik. Dengan demikian delay yang terjadi tidak terlalu signifikan.




Waktu Play klien

1 23:51:53 23:51:53 2 23:52:53 23:52:533 23:53:53 23:53:53 4 23:54:54 23:54:54 5 23:55:54 23:55:546 23:56:53 23:56:53 7 23:57:53 23:57:53 8 23:58:54 23:58:549 23:59:54 23:59:55 10 0:0:53 0:0:54



Dari Tabel 5.6, dapat dihitung rata-rata delay yang terjadi adalah 0,1 detik. Dengan demikian delay yang terjadi tidak terlalu signifikan.

4.2.1 Skenario 3

Pada skenario ini, ujicoba dilakukan dengan menggunakan parameter kualitas yang diset tetap pada 50 persen, sedangkan parameter frame rate diubah bergantian pada 100, 70, dan 50 frame per second.




Waktu Play klien

1 23:36:15 23:36:16 2 23:37:15 23:37:163 23:38:15 23:38:16 4 23:39:15 23:39:16 5 23:40:15 23:40:166 23:41:16 23:41:16 7 23:42:15 23:42:16 8 23:43:15 23:43:16 9 23:44:15 23:44:17 10 23:45:15 23:45:16

Dari tabel 4.7, dapat dihitung rata-rata delay yang terjadi adalah 1 detik. Dengan demikian delay yang terjadi tidak terlalu signifikan.




Waktu Play klien

1 4:46:32 4:46:32 2 4:47:32 4:47:32 3 4:48:32 4:48:32 4 4:49:31 4:49:32 5 4:50:32 4:50:32 6 4:51:32 4:51:32 7 4:52:31 4:52:32 8 4:53:31 4:53:32 9 4:54:32 4:54:32 10 4:55:32 4:55:32

Dari Tabel 4.8, dapat dihitung rata-rata delay yang terjadi adalah 0,3 detik. Dengan demikian delay yang terjadi tidak terlalu signifikan

Dari tabel 4.9, dapat dihitung rata-rata delay yang terjadi adalah 0,1 detik. Dengan demikian delay yang terjadi tidak terlalu signifikan. Dari ketiga skenario percobaan diatas dapat disimpulkan dengan grafik pada Gambar 4.2.




Waktu Play klien

1 5:1:9 5:1:9 2 5:2:9 5:2:9 3 5:3:9 5:3:9 4 5:4:9 5:4:10 5 5:5:9 5:5:9 6 5:6:9 5:6:9 7 5:7:9 5:7:98 5:8:9 5:8:9 9 5:9:9 5:9:9 10 5:10:9 5:10:9

Gambar 4.2 Grafik hasil Uji Coba

Dari ketiga percobaan diatas dapat diambil kesimpulan bahwa semakin besar frame rate dan kualitas, maka akan terjadi delay yang semakin lama. Namun bila mengurangi terlalu banyak frame rate dan kualitas, maka manfaat yang dapat diambil pun tidak dapat maksimal. Maka berdasarkan percobaan, frame rate dan kualitas yang tidak menimbulkan terlalu banyak delay, namun juga tidak terlalu mengorbankan kualitas. Yaitu dengan frame rate 70 dan kualitas 70 persen.

5. Kesimpulan Dari hasil pengamatan selama perancangan, implementasi dan proses uji coba perangkat lunak yang dilakukan, dapat diambil kesimpulan sebagai berikut :

1. Kita dapat membangun aplikasi mobile live streaming dengan memenuhi beberapa hal, yaitu handset yang mempunyai kemampuan pendukung yang cukup, jaringan WiFi yang kuat, serta server yang mampu menangani protokol yang dapat dipakai oleh baik pihak pemancar maupun penerima.

2. Server streaming dapat terhubung dengan klien dengan protokol RTMP dilakukan dengan cara inisialisasi koneksi dan



pembuatan objek stream yang digunakan sebagai kendaraan data untuk menyeberangi media koneksi.

3. PC yang terhubung ke server streaming, dapat mengirimkan data stream video dengan menggunakan objek stream yang dikirimkan melalui koneksi yang telah dibuat sebelumnya..

6. Daftar Pustaka

[1] [1] Gong Steven, Gregoire Paul, Rossi Daniel, 2009, Red5 Open Source Flash Server Reference Documentation – version 0.8, Red5 Open Source Flash Server.

[2] Adobe System Incorporated, 2010, Developing Flash Lite 4 Applications

[3] Adobe System Incorporated, 2009, RTMP Specification License

[4] http://www.adobe.com/livedocs/flash/9.0/ActionScriptLangRefV3/flash/ tentang dokumentasi dan contoh ActionScript 3.0, diakses tanggal 15 Desember 2010

[5] http://red5.org/wiki/Documentation tentang dokumentasi server Red5, diakses tanggal 20 Nopember 2010.

[6] Pratama, Henry (2010). Video Streaming Pada Mobile Phone Berbasis Symbian OS Melalui WLAN Dengan Menggunakan Mobile Media API (MMAPI),Tugas Akhir, Jurusan Teknik Informatika, Fakultas Teknologi Informasi ITS, Surabaya

MOBILE LIVE VIDEO STREAMING PADA ANDROID DENGAN MENGGUNAKAN RTMP DAN FLASH LITE 4

Education

Transcript of MOBILE LIVE VIDEO STREAMING PADA ANDROID DENGAN MENGGUNAKAN RTMP DAN FLASH LITE 4