Live Streaming Service(생방송)를 설계 및 구현하고자 할 때 고려해야하는 점

필자는 인디밴드 들을 위한 온라인 공연 서비스인 인디크라우드 서비스를 만들었다. 이 서비스를 만들면서 팀원들과 여러가지 미디어 서버들을 고려해본 결과 당시에 가지고 있던 자금 등의 상황을 견주어 봤을 때 제일 적절한 솔루션이 Wowza Media Server라는 결론을 얻었었다. 우리는 실제로 서버를 구입하여 직접 테스트를 해보고 실제 공연을 해본 결과 문제 없이 잘 동작하는 것을 확인할 수 있었다. 하지만 문제는 실시간 공연이라는 점이였다. 지금부터 실시간 스트리밍 서비스를 만들기 위해서 어떤 고려사항이 있는지 알아보도록 한다.

실시간 방송(생방송)을 송출하고 PC, 스마트폰 할 것 없이 모든 디바이스에서 볼 수 있게 하기 위해서는 크게 두 가지 기술이 모든 디바이스에서 지원을 해야한다.

코덱¹

코덱(Codec, Coder-Decoder)은 영상이나 음성을 일정한 형식에 맞게 변환하는 기술을 말한다. 동영상 서버, 방송 송출 장비, 방송 수신 장비 들이 모두 코덱을 지원할 수 있어야만 한다. 예를 들어서 영상 코덱에 H.263이라는 것이 있는데 방송 송출 장비와 방송 수신 장비는 지원하지만 수신장비(Ex:스마트폰)에서 지원을 하지 않으면 영상을 볼 수가 없게 된다. 또는 방송 송출 장비에서 H.263을 지원안하는데 다른 두 부분에서 지원을 한다면 이 또한 변환이 불가능하기 때문에 방송 송출이 불가능해 진다. 이렇게 코덱은 세 가지 부분에서 다 지원이 되는 것을 해야한다. 만약 안된다면 직접 구현하여 탑제해야 하는데 라이브러리가 없다면 최악의 경우 코덱을 구현해야할 수도 있다. 회사의 경우 코드 공개가 힘든 경우가 많은데 오픈 소스를 쓰기 어려워지기 때문에 비용이 증가한다. 그리고 경우에 따라서 사용자가 스마트폰 앱을 설치하거나 PC용 프로그램을 설치해야하는 부가 비용이 발생 할 수 있다. 그리고 코덱을 선택할 때 주의할 점은 코덱 자체(Ex: 특허비, 라이센스 비용)등이 발생할 수 있다
실시간 스트리밍 프로토콜²

실시간 스트리밍 프로토콜은 영상이나 음성을 인터넷을 통해 전송하기 위한 규약을 말한다. 스트리밍 프로토콜도 코덱과 마찬가지로 각각 시스템에서 지원이 되어야 한다. 예를들면 RTMP프로토콜의 경우 서버에서 지원을 하더라도 사용자가 보게 될 디바이스(스마트폰)에서 지원을 하지 않는다면 볼 수가 없다. 이도 코덱과 마찬가지 문제가 있다. 프로토콜을 사용하기 위한 라이센스 비용은 보통 없다. 하지만 지원하지 않는 장치에 대해서는 프로토콜을 따로 구현하고 앱을 설치 해야한다는 문제가 있다.

코덱과 프로토콜 — 방송 송출 디바이스부터 방송 수신 디바이스까지 영상/소리 데이터 흐름

위의 그림은 방송 송출 디바이스, 서버, 방송 수신 디바이스에서 고려해야할 것들을 항목별로 나누어 본 것이다.

동영상을 송출하는 측에서는 인코더(코덱)과 스트리밍 프로토콜이 필요하다. 실시간으로 획득한 영상과 소리 데이터는 인코더를 통하여 압축된다. 그리고 이 압축된 내용은 서버와 미리 약속한 프로토콜을 통하여 전송하게 된다.

서버의 디코더/인코더는 필요할 수도 있고 필요 없을 수도 있다. 만약 동영상을 수신하는 측에서 송출할 때 사용된 코덱이 지원하지 않는다면 지원하는 코덱으로 다시 인코딩을 하여야 한다. 이러한 역할을 하는 것을 트랜스코더(Transcoder)라고 부른다. 만약 필요가 없을 경우 바로 동영상을 수신하는 측으로 영상/소리 데이터를 클라이언트와 미리 약속된 프로토콜로 전달하게 된다.

클라이언트는 지원하는 프로토콜을 이용하여 압축된 영상/소리 데이터를 수신한다. 그리고 받은 데이터를 디코딩(압축을 품)하여 영상을 출력하고 소리를 재생하게 된다.

위의 그림을 통해서 우리가 선택한 Wowza Media Server에 어떤 장단점이 있는지 알아볼 것이다.

다음 포스팅에는 장치, OS, 라이브러리 별로 가능한 스트리밍 프로토콜과 코덱에 대해서 이야기를 해보고 Wowza Media Server에서 라이브 스트리밍을 할 때 어떤 문제와 어려움이 있는지에 대해서 설명해 보도록 하겠다.