Levels interpretation problem between Windows and Mac

I had a strange problem occur today,

I graded a TVC with mixed footage (Alexa 2K Prores444 Anamorphic, Sony A7SII Mp4 at 1080p,720p at various frame rates and DJI 4K footage) on my main workstation which is a Windows Machine.
The client requested Prores4444 and Prores422HQ files as deliverables both rendered flat and as individual clips with 25frame handles. (I know Prores4444 is overkill for the DJI and A7SII footage but this is what they wanted.) This is very common for almost every commercial I grade lately.

All footage exists on a big Storage Server with 10Gb Ethernet and can be accessed from all my workstations.
To do the prores exports I used an iMac. Everything went fine and reasonably fast.

Afterwards I placed the flat Prores files on the top video layer of my timeline on my Windows machine to compare them.
Everything was exactly the same on my external reference monitor and also on internal resolve scopes and external (scopebox); except for the Sony A7SII footage which had lifted blacks.

I immediately thought it was a levels interpretation problem.
After some investigation I realised that levels where interpreted differently on Windows than on the Mac but only for the A7SII footage.

On windows Resolve clip attributes for A7SII clips where set to Auto (Which was the same as setting it manually on video) and when opening the same project on Mac Resolve (when set to auto or video) black levels where lifted both on the scopes and on the external monitor.

I then tried setting the levels for those clips at Full on my Windows Resolve and compared that with the Mac Resolve set both at auto and video and they looked exactly the same. I did that in the media pool on the original ungraded clips.
Then I tried setting it to Full on the Mac and resulted on blacks that where even more lifted.

To deliver the project with correct blacks (and highlights) I manually switched the levels to Full on all A7SII clips and re graded them and then on my iMac I changed the attributes back to video.
Then the renders where correct. Problem solved.

I don’t understand though why this is happening.
Seems to be A7SII specific although I haven’t yet tried with other h264-avc encoded footage. 
I will and post results.

Have anybody had that occur on a similar situation? Does anybody have an explanation on why this is happening?

Both machines are running Resolve 12.5.5.

Does anybody have an explanation on why this is happening?

Here is a Developer paper on media types in Quicktime:

https://developer.apple.com/library/con ... qtff3.html

Its a bit of a long document, but you will be able to see fairly quickly that "Atoms"

https://developer.apple.com/library/con ... qtff1.html

carry the information used by a player application to decode the data information packet.

They are sometimes misinterpreted, and "auto" is not always your friend.

jPo, CSI

But JP, the problem is that apparently Windows and Mac versions of Resolve interpret the source footage differently (even though they are using the exact same clip attribute settings).

This is very possible as not all libraries/different source types handling is exactly the same.

You graded on a Windows box and rendered on a Mac. Did you use remote rendering or did you use intermediates, and if so what did you use?

...
I immediately thought it was a levels interpretation problem.
After some investigation I realised that levels where interpreted differently on Windows than on the Mac but only for the A7SII footage.

On windows Resolve clip attributes for A7SII clips where set to Auto (Which was the same as setting it manually on video) and when opening the same project on Mac Resolve (when set to auto or video) black levels where lifted both on the scopes and on the external monitor.
...

Cary, I'm pretty sure Angelos is saying that the discrepancy exists when viewing the original XAVC-S clips at the project level.

You graded on a Windows box and rendered on a Mac. Did you use remote rendering or did you use intermediates, and if so what did you use?

I just opened the same project linking to the same media on my iMac. Haven't tried remote rendering to see if it changes anything.

I have checked with Canon 7d media also. Same thing happens.

...
I immediately thought it was a levels interpretation problem.
After some investigation I realised that levels where interpreted differently on Windows than on the Mac but only for the A7SII footage.

On windows Resolve clip attributes for A7SII clips where set to Auto (Which was the same as setting it manually on video) and when opening the same project on Mac Resolve (when set to auto or video) black levels where lifted both on the scopes and on the external monitor.
...

Cary, I'm pretty sure Angelos is saying that the discrepancy exists when viewing the original XAVC-S clips at the project level.

Yes, that is what I'm saying exactly.

That is interesting.

So if you explicitly set the level (either video or full) on both platforms there is a discrepancy on the scopes?

That should never happen.

It is true that auto is not reliable but explicitly setting a level should obviously work the same on all platforms.

I have a suspicion that this has to do with how Quicktime is implemented (or replaced) in Windows vs MacOS.

Maybe try opening the source file in QT Player in Windows and then do the same in MacOS, and see if there is a level change. Screen captures may make judging any level change easier.

This is very bad test as relies on players which are not reliable at all (QT on windows is last thing where it comes to accurate preview).
Problem will be related to the way how Resolve opens files on different OSes- it's not 100% the same so results may vary.

Andrew, do you know if Resolve uses QT to open and play h.264 files in Windows? I believe Premiere has moved on from using QT; I believe Avid still uses QT; I don't know about Resolve.

A similar test would be for other people with both Mac and PC systems to open an h.264 source file in Resolve in both Windows and MacOS and see if there is levels difference.

Angelos has done this and sees a difference. Maybe other people can try too?

Angelos has done this and sees a difference. Maybe other people can try too?

I would recommend for testing to specify YRGB color science and no other settings because managed color science could potentially skew the results due to monitor output LUTs and even scope LUTs.

Andrew, do you know if Resolve uses QT to open and play h.264 files in Windows? I believe Premiere has moved on from using QT; I believe Avid still uses QT; I don't know about Resolve.

A similar test would be for other people with both Mac and PC systems to open an h.264 source file in Resolve in both Windows and MacOS and see if there is levels difference.

Angelos has done this and sees a difference. Maybe other people can try too?

I don't think Resolve uses QT on Windows. h264 QT decoder on Windows is very simple and has poor performance.
I think it uses Windows system decoder. That's why it can't decode 10bit or 4:2:2 file as this is not supported as far as I know. Resolve Studio uses 3rd party (Mainconcept I think) licensed decoder which is full spec h264 decoder including 10bit and 4:2:2. Now h264 decoding is shifted to GPU on supported cards, but this again will be limited to 8bit and 4:2:0.

It's going be probably full range h264 file. For typical h264 (with limited range file) result should be identical. Not many h264 decoders read and respect range flag.

Andrew, very interesting information. And it probably explains why BMD has said, in Windows, the Studio version will have better h.264 performance than the free version.

Why not use VLC. There is a version for PC, one for MAC, one for LINUX.

I do not think the developers of VLC modify the code according to the OS. To each of "see"

You can't avoid this- at some point you have to send data to GPU and display and this is very different on each OS. VLC uses GPU acceleration for h264 on Win and Mac and this is going to be different code also.

Hi Andrew,
And there is no solution to use only the CPU? (I admit not to know too much VLC. Sorry if I say a stupidity)

There is, but still whole path after decoding h264 to uncompressed data and passing to display is very different than on PC. VLC is not very stable on Mac.

I must be confused, what do external viewers have to do with any of this?
The alleged problem is in Resolve and with Resolve scopes right?

Not much- it's comment about overall accuracy/difference of playback on different OSes.

[Peter Chamberlain]

Thanks for feedback.. we will take a look.

I see this as a serious problem, is there a solution? I am running studio version 12.5.6 on: Mac OS X 10.11.6 and Windows 10 Pro. We need consistent results when switching over to render prores.

Can anyone report if this has been fixed in version 14?

Version 14 does not rely on any QT code on the PC any more.

And when I export stuff with the correct setting out of DR from either platform I can't see any difference when imported to DR one the other one if viewed via an I/O device on a calibrated monitor or in the scopes. According to my limited testing, I can even leave DR on "Auto" for the range settings.

Viewing on any software player is quite different, some assume their own settings, some respect the atoms and some rely on system settings for color space and gamma. Don't trust them!

BTW, even Adobe, who have been moving away from the QT framework in 2017, isn't always flagging right. I can export full range signals from After Effects only by using a 444 codec (the settings from the old Avid interface have disappeared), but when DR is on "Auto" they are seen as "Video" and I have to correct that manually.