framboise314.fr

essais et observations sous windows :

Pour savoir tous les formats:
youtube-dl.exe -F https://www.youtube.com/watch?v=oJ5tiq4DBNY (ton live)
résultat On peut en déduire que l'on peut prendre la version 720p, même audio que 1080

ta commande devient : Or sous windows l'audio de 95 et 96 est à 128k / 91 et 92 -> 48k / 93 -> 128k
On peut donc en conclure que le flux 93 est pour toi le meilleur

et donc ta commande est : Hors ton wav passe d'un débit de 128k à 1536k. Je ne suis pas un spécialiste audio mais je dirai que c'est du "faux" 1536k.

C'est ce que tu disais, et c'est visible dans le résultat des fragments, lorsque tu lances ta commande, il récupère les 5s avant.
C'est pour ça que tu vois speed=2x puis ça descend, c'est pour récupérer le live
frame= 5999 fps= 32 q=-1.0 Lsize= 12816kB time=00:03:20.00 bitrate= 525.0kbits/s speed=1.06x

Après divers essais, je préfère cette commande : Pour 3min20, vidéo 12.52Mo et audio ogg 3.75Mo à 160k
En gros, l'audio prend 1/4 de la vidéo.

Cette commande me permet d'écouter automatiquement l'audio, après un ctrl-c Voici quelques pistes.

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"

Oh merci, je vais voir ce que je peux en faire
Pour le script, j'imagine qu'un .sh devrait faire l'affaire

Il y a peut-être 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.

En effet, après les modifications effectuées, j'ai seulement ~300Mo de RAM utilisés au démarrage.

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)

J'ai pris la décision de faire un 1er tmpfs en "/tmp/" de 40Mo, et un 2nd tmpfs en "/tmp/fragments-dl/" de 1Go.
Ça ne pose pas de soucis que ce soit un sous-dossier on dirait (tout démarre et fonctionne bien)

Ouaip j'ai vu ça, il y a plusieurs tmpfs déjà installés par défaut sur le système (comme en /run/user/1000/ par exemple)

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]

Ah okay, c'est que ça doit être trop coûteux pour YouTube de réencoder l'audio en plusieurs qualités peut-être :p

Pour la vidéo comme je l'ai dit, malheureusement c'est impossible.
Lors d'un "--format worstvideo", youtube-dl retourne un "requested format not available"


Par contre j'ai trouvé 2 trucs cool:

-L'option "--list-formats" permet de lister tous les formats disponibles (de 144p à 1080p par exemple) avec un numéro associé à chacun d'entre eux.
Et devine quoi... un simple "--format 91" (dans mon cas) me donne du 144p!

-J'ai téléchargé deux extraits 144p et 1080p, de la même taille (01:05 minute) convertis ensuite en .wav .
Et résultat... 11.9Mo chacun, exactement le même débit etc... la qualité est bien la même des deux côtés

Mon dieu qu'ai-je dit o_o
En effet dans ton post on le voit bien, la qualité audio reste dégradée.
Le fait que le .wav fasse la même taille dans les 2 cas est juste qu'il n'y a pas de compression


Je viens de voir ton nouveau commentaire, on a trouvé à peu près la même chose on dirait xDD
À moins que tu en aies trouvé plus que moi

Par malheur, mon Rpi4 a décidé de bouder et ne diffuse plus rien.
Il brouille le signal à la place, comme si il tentait d'émettre quelque chose sans y parvenir.

J'ai fait des tests avant avec de multiples antennes pour tenter d'émettre + ou - loins, ça vient peut-être de ma broche GPIO qui aurait quelque soucis, même si à vue d’œil elle semble intact (comme toutes les autres broches)

