
Recherche avancée
Médias (1)
-
GetID3 - Bloc informations de fichiers
9 avril 2013, par
Mis à jour : Mai 2013
Langue : français
Type : Image
Autres articles (51)
-
Qu’est ce qu’un éditorial
21 juin 2013, parEcrivez votre de point de vue dans un article. Celui-ci sera rangé dans une rubrique prévue à cet effet.
Un éditorial est un article de type texte uniquement. Il a pour objectif de ranger les points de vue dans une rubrique dédiée. Un seul éditorial est placé à la une en page d’accueil. Pour consulter les précédents, consultez la rubrique dédiée.
Vous pouvez personnaliser le formulaire de création d’un éditorial.
Formulaire de création d’un éditorial Dans le cas d’un document de type éditorial, les (...) -
Multilang : améliorer l’interface pour les blocs multilingues
18 février 2011, parMultilang est un plugin supplémentaire qui n’est pas activé par défaut lors de l’initialisation de MediaSPIP.
Après son activation, une préconfiguration est mise en place automatiquement par MediaSPIP init permettant à la nouvelle fonctionnalité d’être automatiquement opérationnelle. Il n’est donc pas obligatoire de passer par une étape de configuration pour cela. -
Ajouter des informations spécifiques aux utilisateurs et autres modifications de comportement liées aux auteurs
12 avril 2011, parLa manière la plus simple d’ajouter des informations aux auteurs est d’installer le plugin Inscription3. Il permet également de modifier certains comportements liés aux utilisateurs (référez-vous à sa documentation pour plus d’informations).
Il est également possible d’ajouter des champs aux auteurs en installant les plugins champs extras 2 et Interface pour champs extras.
Sur d’autres sites (8561)
-
ffmpeg crashes on crossfades between 3 clips if 2 clips coming from same input file [closed]
14 avril 2020, par ErikI observed that ffmpeg 4.2.2 (macOS) crashes in particular cases of crossfades between clips, if one clip comes from file
1.dv
, and two clips are cut out of file2.dv
, as shown below :


ffmpeg -f lavfi -i color=black:size=720x576:duration=11:rate=25 -i 1.dv -i 2.dv -filter_complex "\
 [1:v]trim=5:10,setpts=expr=PTS-STARTPTS,yadif,fade=alpha=1:d=2:st=3:type=out,setpts=expr=PTS-STARTPTS,fifo[s5];\
 [2:v]split=2[s7][s8];\
 [s7]trim=5:10,setpts=expr=PTS-STARTPTS,yadif,fade=alpha=1:d=2:type=in,fade=alpha=1:d=2:st=6:type=out,setpts=expr=PTS-STARTPTS+(3/TB),fifo[s15];\
 [s8]trim=12:17,setpts=expr=PTS-STARTPTS,yadif,fade=alpha=1:d=2:type=in,setpts=expr=PTS-STARTPTS+(6/TB),fifo[s22];\
 [0:v][s5]overlay=eof_action=repeat[s6];\
 [s6][s15]overlay=eof_action=repeat[s16];\
 [s16][s22]overlay=eof_action=repeat[s24];\
 [1:a]atrim=5:10,asetpts=expr=PTS-STARTPTS[s26];\
 [2:a]asplit=2[s27][s28];\
 [s27]atrim=5:10,asetpts=expr=PTS-STARTPTS[s30];\
 [s28]atrim=12:17,asetpts=expr=PTS-STARTPTS[s33];\
 [s26][s30]acrossfade=d=2[s31];\
 [s31][s33]acrossfade=d=2[s36]" \
 -map "[s24]" -map "[s36]" -ab 128k -acodec aac -crf 23 -movflags faststart -preset medium -tune film -vcodec libx264 -aspect 1024:576 out.mp4 -y




The order makes a difference : if the two clips from
2.dv
are used first and then the clip from1.dv
is appended, everything works fine. Also, if all clips are coming from different files.


ffmpeg 3.4.6 (ubuntu 18.04) shows no issues in any case.



A self-compiled ffmpeg version N-97322-gb1699f4 (commit 2020-04-13) works with short clips as above, but crashes if one of the two clips taken from
2.dv
is getting longer. In my tests 1500 frames (64 sec) is OK, 1700 (68 sec) leads to a segmentation fault. That is, if you replace in the command line above :


- 

[s7]trim=5:10...
->[s7]trim=0:68
and accordingly[s27]atrim=5:10...
->[s27]atrim=0:68







Interestingly, the length of the clip taken from
1.dv
does not play a role.


The ffmpeg output shows about 20 times :



frame= 0 fps=0.0 q=0.0 size= 0kB time=00:00:00.00 bitrate=N/A speed= 0x 




before it continues (seg fault case) :



frame= 4 fps=0.3 q=0.0 size= 0kB time=00:00:00.00 bitrate=N/A speed= 0x 
frame= 24 fps=1.6 q=0.0 size= 0kB time=00:00:00.00 bitrate=N/A speed= 0x 
frame= 25 fps=1.5 q=0.0 size= 0kB time=00:00:00.00 bitrate=N/A speed= 0x 
frame= 34 fps=1.9 q=0.0 size= 0kB time=00:00:00.00 bitrate=N/A speed= 0x 
frame= 36 fps=2.0 q=0.0 size= 0kB time=00:00:00.00 bitrate=N/A speed= 0x 
frame= 39 fps=2.1 q=0.0 size= 0kB time=00:00:00.00 bitrate=N/A speed= 0x 
frame= 40 fps=2.0 q=0.0 size= 0kB time=00:00:00.00 bitrate=N/A speed= 0x 
frame= 40 fps=2.0 q=0.0 size= 0kB time=00:00:00.00 bitrate=N/A speed= 0x 
frame= 40 fps=1.9 q=0.0 size= 0kB time=00:00:00.00 bitrate=N/A speed= 0x 





success case :



frame= 5 fps=0.4 q=0.0 size= 0kB time=00:00:00.00 bitrate=N/A speed= 0x 
frame= 42 fps=3.2 q=28.0 size= 0kB time=00:00:00.00 bitrate=N/A speed= 0x 
frame= 53 fps=3.9 q=28.0 size= 0kB time=00:00:00.36 bitrate= 2.9kbits/s speed=0.0264x 
frame= 65 fps=4.6 q=28.0 size= 0kB time=00:00:00.84 bitrate= 1.2kbits/s speed=0.0594x 
... 




Slightly older versions included in the newest MacOS builds from zeranoe.com (git-2020-04-13-59e3a9a) and evermeet.cx (N-97308-g14dd0a9057-tessus, from 2020-04-12) are working nicely - also on my production cases (longer clips).



Any feedback would be appreciated !


-
How do I configure ffmpeg & openh264 so that the video file can be opened in Windows Media Player 12
10 mars 2017, par Sacha GuyerI 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 : VideoHandlerffprobe 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 charlie80I have an
mp4
file with only a single video stream (no audio) and awav
audio file that I would like to add to the video usingffmpeg
. 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 : VideoHandlerand 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/sI’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 theMTS
files generated by the video camera into themp4
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 withcat
or withffmpeg -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).