Przesyłanie strumieniowe multimediów ze stron HTML, według przykładów

Więc jestem inżynierem oprogramowania, który próbuje zrozumieć pewne drobiazgowe szczegóły na temat działania mediów strumieniowych. Lwia część dnia poświęciła na zrozumienie różnych kodeków, formatów kontenerów i protokołów transmisji strumieniowych związanych z moją aplikacją. Jak dotąd rozumiem, jak to działa, co bardzo dobrze można wprowadzić w błąd:

• Strumieniowe przesyłanie multimediów sprowadza się do formatu kontenera i protokołu przesyłania strumieniowego :
  • Wszystkie dane audio są kodowane (przez kodek audio) do strumienia bitów audio
  • Wszystkie dane wideo są kodowane (ponownie przez kodek) do strumienia bitów wideo
  • Dwa strumienie są łączone ( multipleksowane? ) Razem w kontenerze, który ostatecznie staje się plikiem (takim jak MP4 itp.)
  • Specjalny serwer multimediów następnie podaje ten kontener (plik MP4 lub inny format) klientowi (być może odtwarzaczowi wideo HTML5 działającemu w przeglądarce) za pośrednictwem standardowego protokołu przesyłania strumieniowego, takiego jak RTSP
    • W przypadku klienta przeglądarki zakładam, że sama przeglądarka ma klienta RTSP, który następnie przedstawia użytkownikom HTML5 Video Player
• I mógłby obsługiwać pliku MP4 z internetowego serwera, takich jak nginx lub httpd, ale ponieważ serwery te nie są serwerami RTSP, będzie tylko w stanie leczyć wniosków o MP4 jako wnioski do pobrania , a tym samym nie będzie w stanie przesyłać strumieniowo pliki medialne
  • Podobnie, jeśli miałbym użyć curldo pobrania plików z serwera nginx, ponieważ curlani nginx nie mówią RTSP, byłoby to traktowane jako pobieranie pliku
• Ale kiedy hostuję plik MP4 z serwera multimediów strumieniowych (VideoLAN, Red5, Wowza itp.) I używam klienta RTSP (lub dowolnego obsługiwanego klienta multimediów strumieniowych) do żądania strumienia z tego serwera, to wtedy i tylko wtedy nie każdy rzeczywisty strumieniowe wystąpić
  • Dlatego nawet pomimo tego, że „filmy” YouTube lub Vimeo są hostowane na stronach HTML obsługiwanych przez HTTP (S) przez serwery HTTP, zakładam, że osadzone odtwarzacze wideo na tych stronach (z których faktycznie odtwarzane są filmy) faktycznie zaczynają sekundę , kolejne połączenie z serwerem przesyłania strumieniowego, a przesyłanie strumieniowe odbywa się przez RTSP lub inny protokół inny niż HTTP

Tak rozumiem i sądzę, że najpierw zapytam, czy jeśli coś, co powiedziałem powyżej, jest nieprawidłowe, zacznij od poprawienia mnie! Zakładając, że mam mniej więcej rację:

W jaki sposób odtwarzacze multimediów strumieniowych, działające na stronach HTML i obsługiwane przez serwery HTML, ustanawiają połączenia strumieniowe (RTSP itp.) Z serwerami multimediów strumieniowych (obsługującymi żądania RTSP)?

W jaki sposób odtwarzacze multimediów strumieniowych, działające na stronach HTML i obsługiwane przez serwery HTML, ustanawiają połączenia strumieniowe (RTSP itp.) Z serwerami multimediów strumieniowych (obsługującymi żądania RTSP)?

Typowe zastosowania

Wydaje się, że RTSP jest obecnie częściej używany w aplikacjach / interfejsach urządzeń, które bezpośrednio transmitują na żywo (np. Kamera IP) lub ponownie streamują (jak silnik), niż do przesyłania strumieniowego zapisanych plików multimedialnych z fizycznej lokalizacji za pośrednictwem interfejsu odtwarzania internetowego HTTP z wbudowany odtwarzacz.

Wygląda na to, że RTSP jest protokołem stanowym i używa przesyłania strumieniowego w większym stopniu niż TCP, a także jako urządzenia serwerowego (takiego jak kamera IP), który jest podłączony do sieci TCP / IP i wysyła strumienie przez UDP itp. Następnie łączysz się z tymi kanałami (serwerem) jako klient w tej samej sieci i możesz wysyłać żądania RTSP, aby odpowiednio je wykorzystać.

