
Recherche avancée
Autres articles (69)
-
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 (...) -
Menus personnalisés
14 novembre 2010, parMediaSPIP utilise le plugin Menus pour gérer plusieurs menus configurables pour la navigation.
Cela permet de laisser aux administrateurs de canaux la possibilité de configurer finement ces menus.
Menus créés à l’initialisation du site
Par défaut trois menus sont créés automatiquement à l’initialisation du site : Le menu principal ; Identifiant : barrenav ; Ce menu s’insère en général en haut de la page après le bloc d’entête, son identifiant le rend compatible avec les squelettes basés sur Zpip ; (...) -
Gestion de la ferme
2 mars 2010, parLa ferme est gérée dans son ensemble par des "super admins".
Certains réglages peuvent être fais afin de réguler les besoins des différents canaux.
Dans un premier temps il utilise le plugin "Gestion de mutualisation"
Sur d’autres sites (6513)
-
Convert png to mp4
9 septembre 2018, par user3073118I have a lot of png files that I want to convert to mp4 in R.
I used to convert it to .gif using ImageMagick, then converting it using a free online website from .gif to MP4.
library(magick)
system(command = "convert -delay 70 '/Users/Desktop/figures/*.png' '/Users/Desktop/figures/animation.gif'")But the current file size is too big, such that even converting it to .gif takes hours.
Is there a way I can convert it directly from png to mp4 in R ?
I tried to look up ffmpeg but I have a MAC and installing it is a little confusing...
Thanks !
-
Background transparency lost on new machine using matplotlib and ffmpeg
23 octobre 2023, par Jan TurowskiI am creating animated physics graphs with a transparent background for later use in a NLE. On my old machine at work they display and render with background transparency just fine. The exact same code however loses background transparency in the ffmpeg render on both my Linux and my Windows machine at home. The animations are displayed just fine on all machines.


As I first thought it was a Linux issue, I tried to run the code on my Windows machine expecting it to work again. Unfortunately it did not.


Reduced code :


import numpy as np
import matplotlib.pylab as plt
from matplotlib.animation import FuncAnimation
import matplotlib.animation as animation
from matplotlib.pyplot import figure
from matplotlib import style
import locale
from matplotlib.ticker import (MultipleLocator, AutoMinorLocator)
# Set to German locale to get comma decimal separater
locale.setlocale(locale.LC_NUMERIC, "de_DE")
# Tell matplotlib to use the locale we set above
plt.rcParams['axes.formatter.use_locale'] = True

# plt.clf()
# plt.rcdefaults()

# Style und Font definieren

style.use('dark_background')

# Pfeile erstellen
def arrowed_spines(fig, ax):

 xmin, xmax = ax.get_xlim()
 ymin, ymax = ax.get_ylim()

 # removing the default axis on all sides:
 for side in ['bottom','right','top','left']:
 ax.spines[side].set_visible(False)

 # removing the axis ticks
 # plt.xticks([]) # labels
 # plt.yticks([])
 # ax.xaxis.set_ticks_position('none') # tick markers
 # ax.yaxis.set_ticks_position('none')

 # get width and height of axes object to compute
 # matching arrowhead length and width
 dps = fig.dpi_scale_trans.inverted()
 bbox = ax.get_window_extent().transformed(dps)
 width, height = bbox.width, bbox.height

 # manual arrowhead width and length
 hw = 1./20.*(ymax-ymin)
 hl = 1./20.*(xmax-xmin)
 lw = 1. # axis line width
 ohg = 0.3 # arrow overhang

 # compute matching arrowhead length and width
 yhw = hw/(ymax-ymin)*(xmax-xmin)* height/width
 yhl = hl/(xmax-xmin)*(ymax-ymin)* width/height

 # draw x and y axis
 ax.arrow(xmin, 0, xmax-xmin, 0., fc='w', ec='w', lw = lw,
 head_width=hw, head_length=hl, overhang = ohg,
 length_includes_head= True, clip_on = False)

 ax.arrow(0, ymin, 0., ymax-ymin, fc='w', ec='w', lw = lw,
 head_width=yhw, head_length=yhl, overhang = ohg,
 length_includes_head= True, clip_on = False)

# Meine easing-Funktion
def ease(n):
 if n < 0.0:
 return 0
 elif n > 1.0:
 return 1
 else:
 return 3*n**2-2*n**3

# Meine Floor/Warte Funktion
def wait(n):
 if n < 0.0:
 return 0
 else:
 return n

# Canvas erstellen
fig = plt.figure()
ax = fig.add_subplot(111)
fig.set_size_inches([8,9])

def f(x):
 return -0.05*x**2+125
xlin = np.linspace(0,60,100)


# Beschriftung und Optik

plt.xlabel(r"$x$ in $\rm{m}$", horizontalalignment='right', x=1.0)
plt.ylabel(r"$y$ in $\rm{m}$", horizontalalignment='right', y=1.0)
ax.set_xlim(0,100)
ax.set_ylim(0,139)
plt.grid(alpha=.4)
plt.xticks(np.arange(0, 100, 20))
plt.yticks(np.arange(0, 140, 20))
ax.yaxis.set_minor_locator(MultipleLocator(10))
ax.xaxis.set_minor_locator(MultipleLocator(10))
ax.tick_params(axis='x', direction = "inout", length= 10.0, which='both', width=3)
ax.tick_params(axis='y', direction = "inout", length= 10.0, which='both', width=3)


xsub = np.array([0])

# statische Linien definieren
line2, = ax.plot(xsub,f(xsub),linewidth=5,zorder=0,c = 'b')
arrowed_spines(fig, ax)
plt.tight_layout()

