
Recherche avancée
Médias (2)
-
GetID3 - Bloc informations de fichiers
9 avril 2013, par
Mis à jour : Mai 2013
Langue : français
Type : Image
-
GetID3 - Boutons supplémentaires
9 avril 2013, par
Mis à jour : Avril 2013
Langue : français
Type : Image
Autres articles (27)
-
MediaSPIP v0.2
21 juin 2013, parMediaSPIP 0.2 est la première version de MediaSPIP stable.
Sa date de sortie officielle est le 21 juin 2013 et est annoncée ici.
Le fichier zip ici présent contient uniquement les sources de MediaSPIP en version standalone.
Comme pour la version précédente, il est nécessaire d’installer manuellement l’ensemble des dépendances logicielles sur le serveur.
Si vous souhaitez utiliser cette archive pour une installation en mode ferme, il vous faudra également procéder à d’autres modifications (...) -
Mise à disposition des fichiers
14 avril 2011, parPar défaut, lors de son initialisation, MediaSPIP ne permet pas aux visiteurs de télécharger les fichiers qu’ils soient originaux ou le résultat de leur transformation ou encodage. Il permet uniquement de les visualiser.
Cependant, il est possible et facile d’autoriser les visiteurs à avoir accès à ces documents et ce sous différentes formes.
Tout cela se passe dans la page de configuration du squelette. Il vous faut aller dans l’espace d’administration du canal, et choisir dans la navigation (...) -
MediaSPIP version 0.1 Beta
16 avril 2011, parMediaSPIP 0.1 beta est la première version de MediaSPIP décrétée comme "utilisable".
Le fichier zip ici présent contient uniquement les sources de MediaSPIP en version standalone.
Pour avoir une installation fonctionnelle, il est nécessaire d’installer manuellement l’ensemble des dépendances logicielles sur le serveur.
Si vous souhaitez utiliser cette archive pour une installation en mode ferme, il vous faudra également procéder à d’autres modifications (...)
Sur d’autres sites (7062)
-
Is Replacing Dynamic Resolution with scale_amf in FFmpeg Command a Good Direction ?
21 novembre 2024, par fredI'm working on a Lua script for MPV that processes 360-degree videos using FFmpeg's v360 filter. The original command dynamically calculates the output resolution based on a res variable, like this :


mp.command_native_async({
 "no-osd", "vf", "add", 
 string.format(
 "@vrrev:v360=%s:%s:reset_rot=1:in_stereo=%s:out_stereo=2d:
id_fov=%s:d_fov=%.3f:yaw=%.3f:pitch=%s:roll=%.3f:
w=%s*192.0:h=%.3f*108.0:h_flip=%s:interp=%s",
 in_flip, inputProjection, outputProjection, in_stereo, idfov, dfov, yaw, pitch, roll, res, res, h_flip, scaling
 )
}, updateComplete)



Change Proposal :


I am considering replacing the dynamic width and height calculations with a scale_amf filter to handle scaling more efficiently and leverage GPU acceleration. The updated command would look like this :


mp.command_native_async({
 "no-osd", "vf", "add", 
 string.format(
 "@vrrev:v360=%s:%s:reset_rot=1:in_stereo=%s:out_stereo=2d:
id_fov=%s:d_fov=%.3f:yaw=%.3f:pitch=%s:roll=%.3f,
%sscale_amf=w=%.0f:h=%.0f",
 inputProjection, outputProjection, in_stereo, idfov, dfov, yaw, pitch, roll, in_flip, res * 192.0, res * 108.0
 )



Hardware Specifications :


I am using an AMD Ryzen 5 5600G, no display card, 16GB RAM, Windows 10.


Questions :


Is using scale_amf for scaling a good direction in terms of performance and efficiency ?
Are there any potential drawbacks to this approach that I should be aware of ?
How does using scale_amf compare to the original dynamic resolution method in terms of output quality and processing speed ?
}, updateComplete)


Any insights or experiences with this change would be greatly appreciated !


-
ffmpeg ignores input svg files resolution and produces 100x100 video [closed]
11 novembre 2024, par Francesco PotortìI have used this command for some years to produce .ogg files (or any other format) from a series of .svg files on Linux :


ffmpeg -y -r 1.2 -i %06d.svg -qscale:v 10 path.ogg


It has worked flawlessly until now, when it produces a video with 100x100 resolution, rather then the 1920x1080 resolution of the input files.


If I force the output resolution to be 1920x1080 using the
-s
option, the resulting video is a magnified version of the 100x100 video output I obtain without the-s
option. If I convert the svg files to png usinginkscape
everything is well, but I'd like to avoid making my workflow more complex.

Here you can find some of the .svg files.


Any ideas ?


-
FFprobe reading incorrect resolution value despite players rendering it correctly
28 octobre 2024, par BoehmiI'm creating a video from a stream with the help of FFMPEG and I also use FFPROBE to gather information for use on a status page like resolution, codecs et cetera.



When FFProbe parses my video for information, I get a resolution value of 544x576 (almost a square !), but an aspect ratio of 16:9.



These values are consistent on both the input stream and my saved video.



When I watch the video in the standard HTML5 Player, VLC or FFPLAY however, I get a video with the proportions of 16:9 and a resolution (measured using an image editing program) of 1024x576 that does look native and not stretched in any way.



Even if I re-encode the video using slightly different codecs, this incorrect resolution value persists, even though every player I use displays it correctly.



This is slightly inconvenient because I am relying on getting the correct resolution value from the video for further processing.



I'm also using a recent FFMPEG+FFPROBE version that was compiled on the 15th of July.



Is this a bug within FFMPEG or is there anything I'm doing wrong ?



Used command lines :



FFMPEG :



ffmpeg -i source -loglevel debug -vcodec copy -acodec copy -bsf:a aac_adtstoasc -movflags +faststart -t 360 -y video.mp4




FFPROBE (I parse the output of this directly and save the values) :



ffprobe -i source -show_format -show_streams 




FFProbe output :



width=544
height=576
coded_width=544
coded_height=576
has_b_frames=2
sample_aspect_ratio=32:17
display_aspect_ratio=16:9




I can see that the sample aspect ratio is different from the display aspect ratio, but how come the video looks proper in 16:9 when it's supposedly encoded at a near square resolution ?