Recherche avancée

Sur d’autres sites (6821)

• FFmpeg concat video and audio out of sync

  16 septembre 2016, par Xeoncross

  Joining multiple files using ffmpeg concat seems to result in a mismatch of the timestamps or offsets for the audio. I’ve tried with several videos and noticed the same problem for h.264 / MP4.

  Using concat and encoding the video seems to work fine. The audio stays in sync as ffmpeg does the full conversion calculations and seems to get everything right.

  However, simply concatenating the videos without any transformation or encoding results in a slowly increasing sync issue. Obviously, encoding the videos rather than simply joining them will result in a loss of information/quality so I would rather find a way around this problem.

  I’ve tried several flags to sort out this problem that appears to be based on the timestamps. None of these seem to correct the problem though.

  ffmpeg -f concat -fflags +genpts -async 1 -i segments.txt test.mov
  
  ffmpeg -auto_convert 1 -f concat -fflags +genpts -async 1 -i segments.txt -c copy test2.mov
  
  ffmpeg -f concat -i segments.txt -c copy -fflags +genpts test3.mp4
  
  ffmpeg -f concat -fflags +genpts -async 1 -i segments.txt -copyts test4.mov
  
  ffmpeg -f concat -i segments.txt -copyts test5.mov
  
  ffmpeg -f concat -i segments.txt -copyts -c copy test6.mov
  
  ffmpeg -f concat -fflags +genpts -i segments.txt -copyts -c copy test7.mov

  Note : all other questions that I could find on SO seem to "fix" the problem by simply encoding the videos over again. Not a good solution.

  Update

  I realized the concat wasn’t the problem. The original set of clips had mis-matched timestamps. Somehow concat + encoding fixed the issue, but I don’t want to re-encode the videos and loose quality each time.

  ffmpeg -y -ss 00:00:02.750 -i input.MOV -c copy -t 00:00:05.880 output.MOV

  Which resulted in the following data

  ffprobe -v quiet -show_entries stream=start_time,duration output.MOV
  
  
  
  start_time=-0.247500
  
  duration=6.131125
  
  start_time=-0.257333
  
  duration=6.155333

  Since then I’ve tried to use -tom and -t in different places along with -af apad -c:v copy and I’ve still failed to get the duration to be the same.

  Here is the full ffprobe output

  Here is the original (red) vs the segment (green)

  Detailed Sample Files

  I recorded a sample video, added the commands to chop it up, then concat it. http://davidpennington.me/share/audio_sync_test_video.zip

• FFmpeg concat video and audio out of sync

  20 décembre 2020, par Xeoncross

  Joining multiple files using ffmpeg concat seems to result in a mismatch of the timestamps or offsets for the audio. I've tried with several videos and noticed the same problem for h.264 / MP4.

  



  Using concat and encoding the video seems to work fine. The audio stays in sync as ffmpeg does the full conversion calculations and seems to get everything right.

  



  However, simply concatenating the videos without any transformation or encoding results in a slowly increasing sync issue. Obviously, encoding the videos rather than simply joining them will result in a loss of information/quality so I would rather find a way around this problem.

  



  I've tried several flags to sort out this problem that appears to be based on the timestamps. None of these seem to correct the problem though.

  



  ffmpeg -f concat -fflags +genpts -async 1 -i segments.txt test.mov
ffmpeg -auto_convert 1 -f concat -fflags +genpts -async 1 -i segments.txt -c copy test2.mov
ffmpeg -f concat -i segments.txt -c copy -fflags +genpts test3.mp4
ffmpeg -f concat -fflags +genpts -async 1 -i segments.txt -copyts test4.mov
ffmpeg -f concat -i segments.txt -copyts test5.mov
ffmpeg -f concat -i segments.txt -copyts -c copy test6.mov
ffmpeg -f concat -fflags +genpts -i segments.txt -copyts -c copy test7.mov


  



  Note : all other questions that I could find on SO seem to "fix" the problem by simply encoding the videos over again. Not a good solution.

  



  Update

  



  I realized the concat wasn't the problem. The original set of clips had mis-matched timestamps. Somehow concat + encoding fixed the issue, but I don't want to re-encode the videos and loose quality each time.

  



  ffmpeg -y -ss 00:00:02.750 -i input.MOV -c copy -t 00:00:05.880 output.MOV


  



  Which resulted in the following data

  



  ffprobe -v quiet -show_entries stream=start_time,duration output.MOV

start_time=-0.247500
duration=6.131125
start_time=-0.257333
duration=6.155333


  



  Since then I've tried to use -tom and -t in different places along with -af apad -c:v copy and I've still failed to get the duration to be the same.

  



  Here is the full ffprobe output

  



  Here is the original (red) vs the segment (green)

  



  Detailed Sample Files

  



  I recorded a sample video, added the commands to chop it up, then concat it. http://davidpennington.me/share/audio_sync_test_video.zip

  


