Recherche avancée

Médias (1)

Mot : - Tags -/framasoft

Autres articles (78)

  • Le profil des utilisateurs

    12 avril 2011, par

    Chaque 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 (...)

  • XMP PHP

    13 mai 2011, par

    Dixit Wikipedia, XMP signifie :
    Extensible Metadata Platform ou XMP est un format de métadonnées basé sur XML utilisé dans les applications PDF, de photographie et de graphisme. Il a été lancé par Adobe Systems en avril 2001 en étant intégré à la version 5.0 d’Adobe Acrobat.
    Étant basé sur XML, il gère un ensemble de tags dynamiques pour l’utilisation dans le cadre du Web sémantique.
    XMP permet d’enregistrer sous forme d’un document XML des informations relatives à un fichier : titre, auteur, historique (...)

  • La sauvegarde automatique de canaux SPIP

    1er avril 2010, par

    Dans le cadre de la mise en place d’une plateforme ouverte, il est important pour les hébergeurs de pouvoir disposer de sauvegardes assez régulières pour parer à tout problème éventuel.
    Pour réaliser cette tâche on se base sur deux plugins SPIP : Saveauto qui permet une sauvegarde régulière de la base de donnée sous la forme d’un dump mysql (utilisable dans phpmyadmin) mes_fichiers_2 qui permet de réaliser une archive au format zip des données importantes du site (les documents, les éléments (...)

Sur d’autres sites (9570)

  • How do I configure ffmpeg & openh264 so that the video file can be opened in Windows Media Player 12

    10 mars 2017, par Sacha Guyer

    I have successfully created h264/mp4 movie files with ffmpeg and the x264 library.

    Now I would like to change the h264 library from x264 to openH264. I could replace the x264 library with openH264, recompile ffmpeg and produce movie files, without changing my sources that produce the movie. The resulting movie opens fine in Quicktime on Mac, but on Windows, Windows Media Player 12 cannot play it.

    The documentation about Windows Media Player support for h264 is unclear. File types supported by Windows Media Player states in the table that Windows Media Player 12 supports mp4, but the text below says :

    Windows Media Player does not support the playback of the .mp4 file format.

    From what I have observed, Windows Media Player 12 IS capable of playing h264/mp4 files, but only when created with x264.

    Does anyone know how I need to adjust the configuration of the codec/context so that the movie plays in Windows Media Player ? Does Windows Media Player only support certain h264 profiles ?

    I noticed the warning :

    [libopenh264 @ 0x...] [OpenH264] this = 0x..., Warning:bEnableFrameSkip = 0,bitrate can’t be controlled for RC_QUALITY_MODE,RC_BITRATE_MODE and RC_TIMESTAMP_MODE without enabling skip frame

    With the configuration :

    av_dict_set(&options, "allow_skip_frames", "1", 0);

    I could get rid of this warning, but the movie still does not play. Are there other options that need to be set so that the movie plays in Windows Media Player ?

    Thank you for your help

    ffprobe output of the file that does play fine in Windows Media Player :

    Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'test_x264.mp4':
     Metadata:
       major_brand     : isom
       minor_version   : 512
       compatible_brands: isomiso2avc1mp41
       title           : retina
       encoder         : Lavf57.56.100
       comment         : Creation Date: 2017-03-10 07:47:39.601
     Duration: 00:00:04.17, start: 0.000000, bitrate: 17497 kb/s
       Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661),
         yuv420p, 852x754, 17495 kb/s, 24 fps, 24 tbr, 24k tbn, 48 tbc (default)
       Metadata:
         handler_name    : VideoHandler

    ffprobe output of the file that does not play in Windows Media Player :

    Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'test_openh264.mp4':
     Metadata:
       major_brand     : isom
       minor_version   : 512
       compatible_brands: isomiso2avc1mp41
       title           : retina
       encoder         : Lavf57.56.100
       comment         : Creation Date: 2017-03-10 07:49:27.024
     Duration: 00:00:04.17, start: 0.000000, bitrate: 17781 kb/s
       Stream #0:0(und): Video: h264 (Constrained Baseline) (avc1 / 0x31637661),
         yuv420p, 852x754, 17779 kb/s, 24 fps, 24 tbr, 24k tbn, 48k tbc (default)
       Metadata:
         handler_name    : VideoHandler
  • Slow audio-video sync drift when merging wav and mp4 with ffmpeg

    27 juin 2018, par charlie80

    I have an mp4 file with only a single video stream (no audio) and a wav audio file that I would like to add to the video using ffmpeg. The audio and the video have been recorded simultaneously during a conference, the former from a mixer output on a PC and the latter from a digital videocamera.

    I am using this ffmpeg command :

    ffmpeg -i incontro3.mp4 -itsoffset 18.39 -i audio_mix.wav -c:v copy -c:a aac final-video.mp4

    where I’m using the -itsoffset 18.39 option since I know that 18.39s is the video-audio delay.

    The problem I’m experiencing is that in the output file, while the audio is perfectly in sync with the video at the beginning, it slowly drifts out of sync during the movie.

    The output if ffprobe on the video file is :

    Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'incontro3.mp4':
     Metadata:
       major_brand     : isom
       minor_version   : 512
       compatible_brands: isomiso2avc1mp41
       encoder         : Lavf57.25.100
     Duration: 00:47:22.56, start: 0.000000, bitrate: 888 kb/s
       Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 886 kb/s, 25 fps, 25 tbr, 12800 tbn (default)
       Metadata:
         handler_name    : VideoHandler

    and the ffprobe output for the audio file is :

    Input #0, wav, from 'audio_mix.wav':
     Metadata:
       track           : 5
       encoder         : Lavf57.25.100
     Duration: 00:46:32.20, bitrate: 1411 kb/s
       Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 44100 Hz, 2 channels, s16, 1411 kb/s

    I’m using the latest ffmpeg Zeranoe windows build git-9591ca7 (2016-05-25).

    Thanks in anticipation for any help/ideas !


    UPDATE 1 : It looks like the problem is upstream the video-audio merging, and could be in the concatenation and conversion of the MTS files generated by the video camera into the mp4 video. I will follow up as I make any progress in understanding...


    UPDATE 2 : The problem is not in the initial merging of the MTS files generated by the camera. Or, at least, it occurs identically if I merge them with cat or with ffmpeg -f concat


    UPDATE 3 : Following @Mulvya’s suggestion, I observed that the drift rate is constant (at least as far as I can tell judging by eye). I also tried to superimpose the A/V tracks with another software, and the drift is exactly the same, thereby ruling out ffmpeg as culprit. My (bad) feeling is that the issue could be related to the internal clocks of the digital video camera and the laptop used for audio recording running at slightly different rates (see here the report of an identical issue I just found).

  • Slow audio-video sync drift when merging wav and mp4 with ffmpeg

    30 mai 2016, par charlie80

    I have an mp4 file with only a single video stream (no audio) and a wav audio file that I would like to add to the video using ffmpeg. The audio and the video have been recorded simultaneously during a conference, the former from a mixer output on a PC and the latter from a digital videocamera.

    I am using this ffmpeg command :

    ffmpeg -i incontro3.mp4 -itsoffset 18.39 -i audio_mix.wav -c:v copy -c:a aac final-video.mp4

    where I’m using the -itsoffset 18.39 option since I know that 18.39s is the video-audio delay.

    The problem I’m experiencing is that in the output file, while the audio is perfectly in sync with the video at the beginning, it slowly drifts out of sync during the movie.

    The output if ffprobe on the video file is :

    Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'incontro3.mp4':
     Metadata:
       major_brand     : isom
       minor_version   : 512
       compatible_brands: isomiso2avc1mp41
       encoder         : Lavf57.25.100
     Duration: 00:47:22.56, start: 0.000000, bitrate: 888 kb/s
       Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 886 kb/s, 25 fps, 25 tbr, 12800 tbn (default)
       Metadata:
         handler_name    : VideoHandler

    and the ffprobe output for the audio file is :

    Input #0, wav, from 'audio_mix.wav':
     Metadata:
       track           : 5
       encoder         : Lavf57.25.100
     Duration: 00:46:32.20, bitrate: 1411 kb/s
       Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 44100 Hz, 2 channels, s16, 1411 kb/s

    I’m using the latest ffmpeg Zeranoe windows build git-9591ca7 (2016-05-25).

    Thanks in anticipation for any help/ideas !


    UPDATE 1 : It looks like the problem is upstream the video-audio merging, and could be in the concatenation and conversion of the MTS files generated by the video camera into the mp4 video. I will follow up as I make any progress in understanding...


    UPDATE 2 : The problem is not in the initial merging of the MTS files generated by the camera. Or, at least, it occurs identically if I merge them with cat or with ffmpeg -f concat


    UPDATE 3 : Following @Mulvya’s suggestion, I observed that the drift rate is constant (at least as far as I can tell judging by eye). I also tried to superimpose the A/V tracks with another software, and the drift is exactly the same, thereby ruling out ffmpeg as culprit. My (bad) feeling is that the issue could be related to the internal clocks of the digital video camera and the laptop used for audio recording running at slightly different rates (see here the report of an identical issue I just found).