^{Dyrektywy protokołów}

^{Mimo że pod pewnymi względami podobny do HTTP, RTSP definiuje sekwencje kontrolne przydatne w kontrolowaniu odtwarzania multimediów. Podczas gdy HTTP jest bezstanowy , RTSP ma stan; identyfikator jest używany, gdy jest potrzebny do śledzenia równoczesnych sesji. Podobnie jak HTTP, RTSP używa TCP do utrzymywania połączenia typu end-to-end i chociaż większość komunikatów kontrolnych RTSP jest wysyłanych przez klienta do serwera, niektóre polecenia przemieszczają się w innym kierunku (tj. Z serwera na klienta).}

^{Przedstawiono tutaj podstawowe żądania RTSP. Dostępne są również niektóre typowe żądania HTTP, takie jak żądanie OPCJE. Domyślny numer portu warstwy transportowej to 554 [3] zarówno dla TCP, jak i UDP, ten ostatni jest rzadko używany do żądań sterowania.}

^_źródło

^{Bezpaństwowiec}

^{Bezstanowy protokół nie wymaga od serwera zachowania informacji o sesji ani statusu każdego partnera komunikacji przez czas trwania wielu żądań. W przeciwieństwie do protokołu, który wymaga utrzymania stanu wewnętrznego na serwerze jest znany jako stanowej protokołu.}

^{Wadą bezpaństwowości jest to, że może być konieczne dołączenie dodatkowych informacji do każdego żądania, a te dodatkowe informacje będą musiały zostać zinterpretowane przez serwer.}

^_źródło

Przepływ logiczny

Sposób, w jaki rozumiem przepływ mediów strumieniowych w tej formie, to:

• serwer, na którym znajduje się treść medialna, kapsułkuje, kompresuje, koduje itp. zawartość danych wideo / audio w odpowiednich formatach i segmentach do dostarczania strumieniowego
• serwer WWW, który nasłuchuje połączeń w celu uzyskania dostępu do mediów strumieniowych, dostarczy wszystkie zasoby potrzebne do strumieniowego przesyłania mediów
• klient żąda i pobiera odpowiednie zasoby i pliki, a następnie montuje je w sposób ciągły w celu odtwarzania za pomocą skonfigurowanego wskaźnika adresu URL i innych parametrów. Oprogramowanie do odtwarzania na poziomie klienta składa pakiety przesyłane po kolei, aby umożliwić prawidłowe odtwarzanie zawartości.

Ogólne porównanie HTTP i RTSP znajduje się w sekcji Technologie przesyłania strumieniowego poniżej.

Ponadto

W poniższej sekcji 10 powodów, dla których nigdy nie powinieneś hostować własnych filmów , zacytowałem części, które prowadzą do tego, aby pomóc Ci odpowiedzieć „ogólnie” bez pytania.

Zasadniczo mówi, że strona internetowa, która ma wbudowane sterowanie odtwarzaczem multimediów, będzie:

• ⁽¹⁾ wykrywają ustawienia przeglądarki internetowej klienta po „połączeniu i żądaniu” od klienta i
• ⁽²⁾ spowoduje to ustawienie kodeka i innych ustawień wykrywania po stronie klienta na odpowiednie wartości parametrów, a następnie
• ⁽³⁾ będzie przesyłać strumieniowo wideo bezpośrednio z serwera przesyłania strumieniowego, na którym hostujesz pliki wideo i audio, na podstawie dalszego kodu we wbudowanych konfiguracjach odtwarzacza multimediów, wskazując adres URL pliku multimedialnego na hostowanym serwerze.

^{Technologie przesyłania strumieniowego}

^{Przeglądarka klienta musi odebrać dane z serwera i przekazać je do aplikacji strumieniowej w celu przetworzenia. Aplikacja do przesyłania strumieniowego przekształca dane w obrazy i dźwięki. Ważnym czynnikiem powodzenia tego procesu jest zdolność klienta do szybszego odbierania danych, aby aplikacja mogła wyświetlić informacje. Nadmiar danych jest przechowywany w buforze - obszarze pamięci zarezerwowanym do przechowywania danych w aplikacji. W przypadku opóźnionego przesyłania danych między dwoma systemami bufor opróżnia się, a prezentacja materiału nie będzie płynna.}

