[Camillo]

> The video surface was a little more problematic. To provide smooth playback, the video frames are queued a half second ahead, tagged with a "release time" that the Android window compositor will use to pick the best frame each update. The SurfaceTexture interface that I could access as a normal user program only had an "Update" method that always returned the very latest frame submitted. This meant that the video came out a half second ahead of the audio, and stuttered a lot.

> To fix this, I had to make a small change in the Netflix video decoding system so it would call out to my VR code right after it submitted each frame, letting me know that it had submitted something with a particular release time. I could then immediately update the surface texture and copy it out to my own frame queue, storing the release time with it. This is an unfortunate waste of memory, since I am duplicating over a dozen video frames that are also being buffered on the surface, but it gives me the timing control I need.

Oh, Mr. Carmack...

http://developer.android.com/reference/android/graphics/Surf...

http://developer.android.com/reference/android/graphics/Surf...

And I only started coding for Android last month. I guess I'm an 11x programmer. :) ducks

[pjmlp]

Those APIs aren't available from the NDK, without an extra JNI performance hit.

Also I bet they don't behave 100% the same way, in regards to timing, across devices.

In graphics programming at the level Carmack develops, every ms counts.

[Camillo]

He explicitly said he was using SurfaceTexture. That is a Java API, there is no SurfaceTexture in the NDK.

[pjmlp]

Somehow I don't see him using Java, but if he said so, then ok.