การปรับความเที่ยงตรงของภาพในซูเปอร์โบวล์ด้วย Elixir
(elixir-lang.org)- Cyanview ผลิตอุปกรณ์ camera shading สำหรับปรับสี การรับแสง และโทนผิวของกล้องหลายร้อยตัวในการถ่ายทอดสดขนาดใหญ่อย่างซูเปอร์โบวล์ โดยใช้ Elixir ในเส้นทางควบคุมหลัก
- หน้างานถ่ายทอดสดยอมรับความผิดพลาดไม่ได้แม้แต่ครั้งเดียว ดังนั้น Cyanview จึงยึด การควบคุมผ่านเครือข่าย IP และความสามารถในการประสานงานอุปกรณ์ของ Erlang VM เป็นฐานของผลิตภัณฑ์
- อุปกรณ์ RCP และ RIO ทำงานบน Yocto Linux ด้วยลอจิกที่เขียนด้วย Elixir และ C รองรับการสื่อสารบน MQTT และการรีเลย์ผ่านคลาวด์แบบจำกัดเพื่อสนับสนุนการผลิตระยะไกล
- ความสามารถด้านการ เข้ารหัส·ถอดรหัส ไบนารีของ Elixir และ supervision tree ถูกนำมาใช้กับการเชื่อมรวมอุปกรณ์เฉพาะทางหลากหลายชนิด การแยกผลกระทบจากปัญหาการเชื่อมต่อ และการทดสอบความเป็นไปได้ของฟีเจอร์อย่างรวดเร็ว
- ทีมขนาด 9 คนรองรับการเชื่อมต่อกล้องมากกว่า 200 ตัว และสนับสนุนงานอย่าง Le Mans, Ninja Warrior, Australian Open และ US Open ช่วยขยายขอบเขตผลิตภัณฑ์ของทีมเล็กให้กว้างขึ้น
ปัญหาที่ Cyanview กำลังแก้ในหน้างานถ่ายทอดสด
- ในการถ่ายทอดสดอย่างซูเปอร์โบวล์ ต้องปรับ สี การรับแสง และโทนภาพ ของกล้องราว 200 ตัวให้สอดคล้องกัน
- camera shading คือการปรับให้กล้องแต่ละตัวแสดงสีสนามหญ้าและโทนผิวได้เหมือนกัน
- อุปกรณ์เป้าหมายมีตั้งแต่กล้องถ่ายทอดสดขนาดใหญ่ กล้องโดรน กล้อง PTZ ไปจนถึงกล้องมิเรอร์เลสติดกิมบอล
- Cyanview เป็นบริษัทขนาดเล็กจากเบลเยียมที่ขายผลิตภัณฑ์ให้กับอุตสาหกรรมการถ่ายทอดวิดีโอสด โดยเชี่ยวชาญด้าน shading
- เครื่องมือในอุตสาหกรรมกระจายเสียงต้องพิสูจน์ตัวเองได้ทันทีในการถ่ายทอดสดจริง และแทบไม่อาจยอมรับความล้มเหลวระดับรุนแรงได้
วิธีที่ RCP แพร่หลายและหน้างานที่ถูกใช้งาน
- Remote Control Panel(RCP) ที่สร้างโดยทีมเล็กเพียง 3 คน แพร่หลายในอุตสาหกรรมจากความสามารถของมันมากกว่าการตลาด
- RCP ถูกใช้งานโดยโอเปอเรเตอร์วิดีโอมืออาชีพในงานต่อไปนี้
- Olympics
- Super Bowl
- NFL
- NBA
- ESPN
- Amazon
- แฟชั่นโชว์หลายงานในปารีส
- มีกรณีที่ RCP ตัวเดียวจัดการกล้องได้ มากกว่า 100 ตัว โดยไม่มีปัญหา ซึ่งสร้างอยู่บนสแตกเครือข่ายของ Elixir
- Cyanview เลือก Elixir เพื่อให้ได้ความสามารถด้านเครือข่าย ความทนทาน และการวนรอบพัฒนาฟีเจอร์ผลิตภัณฑ์ที่รวดเร็ว
เหตุผลที่เลือก Elixir
- ทีมผู้ก่อตั้ง Cyanview มีประสบการณ์หลักด้านการพัฒนา embedded และในผลิตภัณฑ์ก็มีโค้ด C ระดับล่างกับ FPGA อยู่มาก
- รายละเอียดระดับล่างของ color science และข้อกำหนดด้าน timing ที่เข้มงวด ทำให้จำเป็นต้องมีการพัฒนาระดับล่าง
- ซอฟต์แวร์กล้องจำนวนมากแม้เข้าสู่ยุคดิจิทัลเต็มตัวแล้ว ก็ยังผูกอยู่กับระบบแอนะล็อกหรือรูปแบบการเชื่อมต่อเฉพาะทาง
- ตั้งแต่แรกพวกเขาตั้งเป้าไปที่ การควบคุมบน IP ทำให้ซอฟต์แวร์ต้องทำงานกับอุปกรณ์ผ่านเครือข่ายทั่วไป
- เมื่อการผลิตระยะไกลเพิ่มขึ้น รูปแบบที่ทีมโปรดักชันทำงานจากศูนย์กลางและลดบุคลากรในหน้างานก็แพร่หลายมากขึ้น
- โปรโตคอลไร้สายแบบกำหนดเองหรือสาย serial ขยายข้ามทวีปได้ยาก
- Erlang VM ถูกออกแบบมาเพื่อสื่อสารและประสานงานอุปกรณ์จำนวนมากผ่านเครือข่ายอย่างเสถียร และจุดนี้เองที่นำไปสู่การเลือกใช้ Elixir
การเชื่อมรวมโปรโตคอลและกรณีการผลิตระยะไกล
- นักพัฒนา Ghislain นำ Elixir มาใช้เพื่อเชื่อมรวมกล้องและอุปกรณ์วิดีโอผ่านโปรโตคอลเครือข่ายหลายแบบ
- Elixir มีความสามารถที่ใช้งานได้จริงสำหรับ เข้ารหัส·ถอดรหัส ข้อมูลไบนารีลงลึกถึงระดับบิตแต่ละบิต
- ทรัพย์สินทางปัญญาหลักของ Cyanview อยู่ที่การเชื่อมรวมอุปกรณ์จำนวนมากและการทำ reverse engineering
- ผลิตภัณฑ์ถูกออกแบบให้เข้ากันได้กับระบบกล้องมืออาชีพและอุปกรณ์ที่เกี่ยวข้องหลากหลายแบบซึ่งลูกค้าใช้งานอยู่
- ยังมีการเปิด API เพื่อให้เชื่อมรวมกับอุปกรณ์ภายนอกได้อย่างราบรื่น
-
กรณีรีโมตคอนโทรล Beijing–Paris
- ในกรณี Olympics ที่จีน สตูดิโอใน Beijing ใช้กล้อง Panasonic PTZ จำนวนมาก และทีมส่วนใหญ่ต้องควบคุมจาก Paris ระยะไกล
- โปรโตคอลของกล้อง Panasonic ไม่ได้ออกแบบมาโดยคำนึงถึงการใช้งานผ่านอินเทอร์เน็ต และการปรับแต่ละครั้งต้องอาศัย timing ที่แม่นยำกับข้อความหลายชุด
- ความหน่วงของเครือข่ายอาจนำไปสู่ timeout การตัดการเชื่อมต่อ และความล้มเหลวของระบบ
- พวกเขาใช้งานโดยวางอุปกรณ์ Cyanview ไว้ข้างกล้องที่ Beijing แล้วควบคุมจาก Paris ผ่าน IP
- อุปกรณ์ในสถานที่เดียวกันสื่อสารและประสานงานกันบนเครือข่ายด้วยโปรโตคอล MQTT แบบกำหนดเอง
โครงสร้างของ RCP·RIO และ UI
- ระบบทั้งหมดประกอบด้วยอุปกรณ์ RCP ที่รัน Yocto Linux และลอจิกที่พัฒนาด้วย Elixir·C
- Python ยังถูกใช้สำหรับงานสคริปต์และเครื่องมือ แต่บทบาทค่อย ๆ ลดลง
- ไมโครคอนโทรลเลอร์หลายตัวและอุปกรณ์บนกล้องสื่อสารกันผ่าน MQTT
- คลาวด์รีเลย์ช่วยด้านการเชื่อมต่อ และแดชบอร์ดกับคอนโทรลเลอร์ UI ใช้สำหรับการเฝ้าดูและควบคุม
- อุปกรณ์หลักมีสองชนิด
- RCP: อุปกรณ์ควบคุมฝั่งโปรดักชัน
- RIO: อุปกรณ์ที่รับผิดชอบการควบคุมกล้องแบบหน่วงต่ำ
- ทั้ง RCP และ RIO ต่างก็รัน Elixir
- UI สำหรับการตั้งค่าปัจจุบันสร้างด้วย Elm
- ตามลำดับความสำคัญ UI สำหรับการตั้งค่าอาจย้ายไปใช้ Phoenix LiveView เพื่อลดจำนวนภาษาในระบบ
- ตัวคอนโทรลเลอร์เว็บ UI เป็น LiveView อยู่แล้ว และทำงานได้ดีบนเครื่อง embedded Linux สเปกต่ำ
คลาวด์แบบจำกัดและคลัสเตอร์อุปกรณ์ภายในพื้นที่
- ส่วนคลาวด์ของ Cyanview ในตอนนี้ยังมีขอบเขตจำกัด และไม่ได้เป็นสถาปัตยกรรมที่เน้น SaaS
- คลาวด์รีเลย์รับหน้าที่ด้านการแจกจ่าย·แชร์การควบคุมกล้อง การส่งต่อพอร์ตเครือข่ายระหว่างสถานที่ และฟังก์ชันที่เกี่ยวข้อง
- คลาวด์รีเลย์ก็สร้างด้วย Elixir เช่นกัน
- อุปกรณ์ Elixir ในหน้างานสร้าง คลัสเตอร์ IP ด้วยโปรโตคอลที่อิง MQTT แบบกำหนดเองซึ่งออกแบบให้เหมาะกับงาน
- อุปกรณ์เหล่านี้สื่อสารกับกล้องหลายร้อยตัวและอุปกรณ์วิดีโออื่น ๆ
การแยกปัญหาและ supervision tree
- เมื่อเชื่อมรวมกับอุปกรณ์เฉพาะทางจำนวนมาก ความน่าเชื่อถือและคุณภาพเอกสารของแต่ละอุปกรณ์ย่อมต่างกันมาก
- อุปกรณ์บางชนิดถูกใช้อย่างแพร่หลายจนรู้พฤติกรรมของมันดี บางชนิดมีเอกสารที่ดี แต่บางชนิดก็มีพฤติกรรมคาดเดายาก
- แม้จะเกิดปัญหาชั่วคราว บั๊กของโปรโตคอล หรือความขัดข้องของการเชื่อมต่อจริงกับกล้องตัวหนึ่ง ระบบส่วนที่เหลือต้องทำงานต่อได้
- supervision tree ของ Elixir เหมาะกับการป้องกันไม่ให้ปัญหาของการเชื่อมต่อรายตัวลุกลามเป็นความล้มเหลวของทั้งระบบ
การแบ่งบทบาทของทีม 9 คน
- Cyanview เติบโตอย่างค่อยเป็นค่อยไปตลอด 9 ปี โดยเฉลี่ยเพิ่มคนปีละ 1 คน
- ปัจจุบันทีมขนาด 9 คนสนับสนุนงานถ่ายทอดสดระดับใหญ่ที่สุดของโลก
- นักพัฒนา Elixir มี 2 คน
- Daniil ดูแลงานปรับโฉม UI บางส่วนและทิศทางฟีเจอร์คลาวด์เพิ่มเติม
- Ghislain ดูแลงานเชื่อมรวมกับกล้อง
- LiveView และ Elm ถูกใช้กับ UI ของอุปกรณ์และแดชบอร์ด
- นักพัฒนา embedded คนอื่น ๆ แม้ไม่ได้ใช้ Elixir มากในงานประจำวัน แต่ก็คุ้นเคยกับการทำโปรโตคอลและการเข้ารหัสด้วย Elixir
- เหตุผลหลักที่พวกเขาไม่ได้ลงลึกกับ Elixir มากกว่านี้คือเวลามีน้อย และไม่จำเป็นต้องมีความเชี่ยวชาญ Elixir เชิงลึกเสมอไป
- งานของทีมครอบคลุมตั้งแต่การออกแบบ PCB การเลือกชิ้นส่วนอิเล็กทรอนิกส์ reverse engineering โปรโตคอล อินเทอร์เฟซจอแสดงผล การพัฒนา FPGA การจัดการการทดสอบการผลิต งานโปรดักชันจริง ไปจนถึงการอัปเดตเฟิร์มแวร์
การขยายฟีเจอร์และการพัฒนาที่เน้นลูกค้า
- อุปกรณ์ของ Cyanview ถูกใช้งานในสถานที่ต่อไปนี้
- กล้อง onboard บนรถมากกว่า 40 คันใน 24 Hours of Le Mans
- Ninja Warrior
- Australian Open
- US Open
- สตูดิโอใน Louvre
- NFL pylons
- การเชื่อมต่อกล้องพร้อมกันมากกว่า 200 ตัว
- พวกเขาสร้างอุปกรณ์บน Elixir สำหรับโลกที่ทำงานอยู่บน IP และด้วยสิ่งนี้จึงรองรับอุปกรณ์หลากหลายพร้อมเพิ่มฟีเจอร์ใหม่ได้ในเวลาเดียวกัน
- การย้ายจากคลื่นวิทยุเฉพาะพื้นที่เดิม การเชื่อมต่อ serial และโปรโตคอลเฉพาะทางที่ไม่ยืดหยุ่น ไปสู่เครือข่าย IP ได้เปลี่ยนวิธีการใช้งานระบบกล้อง
- ชุดฟีเจอร์มีดังนี้
- multicam แบบไม่จำกัด
- Tally lights
- การควบคุม Pan & Tilt
- การเชื่อมรวม color corrector
- การผลิตระยะไกลในระดับทั่วโลก
- เมื่อความต้องการถ่ายภาพผู้ชมด้วยกล้องมิเรอร์เลสติดกิมบอลเพิ่มขึ้น Cyanview ก็ทำต้นแบบการควบคุมกิมบอลอย่างรวดเร็วและทดสอบร่วมกับลูกค้าเพื่อยืนยันความเป็นไปได้
- สถาปัตยกรรมที่ยืดหยุ่นช่วยให้ส่งมอบฟีเจอร์ใหม่ได้รวดเร็วโดยไม่ทำลายฐานระบบหลัก
- บริษัทกล้องอย่าง Canon หรือ RED ที่ไม่ได้ทำรีโมต shading สำหรับงานถ่ายทอดสด จะแนะนำ Cyanview ให้ลูกค้า
- Cyanview มองตัวเองเป็นพาร์ตเนอร์มากกว่าคู่แข่งของบริษัทฮาร์ดแวร์สำหรับงานกระจายเสียงส่วนใหญ่
- พวกเขาให้ความสำคัญกับการช่วยให้อีเวนต์ของลูกค้าสำเร็จและการบริการลูกค้าเชิงลึก มากกว่าการตลาด
ทิศทางต่อจากนี้
- David Bourgeois ตอบว่าถ้าต้องเลือกใหม่อีกครั้งก็ยังจะเลือก Elixir
- เขามองว่า Erlang VM เหมาะกับความต้องการของ Cyanview มาก และคุณค่าของฟีเจอร์ที่ Elixir ให้มาในตัวนั้นยากจะเข้าใจได้เต็มที่หากยังไม่เคยลองสร้างเอง
- Cyanview อยากขยายทีมต่อ แต่ต้องการเติบโตอย่างรับผิดชอบแม้จะใช้เวลา
- ตอนนี้มีงานมากกว่าที่ทีมเล็กปัจจุบันจะรับมือได้ทั้งหมด
- นอกจากอุปกรณ์ RCP หลักแล้ว ก็มีผลิตภัณฑ์เสริมอยู่แล้ว และยังมีผลิตภัณฑ์เพิ่มเติมตามมาอีก
- มีแผนสำหรับผลิตภัณฑ์คลาวด์และโครงการฮาร์ดแวร์ที่ต่อยอดจากสิ่งที่เรียนรู้มาจนถึงตอนนี้
- Elixir จะมีบทบาทสำคัญยิ่งขึ้นในบางส่วนของการถ่ายทอดสดระดับใหญ่ที่สุดของโลก
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
พอรู้แล้วก็เห็นได้ชัดมากว่าในอีเวนต์กีฬา ต้องทำการปรับสีให้กับ กล้องแต่ละตัวที่วางไว้หลายมุม
การได้อ่านปัญหายาก ๆ ที่คนส่วนใหญ่มองไม่เห็นนั้นสนุกจริง ๆ
มีวิดีโอที่ติดตาม การสลับช็อตกล้อง ทั้งหมดของการแสดงช่วงพักครึ่ง: https://www.youtube.com/watch?v=YXNWfFtgbNI
Hamish Hamilton กำกับ โชว์ช่วงพักครึ่ง Super Bowl ทุกครั้งมาตั้งแต่ปี 2010
https://x.com/SNYtv/status/1832250958258036871
ประโยคที่ว่า “แม้ไม่มีการตลาด ก็ได้รับชื่อเสียงในหมู่ผู้เชี่ยวชาญมากฝีมือ และกลายเป็นสิ่งจำเป็นของอีเวนต์สดระดับโลก” ฟังดูสมกับเป็น วงการบันเทิง
ถ้าทำโชว์เดียวกันกับทีมงานชุดเดิมปีแล้วปีเล่า ทุกคนก็จะรู้จักกันจริง ๆ และกลายเป็นโครงสร้างคล้ายครอบครัวแบบหนึ่ง
Cyanview มีทั้ง เว็บไซต์หน้าร้าน และโพสต์การตลาดบน LinkedIn
ดีใจที่ได้เห็น Elixir มีบทบาทใน ระบบออกอากาศที่มีความสำคัญระดับ mission-critical
สงสัยว่าความน่าเชื่อถือของ Cyanview มาจาก Elixir เองมากแค่ไหน หรือเป็นผลจากการทำ MQTT ได้ดี
และสงสัยด้วยว่ามีฟีเจอร์เฉพาะของ Elixir ที่ทำซ้ำได้ยากในภาษาอื่นหรือไม่
BEAM และ OTP ให้แนวทางที่สมเหตุสมผลต่อ concurrency และ Elixir ก็เป็นภาษาที่ดีที่วางอยู่บนสิ่งนั้น
การแยกโปรเซสทำได้ดี ถึงขั้นแยก heap ตามแต่ละโปรเซสด้วย จึงรันโค้ดที่เสถียรและเติบโตเต็มที่ร่วมกับฟีเจอร์เชิงทดลองได้โดยไม่ต้องกังวลมากว่าทั้งระบบจะล่ม และการสื่อสารระหว่างโปรเซสก็ง่าย
ด้วย supervision tree การจัดการโปรเซสจึงง่าย และเรายังสร้าง supervisor เฉพาะทางที่มีกลยุทธ์รีสตาร์ตต่างกันได้ด้วย
ในสภาพแวดล้อมที่การเชื่อมต่อเครือข่ายหลุดแล้วกลับมาต่อใหม่ ความทนทานของระบบจึงถูกทดสอบบ่อย ๆ ราวกับมี chaos monkey ทางกายภาพ
ความไม่เปลี่ยนรูปแบบของ BEAM ช่วยทำให้การเขียนโค้ด concurrency ง่ายขึ้นมาก ภายในโปรเซสหนึ่งไม่ต้องกลัวว่าข้อมูลจะถูกเปลี่ยนลับ ๆ และโปรเซสอื่นก็เปลี่ยนสถานะของเราไม่ได้
ดังนั้นแทบไม่ต้องใช้ mutex หรือ critical section แต่ deadlock ก็ยังเกิดได้ จึงไม่ใช่คำตอบครอบจักรวาล
เป็นงานประสานและ route ฟีดแบบเรียลไทม์จำนวนมาก พร้อม failover และเส้นทางสำรอง โดยเป้าหมายดั้งเดิมคือสายโทรศัพท์
วิดีโอสตรีมมีข้อมูลต่อวินาทีมากกว่ามาก แต่หลักการส่วนใหญ่ยังคงใช้ได้
แม้ผมจะค่อนข้างวิจารณ์ระบบนี้ แต่สำหรับการใช้งานแบบนี้ แค่สภาพพื้นฐานของมันก็เป็นฐานที่แข็งแรงมากแล้ว
ความต่างอยู่ที่มันทำให้งานนั้น ง่ายขึ้นแค่ไหน
เคยนำ Elixir ไปใช้ในหลายที่ เช่น แอปพลิเคชันการเงินสำคัญ, B2B growth intelligence, การตรวจจับทุจริต, และการช้อปปิ้งแบบ scan-and-go
ทุกครั้ง ประสบการณ์ของนักพัฒนาและผลลัพธ์สุดท้ายเหนือความคาดหมายเหมือนทีมวิศวกรรมในบทความนี้ และถ้ายังไม่เคยลอง Elixir ก็คุ้มที่จะลองสักครั้ง
ผมเองก็ไม่ใช่ข้อยกเว้น ได้ยินเรื่องดี ๆ มาหลายสิบปี แต่ยังไม่เคยใช้ในโปรเจกต์จริง
เช่น เพิ่งปล่อยฟีเจอร์ในผลิตภัณฑ์คลาวด์ที่ให้ผู้ใช้เรียกหุ่นยนต์จากระยะไกลไปยัง waypoint ที่กำหนดภายในสถานที่ และแสดงตำแหน่งบนแผนที่แบบเรียลไทม์ขณะที่หุ่นยนต์กำลังเคลื่อนที่
เราสร้างสิ่งนี้ด้วย MQTT, LiveView, Phoenix PubSub และ JavaScript เพียงเล็กน้อยสำหรับการจัดการแผนที่ และถ้าไม่นับโค้ดเดิมสำหรับแสดง PNG แผนที่จาก S3 หรือการประมวลผล MQTT ที่รับเข้ามา ส่วนคลาวด์ใช้คนเดียวทำประมาณ 2–3 สัปดาห์
แน่นอนว่าภาษาอื่นก็ทำได้ แต่ฟีเจอร์แกนหลักของภาษาดีมากจนสำหรับการใช้งานของเรา มันทิ้งตัวเลือกอื่นไม่เห็นฝุ่น
สงสัยว่า Gleam จะใช้งานได้จริงกับแอปพลิเคชันลักษณะคล้ายกันไหม นอกเหนือจากรันไทม์ OTP/BEAM
ดูเหมือนว่ายังต้องใช้ไลบรารีของ Elixir ที่ Gleam ยังไม่มี และถึงแม้ static type อาจทำให้คอมไพล์ช้าลง แต่ก็น่าจะช่วยจับข้อผิดพลาดตอนรันไทม์ได้เร็วขึ้น
เลยสงสัยว่ามันเป็นการแลกเปลี่ยนระหว่างการดีบักกับการวนทำงานแบบไดนามิกที่รวดเร็วหรือเปล่า และกำลังพยายามเลือกระหว่าง Gleam กับ Elixir
เคยชอบไวยากรณ์แบบ ML ของ Gleam รุ่นก่อน ๆ และก็ชอบ static type ด้วย
กำลังแทนที่ C ด้วย Zig และนอกจาก x64 แล้วก็กำลังเรียน ARM พร้อมปัดฝุ่นแอสเซมบลีใหม่ด้วย
ประวัติด้านความน่าเชื่อถือของ Erlang แข็งแกร่งกว่าภาษาแบบ static type หลายภาษา รวมถึง Java ด้วย
แม้ static type จะช่วยกันข้อผิดพลาดบางประเภทได้ แต่ข้อผิดพลาดที่มันกันไม่ได้มีมากกว่ามาก
ถ้าจะอ้างว่าภาษาอย่าง TS, Java, Swift, Go, Gleam ลดข้อบกพร่องรันไทม์จริงได้มากกว่า Erlang หรือ Elixir ก็ต้องมีข้อมูลจากโลกจริงมารองรับ
ตอนนี้กำลังมีงานด้านนี้อยู่ แต่ยังไม่ได้ลองใช้ ดังนั้น Gleam ก็น่าจะใช้ได้เหมือนกัน
แต่ตอนที่เราเริ่ม Gleam ยังไม่ถึง 0.1 และไม่เคยได้ยินชื่อมาก่อนด้วย
โปรเจกต์ที่ผสม Erlang, Elixir, Gleam เข้าด้วยกันก็น่าจะเป็นไปได้ แต่ไม่แน่ใจเรื่องความคุ้มค่าในทางปฏิบัติ
คอมไพล์เร็วมากด้วย
ถึงยังไม่เคยทำโปรเจกต์ขนาดใหญ่มาก แต่แม้ใช้ไลบรารีที่ค่อนข้างหนักหลายตัว ทุกอย่างก็คอมไพล์ได้เร็วมาก
โลกของวิดีโอดิจิทัลเหมือนเป็นญาติของ IT แต่สำหรับคนที่อยู่นอกวงการวิดีโอกลับรู้สึกว่ามี อุปสรรคในการเริ่มต้น สูงเสมอ
วิธีเรียกความละเอียด สี เครือข่าย และสตอเรจ ดูเหมือนแทบจะตั้งใจให้ต่างออกไป
นี่เป็นแค่รายการที่วิศวกรวิดีโอใช้ปรับคุณภาพภาพ และปกติไม่ได้ครอบคลุมฟังก์ชันสำหรับโอเปอเรเตอร์กล้อง
ความยากอยู่ที่การสร้าง ความสอดคล้อง ระหว่างกล้องและโปรโตคอลจำนวนมากขนาดนี้
หลังจากนั้นจึงค่อยไปถึงเรื่องวิดีโอไม่บีบอัดแบบ raw yuv/y4m, วิดีโออัตราบิตสูงมากแต่บีบอัดต่ำ, และปัญหาที่ข้อมูลต้นฉบับใหญ่เกินไปจนแม้แต่เวิร์กสเตชันแรง ๆ ก็ยังตัดต่อยาก จึงต้องสร้างวิดีโอ proxy
ถ้าไม่มีเหตุผลเชิงวิชาชีพ ผู้ใช้ปลายทางทั่วไปแทบไม่ได้ประโยชน์จากการเจาะลึกเรื่องนี้
แต่ถ้าคิดจะจ่าย 7,000 ดอลลาร์กับกล้อง RED แล้วจ่ายเพิ่มอีก 13,000 ดอลลาร์สำหรับเลนส์ กิมบอล เคจ follow focus, matte box, เมมโมรีการ์ด ฯลฯ เพื่อทำแพ็กเกจผลิตงานด้วยกล้องเดี่ยวที่เล็กและคุ้มค่า ก็ถือว่าน่าเจาะลึก
เมื่อกว่า 30 ปีก่อน ในสภาพแวดล้อมสตูดิโอ งานส่วนหนึ่งคือการปรับ สมดุลสี ของกล้อง
ไม่จำเป็นต้องใช้คอมพิวเตอร์ แต่ก็มีกล้องอย่างมากแค่ 5 ตัว
ส่วนที่สะดุดตาในบทความคือ “อุปกรณ์ในสถานที่เดียวกันสื่อสารและประสานงานกันบนเครือข่ายผ่านโปรโตคอล MQTT แบบปรับแต่งเอง และจัดการกล้องกว่า 100 ตัวได้โดยไม่มีปัญหาจาก Remote Control Panel(RCP) ตัวเดียวที่สร้างบนสแต็กเครือข่าย Elixir”
ผมเข้าใจว่า MQTT สร้างอยู่บน TCP และไม่แน่ใจว่าถ้าเป็นผมจะหาคำตอบแบบเดียวกันได้ไหม แต่ดูเป็นตัวเลือกที่ค่อนข้างดี