Serious bug in VideoFileClip.get_frame time to frame# transformation

[nerduno]

I've found a bug in VideoFileClip.get_frame(t).

For some times t (not all), the frame returned by get_frame(t0) changes depending on prior calls to get_frame.

For example, the following code will print the value False, unless I comment out the request for frame100.

#get frame 101
myclip = mpye.VideoFileClip(movie.mp4)
frame101_v1 = myclip.get_frame(0.8455)

#get frame 101 after requesting frame 100
myclip = mpye.VideoFileClip(movie.mp4)
frame100 = myclip.get_frame(0.8375)
frame101_v2 = myclip.get_frame(0.8455)

print all(frame101_v1 == frame101_v2)

It turns out frame101_v1 is equal to frame102.

The bug appears to be related to code in ffmpeg_reader.py that attempts to optimize the speed of get_frame seeking behavior.

[nerduno]

Poking around more, the bug seems to be that when get_frame calls initialize with a non-zero time, self.pos becomes offset from the actual position by one.

[Zulko]

Thanks for the report, this is a serious bug indeed. The strange thing is that apparently the bug appears for some videos, and not for others. I am not sure yet, but that could be a question of where the "key-frames" are or something like that. I'll investigate.

[nerduno]

Thanks for the response and for looking into this. I'll let you know if I find other clues.

[tburrows13]

Very likely no longer valid

[SamirS97]

I am still getting this issue when iterating through the frames with a time index.
get_frame(767) returns the right frame when run independently but it returns an image corresponding to the output of get_frame(5230) (frame at second 5230) inside a for loop.