크롬북으로 제작한 가장 기발한 비디오 월

 (varun.ch)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 폐기 예정이던 학교 지급 Lenovo ThinkPad 11e 크롬북을 분해·재활용해 10개 화면짜리 비디오 월을 만드는 데 약 3년이 걸림
  • 별도 디스플레이 컨트롤러 대신 기존 노트북 메인보드가 각 화면을 구동하고, 웹 기반 동기화 시스템으로 하나의 영상을 10개 조각으로 나눠 재생함
  • socket.io 기반 c-sync 는 느린 성능, 로딩 시간 차이, 지연 시간, 시스템 시계 문제를 겪었지만, 가장 느린 클라이언트에 맞춰 루프를 늦추는 방식으로 거의 동기화된 재생을 구현함
  • ChromeOS의 기업 등록, 개발자 모드 제한, 배터리 제거 시 전원 문제는 coreboot, MrChromebox 도구, Debian 자동 설치 USB, ectool 팬 제어로 우회함
  • TN 패널 시야각, 색상 차이, 완벽하지 않은 동기화가 남았지만, 전자폐기물을 협업과 반복 설계로 실제 작동하는 설치물로 바꾼 사례임

폐기 예정 크롬북에서 시작한 비디오 월

  • 학교가 기존 크롬북들을 폐기하려 하면서, 이를 활용해 무엇을 만들 수 있을지에서 프로젝트가 시작됨
  • 사용된 기기는 Lenovo ThinkPad 11e로, 학교 지급용 노트북이었지만 더 이상 Google 소프트웨어 업데이트를 받지 못함
  • 대부분 웹페이지 로딩도 버거웠고, 오래된 Enterprise Enrolment에 묶여 학교 Google 계정 없이는 사용하기 어려웠음
  • 목표는 여러 화면을 하나의 큰 디스플레이처럼 배치해 동작하는 비디오 월을 만드는 것이었음

화면 구동 방식과 동기화 실험

  • 처음에는 노트북 디스플레이 패널만 떼어내 강력한 컴퓨터 하나로 10개 화면을 동시에 구동하는 방식을 검토함
  • 시간과 비용 부담이 컸고, 화면이 이미 작동하는 노트북에 붙어 있었기 때문에 각 화면을 각자의 노트북 메인보드로 구동하는 방식으로 전환함
  • VLC 스트리밍으로 같은 네트워크 안의 여러 장치에 영상을 보내는 실험도 했지만, 비디오 월 요구사항과 맞지 않았음
    • 영상이 완벽히 동기화되도록 설계된 시스템이 아니었음
    • 10개 화면에 같은 영상을 반복 표시하는 것이 아니라, 하나의 긴 영상을 10개 조각으로 나눠 각 화면에 다른 입력을 표시해야 했음

c-sync로 맞춘 재생 타이밍

  • 웹페이지와 socket.io를 이용해 클라이언트 간 비디오 재생을 맞추는 ExpressJS 서버/클라이언트 시스템 c-sync 를 만듦
  • 기본 구조는 서버가 play 이벤트를 보내면 각 클라이언트의 <video> 요소가 재생을 시작하는 방식이었음
  • 데스크톱 컴퓨터 테스트에서는 꽤 잘 동기화되는 것처럼 보였지만, 실제 크롬북에서는 성능 부족 때문에 안정적으로 맞지 않았음
    • 로딩 시간 차이
    • 네트워크 지연
    • 시스템 시계 차이
  • 최종 방식은 각 클라이언트가 영상 끝에 도달하면 start 이벤트를 내보내도록 바뀜
    • 가장 느린 컴퓨터가 빠른 컴퓨터를 기다리게 만들어 영상 로딩 시간을 확보함
    • 각 화면이 10개의 start 이벤트를 받을 수 있어 루프 시점이 약간 흔들릴 수 있음
    • 영상의 첫 몇 프레임이 같으면 사용자가 차이를 알아차리기 어려웠음
  • 타임스탬프 기반 예약 재생도 가능해 보였지만, 이 크롬북들은 서로 밀리초 단위로 시간을 안정적으로 맞추지 못해 작동하지 않았음

ChromeOS를 벗어나기 위한 펌웨어 작업

  • 한두 달 안에 웹페이지를 수동으로 열어 전체 화면 동기화 영상을 보여주는 단계까지 도달함
  • 실제 설치물로 쓰려면 전원이 들어오면 자동 부팅되고 c-sync 클라이언트 페이지가 열려야 했음
  • 기본 ChromeOS는 학교 도메인으로 잠긴 Google 로그인 화면으로 부팅됐고, 배터리를 제거한 상태에서는 전원을 연결해도 자동으로 켜지지 않았음
  • MrChromebox의 ChromeOS Firmware Recovery Script를 사용해 GLIMMER 메인보드를 다룸
    • Recovery Mode 진입
    • Developer Mode 활성화
    • ChromeOS Shell에서 스크립트 실행
  • 일부 크롬북은 Enterprise Enrolment 때문에 Developer Mode 진입을 거부했고, Linux 설치에 성공한 기기들도 시간이 지나면 비디오 재생이 멈추거나 시스템 전체가 잠겼음
  • 해결책은 각 노트북 메인보드에서 Write Protection 나사를 제거하고 기본 펌웨어 전체를 coreboot로 덮어쓰는 것이었음
    • 이 과정이 등록 제한도 우회한 것으로 보였음
    • 20대가 넘는 컴퓨터에서 반복해야 해 느리고 번거로웠음
    • 이후 Wake on AC가 펌웨어 기능으로 동작했고, 비디오 재생도 무작위로 깨지지 않았음

자동 부팅되는 Linux 키오스크 만들기

  • 처음에는 Chromium을 열고 키 입력을 흉내 내 전체 화면으로 만드는 시작 스크립트를 사용함
  • FullPageOS는 이전 프로젝트에서 사용해 봤지만 x86 하드웨어에서 동작하지 않았음
  • Porteus Kiosk는 최소 Linux 배포판으로 전체 화면 Chromium을 실행하고, 사용자 상호작용 없이 비디오 재생을 허용하는 플래그를 설정할 수 있어 잘 동작함
  • 다만 Porteus Kiosk는 실제 설치물 운영에 걸림돌이 있었음
    • 부팅 때마다 Porteus 로고가 표시되는 스플래시 화면을 바꿀 수 없었음
    • 설치 후 페이지 URL 변경 같은 원격 작업을 할 수 없어, 벽에 장착한 뒤 문제가 될 수 있었음
  • 자체 배포판에 가까운 구성을 만들기 위해 최소 시스템에서 데스크톱 환경 없이 kiosk 모드 Chromium을 자동 실행하는 방식을 시도함
  • NixOS는 크롬북의 작은 저장공간 때문에 설치에 실패함
  • 이후 Debian minimal install을 기반으로 프로비저닝 스크립트를 작성함
    • KIOSK_ID 생성
    • 호스트명을 csync-client-$KIOSK_ID로 설정
    • 학교 WiFi 연결
    • 사용자와 권한 생성
    • openbox로 전체 화면 kiosk 모드 Chromium 자동 시작
  • 수동 Debian 설치가 번거로워 FAI - Fully Automatic Installation과 FAI.me를 사용함
  • 최종적으로 coreboot가 적용된 크롬북에 꽂으면 c-sync 클라이언트로 자동 프로비저닝하는 단일 USB를 만들었음
  • c-sync에는 연결된 클라이언트를 관리하고 각 클라이언트에 영상을 할당하는 controller도 추가됨
  • 3일간의 스트레스 테스트에서 재생이 부드럽게 유지된 뒤 벽 장착 단계로 넘어감

장착, 전원, 발열 처리

  • 장착 하드웨어는 Aksel Salmi가 설계했으며, 메인보드와 디스플레이를 벽에 걸 수 있는 구조가 사용됨
  • 전원 공급 장치는 각 어댑터가 두 대의 컴퓨터에 전원을 공급할 수 있도록 케이블을 이어 붙이는 방식으로 구성됨
  • 설치 뒤 가장 큰 문제는 발열이었고, 펌웨어를 지우는 과정 이후 노트북 팬이 돌지 않았음
  • ChromeOS Embedded Controller에는 ectool로 접근할 수 있어 팬 속도를 수동 설정할 수 있음
  • 온라인 문서가 부족했고 coreboot와 Google 쪽 ectool이 달라 혼란이 있었지만, Wayback Machine을 통해 구한 바이너리가 팬 속도 설정에 정상 동작함
  • 테스트를 거쳐 소음과 온도 사이 균형이 맞는 팬 속도 값을 찾음

