2012-11-06 13 views
13

Attualmente sto lavorando utilizzando il lettore audio HTML5 per fornire un flusso audio (streaming radio 24/7) tramite il browser (mobile). Caricando nel flusso e giocando funziona bene.Arresta il buffering audio nel tag <audio>

Il problema principale è che il tag HTML5 <audio> continua a scaricare (buffering) il contenuto anche quando non è attivo. Questo potrebbe essere un grosso problema per gli utenti di dispositivi mobili poiché la maggior parte di essi paga per l'utilizzo dei dati. Finora non sono stato in grado di trovare una soluzione decente che funzioni cross browser per impedirlo.

ho provato finora:

  1. Scaricare la sorgente quando si preme pausa. < Questo non funziona cross browser
  2. Rimuovere l'elemento del lettore audio e caricarne uno nuovo. Funziona ma lascia intendere, questo è un modo molto hacky di eseguire un'attività estremamente semplice .

Mi stavo semplicemente chiedendo se c'è qualcosa che sto trascurando in tutta questa questione poiché sono convinto di non essere l'unico con questo problema.

+1

Ho modificato il titolo. Per favore vedi, "[Le domande dovrebbero includere" tag "nei loro titoli?] (Http://meta.stackexchange.com/questions/19190/)", dove il consenso è "no, non dovrebbero". –

+2

Ho appena notato che la rimozione dell'elemento dal DOM non separa sempre la risorsa. Significa che lo streaming è ancora in fase di download. – Ruben

+0

@Ruben totalmente sì, anche se il DOM corrente mostra solo 1 giocatore, il browser sta ancora memorizzando le risorse nella cache. Ho provato proprio ora, implementando un player di shoutcast Ajax che ha caricato il mio stream più di 10 volte perché il precarico e l'ajax. Se non si utilizza il "preload". meglio se non includi il tag audio a meno che tu non faccia clic su qualcosa, ad esempio un piccolo pulsante giocatore;) – erm3nda

risposta

3

Ho trovato una soluzione praticabile per il problema sopra descritto. Una descrizione dettagliata può essere trovato qui: https://stackoverflow.com/a/13302599/1580615

+1

Questa non è una buona soluzione e genererà errori su webkit (chrome, ios ecc.) –

2

È possibile effettuare le seguenti operazioni per fermare il carico di buffering senza errori:

var blob = new Blob([], {type: "audio/mp3"}); 
var url = URL.createObjectURL(blob); 
audio.src = _url; 

o, abbreviato up:

audio.src = URL.createObjectURL(new Blob([], {type:"audio/mp3"}); 

Ora non sta caricando un "" che è un brutto url per il tag audio da provare e caricare. Stai invece caricando un url reale creato da un BLOB che non contiene dati per l'audio da riprodurre.

+1

err in firefox: "Blob risorsa multimediale: http: // localhost: 4200/c68c796c-5af0-5343-a68d-9043c4c9b9a2 non può essere decodificato." err chrome: "GET blob: http: // localhost: 4200/fec774b7-7680-48a9-927e-1926685da447 416 (Intervallo richiesto non soddisfacente)" quando si utilizza il tipo: "video/mp4" –

8

L'elemento <audio> include un attributo preload. Questo può essere impostato su "nessuno" o "metadati" che dovrebbe impedire il preloading dell'audio.

Fonte: https://developer.mozilla.org/en/docs/Web/HTML/Element/audio

+1

Questa è la soluzione più elegante. Impostando su "nessuno" non è stato scaricato alcun dato e l'impostazione su "metadati" ha scaricato 517kb di dati. Il mio test era per un flusso di Voscast. – Rohmer

+0

Non è solo elegante, è il modo di farlo. Stavo cercando di impostare "falso" come un noob :), impostandolo su "nessuno" ha funzionato. U può impostarlo anche su "auto". Otterrai molti problemi se hai sorgenti di streaming e pagine Ajax. Gli oggetti audio vengono memorizzati nella cache del browser e l'utilizzo della larghezza di banda aumenterà a ogni caricamento. – erm3nda

Problemi correlati