
미러링 기술 개발에 필요한 영상 스트리밍에 대한 공부를 해 볼 예정이다.
미러링
화면이라는 실시간 미디어를 다른 기기까지 끊기지 않게 전달/재생 하는 것이다.
이러한 미러링을 가능하게 해주는 표준적인 해법이 영상 스트리밍 인 것.
미러링 = 실시간 스트리밍 이라고 생각할 수 있다.
다운로드
파일 전체를 받은 뒤 재생하는 것
스트리밍
데이터가 들어오는 대로 즉시 재생 하는 것
지연 최소화가 중요하다.
데이터가 생성되는 즉시 전송하고 재생하는 방식.
지연 시간 최소화 / 버퍼링 최소화 / 거의 실시간
ex) 미러링, 화상 통화
주요 기술
WebRTC(Web Real-Time Commnication), RTSP(Real-Time Streaming Protocol)
파일을 내려받으면서 동시에 재생하는 방식.
파일을 일부만 다운로드 해도 재생이 시작되고, 계속해서 남은 부분을 순차적으로 다운로드한다.
영상을 시청할 때 영상이 끊기지 않도록 버퍼링을 통해 일정량의 데이터를 미리 저장해둔다. (버퍼링 기반 스트리밍)
실시간성이 낮음 / 네트워크가 불안정해도 버퍼링 덕에 끊기는 현상을 줄인다
ex) 유튜브,넷플릭스
주요 기술
HLS(HTTP Live Streaming), DASH(Dynamic Adaptive Streaming over HTTP)
원본 영상은 용량이 너무 커서 인터넷으로 전송하기가 어렵다.
- 원본 영상은 초당 수백 메가 ‼️ -> 네트워크로 전송할 수 없다.
-> 압축 기술을 사용해서 영상 용량을 줄인다.
압축을 담당하는 소프트웨어나 하드웨어 기술
코더(Coder)가 영상을 압축하고, 디코더(Decoder)가 압축된 영상을 다시 풀어주는 (압축해제) 역할을 한다.
코덱 = 코더 + 디코더
H.265, H.265, VP9, AV1 모두 영상 압축에 사용되는 코덱의 이름
- H.264: 가장 널리 사용되는 표준 코덱
- H.265: H.264보다 압축 효율이 좋음. 같은 화질을 더 적은 용량으로 만들 수 있음.
- VP9, AV1: 구글이 주도하여 만든 코덱. H.265와 유사하거나 더 나은 압축 효율
압축 방식은 '영상을 어떻게 줄이는지'에 대한 방식
영상은 '프레임'이란 수많은 정지 이미지들의 연속으로 이루어짐
키프레임 + 델타프레임 구조
영상의 용량을 획기적으로 줄임.
대역폭(즉, 네트워크)를 통해 전송할 수 있는 데이터의 양을 절약하게 됨.

파일을 통째로 받아야 재생이 가능하므로, 수 초 정도의 지연이 발생함.
WebRTC (Web Real-Time Communication)
웹 브라우저 간에 별도의 프로그램 설치 없이 P2P 방식으로 직접 통신하는 기술.
중간 서버를 거치지 않고 장치끼리 직접 데이터를 주고받기에 초저지연이 가능
이미 있는 영상을 다른 코덱/해상도로 변환
ex) H.264 4K -> H.264 720p
이미 압축된 영상을 다른 코덱이나 해상도, 비트레이트(데이터 전송량)으로 재변환하는 것.
원본 영상보다 낮은 품질로 변환해 파일 크기를 줄이거나,
특정 기기에서 재생할 수 있도록 코덱을 바꿈
CPU나 GPU 자원을 많이 소모 하므로, 실시간으로 처리하긴 어렵고
미리 여러 버전의 파일을 만드는 경우가 많음.
같은 압축 포맷이지만 다른 컨테이너로 변환
ex) .mp4 -> .ts
영상의 코덱(압축 포맷)은 그대로 두고, 영상 데이터를 담는 컨테이너 포맷만 바꾸는것.
H.264 코덱으로 압축된 영상 파일을 MP4 컨테이너에서 TS 컨테이너로 바꾸는 작업.
컨테이너는 영상, 오디오, 자막 등의 데이터를 묶어주는 그릇 역할.
코덱 변환이 필요 없는 과정이므로, 트랜스코딩보다 훨씬 빠르고 효율적.
네트워크 불안정
트랜스코딩이 필요 (실시간으로 영상을 낮은 해상도나 비트레이트로 바꾸어 전송)
여러 기기를 지원
여러 외부 기기에서 최적의 화질을 보여주기 위해 기기마다 다른 해상도와 비트레이트로 영상을 변환하여 전송한다.
지연 최소화가 스트리밍에서 가장 중요함.
지연
영상이 촬영된 시점부터 시청자에게 재생되기까지 걸리는 시간
인코딩 -> 전송 -> 디코딩
H.264 baseline 같은 코덱은 압축 효율은 조금 낮지만, 인코딩/디코딩 속도가 매우 빠르다.
반면, 압축 효율이 높은 H.265나 AV1 코덱은 더 많은 연산이 필요해 지연이 커질 수 있다.
TCP는 패킷 손실시 재전송을 요청하므로 안정적이지만, 재전송 과정에서 지연이 발생한다.
UDP는 패킷 손실이 발생해도 재전송 없이 데이터를 계속 보낸다.
신뢰성은 낮아도, 지연을 최소화할 수 있다.
RTP와 WebRTC가 UDP를 기반으로 한다.
버퍼
영상이 끊기지 않도록 미리 데이터를 저장해두는 공간
버퍼를 크게 설정하면, 네트워크가 불안정해도 끊김 없이 영상을 볼 수 있다. 그러나, 재생이 시작되기까지의 지연 시간이 길어진다.
지연을 줄이려면, 버퍼를 최소화하여 영상을 거의 실시간으로 전송한다.
대신 네트워크 상태가 나빠지면 영상이 끊길 수 있다.
캡처 -> 압축 -> 전송 -> 압축 해제 -> 출력

스마트폰 화면을 찍는 것
위 API를 사용해, 앱이 화면 전체를 안전하게 녹화하거나 스트리밍 할 수 있게 허가 받는다.
캡처한 원본 영상 데이터는 용량이 너무 크므로, 압축 해야한다.
압축을 돕는 것이 MediaCodec API이다.
이 API는 안드로이드 기기에 내장된 하드웨어 압축 기술을 활용한다.
주로 H.264 같은 코덱을 사용한다고 한다.
압축된 영상을 다른 기기로 보낸다.
RTC/RTSP
서버-클라이언트 구조
ex) 스마트폰이 서버에 영상을 보내고, TV가 클라이언트 역할을 해 받아서 재생
WebRTC
스마트폰과 TV가 P2P 로 직접 연결하여 데이터를 주고받는 방식
중간 과정이 없으므로, 지연시간이 매우 짧다.
영상을 받는 쪽 (ex. TV) 에서 압축된 데이터를 다시 원본 영상으로 되돌려야 한다.
압축할 때 사용했던, MediaCodec API가 압축을 푸는 디코더 역할을 한다.
디코딩이 완료된 영상은 Surface라는 화면 출력 공간에 그러지고, 이 Surface가 받는 쪽 기기 티비 화면에 보이게 된다.