Help with current MacBook Pro

[Carsten]

During a recent workshop, one of the participants was using a 2018 MacBook Pro, 15" Retina (see screenshot). It uses a nice 6coreHT i7-8850H CPU at 2.6GHz base clock. We were very disappointed with DCP-o-matic's player performance, as even at quarter resolution decoding, it skipped very many frames. We disabled an antivirus software, but no change. I ran through BigBuckBunny to compare encoding speed with my older MacBook Pro, and the CPU/system itself is doing fine, 12.5fps during encoding, which is similar to what other 6coreHT CPUs yield. The machine is running Mojave/10.14.
My personal non-retina 15" MacBook pro uses an older 4coreHT CPU, Sierra/10.12, and encodes BigBuckBunny at half the speed, yet playback performance in player is far better - it plays 25fps at half 2k decoding resolution without any skipped frames.

I reduced the display resolution, because the Retina display has a very high resolution, and currently, DCP-o-matic player has a weak point in pushing the video to the display. That didn't solve the issue either. I noticed though, when I encoded BigBuckBunny, that DCP-o-matic wasn't even able to playback the preview of the original source video without stuttering. We tried both 2.12.20 and 2.13.132.

I still believe this has something to do with the display addressing. The filmmaker of course is very disappointed because she paid quite a bunch of $ for this machine.

Did anyone experience something similar on his machine?
Carl - you mentioned a prototype open-gl output module - could you make a beta version of the player available to see if that is an immediate improvement?

- Carsten

Bildschirmfoto 2019-03-18 um 17.30.30.png

[phili2p]

I just moved to a somehow powerful Win10 workstation and found the player stottering, too.

CPU: i9-9940X
RAM: 128 GB
Geforce RTX 2070
SSD: Samsung 970 Pro (from which the DCP is loaded). System is on another SSD.
Display: DELL 27'' with 2560x1440 pix native resolution.

DoM-Version: 2.12.20

Having a 2K 25 DCP loaded (average bitrate or 230 MB/s) I had over 380 dropped frames from 540 frames in total at full resolution playback.
In quarter resolution I got only 14 dropped frames.

Monitoring the resouses I found the CPU does not use all cores. Only two are on 100% - all others are idling.
As neither SSD nor RAM do somehow show up relevant peaks I guess, that's where the Player could be improved.

[Carsten]

The player has seen quite a bit of improvement in 2.13.x. Still, there are bottlenecks, but it seems, on current fast CPUs, that is no longer just the J2K decoding, but other issues. Carl thinks about using OpenGL for display, but maybe there are other, simpler workarounds for now. It would at least be important to get one mode without dropped frames in quarter or half res at a decent image size. It's weird that a slower, older machine shows better playback performance than the most recent breed.

I have no trouble with slow progression of individual features in general, but I think it would be bad if we don't get this playback issue sorted out for 2.14 stable.

Could you try loading a DCP into DCP-o-matic main and compare the playback performance between main/preview and player on your machine?

- Carsten

[phili2p]

The same DCP loaded in the main app and it seems to behave like half resolution in the player. Not sure if I never had a closer look on that but I am not sure if it's possible to change the resolution of the preview window in DoM-Main. Maybe it's the size of the player window?

I have no clue about the decoding process but I expected to have all cores to be used. I keep my fingers crossed for a(ny) solution. I don't mind if it's OpenGL or buffering some seconds before the playout starts.

[Carsten]

Not all cores being used may first hint to the decoder working inefficient - as a matter of fact, on my older 4coreHT notebook, all 8 logical cores ARE working full thrust at half resolution decode. At quarter frame resolution, only 4 cores are used, so the J2K decoding is fast enough even with the remaining four cores idle.

On more recent CPUs, it may be that now the display drawing routine is so slow that it can't keep all cores busy with j2k decoding, so the J2K decoder is actually waiting for the display routine to request more frames, and so needs only 2 cores J2K decoding to satisfy the few display requests.

Don't know if that is actually the case, but it could be an explanation.


Think of a bike or car braking on either the back or the front wheels. A slow j2k decoder would brake from behind, a slow display routine would brake from the front.



- Carsten

[phili2p]

I installed the latest test version (2.13) and I'm quite fine with the results so far:
Playing back the same short (as above) twice at full resolutuon, I had 9 dropped frames and later 4 dropped frames in total. So that's a quite okay result for preview.
All CPU cores are active, not really balanced equally though but that's a very important step ahead: 35% usage of the CPU in total with two main cores with 100% and others up to 40% in peaks.

[carl]

It might be interesting if you could run the version from here. Play a DCP for 30s or so, then go to Tools -> Timing and give us a screenshot of what it shows - it's some basic information about how long the rendering of images takes. This is (or should be) the only single-threaded part so it's probably the bottleneck if you're seeing non-100% CPU usage.

[phili2p]

Great news: Having installed version 2.15.0, I had 0 dropped frames at full resolution and the requested timing says:

Timing_DoM-Player.JPG

In full screen mode, I had 11 dropped frames. But I'm not sure if this is a result from changing from standard to full screen and back to normal mode. Here's the timing for that:

Timing_DoM-Player_FullScreen.JPG

Best wishes
Philipp

[carl]

OK, good; so blitting the image to the screen takes 11ms per frame, which seems pretty slow but is within the limit of ~40ms.

I'm going to try getting that down using an OpenGL renderer but I haven't got it working on Windows yet.

[Carsten]

Playing a commercial 2k 'Scope in Flat' Trailer in all three decoding resolutions, bot windowed (player default) and fullscreen on my 2.3GHz i7-4coreHT MacBookPro with a 1440/900 display. In both display modes, playback of this trailer is possible with zero dropped frames in quarter and halfdecode resolution. In full decode resolution, very many frames are dropped (1950 out of 2200, it's more a slideshow, once the caching has run out).

In fullres decode, all 8 logical cores stick at 100%, CPU clock is turbo'd to 3.1GHz, and CPU temp rises to 100degree celsius quickly.
In halfres decode at 0 dropped frames, 4 cores work constantly at about 90%, while the remaining four drift between all zero and all 30-40%. That looks solid from a core utilization point of view.

S-F_fulldecode_window.png

S-F_fulldecode_fullscreen.png