Microsoft Stream (Klassisk) videolevering og netværksoversigt

  • Artikel

Advarsel

Microsoft Stream (Klassisk) udgår og erstattes af Stream (på SharePoint) og Microsoft Teams-livebegivenheder. Det anbefales, at du begynder at bruge Stream (på SharePoint) ved at uploade videoer til SharePoint, Teams, Viva Engage eller OneDrive og til at køre dine livebegivenheder via Teams og Viva Engage.

Funktionaliteten i Stream (Klassisk) ændres og fjernes op til udfasningsdatoen. Få mere at vide om Stream (på SharePoint)...

Streaming med tilpassede bithastigheder

Der er mange understøttede videoformater, der kan uploades til Microsoft Stream. Hver videofil kodes derefter til et standardformat med flere forskellige videokvaliteter og -størrelser til afspilning. Stream (Klassisk) bruger HTTPS unicast-streaming med tilpassede bithastigheder til dynamisk at vælge den bedste videoafspilningskvalitet baseret på den tilgængelige netværksbåndbredde og videoafspillerens størrelse.

Under afspilning tilpasser afspilleren sig udsving i netværksforhold og størrelsen på afspilleren. Når den tilgængelige båndbredde er høj, streamer afspilleren en version af høj kvalitet af videoen. Når båndbredden falder, streamer afspilleren en version af videoen af lav kvalitet. Kvaliteten og opløsningen af videoen vil også være proportional med størrelsen af afspilleren. Hvis en seer ser den på en mindre skærm, får vedkommende altid en mindre version af videoen.

Streaming med tilpassede bithastigheder udfører alt dette arbejde i baggrunden, mens videoen afspilles med den mindste mængde afbrydelse eller bufferlagring. Under afspilning af video giver videoafspilleren seerne mulighed for manuelt at tilsidesætte den automatiske afspilningskvalitet for at vælge en bestemt videoafspilningskvalitet.

Smart kodning af uploadede videoer til streaming med tilpassede bithastigheder

Stream (Klassisk) bruger nogle smarte egenskaber til at bestemme, hvordan de forskellige videokvaliteter og -størrelser oprettes ud fra den oprindelige uploadede video, som skal bruges til streaming med tilpassede bithastigheder.

Først bestemmer Stream (Klassisk), hvor mange forskellige videokvaliteter eller gengivelser der skal oprettes for den uploadede video. Stream (Klassisk) tager højde for videoens oprindelige opløsning. Hvis det f.eks. er en video på 1080p eller højere, oprettes der flere kvalitetsniveauer (ca. 6) for at gå ned til versionen med den laveste kvalitet. Hvis den uploadede video i stedet er 480p, opretter den færre kvalitetsniveauer (ca. 3) for at gå ned til versionen med den laveste kvalitet. Stream (Klassisk) genererer ikke en opløsning af videoen, der overskrider opløsningen for den oprindeligt uploadede video.

Når antallet af videokvaliteter eller gengivelser er besluttet, er det næste trin at bestemme bithastigheden for hver gengivelse. Jo højere kvaliteten af gengivelsen er, jo flere bit kræver den. Men ikke alle videoer er oprettet lige, forskellige typer videoer kræver forskellige bithastigheder for at opnå en visningsoplevelse af høj kvalitet. Hvis en video har masser af bevægelse, skal den leveres med en højere bithastighed for at opnå en god visningsoplevelse. En PowerPoint-præsentation i en video med overvejende statisk tekst kan dog stadig få en fantastisk visningsoplevelse med en lavere bithastighed.

For at håndtere denne variation i videoindhold anbefaler Stream (Klassisk) egenskaberne for den uploadede video og anbefaler derefter bithastighed for hver gengivelse. Hver video, der uploades til Stream (Klassisk), vil ende med et lidt andet sæt opløsninger og bithastigheder, der bruges til streaming, for at sikre, at vi bruger båndbredde med omhu og kun bruger flere bit, når det er nødvendigt.

Når du får vist en video i Stream, kan de forskellige gengivelser, der blev oprettet til streaming med tilpassede bithastigheder, ses i afspilleren:

  • Klik på tandhjulsikonet i den Stream (Klassisk) spiller, og vælg derefter Kvalitet.
Eksempel Beskrivelse Spiller
Teams-mødeoptagelser Teams-mødeoptagelser kodes med en enkelt videoversion med en opløsning på 1080p. 1080p – 574 Kbps
Video on-demand (undtagen mødeoptagelser) Ikke-Teams-video on-demand kodes med en indholdsbevidst forudindstilling, der på intelligent vis vælger op til 6 videoversioner, som vist i dette eksempel. Indhold med højere kompleksitet med en høj grad af farve- og bevægelsesvarians kodes med flere videoversioner, og mindre kompleksitetsindhold kodes med færre. 1080p – 3 Mbps
720p – 1,6 Mbps
540p – 989 Kbps
360p – 460 Kbps
270p – 327 Kbps
180p – 193 kbps

Kodningsprofil til livebegivenheder

Den intelligente kodning, der er angivet ovenfor, gælder kun for videoer, der uploades til Stream.

