인터넷 멀티미디어 스트리밍 프로토콜
인터넷 멀티미디어 스트리밍 프로토콜은 유튜브와 같은 미디어에서 스트리밍 시 필요한 기술이 여러 가지가 있다.
신호
- SIP/SDP
시작과 관련된 프로토콜이다.
오디오/비디어 전송과 제어 메세지 전송
- HTTP(HLS,HTTP Live Stream ), RTP/RTMP (최근에는 HLS로 통일)
- RTCP/RTMP/RTSP
스트리밍 프로토콜
- RTMP, RTSP
재생, fastforward, rewind 등 DVD와 비슷하다.
실제 요청, 재생 등에 사용되는 프로토콜이다.
실시간 프로토콜
- WebRTC
줌과 같은 화상회의에서 주로 사용한다.
전통적인 프로토콜
- RTP/UDP (비디오 전송)
RTP는 UDP 위에서 실제로 데이터를 전송
- RTSP (재생, 멈춤 등)
스트리밍을 제어함
웹 기반 프로토콜
- RTMP (최근에는 웹으로 접근하며, 게임의 비디오/오디오에서 사용)
- HLS
RTSP (Real-time Streaming Protocol)
실시간 스트리밍 프로토콜(Real Time Streaming Protocol, RTSP)은 스트리밍 미디어 서버를 제어할 목적으로 엔터테인먼트, 통신 시스템에 사용하도록 설계된 네트워크 제어 프로토콜이다. 실제로 데이터를 전송하는 프로토콜이 아니며 데이터 전송 프로토콜은 RTP다.
위 사진에서 빨간색 화살표가 RTSP가 보내는 제어 메세지이다.
RTMP (Real-Time Messaging Protocol)
RTSP는 IETF에서 만든 정식 표준이지만, RTMP는 어도비에서 제작한 프로토콜로 정식 표준은 아니다.
RTMP는 관련 제어하는 핸드쉐이크 제어 메세지가 있고, PLAY, 오디오, 비디오 등 데이터 자체를 재생하기도 한다. RTMP는 제어 메세지를 전달하는 프로토콜 메세지를 다 가지고 있으므로 RTMP 구현시 웹브라우저에서 오디오비디오 재생가능
RTMP는 어도비에 의해 제작되어 flash 플러그인을 설치하고 써야한다. 하지만, 최근 HTML5가 등장하면서 브라우저 내에서 flash plug-in이 지원이 안 되는 경우가 있어 HLS와 같은 프로토콜을 사용한다.
HLS (HTTP Live Streaming)
HLS는 가장 많이 사용되는 프로토콜로 스트리밍 시 70%-80%가 이 프로토콜을 사용한다.
오디오나 비디오가 입력으로 들어오면 서버에서는 미디어 인코더를 통해 파일을 만든다.
코덱(영어: codec)은 어떠한 데이터 스트림이나 신호에 대해, 인코딩이나 디코딩, 혹은 둘 다를 할 수 있는 하드웨어나 소프트웨어를 말한다. mp2, mp3, mp4 등으로 압축할 수 있는 코덱으로 인코더가 파일을 만든다.
인코딩 과정을 통해 파일은 여러 개가 생성된다.
서버에서 생성된 파일을 세그멘테이션(segmentation)을 통해 몇 초 단위로 쪼갠 후 인덱스 번호를 붙인다.
이후 서버에서 HTTP를 통해 전송하는데, 네트워크의 속도에 따라 전송하는 비디오의 포맷이 달라지는데, 이것이 바로 해상도 차이이이다.
앞서 해 두었던 인덱싱은 HTTP에서 5분 10초에 대한 오디오/비디오를 요청하면 인덱스 번호를 통해 올바르게 전송한다.
이러한 구조가 HTTP 기반으로 스트리밍이 가능하고, 라이브의 형태로 제공할 수 있기 때문에 HTTP Live Streaming이 된다. 유튜브 생방송이나, 방송국 라이브도 HLS를 사용한다.
MPEG-DASH (Dynamic Adaptive Streaming over HTTP)
마찬가지로 HTTP 위에서 작동한다. HTTP에서는 HLS가 표준이며, MPEG-DASH는 HLS와 형태/구현물만 다르며 구조는 비슷하다.
HTTP가 파일을 전송하는 동안 데이터를 받는데, 전송과정은 HLS와 동일하다.
하지만 HTTP Access Control에서 어떤 데이터를 받느냐에 따라 달라진다.
MPEG-DASH는 네트워크나 클라이언트의 해상도에 따라 동적으로 스트리밍한다.
따라서 데이터 자체의 퀄리티를 조정할 수 있다는 특징이 있다.
Real Time Messaging Protocol (RTMP)
가장 많이 사용되었고, 가장 오래되었지만, 아직도 사용 중인 산업 표준 중 하나다.
스트리밍을 지향하진 않았지만 오디오와 비디오를 포함할 수 있기 때문에 많이 지원되었다.
국내 방송국에서 실시간 전송 시 채택한 상업 SW는 Wowza이다.
방송국에서 스트리밍 서버를 구축할 때에 Wowza를 사용하여 마이크로부터 받은 오디오와 카메라로부터 받은 비디오를 실시간으로 전송할 수 있다.
Wowza는 RTMP, RTP/RTSP, REST API, DASH, HLS, WebRTC의 기능을 모두 포함하고 있다.
[참고링크] https://en.wikipedia.org/wiki/Wowza_Streaming_Engine
RTMP는 TCP 위에서 메세지를 주고 받을 수 있는 별도의 헤더 포맷이 존재한다.
타임 스탬프를 통해 해당 오디오가 몇 분 몇 초에 생성되었다를 보여준다. 따라서 타임 스탬프를 통해 원하는 시간대를 알 수 있으며, 위와 같은 메세지를 왔다갔다하면서 데이터를 전송한다.
위 사진은 2014년도에 스트리밍 프로토콜로 어떤 것을 쓰는지를 보여주는 표다.
당시에는 모두 RTMP(어도비의 flash)를 사용하였고, 서버-클라이언트 구조를 만들어 웹에서 비디오를 바로 전송할 수 있게 만들었다. 또한 높은 해상도도 제공할 수 있다. 하지만 최근 RTMP는 HLS로 많이 대체되었다.
Software
- Client
XBMC
Gnash
- Rtmpdump
Mplayer, avconv, ffmpeg, cURL, VLC
- Server
Adobe Flash Media Server
FFmpeg
각 클라이언트와 서버에서 사용할 수 있는 소프트웨어는 위와 같다.
이때, ffmpeg은 클라이언트와 서버에서 동시에 사용할 수 있는 오픈소스이다.
HTTP Live Streaming (HLS)
HLS는 현재 우리가 쓰는 HTML5 이후의 표준으로 오디오와 비디오를 전송할 때 대부분 HLS를 사용한다.
이 표준은 애플에서 만들었으며 오픈되어 있어 여러 응용이 가능하다.
오디오/비디오를 별도 압축하는 코덱이 있으며, 지금 표준으로는 H.264로 인코딩하여 전송한다. (압축률 높임)
데이터를 6초 단위로 조각내고, 각 조각을 실시간으로 전송했을 때에 다운로드를 받아야 하는 시간이 필요하기 때문에 6초 정도의 딜레이가 발생할 수 있다. 즉, 실제 방송과의 시간차가 존재한다.
데이터 전송의 기본 단위는 TCP인데, HTTP3가 등장하면서 UDP를 사용한다.
이때, 구글 내부 망과 같이 UDP를 지원하는 곳에서는 UDP를 사용한다.
interactive한 화상 회의의 목적은 아니며, 일부 딜레이나 버퍼링이 발생한다.
nginx와 같은 웹 서버에도 오픈 소스를 지원하기 때문에 내가 만든 웹 서버에 HLS 모듈을 연동한 후 카메라를 연결하면 비디오 실시간 전송 서비스를 구축할 수 있다.
HTTP Live Streaming 서비스
서비스를 하기 위해 HTML 파일에서 video src에 mp3에 대한 실제 url을 넣는다.
이 url은 실제 비디오 파일이 될 수도 있고 카메라가 녹화해서 받아오는 데이터일 수 있다.
이 파일을 계속해서 사용해야 하기 때문에 해당 파일에 대해 인덱스 파일을 계속해서 생성하고 저장하여 전송한다.
이렇게 실시간 서버를 만들 수 있지만 상용 서비스로 만들기 위해서는 정식으로 인증서를 발급해야 한다.
참고 및 출처
https://yoooonghyun.gitbook.io/documents/multimedia/overview
'Computer Science > 컴퓨터네트워크(ComNet)' 카테고리의 다른 글
| [컴네/CN] WebRTC (0) | 2023.12.10 |
|---|---|
| [컴네/CN] Nodejs (0) | 2023.12.10 |
| [컴네/CN] 암호통신: 방화벽 (0) | 2023.12.09 |
| [컴네/CN] 암호통신: IPSec (0) | 2023.12.09 |
| [컴네/CN] 암호통신: 이메일 (0) | 2023.12.09 |