Ngobrolin Koneksi Real-Time - Ngobrolin WEB

2:25pertama kali pertama banget banget banget ikut acara web community belum jadi jadi Oh

2:39belum jadi jadi Iya malam jadi masih wan ini adalah orang yang bertanggung jawab untuk menjadikan kita

2:47jadi Iya yang menjemputkan kita ke jadi abur ya dari Google ya kan udah ada ini udah ada

3:04Oke mungkin disini kayaknya masanya masih banyak ya tapi mungkin ada yang mungkin belum kenal gitu

3:15ya mungkin boleh perkenalan singkat dong perjalanan lalu nges-nges jadi Halo nama saya Yohan disini

3:28ajakin Risa, Ivan, sama Eka

3:31untuk ikutan ngobrol

3:32hari ini kita bakal ngobrolin

3:34web

3:36real time communication

3:38dan karena kebetulan

3:40saat ini kesibukannya adalah

3:42lagi ngembangin startup

3:44yang menggunakan web artisi

3:46dan live streaming yaitu

3:48in live jadi

3:49mudah-mudahan pengalaman ngedevelop

3:52in live ini bisa dipakai buat sharing

3:54ke teman-teman disini

3:56itu mungkin intronya ya

3:57inlife.app ya

4:00inlife.app

4:02ya betul

4:02ini udah dikembangin

4:06berapa lama mas?

4:09kayaknya udah jalan setahunan

4:11jalan setahunan dan produknya itu

4:13sendiri sebenarnya ada

4:15yang pertama

4:17live streaming berbasis CDN

4:19terus yang kedua itu

4:21adalah

4:22kita bilangnya two way communication

4:26dan sama kayak StreamYard atau sama kayak Google Meet ini

4:28jadi yang satu itu untuk one way live streaming

4:31yang satunya tuh lebih buat two way live streaming kayak sekarang kita ini

4:35kayak Zoom berarti juga ya

4:36Zoom, Meet, Teams

4:39betul ya betul yang pertama itu lebih mirip kayak YouTube Live kurang lebih Tapi bisa di website sendiri Oke

4:51Problem yang mau disolve apa sih dari in live ini?

4:55Jadi sebenarnya kan permasalahan di Indonesia itu kita terlalu banyak pakai,

5:02apa ya, pas pandemi kemarin banyak pakai Zoom, Google Meet,

5:07kemudian live di mana-mana ya.

5:08di Twitch, Youtube, dan segala macam.

5:11Webinar ya?

5:12Ya, webinar dan macam-macam gitu kan.

5:15Nah, kita sendiri waktu itu kan lagi ngebantuin asumsi.

5:19Asumsi sendiri kan sebagai media online,

5:21itu tuh dia punya konten sangat banyak yang berbasis video gitu kan.

5:25Dan mereka waktu itu pandemi juga banyak bikin live event.

5:29Nah, waktu pengen mencoba monetize konten videonya,

5:32terus pengen ngedevelop produk yang terkait dengan live event,

5:36live streaming, dan lain-lain,

5:37kendala utamanya itu selalu kayak hitung-hitungan biaya itu pasti mahal banget

5:44karena semua produk API yang bisa kita pakai itu semua basisnya ada di luar

5:52dan semua pricingnya itu ya pakai pricing luar gitu gambarannya

5:57dan kalau kita

5:59UMR lokal nggak bisa ya

6:02Iya betul. Jadi kalau kita ngedevelop sesuatu yang costnya sendiri udah mahal, terus kita pengen coba jual di Indonesia, itu hitungan marginnya itu susah banget masuknya.

6:15Nah akhirnya kepikiran karena di Indonesia itu nggak ada API yang kita bisa pakai untuk ngedevelop produk live streaming, kemudian juga kayak Google Meet atau Telemedicine atau Consultation dan lain-lain.

6:29akhirnya yaudah waktu itu penasaran dengan web RTC dan udah ngoprek web RTC dari 2016

6:36anyway yang bikin dulu pertama kali jadi GDI itu sebenarnya demo web RTC

6:41jadi ada dulu tuh ada istilahnya ada jam with chrome

6:48jadi kita main band, main music gitu ya

6:52itu pake web RTC

6:54jadi tinggal buka browser terus kita pilih toolsnya mau pakai drum, mau pakai gitar, mau pakai piano gitu kan

7:02terus kita nyambungnya lewat web RTC

7:04itu waktu itu buat saya amaze banget dan akhirnya jadi penasaran buat explore web RTC

7:10nah karena itulah berhubung ada concern terkait infra API kita di Indonesia gak ada

7:16pengen develop something susah, mahal gitu ya

7:19terus lagi passionate ke web artis ya udah akhirnya mutusin ya udah develop aja sendiri ketimbang nungguin yang luar gitu

7:27gitu lah kurang lebih idenya gitu

7:32berarti web artis ini udah lama banget sebenarnya ya?

7:37starting from 2012

7:392011-an ya?

7:41Nah, itu jadi kalau misalnya kita tahu get user media tuh,

7:45media streams and capture API tuh yang buat ngambil gambar dari webcam

7:50dan microphone dan sebagainya, itu kayak foundation-nya,

7:54landasan buat itu kayak di konsep sebagai bagian dari web artisi API kan ya?

8:00Jadi itu kayak nyiapin untuk kedepannya web artisi.

8:04Jadi emang kayaknya ini salah satu hal yang udah dikejar

8:08dan udah dipengenin banyak pihak sendiri dulu ya berarti.

8:11Iya, karena kan kalau nggak bisa capture video kan apa yang bisa dikirim buat communicate gitu kan.

8:18Kalau web udah bisa, akhirnya kan bisa tinggal dikirim lewat network.

8:23Nah, itulah asal mula dari web artis itu sendiri sih.

8:26Nah, mungkin boleh dijelaskan sedikit tentang web artis itu apa dan use case-nya bisa dipakai buat apa aja?

8:33Oke, jadi web RTC itu ya nama singkatannya kan sebenarnya web real-time communication ya.

8:41Pada dasarnya ini adalah protokol yang memungkinkan kita tuh nge-develop aplikasi yang menggunakan komunikasi dua arah.

8:51Dua arah.

8:52Berbasis media atau data.

8:55dan karena yang namanya real time communication

8:59ada kata communicationnya di situ

9:01jadi diperlukan latensi yang sangat rendah

9:06kalau kita ngobrol kayak gini

9:08itu tuh latensinya idealnya gak boleh lebih dari 200 milisecond

9:13karena on selebih dari 200 milisecond

9:15kita tuh ngobrol jadi kayak aneh gitu loh

9:17kayak ada delay-delaynya

9:19kayak ngomong sendiri

9:22Iya betul atau ngomong kelihatan gitu ya tapi suaranya telat dan lain gitu Nah inilah yang sebenarnya di sebagai protokol standar sehingga semua browser itu bisa berkomunikasi

9:40Karena kan kalau nggak di-standarisasi, masing-masing pakai protokol berbeda.

9:44Semua bikin sendiri, repot.

9:45Iya. Akhirnya kan web nggak bisa jalan, kan.

9:50Nggak bisa. Satu pakai Firefox, kemudian satu pakai Chrome, satu pakai Safari.

9:53Gak bisa nyambung kalau misalnya kita pengen

9:56Ngobrol kayak sekarang

9:57Nah itulah kenapa

9:59Di develop yang namanya web RTC

10:02Tujuannya itu untuk memudahkan kita

10:04Menggunakan API standar ini

10:07Ngedevelop aplikasi web

10:08Walaupun sekarang juga

10:10Dipake ya library-nya di

10:12Mobile, di native gitu

10:14Tapi awalnya memang

10:16Tujuannya adalah untuk digunakan di browser

10:18Sehingga kita bisa

10:19Komunikasi real time berbasis media

10:22Atau data itu

10:23Oke berarti oh ya selalu tadi peer-to-peer kan yang masih masih dengan contoh di streaming yang

10:30sekarang kita ini batikin kita pilih-pilih nih antara masih Han memang berarti dari saya koneknya

10:36ke Yohan Riza enggak itu tue kan semua sebetulnya jadi jadi web artis itu memang pada dasarnya adalah

10:49aplikasi yang didesain untuk peer-to-peer

10:51jadi bisa

10:53aja kita memang ngobrol

10:55langsung tidak lewat server

10:56tapi dalam konteks yang

10:59sekarang dalam artian lebih dari

11:01satu, kalau satu

11:02101 itu

11:05memang idealnya biasanya

11:07itu dibuat peer-to-peer

11:09jadi server itu

11:11cuma buat ngasih

11:13tahu oh alamatnya Eka ini

11:15alamatnya Ipaling ya

11:16jadi

11:19ons udah saling tau alamatnya

11:21itu langsung akan terkeumum

11:23peer to peer

11:24tapi kalau dalam konteks kita sekarang

11:27karena lebih dari satu

11:28biasanya kalau udah lebih dari satu dibikin peer to peer

11:32itu bandwidthnya yang gak cukup

11:34karena kalau misalnya

11:36semua yang mau nonton juga harus

11:38connect ya

11:38jadi kayak

11:41kalau misalnya kita mau bikin semua peer to peer

11:43let's say kita pake 720

11:46dengan bitrate 3 Mbps

11:48artinya ini saya peer-to-peer ke Riza

11:52peer-to-peer ke Ivan

11:53sama peer-to-peer ke Eka

11:54itu 3x3 bandwidthnya

11:58jadi 9 Mbps yang dibutuhkan

12:01nggak ideal kan

12:02sehingga di develop-lah

12:05bukan protokol

12:07tapi ada metode

12:08yaitu yang namanya

12:10Selective Forwarding Unit

12:12atau SFU

12:13Jadi sebenarnya kita tuh ngirim video

12:16Ke server

12:17Server ini tugasnya yang nge-broadcast

12:20Ke yang lain

12:21Tapi dia cuma nurusin aja sebenarnya

12:24Ada encoding gak?

12:27Terjadi

12:28Nah ini yang menarik

12:30Zaman dulu

12:32Encoding itu terjadi

12:34Di server

12:35Di server

12:38Jadi dulu pada zaman Skype

12:41Terus apa lagi ya

12:42yang zaman dulu itu. Microsoft punya apa ya? Skype. Google Hangout. Hangout itu udah nerapin SFU awal-awal 2016 gitu. Hangout mungkin awal-awal serpan di Encode dulu.

13:05Jadi ada namanya MCU

13:08Saya lupa namanya

13:10Si panjangannya apa

13:11Tapi MCU itu pada dasarnya

13:14Dia nge-encode

13:16Semua video

13:17Kemudian video encoding itu

13:20Di forward

13:21Ke yang lain

13:23Jadi itu

13:26Nambah latensi satu

13:27Terus yang kedua

13:30Tapi

13:30Nambah beban server juga

13:33jadi sekarang sih enggak kalau dalam konteks yang kita lakukan tinggal di forward aja videonya

13:43nah teknologi yang digunakan selain web artis di inlife apa aja ya

13:54Saat ini sebenarnya kita kan ada dua produk, jadi produk yang pertama itu kan kita sama persis

14:06kayak ini jadi kayak streamer kemudian streamer kan ini nge ke YouTube kan ya Nah produk yang pertama kita itu pada dasarnya mirip kayak gini Jadi dia capture video menggunakan WebRTC

14:23kemudian di-forward ke servernya in-live.

14:26Di servernya in-live itu kita encode jadi format HLS sama DAS.

14:33Nah, HLS sama DAS ini format standar live streaming sebenarnya.

14:37Ya.

14:37yang digunakan di Youtube Live juga

14:41jadi itu kita combine antara WebRTC, FFMPEG, sama HLS

14:48nah yang produk kedua itu murni WebRTC dengan menggunakan SFU tadi

14:56yang Selective Forwarding Unit

14:58jadi kalau yang produk kedua itu memungkinkan kita ya bikin kayak stream yard kayak gini

15:05Ada banyak orang

15:06Atau mau bikin telemedicine

15:09Mau bikin google meet

15:11Mau bikin webinar

15:12Nah itu pada dasarnya

15:16Teknologi sebagian besar

15:18Lebih banyak menggunakan web artisi

15:20Tapi

15:21Dalam konteks web artisi

15:24Itu tuh

15:24Luas banget sebenarnya

15:26Jadi gak cukup cuman dengan

15:29Kita capture terus

15:31Kemudian kirim

15:32Yang paling ribet itu dari web RTC, terutama kalau kita banyak orang kayak gini,

15:38itu ada istilah namanya congestion controller.

15:42Jadi kalau misalnya saya itu video 720 nih ceritanya.

15:47Terus kan bandwidth-nya Eka ternyata cuma muat 360.

15:52Nah, video saya kan berarti harus diturunin.

15:57diturunin itu itu sebenarnya jadi diwetartisi ada namanya selektif video

16:11smart video coding kalau nggak salah saya lupa panjangnya apa ini yang diterapkan di

16:22p9 kalau di H264 itu belum bisa tapi kalau di p9 ada namanya SPC jadi saya ngirim 720 tapi di server

16:30itu kita bisa ngakalin yang mau dikirim ke Eka ini mau 360 atau yang 180 tanpa di encode ulang ya

16:40jadi yang server itu kayak memproses on the fly gitu ya betul jadi pada dasarnya pada saat kita

16:49video itu kan yang dikirim sebenarnya adalah paket-paket data ya nah paket-paket data ini

16:55itu tinggal ditentuin misalnya Oh Eka nih cuman bisa terima 360 artinya setelah saya ngirim 360

17:05ke Eka video sisa paketnya itu di drop di server karena kalau dikirim juga Eka jadinya terima 720

17:13Jadi ada mekanisme

17:16Gimana caranya kita ngedrop paket

17:19Yang kira-kira

17:21Tidak dibutuhkan oleh

17:22Eka sehingga tidak perlu

17:24Render videonya sampai 720

17:26Cuma sampai 360 aja

17:28Nah itulah

17:31Fungsi dari web artisi

17:34Kodek yang VP9

17:36Itu punya Google

17:37Terus kemudian

17:39Ada lagi teknologi simulkas gitu ya

17:42Itu tuh, kalau simulcast ini agak kompleks ya, karena simulcast ini kita ngirim video itu 3 jenis sekaligus.

17:50Jadi ada 720, kemudian ada 360, kemudian 180.

17:55Nah di server, itu server yang milih nih, dari 3 stream yang saya punya,

18:01mana yang saya harus forward ke Eka sesuai dengan bandwidthnya.

18:04Nah itu untuk memastikan biar Eka bisa terima video tapi bandwidthnya itu gak buffering

18:15Biasanya yang dipilih

18:16Iya betul biar gak mampat gitu pelanggaran

18:19Jadi bisa dibilang ya kalau kita pengen ngedupload API server buat web artisi over the weekend

18:28Itu sebenarnya bisa selesai

18:31Prototipe-nya ya

18:33Prototipe-nya aja

18:34Tapi untuk ngedevelop

18:37WebRTC server

18:39Yang bisa jalan di semua kondisi

18:41Wah itu tuh never ending

18:43Journey sih, sampai sekarang kita

18:45Masih ngulik-ngulik nih

18:47Kalau misalnya contoh gitu ya

18:48Oh bandwidthnya sekian

18:50Tapi paket lossnya tinggi misalnya

18:52Gimana nih kakak lihat

18:54Kalau paket loss tinggi, nah itu ada lagi

18:56Teknologinya macem-macem

18:58Kalau videonya

19:01Banyak ilang paketnya kan videonya jadi pixelated atau nge-freeze gitu kan.

19:06Nah itu tuh ada caranya buat ngakalin walaupun paket lo silah,

19:10itu video masih bisa smooth itu ada caranya.

19:13Pakai AI?

19:14Nggak.

19:15Ada, ada yang lagi di-develop.

19:18Jadi Google itu lagi punya kalau buat audio ada namanya,

19:22kan sekarang kodek yang kita pakai ini namanya Opus ya kodeknya.

19:26Oh iya Opus ya.

19:27Google itu sudah ngerilis

19:30Ada kodek yang namanya

19:31Likra, Lira, saya lupa

19:33Lira kalau nggak salah

19:34Itu tuh dia pakai AI

19:37Jadi kalau ada paket lost, paketnya tuh

19:39Di recover pakai AI

19:40Sehingga walaupun koneksinya jelek

19:44Audio kita tetap jelas

19:46Karena dia tuh

19:48Memprediksi bahwa kalau bilang

19:50Misalnya saya mau bilang Apple nih ya

19:52Baru yang kedapet

19:54Itu cuma app

19:55tapi dia udah nebak berikutnya nih Apple nih

19:58Apple loh, oh bukan Apple

20:00ya gitu

20:02sama kayak large language model

20:05yang hilang itu dia memprediksi

20:08oh apa sih kira-kira

20:10yang hilang

20:11itu kodenya

20:14udah masuk dalam eksperimen sih sekarang

20:16nah kalau web artisi ini

20:22sendiri

20:22Bukan cuma buat multimedia kan

20:26Bisa buat yang lain juga kan

20:28Text juga bisa

20:32Nah di web RTC itu

20:35Kan ada data channel

20:37Oh data channel

20:38Yang menarik ini yang paling menarik ya

20:42Jadi Zoom

20:44Itu dia pakai web RTC nya tuh aneh

20:47Agak nyeleneh

20:49Jadi Zoom itu dia capturing

20:52video itu menggunakan H264 tapi permasalahannya kodec yang dipakai oleh Zoom itu nggak disupport

21:02sama web RTC jadi dia punya H264 ini kan ada banyak ya ada yang open gitu ya ada yang komersil

21:12jadi Zoom itu pakai yang komersil atau bukan yang non-open gitu memang ada kelebihannya

21:19kelebihannya itu mirip kayak SPC-nya

21:21VPN tadi, jadi bisa ngedrop paket

21:24jadi

21:26Zoom itu ngakalinnya

21:27dia pakai WPTC, video kodenya

21:29itu dikirim lewat data channel

21:31jadi

21:33dikirim

21:34dikirim berupa binary

21:37stream, dikirim lewat data channel

21:39gitu

21:42nah, yang menarik

21:45lagi adalah

21:46kenapa dia ngirim lewat data channel

21:50dan kenapa dia butuh web artisi jatuhnya

21:52kenapa dia gak kirim pake web socket aja

21:54kalau gitu

21:54iya

21:55iya

21:56karena kan web socket bisa ngirim

22:01di narik juga kan

22:02iya kan

22:04ini yang paling menarik

22:07kalau pake web socket bisa dipastikan

22:09kita gak bisa ngobrol

22:11kayak sekarang

22:12kalau pake web socket

22:13karena latensi

22:15Karena latency, betul. Jadi sebelum kita melihat perbedaan WebSocket dan WebRTC, yang paling harus dipahami itu sebenarnya adalah perbedaan antara TCP dan UDP.

22:33Protokol Layer Network.

22:36TCP versus UDP.

22:38Yes betul

22:40Jadi kalau di jaringan

22:41Itu ada dua jenis protokol

22:44Satu TCP

22:45Atau kita bilangnya TCP ini adalah

22:47Reliable Network

22:49Jadi apa yang kita kirim

22:51Itu akan dikontrol dan dipastikan

22:53Selalu diterima di ujung

22:55Ada ACK nya

22:56Ada knowledge nya

23:00Knowledge nya

23:01Tapi kalau yang UDP

23:04Itu tuh dia

23:05Kirim kirim kirim

23:06Tapi gak peduli terima sana

23:08sana terima atau enggak, enggak peduli. Pokoknya kirim-kirim

23:10aja. Ada statusnya.

23:13Ya, betul. Nah, jadi

23:14yang menarik adalah kan

23:16kita tahu tadi video

23:18atau data apapun, kalau dikirim kan selalu

23:20paket-paket ya.

23:22Nah, kalau dikirim lewat web socket

23:24itu tuh cara kirimnya tuh bakal

23:26kayak gini. Paket satu, kirim.

23:29Server itu dia harus ngejawab

23:30dulu. Saya terima

23:32ya paket satu, terus dikirim balik.

23:35Begitu sudah

23:36dikasih tahu, sudah dikirim balik, oh sudah diterima

23:39ini paket 1, oke, ini paket 2 nya

23:41nunggu lagi dijawab dari server dan kalau server bilang eh gue nggak terima Time out Dikirim pulang Dikirim pulang Nah sehingga kalau kita hitung latency

23:54anggap latency internet kita 50 milisekund gitu ya.

23:58Jadi kita ngirim nih ke sana 50 milisekund.

24:02Terus dikasih tau kan.

24:03Balik lagi.

24:03Balik lagi.

24:04Ya, balik lagi 50 second gitu kan.

24:08Itu kan udah 100 milisekund.

24:10Jadi belum lagi kalau yang tadi Ivan bilang ada yang missing

24:15Terus dia harus kirim ulang, terus balik lagi

24:17Itu udah 200 milisekund tuh kalau sekali kirim ulang ya

24:22Bandingkan dengan UDP yang setiap paketnya itu dikirim jedanya itu bisa nanosekund

24:29Bukan milisekund lagi

