
Recherche avancée
Autres articles (67)
-
La file d’attente de SPIPmotion
28 novembre 2010, parUne file d’attente stockée dans la base de donnée
Lors de son installation, SPIPmotion crée une nouvelle table dans la base de donnée intitulée spip_spipmotion_attentes.
Cette nouvelle table est constituée des champs suivants : id_spipmotion_attente, l’identifiant numérique unique de la tâche à traiter ; id_document, l’identifiant numérique du document original à encoder ; id_objet l’identifiant unique de l’objet auquel le document encodé devra être attaché automatiquement ; objet, le type d’objet auquel (...) -
Le profil des utilisateurs
12 avril 2011, parChaque utilisateur dispose d’une page de profil lui permettant de modifier ses informations personnelle. Dans le menu de haut de page par défaut, un élément de menu est automatiquement créé à l’initialisation de MediaSPIP, visible uniquement si le visiteur est identifié sur le site.
L’utilisateur a accès à la modification de profil depuis sa page auteur, un lien dans la navigation "Modifier votre profil" est (...) -
Configurer la prise en compte des langues
15 novembre 2010, parAccéder à la configuration et ajouter des langues prises en compte
Afin de configurer la prise en compte de nouvelles langues, il est nécessaire de se rendre dans la partie "Administrer" du site.
De là, dans le menu de navigation, vous pouvez accéder à une partie "Gestion des langues" permettant d’activer la prise en compte de nouvelles langues.
Chaque nouvelle langue ajoutée reste désactivable tant qu’aucun objet n’est créé dans cette langue. Dans ce cas, elle devient grisée dans la configuration et (...)
Sur d’autres sites (6816)
-
avfilter : add vf_yadif_videotoolbox
14 décembre 2021, par Aman Karmaniavfilter : add vf_yadif_videotoolbox
deinterlaces CVPixelBuffers, i.e. AV_PIX_FMT_VIDEOTOOLBOX frames
for example, an interlaced mpeg2 video can be decoded by avcodec,
uploaded into a CVPixelBuffer, deinterlaced by Metal, and then
encoded to h264 by VideoToolbox as follows :ffmpeg \
-init_hw_device videotoolbox \
-i interlaced.ts \
-vf hwupload,yadif_videotoolbox \
-c:v h264_videotoolbox \
-b:v 2000k \
-c:a copy \
-y progressive.ts(note that uploading AVFrame into CVPixelBuffer via hwupload
requires 504c60660d3194758823ddd45ceddb86e35d806f)this work is sponsored by Fancy Bits LLC
Reviewed-by : Ridley Combs <rcombs@rcombs.me>
Reviewed-by : Philip Langdale <philipl@overt.org>
Signed-off-by : Aman Karmani <aman@tmm1.net> -
How to make FuncAnimation animations faster ?
12 juin 2021, par ZenitsuThe code I have written is for a Lorrenz Attractor in Python. It shows how a number of random points evolves according to lorrenz equtions and falls into the lorrenz attractor. I did get satisfactory results when I ran the code, but ran into problems while saving the animation as a gif or mp4 file. Python and my text editor started crashing when I tried saving them. I want to know if the code could be simplified or maybe made more effective in some way. Thankyou for helping !!


# Importing all the necessary modules

import matplotlib.pyplot as pl
from mpl_toolkits.mplot3d import Axes3D
from matplotlib.animation import FuncAnimation
import matplotlib.animation as animation
import matplotlib.cm as cm
import numpy as np

#Writer = animation.writers['ffmpeg']
#writer = Writer(fps=15, metadata=dict(artist='Me'), bitrate=1800)

fig = pl.figure(figsize=(35,35))
ax = pl.axes(projection="3d") 
fig.set_facecolor('black')
ax.set_facecolor('black') 
ax.w_xaxis.pane.fill = False
ax.w_yaxis.pane.fill = False
ax.w_zaxis.pane.fill = False
ax.get_proj = lambda: np.dot(Axes3D.get_proj(ax), np.diag([2, 2, 2, 1.3]))
ax.grid(False)
ax.set_axis_off()

# B has the values of sigma, rho and beta used in the lorrenz equations
B =[10,28,8/3]
# t is the dt time element
t = 0.001
# The number of points 
num_points = 20

# These three list will store all the x, y and z position of all the points
X_data = []
Y_data = []
Z_data = []

