Sebuah presentasi yang merangkum berbagai portofolio kami terkait Image/Video Processing dan Analytics. Ada banyak aspek yang dibahas dan semoga semua ini dapat memberikan insight/pembelajaran bagi yang akan terjun ke dunia image/video processing secara online/cloud

1. Cloud Service Design
for Computer Vision,
Image/Video Processing & Analytics
By Dony Riyanto
Telegram: @donyriyanto
Web: slideshare.net/DonyRiyanto
June 2021

2. Problem Statement
• Pengantar
• Saat ini teknologi, metode, software, produk & layanan AI sedang berkembang pesat.
• Demikian juga dengan Cloud Computing, Big Data, IoT, dsb.
• Big Four sudah menyediakan dan mengintegrasikan layanan AI, khususnya computer vision seperti: AWS
Rekognition, Google Vision, Azure Cognitive, Aliyun Image Search/Video AI /ApsaraVideo
• Produk AIoT/Edge Computing semakin banyak. Hardware module/library/firmware semakin berkembang.
• Kami sudah biasa mengembangkan solusi microcontroller, IoT, drone, hardware integration, web service,
microservices, API, aplikasi bisnis dan layanan mobile.
• Namun kami melihat masih banyak kebutuhan pasar/niche market yang belum terpenuhi terkait dengan
layanan cloud untuk image/video processing & analytics.
• Pernyataan Permasalahan
Kami menemukan bahwa, mendesain layanan web (web service) AI, khususnya untuk pemrosesan dan analisa
image/video, ternyata memiliki tingkat kerumitan dan tantangan yang tinggi:
• Apa saja kemungkinan pola/arsitektur/topologi yang tersedia dan dapat dikembangkan lebih lanjut untuk
memenuhi kebutuhan pasar tersebut?
• Apa saja kendala/kekurangan/kelebihan/solusi dari masing-masing pola/arsitektur tersebut?

3. Contoh Kasus
Pembahasan saya mulai dengan beberapa contoh kasus yang saling
terkait. Hal ini agar kita dapat membayangkan bagaimana situasi/
masalah yang dihadapi dilapangan terkait dengan pemrosesan image
dan video. Berikut ini beberapa contoh kasus yang pernah kami alami
dalam proyek maupun eksperimen pribadi:
A. Web CCTV Stasiun KAI
B. Drone Video Surveillance Streaming
C. Customer Behavior Video Analytics
D. Face Recognition for Unbank Fintech Service
E. Mobile Phone Game Streaming

4. Case Study A: Web CCTV Stasiun KAI
Latar Belakang:
Semua stasiun KAI (antar kota) sudah terpasang kamera CCTV dan DVR, serta memiliki koneksi internet dari Telkom.
Setiap masa Musik dan Nataru, kemenhub mempersiapkan: web monitoring, tampilan CCTV di media center, serta
dashboard utama di kantor pusat. Sebelumnya sudah ada sistem tersebut, yaitu dengan menggunakan DVR
merek/jenis tertentu, aplikasi NVR opensource (Linux) Zoneminder, sebuah aplikasi custom yg menggunakan SDK
Zoneminder lalu dijalankan secara terjadwal (task scheduling) untuk membuat potongan video pendek per sekian
menit dari masing-masing kamera.
Permasalahan:
• Merek/jenis DVR yang lama sudah lagi di produksi, sedangkan DVR seri terbaru (merek yang sama) ternyata
menggunakan firmware yang berbeda dari sebelumnya dan tidak lagi dapat terbaca oleh aplikasi lama/Zoneminder.
Sempat coba berganti merek, kondisinya sama. Padahal DVR DVR tersebut sudah terlanjut terpasang di berbagai
stasiun. Software developer outsourcing lama sudah tidak mau handle (diduga sebelumnya pun proyek ini banyak
mengalami kendala/tidak smooth). Sementara pada saat kami mendapatkan pekerjaan ini waktunya sudah angat
mepet dengan hari H (kurang dari 1 bulan).

5. Kondisi/Fakta
Kondisi/fakta yang kami temukan:
• Semua DVR yang terpasang masih bisa dibaca dengan menggunakan aplikasi bawaan dari
merek/jenis DVR tsb. Tetapi jadi harus pakai 2 aplikasi berbeda: utk DVR type lama menggunakan
aplikasi NVR A, sementara untuk DVR baru menggunakan aplikasi NVR B.
• Sangat minim (tidak ada) dokumentasi teknis dan library yang open source yang mendukung
merek/type DVR tersebut.
• Kami sudah mengetahui bahwa DVR tersebut bisa diakses dengan protocol RTSP, tetapi untuk bisa
mengakses channel (masing-masing cam) dibutuhkan data-data pendukung lain seperti: port, URL
path, auth (username & password).
• Secara prinsip sebetulnya bisa saja dilakukan dengan cara 'hack', misalnya dengan teknis reverse
engineering, packet capture, trial error dengan produk yg mirip, dsb. Tapi dengan kondisi mini
dokumentasi baik dari tim teknis lama maupun dari vendor, dan waktu yang sangat terbatas, kami
memutuskan utk 'work around'

6. Contoh Daftar URL Cam/DVR
Merek Avtech
Merek Hikvision

7. Solusi
Solusi awal:
• Kami membuat aplikasi desktop (windows), menggunakan VB6 untuk
secara bergantian running aplikasi NVR dan capture screen secara
berkala lalu, dilakukan pemotongan gambar per channel dan masing-
masing rangkaian image yang sdh di-capture, di konversi menjadi
format video (mp4). Kemudian otomatis di upload ke web server,
sehingga bisa diakses masyarakat luas/wartawan yang berada di
media center.
• Sementara untuk dashboard utama tetap menggunakan aplikasi
bawaan dari masing2 merek/type DVR

8. Hasil
Hasil dari pelaksanaan pekerjaan pertama tersebut:
• Tentu sesuai dugaan, hasil video kurang optimal, karena: resolusi
rendah, jeda waktu yang panjang (karena prosesnya harus
bergantian/bertahap. Dalam satu layar maksimal hanya 16 tampilan
kamera), dan video tidak lancar secara intermitten karena pada saat2
tertentu proses capture layar terjadi perlambatan (lag).
• Namun sebelum hari-H sudah dapat ditampilkan semua channel dari
semua stasiun KA.

9. Topologi DAOP 1
Stasiun A
Stasiun B
Stasiun C
DAOP 2
Stasiun D
Stasiun E
Perlintasan F
DAOP n
Gedung Kemenhub
Media Center
Data Centre
Vendor/
Technical

10. Alur Proses
Cam 1
Cam 2
cam1.mp4
cam2.mp4
Scheduled:
• Screenshot
• Image crop
Convert to mp4
using FFMPEG tool
CCTV NVR/CMS app (Windows)

11. Cuplikan Tampilan Web CCTV Stasiun

12. Topologi (Dengan Data Flow)
Data Centre
Dashboard Utama Kemenhub
Media Centre
Masyarakat / Netizen
Vendor/
Technical
Analog
IP. High Payload
IP. Low Payload

13. Topologi (Dalam konteks Kemenhub yang lebih besar/bersamaan)
Data Centre
Kemenhub
Kapasitas Backbone
Internet Terbatas /
High Concurrency
Realtime Traffic
Monitoring Centre
Direktorat Darat
Direktorat Laut
Direktorat Udara
Bandara
Stasiun KA
Terminal Bis
Jalan Raya
Jalan Tol

14. Masalah
Masalah tak terduga datang pada hari H:
• Momentum penyelenggaraan Media Centre untuk wartawan dan
akses web publik di launching bersamaan saat operasi Mudik dan
Nataru
• Antar direktorat dan unit kurang koordinasi.
• Punya vendor sendiri-sendiri.
• Capacity-planning tidak dijalankan tim IT internal dengan seksama.
• Website tidak bisa diakses publik. Wartawan kesulitan untuk
akses/download cuplikan video untuk materi liputan. Dashboard
utama untuk pejabat kemenhub tampilannya tersendat/putus
sambung.

15. Mengapa bisa Terjadi?
Jika lingkupnya kita kecilkan kembali pada stasiun KAI. Maka dapat di analisa
awal sebagai berikut:
• Jumlah DVR sangat banyak. 9 DAOP. 145 kamera yang terhubung. Tiap DVR
menyalurkan 4 sampai 8 camera (belum termasuk IP cam pada beberapa
persimpangan rawan). Per DVR, untuk tiap NVR yang terkoneksi, mengirimkan
stream video Full HD H.264. Perkiraan dibutuhkan 15-30 Mbps/DVR. Sehingga
untuk monitoring KAI saja, dibutuhkan 2-4.4Gbps. Dengan 3 NVR utama yang
mengakses rutin secara bersamaan, maka angkanya dikali 3. Kemudian
ditambah dengan kebutuhan streaming untuk moda transportasi darat lain,
direktorat laut, direktorat udara, website dan aplikasi kementerian lainnya.
• Resolusi dan fps rate dari masing-masing DRV yang mengirimkan streaming
H.264 via RTSP tersebut, tidak bisa dikurangi karena setting bawaan. Kalaupun
bisa, pilihannya hanya turun sedikit sekali.
• Banyaknya NVR disini jelas menjadi salah satu faktor penentu yang krusial

16. Usulan
Kami mengajukan usulan solusi untuk pekerjaan selanjutnya:
• NVR utama cukup 1. NVR lain yang diperbolehkan maks 1 dan tidak dipakai
terus menerus (hanya untuk situasi emergency/maintenance)
• Streaming harus di push dulu ke VPS/Cloud diluar data center, yang memiliki
kapasitas dan backbone yang lebih baik. Baru kemudian video di proses ulang
dan disimpan dengan beberapa opsi resolusi/fps. Kategori tinggi (high res,
higher fps, durasi clip lebih panjang, jeda lebih pendek) untuk dipakai pada
dashboard utama. Sementara kategori yang lebih rendah (lower res, lower fps,
durasi clip lebih pendek, jeda antar clip lebih panjang), dipakai untuk pelayan
publik dan media centre.
• Video untuk public dan media center mesti didistribusikan menggunakan CDN
dan memiliki cache. Juga di proses dengan codec yang secara natif didukung
oleh web (HTML5)

17. Diagram Usulan
Masing-masing DAOP
Stasiun D
Stasiun E
Perlintasan F
Masyarakat / Netizen
Data Centre
Kemenhub
Cloud Server Provider
Main Dashboard
Media Centre

18. Diagram Usulan
Masyarakat / Netizen
Vendor/Technical
only for emergency
RTSP H.264
full HD
mp4 scheduled
file transfer
HTTP Live Streaming (HLS)
Cloud Server Provider
With video processing
features
High Internet
Backbone
Limited Internet
Backbone
Data Centre
Kemenhub
Media Centre Main Dashboard

19. Permasalahan
Para tahun berikutnya, usulan baru ini diajukan dan mulai
diperhitungkan:
• Mencari calon cloud server provider
• Meminta perkiraan biaya dan solusi
Namun ternyata timbul masalah baru:
• Tidak ada/sangat sedikit provider cloud di Indonesia yang
menyediakan fitur Video Processing (hanya ada Alibaba Cloud
Indonesia)
• Harganya melebihi budget. Sehingga tidak bisa dilaksanakan.

20. Perubahan Usulan
Masyarakat / Netizen
Vendor/Technical
only for emergency
RTSP H.264
full HD
Video
Process
HTTP Live Streaming (HLS)
Limited Internet
Backbone
Data Centre Kemenhub
Media Centre Main Dashboard
Shinobi CCTV/NVR

21. Perubahan Usulan
RTSP H.264
full HD
• Connect & read RTSP source
• Caching
• Restream as HLS
Masyarakat / Netizen
HTTP Live
Streaming (HLS)
Media Centre
Main Dashboard

22. NVR Shinobi
• Relatif baru (pada saat itu)
• Dibuat dengan tech-stack modern:
• menggunakan nodejs,
• source code dapat di akses melalui github,
• miliki web console,
• mendukung berbagai protokol streaming/codec baru seperti HLS/mp4,
• memiliki sistem authentifikasi yang lebih baik,
• masih aktif berkembang
• Namun belum pernah di uji performanya untuk ratusan kamera
https://github.com/ShinobiCCTV

23. Hasil
Solusi terakhir ini sudah jauh lebih baik dari pada eksekusi pekerjaan
sebelumnya:
• Arsitekturnya lebih simple
• Instalasi dan settingnya lebih mudah
• Dapat langsung diakses lewat web console
• Untuk akses publik web Kemenhub cukup mengakses URL dari
masing2 kanal URL kamera di Shinobi.

24. Permasalahan
Namun solusi ini masih meninggalkan pemasalahan baru:
• Node JS mengusung single thread. Namun hal ini masih bisa kami atasi dengan membuat
beberapa instance Shinobi dan multi process, sehingga okupansi server bisa lebih
berimbang/optimal
• Namun Node JS tetap membutuhkan resource server yang sangat besar seperti layaknya bahasa
interpreter lainnya (hampir seluruh CPU dan Memory penuh. Jauh lebih besar dibandingkan solusi
sebelumnya/atau saat menggunakan Zoneminder)
• Internet backbone masih terbatas. Walaupun jumlah trafficnya sudah ditekan jauh (1/3 dari
eksekusi sebelumnya), tapi jelas dibutuhkan peningkatan kapasitas bandwidth untuk memenuhi
keseluruhan kebutuhan data centre.
• Solusi alternatif lain adalah: dipasang mini pc/SBC pada tiap stasiun (dihubungkan dngan DVR)
dan dipasang aplikasi video processing (misalnya Shinobi) utk memproses video langsung
ditempat sehingga menghasilkan file mp4 dengan ukuran yang lebih kecil, lalu di push ke web
server. Sehingga beban kerja server dapat ditenak jauh.

25. Alternatif Solusi
Masyarakat / Netizen
Vendor/Technical
only for emergency
LAN RTSP
H.264 full HD
HTTP Live Streaming (HLS)
Limited Internet
Backbone
Data Centre Kemenhub
Media Centre Main Dashboard
LAN RTSP
H.264 full HD MP4 File
Transfer

26. Case Study B: Drone Video Surveillance Streaming
Kondisi:
• KLHK (kementerian) membutuhkan solusi surveillance realtime di
wilayah pelosok tertentu/pada waktu yang tertentu, secara live, untuk
keperluan penyidikan.
• Ada vendor drone di Indonesia yang membawa solusi/merek drone
dari luar negeri, jenis VTOL dan sudah dilengkapi dengan kemampuan
video streaming surveillance
• Demo ujicoba akan dilakukan di 2 wilayah di Indonesia Timur (remote
site). Visual ditampilkan di kantor pusat Jakarta.
• Unit drone, ground control station, surveillance camera, dan 3 teknisi
pabrikan sudah berada di Jakarta.

27. Permasalahan
• H-2 ditemukan masalah untuk memproses video streaming.
Requirement dari perangkat drone ini membutuhkan modul
tambahan khusus untuk streaming yang tidak terbawa ke Indonesia,
dan itupun harus menggunakan layanan cloud video processing
Aliyun, yang pada saat itu fitur tersebut belum bisa diakses dari
Indonesia.
• Waktu keberangkatan sudah sangat mepet (kurang dari 24 jam).

28. Solusi
• Saya diminta untuk membantu memecahkan masalah
• Alternatif pertama, mereka install OBS (Open Broadcaster Software)
pada ground control, lalu screen desktop akan di-streaming ke server
RTMP (OBS hanya bisa untuk streaming dengan protocol RTMP).
Namun jangan menggunakan server RTMP publik seperti Youtube,
Twitch, dsb (karena bisa dengan mudah di akses orang lain). Sore itu
kami setup server RTMP sendiri namun karena suatu hal terkendala
dan belum selesai, sementara perangkat malam itu sudah harus di
packing dan kirim kargo.
• Alternatif lain, kami menggunakan tools gratis Happytime RTSP dari
happytimesoft.com Lalu menggunakan Ngrok untuk tunelling ke IP
public. Solusi ini berjalan lancar saat didemokan malam itu dalam
area lokal

29. Topologi
RF Telemetry/
Video Transmission
3G/4G Signal
Main Dashboard
with VLC Video Player
Jakarta
Screen streaming with:
• Happytime RTSP
• Ngrok

30. Pelaksanaan hari H
Coverage sinyal provider seluler
Posisi GCS dan
launching UAV
Rencana area yang
mau diselidiki
*Ini hanya gambaran ilustrasi, bukan posisi sebenarnya
Main Dashboard
Jakarta
Pejabat / penyidik terkait
Jangkauan radio
telemetry/video

31. Permasalahan
• Kecil/ tidak ada sinyal data 3G/4G di titik GCS/peluncuran UAV. Titik tersebut dipilih
karena:
• masih dalam jangkauan radio telemetry/video dari lokasi yang akan diawasi ke GCS,
• dan lokasi yang paling memungkinkan untuk diakses dengan peralatan (tidak boleh berada
langsung di lokasi yang diawasi karena akan menggagalkan proses penyidikan).
• Sinyal masih muncul tetapi bandwith data kecil sekali, sehingga tidak memungkinkan
untuk streaming.
• Pesawat tetap diterbangkan, namun tidak streaming live ke pejabat terkait di pusat.
Sehingga pejabat/petugas pusat tidak bisa melihat langsung secara realtime dan
menentukan arah navigasi/objek pengawasan yang mau dituju (tidak bisa interaktif). Tim
lapangan kemudian merekam video secara offline, menuju kota, lalu upload video
menggunakan laptop. Jika dari hasil sementara tersebut ada yang kurang, keesokan
harinya tim bergerak lagi ke site untuk merekam video.

32. Alternatif Solusi
A. Menggunakan koneksi data satelit. Ada beberapa pilihan:
menggunakan Mobile Sattelite Service (MSS) seperti INMARSAT
BGAN portable, tetapi alatnya sangat mahal, voucher airtime-nya
juga mahal dan pendek masa expired-nya. dan kena biaya
abonemen. Overkill untuk proyek yang sifatnya insidental/tidak
rutin. Alternatif lain adalah menggunakan layanan Fix (FSS) seperti
Telkom Mangoesky. Jauh lebih murah daripada INMARSAT, namun
dibutuhkan proses pointing setiap berpidah tempat operasi.
B. Dapat terbantu jika ada terobosan image/video reconstruction
(masih berbentuk ide). Dibahas di slide selanjutnya.

33. Image/Video Reconstruction
Sumber image/video asli Image/video Analytics
horizon
wild grass
road
trees

34. Image/Video Reconstruction
GPRS Signal
Main Dashboard
Jakarta
Bandwidth
tidak stabil
Gangguan
Transmisi
RF

35. Image/Video Reconstruction
Sumber image/video asli
Data Transmitted
Image Data
Meta Data

36. Image/Video Reconstruction
Recontruction
Process
Image Data
Meta Data

37. Image/Video Reconstruction
Sumber image/video asli Hasil Rekonstruksi
horizon
wild grass
road
trees

38. Demo Sederhana NVIDIA GauGAN
http://nvidia-research-mingyuliu.com/gaugan

