[PHP] Passthrough van streaming audio

[Tim_R]

Voor een groot radioproject waar verschillende radiostations gebruik van moeten kunnen maken ben ik bezig met een frontend luisteraars-applicatie. Deze applicatie gebruikt een https-verbinding en derhalve moeten alle bronnen binnen de pagina ook via https lopen.

Nu vormt dit een probleem voor de streams van veel radiostations, die outputten alleen via http. Zeker kleinere stations die Shoutcast gebruiken krijgen we niet aan de SSL. Ik heb daarom het idee opgevat om de streams via onze eigen server te laten lopen, zo kan ik vanuit de webapplicatie een request uitvoeren naar /stream.php?radiostation=[id], en vervolgens een soort passthrough uitvoeren. Dit is op zich wel te realiseren met de bekende mogelijkheden in PHP, maar met een flink aantal streams zorgt dat voor veel geheugengebruik, omdat alle data ingelezen moet worden, door de output buffer gaat en daarna naar Apache geflusht wordt.

Vervolgens kwam ik uit bij X-SendFile, hetgeen precies doet wat ik wil, namelijk het versturen van het bestand buiten PHP, buffers en het geheugen om. Deze Apache mod is echter alleen geschik voor lokale bestanden.

Hebben jullie misschien ideeën voor een andere aanpak, of probeer ik iets onmogelijks?

[EnnaN]

Je gaat dan dus wel de volledige bandbreedte van al deze luisteraars moeten kunnen leveren: jij wordt in principe dus degene die het naar ze streamed.

Voor de rest zou ik kijken of je niet het makkelijkst een (beperkte) proxy kan doen, dus dat je een stream direct proxied in nginx oid -> kost verder dan alleen bandbreedte gok ik zo.

[mbarie]

Is er iets specifieks wat je probeert te bewerkstelligen? Is er een reden waarom het in PHP zou moeten? Er zijn een hoop applicaties waarmee je een audiostream kan relayen (IceCast bijv). Deze zullen al snel een stuk efficiënter zijn dan PHP.

En zijn er sowieso geen manieren om non-https streams alsnog aan het werk te krijgen binnen een https-context? Volgens mij zin daar wel wat mogelijkheden voor, toch?

[ Voor 25% gewijzigd door mbarie op 24-06-2015 17:03 ]

[emnich]

Buiten wat hierboven al gezegd wordt, moet je ook nadenken over de juridische implicaties hiervan. Doordat het via jouw server gaat kan jij gezien worden als degene die het openbaar maakt en dus vergoedingen moet betalen.

[Tim_R]

Dank voor jullie input, de bandbreedte is inderdaad een punt (er is voldoende, maar het moet eigenlijk onbeperkt schaalbaar zijn), maar het juridische aspect is misschien nog wel belangrijker en daar had ik helemaal nog niet over nagedacht. Ik zal dan toch wat meer aandacht besteden aan het mogelijk maken van het gebruiken van non-https-content binnen de https-context en dan laat ik deze oplossing maar even varen.

Mocht het uiteindelijk toch een vergelijkbare oplossing moeten worden, dan zal ik me inderdaad eerst verdiepen in bijvoorbeeld IceCast. Ik moet duidelijk iets meer out-of-the-(backend development)-box denken ;-)

[mbarie]

emnich schreef op woensdag 24 juni 2015 @ 17:14:
Buiten wat hierboven al gezegd wordt, moet je ook nadenken over de juridische implicaties hiervan. Doordat het via jouw server gaat kan jij gezien worden als degene die het openbaar maakt en dus vergoedingen moet betalen.

Hele belangrijke suggestie, dit. Kijk bijv op http://www.muziekenrecht.nl/hyperlinks-en-embedden/ voor wat meer info over de stand van zaken mbt streaming en recht.

[GrooV]

Ik zou niet te veel moeite steken in HTTP content over een HTTPS verbinding, het zal niet lang meer duren voor bijv. Chrome dit standaard zal blokkeren

[kwaakvaak_v2]

GrooV schreef op woensdag 24 juni 2015 @ 21:34:
Ik zou niet te veel moeite steken in HTTP content over een HTTPS verbinding, het zal niet lang meer duren voor bijv. Chrome dit standaard zal blokkeren

ik zou er mijn adem niet op inhouden, maar het gaat nog best even duren voor iedereen een site onder https heeft. Google kan dat wel willen, maar dat wil nog niet zeggen dat iedereen dat direct doet. Zeker niet zolang er nog sites zijn die op shared hosting draaien. Het is gewoon teveel gedoe voor de gemiddelde leek om even een SSL certificaat te kopen en te installeren. En zolang dat proces niet vereenvoudigd wordt bij de bron, dus je bij het koppelen van een domein aan een webserver direct een SSL certificaat aanmaakt gaat het nog best even duren voor iedereen over is naar https. En als chrome het gaat blokkeren stappen mensen vanzelf over naar een browser die het niet blokkeert.

