เครื่องมือฟรี · การแชร์หน้าจอและรีโมตเดสก์ท็อป

เครื่องคำนวณ latency & bandwidth สำหรับการแชร์หน้าจอ

วางแผนไปป์ไลน์การแชร์หน้าจอก่อนเปิดใช้งาน ตั้งค่าความละเอียด, frame rate, codec, bandwidth ที่มี และ round-trip time; หน้าจะคืนงบ encode ต่อเฟรม, bitrate โดยประมาณ, การแบ่ง latency และสิ่งที่ควรลดเมื่อลิงก์ตึง

ตัวเลขทุกตัวในหน้านี้เป็นการประเมิน ตัวเลขมาจาก สูตรที่แสดงด้านล่าง ไม่ได้มาจากการวัด encoder, เครือข่าย หรืออุปกรณ์ของคุณ ให้ถือเป็นข้อมูลตั้งต้นในการวางแผน แล้วตรวจสอบกับไปป์ไลน์ของคุณเอง

ข้อมูลนำเข้า

อธิบายสตรีม

ความละเอียดที่ตั้งไว้

Frame rate

Codec

Bandwidth ที่มี

Mbps

Round-trip time (RTT)

1 · งบ encode

งบต่อเฟรม

33.3ms ต่อเฟรม

1000 ÷ 30 fps

เวลา encode ด้วยฮาร์ดแวร์ทั่วไป ~5 ms

ส่วนที่เหลือภายในเฟรม 28.3 ms

2 · ความต้องการ bitrate

bitrate โดยประมาณ

6.8Mbps

ช่วง 5–8.7 Mbps โดยสมมติค่ากลาง 0.11 bits per pixel per frame (bpp)

Bandwidth ที่มี 20 Mbps

ส่วนที่เหลือเหนือค่าประเมินบน 11.3 Mbps

3 · งบ latency

ค่าประเมิน end-to-end

150ms

ราวกับค่าอ้างอิงการโต้ตอบ 150 ms

การแบ่ง latency — เป็นการประเมิน ไม่ใช่ benchmark
ขั้น	ค่าประเมิน	สัดส่วน	เกณฑ์	สถานะ

4 · การแลกเปลี่ยนเมื่อลดคุณภาพ

รักษาความละเอียด หรือรักษา frame rate?

ที่ 20 Mbps ด้วยสมมติฐาน bpp กลางสำหรับ H.264 กลยุทธ์ลดคุณภาพสองแบบให้ผลดังนี้:

ผลลัพธ์โดยประมาณที่ bandwidth ที่กำหนด
ตัวชี้วัด	A · รักษาความละเอียด ลด fps	B · รักษา fps ลดความละเอียด
Frame rate	30 fps	30 fps
ความละเอียด	1920 × 1080	1920 × 1080
สเกลเทียบกับอินพุต	100%	100%
bitrate โดยประมาณ	~6.8 Mbps	~6.8 Mbps
เวลา encode โดยประมาณ	~5 ms	~5 ms
encode เทียบกับงบเฟรม	—	—
ข้อจำกัดที่ผูกอยู่	—	—
latency end-to-end โดยประมาณ	~150 ms	~150 ms
การเคลื่อนไหว	ลื่นไหลที่อัตราเป้าหมาย	คงจังหวะเป้าหมายไว้
ตัวอักษรและรายละเอียดเล็ก	ความละเอียดเต็ม; ตัวอักษรและ UI ยังคมชัด	ไม่เปลี่ยนแปลง
เหมาะที่สุดสำหรับ	เอกสาร โค้ด แดชบอร์ด สไลด์	วิดีโอ แอนิเมชัน การเคลื่อนไหวเคอร์เซอร์ cloud gaming

สูตรและสมมติฐาน — เปิดเพื่อตรวจสอบการคำนวณ

งบเฟรม

budget_ms = 1000 / fps

เวลาที่แต่ละเฟรมใช้ในขั้น encode ได้ก่อนเฟรมถัดไปจะครบกำหนด

Bitrate

Mbps = width × height × fps × bpp / 1,000,000

การประเมินคร่าว ๆ เพื่อวางแผน เนื้อหาหน้าจอที่มีพื้นที่นิ่งขนาดใหญ่อาจใช้ต่ำกว่านี้มาก; noise, การเคลื่อนไหว และ chroma 4:4:4 อาจใช้สูงกว่า

fps สูงสุดที่ความละเอียดเต็ม

max_fps = bandwidth_bps / (width × height × bpp)

คอลัมน์ A คงความละเอียดอินพุตและแก้หาอัตราเฟรมที่ลิงก์รับได้

ตัวคูณลดสเกล

scale = √( bandwidth_bps / (width × height × fps × bpp) )

คอลัมน์ B คงอัตราเฟรมเป้าหมายและแก้หาจำนวนพิกเซล สเกลเชิงเส้นคือรากที่สองของอัตราส่วนพื้นที่

สเกลที่พอดีกับ encode

scale_enc = √( 2,073,600 × (budget_ms / base_ms)^(1 / 0.85) / pixels )

คอลัมน์ B ใช้ค่าที่น้อยกว่าระหว่างสเกล bandwidth และสเกลที่พอดีกับ encode เพื่อให้อัตราเฟรมเป้าหมายพอดีกับ encoder ด้วย หากอินพุตพอดีอยู่แล้ว สเกลจะถูกจำกัดที่ 100%

เวลา encode

t ≈ base_ms × (pixels / 2,073,600)^0.85

