Microsoft Stream (wersja klasyczna) omówienie dostarczania wideo i sieci

  • Artykuł

Ostrzeżenie

Microsoft Stream (wersja klasyczna) jest wycofywana i zastępowana przez usługi Stream (w programie SharePoint) i wydarzenia na żywo w usłudze Microsoft Teams. Zaleca się rozpoczęcie korzystania z usługi Stream (w programie SharePoint) przez przekazywanie filmów wideo do programu SharePoint, aplikacji Teams, Viva Engage lub OneDrive oraz uruchamianie wydarzeń na żywo za pośrednictwem usługi Teams i Viva Engage.

Funkcje w Stream (wersja klasyczna) zostaną zmienione i usunięte przed datą wycofania. Dowiedz się więcej o usłudze Stream (w programie SharePoint)...

Przesyłanie strumieniowe z adaptacyjną szybkością transmisji bitów

Istnieje wiele obsługiwanych formatów wideo, które można przekazać do Microsoft Stream. Każdy plik wideo jest następnie kodowany do formatu standardowego z kilkoma różnymi jakościami wideo i rozmiarami do odtwarzania. Stream (wersja klasyczna) korzysta z adaptacyjnego przesyłania strumieniowego z adaptacyjną szybkością transmisji bitów HTTPS (ABR), aby dynamicznie wybierać najlepszą jakość odtwarzania wideo na podstawie dostępnej przepustowości sieci i rozmiaru odtwarzacza wideo.

Podczas odtwarzania gracz dostosowuje się do wahań warunków sieciowych i rozmiaru odtwarzacza. Gdy dostępna przepustowość jest wysoka, odtwarzacz przesyła strumieniowo wersję wideo o wysokiej jakości. Gdy przepustowość spadnie, odtwarzacz przesyła strumieniowo wersję wideo o niskiej jakości. Jakość i rozdzielczość wideo będą również proporcjonalne do rozmiaru odtwarzacza. Jeśli widz ogląda na mniejszym ekranie, zawsze otrzyma mniejszą wersję wideo.

Przesyłanie strumieniowe z adaptacyjną szybkością transmisji bitów działa w tle, podczas gdy wideo odtwarza się z najmniejszą ilością zakłóceń lub buforowania. Podczas odtwarzania wideo odtwarzacz wideo umożliwia przeglądarce ręczne zastąpienie jakości odtwarzania automatycznego w celu wybrania określonej jakości odtwarzania wideo.

Inteligentne kodowanie przekazanych filmów wideo na potrzeby przesyłania strumieniowego z adaptacyjną szybkością transmisji bitów

Stream (wersja klasyczna) używa niektórych elementów inteligentnych, aby określić, w jaki sposób tworzy różne cechy i rozmiary wideo z oryginalnego przekazanego wideo, które mają być używane do przesyłania strumieniowego z adaptacyjną szybkością transmisji bitów.

Najpierw Stream (wersja klasyczna) określa, ile różnych cech lub odwzorowania wideo powinno zostać utworzonych dla przekazanego filmu wideo. Stream (wersja klasyczna) uwzględnia oryginalną rozdzielczość wideo. Jeśli na przykład jest to film wideo o rozmiarze 1080p lub wyższym, utworzy on więcej poziomów jakości (około 6), aby obniżyć poziom do wersji o najniższej jakości. Jeśli zamiast tego przekazany film wideo ma wartość 480p, utworzy mniej poziomów jakości (około 3), aby obniżyć poziom do wersji o najniższej jakości. Stream (wersja klasyczna) nie wygeneruje rozdzielczości wideo, która przekracza rozdzielczość pierwotnie przekazanego filmu wideo.

Po określeniu liczby jakości lub odwzorowania wideo następnym etapem jest określenie szybkości transmisji bitów dla każdego odwzorowania. Im wyższa jakość odwzorowania, tym więcej bitów wymaga. Jednak nie wszystkie filmy wideo są tworzone na równi, różne typy filmów wideo wymagają różnych szybkości transmisji bitów, aby zapewnić wysoką jakość wyświetlania. Jeśli film wideo ma dużo ruchu, musi być dostarczany z większą szybkością transmisji bitów, aby osiągnąć doskonałe środowisko wyświetlania. Jednak prezentacja programu PowerPoint w filmie wideo z głównie statycznym tekstem może nadal uzyskać doskonałe środowisko wyświetlania z mniejszą szybkością transmisji bitów.

Aby rozwiązać ten problem zmienności zawartości wideo, Stream (wersja klasyczna) mierzy charakterystykę przekazanego wideo, a następnie zaleca szybkość transmisji bitów dla każdego odwzorowania. Każdy film wideo przekazany do Stream (wersja klasyczna) będzie miał nieco inny zestaw rozdzielczości i szybkości transmisji bitów używanych do przesyłania strumieniowego, aby upewnić się, że korzystamy z przepustowości mądrze i używamy więcej bitów tylko wtedy, gdy jest to potrzebne.

