Hvorfor dyr streamer?

[MrSpock]

Ja - og Spotify ansatte veldig tidlig Ludvig Strigeus, utvikleren av uTorrent - for å få tilgang til denne teknologien og bruke den.

Spotify Owned uTorrent Before BitTorrent Inc. Acquired It * TorrentFreak

As Spotify prepares to collect billions of dollars with a listing on the New York Stock exchange, a little-known fact about the company has emerged. The music streaming service, which had uTorrent developer Ludvig Strigeus as one of its early developers, was also the owner of the popular...

torrentfreak.com

The file-sharing angle was also very prominent in the early releases of Spotify. At the time, of all the tracks that were streamed over the Internet by Spotify users, the majority were streamed via P2P connections.

 

[ufo]

om man buffrer samme fil fra en annen kunde eller rett fra spotify spiller da ingen rolle for kvaliteten, med mindre de trikset med bitrate.

 

[Powercon]

om man buffrer samme fil fra en annen kunde eller rett fra spotify spiller da ingen rolle for kvaliteten, med mindre de trikset med bitrate.

Korrekt.
Problemene oppstår i det øyeblikk brukeren skal betale for en tjeneste, for så også måtte være en del av den med å stille lagring/datakraft tilgjengelig for alle de andre.

 

[HasseBasse]

Når det nå i etterkant viser seg at de droppet datapakker for at streaming skulle være raskt nok

DAGENS

 

[MrSpock]

om man buffrer samme fil fra en annen kunde eller rett fra spotify spiller da ingen rolle for kvaliteten, med mindre de trikset med bitrate.

Korrekt - dette var mer en opplysning til en som mente at P2P og Spotify ikke hørte hjemme noen steder

Men tilbake til dropping av datapakker - dette forklares i episoden jeg nevner - triksing foregår.

 

[Harry Stoteles]

dropping av datapakker

Hva betyr dette?

 

[MrSpock]

Hva betyr dette?

Packet loss - Wikipedia

en.wikipedia.org

 

[larsmartin]

Hva betyr dette?

Det viser seg at verden ikke er perfekt likevel!

 

[HasseBasse]

triksing foregår

Sikkert, men da heter det komprimering/reduksion, og dette er noe som foregår innen avsendelse i nettverket.
Om du mister en pakke i en transmission, da virker den resulterende filen IKKE.
Det forunnerlige ved nettverket er jo, at om du "mister" en pakke, forsøkes igjen, og igjen om første gang ikke var nokk.
Dette er vel det motsatte av å spare plass.
At påstå, at man "dropper" noen pakker for å spare plass.......... I rest my case

 

[Powercon]

Nå har jeg ikke sett den serien på Netflix eller satt meg inn i selve problematikk som skal ha vært tilstedet , men jeg er generelt litt skeptisk til å legge for mye i hva som kommer frem i en drama-serie med skuespillere++.
Selv om tema stemmer, så synes jeg man ikke skal se bort ifra at det kan være noen kunstneriske friheter i den serien for å gjøre den mere interessant/holde på seerene.

Har Spotify vært ute og kommentert innholdet/nøyaktigheten serien?

 

[MrSpock]

Sikkert, men da heter det komprimering/reduksion, og dette er noe som foregår innen avsendelse i nettverket.
Om du mister en pakke i en transmission, da virker den resulterende filen IKKE.
Det forunnerlige ved nettverket er jo, at om du "mister" en pakke, forsøkes igjen, og igjen om første gang ikke var nokk.
Dette er vel det motsatte av å spare plass.
At påstå, at man "dropper" noen pakker for å spare plass.......... I rest my case

Nei, det er ikke slik. Se gjerne nevnte episode og kom tilbake med kommentar etterpå.

 

[MrSpock]

Eller man kan jo bare drite i å se episoden - heller diskreditere den og krangle videre

 

[HasseBasse]

Nei, det er ikke slik. Se gjerne nevnte episode og kom tilbake med kommentar etterpå.

Dette er jo helt i Trump land.
Så du stoler mere på en episode i en Netflix/Youtube serie, enn den vitenskapeligt dokumenterte måten (som har vært
dokumentert siden start på nettverk) nettverk virker på??
Dette er bare for trist. "Alternative fact" kanskje???

 

