Game streaming bisa terlihat mulus tetapi tetap terasa “berat” ketika dikendalikan. Karakter mungkin bergerak sepersekian detik setelah tombol ditekan, aim terasa tertinggal, atau mobil terlambat merespons kemudi.
Masalah seperti ini berkaitan dengan input lag, bukan sekadar FPS atau kecepatan internet. Karena itu, memahami Cara Mengukur Input Lag menjadi penting sebelum developer mencoba melakukan optimasi.
Pengukuran yang baik harus melihat perjalanan lengkap dari aksi pemain hingga perubahan visual muncul di layar, sehingga tim mengetahui apakah delay berasal dari jaringan, rendering, encoding, decoding, atau perangkat display.
Apa Sebenarnya yang Disebut Input Lag?
Input lag adalah waktu antara aksi fisik pengguna dan munculnya respons yang sesuai pada layar.
Dalam game lokal, jalurnya relatif pendek: perangkat input mengirim sinyal, game memprosesnya, GPU merender frame, lalu monitor menampilkannya. Pada cloud gaming, perjalanan tersebut menjadi lebih panjang.
Input harus dikirim melalui jaringan menuju server. Server kemudian menjalankan simulasi game, merender frame, melakukan video encoding, mengirim stream kembali, lalu perangkat pemain melakukan decoding dan menampilkan hasilnya.
Karena itu, ping 30 ms tidak berarti input lag hanya 30 ms.
Round-trip network time hanyalah satu bagian dari keseluruhan pipeline.
Ukur dari Input sampai Piksel Berubah
Metode paling mudah dipahami adalah click-to-photon measurement atau pengukuran dari saat input terjadi sampai layar memperlihatkan respons.
NVIDIA menggunakan konsep serupa pada Reflex Analyzer. Sistem tersebut dapat mendeteksi klik dari mouse yang kompatibel dan mengukur waktu sampai piksel tertentu pada monitor berubah. NVIDIA menyebut pengukuran ini sebagai end-to-end system latency.
Untuk layanan streaming, prinsip yang sama dapat digunakan.
Pilih aksi dengan hasil visual yang mudah dikenali. Contohnya menembak senjata yang menghasilkan muzzle flash, membuka menu dengan perubahan warna yang jelas, atau membuat karakter melompat.
Semakin jelas titik awal dan respons visualnya, semakin mudah pengukran dilakukan secara konsisten.
Gunakan Kamera High-Speed untuk Pengujian Praktis
Salah satu metode yang cukup mudah direplikasi adalah merekam controller atau mouse dan layar dalam frame video yang sama.
Gunakan kamera dengan frame rate setinggi mungkin.
Pada rekaman 240 FPS, satu frame mewakili sekitar 4,17 ms. Kamera 120 FPS memberikan resolusi waktu sekitar 8,33 ms per frame. Semakin tinggi frame rate kamera, semakin presisi perkiraan latency yang bisa diperoleh.
Misalnya, rekaman 240 FPS memperlihatkan tombol mulai ditekan pada frame 100 dan respons muncul pada frame 122.
Selisihnya 22 frame.
Dengan durasi sekitar 4,17 ms per frame, perkiraan input lag menjadi sekitar 91,7 ms.
Gunakan Indikator Input jika Memungkinkan
Menentukan kapan tombol “benar-benar ditekan” dari gerakan jari terkadang sulit.
Pengujian yang lebih serius dapat memakai mouse, controller, atau rangkaian sederhana yang menghasilkan lampu indikator ketika sinyal input aktif. Lampu dan monitor kemudian direkam bersama.
Dengan begitu, frame saat LED menyala menjadi titik awal yang lebih jelas.
Jangan mengambil satu pengukuran saja. Lakukan puluhan percobaan karena frame scheduling, kondisi jaringan, dan waktu display scan-out dapat membuat hasil setiap percobaan sedikit berbeda.
Pisahkan Latency Lokal dan Streaming
Sebelum mengukur layanan cloud, ukur dulu game yang sama secara lokal jika memungkinkan.
Tujuannya membuat baseline.
Misalnya, game lokal mempunyai click-to-photon latency 45 ms. Setelah dimainkan melalui cloud streaming, hasil median menjadi 105 ms.
Tambahan sekitar 60 ms tersebut berasal dari berbagai komponen streaming seperti perjalanan jaringan, encoding, buffering, dan decoding.
Metode ini memang tidak dapat menjelaskan setiap komponen secara individual, tetapi sangat berguna untuk mengetahui “streaming overhead” yang benar-benar dirasakan pemain.
Hasilnya juga lebih berguna dibanding hanya mengatakan koneksi memiliki ping tertentu.
Jangan Menyamakan RTT dengan Input Lag
Round-trip time atau RTT adalah waktu perjalanan data menuju endpoint dan kembali.
Metrik ini sangat penting, tetapi tidak mencakup seluruh input-to-display latency.
Amazon GameLift Streams, misalnya, menyediakan metrik RoundTripTime untuk mengukur waktu perjalanan antara client dan server. Layanan tersebut juga memiliki metrik lain seperti frame capture rate serta resource utilization.
Jika RTT adalah 40 ms sementara input lag yang diukur kamera mencapai 110 ms, berarti sekitar 70 ms lainnya terjadi di bagian lain pipeline.
Sumbernya dapat berupa simulation delay, frame queue, rendering, encoder, decoder, jitter buffer, display refresh, atau kombinasi semuanya.
Karena itu, gunakan RTT sebagai diagnosis jaringan, bukan hasil akhir pengalaman pemain.
Perhatikan Encode dan Decode Latency
Game streaming membutuhkan video frame dikompresi sebelum dikirim.
Proses ini membutuhkan waktu.
Setelah sampai di client, frame juga harus didecode sebelum dapat muncul di layar.
Parsec, misalnya, menampilkan encode latency, decode latency, dan network latency secara terpisah pada performance overlay. Encode menunjukkan berapa lama host menangani sebuah frame, sedangkan decode memperlihatkan waktu pemrosesan frame pada perangkat client.
Dokumentasi troubleshooting Parsec juga mencatat bahwa untuk streaming 60 FPS, encode atau decode yang mendekati lebih dari sekitar 15 ms per frame dapat menjadi sinyal adanya masalah karena frame budget 60 FPS hanya sekitar 16,7 ms.
Data seperti ini membantu mengetahui apakah masalah berasal dari koneksi atau hardware decoding yang lambat.
Uji pada Beberapa Kondisi Jaringan
Pengujian di koneksi kantor yang sangat stabil belum tentu menggambarkan pengalaman pengguna sebenarnya.
Buat beberapa kondisi pengujian.
Uji Wi-Fi, Ethernet, jaringan dengan latency tambahan, packet loss ringan, bandwidth terbatas, serta koneksi ke region berbeda.
Amazon merekomendasikan penggunaan region yang sedekat mungkin dengan pengguna karena tingginya latency client menuju lokasi streaming dapat memengaruhi kualitas stream.
Jarak geografis memang bukan satu-satunya faktor karena routing ISP juga berpengaruh, tetapi perbandingan antarlokasi dapat menunjukkan bagaimana arsitektur regional memengaruhi responsiveness.
Catat juga konektifitas yang digunakan pada setiap sesi agar hasil tidak tercampur.
Jangan Hanya Melihat Nilai Rata-Rata
Katakanlah 50 hasil pengujian memiliki rata-rata 75 ms.
Angka tersebut belum menceritakan semuanya.
Mungkin sebagian besar sesi berada pada 60–70 ms, tetapi beberapa percobaan melonjak hingga 180 ms. Pemain akan tetap merasakan spike tersebut meskipun average terlihat bagus.
Gunakan median, p95, dan jika dataset cukup besar, p99.
Median menunjukkan pengalaman tipikal. P95 memberi gambaran nilai yang tidak dilampaui oleh sekitar 95% sampel dan membantu melihat pengalaman sisi buruk distribusi.
Jangan lupa mencatat jitter dan packet loss. Spesifikasi WebRTC Statistics API menyediakan metrik seperti jitter, packetsLost, dan roundTripTime untuk membantu aplikasi memantau kondisi jaringan media real-time.
Buat Benchmark yang Bisa Diulang
Pengukuran input lag akan lebih bermanfaat jika kondisi pengujian konsisten.
Gunakan game build yang sama, resolusi sama, refresh rate sama, codec sama, region sama, serta aksi gameplay yang sama.
Setelah melakukan perubahan pada encoder atau jaringan, jalankan benchmark tersebut kembali.
Contohnya, versi A menghasilkan median 96 ms dengan p95 128 ms. Setelah optimasi, versi B menghasilkan median 79 ms dan p95 93 ms.
Perbandingan seperti ini jauh lebih berguna daripada komentar subjektif bahwa game “terasa sedikit lebih cepat”.
Simpan hasil dalam spreadsheet atau dashboard agar perubahan performa dari satu build ke build berikutnya mudah dilihat.
Cara Mengukur Input Lag yang paling berguna adalah menggabungkan click-to-photon test dengan metrik jaringan dan streaming.
Gunakan kamera high-speed untuk mengukur pengalaman end-to-end, lalu lihat RTT, encode, decode, jitter, dan packet loss untuk menemukan sumber delay.
Buat benchmark berulang pada perangkat dan jaringan berbeda agar setiap optimisasi bisa dibuktikan dengan data, bukan sekadar feeling.