[MSalters]

emnich schreef op woensdag 24 juni 2015 @ 17:14:
Buiten wat hierboven al gezegd wordt, moet je ook nadenken over de juridische implicaties hiervan. Doordat het via jouw server gaat kan jij gezien worden als degene die het openbaar maakt en dus vergoedingen moet betalen.

Welnee. Hier geldt hetzelfde voor als voor je ISP. Wat jij biedt is een technische voorziening om data te transporteren. Het is geen zelfstandige openbaarmaking. Ga dus niet proberen om "slim" te wezen, en de stream te "verrijken" want dan pas wordt je inhoudelijk verantwoordelijk.

(Artikel 13a, auteurswet)

[mbarie]

Vertel dat maar aan een eigenaar van een hotel. Dat is simpelweg niet hoe die regel in de praktijk wordt geïnterpreteerd en toegepast.

[ Voor 49% gewijzigd door mbarie op 25-06-2015 15:44 ]

[emnich]

MSalters schreef op donderdag 25 juni 2015 @ 15:38:
[...]

Welnee. Hier geldt hetzelfde voor als voor je ISP. Wat jij biedt is een technische voorziening om data te transporteren. Het is geen zelfstandige openbaarmaking. Ga dus niet proberen om "slim" te wezen, en de stream te "verrijken" want dan pas wordt je inhoudelijk verantwoordelijk.

(Artikel 13a, auteurswet)

Het is niet te vergelijken met een ISP en het is helemaal niet zeker dat 13a hier van toepassing is. Het gaat hierbij niet om het puur doorgeven tussen derden. Je bent als site eigenaar een actieve partij en dat is anders dan de mensen bij je ISP of AMS-IX.

Daarbij is het al de vraag of je de stream niet verrijkt door het als https door te geven ipv de originele http.

Het is een grijs gebied en juist daarom zou je je goed (dus niet op een forum ) moeten laten adviseren over de mogelijke gevolgen.

[MSalters]

Waar staat in de wet iets over websites? Of je nu een proxy draait om NAT reden, of omdat HTTP en HTTPS niet mixen, of een IPv6-IPv4 gateway, in alle gevallen ben je een intermediair die een technische oplossing oplossing heeft voor een technische beperking.

Verrijking in de context van het auteursrecht gaat over het onderliggende beschermde werk. Dus niet de headerbits van je pakketjes en je protocollen, maar de eigenlijke content.

Ja, natuurlijk is er een zeker grijs gebied. Zie de Usenet zaken, waar de intermediate (a) ernstige twijfels had moeten hebben over de originele bron en (b[norml])[/] die content niet direct doorgaf op verzoek, maar spontaan ophaalde en (c) dezelfde content herhaaldelijk aanbood zonder verdere toestemming van de originele bron. Een HTTPS proxy in vergelijking is #FEFEFE.

[emnich]

MSalters schreef op donderdag 25 juni 2015 @ 17:28:
Waar staat in de wet iets over websites? Of je nu een proxy draait om NAT reden, of omdat HTTP en HTTPS niet mixen, of een IPv6-IPv4 gateway, in alle gevallen ben je een intermediair die een technische oplossing oplossing heeft voor een technische beperking.

Je bent hier geen neutrale intermediair, je doet daar veel te makkelijk over.

Als makkelijkste voorbeeld kan het zijn dat een radio stream alleen toegankelijk is in een bepaald land (bijv Nederland). Als jij die vervolgens via jouw site internationaal beschikbaar maakt (immers jouw server staat gewoon in NL) dan maak je gewoon inbreuk.

Kortweg stellen dat er geen enkele juridische consequentie kan zijn is echt veel te kort door de bocht.

Let wel, ik zeg nergens dat het per definitie niet zou mogen maar zonder alle details te kennen kan je er geen goede uitspraak over doen.

Kortom mijn advies blijft, denk er niet te licht over en laat je heel goed adviseren als je dit in de toekomst toch nog wil doen.

[mbarie]

Er zijn vele redenen waarom OP wel moet betalen om enkel als relay te fungeren. Impliciet winstbejag en potentieel bereik wegen in deze zwaarder dan het eerder genoemde artikel 13a.