[Powercon]

Så lenge man ikke vet hva som egentlig skjedde, så er det jo litt vanskelig å skulle vurdere noe som helst med å se en episode i en serie. Det er jo ingen dokumentar den serien.
Underholdene serie?; helt sikkert.
Tema interessant?; Ja.

 

[MrSpock]

Dette er jo helt i Trump land.
Så du stoler mere på en episode i en Netflix/Youtube serie, enn den vitenskapeligt dokumenterte måten (som har vært
dokumentert siden start på nettverk) nettverk virker på??
Dette er bare for trist. "Alternative fact" kanskje???

Slik jeg forstår det utviklet Spotify sine egne protokoller - de tok også patent på de? Disse bryter de vanlige reglene på internet - ved at de ofrer datapakker hvis nødvendig - for å få rask nok respons.

Litt googling viser at dette faktisk skjedde.

Men det er kanskje ikke så interessant - heller kalle andre for Trump?

 

[Harry Stoteles]

Det viser seg at verden ikke er perfekt likevel!

Hvem trodde Spotify var perfekt? Du?

 

[E.I.A.]

Bruker Wifi til både lyd og bilde og har til tider uklart bilde på tv, sendingen snurrer videre, men ikke i full oppløsning.
Restart av router løser ofte dette problemet.
Kan det samme skje med streaming av lydfiler, at sangen spiller videre, men på lavere oppløsning?

 

[MrSpock]

Bruker Wifi til både lyd og bilde og har til tider uklart bilde på tv, sendingen snurrer videre, men ikke i full oppløsning.
Restart av router løser ofte dette problemet.
Kan det samme skje med streaming av lydfiler, at sangen spiller videre, men på lavere oppløsning?

Ja, mener noe om adaptive streaming er en del av dette opplegget til Spotify - at det ofres litt for å opprettholde avspilling.

Tidligere stoppet det og buffres.

 

[HasseBasse]

Slik jeg forstår det utviklet Spotify sine egne protokoller - de tok også patent på de? Disse bryter de vanlige reglene på internet - ved at de ofrer datapakker hvis nødvendig - for å få rask nok respons.

Litt googling viser at dette faktisk skjedde.

Men det er kanskje ikke så interessant - heller kalle andre for Trump?

Bare for å sette på plass...... Jeg sa, at (tankegangen) var Trump-Land.
Jeg kallte IKKE deg (eller andre) for Trump. Så´nn.

Fakta: Om du pakker en analogfil (eller en hvilken som helst annen fil) som datastream, består den av x-antal små pakker. Om du kaster en av de pakkene, virker den resulterende filen ikke.
Spotify kan ha gjort deres egne protokoller dengangen, men det er ikke sånn normale nettverk virker. Det fjerner ikke det faktum, at om du kaster en datapakke (eller flere), da bli´r den resulterende filen ikke som original. Som CD-avspillers feilkorreksjon, som selv danner et tenkt gjennemsnitt, om den noen steder ikke kan lese informasjon. Om Spotify har gjort noe liknende fusk, da fortjener de vel å bli lagt i graven, hva vet jeg.
Ta´r du et dataprogram og nedlaster dette, og det bli´r en pakke vekk unnerveis, da virker programmet ikke. Dette er ikke diskutérbart. Undrer meg på, hvilke protokoller, som kan se forskjell på en program-data-stream og en musikk-data-stream og mene, att den ene tåler å få kastet bort pakker, men ikke den andre??

 

[MrSpock]

Bare for å sette på plass...... Jeg sa, at (tankegangen) var Trump-Land.
Jeg kallte IKKE deg (eller andre) for Trump. Så´nn.

Ja, særlig

Ikke noe problem

Men ellers å overføre en fil med variabel hastighet gjør ingen forskjell annet enn at det varierer i tid. Men for direkte streamet musikk er det kritisk.

Det er derfor jeg også tidligere i tråden nevne noe om at det kan være forskjell på å streame fra pc (lokal cache, perfekt filoverføring) enn ren streamer (direkte stream utsatt for varierende hastighet).

Men er usikker på om slike rene streamer dingser har intern lagring - slik at cache kan benyttes? Jeg forstår det slik at Roon fikser dette med egen cache - forhåndslagrer neste låt i spillelisten?

 

[HasseBasse]

Helt enig....... men variende streaming hastighet (som kan være spesielt trøbbelte med HiRez på
langsomme nettforbindelser (jo... de finnes stadig)) er ikke det samme som å "kaste bort" datapakker

 

[MrSpock]

Helt enig....... men variende streaming hastighet (som kan være spesielt trøbbelte med HiRez på
langsomme nettforbindelser (jo... de finnes stadig)) er ikke det samme som å "kaste bort" datapakker

Vel, det er nettopp det som skjer - alternativet ville være å stoppe avspilling og bufre.

 

[Powercon]

Bruker Wifi til både lyd og bilde og har til tider uklart bilde på tv, sendingen snurrer videre, men ikke i full oppløsning.
Restart av router løser ofte dette problemet.
Kan det samme skje med streaming av lydfiler, at sangen spiller videre, men på lavere oppløsning?

Dette går oftest på at protkollen brukt til TV-bilde er laget slik at mottageren (eks TV/dekoder i din ende) melder tilbake til sender om hvordan forholdene er.
-Om det blir trangt på nettet/router/wifi en periode, så vil TV typisk melde til kilde at nå går det tregt og at kilde må roe ned, eks ved å sette ned kvaliteten.
Dette vil da pågå en stund (kan vare ganske lenge) før mottager sender og mottager ev blir enige om å prøve å øke litt igjen.
En restart gjør at alt er tilbake til start, full pupp.

Strømming av musikk går ikke via samme protokoll/funksjonalitet. Kanskje den burde?
Anyways, merk at TV-bilde er mye mye mere data enn selv en hi-res musikklåt.

 

[HasseBasse]

Vel, det er nettopp det som skjer - alternativet ville være å stoppe avspilling og bufre.

Å stoppe/buffre vil gi et stopp/pause i avspilning, ja.
Å kaste en datapakke vil gi stopp i avspillning, men din evt. player vil ikke vite, hvor den skal starte igjen,
og du vil få en "error"-melding i stedet. Sååååhhhhh..... Ikke helt det samme som skjer

 

[MrSpock]

Å stoppe/buffre vil gi et stopp/pause i avspilning, ja.
Å kaste en datapakke vil gi stopp i avspillning, men din evt. player vil ikke vite, hvor den skal starte igjen,
og du vil få en "error"-melding i stedet. Sååååhhhhh..... Ikke helt det samme som skjer

Lurer på hvem som er i Trump land nå

 

[HasseBasse]

Lurer på hvem som er i Trump land nå

Det er bare å teste ut. Så kan du svare på spørgsmålet ditt etterpå
Søk på nett, og du finner filer med feil i, til netopp det formålet

 

[MrSpock]

Det er bare å teste ut. Så kan du svare på spørgsmålet ditt etterpå
Søk på nett, og du finner filer med feil i, til netopp det formålet

Det var jo derfor Spotify utviklet egen protokoller - for nettopp å komme rundt dette problemet. Det var også hele mitt poeng med å henvise til nevnte tv-serie episode.

Men vi er ferdige for min del - ikke så interessant å diskutere videre.

 

[na_X]

Vel, det er nettopp det som skjer - alternativet ville være å stoppe avspilling og bufre.

Protokollene er akkurat de samme hvilken hastighet/kvalitet filen man streamer fra, det er det som er greia med protokoller da de er standardiserte. At hastigheten/kvalitet på filen går ned er det applikasjonen som styrer, kan kjøre en vektor om buffer ikke er over 50% så settes kvaliteten ned f.eks. og applikasjonen spør da om lavere kvalitet. Det er kun payload det er snakk om her, header og pakker er fortsatt intakt. Om en pakke går tapt, så vil den forsøkes å sendes på nytt. Apllikasjonen kan derimot gå inn og spørre etter andre pakker om forsøk mislykkes, eller stoppe opp for å bufre.
ALLE streamere har buffer, til og med CD-spillere har buffer. CD-spillere i bil fikk også en større buffer på 90-tallet så man kunne kjøre på humpete vei i 20 sekunder uten at musikken stoppet pga. laser ikke fikk lest mediet.
Så ting står kanskje litt bedre til med tingenes tilstand enn mange egentlig vil ha det til og teknologien finnes og brukes gjerne flittig. Om man da ikke bor under en stein, som mange hifi-nerder og highend produsenter gjerne gjør eller kanskje mest ønsker at folk gjør for å tjene på bogus.

 

[MrSpock]

Protokollene er akkurat de samme hvilken hastighet/kvalitet filen man streamer fra, det er det som er greia med protokoller da de er standardiserte. At hastigheten/kvalitet på filen går ned er det applikasjonen som styrer, kan kjøre en vektor om buffer ikke er over 50% så settes kvaliteten ned f.eks. og applikasjonen spør da om lavere kvalitet. Det er kun payload det er snakk om her, header og pakker er fortsatt intakt. Om en pakke går tapt, så vil den forsøkes å sendes på nytt. Apllikasjonen kan derimot gå inn og spørre etter andre pakker om forsøk mislykkes, eller stoppe opp for å bufre.
ALLE streamere har buffer, til og med CD-spillere har buffer. CD-spillere i bil fikk også en større buffer på 90-tallet så man kunne kjøre på humpete vei i 20 sekunder uten at musikken stoppet pga. laser ikke fikk lest mediet.
Så ting står kanskje litt bedre til med tingenes tilstand enn mange egentlig vil ha det til og teknologien finnes og brukes gjerne flittig. Om man da ikke bor under en stein, som mange hifi-nerder og highend produsenter gjerne gjør eller kanskje mest ønsker at folk gjør for å tjene på bogus.

Vel dette var jo liksom poenget da - Spotify laget derfor sine egne protokoller - da standard protokollene ikke fungerte slik.

Og settes kvaliteten ned - vel da settes kvaliteten ned. Da sendes ikke samme antall bits lenger.

 

[PeriodeLytter]

Slik jeg forstår det utviklet Spotify sine egne protokoller - de tok også patent på de? Disse bryter de vanlige reglene på internet - ved at de ofrer datapakker hvis nødvendig - for å få rask nok respons.

Litt googling viser at dette faktisk skjedde.

Mer presist var vel idéen å starte avspilling så raskt som mulig. Vi ser den samme praksis mer tydelig hos de fleste film streamingselskapene hvor filmen hos de fleste av dem starter med lav oppløsning. Nå var det nok ikke nettverksprotokollen de manipulerte, men musikkdekoderen hvor de interpolerte* manglende samples på et vis.

I lenken jeg tidligere postet hvor vi ser hvordan Spotify i dag forsøker kontrollere resending av pakker med BBR finner jeg ingen info om anbefalt praksis for TCP timeout. Men standard vil TCP datagram resendes rett så lenge om server mangler bekreftelse. Jeg mener jeg har sett tall på 100 sekunder før oppkobling taes ned med en feilmelding?

Men jeg tror ikke player venter på slik feilmeding fra TCP stacket men heller overvåker sin buffer. Dette virker for meg være enklere å overvåke enn manglende TCP datagram med ditto problematikk rundt API til drivere på alle de ulike plattformene. Man kan da heller starte en ny HTTPS oppkobling med beskjed hvilken fil man ønsker og hvor i filen man ønsker starte nedlasting.

Nå er det i praksis ikke mulig å streame uten buffer når vi nytter TCP/IP. Hvor datagram kommer usynkront. Det var vel i starten for 15-20 år siden man lekte med UDP til overføring av musikk hvor pakketap kan være et fenomen. Enklere lokale UPnP/DNLA servere ser jeg fortsatt nytter UDP trolig mest for lavere CPU last.


(*) Jeg har tidligere i tråden vektlagt at på toppen av TCP/IP og hva streaming selskap lager til av protokoller har vi komprimeringsalgoritmen musikken er pakket i. F.eks. en stream som nytter FLAC container i CD kvalitet vil ikke droppe noen samples som kan forringe lyden. I stedet vil FLAC dekoderen sette en ramme på 4096 samples til stillhet. Værre det er at rammen blokken er plassert i inneholder tidskode som da trolig også er gått tapt som da i stedet vil gi skipping til neste hele ramme.

 

[MrSpock]

Her står det litt om Spotifys opplegg:

How Spotify beat the TCP/IP Protocol?

How the music giant overcame their biggest engineering hurdle in its nascent days

