Gestion des médias

[Cl0v1s]

Discussion sur la gestion des médias suite à ce commentaire

https://github.com/Cl0v1s/mangane/issues/53#issuecomment-1311561447

cc @ymollard

[Cl0v1s]

Pour te répondre, c'est déjà ce qu'il se passe, tu as une compression coté serveur, après je n'ai pas réellement la main en l'état sur la compression réalisée. D'après ce que je vois sur cette interface, on peut ajouter des filtres au processus, donc une compression auto vers webp par exemple serait réalisable... avec un peu de développement

Concernant l'accessibilité pour les non-techos j'suis tout à fait ok avec toi. En revanche 150mo est énorme imo. Par exemple discord qui est un outil grand public limite les uploads gratuits à 20mo :) Je pense qu'une ouverture à 50/75 mo avec compression auto derrière serait un compromis intéressant, étant donné qu'avec webP on peut attendre 30% de gain, ça nous ramène à un poids proche de l'original

[ymollard]

Pour le moment, mes priorités sont l'accessibilité et la CI gratuite, et Gitlab n'est pas vraiment bon sur ces deux points,

Possible de détailler un peu plus ? J'ai un a priori inverse que GitLab Runner est hyper bien, au moins aussi bon que GitHub Actions. Gitea c'est très bien aussi, mais la CI est moins immédiate à mettre en oeuvre je pense, bien qu'il y ait quelques pistes.

En revanche 150mo est énorme imo.

Oui, en fait je prends l'exemple d'une vidéo de smartphone, habituellement très lourdes, et je pars du principe qu'elle sera dégradéee/compressée fortement donc qu'elle ne prendra pas beaucoup de place sur le serveur.

On peut êut-être faire un essai d'augmenter à 50Mo et voir comment sont compressés les fichiers avec les options par défaut ? Si c'est un fort gain on peut augmenter ou baisser le quota.

Je pense qu'on ne peut pas vriament comparer avec Discord car en terme d'usages Discord reçoit moins de vidéos que Twitter ou Mastodon.

PS : je pars du principe qu'on a vraiment un très fort gain sur la compression, par ex 60%, et qu'il ne faut pas hésiter à redimenssionner (Full HD maximum).

[Cl0v1s]

J'utilise Gitlab au taf tous les jours, effectivement leur CI est très performante, mais il ne me semble pas qu'elle soit gratuite, si ? Au début on s'est retrouvé avec une facture qui nous a pris par surprise ! Pour ce qui est de l'accessibilité, l'interface est par contre horrible, avec énormément de sous menus et une architecture générale peu claire.

Et bien écoute go, quelqu'un a une vidéo de 50Mo sous la main ? :)

[ymollard]

J'utilise Gitlab au taf tous les jours, effectivement leur CI est très performante, mais il ne me semble pas qu'elle soit gratuite, si ?

Si si il y a des runners publics gratuits. Fais l'essai : tu créés un .gitlab-ci.yml sur gitlab.com et boum, il est exécuté par un runner public. Il y a peut-être jsute une étape avant pour activer les runners publics sur ton compte et mettre un numéro de CB non débité pour éviter les abus (type minage crypto etc) mais dans mon souvenir ça prend 30 secondes et c'est hyper facile.

Le top du top c'est d'auto-héberger un GitLab et des runners, par exemple chez Aquilenet mais c'est l'étape d'après :) (Je suis en train de le faire, mais c'est une instance pour une école d'ingénieurs :)

Et bien écoute go, quelqu'un a une vidéo de 50Mo sous la main ? :)

J'ai déjà une vidéo de 22Mo que je voulais publier. Si tu montes la limite au dessus de 22 on essaye :D

[Cl0v1s]

Ouais c'est cette histoire de cb qui nous a pris par surprise !

Ca marche je monte à 23 pour être sur !

EDIT: dis moi quand c'est bon !

[ymollard]

Ouais c'est cette histoire de cb qui nous a pris par surprise !

