View Issue Details

IDProjectCategoryView StatusLast Update
0005575The Dark ModSoundpublic22.05.2024 15:03
ReporterGeep Assigned Tostgatilov  
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
OSWindowsOS Version10 
Product VersionTDM 2.09 
Target VersionTDM 2.13Fixed in VersionTDM 2.13 
Summary0005575: When Uncapped FPS is Off, Video Cutscene Loses Audio Sync
DescriptionAs 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 ReproduceThe 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 InformationIt 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.
TagsNo tags attached.

Relationships

related to 0004514 resolvedstgatilov Game runs sluggish randomly 
has duplicate 0005855 closedstgatilov Cutscenes sound out of sync without uncapped FPS 

Activities

Geep

Geep

31.03.2021 17:24

reporter   ~0013823

A test FM with video that demos the problem is available. PM me for a link
Geep

Geep

31.03.2021 21:36

reporter   ~0013824

Confirmed that the Movie Theatre method exhibits the same bug.
stgatilov

stgatilov

02.07.2022 16:15

administrator   ~0014955

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.
Geep

Geep

14.07.2022 15:48

reporter   ~0015018

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.
stgatilov

stgatilov

14.07.2022 16:48

administrator   ~0015019

Last edited: 14.07.2022 16:48

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.
Geep

Geep

14.07.2022 19:05

reporter   ~0015020

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.
nbohr1more

nbohr1more

15.11.2022 15:26

developer   ~0015431

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.
Geep

Geep

17.11.2022 15:44

reporter   ~0015442

Sure. That idea may be most problematic for video playing on a small surface, but maybe that doesn't occur all that much.
stgatilov

stgatilov

19.11.2022 08:41

administrator   ~0015453

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.
nbohr1more

nbohr1more

15.01.2023 05:18

developer   ~0015773

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?
stgatilov

stgatilov

15.01.2023 08:44

administrator   ~0015776

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.
stgatilov

stgatilov

22.05.2024 15:03

administrator   ~0016705

I reverted the fix from 0004514 in svn rev 10746.

So now GUI + game time goes with the same speed as the sound time.
No sound stutters when playing sound from video file, no problem with sound playing slower if it is run independently.

Unfortunately, most of the code treats time as integer number of milliseconds.
So if we want to keep time step constant, it can be either 16 ms or 17 ms.
Neither of which is synced to Vsync, so the double-frames are inevitable.
The previous "solution" was to have game frame at 16 ms but run it every 16.65 ms, which introduces this difference between video and sound.

Given that now default mode is "uncapped FPS + Vsync on", I don't think lack of smoothness in this legacy mode is a problem.
Keeping strictly fixed timestep is more important --- that's the only reason we maintain this mode...

Issue History

Date Modified Username Field Change
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
05.12.2023 02:10 nbohr1more Target Version TDM 2.12 => TDM 2.13
22.05.2024 14:27 stgatilov Relationship added related to 0004514
22.05.2024 15:03 stgatilov Note Added: 0016705
22.05.2024 15:03 stgatilov Assigned To => stgatilov
22.05.2024 15:03 stgatilov Status confirmed => resolved
22.05.2024 15:03 stgatilov Resolution open => fixed
22.05.2024 15:03 stgatilov Fixed in Version => TDM 2.13