24:30Biasanya ngirim paket UDP yang berbasis video itu

24:36waktu yang diperlukan kurang lebih jarak antar paket cuman 50 nanosecond jadi bisa dikirim

24:45paket-paket paket-paket beneran ya jadi dia cuman ngirim paket-paket paket-paket per 50 nanosecond

24:53dia ngirim paket terus gitu ya kalau nanti dari sana ngasih tahu ada yang missing nih baru dia

24:58kirim pulang jadi enggak ada tektok kan sifatnya oke itu kan lebih baik kalau misalnya di video

25:06kalau misalnya kayak chat text base sedangkan urutan itu kan penting ya apakah lebih baik

25:13kalau chat atau collaborative editing kayak Google Doc kalau yang datanya harus bener ya

25:22gimana harus perfect ya apalagi misalnya kada ada collision detection nih kalau misalnya Google Doc

25:28ya itu kan harus kayak data yang diedit bersama itu kan bisa terjadi collision ya kalau misalnya

25:35jadi kalau misalnya datanya itu kita bisa kirim cuman satu paket dalam artian gak lebih dari

25:511500 baik Kenapa 1500 baik jadi biasanya kalau yang suka main ya kalau yang suka main game

25:58Itu kan cara ngakal-ngakalin network, latency itu kadang, coba tuh adjust MTU-nya di router.

26:06Itu maksimum transmission unit.

26:08Jadi satu paket itu maksimum dikirim berapa?

26:11Ya itu biasanya 1500 byte itu.

26:13Nah, kalau paket data yang berupa text, atau kalau kita main game online kayak Dota gitu kan,

26:20Itu kan dia cuma ngirim koordinat kan

26:22Koordinat terus ngirim

26:24Apa

26:26Data, text, action

26:28Ya action

26:30Kayak up, down, left, right

26:33Gitu kan

26:33Itu kan sebenarnya dikirim satu paket

26:36Berulang itu sebenarnya

26:38It's okay gitu

26:39Karena gak perlu ada satu paket

26:43Dikirim langsung banyak

26:44Beda

26:46Dengan video

26:47Video itu kalau kita kirim keyframe atau gambar full,

26:55itu dia butuh mungkin kurang lebih ada 5 paket sekaligus yang akan dikirim.

27:02Sehingga ini tuh nggak boleh ada delay, nggak boleh ada yang hilang.

27:08Sehingga kalau ngirim 5 paket sekaligus dan harus diterima secepat mungkin,

27:15itu tuh nggak mungkin pakai TCP.

27:16terlalu lambat

27:18oke

27:19kecuali

27:21kecuali

27:22konsepnya

27:23itu adalah

27:24live streaming

27:25yang delay itu

27:26is fine

27:27kayak

27:28satu arah

27:29kayak youtube itu kan

27:30satu arah kan

27:31youtube live ya

27:32ya

27:33youtube itu kan

27:34protokolnya masih

27:35http

27:35walaupun udah ada

27:36http3 yang berbasis udp

27:38gitu ya

27:38tapi

27:39youtube itu

27:40dengan http2 juga

27:42itu pada dasarnya

27:43pcp kan

27:44ya

27:45dan itu kan

27:45nge-stream video.

27:47Dan itu enggak masalah. Kenapa?

27:50Karena sebenarnya delay-nya itu sampai 2 detik.

27:53Tapi

27:54kalau kita ngobrol kayak gini

27:55kan enggak boleh ada delay 2 detik.

27:59Jauh sekali ya.

28:01Nah itulah

28:02kenapa kalau kita

28:03yang berbasis video karena

28:05data streamnya itu gede dan

28:07banyak gitu ya. Itu hampir enggak mungkin

28:10kita pakai TCP.

28:12Kalau jaringannya

28:13sangat oke mungkin masih mungkin.

28:15Tapi sebaiknya sebenarnya sebagus apanya jaringan kita tapi kalau wifi kita aja tabrakan sama punya tetangga itu pasti paket lossnya udah hilang duluan di rumah gitu sebelum dikirim paket loss itu terjadi ya oh berarti webRTC itu pakai UDP

28:37terus kalau websocket itu pakai TCP berarti ya

28:41ya betul gitu bedanya

28:45nah kebutuhan untuk webRTC itu kan

28:50kalau secara infrastruktur kan ya

28:53pertama butuh signaling yang mendaftarkan address dari peer, mengasih tau, oh mas Yohan detail networknya disini,

29:07Liza detail networknya disini supaya kita bisa connect, terkomunikasi. Lalu ada yang disebut dengan kayak STUN atau TURN server itu sebenarnya buat apa sih?

29:18Oke, nah ini menarik kenapa web RTC butuh stun dan turn server buat signalling.

29:28Sedangkan web socket enggak.

29:30Pada dasarnya karena peer-to-peer yang web RTC itu enggak butuh IP public.

29:39Jadi tidak memerlukan stun atau turn tadi.

29:46kalau web socket kan kita yang penting

29:49IP nya berapa kan

29:51connect ke server kan

29:53client server ceritanya

29:55client server, jadi kita beneran

29:58nembak satu IP

29:59dan langsung connect kan

30:01dan itu jadi kita

30:03untuk bisa connect ke

30:06server web socket, itu tuh beneran

30:08ya tembak aja ke sana

30:09tapi

30:11kalau yang namanya web

30:14ITC, terutama yang

30:15101 ya, kayak

30:17saya, kita mau

30:19komunikat berempat nih, ini tuh

30:22udah pasti

30:23kalau

30:24sorry, kalau berempat, ini kan

30:27sama server, jadi

30:29kita sekarang connect-nya itu kan ke StreamYard

30:31server, kalau sama

30:33StreamYard server, itu kita

30:35bisa nggak pakai stun dan nggak usah

30:37pakai turn, kenapa?

30:40karena StreamYard kan punya IP public

30:41ya kan?

30:45Oke.

30:47Gitu.

30:47Jadi bisa aja yang diperlukan itu cuma offer SDP, session description protocol.

30:57Yang isinya itu cuma menjabarkan alamat saya itu servernya di mana.

31:04Terus kemudian saya pakai kodeknya apa aja.

31:08Terus saya kasih ini ke Riza.

31:10Riza terima itu dia bilang, oh Yohan ini kodeknya VPN-nya.

31:14Oh oke saya support COVID-19

31:16Nanti Riza akan balas

31:18Dia ngasih answer SDP namanya

31:20Answer SDP itu isinya sama

31:22Kayak offer SDP

31:23Isinya juga cuma oh alamat saya

31:26Terus kemudian kodek yang saya support

31:28Itu ini, nah nanti itu di matchmaking

31:30Jadi nanti saya ngirim video ke Riza

31:35Itu tuh kodeknya

31:36Udah pasti bisa diterima sama Riza

31:38Karena dia udah ngasih tau kan sebelumnya

31:42Jadi kalau misalnya dalam konteks stream yard itu tuh mungkin kita nggak perlu stun dan turn tadi

31:53karena stream yard punya public IP

31:55Kalau in live juga sama kasusnya?

31:58In live itu kita pakai turn server stunnya nggak dipakai

32:05gitu kenapa karena kita nge-deploy in-liveserver itu di belakang kubernetes

32:12berarti ada proxy ya ada nutsnya kan jadinya ada reverse proxy ada ya

32:19jadi servernya si in-lives sendiri itu sebenarnya nggak punya IP public

32:26gitu karena dia lewat log balancernya kubernetes kita kan

32:32Nah itu makanya kita cuma pakai turn tapi kita enggak pakai stun kenapa?

32:38Karena kita lagi-lagi turn kita itu punya IP public jadi bisa langsung connect aja ke turn.

32:47Nah web socket itu enggak perlu turn dan stun sesimpel karena ya itu tadi dia udah tahu IP publiknya.

32:58karena dia sebenarnya cuma connect ke yaitu web socket protocol

33:06WSS biasanya, web socket secure

33:08dan langsung IP atau domain yang sudah public yang ada service web socketnya sebenarnya betul nah bedanya sebenarnya cuman stun itu itu sebenarnya untuk ngasih tau IP site itu berapa sih

33:24jadi

33:25ini tuh paling sederhana kayak gini ya bentar

33:29boleh screen sharing gak Riza?

33:32boleh boleh silahkan

33:32oke

33:33jadi

33:35gak ada masalah politik kan

33:37apa ini

33:41jadi contoh nih ini tuh ada website kalian bisa cari aja trickle eyes gitu ya ini tuh

34:02untuk ngecek IP address kita dari student servernya Google

34:09jadi misalnya kita getter kandidat di bawah ini gitu ya

34:13running, nah ini kan kalau dilihat ini tuh ada dua IP address

34:24ya kan? IPv6 sama IPv4 ya

34:27iya betul

34:29nah ini

34:30ini adalah IP

34:32address router

34:35saya yang bawah itu

34:37oke

34:38sehingga

34:40mas Yuhan bukan IP public kan itu?

34:44oh routernya kebetulan

34:45paketan gaming jadi itu IP public

34:47memang routernya

34:48bagi yang di belakang NAT

34:50bisa juga

34:52jadi justru memang sebenarnya stun itu untuk nge-trace IP kita dari laptop terus nyambung ke router

35:08terus nyambung lagi ke routernya ISP terus nyambung lagi ke mana sampai IP public yang kira-kira bisa diakses sama peer sebelah kita

35:19jadi fungsi untuk buka connection ya jadi kayak cari pintunya gitu ya biar bisa saling nanti keluar

35:29masuk sendiri tapi harus tahu pintunya dari kedua kedua pihak betul karena ada istilahnya kalau di

35:37jaringan tuh ada punch punch holeing jadi kayak nusuk lobang ke dalam nuts jadi sebenarnya caranya

35:47itu adalah kita itu ngonek ke stone server pada saat kita connect ke stone server let's say di port disitu tuh 59160

36:01port itu tuh otomatis di router itu kan kebuka

36:07port itu dibuka sebenarnya untuk nanti peer dari sana itu bisa lewat port itu

36:15karena by default nats itu kalau tidak ada koneksi dari dalam dia nggak akan mau ngebuka port itu

36:23pasti keblok sama firewall kan atau keblok sama nats nya

36:26jadi betul betul jadi stun itu sebenarnya mekanismenya adalah

36:35ngebukain jalur biar peer dari sana itu bisa lewat ke jalur yang udah dibukain

36:41gitu gambarannya

36:45yang terjadi juga kadang

36:47kalo ini kasusnya kayak

36:49enterprise yang dimana secara security company nya itu membutuhkan

36:54karyawannya pake VPN

36:57web artis itu juga masalah kan dengan

