예를 들어 HTML 페이지 내부에서 미디어 스트리밍

그래서 저는 스트리밍 미디어의 작동 방식에 대한 약간의 세부 사항을 이해하려고하는 소프트웨어 엔지니어입니다. 나는 내 응용 프로그램과 관련된 다양한 코덱, 컨테이너 형식 및 스트리밍 프로토콜을 이해하려고 노력했습니다. 지금까지, 그것이 어떻게 작동하는지에 대한 나의 이해 가 있습니다.

• 스트리밍 미디어는 실제로 컨테이너 형식 과 스트리밍 프로토콜 로 요약됩니다 .
  • 모든 오디오 데이터는 오디오 코덱을 통해 오디오 비트 스트림으로 인코딩됩니다.
  • 모든 비디오 데이터는 (다시 코덱을 통해) 비디오 비트 스트림으로 인코딩됩니다.
  • 두 개의 스트림은 컨테이너 로 병합 ( 멀티플렉싱? )되어 결국 파일 (MP4 등)이됩니다.
  • 그런 다음 특수 미디어 서버 는 RTSP와 같은 일부 표준 스트리밍 프로토콜을 통해이 컨테이너 (MP4 파일 또는 기타 형식)를 클라이언트 (아마도 누군가의 브라우저에서 실행되는 HTML5 비디오 플레이어)에 제공합니다.
    • 브라우저 클라이언트의 경우 브라우저 자체에 RTSP 클라이언트가 있다고 가정하고 사용자에게 HTML5 비디오 플레이어를 표시합니다
• 내가 할 수 에서 MP4 파일을 호스팅 웹 등의 nginx 또는 아파치와 같은 서버, 그러나 그 서버는 RTSP 서버가 아니기 때문에, 전용으로 MP4에 대한 치료 요청을 수있을 것 다운로드 요청 , 따라서 스트리밍 할 수없는 것 미디어 파일
  • 마찬가지로 curlnginx 서버에서 파일을 가져 오는 데 사용한다면 curlnginx도 RTSP를 사용 하지 않기 때문에 파일 다운로드로 취급됩니다.
• 하지만이 스트리밍 미디어 서버 (가 VideoLAN, Red5의, Wowza 등)에서 MP4 파일을 호스팅 할 때, 나는 RTSP 클라이언트를 사용 (또는 지원되는 스트리밍 미디어 클라이언트), 해당 서버에서 스트림을 요청하기 위해 그 다음 만 그런 다음 실제 스트리밍이 발생 합니까
  • 따라서 YouTube 또는 Vimeo "동영상"이 HTTP 서버에 의해 HTTP (S)를 통해 제공되는 HTML 페이지에서 호스팅 되더라도 해당 동영상 (실제로 동영상이 재생되는 위치)의 내장 동영상 플레이어 가 실제로 두 번째로 시작 한다고 가정합니다. , 후속 스트리밍 서버 연결 및 RTSP 또는 다른 비 HTTP 프로토콜을 통해 스트리밍이 발생합니다.

그래서 그것은 나의 이해이며, 내가 위에서 언급 한 것이 틀렸다면 먼저 정정하여 시작하십시오. 내가 다소 정확하다고 가정하면 :

HTML 페이지 내에서 실행되고 HTML 서버에서 제공되는 스트리밍 미디어 플레이어는 어떻게 스트리밍 미디어 서버 (RTSP 요청 제공)와 스트리밍 (RTSP 등) 연결을 설정합니까?

HTML 페이지 내에서 실행되고 HTML 서버에서 제공되는 스트리밍 미디어 플레이어는 어떻게 스트리밍 미디어 서버 (RTSP 요청 제공)와 스트리밍 (RTSP 등) 연결을 설정합니까?

일반적인 응용

RTSP는 현재 HTTP 웹 재생 인터페이스를 통해 물리적 위치에서 저장된 미디어 파일 을 스트리밍 하기위한 것보다 직접 라이브 스트림 (예 : IP 카메라) 또는 리 스트리밍 (예 : 엔진)하는 응용 프로그램 / 장치 인터페이스에서 더 많이 사용되는 것으로 보입니다 . 내장 플레이어.

것으로 보인다 RTSP는 A는 상태 기반 프로토콜 및 스트리밍 할 때 더 TCP보다는 UDP를 사용하고, 더 (의 IP 카메라와 같은) 서버 장치로 TCP / IP 네트워크에 연결되어 사용되는, 그리고 피드 UDP 등을 통해 스트림에서 그런 다음 동일한 네트워크에서 클라이언트로 이러한 피드 (서버)에 연결하면 RTSP 요청 을 발행 하여 적절하게 활용할 수 있습니다 .

