Projet radio "avancé"

[ReshibanGaming]

Bonjour,

Hier il était tard j'ai oublié mon raisonnement. A suivre l'évolution de la librairie.
Donc https://github.com/ChristopheJacquet/PiFmRds qui te dit qu'il utilise libsndfile et http://www.mega-nerd.com/libsndfile qui te dit tout.

Oui avec 8Go de ram tu peux tout balancé en ram et ça consomme rien en %proc

Ouaip j'ai vu ça sur mes 8Go de RAM ça consomme rien, et je pense qu'on va rester sur du .wav donc ça parrait le plus sage.

J'ai donné des répertoires à surveiller ( /tmp ou en temp du navigateur), quitte à laisser grossir le téléchargement pour avoir une fourchette de Mo (on connait la taille de 5min). A partir de là, on peut rechercher par taille et date.

Pour l'instant, j'ai pas d'autres idées.

J'ai beaucoup cherché, et j'ai fait un test:

Il me reste 74.0Go, lorsque je lance le téléchargement du live.
Au bout de 500Mo téléchargés dans mon .mp4, je regarde le nombre de place restante:
Il me reste 73.5Go, et lorsque je "Ctrl + C" le téléchargement (pour stopper le téléchargement), même résultat.
Si il gardait bien les fragments comme demandé, ça devrait prendre le double de place -> 2 x 500Mo -> 1Go -> 74.0Go - 1Go = 73.0Go

On peut donc en déduire qu'il semble ne pas garder les fragments lors du téléchargement du live
(ce n'est peut-être pas des fragments mais autre chose qui y ressemble)



Je pense que la solution serait donc de comme tu l'as proposé:
Couper le téléchargement et le relancer (de manière automatique) toutes les 5 minutes -> le convertir automatiquement en .wav (youtube-dl sait le faire de manière automatique) -> lancer automatiquement le fichier .wav sur la radio.

Le seul problème reste donc:
Comment réaliser ça? Avec un script python peut-être?
Tant qu'on trouve un langage de script capable de lancer des commandes à notre place ça devrait être réalisable avec un boucle j'imagine ^^'

[dyox]

J'ai testé sous windows avec vivaldi (base chromium) ton live jap, tout se passe en ram : de 60Mo pour finir à se stabiliser vers 280Mo. Rien d'écrit sur le disque. Même comportement sous twitch.

En bash, cela devrait le faire.
C'est quoi toutes les commandes que tu lances ?
Avec sudo ?

Il n'empêche que je monterai le répertoire des fragments en ram, pour plus d'optimisation

[ReshibanGaming]

Es-tu obligé de l'émettre comme une radio ?
Sinon, j'utilise 2 solutions qui fonctionnent très bien :

• Bluetooth
• PulseAudio : chez moi, ca marche en filaire et ca me permet de mettre une webradio sur mon PI qui n'a pas d'écran et qui se trouve dans la cave lorsque je bricole, le master étant au 1er

Pour les jouer : soit directement firefox, soit VLC pour les webradio.

A+

Salut,

Oui en fait (je vais me débrouiller pour faire ça dans la légalité ) j'aimerais diffuser une radio de musiques d'anime dans mon village pour que moi et mes potes on puisse écouter de la musique jap assez facilement xD
Toujours sympa à faire, et si je peux apprendre quelque trucs en passant et qu'on peut laisser un topic dont tout le monde pourra s'aider, c'est toujours cool

Sinon en effet diffuser en bluetooth pourrait être une solution, mais c'est justement pour éviter d'avoir cette barrière de devoir prendre un appareil bluetooth etc... et en même temps en faire profiter mes potes que je le fais !


Merci pour les propositions en tout cas :p

[ReshibanGaming]

J'ai testé sous windows avec vivaldi (base chromium) ton live jap, tout se passe en ram : de 60Mo pour finir à se stabiliser vers 280Mo. Rien d'écrit sur le disque. Même comportement sous twitch.

Ah tu voulais que je test avec la page sur navigateur !
Moi j'ai fait tous mes tests avec youtube-dl qui doit gérer les fragments comme il le sent (décider de les stocker ou non etc...)

En bash, cela devrait le faire.
C'est quoi toutes les commandes que tu lances ?
Avec sudo ?

1er: je lance le téléchargement du live:
"youtube-dl --extract-audio --audio-format wav https://www.youtube.com/watch?v=oJ5tiq4DBNY"

2ème: je converti le .mp4 en .wav:
Ctrl + C (ça va stopper le live, et les options précédemment entrées vont automatiquement convertir le .mp4 en .wav)
ou
"ffmpeg -i video.mp4 -vn audio.wav" (si on souhaite le faire manuellement)

3ème: renommer "audio.wav" en -> "date_heure-audio.wav"
Entrez la commande qui va vérifier et stocker la date_heure, puis renommer le fichier avec cette date stockée

4ème: je lance la radio qui diffuse mon fichier .wav (on réutilise la valeur date_heure stockée pour définir le nom de notre .wav)
"./pi_fm_rds -ps Anime_radio -freq 92.8 -audio date_heure-audio.wav"

C'est la manière de procéder que j'ai en tête, mais j'avoue que c'est pas ce qu'il y a de plus optimisé.
Donc comme d'hab si tu as une meilleure idée en tête et mieux optimisée (comme l'histoire avec la RAM) je suis preneur