37:01koneksi yang di belakang VPN gitu

37:04karena bingung, ini sekarang

37:06company-nya sama-sama VPN-nya, IP public-nya sama

37:10misalnya kita semua disini pakai VPN yang sama yang dari company

37:14IP public kita sama semua tuh

37:16ya betul

37:18maksudnya salah satu kelemahan alam semisal mungkin

37:23nah tapi itulah fungsi dari turn server

37:27kalau tadi kan turn server kan

37:29oke, maksudnya punya turn server lagi

37:32ya ada lagi turn server karena turn server ini sebenarnya kita bisa bilang sebagai relay server atau proxy server

37:41yang bisa kita pakai untuk terhubung karena turn server ini udah pasti punya IP public

37:47jadi sama kayak web socket aja connectnya

37:50tinggal nembak aja ke IP publicnya kan

37:54berarti si turn ini ngasih tau kita posisi dimana

37:58berarti mesin device connect ke si turn server

38:02Kalau pakai turn kita itu nggak peer-to-peer lagi semuanya itu lewat turn server

38:09Jadi udah kayak relay aja gitu

38:14Nah kurang lebih gitu sih kenapa kita butuh stun dan turn

38:25Itu sebenarnya untuk bisa peer-to-peer ya ngakalin peer-to-peernya itu

38:30Karena tanpa stun dan turn

38:34Kalau kita nggak punya public IP

38:36Artinya kan kita nggak bisa dihubungi dari luar kan

38:38Nah itulah fungsi stun dan turn

38:42Pada saat bikin hubungan web RTC gitu

38:46Oke kita pause dulu

38:49Udah pada pusing pada bingung

38:52Eh yang mau tanya chat

38:54Chat kalau mau tanya tanya aja

38:57Silahkan

38:59Ini mungkin kalau kita ngomongin teknisnya mungkin buat yang baru-baru itu pasti akan sangat kompleks, akan sangat rumit.

39:08Mungkin enaknya ke sesi berikutnya itu kita bahas saja.

39:14Ini sebenarnya web RTC itu bisa diapain sih?

39:16Kemudian, kira-kira comparable nggak sih dengan web RTC?

39:22Jadi, kita ngomongin produk lah yang kita bisa explore yang berbasis web RTC itu.

39:26Kita coba ngomongin saja.

39:28Nah in life sendiri target marketnya itu B2B atau B2C?

39:34Saat awal-awal kita mulai awalnya kan kita jualan API ya.

39:39Jualan API ya.

39:40API sendiri itu kan pada dasarnya B2B awalnya.

39:46Tapi kalau jualan B2B itu pasti kita udah ngerasain itu susahnya minta ampun.

39:52Kenapa? Karena akan selalu setiap ada perusahaan yang kita tawarin selalu akan nanya kliennya siapa.

40:01Itu selalu jadi pertanyaan.

40:03Sebenarnya belum ada. Kita baru mulai gitu kan.

40:07Oh ini ya masalah yang sama ya. Kayak ayam sama telur ya.

40:11Yang mana yang duluan.

40:12Betul. Betul.

40:14Atau kayak resgret.

40:16Lamar kerja. Butuh pengalaman kerja.

40:20Itulah fungsinya internship kan.

40:22sebenarnya sehingga kita tuh mencob terinspirasi dari tiktok sebenarnya jadi tiktok itu kan

40:33bitusia jadi dia consumer based app yang dipakai masih gitu di dunia terus sekarang

40:40behind the scene itu sebenarnya ByteDance atau induk dari tiktok sendiri itu menawarin API

40:48sama dengan epi life itu ke perusahaan-perusahaan untuk menawarin ngedaplop live streaming live

40:57shopping or anything live video gitu ya Terus kalau kliennya nanya-nanya portfolio mana ini

41:06Gak perlu

41:08Gak perlu, udah ada

41:11Nah itulah kenapa

41:13Inlife akhirnya mutusin

41:14Oh, better kita coba

41:17Fokus untuk nge-solve

41:19Apa yang kita lihat dulu di teman-teman kita

41:21Sehingga kita saat ini

41:23Fokus

41:24Coba naikin B2C

41:26Jadi ada satu aplikasi

41:29Yang namanya Inlife Room

41:31Yang kita develop, itu bisa dibuka di

41:33Room.inlife.app

41:34Pada dasarnya ini mirip kayak Google Meet

41:37Tapi kita gak pengen compete sama Google Meet atau Zoom atau Microsoft Team

41:44Fokus utama dari Live Room ke depannya itu lebih buat webinar sebenarnya

41:49Jadi kurang lebih kita pengen ngegabungin Locket.com

41:57Kemudian Zoom

42:00Kemudian paymentnya juga sekaligus

42:04jadi orang bisa bikin webinar webinar berbayar jual tiket disitu terus kemudian join-nya juga

42:13kelasnya yang langsung disitu bisa jadi kalau misalnya ada lagi nonton Coldplay yang ikut

42:22Google Play atau Kamin pakai inlives jadi di broadcast yang lain bisa join nonton

42:27iya terus diseret santam lah diseret security kalau tekan

42:32bejakan itu

42:34ini tampilannya juga mirip-mirip Google Meet ya

42:41ya inspired from nah ini ada pertanyaan nih dari Rahmat nih In life support E2E gak

42:52Oke

42:53E2E

42:54E2E

42:54Oh bukan

42:56Jadi sebenarnya untuk E2E

43:00In life sendiri saat ini

43:02Memutuskan belum

43:04Men support

43:05Kenapa ada

43:07Alasannya sebenarnya

43:09Jadi

43:10end-to-end encryption ini

43:12membuat kita

43:14sebagai server itu tidak bisa

43:16membaca apa

43:18yang lewat di server kita

43:20karena kita cuma bisa nge-forward

43:22aja kan

43:23sedangkan

43:26karena tadi fokus kita adalah

43:28pengen nge-develop webinar

43:30dimana kalau webinar ini kan

43:32kedepannya ada berapa fitur yang

43:34mungkin akan diperlukan misalnya salah satunya

43:36adalah audio transcription

43:38Jadi audio yang lewat itu kita bisa ubah jadi text misalnya

43:44Itu kan kita gak mungkin kita encrypt

43:47Karena kan jadi gak bisa kebaca di server kalau di encrypt

43:50Terus ada satu lagi fitur yang kita support juga

43:56Itu namanya voice detection

43:59Jadi pada saat kita ngomong itu bisa ke detect

44:02Oh ini lagi ngomong

44:03Nah kalau pakai end-to-end encryption lagi-lagi itu nggak bisa dideteksi

44:09Kita nggak bisa baca

44:10Yes gitu akhirnya saat ini kita memutuskan oke kita untuk kebutuhan in-laterall

44:17Kita nggak perlu ngerjain end-to-end encryption dulu

44:20Tapi nanti kalau ada kebutuhan itu bukan hal yang sulit

44:25Kenapa? Karena the good thing adalah web itu udah punya API

44:30yang namanya Insertable Stream API

44:34yang memungkinkan kita ngedupload end-to-end inscription dengan sangat mudah.

44:40Karena udah ada API-nya di web.

44:45Nah sejauh ini yang udah pake si in-live,

44:50baik itu B2C atau B2B,

44:52kalau udah ada, itu biasanya dipake buat apa aja?

44:55Kalau kemarin-kemarin sih kita memang lebih pakai buat meeting

45:00Lebih pakai buat meeting

45:05Terus beberapa klien yang kita ngobrol itu

45:08Itu sebenarnya ada yang lagi explore untuk penggunaan jalur komunikasi ofisial

45:16Untuk perbankan

45:18Jadi kan ini sebenarnya kayak dalam konteks misalnya

45:24semua komunikasi perusahaan kan saat ini

45:28biasanya lewat WhatsApp ya?

45:30Iya.

45:32Terus,

45:34Bang, kalau ngontak klien

45:36itu tuh biasanya

45:38kalau lewat jalur personal

45:39nggak punya legalitas

45:42dan nggak bisa dipertanggungjawabkan

45:44dan nggak bisa direcord.

45:47Iya.

45:48Bisa direcord, tapi itu kan manual

45:50semuanya.

45:51Jadi ada satu potensial client kita yang lagi ngobrol

45:56Pada dasarnya dia pengen ngedevelop aplikasi mirip kayak WhatsApp

46:00Which is possible dengan in-life API

46:02Tapi fungsinya memang untuk internal communication

46:07Jadi setiap obrolan, di situ setiap chat

46:12Itu bisa ke record di server

46:14Sehingga apapun yang dikomunikasikan

46:17Itu bisa dipertanggungjawabkan

46:19Oke, ini salah satu use case di luar Google meeting tadi.

46:24Dengan bantuan inline API kita bisa membuat service WhatsApp sendiri atau telegram sendiri.

46:34Di mana bisa ada video call, bisa ada chat juga ya.

46:36Ya, betul.

46:39Nah, ini ada pertanyaan lagi.

46:41Oh, lanjut, lanjut, lanjut.

46:43Langsung aja.

46:45Oh, langsung. Oke.

46:46Oke, ini salah satu fitur yang sulit dimomentasi adalah dedicated room for video streaming.

46:51Apakah Inline support untuk di-host di server sendiri?

46:55Ya, pada dasarnya core teknologi dari Inline itu sendiri itu open source.

47:02Jadi kalau bisa tolong dibantu dibukain ke GitHub kita ada inline dev.

47:09itu tuh kita ya in live dev slash SFU

47:16eh bukan ini ya coba yang di private chat

47:22private chat di in live room oke ini bisa di play sendiri ya kalau mau ya in live room itu yang yang tadi jadi in room itu juga open source Open source semua ya

47:37Iya, in-live room itu kita bilang open source Google Meet lah.

47:42Let's say kita bilang open source Google Meet, tapi jalannya harus ada dari server in-live.

47:47Jadi yang mana? SFU?

47:49Yang SFU itu, ini tuh sebenarnya core teknologi kita.

47:55Jadi bahkan kalau buka ada example HTTP WebSocket

48:01Itu tuh kita bisa ngerunning langsung aplikasi mirip kayak StreamYard atau Google Meet

48:10Very simple layoutnya, very basic gitu ya

48:13Tapi ya nunjukin fungsi SFU tadi yang forward

48:17Kita ngirim video kemudian di broadcast ke yang lain yang ada di dalam room itu

48:21Jadi pertanyaan yang tadi sebenarnya kita open untuk di host di server sendiri

48:31Jadi kita nerapin ada istilahnya namanya kita ya bilangnya enterprise license

48:38Jadi sifatnya itu memang kita nge-host di servernya mereka sendiri

48:43Ya bayarnya itu per instance per tahun

