SRT-latensfeltet er ikke en hastighetsinnstilling. Det er hvor mye tid du gir protokollen til å oppdage at en pakke forsvant, be om den på nytt, og få den tilbake før bildet trenger den. Sett den for lavt, og streamen fryser på hvert dårlige sekund med mobilnett. Sett den fornuftig, og det samme dårlige sekundet er usynlig.
For IRL er det fornuftige tallet større enn studiotallet. Her er hva det gjør, hva du skal skrive inn, og hvordan du ser om det er dette som må endres.
Hva tallet egentlig er
SRT går over UDP. Når en pakke går tapt, ser mottakeren hullet og ber avsenderen om den pakken på nytt. Latensverdien er hvor lenge mottakeren er villig til å vente på det svaret før den må gi opp og spille det den har. Alt som kommer innenfor vinduet, settes tilbake i riktig rekkefølge, og seeren ser aldri tapet. Alt som bommer på vinduet, forkastes, og det er frysingen eller klosseflekken du ser på en røff forbindelse.
Vinduet må altså være bredere enn en full rundtur, med rom for mer enn ett forsøk. Haivision, som skrev protokollen, uttrykker det som et multiplum av rundturstiden: omtrent tre til fire ganger på en ren link, og mer etter hvert som pakketapet stiger.
Det folk overser, er at dette er en tosidig innstilling. Encoderen din oppgir en latens, relayet oppgir en, og håndtrykket bruker den største av de to. Å skru encoderen ned under relayets verdi endrer ingenting, og å skru den opp får alltid effekt.
Hvorfor IRL-tallet er større
En kablet studiolink har jevn rundtur. En telefon som går gjennom en by har ikke det. Gjennomsnittlig rundtur til et relay i nærheten kan være under en tidels sekund, men et mastebytte, en overfylt celle, eller et modem som våkner igjen, kan dytte én rundtur forbi et halvt sekund og stable noen av dem på rad. Vinduet er ikke dimensjonert for gjennomsnittet. Det er dimensjonert for toppen.
Med SRTLA-bonding har det samme vinduet en jobb til. SRTLA sprer pakkene dine over alle modemene du har. Når ett modem blir mørkt, er pakkene som var underveis på det borte, og SRT ber om dem på nytt. SRTLA sender de nye forsøkene over modemene som fortsatt er friske. Latensvinduet er tidsbudsjettet for den omrutingen. Et trangt vindu betyr at et dødt modem koster deg en frys selv om du har to til som virker. Et romslig vindu betyr at det ikke koster deg noe synlig. Det er hovedgrunnen til at bonding føles så mye jevnere enn én SRT-link på den samme telefonen.
Hva du skal sette
| Hvor | Innstilling | Merknader |
|---|---|---|
| Belabox (SRTLA) | 2000 ms | Standardverdien. Gå opp, ikke ned, hvis en rute er røff. |
| Moblin på iPhone (SRTLA) | 3000 ms | Standardverdien. La den stå; den er allerede på den romslige siden. |
| IRL Pro på Android (SRTLA) | 2000 ms | Samme felt som Belabox, samme utgangspunkt. |
| LiveU Solo Pro (SRT) | 2500 ms | Det dashbordet viser for denne encoderen. |
| Larix (SRT) | 2500 ms | Settes automatisk når du åpner forbindelsen fra dashbordet. |
| OBS-mediekilde som henter relayet | Ingenting å legge til | Relayet setter minst 1000 ms. Vil du høyere, legger du til latency i mikrosekunder: 2000000 er to sekunder. |
Hvis du bare tar med deg én ting fra tabellen: det finnes ingen god grunn til å gå under 2000 ms på en mobilrute, og sjelden noen grunn til å gå over 4000 ms. Mellom de to er høyere tryggere, og prisen er brøkdeler av et sekund forsinkelse som ingen i chatten kjenner.
OBS-siden trenger ingen latensinnstilling
Relayet gir hver OBS-uthenting minst ett sekund latens, så uthentings-URL-en fra dashbordet trenger ingen latensparameter. Fryser bildet i OBS mens strømmen kommer fram til relayet i god stand, kan du øke vinduet i URL-en. OBS leser SRT gjennom FFmpeg, og FFmpegs latens-opsjon er i mikrosekunder, så to sekunder er &latency=2000000. En verdi som 2000 betyr to millisekunder, og relayets gulv overstyrer den. Hele uthentings-URL-en står i OBS-oppsettsguiden.
Å lese symptomene
De fleste latensspørsmål er egentlig "noe er galt, er det denne knappen". Som regel er det én av tre ting, og bare én av dem er latensen.
| Det du ser | Hva det betyr | Hva du skal endre |
|---|---|---|
| Korte frys eller klossete bilder mens bitrate-grafen holder seg frisk | Pakker bommer på vinduet | Hev SRT-latensen med 500 ms og test på nytt |
| Bitraten faller og bildet blir mykere, men det fortsetter å bevege seg | Den adaptive bitraten gjør jobben sin på en tynn link | Ingenting med latensen. Dette er avveiningen som virker. |
| Streamen avsluttes helt | Forbindelsen døde, ikke bufferen | Bruddbeskyttelse: din egen OBS som holder sendingen. Se hold streamen live. |
Den første raden er den eneste latensinnstillingen fikser. Den andre raden er normal, og den tredje er et helt annet problem. Å heve latensen for å bekjempe en frakobling gjør ingenting, fordi det ikke er noen forbindelse igjen å gjenopprette på.
SRT-latens er ikke seerforsinkelsen din
Vinduet på encoderen din er ett hopp i en kjede. Relayet leverer streamen til OBS-en din over et nytt SRT-hopp med sitt eget vindu. OBS holder en nettverksbuffer, encoder, og sender til plattformen. Plattformen tar imot, transkoder, og spilleren buffrer på toppen av det.
| Trinn | Omtrent |
|---|---|
| SRT-vindu i encoderen | 2 til 3 s |
| SRT-vindu relay til OBS | 2 s |
| OBS nettverksbuffer og encoding | under 1 s |
| Plattform-ingest, transkoding, spiller | flere sekunder |
Å kutte den første raden fra 2500 til 1000 sparer halvannet sekund av en kjede som er langt lengre enn det, og du kjøper det sekundet med hver frys vinduet ikke lenger kan absorbere. Folk tilgir en kort forsinkelse. De drar når bildet stadig stopper. Hvis chat-timing genuint betyr noe for et segment, flytter plattformens lavlatens-modus totalen langt mer enn SRT-tallet gjør.
Hvordan du justerer uten å gjette
- Sett encoderen til tallet fra tabellen og la den være.
- Stream den verste delen av ruten din: tunnelen, folkemengden, togperrongen. Ikke stua di.
- Fryser bildet mens bitraten holder, hev latensen med 500 ms og kjør den samme ruten igjen.
- Endre én ting av gangen. Latens, bitrate og oppløsning flytter alle de samme symptomene, og å justere to samtidig forteller deg ingenting.
- Behold det lokale opptaket. Se på bevegelsen og lyden i etterkant i stedet for å stole på et grønt tall i et dashbord.
Relayet er den andre halvdelen av innstillingen
Encoderen din bestemmer bare den ene siden. Relayet vårt kjører som standard en romslig latensprofil, bygget for bondede mobile opplinker heller enn en studiolink, så en fornuftig encoder-verdi lander på en mottaker som forventer røffe forhold. Kombiner det med å hente relayet inn i din egen OBS, så slutter feltforbindelsen å være det som avslutter sendingen din.
Fortsatt usikker på protokoll? SRTLA vs RTMP tar når SRT alene holder og når du trenger bonding.
FAQ
- Hvilken SRT-latens bør jeg bruke til IRL-streaming?
- Start på 2000 til 2500 ms på encoder-siden, og la den stå til streamen har vist seg stabil på den verste delen av ruten din. Belabox står som standard på 2000 ms og Moblin på 3000 ms, og begge er fine som de er. Dashbordet vårt deler ut 2500 ms til SRT-encodere med én forbindelse, som LiveU Solo Pro og Larix.
- Må SRT-latensen være lik i begge ender?
- Nei. Begge ender oppgir en verdi i håndtrykket, og forbindelsen bruker den største. Det er derfor det ikke gjør noe å sette encoderen din lavere enn det relayet bruker, og derfor OBS-uthentingen kan justeres separat fra encoder-siden.
- Gjør 2500 ms at streamen føles treg for chatten?
- Ikke merkbart. SRT-vinduet er én bit av en kjede som allerede inneholder et nytt SRT-hopp inn i OBS, OBS sin egen buffer, og plattformens ingest- og spillerforsinkelse. Å halvere encoder-vinduet sparer omtrent ett sekund av en kjede som er langt lengre enn det.
- Må jeg legge til latens i URL-en til OBS-mediekilden?
- Nei. Relayet gir hver OBS-uthenting minst ett sekund latens, så URL-en fra dashbordet virker som den er. Vil du ha et større vindu, legger du til latens i mikrosekunder, fordi OBS leser SRT gjennom FFmpeg: 2000000 er to sekunder. Et lite tall som 2000 gjør ingenting, fordi relayets gulv på ett sekund vinner.