Pour info, youtube-dl met:
~4 secondes à se lancer (entre le moment où on lance la commande et le moment où il commence à télécharger la page web)
~6 secondes à commencer à télécharger (entre le moment où on lance la commande et le moment où il commence à télécharger la vidéo)


J'ai fait un test chronométré:
J'ai lancé ma commande "youtube-dl https://www.youtube.com/watch?v=oJ5tiq4DBNY" (on prend en compte les 6 secondes de démarrage)
Ça a tourné pendant 3 minutes tout pile (donc ~2:54 minutes de téléchargement) et m'a donné un fichier .mp4 de 3:05 minutes.

On peut donc en déduire que lorsqu'on lance la commande, on récupère ~les 10 dernières secondes qui précèdent le début du téléchargement, et on récupère donc ~les 5 dernières secondes qui précèdent le lancement de la commande

Il n'empêche que je monterai le répertoire des fragments en ram, pour plus d'optimisation

Comment tu fais ça? Il faudra que je lance le live dans mon navigateur pour en récupérer le flux du coup?
J'avoue que cette partie RAM est un peu floue pour moi
(la RAM est accessible en explorateur de fichier en fait? C'est ça qui me perturbe)

[dyox]

Ah tu voulais que je test avec la page sur navigateur !

Pas du tout, c'était le seul moyen que j'avais sous la main pour tester

Pour le 3è point, c'est quoi la commande ?

Comment tu fais ça? Il faudra que je lance le live dans mon navigateur pour en récupérer le flux du coup?
J'avoue que cette partie RAM est un peu floue pour moi
(la RAM est accessible en explorateur de fichier en fait? C'est ça qui me perturbe)

viewtopic.php?f=3&t=3832&sid=ff69cdf920 ... =30#p35352
Renseignez-vous sur les tmpfs.
Au lieu que le répertoire soit sur un support physique, il est mis en ram. C'est plus rapide, c'est plus mieux . Mais on perd tout à l'extinction mais comme ce sera le dossier des fragments, on s'en fout. D'ailleurs, il faut vraiment savoir le dossier où youtube-dl télécharge. Regardez dans~/.cache/youtube-dl, on ne sait jamais.

D'ailleurs, il serait préférable de commencer par se le créer, le tmpfs de youtube-dl et voir le comportementdes points 1 à 4. Cela devrait être plus rapide.
Exemple de ligne à rajouter au fstab
tmpfs /rep des fragments tmpfs defaults,size=4G 0 0

[dyox]

Concernant le 2nd point, est-il utile car d'après la doc, à la fin du 1, on a déja le .wav.

-x, --extract-audio Convert video files to audio-only files (requires ffmpeg or avconv and ffprobe or avprobe)

Arg, tu y avais répondu

Les conditions du style --extract-audio --audio-format wav ne servent (du moins utilisées seules) qu'une fois le téléchargement terminé, le logiciel demande alors à ffmpeg d'en extraire l'audio, mais à ce que je sache, ça ne marche donc pas durant le téléchargement :/

Dans ce cas, au 1er point cela devrait être pour un live :
"youtube-dl "https://www.youtube.com/watch?v=oJ5tiq4DBNY"

[dyox]

autre astuce : on peut cibler la qualité de la vidéo puisque seul l'audio nous intéresse, et cet audio ne change pas quelque soit le format.
Option worstvideo dans https://github.com/ytdl-org/youtube-dl/ ... .md#readme

On peut choisir le dossier de destination avec "-o /tmp/" avec /tmp en ram par exemple

[ReshibanGaming]

Désolé de la réponse tardive, on remerciera encore Windaube qui adore redémarrer en fin de commentaire

Pour le 3è point, c'est quoi la commande ?

En fait le 3ème point c'est que de la théorie, je ne m'y connais presque pas en bash, c'est pour ça que je n'ai pas mis de commande

Au lieu que le répertoire soit sur un support physique, il est mis en ram. C'est plus rapide, c'est plus mieux . Mais on perd tout à l'extinction mais comme ce sera le dossier des fragments, on s'en fout. D'ailleurs, il faut vraiment savoir le dossier où youtube-dl télécharge. Regardez dans~/.cache/youtube-dl, on ne sait jamais.

Ah ok, donc en gros si je fous mon /home/pi/ en RAM, au redémarrage il delete tout ? (c'est juste pour savoir )

Pour youtube-dl j'ai peut-être une "piste" pour nous aider à comprendre
J'ai testé de télécharger une vidéo classique avec le tool, et il l'a bien téléchargée sous forme de (gros) fragments, avant de tout merger en 1 .mkv
C'était un truc du genre "video.f137.mp4", et tout était dans le répertoire où j'ai lancé la commande

On peut donc en déduire que:
-Le répertoire des fragments (lorsqu'il y en a) est le même que celui des .mp4
-Le tool doit écrire les fragments de lives directement dans le fichier .mp4, au-lieu de les ajouter dans des fichiers appart

viewtopic.php?f=3&t=3832&sid=ff69cdf920 ... =30#p35352
Renseignez-vous sur les tmpfs.

D'ailleurs, il serait préférable de commencer par se le créer, le tmpfs de youtube-dl et voir le comportement des points 1 à 4. Cela devrait être plus rapide.
Exemple de ligne à rajouter au fstab
tmpfs /rep des fragments tmpfs defaults,size=4G 0 0

Ah ok, donc en gros si je me trompe pas ça va appliquer les changements uniquement à partir du redémarrage.

On a vraiment besoin de 4Go pour ça?

Je veux dire que si on a bien le même plan:
-On télécharge ~5 minutes de live, puis on arrête le tool qui va automatiquement convertir l'enregistrement en .wav
-On lance le .wav sur la radio
-Direct on relance un téléchargement qui va lui aussi durer 5 minutes
-Au bout de 5 minutes on arrête la radio et on supprime le .wav fini d'être diffusé

Avec cette boucle, moins d'1Go devrait être suffisant non ?
(Même si c'est mieux de rester large )


(Désolé si j'ai loupé des détails, c'est que je suis vraiment énervé d'avoir tout écrit puis tout perdu, c'est moins bien que ttaleur
Je te refait un 2ème commentaire avec certains points peut-être oubliés et avec ceux de tes autres réponses )

[ReshibanGaming]

autre astuce : on peut cibler la qualité de la vidéo puisque seul l'audio nous intéresse, et cet audio ne change pas quelque soit le format.
Option worstvideo dans https://github.com/ytdl-org/youtube-dl/ ... .md#readme

Bien vu, mais mauvaise idée.
Comme youtube est bien fait, lorsque tu mets la vidéo en 240p ou 144p, c'est parce que ta connexion est naze.
Donc lorsque tu sélectionnes une de ces 2 qualités, youtube fait en sorte que la qualité de l'audio baisse également !

Et en live, on ne peut pas sélectionner la qualité vidéo et audio séparément, on est donc obligé de laisser par défaut si on veut une bonne* qualité audio :/
(bonne*: ça reste une compression avec perte ^^')


Ah oui tu avais anticipé en n'appliquant ça qu'à la vidéo autant pour moi, mais je viens de tester et malheureusement impossible en live quand même :/

On peut choisir le dossier de destination avec "-o /tmp/" avec /tmp en ram par exemple

Yep bien vu, je réfléchissais à comment faire les "cd ..." dans le script mais ça sera pas forcément nécessaire alors

Concernant le 2nd point, est-il utile car d'après la doc, à la fin du 1, on a déja le .wav.

Dans les 2 cas il est utile, car on a besoin de stopper le téléchargement.
Il faudra donc (si c'est possible) ajouter dans le script un "Ctrl + C" effectué automatiquement par le système, qui fait partie du 2nd point

[dyox]

pour la commande de la date, j'ai récupéré. A toi de jouer avec. Ne pas oublier que youtube-dl à une option date !
$ date "+%d-%m-%Y-%Hh%Mm"

Ah ok, donc en gros si je me trompe pas ça va appliquer les changements uniquement à partir du redémarrage.
On a vraiment besoin de 4Go pour ça?

Il y a pê aussi : $ systemctl daemon-reload pour que ce soit effectif. On peut le voir avec : $ mount
Cela n'ampute pas de 4G la ram, le tmpfs s'autogère.

dans ton cas :
tmpfs /tmp tmpfs defaults,size=4G 0 0 (à affiner +tard)
-> avec youtube-dl -o /tmp/ ...
-> pour info,le tmpfs est utilisé par apt upgrade (j'ai observé ça)

Concernant la qualité vidéo/audio, j'ai testé (vivaldi) sur ton live et j'ai pourtant bien une vidéo dégradée mais pas le son. Et je vois ça en cliquant sur "statistique".

Youtube-dl permet aussi d'insérer la date.
Je te laisse tester la commande finale du genre
$ youtube-dl -o /tmp/ URL [worstvideo.best_son] [DATE]