Opened 3 years ago

Last modified 3 years ago

#5951 new defect

Problem with accurate seeking

Reported by: hanky Owned by:
Priority: normal Component: undetermined
Version: unspecified Keywords: seeking
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

I want to extract an image frame at a certain time.
I'm using the following command:

% ffmpeg -ss 00:05:00 -i V0000754.mpg -frames:v 1 out_1.jpg

The Seeking article says that prefix version of '-ss' parameter should be frame-accurate. But the result I get is different from the postfix version:

% ffmpeg -i V0000754.mpg -ss 00:05:00 -frames:v 1 out_2.jpg

Video info:

% ffprobe V0000754.mpg 
ffprobe version 3.1.1-static http://johnvansickle.com/ffmpeg/  Copyright (c) 2007-2016 the FFmpeg developers
  built with gcc 5.4.0 (Debian 5.4.0-4) 20160609
  configuration: --enable-gpl --enable-version3 --enable-static --disable-debug --enable-libmp3lame --enable-libx264 --enable-libx265 --enable-libwebp --enable-libspeex --enable-libvorbis --enable-libvpx --enable-libfreetype --enable-fontconfig --enable-libxvid --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtheora --enable-libvo-amrwbenc --enable-gray --enable-libopenjpeg --enable-libopus --enable-libass --enable-gnutls --enable-libvidstab --enable-libsoxr --enable-frei0r --enable-libfribidi --disable-indev=sndio --disable-outdev=sndio --enable-librtmp --enable-libmfx --enable-libzimg --cc=gcc
  libavutil      55. 28.100 / 55. 28.100
  libavcodec     57. 48.101 / 57. 48.101
  libavformat    57. 41.100 / 57. 41.100
  libavdevice    57.  0.101 / 57.  0.101
  libavfilter     6. 47.100 /  6. 47.100
  libswscale      4.  1.100 /  4.  1.100
  libswresample   2.  1.100 /  2.  1.100
  libpostproc    54.  0.100 / 54.  0.100
[h264 @ 0x4b2a480] mmco: unref short failure
[h264 @ 0x4b2a480] number of reference frames (0+4) exceeds max (3; probably corrupt input), discarding one
[h264 @ 0x4b2a480] Increasing reorder buffer to 2
Input #0, mpeg, from 'V0000754.mpg':
  Duration: 00:15:05.55, start: 48367.196511, bitrate: 2324 kb/s
    Stream #0:0[0x1c0]: Audio: mp2, 48000 Hz, stereo, s16p, 192 kb/s
    Stream #0:1[0x1e0]: Video: h264 (Main), yuv420p(tv, bt470bg), 720x576 [SAR 12:11 DAR 15:11], 25 fps, 25 tbr, 90k tbn, 50 tbc

Should the results of those two commands be identical?

Change History (3)

comment:1 Changed 3 years ago by hanky

Also I've noticed that both prefix and postfix '-ss' parameters give identical results for files with start = 0:

Input #0, ogg, from 'big_buck_bunny.ogv':
  Duration: 00:01:00.71, start: 0.000000, bitrate: 613 kb/s

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '300_trailer.mp4':
  Duration: 00:02:33.24, start: 0.000000, bitrate: 7377 kb/s

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'rbsp_launch_1080p.mp4':
  Duration: 00:02:06.17, start: 0.000000, bitrate: 31587 kb/s

comment:2 Changed 3 years ago by hanky

And also I get correct results if I convert the source file from mpg to mp4 or avi:

% ffmpeg -i V0000754.mpg -c copy V0000754.mp4

comment:3 Changed 3 years ago by hanky

It seems that using '-copyts -start_at_zero' provides same results for both prefix and postfix '-ss' parameter. Is this intended behaviour?

Note: See TracTickets for help on using tickets.