Cloud Service Design for Computer Vision, Image & Video Processing+Analytics
0 likes511 views
Dokumen ini membahas desain layanan cloud untuk pemrosesan dan analisis image/video yang menghadapi banyak tantangan teknis dan kebutuhan pasar yang belum terpenuhi. Contoh kasus yang diuraikan mencakup proyek pemantauan CCTV, streaming video drone, dan analisis perilaku pelanggan, masing-masing dengan solusi inovatif dan masalah yang ditemukan. Masalah utama termasuk kurangnya infrastruktur yang memadai dan kebutuhan vendor yang beragam, serta solusi yang diusulkan untuk mengoptimalkan kinerja dan memenuhi kebutuhan pengguna.
Cloud Service Design for Computer Vision, Image & Video Processing+Analytics
- 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
- 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
- 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.
- 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:
- 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