10개 화면용 영상 제작

  • 각 디스플레이 해상도는 1366×768이고, 10개 화면 전체 영상은 13660×768이 됨
  • 이처럼 넓은 영상을 편집할 수 있는 소프트웨어가 많지 않았고, 실제로 Final Cut Pro와 Blender만 사용 가능했음
  • 전체 폭 영상을 렌더링한 뒤 ffmpeg로 10개 구간으로 잘라 각 화면에 배정함
  • 분할 스크립트는 crop=1366:768:x_offset:0 형태로 각 화면 위치에 맞는 세그먼트를 생성함

완성 결과와 남은 한계

  • 완성된 비디오 월은 부팅 시퀀스, 자체 보정처럼 보이는 과정, 동기화 영상 재생, 인클로저와 케이블 라우팅까지 갖춤
  • 결과물은 완벽하지 않음
    • TN 패널의 시야각이 좋지 않음
    • 화면마다 색상이 다름
    • 동기화가 완벽하지 않음
    • 각 의사결정에는 더 나은 대안이 있었을 수 있음
  • 그래도 전자폐기물을 흥미로운 설치물로 바꾸고, 반복 설계와 팀 협업을 보여주는 결과물로 완성됨

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 재미있는 프로젝트를 완성한 것 축하함. 여러 기기에서 미디어 동기화 작업을 많이 해서, 사람들이 어떤 해법을 내놓는지 보는 게 늘 즐거움
    이런 동기화된 비디오 월을 만드는 업계 표준 방식은 BrightSign 미디어 플레이어를 쓰는 것인데, 20대 디스플레이 기준 플레이어와 화면 구매 비용만 수만 달러까지 쉽게 올라갈 수 있음. 재활용 기기로 작동하게 만든 점이 정말 대단함
    미디어 동기화 관련 코드베이스 작업에 관심 있으면 연락해도 좋음. 프리랜서 계약 개발자를 꽤 자주 채용함

    • 고마움. 블로그 글에는 못 넣었지만 상용 솔루션 가격표도 확인해 봤고, 정말 비쌌음
      비용 중 하드웨어와 소프트웨어 비중이 각각 얼마나 되는지 늘 궁금했고, 전문 디지털 사이니지는 신뢰성·수명 같은 부분까지 고려해 설계됐을 것 같음

  • Chromebook이 출시됐을 때 Google에서 일하고 있었고, 로비 장식 아이디어를 모집하길래 비슷한 걸 제안했지만 거절당함. 아마 40~64대 기기를 요청해서였을지도 모름
    다만 비디오는 동기화하려 하지 않았을 것 같고, 대신 시간 기반 애니메이션을 만들고 네트워크로 시계를 맞췄을 것임
    예시는 여기서 볼 수 있음: https://www.youtube.com/watch?v=64TcBiqmVko
    Chrome을 실행하는 8대 기기이고, 동기화된 것은 설정과 시간뿐임. 기기들이 꼭 격자 형태일 필요도 없고, Boston Science Museum의 가상 수족관에서 영감을 받았음

    • 글쓴이도 시도했지만 시계가 동기화 상태를 유지하지 못했음. 접을 수 있는 사이드노트에 있음
      “안타깝게도 이 Chromebook들은 서로 밀리초 단위로 시간을 안정적으로 맞추지 못해서, 이 방식은 우리에게 작동하지 않았다”는 내용임
    • 고정 미디어라면, 실시간으로 동적 생성되거나 스트리밍되는 경우가 아니라면 이 요령이 꽤 멀리 갈 수 있음. 생성형이라도 시간이 애니메이션을 구동하는 값으로 쓰이면 가능함
      말한 것처럼 좋은 시계 동기화가 필요하고, 특히 오디오가 있으면 20~30ms 차이도 매우 눈에 띄어서 쉽지 않음. 그래도 NTP/PTP를 쓰면 상당히 멀리 갈 수 있음

  • 멋짐. 4x4 태블릿으로 비슷한 걸 해봤고, 16대를 모두 ADB와 단일 호스트에 연결한 뒤 대부분을 자동화할 수 있었음
    이후 sway에서 가상 화면 16개와 VNC 클라이언트 16개를 만들고 Wi-Fi로 전부 스트리밍해 테스트했는데, Wi-Fi가 너무 잘 동작해서 더 효율적인 해법은 찾지 않았음
    그 기간 동안 내 PC에는 디스플레이가 19개 있었고, 그중 17개가 VNC였는데 장관이었음. 전체에 같은 작업을 하거나, 음악·htop·캘린더·시계·ssh 세션처럼 각각 다른 용도로 쓸 수 있었음
    다만 하드웨어를 다루는 건 꽤 성가셨음. 일부는 스로틀링이 걸리고, 일부는 연결 문제가 있었고, 어떤 배터리는 충전을 유지하지 못했음

  • 오래전에 비슷한 것으로 Junkyard Jumbotron이 있었음. 제각각인 디스플레이들을 모아 더 큰 이미지의 각 부분을 표시할 수 있게 해줬음
    https://github.com/mitmedialab/Junkyard-Jumbotron
    영상: https://youtu.be/cAUtSVSTbzU?feature=shared

    • Media Lab은 무작위로 재미있는 걸 정말 많이 만듦. 현대적인 웹 기술로 이걸 다시 만들어도 재미있을 것 같음
      정렬용 사진을 이메일로 보내는 방식도 나름 재미있어 보임

  • 대충 훑고 전체 블로그를 안 읽었다면, 이 프로젝트는 고등학생들이 고등학교 재학 기간 동안 만든 것임. 그래서 더 인상적으로 보임

  • “왜 이렇게 잘 동작하는지 완전히 확신은 없지만, 우연히 터무니없는 해법을 떠올렸다”와 “가장 느린 컴퓨터가 가장 빠른 컴퓨터를 붙잡는다”는 부분을 보면, 병목에 맞춰 시스템 설계를 최적화했기 때문에 잘 동작하는 것임
    제약 이론을 보면 좋음

  • 한 번은 큰 터치스크린 TV 5대를 테이블처럼 배치해 비슷한 일을 해야 했음. 각 면은 별도 터치스크린 앱이어야 했고, 모두 배경에서 동기화된 비디오를 재생하면서 사용자가 한쪽 끝에서 다른 쪽 끝으로 흐르는 요소와 상호작용하거나, 테이블 반대편 사용자에게 찾은 객체를 보내는 식이었음
    결국 모든 화면을 동시에 구동할 수 있는 예산 내 장비가 거의 원통형 Mac Pro뿐이라 그걸 썼고, 앱들은 Redis로 동기화했음. 그 부분은 내가 작성했음
    꽤 잘 동작했지만, 회사를 떠나기 전에 완성품은 보지 못했음. 원래는 별도 컴퓨터들을 동기화하고 싶었지만 충분히 안정적으로 만들 수 없었고, 잠시 작동하다가 여러 요인으로 동기화가 틀어져 애플리케이션을 주기적으로 재시작해야 했는데 그건 불가능했음
    PC 초기부터 늘 바라던 건 여러 기기를 네트워크로 묶어 자원을 공유하고 더 협력하게 만드는 능력이었음. 사무실의 모든 컴퓨터를 슈퍼컴퓨터처럼 활용해 작업을 처리하는 모습을 상상해 왔음. 물론 매우 어려운 문제이고, 앱과 운영체제가 그런 식으로 설계되어야 하며 새 알고리즘도 필요함. 같은 보드의 단일 기기 안에서 다중 프로세서를 제대로 활용하는 데도 오래 걸렸다는 걸 보면 더 그렇지만, seti@home이나 folding@home 같은 프로젝트는 어느 정도 그런 일을 했고, 언젠가는 컴퓨터 자체가 이를 지원하길 바랐음

  • “노트북에 설치할 수 있는 ‘내 배포판’을 만들기 시작했다. 시스템은 최소 구성으로 시작하고, 데스크톱 환경 없이 kiosk 모드 Chromium 인스턴스를 자동 시작하는 우아한 스크립트가 있어야 했다. 처음엔 NixOS를 시도했지만 이 Chromebook들의 저장공간이 너무 작아서 불가능하다는 걸 금방 깨달았고, 매번 설치에도 실패했다. 결국 포기하고 Debian 최소 설치로 시작했는데, Debian 설치는 버튼을 많이 눌러야 해서 시간이 너무 낭비된다는 걸 깨달았고, ‘FAI - Fully Automatic Installation’과 웹 도구 FAI.me를 발견했다”는 부분을 보면, DietPi, OpenWrt, OpenBalena도 특정 패키지를 선택해 최소 베어메탈에 설치하는 자동 설치 옵션이 있음
    다른 비데스크톱 선택지가 더 있는지도 궁금함

  • 가장 흥미로운 건 coreboot로 바꾸자 멈춤 현상이 해결됐다는 점임. 왜 그런지 이론이 있는지 궁금함
    ACPI/DSDT 관련일 수도 있고, 원래 BIOS가 하드웨어 컨트롤러를 잘못 초기화했기 때문일 수도 있어 보임

    • 감시 타이머가 발동한 것일 수도 있음
답변달기