
Recherche avancée
Autres articles (113)
-
Les tâches Cron régulières de la ferme
1er décembre 2010, parLa gestion de la ferme passe par l’exécution à intervalle régulier de plusieurs tâches répétitives dites Cron.
Le super Cron (gestion_mutu_super_cron)
Cette tâche, planifiée chaque minute, a pour simple effet d’appeler le Cron de l’ensemble des instances de la mutualisation régulièrement. Couplée avec un Cron système sur le site central de la mutualisation, cela permet de simplement générer des visites régulières sur les différents sites et éviter que les tâches des sites peu visités soient trop (...) -
Les autorisations surchargées par les plugins
27 avril 2010, parMediaspip core
autoriser_auteur_modifier() afin que les visiteurs soient capables de modifier leurs informations sur la page d’auteurs -
Publier sur MédiaSpip
13 juin 2013Puis-je poster des contenus à partir d’une tablette Ipad ?
Oui, si votre Médiaspip installé est à la version 0.2 ou supérieure. Contacter au besoin l’administrateur de votre MédiaSpip pour le savoir
Sur d’autres sites (32357)
-
Révision 24514 : Exclure les fichier CACHEDIR.TAG de la vidange de cache
16 février 2020, par gitea@fake.local -
Révision 24498 : Exclure les fichier CACHEDIR.TAG de la vidange de cache
6 février 2020, par bruno@eliaz.fr -
aac encoding with ffmpeg result in super short file
5 janvier 2017, par MockarutanSo I’m having problem with AAC encoding. I’m trying to encode some synthetic sound waves, but it does not work as expected. The file I get gives just a super short sound when played in VLC. When I play is in ffplay is plays like I expect, but it says "duration : 00:00:00.05" which I suppose says 5 ms. But I encode a lot more than that, and it played more. So VLC plays a super short sound, ffplay plays a longer file (the expected length), but displays it with super short duration, what’s going on ?
Source : http://pastebin.com/M5MKkEL3
One of the things that looks wrong to me is this :
If you look for the variable "audio_time", if you breakpoint it and read it every encode frame, you will get this :..
Encode frame 8 : 0.00010416666666666666
Encode frame 9 : 0.00012500000000000000
(and so on)The diff is : 0.00002085, which is a 1/1000 of a the diff I expected from 47 samples frames per second, which is what the encoder wants with 48k sample rate (48k / 1024 = 47).
So why do I get a thousand of the expected data encoded ?
Feel free to point anything suspicious out !
Thanks in advance !