TL;DR

Castor는 헤드리스 Chrome으로 웹 페이지의 네트워크 트래픽을 모니터링해 실제 미디어 스트림을 추출하고 ffprobe/ffmpeg로 포맷을 검사·처리해 DLNA나 실험적 Chromecast로 실시간 전송하는 터미널 기반 도구이다. 가능한 경우 stream-copy로 소스 패킷을 그대로 전달해 CPU 사용을 거의 0으로 낮추고, 필요 시 하드웨어 인코더(VA-API, VideoToolbox)나 libx264로 재인코딩해 TV 호환성을 확보한다. whisper.cpp 바인딩을 통해 로컬에서 자동 자막을 생성할 수 있으며 Docker 이미지를 제공하지만 Docker는 Linux 호스트에서의 네트워크 및 GPU 노출 제약을 명시해 실제 배포 환경에서 주의가 필요하다.

주요 기능

• 웹 페이지에서 비디오 리소스를 자동으로 추출하고 재생을 시뮬레이션해 스트림 URL을 획득한다. 이 과정에서 Castor는 headless Chrome의 DevTools Protocol을 사용해 네트워크 트래픽을 관찰하고 가장 큰 iframe으로 이동해 클릭하는 파이프라인을 실행한다. 추출된 스트림은 즉시 재생 파이프라인으로 전달된다.
• 추출한 스트림을 ffprobe로 포맷 검사한 뒤 가능한 경우 stream-copy로 전송해 CPU 사용을 거의 0으로 유지하거나 필요 시 ffmpeg로 재인코딩한다. 재인코딩 시에는 호스트에서 동작하는 하드웨어 인코더(VA-API, VideoToolbox)를 우선 사용하고 동작하지 않으면 libx264로 소프트웨어 인코딩을 수행한다. 이로 인해 TV가 지원하는 프로파일/레벨로 자동 조정하여 호환성을 확보한다.
• 로컬 자동 자막 생성 기능을 제공하며 whisper.cpp 바인딩을 통해 소형 모델을 로컬에 다운로드해 음성 트랜스크립션을 수행한다. 자막은 원하는 경우 비디오에 번(burn)해서 출력할 수 있으며 whisper 관련 설정은 config에서 활성화하거나 모델 경로를 지정할 수 있다. whisper 바인딩은 정적 라이브러리 빌드가 필요해 소스 빌드 절차가 요구된다.
• TMDB 키를 설정하면 대화형 터미널 UI에서 타이틀 검색과 소스 템플릿을 조합해 영화/에피소드 ID를 열어 자동으로 소스를 열고 추출할 수 있다. 사용자가 직접 구성한 프록시와 템플릿을 순서대로 시도해 접근 가능한 소스를 찾아낸다. 이 방식은 Castor가 별도의 카탈로그를 제공하지 않고 사용자가 합법적으로 접근 가능한 소스만 사용한다는 설계와 결합된다.

어떻게 동작하는가

Castor는 헤드리스 Chrome을 실행해 DevTools Protocol로 페이지의 네트워크 트래픽을 모니터링하고 요청 중 비디오 스트림 엔드포인트를 식별한다. 스트림이 발견되면 Castor는 ffprobe로 포맷을 검사하고, TV가 재생 가능한 포맷이면 stream-copy로 패킷을 전달해 CPU 부하를 최소화하며, 그렇지 않으면 하드웨어 인코더(VA-API, VideoToolbox)를 우선시해 ffmpeg로 재인코딩한다. 또한 whisper.cpp 바인딩을 통해 로컬에서 음성 인식을 수행해 선택적으로 자막을 번(burn)인하므로 외부 서비스 의존 없이 자막을 생성할 수 있다.

해결 문제

스마트 TV는 모든 웹 비디오를 직접 재생하지 못하거나 화면 미러링이 대역폭과 해상도 손실을 야기해 원본 화질을 유지하기 어렵다. Castor는 웹 페이지나 스트림 URL에서 실제 미디어 스트림을 찾아 직접 재전송함으로써 화면 미러링 대신 원본 화질에 가까운 스트리밍을 가능하게 한다. 또한 디바이스가 지원하는 코덱/프로파일을 확인해 stream-copy 또는 하드웨어/소프트웨어 트랜스코딩을 선택해 실시간으로 TV에 전달한다.

지금 주목받는 이유

README에 Homebrew 설치, GitHub Release 배지, GitHub Actions 빌드 상태가 표시되어 있어 네이티브 배포와 패키징이 잘 갖춰진 프로젝트로 인식된다. Docker 이미지를 통해 의존성 번들링을 제공하면서도 네트워크·하드웨어 제약을 명확히 문서화해 실사용자 경험을 고려한 설계가 드러난다. 또한 로컬 whisper 자막 지원과 터미널 기반 대화형 브라우징 기능이 실용적 조합으로 주목을 받는다.