Podczas wyświetlania wideo w usłudze Stream różne odwzorowania, które zostały utworzone na potrzeby przesyłania strumieniowego z adaptacyjną szybkością transmisji bitów, są widoczne w odtwarzaczu:

  • W odtwarzaczu Stream (wersja klasyczna) kliknij ikonę Koła zębate, a następnie wybierz pozycję Jakość.
Przykład Opis Player
Nagrania spotkań w usłudze Teams Nagrania spotkań w usłudze Teams są kodowane za pomocą pojedynczego odwzorowania wideo o rozdzielczości 1080p. 1080p – 574 Kb/s
Wideo na żądanie (z wyłączeniem nagrań ze spotkania) Wideo na żądanie inne niż Teams jest zakodowane przy użyciu ustawień wstępnych obsługujących zawartość, który inteligentnie wybiera maksymalnie 6 odwzorowania wideo, jak pokazano w tym przykładzie. Większa złożoność zawartości o wysokim stopniu wariancji kolorów i ruchu zostanie zakodowana przy użyciu większej liczby odwzorowania wideo, a mniejsza złożoność zawartości zostanie zakodowana z mniejszą liczbą. 1080p – 3 Mb/s
720p – 1,6 Mb/s
540p – 989 Kb/s
360p – 460 Kb/s
270p – 327 Kb/s
180p – 193 Kb/s

Profil kodowania dla wydarzeń na żywo

Kodowanie inteligentne wymienione powyżej dotyczy tylko filmów wideo przekazanych do usługi Stream.

Wydarzenia na żywo utworzone w Stream (wersja klasyczna) lub "Zewnętrzna aplikacja lub urządzenie" utworzone na żywo z usługi Yammer lub Microsoft Teams otrzymają stały profil kodowania:

  • 720p — 1,7 Mb/s
  • 540p – 850 Kb/s
  • 360p – 350 Kb/s
  • 240p – 140 Kb/s

Uwaga

Jeśli rozdzielczość wejściowego wideo z kodera wynosi 720p lub nowszą, uzyskasz powyższy profil. Jeśli porzucisz rozdzielczość wejściowego wideo z kodera do wartości niższej niż 720p, otrzymasz tylko wyjściowe szybkości transmisji bitów z rozdzielczości wejściowej i w dół. Jeśli na przykład wysłano rozdzielczość 540p z kodera, użytkownicy o najwyższej szybkości transmisji bitów będą mogli uzyskać wersję 540p – 850kbps. Stream (wersja klasyczna) nie zmienia powyższego profilu kodowania na żywo na podstawie wejściowej szybkości transmisji bitów z kodera, tylko odcina poziomy jakości na podstawie rozdzielczości danych wejściowych.

Wymagania dotyczące przepustowości odtwarzania wideo

Odtwarzanie wideo w Stream (wersja klasyczna) jest emisji pojedynczej, co oznacza, że każdy widz otrzymuje własny strumień wideo z Internetu. Na podstawie inteligentnego kodowania i przesyłania strumieniowego z adaptacyjną szybkością transmisji bitów używanego przez usługę Stream wymaganie przepustowości odtwarzania wideo nie jest liczbą statyczną. Odtwarzanie wideo może zużywać różne ilości przepustowości Internetu, w zależności od przekazanych filmów wideo:

  • oryginalna rozdzielczość, szybkość transmisji bitów i zawartość
  • dostępna przepustowość użytkownika
  • rozmiar odtwarzacza

Jeśli chcesz opracować szacowanie przepustowości, musisz przekazać kilka filmów wideo reprezentujących typową zawartość używaną przez organizację z Stream (wersja klasyczna) i watch filmów wideo na ekranach, które twoim zdaniem będą używane przez użytkowników. Następnie można wykonać pewne pomiary przepustowości i próbkowanie. Następnie możesz użyć tych zbliżeń, aby wykonać obliczenia wysokiego poziomu i oszacować, ile przepustowości użytkownicy będą zużywać w zależności od tego, ile twoim zdaniem będzie watch filmów wideo w tym samym czasie.

Optymalizacja dostarczania wideo w mojej sieci lokalnej

Stream (wersja klasyczna) wykorzystuje inteligentne kodowanie i przesyłanie strumieniowe z adaptacyjną szybkością transmisji bitów w celu zmniejszenia ruchu sieciowego i internetowego odtwarzania wideo. Jednak odtwarzanie jest strumieniem emisji pojedynczej. W przypadku zdarzeń na żywo lub klipów wideo wysyłanych do dużych części Twojej organizacji widzowie mogą zużywać znaczną ilość przepustowości internetowej.

