기존 영상 전송 방식 (SNG)
SNG(Satellite News Gathering) 방식은 위성을 통해 동영상을 실시간으로 스트리밍 하는 방법을 의미한다. 특징으로는
•
차량에 탑재 되어서 현장에서 실시간으로 뉴스를 전송
•
고속 전송이 가능하다
•
광범위한 지역에 송수신 가능
•
고품질 영상 전송이 가능하다.
단점으로는,
•
높은 비용 (운용 인력비, 유지 보수 비용)
•
복잡한 설치 및 운영
•
기동성이 떨어짐 (차가 들어가지 못하는 곳에는 어렵다.)
•
지연시간 (위성을 사용하기 떄문에 지연시간 발생)
•
환경 의존성 (날씨가 좋아야 된다.)
네트워크 전송 방식
인터넷이 발달함에 따라서 비용적인 측면 때문에 SNG방식 보다는 네트워크 전송 방식을 선택하게 된다.
네트워크 전송방식은 OSI 7계층을 통해서 데이터를 송수신 하는데,
정리해서 말하자면, 물리적 회선을 통한 패킷교환 방식이라고 말할 수 있다.
영상 전송의 주요 3단계
원래는 5단계 정도가 있지만,
우리가 직접 사용하는 환경에 대해서 요약을 하자면 위의 3단계로 표현할 수 있다.
전송하는 과정에서의 프로토콜과
배포하는 과정에서의 프로토콜이 있다고만 생각해두자.
동영상 전송이 가진 문제점
동영상은 상대적으로 데이터가 크므로, 이 용량이 큰 데이터를 보내는 방법에 대한 고민과
영상이기 때문에 데이터가 순서대로 전달되어야 된다는 점이 중요하다.
영상 다운로드 방식 (프로그레시브 방식)
하지만 과거 영상 네트워크 전송방식에서는
다운로드가 완료가 되어야지 영상을 재생할 수 있다는 단점과
다운로드가 중간에 실패하면 다시 처음부터 다운받아야 된다는 큰 단점이 존재했다.
영상 전송 프로토콜 ( RTSP / RTMP / SRT )
RTSP의 등장
다운로드를 방식을 사용하던 시대에서는 신세계와 같았음.
일단,
영상받다가 끊겨도 처음 부터 다시 다운 받지 않아도 되고,
중간에 영상도 탐색이 가능하고
그리고 응답속도 역시 빨랐다.
하지만,,,
미디어 서버를 운용하기에는 부적합했다. 영상이 깨지는 문제등등으로…
RTMP의 등장
RTMP는 macro media에서 개발한 프로토콜로,
•
현재 가장 많이 쓰이는 프로토콜
•
실시간 스트리밍에 적합하고
•
지속적인 연결유지
•
Adobe사에 인수가 되어서 flash 미디어 서버에서 많이 사용됨
•
호환성, 범용성이 좋다
하지만,
•
현재에선 오래된 규격
•
비용이 많이 들어가는 문제
•
Adobe가 2020년도 flash 지원 중단 —> 보안 이슈
•
hevc 코덱 지원하지 않음 —> 최신 코덱 사용 못함
•
암호 전송 안됨
SRT의 등장
Haivision에서 개발한 프로토콜
•
RTSP, RTMP의 장점 모두 유지
•
낮은 딜레이
•
신뢰할 수 있는 전송 (데이터 유실 적음)
•
암호화 가능 —> 군대, 방송사에서 사용됨
하지만
•
한 회사에서 개발한 프로토콜이라 호환성, 범용성이 떨어짐
영상 시청 프로토콜 HLS vs DASH
HLS와 DASH는 delievery 단계에서 사용되는 프로토콜로
즉, 영상 시청에 사용되는 프로토콜이다.
기존 프로그레시브 방식과는 다르게, 영상을 다 다운받아서 실행하는 방식이 아니라.
영상을 잘게 나누어서 전송하는 방식이다.
이는 네트워크 상태에 따라서 실시간으로 스트리밍 품질조절이 가능하고,
결국 라이브 스트리밍이 가능하다.
그리고 HTTP 웹 인프라를 사용하기 때문에, 방화벽과 프록시를 쉽게 통과할 수 있으며,
많은 사용자들에게 효율적으로 분배가 가능하다.
HLS (Http Live Streaming)
애플이 애플사용자를 위하여 개발한 프로토콜
구현이 비교적 단순하고, 실시간 라이브 스트리밍에 적합하다.
단점으로는 플랫폼 종속적이라 호환성 문제가 있다.
DASH (Dynamic Adaptive Streaming over HTTP)
DASH는 국제 표준 스트리밍 프로토콜이다.
HLS가 Apple에 최적화 되어있어,
다양한 디바이스 환경에서 일관적인 서비스를 위해서 개발.
다양한 코덱지원과 대역폭 사용이 가능.
MPD파일로 다양한 메타데이터 관리가능. (자막, 챕터, 정보, 썸네일 등등)
세그먼트 파일 비교
TS 파일
ts는 HLS에서 사용하는 세그먼트 파일으로 실시간 스트리밍에서 강력하다.
구현이 상대적으로 단순하다.
하지만,
세그먼트의 크기가 고정(188바이트)되어 있어,
각 세그먼트 마다 헤더를 가져야 하므로, 오버헤드가 증가한다. → 비효율적인 대역폭사용
고정된 크기의 패킷 구조는 저장 매체에서 효율성을 떨어뜨릴수 있다.
코덱 지원에 제한적이다.
그리고 메타 데이터를 포함하는 데 제한적이라, 추가 정보를 포함하기 어렵다.
m4s 파일
m4s는 dash에서 사용하는 세그먼트 파일로,
유연한 길이를 가지고 있어서, 낮은 오베헤드 발생율을 가지고 있다.
패킷 기반이 아닌 청크 기반 구조로, 헤더 오버헤드가 적고,
효율적인 데이터 전송이 가능
메타 데이터를 관리하는 방법 역시 수월하고,
다양한 코덱을 지원한다. avc,hevc
하지만,,
구현이 다소 복잡하다.