멀티미디어네트워크
멀티미디어를 제공하는 네트워크는 뭐가 다를까?
오디오를 전송할 때, 샘플링을 통해 analog signal을 변환하는 작업이 필요하다. 샘플링한 데이터의 크기와 주기에 따라 오차가 변화한다.
초당 64,000bit를 보낸다 -> 초당 전송되는 bit가 많을수록 정확하게 전송된다.
CD: 1.41Mbps
MP3: 96,128,160 kbps
=> CD>MP3
각 픽셀에 어떤 색이 있는지 인코딩하여 압축시켜서 전송한다. 이웃한 픽셀엔 비슷한 정보가 있을 것.
CBR(Constant bit rate) : video encoding rate fixed
VBR(Variable bit rate) : video encoding rate changes as amount of psatial, temporal coding changes
코딩 rate 가 높을수록 화질이 좋을 것 !!
Ex) MPEG 1 (CD-ROM): 1.5Mbps
MPEG 2 (DVD): 3-6Mbps
MPEG 4 (often used in Internet) < 1mbps
Stored audio video : YouTube
Streaming audio video : Streaming live
Sever의 Network을 거쳐서 Client에게 전송
여기서 문제는 -> Network Delay가 일정하지 않다! = Network Jitter
-> buffering으로 모든 데이터가 모아졌을 때 재생 (Client-side buffering, playout)
결국, Server -> Client 모두 application : transport layer에 의존한다. (TCP, UDP)
보통 멀티미디어 서비스는 TCP 통신을 한다.
DASH (Dynamic Adaptive Streaming over HTTP)
- Server :
- divides video files into multiple chuncks
- each chunck stored, encoded at different rates
- manifest file : provides URLs for different chunks
- Client :
- periodically measures server-to-client bandwith
- consulting manifest, requests one chunck at a time
- chooses maximum coding rate sustainable given current bandwidth
- can choose different coding rates at different points in time (depending on available bandwith at time)
2GB의 미디어를 전송한다고 하면, 여러 chunk로 나눠서 인코딩한다.
chunk1 -> 128kbps url, 256kbps url, 512kbps url, ~ ,5Mbps url
chunk2 -> 128kbps url, 256kbps url, 512kbps url, ~ ,5Mbps url
.
.
.
chunk8000 -> 128kbps url, 256kbps url, 512kbps url, ~ ,5Mbps
-> Manifest File (각 chunk no. 와 url이 담겨있는 파일)
unicast vs. multicast
multicast -> 라우터의 고도화된 기능 구현이 필요하다. 다른 방법이 필요!
--> CDN(Content Distribution Network): 컨텐츠의 스토리지를 분리하여 배포하는 것. (application layer 기법)
-> Manifest file을 client와 가장 가까운 스토리지 인프라에서 제공함
사용자의 Access Network -> SK broadband .. CDN 인프라의 물리적 위치에 최적화된 곳!
Case Study : Netflix
owns very little infrastructure -> 아마존 클라우드 서비스를 이용한다!
느낀점) 넷플릭스는 네트워크, 클라우드 쪽에서 케이스스터디로 많이 연구되는 회사이다. 기술력의 뛰어남을 알 수 있었다.