gantavya.hashnode.dev

Spotify's Innovation

They developed a custom protocol technique to prioritize the data packets to ensure that the most important data is delivered first.

The protocol works by dividing data into smaller chunks, which are then transmitted using a combination of reliable and unreliable data transfer methods. This allows the protocol to minimize latency and reduce the number of retransmissions that are required due to packet(Data) loss. The prioritization technique ensures that the most important data, such as the audio stream is delivered first, while less important data, such as metadata, can be delivered later without affecting the user experience.

One of the key innovations that the team developed was adaptive bitrate streaming. This technique allows the streaming service to adjust the quality of the audio based on the available network bandwidth. So, if the user has a fast connection, they get high-quality audio. If the connection is slow, the service automatically adjusts the audio quality to prevent buffering.

Another major innovation was the use of caching servers. These servers store frequently requested data closer to the user, reducing latency and improving performance. This meant that users could start listening to their favorite music almost instantly, without having to wait for the data to be transferred over the internet.

They also obtained a patent for this technology.

 

[na_X]

Vel dette var jo liksom poenget da - Spotify laget derfor sine egne protokoller - da standard protokollene ikke fungerte slik.

Og settes kvaliteten ned - vel da settes kvaliteten ned. Da sendes ikke samme antall bits lenger.

Skill på applikasjon og protokoll, takk. Dette er gjerne to ting som blandes sammen i en smørje, gjerne avhengig av hvem man snakker med.
Spotify er en sky-leverandør, og ja de har prøvd forskjellige greier oppigjennom årene som ikke har slått an helt som var på moten i den tiden og det er ting de også har gått helt bort i fra igjen, som alle andre også har gjort.
Greia med sky er at det meste styres fra applikasjonen, og det er også der ting ligger og det kan kjøres kun igjennom HTTPS om man ønsker det uavhengig hva det skulle være. HTTPS fungerer da som en ekstra "header" på nettverket. Slikt krever også veldig mye av servere og DNS som er satt opp på en fiffig måte for trafikk shaping fra servere som ligger nærmest og ikke har full load. Når man streamer en sang så kan det faktisk streames fra mange mange servere før den sangen er ferdig lastet komplett til en hel sang. P2P er et annet konsept, men bunnprinsippene er noe lik. Forskjellen fra cloud og P2P er at fra cloud så ligger alt på forskjellige servere som ligger sentralt og DNS er også en veldig sentral part i det hele, P2P så deles det imellom brukere uten sentral lagring uten noen form for garanti på hastighet etc og om de har en komplett fil i det hele tatt. Integritet på data er et nøkkelord her, og er grunnen til hvorfor alle har gått imot cloud istedet for P2P.

Serier er gjerne (over)dramatisering av virkeligheten og det foregår mye kreative greier som har både feil språk og forklaringer på ting for at normale folk ikke skal kjede seg og skru av før det har gått 10 min. Skulle den ha vært basert på fakta så ville det nok vært såpass tørt at ingen hadde giddet å sett serien, koding er ikke akkurat noe veldig mange synes er interessant selv om enkelte få kan synes det (og der er det også mye feil språk og forklaringer på ting internt, det kan jeg skrive under på som har jobbet med nettverk der kodere må strammes tøylene på da de ikke skjønner en dritt hva som foregår utenfor applikasjonen og ut imot resten av verden).

 

[MrSpock]

Skill på applikasjon og protokoll, takk. Dette er gjerne to ting som blandes sammen i en smørje, gjerne avhengig av hvem man snakker med.
Spotify er en sky-leverandør, og ja de har prøvd forskjellige greier oppigjennom årene som ikke har slått an helt som var på moten i den tiden og det er ting de også har gått helt bort i fra igjen, som alle andre også har gjort.
Greia med sky er at det meste styres fra applikasjonen, og det er også der ting ligger og det kan kjøres kun igjennom HTTPS om man ønsker det uavhengig hva det skulle være. HTTPS fungerer da som en ekstra "header" på nettverket. Slikt krever også veldig mye av servere og DNS som er satt opp på en fiffig måte for trafikk shaping fra servere som ligger nærmest og ikke har full load. Når man streamer en sang så kan det faktisk streames fra mange mange servere før den sangen er ferdig lastet komplett til en hel sang. P2P er et annet konsept, men bunnprinsippene er noe lik. Forskjellen fra cloud og P2P er at fra cloud så ligger alt på forskjellige servere som ligger sentralt og DNS er også en veldig sentral part i det hele, P2P så deles det imellom brukere uten sentral lagring uten noen form for garanti på hastighet etc og om de har en komplett fil i det hele tatt. Integritet på data er et nøkkelord her, og er grunnen til hvorfor alle har gått imot cloud istedet for P2P.

