0

I'm trying to check 360 Video performance with version 11.62465, the 360 video output can't reach to 60P when we play FHD@60P 360 video. The video decode will update video frame in every 14ms~17 ms, but the application can't call SbPlayerGetCurrentFrame() 16ms, then the drop frame happens. The drop frame rate is nearly 20%. I tried to use chrome://tracing/ check the performance and found that sometimes the rasterizer lasted 40ms, the CPU duration is only 8ms, does this mean the GPU ability is not enough? Will the cobalt render thread be blocked by other modules?

GPU Status

bitchainer
  • 535
  • 2
  • 19
Kai Wang
  • 25
  • 5

1 Answers1

0

If the CPU duration per-frame is 8ms, then it does sound like the GPU is not powerful enough to process each video frame fast enough. The Cobalt render thread should never be blocked by other modules, though it may be worth double checking that your implementation of SbPlayerGetCurrentFrame() is not taking a long time to render (perhaps it acquires a lock?).

You can use chrome://tracing/ to check the performance of the renderer when a non-360 FHD@60P video is playing, and compare that performance to when a 360 video is playing. This will tell you whether the renderer's performance is affected by the decode-to-texture process or not.

Andrew Top
  • 2,517
  • 1
  • 17
  • 10
  • Thanks for your explanation. In our design, only decode-to-texture will use GPU for the renderering, no-360 video will use HW video path. We can't compare that. We will save latest video output frame and SbPlayerGetCurrentFrame() will get the latest frame immediately without any lock. We are checking the GPU performance now. – Kai Wang Sep 06 '17 at 01:11
  • We use DS5 check GPU loading and found that the GPU is always 100% run, as the previous comment, I think bottle neck is in GPU part. By the way, is there any suggestion about GPU ability if we want do FHD@60P render? – Kai Wang Sep 06 '17 at 07:50
  • You can modify SbPlayerOutputModeSupported() to report that it only supports decode-to-texture, to force non-360 videos to use decode-to-texture. But almost certainly I think the problem is with the large video passing through the GPU unit, regardless of if it's 360 or not. There is not yet a way to suggest that you cannot render high resolution 360 video, though we are looking into passing that information through to SbMediaCanPlayMimeAndKeySystem(). – Andrew Top Sep 08 '17 at 00:27
  • Hi, Andrew, I modified SbPlayerOutputModeSupported() as you suggested, and the performance of non-360 FHD@60P video is almost the same as 360 video. – Kai Wang Sep 12 '17 at 07:49
  • Please see attached picture of the DS5 result: Channel 1 means the Rasterizer get current frame, Channel 2 means the VDEC notified that there is a new video frame. The select part shows that Rasterizer gets the current frame in nearly 33ms even the GPU is free. It's a little strange. Will the Rasterizer get video frame by VSYNC, if not, what is it waiting for? – Kai Wang Sep 12 '17 at 12:15
  • Hi Kai, so it looks like most of the time we render every 16ms (60fps), but every now and then we render in 33ms (30fps)? Looking at the screenshot you posted, it seems as though that 1 problematic frame took *slightly* longer than 16ms to render, and because of that, it missed the VSYNC event (which occurs every 16ms) and so it will have to wait for the next one (so the GPU will be idle). In other words, if you take (even slightly) longer than 16.6ms to render a frame, then the framerate will drop to 30fps for that frame. So, it looks like VSYNC is the thing the rasterizer is waiting on. – Andrew Top Sep 13 '17 at 16:46
  • Hi, Andrew, the render not run in 16ms or 33ms, sometimes it will be 22ms. The render is running in MessageLoop::RunTask and it will run every COBALT_MINIMUM_FRAME_TIME_IN_MILLISECONDS(16.4ms), It may be not waiting for VSYNC event. When the NG case happens, RasterizeRenderTreeToCanvas and VisitRenderTree will last for a long time even the CPU duration is not high. We may need to check what are they waiting for. – Kai Wang Sep 15 '17 at 09:46