39. Alur Proses
Sumber image/video asli
Image data yang diterima
Meta data yang diterima
Hasil akhir rekonstruksi
GAN
1
2
Blending/
Correction/
Key Framing
Process
3
4
Sumber data lain/eksternal:
koordinat GPS, kompas, altitude,
attitude, suhu, waktu, topologi,
citra satelit, prakiraan cuaca
(BMKG), database objek/ vegetasi,
Big Data
5
Tampilkan pada dashboard
beserta meta data, hasil analisa
intelligence, status koneksi dan
object properties

40. Case Study C: Customer Behavior Video Analytics
• Kami diundang sebuah perusahaan konsultan yang sedang dalam ujicoba
membangun solusi Video Analytics untuk mendapatkan insight mengenai
customer behavior, khususnya melalui Face Recognition dan Motion Tracking,
pada Mall Kelapa Gading (MKG)
• Perusahaan tersebut sudah memiliki software developer, dan sudah
bekerjasama dengan RealNetworks (safr.com) untuk solusi aplikasi/SDK Face
Recognition (Kami kemudian didemokan menggunakan PC lokal dan wajah
kami dapat dengan cepat dan tepat dideteksi ketika masuk dalam frame
webcam)
• Namun perusahaan tersebut:
• Tidak memiliki tenaga ahli kamera
• Membutuhkan rekomendasi jenis kamera
• Serta posisi instalasi kamera yang baik dan dapat mencapai tujuan mereka

41. SAFR

42. SAFR

43. Rekomendasi kami
• Kami memiliki latar belakang/kemampuan teknis pada bidang: CCTV,
instalasi dan integrasi kamera dan aplikasinya. Namun kami belum
memiliki pengalaman khusus untuk kebutuhan Face Recognition
Video Analytics seperti yang mereka maksud.
• Lalu kami melakukan sedikir riset dan mencocokkan dengan berbagai
spec teknis dari brand/tipe kamera yang kami jual/miliki
• Berikut ini adalah rekomendasi yang kami buat pada saat itu (2018.
Mungkin sudah banyak perubahan teknologi/best practise saat ini).
Dibahas di halaman berikutnya)

44. Aspek yang Kami Pertimbangkan
Beberapa aspek yang perlu diperhatikan:
• Aspek kamera:
• Resolusi
• Zoom
• Product List
• Ketersediaan produk dan spec yang mendukung
• Jenis koneksi, topologi, kemudahan instalasi
• Luasan wilayah
• Posisi dan arah sorot kamera

52. Case Study D: Face Recognition for Unbank Fintech Service
• D (inisial) adalah sebuah aplikasi fintech yang fokus untuk
menyelesaikan permasalahan pembayaran untuk kaum marginal
(unbank/under bank). Proses bisnis utama adalah membantu
organisasi organisasi kemanusiaan dalam melaksanakan kegiatan
bansos non-tunai dalam bentuk eVoucher. Sasaran keluarga yang
dituju umumnya memiliki beberapa kendala tidak
memiliki/membawa (atau hilang) KTP atau berada dalam pengungsian.
• D menggunakan solusi Face Recognition dimana penerima bansos
cukup datang ke warung terdekat yang bekerjasama, untuk scan
wajah, memasukkan PIN dan mencairkan bantuan. Sistem ini sudah
diujicoba di lapangan lebih dari 2 tahun dan puluhan ribu penerima
bantuan di berbagai pelosok Indonesia.

53. Solusi yang digunakan
• AWS Recognition
• Untuk membantu memproses pengenalan wajah secara online
• https://konvergen.ai/
• Konvergen AI
• Untuk membantu proses verifikasi KTP
• https://konvergen.ai/

54. Alur Proses
Send Image
Return Face ID &
Other properties in JSON
Send Image
Return eKTP properties

55. Cara Membuat Layanan dengan AWS Rekognition
https://aws.amazon.com/blogs/machine-learning/build-your-own-face-recognition-service-using-amazon-rekognition/

56. Beberapa Permasalahan AWS Rekognition
• Return JSON berisi satu atau lebih Face ID berikut dengan persentasi
kemiripan, yang terdeteksi dari foto wajah yang dikirimkan. Selanjutnya kita
sendiri yang harus mencocokan dengan database aplikasi kita, data penduduk
yang bersesuaian dengan Face ID tersebut. AWS Rekoqnition tidak melakukan
liveness test.
• Return JSON tidak memberikan informasi orientasi foto. Apakah portrait atau
landscape. Ada beberapa case dimana foto yang di rekam sebelumnya, atau
foto yang akan dicocokkan, berbeda orientasi fotonya sehingga menyebabkan
salah pengenalan/tidak terdeteksi.
• Membutuhkan koneksi internet dengan bandwidth yang cukup untuk
mengirimkan foto ke cloud. Ini menjadi masalah ketika beroperasi di wilayah
yang tidak ada/kecil koneksi internetnya. Semua proses dilakukan di cloud.

