
Recherche avancée
Médias (1)
-
MediaSPIP Simple : futur thème graphique par défaut ?
26 septembre 2013, par
Mis à jour : Octobre 2013
Langue : français
Type : Video
Autres articles (61)
-
Pas question de marché, de cloud etc...
10 avril 2011Le vocabulaire utilisé sur ce site essaie d’éviter toute référence à la mode qui fleurit allègrement
sur le web 2.0 et dans les entreprises qui en vivent.
Vous êtes donc invité à bannir l’utilisation des termes "Brand", "Cloud", "Marché" etc...
Notre motivation est avant tout de créer un outil simple, accessible à pour tout le monde, favorisant
le partage de créations sur Internet et permettant aux auteurs de garder une autonomie optimale.
Aucun "contrat Gold ou Premium" n’est donc prévu, aucun (...) -
Activation de l’inscription des visiteurs
12 avril 2011, parIl est également possible d’activer l’inscription des visiteurs ce qui permettra à tout un chacun d’ouvrir soit même un compte sur le canal en question dans le cadre de projets ouverts par exemple.
Pour ce faire, il suffit d’aller dans l’espace de configuration du site en choisissant le sous menus "Gestion des utilisateurs". Le premier formulaire visible correspond à cette fonctionnalité.
Par défaut, MediaSPIP a créé lors de son initialisation un élément de menu dans le menu du haut de la page menant (...) -
Déploiements possibles
31 janvier 2010, parDeux types de déploiements sont envisageable dépendant de deux aspects : La méthode d’installation envisagée (en standalone ou en ferme) ; Le nombre d’encodages journaliers et la fréquentation envisagés ;
L’encodage de vidéos est un processus lourd consommant énormément de ressources système (CPU et RAM), il est nécessaire de prendre tout cela en considération. Ce système n’est donc possible que sur un ou plusieurs serveurs dédiés.
Version mono serveur
La version mono serveur consiste à n’utiliser qu’une (...)
Sur d’autres sites (5953)
-
Evolution #3649 : Ajouter un champ pour préciser le préfixe SPIP d’une base externe
9 février 2021, par cedric -en effet il manque le prefixe
-
Revision 681d5e9024 : Merge "Only allow for cyclic refresh (aq=3 mode) for base layer."
24 novembre 2014, par MarcoMerge "Only allow for cyclic refresh (aq=3 mode) for base layer."
-
Dealing with long conversion times on nginx, ffmpeg and Ruby on Rails
19 avril 2013, par GraemeI have developed a Ruby on Rails-based app which allows users to upload videos to one of our local servers (Ubunto 10.04 LTS). The server uses nginx.
Through the paperclip-ffmpeg gem, videos are converted to mp4 format using the ffmpeg library.
Everything appears to be working fine in production, except Rails' own 500 page (not the customised version I have provided - but that's a different issue) is displayed whenever certain videos are uploaded. Otherwise, videos are being converted as expected.
Having done a bit of investigation, I think the default 500 page is being displayed because a 502 error has occurred. I think what is happening, having uploaded the videos locally, is that some videos are taking an extensive amount of time to convert, and that an interruption is occurring on the server (I'm not a server expert by any means).
Using the excellent Railscasts episode on deployment, I use Capistrano to deploy the app. Here's the
unicorn.rb
file :root = "XXXXXXX"
working_directory root
pid "#{root}/tmp/pids/unicorn.pid"
stderr_path "#{root}/log/unicorn.log"
stdout_path "#{root}/log/unicorn.log"
listen "/tmp/unicorn.XXXXXXXXX.sock"
worker_processes 2
timeout 200And here's the
nginx.conf
file. Note thatclient_max_body_size
has been set to a fairly hefty 4Gb ! :upstream unicorn {
server unix:/tmp/unicorn.XXXXXXXXX.sock fail_timeout=0;
}
server {
listen 80 default deferred;
root XXXXXXXXX;
location ^~ /assets/ {
gzip_static on;
expires max;
add_header Cache-Control public;
}
try_files $uri/index.html $uri @unicorn;
location @unicorn {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_read_timeout 600;
proxy_redirect off;
proxy_pass http://unicorn;
}
error_page 500 502 503 504 /500.html;
client_max_body_size 4G;
keepalive_timeout 10;
}So, my question is...how could I edit (either of) the above two files to deal with the extensive time that certain videos take to convert through ffmpeg - possibly up to an hour, 2 hours or even more ?
Should I extend
timeout
in the former and/orkeepalive_timeout
in the latter - or is there a more efficient way (given that I've no idea how long certain videos will take to convert) ?Or, is there possibly a more significant issue I should consider - e.g. the amount of memory in the server ?
I'm not an nginx/server expert, so any advice would be useful (particularly where to put extra lines of code) - however, as the rest of the app just "works", I'm not keen to make a huge amount of changes !