Till senaste kommentaren

SR och de nya direktströmmarna under HLS

Sveriges Radio har infört kvalitetsvalen Låg, Mellan och Hög för direktsänd radio. Enligt er information motsvarar dessa 32, 128 respektive 192 kbit/s AAC, medan Hög för P2, P3 och P4 Plus innebär 320 kbit/s.

Samtidigt skriver ni att kvaliteten tillfälligt kan sänkas om uppkopplingen försämras. Det innebär att ”Hög” inte nödvändigtvis är en fast bitrate utan en önskad högsta nivå i en adaptiv HLS-ström.

För att kunna bedöma den verkliga ljudkvaliteten och funktionen i mobilnät skulle jag uppskatta ett tekniskt svar med faktiska eller åtminstone ungefärliga värden på följande punkter:

  1. Är Låg, Mellan och Hög fasta kvalitetsval eller endast mål-/maxnivåer?
  2. Kan samtliga tre inställningar växla ned automatiskt, eller gäller automatisk nedväxling endast när Hög är valt?
  3. Vilka steg används vid adaptiv växling? Växlar exempelvis P2 från 320 till 128 och därefter till 32 kbit/s, eller finns även mellanliggande nivåer?
  4. Vilka faktiska villkor utlöser en nedväxling?
    • Uppmätt tillgänglig datahastighet
    • Förhållandet mellan datahastigheten och den valda ljudströmmens bitrate
    • Framåtbuffertens återstående längd i sekunder
    • Paketförluster, variationer eller tidigare avbrott
    • Hur lång mätperiod som används
  5. Hur fungerar hysteresen? Hur länge måste förbindelsen vara försämrad innan kvaliteten sänks, och hur länge måste den åter vara stabil innan strömmen går tillbaka till exempelvis 320 kbit/s?
  6. Hur stor är den normala framåtbufferten i sekunder vid direktlyssning på:
    • iPhone/iOS
    • Android
    • SR:s webbspelare?
  7. Förändras buffertens storlek beroende på vald bitrate eller nätförhållandena?
  8. Vad händer när lyssnaren pausar eller backar i direktsändningen? SR erbjuder upp till tre timmars tillbakalyssning, men det är viktigt att skilja mellan:
    • tillgängligt material bakåt på servern
    • redan spelat material i telefonens lokala minne
    • ospelat ljud i framåtbufferten
Om jag exempelvis lyssnar 15 minuter efter direktsändningen, hämtar appen då en större mängd ljud i förväg i vald kvalitet, eller behåller den ungefär samma korta framåtbuffert som vid lyssning nära direktsändningspunkten?

  1. Om ett ljudsegment redan har hämtats i 320 kbit/s, ligger det kvar i den kvaliteten även om nätet därefter försämras? Om man söker bakåt till material som inte längre finns lokalt, kan samma programdel då hämtas på nytt i 128 eller 32 kbit/s?
  2. Finns det något sätt för lyssnaren att se vilken bitrate som faktiskt används för tillfället? Annars kan appen omärkligt spela 128 eller 32 kbit/s trots att användaren har valt Hög.
Spotify skiljer mellan automatisk kvalitet och en vald kvalitet samt har en separat funktion för automatisk kvalitetsanpassning som kan stängas av. Hos SR förefaller automatiken alltid vara aktiv. Har ni övervägt ett verkligt fast val, exempelvis:

”Fast 320 kbit/s – behåll vald kvalitet och använd större buffert; acceptera hellre tillfällig väntan än automatisk kvalitetsförsämring”?

En sådan möjlighet vore särskilt värdefull för P2 och annan kvalitetskritisk musiklyssning. En inställbar framåtbuffert, exempelvis 15, 30 eller 75 sekunder, skulle också kunna ge stabil 320 kbit/s-kvalitet vid korta svackor i mobilnätet.

Jag är framför allt intresserad av de verkliga tröskelvärdena, bufferttiderna och hysteresen. Ett allmänt svar om att kvaliteten ”anpassas efter uppkopplingen” förklarar inte när eller hur länge ljudkvaliteten faktiskt sänks.

BBC skiljer tekniskt mellan fasta HLS-profiler på 128 och 320 kbit/s AAC-LC och en separat adaptiv 128–320 kbit/s-ström. Har SR övervägt motsvarande tydliga uppdelning, så att lyssnaren kan välja mellan automatisk anpassning och en verkligt fast 320 kbit/s-ström?

Vänliga hälsningar

Lars Mossberg
Lars Mossberg

