프로젝트에서 WebRTC 적용하게 되어 스트리밍 기술에 대해 궁금증을 가지게 되었다. 비교적 최신 기술인 WebRTC 이외에 많이 사용되었던 기술들은 무엇인지 궁금하기도 하고, 해당 기술들에 대해 알아야 WebRTC만의 장점을 최대한 살려서 개발 가능하다고 생각해서 공부를 해보았다.
아직 자세히 파헤쳐보지는 않았지만 이전에 공부했던 내용들을 블로그로 정리해보고자 한다.
이 게시글에 정리한 내용이나 기타 스트리밍 기술들은 앞으로 추가적으로 더 공부해 업로드할 예정이다.
스트리밍 기술
스트리밍은 인터넷을 통해 영상(비디오 및 오디오 미디어)을 전송하는 기술이다. 이때 미디어 파일을 한 번에 통째로 보내는 대신, 한 번에 조금씩 지속적으로 사용자 장치에 보낸다. 따라서 사용자 장치가 모든 파일을 받지 않은 상태에서도 미디어를 재생할 수 있다.
라이브 스트리밍의 경우 원격 카메라 및 마이크를 사용하여 실시간으로 제작되는 미디어 파일을 스트리밍 하는 것을 말한다.
HLS (HTTP Live Streaming)
HLS는 2009년 애플에서 개발한 표준 스트리밍 프로토콜이며, 현재 가장 일반적으로 많이 사용하고 있다.
HTTP 프로토콜을 이용해 매우 안정적으로 영상을 전송한다. 또한 HTTP 프로토콜을 사용하기 때문에 다양한 플랫폼에서 사용 가능하다는 장점이 있다. (전용 서버가 필요한 타 프로토콜에 비해 간단하게 실행 가능)
재생에 지장을 주지 않고 네트워크 상태에 따라 비디오 품질을 높이거나 낮출 수 있다. 이 때문에 사용자가 비디오를 보는 중에 품질이 나빠지거나 좋아질 수 있다. 이러한 기능을 ‘Adaptive bitrate streaming (적응 비트 전송률 스트리밍)’이라고 하며, 이 기능이 제공되지 않으면 네트워크 상태가 나빠질 경우 비디오 재생이 완전히 멈출 수 있다.
WebRTC 등과 비교했을 때, 지연 시간이 상대적으로 길어 실시간 스트리밍에는 적합하지 않을 수 있다. (TCP 사용)
- 일반적인 HTTP 통신? HLS의 경우 HTTP 프로토콜을 이용하긴 하지만, 표준의 요청/응답 패턴이 적용되지는 않는다. 클라이언트와 서버 사이의 연결이 스트리밍 기간 동안 지속적으로 열려 있고, 서버는 비디오 데이터를 클라이언트에게 계속 보내기 때문에 클라이언트는 비디오 데이터 세그먼트마다 request를 보내지 않아도 된다.
- 작동 방법
데이터 흐름은 ‘원본 → 인코더 → 스트림 세그먼터 → 웹 서버 → 플레이어’ 단계로 구성된다.
- 서버에서 인코딩을 진행한다. 비디오 데이터의 포맷을 재설정하여 모든 장치가 데이터를 인식, 해석할 수 있게 한다. (HLS는 H.264나 H.265 인코딩을 사용해야 함)
- 서버에서 조각화를 진행한다. 비디오를 작은 단위의 세그먼트로 나눈다. 세그먼트의 기본 길이는 6초이다. (2016년까지는 10초였고, 길이는 다양하다.)
비디오를 세그먼트로 나눌 때, 비디오 세그먼트의 인덱스 파일을 만들어 세그먼트의 순서를 기록한다. 또한, 다양한 품질로 여러 세트의 세그먼트를 복제한다. - 인코딩된 비디오 세그먼트는 클라이언트 장치가 스트리밍을 요청하면 인터넷을 통해 전송된다. (CDN을 사용하여 전송 속도를 높일 수 있다.)
- 클라이언트 장치는 인덱스 파일을 참조하여 세그먼트들을 순서대로 조합하여 비디오를 연결하고, 필요에 따라 품질을 높이거나 낮춘다.
- 구성 파일 형식
.m3u8, .ts 형식의 파일로 구성된다.
.m3u8 파일은 영상 재생을 위한 메타 정보들이 담겨 있다. 예를 들어, 대역폭 별 m3u8 파일 경로나 ts 파일 경로 등이 담겨있다. .ts 파일은 실제 스트리밍 영상 데이터로, 세그먼트이다.
WebRTC (Web Real-Time Communications)
WebRTC는 구글에서 2011년 개발한 기술로, 웹 브라우저에서 실시간 미디어 데이터를 전송할 수 있다. P2P 방식을 채택하고 있어 중간 서버 없이도 통신이 가능하다. 또한, 다양한 플랫폼에서 사용이 가능하며, 높은 보안성을 가지고 있다. (자세한 내용은 다음 링크를 참고)
UDP 기반의 RTP 프로토콜을 사용하고 있다. 따라서 WebRTC 기술 내에 품질 보정 기술이 내장되어 있다고는 하지만, 안정적인 품질을 보장할 수 없다는 것이 현실이다. 개발자의 네트워크 기술에 대한 이해와 개발 능력이 중요하다.
ORTC (Object Real-Time Communications)
ORTC는 2014년 마이크로소프트에서 WebRTC에 대응하여 개발한 기술이다. 실질적으로 WebRTC와 유사한 기술로, 현재 사실 WebRTC와 ORTC를 완전히 분리하여 바라보기는 애매하다. WebRTC 1.0 이 ORTC를 일부 지원하고 있고, 서로 일부 호환이 가능해졌다. 두 기술이 목표하는 방향이 비슷하고, SDP 사용 유무 등의 약간의 차이를 제외하면 흐름도 비슷하기 때문에 앞으로 두 기술이 나아가는 방향성에 따라 통합될 여지도 있어 보인다. (현재 MS와 구글이 공동 표준화 중)
아직까지 지원되는 브라우저가 제한적이며, 개발이 덜 되어있는 단점이 있다. (WebRTC보다 개발이 덜 되어 있음)
HLS vs WebRTC
| HLS | WebRTC | |
|---|---|---|
| 기반 프로토콜 | HTTP | RTP |
| Delivery Method | TCP | UDP |
| Latency | high | low |
| 통신 방법(model) | client-server | peer-to-peer |
| 비디오 품질 | high | low |
| 안정성 | high | low |
| 동작 과정 | segment 생성,조합 | SDP로 시그널링 |
결론
실시간(라이브) 스트리밍을 위해서는 ORTC나 WebRTC가 적합하고, 안정적인 스트리밍을 위해서는 HLS가 적합하다.
