Chromebook से बना सबसे अनोखा video wall

 (varun.ch)
1 पॉइंट द्वारा GN⁺ 2025-03-02 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • कबाड़ होने वाले स्कूल-इश्यू Lenovo ThinkPad 11e Chromebook को खोलकर और दोबारा इस्तेमाल करके 10-स्क्रीन वाला video wall बनाने में लगभग 3 साल लगे
  • अलग display controller की जगह मौजूदा laptop motherboard ही हर स्क्रीन को चलाता है, और web-based sync system एक वीडियो को 10 हिस्सों में बांटकर चलाता है
  • socket.io आधारित c-sync ने धीमी performance, loading time के अंतर, latency और system clock की समस्याओं का सामना किया, लेकिन सबसे धीमे client के हिसाब से loop को धीमा करके लगभग synced playback हासिल किया
  • ChromeOS के enterprise enrollment, developer mode restrictions, और battery हटाने पर power issues को coreboot, MrChromebox tools, Debian auto-install USB, और ectool fan control से bypass किया गया
  • TN panel viewing angles, color differences और पूरी तरह perfect sync की सीमाएं रहीं, लेकिन यह e-waste को collaboration और iterative design से एक काम करने वाली installation में बदलने का उदाहरण है

कबाड़ होने वाले Chromebook से शुरू हुआ video wall

  • जब स्कूल पुराने Chromebooks को फेंकने वाला था, तब यह सोचकर प्रोजेक्ट शुरू हुआ कि इनसे क्या बनाया जा सकता है
  • इस्तेमाल किया गया डिवाइस Lenovo ThinkPad 11e था, जो स्कूल-इश्यू laptop था, लेकिन अब उसे Google software updates नहीं मिल रहे थे
  • ज़्यादातर मशीनें web pages तक ढंग से load नहीं कर पा रही थीं, और पुराने Enterprise Enrolment में फंसी होने की वजह से स्कूल के Google account के बिना इस्तेमाल करना मुश्किल था
  • लक्ष्य था कई screens को इस तरह लगाना कि वे एक बड़े display की तरह काम करें, यानी एक video wall

स्क्रीन चलाने का तरीका और sync के प्रयोग

  • शुरुआत में सिर्फ laptop display panels निकालकर एक ताकतवर computer से 10 screens को एक साथ चलाने का विचार किया गया
  • इसमें समय और लागत दोनों ज़्यादा थे, और क्योंकि screens पहले से काम कर रहे laptops से जुड़ी थीं, इसलिए हर स्क्रीन को उसकी अपनी laptop motherboard से चलाने का तरीका चुना गया
  • VLC streaming से एक ही network पर कई devices को वीडियो भेजने का प्रयोग भी किया गया, लेकिन यह video wall की ज़रूरतों के लिए ठीक नहीं था
    • यह ऐसा system नहीं था जिसे perfect sync के लिए design किया गया हो
    • 10 screens पर एक ही वीडियो दोहराने के बजाय, एक लंबे वीडियो को 10 हिस्सों में बांटकर हर स्क्रीन पर अलग input दिखाना था

c-sync से playback timing मिलाना

  • web page और socket.io का इस्तेमाल करके clients के बीच video playback मिलाने वाला ExpressJS server/client system c-sync बनाया गया
  • इसका basic structure यह था कि server play event भेजता और हर client का <video> element playback शुरू कर देता
  • desktop computer पर testing में यह काफ़ी अच्छी तरह synced लगता था, लेकिन असली Chromebooks पर performance की कमी की वजह से यह स्थिर नहीं रहा
    • loading time में अंतर
    • network latency
    • system clock में अंतर
  • आख़िर में तरीका बदला गया ताकि हर client वीडियो के अंत तक पहुंचने पर start event भेजे
    • इससे सबसे धीमा computer तेज़ systems को इंतज़ार करवाता था, और वीडियो load होने का समय मिल जाता था
    • हर स्क्रीन 10 start events पा सकती थी, इसलिए loop का timing थोड़ा हिल सकता था
    • अगर वीडियो के शुरुआती कुछ frames एक जैसे हों, तो user के लिए यह अंतर समझना मुश्किल होता था
  • timestamp आधारित scheduled playback संभव लग रहा था, लेकिन ये Chromebooks आपस में millisecond स्तर पर समय स्थिर रूप से match नहीं कर पा रहे थे, इसलिए यह काम नहीं कर पाया

