
Recherche avancée
Médias (91)
-
GetID3 - Boutons supplémentaires
9 avril 2013, par
Mis à jour : Avril 2013
Langue : français
Type : Image
-
Core Media Video
4 avril 2013, par
Mis à jour : Juin 2013
Langue : français
Type : Video
-
The pirate bay depuis la Belgique
1er avril 2013, par
Mis à jour : Avril 2013
Langue : français
Type : Image
-
Bug de détection d’ogg
22 mars 2013, par
Mis à jour : Avril 2013
Langue : français
Type : Video
-
Exemple de boutons d’action pour une collection collaborative
27 février 2013, par
Mis à jour : Mars 2013
Langue : français
Type : Image
-
Exemple de boutons d’action pour une collection personnelle
27 février 2013, par
Mis à jour : Février 2013
Langue : English
Type : Image
Autres articles (68)
-
MediaSPIP en mode privé (Intranet)
17 septembre 2013, parÀ partir de la version 0.3, un canal de MediaSPIP peut devenir privé, bloqué à toute personne non identifiée grâce au plugin "Intranet/extranet".
Le plugin Intranet/extranet, lorsqu’il est activé, permet de bloquer l’accès au canal à tout visiteur non identifié, l’empêchant d’accéder au contenu en le redirigeant systématiquement vers le formulaire d’identification.
Ce système peut être particulièrement utile pour certaines utilisations comme : Atelier de travail avec des enfants dont le contenu ne doit pas (...) -
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 (...) -
Gestion des droits de création et d’édition des objets
8 février 2011, parPar défaut, beaucoup de fonctionnalités sont limitées aux administrateurs mais restent configurables indépendamment pour modifier leur statut minimal d’utilisation notamment : la rédaction de contenus sur le site modifiables dans la gestion des templates de formulaires ; l’ajout de notes aux articles ; l’ajout de légendes et d’annotations sur les images ;
Sur d’autres sites (6213)
-
How to use web analytics to acquire new customers
2 septembre 2020, par Joselyn Khor — Analytics Tips, Marketing -
Blog series part 1 : How to use Matomo to increase customer acquisitions for your business
2 septembre 2020, par Joselyn Khor — Analytics Tips, Marketing -
Video files recorded in Google Chrome have stuttering audio
4 juin 2018, par maxpajBackground
I’m developing a platform where users can record videos of themselves or their screen and send them as video messages to customers / clients.
I have limited users to only using my application with Google Chrome and I’m using the MediaRecorder API to record the video data from the users screen or webcamera. The codecs that are used for recording are VP8/OPUS (WEBM container).
I need the videos to run in as many browsers as possible, so I’m using a 3rd party service to transcode videos from whatever format I’m getting from the users to a H.265/AAC MP4 container (caniuse MPEG-4/H.264).
Issue
Lately I’ve seen that some videos recorded on Mac OSX machines have the video and audio out of sync or that the video and audio stutters, depending on which player I’m using. I call these video files corrupt, for lack of a better word. Playing a corrupt file in Google Chrome renders smooth playing audio. Playing the video in VLC on my Windows machine renders stuttering audio.
When I run the corrupt video files through the transcoding service I get video files with stuttering audio, no matter which player I’m using.
This is an unwanted result and pretty much unacceptable since the audio needs to be smooth in order for the recipient of a video to not be bothered with the quality.
Debugging
According to the transcoding service support, this happens because of their mechanisms that try to sync up the audio and video from the corrupt file :
Inspecting our encoding logs, I’ve noticed the following kind of
warnings :[2018-05-16 14:08:38.009] [pcm_s16le @ 0x1d608c0] pcm_encode_frame :
filling in for 5856 missing samples (122 ms) before pts 40800 to
correct sync ! [2018-05-16 14:08:38.009] [pcm_s16le @ 0x1d608c0]
pcm_encode_frame : dropping 2880 samples (60 ms) at pts 43392 to help
correct sync to -3168 samples (-66 ms) !The problem here comes from the way that the audio in the original
source file is encoded.-
you should ensure that the audio is not out of sync (audio timestamps
are correct) in your source file before submitting the jobRunning a corrupt file through ffmpeg on my own machine, re-encoding with the same codecs, produces the same kind of stuttering video. The logs produce an alarming amount of errors. Here is a sample of the log output :
[libopus @ 0000029938e24d80] Queue input is backward in timeitrate= 194.8kbits/s dup=0 drop=5 speed=0.31x
[webm @ 0000029938e09b00] Non-monotonous DTS in output stream 0:1; previous: 15434, current: 15394; changing to 15434. This may result in incorrect timestamps in the output file.
[webm @ 0000029938e09b00] Non-monotonous DTS in output stream 0:1; previous: 15434, current: 15414; changing to 15434. This may result in incorrect timestamps in the output file.
[libopus @ 0000029938e24d80] Queue input is backward in timeitrate= 193.3kbits/s dup=0 drop=5 speed=0.309x
[webm @ 0000029938e09b00] Non-monotonous DTS in output stream 0:1; previous: 15539, current: 15499; changing to 15539. This may result in incorrect timestamps in the output file.
[webm @ 0000029938e09b00] Non-monotonous DTS in output stream 0:1; previous: 15539, current: 15519; changing to 15539. This may result in incorrect timestamps in the output file.
[libopus @ 0000029938e24d80] Queue input is backward in timeitrate= 192.0kbits/s dup=0 drop=5 speed=0.308x
[webm @ 0000029938e09b00] Non-monotonous DTS in output stream 0:1; previous: 15667, current: 15627; changing to 15667. This may result in incorrect timestamps in the output file.
[webm @ 0000029938e09b00] Non-monotonous DTS in output stream 0:1; previous: 15667, current: 15647; changing to 15667. This may result in incorrect timestamps in the output file.
[libopus @ 0000029938e24d80] Queue input is backward in timeI tried running the same inputs through another transcoding service and those outputs worked a lot better - video was still stuttering but the audio played smoothly, which is more important to the use case of my application.
To my knowledge, this have so far only occurred for users on Mac OSX machines.
Questions
-
Is there anything I can do to have the files work better ? Or is this entirely a consequence of how encoding of video and audio in Google Chrome works ?
-
One step in the right direction would be to just be able to detect when the video is corrupt. How can I do that ?
-