J'utilise généralement mon câble de ventilateur comme antenne (un seul des deux câbles branché pour éviter le court-circuit!)
Mais j'ai aussi testé avec des fils de cuivre dont 1 qui a peut-être pu "rayer" mon pin, si c'est le cas je ne sais pas si ça aurait un impacte sur son fonctionnement.
(J'explique ça si tu as une idée de où ça pourrait venir, mais également pour "avertir" les personnes qui vont parcourir le topic)


Bref du coup en attendant j'ai move sur mon Rpi3 (1Go de RAM), et lui diffuse encore impec

Ton Pi4 boot encore ?

Si tu as fait un court-circuit avec ton cuivre, c'est le régulateur de tension qui saute et plus rien ne démarre (voir dans ma signature)

Sinon, je n'ai pas d'idées, à part de changer de pin, si possible.

Pour info, si tu les gères en headless, tu peux baisser ta ram allouer au gpu.

dyox a écrit : ↑

ven. 14 août 2020 21:33

Ton Pi4 boot encore ?

Si tu as fait un court-circuit avec ton cuivre, c'est le régulateur de tension qui saute et plus rien ne démarre (voir dans ma signature)

Sinon, je n'ai pas d'idées, à part de changer de pin, si possible.

Pour info, si tu les gères en headless, tu peux baisser ta ram allouer au gpu.

Oui, heureusement le Rpi4 boot toujours ça fait quelque jours que le problème est là, je pensais qu'avec un reboot ça se fixerait etc... mais non, je vais voir si je remake pi_fm_rds et dans ta signature du coup


Au fait, on m'a fait taper quelque commandes sur un discord (lsof -p %PROC) qui ont retourné pas mal d'infos, et apparemment dans le proc de youtube-dl et ffmpeg y'a aucune trace d'écriture de fragments, donc on est bien fixé à ce niveau là !

dyox a écrit : ↑

ven. 14 août 2020 20:19

essais et observations sous windows :

Pour savoir tous les formats:
youtube-dl.exe -F https://www.youtube.com/watch?v=oJ5tiq4DBNY (ton live)
résultat

Code : Tout sélectionner

[youtube] oJ5tiq4DBNY: Downloading webpage
[youtube] oJ5tiq4DBNY: Downloading m3u8 information
[youtube] oJ5tiq4DBNY: Downloading MPD manifest
[info] Available formats for oJ5tiq4DBNY:
format code  extension  resolution note
91           mp4        256x144    HLS  194k , avc1.4d400c, 30.0fps, mp4a.40.5@ 48k
92           mp4        426x240    HLS  335k , avc1.4d4015, 30.0fps, mp4a.40.5@ 48k
93           mp4        640x360    HLS  808k , avc1.4d401e, 30.0fps, mp4a.40.2@128k
94           mp4        854x480    HLS  994k , avc1.4d401f, 30.0fps, mp4a.40.2@128k
95           mp4        1280x720   HLS 1490k , avc1.4d401f, 30.0fps, mp4a.40.2@256k
96           mp4        1920x1080  HLS 2525k , avc1.4d4028, 30.0fps, mp4a.40.2@256k (best)

On peut en déduire que l'on peut prendre la version 720p, même audio que 1080

...

Cette commande me permet d'écouter automatiquement l'audio, après un ctrl-c

Code : Tout sélectionner

youtube-dl.exe -x --audio-format vorbis -f 93 https://www.youtube.com/watch?v=oJ5tiq4DBNY --exec mpc-hc64.exe *.ogg

Voici quelques pistes.

Oh! alors avec --exec y'aurait moyen de fusionner la phase 1 & 4 et d'éliminer la phase 3!
Ça c'est très intéressant !


Pour ce qui est de l'audio, je partirais plutôt sur du .flac .

Le .wav est un conteneur sans compression et sans perte dit LOSSLESS.
Autrement dit, une boîte où tu mets n'importe quel son, et on te le ressort sans perte. Le truc c'est qu'il ne compresse rien, donc il prend beaucoup de place.

Le .ogg par contre lui, a une bonne compression, mais compresse malheureusement avec perte dit LOSSY.
On perd donc un peu de la qualité initiale, même si ça reste bon en .ogg (meilleur qu'en .mp3)

Le .flac par contre, a également une compression, mais une compression sans perte dite LOSSLESS.
Il est donc (sensé) prendre moins de place qu'un .wav, compressant intelligemment, tout en ressortant la même qualité qu'un wav !


C'est donc sur du .flac que je vais me pencher, étant supporté par libsndfile :p


(Ah et ça ne serait pas -f 95 le plus intéressant? Il a 256Kbps contre 128Kbps, ce qui est logiquement meilleur )

lsof -p $id

Je me le note, merci

Oh! alors avec --exec y'aurait moyen de fusionner la phase 1 & 4 et d'éliminer la phase 3!
Ça c'est très intéressant !

Je te conseille de lire la doc, il pourrait y avoir des options fortes intéressantes

Le .wav est un conteneur sans compression et sans perte dit LOSSLESS.
...

Ton résonnement est bon, mais il faut l'adapter à la pratique. Ici ta SOURCE est en 128k. Ce n'est pas en augmentant son bitrate à 1600k que tu vas recréer ce que tu avais perdu lors de sa compression.
C'est pour ça que j'avais dit : "mais je dirai que c'est du "faux" 1536k."

(Ah et ça ne serait pas -f 95 le plus intéressant? Il a 256Kbps contre 128Kbps, ce qui est logiquement meilleur )

Non, car en pratique, c'est du 128K. Refais mes tests qui te le confirmera

Or sous windows l'audio de 95 et 96 est à 128k / 91 et 92 -> 48k / 93 -> 128k
On peut donc en conclure que le flux 93 est pour toi le meilleur