การประเมินเพื่อวางแผนสำหรับ encoder ฮาร์ดแวร์ ค่าฐานที่ 1080p: H.264 5 ms, HEVC 8 ms, AV1 11 ms อุปกรณ์ preset เนื้อหา และอุณหภูมิเปลี่ยนค่านี้มาก

เวลา decode

decode ≈ 0.6 × encode

ตัวคูณความไม่สมมาตรคร่าว ๆ; decoder ฮาร์ดแวร์มักเร็วกว่า encoder

latency รวม

capture + encode + RTT/2 + 2 × frame + decode + render

Capture คือหนึ่งช่วงเฟรม เครือข่ายคือการเดินทางขาเดียว Jitter buffer คือสองเฟรม Render คือ 16.7 ms สำหรับจอ 60 Hz

สมมติฐาน bpp

H.264 0.08–0.14 · HEVC 0.05–0.09 · AV1 0.035–0.07

Bits per pixel per frame เครื่องคำนวณใช้ค่ากลางสำหรับผลลัพธ์ค่าเดียว และใช้ปลายทั้งสองของช่วงสำหรับแถบ bitrate

นี่คือการประเมิน ไม่ใช่การวัด ไม่มี encoder อุปกรณ์ หรือเครือข่ายใดถูก benchmark ที่นี่
แถบ bpp เป็นสมมติฐานเพื่อวางแผนสำหรับวิดีโอโต้ตอบและเนื้อหาหน้าจอ ไม่ใช่การรับประกันของ codec และไม่รวมพฤติกรรม rate control
เวลา encode และ decode ถือว่าใช้ฮาร์ดแวร์เร่ง โดยเฉพาะ AV1 อาจ fallback ไปซอฟต์แวร์ ซึ่งเวลา encode อาจสูงกว่าหลายเท่า
คอลัมน์ A ถูกจำกัดด้วยค่าที่ต่ำกว่าระหว่างขีดจำกัด bandwidth และ throughput ของ encoder (1000 / เวลา encode) คอลัมน์ B ลดสเกลจนทั้ง bitrate และเวลา encode ต่อเฟรมพอดี
latency เครือข่ายจำลองเป็น RTT ÷ 2 โดยไม่มีการส่งซ้ำ การเข้าคิว หรือความแออัด Wi-Fi, relay และ uplink ที่ทำงานหนักเพิ่มความหน่วงจริง
Jitter buffer ถูกตรึงไว้ที่สองเฟรม การใช้งานจริงมักใช้หนึ่งถึงห้าเฟรม หรือปรับ buffer ระหว่างรัน
เส้น 150 ms เป็นค่าอ้างอิงการโต้ตอบทั่วไป ไม่ใช่ข้อบังคับ cloud gaming มักตั้งเป้าต่ำกว่า; การซัพพอร์ตระยะไกลและงานนำเสนอรับค่าที่สูงกว่าได้
การเพิ่ม frame rate ทำให้ช่วงเฟรมและพจน์ jitter เล็กลงแต่เพิ่ม bitrate การลด frame rate ให้ผลตรงกันข้าม

ขั้นต่อไป

ต้องการ checklist ฉบับเต็มและสคริปต์วัดค่าหรือไม่?

Checklist ครอบคลุมขั้นของไปป์ไลน์ข้างต้น สัญญาณที่ควรเก็บ และวิธี อ่านโดยไม่เดา สคริปต์คือสิ่งที่ควรรันบนบิลด์ของคุณเอง

รับ checklist — โค้ด FIRST50 →

ลิงก์มีโค้ดส่วนลด FIRST50 หน้านี้ไม่ใช้สคริปต์ติดตาม

คำถามที่พบบ่อยเกี่ยวกับการแชร์หน้าจอ

ทำไมการแชร์หน้าจอของฉันกระตุกทั้งที่ packet loss 0%?

Packet loss เป็นเพียงแหล่งหน่วงแหล่งหนึ่ง โมเดลนี้แยกเวลา encode, bitrate และ jitter ออกจากกัน: หากเวลา encode เกินงบต่อเฟรมที่ 1000 ÷ fps ให้คาดว่าจะมีเฟรมหลุดหรืออัตราเฟรมจริงต่ำลง; เมื่อ bandwidth เป็นข้อจำกัด สตรีมจะลดคุณภาพแทน Jitter buffer ถูกตรึงไว้ที่สองเฟรม และการประเมิน latency ไม่รวมการส่งซ้ำ การเข้าคิว และความแออัด ดังนั้น Wi-Fi, relay และ uplink ที่ทำงานหนักสามารถเพิ่มความหน่วงจริงได้

การแชร์หน้าจอควรตั้งเป้างบ latency เท่าไร?

เส้น 150 ms เป็นค่าอ้างอิงการโต้ตอบที่ใช้กันทั่วไป ไม่ใช่ข้อบังคับ cloud gaming มักตั้งเป้าต่ำกว่า ขณะที่การซัพพอร์ตระยะไกลและงานนำเสนอรับค่าที่สูงกว่าได้ ให้ถือเป็นข้อมูลตั้งต้นแล้วตรวจสอบกับไปป์ไลน์ของคุณ

ความละเอียดหรือ frame rate สำคัญกว่ากันสำหรับการแชร์หน้าจอ?

ขึ้นกับเนื้อหา การคงความละเอียดและลด frame rate เหมาะกับเอกสาร โค้ด แดชบอร์ด และสไลด์; การคง frame rate และลดความละเอียดเหมาะกับวิดีโอ แอนิเมชัน การเคลื่อนไหวเคอร์เซอร์ และ cloud gaming สำหรับตัวอักษรใช้แบบแรก สำหรับการเคลื่อนไหวใช้แบบหลัง