Kommentarer

  • Tack Lars!
    Detta är intressanta frågor, där vi dessutom är mitt uppe i en förändring där vi kommer att landa i delvis andra kvaliteter, så jag behöver ta hjälp av kolleger på olika avdelningar innan jag kan svara.
    Annika Webbmaster
  • Jag börjar med ett förtydligande som jag kan svara på själv. Alternativen Låg, Mellan och Hög finns för HLS endast i mobilappen. På webben finns det endast möjligheten att välja mellan Adaptiv (som vid normal uppkoppling motsvarar appens Hög) och Begränsad för den som vill spara in på dataförbrukningen.

    På en bredare skärm ligger inställningen under kugghjulet,. På smala fönster (som mobiler och surfplattor, till höger på bilden nedan) finns inställningen direkt nedanför play-knappen i "storspelaren"::

    Annika Webbmaster
  • Hej igen!

    Här ett försök till svar, som en av dina forna kolleger hjälpt mig med:
    1. Är Låg, Mellan och Hög fasta kvalitetsval eller endast mål-/maxnivåer?
    När vi talar om ”Direktlyssning” i apparna så är det en maxnivå. På sverigesradio.se kan man bara välja ”Automatisk” (max) eller ”Begränsad” (låg). Efterhandslyssning och poddar är i dagsläget fasta kvalitétsval då HLS inte används de publiceringarna.
    1. Kan samtliga tre inställningar växla ned automatiskt, eller gäller automatisk nedväxling endast när Hög är valt?
    ”Hög” och ”Mellan” kan växla till lägre kvalitéer, väljs ”Låg” finns ingen lägre kvalité att växla till.
    1. Vilka steg används vid adaptiv växling? Växlar exempelvis P2 från 320 till 128 och därefter till 32 kbit/s, eller finns även mellanliggande nivåer?
    Hur spelaren växlar mellan kvalitéer är upp till spelaren. Olika spelare tillämpar olika algoritmer för växling mellan de kvalitéer som finns och dessutom så tekniker beroende på vilket läge de är i, t.ex. ”uppstart” eller ”spelarläge”. I huvudsak använder vi tre olika grundspelare, Media3 för vår app i Android, AVPlayer för vår app i iOS/Apple, samt HLS.js för sverigesradio.se. Både Media3 och HLS.js har öppen källkod för de bibliotek som används för att växla mellan olika HLS-kvalitéer i live-läge om du är intresserad av att ljupdyka inom detta område.
    1. Vilka faktiska villkor utlöser en nedväxling?
      • Uppmätt tillgänglig datahastighet
      • Förhållandet mellan datahastigheten och den valda ljudströmmens bitrate
      • Framåtbuffertens återstående längd i sekunder
      • Paketförluster, variationer eller tidigare avbrott
      • Hur lång mätperiod som används
    Varierar mellan olika spelare, se svar på 3) ovan.
    1. Hur fungerar hysteresen? Hur länge måste förbindelsen vara försämrad innan kvaliteten sänks, och hur länge måste den åter vara stabil innan strömmen går tillbaka till exempelvis 320 kbit/s?
    Återigen, beror på spelare, se svar på 3) ovan.
    1. Hur stor är den normala framåtbufferten i sekunder vid direktlyssning på:
      • iPhone/iOS
      • Android
      • SR:s webbspelare?
    Rekommendationen för HLS-protokollet är att spelaren buffrar minst tre mediasegment innan uppspelning. I dagsläget använder vi 6,4 sekunder långa mediasegment för majoriteten av våra live-kanaler, dvs spelaren bör buffra minst 19,2 sekunder.
    1. Förändras buffertens storlek beroende på vald bitrate eller nätförhållandena?
    Inte av bitrate men om nätförhållanden försämras kan bufferten minska (vilket är huvudanledningen till att spelaren håller en viss buffert).
    1. Vad händer när lyssnaren pausar eller backar i direktsändningen? SR erbjuder upp till tre timmars tillbakalyssning, men det är viktigt att skilja mellan:
      • tillgängligt material bakåt på servern
      • redan spelat material i telefonens lokala minne
      • ospelat ljud i framåtbufferten
    Om jag exempelvis lyssnar 15 minuter efter direktsändningen, hämtar appen då en större mängd ljud i förväg i vald kvalitet, eller behåller den ungefär samma korta framåtbuffert som vid lyssning nära direktsändningspunkten?

    Ja den hämtar mer men återigen upp till spelaren. T.ex. på sverigesradio.se har vi en maxBufferLength på 60 sekunder även om det skulle vara tekniskt möjligt att buffra mer.
    1. Om ett ljudsegment redan har hämtats i 320 kbit/s, ligger det kvar i den kvaliteten även om nätet därefter försämras? Om man söker bakåt till material som inte längre finns lokalt, kan samma programdel då hämtas på nytt i 128 eller 32 kbit/s?
    Det finns ingen anledning för spelaren att växla ned på kvalitéer som den redan har lokalt. Nedväxlingen sker om spelaren inte förmår att ladda hem den högre kvalitén, men återigen, detaljerna för detta skiljer sig åt beroende på implementation.
    1. Finns det något sätt för lyssnaren att se vilken bitrate som faktiskt används för tillfället? Annars kan appen omärkligt spela 128 eller 32 kbit/s trots att användaren har valt Hög.
    Vi har inte implementerat något sådan funktionalitet.
    Annika Webbmaster
  • Tack, snabbt svar och bra och tydligt svar men huvudproblemet kvarstår. Att jag inte garanteras den ljudkvalitét jag valt.

    Bra funktion när man är ute och rör på sig för att säkra mottagningen men man måste även kunna välja garanterad kvalitét även i mobilen

    Både DR, NRK och BBC har löst detta även om dom gjort det på en sämre kvalitét.

    Spotify har gjort det men där är allt ljud färdigt på fil

    Lars
    Lars Mossberg
  • Vill du vara helt säker på att få en given kvalitet, så använd våra direktlänkar ihop med t ex VLC. I VLC kan du dessutom öka latensen/bufferten ifall du märker att det behövs:
    1. Gå in under Inställningar i appens nederkant
    2. Skrolla ned till Nätverk -> Cachenivå för nätverk
    3. Välj alternativet Högst latens, vilket ger viss eftersläpning i uppspelningen, men samtidigt minskar risken för avbrott
    Kan det funka för ditt behöv?
    Annika Webbmaster
  • Hej igen!

    Ett alternativt och smidigt sätt att själv skaffa sig en större buffert är att använda våra HLS-strömmar i hög kvalitet i appen eller på webben, och sen backa kanske 30 sekunder.

    OM det trots allt skulle bli avbrott så stryps kvaliteten tillfällig, men risken för detta minskar. I fall du tycker att försämrad kvalitet är mer störande än rena avbrott, är det istället bättre att lyssna med direktlänkarna och ökad buffert, som alltså går att ställa in i t ex VLC.

    För spelare som inte har sådana inställningar får du liknande effekt genom att lägga till parametern latency=high i slutet av länken, till exempel:
    https://live1.sr.se/p2-aac-320?latency=high 

    Den "flaggan" gör så att servern försöker skicka en större mängd data som buffert till spelaren, sen är det upp till spelaren att hantera bufferten på rätt sätt.

    En annan aspekt att ha med är att direktlänkarna bör vara känsligare för temporära nätverksproblem än vad HLS är. HLS har många korta anslutningar medan direktlänkar har en fast anslutning som kan störas och brytas.

    Sammanfattning:
    • Backad kanal i Sveriges Radio-appen ger en extra buffert som minskar risken för avbrott vid sämre uppkoppling. Om bufferten ändå inte räcker till kommer kvaliteten att tillfälligt sänkas
    • Direktlänkar med ökad buffert ger garanterat önskad kvalitet. Om denna buffert inte räcker till så blir det avbrott. Den kontinuerliga strömmen är dessutom mer känslig än "HLS-chunkarna" för nätverksproblem.
    De flesta lyssnare föredrar "dämpad kvalitet" framför "avbrott".
    Annika Webbmaster
  • Före övergången till adaptiv HLS fungerade det mer som du beskriver: hade man valt en fast ström på exempelvis 320 kbit/s, hämtades även den tillbakaflyttade lyssningen i just 320 kbit/s. Kvaliteten låg fast tills användaren själv valde något annat.

    Men det gäller inte adaptiv HLS där garanteras endast abrottsfri lyssning men inte ljudkvalitéten



    Lars Mossberg
  • Ok!
    Nedväxling av kvalité vid sämre nätförhållanden är en av de kanske viktigaste egenskaper i som finns i "Adaptive BitRate"-protokoll som HLS. Vi är övertygade om att de flesta lyssnarna föredrar en temporär nedväxling i kvalité framför att det blir avbrott, men vill man ha en fast kvalité så går det - genom direktlänkarna.

    Trevlig helg!
    Annika Webbmaster

Kommentera eller skriv ett nytt inlägg

Ditt namn och inlägget kan ses av alla. Din e-post syns inte publikt.