브라우저가 실시간 동영상을 재생하는 과정( != 실시간 )
산업현장에 설치된 IP 카메라로
산업현장의 영상과 위험을 모니터링 하는 프로젝트를 수행했었다.
프로젝트 수행시 '동영상 재생' 기능을 어떻게 구현했는지
복습과 정리를 위해 글을 작성했다.
환경
제품이 설치될 환경은 확정적으로
- 폐쇄 내부망
- 유/무선 IP 카메라
- 실시간 동영상
이었다.
다만 원격 소프트웨어 업데이트 도구와 같은
본 제품을 지원하는 유틸리티 프로그램들은
특정 포트를 외부에 열어두는 식으로 접근 통제를 하기로 했다.
디바이스 <-> 제품 <-> 원격 소프트웨어 업데이트 도구 <-> 인터넷
대략 구도는 이런식이다.
개발 환경
Window app 개발자를 구할 수 있었다면
Native app, 그러니까 특정 OS에서 제공하는 자원이나 API를 활용할 수 있었겠지만
웹 개발 스택의 개발자만 있었기에 Browser에서 작동하는 제품을 구현하기로 했다.
HTML RTSP 미지원
24년 8월 기준,
실시간 동영상을 송출하는 기능에 있어서 html은 rtsp를 지원하지 않는다.
- 보안에 취약하고
- 브라우저가 rtsp 패킷을 decode할 수 없다.
만약에 html이 rtsp를 지원했다면
본인의 pc와 지구 반대편의 인터넷과 연결된 디바이스가
직접 연결됐다고 봐도 무방할 것이다.
그렇다고 무한정 접속할 수는 없는 것이,
rtsp는 디바이스별로 접속 허용 개수가 정해져있기 때문이다.
실시간에 '가깝게' 동영상을 재생하는 방법
브라우저 - 지원 디바이스를 1 : 1로 연결할 수는 없기에 다른 방법이 필요하다.
- 트랜스코딩 프로그램
- 동영상 파일 서버
를 사용하여 1:1 rtsp 연결보다는 부족하지만
실시간에 가깝게 동영상을 브라우저로 보낼 수 있다.
브라우저 <-> 동영상 파일 서버 <-> 트랜스코딩 프로그램 <-> 디바이스
1. rtsp 패킷을 사용하여 일반적인 동영상 파일로 트랜스코딩한다.
2. 짧은 길이의 동영상 몇 개를 만든다.(이를 chunk라고 부르겠다)
3. 시간이 지나면 오래된 동영상부터 최신 동영상 chunk로 교체한다.
트랜스코딩 프로그램이 필요한데,
gstreamer, python binding을 사용했다.
여기서 주의해야 할 것은
브라우저 <-> 동영상 파일 서버 양단에서 사용할 프로토콜에 따라
트랜스코딩의 결과물이 달라진다.
예를 들어, hls.js를 사용할 경우에는
동영상 파일 서버에
- .ts 동영상 chunk파일들
- 플레이리스트 파일
쌍으로 존재해야하므로
트랜스코딩 프로그램도 이 둘을 추출해내야한다.
이는 gstreamer 파이프라인을 구성하는 작업이며
글의 범위를 넘어가므로 설명하지 않겠다.
추출 옵션으로
- 동영상의 길이
- 플레이리스트 길이(몇 개의 동영상을 유지할 건지)
등을 사용할 수 있다.
네트워크 환경과 실시간성
직관적으로도, 실제로도
- 네트워크 hop이 많을 수록 실시간성이 떨어지고
- 경로가 길 수록 실시간성이 떨어지며
- 대역폭이 작을 수록 퀄리티의 제약이 크다.
때문에
hls.js를 활용하면 거쳐야 할 과정이 rtsp보다 많다. (트랜스코딩)
실데이터를 보내기 전에 수립해야할 절차도 rtsp보다 많으며
rtsp 1 : 1 연결보다는 실시간성이 떨어진다.
하지만 대역폭이 일정하게 유지되는 등
네트워크 품질의 조건이 동일하다면 허용되는 딜레이로 전송할 수 있다.
댓글
댓글 쓰기