^{Protokół HTTP}

^{HTTP jest dominującym sposobem łączenia dokumentów w Internecie. Klient nawiązuje połączenie z serwerem zawierające plik, który ma być przesyłany strumieniowo, plik jest pobierany, a połączenie zamykane. Serwer HTTP przekazuje przeglądarce typ pliku do przesłania.}

^{Korzyści z używania HTTP}

^{Podczas przesyłania strumieniowego pliku przy użyciu protokołu HTTP specjalny serwer przesyłania strumieniowego nie jest wymagany. Tak długo, jak przeglądarka obsługuje typy MIME, może odbierać plik strumieniowy z serwera HTTP. Jedną z wyraźnych zalet przesyłania strumieniowego plików za pomocą protokołu HTTP jest to, że może on przechodzić przez zapory ogniowe i wykorzystywać serwery proxy.}

^{Niektóre wady}

^{Strumieniowe przesyłanie HTTP wykorzystuje protokół TCP / IP (Transmission Control Protocol i Internet Protocol), aby zapewnić niezawodne dostarczanie plików. Ten proces sprawdza brakujące pakiety i prosi o ich ponowną transmisję. Staje się to problematyczne w scenariuszu przesyłania strumieniowego, gdy chcesz, aby dane zostały zignorowane, jeśli zostaną utracone podczas dostarczania, więc pliki dynamiczne będą odtwarzane dalej. HTTP nie może wykryć szybkości modemu, więc administratorzy serwerów muszą celowo tworzyć pliki o różnych współczynnikach kompresji dla użytkowników serwerów z różnymi typami połączeń. Przesyłanie strumieniowe plików z serwerów HTTP nie jest zalecane w sytuacjach wymagających dużego popytu.}

^{Protokół RTSP}

^{RTSP jest standardowym protokołem używanym przez większość dostawców serwerów przesyłania strumieniowego. Serwery RTSP używają protokołu UDP (User Datagram Protocol) do przesyłania plików multimedialnych. UDP nie sprawdza stale, czy pliki dotarły do ​​miejsca docelowego. Jest to zaletą dla aplikacji do przesyłania strumieniowego, ponieważ pozwala na przerwanie przesyłania plików, o ile opóźnienie nie jest zbyt długie. W wyniku tej metody czasami dochodzi do utraty danych, ale pliki są odtwarzane, jeśli opóźnienie jest niewielkie.}

^źródło

^{10 powodów, dla których nigdy nie powinieneś hostować własnych filmów}

^{Mówimy o osadzaniu vs. wideo hostowane}

^{Najpierw przesyłasz plik wideo do zewnętrznej usługi hostingowej, takiej jak YouTube, Vimeo lub Wistia.}

^{Następnie skopiujesz niewielki fragment kodu, który ci dostarczą, i wkleisz go do postu lub strony na własnej stronie WordPress. Film pojawi się w Twojej witrynie, w miejscu, w którym wkleiłeś kod do osadzenia, ale sam film jest przesyłany strumieniowo z serwerów hosta wideo, w przeciwieństwie do własnego serwera internetowego, na którym znajduje się witryna WordPress.}

^{4. Brak standardowego formatu pojedynczego pliku dla wideo w sieci Web}

^{Obecna specyfikacja wersji roboczej HTML5 nie określa, jakie formaty wideo powinny być obsługiwane przez przeglądarki. W rezultacie główne przeglądarki internetowe rozeszły się, każda z nich obsługuje inny format. Internet Explorer i Safari będą odtwarzać filmy w formacie H.264 (MP4), ale nie WebM ani Ogg. Firefox będzie odtwarzał filmy Ogg lub WebM, ale nie H.264. Na szczęście Chrome odtwarza wszystkie główne formaty wideo, ale jeśli chcesz mieć pewność, że będzie on odtwarzany we wszystkich głównych przeglądarkach internetowych, musisz przekonwertować go na wiele formatów: .mp4, .ogv i .webm}

^{5. Mam nadzieję, że lubisz konwertować filmy. Dużo.}

