View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005575||The Dark Mod||Sound||public||31.03.2021 03:13||15.01.2023 08:44|
|Product Version||TDM 2.09|
|Target Version||TDM 2.12|
|Summary||0005575: When Uncapped FPS is Off, Video Cutscene Loses Audio Sync|
|Description||As reported in stgatilov's [[Time frames and ticks]], when uncapped FPS is off, the game runs slower by 4%, due to integer time issues. This adversely affects playback of video cutscenes. The currently available methodologies for video cutscenes require use of a separate .ogg audio file (even though the video itself contains audio).|
In particular, with the "GUI Message Overlay Method" described in my wiki article [[Full-Screen_Video_Cutscenes]], it was observed that synchronization is fine with Video > Advanced > Uncap FPS ON. With Uncap FPS OFF (and Max FPX 60), playback is synchronized at the beginning, but as time goes on the audio increasingly precedes the video. This is consistent with the audio playing at proper speed but the video framerate too slow.
Since the mapper has no control of whether the gamer uncaps FPS or not, this presents a problem.
|Steps To Reproduce||The foregoing observation was in my FM WIP.|
[TO DO SHORTLY: Create a simplified map with cutscene that demonstrates the problem and can be used as a test of any solution]
|Additional Information||It is not yet known if the other video cutscene method, using a Movie Theatre, represents a viable workaround, or suffers the same problem (but probably).|
The best solution would be to no longer require a separate ogg file, but use the audio within the .mp4, presumably enforcing sync. Could the reported special coding applied in TDM 2.06 for video briefings with embedded audio be extended to video cutscenes?
If so, this could be restated as a feature request.
A workaround, at least for an audio track with talk and no music, is to chop it into short segments (under 30 seconds and between sentence boundaries), each of which is then script-started independently after an appropriate wait. These segments would ideally be short enough so that the sloppy sync is not too obvious. Ugly work, though.
|Tags||No tags attached.|
|A test FM with video that demos the problem is available. PM me for a link|
|Confirmed that the Movie Theatre method exhibits the same bug.|
As a matter of fact, mp4 videos allow to play sound from video file.
It stays in sync with video no matter what, but since video plays slower without uncapped FPS, audio briefly pauses every so often, so it is still bad.
Unfortunate that it is still bad.
Is the method to play sound from the mp4 video something a mapper could currently do outside of briefings (in 2.10 or 2.11)? If so, please point me to details, so I can update [[Full-Screen_Video_Cutscenes]] to include it... even with the sync loss problem. Thanks.
I don't know.
I think there is no artificial barrier for playing sound from video file during gameplay.
To be honest, I don't know how to fix this issue in a way that would work during gameplay too.
Aside from returning to old-style modelling with guaranteed micro-stutter every 1.5 seconds regardless of mission size.
If no artificial barrier, then I'll experiment at some point. But not this month... I'm trying to complete a major wiki series.
Always depressing when no fix can be seen. I wonder if there's some capped fps where the slowdown doesn't happen. Maybe it would be a fractional fps (59.94, 29.97, 23.976... the usual 1000/1001 ratio with respect to an integer fps). If so, the ability for the user to easily select a fractional fps would be useful.
This probably won't be a popular suggestion but we could just force uncapped behavior with max_fps 60
whenever a video is playing ? At least it should be good enough to get 2.11 out with something resembling the intended functionality.
|Sure. That idea may be most problematic for video playing on a small surface, but maybe that doesn't occur all that much.|
No, I definitely don't like the idea.
Deterministic fixed-step tics is the only benefit of the capped mode.
Introducing hacks for disabling it is a road to nowhere.
I went back to a very old TDM version ( 1.07 ) and noticed that the bad FPS behavior in Linux with capped FPS has been with us since before going standalone.
One thing I found that dramatically improved the behavior was disabling "precise tic" ( com_preciseTic 0 ).
I tried testing this in 2.11 and the game froze.
Most of the code for this looks unchanged from Doom 3 vanilla so I am guessing something else in the timer infrastructure broke this?
Yes, of course it is broken: all those "uncapped FPS" changes broke it.
Anyway, as far as I see, it just issues the tick every time timer calls async function.
So it would break time synchronization even harder than the current code does.
|31.03.2021 03:13||Geep||New Issue|
|31.03.2021 17:24||Geep||Note Added: 0013823|
|31.03.2021 21:36||Geep||Note Added: 0013824|
|02.07.2022 16:15||stgatilov||Note Added: 0014955|
|02.07.2022 16:15||stgatilov||Relationship added||has duplicate 0005855|
|02.07.2022 16:15||stgatilov||Target Version||=> TDM 2.11|
|14.07.2022 15:48||Geep||Note Added: 0015018|
|14.07.2022 16:48||stgatilov||Note Added: 0015019|
|14.07.2022 16:48||stgatilov||Note Edited: 0015019|
|14.07.2022 19:05||Geep||Note Added: 0015020|
|15.11.2022 15:26||nbohr1more||Note Added: 0015431|
|17.11.2022 15:44||Geep||Note Added: 0015442|
|19.11.2022 08:41||stgatilov||Note Added: 0015453|
|10.12.2022 07:05||nbohr1more||Status||new => confirmed|
|23.12.2022 18:52||nbohr1more||Target Version||TDM 2.11 => TDM 2.12|
|15.01.2023 05:18||nbohr1more||Note Added: 0015773|
|15.01.2023 08:44||stgatilov||Note Added: 0015776|