Điều chỉnh độ nhất quán hình ảnh của Super Bowl bằng Elixir
(elixir-lang.org)- Cyanview tạo ra thiết bị camera shading để đồng bộ màu sắc, phơi sáng và tông da của hàng trăm camera trong các buổi phát sóng trực tiếp quy mô lớn như Super Bowl, và sử dụng Elixir ở đường điều khiển cốt lõi
- Hiện trường phát sóng không cho phép thất bại dù chỉ một lần, nên Cyanview lấy điều khiển mạng IP và khả năng điều phối thiết bị của Erlang VM làm nền tảng sản phẩm
- Thiết bị RCP và RIO chạy trên Yocto Linux với logic Elixir và C, hỗ trợ sản xuất từ xa bằng giao tiếp dựa trên MQTT và relay đám mây ở mức hạn chế
- Khả năng mã hóa/giải mã nhị phân của Elixir và supervision tree được dùng để tích hợp nhiều thiết bị độc quyền, cô lập sự cố kết nối và kiểm chứng tính năng nhanh
- Đội ngũ 9 người hỗ trợ các hiện trường như Le Mans, Ninja Warrior, Australian Open, US Open và kết nối hơn 200 camera, mở rộng phạm vi sản phẩm của một nhóm nhỏ
Bài toán Cyanview giải quyết tại hiện trường phát sóng
- Trong các buổi phát sóng trực tiếp như Super Bowl, cần đồng bộ màu sắc, phơi sáng, tông hình ảnh của khoảng 200 camera
- Camera shading là công việc điều chỉnh để mỗi camera hiển thị cùng một màu cỏ và cùng một tông da
- Thiết bị mục tiêu rất đa dạng, từ camera truyền hình cỡ lớn, camera drone, camera PTZ đến camera mirrorless gắn gimbal
- Cyanview là một công ty nhỏ của Bỉ bán sản phẩm cho ngành phát sóng video trực tiếp, và mảng chủ lực là shading
- Công cụ trong ngành phát sóng phải được kiểm chứng ngay tại một sự kiện trực tiếp, và rất khó chấp nhận lỗi nghiêm trọng
Cách RCP lan rộng và các nơi sử dụng
- Remote Control Panel (RCP) do một nhóm nhỏ 3 người tạo ra đã lan rộng trong ngành nhờ tính năng hơn là marketing
- RCP được các video operator chuyên nghiệp sử dụng tại các hiện trường sau
- Olympics
- Super Bowl
- NFL
- NBA
- ESPN
- Amazon
- nhiều show thời trang ở Paris
- Đã có trường hợp một RCP duy nhất xử lý ổn định hơn 100 camera, được triển khai trên stack mạng của Elixir
- Cyanview chọn Elixir để có được khả năng mạng, độ bền bỉ và vòng lặp cải tiến tính năng sản phẩm nhanh
Vì sao chọn Elixir
- Đội ngũ sáng lập Cyanview chủ yếu có kinh nghiệm phát triển nhúng, và sản phẩm chứa nhiều mã C cấp thấp cùng FPGA
- Chi tiết cấp thấp của khoa học màu sắc và yêu cầu thời gian rất chặt chẽ khiến việc triển khai ở tầng thấp là cần thiết
- Phần mềm camera, ngay cả sau khi số hóa hoàn toàn, vẫn thường bị ràng buộc vào hệ thống analog hoặc các kiểu kết nối độc quyền
- Ngay từ đầu, họ đã đặt mục tiêu điều khiển dựa trên IP, từ đó hình thành kiến trúc nơi phần mềm vận hành thiết bị trên mạng phổ thông
- Khi sản xuất từ xa gia tăng, mô hình để đội ngũ sản xuất vận hành từ vị trí trung tâm và giảm nhân sự tại hiện trường ngày càng phổ biến
- Các giao thức RF tùy biến hoặc giao thức dây nối tiếp khó mở rộng trên khoảng cách liên lục địa
- Erlang VM được thiết kế để giao tiếp và điều phối ổn định vô số thiết bị qua mạng, và điều này dẫn tới việc họ dùng Elixir
Tích hợp giao thức và ví dụ sản xuất từ xa
- Nhà phát triển Ghislain đưa Elixir vào để tích hợp camera và thiết bị video qua nhiều giao thức mạng khác nhau
- Elixir cung cấp khả năng thực dụng để mã hóa/giải mã dữ liệu nhị phân đến tận từng bit riêng lẻ
- Tài sản trí tuệ cốt lõi của Cyanview nằm ở việc tích hợp khối lượng lớn thiết bị và reverse engineering
- Sản phẩm được thiết kế để tương thích với nhiều hệ thống camera chuyên dụng và thiết bị liên quan mà khách hàng sử dụng
- Họ cũng cung cấp API để có thể tích hợp mượt mà với thiết bị bên ngoài
-
Trường hợp điều khiển từ xa Beijing–Paris
- Trong trường hợp Olympics tại Trung Quốc, studio ở Beijing dùng nhiều camera Panasonic PTZ và phần lớn đội ngũ phải điều khiển từ xa từ Paris
- Giao thức camera Panasonic không được thiết kế với mục tiêu sử dụng qua Internet, và mỗi lần điều chỉnh đều cần thời điểm chính xác cùng nhiều thông điệp
- Độ trễ mạng có thể dẫn tới timeout, mất kết nối và hệ thống thất bại
- Họ vận hành bằng cách đặt thiết bị Cyanview cạnh camera ở Beijing và điều khiển qua IP từ Paris
- Các thiết bị ở cùng địa điểm giao tiếp và phối hợp trên mạng bằng giao thức MQTT tùy biến
RCP·RIO và cấu trúc UI
- Toàn bộ hệ thống gồm thiết bị RCP chạy Yocto Linux và logic dựa trên Elixir·C
- Python vẫn được dùng cho scripting và công cụ, nhưng vai trò đang dần giảm
- Nhiều vi điều khiển và thiết bị gắn trên camera giao tiếp qua MQTT
- Relay đám mây hỗ trợ kết nối, còn dashboard và UI bộ điều khiển cung cấp khả năng giám sát và điều khiển
- Có hai thiết bị cốt lõi
- RCP: thiết bị điều khiển phía sản xuất
- RIO: thiết bị đảm nhận thao tác độ trễ thấp với camera
- Cả RCP và RIO đều chạy Elixir
- UI cấu hình hiện được xây dựng bằng Elm
- Tùy theo mức độ ưu tiên, UI cấu hình có thể chuyển sang Phoenix LiveView để giảm số lượng ngôn ngữ sử dụng
- UI web của bộ điều khiển đã dùng LiveView và hoạt động tốt ngay cả trên máy nhúng Linux cấu hình thấp
Đám mây hạn chế và cụm thiết bị cục bộ
- Phần đám mây của Cyanview hiện còn hạn chế và không phải cấu trúc lấy SaaS làm trung tâm
- Relay đám mây đảm nhận việc triển khai/chia sẻ điều khiển camera, chuyển tiếp cổng mạng giữa các địa điểm và các chức năng liên quan
- Relay đám mây cũng được xây dựng bằng Elixir
- Các thiết bị Elixir tại hiện trường tạo thành cụm IP bằng giao thức tùy biến dựa trên MQTT được thiết kế theo từng công việc
- Các thiết bị này giao tiếp với hàng trăm camera và các thiết bị video khác
Cô lập lỗi và supervision tree
- Khi tích hợp nhiều thiết bị độc quyền, độ tin cậy và chất lượng tài liệu của từng thiết bị khác nhau rất lớn
- Một số thiết bị được dùng phổ biến nên đặc tính đã khá rõ, một số có tài liệu tốt, nhưng thiết bị khác lại cho thấy hành vi khó dự đoán
- Ngay cả khi một kết nối camera gặp sự cố tạm thời, giao thức lỗi hoặc trục trặc kết nối vật lý, phần còn lại vẫn phải tiếp tục hoạt động
- Supervision tree của Elixir có lợi thế trong việc ngăn sự cố ở từng kết nối riêng lẻ lan thành lỗi toàn hệ thống
Phân chia vai trò trong đội ngũ 9 người
- Cyanview đã tăng trưởng chậm trong 9 năm, trung bình mỗi năm thêm 1 người
- Hiện nay, đội ngũ 9 người hỗ trợ các sự kiện phát sóng thuộc hàng lớn nhất thế giới
- Có 2 lập trình viên Elixir
- Daniil phụ trách một phần cải tổ UI và định hướng bổ sung nhiều tính năng đám mây hơn
- Ghislain phụ trách camera và công việc tích hợp
- LiveView và Elm được dùng cho UI thiết bị và dashboard
- Các lập trình viên nhúng khác không dùng Elixir quá nhiều trong công việc hằng ngày, nhưng quen với việc triển khai giao thức và mã hóa bằng Elixir
- Lý do chính khiến họ chưa học Elixir sâu là thiếu thời gian, và chuyên môn Elixir ở mức sâu không phải điều bắt buộc
- Công việc của đội ngũ bao gồm thiết kế PCB, chọn linh kiện điện tử, reverse engineering giao thức, giao diện hiển thị, triển khai FPGA, quản lý kiểm thử sản xuất, vận hành sản xuất thực tế và cập nhật firmware
Mở rộng tính năng và phát triển xoay quanh khách hàng
- Thiết bị Cyanview được dùng tại các hiện trường sau
- hơn 40 camera onboard trên xe tại 24 Hours of Le Mans
- Ninja Warrior
- Australian Open
- US Open
- studio ở Louvre
- NFL pylons
- kết nối đồng thời hơn 200 camera
- Họ tạo ra thiết bị dựa trên Elixir cho một thế giới vận hành trên IP, từ đó vừa hỗ trợ đa dạng thiết bị vừa cung cấp tính năng mới
- Việc chuyển từ RF cục bộ, kết nối nối tiếp và các giao thức độc quyền kém linh hoạt sang mạng IP đã làm thay đổi cách vận hành hệ thống camera
- Bộ tính năng bao gồm
- multicam không giới hạn
- Tally lights
- điều khiển Pan & Tilt
- tích hợp color corrector
- sản xuất từ xa trên phạm vi toàn cầu
- Khi nhu cầu quay cảnh khán giả bằng camera mirrorless gắn gimbal tăng lên, Cyanview đã nhanh chóng tạo prototype điều khiển gimbal, thử nghiệm cùng khách hàng và xác thực
- Kiến trúc linh hoạt cho phép phát hành nhanh tính năng mới mà không phá vỡ nền tảng cốt lõi
- Các hãng camera như Canon hay RED, vốn không tạo remote shading cho phát sóng, giới thiệu Cyanview cho khách hàng
- Cyanview xem mình là đối tác hơn là đối thủ của phần lớn các công ty phần cứng phát sóng
- Họ coi trọng việc hỗ trợ khách hàng thành công tại sự kiện và cung cấp dịch vụ khách hàng chuyên sâu hơn là marketing
Hướng đi sắp tới
- David Bourgeois cho biết nếu chọn lại, ông vẫn sẽ chọn Elixir
- Erlang VM rất phù hợp với nhu cầu của Cyanview, và giá trị của những gì Elixir cung cấp sẵn khó có thể hiểu hết trước khi tự tay xây dựng
- Cyanview muốn mở rộng đội ngũ hơn nữa, nhưng muốn tăng trưởng có trách nhiệm dù phải mất thời gian
- Hiện có nhiều việc hơn khả năng mà đội ngũ nhỏ hiện tại có thể gánh vác
- Bên cạnh thiết bị RCP chủ lực, họ đã có các sản phẩm bổ trợ và sẽ còn thêm nhiều sản phẩm nữa
- Các sản phẩm đám mây và những dự án phần cứng dựa trên bài học tích lũy tới nay đang được lên kế hoạch
- Elixir sẽ đảm nhận vai trò ngày càng quan trọng hơn trong một phần của những buổi phát sóng trực tiếp lớn nhất thế giới
1 bình luận
Các ý kiến trên Hacker News
Sau khi biết rằng trong các sự kiện thể thao, từng camera được bố trí ở nhiều góc khác nhau đều phải được cân chỉnh màu, điều đó nghe quá hiển nhiên
Đọc về những vấn đề khó mà hầu hết mọi người không nhìn thấy thật sự rất thú vị
Có một video theo dõi tất cả các lần chuyển cảnh giữa các góc máy trong show giữa giờ: https://www.youtube.com/watch?v=YXNWfFtgbNI
Hamish Hamilton đã đạo diễn mọi show giữa giờ Super Bowl kể từ năm 2010
https://x.com/SNYtv/status/1832250958258036871
Đoạn “không cần marketing mà vẫn tạo được danh tiếng trong giới chuyên gia lão luyện và trở thành thứ không thể thiếu ở các sự kiện live hàng đầu thế giới” nghe rất đúng kiểu ngành giải trí
Khi làm cùng một show với cùng một ê-kíp qua từng năm, thật sự là ai cũng biết ai, và nó trở thành một cấu trúc gần như gia đình
Cyanview cũng có website storefront và các bài đăng marketing trên LinkedIn
Thật vui khi thấy Elixir có chỗ đứng trong các hệ thống phát sóng mission-critical
Tôi tò mò độ tin cậy của Cyanview đến từ bản thân Elixir đến mức nào, hay là nhờ triển khai MQTT tốt
Cũng tò mò liệu có tính năng cụ thể nào của Elixir từng khó tái tạo bằng ngôn ngữ khác không
BEAM và OTP cung cấp một cách tiếp cận lành mạnh với concurrency, còn Elixir là một ngôn ngữ tốt nằm bên trên nền tảng đó
Khả năng cô lập process rất tốt, đến mức heap cũng được tách theo từng process, nên có thể chạy chung mã trưởng thành ổn định và các tính năng thử nghiệm mà ít lo toàn bộ hệ thống sụp đổ; giao tiếp giữa các process cũng dễ dàng
Nhờ supervision tree, việc quản lý process trở nên dễ hơn, và chúng tôi cũng có thể tạo các supervisor chuyên biệt với những chiến lược restart khác nhau
Trong môi trường kết nối mạng thường xuyên bị ngắt rồi nối lại, khả năng phục hồi của hệ thống liên tục bị thử thách như một chaos monkey vật lý
Tính bất biến kiểu BEAM đơn giản hóa đáng kể việc viết mã concurrency: trong một process, không phải lo dữ liệu bị âm thầm thay đổi, và process khác cũng không thể thay đổi trạng thái của mình
Vì vậy hầu như không cần mutex hay critical section, nhưng deadlock vẫn có thể xảy ra, nên đây không phải thuốc chữa bách bệnh
Công việc là điều phối và định tuyến vô số feed thời gian thực với failover và đường đi thay thế; đối tượng ban đầu là các cuộc gọi điện thoại
Luồng video có lượng dữ liệu mỗi giây lớn hơn nhiều, nhưng nguyên lý phần lớn vẫn tiếp nối
Tôi khá hay phê bình hệ thống này, nhưng với kiểu tác vụ như vậy thì ngay trạng thái mặc định cũng đã là một nền tảng rất mạnh
Khác biệt nằm ở chỗ nó giúp việc đó dễ đến mức nào
Tôi đã áp dụng Elixir ở nhiều nơi như ứng dụng tài chính quan trọng, growth intelligence B2B, phát hiện gian lận, mua sắm scan-and-go
Lần nào trải nghiệm phát triển và kết quả cuối cùng cũng vượt kỳ vọng, giống như đội ngũ kỹ thuật trong bài này; nếu bạn chưa thử Elixir thì đáng để thử một lần
Bản thân tôi cũng không ngoại lệ: đã nghe những điều tốt đẹp về chúng suốt hàng chục năm, nhưng chưa từng dùng trong dự án thực tế
Ví dụ, chúng tôi vừa triển khai cho sản phẩm cloud một tính năng cho phép người dùng gọi robot từ xa tới waypoint chỉ định trong cơ sở, đồng thời hiển thị vị trí của robot trên bản đồ theo thời gian thực khi nó di chuyển
Chúng tôi làm tính năng này chỉ bằng MQTT, LiveView, Phoenix PubSub và rất ít JavaScript để thao tác bản đồ; nếu không tính mã hiện có để hiển thị PNG bản đồ từ S3 hay xử lý nhận MQTT, phần cloud do một người triển khai trong khoảng 2–3 tuần
Tất nhiên ngôn ngữ khác cũng làm được, nhưng các tính năng cốt lõi của ngôn ngữ quá tốt đến mức với nhu cầu của chúng tôi, nó vượt trội so với các lựa chọn khác
Tò mò liệu Gleam có thực dụng cho các ứng dụng tương tự không, ngoài runtime OTP/BEAM
Có lẽ vẫn phải tận dụng các thư viện Elixir mà Gleam chưa có, và vì kiểu tĩnh nên biên dịch có thể chậm hơn, nhưng có thể bắt lỗi runtime sớm hơn
Tò mò liệu đây có giống một sự đánh đổi giữa gỡ lỗi và vòng lặp động nhanh hay không, và đang cố chọn giữa Gleam và Elixir
Cũng thích cú pháp kiểu ML của Gleam trước đây và thích kiểu tĩnh
Đang thay C bằng Zig, đồng thời học ARM bên cạnh x64 và ôn lại assembly
Hồ sơ về độ tin cậy của Erlang mạnh hơn nhiều ngôn ngữ kiểu tĩnh, kể cả Java
Đúng là kiểu tĩnh ngăn được một số nhóm lỗi, nhưng có nhiều lỗi hơn rất nhiều mà nó không ngăn được
Nếu muốn nói các ngôn ngữ như TS, Java, Swift, Go, Gleam làm giảm lỗi runtime thực tế hơn Erlang hay Elixir thì cần dữ liệu thực tế
Hiện việc này đang được phát triển, nhưng tôi chưa dùng thử, nên Gleam cũng có vẻ ổn
Tuy vậy lúc chúng tôi bắt đầu, Gleam còn chưa tới 0.1 và tôi cũng chưa từng nghe đến nó
Một dự án pha trộn Erlang, Elixir và Gleam cũng có thể làm được, nhưng tôi không chắc tính thực dụng ra sao
Biên dịch cũng rất nhanh
Tôi chưa làm dự án thật lớn nào, nhưng ngay cả khi dùng các thư viện khá nặng thì mọi thứ vẫn biên dịch rất nhanh
Thế giới video số giống như họ hàng của IT, vậy mà với người ngoài ngành video thì luôn có cảm giác rào cản gia nhập rất cao
Cách gọi độ phân giải, màu sắc, mạng và thiết bị lưu trữ trông gần như cố tình khác đi
Đây chỉ là các mục để kỹ sư hình ảnh điều chỉnh chất lượng hình ảnh, và thường không bao gồm các chức năng dành cho người vận hành camera
Cái khó nằm ở việc tạo ra tính nhất quán giữa rất nhiều camera và giao thức như vậy
Sau đó mới có thể chuyển sang các vấn đề như video thô yuv/y4m không nén, video bitrate cực cao với mức nén thấp, và việc tạo video proxy vì dữ liệu gốc quá lớn đến mức ngay cả workstation mạnh cũng khó chỉnh sửa
Nếu không có lý do chuyên môn, người dùng cuối thông thường gần như không có lợi ích gì khi đào sâu
Nếu bạn định chi 7.000 USD cho một camera RED rồi thêm 13.000 USD cho ống kính, gimbal, cage, follow focus, matte box, thẻ nhớ, v.v. để tạo một bộ sản xuất một camera nhỏ gọn và hiệu quả về chi phí, thì đáng để đào sâu
Hơn 30 năm trước, trong môi trường studio, việc cân cân bằng màu cho camera là một phần công việc
Không cần máy tính, nhưng nhiều lắm cũng chỉ có 5 camera
Phần trong bài viết nói rằng “các thiết bị tại một địa điểm giao tiếp và phối hợp trên mạng bằng giao thức MQTT tùy chỉnh, và xử lý hơn 100 camera mà không gặp vấn đề từ một Remote Control Panel (RCP) duy nhất được triển khai trên network stack Elixir” khiến tôi chú ý
Tôi hiểu MQTT được xây dựng trên TCP, và không biết liệu mình có tìm ra cùng giải pháp hay không, nhưng trông có vẻ là một lựa chọn khá tốt