Search Issue Tracker
Fixed in 2019.1.X
Fixed in 2017.1.X, 2017.2.X, 2018.4.X, 2019.2.X
Setting VideoPlayer.frame from code offsets audio
How to reproduce:
1. Open attached project "Case_889059_newrepro.zip"
2. Enter Play mode
3. When the video is playing press W to advance 200 frames forward and S to go back 200 frames
Expected result: Audio and video are still synced after setting new videoPlayer.frame
Actual result: Audio gets offset/desynced
Reproducible with - 2018.3.10f1, 2019.1.0b8, 2019.2.0a9
Not reproducible with - 2017.4.24f1
Was fixed in: 2017.3.0b1
And backported to: 2017.1.1p4, 2017.2.0f2
Apr 26, 2019 07:34
Mar 14, 2019 21:58
This is NOT fixed. I'm still getting this on 2019.3.6
Feb 27, 2019 09:18
Works correctly on Windows 10 but still exists on Windows 7.
Feb 13, 2019 15:06
This issue persists in 2018.3.0f2. I'm using the videoPlayer.frame property and rendering the far plane with audio output direct.
Feb 13, 2019 13:50
Issue persists in 2018.3.0f2. I'm using the frame property.
Nov 05, 2018 10:24
Issue still persists in 2018.2.14f1
Mar 15, 2018 01:02
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.
Mar 01, 2018 00:26
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.
Jul 18, 2017 15:56
I'd like to know why severity is set to "3: workaround is possible". If there is any workaround, where is it?
Jun 21, 2017 11:54
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.
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
- Shader Graph and the Visual Effects Graph scroll unreasonably fast on OSX
- [Android 4.4] Player crashes at splash screen when building with Frame Timing Stats enabled in the Player Settings
- VisualElement’s auto width is incorrect when the element’s parent has a set width
- Black and white flickering when using two Full Screen Pass Renderer Features
- [Audio] Microphone API latency and audio distortions appear after recording
Resolution Note (fix version 2019.1):
Fixed in 2019.1.2f1
Fixed in 2019.2.0a15
Fixed in 2019.3.0a1
Resolution Note (fix version 2019.2):
Fixed in 2019.2.0a15