Microsoft Stream video-levering og nettverksoversikt
Dynamisk bithastighet for strømming
Det finnes mange støttede videoformater som kan lastes opp til Microsoft Stream. Hver videofil kodes deretter til et standardformat med flere forskjellige videokvaliteter og -størrelser for avspilling. Stream bruker HTTPS unicast adaptive bitrate streaming (ABR) til å dynamisk velge den beste videoavspillingskvaliteten basert på den tilgjengelige nettverksbåndbredden og størrelsen på videospilleren.
Under avspilling tilpasses spilleren til svingninger i nettverksforholdene og størrelsen på spilleren. Når den tilgjengelige båndbredden er høy, strømmer spilleren en versjon av videoen av høy kvalitet. Når båndbredden synker, strømmer spilleren en versjon av videoen med lav kvalitet. Kvaliteten og oppløsningen på videoen vil også være proporsjonal med størrelsen på spilleren. Hvis et visningsprogram ser på en mindre skjerm, får de alltid en mindre versjon av videoen.
Den adaptive strømmingen av bithastigheten gjør alt dette arbeidet i bakgrunnen mens videoen spilles av med minst mulig avbrudd eller bufring. Under videoavspilling lar videospilleren brukeren overstyre den automatiske avspillingskvaliteten manuelt for å velge en bestemt videoavspillingskvalitet.
Smart koding av opplastede videoer for dynamisk strømming av bithastighet
Stream bruker noen smarte smarter til å bestemme hvordan den oppretter de forskjellige videokvalitetene og -størrelsene fra den opprinnelige opplastede videoen som skal brukes til adaptiv strømming av bithastighet.
Først bestemmer Stream hvor mange forskjellige videokvaliteter eller gjengivelser som skal opprettes for den opplastede videoen. Stream tar hensyn til den opprinnelige oppløsningen på videoen. Hvis det for eksempel er en 1080p- eller høyere video, vil det opprette flere kvalitetsnivåer (ca. 6) for å gå ned til den laveste kvalitetsversjonen. Hvis den opplastede videoen i stedet er 480p, vil den opprette færre kvalitetsnivåer (omtrent 3) for å gå ned til den laveste kvalitetsversjonen. Stream genererer ikke en oppløsning på videoen som overskrider oppløsningen til den opprinnelig opplastede videoen.
Når antall videokvaliteter eller gjengivelser er avgjort, er neste trinn å bestemme bithastigheten for hver gjengivelse. Jo høyere kvalitet på gjengivelsen, jo flere biter krever den. Men ikke alle videoer opprettes like, forskjellige typer videoer krever ulike bithastigheter for å oppnå en visningsopplevelse av høy kvalitet. Hvis en video har mye bevegelse, må den leveres med en høyere bithastighet for å oppnå en flott visningsopplevelse. En presentasjon PowerPoint i en video med for det meste statisk tekst, kan imidlertid fortsatt få en flott visningsopplevelse på en lavere bithastighet.
For å løse denne variasjonen i videoinnholdet måler Stream egenskapene til den opplastede videoen og anbefaler deretter bithastighet for hver gjengivelse. Hver video som lastes opp til Stream, vil ende opp med et litt annet sett med oppløsninger og bithastigheter som brukes til strømming, for å sikre at vi bruker båndbredde klokt og bare bruker flere biter når det er nødvendig.
Når du viser en video på Stream, kan du se de forskjellige gjengivelsene som ble opprettet for adaptiv bitrate-strømming i spilleren:
- Klikk tannhjulikonet i Stream-spilleren, og velg deretter Kvalitet.
| Eksempel | Beskrivelse | Spiller |
|---|---|---|
| Teams møteopptak | Teams møteopptak kodes med én videogjengivelse i 1080p-oppløsning. | 1080p – 574 kbps |
| Video ved behov (unntatt møteopptak) | Ikke-Teams video ved behov er kodet med en innholdsbevisst forhåndsinnstilling som velger opptil seks videogjengivelser på en intelligent måte, som vist i dette eksemplet. Høyere kompleksitetsinnhold med høy grad av farge- og bevegelsesvarians kodes med flere videogjengivelser, og mindre kompleksitetsinnhold kodes med færre. | 1080p – 3 Mbps 720p – 1,6 Mbps 540p – 989 kbps 360p – 460 kbps 270p – 327 kbps 180p – 193 kbps |
Kodingsprofil for direktesendte arrangementer
Den smarte kodingen som er oppført ovenfor, gjelder bare for videoer som lastes opp til Stream.
Direktesendte hendelser som er opprettet i Stream, eller «Ekstern app eller enhet» produserte direktesendte hendelser fra Yammer eller Microsoft Teams, får en fast kodingsprofil:
- 720p - 1,7 Mbps
- 540p - 850 kbps
- 360p – 350 kbps
- 240p - 140 kbps
Obs!
Hvis oppløsningen for inndatavideo fra koderen er 720p eller høyere, får du profilen ovenfor. Hvis du slipper oppløsningen for inndatavideo fra koderen til lavere enn 720p, får du bare utdatabitrater fra inndataoppløsningen og ned. Hvis du for eksempel har sendt 540p-oppløsning fra koderen, er 540p- til 850 kbps-versjonen den høyeste bithastigheten. Stream endrer ikke profilen for direkte koding basert på inndatabitrate fra koderen, men avkorter bare kvalitetsnivåer basert på inndataoppløsning.
Båndbreddekrav for videoavspilling
Videoavspilling i Stream er unicast, noe som betyr at alle seere får sin egen videostrøm fra Internett. Basert på smart koding og dynamisk bithastighet som strømmer brukes av Stream, er ikke båndbreddekravet for videoavspilling et statisk nummer. Avspilling av en video kan bruke ulike mengder Internett-båndbredde, avhengig av en opplastet video:
- opprinnelig oppløsning, bitrate og innhold
- brukerens tilgjengelige båndbredde
- størrelsen på spilleren
Hvis du vil utvikle noen båndbreddeberegninger, må du laste opp noen videoer som representerer det vanlige innholdet organisasjonen bruker med Stream, og se videoene på skjermstørrelser du tror vil bli brukt av brukerne. Deretter kan du gjøre noen båndbreddemålinger og prøvetaking. Deretter kan du bruke disse beregningene til å foreta noen beregninger på høyt nivå og beregne hvor mye båndbredde brukerne bruker, basert på hvor mange du tror vil se videoer samtidig.
Optimalisering av videolevering innenfor det lokale nettverket
Stream benytter smart koding og lydavspilling med tilpasset bit-hastighet for å redusere nettverks- og Internett-trafikk for videoavspilling. Avspilling er imidlertid en unicast-strøm. Direktesendinger eller videoer som sendes ut til en stor del av organisasjonen kan gjøre at seere bruker mye båndbredde.
For organisasjoner som ønsker å redusere denne Internett-trafikken for direktesendte arrangementer og populære videoer, finnes det to alternativer:
Dra nytte av eksisterende bufferproxyer i nettverket
Hvis du ser på videoer fra Stream, skjer via HTTPS, kan normale proxyer for netthurtigbuffer konfigureres til å bufre videoavspillingstrafikken. Du må kanskje konfigurere egendefinert SSL-sertifisering for å få dette til å skje med HTTPS. Hvis du ser på en nettverkssporing mens du spiller av en video, kan du imidlertid se nettadressene som Stream bruker til å strømme videoen for organisasjonen (nettadresser kan variere etter Strøm tenant). Hvis du ruter disse nettadressene gjennom bufferproxyen, kan den bufre videotrafikken og redusere Internett-trafikken for ofte avspilte videoer.
Bruke en tredjeparts løsning for eCDN-videolevering optimalisert for Strøm
Flere eCDN-løsninger for videolevering er forhåndsintegrerte og kan konfigureres til å brukes med Stream. Disse eCDN-plattformene gjør det mulig for organisasjoner å optimalisere nettverksbåndbredde uten å ofre sluttbrukeres visningsopplevelser. Partnerne våre kan bidra til å aktivere en mer skalerbar og effektiv videodistribusjon på tvers av bedriftsnettverket. Se Skalering av videolevering med tredjeparts eCDN-leverandører for mer informasjon.
Endepunkter som må nås av brukere i nettverket
Generelle Microsoft Stream-endepunkter
Microsoft Stream krever tilkobling til Internett. Alle endepunkter som er oppført Office 365 endepunkter for Microsoft Stream, må nås av brukere av Microsoft Stream i organisasjonens nettverk.
Ekstern app eller enhet produserte direktesendte hendelser (tidligere ekstern koder) – RMTP-inntak av endepunkter
Hvis du vil ha en videofeed for en ekstern app eller enhet som produseres direktesendt hendelse, sendt til Microsoft Stream fra koderen, må du ha følgende IP-områder og porter åpne i nettverkets brannmur:
- Domener: * .channel.media.azure.net
- Porter: 1935/2935/1936/2936 (for RTMP og RTMPS)
Hvis det bestemte nettverksoppsettet ikke tillater at du (eller du ikke vil) åpne domeneområdet ovenfor, er det eneste alternativet for å få bestemte IP-adresser for RTMP/RTMPS-inntaket, å få de roterende IP-områdene for Azure-datasenteret som Microsoft Stream-leieren er koblet til.
Følgende JSON-filer oppdateres etter hvert som IP-adressene for Azure-datasentre endres, brutt etter område og av de kodede tjenestene.
Offentlig: https://www.microsoft.com/download/details.aspx?id=56519
US Gov: https://www.microsoft.com/download/details.aspx?id=57063
Tyskland: https://www.microsoft.com/download/details.aspx?id=57064
Kina: https://www.microsoft.com/download/details.aspx?id=57062
Disse filene oppdateres ukentlig og inkluderer versjonskontroll både for hele filen og hver enkelt servicekode i filen.
Slik finner du Azure-datasenteret for Stream-leieren:
Klikk på ? i Strøm . øverst til høyre.
Velg Om Microsoft Stream.
Vis informasjonen i Dataene er lagret i.
Når du har funnet ut Azure-datasenteret for Stream-leieren, finner du de tilsvarende IP-områdene i XML-filen ovenfor, og deretter oppdaterer du brannmuren/proxyen med de spesifikke IP-områdene for datasenteret. Når XML-filen endres, må du også oppdatere brannmur-/proxy-innstillingene.
Eksempel:
Hvis Om Microsoft Stream sier at dataene er lagret i «Øst USA 2»
I XML-filen ser du etter en node merket <Region Name="useast2">
Under denne områdenoden vil det være flere oppføringer for alle IP-områdene ( <IpRange Subnet="13.68.0.0/17"> )
Du må konfigurere brannmuren\proxy for å tillate alle disse IP-områdene og endre dem regelmessig når XML-filen endres.
Brukere i fellesskapet har skrevet kode som etter en tidsplan tar XML-filen ovenfor og konverterer dataene til en API som kan spørres. Organisasjonen min kan lære av hva som ble gjort med dette open source-prosjektet og bygge din egen lignende løsning for å oppdatere brannmuren/proxy-innstillingene regelmessig.
Eksempel: http://iprange.omartin2010.com/
Kildekode på Github: https://github.com/omartin2010/AzureRange
CDN brukt til videoavspilling
Direktesendte hendelser fra Strømme- og Eksterne app- eller enhetshendelser fra Yammer/Teams samt behovsbasert videoer bruker automatisk Azure CDN.
Videoer som lastes opp til Stream ved behov, samt direktesendte arrangementsopptak, vil også bruke Azure CDN for avspilling, om nødvendig. Når Azure CDN ikke er nødvendig for disse videoene, vil de bli spilt av fra Azure Media Services opprinnelsesservere som er knyttet til leierens geografiske område.
Hvis flere personer fra samme organisasjon innenfor samme geografiske plassering strømmer de samme videoene, lagrer CDN-er en kopi av disse videoene på et sted nærmere det geografiske området. Når videoen er lagret eller bufret på nærmeste sted, strømmer hver person videoen fra plasseringen som er nærmest dem, i stedet for et sted lenger unna. Stream bruker Azure Media Services til å administrere hva som bufres i Azure CDN-er, og hvor lenge. Azure Media Services bruke en av de Azure CDN til å bufre videofragmenter og manifester i noen dager. Hvis personer i organisasjonen fortsetter å se de bufrede videoene, forblir de i bufferen. Hvis ingen får tilgang til videoen i flere dager, vil videoen etter hvert bli fjernet fra bufferen. Neste gang noen prøver å se videoen, bufres den igjen på nærmeste CDN plassering.
Alle som prøver å se videoen mens innholdet bufres på et nærliggende CDN, drar nytte av at videoen blir nærmere, og i de fleste tilfeller mindre hopp, borte. Dette forbedrer videoavspillingshastigheten. Det endrer imidlertid ikke nettverkskravet for å spille av videoen.
Kryptering og avspillingsflyt på videonivå
Stream vet hvor viktig det er å holde dataene dine sikre og private. Microsoft Trust Center beskriver vår forpliktelse til personvern og sikkerhet for innholdet. Med videoavspilling er hastigheten viktig for en god opplevelse. Vi går imidlertid ikke på akkord med sikkerheten eller personvernet ditt i bytte for hastighet. Slik tar vi hensyn til hastighet, sikkerhet og personvern.
Når du eller noen i organisasjonen laster opp en ny video eller oppretter en direktesendt hendelse, transkodes videoen, krypteres med AES-128-kryptering og lagres i Azure Media Services. Dette betyr at videoene krypteres både i transitt og ved hvile.
Når noen i organisasjonen prøver å se en video, følger de disse trinnene:
Stream bestemmer om visningsprogrammet har tilgang til videoen ved å kontrollere tillatelsene som er angitt for videoen i Azure SQL-databasen for Strøm og informasjon i Azure Active Directory om brukeren
Hvis brukeren har tillatelse til å vise videoen, hentes dekrypteringsnøkkelen fra Azure Media Services og gis til Stream-videospilleren
Stream-videospilleren bruker deretter dekrypteringsnøkkelen til å dekryptere videoen mens videoen spilles av
Se også
Skalering av videolevering med tredjepartsleverandører av eCDN