W przypadku organizacji, które chcą zmniejszyć ten ruch internetowy dla wydarzeń na żywo i popularnych filmów wideo, dostępne są dwie opcje:

  1. Korzystanie z istniejących serwerów proxy pamięci podręcznej w sieci

    Oglądanie filmów wideo z Stream (wersja klasyczna) odbywa się za pośrednictwem protokołu HTTPS, dlatego normalne serwery proxy internetowej pamięci podręcznej można skonfigurować do buforowania ruchu odtwarzania wideo. Może być konieczne skonfigurowanie niestandardowego certyfikatu SSL, aby stało się to z protokołem HTTPS. Jeśli jednak przyjrzysz się śladowi sieci podczas odtwarzania wideo, zobaczysz adresy URL używane przez Stream (wersja klasyczna) do przesyłania strumieniowego wideo dla organizacji (adresy URL mogą się różnić w zależności od dzierżawy Stream (wersja klasyczna)). Jeśli kierujesz te adresy URL przez serwer proxy pamięci podręcznej, może on buforować ruch wideo i zmniejszać ruch internetowy dla często odtwarzanych filmów wideo.

  2. Korzystanie z rozwiązania do dostarczania wideo eCDN innej firmy zoptymalizowanego pod kątem Stream (wersja klasyczna)

    Kilka rozwiązań eCDN dostarczania wideo jest wstępnie zintegrowanych i można je skonfigurować do użycia z usługą Stream. Te platformy eCDN umożliwiają organizacjom optymalizowanie przepustowości sieci bez poświęcania środowiska wyświetlania użytkowników końcowych. Nasi partnerzy mogą pomóc w umożliwieniu bardziej skalowalnej i wydajnej dystrybucji wideo w sieci przedsiębiorstwa. Aby uzyskać więcej informacji, zobacz Scaling video delivery with 3rd party eCDN providers (Skalowanie dostarczania wideo z dostawcami eCDN innych firm ).

Punkty końcowe, które muszą być dostępne dla użytkowników w sieci

Ogólne punkty końcowe Microsoft Stream (wersja klasyczna)

Microsoft Stream (wersja klasyczna) wymaga łączności z Internetem. Wszystkie punkty końcowe wymienione w punktach końcowych Office 365 dla Microsoft Stream muszą być dostępne dla użytkowników Microsoft Stream (wersja klasyczna) w sieci organizacji.

Zdarzenia na żywo generowane przez aplikację zewnętrzną lub urządzenie (dawniej koder zewnętrzny) — punkty końcowe pozyskiwania RMTP

Aby uzyskać kanał wideo dla aplikacji zewnętrznej lub zdarzenia na żywo utworzonego na urządzeniu wysyłanego do Microsoft Stream (wersja klasyczna) z kodera, potrzebne są następujące zakresy adresów IP i porty otwarte w zaporze sieci:

  • Domeny: *.channel.media.azure.net
  • Porty: 1935/2935/1936/2936 (dla RTMP i RTMPS)

Jeśli określona konfiguracja sieci nie umożliwia (lub nie chcesz) otwierania powyższego zakresu domen, obecnie jedyną opcją uzyskania określonych adresów IP na potrzeby pozyskiwania rtmp/RTMPS jest pobranie zakresów adresów IP dla centrum danych platformy Azure, z którą jest połączona dzierżawa Microsoft Stream (wersja klasyczna).

Następujące pliki JSON są aktualizowane w miarę zmiany adresów IP centrów danych platformy Azure, które są uszkodzone według regionów i przez oznaczone usługi.

Te pliki są aktualizowane co tydzień i obejmują przechowywanie wersji dla pełnego pliku i każdego pojedynczego tagu usługi w tym pliku.

Aby znaleźć centrum danych platformy Azure dla dzierżawy Stream (wersja klasyczna):

  1. W usłudze Stream kliknij pozycję ? w prawym górnym rogu.

  2. Wybierz pozycję Informacje o Microsoft Stream.

  3. Wyświetl informacje w obszarze Twoje dane są przechowywane.

Po znalezieniu centrum danych platformy Azure dla dzierżawy Stream (wersja klasyczna) znajdź odpowiednie zakresy adresów IP w powyższym pliku XML, a następnie zaktualizuj zaporę/serwer proxy przy użyciu określonych zakresów adresów IP dla centrum danych. W miarę zmiany pliku XML należy również zaktualizować ustawienia zapory/serwera proxy.

