Duration calculation error when -ss precedes -i

[Cheedoong]

Summary of the bug:

It appeared long time ago, I also saw somebody else posted similar issues onto other forums.

How to reproduce:

% ffmpeg.exe -y -ss 00:00:05 -t 00:00:15 -i "http://182.131.19.177/videoctfs.tc.qq.com/k01025rk99s.p708.1.flv?sdtfrom=v2&type=tflv&vkey=49B6CAA790F75B58D8D8C20CA392116CD6A4B647573068BF7B66B03859BFB5E0B6A814A10B843B18&level=3&sha=3928588565e69ba1897b9ad4b876014ef0697d2a&platform=1&br=20&fmt=sd" -vcodec libx264 -acodec libmp3lame -strict -2 -f mpegts dura_err.ts 2>dura_err.txt

dura_err.txt: 

ffmpeg version N-42547-g7543fd8 Copyright (c) 2000-2012 the FFmpeg developers
  built on Jul 15 2012 21:36:07 with gcc 4.7.1
  configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-runtime-cpudetect --enable-avisynth --enable-bzlib --enable-frei0r --enable-libass --enable-libcelt --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libfreetype --enable-libgsm --enable-libmp3lame --enable-libnut --enable-libopenjpeg --enable-librtmp --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libutvideo --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxavs --enable-libxvid --enable-zlib
  libavutil      51. 65.100 / 51. 65.100
  libavcodec     54. 40.100 / 54. 40.100
  libavformat    54. 16.104 / 54. 16.104
  libavdevice    54.  1.100 / 54.  1.100
  libavfilter     3.  2.100 /  3.  2.100
  libswscale      2.  1.100 /  2.  1.100
  libswresample   0. 15.100 /  0. 15.100
  libpostproc    52.  0.100 / 52.  0.100
Input #0, flv, from 'http://182.131.19.177/videoctfs.tc.qq.com/k01025rk99s.p708.1.flv?sdtfrom=v2&type=tflv&vkey=49B6CAA790F75B58D8D8C20CA392116CD6A4B647573068BF7B66B03859BFB5E0B6A814A10B843B18&level=3&sha=3928588565e69ba1897b9ad4b876014ef0697d2a&platform=1&br=20&fmt=sd':
  Metadata:
    creator         : QQVideo
    hasKeyframes    : true
    hasVideo        : true
    hasAudio        : true
    hasMetadata     : true
    canSeekToEnd    : true
    datasize        : 6994383
    videosize       : 5049011
    audiosize       : 1889996
    lasttimestamp   : 238
    lastkeyframetimestamp: 238
    lastkeyframelocation: 6995950
  Duration: 00:03:58.33, start: 0.067000, bitrate: 234 kb/s
    Stream #0:0: Video: h264 (Main), yuv420p, 480x270 [SAR 1:1 DAR 16:9], 168 kb/s, 15 tbr, 1k tbn, 30 tbc
    Stream #0:1: Audio: aac, 44100 Hz, stereo, s16, 59 kb/s
-t is not an input option, keeping it for the next output; consider fixing your command line.
[libx264 @ 03532a20] using SAR=1/1
[libx264 @ 03532a20] using cpu capabilities: MMX2 SSE2Fast FastShuffle SSEMisalign LZCNT
[libx264 @ 03532a20] profile High, level 2.1
[mpegts @ 03532320] muxrate VBR, pcr every 1 pkts, sdt every 200, pat/pmt every 40 pkts
Output #0, mpegts, to 'bug3.ts':
  Metadata:
    creator         : QQVideo
    hasKeyframes    : true
    hasVideo        : true
    hasAudio        : true
    hasMetadata     : true
    canSeekToEnd    : true
    datasize        : 6994383
    videosize       : 5049011
    audiosize       : 1889996
    lasttimestamp   : 238
    lastkeyframetimestamp: 238
    lastkeyframelocation: 6995950
    encoder         : Lavf54.16.104
    Stream #0:0: Video: h264, yuv420p, 480x270 [SAR 1:1 DAR 16:9], q=-1--1, 90k tbn, 15 tbc
    Stream #0:1: Audio: mp3, 44100 Hz, stereo, s16
Stream mapping:
  Stream #0:0 -> #0:0 (h264 -> libx264)
  Stream #0:1 -> #0:1 (aac -> libmp3lame)
Press [q] to stop, [?] for help
DTS -3000, next:-3001000 st:0 invalid dropping
PTS -2867, next:-3001000 invalid dropping st:0
DTS -2933, next:-2935000 st:0 invalid dropping
PTS -2933, next:-2935000 invalid dropping st:0
DTS -2867, next:-2869000 st:0 invalid dropping
PTS -2733, next:-2869000 invalid dropping st:0
DTS -2800, next:-2803000 st:0 invalid dropping
PTS -2800, next:-2803000 invalid dropping st:0
DTS -2733, next:-2737000 st:0 invalid dropping
PTS -2533, next:-2737000 invalid dropping st:0
frame=    0 fps=0.0 q=0.0 size=       0kB time=00:00:-2.-70 bitrate=  -0.0kbits/s dup=0 drop=2    
frame=    0 fps=0.0 q=0.0 size=       0kB time=00:00:-1.-14 bitrate=  -0.0kbits/s dup=0 drop=26    
frame=   58 fps= 36 q=27.0 size=     114kB time=00:00:00.40 bitrate=2331.2kbits/s dup=0 drop=43    
frame=  134 fps= 64 q=27.0 size=     481kB time=00:00:05.46 bitrate= 720.5kbits/s dup=0 drop=43    
frame=  207 fps= 79 q=27.0 size=     824kB time=00:00:10.33 bitrate= 652.9kbits/s dup=0 drop=43    
frame=  225 fps= 73 q=27.0 Lsize=    1209kB time=00:00:14.86 bitrate= 666.3kbits/s dup=6 drop=43    

