Recherche avancée

Sur d’autres sites (3504)

• Best way to precisely trim and concatenate with ffmpeg

  24 janvier 2021, par TommyG

  I'm trying to find the most efficient way to cut up a video with frame precision then join the pieces together and have it play without any issues or glitches. But so far my experiments have failed and I can't figure out where I'm going wrong. First of all I understand that the only way to get the video cut precisely unless all frames are I-frames is to re-encode it and that's fine except to my surprise the cuts on the clips I tried are not accurate despite of re-encoding. Here's my code.

  


  ffmpeg -i input.mp4 -filter_complex \
"[0:v]trim=start_frame=23:end_frame=343,setpts=PTS-STARTPTS[cp1]; \ 
[0:v]trim=start_frame=2905:end_frame=3248,setpts=PTS-STARTPTS[cp2]; \
[cp1][cp2]concat[out]" -map [out] -c:v libx264 -crf 8 -preset ultrafast -fflags +genpts output.mkv -y


  


  When I play this the second clip [cp2] appears like it's been cut at least one frame earlier resulting in an unwanted flash. So for my second test I tried something simpler. First I opened the input file in MPC to get timing info for frames of cp2 start_frame=2905 is 00:02:01.162 and end_frame=3248 is 00:02:15.512. So I tried the following.

  


  ffmpeg -i input.mp4 -ss 00:02:01.162 -to 00:02:15.512 -c:v libx264 -crf 8 -preset ultrafast -fflags +genpts output.mkv -y


  


  The result was exactly the same with cut happening earlier than specified. Note : the -to time is actually the end of the clip. Finally someone has suggested to force key frames by specifying your cuts time stamps first like :

  


  ffmpeg -i input.mp4 -force_key_frames 00:02:01.162,00:02:15.512 output.mp4


  


  Then take the output.mp4 and feed it as input to the code where I use the filter_complex but unfortunately this returned the same results.

  


  I'm still very new to ffmpeg. What can I try next ?

  


• avformat/dv : fix timestamps of audio packets in case of dropped corrupt audio frames

  31 octobre 2020, par Marton Balint

  avformat/dv : fix timestamps of audio packets in case of dropped corrupt audio frames
  By using the frame counter (and the video time base) for audio pts we lose some
  
  timestamp precision but we ensure that video and audio coming from the same DV
  
  frame are always in sync.
  This patch also makes timestamps after seek consistent and it should also fix
  
  the timestamps when the audio clock is unlocked and have a completely
  
  indpendent clock source. (E.g. runs on fixed 48009 Hz which should have been
  
  exact 48000 Hz)
  Fixes out of sync timestamps in ticket #8762.
  Signed-off-by : Marton Balint <cus@passwd.hu>
  

  • [DH] libavformat/dv.c
  • [DH] tests/ref/seek/lavf-dv

• ffmpeg : error messages when creating prores

  10 septembre 2020, par user14245857

  I'm trying to convert from TIFF, 16-Bit, Raw, little endian to ProRes 4444 with ffmpeg

  


  command line is :

  


  ffmpeg -f image 2 -i 0%05d.tiff -c:v prores_ks –profile:v 4444 –v:f scale=2048x1550 –pix_fmt yuv444p10le out.mov


  


  Error messages are :

  


  „Unknown dref type 0x206c7275 size 12 “

„cur_dts is invalid st:0 (0) [init:0 i_done:0 finish:0]"


  


  My suspicion is, that ffmpeg is only supporting 10-bit for ProRes codecs ("ffmpeg –h encoder=prores_ks"). But that is why i specifically put "–pix_fmt yuv444p10le" in the command line.

  


  But ffprobe -i out.mov tells me that ffmpeg used "yuv444p12le" as pix_fmt!

  


  Why does ffmpeg use a pix_fmt that it doesn't support although told differently in the command line ?
(Another output of the log : "[prores @ 0000025d28ece880] Auto bitdepth precision. Use 12b decoding based on codec tag")

  


  Are the error messages ("Unknown dref..." and "cur_dts...") resulting from unsupported 12-Bit ?

  


  Thanks already for your helpful answers