^{프로토콜 지시어}

^{RTSP는 HTTP와 몇 가지면에서 비슷하지만 멀티미디어 재생을 제어하는 ​​데 유용한 제어 순서를 정의합니다. HTTP는 stateless 이지만 RTSP는 state입니다. 동시 세션을 추적하는 데 필요할 때 식별자가 사용됩니다. HTTP와 마찬가지로 RTSP는 TCP를 사용하여 종단 간 연결을 유지하며 대부분의 RTSP 제어 메시지는 클라이언트에서 서버로 전송되지만 일부 명령은 다른 방향 (예 : 서버에서 클라이언트로)으로 이동합니다.}

^{여기에는 기본 RTSP 요청이 나와 있습니다. OPTIONS 요청과 같은 일부 일반적인 HTTP 요청도 사용할 수 있습니다. 기본 전송 계층 포트 번호는 TCP 및 UDP 모두에 대해 554 [3]이며 후자는 제어 요청에 거의 사용되지 않습니다.}

^_출처

^무국적

^{상태 비 저장 프로토콜은 서버가 여러 요청 기간 동안 각 통신 파트너에 대한 세션 정보 또는 상태를 유지하도록 요구하지 않습니다. 반대로 서버에서 내부 상태를 유지해야하는 프로토콜을 상태 저장 프로토콜 이라고 합니다.}

^{상태 비 저장의 단점은 모든 요청에 ​​추가 정보를 포함해야 할 수 있으며이 추가 정보는 서버에서 해석해야한다는 것입니다.}

^_출처

논리 흐름

이 형식의 스트리밍 미디어 흐름을 이해하는 방법은 다음과 같습니다.

• 미디어 컨텐츠가 상주하는 서버는 비디오 / 오디오 데이터 컨텐츠를 스트림 전달을위한 적절한 형식 및 세그먼트로 캡슐화, 압축, 인코딩 등을합니다.
• 스트리밍 미디어에 액세스하기 위해 연결을 수신하는 웹 서버는 미디어를 스트리밍하는 데 필요한 모든 리소스를 제공합니다.
• 클라이언트는 적용 가능한 리소스와 파일을 요청 및 다운로드 한 다음 구성된대로 다른 매개 변수와 URL 포인터를 통해 재생할 수 있도록 연속적인 방식으로 어셈블합니다. 클라이언트 레벨의 재생 소프트웨어는 콘텐츠의 적절한 재생을 허용하기 위해 순서대로 전송 된 패킷을 조립합니다.

HTTP와 RTSP의 일반적인 비교에 대해서는 아래 의 스트리밍 기술 섹션을 참조하십시오 .

더욱이

아래의 10 가지 이유에서 자신의 비디오를 호스팅해서는 안되는 부분 섹션에서 "일반적인"질문에 답변하는 데 도움이되는 부분을 인용했습니다.

기본적으로 임베디드 미디어 플레이어 컨트롤이있는 웹 사이트는 다음을 수행합니다.

• ⁽¹⁾ 클라이언트의 "연결 및 요청"시 클라이언트 웹 브라우저 설정을 감지하고
• ⁽²⁾ 코덱 및 기타 클라이언트 측 탐지 설정을 적용 가능한 매개 변수 값으로 설정 한 다음
• ⁽³⁾ 호스팅 된 서버에서 미디어 파일의 URL을 가리키는 내장 미디어 플레이어 구성의 추가 코드 를 기반으로 비디오 및 오디오 파일을 호스팅하는 스트리밍 서버에서 직접 비디오를 스트리밍 합니다.

^{스트리밍 기술}

^{클라이언트 브라우저는 서버에서 데이터를 수신하여 처리를 위해 스트리밍 애플리케이션으로 전달해야합니다. 스트리밍 응용 프로그램은 데이터를 그림과 사운드로 변환합니다. 이 프로세스의 성공에 중요한 요소는 클라이언트가 응용 프로그램이 정보를 표시 할 수있는 데이터를 더 빨리받을 수있는 능력입니다. 초과 데이터는 버퍼에 저장됩니다. 응용 프로그램 내의 데이터 저장을 위해 예약 된 메모리 영역입니다. 두 시스템간에 데이터 전송이 지연되면 버퍼가 비워지고 재료가 부드럽게 표시되지 않습니다.}