57. Beberapa Permasalahan Konvergen AI
• Konvergen memiliki beberapa layanan. Salah satunya Kontext ID
untuk pengenalan KTP (tanpa di cocokkan dengan Dukcapil).
Prosesnya sangat sederhana yaitu kirim foto KTP, dan return-nya
adalah semua data yang terbaca di KTP tersebut, kecuali pas photo.
Return JSON tetap dikirimkan walaupun salah satu, ataupun sebagian
besar data tidak terbaca/dikenali. Misalnya: ada foto KTP yang NIK
nya tidak terbaca atau tidak terbaca penuh. Atau nama
kelurahan/kecamatan/kabupaten/kota yang salah terbaca. Tidak
diverifikasi dengan data wilayah Indonesia.
• Tidak ada keterangan confidence level ataupun error dalam
pembacaan foto KTP.
• Proses scanning membutuhkan waktu cukup lama antara request dan
return.

58. Case Study E: Mobile Phone Game Streaming
• Bagaimana membuat video streaming game dari handphone?
• Kami mencoba melakukan beberapa eksperimen
• Percobaan pertama:
• Hp android dihubungkan dengan laptop menggunakan kabel USB.
• Lalu dengan bantuan ADB, tools SCRCPY, layar hp dimunculkan ke laptop.
• Lalu menggunakan OBS, dibuat komposisi 3 layer: webcam laptop untuk
player, window capture dari hp, dan image frame menggunakan sebuah file
PNG.
• Lalu di kirim ke server steaming Twitch.

59. Ilustrasi

60. Topologi
Akses web Twitch
USB Cable:
- ADB
- SCRCPY
RTMP
HTTP + HLS

61. Perbedaan Topologi RTMP dan RTSP
RTSP Player
NVR app
RTSP Pusher
• No Media Server Needed.
• Not supportted by web browser natively
• 'Behind NAT/Firewall' problem
• Supported by most CCTV product/solution
• Suitable for local LAN (or WAN with port forward)
video/camera access
RTMP RTSP
• Must have media server.
• Supportted natively by web browser
• No 'Behind NAT/Firewall' problem
• Supported by many Media Stream platform like YouTube,
Facebook, Twitch, etc
• Suitable for video broadcasting need

62. Perbedaan Latency

63. Hasil
Percobaan pertama berhasil dengan baik, dengan beberapa indikator:
• Dilihat dari hp/laptop lain yang berada dalam area yang sama (akses ke Twich) berjalan
lancar. Bahkan diakses beberapa rekan beda kota juga lancar. Video tidak tersendat-
sendat.
• Memang ada delay yang cukup lama. Misalnya objek diam lalu bergerak, maka di Twitch
4-5 detik kemudian baru bergerak.
• Performa aplikasi game di hp tetap sangat baik, seperti tidak sedang streaming. FPS-nya
tetap seperti biasa. Tidak ada jitter/glitch, baik pada hp maupun ketika dilihat di Twitch.
• Hal ini berbeda apabila dengan menggunakan fitur dari platform game tersebut. FPS
turun jauh, dan layar hp beberapa kali jitter/glitch.
• Namun pada percobaan pertama suara dari hp belum di-streaming langsung. Suara
hanya ditangkap dari laptop, bersamaan dengan video yang ditangkap webcam laptop.

64. Percobaan Berikutnya
• Bagaimana agar suara dari hp bisa langsung di streaming?
• Bagaimana agar tidak perlu menggunakan kabel USB agar tidak
mengganggu player?
• Dan bagaimana jika ditambahkan layer dari sumber video lain seperti
RTSP dari CCTV lokal?
• Lalu bagaimana jika menggunakan server RTMP yang dibangun
sendiri di VPS/cloud VM? (tidak menggunakan server umum seperti
Twitch/Youtube/FB)

65. Eksekusi
• Kami lalu mencari tools yang berpadanan dengan SCRCPY tetapi untuk suara.
Dan ternyata kami menemukan tools SNDCPY yang vendor/sumber berbeda
dari pencipta SCRCPY.
• Kami menggunakan fitur tcpip pada ADB sehingga hp tetap dapat terhubung
dengan laptop, namun secara wireless menggunakan WiFi lokal.
• Kami membuat layer baru di OBS yang mengakses RTSP dari CCTV lokal yang
dapat diakses via WiFi LAN.
• Percobaan ini berjalan dengan bagus, seperti percobaan sebelumnya. Suara
dari hp lgs bisa dapat di-streaming tanpa masalah. SCRCPY dan SNDCPY
berjalan paralel dengan baik tanpa gangguan. Dan pada layar streaming
Twitch tersebut dapat dilihat ada window kecil yang menampilkan vide dari
CCTV.

