[FFmpeg-trac] #6402(avformat:new): First frames incorrect after seeking on H264 file

[FFmpeg]

#6402: First frames incorrect after seeking on H264 file
----------------------------------+---------------------------------------
             Reporter:  jrummell  |                     Type:  defect
               Status:  new       |                 Priority:  normal
            Component:  avformat  |                  Version:  unspecified
             Keywords:            |               Blocked By:
             Blocking:            |  Reproduced by developer:  0
Analyzed by developer:  0         |
----------------------------------+---------------------------------------
 Summary of the bug:
 While playing a H264 video, seeking to a different position appears to
 display the wrong frames. After a few (1-4?), subsequent frames look
 correct.

 Input: https://storage.googleapis.com/chromiumos-test-assets-public/Shaka-
 Dash/480.mp4

 How to reproduce:
 > ffplay 480.mp4
 ffplay version N-86098-g3fefaea Copyright (c) 2003-2017 the FFmpeg
 developers
   built with gcc 4.8 (Ubuntu 4.8.4-2ubuntu1~14.04.3)
   configuration: --pkg-config-flags=--static --extra --enable-gpl
 --enable-libass --enable-libfdk-aac --enable-libfreetype --enable-
 libmp3lame --enable-libopus --enable-libtheora --enable-libvorbis
 --enable-libvpx --enable-libx264 --enable-nonfree
   libavutil      55. 63.100 / 55. 63.100
   libavcodec     57. 96.101 / 57. 96.101
   libavformat    57. 72.101 / 57. 72.101
   libavdevice    57.  7.100 / 57.  7.100
   libavfilter     6. 89.101 /  6. 89.101
   libswscale      4.  7.101 /  4.  7.101
   libswresample   2.  8.100 /  2.  8.100
   libpostproc    54.  6.100 / 54.  6.100
 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '480.mp4':
   Metadata:
     major_brand     : dash
     minor_version   : 0
     compatible_brands: iso6mp41avc1
     creation_time   : 2015-09-01T00:38:39.000000Z
   Duration: 00:07:10.00, start: 0.033367, bitrate: 626 kb/s
     Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p,
 854x480 [SAR 1:1 DAR 427:240], 15 kb/s, 29.97 fps, 29.97 tbr, 90k tbn,
 59.94 tbc (default)
     Metadata:
       creation_time   : 2015-09-01T00:38:39.000000Z
       handler_name    : VideoHandler

 Once playing, right click at various different points. In some places it's
 obvious that a different frame is displayed.

 Example: seek to 46%. Person walking across the screen jumps several times
 before walking normally. Even if the video is paused when you seek, then
 when play is started again the same effect is seen.

 Reference: http://crbug.com/568336

 After playing with this for a while, it appears to be related to commit
 4ab56667594842283dc5ae07f0daba2a2cb4d3af. My guess is that when seeking
 the first frame displayed is the one at the start of the fragment, but
 then the code catches up to the correct position quickly. Removing the
 call to either mov_read_sidx() or mov_seek_fragment() in libavformat/mov.c
 "fixes" the problem.

 In Chromium, the effect is different. It gets the following frames out of
 order, so the video jumps around quite a bit. Observation video attached
 to the crbug listed above, if you're interested.

--
Ticket URL: <https://trac.ffmpeg.org/ticket/6402>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker