Recherche avancée

Sur d’autres sites (6914)

• How to build a daemon to encode video files on S3 ?

  4 avril 2013, par Yuval Cohen

  I am interested in running a daemon to go over user uploaded video files and encode them in an optimal format (and add some watermarks).

  I was considering services such as Zencoder, Encoding.com, Amazon's encoding service but some lack overlaying capabilities and some are just too expensive for our (big) volumes.

  I want to build a daemon that encodes videos that are located on S3 once users upload them.

  The solution I thought of would be Python Heroku servers using Celery for a task queue to keep track of the encoded files and ffmpeg to do the actual work. However, I ran into troubles compiling ffmpeg for Heroku (with libass support, so the basic ffmpeg bins aren't enough).

  What approach/technology stack would you consider for this mini-project ?

  Thanks !
  Yuval

• Encoding videos locally or through a third party ?

  7 septembre 2015, par JordanDevelop

  We’re in the process on building a view uploading and sharing community right now and we’re currently developing with idea of using a third-party like Zencoder, but what makes Zencoder a better option ?

  I’m sorry if i butcher up what is involved with supporting a local encoding system, so I’ll try to be vague. We plan on releasing with AWS, so why not setup an instance running ffmpeg ? I understand it’s a lot more then simply that, but if is it that difficult to find someone who can put together an instance for encoding ?

  Am I right to assume most third party encoding services seem very unrealistic, price wise, for a web application who specifically focus on encoding large amounts of media ? I did notice Amazon offers an encoding features and would definitely feel more comfortable using them, but even that seems seems redundant.

  I completely understand the cost behind encoding is very real, but I just can’t understand why third-party encoders are so widely accepted.

• Evolution #4739 (Nouveau) : Styles des boîtes et messages du privé

  19 avril 2021

  Dans la foulée des styles des formulaires, je pense qu’il serait bien d’accorder ça avec les styles des boîtes #BOITE_OUVRIR.
  Mais avant d’y aller, je prends la température.

  Si une alpha est prévue pour le 1er mai ça va être un peu sport. Cela dit, c’est moins compliqué que les formulaires puisqu’il ne s’agit que de l’emballage extérieur, et il s’agit de reprendre une partie des styles des formulaires. Bref ça pourrait.

  Par contre ça repose sur une partie des évolutions de la PR 157, donc travail à entamer qu’après celle-ci intégrée.

  Boîtes¶

  Dans l’immédiat je ne souhaite pas revenir sur toutes les variantes de boîtes (info, raccourcis, inverse, etc.), qui devraient rester pareil dans les grandes lignes.
  Par contre il faudrait alléger les variantes notice, erreur et info. Sur la page de maintenance c’est festif actuellement :)

  La direction que je veux prendre, c’est de mettre juste une bordure de couleur, et éventuellement déplacer l’icône en haut.
  Cf. image boite_notice_1.png en pièce-jointe.

  Messages¶

  Par contre un truc un peu problématique, c’est que ces boîtes font un peu double emploi : parfois elles ne sont pas utilisées en tant que boîte à proprement parler, mais en tant que message d’alerte (notice, success, error).
  Je pense qu’il faudrait éviter de les utiliser comme ça, ce sont 2 besoins différents, et ça devrait être 2 composants différents avec des styles propres.

  Dans ce cas, il s’agit de l’équivalent des alertes de Bootstrap par exemple : https://getbootstrap.com/docs/5.0/components/alerts/

  Exemple : sur la page maintenance, le bloc « htaccess inopérant » ça devrait être un simple message d’alerte.
  Et tout bas, le bloc « effacer les statistiques » c’est logique qu’il s’agisse d’une boîte.

  Alors ce composant « alerte » existe à peu près, mais un peu par contingence je crois : il y a des classes .notice, error et .info qu’on peut appliquer à un div, et ça semble faire le job.
  Mais il faudrait rendre ça plus sûr : une classe .alerte et ces déclinaisons .alerte_notice, .alerte_error et .alerte_info
  Pour officialiser ça pourrait pourquoi pas être complété par une balise #ALERTE{titre, variante, …}.

  Là au niveau des styles, ça serait en mode flat, sans ombre portée, et avec un fond de couleur (proche voir identique aux messages de retour des formulaires).
  Cf. image message_notice_1.png en pièce-jointe.