av_seek_frame messes up PTS of frames

[denial]

Adding a line
av_seek_frame(fmt_ctx, video_stream, 0, AVSEEK_FLAG_BACKWARD);
before the main loop of test/api/api-h264-test.c for some videos results in different PTSs.

In my mp4 test video the first frame to have a wrong PTS is frame 130. The error is noticeable because after decoding the PTSs are no longer monotonic. When the video is shortened to 1MB, the PTSs are correct. I guess libavformat then avoids reading the index.

Since upload.ffmpeg.org does not work right now, I can't upload the video.
A video that shows the error can be downloaded with
youtube-dl -f 136 https://www.youtube.com/watch?v=1tdbtRpfk-c
After download it should have the md5 hash d1159f216fcdb2e034b5ca3a8e25a886.

[denial]

If I understand correctly, what happens is that the MOV demuxer forgets to set the headers_read flag for the fragment that has already been parsed by mov_read_header. When av_seek_frame is called, mov_switch_root decides to parse the headers again, resulting in mov_read_trun appending the values for the first fragment a second time to the ctts array.

[Carl Eugen Hoyos]

Apparently fixed in feb1dbc7bd4c395400c48055c563ac23d5251716