^{HTTP 프로토콜}

^{HTTP는 문서가 인터넷에서 연결되는 주요 방법입니다. 클라이언트는 스트리밍 할 파일이 포함 된 서버에 연결하고 파일을 검색 한 후 연결을 닫습니다. HTTP 서버는 전송할 파일 유형을 브라우저와 통신합니다.}

^{HTTP를 사용하는 이점}

^{HTTP를 사용하여 파일을 스트리밍 할 때는 특별한 스트리밍 서버가 필요하지 않습니다. 브라우저가 MIME 유형을 이해하는 한 HTTP 서버에서 스트리밍 파일을 수신 할 수 있습니다. HTTP를 사용하여 파일을 스트리밍 할 때의 장점 중 하나는 방화벽을 통과하고 프록시 서버를 활용할 수 있다는 것입니다.}

^{몇 가지 단점}

^{HTTP 스트리밍은 TCP / IP (전송 제어 프로토콜 및 인터넷 프로토콜)를 사용하여 파일을 안정적으로 전달합니다. 이 프로세스는 누락 된 패킷을 확인하고 다시 전송하도록 요청합니다. 전송시 데이터가 손실 될 경우 데이터를 무시하고 싶을 때 스트리밍 시나리오에서 문제가되므로 동적 파일이 계속 재생됩니다. HTTP는 모뎀 속도를 감지 할 수 없으므로 서버 관리자는 연결 유형이 다른 서버 사용자에게 다른 압축률로 파일을 의도적으로 생성해야합니다. 수요가 많은 상황에서는 HTTP 서버에서 파일을 스트리밍하지 않는 것이 좋습니다.}

^{RTSP 프로토콜}

^{RTSP는 대부분의 스트리밍 서버 공급 업체에서 사용하는 표준 프로토콜입니다. RTSP 서버는 UDP (User Datagram Protocol)를 사용하여 미디어 파일을 전송합니다. UDP는 파일이 대상에 도착했는지 지속적으로 확인하지 않습니다. 지연 시간이 너무 길지 않으면 파일 전송이 중단 될 수 있으므로 스트리밍 응용 프로그램에 유리합니다. 이 방법의 결과는 때때로 데이터 손실이 발생하지만 지연 시간이 작 으면 파일이 계속 재생됩니다.}

^출처

^{자신의 비디오를 호스팅해서는 안되는 10 가지 이유}

^{임베딩 및 자체 호스팅 비디오에 대해 이야기하고 있습니다.}

^{먼저 YouTube, Vimeo 또는 Wistia와 같은 타사 비디오 호스팅 서비스에 비디오 파일을 업로드합니다.}

^{그런 다음 그들이 제공 한 작은 코드를 복사하여 자신의 WordPress 사이트의 게시물이나 페이지에 붙여 넣습니다. 비디오는 포함 코드를 붙여 넣은 위치에 사이트에 나타나지만 WordPress 사이트가 호스팅되는 자체 웹 서버와 달리 비디오 자체가 비디오 호스트 서버에서 스트리밍됩니다.}

^{4. 웹 비디오를위한 단일 파일 형식 표준 없음}

^{현재 HTML5 초안 사양은 브라우저가 지원해야하는 비디오 형식을 지정하지 않습니다. 결과적으로, 주요 웹 브라우저는 각각 다른 형식을 지원하도록 분기되었습니다. Internet Explorer 및 Safari는 H.264 (MP4) 비디오를 재생하지만 WebM 또는 Ogg는 재생하지 않습니다. Firefox는 Ogg 또는 WebM 비디오를 재생하지만 H.264는 재생하지 않습니다. 고맙게도 Chrome은 모든 주요 동영상 형식을 재생하지만 모든 주요 웹 브라우저에서 동영상을 재생하려면 동영상을 .mp4, .ogv 및 .webm의 여러 형식으로 변환해야합니다.}

^{5. 비디오 변환이 마음에 드시기 바랍니다. 많이.}

^{대부분의 청중은 고속 인터넷 연결의 이점으로 데스크탑 또는 랩톱에서 비디오를 볼 수 있습니다. 그런 사람들을 위해 큰 HD 품질의 파일을 제공하여 원하는 경우 전체 화면으로 볼 수 있습니다. 일반적으로 이는 높은 스트리밍 비트 전송률 (5000 – 8000kbps)에서 1080p 또는 720p 파일을 의미합니다.}