48:47biayanya berapa ya itu silahkan

48:50nontak aja

48:51jadi bisa running server

48:54sendiri dengan infra sendiri

48:56tapi pakai server kita

48:58itu bisa tapi

49:00biasanya running server

49:02sendiri itu jauh

49:04lebih kompleks

49:05kalau udah ngerti

49:08kita juga provide support kalau udah

49:10ngerti ya silahkan sih bisa-bisa aja tapi

49:12kalau

49:14agak rumit ya

49:15better pakai yang cloud API kita aja

49:18oh jadi ada

49:20ada ininya ya ada apa

49:22ada bisnis modelnya seperti itu ya

49:24mau yang open source

49:26download terus abis itu deploy

49:28atau pakai service yang udah disediakan

49:30oleh in live ya

49:31betul betul

49:33kalau pakai dari in live kan di hostingin

49:36juga kan ada servernya

49:38kan bisa connect, pokoknya gak perlu mikir

49:40infra atau apalah

49:42deploy-deployan

49:43karena sebetulnya

49:45Ya, karena sebenarnya ya masalah kita nge-host server itu terutama kalau kalian nge-hostnya itu kayak di Google Cloud, di Amazon, dan lain-lain.

49:53The most painful part itu sebenarnya adalah bandwidthnya.

49:57Bandwidthnya Google Cloud, Amazon, dan kawan-kawan itu super mahal.

50:03Sangat mahal.

50:05Berarti in-live nggak di cloud ya? Nggak di cloudnya yang tadi disebutkan?

50:10Nggak.

50:11Nggak, on-prem ya?

50:13On-prem.

50:13karena dedicated line di Indonesia itu gak bayar per total bandwidth yang digunakan

50:26per jalur bandwidth yang berpulan jadinya

50:30per capacity gitu

50:32Tapi ya feel free aja

50:36Sesuai kebutuhan

50:36Kalau bandwidth yang dipakai masih kecil

50:38Ya buat personal

50:40Bikin kelas online seminggu

50:42Cuma 1 kali 2 kali

50:44Di Google Cloud itu masih affordable

50:47Pakai aja yang open source

50:48Atau bisa ngobrol

50:49Questions

50:52Kalau misalnya komunitas kayak kita nih

50:56Ngobrolin web pengen pake in live

50:58Teknisnya gimana?

50:59Nah, jadi

51:01Bisa di broadcast ke Youtube juga

51:04Nah, saat ini

51:06Kita belum support broadcast ke Youtube

51:08Karena belum ada client yang minta

51:11Jadi kita

51:14Belum buatin, tapi pada dasarnya

51:16Ngebuatin itu tuh

51:17Sebenernya konteksnya sederhana

51:19Dan masih possible juga kita lakuin

51:22Bedanya

51:24Itu adalah

51:25Kita pada dasarnya ya sama aja kayak

51:28Masuk ke inline room tadi

51:29tapi kan itu sama aja kayak kita masuk ke Zoom atau kita masuk ke Google Meet gitu ya

51:35nah kemudian ya di capture pakai OBS kemudian ditembakin gitu

51:42nah tapi kan kalau dalam konteks kayak gitu itu kan biasanya butuh PC yang powerful ya

51:49biar bisa capture pakai OBS kemudian ditembakin ke Youtube ya

51:56nah butuh juga misalnya kayak saya pakai PC siapa misalnya saya gitu berarti kan harus ada audio feedback juga

52:05kan harus bisa dapat audio yang saya dengar masuk ke OBS baru tipe di youtube kalau enggak

52:11ya betul ada videonya nggak ada audionya gitu juga susah tapi buat kalian karena biar kita bisa ngobrol di in gak usah pake stream match lagi nanti saya bikinin deh

52:22yeayyyy

52:25sanggup, sanggup

52:27karena

52:29oh sanggup

52:31bikin itu tuh harusnya

52:33wuih

52:35wuih

52:37bikin itu harusnya gak rungut sih

52:39karena pada dasarnya dia cuman

52:42apa ngerekam Chrome headless kayak gini terus ya ditembakin aja ke itu YouTube-nya jadi harusnya

52:54bisa kita buatin di berarti kita nembak langsung ya minta disponsor ini hahaha

53:01mau nggak mau pasti akan dibutuhinkan kita sebenarnya dalam roadmapnya in

53:14live group sendiri karena itu kan kita pake sebagai webinar ya itu memang fitur kayak

53:20streamyard itu memang udah ada di pipeline tapi saat ini yang lagi kita fokusin itu adalah untuk

53:30bisa register participants kemudian terima pembayaran itu yang lagi kita kerjain sekarang

53:36karena kan kalau sekarang kan teman-teman bikin webinar kan daftarnya dimana terus webinar

53:43terus nggak kecatat juga tuh kadang tuh kalau webinar ini ya kalau webinar pemerintahan itu

53:52rasanya begitu masuk ya dulu 11 panggil dulu 11 ya ya ya ya ya nanti lihat liveroom lanjut lanjut

54:02di liveroom itu kita pengennya nanti kita bisa langsung lihat ya langsung aja ya terus kemudian

54:10yang join itu durasinya masing-masing per orang itu berapa lama Oh Riza cuma 30 menit tiba cuman

54:1745 menit, 20 menit misalnya.

54:21Terus kita juga karena kita ada voice activity detection,

54:25jadi kita juga lagi ngerjain gimana caranya kita bisa ngitung engagement speaking.

54:30Jadi ketahuan, oh Risa ngobrol.

54:35Jadi ada analytics, oh Risa tuh ngobrol sekian menit,

54:39Ivan sekian menit, saya sekian menit.

54:41jadi the whole webinar kita bisa tahu untuk planning next berikutnya itu seperti apa berdasarkan data-data itu

54:50itu yang lagi kita kerjain sebenarnya untuk in live room

54:55next sama mas danang kita semua jdg yang live-nya pakein live nanti

55:00pusing

55:04ajar ajar

55:05gausah pake google mic

55:11menarik ya Iya soalnya kemarin itu sempat kepikiran kan ini kan streamyart kita pakai

55:24streamyart terus mikir ini mau diperpanjang lagi soalnya udah mau habiskan mungkin ada

55:29nggak solusi yang gratisan gitu ada namanya video dan ninja itu kok nggak salah pakai

55:34juga tapi tetap tadi harus di broadcast melalui OBS nah takutnya enggak kuat karena kan sih

55:41videonya sendiri kan kita harus download dan upload kan gitu kan butuh bandwidth untuk

55:47ngumpulin orang-orang ini habis itu baru di broadcast lagi jadi ada dua kali bandwidth

55:53yang harus dipakai gitu kan apalagi apa saya sebagai operatornya koneksi internetnya uploadnya

56:02bagus gitu Oke agak khawatir di sana makanya siapa polusi streamer ini luar biasa bagus karena dia

56:09kan di server jadi kita enggak enggak terlalu ngatur betul belah belakangnya terlalu banyak

56:14kalau hostnya mati paling enggak Ivan sama Eka kan masih bisa ketangkes bisa ngomong selama ini

56:22sering kayak gitu sering terjadi ya Mari Mari kita coba let's say nanti satu bulan ke depan

56:29kemudian ada prototipe asyik Oh ya ini masih ada pertanyaan lagi nih dari rahmat lagi nih

56:36ntar tanya ketiga gantinya kalau misalnya butuh beta tester dan misalnya Oh kita coba-coba open

56:45open welcome kah kalau kita open PR isu dan terlalu welcome very welcome very welcome nah

56:54salah satu apa salah satu yang tidak jarang orang tahu adalah in life itu

57:03Ternyata open source. Itu saya juga baru tahu sekarang nih.

57:06Karena kayaknya belum terlalu di highlight ya.

57:08Jadi tahunya inline itu ya produk berbayar atau bisa trial.

57:13Ada SDK-nya, ada API-nya, kita bisa berkreasi di sana.

57:17Ternyata, ya, core-nya pun sampai di open source gitu.

57:20Jadi core-nya, core-nya sangat baik sekali.

57:27Actually this is a win for everyone.

57:29Jadi sebenarnya pengen nyoba juga, pengen main-main.

57:33kalau memang nanti ada yang bisa di beta testing kita siap ya salah satu yang ada yang namanya

57:40Jitsu meet ya beberapa bukan Jutsu Jitsi itu Jitsu Jitsu Jitsu Jitsu Jitsu Jitsu

57:51itu mempunyai pendekatan dari segi arsitektur apakah sama?

58:10Sebenarnya dari segi arsitektur

58:14Jitsi, Google Meet, Zoom

58:18Dan yang serupa

58:20Itu pada dasarnya arsitekturnya sama

58:22Pendekatannya adalah menggunakan SFU tadi

58:25Selective Forwarder Unit tadi

58:27Jadi secara arsitektur pada dasarnya semua sama

58:33Bedanya mungkin ada yang dipokusin buat meeting

58:36Ada yang dipokusin untuk apa

58:39Jadi masing-masing use case itu memang beda-beda

58:43Sehingga fitur yang bisa di develop di dalam API-nya sendiri itu beda-beda

58:49Tergantung kebutuhan

58:50Jadi in live room sendiri itu kan pada dasarnya ya memang live room virtual

58:58Tapi bukan berarti bahwa semua video yang kita broadcast ke sana

59:03Itu semuanya otomatis di broadcast ya

59:06kita tuh bisa milih servernya handling ya jadi kita bisa milih misalnya ya contoh saya tuh punya

59:14dua video satu screen sharing satu lagi video kamera gitu ya itu kalian tuh nanti akan dapat

59:21dari API akan dapat info bahwa oh Johan punya dua video nih mau ditampilin gak dua-duanya atau satu

59:29jadi bisa milih

59:30nah ini

59:32fungsinya buat apa, itu salah satu

59:35misalnya kita mau bikin breakout room

59:37jadi

59:38satu sesi

59:40tapi ruangan-ruangan

59:43kecil gitu ya

59:44itu jadi manual

59:47subscription ke video

59:48nah fitur tadi yang menarik lagi

59:51itu adalah

59:52lagi kepikiran kemarin ngobrol sama teman

59:55bikin ini

59:56video interview

59:58Antrian video interview

1:00:00Jadi kalian tau kalau

1:00:02Orang-orang yang kerja

1:00:04Kera biru yang di cafe

1:00:06Nyari pegawai magang

1:00:08Di cafe apa dan segala macam

1:00:10Itu tuh kalau ngelamar kerja

1:00:12Mereka kan yang ngantri tuh bisa ratusan kan

1:00:14Karena mereka kan

1:00:16Mereka kan walk-in interview kan