ChromeOS से बाहर निकलने के लिए firmware का काम

  • एक-दो महीने में यह चरण हासिल कर लिया गया जिसमें web page को manually खोलकर full-screen synced वीडियो दिखाया जा सकता था
  • लेकिन इसे असली installation बनाना था, इसलिए power मिलते ही auto boot होना और c-sync client page अपने आप खुलना ज़रूरी था
  • default ChromeOS स्कूल domain से locked Google login screen पर boot होता था, और battery हटाने पर power connect करने से भी system अपने आप चालू नहीं होता था
  • MrChromebox की ChromeOS Firmware Recovery Script का इस्तेमाल करके GLIMMER motherboard को संभाला गया
    • Recovery Mode में जाना
    • Developer Mode चालू करना
    • ChromeOS Shell में script चलाना
  • कुछ Chromebooks ने Enterprise Enrolment की वजह से Developer Mode में जाने से मना कर दिया, और जिन devices पर Linux install हो गया था वे भी कुछ समय बाद video playback रोक देते थे या पूरा system freeze हो जाता था
  • इसका समाधान यह निकला कि हर laptop motherboard से Write Protection screw हटाकर पूरा default firmware coreboot से overwrite कर दिया जाए
    • लगता है इससे enrollment restriction भी bypass हो गई
    • 20 से ज़्यादा computers पर इसे दोहराना धीमा और झंझट भरा था
    • इसके बाद Wake on AC firmware feature की तरह काम करने लगा और video playback भी random तरीके से टूटना बंद हो गया

auto-boot Linux kiosk बनाना

  • शुरुआत में एक startup script इस्तेमाल की गई जो Chromium खोलती थी और key input का नाटक करके उसे full screen में करती थी
  • FullPageOS पहले के एक project में इस्तेमाल किया गया था, लेकिन यह x86 hardware पर काम नहीं कर पाया
  • Porteus Kiosk एक minimal Linux distribution है जो full-screen Chromium चलाता है, और ऐसे flags सेट कर सकता है जिनसे user interaction के बिना video playback संभव हो जाता है, इसलिए यह अच्छी तरह काम किया
  • लेकिन Porteus Kiosk में असली installation चलाने के लिए कुछ रुकावटें थीं
    • हर boot पर दिखने वाली Porteus logo splash screen बदली नहीं जा सकती थी
    • install होने के बाद page URL बदलने जैसे remote काम नहीं हो सकते थे, जो wall mount के बाद समस्या बन सकता था
  • अपनी distribution जैसी setup बनाने के लिए minimal system पर desktop environment के बिना kiosk mode Chromium को auto-run कराने का तरीका आज़माया गया
  • Chromebook के छोटे storage की वजह से NixOS install नहीं हो पाया
  • इसके बाद Debian minimal install पर आधारित provisioning script लिखी गई
    • KIOSK_ID बनाना
    • hostname को csync-client-$KIOSK_ID पर सेट करना
    • स्कूल WiFi से connect करना
    • user और permissions बनाना
    • openbox के साथ full-screen kiosk mode Chromium auto-start करना
  • manual Debian install झंझट भरा था, इसलिए FAI - Fully Automatic Installation और FAI.me का इस्तेमाल किया गया
  • आख़िर में एक single USB बनाई गई जिसे coreboot वाले Chromebook में लगाते ही वह c-sync client के लिए auto-provision हो जाता था
  • c-sync में connected clients को manage करने और हर client को वीडियो assign करने वाला controller भी जोड़ा गया
  • 3 दिनों की stress test में playback लगातार smooth रहने के बाद wall mounting के चरण में बढ़ा गया

