Update: Long story short, Niss3's computer couldn't handle encoding at 60fps, which is what caused us to see clock drift. Niss3's run at 29.97fps had no drift -- though I got to make my usual adjustment of adjusting people faster because they started their timer early. Niss3's now recording at 30fps.
Note: I don't believe this is nefarious. No evidence of foul play, likely a technical explanation for the discrepancy.
Whenever I moderate a time, regardless of the length, I manually verify runs. This is regarding Niss3's River City Ransom speedrun submitted on April 2nd, 2016 (). After first manual verification, I noticed my timing was ~5 seconds off. Re-verified, to get the same result (to within 0.2s). Re-verified again to notice clock drift as I was watching the run.
Video here: Looking at ~5.1 seconds of clock drift between the end times (probably more like 6+ seconds of drift considering Niss3 split early when starting the run), against two separate devices (Core i7-2700 on 150Mbps connection, and iPhone 6S Plus). No evidence of splicing. Likely a technical explanation. However 29.97 vs. 30 fps would only yield about a ~0.45s difference. 25 vs. 24fps would yield a far larger discrepancy (~18.5 sec).
Niss3: If you can supply your Twitch broadcast settings for OBS/XSplit (particularly framerate), and also the original recording, that'd be great.
In the meantime, the frame-correct average of my three timings would be 7:41.867.
I get the same result when I time with Livesplit on the online twitch vod:
Is this because I stream at 60 FPS? Or is it because my bitrate can't support 60 FPS? I don't understand. I'll try stream some with 29.97 FPS.
I timed the local vod and it's all fine. So there's nothing wrong with Live Split. There's something with either Twitch or my Xsplit settings towards Twitch.
I don't have AmaREC local recordings because I did this under a practise session. But I do have the Xsplit vod:
(Its the last run in the vod. So you have to forward to ~09:10)
niss3.com/xsplitvodrcr.mp4
http://www.filedropper.com/xsplitvodrcr
I did time the youtube clip after I uploaded it. No problems there either.
I've confirmed that the problem was me streaming in 60 FPS.
Also uploading the AmaREC VOD as I write this (its 16GB for just 8 minutes so it will take an hour to upload. Will add youtube link here when it's done) -edit- added link:
Manually confirmed the discrepancy that CapnGoof noted in the 7:41 review. Also confirmed Niss3's 7:29 time as good! Seems you've fixed it! Great time!
Manually verified. No clock drift. Niss3 started his timer early, cheating himself out of some time, so I get to go back to adjusting people a bit faster as usual. Average of three timings was 7:28.983.
Glad we got the problem sorted (Niss3 is now recording at 30fps)!
Niss3, consider setting the video encoding settings encoder preset in XSplit (Broadcast -> Gear next to the Twitch entry -> Gear next to 'Extra Param' in the Video Encoding section) from 'slow' to 'medium' (or 'fast'). The quality hit will be negligible for Twitch, but you may get around the issue where Twitch videos are longer. FWIW, I run on an Core i7-2700K (3.4GHz base clock, ~5.5 years old) and medium is the best I can manage
If the encoder can't keep up (CPU bound) and XSplit can't render the frames fast enough, it occasionally will stuff multiple copies of a frame within a given keyframe/I-frame GOP instead of producing an empty frame (black image) or dropping the frame. Keep in mind since you're running AMARec (which may have less demanding H.264 encoder settings) you are encoding two streams at once -- one that's pushed as an RTMP stream to Twitch's ingest servers, and one that's written to local disk -- so your CPU usage is higher than just streaming to Twitch, and therefore a contested resource.