1:00:19Video itu sebenarnya bisa kita pakai untuk

1:00:22Walk-in interview

1:00:23Pendekatannya itu sama kayak breakout room

1:00:26Jadi

1:00:28saya tuh sekarang misalnya

1:00:31sendiri nih dalam

1:00:32dekat room ini, masukin aja tuh

1:00:34orang yang pertama join tadi, siapa?

1:00:36masukin ke room ini, terus nanti

1:00:39kalau udah selesai ngobrol, ini dikeluarin

1:00:40selesai, otomatis antrian selanjutnya

1:00:42iya, masukin lagi, itu kan tinggal

1:00:45di automate aja dari API, masukin

1:00:46jadi kita bisa bikin walk-in

1:00:49interview untuk

1:00:50ya, kasihan kan orang-orang yang

1:00:52antri pada sepanasan, cuma buat

1:00:54interview 10 menit kan, paling interviewnya

1:00:57iya, iya

1:00:58itu use case-use case yang kita harapkan

1:01:01servernya itu bisa custom logic ya berarti

1:01:04ya betul

1:01:05sebenarnya logicnya itu bukan di server

1:01:08logicnya itu di

1:01:09di apps kali ya

1:01:10oh kita bikin apps

1:01:14pakai API nya soalnya ya

1:01:15pakai SDK

1:01:16itu tadi

1:01:19mengatur traffic data in and out

1:01:22karena kan kita yang

1:01:24ngasih tau kan ini clientnya

1:01:26ada sekian yang ini

1:01:28ini duluan ini ini kedua ini ketiga ini keempat kita tuh yang atur tunggu ini masukin ini masukin

1:01:34JavaScript JavaScript saat ini SDK javascript aja javascript masih javascript aja ya senang iya biar anak front frontend bisa ikutan juga ya maaf saya masih bisa nya cuma javascript

1:01:55tapi tadi ini go lang

1:01:57oh iya itu kan yang backend kalau yang depan depan

1:02:01belum bisa plater belum bisa switch

1:02:05kan sekarang semua di rewrite

1:02:09Kurius, inline servernya berarti bisa jadi server game online juga?

1:02:16Oh bisa, tapi ada pendekatan yang agak beda dengan game server.

1:02:25Jadi Nvidia itu kan punya apa gitu, tapi dulu kan Google punya Google Stadia gitu ya.

1:02:30ada beberapa fitur yang

1:02:33perlu di develop lagi

1:02:35kalau misalnya pengen

1:02:36nge-develop cloud gaming

1:02:39tapi cloud gaming itu basisnya itu

1:02:41web RTC

1:02:41jadi

1:02:43salah satu yang paling penting

1:02:47dari cloud gaming itu

1:02:49adalah latency

1:02:50latency ini di server

1:02:53itu tuh beda antara cloud gaming

1:02:55dengan video call kayak gini

1:02:57dia harus dibawa

1:02:5920 menit second ya?

1:03:03Yes itu, tapi sebenarnya lebih masalah dari jitter buffer.

1:03:07Jadi jitter buffer itu istilahnya kayak gini,

1:03:11kan kalau kita ngirim paket video untuk satu gambar,

1:03:15let's say itu ada 5 paket kan,

1:03:17itu pada saat dikirim, itu belum tentu diterimanya berurutan,

1:03:211, 2, 3, 4, 5, belum tentu.

1:03:23Bisa jadi paket 3 sampai duluan.

1:03:26Iya bisa jadi paket 3 sampai duluan

1:03:29Bisa jadi paket 2 sampai duluan

1:03:31Jadi kadang gak berurutan

1:03:32Jitter buffer itu adalah

1:03:34Berapa lama kita mau nunggu

1:03:375 paket ini nyampe semua

1:03:39Biasanya sih kecil

1:03:43Cuman kayak 20 milisekund

1:03:44Atau 30 milisekund

1:03:47Nah ini kadang perlu adjustment

1:03:49Kalau untuk video call kayak kita

1:03:51Itu biasanya jitter buffernya itu

1:03:53Di range di sekitar 30 sampai 50 milisekund

1:03:56tapi kayak tadi Ivan bilang kalau Cloud Gaming latency-nya itu beneran bisa jadi nggak pakai JITER Buffer

1:04:07karena ada teknik lagi yang namanya Forward Encoding Correction atau FEC

1:04:19jadi itu tuh dipakai di cloud gaming tujuannya adalah kalau ada paket missing paket itu bisa

1:04:27direcover dengan forward encoding correction tadi jadi enggak pakai jitter buffer latency-nya rendah

1:04:37tapi perlu ada teknologi itu untuk memastikan videonya bisa smooth dengan latency rendah

1:04:43nah ini ada pertanyaan lagi sebenarnya udah udah sempet jawab tadi ya Zoom gitu pakai web artisikan

1:04:53ya kalau RTMP itu lebih buat live streaming ya buat satu arah RTMP itu TCP anyway jadi dia pasti

1:05:02latensinya tinggi dan memang tujuannya cuman satu arah kalau satu arah ada latensi itu masih oke

1:05:08ya kayak YouTube live streaming atau Twitch ya Twitch ya ya ya ya karena dia satu arah

1:05:17gak butuh dua arah gitu jadi latensi 2 detik 5 detik bahkan itu is oke sebenarnya

1:05:23ini ada pertanyaan lagi apakah one to one call di hit live dilakukan apa melewati video bridge

1:05:31Saat ini dan ini kita pilih memang semua one to one atau multi lebih dari satu itu semuanya lewat server

1:05:43Kenapa?

1:05:44Karena kalau nggak lewat server, satu kita nggak bisa dapat analyticsnya

1:05:50Terus yang kedua itu ada beberapa fitur yang bakal missing

1:05:55Salah satunya itu kayak voice activity detection itu nggak bisa dilakukan di web

1:06:00Saat ini karena kalau kita lakuin di web itu jadi harus ngelakuin audio processing.

1:06:07Sedangkan kalau di server itu tuh kita nggak nge-capture audio ya.

1:06:13Jadi di paket datanya audio kalau lewat di server itu tuh udah ada decibelnya tuh berapa.

1:06:21Jadi kita cuma ngelihat data itu aja.

1:06:25Ngebaca doang.

1:06:26Ngebaca doang.

1:06:27Jadi kita melihat untuk voice activity detection terus analytics dan everything itu kayaknya walaupun dia 101 itu tetap kita lewatin server aja

1:06:40daripada kalian harus bikin audio processing di web untuk tahu dia lagi ngomong atau enggak

1:06:46itu lebih ribet kan

1:06:48atau mau bikin transcription misalnya

1:06:51kalau yang process sendiri

1:06:53kalau yang blur background kayak mas Yohan ini di server atau dari client?

1:06:57client client client dari web ini masih dari sistem ini menjadi akan Oh enggak ini kebetulan Mac OS

1:07:10yang versi enggak tahu keberapa gitu ya yang agak-agak baru gitu itu mereka punya fitur untuk

1:07:17ngeblur semua video capture web RPC obat itu lepih ya ini dari sini integrasi nabok eskan

1:07:27Iya bahkan dia tuh punya efek-efek kayak gini nih bentar ya ini bukan kampanye ya

1:07:32bentar biasanya ada reaction gitu Oh iya iya iya dia bisa kayak

1:07:40betul-betul ini kan Oh iya loh Oh ini OS OS OS OS OS OS OS OS OS OS OS OS OS OS OS OS OS OS

1:08:00baru gitu ya di atas itu kan ada ikon kamera warna hijau itu harus diaktifkan reaction nya

1:08:06ah gua nggak ada ya bisa kayak gitu gua nggak ada nggak kalau belum nyatakan bisa ini terkentul ya

1:08:17tapi ini ini possible juga dibikin di web periisi kalau mau dibikin di web sebenarnya

1:08:31ya cuma kalau netizen support mah ya nggak usah Iya kalau esnya nggak support ya bisa aja kita

1:08:39fallback sensor flow.js tahun depan perbincangan kita adalah add-on di marketplace-nya in life

1:08:47untuk nambah-nambahin efek filter-filter efek filter er er hahaha jadi in life punya marketplace

1:08:57bisa nambah head on head on ya kalau ada bikinnya kan bisa lagi-lagi ceritanya extension plugin

1:09:07Oh ya kalau bikin lagi yang terbuka semua peserta jadi kayak gini jadi pakai mukanya

1:09:15bisa Ipan pastularis aja kalau discord sendiri itu pakai webatrisi juga enggak soalnya kan

1:09:24terkenal ringan ya walaupun

1:09:26kalau videonya nggak tahu tapi kalau audionya

1:09:28terkenal ringan ya apalagi buat gamer kan

1:09:30gamer kan resource-nya kan udah banyak di game

1:09:32terus kita masih bisa

1:09:34lancar berkomunikasi

1:09:36udah pernah riset nggak?

1:09:38most likely

1:09:40semua two way communication

1:09:42di aplikasi manapun itu

1:09:43most likely pasti web RPC

1:09:45karena kenapa

1:09:47saat ini that's the only protocol

1:09:50dan banyak

1:09:52protokol lainnya yang digunakan

1:09:54untuk ngedevelop

1:09:56two way communication kayak gini

1:09:57jadi web RTC

1:10:00itu sebenarnya kumpulan protokol

1:10:01dimana itu

1:10:04keperluannya memang untuk real time

1:10:06communication

1:10:07jadi

1:10:08saya gak ngelihat bang

1:10:11gak pernah ngelihat ada

1:10:13yang pake

1:10:14teknologi selain web RTC

1:10:18walaupun mungkin gak semua ya

1:10:19kayak tadi kan, Zoom itu ngakalin kan

1:10:21Jadi dia pakai WPPC tapi data channelnya aja gitu.

1:10:26Tapi hampir semuanya itu pakai itu.

1:10:30Kalau Zoom kan ada aplikasi desktopnya juga yang native kan ya?

1:10:36Itu juga tetap WPPC ya protokolnya ya?

1:10:39Ya itu tadi, dia pakai data channelnya.

1:10:43Kenapa dia pakai ini aplikasi desktop atau native-nya?

1:10:49karena kalau dia pakai browser

1:10:51browser itu kan gak punya

1:10:53kodec property yang tadi

1:10:55dia pengen pakai

1:10:57yang komersial itu

1:11:00jadi

1:11:01mereka ngedevelop native

1:11:04clientnya itu for the sake pakai kodec

1:11:06H264

1:11:07yang hardware optimized

1:11:10hardware accelerated di mayoritas

1:11:12devices tapi dia support SVC atau select smart Coding yang saat ini cuma ada di VP9

1:11:25di H264 biasa itu nggak ada