Ha ! Mais ça vous a rien coûté du tout dans ce cas ? C'est juste une forme de vérification d'identité. Ou d'intimidation je sais pas.

EDIT: dis moi quand c'est bon !

Toujours Request Entity Too Large. Tu peux mettre 35 plutôt ? Des fois qu'il y ait une embrouille entre Mio et Mo

[Cl0v1s]

J'ai pas suivi la résolution de l'histoire, mais en gros on a du dépasser une certaine limite, et on a reçu une facture.

Je fais ça !

EDIT: done

[ymollard]

EDIT: done

Toujours pas :( Tu es sûr que c'est le bon réglage ?

[Cl0v1s]

Y'en a pas d'autres, par contre il y a parfois des conflits entre la configuration en base de donnée et la configuration dans les fichier .exs de pleroma. Je regarde ça.

Il est pas improbable que ce soit Nginx aussi qui refuse la requete je me penche dessus. Tu peux poster la vidéo ici que je puisse le faire de mon coté ? Sinon je me débrouille en prenant un autre canari :)

[ymollard]

Oui n'importe quelle vidéo devrait faire l'affaire https://download.blender.org/peach/bigbuckbunny_movies/

[Cl0v1s]

J'ai upload cette vidéo: https://jsoncompare.org/LearningContainer/SampleFiles/Video/MP4/Sample-MP4-Video-File-Download.mp4 47.9Mo

Visionalble ici: https://bdx.town/media/7baad60681f0e480c1e3726ede92f77851fad54642e5524a4247f3c56c483503.mp4 47.9Mo

Comme on peut le constater en l'état il n'y a aucune compression de réalisée. Je vais donc voir ce que je peux faire pour ajouter de la compression automatique

[ymollard]

C'est bon désormais je n'ai plus d'erreur lors de l'upload non plus. C'est quoi que tu as corrigé ? J'ai fait un upload de la vidéo puis fermé le brouillon du pouet, j'espère que le serveur détruit les fichiers dans ce cas :P

[Cl0v1s]

J'avais changé les paramètres dans nginx en plus, lui limitant nativement la taille des requètes à 1Mo. Aucun idée et sincèrement je pense pas x)

J'ai fais quelques tests, les filtres ne s'appliquent qu'aux img mais de ce point de vue là on est déjà à peu près bons, le soucis étant plutôt les vidéos.

J'arrive à diviser par 10 la taille de ma vidéo de test sans perdre de qualité de manière visible. Par contre pas possible de faire ça via Pleroma. Donc ce que je pense que je vais faire c'est:

1) Avant le lancement de mon script de backup, je run un script qui tourne sur toutes les nouvelles vidéos depuis 24h 2) Ce script compresse avec ffmpeg -i source.mp4 -vcodec h264 -acodec aac -crf 28 output.mp4 3) Je supprime l'original plus lourd 4) Je poursuis le backup

De cette manière mes backups restent légères, et en plus le toot aura eu le temps de se diffuser à sa qualité originale avant d'être nerf.

Vous en pensez quoi ?

Je pense tout de même conserver une limite à 64mo. C'est un joli multiple de 8, et ça permet de rester raisonnable en encourageant pas les uploads "gaspillage".

Le soucis étant de gérer la compression sur tous les formats. Je vais faire des tests avec l'argument copy et en jouant juste sur le crf

[Dehelssey]

L'idéal côté poids serait de charger des vidéos externes (peertube, yt...) mais c'est pas le plus simple côté user

[Cl0v1s]

Oui clairement, faut que ça reste facile d'usage, d'où le fait que je suis d'accord avec @ymollard de monter la limite.

J'aimerai quand même réussir à intervenir directement à l'upload pour éviter les soucis de formats ...

[ymollard]

Je pense tout de même conserver une limite à 64mo. C'est un joli multiple de 8

Ca n'a de sens que si ce sont des Mio, après je vois pas bien l'intérêt d'avoir un multiple de deux même pour des Mio mais pourquoi pas 64 oui :P

