혹시 궁금한 사람들을 위해 말하자면, 이 웹사이트의 문법 하이라이팅 색상 테마는 “gruvbox”임
개인적으로 아주 마음에 드는데, 이걸 찾아내는 데 꽤 오래 걸렸음 gruvbox GitHub 링크
혹시 이 웹사이트가 어떤 기술로 만들어졌는지 아는 사람 있음? 디자인과 UI가 정말 마음에 듦
참고로 이 테마는 VSCode에서도 사용할 수 있음
나는 video.js를 써본 적이 없는데, 사이트나 광고가 이미 익숙한 사람들을 대상으로 한 것처럼 느껴졌음
읽으면서도 한 가지 궁금했던 건, 이게 HTML video 태그와 뭐가 다른지였음. 단순히 컨트롤러만 다른 건가?
좋은 지적임. 사이트에서 그 부분을 더 명확히 설명할 필요가 있음
video 태그는 요즘 꽤 좋아졌지만, Video.js는 브라우저 간 일관된 스타일링, 고급 기능(분석, DRM, 360도 영상 등), 다양한 스트리밍 포맷 지원(HLS, DASH 등) 같은 점에서 차별화됨
결국 video 태그로도 구현은 가능하지만, 그렇게 하다 보면 결국 Video.js 같은 걸 직접 만들게 됨
모든 환경에서 video 태그가 제대로 동작하지 않음. 브라우저마다 엣지 케이스가 많음
안정적인 플레이어나 스트리밍 기능이 필요하면 Video.js를 쓰는 게 좋음
참고로 나는 조지아 국가용 TV 방송 플레이어를 만들었는데, 2009년 LG 스마트TV부터 최신 브라우저까지 지원했음
대부분의 브라우저가 HLS나 DASH를 지원하지 않음
이게 중요한 이유는 동적 비트레이트 조정 때문임. 캐싱도 더 효율적임
WebVTT 관련해서 요즘 상황이 달라졌는지 궁금함
예전에 자막 렌더링을 커스터마이징하려 했는데 너무 어려웠음
왜 이걸 Web Component로 배포하지 않았는지 궁금함
내 생각엔 완벽한 사용 사례 같음 — 의미 있는 객체에 내장된 컨트롤이 있으니까
좋은 질문임. 예전에 media-chrome과 Mux Player를 Web Component로 만들려다 React 통합 문제로 고생했음
결국 React용 shim을 만들어서 해결했지만, 그게 또 다른 문제를 낳았음
VJS 10에서는 headless 코어 + 렌더링 레이어 구조로 타협점을 찾았음
덕분에 React 컴포넌트와 Web Component를 모두 지원함 media-chrome GitHub 링크
Web Component는 멋져 보이지만, 실제로는 스타일링과 SSR 문제로 시간을 많이 잡아먹음
Shadow DOM 버그나 프레임워크 간 호환성 때문에 결국 플레이어보다 환경 설정에 더 많은 시간을 쓰게 됨
대부분의 사용자는 이런 걸 신경 쓰지 않음. 그냥 JS 라이브러리 + 깔끔한 API가 훨씬 낫다고 생각함
사실 React 코드가 HTML Custom Elements로 컴파일되기 때문에, 넓은 의미로 보면 이미 Web Component임
다만 React를 쓰는 이유는 트리 셰이킹(tree-shaking) 덕분에 필요한 코드만 포함할 수 있기 때문임
일반 HTML에서는 아직 이런 최적화가 어렵기 때문에, 빌드 파이프라인이 일종의 Web Component 생성기 역할을 하는 셈임
Plyr를 쓰던 내 오디오 플레이어를 Video.js로 바꿔보려 했는데, 기본 설정에서 몇 가지 기능 격차가 있었음
1배속 이하 재생 속도 없음, 모바일에서 볼륨 조절 불가, 탐색 버튼 없음, 색상 커스터마이징 어려움, 데모 부족 등
좋은 피드백임. 이 내용들을 이슈로 등록할 예정임
현재 Plyr 등과의 기능 동등성(feature parity) 을 목표로 하고 있으며, GA 시점(연내 중반)을 목표로 함
나는 영상 호스팅은 잘 모르지만 HTML5 비디오 플레이어를 써본 적 있음
서버 측에서 비디오 청크를 직접 제공하는 엔드포인트를 만들어야 하는지 궁금함
ffmpeg로 2MB 단위로 나눈다면, 그걸 어디에 두는 게 좋을까? CDN? 자체 서버?
Video.js가 가장 부드럽게 작동하려면 어떤 구성이 최선일까?
그냥 HLS로 변환하면 됨. 1~2초 단위로 자동 청크화되고, nginx에서 정적 파일로 서빙 가능함
Video.js와 잘 맞고, LG TV에서도 태그 기반 재생이 가능함
런타임에서 버전 전환(ABR)이 필요 없다면 수동 청크화도 필요 없음
서버가 Range 요청만 지원하면 브라우저가 알아서 처리함
나는 DO Spaces 같은 오브젝트 스토리지 + CDN 조합을 쓰는데 잘 작동함
다만 청크는 IDR 키프레임으로 시작해야 해서 단순하지 않음
인코딩과 세그먼트 분할을 한 번에 처리해야 함 (예: ffmpeg의 dash 포맷터)
오디오와 비디오 세그먼트 길이를 맞추려면 GOP 계산기가 유용함
일반적으로는 고품질 원본에서 여러 해상도로 인코딩 후, HLS/DASH 매니페스트와 함께 S3 같은 곳에 올림
플레이어는 매니페스트 URL 하나로 필요한 모든 리소스를 찾아감
MPE-DASH도 고려해볼 만함
블로그 포스트가 정말 잘 쓰였음
독자를 전문가로 존중하는 설명 방식이 인상적이었음. 이런 식의 제품 발표가 더 많아졌으면 함
Steve 축하함!
예전에 JW Player에서 일할 때 Video.js의 단순함과 테마 시스템에 감명받았음
이번 버전도 큰 성공을 거두길 바람
오랜만이네 Zach! 반가움
FOMS나 여러 컨퍼런스에서 JW 팀과 이야기 나눴던 게 즐거웠음
영상 기술 쪽은 여전히 뜨거운 분야니까 언제든 다시 돌아오길 바람
88%라는 수치는 놀라움
가장 큰 개선 포인트가 뭐였는지 궁금함 — 아마 플러그인 시스템일 것 같음
리라이트 과정에서 주요 통합 기능이 깨지진 않았는지도 알고 싶음
리라이트 과정에서의 아키텍처 변화와, 이전 Video.js 디자인 대비 트레이드오프가 무엇이었는지 궁금함
Hacker News 의견들
혹시 궁금한 사람들을 위해 말하자면, 이 웹사이트의 문법 하이라이팅 색상 테마는 “gruvbox”임
개인적으로 아주 마음에 드는데, 이걸 찾아내는 데 꽤 오래 걸렸음
gruvbox GitHub 링크
나는 video.js를 써본 적이 없는데, 사이트나 광고가 이미 익숙한 사람들을 대상으로 한 것처럼 느껴졌음
읽으면서도 한 가지 궁금했던 건, 이게 HTML video 태그와 뭐가 다른지였음. 단순히 컨트롤러만 다른 건가?
video 태그는 요즘 꽤 좋아졌지만, Video.js는 브라우저 간 일관된 스타일링, 고급 기능(분석, DRM, 360도 영상 등), 다양한 스트리밍 포맷 지원(HLS, DASH 등) 같은 점에서 차별화됨
결국 video 태그로도 구현은 가능하지만, 그렇게 하다 보면 결국 Video.js 같은 걸 직접 만들게 됨
안정적인 플레이어나 스트리밍 기능이 필요하면 Video.js를 쓰는 게 좋음
참고로 나는 조지아 국가용 TV 방송 플레이어를 만들었는데, 2009년 LG 스마트TV부터 최신 브라우저까지 지원했음
이게 중요한 이유는 동적 비트레이트 조정 때문임. 캐싱도 더 효율적임
WebVTT 관련해서 요즘 상황이 달라졌는지 궁금함
예전에 자막 렌더링을 커스터마이징하려 했는데 너무 어려웠음
왜 이걸 Web Component로 배포하지 않았는지 궁금함
내 생각엔 완벽한 사용 사례 같음 — 의미 있는 객체에 내장된 컨트롤이 있으니까
결국 React용 shim을 만들어서 해결했지만, 그게 또 다른 문제를 낳았음
VJS 10에서는 headless 코어 + 렌더링 레이어 구조로 타협점을 찾았음
덕분에 React 컴포넌트와 Web Component를 모두 지원함
media-chrome GitHub 링크
Shadow DOM 버그나 프레임워크 간 호환성 때문에 결국 플레이어보다 환경 설정에 더 많은 시간을 쓰게 됨
대부분의 사용자는 이런 걸 신경 쓰지 않음. 그냥 JS 라이브러리 + 깔끔한 API가 훨씬 낫다고 생각함
다만 React를 쓰는 이유는 트리 셰이킹(tree-shaking) 덕분에 필요한 코드만 포함할 수 있기 때문임
일반 HTML에서는 아직 이런 최적화가 어렵기 때문에, 빌드 파이프라인이 일종의 Web Component 생성기 역할을 하는 셈임
Plyr를 쓰던 내 오디오 플레이어를 Video.js로 바꿔보려 했는데, 기본 설정에서 몇 가지 기능 격차가 있었음
1배속 이하 재생 속도 없음, 모바일에서 볼륨 조절 불가, 탐색 버튼 없음, 색상 커스터마이징 어려움, 데모 부족 등
현재 Plyr 등과의 기능 동등성(feature parity) 을 목표로 하고 있으며, GA 시점(연내 중반)을 목표로 함
나는 영상 호스팅은 잘 모르지만 HTML5 비디오 플레이어를 써본 적 있음
서버 측에서 비디오 청크를 직접 제공하는 엔드포인트를 만들어야 하는지 궁금함
ffmpeg로 2MB 단위로 나눈다면, 그걸 어디에 두는 게 좋을까? CDN? 자체 서버?
Video.js가 가장 부드럽게 작동하려면 어떤 구성이 최선일까?
Video.js와 잘 맞고, LG TV에서도 태그 기반 재생이 가능함
서버가 Range 요청만 지원하면 브라우저가 알아서 처리함
나는 DO Spaces 같은 오브젝트 스토리지 + CDN 조합을 쓰는데 잘 작동함
인코딩과 세그먼트 분할을 한 번에 처리해야 함 (예: ffmpeg의 dash 포맷터)
오디오와 비디오 세그먼트 길이를 맞추려면 GOP 계산기가 유용함
일반적으로는 고품질 원본에서 여러 해상도로 인코딩 후, HLS/DASH 매니페스트와 함께 S3 같은 곳에 올림
플레이어는 매니페스트 URL 하나로 필요한 모든 리소스를 찾아감
블로그 포스트가 정말 잘 쓰였음
독자를 전문가로 존중하는 설명 방식이 인상적이었음. 이런 식의 제품 발표가 더 많아졌으면 함
Steve 축하함!
예전에 JW Player에서 일할 때 Video.js의 단순함과 테마 시스템에 감명받았음
이번 버전도 큰 성공을 거두길 바람
FOMS나 여러 컨퍼런스에서 JW 팀과 이야기 나눴던 게 즐거웠음
영상 기술 쪽은 여전히 뜨거운 분야니까 언제든 다시 돌아오길 바람
88%라는 수치는 놀라움
가장 큰 개선 포인트가 뭐였는지 궁금함 — 아마 플러그인 시스템일 것 같음
리라이트 과정에서 주요 통합 기능이 깨지진 않았는지도 알고 싶음
리라이트 과정에서의 아키텍처 변화와, 이전 Video.js 디자인 대비 트레이드오프가 무엇이었는지 궁금함