2017-08-15 3 views
8

Ich habe Probleme, statische Inhalte (mp3-Dateien) zu erhalten, die von einem Icecast-Server zur Wiedergabe im Google Chrome-Browser mit HTML5 bereitgestellt werden. Der Grund, warum wir die mp3s über Icecast bedienen, ist die Richtlinie: Die CPB verlangt, dass sie "gestreamt" und nicht "heruntergeladen" werden, da wir öffentliches Radio sind. Unsere Live-Audio-Streams können problemlos in Chrome wiedergegeben werden.Audio vom Icecast-Server wird nicht in Chrome wiedergegeben

Wenn Sie die URL für einen MP3, der von meinem Icecast 2.4.3 Server geliefert wird, direkt in die URL-Leiste von Google Chrome stellen, wird sie nicht abgespielt. Machen Sie dasselbe in Firefox, IE, Safari, etc .. es spielt! Versuchen Sie es:

https://streaming.kansaspublicradio.org:8001/mp3/First_0713886.mp3

(Die temporäre Lösung, die ich bin mit Flash ist aber das neueste Update auf Chrome (v60.0) Makes Flash standardmäßig blockiert, die „immer zulassen für diese Website“ Option nicht scheinen zu funktionieren, und das kleine Symbol zeigt, dass Flash ist diskretere viel blockiert Versuchen sie es hier:. http://kansaspublicradio.org/kpr-news/midwest-farmers-hope-boost-online-grocery-shopping)

Meine beste Vermutung, warum dies geschieht, ist, dass es etwas damit zu tun hat: https://developers.google.com/web/updates/2016/03/play-returns-promise?hl=en

Also habe ich versucht, ihr Codebeispiel zu reproduzieren, in dem die y Monkey mit HTML5 Media Capture, um Audio ohne Benutzerinteraktion zu spielen. Aber mit this URL for the audio, es spielt nicht und wirft diesen Fehler: Uncaught (in promise) DOMException: The element has no supported sources. Versuchen Sie es: https://jsfiddle.net/wo94xohr/2/ Es schlägt nur in Chrome und nicht Firefox oder andere.

Ich versuchte es erneut, aber ohne die HTML5 Media Capture Zeug. Immer noch keine Würfel. Versuchen Sie es: https://jsfiddle.net/yrhets74/

Auch wenn Sie die Antwort-Header sehen, sehen Sie "Content-Range: Bytes 0-0/0" ... könnte das etwas bedeuten?


UPDATE: ich testen werde, um zu sehen, ob dies ein CORS (Cross-Origin Resource Sharing) Problem. Ich habe the jsfiddle aktualisiert:

var audioElement = document.querySelector('#music'); 
audioElement.crossOrigin = "anonymous"; // CORS access restriction. Worth a shot but no dice 
audioElement.type = "audio/mpeg"; // just in case? idk 
audioElement.src = "https://streaming.kansaspublicradio.org:8001/mp3/First_0713886.mp3"; 

function startPlayback() { 
    // .play() is a Promise 
    return audioElement.play().then(function(x){console.log('yay!')}, function(reason){ 
     console.log('Error: ' + reason); 
    }); 
} 
var playButton = document.querySelector('#play'); 
playButton.addEventListener('click', startPlayback); 

Es ist nicht das Endergebnis auf Chrome geändert hat, aber auf Firefox es jetzt nicht spielen, und es gibt die Warnung: Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://streaming.kansaspublicradio.org:8001/mp3/First_0713886.mp3. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).

Glauben Sie, das Icecast Server benötigt den Header 'Access-Control-Allow-Origin' auf 'allow' oder so?

Hier ist die vollständige Antwort vom Icecast-Server:

Request URL:https://streaming.kansaspublicradio.org:8001/mp3/First_0713886.mp3 
Request Method:GET 
Status Code:206 Partial Content 
Remote Address:129.237.213.244:8001 
Referrer Policy:no-referrer-when-downgrade 

Response Headers 
view source 
Accept-Ranges:bytes 
Cache-Control:no-cache 
Content-Length:526408 
Content-Range:bytes 0-0/0 
Content-Type:audio/mpeg 
Date:Tue, 15 Aug 2017 19:34:23 GMT 
Expires:Mon, 26 Jul 1997 05:00:00 GMT 
Pragma:no-cache 
Server:Icecast 2.4.3 

Request Headers 
view source 
Accept:*/* 
Accept-Encoding:identity;q=1, *;q=0 
Accept-Language:en-US,en;q=0.8,ms;q=0.6 
Cache-Control:no-cache 
Connection:keep-alive 
DNT:1 
Host:streaming.kansaspublicradio.org:8001 
Origin:https://fiddle.jshell.net 
Pragma:no-cache 
Range:bytes=0- 
Referer:https://fiddle.jshell.net/_display/ 
User-Agent:Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36 

UPDATE 2: Wir haben die CORS-Header Access-Control-Allow-Origin:* auf die icecast Server-Antwort-Header und jetzt die jsfiddle Werke in Firefox hinzugefügt - nein CORS header ‘Access-Control-Allow-Origin’ missing Warnung. Noch nicht spielt, obwohl in Chrome :(

Getestet habe ich auch WAV-Dateien und M3U-Dateien und weder in Chrome spielen. Firefox die WAV-Datei (mit dem JSfiddle Code) spielen konnte, aber keine der M3U-Datei

+1

Sie sollten wissen, dass kein Unterschied zwischen „gestreamt“ gibt es und „heruntergeladen“, und dass Ihre Implementierung einer solchen Beschränkung ist das Hinzufügen kein Gefühl der Sicherheit oder Prävention in irgendeiner Weise herunterzuladen. Die Behauptung, dass es statisch ist, mit Icecast statisch zu arbeiten, ist irgendwie falsch. Für andere CPB-Stationen, mit denen ich gearbeitet habe, war die clientseitige Unterscheidung von Streaming und Herunterladen der Schlüssel zu dieser Anforderung. Einige grundlegende Einschränkungen (z. B. signierte URLs mit einem Ablaufdatum) haben einen langen Weg in Richtung Best-Effort-Sicherheit aufgezeigt. – Brad

+0

danke @Brad und du hast natürlich Recht. Wenn Sie die URL der MP3-Datei direkt in die Adresszeile des Browsers eingeben, drücken Sie die Eingabetaste und drücken Sie dann Strg + s. Die MP3-Datei wird heruntergeladen und auf dem Computer gespeichert. Aber warum verhält es sich anders als MP3s, die von Apachen serviert werden? * seufz * –

+1

@DanMantyla Hast du die Antwort hier von Bobince gesehen? Einen Versuch wert https://stackoverflow.com/questions/2743279/how-could-i-play-a-shoutcast-icecast-stream-using-html5 –

Antwort

2

I denke, das Problem ist mit deinem Stream.Hier ist ein leicht modifiziertes Beispiel mit einer anderen Streaming-URL:

audioElement.src = "http://novazz.ice.infomaniak.ch/novazz-128.mp3"; 

https://jsfiddle.net/yrhets74/5/

Das auf meiner Maschine arbeitet mit Firefox 55 und Chrome 60

VLC sagt mir den verwendeten Codec ist MPEG Audio 1/2 (mpga).

die CORS Politik betrifft, so können Sie in dieser Frage interessieren: DOMException: Failed to load because no supported source was found

+0

ja es ist ein Problem mit der Art und Weise, wie der Server die Datei an Chrome –

+0

... oder die Art, wie wir es kodieren –

+0

Ich nahm ein mp3, das war gut, wenn serviert von Apache, legte es auf den Icecast-Server und jetzt tut es nicht t spielen in Chrome. http://streaming.kansaspublicradio.org:8000/clip2.mp3 –

3

Chrome is likely to play audio files with standards BitRate 128 , 160 , 320 , 512 , ...

Ich bin nicht 100% auf die Besonderheiten dieser, sieht es jedoch wie einige MP3s ältere Versionen von Lame verwenden, oder länger als ein paar Minuten oder bei hohen (300 <) oder niedrigen (128> =) Bitraten scheinen betroffen zu sein. Es scheint Webkit-bezogen zu sein, da es auch Safari-Benutzer betrifft.

JEDOCH!

Als eine Lösung, die MP3-Dateien mit 160Kbps Bitrate neu zu kodieren, und die neueste Version von LAME (3.99.5) scheint dies behoben zu haben, und sie spielen nun wieder normal über alle gängigen Browser. enter link description here

Mp3 File Properties

+0

hast du diese Antwort von hier kopiert? https://stackoverflow.com/questions/32441979/google-chrome-no-longs-plays-certain-audio-files –

+0

Sorry, ich habe vergessen, eine Referenz zu geben. Aber ich habe meine eigene Überprüfung Ihrer Dateien –

+0

Ich glaube nicht, dass das das Problem ist, weil ich das gleiche mp3 auf einen Apache-Server legte und es gut spielte. http://kansaspublicradio.org/widgets/First_0713886.mp3 –

Verwandte Themen