Still exists.

This is NOT fixed. I'm still getting this on 2019.3.6

Works correctly on Windows 10 but still exists on Windows 7.

This issue persists in 2018.3.0f2. I'm using the videoPlayer.frame property and rendering the far plane with audio output direct.

Issue persists in 2018.3.0f2. I'm using the frame property.

Issue still persists in 2018.2.14f1

I am also having the same issue as JOSHMCCREADY. I can tell it is new because if I set a video to pause and go to a specific hard coded time, it will show a different in frame in 2017.3 than 5.6. I am currently unable to upload a bug report for some reason (I keep getting server timeout and the bug reporter freezes). Has anyone been able to submit a bug report for this issue/am I able to upload a bug report in a different way? I have a small sample project that illustrates this problem easily.

I'm having an issue that it think is related. Ive been testing the seek function on a frame indexed video and have noticed that both the frame number and frame time become incorrect by one frame after a fixed number of frames. That number of frames stays constant for a given video (was 6005 frames on the video i was looking at) seeking below that number returned the correct frame, seeking above that number returned the frame I wanted +1. by seeking it was impossible to get to frame # 6006. I could however get to this frame if i were to seek to frame 6005 and then call StepForward(). If 6006 were a magic number i could work around this problem but unfortunately this number is different for different videos. Maybe somehow dependent on the bitrate? Something is wrong with how unity is calculating time when it does a seek. Its not fixed in 2017.3.1f1 but am hoping it can be soon.

I'd like to know why severity is set to "3: workaround is possible". If there is any workaround, where is it?

The same applies to setting VideoPlayer.time. As play, pause and seek are the three major video-player related actions, this issue is urgent and critical.