[Video Streaming & CDNs의 배경]
- Stream video traffic : 인터넷 대역폭의 주된 소비자(주거용 ISP 트래픽의 80%가 넷플릭스, 유튜브, 아마존)
- 어떻게 엄청 많은 유저들에게 정보가 도달할 수 있을까?
- 서로 다른 유저들의 서로 다른 용량을 어떻게 고려할까?
💨 분산형 Application-level 인프라 구축을 통해 해결 가능
🎞 Video Streaming 개념
Video : 비디오는 변함없는 비율로 나타나는 연속된 이미지들이라고 할 수 있다! (예를 들어 초마다 24 or 30 프레임을 연속적으로 보여주는 것)
Digital image : 픽셀들의 배열, 각 픽셀은 bits(rgb정보같은 것을 나타내는)로 이루어짐
Encoding : 이미지 내부 혹은 이미지들 사이의 중복을 활용해서 이미지를 부호화 하는 데에 사용되는 비트 수를 줄이는 것
- 공간적 활용 예시: 같은 색의 N개 값을 다 보내는 대신에 무슨 색인지(1), 그 색이 반복되는 갯수(2) 이렇게 두 가지 값만 보내는 것
- 시간적 활용 예시: i번째 프레임에서 i+1프레임으로 넘어갈 때, i+1프레임의 완벽한 값 말고 i프레임과 비교했을 때 차이가 나는 부분에 대해서만 정보를 보내는 것
- 비트 전송률과 비디오 화질 사이의 균형
CBR(constant bit rate) : 고정된 비디오 인코딩 속도
VBR(variable bit rate) : 비디오 인코딩 속도는 공간적/시간적 코딩의 변화에 따라 달라질 수 있음
👀 같은 비디오를 다양한 버전으로 만들 수 있고 각 버전의 퀄리티는 다를 수 있음. 유저는 자신이 이용가능한 대역폭에 따라 원하는 버전으로 선택할 수 있음.
📽 Streaming stored video(비디오 스트리밍)
- 비디오는 저장된 서버 -> 인터넷 -> 클라이언트로 옴
- 모든 데이타를 받기 전에 클라이언트에서 재생 할 수 있다.
- 서버와 클라이언트 사이의 대역폭은 시간이 지남에 따라 달라질 수 있다(변동하는 network congestion levels 때문).
- congestion으로 인한 패킷 손실, 딜레이는 재생을 지연시키거나 형편없는 화질의 이유가 될 수 있다.
- continuous playout constraint(연속 재생 제약조건): 클라이언트가 비디오를 재생하는 동안 재생시간은 원래의 타이밍과 딱 맞아야 한다(그래야 동영상 속도가 일정하게 흘러나온다. 당연한 것).
- 하지만 네트워크 딜레이는 가변적임(jitter: 딜레이의 변동을 나타내는 말)
-> 연속 재생 제약조건을 맞추려면 client-side buffer가 필요하다.
- client-side buffering: beffered video라고 써져있는 부분이 버퍼에 있는 비디오 데이터의 양을 나타낸 것이다. 만약 playout그래프(맨 오른쪽)가 서버로부터 데이타 전달되는 그래프(중간)보다 더 커지면 beffer가 비어서 재생하지 못한다.
- client playout deley: 동그라미 친 부분과 같이 딜레이가 일정하지 않기 때문에 재생이 중간에 끊길 수 있으므로 프레임을 받은 뒤에 어느 정도 기다렸다가 재생하는 것
100% + 100%