1. Indien OP een kvk registratie heeft is er winstoogmerk, met uitzondering van een stichting - dus rechten afdragen.
2. Indien OP reclame heeft is er sprake van winstbejag en commercieel belang bij de stream - dus rechten afdragen.
3. Verder is het aanbieden van streams via een eigen platform afdoende om te moeten betalen voor openbaarmaking, ongeacht het feit of je de streams host, of dat een derde dat doet. Voornamelijk omdat je je heirmee actief inzet het bereik te vergroten. Zie Nederland.fm niet in beroep tegen buma/stemra.

Dit artikel mbt het auteursrecht is allesbehalve universeel toepasbaar. Sterker nog, deze geldt alleen in een zeer beperkte context. Juridisch maak je in bijna elke situatie geen schijn van kans door op basis van dit wetsartikel als relay te fungeren.

[MSalters]

Citeer op z'n minst een wet or jurisprudentie.

KvK registratie is onzin : je ISP heeft dat ook.

Reclame toevoegen is inderdaad een no-no. Zoals ik al hierboven zei: Ga dus niet proberen om "slim" te wezen en de stream te "verrijken". Reclame is exact dat.

Ook je derde punt gaat onderuit om diezelfde reden. Om uit het vonnis te citeren:

Naar het oordeel van de rechtbank moet de vraag [of het openbaarmaking is - ms] bevestigend worden beantwoord omdat Souten zijn websites zo heeft ingericht dat de gelinkte radiostreams worden beluisterd in het kader van zijn websites.

En van die websites was vastgesteld dat ze reclame blokken toonden. Ook hier is het dus geen technische conversie, maar een toevoeging van reclame.

[mbarie]

Ik enkele maanden geleden nog afgezien van een overeenkomst met de buma stemra (met alle gevolgen van dien voor mijn concept) waar de 3 punten die ik eerder benoemde ook in terugkomen.

3de argument lijkt me nadrukkelijk juist relevant. OP spreekt over een front-end streaming applicatie. Hij gaat dus in eigen context content beschikbaar stellen. Nou zal dat met een desktop applicatie mogelijk nog wel loslopen, maar als het een website/webapplicatie betreft is het op zijn minst grijs gebied.

[ Voor 130% gewijzigd door mbarie op 25-06-2015 23:04 ]

[emnich]

Punt 3 is al achterhaald dus ik weet niet waarom Buma daar mee komt. Via je site een stream aanbieden van een derde mag mits die derde ook normaal toegang zou hebben tot die stream.

Het gaat er om of jij een nieuw publiek aanboort. Door de stream zelf te pakken en door te geven is er een kans dat je het voor een nieuw publiek openbaar maakt en kan je problemen krijgen.

Dat er advertenties op de site staan maakt niet zo veel uit als de stream niet vanaf je eigen server komt.

[MSalters]

Dat laatste kun jij vinden, maar de rechter vindt die advertenties cruciaal. Ik heb niet voor niets in de quote van het vonnis "omdat" in bold gezet. Dat benadrukt de oorzakelijke relatie.

Overigens begrijp ik uit de TS "kleinere stations ... krijgen we niet aan de SSL" dat er sprake is van een samenwerkingsverband. Dan is het ook aannemelijk dat de doelgroep bekend is. Dat maakt het helemaal triviaal: het opzetten van een HTTPS proxy is dan dienstverlening richting het station, niet de luisteraar. Daar gaat BUMA/STEMRA helemaal niet over.

[emnich]

Nee, dat vind ik niet dat vindt het Europese Hof . Zie ook de eerdere link van mbarie. Dat vonnis waar jij uit quote is dus achterhaald door nieuwe uitspraken waarin is bepaald dat een stream embedden géén nieuwe openbaarmaking is.

Het gaat er om of er een nieuw publiek aangeboord wordt.

Ook je laatste punt slaat de plank mis, de stations vragen niet om voor hun een HTTPS proxy op te zetten zodat ze hun eigen stream secure kunnen aanbieden. Het is wel degelijk een `dienst` voor de gebruiker van het nieuwe portal en niet een dienst voor het station.

Tot slot, de uitspraak van het Europese hof gaat specifiek over embedden (dus dat de stream van de oorspronkelijke aanbieder komt). Voor een proxy zou het anders kunnen zijn omdat dat geen embedden is.

[mbarie]

Daarnaast kan ik met niet voor stellen dat een 'groot radio-project' (zoals de OP het benoemd) geen winstoogmerk zal hebben. Waarschijnlijk zal het project belang hebben bij het relayen van de streams om deze beschikbaar te stellen aan eigen publiek al dan niet tegen een vergoeding. Daarnaast zullen de streams zelf ook belang hebben bij de samenwerking, wat impliceert dat er een groter bereik wordt gecreëerd (=openbaarmaking), want dat is één van de weinige vormen waarin je waarde kan creëren voor een online radio station.