mounting, power और heat management

  • mounting hardware Aksel Salmi ने design किया था, और ऐसा structure इस्तेमाल हुआ जिसमें motherboard और display को दीवार पर टांगा जा सके
  • power supply setup में cables को इस तरह जोड़ा गया कि हर adapter दो computers को power दे सके
  • installation के बाद सबसे बड़ी समस्या heat थी, और firmware मिटाने की प्रक्रिया के बाद laptop fans चल नहीं रहे थे
  • ChromeOS Embedded Controller को ectool से access किया जा सकता है, इसलिए fan speed manually set की गई
  • online documentation कम थी और coreboot तथा Google वाले ectool में अंतर होने से उलझन हुई, लेकिन Wayback Machine से मिला binary fan speed सेट करने में सही काम कर गया
  • testing के बाद ऐसा fan speed value चुना गया जिसमें noise और temperature के बीच संतुलन बन सके

10 screens के लिए वीडियो बनाना

  • हर display का resolution 1366×768 है, इसलिए 10 screens के लिए पूरा वीडियो 13660×768 बनता है
  • इतनी चौड़ी वीडियो edit कर सकने वाला software बहुत कम था, और व्यवहार में सिर्फ Final Cut Pro और Blender इस्तेमाल किए जा सके
  • पूरे चौड़ाई वाले वीडियो को render करने के बाद ffmpeg से उसे 10 हिस्सों में काटकर हर स्क्रीन को दिया गया
  • splitting script crop=1366:768:x_offset:0 के रूप में हर स्क्रीन की position के अनुसार segment बनाती थी

अंतिम परिणाम और बाकी सीमाएं

  • तैयार video wall में boot sequence, self-calibration जैसा दिखने वाला process, synced video playback, enclosure और cable routing तक सब शामिल था
  • परिणाम perfect नहीं है
    • TN panel के viewing angles अच्छे नहीं हैं
    • हर स्क्रीन के colors अलग हैं
    • sync पूरी तरह perfect नहीं है
    • हर decision के लिए शायद कोई बेहतर विकल्प मौजूद रहा हो
  • फिर भी यह e-waste को एक दिलचस्प installation में बदलने और iterative design व team collaboration को दिखाने वाला नतीजा है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-03-02