Super pour l'astuce de réduction de taille des vidéos. Est-ce que d'une manière ou d'une autre ça peut bénéficier à toutes les installations de Pleroma plutôt que de rester sur bdx.town ?

[Cl0v1s]

En l'occurrence non, je pourrais développer un filtre d'upload mais c'est une autre quantité de travail. Par contre je peux l'intégrer à notre containeur Akkoma par default (cf le projet Akkoma sur mon compte)

Le 12 novembre 2022 17:41:57 GMT+01:00, Yoan Mollard @.***> a écrit :

Je pense tout de même conserver une limite à 64mo. C'est un joli multiple de 8

Ca n'a de sens que si ce sont des Mio, après je vois pas bien l'intérêt d'avoir un multiple de deux même pour des Mio mais pourquoi pas 64 oui :P

Super pour l'astuce de réduction de taille des vidéos. Est-ce que d'une manière ou d'une autre ça peut bénéficier à toutes les installations de Pleroma plutôt que de rester sur bdx.town ?

-- > Reply to this email directly or view it on GitHub:

https://github.com/Cl0v1s/mangane/issues/54#issuecomment-1312523799

You are receiving this because you authored the thread.

Message ID: @.***>

[Dehelssey]

ça vaudrait le coup d'ouvrir un ticket sur leur repo ? ou celui de pleroma ? ou les deux ? 🤷

[Cl0v1s]

Je sais pas trop ! Ils proposent un système de filtre qui peuvent visiblement être developpés par des tiers, donc ils ont l'air de considérer que ça rentre pas dans le scope. Après pourquoi pas essayer !

Le 12 novembre 2022 19:35:42 GMT+01:00, "Guérin" @.***> a écrit :

ça vaudrait le coup d'ouvrir un ticket sur leur repo ? ou celui de pleroma ? ou les deux ? 🤷 >

-- > Reply to this email directly or view it on GitHub:

https://github.com/Cl0v1s/mangane/issues/54#issuecomment-1312546737

You are receiving this because you authored the thread.

Message ID: @.***>

[Cl0v1s]

Pour la postérité le script que j'ajoute au conteneur akkoma qui fera tourner l'instance.

Par ailleurs, vu les ressources que ça bouffe, ça me surprend pas trop qu'ils ne le fassent pas. Ca doit être un petit challenge de faire rentrer ce genre de traitement dans le cycle de vie de l'app sans l'immobiliser pendant des plombes.

Ce script va être la seule priorité du serveur, de 3h à 4h du matin tous les jours, donc je peux y aller niveau conso de ressources

#!/bin/sh

formats="\.webm$|\.flv$|\.vob$|\.ogg$|\.ogv$|\.drc$|\.gifv$|\.mng$|\.avi$|\.mov$|\.qt$|\.wmv$|\.yuv$|\.rm$|\.rmvb$|/.asf$|\.amv$|\.mp4$|\.m4v$|\.mp*$|\.m?v$|\.svi$|\.3gp$|\.flv$|\.f4v$"

# retrieve video files modified (and so uploaded) during the last 24 hours
for file in $(find . -mtime -1 -type f -and -not -name "*.small.*" | grep -E $formats)
do 
    echo "Compressing $file in mp4";
    (
        ffmpeg -y -loglevel error -i $file -vcodec h264 -acodec aac -crf 28 $file.small.mp4 &&\
        rm $file &&\
        ln -s $file.small.mp4 $file
    ) || rm -f $file.small.mp4
done

# retrieve gif files modified (and so uploaded) during the last 24 hours
for file in $(find . -mtime -1 -type f -and -not -name "*.small.*" | grep -E "\.gif$")
do 
    echo "Compressing $file in webp";
    (
        ffmpeg -y -loglevel error -i $file -vcodec libwebp -lossless 0 -loop 0 -pix_fmt yuva420p -compression_level 8 $file.small.webp &&\
        rm $file &&\
        ln -s $file.small.webp $file
    ) || rm -f $file.small.webp
done