^{그러나 인터넷 연결 속도가 느린 시청자에게 제공 할뿐만 아니라 휴대 전화 및 태블릿과 같은 휴대 기기로 전송하기 위해 더 작은 저해상도 버전을 인코딩하고 싶을 것입니다.}

^{6. 비디오 플레이어}

^{비디오 플레이어는 사이트에 설치하는 작은 웹 소프트웨어로, 연결 속도와 함께 비디오를 요청하는 장치를 자동으로 감지 한 다음 해당 사용자에게 적절한 버전을 제공합니다.}

^{7. 번거로운 코드 또는 단축 코드}

^{타사 플러그인을 사용하든 WordPress에 내장 된 비디오 기능을 사용하든 비디오 플레이어가 생성 한 형식과 서버에서의 위치를 ​​알려주는 약간의 코드를 작성해야합니다. 이렇게 생겼어요…}

<video poster="movie.jpg" controls>
<source src="movie.webm" type='video/webm; codecs="vp8.0, vorbis"'/>
<source src="movie.ogg" type='video/ogg; codecs="theora, vorbis"'/>
<source src="movie.mp4" type='video/mp4; codecs="avc1.4D401E, mp4a.40.2"'/>
<p>This is fallback content</p>
</video>

그렇다면 사이트에 비디오를 추가하는 가장 좋은 방법은 무엇입니까?

타사 비디오 호스팅 서비스를 사용한 다음 비디오를 WordPress 게시물 또는 페이지에 포함시키기 만하면됩니다.

1 단계 : Vimeo PRO와 같이 널리 알려진 널리 알려진 비디오 호스팅 서비스 중 하나에 비디오를 업로드하십시오.

2 단계 : 동영상을 업로드하고 볼 준비가되면 URL을 동영상에 복사합니다. WordPress 사이트로 돌아와서 비디오를 표시 할 게시물이나 페이지에 URL을 붙여 넣습니다.

---

^{사람들이 내 페이지를 볼 때 URL을 붙여 넣은 위치에 비디오가 나타납니다. 그러나 비디오 파일 자체는 WordPress 사이트가 호스팅되는 자체 서버와 달리 비디오 호스트 서버에서 스트리밍됩니다.}

_{내장 비디오 플레이어는 사용자의 장치, 브라우저 및 인터넷 연결 속도를 자동으로 감지 한 다음 적절한 버전의 비디오 파일을 제공합니다. 사이트에 설치할 것이 없습니다. 최신 플러그인은 없습니다. 까다로운 코드가 없습니다.}

_출처

나는 주로 비디오가 브라우저에 표시 될 때 어떻게되는지에 대한 귀하의 질문을 아래에서 처리 할 것입니다. 주제는 방대하므로 관련 항목 만 다룰 것입니다.

HTML5는 <VIDEO>JavaScript와 CSS를 사용하는 동안 표시된 비디오를 브라우저에 통합하는 문제를 해결 하는 태그를 도입했습니다 . 이전 <OBJECT>태그에는 외부 소프트웨어가 필요했으며 페이지와 잘못 통합되었습니다. 새로운 태그는 사실상 표준이 없었음에도 불구하고 브라우저도 비디오 플레이어가되어야했습니다. 그 결과 표준의 전체 조각화가 이루어졌으며, 유일한 해결책은 비디오 서버가 여러 비디오 형식을 사용할 수있게하고이 모든 대체 소스를 <VIDEO>태그에 지정 하면 브라우저가 지원하는 형식을 선택할 수 있다는 것입니다.

여러 소스가있는 태그의 예 :

<video width=320 height=240 controls poster=image.jpg>
   <source src="movie.mpd">
   <source src="movie.webm">
   Your browser does not support the video tag.
</video>

<VIDEO>태그 자체는 프로토콜에 독립적이기 때문에, RTSP를 포함하여 브라우저가 지원하는 모든 프로토콜을 사용할 수 있습니다. 지원 MPEG-DASH 프로토콜 은 대부분의 장치와 기본 브라우저, 또는 여분의 플러그인이 필요하지 않습니다 의미 사용하여 HTML5에 재생할 수 있도록 (HTTP를 통한 동적 적응 스트리밍)는 최근, 매우 포괄적되었다. 이 장치 및 브라우저 호환성 차트를 참조하십시오 . MPEG-DASH 서비스를 위해 서버를 준비하려면 이 Mozilla 기사 를 참조하십시오 . DASH는 HTTP를 통해 작동하므로 HTTP 서버가 바이트 범위 요청을 지원하고 .mpd 파일을 제공하도록 설정되어 있으면 작동합니다 mimetype="application/dash+xml".