Hacker News की राय

  • मज़ेदार प्रोजेक्ट पूरा करने पर बधाई। मैंने कई डिवाइसों पर media synchronization का बहुत काम किया है, इसलिए लोग कौन-से समाधान निकालते हैं यह देखना हमेशा अच्छा लगता है
    ऐसे synchronized video wall बनाने का industry-standard तरीका आमतौर पर BrightSign media player इस्तेमाल करना है, लेकिन 20 display के हिसाब से सिर्फ player और screen खरीदने की लागत ही आसानी से कई दसियों हज़ार डॉलर तक पहुँच सकती है। यह कि आपने इसे recycled devices पर चलाया, सच में प्रभावशाली है
    अगर media synchronization से जुड़े codebase पर काम करने में रुचि हो तो संपर्क कर सकते हैं। मैं freelance contract developers काफ़ी नियमित रूप से hire करता हूँ

    • धन्यवाद। ब्लॉग पोस्ट में यह नहीं जोड़ पाया, लेकिन मैंने commercial solutions की pricing भी देखी थी, और वे सच में बहुत महँगे थे
      मैं हमेशा सोचता रहा कि लागत में hardware और software का अनुपात कितना होता है, और professional digital signage शायद reliability और lifespan जैसी बातों को ध्यान में रखकर डिज़ाइन की जाती होगी

  • जब Chromebook लॉन्च हुआ था, तब मैं Google में काम करता था, और वे lobby decoration ideas माँग रहे थे, तो मैंने कुछ ऐसा ही प्रस्तावित किया था, लेकिन उसे ठुकरा दिया गया। शायद इसलिए कि मैंने 40~64 devices माँगे थे
    हालाँकि, मैं शायद video को synchronize करने की कोशिश नहीं करता, बल्कि time-based animation बनाता और network पर clocks को sync करता
    उदाहरण यहाँ देख सकते हैं: https://www.youtube.com/watch?v=64TcBiqmVko
    यह Chrome चलाने वाले 8 devices हैं, और synchronized सिर्फ configuration और time हैं। devices का grid में होना भी ज़रूरी नहीं था, और inspiration Boston Science Museum के virtual aquarium से मिली थी

    • लेखक ने भी यह कोशिश की थी, लेकिन clocks sync नहीं रह पाए। यह fold होने वाले sidenote में है
      उसमें लिखा है: “दुर्भाग्य से, ये Chromebook आपस में millisecond स्तर पर समय को स्थिर रूप से sync नहीं रख पाए, इसलिए यह तरीका हमारे लिए काम नहीं आया”
    • अगर media fixed हो, यानी real-time में dynamically generated या streamed न हो, तो यह तरकीब काफ़ी दूर तक काम कर सकती है। generative होने पर भी, अगर animation चलाने के लिए time को value की तरह इस्तेमाल किया जाए, तो यह संभव है
      जैसा आपने कहा, अच्छी clock synchronization चाहिए, और खासकर audio होने पर 20~30ms का फर्क भी बहुत साफ़ महसूस होता है, इसलिए यह आसान नहीं है। फिर भी NTP/PTP के साथ काफ़ी हद तक पहुँचा जा सकता है

  • बढ़िया। मैंने 4x4 tablets के साथ कुछ ऐसा ही किया था, और सभी 16 devices को ADB और एक single host से जोड़कर ज़्यादातर चीज़ें automate कर पाया था
    फिर sway में 16 virtual screens और 16 VNC clients बनाए, और सबको Wi-Fi पर stream करके test किया, लेकिन Wi-Fi इतना अच्छा चला कि मैंने इससे अधिक efficient समाधान खोजा ही नहीं
    उस दौरान मेरे PC पर 19 displays थे, जिनमें 17 VNC थे, और दृश्य कमाल का था। आप पूरे सेटअप पर एक जैसा काम करा सकते थे, या हर एक को अलग काम—जैसे music, htop, calendar, clock, ssh sessions—के लिए इस्तेमाल कर सकते थे
    हालाँकि hardware संभालना काफ़ी झंझट भरा था। कुछ पर throttling होती थी, कुछ में connection issues थे, और कुछ batteries charge बनाए नहीं रख पाती थीं

  • बहुत पहले Junkyard Jumbotron नाम की एक मिलती-जुलती चीज़ थी। यह अलग-अलग तरह के displays को जोड़कर उन्हें एक बड़ी image के हिस्से दिखाने देती थी
    https://github.com/mitmedialab/Junkyard-Jumbotron
    वीडियो: https://youtu.be/cAUtSVSTbzU?feature=shared

    • Media Lab बहुत सारी random मज़ेदार चीज़ें बनाता है। इसे modern web technologies के साथ फिर से बनाना भी काफ़ी मज़ेदार हो सकता है
      alignment के लिए photo को email से भेजने वाला तरीका भी अपने आप में दिलचस्प लगता है

  • अगर आपने बस सरसरी नज़र डाली और पूरा ब्लॉग नहीं पढ़ा, तो यह प्रोजेक्ट high school students ने अपने school के दौरान बनाया था। इसलिए यह और भी ज़्यादा प्रभावशाली लगता है

  • “मुझे पूरी तरह यक़ीन नहीं कि यह इतना अच्छा क्यों काम करता है, लेकिन संयोग से मेरे दिमाग में एक बेतुका समाधान आया” और “सबसे धीमा कंप्यूटर सबसे तेज़ कंप्यूटर को रोककर रखता है” वाले हिस्सों को देखकर लगता है कि यह इसलिए अच्छा चला क्योंकि system design को bottleneck के हिसाब से optimize किया गया था
    Theory of Constraints देखना उपयोगी हो सकता है

  • एक बार मुझे 5 बड़े touchscreen TVs को टेबल की तरह लगाकर ऐसा ही कुछ करना था। हर side एक अलग touchscreen app होना चाहिए था, और सबको background में synchronized video चलाना था, जबकि users एक छोर से दूसरे छोर तक बहते elements के साथ interact कर सकें, या टेबल के दूसरी तरफ़ बैठे user को मिली हुई object भेज सकें
    आखिरकार बजट में ऐसा hardware लगभग सिर्फ cylindrical Mac Pro ही था जो सभी screens को एक साथ चला सकता था, इसलिए वही इस्तेमाल किया गया, और apps को Redis से synchronize किया गया। वह हिस्सा मैंने लिखा था
    यह काफ़ी अच्छा चला, लेकिन कंपनी छोड़ने से पहले मैं final product नहीं देख पाया। मूल योजना अलग-अलग computers को synchronize करने की थी, लेकिन हम उसे काफ़ी stable नहीं बना पाए, और थोड़ी देर चलने के बाद कई कारणों से sync बिगड़ जाता था, फिर application को समय-समय पर restart करना पड़ता—जो संभव नहीं था
    PC के शुरुआती दिनों से ही मेरी इच्छा रही है कि कई machines को network से जोड़कर वे resources share करें और अधिक सहयोगी ढंग से काम करें। मैं हमेशा कल्पना करता था कि office के सभी computers को supercomputer की तरह इस्तेमाल कर काम कराया जा सके। बेशक यह बहुत कठिन समस्या है, और apps तथा operating systems को इसी तरह डिज़ाइन होना होगा, साथ में नए algorithms भी चाहिए होंगे। यही काम एक ही board के single device के अंदर multiple processors के सही उपयोग में भी बहुत समय लगा, तो यह और भी कठिन है; फिर भी seti@home और folding@home जैसे projects ने किसी हद तक ऐसा किया था, और मैं हमेशा चाहता था कि किसी दिन computers खुद यह native रूप से support करें

  • “मैंने laptops पर install की जा सकने वाली ‘अपनी distro’ बनानी शुरू की। system को minimal configuration से शुरू होना था, और desktop environment के बिना kiosk mode Chromium instance को auto-start करने वाली एक elegant script चाहिए थी। पहले मैंने NixOS आज़माया, लेकिन जल्दी समझ आ गया कि इन Chromebooks का storage बहुत छोटा है, इसलिए यह संभव नहीं होगा, और हर बार installation भी fail हो जाता था। आखिरकार मैंने हार मानकर Debian minimal install से शुरुआत की, लेकिन फिर समझ में आया कि Debian install में बहुत सारे buttons दबाने पड़ते हैं और इसमें बहुत समय बर्बाद होता है, तभी मुझे ‘FAI - Fully Automatic Installation’ और web tool FAI.me मिला” इस हिस्से को देखकर लगता है कि DietPi, OpenWrt, और OpenBalena में भी specific packages चुनकर minimal bare metal पर install करने के automated options हैं
    यह भी जानने की जिज्ञासा है कि और कौन-कौन से non-desktop विकल्प मौजूद हैं

  • सबसे दिलचस्प बात यह है कि coreboot पर बदलते ही freezing की समस्या हल हो गई। क्यों, इस पर कोई theory है क्या?
    यह ACPI/DSDT से जुड़ा हो सकता है, या शायद original BIOS ने hardware controllers को सही तरह initialize नहीं किया होगा

    • हो सकता है watchdog timer trigger हो रहा था