1. MPD와 m3u8 파일은 왜 만들었을까?
=> MPD파일 구조 먼저 살펴봄(https://www.brendanlong.com/the-structure-of-an-mpeg-dash-mpd.html)
=> MPD(DASH), m3u8(HLS)모두 HTTP 스트리밍 프로토콜인데, 이 프로토콜이 Adaptive Bitrate Streaming(ABS) 방식을 사용하기 때문이다. MPD, m3u8파일에는 메타데이터+고~저화질의 청크파일 목록이 들어있다. 이 목록이 들어있는 파일을 만들어서 클라에게 보내주면 클라는 자신의 대역폭에 맞는 데이터 영상을 요청할 수 있다.
또한 HTTP방식은 비동기식인데, 이렇게 파일을 만들어서 클라가 받으면 서버에 재요청할 필요없이 MPD 혹은 m3u8파일에서
변경된 대역폭에 맞는 데이터영상 리스트를 골라 바로 요청할 수 있다.(즉 두 번 요청해야 할 것을 MPD, m3u8 파일을 가지고 있음으로써 한 번요청하면 된다.) => 내생각
*ABS는 클라이언트의 네트워크 환경에 따라 변하는 대역폭에 맞춰 데이터 영상을 보내주는 적응형 스트리밍 방식을 말한다.
<The structure of an MPEG-DASH MPD>
The MPEG-DASH Media Presentation Description (MPD) is an XML document containing information about media segments, their relationships and information necessary to choose between them, and other metadata that may be needed by clients.
-------------------------------------------------------------------------------------------------
Q. xml문서는 뭔데?
https://www.w3schools.com/xml/xml_whatis.asp
XML is a software- and hardware-independent tool for storing and transporting data.
- XML은 eXtensible(확장가능한) Markup Language의 약자입니다.
- XML은 HTML과 비슷한 마크 업 언어입니다.
- XML은 데이터를 저장하고 전송하도록 설계되었습니다.
- XML은 자기 설명 적으로 디자인되었습니다.
- XML은 W3C 권장 사항입니다.
The XML above is quite self-descriptive:
- It has sender information.
- It has receiver information
- It has a heading
- It has a message body.
But still, the XML above does not DO anything. XML is just information wrapped in tags.
=> xml문서는 태그를 감싸고 있는 정보일뿐 아무일도 하지 않는다.
Q-1. 마크업언어는 또 뭔데?
마크업 언어(markup 言語, markup language)는 태그 등을 이용하여 문서나 데이터의 구조를 명기하는 언어의 한 가지이다.
태그는 원래 텍스트와는 별도로 원고의 교정부호와 주석을 표현하기 위한 것이였으나 용도가 점차 확장되어 문서의 구조를 표현하는 역할을 하게 되었다. 이러한 태그 방법의 체계를 마크업 언어라 한다.
-------------------------------------------------------------------------------------------------
XML과 HTML의 차이점
XML과 HTML은 서로 다른 목표로 설계되었습니다.
- XML은 데이터를 전달하도록 설계되었습니다.
- HTML은 데이터를 표시하도록 설계되었습니다. 데이터의 모양에 중점을 둡니다.
- HTML 태그처럼 미리 정의 된 XML 태그가 아닙니다.
-------------------------------------------------------------------------------------------------
XML은 미리 정의 된 태그를 사용하지 않습니다.
XML 언어에는 미리 정의 된 태그가 없습니다.
위의 예제 (<to> 및 <from>과 같은)의 태그는 XML 표준에 정의되어 있지 않습니다. 이러한 태그는 XML 문서 작성자가 "발명"합니다.
HTML은 <p>, <h1>, <table> 등과 같은 사전 정의 된 태그와 함께 작동합니다.
XML의 경우 저자는 태그와 문서 구조를 모두 정의해야합니다.
-------------------------------------------------------------------------------------------------
XML 단순화
- 데이터 공유를 단순화합니다.
- 데이터 전송을 단순화합니다.
- 플랫폼 변경을 단순화합니다.
- 데이터 가용성을 단순화합니다.
많은 컴퓨터 시스템에는 호환되지 않는 형식의 데이터가 들어 있습니다. 호환되지 않는 시스템 (또는 업그레이드 된 시스템)간에 데이터를 교환하는 것은 웹 개발자에게는 시간이 많이 소요되는 작업입니다. 대용량의 데이터는 변환되어야하며 호환되지 않는 데이터는 종종 손실됩니다.
XML은 데이터를 일반 텍스트 형식으로 저장합니다. 이를 통해 소프트웨어 및 하드웨어에 독립적인 방식으로 데이터를 저장, 전송 및 공유 할 수 있습니다.
또한 XML을 사용하면 데이터 손실없이 새 운영 체제, 새 응용 프로그램 또는 새 브라우저로 쉽게 확장하거나 업그레이드 할 수 있습니다.
XML을 사용하면 사람, 컴퓨터, 음성 시스템, 뉴스 피드 등과 같은 모든 종류의 "판독기"에서 데이터를 사용할 수 있습니다.
-------------------------------------------------------------------------------------------------
MPD파일에는 클라의 대역폭에 맞춰 다양한 화질로 제공해 줄 수 있는 영상데이터들이 들어있다.
이 데이터들을 하나의 묶음으로 관리하여 클라의 네트워크 상황에 따라 그에 맞는 영상정보를 전송해 줄 수 있다.
*m3u8
HLS 스트리밍은 진정한 적응 형 비트 전송 기술입니다. 비디오가 HLS로 인코딩되면 여러 대역폭 및 해상도로 여러 파일이 만들어집니다. 파일은 mpg2_ts 코덱을 사용하여 인코딩됩니다 . 스트림은 화면 크기와 사용 가능한 대역폭에 따라 .M3u8 색인 파일을 사용하여 실시간으로 클라이언트에 매핑됩니다.
Answer 2:
MPD파일은 XML 문서이다. XML문서는 HTML과 비슷한 마크업언어로 데이터 전송, 저장을 위해 만들어졌다.
특히 인터넷상에서 데이터를 전송할때 서로 호환되지 않는 형식의 데이터들이 존재할텐데
XML문서는 텍스트 형식으로 저장하기 때문에 소프트웨어 및 하드웨어에 관계없이 데이터를 저장 및 전송, 공유할 수 있다.
즉 MPD파일은 영상데이터 및 그와 관련된 다양한 형식의 데이터들를 클라와 서버, 클라와 클라간의 전송할 수 있도록 만든 파일이다.
-------------------------------------------------------------------------------------------------
what protocol youtube use?
2. 인코더와 코덱의 차이점은?
(둘다 데이터를 압축, 해제해주는거 같은데 무슨 차이..?)
Q. 스트리밍 프로토콜마다 지원하는 코덱이 있고, 모바일 기기에서도 지원되는 코덱이 따로 있다?
ex) HLS는 H.264 코덱만 지원 => 안드로이드와 아이폰 둘다 지원하는 코덱은 H.264(HEVC) => 유투브가 사용하는 코덱!
[iphone 지원 코덱]
[안드로이드 지원 코덱]
(안드로이드 동영상 인코딩 권장사항 : https://developer.android.com/guide/topics/media/media-formats)
Answer : 인코더와 코덱은 비슷한 개념이고 현재 스트리밍 프로토콜에서 영상 데이터를 압축하는 것은 코덱(ex : H.264, VP8 etc)이라고 부르고 그 형태를 포맷(ex : MPEG-4(.mp4), MPEG-TS(.ts))이라고 한다.
추후 인코더와 코덱의 차이 다시 알아보는걸로.
-------------------------------------------------------------------------------------------------
3. MPEG-DASH가 나오게 된 배경은?
아시다시피, 적응 형 비트율 스트리밍비디오 컨텐트를 여러 장치에 온라인으로 전달하기위한 표준이되었습니다. 이러한 유형의 전송은 클라이언트의 대역폭 용량을 탐지하고 여러 비트 전송률 및 / 또는 해상도 사이에서 비디오 스트림의 품질을 조정하는 서버 및 클라이언트 소프트웨어의 조합입니다. 적응 형 비트 레이트 비디오 경험은 단일 비트 전송률로 정적 비디오 파일을 전송하는 것보다 월등합니다. 왜냐하면 비디오 스트림이 클라이언트의 사용 가능한 네트워크 속도만큼 좋거나 나쁠 수 있도록 중간에 전환 될 수 있기 때문입니다 (재생할 때의 버퍼링 또는 중단과는 달리 클라이언트의 네트워크 속도가 비디오 품질을 지원할 수 없을 때 발생합니다.) 표준 HTTP 포트를 사용하기 때문에 방화벽, 특수 프록시 또는 캐시가 부족하고 비용 효율성이 높아 인기와 사용이 증가했습니다. 이러한 유형의 배송에는 세 가지 기본 프로토콜이 있습니다.HTTP 실시간 스트리밍 , Microsoft Smooth Streaming 및 HTTP 동적 스트리밍 . 각 프로토콜은 서로 다른 방법 및 형식을 사용하므로 각 서버에서 콘텐츠를 수신하려면 장치가 각 프로토콜을 지원해야합니다. 멀티미디어 콘텐츠의 HTTP 스트리밍 표준은 표준 기반 클라이언트가 모든 표준 기반 서버의 콘텐츠를 스트리밍 할 수있게 하여 다른 공급 업체의 서버 및 클라이언트를 일관되게 재생하고 통합 할 수 있도록합니다.
MPEG 는 흩어져있는 풍경에 대한 응답으로 2009 년 4 월에 HTTP 스트리밍 표준 제안서를 발행했습니다. 그 후 2 년 동안 MPEG는 많은 전문가의 참여와 제 3의 세대 파트너십 프로젝트 (3GPP). Microsoft, Netflix 및 Adobe가 포함 된 50 개 이상의 회사가 참여했으며 스튜디오 백업 디지털 보관함 개시자인 Digital Entertainment Content Ecosystem, LLC (DECE), OIPF 및 World Wide Web Consortium과 같은 다른 업계 조직과 협력했습니다 W3C). 이로 인해 MPEG-DASH 표준이 개발되었습니다.
Q. 각 프로토콜은 서로 다른 메서드 및 포맷을 사용하므로 각 서버에서 컨텐츠를 수신하려면 디바이스가 각 프로토콜을 지원해야한다 => 안드로이드와 아이폰은 어떤 스트리밍 프로토콜은 지원하지?
[안드로이드에서 지원하는 스트리밍 프로토콜 ]
[IOS에서 지원하는 스트리밍 프로토콜 ]
=> HLS
=> RTSP 도 사용가능 ? (https://forums.developer.apple.com/thread/71303)
. RTSP를 지원하는 오픈 소스 ffmpeg 라이브러리의 iOS 빌드를 사용하여 RTSP 패킷을 수신하고 디코드하고 프레임에서 UIImages를 생성 한 다음 해당 프레임을 표시 할 수있는 테스트 응용 프로그램을 마련했습니다. 화면. 이것은 조잡한 플레이어를 제공하지만 성능은 좋지 않습니다. ffmpeg가 하드웨어 가속을 이용할 수 없기 때문입니다. 또한 비디오 스트림을 AVFoundation에 통합하는 방법을 제공하지 않기 때문에 스트림을 파일에 저장하고 코드를 변환하는 등의 방법으로 직접 작업 할 수 있습니다.
-------------------------------------------------------------------------------------------------
4. HLS/DASH vs RTMP/RTSP 차이점은?(RTMP/RTSP는 chunk 파일이 있는지 등)
HLS/DASH는 클라의 네트워크 대역폭에 따라 그에 맞는 화질의 세그먼트를 일정간격으로 나누어 클라에게 보내주는 적응형 비트레이트 라이브 스트리밍
RTMP는 low latency를 달성하기 위해 만들어진 실시간 라이브 스트리밍
RTSP는 화상채팅, 회의 등 latency가 아주 짧아서 동시에 커뮤니케이션을 하듯이 사용하는 것을 목적으로 만들어진 프로토콜
Q. RTSP가 제일 빠른 이유(WebRTC 제외)?
Q-1. RTMP가 그 다음으로 빠른 이유
Q-2. DASH
Q-3. HLS
RTSP 및 RTP는 스트리밍 RTSP / RTP 서버와 플레이어 클라이언트 간의 스트리밍 세션을 만드는 여러 측면을 정의하는 인터넷 프로토콜 사양입니다. 작동중인 다른 미디어 스트리밍 프로토콜이 있습니다. 예를 들어 새로운 HTML5 표준이 등장한 다양한 스트리밍 방식이 있습니다. 여기서 RTSP 및 RTP 만 처리합니다.
RTSP (Real Time Streaming Protocol)는 인터넷 표준 초안 RFC 2326에 정의되어 있습니다. RTSP라는 이름에도 불구하고 실제로 비디오 및 오디오와 같은 미디어는 전송하지 않습니다. RTSP는 미디어 전송의 실제 작업을 수행하는 RTP를위한 보조 프로토콜입니다. RTSP는 RTP 스트리밍 세션 제어를위한 모든 측면을 다룹니다. 플레이어는 스트리밍 서버의 RTSP 연결 처리기에 연결하고 RTSP 요청을 서버와 교환합니다. 이러한 요청과 응답은 RFC 2326에 정의되어 있습니다. 예를 들어 RTSP 요청은
클라이언트가 재생할 스트림을 선택하고,
스트림 (코덱) 및 전송 방법 (예 : UDP 또는 TCP 기반)의 형식을 쿼리합니다.
스트리밍 세션 시작 및 중지
RTSP / RTP 서버는 클라이언트가 RTSP PLAY 요청을 보낼 때 클라이언트로부터의 일부 요청 후에 스트림을 시작합니다. 클라이언트에서 RTSP 요청을 처리하려면 스트리밍 서버가 클라이언트 메시지를 해석하는 RTSP 파서를 구현해야합니다. 간소화 된 RTSP 파서는 스 트리머 구현의 유닛 "RTSPSession.cpp"에 구현됩니다.
여기서 RTSP 요청 / 응답 통신에 대해 자세히 설명하지 않겠습니다. 인터넷과 RFC 2326은 파서 모듈을 구현하기위한 많은 함정과 함정을 제공합니다.
------------------------------------------------------------------------------------------
실시간 스트리밍 프로토콜 (Real Time Streaming Protocol, RTSP) [4]은
실시간 속성을 가진 데이터. RTSP는 주문형 제어가 가능한 확장 가능한 프레임 워크를 제공합니다.
오디오 및 비디오와 같은 실시간 데이터 제공
데이터 원본에는 라이브 데이터 피드와 저장된 클립이 모두 포함될 수 있습니다. 이 프로토콜은 다중
데이터 전달 세션, UDP, 멀티 캐스트 UDP 및 TCP와 같은 전달 채널을 선택하는 수단 제공,
RTP 기반의 전달 메커니즘을 선택하는 수단을 제공합니다.
RTSP는 클라이언트와 서버 간의 텍스트 메시지 교환으로 구성됩니다. 클라이언트는 요청 메시지를 보내고 서버는 각 요청에 응답합니다 (
HTTP).
이 프로토콜은 클라이언트가 서버에 보낼 수있는 메소드 (명령) 세트를 정의합니다. 각 방법에는 여러 가지가 있습니다.
추가 정보를 전달하기위한 필드. 가장 중요한 방법은 DESCRIBE, SETUP,
PLAY, PAUSE 및 TEARDOWN.
DESCRIBE 메서드는 서버에서 재생할 미디어 세션에 대한 초기화 정보를 검색하기위한 메서드입니다. 이 정보는
SDP 설명으로 저장되며 세션에 대한 전역 정보 (작성자, URL, 대역폭 정보, 타이밍, 암호화 정보에 대한 정보 포함) 및 개별 미디어 스트림 (번호, 유형, 연결 및 전송 정보, 기타 정보).
세션 초기화 정보를 수신 한 후, 클라이언트는 각각의 미디어 스트림을 요청할 수있다
미디어 세션을 작성하십시오. 예를 들어, 클라이언트가 영화를 재생하기를 원할 경우, 영화는 일반적으로
2 개의 스트림, 오디오 스트림 및 비디오 스트림으로 구성된다.
개별 미디어 스트림 요청은 SETUP 메서드로 수행됩니다. 가장 중요한 정보 필드는 정보가 들어있는 전송 필드입니다.
=> Requesting individual media streams is performed with
the SETUP method.
The most important information
field is the Transport field that contains information
about the data transport possibilities of the client.
개별미디어 스트림을 요청하는 것은 SETUP메소드에 따라 수행된다
가장 중요한 정보 filed 는 클라의 데이터 전송 가능성에 대한 정보를 포함하는 전송 filed이다.
The
answer from the server also contains a Transport field
that actually chooses one of the transport methods
proposed by the client.
클라이언트의 데이터 전송 가능성에 대해 서버의 응답에는 전송 필드도 포함됩니다
실제로 클라이언트가 제안한 전송 방법 중 하나를 선택합니다.
위의 예에서 클라이언트는 미디어 URL을 요청하고 서버에 두 가지 데이터 방법을 알립니다.
수송. 첫 번째 방법은 RTP 프로토콜 인 오디오 - 비디오 프로파일을 사용하여 데이터를 멀티 캐스팅하는 것입니다. 그만큼
두 번째 방법은 서버가 클라이언트의 3456 UDP 포트에 RTP 패킷을 보내는 유니 캐스트 스트리밍입니다 (3457
포트는 RTCP 사용을위한 것임). 서버의 응답에서 우리는 두 번째 방법을 선택했다는 것을 알았고 두 번째 방법도 선택했습니다.
포트 정보 (RTCP에 유용함).
미디어 데이터 스트림이 설정되면 클라이언트는 PLAY 명령을 서버에 보내야
서버가 데이터 보내기를 시작합니다. 추가 필드는 재생 위치 및 속도를 지정할 수 있습니다.
PAUSE 메소드는 스트림 전송을 인터럽트합니다.
클라이언트가 미디어 세션을 종료하기를 원하면 TEARDOWN 명령을
세션. 개별 미디어 스트림은 또한 진술 될 수 있습니다.
실시간 프로토콜 (RTP)은 애플리케이션에 적합한 종단 간 네트워크 전송 기능을 제공합니다.
멀티 캐스트 또는 유니 캐스트 네트워크 서비스를 통해 오디오, 비디오 또는 시뮬레이션 데이터와 같은 실시간 데이터를 전송합니다. RTP는 리소스 예약을 처리하지 않으며 실시간으로 서비스 품질을 보장하지 않습니다.
서비스. 데이터 전송은 데이터 전달을 모니터링 할 수 있도록 제어 프로토콜 (RTCP)에 의해 보강됩니다.
대형 멀티 캐스트 네트워크에 확장 가능한 방식으로, 최소한의 제어 및 식별 기능을 제공합니다.
RTP 및 RTCP는 기본 전송 및 네트워크 계층과 독립적으로 설계되었습니다. => 계층구조 다시 확인 필요
RTP를 통해 전송 된 데이터는 UDP 케이스와 마찬가지로 조각화되어 패킷으로 전송됩니다. RTP는 또한 헤더를 패킷에 추가합니다. RTP 헤더에는 몇 가지 추가 정보를 지정하는 여러 필드가 있습니다. 제일 중요한 분야는
•페이 로드 유형–데이터 유형 지정
RTP패킷이 운반됩니다. 다른 데이터의 경우
정의된 RTP프로필이 있는 유형은 다음과 같습니다.
에서 수행되는 추가 정보
RTP패킷, 확장 필드(헤더)
확장).
•시퀀스 번호–지정
수신기가 식별할 수 있도록 RTP패킷
패킷 순서 및 패킷 손실:
잃어버린 패킷을 세면서.
•타임 스탬프–타이밍 정보 제공
해독을 위해 수신기에 필요한
또는 프로세스를 표시합니다.
RTP프로필을 정의하는 RFC표준도 있습니다.
전달할 미디어 유형
RTP.
RTMP 프로토콜이 서버에 어떻게 요청하는지?
http 프로토콜의 장점 - 캐시서버를 둘 수 있다. cdn 사용
----------------------------------------------------------------------
mcu방식
믹싱을해야한다. -> 디코딩및 재인코딩이 필요하기떄문에 추가지원과 품질 손실이 발생한다.
트랜스 코딩의 컴포지션은 응용프로그램의 ui/ux의 유연성을 떨어트린다.
webrtc
->세션연결
rtsp
서버와 클라이언트 기반
webrtc
p2p통신을 고려한 ice기반 프로토콜
----------------------------------------------------------------------
WebRTC, RTSP, RTMP latency 차이가 각 0.5초~1초 차이인데 내 앱에서 그 정도로 크리티컬한 부분인가?
=> latency만 보면 별차이 없을수도 있지만 방송 시간을 5분이상으로 하거나 RTMP에 연결되어 있는 사용자의 숫자가 많아질수록 latency가 더 길어질 수 있다 => 확인, 근거필요
