まこと の ブログ

MaKoTo no burogu — Journal de bord…

Aller au contenu | Aller au menu | Aller à la recherche

samedi, 3 janvier 2015

Passage des vidéos du blog en webm

  • Jusqu'ici j'utilisais théora pour encoder les vidéos postées sur ce blog, lisibles donc nativement par le navigateur internet.

Suite à quelques tests concluants, notamment lors de la publication de la vidéo du X-Wing, j'ai décidé d'utiliser dorénavant le format VP8 libéré par Google.

En effet, à bitrate équivalent, la qualité de la vidéo obtenue est visuellement bien meilleure, permettant soit de compresser jusqu'à deux fois plus fort pour alléger le fichier, soit d'obtenir une qualité supérieure en conservant le même poids de fichier.

  • Le webm est un dérivé du mkv, c'est le conteneur.

Dedans on va donc y mettre le VP8 pour la vidéo et Ogg (Vorbis) pour l'audio.


Encodage :

Pour encoder avec Ubuntu 14.04, on utilise avconv (si besoin : sudo apt-get install libav-tools), un fork du logiciel ffmpeg.
Sur des versions d'Ubuntu plus ancienne, on remplacera donc l'expression « avconv », par « ffmpeg ».

Voici la commande que j'ai utilisé, qui m'a donné le plus satisfaction :

avconv -i PuramoX-Wing.mpg -s 640x360 -c:v libvpx -qmin 0 -qmax 50 -crf 5 -b:v 600k -c:a libvorbis PuramoX-Wing.webm

Pas de panique, quelques explications :

Lire la suite...

vendredi, 1 février 2013

interruption de service -3-

 Retour de mes sites après quelques jours off-line !!

En effet un problème de connectiques pourries a impacté depuis mardi midi la moitié des résidents de mon immeuble.

Pour les lecteurs hors « planète auto-hébergement » qui ne le saurait pas, cela fait trois ans maintenant que j'auto-héberge mes services internet.
Depuis lors, je n'ai eu à déplorer que deux coupures de longue durée, l'une de 1 journée car mon disjoncteur EDF avait sauté et la présente de 3 jours, due au câblage du FAI.

D'autres soucis mineurs lié à l'administration du serveur sont survenu en trois ans, notamment apache qui saturait la mémoire du serveur, et plantait la machine, un simple reboot du serveur suffisant à faire repartir la disponibilités de mes pages, et depuis ce problème est résolu en activant le multi-threading php.
Mais j'ai envie de dire que ce genre de panne surviendrait tout autant avec un hébergement payant et centralisé, donc ça compte pas :D

jeudi, 2 février 2012

Du bon usage de la sauvegarde de donnée -3- LiveBox2 n'est PAS un vrai routeur !

livebox.png Pour faire suite au billet précédent sur la sauvegarde de donnée à distance, avec mise en marche de l'ordinateur sur demande, voici la mise en pratique sur le site de sauvegarde.
Concernant le Wake On Lan, chez moi, les tests en local et via internet s'étaient bien passés…
Mais chez Orange c'est une toute autre affaire que je m'en vais vous conter de suite !

Pour les pressés, conclusion avant l'heure : WOL avec le FAI Orange (LiveBox2 sagem) et routeur Linksys DD-WRT (port forwarding) est impossible !

Tout aurait dû se dérouler tranquillement…

J'ai pourtant procédé exactement de la même manière que précédemment, mais pas moyen… impossible d'allumer ce satané ordi…
Il se trouve que ce bel outil qu'est Wireshark, m'indiquait que le paquet magique n'était simplement pas dirigé vers la bonne machine sur le réseau local… Port Unreachable.

  • J'indiquais bel et bien à la LiveBox2 de rediriger les paquets en provenance des ports 7-9 vers l'IP du routeur Linksys DD-WRT, et à ce dernier de rediriger ces paquets vers l'IP de l'ordi que je souhaitais réveiller… Mais rien… Paquets perdu dans la nature…

Lire la suite...

mardi, 27 décembre 2011

Apache2 en mode multi-thread

Depuis déjà 6 mois, comme cela s'était déjà produit, mon serveur plante de temps à autre…
Le démon Apache2 devient fou et déclenche les foudres d'anon, le killer de démon, qui vise à libérer de l'espace mémoire Ram+Swap, mais la Machine est à ce point submergée que rien n'y fait, il est impossible de prendre la main et le disque dur gratte comme un fou, jusqu'à ce qu'on veuille bien lui administrer les magic syst key (SEIUB)

En fait mon serveur s'est retrouvé non pas victime de son succès, mais de la coïncidence de plusieurs événements simultanés :
. scan par les robots de divers moteurs de recherche
+ scan de divers planet
+ consultation de visiteurs de mes deux sites
+ mon propre usage de TinyTinyRSS
= Autant de démon Apache2 qui se lancent que de requêtes html, php5, etc.

Bref, le temps de cerner le coupable et comprendre le problème, j'ai enfin décidé de tenter quelque chose… Apache2 en mode multi-thread

Il m'avait bien semblé voir passer un billet au titre intéressant, et en fouillant les tréfonds de ce cher TinyTinyRSS j'ai pu le retrouver et le mettre en œuvre !

Très clair, on y explique ce qui semble être la solution à mon problème, et la méthode fonctionne très bien !
Maintenant il y a très peu de lourd démon Apache2 et beaucoup de léger démon php.
On peut aussi vérifier la config en créant la fameuse page phpinfo.

Mais ayant eu quelques soucis avec ma config, je vais préciser certaines choses :

  • En premier lieux, si vous utilisez un accès https pour lire votre Webmail ou votre TinyTinyRSS, vous risquez de tomber sur une erreur de type :
ERROR : Wrong 'suhosin.session.encrypt' option value

Et effectivement, comme pour /etc/php5/cgi/php.ini, la config cgi de suhosin est elle aussi placée ailleurs.
Il faudra alors éditer /etc/php5/cgi/conf.d/suhosin.ini et dé-commenter puis mettre à off la ligne suhosin.session.encrypt

suhosin.session.encrypt = off
  • Seconde chose, l'upload de fichiers de plus de 130 kio au travers de php s'est révélé impossible (via Dotclear, Owncloud…) avec notamment des erreurs 500.

Et ceci alors même que la configuration dans le nouveau fichier /etc/php5/cgi/php.ini était correcte, c'est à dire :

file_uploads= On

ou Off permet d'autoriser ou non l'envoi de fichiers.

upload_max_filesize = 2M

permet de définir la taille maximale autorisée pour le fichier. Si cette limite est dépassée, le serveur enverra un code d'erreur.

post_max_size = 2M

indique la taille maximale des données envoyées par un formulaire. Cette directive prime sur upload_max_filesize, il faut donc s'assurer d'avoir post_max_size supérieure à upload_max_filesize.

En fait, c'est un autre fichier de config qui fixait la limite de 130 kio !
C'est donc /etc/apache2/mods-available/fcgid.conf qu'il faut amender d'une ligne MaxRequestLen

<IfModule mod_fcgid.c>
  AddHandler    fcgid-script .fcgi
  FcgidConnectTimeout 20
  MaxRequestLen 1073741824
</IfModule>

Ici j'ai donc mis 1 Gio, valeur configurée par défaut lorsqu'on utilise Apache2 en mode « pas multi-thread»
Ce qui au passage, explique enfin pourquoi avec Owncloud je ne pouvais pas uploader plus d'1 Gio par fichier ^^

Sources :
- http://www.commentcamarche.net/faq/889-php-upload-de-fichiers#configuration-de-php-pour-permettre-l-upload
- http://blog.philippklaus.de/2011/04/fix-mod_fcgid-http-request-length-xyz-so-far-exceeds-maxrequestlen-131072/
- http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html#fcgidmaxrequestlen

- page 1 de 8