Sponsors
Sponsor Products
Oculus Rift CV1 on Linux for 4K 60FPS playback with Head Tracking
posted by Todd Smith  on Nov. 20, 2017, 7:40 a.m. (27 days ago)
2 Responses     0 Plus One's     0 Comments  
On what medium is the source material being played from? Technical specifications of the underlying storage?Machine specifications?Load on CPU/GPU/RAM/Storage during playback?
Todd Smith
Head of Information Technology
soho vfx | 40 Hanna Ave. Suite 403, Toronto, Ontario M6K 0C3
office: (416) 516-7863 fax: (416) 516-9682 web: sohovfx.com

From: "Cam Wright" <content@studiosysadmins.com>
To: "studiosysadmins-discuss" <studiosysadmins-discuss@studiosysadmins.com>
Sent: Sunday, November 19, 2017 7:34:55 PM
Subject: [SSA-Discuss] Oculus Rift CV1 on Linux for 4K 60FPS playback with        Head Tracking

Hi,

I'm investigating using an Oculus Rift CV1 for headset reviews of 4K media on Ubuntu 16.04 using RV and Nuke.

It seems the documentation for Nuke / CaraVR is very useful and getting that working out of the box was pretty painless... Nuke's framerate playback when Monitor Out is enabled with the Rift connected is not ideal though - 15FPS from the viewer (30FPS out of Nuke Studio using the timeline) - we need 60FPS though as that's what we're delivering media to the client in. Can't "Monitor Out" of a flipbook either. 

RV was basically a no-go either, as that seems to want separate GL distortion shaders- and even then the head tracking doesn't work so it's basically a worse broadcast monitor. It did seem to play back at the correct framerate though... mplayer essentially did the same thing, once Nuke had been triggered to make the display available for configuration via xinerama.

Has anyone else had any luck (or experience at all, successful or not) with any applications (above mentioned or otherwise) on Linux for 60FPS playback of 4K media through the Rift, complete with head tracking?

At the moment we're testint primarily with the Rift connected directly to the GPU (GTX {9,10}80, it matters not), but haven't had any luck running it through a dedicated output playback device either (BlackMagic Decklink Mini Monitor 4K) as it seems that applications and HMD drivers don't even recognise it as a video device, so won't display any video.

-C


To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe

Thread Tags:
  discuss-at-studiosysadmins 

Response from Cam Wright @ Nov. 20, 2017, 7:19 p.m.

> On what medium is the source material being played from? Technical specifications of the underlying storage?

Oracle ZS3-2 w/ 512GB memory, backed by ~75 8GB spindles in RAIDZ6 and a 20GbE pipe all the way to the edge switch which the workstation is running.
Storage is connected to the workstations via NFSv3 on a subnet configured for MTU 9000.

> Machine specifications?

Nuke 10.5v3
Nvidia GeForce GTX 970
Intel(R) Core(TM) i7-5930K CPU @ 3.50GHz (six core, two threads per core).
64GB 2133MHz Memory
500GB Intel Datacenter SATA SSD as scratch/cache playback
10GbE to edge switch, 20GbE all the way from edge switch to to core switch to storage.

> Load on CPU/GPU/RAM/Storage during playback?

On the storage- Negligable, not high enough to be causing an issue given the media should be cached locally either to disk or RAM before playing back in the Nuke viewer anyway. I don't believe network load (either on the storage nor switchs) between is an issue either.
Ditto on the workstation- GPU is doing nothing except drawing the display plus whatever is needed for Nuke's GL-accelerated nodegraph and viewer. RAM is only what the OS and Nuke needs, so sub-5GB. CPUs are virtually idle.

I'm not convinced storage is the issue, playback with the "Monitor Out" disabled is 60FPS as needed, but with the "Monitor Out" enabled it drops dramatically to 15/30. Initial playback (pre-cache) is certainly limited by the network storage, so plays at ~3-4FPS, but once reading from the cache (local SSD) it ramps up to the 15/30FPS.
I'll sync some frames locally to the scratch disk and playback from that and see if that helps, but Nuke's aforementioned caching should already take care of this for us.

-C


0 Plus One's     0 Comments  
   

Response from Cam Wright @ Nov. 20, 2017, 7:19 p.m.

> On what medium is the source material being played from? Technical specifications of the underlying storage?

Oracle ZS3-2 w/ 512GB memory, backed by ~75 8GB spindles in RAIDZ6 and a 20GbE pipe all the way to the edge switch which the workstation is running.
Storage is connected to the workstations via NFSv3 on a subnet configured for MTU 9000.

> Machine specifications?

Nuke 10.5v3
Nvidia GeForce GTX 970
Intel(R) Core(TM) i7-5930K CPU @ 3.50GHz (six core, two threads per core).
64GB 2133MHz Memory
500GB Intel Datacenter SATA SSD as scratch/cache playback
10GbE to edge switch, 20GbE all the way from edge switch to to core switch to storage.

> Load on CPU/GPU/RAM/Storage during playback?

On the storage- Negligable, not high enough to be causing an issue given the media should be cached locally either to disk or RAM before playing back in the Nuke viewer anyway. I don't believe network load (either on the storage nor switchs) between is an issue either.
Ditto on the workstation- GPU is doing nothing except drawing the display plus whatever is needed for Nuke's GL-accelerated nodegraph and viewer. RAM is only what the OS and Nuke needs, so sub-5GB. CPUs are virtually idle.

I'm not convinced storage is the issue, playback with the "Monitor Out" disabled is 60FPS as needed, but with the "Monitor Out" enabled it drops dramatically to 15/30. Initial playback (pre-cache) is certainly limited by the network storage, so plays at ~3-4FPS, but once reading from the cache (local SSD) it ramps up to the 15/30FPS.
I'll sync some frames locally to the scratch disk and playback from that and see if that helps, but Nuke's aforementioned caching should already take care of this for us.

-C


0 Plus One's     0 Comments