13a is in mijn ogen niet van toepassing om diverse redenen:
1. De tijd dat HTTP is uitgefaseerd ten faveure voor HTTPS zal nog jaren duren. Het mag een 'tijdelijke' oplossing betreffen, maar om het relayen van een stream jaren vol te houden totdat de transitie naar HTTPS is gemaakt is simpelweg niet redelijk, niet incidenteel. Tijdelijk slechts in de ruimste interpretatie van het begrip.
2. De sprong van HTTP naar HTTPS is geen essentieel deel van een procédé. Simpelweg een applicatie laten draaien op http lost het probleem immers op. Het betreft een technische beperking vanwege een designkeuze.
3. Daarnaast zal zowel de doorgifte als de radiozenders naar alle waarschijnlijkheid wel over economische waarde beschikken, dit alleen al door mogelijk gebruik van reclame in de applicatie van OP, het ontsluiten van de radiostreams aan een breder publiek middels applicatie van OP, danwel door mogelijke reclame op de streams.

[ Voor 13% gewijzigd door mbarie op 26-06-2015 11:55 ]

[Tim_R]

Inderdaad is er sprake van het doorgeven als dienst aan het radiostation; het station betaalt straks aan ons voor de uiteindelijke applicatie die naast de stream een heleboel informatiestromen zoals geautomatiseerd nieuws, now-playinginformatie, EPG en (nog niet, maar wellicht later) webadvertenties bevat. Ik ben het met jullie eens dat wellicht te verdedigen valt dat het aanbieden van de stream via onze server slechts een doorgifte is, maar het gebied is voor mij grijs genoeg (heel mooi onschreven als #EFEFEF) om er een andere oplossing voor te zoeken. We gaan immers geld verdienen aan het geheel en het doorgeven/verspreiden van de stream vanaf onze server kan zeker gezien worden als een deel van de dienst.

Ik ben in de afgelopen dagen geen andere oplossing tegengekomen waarbij geen doorgifte via onze server plaatsvindt, dus ik ga met de andere stakeholders overleggen welke richting we inslaan, de webapplicatie toch over HTTP laten lopen is niet echt een optie aangezien de eindgebruiker middels Facebook kan koppelen en zo sociale content aan het platform kan bijdragen. In de ogen van de wet is dit vast persoonsinformatie en daar is HTTPS voor benodigd (en zelfs indien niet wettelijk, dan is het op zijn minst netjes om het te gebruiken).

Chrome had tot een paar maanden geleden geen moeite met één asynchroon ingeladen bron over HTTP zoals de mp3 streams in jPlayer, maar sinds een tijdje krijgen we een grijs slotje met het oranje driehoekje te zien. Dat is voor de eindgebruiker mogelijk niet acceptabel.

[MSalters]

mbarie schreef op vrijdag 26 juni 2015 @ 11:51:

13a is in mijn ogen niet van toepassing om diverse redenen:
1. De tijd dat HTTP is uitgefaseerd ten faveure voor HTTPS zal nog jaren duren. Het mag een 'tijdelijke' oplossing betreffen, maar om het relayen van een stream jaren vol te houden totdat de transitie naar HTTPS is gemaakt is simpelweg niet redelijk, niet incidenteel. Tijdelijk slechts in de ruimste interpretatie van het begrip.
2. De sprong van HTTP naar HTTPS is geen essentieel deel van een procédé. Simpelweg een applicatie laten draaien op http lost het probleem immers op. Het betreft een technische beperking vanwege een designkeuze.
3. Daarnaast zal zowel de doorgifte als de radiozenders naar alle waarschijnlijkheid wel over economische waarde beschikken, dit alleen al door mogelijk gebruik van reclame in de applicatie van OP, het ontsluiten van de radiostreams aan een breder publiek middels applicatie van OP, danwel door mogelijke reclame op de streams.

Punt 1 is niet relevant - 13a is niet beperkt in de tijd.
Punt 2 is incorrect. De bescherming van persoonsgegevens is een verplichting die met de huidige stand van de techniek gerealiseerd moet worden door het gebruik van HTTPS. Die verplichting is genoeg om HTTPS essentieel te maken.
Punt 3 bestrijd ik niet, in zoverre dat reclame toevoegen 13a inderdaad irrelevant maakt. Ook het ontsluiten naar een breder publiek zou van toepassing kunnen zijn, tenzij het originele station al toegankelijk was voor alle internetgebruikers. Zie daarvoor het arrest van het Europese Hof; indien alle internetgebruikers al bij de onderliggende stream kunnen dan kan er geen sprake zijn van een verdere openbaarmaking op internet.