프로그레시브 HTTP 다운로드는 라이브 비디오를 제공하기 위해 HLS / DASH / RTMP의 대안이 될 수 있습니까?

라이브 비디오를 사용자에게 스트리밍해야하는 웹 사이트에서 작업 중이므로 현재 브라우저 기반 비디오 스트리밍 기술의 미안한 상태를 둘러 봐야했습니다. 현재 라이브 스트리밍에 가장 많이 사용되는 솔루션에는 호환성 문제가 있습니다. RTMP에는 Flash가 필요하고 HLS는 Safari 및 Android 용 Chrome에서만 기본적으로 지원되며 DASH 는 기본적으로 어디서나 지원 되지 않으며 dash.js를 사용 하려면 아직 널리 지원되지 않는 Media Source Extensions 가 필요합니다 .

이것은 나에게 명백한 질문으로 이어진다 : 브라우저 지원이나 플러그인이 필요한 HLS, RTMP 및 DASH와 같은 프로토콜의 대안으로 간단한 점진적 다운로드 를 사용할 수 있습니까?

라이브 미디어를 스트리밍하기 위해 점진적 다운로드를 사용한다는 아이디어는 전례가 없습니다. 사람들은 이미 오디오를 위해 그것을합니다. liveCaster 와 같은 도구를 사용하면 사전 녹음 된 MP3 파일없이 단일 점진적 HTTP 응답을 통해 라이브 MP3 오디오를 스트리밍 할 수 있으며 AmplitudeJS와 같은 라이브러리는 이러한 종류의 라이브 오디오 스트리밍과 관련된 기능을 추가하지 못했습니다 .

그러나이 기술의 어떤 사례도 비디오 용으로 야생에서 사용되는 것을 보지 못했지만 그 이유를 알 수 없습니다. 비교적 적은 양의 트레이드 오프를 위해 복잡하고 어려운 브라우저 측 호환성 문제 계층을 제거하는 것처럼 보입니다. (그리고 호환성은 여전히 프로 스트리밍을 할 때조차도 라이브 스트리밍에서 큰 문제입니다. Firefox에서 BBC의 iPlayer에서 라이브 비디오를 보려고하면 Flash를 설치하라는 오류 메시지가 표시됩니다.) 이 테크닉은 아무도 저 외에 다른 아이디어를 언급 한 적이 없습니다 .

왜? MP4와 같은 비디오 파일을 점진적 다운로드가 생성되는 동안 점진적 다운로드를 통해 스트리밍하고 다운로드 할 때 <video>요소로 재생하는 것이 불가능하다는 근본적인 한계가 있습니까?

귀하의 질문은 유효하며 이론적 으로 라이브 비디오 스트리밍에 프로그레시브 다운로드 를 사용할 수 있다고 생각합니다 . 실제로 YouTube와 같은 많은 온라인 스트리밍 비디오는 이미 HTTP를 사용합니다. 스트리밍이 아닌 라이브 스트리밍 에 대해 엄격하게 이야기하고 있다고 가정합니다 .

그래도 라이브 스트리밍 사용 사례를 직접 구현해야합니다! 그렇지 않으면 스트리밍 프로토콜 (RTMP 등) 자체가 수행됩니다. 이러한 프로토콜과 아키텍처를 선호하는 몇 가지 이유는 다음과 같습니다.

1. 가변 비트 레이트

대부분의 라이브 스트리밍 비디오는 VBR로 인코딩되며 비디오는 클라이언트의 네트워크 혼잡 변화에 빠르게 적응해야합니다. 따라서 클라이언트 연결 속도에 따라 비디오가 짧은 시간에 여러 해상도로 전환 될 수 있습니다.

Wikipedia에 따르면

실시간으로 사용자의 대역폭과 CPU 용량을 감지하고 그에 따라 비디오 스트림의 품질을 조정하여 작동합니다

2. 라이브 컨텐츠

가장 중요한 점은 라이브 스트리밍은 라이브 컨텐츠를 의미한다는 것 입니다. HTTP Progressive Download와 달리 언제든지 버퍼링 할 수 없습니다. 사용자 는 전 세계를 대상으로 한 최신 프레임을보고 뒤쳐 질 수 없습니다.

3. 찾기 비활성화

사소한 문제이지만, 프로토콜은 구체적으로 사용자가 뒤로 (그리고 분명히 앞으로) 찾을 수 없도록해야합니다. 비디오 플레이어 수준뿐만 아니라 네트워크 수준에서도 제어해야합니다.

4. 빈번한 연결 끊기 / 신뢰할 수없는 네트워크

나는이 점에 대해 조금 불분명하지만 들어오는 HTTP 다운로드가 연결 해제되면 다른 핸드 셰이크를 설정하는 데 시간이 걸릴 수 있음을 알고 있습니다 keep-alive. 실시간 프로토콜은 다음 지점으로 인해 연결 및 연결 해제가 훨씬 빠릅니다.->

5. 지연

HTTP는 본질적으로 TCP 를 통해 실행되므로 패킷 전달이 보장됩니다. 속도가 보장보다 우선 순위가 높은 많은 프로토콜 (특히 라이브 멀티 플레이어 게임)에서 사용되는 UDP 와 이것을 비교하십시오 .

자세한 내용은 여기를 참조하십시오-> https://en.wikipedia.org/wiki/Streaming_media#Protocols

6. 컨텐츠 복사

대부분의 라이브 스트림 서버는 현재 시간의 내용에만 응답합니다. 라이브 스트림의 콘텐츠를 여전히 복사 할 수는 있지만 화면 캡처 등을 사용해야합니다. HTTP 점진적 다운로드를 제공하면 콘텐츠를 복사하는 작업이 매우 간단 해집니다 (따라서 많은 YouTube 다운로더가 있습니다).

이제 HTTP를 모델링 하여 위의 대부분을 제공 할 수 있습니다 .

언급 한 Apple의 HTTP 라이브 스트리밍 (HLS) 은 달성하려는 목표에 가장 가깝습니다.

그리고이 분야에서 진행중인 연구가 여기에 있습니다-> http://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=65749&PageNum=2

더 많은 정보를 찾고 있으며이 답변을 업데이트 할 것입니다.