66. Eksekusi Lanjutan
• Kami lalu mencoba memperluas eksperimen dengan mencoba membuat
server streaming sendiri.
• Kami coba eksperimen dengan tools dari Happytimesoft. Dan kami
menemukan RTSP Pusher. Kami coba untuk push RTSP CCTV local ke VPS yang
kami sewa, berjalan dengan baik. Namun tool ini hanya bisa menerima
sumber video RTSP. Sementara OBS hanya mendukung streaming RTMP. Kami
lalu mencoba RTMP Pusher dari Happytime. Baik RTSP Pusher dan RTMP
Pusher ini dokumentasinya agak membingungkan. Walaupun akhirnya dapat
berjalan dengan baik, tetapi hanya bisa diakses menggunakan protokol RTMP.
Kami lalu mencoba mencari alternatif solusi yang lebih baik.
• Lalu kami menemukan tools RTSP Simple Server
(https://github.com/aler9/rtsp-simple-server) Tools ini bisa melakukan
RTSP/RTMP /HLS server dan proxy, juga gratis dan open source. Hasil
percobaan tersebut berjalan baik dan sangat memuaskan

67. Topologi
VLC Network Player
rtmp://<vps ip addr>
HTML5 Web Video Player
http://<vps ip addr>
Wireless:
- SCRCPY
- SNDCPY
IDCloudHost VM
Instance using Linux OS
+ RTSP Simple Server
+ Web Server
+ HTML5 video player
CCTV RTSP

68. Hasil
• Sangat memuaskan. Memenuhi semua kriteria dari percobaan sebelumnya.
• Bahkan delay yang terjadi sangat kecil antara kejadian aktual dan tampilan
pada streaming (terasa hampir tidak ada delay). Bahkan ketika dicoba akses
dari kota lain.
• Namun resource VPS yang terpakai cukup besar. Dengan 2 vCPU dan 2GB
memory, hampir penuh hanya untuk melayani 2-3 client bersamaan. Dari sini
kami sadar mungkin server seperti Twitch membutuhkan waktu (delay
beberapa detik) untuk kepentingan optimasi, seperti:
• Ada re-process video (optimasi, penurunan resolusi, dsb)
• Ada proses distribusi ke node server lain/PoP (seperti mekanisme CDN). Karena
solusi seperti Twitch ini ditargetnya untuk publik secara internasional dan diakses
banyak penonton secar bersamaan.
• Tim sarsitek dan engineer Twitch pasti bekerja keras menemukan
formula/topologi/tuning yang optimal agar performanya bisa dijaga. Ini semua pasti
berbeda jauh dengan percobaan sederhana kami barusan menggunakan VPS.

69. Teknologi AIOT
• Diatas kita sudah banyak membahas berbagai studi kasus terkait pemrosesan
image/video ke server/cloud.
• Slide ini akan mengupas sedikit pengenai perang AI + IoT.
• AIOT adalah perangkat IoT yang sudah dilengkapi dengan kemampuan
embedded AI (machnine learning) terbatas.
• Beberapa tujuannya adalah:
• Supaya proses AI lebih terdistribusi
• Dapat memproses data/feedback secara lebih realtime
• Menekan kebutuhan bandwidth ke Cloud
• Perlu menjadi catatan: AIoT bukanlah ditujukan untuk menggantikan
pemrosesan AI di cloud. Karena bagaimapun cloud server punya kapasitas
komputasi yang jauh lebih baik.

70. Node Classification
AIoT

71. Topologi Umum IoT

72. Topologi Umum AIoT

73. Contoh Detail Implementasi

74. SOA & Microservices
• Pada awalnya apikasi di desain secara monilytics karena tujuannya lebih untuk
sistem informasi manajemen yang lingkup aksesnya sangat terbatas dan
dijalankan pada desktop PC.
• Dengan berkembangnya kebutuhan Enterprise, arsitektur ini berkembang
menjadi 3-tiers/n-tiers, dimana presentation layer, business logic layer dan
data management layers. Ini menyebabkan pengembangan sistem menjadi
lebih kompleks namun lebih terkategorisaikan.
• Lalu muncul kebutuhan untuk integrasi antar sistem/vendor yang berbeda.
Untuk menjawab tantangan ini, berbagai ahli memunculkan usulan arsitektur
SOA (Sevice Oriented Architecture). Lalu beberapa vendor besar berkumpul,
membuat konsorsoium dan membentuk standar SOAP/WSDL, dengan format
pertukran data XML (yang diadopsi dari kelebihan yang dimiliki HTML)

75. SOAP & WSDL

76. SOA & Microservices
• Memasuki era internet, device convergen, mobile (handphone, laptop,
tablet, PDA, dsb) kebutuhan aplikasi dan layanan digital semakin
beragam. Dan ini menimbulkan tantangan baru.
• Komunitas pengembang aplikasi dunia lalu memunculkan ide
REST/RESTFULL API. Sebuah mekanisme akses data/remote procedure
call dengan memanfaatkan protocol HTTP yang terbukti fleksibel,
dipakai jutaan pengguna, dan rendah kendala (seperti masalah
custom port, behind NAT/Firewall, dsb). Juga dipico oleh jargon AJAX
ada pemrograman HTML+Javascript yang awalnya diusung oleh
Google yang saat itu sedang berkembang pesat.

77. RESTFULL API

78. SOA & Microservices
• Hadirnya REST/RESTFULL API
yang semakin populer dan
semakin banyak pengguna
smartphone, menunjuk
perusahaan pengembang
layanan digital untuk membuat
layanan berbasis micro
• Lahirnya microservice. Seperti
ilustrasi pada layanan
transportasi online berikut ini:

79. SOA & Microservices

80. SOA & Microservices

81. Microservice Era
• Secara defacto, sebagian besar layanan mobile yang ada saat ini menggunakan
REST/RESTFULL API dan mayoritas menggunakan arsitektur microservices.
Namun REST/microservice tidak luput dari masalah turunan:
• Ukuran payload footprint yang cukup besar
• Proses handshaking dan header yang besar, sehingga latency-nya relatif tinggi
• Hanya bisa dipakai untuk text (ASCII). Sehingga jika akan bertukar data binary, butuh
dikonversi terlebih dahulu, misalnya menggunakan metode BASE64 yang ukurannya
(byte size) menjadi lebih besar
• Tidak memiliki standar khusus, format data dapat diubah sewaktu-waktu oleh
pengembangnya, sehingga implementasinya bisa berantakan.
• Lalu muncul teknologi pendukung seperti: gRPC, prototype, GraphQL, dsb.
Walaupun lebih canggih, namun semua teknologi tersebut masih bergantung
pada protocol HTTP.

82. REST untuk Image/Video Processing
• REST sebenarnya tidak didesain untuk pertukaran data binary seperti
image/video, apalagi untuk kebutuhan proses realtime, karena mengandalkan
protokol HTTP, yang memang tidak didesain dari awal untuk kebutuhan
tersebut. Untuk upload/download file, sebenarnya ada protokol FTP/SFTP,
yang tentunya mendukung berbagai format file termasuk binary. Namun
kacamata FTP adalah file (ada Begin of File/BoF dan End of File EoF) yang
proses transfer datanya dilakukan secara sekuensial (batch processing).
• Apakah ada protokol level aplikasi yang mendukung realtime communication,
dua arah, mampu mengirimkan data binary tak terputus (stream), namun
tetap se-fleksibel HTTP? Konsorsium web lalu membuat standar protocol baru
yang disebut dengan WebRTC

83. Cloud Computing
• Sesuah teknologi yang melakukan pergeseran infrastruktur server yang tadinya harus dimiliki dan
dikelola sendiri, sekarang dapat berbagi/mengoptimalkan sumberdaya server dan pengelolaannya
lebih tersentral dan diabstraksi, “seolah olah server berada di atas awan”.
• Cloud Computing awalnya terbagi menjadi IaaS, PaaS dan SaaS. Namun saat ini menjadi kurang
relevan karena pada prinsipnya semua bisa disediakan 'as a services' (XaaS).
• Cloud computing mendorong pemakaian luas teknologi virtualization, container, microservices,
blockstorage, bahkan Machine Learning/AI & Robotics.
• Cloud computing memiliki 5 karakteristik dasar yang membedakannya dariteknologi lain. Antara
lain adalah: on demand-self service, rapid elasticity dan measured service (“pay as you go”).
• Lebih detail mengenai Cloud Computing bisa dibaca di
https://www.slideshare.net/DonyRiyanto/cloud-computing-fundamental-65613737

84. Bagaimana membuat layanan Cloud untuk
Image/Video Processing beserta Analytics nya?
Tentu banyak sekali aspek/kriteria yang harus diperhatikan. Beberapa key point yang penting diperhatikan:
• Harus bisa memenuhi karakteristik Cloud Computing (terutama on demand-self service, rapid elasticity
dan measured service)
• Memiliki/mengembangkan platform image/video processing yang mumpuni dan dapat dengan mudah
diconfigurasi penggunanya (on demand-self service). Sehingga minim/tidak ada interaksi langsung
dengan admin/teknisi.
• Memiliki arsitektur/topologi/techstack yang mapan, diperhitungkan secara hati-hati, memperhitungkan
berbagai aspek penting.
• Harus dapat menyediakan/mendukung protokol/teknologi yang umum dipakai seperti: REST API, gRPC,
WebRTC/WebSocket, Microservices, Edge Computing, CDN, dsb.
• Sudah memiliki perencanaan (Capacity Planning) yang matang dan didukung infrasruktur backbone
internet yang kuat.
• Dekat dengan komunitas pengembang (software developer) agar dikenal dan mudah diimplementasikan
secara luas.

85. Contoh Arsitektur & Tech Stack

86. Contoh Arsitektur Netflix (Video on Demand)
https://medium.com/swlh/a-design-analysis-of-cloud-based-microservices-architecture-at-netflix-98836b2da45f

87. Contoh Arsitektur Aliyun Cloud ApsaraVideo
https://www.alibabacloud.com/product/mts