Livebegivenheder, der er oprettet i Stream (Klassisk) eller "Ekstern app eller enhed"-producerede livebegivenheder fra Yammer eller Microsoft Teams, får en fast kodningsprofil:

  • 720p – 1,7 Mbps
  • 540p - 850 Kbps
  • 360p - 350 Kbps
  • 240p - 140 Kbps

Bemærk!

Hvis opløsningen for din inputvideo fra koderen er 720p eller højere, får du ovenstående profil. Hvis du slipper opløsningen for din inputvideo fra koderen til lavere end 720p, får du kun outputbithastigheder fra din inputopløsning og ned. Hvis du f.eks. har sendt en opløsning på 540p fra koderen, vil den højeste bithastighed, som seerne kan få, være 540p-850 kbps-versionen. Stream (Klassisk) ikke ændrer ovenstående livekodningsprofil baseret på inputbithastighed fra koderen, afskærer den kun kvalitetsniveauer baseret på inputopløsning.

Krav til båndbredde ved afspilning af video

Videoafspilning i Stream (Klassisk) er unicast, hvilket betyder, at alle seere får deres egen videostream fra internettet. Baseret på den intelligente kodning og streaming med tilpassede bithastigheder, der bruges af Stream, er kravet til båndbredde for videoafspilning ikke et statisk tal. Afspilning af en video kan forbruge forskellige mængder internetbåndbredde, afhængigt af en uploadet videos:

  • oprindelig opløsning, bithastighed og indhold
  • brugerens tilgængelige båndbredde
  • størrelsen på afspilleren

Hvis du vil udvikle nogle estimering af båndbredde, skal du uploade nogle videoer, der repræsenterer det typiske indhold, som din organisation vil bruge sammen med Stream (Klassisk) og se videoerne på skærmstørrelser, som du mener vil blive brugt af dine brugere. Du kan derefter foretage nogle målinger af båndbredde og sampling. Du kan derefter bruge disse tilnærmelser til at foretage nogle beregninger og estimater på højt niveau af, hvor meget båndbredde dine brugere vil forbruge, baseret på hvor mange du tror, der vil se videoer på samme tid.

Optimering af videolevering inden for mit lokale netværk

Stream (Klassisk) udnytter smart kodning og streaming med tilpassede bithastigheder til at reducere netværks- og internettrafikken ved videoafspilning. Afspilning er dog en unicast-stream. For live begivenheder eller videoer, der sendes til store dele af din organisation, kan brugeren bruge en betydelig brug af Internetbåndbredde.

For organisationer, der ønsker at reducere denne internettrafik for livebegivenheder og populære videoer, er der to muligheder:

  1. Udnyt eksisterende cacheproxyer i dit netværk

    Når du ser videoer fra Stream (Klassisk) sker via HTTPS, kan normale webcacheproxyer konfigureres til at cachelagre videoafspilningstrafikken. Du skal muligvis konfigurere brugerdefineret SSL-certificering for at få dette til at ske med HTTPS. Men hvis du ser på en netværkssporing, mens du afspiller en video, kan du se de URL-adresser, som Stream (Klassisk) bruger til at streame videoen for din organisation (URL-adresser kan variere efter Stream (Klassisk) lejer). Hvis du distribuerer disse URL-adresser via din cacheproxy, kan den cachelagre videotrafikken og reducere internettrafikken for ofte afspillede videoer.

  2. Brug en eCDN-videoleveringsløsning fra tredjepart, der er optimeret til Stream (Klassisk)

    Flere eCDN-videoleveringsløsninger er forudintegreret og kan konfigureres til at blive brugt med Stream. Disse eCDN-platforme gør det muligt for organisationer at optimere netværksbåndbredden uden at gå på kompromis med slutbrugerens visningsoplevelser. Vores partnere kan hjælpe med at muliggøre en mere skalerbar og effektiv videodistribution på tværs af dit virksomhedsnetværk. Se Skaler videolevering med tredjepartsudbydere af eCDN for at få flere oplysninger.

Slutpunkter, der skal være tilgængelige for brugere på netværket

Generelle Microsoft Stream (Klassisk) slutpunkter

Microsoft Stream (Klassisk) kræver forbindelse til internettet. Alle slutpunkter, der er angivet på Office 365 slutpunkter for Microsoft Stream, skal være tilgængelige for brugere af Microsoft Stream (Klassisk) på organisationens netværk.

Livebegivenheder, der er produceret af en ekstern app eller enhed (tidligere ekstern koder) – slutpunkter for RMTP-indfødning

Hvis du vil have et videofeed til en ekstern app eller enhed produceret livebegivenhed sendt til Microsoft Stream (Klassisk) fra koderen, skal du have følgende IP-intervaller og porte åbnet i netværkets firewall:

  • Domæner: *.channel.media.azure.net
  • Porte: 1935/2935/1936/2936 (til RTMP og RTMPS)

Hvis din specifikke netværkskonfiguration ikke tillader dig at (eller du ikke vil) åbne ovenstående domæneinterval, er den eneste mulighed for at få specifikke IP-adresser til RTMP/RTMPS-indfødning i øjeblikket at få de roterende IP-intervaller for Azure-datacenteret, som din Microsoft Stream (Klassisk) lejer er tilsluttet.