Przykład:

  • Jeśli informacje o Microsoft Stream mówią, że dane są przechowywane w regionie "Wschodnie stany USA 2"

  • W pliku XML szukasz węzła z etykietą <Nazwa regionu="useast2">

  • W tym węźle Region będzie kilka wpisów dla wszystkich zakresów adresów IP (<IpRange Subnet="13.68.0.0/17">)

  • Należy skonfigurować zaporę\serwer proxy, aby zezwolić na wszystkie te zakresy adresów IP i regularnie je zmieniać po zmianie pliku XML.

Użytkownicy w społeczności napisali kod, który zgodnie z harmonogramem przyjmuje powyższy plik XML i konwertuje dane na interfejs API, który można odpytywane. Twoja organizacja może być w stanie dowiedzieć się, co zostało zrobione w tym projekcie open source i utworzyć własne podobne rozwiązanie, aby regularnie aktualizować ustawienia zapory/serwera proxy.

Sieci CDN używane do odtwarzania wideo

Wydarzenia na żywo z Stream (wersja klasyczna) i wydarzeń na żywo aplikacji zewnętrznej lub urządzenia z usługi Yammer/Teams, a także wideo na żądanie będą automatycznie używać usługi Azure CDN.

Filmy wideo na żądanie przekazane do usługi Stream , a także nagrania zdarzeń na żywo, będą również używać usługi Azure CDN do odtwarzania, jeśli jest to wymagane. Jeśli usługa Azure CDN nie jest wymagana dla tych filmów wideo, będą one odtwarzane z serwerów pochodzenia usługi Azure Media Services skojarzonych z regionem geograficznym dzierżawy.

Jeśli kilka osób z tej samej organizacji w tej samej lokalizacji geograficznej przesyła strumieniowo te same filmy wideo, sieci CDN będą przechowywać kopię tych filmów wideo w lokalizacji bliżej tego regionu geograficznego. Gdy wideo jest przechowywane lub buforowane w najbliższej lokalizacji, każda osoba przesyła strumieniowo wideo z najbliższej lokalizacji, a nie z lokalizacji znajdującej się dalej. Stream (wersja klasyczna) używa usługi Azure Media Services do zarządzania tym, co jest buforowane w usłudze Azure CDN i jak długo. Usługa Azure Media Services może używać dowolnej lokalizacji usługi Azure CDN do buforowania fragmentów i manifestów wideo przez kilka dni. Jeśli osoby w organizacji nadal watch buforowane filmy wideo, pozostaną w pamięci podręcznej. Jeśli nikt nie uzyska dostępu do wideo przez kilka dni, film wideo zostanie ostatecznie usunięty z pamięci podręcznej. Następnym razem, gdy ktoś spróbuje watch wideo, zostanie on ponownie zapisany w pamięci podręcznej w najbliższej lokalizacji usługi CDN.

Każdy, kto próbuje watch wideo, gdy zawartość jest buforowana w pobliskiej sieci CDN, korzysta z tego, że wideo jest bliżej, a w większości przypadków mniej przeskoków. Zwiększa to szybkość odtwarzania wideo; Nie zmienia to jednak wymagań sieciowych do odtwarzania wideo.

Szyfrowanie i przepływ odtwarzania na poziomie wideo

Stream (wersja klasyczna) wie, jak ważne jest zapewnienie bezpieczeństwa danych i ich prywatnych danych. Centrum zaufania firmy Microsoft opisuje nasze zobowiązanie do zachowania prywatności i bezpieczeństwa zawartości. W przypadku odtwarzania wideo szybkość jest ważna dla dobrego środowiska; nie naruszamy jednak bezpieczeństwa ani prywatności w zamian za szybkość. Oto jak dostosować szybkość, bezpieczeństwo i prywatność.

Gdy Ty lub ktoś w organizacji przekaże nowe wideo lub utworzy wydarzenie na żywo, ten film wideo zostanie transkodowany, zaszyfrowany za pomocą szyfrowania AES-128 i przechowywany w usłudze Azure Media Services. Oznacza to, że filmy wideo są szyfrowane zarówno podczas przesyłania, jak i w spoczynku.

Gdy ktoś w twojej organizacji próbuje watch wideo, wykonaj następujące kroki:

  1. Stream (wersja klasyczna) określa, czy osoba przeglądająca ma dostęp do filmu wideo, sprawdzając uprawnienia ustawione na filmie wideo w bazie danych Azure SQL pod kątem Stream (wersja klasyczna) i informacji w Tożsamość Microsoft Entra o użytkowniku

  2. Jeśli użytkownik może wyświetlić film wideo, klucz odszyfrowywania jest pobierany z usługi Azure Media Services i podawany do odtwarzacza wideo Stream (wersja klasyczna)

  3. Odtwarzacz wideo Stream (wersja klasyczna) następnie używa klucza odszyfrowywania do odszyfrowywania wideo w locie podczas odtwarzania wideo

Zobacz też

Skalowanie dostarczania wideo z dostawcami eCDN innych firm