Un équipement matériel à brancher à la maison sur une box en fibre ou bien un serveur hébergé ?
Il semble qu’un raspberry pi3 ne soit pas assez puissant, est-ce confirmé ?
Je ne me suis pas lancé dans l’aventure à cause de cette restriction, il semble qu’il faille un matériel assez puissant et une bande passant eassez large pour ne pas impacter les atures instance.
Pourquoi la faiblesse d’une instance affecte les autres instances ? Cela ne mets pas la barre un peu haute pour le ticket d’entrée ?
Quelle en est le coût mensuel ?
Regrouper l’information sur les instances existante pour connaître la bonne solution.
Dans la liste des instances une colonne indiquant le hardware, l’os et la bande passante serait très intéressant.
@gegeweb salut, je vous que tu as monté une instance peertube sur un serveur dédibox sous freebsd ( peertube.gegeweb.eu/about ) ces informations m’intéressent suite à ma question : framacolibri.org/t/quel-serveu
une idée du coût mensuel ?
– @PhilippeLhardy Dedibox SC d’entrée de gamme.
Plus deux autres IPV4 (le nat c’était chiant).
Dessus j’ai l’instance Peertube, mon pod Diaspora* et mon instance Mastodon de test.
Avant les deux nouvelles IPV4 j’en avais pour 21,58 TTC / mois pour deux Dedibox.
Ajoutons à ça le cout du domaine annuel, là ça va dépendre de l’extension. Mes domaines sont chez Gandi.
Par contre j’ai réinstallé le système from scratch en ZFS.
Un raspberry 3 pourrait aller, par contre je n’ai jamais testé. C’est au niveau du transcoding que ça pourrait coincer.
De la fibre avec 100Mbit/s en débit ascendant est suffisant.
Si une instance est derrière une ligne ADSL lente, chez soit:
Elle peut facilement tomber (coupure d’électricité, coupure internet etc) → les autres instances vont essayer de poster de l’information sur une instance morte, puis réessayer plusieurs fois → perte de temps pour le fédiverse
Le streaming vidéo requière beaucoup de bande passante montante, les utilisateurs auraient du mal à regarder les vidéos de cette instance peertube → donne une mauvaise image du logiciel, et crée de la frustration
Peut-être oui : mais c’est du streaming vidéo, ça demande un minimum de capacité
Je pense que pour une petite instance un serveur autour de 10€ par mois est suffisant. Encore une fois, tout dépendra du nombre de vidéos à héberger.
“EN GROS” je résume le “problème” c’est pas le serveur web /Ngnix qui pose soucis ni la bande passante / upload +/- ssl
C’est bel et bien le réencodage des vidéos ( <- vidéo uploadée et réencodée PAR / sur le serveur !?)
Question il serait possible d’injecter “directement” les vidéos réencodées ( aux formats ad hoc ? )
Genre mon serveur est sur un raspberry pi
Et mon PC perso c’est un GROS i7 + GTX1080 <-- je le fais bosser lui et j’uploade ma vidéo + les différentes versions / réencodages !?
A plus long terme voici des pistes qui me viennent à l’esprit :
permettre de définir une plage horaire pendant laquelle une instance peertube est active et ainsi ne pas essayer de se conencter dessus lorsqu’elle est arrêtée. Cela permet de mettre en place des instances de style “chaîne TV” qui n’émettent que sur une durée limitée.
de la même manière n’autoriser les ajouts de vidéo que sur une plage horaire limitée, pendant laquelle ,comme @Dfalm l’a suggéré , une machine plus puissante réeencde les vidéos
imaginer un protocole P2P de parallélisation du réencodage sur les clients. Tous les gens q<ui regardent une vidéo , en contrepartie, réencodent un morceau de nouvelles vidéos.
Je ne suis pas certain de comprendre l’intérêt de ton point n°1. Une instance PeerTube est un service web. On imagine mal YouTube être accessible de 8h à 18h…
Le point n°2 peut être intéressant, mais peut-être pas en empêchant le téléversement, juste en contraignant les tâches d’encodage à ne s’exécuter qu’à des horaires précis. Aussi, si ton but est uniquement que l’encodage soit fait sur une machine plus puissante, alors il faut déjà qu’il y ait la possibilité de déléguer l’encodage à une autre machine, ce qui n’est pas encore le cas.
Le point n°3 est cool! Je n’avais pas encore pensé à ça Mais soyons honnêtes, c’est un peu compliqué de faire encoder une même vidéo à plusieurs ordinateurs, encore plus s’il s’agit de déplacer la charge de l’encodage à des clients tiers. Je garde ça en tête cela dit - quand on aura un client de bureau dédié à l’encodage, ce sera sûrement plus simple à ajouter aussi
Tout d’abord merci de me lire et de me répondre cela me fait plaisir.
Je vais donc expliciter le point #1 qui pour moi a un intérêt.
Ce n’est justement pas pour reproduire Youtube, mais plutôt proposer du contenu plus local plus amateur. Pour effectivement redonner le pouvoir de diffusion à tous le monde en respectant les contraintes familiales. Dans un cadre familial on peut s’organiser pour que cela n’impacte pas le horaires de consommation de l’internet pour la famille, mais fournir le service lorsque c’est moins impactant. Un peertube inclusif, où l’on arrive en ajoutant le contrôle nécessaire à permettre à des acteurs qui seraient normalement exclus parce qu’il ne peuvent pas mettre à disposition leur machine 24h/24h et 7/7 ou de payer pour un serveur addtionnelj de participer.
Par exemple une télé local ou bien du contenu avec une possibilité d’interaction très rapide (ie mastodon) avec les spectateurs.
En diffusant à heure fixe on bénéficie de l’effet pair à pair car tout le monde consomme la même vidéo en même et donc… la partage.
Cela permet aussi de réduire l’exposition du serveur qui peut être une machine personnelle en marche sur une durée limitée. Le meilleur moyen de protéger un serveur des attaques, c’est qu’il soit éteint.
En diffusant en soirée on peut aussi bénéficier de l’électricité à tarif réduit, mais c’est anecdotique.
D’accord, je comprends. Cela dit, ma comparaison avec YouTube aurait pu se faire avec n’importe quel site web. Si ton serveur est éteint, rien ne le différencie d’un serveur n’existant plus. On ne peut pas savoir si c’est un comportement normal et voulu, ou si c’est un échec du service/un retrait définitif de l’instance. C’est gênant si d’autres instances te suivent pour tes vidéos. Si c’est juste pour que toi tu suive d’autres instances, alors là j’ai envie de dire que c’est moins problématique.
Je comprends bien que mettre à dispositions des utilisateurs n’ayant pas de serveur, la tâche dévolue à un serveur, soit importante. On a tous envie que cette forme d’auto-hébergement arrive, surtout avec des ordinateurs de bureau de plus en plus puissants (sans parler des téléphones). Seulement voilà, un serveur est vraiment quelque chose qui doit tourner 24h/24h, 7j/7j. Sans ça les autres instances vont se demander ce qu’il se passe, tant littéralement que techniquement (les instances font des appels vers l’instance de manière répétée, jusqu’à avoir une réponse). Alors oui, on peut diffuser une information lors de l’abonnement à ton instance, comme quoi ton instance s’éteint à des horaires précis. Mais dans ce cas tous les lecteurs intégrés à des pages web (embedel players) échoueront, car ils n’ont aucun moyen de récupérer ou stocker cette information. Idem pour les simples liens envoyés sur le fédiverse. PeerTube aura toujours besoin d’un serveur pour répondre à la place des ordinateurs de ses vidéastes.
Maintenant, rien n’empêche de bloquer la lecture en dehors d’horaires définis. C’est pour le moins étrange, mais possible. Ton serveur devra toujours tourner pour répondre que non, la vidéo ne peut pas être lue jusqu’à tel horaire. C’est pas une extinction totale de la consommation électrique, mais sur un rPI c’est pas trop le soucis (d’ailleurs ce qui consomme le plus est le transcodage, qui lui mériterait d’être planifié à des horaires ou déporté sur d’autres machines, comme dit avant).
J’héberge une instances “at home”, je n’ai jamais essayé avec un Raspberry (mais le Raspberry Pi 3 Model B+ est sortie, faudrait tester), mais j’ai la configuration suivante :
Machine host :
OS : FreeNAS-11.1-U5
CPU : AMD FX™-6300 Six-Core Processor
RAM : 16072MB ECC Unregistered
Qui héberge la VM Peertube avec :
4 Virtual CPUs
4096MB Ram
Derrière une connexion fibre avec 250mega en upload (1gig en down) mais partagé avec mes ordinateurs, mes raspberrys et une VM qui sert de seedbox (avec Rutorrent) qui seed des projets opensource (OS pour Raspberry, LibreOffice etc. Généralement ça dépasse pas les 2 Mo en up).
Bonjour, intéressant, sur quelle machine exactement.
Depuis que j’ai retrouvé la fibre, et qui fonctionne fort bien sur un RIP avec K-Net comme FAI (les “gros” veulent pas venir sur les zones peu denses) j’envisage de ré-installer le serveur @home mais ce qui me freine encore :
Coupures de jus que je trouve fréquente dans le coin… (on en a même eu une de plus de trois jours, trouvaient pas où se situait le court-circuit et ont transformé la rue en gruyère)
Pas de délégation pour les reverse IPV6.
Comme j’ai répondu sur Masto, perso ça tourne sur une Dedibox SC d’entrée de gamme.
J’ai testé l’installation sur mon raspberry pi3. ( Machine model: Raspberry Pi 3 Model B Rev 1.2 ) à la maison derrière une livebox en fibre.
J’arrive à lire une petite vidéo, le transcoding a été assez lent ( plus de 15 minutes pour une vidéo de 3 minutes ) mais je ne connais pas encore assez bien le fonctionnement pour avoir fait des mesures.
Cela n’a pas été sans mal, mais ce n’est pas forcément un problème avec le rasp, c’est ma première installation de peertube.
j’ai un problème avec la librairie libz fournie dans le prebuild de libvips de sharp, alors je dois lancer le serveur à la main en forçant le LD_LIBRARY_PATH :
Le serveur peut être redémarré ou reconfiguré parce que je dois le partager avec un blog et pour l’instant j’ai désactivé le blog pour avoir peertube ( à utiliser juste pour avoir une idée : https://pire.artisanlogiciel.net/ )/. le choix du nom n’est pas un hasard, cela doit être l’instance la pire de peertube
Merci de la réponse :
“Le point n°3 est cool! Je n’avais pas encore pensé à ça Mais soyons honnêtes, c’est un peu compliqué de faire encoder une même vidéo à plusieurs ordinateurs”
Non pas : si tu as master / slave ou primary / secondary
Ca marche avec DNS depuis assez longtemps et ça semble robuste
On peut chercher du côté d’un hearbeat ou puppemaster-like ?
Ce serait cool.
EG j’avais ( pour d’autres applications )
N serveurs , “n-1” petits avec GROSSE bande-passante
Et un seul GROS serveur gros cpu/ram mais petite bande passante.
Le “gros” était master : c’est lui qui effectuait les “calculs”
et il était secondary ( pour les “réponses” / reqêtes )
Les “petits” étaient esclaves il faisait que recevoir les ordres / données du maitre
et ils étaient primary ( pour les “requettes” ) sur le réseau.
Depuis au moins la version 2.3.0 de peertube le hack LD_LIBRARY_PATH pour fournir à sharp la zlib n’est plus nécessaire puisque que sharp a été remplacé par une autre librairie non native.
Donc le raspberry pi s’installe un peu comme les autres plateformes.
Ceci devrait être discuté ailleurs.
Mais je n’ai pas changé d’avis vis à vis de ce que j’écrivais il y a trois ans.
Si la seule raison pour laquelle les serveurs doivent tourner 24/24 et 7/7 c’est que les autres serveurs ne sont pas au courant, alors il est temps de penser une norme pour les services intermittents qu’ils puissent indiquer leur heure de présence.
Quand à l’idée que tout doit être disponible 24/24 7/7… Le sommeil est aussi une force.
Mais soyons honnêtes, c’est un peu compliqué de faire encoder une même vidéo à plusieurs ordinateurs, encore plus s’il s’agit de déplacer la charge de l’encodage à des clients tiers. Je garde ça en tête cela dit - quand on aura un client de bureau dédié à l’encodage, ce sera sûrement plus simple à ajouter aussi 
Mais soyons honnêtes, c’est un peu compliqué de faire encoder une même vidéo à plusieurs ordinateurs”