SRT-latensrutan är inte en hastighetsinställning. Det är hur mycket tid du ger protokollet att märka att ett paket försvann, be om det igen, och få tillbaka det innan bilden behöver det. Sätter du den för lågt fryser streamen på varje dålig sekund av mobilnät. Sätter du den vettigt är samma dåliga sekund osynlig.
För IRL är den vettiga siffran större än studiosiffran. Här är vad den gör, vad du ska skriva in, och hur du avgör om det är den här som behöver ändras.
Vad siffran egentligen är
SRT går över UDP. När ett paket tappas ser mottagaren luckan och ber avsändaren om det paketet igen. Latensvärdet är hur länge mottagaren är villig att vänta på det svaret innan den måste ge upp och spela det den har. Allt som kommer inom fönstret sätts tillbaka i rätt ordning och tittaren ser aldrig förlusten. Allt som missar fönstret kastas, och det är frysningen eller klossmoraset du ser på en skakig anslutning.
Fönstret måste alltså vara bredare än en full tur och retur, med utrymme för mer än ett försök. Haivision, som skrev protokollet, uttrycker det som en multipel av round trip-tiden: ungefär tre till fyra gånger på en ren länk, och mer allteftersom paketförlusten stiger.
Det folk missar är att det är en tvåsidig inställning. Din encoder anger en latens, relayen anger en, och handskakningen använder den största av de två. Att skruva ner din encoder under relayens värde ändrar ingenting, och att skruva upp den får alltid effekt.
Varför IRL-siffran är större
En trådbunden studiolänk har jämn tur och retur. En telefon som går genom en stad har inte det. Genomsnittlig tur och retur till en närliggande relay kan ligga under en tiondels sekund, men ett mastbyte, en trängd cell, eller ett modem som vaknar igen kan trycka en enskild tur och retur förbi en halv sekund och stapla ett par sådana i rad. Fönstret dimensioneras inte för genomsnittet. Det dimensioneras för toppen.
Med SRTLA-bonding har samma fönster ett jobb till. SRTLA sprider dina paket över varje modem du har. När ett modem tystnar är paketen som var på väg där borta, och SRT ber om dem igen. SRTLA skickar de omförsöken över de modem som fortfarande är friska. Latensfönstret är tidsbudgeten för den omdirigeringen. Ett trångt fönster betyder att ett dött modem kostar dig en frysning trots att du har två till som fungerar. Ett rymligt fönster betyder att det inte kostar dig något synligt. Det är största delen av varför bonding känns så mycket jämnare än en enda SRT-länk på samma telefon.
Vad du ska sätta
| Var | Inställning | Kommentar |
|---|---|---|
| Belabox (SRTLA) | 2000 ms | Standardvärdet. Gå upp, inte ner, om en rutt är skakig. |
| Moblin på iPhone (SRTLA) | 3000 ms | Standardvärdet. Låt det stå; det ligger redan på den rymliga sidan. |
| IRL Pro på Android (SRTLA) | 2000 ms | Samma fält som Belabox, samma utgångspunkt. |
| LiveU Solo Pro (SRT) | 2500 ms | Det dashboarden visar för den här encodern. |
| Larix (SRT) | 2500 ms | Sätts automatiskt när du öppnar anslutningen från dashboarden. |
| OBS mediakälla som hämtar relayen | latency=2000000 | Mikrosekunder, inte millisekunder. Det här är två sekunder. |
Om du bara tar med dig en sak från tabellen: det finns ingen bra anledning att gå under 2000 ms på en mobil rutt, och sällan någon anledning att gå över 4000 ms. Däremellan är högre säkrare, och priset är bråkdelar av en sekunds fördröjning som ingen i chatten känner av.
OBS-sidan räknar i mikrosekunder
OBS läser SRT genom FFmpeg, och FFmpegs latensalternativ är i mikrosekunder. Två sekunder är 2000000. Skriver du 2000 får du två millisekunder, vilket inte är något återhämtningsfönster alls, och hämtningen kommer att hacka även på en perfekt hemuppkoppling. Hela hämtnings-URL:en finns i OBS-guiden.
Att läsa symptomen
De flesta latensfrågor är egentligen "något är fel, är det den här ratten". Oftast är det en av tre saker och bara en av dem är latensen.
| Det du ser | Vad det betyder | Vad du ska ändra |
|---|---|---|
| Korta frysningar eller klossiga bildrutor medan bitrate-grafen håller sig frisk | Paket missar fönstret | Höj SRT-latensen med 500 ms och testa igen |
| Bitraten faller och bilden blir mjukare, men den fortsätter röra sig | Den adaptiva bitraten gör sitt jobb på en tunn länk | Ingenting med latensen. Det här är avvägningen som fungerar. |
| Streamen avslutas helt | Anslutningen dog, inte bufferten | Avbrottsskydd: din egen OBS som håller sändningen. Se håll din stream live. |
Första raden är den enda som latensinställningen fixar. Andra raden är normal och tredje raden är ett helt annat problem. Att höja latensen för att bekämpa en frånkoppling gör ingenting, eftersom det inte finns någon anslutning kvar att återhämta sig på.
SRT-latens är inte din tittarfördröjning
Fönstret på din encoder är ett hopp i en kedja. Relayen lämnar streamen till din OBS över ett andra SRT-hopp med sitt eget fönster. OBS håller en nätverksbuffert, encodar, och skickar till plattformen. Plattformen tar emot, transkodar, och spelaren buffrar ovanpå det.
| Steg | Ungefär |
|---|---|
| SRT-fönster i encodern | 2 till 3 s |
| SRT-fönster relay till OBS | 2 s |
| OBS nätverksbuffert och encoding | under 1 s |
| Plattformens ingest, transkodning, spelare | flera sekunder |
Att kapa första raden från 2500 till 1000 sparar en och en halv sekund ur en kedja som är betydligt längre än så, och du köper den sekunden med varje frysning som fönstret inte längre kan absorbera. Folk förlåter en kort fördröjning. De lämnar när bilden hela tiden stannar. Om chat-timing verkligen spelar roll för ett segment flyttar plattformens lågfördröjningsläge totalen långt mer än SRT-siffran gör.
Hur du justerar utan att gissa
- Sätt encodern till siffran från tabellen och låt den vara.
- Streama den värsta delen av din rutt: tunneln, folkmassan, tågperrongen. Inte ditt vardagsrum.
- Fryser bilden medan bitraten håller, höj latensen med 500 ms och kör samma rutt igen.
- Ändra en sak i taget. Latens, bitrate och upplösning flyttar alla samma symptom, och att justera två samtidigt säger dig ingenting.
- Behåll den lokala inspelningen. Titta på rörelsen och ljudet i efterhand i stället för att lita på en grön siffra i en dashboard.
Relayen är den andra halvan av inställningen
Din encoder bestämmer bara ena sidan. Vår relay kör som standard en rymlig latensprofil, byggd för bondade mobila upplänkar snarare än en studiolänk, så ett vettigt encoder-värde landar hos en mottagare som förväntar sig tuffa förhållanden. Kombinera det med att hämta in relayen i din egen OBS så slutar fältanslutningen vara det som avslutar din sändning.
Fortfarande osäker på protokoll? SRTLA vs RTMP tar när SRT ensamt räcker och när du behöver bonding.
FAQ
- Vilken SRT-latens ska jag använda för IRL-streaming?
- Börja på 2000 till 2500 ms på encoder-sidan och låt den stå tills streamen visat sig stabil på den värsta delen av din rutt. Belabox står som standard på 2000 ms och Moblin på 3000 ms, och båda är bra som de är. Vår dashboard delar ut 2500 ms till SRT-encoders med en anslutning, som LiveU Solo Pro och Larix.
- Måste SRT-latensen matcha i båda ändar?
- Nej. Båda ändar anger ett värde i handskakningen och anslutningen använder det största. Därför gör det ingenting att sätta din encoder lägre än vad relayen använder, och därför kan OBS-hämtningen justeras separat från encoder-sidan.
- Får 2500 ms streamen att kännas långsam för chatten?
- Inte märkbart. SRT-fönstret är en bit av en kedja som redan innehåller ett andra SRT-hopp in i OBS, OBS egen buffert, och plattformens ingest- och spelarfördröjning. Att halvera encoder-fönstret sparar ungefär en sekund ur en kedja som är betydligt längre än så.
- Varför vill OBS mediakälla ha 2000000 i stället för 2000?
- OBS läser SRT-URL:en genom FFmpeg, och FFmpeg tar latens i mikrosekunder. 2000000 är två sekunder. Skriver du 2000 där får du två millisekunder, vilket i praktiken inte är något återhämtningsfönster alls.