[FFmpeg-trac] #4554(undetermined:reopened): wrong seek with -ss
FFmpeg
trac at avcodec.org
Mon Jul 13 13:15:21 CEST 2015
#4554: wrong seek with -ss
-------------------------------------+-------------------------------------
Reporter: | Owner:
josephine.dussourd | Status: reopened
Type: defect | Component:
Priority: normal | undetermined
Version: git-master | Resolution:
Keywords: mov h264 | Blocked By:
seek | Reproduced by developer: 1
Blocking: |
Analyzed by developer: 0 |
-------------------------------------+-------------------------------------
Changes (by noirbee):
* cc: nicolas@… (added)
* status: closed => reopened
* resolution: fixed =>
Comment:
Unfortunately the heuristic fix actually breaks seeking for other files,
i.e. it seeks too far back.
For example with http://kimsufi.noirbee.net/pub/video.mp4 , when seeking
and using stream copy with the following command:
`ffmpeg -y -ss 2 -i video.mp4 -c copy video_seek_heuristic.mp4`
Despite the fact that there is a keyframe 2 seconds / 50 frames into the
video, ffmpeg will seek back to the very first one.
Reverting the abovementioned commit, i.e. not using the heuristic
introduced by Michael, correctly seeks to the keyframe at 2 seconds.
Original video: http://kimsufi.noirbee.net/pub/video.mp4
`ffprobe -select_streams v -show_packets video.mp4` :
http://kimsufi.noirbee.net/pub/video_ffprobe.txt
Output video when using the heuristic (git HEAD):
http://kimsufi.noirbee.net/pub/video_seek_heuristic.mp4
Output video without the heuristic:
http://kimsufi.noirbee.net/pub/video_seek.mp4
Not sure how this could be fixed both for the OP's and my files,
considering seeking uses DTS anyway in MOV/MP4 (well actually for
everything else than nut if I trust `git grep AVFMT_SEEK_TO_PTS`).
--
Ticket URL: <https://trac.ffmpeg.org/ticket/4554#comment:7>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list