for i in range(0,num_points,1):
 x_data = []
 y_data = []
 z_data = []
 x , y , z = np.random.uniform(-25,25),np.random.uniform(-25,30),np.random.uniform(0,60)
 for i in np.arange(0,10,t):

 dx = B[0]*(y-x)*t
 dy = (x*(B[1] - z)-y)*t
 dz = (x*y-B[2]*z)*t

 x+=dx
 y+=dy
 z+=dz

 x_data.append(x)
 y_data.append(y)
 z_data.append(z)
 X_data.append(x_data)
 Y_data.append(y_data)
 Z_data.append(z_data)

color = cm.rainbow(np.linspace(0,1,num_points))

def animate(i):
 pl.cla()

 for j in range(0,num_points,1):
 ax.set_axis_off()
 ax.plot3D(X_data[j][2*i:10*i],Y_data[j][2*i:10*i],Z_data[j][2*i:10*i],linewidth=0.5,color=color[j])
 ax.plot3D(X_data[j][10*i],Y_data[j][10*i],Z_data[j][10*i],marker=".",color=color[j],markersize=3)
 ax.set_xlim([-30,30])
 ax.set_ylim([-30,30])
 ax.set_zlim([0,60])

 ax.view_init(0,i/2) 

ani = FuncAnimation(fig,animate,repeat=False,interval=100,frames=600)

# Commented out the bottom part so that i can see it before saving

#ani.save('Lorrenz_Attractor.mp4', writer=writer)

#writer = animation.PillowWriter(fps=10) 
#ani.save("Lorrenz_Attractor.gif", writer=writer)

pl.show()



-
Is ffmpeg broken for h.264 RTP Output ?
13 mars 2023, par GroovyDotComI used wireshark to capture the RTP stream sent with :


ffmpeg -f lavfi -i "testsrc=duration=5:size=cif:rate=25" -pix_fmt yuv420p -g 25 -bf 2 -an -c:v libx264 -f rtp rtp://127.0.0.1:1234 > play.sdp


ffmpeg -version
ffmpeg version git-2020-03-15-c467328 Copyright (c) 2000-2020 the FFmpeg developers


As can be seen in bold, RTP timestamps go forward and backward. I expect them to be the same for every packet in the frame and then only go forward by 40ms (+3600 at 90khz clock) as per the H.264/RTP spec.


Also, according to that spec, the last packet in a frame should have its marker-bit set but here almost all the packets have this bit set.


Am I doing something wrong ? Not understanding something ? Or is ffmpeg support for writing H.264 RTP simply broken ?


SSRC=0xA49C3DC9, Seq=3595, Time=3153114809

SSRC=0xA49C3DC9, Seq=3596, Time=3153114809

SSRC=0xA49C3DC9, Seq=3597, Time=3153114809

SSRC=0xA49C3DC9, Seq=3598, Time=3153114809, Mark

SSRC=0xA49C3DC9, Seq=3599, Time=3153125609, Mark

SSRC=0xA49C3DC9, Seq=3600, Time=3153118409, Mark

SSRC=0xA49C3DC9, Seq=3601, Time=3153122009, Mark

SSRC=0xA49C3DC9, Seq=3602, Time=3153136409, Mark

SSRC=0xA49C3DC9, Seq=3603, Time=3153129209, Mark

SSRC=0xA49C3DC9, Seq=3604, Time=3153132809, Mark

SSRC=0xA49C3DC9, Seq=3605, Time=3153147209, Mark

SSRC=0xA49C3DC9, Seq=3606, Time=3153140009, Mark

SSRC=0xA49C3DC9, Seq=3607, Time=3153143609, Mark

SSRC=0xA49C3DC9, Seq=3608, Time=3153158009, Mark

SSRC=0xA49C3DC9, Seq=3609, Time=3153150809, Mark

SSRC=0xA49C3DC9, Seq=3610, Time=3153154409, Mark

SSRC=0xA49C3DC9, Seq=3611, Time=3153168809, Mark

SSRC=0xA49C3DC9, Seq=3612, Time=3153161609, Mark

SSRC=0xA49C3DC9, Seq=3613, Time=3153165209, Mark

SSRC=0xA49C3DC9, Seq=3614, Time=3153179609, Mark

SSRC=0xA49C3DC9, Seq=3615, Time=3153172409, Mark

SSRC=0xA49C3DC9, Seq=3616, Time=3153176009, Mark

SSRC=0xA49C3DC9, Seq=3617, Time=3153190409, Mark

SSRC=0xA49C3DC9, Seq=3618, Time=3153183209, Mark

The RTP specification, defined in RFC 3550, states that "the timestamp reflects the sampling instant of the first octet in the RTP data packet. The sampling instant must be derived from a clock that increments monotonically and linearly in time to allow synchronization and jitter calculations" (Section 5.1).