Streaming web

Le cas est intéressant, il s’agit de voir comment se comportent les lecteurs audio lors de la lecture de flux depuis http(s).

Dans pas mal de cas, il est primordial de laisser le temps au lecteur lire l’entête du fichier. Il peut perdre cette information dès lorsqu’on pointe le curseur de lecteur sur une zone éloignée du fichier.

Le comportement est difficile à décrire car il peut changer selon si les données ont eu le temps d’être téléchargées

Firefox

Firefox sait ouvrir certains formats directement dans son interface (.flac, .ogg, .mp3…).

Ouverture d’un grand flac :

Ouverture d’un grand mp3 :

Ouverture d’un grand ogg :

mpv (ffmpeg)

Ouverture d’un grand flac :

Ouverture d’un grand mp3 :

Ouverture d’un grand ogg :

Réseau lent

Lorsque le fichier streamé est hébergé sur un serveur ayant un débit pas fulgurant (400Ko/sec).

Sur un OGG avec mpv, un seek sur une zone arbitraire peut provoquer un gel un peu long, mais il se rattrape.

Sur un MP3 avec mpv, un seek sur une zone arbitraire peut provoquer un gel un peu long (plus long qu’avec ogg ?) qui semble proportionnel à l’éloignement du seek, mais il se rattrape.

mpd

Des solutions pour écouter de l’audio depuis interface web ou client androïd/linux/windows.

Audio sur le serveur :

icecast

Les solutions à base d’icecast sont assez problématiques, le flux radio ajoute une latence, se gère de façon autonome, peut s’interrompre s’il n’est plus alimenté

usines à gaz

Audio streamée : * funkwhale : des instances, semi-public, communautés de zik libres, social avec activitypub * airsonic : poursuite de subsonic, utilise JAVA Tomcat * ampache : streaming de fichiers locaux, a l’air assez bien rôdé, évoque la fourniture via soundcloud mais très peu orienté cloud providers * tizonia http://tizonia.org/ : en Python (pip), lecture de zik en ligne de commande, très orienté cloud/API/services payants.