- Cyanview, Super Bowl जैसे बड़े लाइव ब्रॉडकास्ट में सैकड़ों कैमरों के रंग, exposure और skin tone मिलाने वाले camera shading उपकरण बनाता है, और core control path में Elixir का उपयोग करता है
- ब्रॉडकास्ट साइट पर एक भी failure घातक हो सकता है, इसलिए Cyanview ने IP network control और Erlang VM की device coordination क्षमता को अपने product का आधार बनाया
- RCP और RIO डिवाइस Yocto Linux पर Elixir और C logic के साथ चलते हैं, और MQTT-based communication व सीमित cloud relay के जरिए remote production को support करते हैं
- Elixir की binary encoding/decoding और supervision tree का उपयोग अलग-अलग proprietary devices को integrate करने, connection failures को isolate करने और features को जल्दी validate करने में होता है
- 9 लोगों की टीम 200 से अधिक cameras के connection, Le Mans, Ninja Warrior, Australian Open और US Open जैसे venues को support करती है, जिससे छोटी टीम का product scope बढ़ता है
ब्रॉडकास्ट साइट पर Cyanview कौन-सी समस्या हल करता है
- Super Bowl जैसे live broadcast में करीब 200 cameras के रंग, exposure और visual tone को match करना पड़ता है
- Camera shading वह काम है जिसमें हर camera को ऐसा adjust किया जाता है कि वह वही grass color और वही skin tone दिखाए
- Target equipment में बड़े broadcast cameras से लेकर drone cameras, PTZ cameras और gimbal-mounted mirrorless cameras तक शामिल हैं
- Cyanview Belgium की एक छोटी कंपनी है जो live video broadcast industry के लिए products बेचती है, और उसका मुख्य क्षेत्र shading है
- Broadcast industry के tools को एक live event में तुरंत prove होना पड़ता है, और hard failure को tolerate करना मुश्किल होता है
RCP कैसे फैला और कहाँ इस्तेमाल होता है
- 3 लोगों की छोटी टीम द्वारा बनाया गया Remote Control Panel(RCP), marketing से ज्यादा अपने features के जरिए industry में फैला
- RCP का उपयोग professional video operators इन venues में करते हैं
- Olympics
- Super Bowl
- NFL
- NBA
- ESPN
- Amazon
- Paris के कई fashion shows
- एक single RCP से 100 से अधिक cameras को बिना समस्या संभालने का case रहा है, और यह Elixir network stack पर implement किया गया है
- Cyanview ने Elixir चुनकर networking capabilities, resilience और product features को तेजी से iterate करने की क्षमता हासिल की
Elixir चुनने की वजह
- Cyanview की founding team के पास मुख्यतः embedded development का अनुभव था, और product में काफी low-level C code और FPGA शामिल हैं
- Color science की low-level details और सख्त timing requirements की वजह से low-level implementation जरूरी है
- Camera software, पूरी तरह digital हो जाने के बाद भी, अक्सर analog systems या proprietary connection methods से बंधा रहता है
- शुरुआत से ही IP-based control को लक्ष्य बनाते हुए, structure ऐसा बना जिसमें software सामान्य network पर equipment को handle करता है
- Remote production बढ़ने के साथ central location से production team द्वारा operate करने और on-site staff घटाने का तरीका फैल रहा है
- Custom radio frequency या serial wire protocols को continent-to-continent distance तक scale करना मुश्किल है
- Erlang VM को network के जरिए बहुत सारे devices के साथ reliably communicate और coordinate करने के लिए design किया गया था, और यही बात Elixir adoption की वजह बनी
Protocol integration और remote production के examples
- Developer Ghislain ने कई network protocols के जरिए cameras और video equipment को integrate करने के लिए Elixir अपनाया
- Elixir, individual bit level तक binary data को encode/decode करने की practical capabilities देता है
- Cyanview की core intellectual property, बड़ी मात्रा में equipment integration और reverse engineering में है
- Product को customers द्वारा इस्तेमाल किए जाने वाले अलग-अलग professional camera systems और related equipment के साथ compatible रहने के लिए design किया गया है
- External equipment के साथ smoothly integrate करने के लिए API भी दिया जाता है
-
Beijing–Paris remote control case
- China Olympics case में Beijing studio ने कई Panasonic PTZ cameras इस्तेमाल किए, और team के ज्यादातर लोगों को Paris से remote control करना था
- Panasonic camera protocol को internet use को ध्यान में रखकर नहीं बनाया गया था, और हर adjustment के लिए precise timing और कई messages चाहिए थे
- Network latency, timeouts, disconnections और system failure तक ले जा सकती थी
- Operation इस तरह किया गया कि Cyanview equipment को Beijing में cameras के पास रखा गया और Paris से IP के जरिए control किया गया
- उसी जगह के devices, custom MQTT protocol के जरिए network पर communicate और coordinate करते हैं
RCP, RIO और UI configuration
- पूरा system Yocto Linux चलाने वाले RCP device और Elixir/C-based logic से बना है
- Python अभी भी scripting और tools के लिए इस्तेमाल होता है, लेकिन उसकी भूमिका धीरे-धीरे घट रही है
- कई microcontrollers और on-camera devices MQTT के जरिए communicate करते हैं
- Cloud relay connectivity में मदद करता है, और dashboard व controller UI monitoring और control देते हैं
- Core devices दो हैं
- RCP: production-side control device
- RIO: camera की low-latency operation संभालने वाला device
- RCP और RIO दोनों Elixir चलाते हैं
- Configuration UI फिलहाल Elm में बनाया गया है
- Priorities के आधार पर configuration UI को languages की संख्या घटाने के लिए Phoenix LiveView पर migrate किया जा सकता है
- Controller web UI पहले से LiveView में है, और low-spec embedded Linux machines पर भी अच्छी तरह चलता है
सीमित cloud और local device cluster
- Cyanview का cloud हिस्सा फिलहाल सीमित है, और यह SaaS-centric structure नहीं है
- Cloud relay camera control distribution/sharing, locations के बीच network port forwarding और related features संभालता है
- Cloud relay भी Elixir में बनाया गया है
- Site पर मौजूद Elixir devices, काम के मुताबिक custom MQTT-based protocol से IP cluster बनाते हैं
- ये devices सैकड़ों cameras और अन्य video devices के साथ communicate करते हैं
Failure isolation और supervision tree
- कई proprietary devices के साथ integrate करते समय device-wise reliability और documentation quality में बड़ा फर्क होता है
- कुछ devices आम तौर पर इस्तेमाल होते हैं इसलिए उनकी characteristics अच्छी तरह ज्ञात हैं, कुछ अच्छी documentation देते हैं, लेकिन अन्य devices unpredictable behavior दिखाते हैं
- किसी एक camera connection में temporary issue, buggy protocol या physical connection failure हो जाए, तब भी बाकी हिस्सा चलते रहना चाहिए
- Elixir की supervision tree individual connection issues को पूरे system failure में फैलने से रोकने में मददगार है
9 लोगों की team में role distribution
- Cyanview 9 साल में धीरे-धीरे बढ़ा है, औसतन हर साल 1 व्यक्ति जोड़ा गया
- फिलहाल 9 लोगों की team दुनिया के सबसे बड़े broadcast events में से कुछ को support करती है
- Elixir developers 2 हैं
- Daniil कुछ UI revamp और अधिक cloud features की दिशा संभालते हैं
- Ghislain cameras और integration work संभालते हैं
- LiveView और Elm का उपयोग device UI और dashboards में होता है
- अन्य embedded developers अपने daily work में Elixir का ज्यादा इस्तेमाल नहीं करते, लेकिन Elixir में protocols और encoding implement करने के आदी हैं
- इनके Elixir को गहराई से न सीखने की मुख्य वजह समय की कमी है, और deep Elixir expertise जरूरी भी नहीं थी
- Team का काम PCB design, electronic components selection, protocol reverse engineering, display interfaces, FPGA implementation, production test management, actual production और firmware updates तक फैला है
Feature expansion और customer-centric development
- Cyanview equipment इन venues में इस्तेमाल होता है
- 24 Hours of Le Mans में 40 से अधिक in-car onboard cameras
- Ninja Warrior
- Australian Open
- US Open
- Louvre का studio
- NFL pylons
- 200 से अधिक cameras का simultaneous connection
- IP पर चलने वाली दुनिया के लिए Elixir-based devices बनाए गए, और इससे अलग-अलग equipment support व नए features की delivery साथ-साथ हो पाई
- मौजूदा local radio frequency, serial connections और inflexible proprietary protocols से IP networks की ओर जाने से camera systems operate करने का तरीका बदल गया
- Feature set में ये शामिल हैं
- Unlimited multicam
- Tally lights
- Pan & Tilt control
- Color corrector integration
- Worldwide remote production
- Gimbal-mounted mirrorless cameras से crowd scenes shoot करने की मांग बढ़ी, तो Cyanview ने gimbal control को तेजी से prototype किया और customers के साथ test करके validate किया
- Flexible architecture, core foundation को तोड़े बिना नए features जल्दी ship करने देती है
- Canon या RED जैसी camera companies, जो broadcast shading remotes नहीं बनातीं, अपने customers को Cyanview recommend करती हैं
- Cyanview खुद को अधिकतर broadcast hardware companies का competitor नहीं, बल्कि partner मानता है
- Marketing से ज्यादा customer events की सफलता में support और deep customer service को महत्व देता है
आगे की दिशा
- David Bourgeois ने कहा कि दोबारा चुनना पड़े तो भी वे Elixir ही चुनेंगे
- Erlang VM, Cyanview की जरूरतों के लिए अच्छी तरह fit बैठा, और Elixir में default रूप से मिलने वाली capabilities की value को खुद implement करने से पहले पूरी तरह समझना कठिन है
- Cyanview team को और बढ़ाना चाहता है, लेकिन समय लगे तो भी जिम्मेदारी से grow करना चाहता है
- फिलहाल छोटी team जितना संभाल सकती है, उससे ज्यादा काम मौजूद है
- Main RCP equipment के साथ complementary products पहले से हैं, और आगे और products planned हैं
- Cloud product और अब तक की learnings पर आधारित hardware projects planned हैं
- Elixir दुनिया के सबसे बड़े live broadcasts में से कुछ में और भी अहम भूमिका निभाएगा
1 टिप्पणियां
Hacker News टिप्पणियां
यह जानने के बाद बहुत obvious लगता है कि sports events में अलग-अलग angles पर लगाए गए cameras में से हर एक के लिए color correction करना पड़ता है
ऐसे मुश्किल problems के बारे में पढ़ना वाकई मज़ेदार है जो ज़्यादातर लोगों को दिखाई ही नहीं देते
एक video है जिसमें halftime show के सभी camera shot transitions को track किया गया है: https://www.youtube.com/watch?v=YXNWfFtgbNI
Hamish Hamilton ने 2010 के बाद से हर Super Bowl halftime show direct किया है
https://x.com/SNYtv/status/1832250958258036871
“बिना marketing के भी अनुभवी professionals के बीच reputation बनाकर दुनिया के सबसे बड़े live events की ज़रूरत बन गया” वाला हिस्सा entertainment industry जैसा ही लगता है
जब आप हर साल वही show उसी crew के साथ करते हैं, तो सच में सब एक-दूसरे को जानते हैं और एक तरह की family जैसी structure बन जाती है
Cyanview की storefront website भी है और LinkedIn marketing posts भी हैं
Elixir को mission-critical broadcast systems में traction पाते देखना अच्छा लगा
सोच रहा हूं कि Cyanview की reliability कितनी Elixir से आती है, और कितनी MQTT implementation को अच्छी तरह करने से
यह भी जानना चाहूंगा कि क्या Elixir के कोई specific features थे जिन्हें दूसरी languages में reproduce करना मुश्किल होता
BEAM और OTP concurrency के लिए एक sound approach देते हैं, और Elixir उसके ऊपर बनी एक अच्छी language है
process isolation अच्छा है, heap भी process-wise अलग होती है, इसलिए stable mature code और experimental features को साथ चलाने पर पूरी system के गिरने की चिंता कम रहती है, और inter-process communication भी आसान है
supervision trees की वजह से process management आसान है, और हम अलग-अलग restart strategies वाले specialized supervisors भी बना पाए
ऐसे environment में जहां network connection टूटकर फिर जुड़ता रहता है, system resilience की जांच किसी physical chaos monkey की तरह अक्सर होती रहती है
BEAM-style immutability concurrency code लिखना काफी सरल बना देती है: एक process के अंदर data के चुपचाप बदल जाने की चिंता नहीं होती और कोई दूसरा process मेरी state बदल भी नहीं सकता
इसलिए mutexes या critical sections की लगभग जरूरत नहीं पड़ती, लेकिन deadlock अब भी possible है, इसलिए यह कोई silver bullet नहीं है
काम है failure handling और alternate paths के साथ बहुत सारे real-time feeds को coordinate और route करना, और मूल target phone calls था
video streams में per second data कहीं ज़्यादा होता है, लेकिन principles mostly वही रहते हैं
मैं इस system को लेकर critical रहा हूं, लेकिन ऐसे use case के लिए यह out of the box भी बहुत मजबूत foundation बनता है
फर्क इस बात में है कि वह उस काम को कितना आसान बना देती है
मैंने Elixir को critical financial applications, B2B growth intelligence, fraud detection, scan-and-go shopping जैसी कई जगहों पर apply किया है
हर बार, इस article की engineering team की तरह, developer experience और final result उम्मीद से बेहतर रहे; अगर आपने अभी तक Elixir try नहीं किया है, तो इसे एक बार आज़माना बनता है
मैं खुद भी exception नहीं हूं; दशकों से इनके बारे में अच्छी बातें सुनता आया हूं, लेकिन किसी real project में इस्तेमाल नहीं किया
उदाहरण के लिए, हमने अभी cloud product में ऐसा feature deploy किया है जिसमें user facility के अंदर किसी specified waypoint पर robot को remotely बुला सकता है, और robot के चलते समय map पर उसकी location real time में दिखती रहती है
इसे हमने MQTT, LiveView, Phoenix PubSub और map manipulation के लिए बहुत थोड़े JavaScript से बनाया; मौजूदा S3 map PNG display code या MQTT receiving handling वगैरह को छोड़ दें तो cloud वाला हिस्सा एक व्यक्ति ने लगभग 2–3 हफ्तों में implement किया
बेशक यह दूसरी languages में भी किया जा सकता है, लेकिन core language features इतने अच्छे हैं कि हमारे use case में यह बाकी options से बहुत आगे है
सोच रहा हूँ कि क्या मिलते-जुलते applications के लिए Gleam OTP/BEAM runtime के अलावा भी practical होगा
लगता है कि Elixir libraries का इस्तेमाल करना पड़ेगा जो अभी Gleam में नहीं हैं, और static types की वजह से compile धीमा हो सकता है, लेकिन runtime errors को पहले पकड़ पाना संभव हो सकता है
जानना चाहता हूँ कि क्या यह debugging और तेज़ dynamic iteration के बीच किसी trade-off जैसा है, और Gleam व Elixir में से एक चुनने की कोशिश कर रहा हूँ
पुराने Gleam की ML-style syntax भी पसंद थी और static types भी पसंद हैं
C को Zig से replace कर रहा हूँ, और x64 के अलावा ARM सीखते हुए assembly भी फिर से मजबूत कर रहा हूँ
Erlang का reliability record Java समेत कई static typed languages से मजबूत है
static types कुछ तरह की errors रोकते जरूर हैं, लेकिन जिन errors को वे नहीं रोक पाते वे कहीं ज्यादा हैं
अगर यह दावा करना है कि TS, Java, Swift, Go, Gleam जैसी languages Erlang या Elixir की तुलना में असल runtime defects कम करती हैं, तो real-world data चाहिए
इस पर अभी काम चल रहा है, लेकिन मैंने अभी उसे आजमाया नहीं है, इसलिए Gleam भी ठीक लग सकता है
हालांकि जब हमने शुरुआत की थी, तब Gleam 0.1 तक भी नहीं पहुँचा था और हमने उसका नाम भी नहीं सुना था
Erlang, Elixir और Gleam को मिलाकर project बनाना भी संभव होगा, लेकिन practical कितना होगा, पता नहीं
compile भी बहुत तेज़ है
अभी बहुत बड़ा project नहीं किया है, लेकिन काफी भारी libraries इस्तेमाल करने पर भी सब बहुत जल्दी compile हुआ
digital video की दुनिया IT की रिश्तेदार जैसी है, फिर भी video industry के बाहर के लोगों के लिए इसमें entry barrier हमेशा ऊँचा महसूस होता है
resolution, color, networking और storage को नाम देने का तरीका लगभग जानबूझकर अलग रखा गया लगता है
ये सिर्फ वे items हैं जिनसे video engineer image quality adjust करता है, camera operators के features आम तौर पर इसमें शामिल नहीं होते
मुश्किल बात इतनी सारी cameras और protocols के बीच consistency बनाना है
उसके बाद ही raw yuv/y4m uncompressed video, बहुत high-bitrate low-compression video, और original data इतना बड़ा होने की वजह से powerful workstations पर भी editing मुश्किल होने पर proxy videos बनाने की समस्या तक पहुँचा जा सकता है
कोई professional वजह न हो तो आम end user के लिए इतनी गहराई में जाने का फायदा बहुत कम है
अगर आप RED camera पर 7,000 डॉलर खर्च कर, फिर lenses, gimbal, cage, follow focus, matte box, memory cards आदि पर 13,000 डॉलर और लगाकर एक छोटा और cost-effective single-camera production package बनाना चाहते हैं, तो इसमें गहराई से जाना worth it है
करीब 30 साल पहले studio environment में cameras का color balance मिलाना मेरे काम का हिस्सा था
computer की जरूरत नहीं थी, लेकिन cameras अधिकतम 5 ही होते थे
लेख में यह हिस्सा ध्यान खींचता है कि “एक location के devices custom MQTT protocol के जरिए network पर communicate और coordinate करते हैं, और Elixir network stack पर implemented एक single Remote Control Panel(RCP) 100 से ज्यादा cameras को बिना समस्या handle करता है”
मेरी समझ में MQTT TCP के ऊपर बना है, और मुझे नहीं पता कि मैं वही solution ढूँढता या नहीं, लेकिन यह काफी अच्छा choice लगता है