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

1. 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

2. SEMINAR TUGAS AKHIR PERIODE JANUARI 2011
2 Nanang Andri Hidayat ‐ 5106100129
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

3. SEMINAR TUGAS AKHIR PERIODE JANUARI 2011
3 Nanang Andri Hidayat ‐ 5106100129
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)

4. SEMINAR TUGAS AKHIR PERIODE JANUARI 2011
4 Nanang Andri Hidayat ‐ 5106100129
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

5. SEMINAR TUGAS AKHIR PERIODE JANUARI 2011
5 Nanang Andri Hidayat ‐ 5106100129
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.
Tabel 4.2 Tabel Skenario 1 Framerate 70
Posisi
Playhead
(Menit)
Waktu Play
broadcaster
Waktu Play
klien
1 4:23:29 4:23:30
2 4:24:30 4:24:30
3 4:25:29 4:25:30
4 4:26:29 4:26:30
5 4:27:29 4:27:30
6 4:28:29 4:28:30
7 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.
Tabel 4.3 Tabel Skenario 1 Framerate 50
Posisi
Playhead
(Menit)
Waktu Play
broadcaster
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.
Tabel 4.4 Tabel Skenario 2 Framerate 100
Posisi
Playhead
(Menit)
Waktu Play
broadcaster
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:31
9 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
Tabel 4.5 Tabel Skenario 2 Framerate 70
Posisi
Playhead
(Menit)
Waktu Play
broadcaster
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.
Tabel 4.6 Tabel Skenario 2 Framerate 50
Posisi
Playhead
(Menit)
Waktu Play
broadcaster
Waktu Play
klien
1 23:51:53 23:51:53
2 23:52:53 23:52:53
3 23:53:53 23:53:53
4 23:54:54 23:54:54
5 23:55:54 23:55:54
6 23:56:53 23:56:53
7 23:57:53 23:57:53
8 23:58:54 23:58:54
9 23:59:54 23:59:55
10 0:0:53 0:0:54

6. SEMINAR TUGAS AKHIR PERIODE JANUARI 2011
6 Nanang Andri Hidayat ‐ 5106100129
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.
Tabel 4.7 Tabel Skenario 3 Framerate 100
Posisi
Playhead
(Menit)
Waktu Play
broadcaster
Waktu Play
klien
1 23:36:15 23:36:16
2 23:37:15 23:37:16
3 23:38:15 23:38:16
4 23:39:15 23:39:16
5 23:40:15 23:40:16
6 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.
Tabel 4.8 Tabel Skenario 3 Framerate 70
Posisi
Playhead
(Menit)
Waktu Play
broadcaster
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.
Tabel 4.9 Tabel Skenario 3 Framerate 50
Posisi
Playhead
(Menit)
Waktu Play
broadcaster
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:9
8 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

7. SEMINAR TUGAS AKHIR PERIODE JANUARI 2011
7 Nanang Andri Hidayat ‐ 5106100129
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