1 · Anggaran encode
Anggaran per frame
33.3ms per frame
1000 ÷ 30 fps
Waktu encode hardware tipikal
~5 ms
Sisa ruang dalam frame
28.3 ms
Alat gratis · berbagi layar dan desktop jarak jauh
Kalkulator latency & bandwidth berbagi layar
Rencanakan pipeline berbagi layar sebelum dirilis. Atur resolusi, frame rate, codec, bandwidth yang tersedia, dan round-trip time; halaman ini menampilkan anggaran encode per frame, perkiraan bitrate, rincian latency, dan apa yang harus diturunkan saat koneksi ketat.
Semua angka di halaman ini adalah perkiraan. Angka berasal dari rumus yang ditampilkan di bawah, bukan dari pengukuran encoder, jaringan, atau perangkat Anda. Perlakukan sebagai masukan perencanaan, lalu verifikasi dengan pipeline Anda sendiri.
Input
Jelaskan stream
Encoding hardware AV1 tidak tersedia di semua GPU atau SoC mobile. Perkiraan di bawah mengasumsikan encoding hardware; fallback software bisa beberapa kali lebih lambat dan mungkin melewati anggaran frame.
Hasil
2 · Kebutuhan bitrate
Perkiraan bitrate
6.8Mbps
Rentang 5–8.7 Mbps, dengan asumsi menengah 0.11 bits per pixel per frame (bpp).
Bandwidth tersedia
20 Mbps
Sisa ruang di atas perkiraan atas
11.3 Mbps
3 · Anggaran latency
Perkiraan end-to-end
150ms
sekitar referensi interaktif 150 ms
| Tahap | Perkiraan | Porsi | Batas | Status |
|---|
4 · Trade-off degradasi
Pertahankan resolusi, atau pertahankan frame rate?
Pada 20 Mbps dengan asumsi bpp menengah untuk H.264, dua strategi penurunan menghasilkan:
| Metrik | A · Pertahankan resolusi, turunkan fps | B · Pertahankan fps, turunkan resolusi |
|---|---|---|
| Frame rate | 30 fps | 30 fps |
| Resolusi | 1920 × 1080 | 1920 × 1080 |
| Skala vs input | 100% | 100% |
| Perkiraan bitrate | ~6.8 Mbps | ~6.8 Mbps |
| Perkiraan waktu encode | ~5 ms | ~5 ms |
| Encode vs anggaran frame | — | — |
| Batas pengikat | — | — |
| Perkiraan latency end-to-end | ~150 ms | ~150 ms |
| Gerakan | Mulus pada laju target. | Mempertahankan irama target. |
| Teks dan detail halus | Resolusi penuh; teks dan UI tetap tajam. | Tidak berubah. |
| Cocok untuk | Dokumen, kode, dasbor, slide. | Video, animasi, gerakan kursor, cloud gaming. |
Rekomendasi
Rumus dan asumsi — buka untuk memeriksa perhitungan
Anggaran frame
budget_ms = 1000 / fps
Waktu yang boleh dihabiskan setiap frame dalam langkah encode sebelum frame berikutnya jatuh tempo.
Bitrate
Mbps = width × height × fps × bpp / 1,000,000
Perkiraan perencanaan kasar. Konten layar dengan area statis besar bisa jauh lebih murah; noise, gerakan, dan chroma 4:4:4 bisa lebih mahal.
fps maksimum pada resolusi penuh
max_fps = bandwidth_bps / (width × height × bpp)
Kolom A mempertahankan resolusi input dan menyelesaikan frame rate yang bisa dibawa koneksi.
Faktor downscale
scale = √( bandwidth_bps / (width × height × fps × bpp) )
Kolom B mempertahankan frame rate target dan menyelesaikan jumlah piksel. Skala linear adalah akar kuadrat dari rasio area.
Skala agar muat encode
scale_enc = √( 2,073,600 × (budget_ms / base_ms)^(1 / 0.85) / pixels )
Kolom B mengambil skala bandwidth atau skala agar muat encode yang lebih kecil, sehingga frame rate target juga muat di encoder. Jika input sudah muat, skala dibatasi 100%.
Waktu encode
t ≈ base_ms × (pixels / 2,073,600)^0.85
Perkiraan perencanaan untuk encoder hardware. Basis pada 1080p: H.264 5 ms, HEVC 8 ms, AV1 11 ms. Perangkat, preset, konten, dan suhu sangat memengaruhi ini.
Waktu decode
decode ≈ 0.6 × encode
Faktor asimetri kasar; decoder hardware biasanya berjalan lebih cepat daripada encoder.
Latency total
capture + encode + RTT/2 + 2 × frame + decode + render
Capture adalah satu interval frame. Jaringan adalah satu kali perjalanan. Jitter buffer dua frame. Render 16.7 ms untuk layar 60 Hz.
Asumsi bpp
H.264 0.08–0.14 · HEVC 0.05–0.09 · AV1 0.035–0.07
Bits per pixel per frame. Kalkulator memakai titik tengah untuk keluaran nilai tunggal dan ujung rentang untuk pita bitrate.
- Ini perkiraan, bukan pengukuran. Tidak ada encoder, perangkat, atau jaringan yang di-benchmark di sini.
- Pita bpp adalah asumsi perencanaan untuk video interaktif dan konten layar. Ini bukan jaminan codec dan tidak mencakup perilaku rate control.
- Waktu encode dan decode mengasumsikan akselerasi hardware. Khususnya AV1 dapat jatuh ke software, di mana waktu encode bisa beberapa kali lebih tinggi.
- Kolom A dibatasi oleh nilai terendah antara batas bandwidth dan throughput encoder (1000 / waktu encode). Kolom B melakukan downscale hingga bitrate dan waktu encode per frame sama-sama muat.
- Latency jaringan dimodelkan sebagai RTT ÷ 2, tanpa retransmisi, queueing, atau kongesti. Wi-Fi, relay, dan uplink yang sibuk menambah delay nyata.
- Jitter buffer ditetapkan dua frame. Implementasi nyata sering memakai satu hingga lima frame, atau menyesuaikan buffer saat runtime.
- Garis 150 ms adalah referensi interaktif umum, bukan persyaratan. Cloud gaming sering menargetkan lebih rendah; dukungan jarak jauh dan presentasi mentoleransi lebih tinggi.
- Menaikkan frame rate memperkecil interval frame dan suku jitter tetapi menaikkan bitrate. Menurunkan frame rate melakukan sebaliknya.
Langkah berikutnya
Ingin checklist lengkap dan skrip pengukuran?
Checklist mencakup tahap pipeline di atas, sinyal yang layak ditangkap, dan cara membacanya tanpa menebak. Skrip adalah yang dijalankan pada build Anda sendiri.
Dapatkan checklist — kode FIRST50 →Tautan membawa kode diskon FIRST50. Tidak ada skrip pelacakan di halaman ini.
FAQ berbagi layar
Mengapa berbagi layar saya tersendat padahal packet loss 0%?
Packet loss hanyalah satu sumber delay. Model ini memisahkan waktu encode, bitrate, dan jitter: jika waktu encode melewati anggaran per frame 1000 ÷ fps, perkirakan frame drop atau frame rate efektif yang lebih rendah; ketika bandwidth menjadi batas pengikat, stream justru mengalami degradasi. Jitter buffer ditetapkan dua frame, dan perkiraan latency tidak mencakup retransmisi, queueing, dan kongesti, sehingga Wi-Fi, relay, dan uplink yang sibuk dapat menambah delay nyata.
Berapa anggaran latency yang sebaiknya ditargetkan untuk berbagi layar?
Garis 150 ms adalah referensi interaktif yang umum, bukan persyaratan. Cloud gaming sering menargetkan lebih rendah, sedangkan dukungan jarak jauh dan presentasi mentoleransi lebih tinggi. Perlakukan sebagai masukan perencanaan, lalu verifikasi dengan pipeline Anda sendiri.
Mana yang lebih penting untuk berbagi layar, resolusi atau frame rate?
Tergantung kontennya. Mempertahankan resolusi dan menurunkan frame rate paling baik untuk dokumen, kode, dasbor, dan slide; mempertahankan frame rate dan menurunkan resolusi paling baik untuk video, animasi, gerakan kursor, dan cloud gaming. Untuk teks gunakan cara pertama; untuk gerakan gunakan cara kedua.