^{Większość odbiorców prawdopodobnie będzie oglądać Twoje filmy z komputera stacjonarnego lub laptopa z wykorzystaniem szybkiego połączenia internetowego. Dla tych ludzi będziesz chciał dostarczyć duży plik w jakości HD, aby mogli oglądać go na pełnym ekranie, jeśli tak zdecydują. Zasadniczo oznacza to plik 1080p lub 720p o wysokiej przepływności (5000 - 8000 kb / s).}

^{Ale będziesz też chciał zakodować mniejszą wersję o niższej rozdzielczości, która ma być dostarczana na urządzenia mobilne, takie jak telefony i tablety, a także do widzów z wolniejszym połączeniem internetowym.}

^{6. Odtwarzacze wideo}

^{Odtwarzacz wideo to małe oprogramowanie internetowe instalowane w witrynie, które automatycznie wykrywa, które urządzenie żąda Twojego wideo wraz z jego prędkością połączenia, a następnie dostarcza odpowiednią wersję tej osobie.}

^{7. Uciążliwy kod [lub skróty]}

^{Bez względu na to, czy korzystasz z wtyczki innej firmy, czy z wbudowanych funkcji wideo WordPress, musisz utworzyć trochę kodu, aby poinformować odtwarzacz wideo, jakie formaty utworzyłeś, a także o ich lokalizacji na serwerze. Wygląda mniej więcej tak…}

<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>

Więc jakie jest najlepsze rozwiązanie do dodawania wideo do swojej witryny?

Wystarczy skorzystać z usługi hostingu wideo innej firmy, a następnie osadzić wideo w poście lub stronie WordPress.

Krok pierwszy: Prześlij swój film do jednej z popularnych, dobrze znanych usług hostingowych, takich jak Vimeo PRO.

Krok drugi: Po przesłaniu filmu i przygotowaniu go do oglądania skopiuj adres URL do swojego filmu. Wróć do swojej witryny WordPress i wklej adres URL do posta lub strony, na której chcesz wyświetlać wideo.

---

^{Gdy ludzie zobaczą Twoją stronę, wideo pojawi się w miejscu, w którym wkleiłeś adres URL. Ale sam plik wideo będzie przesyłany strumieniowo z serwerów hosta wideo, w przeciwieństwie do własnego serwera, na którym znajduje się witryna WordPress.}

_{Wbudowany odtwarzacz wideo automatycznie wykryje urządzenie użytkownika, przeglądarkę i prędkość połączenia internetowego, a następnie wyświetli odpowiednią wersję pliku wideo. Nic do zainstalowania na twojej stronie. Brak wtyczek do aktualizacji. Bez trudnego kodu.}

_źródło

Poniżej zajmę się głównie twoim pytaniem, co się dzieje, gdy wideo jest wyświetlane w przeglądarce. Temat jest obszerny, więc będę dotyczył tylko odpowiednich elementów.

HTML5 wprowadziło <VIDEO>tag, który rozwiązał problem integracji wyświetlanego wideo z przeglądarką podczas korzystania z JavaScript i CSS. Poprzedni <OBJECT>tag wymagał zewnętrznego oprogramowania i był źle zintegrowany ze stroną. Nowy tag w efekcie wymagał, aby przeglądarka stała się również odtwarzaczem wideo, chociaż nie narzucono żadnych standardów. Rezultatem było całkowite rozdrobnienie standardów, do którego jedynym rozwiązaniem jest to, że serwer wideo udostępni kilka formatów wideo i że wszystkie te alternatywne źródła zostaną określone w <VIDEO>tagu, z którego przeglądarka wybierze ten, który obsługuje.

Przykład tagu z wieloma źródłami:

<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>

Sam <VIDEO>tag jest niezależny od protokołu, więc może używać dowolnego protokołu obsługiwanego przez przeglądarkę, w tym RTSP. Obsługa protokołu MPEG-DASH (dynamiczne adaptacyjne przesyłanie strumieniowe przez HTTP) stała się ostatnio bardzo obszerna, więc będzie można go odtwarzać na większości urządzeń i przeglądarek natywnych lub przy użyciu HTML5, co oznacza, że ​​nie są wymagane żadne dodatkowe wtyczki. Zobacz tabelę zgodności urządzeń i przeglądarek . Zobacz także ten artykuł Mozilli dotyczący przygotowania serwera do obsługi MPEG-DASH. DASH działa przez HTTP, więc będzie działać tak długo, jak długo twój serwer HTTP obsługuje żądania zakresu bajtów i jest skonfigurowany do obsługi plików .mpd mimetype="application/dash+xml".