1:11:30jadi kayak hybrid gitu antara VP9 sama H264

1:11:36karena VP9 itu kan nggak support ini ya nggak hardware accelerated ya

1:11:39Makanya kalau kita meeting pakai Google Meet itu suka panas itunya.

1:11:45Ini streamnya pakai apa ya?

1:11:47Iya, streamnya pakai apa ya?

1:11:50Kalau kalian pengen ngecek sebuah website itu pakai teknologi apa itu sebenarnya ada caranya.

1:11:55Caranya adalah...

1:11:57Demo live.

1:11:59kalau apa kalau kita cobain di sini terus dibuka Network apa dibuka ininya Oh beda ya bukan bukan

1:12:13pakai inspect elemen ya enggak jadi kalian masuk ini ngetiknya tuh Chrome titik 2 slash slash

1:12:23rtc-internal disitu kalian bisa lihat semua yang pakai wprtc termasuk stream ya Jadi kalau lihat

1:12:32kayak gini kita kita jadi tahu kan Oh dia pakai turn kemudian dia pakai stone terus kita bisa

1:12:40lihat juga IP server dia itu berapa terus bisa kelihatan semua data-datanya misalnya contoh ya

1:12:47pakai kodecnya tuh apa lihat aja di outbound nya ini outbound RTP video pakai libvpx vp8

1:12:58ternyata dia pakainya ya bitrate nya berapa bisa kelihatan juga Oh ini bitrate per secondnya

1:13:04banyak pasengkan itu ya ini satu Mega and dan ada grafisnya juga bisa bisa kelihatan nih grafisnya

1:13:16tuh paket senjaya kenapa kita enggak tahu ini ya Iya itu tadi mau ngecek diinspeksi elemen tapi kan

1:13:29di-refresh jadi keluar dari streamyat dulu

1:13:33jadi tinggal pakai Chrome, WPRD, internal

1:13:36hampir semua browser itu punya cara untuk menulis panelnya

1:13:42termasuk Firefox berarti ya ada juga ya

1:13:46harusnya ada tapi biasanya beda-beda detailnya itu beda-beda

1:13:51oke ini ada pertanyaan sambungan

1:13:56mitos atau fakta lewat video bridge itu nggak optimal dan makan resource?

1:14:01Pada dasarnya kan apapun yang kalau kita ngembangin suatu fitur,

1:14:06itu pada dasarnya kan selalu ada trade-off ya untuk sesuatu yang kita develop.

1:14:13Benefit yang kita dapetin itu ada trade-offnya.

1:14:16Jadi kalau dibilang video bridge itu nggak optimal dan makan resource,

1:14:20memang ada yang jadi berkurang.

1:14:24Jadi misalnya latency-nya bertambah gitu. Tapi kan kita tadi bisa menggunakan analytics, kita bisa offload beban dari klien ke server.

1:14:36Karena kan tadi ada beberapa juga nanti mungkin kalau teman-teman lihat di chatnya kan itu juga yang kayak masalah.

1:14:43Bisa nggak sih filter-filter itu dipindahin ke server? Bisa aja.

1:14:47Tapi kalau kita

1:14:50Tapi kalau kita minen ke server

1:14:52Yang sifatnya itu video processing

1:14:54Audio processing

1:14:56Itu kan nambah latency lagi

1:14:58Jadi

1:15:00Selalu ada trade off

1:15:03Untuk apapun yang kita lakuin

1:15:05Kalau dibilang gak optimal

1:15:06Video bridge tergantung dari

1:15:10Arsitekturnya ya

1:15:11Kalau arsitekturnya itu adalah SFU

1:15:14Atau Selective Forwarder

1:15:15tadi jadi dia cuma nerusin video stream kita itu menurut saya itu paling optimal untuk saat ini

1:15:23dan mayoritas developer web artis itu juga agree bahwa SFU is the most optimal arsitektur untuk

1:15:30saat ini kalau pakai yang video Bridge versi lama atau MCU jadi dia multiple coding something gitu

1:15:41Jadi dia tuh meng-encode video yang masuk kemudian satu video itu yang baru dikirim ke orang yang nonton

1:15:49Nah itu kan ada latency di server

1:15:51Jadi ya selalu ada trade off for everything, pinter-pinteran kita aja milih untuk setiap use case nya kan

1:16:04Oh kalau diproses di klien berarti ada kemungkinan bisa pakai ini dong web assembly?

1:16:10Bisa. Ada beberapa web RTC API itu dia pakai web assembly.

1:16:21Bahkan Zoom itu kalau nggak salah melakukan itu deh.

1:16:26Oh iya?

1:16:26Jadi ya coba cari ada website namanya itu blog gig web RTC coba googling aja blog gig web RTC.

1:16:37Dia tuh disitu ngebahas banyak reverse engineering beberapa aplikasi berbasis web RTC.

1:16:46Termasuk Zoom tadi.

1:16:49Yang ini bukan?

1:16:49Ya betul betul coba lihat aja blognya.

1:16:53Blog.

1:16:54itu dia ngebahas itu semuanya tentang web artisik dan harusnya ada ada tentang Zoom diantara blog

1:17:04blog post itu Zoom ya silakan teman-teman cari aja saya share ring aja ya dia reverse

1:17:14engineering Google Meet juga dia banyak reverse engineering dari situ justru jadi belajar Oh

1:17:20atau gitu ya gitu ya terus di copy bikin di ATM amati tiru-tiru banget gaming ya

1:17:32bisa itu tadi yang FH FHC yang tadi saya bilang buat cloud gaming the roll of

1:17:45kalau di live sekarang saat ini kita udah terapin teknologinya itu red buat audionya ya tapi jadi

1:17:56redundancy encoding data gitu jadi pada dasarnya walaupun paket audio kita miss atau loss itu

1:18:05sampai 40% kita masih bisa ngobrol clear karena audio audio yang missing itu bisa di recover di

1:18:13audio berikutnya audio paket berikutnya mau diikuti ke paket berikutnya ya ya jadi selalu setiap paket

1:18:21itu dikirim to double paket yang sebelumnya dikirim juga bersamaan dengan paket berikut

1:18:26jadi kalau ada yang bisa selalu dapet yang sebelumnya betul jadi dia tuh kalau ada yang

1:18:36missing bisa cari dia nunggu aja yang datang setelahnya gitu kan karena dia bisa nanggung

1:18:42disitu besar dua kali lipat dong ya Pak lebih ternyata naik jadi dua kali empat tapi kan

1:18:50audio itu kecil makanya yang redundant redundant encoding itu cuma diterapi di audio untuk video

1:18:57jebol jebol pasti untuk video makanya Pak tadi pakai fact tadi for one encoding correction

1:19:06itu metode terpisah untuk recover video yang hilang dan dan gak makan masih nambah bandwidth

1:19:15tapi mungkin cuman 20% 30% jadi enggak sampai double oke oke gitu for the sake of good video

1:19:25over bad Network Nah kalau ada teman-teman yang nonton mau getting started mau ngulik

1:19:36the web artisih sebaiknya kemana kayak kayaknya paling enak dulu tuh kalau misalnya ngedaplok

1:19:46web artisih itu kan langsung aja bikin aplikasi langsung ini kalau demo-demo ada demo sejuta

1:19:53itu kan yang dari dulu banget udah ada di private chat

1:19:57pasti semua orang pernah, pokoknya pasti kalian semua pernah deh

1:20:01kayak cuma nyoba-nyoba, abis itu ah ya udah nggak jadi pade

1:20:06nah itu tuh bisa bikin itu karena kan

1:20:10kan ada kalau kita bikin aplikasi kan ada beberapa tahapan ya

1:20:13misalnya kayak kita, let's say kita mau bikin Google Meet like gitu ya

1:20:17ya pasti kan yang pertama kayak capture dulu audio videonya

1:20:20Terus abis itu gimana caranya menghubungkan peer Terus abis itu gimana caranya ngirim video yang kita capture tadi ke peer sebelahnya terus gimana playing the video tadi dari yang kita terima

1:20:35Jadi ya step-by-step-nya kurang lebih kayak gitu aja.

1:20:37Coba develop satu aplikasi aja, resource-nya udah banyak lah, tutorial-nya juga udah banyak.

1:20:42Tapi coba aja develop, terus setiap kepentok sama istilah-istilah tertentu gitu ya,

1:20:48kayak stun, turn, apa, googling, cari aja dokumentasinya.

1:20:52dulu banyak ya

1:20:54cara saya

1:20:56nanya ke Bang

1:20:59nanya ke Bang

1:21:01bisa bisa

1:21:02saya kemarin juga kerjaannya

1:21:07gitu jadi baca

1:21:08bacaan kode orang gitu kan

1:21:11terus nyari istilahnya

1:21:12terus coba reverse engineering

1:21:13terus baca spek dokumen

1:21:16terus diterapin

1:21:18ya pasti harus kayak gitu sih karena

1:21:20web RTC itu kompleksitasnya

1:21:22sangat kompleks karena terlalu banyak

1:21:24protokolnya yang harus

1:21:27dipahami, jadi enggak

1:21:28kalau harus belajar protokol dulu

1:21:30pasti berpuyang duluan

1:21:32jadi better langsung bikin

1:21:34aplikasinya aja, belajar protokolnya

1:21:36belakangan, pas dibutuhkan aja

1:21:38dia bikin

1:21:40aplikasi kayak apa ya

1:21:42kayak tampilin webcam

1:21:44terus mungkin tambahin filter, abis itu

1:21:46gimana cara-cara

1:21:47jadi gitu ya

1:21:50atau paling ini kan ini aja apa paling gampang kayaknya paling ini paling sederhana gitu ya bukan paling gampang

1:21:59itu bikin aja aplikasi peer-to-peer kayak FaceTime yang beneran peer-to-peer

1:22:06jadi itu beneran peer-to-peer kita cuma butuh signaling server aja

1:22:11Jadi nggak perlu

1:22:13Stun server kan

1:22:15Signaling server juga banyak yang

1:22:18Public dan gratis kan yang dari Google

1:22:19Iya betul

1:22:21Stunnya bisa pakai Google tapi signaling server

1:22:24Itu pakai HTTP server biasa itu

1:22:26Bisa

1:22:26Bahkan sebenarnya ya ada beberapa

1:22:30Example itu

1:22:31Yang beneran di copy paste

1:22:34Sinyalnya

1:22:34Jadi

1:22:36Over SDP nya

1:22:39Jadi kan semua web artisi

1:22:41itu biar bisa terhubung kita tuh saling

1:22:43bertukar sinyal. Sinyal ini

1:22:44itu ada dua jenis.

1:22:46Over, session, description

