최상의 비디오 전송을 위한 지연시간(Latency) 줄이기
실시간 비디오 전송은 점점 더 대중화되고 경쟁이 치열해지고 있습니다. 특히 OTT 서비스에서 경쟁력 강화를 위해 라이브 스트리밍 서비스를 추가하는 미디어 회사들이 최근 많아지고 있습니다.
미디어 배포자가 OTT플랫폼을 차별화할 수 있는 한 가지 방법은 바로 짧은 지연시간으로 고품질 비디오를 시청자들에게 제공하는 것입니다. 이 블로그에서는 라이브 OTT전송의 지연시간을 줄이는 데 사용할 수 있는 다양한 저 지연 스트리밍 옵션에 대하여 알아 보고자 합니다.
실시간 비디오를 처리하고 네트워크를 통해 시청자의 디바이스로 스트리밍하는 데는 시간이 소요됩니다. 카메라의 비디오가 인코딩되어 온라인 플레이어 또는 OTT장치로 전달되는 데 걸리는 시간을 라이브 스트리밍 지연시간(Latency)라고 합니다.
지연시간이 중요한 이유는 무엇일까요?
OTT 지연시간 요구 사항은 큰텐츠에 따라 다릅니다. 예를 들어 올릴픽, 월드컵, 또는 수퍼볼과 같은 라이브 이벤트의 경우 지연시간이 매우 짧으면 시청자에게 거의 실시간으로 서비스를 제공함으로 보다 이벤트의 가치를 더 할 수 있지만 영화나 TV 프로그램과 같은 VOD같은 콘텐츠는 짧은 지연 시간이 필요하지 않을 수 있습니다.
또한 소셜미디어에서 점수(Score)가 적용되고 모니터링할 수 있는 온라인 라이브 스포츠 이벤트를 할 경우 어떨까요? 이와 같은 이벤트를 해 본적이 있나요?
플랫폼 간 지연 시간의 차이로 인해 스포일러가 발생할 수 있으며 라이브 비디오를 보기 전에 소셜 미디어에서 점수들이 업데이트를 볼 수 있습니다. 만일 지연 시간이 짧으면 스포일러 발생을 줄일 수 있으며 시청자는 기기나 위치에 관계없이 동일한 시청 경험을 할 수 있으며 원하고 있습니다.
짧은 지연 및 실시간 스트리밍을 위한 사용 사례
● 짧은 지연 시간: 라이브 스포츠 이벤트, 웨비나, 정부 발표 , 회의 등
● 상호 작용이 있는 짧은 지연 시간: 투표, 경매, 내기, 게임 등
이와 같이 라이브 데이터와 소셜 미디어의 통합에는 짧은 지연시간이 필요합니다.
TCP/IP를 사용하는 라이브 스트리밍
인터넷은 원래 비디오를 제공하도록 설계되지 않았습니다. HTTP 라이브 스트리밍 프로토콜은 스트리밍을 일련의 작은 http기반 비디오 청크로 만들어 인터넷을 통해 비디오 파일을 전달하는 방법으로 등장했습니다.
이와 같은 http트랜잭션을 사용함으로써 HTTP 라이브 스트리밍은 방화벽을 통과하고 표준 웹 서비를 사용하여 비디오 스트리밍을 제공하고 콘텐츠 전송 네트워크(CDN)을 활용하여 전송을 확장할 수 있습니다.
아래 그램은 TCP/IP를 사용한 라이브 스트리밍 프로세스의 단순화된 그림입니다.
청크 사이즈 튜닝하기
청크 사이즈 튜닝이란 무엇일까요? 청크 사이즈 튜닝은 인코딩된 비디오의 청크(세그먼트)길이를 줄이거나 늘리는 것입니다.
인코더가 비디오 청크(또는 세크먼트)를 만들 때 일반적으로 10초 단위로 생성합니다. 플레이어는 재생을 시작하기 전에 3개의 비디오 청크를 버퍼링해만 합니다. 각각 10초인 3개의 청크가 있을 경우 재생이 시작되기 전에 플레이어가 버퍼링해야하는 필요시간은 바로 30초입니다.
자, 이제 동일한 3개의 비디오 청크를 고려해 보겠습니다. 그러나 길이는 각각 6초로 줄였습니다. 이를 통해 30초 분량의 비디오를 버퍼링하는 대신 플레이어가 재생을 시작하기 전에 18초 분량의 비디오만 버퍼링하면 됩니다.
아래 그림은 이러한 개념을 설명해 줍니다.
청크 크기에 대한 보편적인 설정은 없습니다. 청크 크기를 과도하게 줄이면 스트리밍이 중단되고 비퍼가 비어 있는 경우 플레이어에서 리버퍼링이 발생할 수 있습니다.
따라서 각 워크 플로우는 위의 이유들로 인하여 항상 테스트를 해야만 합니다.
CMAF (Common Media Application Format)
CMAF는 일반적인 짧은 지연시간을 추구하기 위한 파일 형식입니다. HLS 및 MPEG-DASH는 오늘 날 사용되는 두 가지 주요 HTTP 스트리밍 형식입니다. HLS와 DASH는 전통적으로 비디오와 오디오를 컨테이너화하는 다른 방법을 사용했습니다. 공동 프레임 워크를 사용하여 파일을 저장함으로써 현재 우리가 사용 중에 있는 태블릿, 컴퓨터, 스마트폰 및 OTT 디바이스에 비디오를 전달하기 원하는 소유자들은 각각 정확히 동일한 비디오 및 오디오 데이터를 보유하고 있는 두 개의 개별 세트를 갖는 대신 한번에 파일을 패키지하고 저장할 수 있습니다
CMAF 인코딩
CMAF인코딩에 대해 자세히 살펴 보겠습니다.
아래 그림의 맨 위에는 CMAF이 아닌 청크 비디오 조각이 있습니다. 각 비디오 샘플의 타이밍과 지속시간이 포함된 Moov(Movie Fragment Box)로 시작합니다.
MDAT(Movie Data Box)에는 설명된 비디오 샘플이 포함되어 있습니다. 완전한 세그먼트가 생성된 후 비디오 샘플이 인코더에서 출력되고 네트워크를 통해 전송되면 디코더가 디코딩을 시작할 수 있습니다.
그림의 하단에는 더 작은 비디오 청크를 설명하기 위해 추가 ‘moofs’가 삽입된 CMAF 청크 인코딩 세그먼트가 있습니다. 이러한 작은 비디오 청크를 비디오 조각(Video Fragment)라고 합니다.
더 작은 비디오 조각을 인식하고 CMAF 청크 스트리밍 재생을 초기화하는 데 필요한 별도의 헤더가 있습니다. 비디오 조작은 전체 세그먼트가 인코딩되기 전에 전송할 수 있습니다. 이를 통해 디코더는 전체 비디오 세그먼트가 수신되기 전에 비디오 재생을 시작할 수 있습니다. 따라서 이와 같이 CMAF 청크 인코딩을 사용하면 더 작은 비디오 청크를 더 자주 전달하여 종단 간 지연시간을 줄일 수 있습니다.
CMAF 요구사항
CMAF로 지연시간을 줄이기 위해 충족해야 하는데 몇 가지 요구사항이 있습니다.
● 인코딩 – 미디어는 청크 인코딩되어야하며 인코더는 비디오 조각을 적절하게 설명하고 더 작은 비디오 조각을 적절하게 설명하고 더 작은 비디오 조작의 가용성을 알리기 위해 목록을 업데이트해야 합니다.
● 네트워크 – 네트워크는 HTTP 1.1 청크 전송 또는 지속적인 http 연결을 허용하는 유사한 방법을 지원해야만 합니다. 청크 전송 인코딩은 인코더에서 비디오 플레이어에 이르느 전체 배포 체인을 통해 사용해야만 합니다. 청크 전송 인코딩을 사용하면 전체 미디어 콘텐츠가 생성되기 전에 헤더를 쓰고 읽을 수 있습니다.
● 비디오 플레이어 – 비디오 플레이어는 업데이트된 목록을 읽고 반응할 수 있어야만 합니다. 플레이어는 수신된 비디오 조각을 디코딩할 수 있어야 합니다. 또한 플레이어는 버퍼를 동적으로 조정할 수 있어야 합니다.
