यह फ़ाइल ट्रांसफर इंटरनेट का बिल्कुल इस्तेमाल नहीं करता है (डेसिमेन)
BBetter Stack
컴퓨터/소프트웨어가전제품/카메라AI/미래기술
스크립트
00:00:00यहाँ एक सवाल है। बिना किसी नेटवर्क और बिना किसी
00:00:05भौतिक उपकरणों जैसे यूएसबी स्टिक के? खैर, इसका जवाब ऑप्टिकल फ़ाइल ट्रांसफर है। एवन नाम के एक डेवलपर
00:00:13क्रॉली नामक एक डेवलपर ने डेसिमैन नामक एक टूल बनाया है, जो एक डिवाइस से दूसरी डिवाइस में
00:00:19सिर्फ क्यूआर कोड फ्लैश करके और उन्हें वापस पढ़कर फ़ाइल भेजने में सक्षम है। यह एक बेहद शानदार फ़ाइल ट्रांसफर तकनीक है
00:00:26और यह कुछ काफी चतुर इंजीनियरिंग रणनीतियों का उपयोग करती है। तो आज के वीडियो में, हम नजर डालेंगे
00:00:31डेसिमैन पर, देखेंगे कि यह कैसे काम करता है और यह देखने के लिए अलग-अलग परिदृश्यों पर इसका परीक्षण करेंगे कि ऑप्टिकल फ़ाइल
00:00:37ट्रांसफर वास्तव में कितना शक्तिशाली है। यह बहुत मजेदार होने वाला है, तो आइए इसमें गोता लगाएँ।
00:00:46तो डेसिमैन इस तरह काम करता है। एक डिवाइस अपनी स्क्रीन पर क्यूआर कोड जैसे फ्रेम की एक धारा प्रदर्शित करती है
00:00:53और दूसरा डिवाइस उस पर कैमरा पॉइंट करता है और उन्हें वापस एक फ़ाइल में डिकोड करता है। तो इसमें कोई नेटवर्क स्टैक
00:01:00शामिल नहीं है। इसलिए यदि आपको कभी एयर गैप डिवाइस के साथ फ़ाइल का आदान-प्रदान करने की आवश्यकता हो, तो ऐसा करने का यह एकमात्र तरीका है
00:01:06बिना यूएसबी ड्राइव जैसे किसी भी बाहरी डिवाइस को भौतिक रूप से प्लग इन किए। और विचार यह है कि आप
00:01:12अपनी फ़ाइल को क्यूआर कोड के अनुक्रम के रूप में एनकोड करते हैं, उन्हें एक के बाद एक स्क्रीन पर फ्लैश करते हैं, और दूसरे छोर पर कैमरे से
00:01:19प्रत्येक फ्रेम को कैप्चर और डिकोड करवाते हैं। अब यह सरल लग सकता है, लेकिन जटिलता इस तथ्य से उत्पन्न होती है
00:01:26कि कैमरे वास्तव में तुरंत कैप्चर नहीं करते हैं, और स्क्रीन तुरंत रिफ्रेश नहीं होती हैं।
00:01:32इसलिए आप दो अलग-अलग हार्डवेयर टुकड़ों को एक-दूसरे के खिलाफ दौड़ा रहे हैं, और यदि वे सिंक से बाहर हो जाते हैं,
00:01:38तो फ्रेम दूषित हो जाते हैं या पूरी तरह से छूट जाते हैं। लेकिन इस समस्या का डेसिमैन का जवाब फाउंटेन कोडिंग नामक एक विधि है।
00:01:46फ्रेम एक, फ्रेम दो, फ्रेम तीन भेजने और यह उम्मीद करने के बजाय कि हर एक लैंड करता है,
00:01:53यह एन्कोडेड फ्रेम की एक प्रभावी रूप से असीमित धारा उत्पन्न करता है जहाँ प्रत्येक फ्रेम मूल फ़ाइल के टुकड़ों का एक गणितीय मिश्रण है
00:02:00न कि उसके किसी विशिष्ट हिस्से का। इसका मतलब है कि कोई भी एकल फ्रेम अपूरणीय नहीं है।
00:02:07रिसीवर को विशेष रूप से फ्रेम संख्या 47 की आवश्यकता नहीं है, उसे केवल पर्याप्त फ्रेम की आवश्यकता है, जो भी लैंड होते हैं।
00:02:14और यदि आप उनमें से आधे को याद करते हैं, तो इससे कोई फर्क नहीं पड़ता। यह तब तक प्रसारण जारी रखता है जब तक रिसीवर ने पर्याप्त संग्रह नहीं कर लिया है।
00:02:22लेकिन यह दृष्टिकोण किसी भी तरह से रामबाण नहीं है। इस पद्धति के साथ, हम कितना डेटा स्थानांतरित कर सकते हैं, इसकी एक सीमा है।
00:02:29डिफ़ॉल्ट रूप से, डेसिमैन का प्रेषक 60 फ्रेम प्रति सेकंड पर प्रति फ्रेम 2953 बाइट्स पुश करता है।
00:02:37यदि आप उस पर गणित करते हैं, तो आपको लगभग 177 किलोबाइट प्रति सेकंड की सैद्धांतिक सीमा मिलती है।
00:02:44फाउंटेन कोडिंग से ओवरहेड में कारक, क्योंकि उनमें से कुछ मिश्रित फ्रेम डिज़ाइन द्वारा अनिवार्य रूप से अतिરિક्त हैं।
00:02:51और जो आपके पास बचा है वह वह संख्या है जिसका डेसिमैन की रीडमी फ़ाइल वास्तव में दावा करती है।
00:02:56फोन से फोन मापने पर यह लगभग 128 किलोबाइट प्रति सेकंड पर पीक करता है।
00:03:02और इसका कारण यह है कि यह विशेष रूप से 2953 बाइट चंक का उपयोग करता है क्योंकि यह क्यूआर कोड संस्करण 40 से मेल खाता है,
00:03:11सबसे बड़ा मानक क्यूआर आकार, एक ही फ्रेम में पैक व्यक्तिगत मॉड्यूल का 177 बाय 177 ग्रिड।
00:03:20और यहीं से असली ट्रेड-ऑफ सामने आता है। यदि आप एक फ्रेम में अधिक डेटा क्रैम करते हैं, तो आपको एक ही फ़ाइल भेजने के लिए कुल मिलाकर कम फ्रेम की आवश्यकता होती है
00:03:26जिसका अर्थ है कि इसे वापस पढ़ने वाले किसी भी कैमरे को अधिक रिज़ॉल्यूशन की आवश्यकता है,
00:03:33एक स्थिर हाथ, और एक मॉड्यूल को दूसरे से बताने के लिए एक तेज फोकस।
00:03:38तो पूरी प्रणाली वास्तव में तीन चर के बीच एक संतुलनकारी अधिनियम है।
00:03:42आप कितने फ्रेम प्रति सेकंड भेज रहे हैं, उनमें से प्रत्येक फ्रेम कितना सघन है, और प्राप्त करना कितना अच्छा है
00:03:49कैमरा वास्तव में उस घनत्व को हल करने में है। और डेसिमैन डिफ़ॉल्ट रूप से डायल किए गए एक विशिष्ट संतुलन के साथ जहाज भेजता है,
00:03:57और यह एक विशिष्ट परिदृश्य के लिए तैयार किया गया है, जो कि जैसा मैंने पाया, वह परिदृश्य नहीं है जिसमें मैंने इसका परीक्षण किया था।
00:04:03तो यहाँ मेरा सेटअप है: प्रेषक के रूप में एक लैपटॉप स्क्रीन, सामान्य बांह की लंबाई की दूरी पर बैठी है,
00:04:09जैसे आप वास्तव में इसका उपयोग अभ्यास में करेंगे। इस सेटअप के साथ, मेरा ट्रांसफर लगभग तीन किलोबाइट प्रति सेकंड पर सीमित हो गया।
00:04:16पारेषित तख्ते का लगभग एक से दो प्रतिशत वास्तव में डिकोड किया जा रहा है। बाकी पर कब्जा कर लिया जाता है और फेंक दिया जाता है।
00:04:23अब यहाँ तीन चीजें हैं जो हमारे खिलाफ ढेर हो रही हैं। पहली और सबसे बड़ी बाधा फ्रेम दर बेमेल है।
00:04:30प्रेषक 60 फ्रेम प्रति सेकंड धक्का दे रहा है, लेकिन मेरे फोन का कैमरा 30 पर कैप्चर करता है। आप 60 अलग-अलग छवियों का नमूना नहीं ले सकते हैं
00:04:38एक सेंसर के साथ जो केवल 30 ही प्राप्त कर रहा है। और यह उनमें से आधे को याद करने से भी बदतर है, क्योंकि प्रत्येक पर एक्सपोजर विंडो
00:04:45कैप्चर किया गया फ्रेम स्क्रीन पर दो अलग-अलग क्यूआर कोड को स्ट्रैडल करता है। इसलिए कैमरा साफ-साफ फ्रेम से नहीं चूकता। यह दो को एक में मिला देता है।
00:04:56और main.ts फ़ाइल में, एक नोट भी है जो कहता है कि आईओएस चुपचाप 30 फ्रेम प्रति सेकंड डिलीवर करेगा, तब भी जब ऐप स्पष्ट रूप से कैमरे से 60 मांगता है।
00:05:07कैमरा आपको वह नहीं देता जो आपने अनुरोध किया था, और कोड पहले से ही इसका समाधान करता है।
00:05:12और उसी फ़ाइल में थोड़ा आगे, एक टिप्पणी है जो मूल रूप से भविष्यवाणी करती है कि मेरे पहले प्रयास में मेरे साथ क्या हुआ था।
00:05:19डिफ़ॉल्ट, जो प्रति सेकंड 60 फ्रेम पर प्रति फ्रेम 2953 बाइट्स हैं, विशेष रूप से करीबी सीमा फोन से फोन डेमो के लिए तैयार किए गए हैं।
00:05:29और उसी संयोजन से बांह की लंबाई पर एक साधारण मॉनिटर पर संघर्ष करने की उम्मीद की जाती है।
00:05:35दूसरे शब्दों में, प्रोजेक्ट ने मुझे बताया कि ऐसा होगा। मैंने इसे देखने के लिए कोड में काफी दूर तक स्क्रॉल नहीं किया था।
00:05:41भेजने वाले पक्ष पर, 60 हर्ट्ज लैपटॉप पैनल में विपरीत दिशा में समान समस्या है। और एलसीडी पिक्सेल को पूरी तरह से संक्रमण रंग ग्रे से ग्रे में काफी समय लगता है।
00:05:51और उस सेटिंग समय का मतलब है कि पैनल पूरी तरह से एक कोड पर नहीं पहुंचा है इससे पहले कि अगला उस पर पेंट करना शुरू कर दे।
00:05:58तो आपको गोस्टिंग कलाकृतियाँ मिल रही हैं। और दूसरी समस्या कैमरा रिज़ॉल्यूशन बनाम कोड घनत्व है।
00:06:042953 बाइट्स क्यूआर संस्करण 40 है, लेकिन विश्वसनीय डिकोडिंग को प्रति मॉड्यूल लगभग तीन से चार कैमरा पिक्सेल की आवश्यकता होती है, जो अकेले कोड के लिए तेज फोकस में 600 प्लस पिक्सेल पार हो जाता है।
00:06:20और बांह की लंबाई पर आयोजित लैपटॉप स्क्रीन शायद ही फोन के कैमरे के फ्रेम के इतने हिस्से को भरती है, लेकिन कम दूरी पर फोन से फोन आसानी से पूरे विजुअलफाइंडर को भर देता है।
00:06:30और तीसरी समस्या चमक और कंट्रास्ट है। यह एक माध्यमिक मुद्दा है, लेकिन अगर रिसीवर का बाइनराइज़र छवि को स्पष्ट रूप से थ्रेशोल्ड करता है तो मदद मिलती है, लेकिन यह अभी भी फ्रेम दर बेमेल या कम आकार के कोड को ठीक नहीं कर सकता है।
00:06:44तो अब वही ट्रांसफर करने की कोशिश करते हैं, लेकिन इस बार एक फोन से दूसरे फोन में।
00:06:50तो केवल एक चीज जो बदलती है वह प्रेषक है। यह एक छोटी उज्ज्वल ओएलईडी स्क्रीन है जो करीब आयोजित की जाती है, प्राप्त करने वाले फोन के पूरे फ्रेम को भरती है।
00:06:58अब कैमरा वास्तव में अपनी वास्तविक फ्रेम दर के करीब आ सकता है।
00:07:02कोड उच्च रिज़ॉल्यूशन पर फ्रेम को भरता है और लड़ने के लिए कोई एलसीडी गोस्टिंग नहीं है।
00:07:07यह वह परिदृश्य है जिसके तहत रीडमी फ़ाइल में 128 किलोबाइट प्रति सेकंड की संख्या वास्तव में मापी गई थी।
00:07:14रिसीवर के कोड में एक छोटा लेकिन वास्तव में उपयोगी विवरण भी है।
00:07:18यह कैप्चर एफपीएस और डिकोड एफपीएस की अलग से रिपोर्ट करता है। कैप्चर हमें बताता है कि कैमरा भौतिक रूप से क्या देख रहा है।
00:07:26डिकोड आपको बताता है कि इसका कितना हिस्सा वास्तव में उपयोग करने योग्य है।
00:07:30जब वे दो नंबर एक दूसरे से अलग हो जाते हैं, तो कैप्चर स्वस्थ रहता है जबकि डिकोड क्रेटर होता है,
00:07:35आप फ्रेम कितने घने हैं और कैमरा उस सीमा पर क्या हल कर सकता है के बीच एक बेमेल को देख रहे हैं।
00:07:42इसलिए यदि लैपटॉप से फोन आपका वास्तविक उपयोग का मामला है, तो समाधान प्रेषक के पक्ष में उन तीन चर को पुनर्संतुलित करना है।
00:07:50आपको प्रति फ्रेम बाइट्स को 1465 तक कम करना चाहिए, जो बड़े, अधिक क्षमाशील मॉड्यूल के साथ एक मोटे क्यूआर संस्करण से मेल खाता है।
00:07:59और फिर कैमरे के 30 एफपीएस की छत से नीचे जानबूझकर प्रसारित एफपीएस को 24 तक छोड़ दें।
00:08:07इसलिए फ्रेम एक दूसरे में सम्मिश्रण करने के बजाय एक समय में साफ तौर पर नमूना प्राप्त करते हैं।
00:08:12और जैसा कि आप देख सकते हैं, इन नंबरों को कम करने से बहुत बड़ा थ्रूपुट मिलता है।
00:08:16तो यह सिर्फ आपको दिखाता है कि ऑप्टिकल फ़ाइल ट्रांसफर एक आकार-फिट-सभी समाधान नहीं है।
00:08:21आपके द्वारा उपयोग किए जा रहे हार्डवेयर के आधार पर आपको हर उपयोग के मामले के लिए मैन्युअल रूप से इसे ट्विक करना होगा।
00:08:26तो यह आपके पास है, दोस्तों।
00:08:27वह संक्षेप में डेसमान है।
00:08:29कुल मिलाकर, यह खुदाई करने के लिए एक सही मायने में मजेदार परियोजना थी।
00:08:32ऑप्टिकल फ़ाइल ट्रांसफर एक बहुत ही शानदार तकनीक है।
00:08:36और यहाँ वास्तविक मामले के परिदृश्य में लागू किए जा रहे फ़ाउंटेन कोडिंग अवधारणा को देखना वास्तव में दिलचस्प था।
00:08:44और जब मैं इस परियोजना की खोज कर रहा था, तो मैं यह भी सोच रहा था, आप वास्तव में इस तरह के टूल का उपयोग कहाँ करेंगे?
00:08:49मुझे लगता है कि स्पष्ट जवाब एयर-गैप ट्रांसफर के लिए होगा जहाँ आप जानबूझकर बिल्कुल भी नेटवर्क कनेक्शन नहीं चाहते हैं।
00:08:57या शायद ऐसे उपकरण जिनमें ब्लूटूथ या वाई-फाई भी नहीं है जैसे पुराने हार्डवेयर या एम्बेडेड सिस्टम।
00:09:04मेरा मतलब है, कहीं भी जहाँ एक स्क्रीन और एक कैमरा केवल दो चीजें हैं जिन पर आप भरोसा कर सकते हैं।
00:09:10लेकिन आप इस टूल के बारे में क्या सोचते हैं?
00:09:11क्या आपने पहले ऑप्टिकल ट्रांसफर टूल का इस्तेमाल किया है?
00:09:14क्या आपको इसके लिए कोई वास्तविक जीवन का अनुप्रयोग दिखाई देता है?
00:09:17हमें नीचे कमेंट सेक्शन में बताएं।
00:09:19और दोस्तों, यदि आपको इस प्रकार के तकनीकी विवरण पसंद हैं, तो कृपया वीडियो के नीचे लाइक बटन को स्मैश करके मुझे बताएं।
00:09:25और साथ ही हमारे चैनल को सब्सक्राइब करना न भूलें।
00:09:28यह बेटरस्टैक से एंड्रस रहा है और मैं आपको अगले वीडियो में मिलूंगा।
00:09:34मैं आपको अगले वीडियो में मिलूंगा।