✦लैब · इंजीनियरिंग लॉग

पिक्सल पाइपलाइन से नोट्स।

Remio को एक छोटी टीम सार्वजनिक रूप से बना रही है। यह कामकाजी लॉग है — कैप्चर के वे रास्ते जिन्हें हमने खोलकर देखा, एनकोडर की वे सेटिंग जिन्होंने हमें चौंकाया, लेटेंसी बजट जो हमने तोड़े और दोबारा बनाए। नई प्रविष्टियां ऊपर हैं; पुरानी जैसी लिखी गई थीं वैसी ही रहती हैं, भले हमने बाद में अपनी राय बदल ली हो।

आख़िरी अपडेट 2026-05-197 प्रविष्टियांकालानुक्रमिक, नई सबसे पहले

✦शोध नोट्स

इंजीनियरिंग लॉग, क्रम से।

हर प्रविष्टि तारीख़वार, स्थिति-सहित और अपने आप में पूर्ण है। शिप हो चुका का मतलब बदलाव नवीनतम बिल्ड में लाइव है, प्रयोग का मतलब हम अभी भी माप रहे हैं, और संग्रहीत का मतलब हम आगे बढ़ चुके हैं।

शिप हो चुका

वर्चुअल डिस्प्ले अब क्लाइंट विंडो के साथ चलता है।

हफ़्तों तक macOS होस्ट ने अपना वर्चुअल डिस्प्ले क्लाइंट स्क्रीन के रेज़ोल्यूशन पर स्थिर रखा, जिसका मतलब था कि दोनों में से किसी के बदलते ही होस्ट कर्सर और क्लाइंट कर्सर आकार पर असहमत हो जाते थे। हमने वर्चुअल-डिस्प्ले मैनेजर दोबारा लिखा ताकि होस्ट का वर्कस्पेस रीयल-टाइम में क्लाइंट विंडो कैनवास का अनुसरण करे। अब किसी भी विंडो आकार पर सीमा के आर-पार कर्सर के आकार मेल खाते हैं, जैसा Apple Screen Sharing हमेशा से करता आया है।

वर्चुअल डिस्प्ले के लॉजिकल पॉइंट ≡ क्लाइंट विंडो कैनवास पॉइंट  ·  पिक्सल क्लैंप 3840  ·  Retina 1× या 2× हर विंडो के नेटिव पिक्सल लिफ़ाफ़े के हिसाब से चुना जाता है

प्रयोग

हमने वर्चुअल-डिस्प्ले का लिफ़ाफ़ा 3840 पिक्सल पर क्यों सीमित किया।

वर्चुअल डिस्प्ले के लिए डिस्प्ले मोड बनाने वाले आंतरिक macOS फ़्रेमवर्क का एक चुपचाप बिगाड़ने वाला व्यवहार है: जब उसे 4096 या उससे ऊपर का अधिकतम आयाम दिया जाता है, तो वह अधिकतम पर एक काल्पनिक 2× Retina मोड गढ़ लेता है और सक्रिय फ़्लैग छीन लेता है। मांगा गया पिक्सल गिनती दोगुनी हो जाती है। हमने चार रातों के प्रोब-और-लॉग से इसे प्रयोग द्वारा पक्का किया। तीन हज़ार आठ सौ चालीस हर Retina MacBook फ़ुलस्क्रीन के साथ एक 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। यह सीमा उसी-नेटवर्क WiFi और किसी भी संभावित सेल्युलर या क्षेत्र-पार रिले के बीच बैठती है, इसलिए बीटा टेलीमेट्री में ग़लत अनुमान दुर्लभ रहे हैं।

लोकल सीधा · 1 – 5 ms  ·  WiFi उसी-नेट · 5 – 10 ms  ·  क्षेत्रीय रिले · 30 – 80 ms  ·  4G · 40 – 100 ms

शिप हो चुका

Windows-होस्ट के प्राथमिक एनकोडर के रूप में AMD पर हार्डवेयर H.265।

प्रतिस्पर्धी एनकोडरों के साथ लंबी भिड़ंत के बाद, AMD पर हार्डवेयर H.265 ने हर उस Windows-होस्ट बेंचमार्क में जीत हासिल की जिसकी हमें परवाह थी: कम मध्यिका एनकोड टाइम, कम कीफ़्रेम स्पाइक, और अल्ट्रा-लो-लेटेंसी कॉन्स्टेंट-बिटरेट प्रीसेट बफ़र दबाव में अनुमानित व्यवहार करता है। जब GPU असहमत हो तो H.264 फ़ॉलबैक रहता है। B-फ़्रेम बंद हैं। लो-डिले फ़्लैग चालू है। एनकोडर हर कैप्चर टिक पर ठीक एक फ़्रेम देता है।