video:809kB audio:282kB subtitle:0 global headers:0kB muxing overhead 10.804575%
[libx264 @ 03532a20] frame I:10    Avg QP:22.60  size:  8799
[libx264 @ 03532a20] frame P:150   Avg QP:24.22  size:  4437
[libx264 @ 03532a20] frame B:65    Avg QP:26.54  size:  1149
[libx264 @ 03532a20] consecutive B-frames: 48.0% 39.1%  4.0%  8.9%
[libx264 @ 03532a20] mb I  I16..4:  5.1% 70.4% 24.5%
[libx264 @ 03532a20] mb P  I16..4:  4.7% 26.6%  6.3%  P16..4: 30.4% 12.3%  4.2%  0.0%  0.0%    skip:15.5%
[libx264 @ 03532a20] mb B  I16..4:  0.5%  1.9%  0.5%  B16..8: 33.9%  6.0%  1.3%  direct: 2.9%  skip:52.9%  L0:41.0% L1:51.8% BI: 7.2%
[libx264 @ 03532a20] 8x8 transform intra:70.6% inter:62.4%
[libx264 @ 03532a20] coded y,uvDC,uvAC intra: 77.3% 60.1% 12.9% inter: 23.7% 18.2% 1.4%
[libx264 @ 03532a20] i16 v,h,dc,p: 20% 23%  7% 50%
[libx264 @ 03532a20] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 20% 19% 15%  5%  7%  8%  7%  7%  9%
[libx264 @ 03532a20] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 22% 21% 15%  6%  9%  9%  8%  6%  6%
[libx264 @ 03532a20] i8c dc,h,v,p: 54% 25% 16%  5%
[libx264 @ 03532a20] Weighted P-Frames: Y:10.7% UV:5.3%
[libx264 @ 03532a20] ref P L0: 59.1% 17.4% 15.9%  6.8%  0.8%
[libx264 @ 03532a20] ref B L0: 86.0% 13.5%  0.6%
[libx264 @ 03532a20] ref B L1: 97.8%  2.2%
[libx264 @ 03532a20] kb/s:441.71

% ffmpeg -i dura_err.ts 2>dura_err2.txt

dura_err2.txt: 

ffmpeg version N-42547-g7543fd8 Copyright (c) 2000-2012 the FFmpeg developers
  built on Jul 15 2012 21:36:07 with gcc 4.7.1
  configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-runtime-cpudetect --enable-avisynth --enable-bzlib --enable-frei0r --enable-libass --enable-libcelt --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libfreetype --enable-libgsm --enable-libmp3lame --enable-libnut --enable-libopenjpeg --enable-librtmp --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libutvideo --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxavs --enable-libxvid --enable-zlib
  libavutil      51. 65.100 / 51. 65.100
  libavcodec     54. 40.100 / 54. 40.100
  libavformat    54. 16.104 / 54. 16.104
  libavdevice    54.  1.100 / 54.  1.100
  libavfilter     3.  2.100 /  3.  2.100
  libswscale      2.  1.100 /  2.  1.100
  libswresample   0. 15.100 /  0. 15.100
  libpostproc    52.  0.100 / 52.  0.100
[mpegts @ 02220fe0] max_analyze_duration 5000000 reached at 5015467
Input #0, mpegts, from 'bug3.ts':
  Duration: 26:30:58.56, start: 1.400000, bitrate: 0 kb/s
  Program 1 
    Metadata:
      service_name    : Service01
      service_provider: FFmpeg
    Stream #0:0[0x100]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, 480x270 [SAR 1:1 DAR 16:9], 15 fps, 15 tbr, 90k tbn, 30 tbc
    Stream #0:1[0x101]: Audio: mp3 ([3][0][0][0] / 0x0003), 44100 Hz, stereo, s16, 128 kb/s
At least one output file must be specified


The Duration should be 00:00:10. 

However I also saw the duration occurred to be {-ss + -t} in some cases, which was also wrong. 

When I put -ss before and after -i (the fast and accurate seeking mode), everything became correct. 

[burek]

This is not a bug, but rather expected behavior. The reason for your issue is that you didn't quite understand how -ss works. Reading the ​documentation, you can see that:

‘-ss position (input/output)’
When used as an input option (before -i), seeks in this input file to position. When used as an output option (before an output filename), decodes but discards input until the timestamps reach position. This is slower, but more accurate. Position may be either in seconds or in hh:mm:ss[.xxx] form.

What does it say is actually this:

• When -ss is used before -i option (as an input option), it makes ffmpeg seek very fast, using only key frames (which may be arranged every 30 seconds, for example). This is ultra fast, but obviously, not very accurate
• When -ss is used after -i option (or more precisely, before the output file name specification), it makes ffmpeg seek very slowly but extremely accurate (it reads decoded video frames, one by one, dropping them all until the specified point in time is reached)

This would explain why everything magically works when you use both -ss before and after -i option.

One more misunderstanding is regarding -t option. If you specify -t 15, the output file duration will be 15 seconds, not 10, obviously. That you can check also in the ​documentation:

‘-t duration (output)’
Stop writing the output after its duration reaches duration. duration may be a number in seconds, or in hh:mm:ss[.xxx] form.

So, I believe this bug can safely be closed, if you agree.