Recherche avancée

Sur d’autres sites (14715)

• Concatenating videos Audio/Video out of sync : Non-monotonous TDS output

  6 août 2020, par invider

  I am trying to add two videos using ffmpeg and the output video/audio is out of sync (and fast forwarded). Goal is to put intro.mp4 before the original file clip.flv

  



  My approach is to

  



  

  1. Change the format of clip.flv to clip.mp4

  


  



  ffmpeg -i clip.flv -q 0 -c copy clip.mp4


  



  

  2. Concat intro.mp4 with clip.mp4

  


  



  ffmpeg -f concat -safe 0 -i filesToJoin.txt -c copy combinedvideo.mp4


  



  I see this in output log for command#2

  



  [mp4 @ 0x3ebcd60] Non-monotonous DTS in output stream 0:0; previous: 392311, current: 391925; changing to 392312. This may result in incorrect timestamps in the output file.
frame= 1566 fps=0.0 q=-1.0 Lsize=    8711kB time=00:00:48.86 bitrate=1460.2kbits/s speed= 272x    
video:7363kB audio:1294kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.619341%


  



  ---

  



  Files Metadata

  



  Original source file clip.flv metadata

  



    Metadata:
    encoder         : Lavf57.83.100
  Duration: 00:00:40.09, start: 0.010000, bitrate: 1632 kb/s
    Stream #0:0: Video: h264 (High), yuv420p(progressive), 1280x720, 1500 kb/s, 30 fps, 30 tbr, 1k tbn, 60 tbc
    Stream #0:1: Audio: aac (LC), 44100 Hz, stereo, fltp, 160 kb/s


  



  Intermediary file intro.mp4 metadata

  



    Metadata:
    major_brand     : mp42
    minor_version   : 0
    compatible_brands: mp42mp41
    creation_time   : 2020-06-02T10:36:51.000000Z
  Duration: 00:00:13.21, start: 0.000000, bitrate: 484 kb/s
    Stream #0:0(eng): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, bt709), 1280x720 [SAR 1:1 DAR 16:9], 130 kb/s, 30 fps, 30 tbr, 30k tbn, 60k tbc (default)
    Metadata:
      creation_time   : 2020-06-02T10:36:51.000000Z
      handler_name    : Alias Data Handler
      encoder         : AVC Coding
    Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 317 kb/s (default)
    Metadata:
      creation_time   : 2020-06-02T10:36:52.000000Z
      handler_name    : Alias Data Handler


  



  File clip.mp4 metadata

  



      Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf57.83.100
  Duration: 00:00:40.01, start: 0.000000, bitrate: 1635 kb/s
    Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1280x720, 1500 kb/s, 30 fps, 30 tbr, 16k tbn, 60 tbc (default)
    Metadata:
      handler_name    : VideoHandler
    Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 160 kb/s (default)
    Metadata:
      handler_name    : SoundHandler


  



  ---

  



  Things I have tried

  



  

  • As you'll see that the both videos have same frame rate but different timescale, I have tried changing the timescale of one of the video to match the other before combining the video but with no luck. For timescale change I used this command

  


  



  ffmpeg -i clip.mp4 -video_track_timescale 30000 clip_ts30000.mp4

  



  

  • I have seen the similar questions on SO, no luck

  


  


• ffmpeg mkv to mp4 container not changed

  26 août 2020, par Rio

  converting from mkv to mp4 is not working for me ffmpeg is running fine but the container is still mkv this is cmd i am running

  


  for %%i in (*.mkv) do ffmpeg -i "%%i" -c copy -c:a aac -b:a 320k -movflags +faststart "%%i.mp4"


  


  output after ffmpeg is done

  


  General
Complete name                            : C:\laragon\www\run\730428.mp4
Format                                   : Matroska
Format version                           : Version 4
Overall bit rate mode                    : Variable
Encoded date                             : UTC 2020-08-21 07:01:37
Writing application                      : mkvmerge v48.0.0 ('Fortress Around Your Heart') 64-bit
Writing library                          : libebml v1.4.0 + libmatroska v1.6.0
FileExtension_Invalid                    : mkv mk3d mka mks


  


• Is ffmpeg broken for h.264 RTP Output ?

  13 mars 2023, par GroovyDotCom

  I used wireshark to capture the RTP stream sent with :

  


  ffmpeg -f lavfi -i "testsrc=duration=5:size=cif:rate=25" -pix_fmt yuv420p -g 25 -bf 2 -an -c:v libx264 -f rtp rtp://127.0.0.1:1234 > play.sdp

  


  ffmpeg -version
ffmpeg version git-2020-03-15-c467328 Copyright (c) 2000-2020 the FFmpeg developers

  


  As can be seen in bold, RTP timestamps go forward and backward. I expect them to be the same for every packet in the frame and then only go forward by 40ms (+3600 at 90khz clock) as per the H.264/RTP spec.

  


  Also, according to that spec, the last packet in a frame should have its marker-bit set but here almost all the packets have this bit set.

  


  Am I doing something wrong ? Not understanding something ? Or is ffmpeg support for writing H.264 RTP simply broken ?

  


  SSRC=0xA49C3DC9, Seq=3595, Time=3153114809
  
SSRC=0xA49C3DC9, Seq=3596, Time=3153114809
  
SSRC=0xA49C3DC9, Seq=3597, Time=3153114809
  
SSRC=0xA49C3DC9, Seq=3598, Time=3153114809, Mark
  
SSRC=0xA49C3DC9, Seq=3599, Time=3153125609, Mark
  
SSRC=0xA49C3DC9, Seq=3600, Time=3153118409, Mark
  
SSRC=0xA49C3DC9, Seq=3601, Time=3153122009, Mark
  
SSRC=0xA49C3DC9, Seq=3602, Time=3153136409, Mark
  
SSRC=0xA49C3DC9, Seq=3603, Time=3153129209, Mark
  
SSRC=0xA49C3DC9, Seq=3604, Time=3153132809, Mark
  
SSRC=0xA49C3DC9, Seq=3605, Time=3153147209, Mark
  
SSRC=0xA49C3DC9, Seq=3606, Time=3153140009, Mark
  
SSRC=0xA49C3DC9, Seq=3607, Time=3153143609, Mark
  
SSRC=0xA49C3DC9, Seq=3608, Time=3153158009, Mark
  
SSRC=0xA49C3DC9, Seq=3609, Time=3153150809, Mark
  
SSRC=0xA49C3DC9, Seq=3610, Time=3153154409, Mark
  
SSRC=0xA49C3DC9, Seq=3611, Time=3153168809, Mark
  
SSRC=0xA49C3DC9, Seq=3612, Time=3153161609, Mark
  
SSRC=0xA49C3DC9, Seq=3613, Time=3153165209, Mark
  
SSRC=0xA49C3DC9, Seq=3614, Time=3153179609, Mark
  
SSRC=0xA49C3DC9, Seq=3615, Time=3153172409, Mark
  
SSRC=0xA49C3DC9, Seq=3616, Time=3153176009, Mark
  
SSRC=0xA49C3DC9, Seq=3617, Time=3153190409, Mark
  
SSRC=0xA49C3DC9, Seq=3618, Time=3153183209, Mark
  

  


  The RTP specification, defined in RFC 3550, states that "the timestamp reflects the sampling instant of the first octet in the RTP data packet. The sampling instant must be derived from a clock that increments monotonically and linearly in time to allow synchronization and jitter calculations" (Section 5.1).