बिटरेट · 8 Mbps स्थिर  ·  fps · 60  ·  बफ़र · 1 फ़्रेम  ·  B-फ़्रेम · 0  ·  प्रीसेट · अल्ट्रा-लो-लेटेंसी

संग्रहीत

हमने फ़्रेम बफ़र करना पूरी तरह क्यों बंद किया।

रिमोट डेस्कटॉप वीडियो कॉल नहीं है। हर फ़्रेम स्क्रीन की ताज़ा स्थिति है। पुराना फ़्रेम, परिभाषा से, एक झूठ है। हमने रिसीव पाथ इस तरह दोबारा बनाया कि कोई प्लेआउट बफ़र ही नहीं है: फ़्रेम आता है, डिकोड होता है, रेंडर होता है, इसी क्रम में, उसी फ़्रेम अंतराल पर। खोए फ़्रेम पुराने के पुनः-प्रेषण की बजाय नया कीफ़्रेम मांगते हैं। हम कभी-कभार की छोटी फ़्रीज़ स्वीकार करते हैं। हम क़तार का लगातार चलता मिलीसेकंड का कर स्वीकार नहीं करते।

ज़बरन प्लेआउट डिले · न्यूनतम 0 / अधिकतम 0  ·  न्यूनतम प्लेआउट डिले · 0  ·  लॉस पर कीफ़्रेम अनुरोध  ·  कोई पैकेट पुनः-प्रेषण नहीं

संग्रहीत

लेटेंसी बजट, पहली बार लिखित रूप में।

हम एक कमरे में बैठे और उस संख्या से उल्टा काम करते गए जो हम चाहते थे यूज़र महसूस करें — सामान्य लोकल-नेटवर्क सेशन पर, ग्लास-टू-ग्लास, बीस मिलीसेकंड से कम। कैप्चर, एनकोड, पेस, सेंड, रिसीव बफ़र, डिकोड, रेंडर। हमने हर एक को लिखा और उसे एक मिलीसेकंड बजट दिया जिसके ख़िलाफ़ हम माप सकें। इस लॉग की ज़्यादातर प्रविष्टियां प्रोडक्शन ट्रैफ़िक में उन्हीं संख्याओं का बचाव करने से आती हैं।

कैप्चर · 1 ms  ·  एनकोड · 3 ms  ·  पेसिंग बर्स्ट · ≤ 10 ms  ·  रिसीव बफ़र · 0 ms  ·  डिकोड · 2 ms  ·  रेंडर · 1 ms

✦सिग्नल लिफ़ाफ़ा

हम क्या नापते हैं, सेशन दर सेशन।

ये चार संख्याएं हर रिलीज़ नोट में साथ चलती हैं क्योंकि वे बताती हैं कि कनेक्शन असल में कैसा लगता है — न कि स्पेक शीट पर वह क्या दावा करता है।

स्ट्रीम रेज़ोल्यूशन
6K तकनेटिव पिक्सल लिफ़ाफ़ा, हर विंडो के लिए 1× या 2× Retina चुना जाता है
फ़्रेम रेट
120 fps तकस्थिर लय, B-फ़्रेम बंद, हर फ़्रेम के लिए एक कैप्चर टिक
प्रोसेसिंग लेटेंसी, लोकल नेटवर्क
~8 msडिवाइस-से-डिवाइस सीधे कनेक्शन पर आंतरिक रूप से मापा गया — बाक़ी आपके डिस्प्ले का अपना 60 Hz रिफ़्रेश है
ट्रांसपोर्ट एन्क्रिप्शन
एंड-टू-एंडहर बार नई सेशन की के साथ एंड-टू-एंड एन्क्रिप्शन
Remio ऐप आइकन

बिल्ड को फ़ॉलो करें, ब्रोशर को नहीं।

लैब तब अपडेट होती है जब कुछ पहुंचता है या कुछ टूटता है। अगर यह तिमाही न्यूज़लेटर से ज़्यादा काम का लगता है, तो डाउनलोड लिंक एक क्लिक दूर है — और लंबे संस्करण के लिए सिक्योरिटी व्हाइटपेपर भी।

अकाउंट नहीं चाहिएकोई ट्रैकिंग पिक्सल नहींसार्वजनिक रूप से बना