클라이언트와 서버 간의 정상적인 상호 작용은 다음과 유사합니다. HTML5 비디오의 경우 브라우저는 플레이어이기도하지만 재생을 위해 새 연결을 열 수도 있습니다.

초기 연결은 클라이언트가 비디오를 표시하는 데 사용하는 메타 데이터를 제공합니다. RTSP 프로토콜을 사용하여 해당 메타 데이터를 얻는 경우 나중에 비디오 + 오디오 데이터를 전송하기 위해 RTP 연결이 생성됩니다. RTCP 프로토콜은 추가 명령을 서버로 전송하는 데 사용됩니다.

RTP, RTCP 및 RTSP는 모두 다른 포트에서 작동합니다. 일반적으로 RTP가 포트 N에 있으면 RTCP는 포트 N + 1에 있습니다. RTP 세션은 수신기의 끝에 결합 될 다수의 스트림을 포함 할 수있다; 예를 들어, 오디오 및 비디오는 별도의 채널에있을 수 있습니다.

귀하의 콘텐츠에 아무도 갇히지 않도록 로열티가없는 코덱, webM 또는 Theora 및 H.264 비디오와 Vorbis 및 MP3 오디오를 모두 사용할 수 있도록해야합니다. (쉽게 말하기 어렵다.)

이것이 RTSP에 대해 자세히 발생하는 것입니다.

1. 클라이언트는 서버, 일반적으로 RTSP의 잘 알려진 포트 인 TCP 포트 554에서 TCP 연결을 설정합니다.

2. 그런 다음 클라이언트는 HTTP와 유사한 형식의 일련의 RTSP 헤더 명령을 발행합니다. 각 명령은 서버에서 승인합니다. 이 RTSP 명령 내에서 클라이언트는 지원하는 RTSP 버전, 데이터 흐름에 사용되는 전송 및 관련 UDP 또는 TCP 포트 정보와 같은 세션 요구 사항에 대한 서버 세부 정보를 서버에 설명합니다. 이 정보는 DESCRIBE 및 SETUP 헤더를 사용하여 전달되며 클라이언트 및 임시 프록시 장치가 추가 교환에서 스트림을 식별하는 데 사용할 수있는 세션 ID로 서버 응답에서 기능이 보강됩니다.

3. 전송 매개 변수 협상이 완료되면 클라이언트는 PLAY 명령을 실행하여 서버에 RTP 데이터 스트림의 전달을 시작하도록 지시합니다.

4. 클라이언트가 스트림을 닫기로 결정하면 세션 ID와 함께 TEARDOWN 명령이 실행되어 서버에 해당 ID와 연관된 RTP 전달을 중지하도록 지시합니다.

추가 자료 :

• 스트리밍 프로토콜의 기초
• 응용 프로그램 계층 프로토콜 이해-실시간 스트리밍 프로토콜 (RTSP)
• HTML5 비디오 소개 (오페라)
• HTML5 오디오 및 비디오 : 알아야 할 사항
• RTSP 분석 Wireshark

여기에 빠르고 더러운 답변이 있습니다.

웹에서 비디오를 재생하는 것과 실제로 실시간으로 스트리밍하는 것에는 차이가 있습니다.

웹 페이지에 포함 된 플레이어 (플래시, JS 또는 html5 비디오 객체를 사용할 수 있음)를 사용하여 재생합니다. 클라이언트 (브라우저)가이 플레이어를 다운로드하여 실행합니다. 플레이어는 간단한 다운로드 URL에서 비디오를 가져옵니다. 실제로 Youtube에서도 호스팅 된 비디오 파일에 직접 액세스하여 다른 파일처럼 다운로드 할 수있는 프로그램이 있습니다. 시스템은 기존의 기존 다운로드 링크를 사용하므로 RTSP와 같은 복잡한 스트리밍 프로토콜이 필요하지 않습니다.

실시간 스트리밍 (예 : 웹캠에서)은 더 까다 롭습니다. Flash에는이 기능이 내장되어 있지만 더 이상 사용해서는 안됩니다. HTML5 비디오는 실시간 스트리밍을 지원하지 않지만 사람들은 파일 호스팅 서버가 지속적으로 제공하는 비디오 파일을 변경하도록하여 "트릭"할 수있었습니다.