# Linien animieren
def animate(i):

 xsub = xlin[0:wait(i-20)]
 global line2
 line2.remove()
 line2, = ax.plot(xsub, f(xsub), linewidth=5, zorder=0,c = "b")
 plt.tight_layout()

animation = FuncAnimation(fig, animate, np.arange(0, 130, 1), interval=100)

plt.show()

# animation.save(r"YOUR\PATH\HERE\reduced_x-y.mov", codec="png",
 dpi=100, bitrate=-1,
 savefig_kwargs={'transparent': True, 'facecolor': 'none'})




-
ffmpeg drops time delay on last frame of animated GIF
13 août 2014, par AustinI am trying to convert animated GIFs to MP4 files using ffmpeg and x264. However, I seem be suffering from the effects of this bug in ffmpeg that causes the delay time of the last frame of the GIF to be ignored. For very short GIFs, this is quite a problem.
As a work around, I was thinking that I should be able to manually tell ffmpeg to freeze on the last frame for a certain amount of time, specifically the proper duration of that frame (which I can extract from the GIF). However, I can’t seem to find a good way to do this. Any suggestions ? I would really like to be able to do this without having to split to the GIF into frames before putting it into ffmpeg since that will mess up GIFs with a non-constant framerate (in addition to being much slower).
I am using ffmpeg version 2.3, though I have also tried this with the latest git code without any improvement. The full ffmpeg commands I’m using look like this :
ffmpeg -i animation.gif -vf "scale=trunc(in_w/2)*2:trunc(in_h/2)*2" -c:v libx264 -b:v 2000k -y -pix_fmt yuv420p -f mp4 animation.mp4
Here is some console output :
ffmpeg version 2.3 Copyright (c) 2000-2014 the FFmpeg developers
built on Aug 11 2014 21:19:46 with gcc 4.8 (Ubuntu 4.8.2-19ubuntu1)
configuration: --enable-gpl --enable-libass --enable-libfreetype --enable-libtheora --enable-libvorbis --enable-libx264
libavutil 52. 92.100 / 52. 92.100
libavcodec 55. 69.100 / 55. 69.100
libavformat 55. 48.100 / 55. 48.100
libavdevice 55. 13.102 / 55. 13.102
libavfilter 4. 11.100 / 4. 11.100
libswscale 2. 6.100 / 2. 6.100
libswresample 0. 19.100 / 0. 19.100
libpostproc 52. 3.100 / 52. 3.100
Input #0, gif, from 'animation.gif':
Duration: N/A, bitrate: N/A
Stream #0:0: Video: gif, bgra, 500x375, 100 tbr, 100 tbn, 100 tbc
[libx264 @ 0x239ea00] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
[libx264 @ 0x239ea00] profile High, level 3.1
[libx264 @ 0x239ea00] 264 - core 142 - H.264/MPEG-4 AVC codec - Copyleft 2003-2014 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=6 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=abr mbtree=1 bitrate=2000 ratetol=1.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
Output #0, mp4, to 'animation.mp4':
Metadata:
encoder : Lavf55.48.100
Stream #0:0: Video: h264 (libx264) ([33][0][0][0] / 0x0021), yuv420p, 500x374, q=-1--1, 2000 kb/s, 100 fps, 12800 tbn, 100 tbc
Metadata:
encoder : Lavc55.69.100 libx264
Stream mapping:
Stream #0:0 -> #0:0 (gif (native) -> h264 (libx264))
Press [q] to stop, [?] for help
frame= 7 fps=0.0 q=-1.0 Lsize= 7kB time=00:00:00.05 bitrate=1222.1kbits/s dup=5 drop=0
video:7kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 13.542441%
[libx264 @ 0x239ea00] frame I:1 Avg QP:34.86 size: 3657
[libx264 @ 0x239ea00] frame P:3 Avg QP:30.86 size: 744
[libx264 @ 0x239ea00] frame B:3 Avg QP:33.33 size: 49
[libx264 @ 0x239ea00] consecutive B-frames: 42.9% 0.0% 0.0% 57.1%
[libx264 @ 0x239ea00] mb I I16..4: 10.2% 78.3% 11.6%
[libx264 @ 0x239ea00] mb P I16..4: 1.2% 5.0% 0.8% P16..4: 11.7% 3.3% 1.2% 0.0% 0.0% skip:76.8%
[libx264 @ 0x239ea00] mb B I16..4: 0.0% 0.1% 0.0% B16..8: 3.7% 0.0% 0.0% direct: 0.0% skip:96.2% L0:23.5% L1:76.5% BI: 0.0%
[libx264 @ 0x239ea00] final ratefactor: 20.31
[libx264 @ 0x239ea00] 8x8 transform intra:77.0% inter:79.4%
[libx264 @ 0x239ea00] coded y,uvDC,uvAC intra: 39.5% 0.0% 0.0% inter: 2.7% 0.0% 0.0%
[libx264 @ 0x239ea00] i16 v,h,dc,p: 38% 27% 7% 28%
[libx264 @ 0x239ea00] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 35% 12% 13% 7% 6% 10% 4% 8% 5%
[libx264 @ 0x239ea00] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 38% 11% 14% 5% 8% 10% 5% 7% 2%
[libx264 @ 0x239ea00] i8c dc,h,v,p: 100% 0% 0% 0%
[libx264 @ 0x239ea00] Weighted P-Frames: Y:0.0% UV:0.0%
[libx264 @ 0x239ea00] ref P L0: 99.1% 0.7% 0.3%
[libx264 @ 0x239ea00] ref B L0: 85.0% 15.0%
[libx264 @ 0x239ea00] ref B L1: 95.4% 4.6%
[libx264 @ 0x239ea00] kb/s:689.83