กำลังใช้งาน
จอภาพเสมือนตามหน้าต่างของไคลเอนต์แล้ว
หลายสัปดาห์ที่ผ่านมา โฮสต์ macOS ตรึงจอภาพเสมือนไว้ที่ความละเอียดหน้าจอของไคลเอนต์ ซึ่งหมายความว่าเคอร์เซอร์ของโฮสต์และเคอร์เซอร์ของไคลเอนต์เห็นขนาดไม่ตรงกันทันทีที่ฝั่งใดฝั่งหนึ่งเปลี่ยน เราเขียนตัวจัดการจอภาพเสมือนใหม่ให้พื้นที่ทำงานของโฮสต์ตามพื้นที่หน้าต่างของไคลเอนต์แบบเรียลไทม์ ขนาดเคอร์เซอร์จึงตรงกันข้ามขอบเขตที่ขนาดหน้าต่างใดก็ได้ เหมือนที่ Apple Screen Sharing ทำมาตลอด
จุดตรรกะของจอภาพเสมือน ≡ จุดของพื้นที่หน้าต่างไคลเอนต์ · จำกัดพิกเซลที่ 3840 · Retina 1× หรือ 2× เลือกตามขอบเขตพิกเซลเนทีฟของแต่ละหน้าต่าง
ทดลอง
ทำไมเราจำกัดขอบเขตของจอภาพเสมือนไว้ที่ 3840 พิกเซล
เฟรมเวิร์กภายในของ macOS ที่สร้างโหมดจอภาพสำหรับจอภาพเสมือนมีพฤติกรรมทำลายล้างแบบเงียบ ๆ เมื่อกำหนดมิติสูงสุดตั้งแต่ 4096 ขึ้นไป มันจะสร้างโหมด Retina 2× ปลอมที่ค่าสูงสุดและแย่งแฟลกที่ใช้งานอยู่ จำนวนพิกเซลที่ขอเพิ่มเป็นสองเท่า เรายืนยันจากการทดลองด้วยการตรวจและบันทึกต่อเนื่องสี่คืน 3840 พอดีกับ MacBook Retina แบบเต็มจอทุกรุ่นบวกจอภายนอก 4K และเฟรมเวิร์กหยุดสร้างโหมดปลอม เรายังเฝ้าดูหางของการแจกแจงอยู่
พังจริงตั้งแต่ ≥ 4096 · จำกัด = 3840 · ครอบคลุม MacBook Pro 16″ Retina (3456 × 2234) และจอภายนอก 4K (3840 × 2160)
กำลังใช้งาน
ย้อนกลับไปใช้บิลด์เอนจินสตรีมมิงเดิมหลังการทดลองหนึ่งสัปดาห์
เราสร้างเอนจินสตรีมมิงใหม่บนสาขาที่ใหม่กว่า โดยหวังว่าตรรกะการจัดจังหวะที่อัปเดตจะลดได้อีกสองสามมิลลิวินาทีบนเส้นทางเครือข่ายในเครื่อง แต่บัฟเฟอร์ฝั่งรับกลับแย่ลงในทุกเซสชันระยะไกลที่เราวัด ค่ามัธยฐานแบบต้นทางถึงปลายทางเพิ่มขึ้น 18 ms และความแปรปรวนกว้างขึ้น เราย้อนกลับไปใช้บิลด์เสถียรบน iOS, macOS, Android และ Windows แพตช์ของสาขาใหม่ถูกเก็บเข้าคลังไว้เผื่อพฤติกรรมของต้นทางเปลี่ยน
ความหน่วงมัธยฐานของบิลด์ใหม่ · 64 ms ระยะไกล · มัธยฐานของบิลด์เดิม · 46 ms ระยะไกล · แฟลกการปรับจูนไม่เปลี่ยน
กำลังใช้งาน
ตรวจจับบิตเรตของเครือข่ายในเครื่องเทียบกับระยะไกลแบบปรับตัวจากตัวอย่างไป-กลับตัวแรก
ตอนนี้โฮสต์รอการวัดเวลาไป-กลับครั้งแรกหลังการเชื่อมต่อขึ้น แล้วเลือกหนึ่งในสองขอบเขตบิตเรต ต่ำกว่า 15 ms ถือว่าเป็นการเชื่อมต่อตรงบนเครือข่ายในเครื่อง เริ่มที่ 8 Mbps ต่ำสุด 8 Mbps สูงสุด 30 Mbps สูงกว่า 15 ms ถือว่าผ่านรีเลย์หรืออยู่ไกล เริ่มที่ 2 Mbps ต่ำสุด 300 Kbps สูงสุด 15 Mbps เกณฑ์นี้อยู่ระหว่าง Wi-Fi เครือข่ายเดียวกันกับรีเลย์มือถือหรือข้ามภูมิภาคทุกแบบที่เป็นไปได้ ผลบวกลวงจึงพบน้อยในเทเลเมทรีรุ่นเบต้า
ตรงในเครื่อง · 1 – 5 ms · Wi-Fi เครือข่ายเดียวกัน · 5 – 10 ms · รีเลย์ในภูมิภาค · 30 – 80 ms · 4G · 40 – 100 ms
กำลังใช้งาน
H.265 ฮาร์ดแวร์บน AMD เป็นตัวเข้ารหัสหลักของโฮสต์ Windows
หลังการประลองกับตัวเข้ารหัสคู่แข่งอย่างยาวนาน H.265 ฮาร์ดแวร์บน AMD ชนะทุกเกณฑ์วัดของโฮสต์ Windows ที่เราสนใจ เวลาเข้ารหัสมัธยฐานต่ำกว่า สไปก์ของคีย์เฟรมต่ำกว่า และพรีเซ็ตบิตเรตคงที่ที่หน่วงต่ำเป็นพิเศษทำงานคาดเดาได้เมื่อบัฟเฟอร์ถูกกดดัน H.264 ยังคงเป็นตัวสำรองเมื่อ GPU ไม่เห็นด้วย ปิด B-frame เปิดแฟลก low-delay ตัวเข้ารหัสส่งออกหนึ่งเฟรมต่อหนึ่งจังหวะแคปเจอร์เสมอ
บิตเรต · คงที่ 8 Mbps · fps · 60 · บัฟเฟอร์ · 1 เฟรม · B-frame · 0 · พรีเซ็ต · หน่วงต่ำเป็นพิเศษ
เก็บเข้าคลัง
ทำไมเราเลิกบัฟเฟอร์เฟรมไปเลย
รีโมทเดสก์ท็อปไม่ใช่วิดีโอคอล ทุกเฟรมคือสถานะหน้าจอล่าสุด เฟรมเก่าคือคำโกหกโดยนิยาม เราสร้างเส้นทางฝั่งรับใหม่ให้ไม่มีบัฟเฟอร์เล่น เฟรมมาถึง ถอดรหัส เรนเดอร์ ตามลำดับนั้น ในช่วงเฟรมเดียวกัน แพ็กเก็ตที่หายจะถูกส่งซ้ำทันทีถ้ายังไปถึงทันเวลา ถ้าไม่ทัน Remio จะข้ามมันแล้วขอเฟรมใหม่แทนที่จะรอ เรายอมรับการค้างสั้น ๆ เป็นครั้งคราว เราไม่ยอมรับภาษีมิลลิวินาทีคงที่ของคิว
บังคับความหน่วงการเล่น · ต่ำสุด 0 / สูงสุด 0 · ความหน่วงการเล่นขั้นต่ำ · 0 · แพ็กเก็ตที่หายส่งซ้ำถ้าทันเวลา ไม่เช่นนั้นขอเฟรมใหม่
เก็บเข้าคลัง
งบความหน่วง เขียนไว้เป็นครั้งแรก
เรานั่งในห้องแล้วคิดย้อนกลับจากตัวเลขที่อยากให้ผู้ใช้รู้สึก ต่ำกว่ายี่สิบมิลลิวินาทีจากกระจกถึงกระจกในเซสชันเครือข่ายในเครื่องทั่วไป แคปเจอร์ เข้ารหัส จัดจังหวะ ส่ง บัฟเฟอร์รับ ถอดรหัส เรนเดอร์ เราเขียนแต่ละขั้นลงไปและให้งบมิลลิวินาทีที่วัดเทียบได้ รายการส่วนใหญ่ในบันทึกนี้มาจากการปกป้องตัวเลขเหล่านั้นบนทราฟฟิกจริง
แคปเจอร์ · 1 ms · เข้ารหัส · 3 ms · การปล่อยจังหวะเป็นชุด · ≤ 10 ms · บัฟเฟอร์รับ · 0 ms · ถอดรหัส · 2 ms · เรนเดอร์ · 1 ms
