protocol_3주차_MPEG DASH

** 중요한 질문 **

왜 WebRTC가 제일 빠른데 유튜브나 넷플릭스는 DASH와 HLS를 사용하는 걸까???

https://groups.google.com/forum/#!topic/discuss-webrtc/lwiSndTR7AU

https://groups.google.com/a/chromium.org/forum/#!topic/proto-quic/iW2B1QO-Eww(필립윤 질문)

https://www.quora.com/Which-is-better-for-live-streaming-RTMP-vs-HLS-vs-WebRTC

(어떤 라이브 스트리밍, RTMP 대 HLS 대 WebRTC에 대한 더 나은 무엇입니까?)

https://www.quora.com/Which-method-is-better-HTTP-downloading-or-RTMP-streaming

(HTTP와 RTMP의 차이)

https://www.quora.com/Which-is-the-best-way-to-stream-live-video-on-a-website-Ive-been-reading-a-lot-about-RTMP-and-HTTP-pseudo-streaming-Which-one-is-better-and-why

1. Trick mode play

일반적인 영상재생이 아니라 빨리감기, 되감기, 탐색 등의 작업을 위해 DASH 클라이언트가 사용

2. MPEG CMAF(MPEG-A)란?

3. HDS, MSS는 각가 자사의 프로토콜에서 DASH로 전환? 이유는?

4. HTTP/ 1.1 은? 2.0과의 차이점은?

5. WebRTC도 CDN사용가능? (dash나 hls가 cdn을 쓰고 webRTC가 쓰지 못해서 유투브나 넷플릭스가 webRTC를 사용하지 않는건가 궁금)

https://flashphoner.com/how-to-create-a-streaming-cdn-for-low-latency-webrtc-video-broadcasting/

응. 가능 

6. PSNR(Peak Signal to Noise Rate)

https://m.blog.naver.com/PostView.nhn?blogId=forey73&logNo=70007165272&proxyReferer=https%3A%2F%2Fwww.google.co.kr%2F

최대 신호 대 잡음비(Peak Signal-to-noise ratio, PSNR)는 신호가 가질 수 있는 최대 전력에 대한 잡음의 전력을 나타낸 것이다. 주로 영상 또는 동영상 손실 압축에서 화질 손실 정보를 평가할때 사용된다. 최대 신호 대 잡음비는 신호의 전력에 대한 고려 없이 평균 제곱 오차(MSE)를 이용해서 계산 할 수 있다.

수치가 높을수록 노이즈에 대한 저항력이 크다. 즉 동영상 퀄리티가 높다. 하지만 30db이상에서는 육안으로 구분하기가 어렵다.

7. i/p/b 프레임

I 프레임 - Infra Frame 의 약자로, 쉽게 말해 키 프레임 입니다. 이것은 JPEG 같은 방식으로 소스로부터 직접 압축되어 온 전체 그림이죠. 가장 화질도 좋지만 가장 용량도 큽니다.

P 프레임 - Previous 또는 Predicted Frame 이라 불리며, 이전에 나온 키 프레임의 정보를 바탕으로 구성된 프레임 입니다. 화질/용량 둘 다 중간급입니다.

B 프레임 - Bidirectional Frame 의 약자로, 전후의 I/P 프레임의 정보를 바탕으로 구성된 프레임 입니다. 화질/용량이 다 최하급입니다. 

GOP (Group of Pictures)

이것은 MPEG-1/2 인코딩의 가장 기본으로, 키 프레임부터 다음 키 프레임까지의 프레임 모음을 뜻하는 겁니다. 
프레임 타입에는 I, P, B 의 세가지가 있으며 각각의 특징은 아래와 같습니다.

 Scene Detection : 화면이 바뀌는 것을 감지해서 I-frame을 끼워넣는 것

Closed GOP 는 GOP 구성중 다음 I 프레임 전의 B 프레임들을 빼 버리는 방법입니다. 

=> i프레임과 세그먼트 길이