차별점

• 디바이스 네이티브 스트림을 직접 찾아 캐스팅하므로 화면 미러링 대신 원본 스트림 품질을 유지할 수 있다. Castor는 네트워크 트래픽을 관찰해 실제 미디어 요청을 포착하고 그 스트림을 재사용하기 때문에 대역폭과 해상도 손실을 줄인다. 이 접근은 웹 플레이어를 단순히 캡처하는 방식과 달리 재생 가능한 스트림을 직접 전송한다.
• 로컬 기반 워크플로우를 강조해 ffmpeg와 whisper.cpp 같은 로컬 바이너리로 트랜스코딩과 자막 생성을 수행한다. 네트워크 의존성을 낮추며 프라이버시와 오프라인 사용 가능성을 높인다. 소스 템플릿과 프록시를 사용자가 직접 구성하도록 해 Castor 자체가 소스 카탈로그를 포함하지 않는다.
• Docker 이미지가 Chrome, ffmpeg, ffprobe를 번들로 제공하되 네트워크와 GPU 노출 제약을 명시하여 사용 환경 차이에 따른 실패 모드를 문서화했다. 특히 Docker Desktop(macOS/Windows)에서의 SSDP 멀티캐스트 한계와 Linux의 --network host 필요성을 명확히 제시해 사용자 혼선을 줄인다. 하드웨어 가속 접근을 위해 --device /dev/dri 같은 추가 플래그를 요구하는 점을 문서에 반영했다.

사용 사례

• 웹 페이지에서 재생되는 동영상의 원본 스트림을 추출해 집안의 스마트 TV로 실시간 전송할 때 유용하다. 이 경우 Castor는 headless Chrome으로 스트림 URL을 찾아 ffmpeg로 필요한 재인코딩을 수행해 DLNA/UPnP MediaRenderer로 전달한다. 결과적으로 화면 미러링보다 낮은 지연과 높은 화질을 얻을 수 있다.
• 로컬에서 자동 자막을 생성해 비디오에 번(burn)하고자 할 때 적용할 수 있다. Castor는 whisper.cpp 기반 트랜스크립션을 사용해 오디오를 텍스트로 변환한 후 ffmpeg로 자막을 비디오에 병합한다. 이로 인해 클라우드 서비스 없이도 자막이 필요한 환경에서 작업이 가능하다.
• 네트워크에 연결된 미디어 플레이어나 DLNA 호환 장치, 또는 실험적 Chromecast 환경에서 단일 터미널 인터페이스로 디바이스를 검색하고 캐스팅 작업을 자동화하는 자동화 스크립트나 홈서버 환경에 통합할 수 있다. Docker 이미지로 의존성 패키징과 config 마운트를 통해 서버 환경에 배포하기 쉽다.

시작하기

기본 흐름은 디바이스를 `castor scan`으로 검색해 config.yaml의 device 항목에 정확한 이름을 넣고 `castor cast player <URL>`로 실행하는 것이다. macOS에서는 Homebrew Cask로 설치하거나 소스에서 make로 빌드해야 하며, whisper.cpp 바인딩 때문에 소스 빌드는 libwhisper.a를 먼저 생성한다. Docker를 사용할 경우 Linux 호스트에서 `--network host`를 사용해 장치 검색이 가능하며 설정 파일과 캐시 볼륨을 마운트해 컨테이너를 실행하면 된다.

요구사항

• 네이티브 실행을 위해 Chrome/Chromium이 필요하며 Castor는 headless Chrome을 통해 페이지 네트워크를 관찰한다. 또한 ffmpeg와 ffprobe가 PATH에 있어야 하며 이들 바이너리가 포맷 검사와 트랜스코딩 파이프라인을 담당한다. whisper 기능을 사용하려면 whisper.cpp 바인딩 빌드와 관련한 C 연동 도구(cmake 등)가 필요하다.
• Docker 이미지는 Linux 전용으로 제공되며 컨테이너가 LAN의 SSDP 멀티캐스트와 직접 통신할 수 있어야 하므로 `--network host`가 필수이다. Docker Desktop(macOS/Windows)에서는 이 플래그가 유효하지 않아 장치 검색이 실패하므로 네이티브 바이너리 사용이 권장된다. 하드웨어 인코더를 활용하려면 호스트의 GPU 디바이스를 컨테이너에 노출하는 추가 플래그(`--device /dev/dri`)가 필요하다.

이미지 분석