비디오 스트리밍의 기본 접근법
요즈음에 들어서는 동영상 기반의 스트리밍 플랫폼이 매우 많다.
유투브 같은 단순 동영상 제공 채널이나, 트위치 같은 스트리밍 플랫폼, 넷플릭스 같은 미디어 플랫폼 등등...
이러한 동영상 시스템들이 어떤 원리로 만들어지는지 대략적인 원리만 짚어본다.
1. Naive한 방법: 파일 다운로드
기본적으로 동영상도 파일이다. 그래서 사실 근본적인 원리는 서버가 비디오 파일을 클라이언트에게 전송해주고, 클라이언트는 그걸 다운받아서 재생하면 그만이다.
비디오 자체도 작고, 성능이 중요하지도 않고, 많이 쓸 것도 아니라면 이 정도로 충분할 수도 있다.
2. 범위 요청 (Range Request)
근데 비디오를 재생할때마다 비디오 전체 파일을 내려받고 실행하는 것은 너무나도 비효율적이다.
처음 시작할때 로드하는 시간도 길뿐더러, 중지/재시작을 효율적으로 제어하는 것도 불가능하다.
그래서 보통 비디오를 스트리밍할때는 범위 요청(Range Request)라는 기술을 활용한다.
클라이언트가 그때그때 필요한 동영상 범위를 요청하면, 서버는 그 범위에 해당하는 데이터만 쏴주는 것이다.
대표적으로 브라우저의 기본 비디오 엔진이나 video 태그 기능은 범위 요청 기반으로 작동한다.
그냥 비디오를 바로 조회할 때도 그럴듯한 플레이어 UI가 뜨고
비디오 태그 박아서 실행시켜도 비슷하다.
둘다 Range Request 기반으로 작동한다.
그리고 일반적인 서버 프레임워크들의 파일 serving 미들웨어들은 이에 대한 기능도 알아서 지원한다.
Range Request의 세부사항까지는 여기서 다루지 않겠다.
웹 클라이언트가 아니더라도 비슷한 접근법을 사용하면 된다.
3. CDN 서버
비디오와 같은 미디어 파일을 전송할때는 보통 물리적으로도 가까운 CDN 서버를 사용해서 전송을 처리한다.
Range Request 같은건 당연히 쓸 것이고, 거의 모든 서비스는 이런 방법을 취한다.
4. 레거시 프로토콜
이제는 잘 사용되지 않지만, 예전에는 RTSP, RTMP 같은 실시간 프로토콜을 사용해서 스트리밍을 구현하곤 했다.
성능이 그렇게 나쁜건 아닌데, 현재는 프로토콜 호환성도 영 좋지 않고, 브라우저에서 연결할 수도 없다는게 큰 단점으로 꼽혀서 버려졌다.
쌩 UDP 기반으로 쌓인 스택들이라 그렇다.
5. Chunk
근데 위에서 기술했듯 범위 기반의 전송을 처리하더라도, 대역폭을 최대로 발휘할 수 없다는 한계가 존재한다.
클라이언트가 최대로 받을 수 있는 전송량이 아직 남아있더라도, 단위를 하나씩 전송하면 아무래도 속도를 최대로 뽑을 수는 없는 것이다.
사용자의 네트워크 성능이 충분하다면 더 미리 보내줘도 되는데 말이다.
그래서 정말 빠른 로딩과 스트리밍이 필요하다면 각 단위를 적절히 쪼개서 동시에 보낼 수 있도록 한다.
보통 이런걸 Chunk라고 한다.
예전에는 비디오를 그대로 저장해서 쓰는게 아니라 파일을 청크 단위로 실제로 분리해서 쓰기도 했었다.
하지만 아래에서 설명할 HLS 같은 프로토콜이 나오면서 그렇게 하지는 않게 된다.
청크를 쪼갤때는 보통 ffmpeg 같은걸 쓴다.
6. Adaptive bitrate streaming
Adaptive bitrate streaming은 사용자 경험을 극대화하기 위한 비디오 스트리밍 방법론이다.
HTTP 기반으로 만들어지며, 대표적인 구현체로는 HTTP Live Streaming(HLS), Dynamic Adaptive Streaming over HTTP(DASH) 같은 것들이 있다.
의외로 유투브나 넷플릭스 같은 초대형 플랫폼들도 표준을 잘 지켜서 HLS 같은걸 쓰고 있는걸로 알고 있다.
이 방법론의 핵심 원리는 사용자가 받을 수 있는 만큼만 일단 보내줘서 버퍼링을 최소화하는 것이다.
1. 세그먼트
우선 비디오를 세그먼트 단위로 분리한다. 보통 2-10초 단위로 쪼개는게 일반적이다. (실제로 저장하는건 아니다.)
비디오를 통째로 전송하는게 아니라 세그먼트의 시퀀스를 보내는 형태로 스트리밍이 이루어진다.
**2. **bitrate
비디오를 막 시작했거나, 사용자 네트워크가 딸려서 전송률이 낮으면, 최소한만 비디오 데이터를 전송한다. 그러다가 사용자가 충분히 수용할 수 있다고 판단하면 더 많은 데이터를 전송하기 시작한다.
이 때문에 적응 비트레이트(Adaptive bitrate)라고 부르는 것이다.
7. 그리드 시스템 (P2P)
아프리카나 치지직 같은 국내 스트리밍 서비스에서 쓰이는 걸로 유명하다.
이건 사실 자연스런 기술의 발전이라기보단, 망사용료라는 훌륭한 제도에 힘입은 발버둥에 가깝다.
원래 CDN 서버가 직접 동영상 패킷을 날리던것을
클라이언트 컴퓨터에 저장해놓고, 클라이언트가 다른 클라이언트에게로 전송하게끔 하는 것이다.
이러면 CDN 서버가 직접 전송하는 사용량이 줄어들기 때문에, 한국 한정으로 망사용료가 극단적으로 줄어들게 된다.
치지직만 해도 그리드 도입해서 망사용료를 7배쯤 줄인 것 같더라.
참조
https://developer.mozilla.org/ko/docs/Web/HTTP/Range_requests
https://www.cloudflare.com/learning/video/what-is-adaptive-bitrate-streaming/
https://getstream.io/blog/streaming-protocols/
https://web.dev/articles/media-streaming-basics