पाँच रुकावटें — Claude Code से कैमरा नेटवर्क पर

Read in Other Languages
Loading…

पाँच रुकावटें — Claude Code से कैमरा नेटवर्क पर

एक कंप्यूटर से जुड़े कैमरे को उठाकर दूसरे कंप्यूटर के प्रसारण सॉफ़्टवेयर के अंदर डालना। काग़ज़ पर पाँच मिनट का काम।

El Turco | Analyst

मेरे पास दो मशीनें थीं। एक थिंकपैड — 2015 का मॉडल, दो कोर, आठ गीगाबाइट — जिसमें Akaso कैमरा लगा था। और एक मैकबुक जिस पर OBS चल रहा था। दोनों एक ही Tailscale नेटवर्क पर।

काम साफ़ था: कैमरे की तस्वीर को नेटवर्क से पार कराकर OBS में डालना।

पाँच रुकावटें सामने आईं। हर एक अलग परत में।

पहली कोशिश सबसे सीधी थी: कैमरा पकड़ो, दबाओ, UDP से उस पार फेंको।

पैकेट निकले। पहुँचा कुछ नहीं।

UDP वही ट्रैफ़िक है जो फ़ायरवॉल और वर्चुअल नेटवर्क सबसे कम पसंद करते हैं। यह खोजने के बजाय कि वह कहाँ खो रहा है, हमने रास्ता बदला: TCP। SSH पहले से TCP पर चल रहा था, यानी वह रास्ता खुला था।

TCP पर आए, पोर्ट खोला, फ़ायरवॉल में नियम जोड़ा। कनेक्शन अस्वीकृत।

कारण सूक्ष्म था। SSH से जुड़ने पर उपयोगकर्ता के पास प्रशासक अधिकार थे — पर सत्र उन्नत नहीं था। विंडोज़ में ये दोनों एक चीज़ नहीं हैं। फ़ायरवॉल का नियम चुपचाप लागू ही नहीं हुआ था।

दीवार तोड़ने के बजाय हमने उसे पूरी तरह पार किया: एक SSH सुरंग। वीडियो को उसी चैनल से भेजा जो पहले से काम कर रहा था।

सुरंग बनी, ffmpeg चला, और चार सेकंड बाद मर गया।

त्रुटि स्पष्ट थी: रीयल-टाइम बफ़र बहुत भरा है, फ़्रेम गिराया गया।

किसी ने कुछ और न कहा था, इसलिए कैमरा अपनी डिफ़ॉल्ट सेटिंग पर लौट गया था: 3840×2160। 4K को रीयल-टाइम में दबाना 2015 के दो-कोर प्रोसेसर का काम नहीं है।

समाधान के दो हिस्से थे। हमने रिज़ॉल्यूशन 1920×1080 पर तय किया। और संपीड़न का काम प्रोसेसर से हटाकर Intel Quick Sync को दिया — यानी ग्राफ़िक्स चिप के भीतर बैठे हार्डवेयर एन्कोडर को।

कैमरा ख़ुद H.264 बना सकता था। तो सोचा, बिना छेड़े जैसा है वैसा ही भेज दें। प्रोसेसर पर भार शून्य।

दूसरा सिरा उसे डिकोड नहीं कर सका। लॉग एक ही पंक्ति दोहरा रहा था: अनुपस्थित PPS 0 का संदर्भ।

कैमरा तस्वीर का वर्णन करने वाले शीर्षक — SPS और PPS — धारा के आरंभ में नहीं रख रहा था। बिना शीर्षकों की वीडियो धारा, बिना वर्णमाला के पाठ जैसी है।

हमने उसे MJPEG के रूप में लिया और Quick Sync से दोबारा एन्कोड किया। एक क़दम ज़्यादा, पर शीर्षक अपनी जगह पर।

सब कुछ चल पड़ा। तस्वीर आई। फिर ग़ायब हो गई।

मैंने जाँचा: जो प्रक्रिया मैंने शुरू की थी, वह थी ही नहीं। त्रुटि लॉग ख़ाली। कार्यक्रम क्रैश नहीं हुआ था — उसे मार दिया गया था

कारण ख़ुद SSH था। विंडोज़ में SSH सत्र अपनी शुरू की गई प्रक्रियाओं को एक जॉब ऑब्जेक्ट से बाँध देता है; सत्र बंद होते ही संतानें भी चली जाती हैं। जिस क्षण मैं कनेक्शन काटता था, कैमरा भी कट जाता था।

हमने प्रसारण को एक निर्धारित कार्य में बदल दिया। अब वह सत्र पर निर्भर नहीं — अपने आप जीता है और हर टूटन के बाद ख़ुद को फिर चालू कर लेता है।

तस्वीर आ गई। अपनी मेज़ पर बैठे-बैठे मैंने ख़ुद को अपनी ही स्क्रीन पर देखा — पर वह तस्वीर बग़ल के लैपटॉप से निकली थी, एक कूटबद्ध सुरंग से गुज़री थी, और लौट आई थी।

और असली खोज यह थी: दस साल पुराना, दो-कोर वाला लैपटॉप 1080p30 वीडियो को दबाता है, जबकि उसका प्रोसेसर लगभग ख़ाली बैठा रहता है। Quick Sync की बदौलत। मैं उस मशीन को कमज़ोर समझता था। कमज़ोर मेरी सेटिंग्स थीं।

पाँच में से एक भी रुकावट हार्डवेयर की कमी नहीं थी। पाँचों विन्यास, प्रोटोकॉल और ऑपरेटिंग सिस्टम के व्यवहार से जुड़ी थीं।

अगर मैंने नई और ताक़तवर मशीन ख़रीदी होती, तो ये पाँचों बिल्कुल वैसे ही सामने आतीं।

तंत्र बनाना ताक़तवर पुर्ज़े ख़रीदना नहीं है। यह एक-एक करके यह पता लगाना है कि पुर्ज़े आपस में बात करने से क्यों इनकार कर रहे हैं।

⚙️ तकनीकी विवरण — मशीनें, आँकड़े, कमांड

ThinkPad T470 — i5-6300U · 2C/4T · 8 GB · Intel HD 520 · Windows 10 Pro
Kamera — Akaso (UVC, MJPEG 1920×1080 @30)
Kodlayıcı — Intel Quick Sync (h264_qsv)
Taşıma — MPEG-TS over TCP, SSH reverse tunnel (Tailscale)
Kalıcılık — Windows Scheduled Task

Series
Loading…