
Recherche avancée
Autres articles (71)
-
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 (...) -
Support de tous types de médias
10 avril 2011Contrairement à beaucoup de logiciels et autres plate-formes modernes de partage de documents, MediaSPIP a l’ambition de gérer un maximum de formats de documents différents qu’ils soient de type : images (png, gif, jpg, bmp et autres...) ; audio (MP3, Ogg, Wav et autres...) ; vidéo (Avi, MP4, Ogv, mpg, mov, wmv et autres...) ; contenu textuel, code ou autres (open office, microsoft office (tableur, présentation), web (html, css), LaTeX, Google Earth) (...)
Sur d’autres sites (6501)
-
lavu/pixdesc : handle xv30be in av_[read|write]_image_line
4 décembre 2022, par Philip Langdalelavu/pixdesc : handle xv30be in av_read_image_line
xv30be is an obnoxious format that I shouldn't have included in the
first place. xv30 packs 3 10bit channels into 32bits and while our
byte-oriented logic can handle Little Endian correctly, it cannot
handle Big Endian. To avoid that, I marked xv30be as a bitstream
format, but while that didn't produce FATE errors, it turns out that
the existing read/write code silently produces incorrect results, which
can be revealed via ubsan.In all likelyhood, the correct fix here is to remove the format. As
this format is only used by Intel vaapi, it's only going to show up
in LE form, so we could just drop the BE version. But I don't want to
deal with creating a hole in the pixfmt list and all the weirdness that
comes from that. Instead, I decided to write the correct read/write
code for it.And that code isn't too bad, as long as it's specialised for this
format, as the channels are all bit-aligned inside a 32bit word. -
swresample/resample : do not increase phase_count on exact_rational
17 juin 2016, par Muhammad Faizswresample/resample : do not increase phase_count on exact_rational
high phase_count is only useful when dst_incr_mod is non zero
in other word, it is only useful on soft compensationon init, it will build filter with low phase_count
but when soft compensation is enabled, rebuild filter
with high phase_countthis approach saves lots of memory
Reviewed-by : Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by : Muhammad Faiz <mfcc64@gmail.com> -
Is there an efficient way to use ffmpeg to create a huge quantity of small video file, cut from a larger one ?
9 mars 2024, par Giuliano OliveriI'm trying to cut video files into smaller chunks. (each one being one word said in the video, so they're not all of equal size)


I've tried a lot of different approaches to try to be as efficient as possible, but I can't get the runtime to be under 2/3rd of the original video length. That's an issue because I'm trying to process 400+ hours of video.


Is there a more efficient way to do this ? Or am I doomed to run this for weeks ?


Here is the command for my best attempt so far


ffmpeg -hwaccel cuda -hwaccel_output_format cuda -ss start_timestamp -t to_timestamp -i file_name -vf "fps=30,scale_cuda=1280:720" -c:v h264_nvenc -y output_file



Note that the machine running the code has a 4090
This command is then executed via python, which gives it the right timestamps and file paths for each smaller clip in a for loop


I think it's wasting a lot of time calling a new process each time, however I haven't been able to get better results with a split filter ; but here's the ffmpeg-python code for that attempt :


Creation of the stream :


inp = (
 ffmpeg
 .input(file_name, hwaccel="cuda", hwaccel_output_format="cuda")
 .filter("fps",fps=30)
 .filter('scale_cuda', '1280','720')
 .filter_multi_output('split')
)



Which then gets called in a for loop


(
 ffmpeg
 .filter(inp, 'trim', start=row[1]['start'], end=row[1]['end'])
 .filter('setpts', 'PTS-STARTPTS')
 .output(output_file,vcodec='h264_nvenc')
 .run()
)