Normalna interakcja między klientem a serwerem wygląda podobnie do poniższej. W przypadku HTML5 VIDEO przeglądarka jest również odtwarzaczem, chociaż może otworzyć nowe połączenie do odtwarzania.

Początkowe połączenie dostarcza metadane, których klient używa do wyświetlania wideo. Jeśli do uzyskania tych metadanych użyto protokołu RTSP, połączenie RTP zostanie później utworzone w celu przesłania danych wideo + audio. Protokół RTCP służy do przesyłania dodatkowych poleceń na serwer.

RTP, RTCP i RTSP działają na różnych portach. Zwykle gdy RTP jest na porcie N, RTCP jest na porcie N + 1. Sesja RTP może zawierać wiele strumieni do połączenia na końcu odbiornika; na przykład audio i wideo mogą być na osobnych kanałach.

Aby nikt nie został zablokowany przez twoje treści, powinieneś udostępnić zarówno kodeki wolne od tantiem, webM lub Theora, jak i wideo H.264, a także audio Vorbis i MP3. (Łatwo powiedziane, trudne do zrobienia.)

Oto, co dzieje się szczegółowo dla RTSP:

1. Klient nawiązuje połączenie TCP z serwerami, zwykle na porcie TCP 554, dobrze znanym porcie RTSP.

2. Następnie klient rozpocznie wydawanie serii poleceń nagłówka RTSP, które mają format podobny do HTTP, z których każde jest potwierdzane przez serwer. W ramach tych komend RTSP klient opisuje serwerowi szczegóły wymagań dotyczących sesji, takie jak obsługiwana wersja RTSP, transport używany do przepływu danych oraz wszelkie powiązane informacje o porcie UDP lub TCP. Informacje te są przekazywane za pomocą nagłówków DESCRIBE i SETUP i są uzupełniane w odpowiedzi serwera o identyfikator sesji, którego klient i dowolne przejściowe urządzenia proxy mogą wykorzystać do identyfikacji strumienia podczas dalszej wymiany.

3. Po zakończeniu negocjacji parametrów transportu klient wyda polecenie PLAY, aby polecić serwerowi rozpoczęcie dostarczania strumienia danych RTP.

4. Gdy klient zdecyduje się zamknąć strumień, wydawane jest polecenie TEARDOWN wraz z identyfikatorem sesji instruujące serwer, aby zaprzestał dostarczania RTP związanego z tym identyfikatorem.

Dalsza lektura:

• Podstawy protokołów przesyłania strumieniowego
• Zrozumienie protokołów warstwy aplikacji - protokół przesyłania strumieniowego w czasie rzeczywistym (RTSP)
• Wprowadzenie do wideo HTML5 (Opera)
• Audio i wideo HTML5: co musisz wiedzieć
• Analiza RTSP Wireshark

Oto szybka i brudna odpowiedź

Istnieje różnica między odtwarzaniem wideo w Internecie a jego przesyłaniem strumieniowym w czasie rzeczywistym.

Odtwarzanie odbywa się za pomocą odtwarzacza, który znajduje się na stronie internetowej (może to być Flash, JS lub obiekt wideo HTML5). Klient (przeglądarka) pobiera ten odtwarzacz i uruchamia go. Z kolei odtwarzacz pobiera wideo z prostego adresu URL pobierania. W rzeczywistości, nawet w Youtube, istnieją programy, które umożliwiają bezpośredni dostęp do hostowanych plików wideo i pobieranie ich tak, jak każdego innego pliku. Ponieważ system używa zwykłego starego łącza pobierania, nie ma potrzeby stosowania złożonych protokołów przesyłania strumieniowego, takich jak RTSP

Streaming w czasie rzeczywistym (powiedzmy z kamery internetowej) jest ... cóż, trudniejszy. Flash ma tę funkcję wbudowaną, ale nie należy jej już używać. Wideo HTML5 nie obsługuje przesyłania strumieniowego w czasie rzeczywistym, ale ludzie mogli go „oszukać”, zmuszając serwer hostingowy plików do ciągłej zmiany oferowanego pliku wideo.