Serier er gjerne (over)dramatisering av virkeligheten og det foregår mye kreative greier som har både feil språk og forklaringer på ting for at normale folk ikke skal kjede seg og skru av før det har gått 10 min. Skulle den ha vært basert på fakta så ville det nok vært såpass tørt at ingen hadde giddet å sett serien, koding er ikke akkurat noe veldig mange synes er interessant selv om enkelte få kan synes det (og der er det også mye feil språk og forklaringer på ting internt, det kan jeg skrive under på som har jobbet med nettverk der kodere må strammes tøylene på da de ikke skjønner en dritt hva som foregår utenfor applikasjonen og ut imot resten av verden).

Ja - for eksempel P2P som de sluttet med i 2014

Selvfølgelig er en slik serie dramatisert - men Coder episoden var faktisk ganske tørr. Se den.

 

[na_X]

I lenken jeg tidligere postet hvor vi ser hvordan Spotify i dag forsøker kontrollere resending av pakker med BBR finner jeg ingen info om anbefalt praksis for TCP timeout. Men standard vil TCP datagram resendes rett så lenge om server mangler bekreftelse. Jeg mener jeg har sett tall på 100 sekunder før oppkobling taes ned med en feilmelding?

TTL = Time To Live.
TTL kan settes til max 255 sekunder, men dette ligger også i header og kan settes til 1 om man ønsker.
Men for hvert lag 3 hopp så reduseres TTL med 1.
TTL er en måte å forhindre congestion på, så pakker som ikke finner veien sin frem blir forkastet på lag 3.

 

[MrSpock]

Fins det streamere som ikke cacher? Høres ikke ut som en spesielt god idé, synes jeg.

Enig. Har prøvd å sjekke litt specs på streamere men finner lite. Roon fikser dette selv, som tidligere nevnt, tror jeg.

 

[Harry Stoteles]

Sletta spørsmålet fordi @na_X svarte så ettertrykkelig at nei, det fins ikke:

ALLE streamere har buffer

Gir jo ingen mening å lage en streamer uten buffer. Alle som har hatt en discman uten minne skjønner det. Men innen hifi fins det jo alltids produsenter som prøver å lage dårligere produkter og prøve å selge dem som bedre.

 

[PeriodeLytter]

Enig. Har prøvd å sjekke litt specs på streamere men finner lite. Roon fikser dette selv, som tidligere nevnt, tror jeg.

Dra ut nettkabel eller slå av WiFi ruter og ta tiden. De fleste blir overrasket hvor lenge man kan fortsette nytelsen. Ikke som med skjokolade hvor det går tomt med det samme.

 

[bambadoo]

Med enkelte kan du også øke bufferen til gjerne å lagre hele låter i "cache".

 

[MrSpock]

Dra ut nettkabel eller slå av WiFi ruter og ta tiden. De fleste blir overrasket hvor lenge man kan fortsette nytelsen. Ikke som med skjokolade hvor det går tomt med det samme.

Hvis du klikker på låt og drar ut nettkablene med det samme - kanskje ikke så lenge?

Men for en pc kan den kanskje spille hele albumet - alt etter hvor stor cache streamingleverandøren lager. Hvis det er musikk man spiller stadig.

Man kan også lagre masse musikk lokalt/offline - kan være et tiltak for å sikre seg.

 

[HasseBasse]

Funny...... som det er en masse utenomssnakk, fra det som ble påstått av LM og andre.
Bevisst pakkedrop for å spare plass. Hvilket stadig er en tullete påstand.
Ingen steder i sitatene fra Spotify står det annet enn å: Dele opp i mindre pakker, prioritetsstreame musikkinnhold
før Metadata o.a.
Ingenting om pakke drop, som var det, jeg opponerte imot.