23 Mar
2019
23 Mar
'19
4:20 p.m.
Am 22.03.2019 um 19:36 schrieb cjflynn(a)digitaltesttools.com:
Carsten, hello
Playback was a bit surprising on my 4.2 GHz Intel Core i7 5K 27 inch Retina iMac.
Yes, that is similar to my experience with a 5k iMac. That's why I think the HighRes
Retina Display of the MacBook Pro is the cause. You would probably need to set the window
size very small to get a better playback performance. It's exaggerated on the Retina
MacBook Pro as it offers a native 2560/1600 resolution on a 15" display, so, a better
performing window size will result in a tiny video size. I'm still not sure if the
actual video viewport resolution is the problem, as I can play half decode-res (999/540)
in full screen on my older 15"/1440/900 MBP without any dropped frames, which would
still be an acceptable viewport size on the much faster Retina Mac Book.
But, as that Retina machine even has trouble previewing the BBB source file in near-SD
resolution in dcp-o-matic main, there must be something about the current display method
causing this.
Carl is working on some hardware accelerated display method (e.g. OpenGL), but that's
not ready for primetime, and it may be complicated to support it multi-platform (even
though OpenGL is supported on all three common platforms). Maybe it is not the actual
video output, but the color conversion? But that should strongly benefit from a faster CPU
as between my older 4core MBP and that most recent 6core, but, the results do not cover
that assumption.
I was trying to get Carl to set the video display optionally to the same size (or integer
mutiples) of the actual decoded resolution, so to avoid scaling. Using the mouse and
window resize elements, it is impossible to set it to a specific viewport resolution like
999/540 for half-flat.
So far, he hasn't been triggered by that idea. Maybe he missed it where I mentioned
it. Maybe I should file a Mantis entry for it.
I am a bit concerned for that bad playback performance making it into 2.14 stable, as I
notice many beginners are irritated about the dropped frames when testing their DCPs.
Especially since Apple is nearly exclusively sold on those very high res displays now.
Usually users can tweak it after some instruction about decode resolution and window size,
but, as I saw it on that popular current MBP15", it can't be tweaked to a
satisfying result.
- Carsten
30 Apr
30 Apr
3:18 p.m.
New subject: [DCP-o-matic] Help with current MacBook Pro in player/preview
Hi all,
[snip]
Carl is working on some hardware accelerated display
method (e.g.
OpenGL), but that's not ready for primetime, and it may be complicated
to support it multi-platform (even though OpenGL is supported on all
three common platforms). Maybe it is not the actual video output, but
the color conversion? But that should strongly benefit from a faster CPU
as between my older 4core MBP and that most recent 6core, but, the
results do not cover that assumption.
My current theory is that it is the blitting to the screen that is slow,
especially on some Macs.
Once I can get the OpenGL code to work on Windows I can merge it into
2.15.x and we can see if that improves matters.
I was trying to get Carl to set the video display
optionally to the same size (or integer mutiples) of the actual decoded resolution, so to
avoid scaling. Using the
mouse and window resize elements, it is impossible to set it to a specific viewport
resolution like 999/540 for half-flat.
So far, he hasn't been triggered by that idea. Maybe he missed it where I mentioned
it. Maybe I should file a Mantis entry for it.
At this stage I'd rather fix it "properly" rather than spend time on
things that feel like hacks (unless there is a utility here that I'm not
seeing).
I am a bit concerned for that bad playback performance
making it into 2.14 stable, as I notice many beginners are irritated about the dropped
frames when testing
their DCPs. Especially since Apple is nearly exclusively sold on those very high res
displays now. Usually users can tweak it after some instruction about decode
resolution and window size, but, as I saw it on that popular current MBP15", it
can't be tweaked to a satisfying result.
Unfortunately I think this is a complicated business, and there's already
too much piled up in 2.13.x that needs to be out in the wild.
However I'm hoping (as I always do) that 2.16.0 can follow 2.14.0 much
faster than 2.14.0 followed 2.12.0.
All the best,
Carl
4:36 p.m.
New subject: [DCP-o-matic] Help with current MacBook Pro in player/preview
Just to thrown in my two pennies on one point...
I do see some utility in this, personally.
If I'm checking a file for quality, I would always prefer to not scale,
or scale by an even factor, to ensure what I'm seeing is as faithful as
possible to the original. For example, on an iMac 5K display I would
watch a 2K file at 3996x2160 (x2 zoom), rather than scaling it up to
full screen.
I don't know if this applies to DCP-o-matic, but I've found when viewing
files in e.g. Premiere Pro, it's hard to assess interlacing artefacts
unless you're at exactly 100% or 200% zoom. At 210%, for example, the
scaling messes with the fields and can either hide any combing, or
massively exaggerate it. Either way, you can't make a proper judgement
of how the file will look when it's projected.
One other thing... I assume the OpenGL you're talking about is for
displaying image *after* conversion from J2K right? Or are we at last on
the brink of GPU-accelerated J2K encode/decode???
As ever, massive big up for your tireless work on DCP-o-matic Carl.
Can't wait for 2.14.0.
Jim
I was trying
to get Carl to set the video display optionally to the same size (or integer mutiples) of
the actual decoded resolution, so to avoid scaling. Using the
mouse and window resize elements, it is impossible to set it to a specific viewport
resolution like 999/540 for half-flat.
So far, he hasn't been triggered by that idea. Maybe he missed it where I mentioned
it. Maybe I should file a Mantis entry for it.
At this stage I'd rather fix it
"properly" rather than spend time on
things that feel like hacks (unless there is a utility here that I'm not
seeing).
3 May
3 May
2:55 p.m.
New subject: [DCP-o-matic] Help with current MacBook Pro in player/preview
I do see some utility in this, personally.
If I'm checking a file for quality, I would always prefer to not scale,
or scale by an even factor, to ensure what I'm seeing is as faithful as
possible to the original. For example, on an iMac 5K display I would
watch a 2K file at 3996x2160 (x2 zoom), rather than scaling it up to
full screen.
I don't know if this applies to DCP-o-matic, but I've found when viewing
files in e.g. Premiere Pro, it's hard to assess interlacing artefacts
unless you're at exactly 100% or 200% zoom. At 210%, for example, the
scaling messes with the fields and can either hide any combing, or
massively exaggerate it. Either way, you can't make a proper judgement
of how the file will look when it's projected.
Fair enough; https://dcpomatic.com/mantis/view.php?id=1546
One other thing... I assume the OpenGL you're
talking about is for
displaying image *after* conversion from J2K right? Or are we at last on
the brink of GPU-accelerated J2K encode/decode???
OpenGL is just for the rendering, hopefully to speed it up and possibly to
do the scaling and colourspace conversion on the GPU. Accelerating J2K
encode/decode is a separate thing. I've made some progress on GPU
encoding but the speeds I'm seeing aren't too great; I need to pick the
brains of a GPU expert really.
Best,
Carl
2 May
2 May
10:56 a.m.
New subject: [DCP-o-matic] Help with current MacBook Pro in player/preview
Am 30.04.2019 um 17:18 schrieb Carl Hetherington:
At this stage I'd rather fix it "properly" rather than spend time on
things that feel like hacks (unless there is a utility here that I'm not
seeing).
True, but, as we have seen 'weird' performance improvements with some specific
viewport settings, I guess it would be a very quick solution for those poor Mac users.
How about storing the current display resolution in the config (to make it sticky)? That
would allow to set a specific resolution in the config file, so you could match decoding
and display resolution. And, having it sticky is a reasonable feature anyway, no?
This saturday I will have access to a recent Retina MacBook. I could give it a try there.
You could add it to that diagnostic player version 2.15, so I could also read out the
display timing for different settings.
- Carsten
11:04 a.m.
New subject: [DCP-o-matic] Help with current MacBook Pro in player/preview
Am 02.05.2019 um 12:56 schrieb Carsten Kurz via DCPomatic:
True, but, as we have seen 'weird' performance improvements with some specific
viewport settings, I guess it would be a very quick solution for those poor Mac users.
Oh, and as Jim also mentioned it - some users prefer to have a 1:1 pixel reference for QC,
so to be sure no scaling/aliasing artifacts are introduced for critical material.
So, having an option to match decoding and display resolution would be a reasonable
feature anyway, and also that option to be sticky.
- Carsten
2187
days inactive
2228
days old
5 comments
3 participants
participants (3)
-
Carl Hetherington -
Carsten Kurz -
Jim Dummett