SRT-latensfeltet er ikke en hastighedsindstilling. Det er, hvor meget tid du giver protokollen til at opdage, at en pakke forsvandt, bede om den igen, og få den tilbage, før billedet skal bruge den. Sæt den for lavt, og streamen fryser på hvert dårligt sekund af mobilnet. Sæt den fornuftigt, og det samme dårlige sekund er usynligt.
Til IRL er det fornuftige tal større end studietallet. Her er, hvad det gør, hvad du skal skrive ind, og hvordan du finder ud af, om det er det, der skal ændres.
Hvad tallet egentlig er
SRT kører over UDP. Når en pakke går tabt, ser modtageren hullet og beder afsenderen om den pakke igen. Latensværdien er, hvor længe modtageren er villig til at vente på det svar, før den må give op og afspille det, den har. Alt, der ankommer inden for vinduet, sættes tilbage i rækkefølge, og seeren ser aldrig tabet. Alt, der rammer forbi vinduet, kasseres, og det er den frysning eller det klodsede rod, du ser på en ustabil forbindelse.
Vinduet skal altså være bredere end en fuld tur-retur, med plads til mere end ét forsøg. Haivision, der skrev protokollen, formulerer det som et multiplum af round trip-tiden: cirka tre til fire gange på et rent link, og mere efterhånden som pakketabet stiger.
Det, folk overser, er, at det er en tosidig indstilling. Din encoder angiver en latens, relayet angiver en, og håndtrykket bruger den største af de to. At skrue din encoder ned under relayets værdi ændrer ingenting, og at skrue den op får altid effekt.
Hvorfor IRL-tallet er større
Et kablet studielink har en stabil tur-retur. En telefon, der går gennem en by, har ikke. Den gennemsnitlige tur-retur til et nærliggende relay kan ligge under et tiendedels sekund, men et masteskift, en overfyldt celle eller et modem, der vågner igen, kan skubbe en enkelt tur-retur forbi et halvt sekund og stable et par af dem i træk. Vinduet er ikke dimensioneret til gennemsnittet. Det er dimensioneret til spidsen.
Med SRTLA-bonding har det samme vindue et job mere. SRTLA spreder dine pakker over hvert modem, du har. Når ét modem går i sort, er de pakker, der var undervejs på det, væk, og SRT beder om dem igen. SRTLA sender de gentagne forsøg over de modemer, der stadig er sunde. Latensvinduet er tidsbudgettet for den omdirigering. Et snævert vindue betyder, at et dødt modem koster dig en frysning, selv om du har to mere, der virker. Et rummeligt vindue betyder, at det ikke koster dig noget synligt. Det er størstedelen af grunden til, at bonding føles så meget mere jævn end et enkelt SRT-link på den samme telefon.
Hvad du skal sætte
| Hvor | Indstilling | Bemærkninger |
|---|---|---|
| Belabox (SRTLA) | 2000 ms | Standardværdien. Gå op, ikke ned, hvis en rute er ustabil. |
| Moblin på iPhone (SRTLA) | 3000 ms | Standardværdien. Lad den stå; den ligger allerede i den rummelige ende. |
| IRL Pro på Android (SRTLA) | 2000 ms | Samme felt som Belabox, samme udgangspunkt. |
| LiveU Solo Pro (SRT) | 2500 ms | Det, dashboardet viser for denne encoder. |
| Larix (SRT) | 2500 ms | Sættes automatisk, når du åbner forbindelsen fra dashboardet. |
| OBS-mediekilde, der henter relayet | latency=2000000 | Mikrosekunder, ikke millisekunder. Dette er to sekunder. |
Hvis du kun tager én ting med fra tabellen: der er ingen god grund til at gå under 2000 ms på en mobil rute, og sjældent nogen grund til at gå over 4000 ms. Derimellem er højere sikrere, og prisen er brøkdele af et sekunds forsinkelse, som ingen i chatten kan mærke.
OBS-siden regner i mikrosekunder
OBS læser SRT gennem FFmpeg, og FFmpegs latensindstilling er i mikrosekunder. To sekunder er 2000000. Skriver du 2000, får du to millisekunder, hvilket slet ikke er noget genopretningsvindue, og hentningen vil hakke selv på en perfekt hjemmeforbindelse. Hele hentnings-URL'en står i OBS-opsætningsguiden.
At læse symptomerne
De fleste latensspørgsmål er i virkeligheden "noget er galt, er det den her knap". Som regel er det én af tre ting, og kun én af dem er latensen.
| Det du ser | Hvad det betyder | Hvad du skal ændre |
|---|---|---|
| Korte frysninger eller klodsede billeder, mens bitrate-grafen holder sig sund | Pakker rammer forbi vinduet | Hæv SRT-latensen med 500 ms og test igen |
| Bitraten falder, og billedet bliver blødere, men det bliver ved med at bevæge sig | Den adaptive bitrate gør sit arbejde på et tyndt link | Ingenting med latensen. Det er afvejningen, der virker. |
| Streamen slutter helt | Forbindelsen døde, ikke bufferen | Afbrydelsesbeskyttelse: din egen OBS, der holder udsendelsen. Se hold din stream live. |
Den første række er den eneste, latensindstillingen løser. Den anden række er normal, og den tredje er et helt andet problem. At hæve latensen for at bekæmpe en afbrydelse gør ingenting, fordi der ikke er nogen forbindelse tilbage at genoprette på.
SRT-latens er ikke din seerforsinkelse
Vinduet på din encoder er ét hop i en kæde. Relayet afleverer streamen til din OBS over et andet SRT-hop med sit eget vindue. OBS holder en netværksbuffer, encoder, og sender til platformen. Platformen tager imod, transkoder, og afspilleren buffrer oven i det.
| Trin | Cirka |
|---|---|
| SRT-vindue i encoderen | 2 til 3 s |
| SRT-vindue relay til OBS | 2 s |
| OBS netværksbuffer og encoding | under 1 s |
| Platformens ingest, transkodning, afspiller | flere sekunder |
At skære den første række fra 2500 til 1000 sparer halvandet sekund ud af en kæde, der er væsentligt længere end det, og du køber det sekund med hver frysning, vinduet ikke længere kan absorbere. Folk tilgiver en kort forsinkelse. De går, når billedet bliver ved med at stoppe. Hvis chat-timing virkelig betyder noget for et segment, flytter platformens lavlatens-tilstand totalen langt mere, end SRT-tallet gør.
Hvordan du justerer uden at gætte
- Sæt encoderen til tallet fra tabellen, og lad den være.
- Stream den værste del af din rute: tunnelen, menneskemængden, togperronen. Ikke din stue.
- Fryser billedet, mens bitraten holder, så hæv latensen med 500 ms og kør den samme rute igen.
- Skift én ting ad gangen. Latens, bitrate og opløsning flytter alle de samme symptomer, og at justere to sammen fortæller dig ingenting.
- Behold den lokale optagelse. Se bevægelsen og lyden igennem bagefter i stedet for at stole på et grønt tal i et dashboard.
Relayet er den anden halvdel af indstillingen
Din encoder bestemmer kun den ene side. Vores relay kører som standard en rummelig latensprofil, bygget til bondede mobile uplinks snarere end et studielink, så en fornuftig encoder-værdi lander hos en modtager, der forventer barske forhold. Kombinér det med at hente relayet ind i din egen OBS, så holder feltforbindelsen op med at være det, der afslutter din udsendelse.
Stadig i tvivl om protokol? SRTLA vs RTMP tager, hvornår SRT alene er nok, og hvornår du har brug for bonding.
FAQ
- Hvilken SRT-latens skal jeg bruge til IRL-streaming?
- Start på 2000 til 2500 ms på encoder-siden, og lad den stå, indtil streamen har vist sig stabil på den værste del af din rute. Belabox står som standard på 2000 ms og Moblin på 3000 ms, og begge er fine, som de er. Vores dashboard uddeler 2500 ms til SRT-encodere med én forbindelse, som LiveU Solo Pro og Larix.
- Skal SRT-latensen matche i begge ender?
- Nej. Begge ender angiver en værdi i håndtrykket, og forbindelsen bruger den største. Derfor gør det ingenting at sætte din encoder lavere end det, relayet bruger, og derfor kan OBS-hentningen justeres separat fra encoder-siden.
- Får 2500 ms min stream til at føles langsom for chatten?
- Ikke mærkbart. SRT-vinduet er ét led i en kæde, der allerede indeholder et andet SRT-hop ind i OBS, OBS' egen buffer, og platformens ingest- og afspillerforsinkelse. At halvere encoder-vinduet sparer omkring et sekund ud af en kæde, der er væsentligt længere end det.
- Hvorfor vil OBS-mediekilden have 2000000 i stedet for 2000?
- OBS læser SRT-URL'en gennem FFmpeg, og FFmpeg tager latens i mikrosekunder. 2000000 er to sekunder. Skriver du 2000 der, får du to millisekunder, hvilket reelt slet ikke er noget genopretningsvindue.