세그먼트 길이를 짧게 할수록 세그먼트 맨 앞에 포함해야할 i프레임이 많아지므로 인코딩 효율이 떨어지게 된다.

8. index segments

https://www.brendanlong.com/the-structure-of-an-mpeg-dash-mpd.html

Index Segments(sidx, ssix)

Index Segments come in two types: one Representation Index Segment for the entire Representation, or a Single Index Segment per Media Segment. A Representation Index Segment is always a separate file, but a Single Index Segment can be a byte range in the same file as the Media Segment.

Index Segments contain ISOBMFF 'sidx' boxes, with information about Media Segment durations (in both bytes and time), stream access point types, and optionally subsegment information in 'ssix' boxes (the same information, but within segments). In the case of a Representation Index Segment, the 'sidx' boxes come one after another, but they are preceded by an 'sidx' for the index segment itself.

9. HTTP/1.1 과 2.0

https://www.popit.kr/%EB%82%98%EB%A7%8C-%EB%AA%A8%EB%A5%B4%EA%B3%A0-%EC%9E%88%EB%8D%98-http2/

HTTP/1.1의 connection당 하나의 요청처리

요청처리 개선방법 => pipelining

하나의 Connection을 통해서 다수개의 파일을 요청/응답 받을 수 있는 기법을 말하는데 이 기법을 통해서 어느정도의 성능 향상을 꾀 할 수 있으나 큰 문제점이 하나 있다.

순서대로 첫번째 이미지를 요청하고 응답받고 다음 이미지를 요청하게 되는데 만약 첫번째 이미지를 요청하고 응답이 지연되면 아래 그림과 같이 두,세번째 이미지는 당연히 첫번째 이미지의 응답처리가 완료되기 전까지 대기하게 되며 이와 같은 현상을 HTTP의 Head of Line Blocking 이라 부르며 파이프 라이닝의 큰 문제점 중 하나이다.

RTT(Round Trip Time) 증가

무거운 Header 구조(특히 쿠키)

HTTP/2가 어떤 방식으로 성능을 향상 시키고 있는지 주요 요소에 대해 알아보자.

Multiplexed Streams

한 커넥션으로 동시에 여러개의 메세지를 주고 받을 있으며, 응답은 순서에 상관없이 stream으로 주고 받는다. HTTP/1.1의 Connection Keep-Alive, Pipelining의 개선이라 보면 된다.

Stream Prioritization

예를 들면 클라이언트가 요청한 HTML문서안에 CSS파일 1개와 Image파일 2개가 존재하고 이를 클라이언트가 각각 요청하고 난 후 Image파일보다 CSS파일의 수신이 늦어지는 경우 브라우저의 렌더링이 늦어지는 문제가 발생하는데 HTTP/2의 경우 리소스간 의존관계(우선순위)를 설정하여 이런 문제를 해결하고 있다.

Server Push

서버는 클라이언트의 요청에 대해 요청하지도 않은 리소스를 마음대로 보내줄 수 도 있다.

무슨 소리인고 하면 클라이언트(브라우저)가 HTML문서를 요청했고 해당 HTML에 여러개의 리소스(CSS, Image...) 가 포함되어 있는경우 HTTP/1.1에서 클라이언트는 요청한 HTML문서를 수신한 후  HTML문서를 해석하면서 필요한 리소스를 재 요청하는 반면 HTTP/2에선 Server Push기법을 통해서 클라이언트가 요청하지도 않은 (HTML문서에 포함된 리소스) 리소스를 Push 해주는 방법으로 클라이언트의 요청을 최소화 해서 성능 향상을 이끌어 낸다. 이를 PUSH_PROMISE 라고 부르며 PUSH_PROMISE를 통해서 서버가 전송한 리소스에 대해선 클라이언트는 요청을 하지 않는다.

Header Compression

HTTP/2는 Header 정보를 압축하기 위해 Header Table과 Huffman Encoding 기법을 사용하여 처리하는데 이를 HPACK 압축방식이라 부르며 별도의 명세서(RFC 7531)로 관리하고 있다.