Actually fix spikes

[shinyquagsire23]

I'm pretty sure this is an improvement but I may have been looking at it for too long.

• Fixes vsync timing in the graph, and spikes are gone.
  • Spikes were caused by calling alvr_report_submit multiple times for the same timestamp
• Requests IDRs if a frame hasn't been decoded in ~1s, or if the last predicted pose is >400ms ago relative to a received NAL (also abandons all queued NALs before requesting the IDR)
• Predicted poses are now relative to vsync, so timing should be more consistent.
  • Because Apple's prediction gets less consistent the further out you request, I added a constant time offset to the actual anchor requests.

[zmerp]

Because Apple's prediction gets less consistent the further out you request, I added a constant time offset to the actual anchor requests.

I'm not sure how it works... isn't this going to mess with prediction?

[shinyquagsire23]

Because Apple's prediction gets less consistent the further out you request, I added a constant time offset to the actual anchor requests.

I'm not sure how it works... isn't this going to mess with prediction?

Basically the issue is, DeviceAnchor, despite my best attempts, always recalculates its origin transform (maybe it only stores a timestamp). So it gets fetched twice: Once when telling ALVR the position, triggering a frame, and again when that frame arrives, and the DeviceAnchor can change its prediction for that timestamp between then.

So the (hacky) solution is to rewind only the pose prediction fetches closer to the present. I don't really like it, and it definitely feels a bit more sloshy translationally, but the upshot is that it's more stable.

I'm hoping to throw out all the timewarp hacks in the next day or so and do everything correctly, ie only one pose fetch and DIYing timewarp.