You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Another convenience may be a better version of time-pos that isn't dependent on video frame rate or synchronization, but a property that represents where the playback "should be". time-pos is discrete and locked to the frame rate so the resolution isn't always sufficient, and audio-pts isn't guaranteed to be in sync, is nil during seeking, and isn't even guaranteed to exist for files without an audio stream. For example, for a 10fps video, the new property would be able to return something like 0.35317865 when it's on the 4th frame, rather than 0.300. And if a/v gets out of sync, it doesn't return where the audio playback currently is, but the target time the video and/or audio stream is trying to sync up with. So if it skips a few frames or needs to adjust audio or something, the property keeps increasingly at a constant rate as if nothing happened.
If it wouldn't break much, perhaps this new property could replace time-pos, since in most cases it should be functionally equivalent or better. And then the current time-pos would get renamed to video-pts since that name doesn't exist yet, and for video files that's basically what time-pos is.
Then you'd end up with video-pts and audio-pts representing the actual time of each stream and time-pos is what they're both getting synced to, if that makes any sense
The text was updated successfully, but these errors were encountered:
Pulled out from #13614 (comment)
#13614 (comment)
The text was updated successfully, but these errors were encountered: