8. 멀티미디어와 무선 시스템
1. Multimedia Streaming
비디오: 이미지의를 일정한 시간 순서대로 보여주는 것 (24 images/sec)
디지털 이미지: array of pixels
코딩: 압축 바
temporal coding: 영상의 매 프레임마다 모든 정보를 보내면 부하가 크기 때문에 달라진 비트 값만 보냄.
spatial: 모든 픽셀 정보가 아니라 비슷한 픽셀은 하나만 추출해서 보냄.
CBR (constant bit rate)
VBR (variable bit rate)
MPEG1 (CD_ROM) 1.5 Mbps
MPEG2 (DVD) 3-6Mbps
MPEG4 (인터넷 환경에서 주로 쓰인다 , 1 Mbps 이하)
Streaming stored
streaming: 파일 전체를 다운 받기 전에 재생할 수 있다.
1-1. Streaming stored video
저장된 비디오를 스트리밍
(1) video recorded (2) video sent (3) video received, played out at client
(2)와 (3) 사이를 스트리밍이라고 한다.
비디오가 저장된 서버로 부터 인터넷을 거쳐 클라이언트로 온다.
모든 비디오 데이터를 받기 전에 클라이언트에서 재생할 수 있다.
어느 정도의 데이터가 들어오면 비디오를 재생할 것인가?
Continuous playout constraint
바로바로 재생하면 좋겠지만 jitter가 있기 때문에 원래 시간대로 실행하기 위해서는 클라이언트에 버퍼가 필요하다.
jitter: 각 패킷에 대한 지연 변동 (delay for each packet fluctuates)
라우터에서 queueing delay가 일어나기 때문에 패킷이 도착하는 시간은 일정하지 않다.
video transmission과 비디오 데이터를 클라이언트에서 받는 사이에 딜레이가 존재하는데 이것이 네트워크 딜레이, 지터이다.
jitter를 줄이기위해 버퍼를 사용하자!
client-side buffering and playout delay: 클라이언트에서 버퍼링을 사용하기 때문에 비디오 실행에 딜레이가 걸린다. 네트워크 딜레이가 걸릴 것을 예상하고 대비하기 위함. (playout delay: 비디오 데이터를 받은 후 부터 실행하기 까지 걸리는 시간)
단점은?
1-2. Streaming multimedia: HTTP
멀티미디어 파일은 HTTP를 통해 웹 상에서 가져온다.
TCP 최대 전송율 밑으로 전송 가능함.
버퍼의 한계는 TCP congestion control과 retransmission(순차 전송) 에 영향을 받는다.
Application playout buffer: 시작할 때 딜레이(playout delay)는 오래걸리지만 영상은 부드럽다.
왜 HTTP(TCP) 를 사용하는가?
UDP TCP 차이
UDP: unreliable(no acks), lightweight(faster), smooth
TCPL reliable(use acks), heavyweight(slower), sawtooth pattern (congestion control)
이러한 특성들만 봤을 때 UDP를 사용해야하지만... TCP를 사용한다.
UDP는 보안 문제로 방화벽에 막힘
비디오 스트리밍을 위해 서버를 따로 두어야함.
HTTP는 방화벽을 뚫기 쉽다.
기존에 있던 웹 서버를 사용할 수 있다.
TCP sawtooth pattern은 application buffer를 통해 완화할 수 있다.
1-3. DASH: Dynamic, Adaptive Streaming over HTTP
서버
여러 화질의 영상을 가지고 있다.(encoded different rates)
영상들은 청크(chunk)로 나누어져 있는데 하나의 청크는 1~15초의 비디오 영상 데이터이다.
클라이언트
주기적으로 서버-클라이언트의 bandwidth을 측정
현재 bandwidth에서 받을 수 있는 가장 높은 부호화 속도를 선택
당시의 bandwidth에 따라 다른 속도를 선택할 수 있다.
MPEG-DASH, Adobe, Apple, MS
각각의 청크가 존재하는 url에 접속
1-4. Voice-over-IP (VoIP)
- VoIP end-end-delay requirement: 대화해야 하기 때문에 딜레이가 높아서는 안된다. 400 ms 이상 넘어가면 사람이 느낄 수 있음.
- network loss: 네트워크가 혼잡하여 (라우터 오버플로우) IP datagram lost 가 발생할 수 있다. 이 때 재전송을 하게 되면 딜레이가 급격히 증가하기 때문에 대신에 FEC나 Interleaving을 사용함.
Forward Error Correction (FEC) vs. Interleaving
FEC(=Compounding high-and-low resolution packets) | Interleaving (사이사이에 끼워넣는다는 의미) |
앞에 보낸 음성데이터를 저음질(low resolution)로 복제해서 piggyback (1번 데이터를 저음질로 2번 데이터에 실어 보낸다.) |
non interleaved transmission: 보낼 데이터를 순차적으로 패킷으로 묶어 보낸다. |
패킷 로스가 발생하면 다음 패킷으로부터 저음질 데이터를 가져온다. | interleaved transmission: 보낼 데이터를 세로로 묶은 순서로 보내고 수신자 측에서 재조합한다. 각 패킷에 1개씩 밖에 에러가 안난 것 처럼 하여 error correction |
장점: delay가 낮다 단점: 패킷 하나만 로스났을 땐 복구 가능하지만, 연속적인 로스는 복구 불가능하다. 그리고 사실 패킷 하나만 로스나는 경우는 거의 없다. |
장점: FEC에 비해 오버헤드가 줄어든다. 단점: Playout delay |
non-consecutive loss: receiver can conceal loss |
참고 사이트:
2. Content Delivery Network (CDN)
3. Wireless/Mobile Architecture
Subscribe to Mem Learning
Get the latest posts delivered right to your inbox