Kenapa Screen Sharing Tetap Lag Padahal Packet Loss 0%?

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:

1. Encoding bukan penyebabnya. 12.3 ms per frame dari anggaran 33 ms di 30 fps — masih 37% terpakai.
2. Adaptive quality tidak pernah aktif. Dari 501 sampel, limit=none di semua sampel. Artinya engine tidak pernah menurunkan kualitas, meski frame rate jatuh ke 3.
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 degradationPreference secara 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