
Recherche avancée
Autres articles (63)
-
Amélioration de la version de base
13 septembre 2013Jolie sélection multiple
Le plugin Chosen permet d’améliorer l’ergonomie des champs de sélection multiple. Voir les deux images suivantes pour comparer.
Il suffit pour cela d’activer le plugin Chosen (Configuration générale du site > Gestion des plugins), puis de configurer le plugin (Les squelettes > Chosen) en activant l’utilisation de Chosen dans le site public et en spécifiant les éléments de formulaires à améliorer, par exemple select[multiple] pour les listes à sélection multiple (...) -
Installation en mode ferme
4 février 2011, parLe mode ferme permet d’héberger plusieurs sites de type MediaSPIP en n’installant qu’une seule fois son noyau fonctionnel.
C’est la méthode que nous utilisons sur cette même plateforme.
L’utilisation en mode ferme nécessite de connaïtre un peu le mécanisme de SPIP contrairement à la version standalone qui ne nécessite pas réellement de connaissances spécifique puisque l’espace privé habituel de SPIP n’est plus utilisé.
Dans un premier temps, vous devez avoir installé les mêmes fichiers que l’installation (...) -
La sauvegarde automatique de canaux SPIP
1er avril 2010, parDans le cadre de la mise en place d’une plateforme ouverte, il est important pour les hébergeurs de pouvoir disposer de sauvegardes assez régulières pour parer à tout problème éventuel.
Pour réaliser cette tâche on se base sur deux plugins SPIP : Saveauto qui permet une sauvegarde régulière de la base de donnée sous la forme d’un dump mysql (utilisable dans phpmyadmin) mes_fichiers_2 qui permet de réaliser une archive au format zip des données importantes du site (les documents, les éléments (...)
Sur d’autres sites (12418)
-
Encoding video for real time streaming
15 septembre 2019, par lilrooMiguel Grinberg’s article video streaming with flask, covers sending multiple JPG formatted images to a client through a multipart response to stream video to the browser.
After doing some reading, I quickly realized that MJPEG is not a real video format, JPEGs are not optimized for video streaming and MJPEG cannot be streamed to a HTML5 video element.
for my application (a screen sharing application written in python), I need to be able to encode and stream relatively smooth video (smoother than MJPEG anyway) in semi-realtime to the browser.
I think what I need to do is encode a video stream using a tool like FFmpeg and then send chunks of that output to a browser using a multipart response - however it doesn’t look like there is a way to get FFmpeg (using python bindings) to write to an in-memory buffer.
Is ffmpeg up to this task ?
I appreciate that this question may sound nieve, but I would be thankful for being pointed in the right direction.
-
Why is ffmpeg transcoding speed going down over time ?
24 mars 2021, par Nikola R.I'm executing basic ffmpeg command to transcode input MP4 video to output MP4 video (both using H264 as video codec, and stripping out audio, for simplicity) :



ffmpeg -i input-video.mp4 -b:v 20000k -an -vcodec libx264 output-video.mp4




Transcoding is initially pretty fast (around 60-70 fps for first 20 or so frames), and then starts dropping steadily, ending at around 30 fps after 5000 frames.



Is this inherent behavior ? If so, why does it happen ?
Also, is there any better option for the command line that would improve speed (besides using -threads) ?



Would it be better to cut the input video and process it as smaller chunks, getting overall higher speed per sequence ? (I'm afraid that chunking might affect encoder's RD optimization)


-
Why is ffmpeg transcoding speed going down over time ?
24 mars 2021, par Nikola R.I'm executing basic ffmpeg command to transcode input MP4 video to output MP4 video (both using H264 as video codec, and stripping out audio, for simplicity) :



ffmpeg -i input-video.mp4 -b:v 20000k -an -vcodec libx264 output-video.mp4




Transcoding is initially pretty fast (around 60-70 fps for first 20 or so frames), and then starts dropping steadily, ending at around 30 fps after 5000 frames.



Is this inherent behavior ? If so, why does it happen ?
Also, is there any better option for the command line that would improve speed (besides using -threads) ?



Would it be better to cut the input video and process it as smaller chunks, getting overall higher speed per sequence ? (I'm afraid that chunking might affect encoder's RD optimization)