• avcodec_send_packet sporadic crash

  4 juin 2018, par unresolved_external

  I am using ffmpeg for the video decoding currently experiencing a crash in my program inside the avcodec_send_packet method.

  Thing is that my application works as a service. And this crash happens sporadically. Something like once a 20 hours.

  The core dump is below :

  Program terminated with signal SIGSEGV, Segmentation fault.
  
  #0  __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:126
  
  126 ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S: No such file or directory.
  
  [Current thread is 1 (Thread 0x7f8f9f6a4700 (LWP 12133))]
  
  (gdb) backtrace
  
  #0  __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:126
  
  #1  0x00007f8fdf76cdee in av_packet_copy_props () from /usr/local/lib/libavcodec.so.58
  
  #2  0x00007f8fdf76d4b3 in av_packet_ref () from /usr/local/lib/libavcodec.so.58
  
  #3  0x00007f8fdf7fbbb0 in avcodec_send_packet () from /usr/local/lib/libavcodec.so.58

  The way I am using the ffmpeg is the following :

  AVCodecParameters VideoCodecPar;
  
  
  
              AVCodec* decoder = avcodec_find_decoder(VideoCodecPar.codec_id);
  
              AVCodecContext *avctx = nullptr ;
  
              if (!(avctx = avcodec_alloc_context3(decoder)))
  
              {                        
  
                  LOG_ERR("cannot avcodec_alloc_context3 \n");
  
                  goto ERROR;
  
              }
  
  
  
              if (avcodec_parameters_to_context(avctx, &VideoCodecPar) < 0)
  
              {                
  
                  LOG_ERR("cannot avcodec_parameters_to_context\n");
  
                  goto ERROR;
  
              }
  
  
  
              av_opt_set_int(avctx, "refcounted_frames", 1, 0);
  
  
  
              AVBufferRef *hw_device_ctx = NULL;
  
              if ((err = av_hwdevice_ctx_create(&hw_device_ctx, type,
  
                                              NULL, NULL, 0)) < 0) {
  
                  LOG_ERROR( "Failed to create specified HW device.\n");
  
                  goto ERROR;
  
              }
  
              avctx->hw_device_ctx = av_buffer_ref(hw_device_ctx);
  
  
  
              if ((ret = avcodec_open2(avctx, decoder, NULL)) < 0)
  
              {
  
                  LOG_ERROR("Failed to open codec for video stream\n");
  
                  goto ERROR;                
  
              }
  
  
  
              AVPacket nullpkt;                    
  
              nullpkt.data = NULL;
  
              nullpkt.size = 0;
  
  
  
              int ret = avcodec_send_packet(avctx, packet);
  
              if (ret < 0)
  
              {
  
                  LOG_ERR("Error during decoding ret=%d\n",ret);
  
                  goto ERROR
  
                  return ret;
  
              }

  Also, I’ve analyzed the application with Valgrind and it found following error :

  ==8560== 88 bytes in 1 blocks are still reachable in loss record 1,499 of 2,471
  
  ==8560==    at 0x4E4CD65: memalign (vg_replace_malloc.c:857)
  
  ==8560==    by 0x4E4CE80: posix_memalign (vg_replace_malloc.c:1022)
  
  ==8560==    by 0xD063B5F: av_malloc (in /usr/local/lib/libavutil.so.56.18.102)
  
  ==8560==    by 0xD063D2D: av_mallocz (in /usr/local/lib/libavutil.so.56.18.102)
  
  ==8560==    by 0xD04C923: av_buffer_pool_init (in /usr/local/lib/libavutil.so.56.18.102)
  
  ==8560==    by 0xBC99542: ??? (in /usr/local/lib/libavcodec.so.58.19.101)
  
  ==8560==    by 0xBC99DCA: ??? (in /usr/local/lib/libavcodec.so.58.19.101)
  
  ==8560==    by 0xBC9E1D1: ??? (in /usr/local/lib/libavcodec.so.58.19.101)
  
  ==8560==    by 0xBCA1BAA: ??? (in /usr/local/lib/libavcodec.so.58.19.101)
  
  ==8560==    by 0xBB7ED8A: ??? (in /usr/local/lib/libavcodec.so.58.19.101)
  
  ==8560==    by 0xBB81C57: avcodec_send_packet (in /usr/local/lib/libavcodec.so.58.19.101)

  As far as I understand this error just claims that on application exit(which is not implemented properly at the moment) there was some pointer to the dynamical memory which was not freed. But still - could this error be a reason of that crash ?

  If not - what other potential reasons for this problem ?