Sur d’autres sites (6464)

• On concatinating two videos in FFmpeg, the output video is far longer than expected

  15 août 2019, par Ngo Van Phuc

  I want to ask about FFmpeg.

  • Video A (time : 00:31:51 - 1280x720)
  • Video B (time : 00:00:22 - 1280x720)
  • output video : (time : 01:20:38)

  The code I use : ffmpeg -f concat -i file-list.txt -c copy outputfile.mp4

  I hear people say, need to encode videos, How to encode video ?

  please help me.

• The SSIM values calculated using FFMPEG are not what I expected

  18 mai 2020, par fd-alexer

  I'm trying to encode an m2ts (MPEG-2 Transport Stream) file to mp4 (H.264) and get the ssim value.
  
I did get some SSIM values, but the results were contrary to my expectations.

  



  Are there wrong command options for ffmpeg ?

  



  Encoding and SSIM calculation commands

  



  # encode&#xA;$ ffmpeg -hide_banner -fflags &#x2B;discardcorrupt -i input.m2ts \&#xA;  -c:v libx264 -crf <crf> -preset:v medium \&#xA;  -c:a copy -bsf:a aac_adtstoasc \&#xA;  output_ff_crf-<crf>.mp4&#xA;&#xA;# calculate ssim&#xA;$ ffmpeg -hide_banner -i <a> -i <b> \&#xA;  -lavfi  "[0:v]settb=AVTB,setpts=PTS-STARTPTS[main];[1:v]settb=AVTB,setpts=PTS-STARTPTS[ref];[main][ref]ssim" \&#xA;  -f null -&#xA;</b></a></crf></crf>

  



  The results of the SSIM

  



  (a) A=input.m2ts,          B=input.m2ts,           ssim=0.973266
(b) A=input.m2ts,          B=output_ff_crf-0.mp4,  ssim=0.813347
(c) A=input.m2ts,          B=output_ff_crf-30.mp4, ssim=0.819897
(d) A=output_ff_crf-0.mp4, B=output_ff_crf-0.mp4,  ssim=1.000000
(e) A=output_ff_crf-0.mp4, B=output_ff_crf-30.mp4, ssim=0.972911


  



  

  • (d)(e) : These are what I expected.

  


  • (a) : The files are the same, but ssim≠1.

  


  • (b)(c) : SSIMs with CRF=0 and CRF=30 have almost the same value, although the image quality is different.

  


  



  In the case of HandBrakeCLI

  



  To determine if there was a problem with input.m2ts, I ran HandBrakeCLI with almost the same parameters as ffmpeg.

  



  # encode&#xA;HandBrakeCLI --verbose --format av_mp4 --encoder x264 --quality <crf> --x264-preset medium \&#xA;  --aencoder copy \&#xA;  --input input.m2ts --output output_hb_crf-<crf>.mp4&#xA;&#xA;# calculate ssim (same as ffmpeg)&#xA;$ ffmpeg -hide_banner -i <a> -i <b> \&#xA;  -lavfi  "[0:v]settb=AVTB,setpts=PTS-STARTPTS[main];[1:v]settb=AVTB,setpts=PTS-STARTPTS[ref];[main][ref]ssim" \&#xA;  -f null -&#xA;</b></a></crf></crf>

  



  (b') A=input.m2ts,          B=output_hb_crf-0.mp4,  ssim=0.999999
(c') A=input.m2ts,          B=output_hb_crf-30.mp4, ssim=0.972886
(d') A=output_hb_crf-0.mp4, B=output_hb_crf-0.mp4,  ssim=1.000000
(e') A=output_hb_crf-0.mp4, B=output_hb_crf-30.mp4, ssim=0.972886


  



  It's all as I expected. (although A is not ssim=1.0) 
Therefore, I don't see a problem with input.m2ts.

  



  Informations about video files and tools

  



  Results of the ffprobe

  



  input.m2ts

  



  [mpeg2video @ 0x5655577c1680] Invalid frame dimensions 0x0.
    Last message repeated 1 times
[mpegts @ 0x5655577bd080] start time for stream 2 is not set in estimate_timings_from_pts
[mpegts @ 0x5655577bd080] PES packet size mismatch
Input #0, mpegts, from 'input.m2ts':
  Duration: 00:30:02.68, start: 39593.392600, bitrate: 19019 kb/s
  Program 211
    Stream #0:0[0x140]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv, bt709, top first), 1920x1080 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
    Stream #0:1[0x141]: Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 255 kb/s
    Stream #0:2[0x138]: Data: bin_data ([6][0][0][0] / 0x0006)
Unsupported codec with id 100359 for input stream 2


  



  output_ff_crf-0.mp4

  



  Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'output_ff_crf-0.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf57.83.100
  Duration: 00:30:02.67, start: 0.000000, bitrate: 109301 kb/s
    Stream #0:0(und): Video: h264 (High 4:4:4 Predictive) (avc1 / 0x31637661), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 109040 kb/s, 29.97 fps, 29.97 tbr, 30k tbn, 59.94 tbc (default)
    Metadata:
      handler_name    : VideoHandler
    Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 252 kb/s (default)
    Metadata:
      handler_name    : SoundHandler


  



  output_hb_crf-0.mp4

  



  Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'output_hb_crf-0.mp4':
  Metadata:
    major_brand     : mp42
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    creation_time   : 2020-05-17T06:22:06.000000Z
    encoder         : HandBrake 1.1.0 2018042400
  Duration: 00:30:02.22, start: 0.000000, bitrate: 109661 kb/s
    Stream #0:0(und): Video: h264 (High 4:4:4 Predictive) (avc1 / 0x31637661), yuv420p(tv, bt709), 1920x1080 [SAR 1:1 DAR 16:9], 109405 kb/s, 29.97 fps, 29.97 tbr, 90k tbn, 180k tbc (default)
    Metadata:
      creation_time   : 2020-05-17T06:22:06.000000Z
      handler_name    : VideoHandler
    Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 252 kb/s (default)
    Metadata:
      creation_time   : 2020-05-17T06:22:06.000000Z
      handler_name    : Stereo


  



  Tools

  



  version

  



  

  • ffmpeg : 3.4.6-0ubuntu0.18.04.1

  


  • HandBrakeCLI : 1.1.0

  


  



  ldd

  



  $ ldd /usr/bin/ffmpeg
...
libx264.so.152 => /usr/lib/x86_64-linux-gnu/libx264.so.152 (0x00007efbf1f33000)
...

$ ldd /usr/bin/HandBrakeCLI
...
libx264.so.152 => /usr/lib/x86_64-linux-gnu/libx264.so.152 (0x00007efbfb38f000)
...


  



  ffmpeg and HandBrakeCLI are using the same libx264.

  


• ffmpeg - How to bypass uneven segmentation with basic encoding ? [closed]

  2 juin 2021, par valextt

  Example request :

  


  ffmpeg -i 'input.mp4' -c:v libx264 -force_key_frames "expr:gte(t,n_forced*1)" -segment_time 20 -reset_timestamps 1 -f segment output%03d.mp4

  


  If I use -c:v libx264 in the request, then the split time lasts for a long, but it works out correctly. In general, I am satisfied with the source codec, so I tried -c:v copy, so we do not change the codec, which makes the split process almost instantly, but the problem is, that the output segments are not 20 seconds each, but for example :
20.5 sec, 18.5 sec, 21 sec.
How to deal with it ? Why does the -c:v copy modify the split unevenly ?