1:22:49protocol, sama answer.

1:22:51Jadi sama-sama SDP gitu ya.

1:22:53Jadi ini aja ditukar.

1:22:55SDP ini basisnya

1:22:57text. Jadi

1:22:58pada saat udah di print

1:23:00gitu ya, kasih aja

1:23:02kesebelahnya ini over.

1:23:04Masukin aja ke situ.

1:23:06Nanti di sana dimasukin,

1:23:08dia akan generate answer kan.

1:23:10Adswarenya itu teks juga

1:23:11Berutama SDP

1:23:12Gitu

1:23:14Ini kurang lebih gini nih

1:23:16Tunjukin ya ke kalian ya

1:23:18Ini share screen

1:23:19Boleh-boleh

1:23:20Kalau lihat disini

1:23:22Ini kan

1:23:24Streamyard pada saat kita connect

1:23:26Ini bisa dilihat

1:23:27Dia itu masukin

1:23:29Sorry, digedain dulu

1:23:30Ini tuh dia masukin audio, video

1:23:32Terus bikin offer kan

1:23:33Offer ini

1:23:34Itu adalah SDP

1:23:37Dimana formatnya itu teks

1:23:39sebenarnya kayak gini teks kayak gini ini sebenarnya kalau kalian copy copy nih terus

1:23:50dikonsumsi ya dimasukin aja di peer connection kalau nggak salah peer connection set over deskripsi

1:23:58set local description masukin ini terus habis setelah kita set text box ya betul setelah kita

1:24:08set local description itu tuh kita panggil lagi API nya apa generate answer atau apa pokoknya

1:24:16dapetin answer nya kan ya answer nya itu formatnya sama kayak gini nih ini kelihatan juga answernya

1:24:22tuh nih set local description tapi ada lagi set remote description nah ini kan answernya nih

1:24:31itu tinggal dibalikin

1:24:35copy aja ini semuanya

1:24:39kasihin ke sebelah lagi

1:24:40once kita udah sama-sama masukin ini

1:24:43itu dia akan mencoba

1:24:45terhubung satu sama lain

1:24:47oh

1:24:47iya sesederhana itu sebenarnya nukerin SDP tukeran eh ini offer saya ini offer siang sana gitu tukeran

1:25:00Nanti setelah dia tukeran,

1:25:03itu web artisnya akan coba connect sendirinya.

1:25:08Udah otomatis ya?

1:25:09Udah otomatis.

1:25:11Nah, once udah connect,

1:25:13nanti tuh peer connection itu akan ada event yang kita tinggal capture.

1:25:17eventnya itu adalah on track

1:25:19nah track ini

1:25:21itu adalah track video

1:25:23yang tinggal masukin

1:25:25ke video

1:25:26play

1:25:28ini formatnya

1:25:32kayak ini ya, kayak M3U8 gitu juga ya

1:25:35ini kan isinya dia

1:25:38ngasih tau bahwa

1:25:40IP saya itu ini ya, ini alamat IPnya

1:25:43kandidatnya gitu kan

1:25:45terus dia tuh ngasih tau kode-kode yang dia support tuh apa

1:25:48ya

1:25:49gitu kayak g-streamer

1:25:52ya vp8

1:25:54ya jadi

1:25:56intinya sdp tuh ngasih tau

1:25:59alamat sama

1:26:01fitur-fitur yang dia support

1:26:02sama

1:26:04teknologinya atau kode-nya gitu

1:26:07terus yaudah

1:26:09dia akan terhubung satu sama lain

1:26:11oke ini ada pertanyaan lagi nih

1:26:13Implement web RTC di sisi server dari RFC apakah worth it?

1:26:17Atau pakai library yang sudah jadi aja kayak peon?

1:26:23Tergantung pengennya itu ngapain.

1:26:28Kalau misalnya pengen belajar kayaknya silakan mau mulai dari awal

1:26:37tapi dulu saya justru mulainya dari peon itu sendiri.

1:26:39Kalau lihat SFU open source-nya in life, itu basisnya juga itu PNW Partisi itu.

1:26:46Karena example-nya ada banyak gitu kan, kemudian ya dokumentasinya lumayan,

1:26:52community-nya juga well support gitu.

1:26:55Jadi menurut saya mulai dari situ.

1:27:00Kenapa mulai dari situ?

1:27:01Karena jadi kita nggak perlu terlalu deep down ke protokol kayak DTLS.

1:27:07DTLS ini data ground TLS

1:27:10Jadi istilahnya UDP yang dibikin secure

1:27:13Kayak HTTPS atau SSL

1:27:15Itu kita kan gak mau belajar DTLS lagi protokol gitu kan

1:27:21Males gitu

1:27:21Kita tuh pengennya web partisinya aja

1:27:24Nah belum lagi ada lagi protokol RTP misalnya

1:27:27Tapi RTP itu mau gak mau pasti akan harus dipelajari sih

1:27:31Pada saat kita mulai paket datanya itu harus mau gak mau RTP

1:27:36Tapi abis itu ada banyak

1:27:38ICE protokol

1:27:39Apakah kita harus belajar ya ICE protokol?

1:27:41Kayaknya jangan deh

1:27:42Tapi mau gak mau pasti akan masuk ke sana

1:27:45Tapi kalau kita

1:27:46Kalau ketemu yaudah

1:27:48Ya udah ketemu

1:27:50Dan pas lagi butuh

1:27:51Ya udah seketemunya kan

1:27:54Iya betul pada saat dibutuhin aja baru belajar

1:27:57Tapi kalau dari awal langsung dari RFC

1:28:00Implement sendiri

1:28:01Wah berat kayaknya

1:28:03Kayaknya keburu bosen itu

1:28:05bikin terlalu idealis banget seneng banget sama urusan artisian ini biasa kayaknya ya itu ngantuk

1:28:17duluan nih Iya iya baca Red Sea itu membosankan hahaha ya ya ya nah nextnya buat Mas Yohan apalagi

1:28:29kan jadi GDI Google Developer Expert udah

1:28:32jadi Googler udah

1:28:35join Google juga udah

1:28:38terus sekarang bikin produk udah apa

1:28:40nextnya mau ada rencana apa lagi ke depannya

1:28:43belum ini bikin produknya

1:28:44ini belum ya belum selesai ya

1:28:46ini lagi gambling ini

1:28:48gambling iya iya iya iya

1:28:50jadi lagi gambling gitu ya nge-develop produk gitu kan

1:28:55yang masih belum take off masih ongoing

1:28:59produk market fitnya udah dapat belum?

1:29:02kita ngerasa produk market fitnya itu belum jadi

1:29:08kita kan masih bingung juga antara oke kita B2C atau B2B kayaknya ya udah saat ini kita lagi coba fokus B2B tapi kan kita belum tahu juga nih use case yang kita mau fokus itu yang mana dulu gitu kan ada banyak Kayak contoh kalau ngeliat use case web RTC di Indonesia sendiri itu ada edutech telemedicine

1:29:31customer call, call center, in-app call center, terus monitoring CCTV, video, dan everything.

1:29:40terus kayak gojek kalau nelpon kita lewat aplikasi itu kan web artis juga Oh ya pakai proxy dan

1:29:50memang biar kita enggak enggak live streaming so many use case gitu kan makanya kita belum

1:30:00tahu nih mana industri yang kita pengen fokusir tapi karena kita tuh paling dekatnya dengan teman-teman

1:30:07kalian yaitu yang suka bikin webinar gitu atau suka sharing makanya kita coba fokus di webinar

1:30:13atau edutech dulu saat ini gitu nanti kita lihat demandnya seperti apa ya kita coba explore to use

1:30:18case like gitu oke kalau yang mau follow mas Yohan aktifnya di sosial media mana di kalau ini Twitter

1:30:31kalau kalian pengen nanya-nanya everything web artis karena kalau nanya ke Instagram nggak

1:30:35menjawab gitu ya kecuali kalau kalian nanya jalur sepeda atau ada temanya ya ada fokusnya

1:30:46festival-festival Instagram hobi-hobi di Instagram gitu ya sisanya di Twitter ya

1:30:56semuanya itu di Twitter, hobi di Instagram, semuanya tapi di Twitter

1:31:02semuanya di Twitter, oh di Twitter hobi juga ada ya ngomongin hobi

1:31:06hobi juga ada, ya everything lah di Twitter

1:31:12team in life sekarang berapa orang development teamnya

1:31:16ada 4 orang, 1 designer, 2 engineer, 3 engineer termasuk saya, jadi total berempat

1:31:25Wah mantap mantap oke kalau gede semua ya Oh koding semua ya masih juga masih ngoding ya

1:31:33luar biasa ya itu kan kalau apa bekennya kan hampir saya semua sebenarnya ngejahit

1:31:39Oke karena yang engineer kita fullstack sama frontend sebenarnya

1:31:44oke oke oke mantap mantap

1:31:47bisa tanya di reponya

1:31:50hahaha

1:31:51iya iya iya

1:31:52oke kalau gitu terima kasih banyak

1:31:55Mas Yohan untuk waktunya malam hari ini

1:31:56terima kasih

1:31:57mudah mudahan

1:32:00iya luar biasa ya

1:32:03kok gak bisa

1:32:04gak bisa

1:32:05ya mudah mudahan

1:32:10ada kesempatan untuk kita ngobrol ngobrol lagi

1:32:14tentang banyak hal ini ada ada komunitasnya nggak sih wepertisi atau komunitas web biasa aja ya

1:32:21pada umumnya saat ini wepertisi itu komunitasnya belum ada belum ada tapi kalau kalian yang pakai

1:32:31golang itu ya mungkin saran saya coba cari Slack channelnya ini tion di goper jadikan ya golang

1:32:42punya Slack channel, nah cari aja di dalam

1:32:44channelnya itu ada

1:32:46channelnya Pion, disitu kalian

1:32:48kalau pengen belajar itu

1:32:50kata saya sih disitu, tapi ke depannya

1:32:52saya ada wacana

1:32:54juga bakal bikin webinar

1:32:56rutin, sekalian dogfooding

1:32:58in live room sendiri

1:33:00jadi

1:33:01mungkin belajar

1:33:03ngedevelop web RTC app

1:33:05lewat webinar

1:33:06nah ini menarik nih, jadi pantengin aja ya

1:33:09twitternya mas Yohan ya

1:33:11at Yes Johan info-info nya atau Yohan ya Oke kalau gitu Terima kasih banyak buat teman-teman

1:33:20semua terima kasih banyak banget Johan kita ketemu lagi minggu depan di waktu dan jam yang

1:33:30sama di waktu dan jam yang sama sampai jumpa lagi bye bye

1:33:41Terima kasih.