Følgende JSON-filer opdateres, efterhånden som IP-adresserne for Azure-datacentre ændres, brydes efter område og af de mærkede tjenester.

Disse filer opdateres ugentligt og omfatter versionering både for den fulde fil og hver enkelt tjenestekode i den pågældende fil.

Sådan finder du Azure-datacenteret til din Stream (Klassisk) lejer:

  1. Klik på ? i øverste højre hjørne i Stream.

  2. Vælg Om Microsoft Stream.

  3. Få vist oplysningerne i Dine data er gemt i.

Når du har fundet Ud af Azure-datacenteret for din Stream (Klassisk) lejer, skal du finde de tilsvarende IP-intervaller i ovenstående XML-fil og derefter opdatere din firewall/proxy med de specifikke IP-intervaller for dit datacenter. Når XML-filen ændres, skal du også opdatere indstillingerne for firewall/proxy.

Eksempel:

  • Hvis About Microsoft Stream siger, at dine data er gemt i "Det østlige USA 2"

  • I XML-filen skal du søge efter en node med navnet <Region Name="useast2">

  • Under denne områdenode ville der være flere poster for alle IP-intervaller (<IpRange Subnet="13.68.0.0/17">)

  • Du skal konfigurere din firewall\proxy for at tillade alle disse IP-intervaller og ændre dem regelmæssigt, når XML-filen ændres.

Brugere i community'et har skrevet kode, der efter en tidsplan tager OVENSTÅENDE XML-fil og konverterer dataene til en API, der kan forespørges. Din organisation kan muligvis lære af, hvad der blev udført med dette åben kildekode projekt, og bygge din egen lignende løsning for regelmæssigt at opdatere indstillingerne for firewall/proxy.

CDN brugt til videoafspilning

Livebegivenheder fra Stream (Klassisk) og eksterne apps eller enheders livebegivenheder fra Yammer/Teams samt on-demand-videoer bruger automatisk Azure CDN.

Videoer efter behov, der er uploadet til Stream – samt livebegivenhedsoptagelser – bruger også Azure CDN til afspilning, hvis det er nødvendigt. Når Azure CDN ikke kræves til disse videoer, afspilles de fra de oprindelige Azure Media Services-servere, der er knyttet til lejerens geografiske område.

Hvis flere personer fra den samme organisation inden for den samme geografiske placering streamer de samme videoer, gemmer CDN'er en kopi af disse videoer på en placering tættere på det geografiske område. Når videoen er gemt eller cachelagret på den nærmeste placering, streamer hver person videoen fra den placering, der er tættest på dem, i stedet for en placering længere væk. Stream (Klassisk) bruger Azure Media Services til at administrere, hvad der cachelagres i Azure CDN'er, og hvor længe. Azure Media Services kan bruge alle Azure CDN-placeringer til at cachelagre videofragmenter og manifester i et par dage. Hvis personer i din organisation fortsætter med at se de cachelagrede videoer, forbliver de i cachen. Hvis ingen får adgang til videoen i flere dage, fjernes videoen til sidst fra cachen. Næste gang nogen forsøger at se videoen, cachelagres den igen på den nærmeste CDN-placering.

Alle, der forsøger at se videoen, mens indholdet cachelagres på et nærliggende CDN, drager fordel af, at videoen er tættere på, og i de fleste tilfælde færre hop væk. Dette forbedrer afspilningshastigheden for videoer. Det ændrer dog ikke netværkskravet for at afspille videoen.

Kryptering på videoniveau og afspilningsflow

Stream (Klassisk) ved, hvor vigtigt det er at holde dine data sikre og private. Microsoft Trust Center beskriver vores forpligtelse til beskyttelse af personlige oplysninger og sikkerhed for dit indhold. Med videoafspilning er hastighed vigtig for at få en god oplevelse. Vi kompromitterer dog ikke din sikkerhed eller dine personlige oplysninger i bytte for hastighed. Her kan du se, hvordan vi imødekommer hastighed, sikkerhed og beskyttelse af personlige oplysninger.

Når du eller en person i din organisation uploader en ny video eller opretter en livebegivenhed, kodes den pågældende video, krypteres med AES-128-kryptering og gemmes i Azure Media Services. Det betyder, at videoerne krypteres både under overførsel og inaktive.

Når en person i din organisation forsøger at se en video, følger vedkommende disse trin:

  1. Stream (Klassisk) bestemmer, om seeren har adgang til videoen, ved at kontrollere tilladelserne for videoen i Azure SQL Database for at få Stream (Klassisk) og oplysninger i Microsoft Entra ID om brugeren

  2. Hvis brugeren har tilladelse til at se videoen, hentes dekrypteringsnøglen fra Azure Media Services og gives til den Stream (Klassisk) videoafspiller

  3. Den Stream (Klassisk) videoafspiller bruger derefter dekrypteringsnøglen til at dekryptere videoen på farten, når videoen afspilles

Se også

Skalering af videolevering med tredjepartsudbydere af eCDN