Kami mengukur satu sesi screen sharing di macOS: resolusi 3024x1964, H.264 lewat VideoToolbox, frame rate median 29 fps, waktu encoding 12.3 ms, dan dropped=0 di sisi pengirim.
Jaringan? Sempurna. RTT 0–1 ms, packet loss 0%.
Tapi di sisi penonton, freezes tetap terakumulasi sampai 35 kali, dengan satu segmen 2 detik yang hanya 3 fps.
Kesimpulan pertama: bottleneck-nya bukan jaringan.
Kenapa bisa begitu
Ada tiga hal yang biasanya luput diukur:
- Encoding bukan penyebabnya. 12.3 ms per frame dari anggaran 33 ms di 30 fps — masih 37% terpakai.
-
Adaptive quality tidak pernah aktif. Dari 501 sampel,
limit=nonedi semua sampel. Artinya engine tidak pernah menurunkan kualitas, meski frame rate jatuh ke 3. - Preferensi degradasi salah arah. Untuk screen sharing, WebRTC cenderung mempertahankan resolusi dan mengorbankan frame rate. Jadi saat jaringan menurun, yang Anda lihat adalah gambar tetap tajam tapi tersendat.
Yang bisa dilakukan
- Set
degradationPreferencesecara eksplisit, jangan biarkan default. - Buat tangga resolusi sendiri (100% → 66% → 50%) dan turunkan resolusi sebelum frame rate jatuh di bawah 15.
- Batasi resolusi di sisi capture, bukan di encoder. Frame 3024x1964 adalah ~5.9 megapiksel; turun ke 1920x1200 memotong kerja 4x.
- Catat
dropped,freezes, dan waktu decode secara terpisah — tanpa itu Anda hanya bisa menebak.
Alat gratis
Saya membuat kalkulator budget latency & bandwidth untuk screen sharing: masukkan resolusi, fps, codec, dan bandwidth, lalu lihat di tahap mana budget Anda pecah.
https://hhfa008.github.io/tools/screen-share-calc/id/
Kalau butuh checklist lengkap 18 poin plus skrip pengukuran, ada di sini (versi berbayar): https://devinspire734.gumroad.com/l/xejxsp/FIRST50
Top comments (0)