Re: Fundamental DR 14 bug report
![Post Post](./styles/bmd_universal/imageset/icon_post_target.gif)
I'm on 14.1.0.014. How does one get 14.1.0.018?
Just download 14.3 from the support page?
Just download 14.3 from the support page?
https://forum.blackmagicdesign.com/
https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=71032
waltervolpatto wrote:I understand, did not realize you downgrade to 14.1.
Yes the optimization changed substantially between 14.1 and 14.3 and if those option are not ticked in the way I'm describing even some of the most powerful linux can be brought to a crawl.
When yoy have the chance, try and let us know.
waltervolpatto wrote:You should be able to scroll down and access that build, but bm could have pulled from the website.
Piotr Wozniacki wrote:For me, it's indispensable to have the Color page capable of full project's fps with scopes being displayed (for obvious reasons), and 4:2:2 monitoring via Decklink (as 4:4:4 causes false banding in UHD@50p projects due to my Samsung monitor switching to 8-bit mode when receiving a 4:4:4 signal).
Piotr Wozniacki wrote:Much more important than getting 4:2:2 rather than 4:2:0 is keeping 10 bit all the way though the monitoring pipeline; as you can see from the table you posted 10 bit is not possible with 4:4:4 monitoring - hence my struggle to never use it.
Piotr Wozniacki wrote:Unfortunately - for reasons beyond my comprehension - the 4:4:4 SDI setting is one of the only 2 ways of getting full, solid 50 fps at playback (the other being turning scopes off completely). When I engage it, however - I'm clearly seeing banding where it doesn't exist in my source material!
Piotr Wozniacki wrote:As to the 4:2:2 vs 4:2:0: this is much less important for proper monitoring while grading, but I dare say what I'm seeing on my Samsung when fed from the HDMI mezzanine of my Decklink indeed is 4:2:2 (unless of course I don't change it to 4:4:4 for the above mentioned reason). How do I know that? Well - back in the times when Convergent Design nanoFlash was the very popular solution to record in 4:2:2 rather than 4:2:0 (like internally in the EX1/4 cameras); I learnt to distinguish the 4:2:2 picture from its 4:2:0 version (having both the internally and externally recorded clips from my EX1 and nanoFlash, I could do an A/B comparison and learnt where to look to see the difference).
Piotr Wozniacki wrote:Currently, I have an even better method of telling whether my preview is 4:2:2 or not: as I grade for HDR10, my deliverable format of choice is HEVC (h.265 files with 10 bit and 4:2:0 chroma resolution). Comparing such clips on the same Samsung 49KS8000 TV I use for grading preview, I can clearly see the higher color resolution in Resolve than in my 420 HEVC files; this is a proof my Deckink can indeed send, and my SUHD - display the 10bit, 4:2:2 video when grading in Resolve.
Piotr Wozniacki wrote:One more proof it's not my system not being up to the task, but DR 14.3 seriously broken in its Color page, is that my FS7 XAVC-I UHD@50p clips can be played back full speed using Sony's Browse program which can also use Decklink for 10bit preview. Not a single frame is dropped (there is an option to stop playback on a single frame drop-out).
...
PS. While we're at Sony's (currently Magix) NLE, Vegas Pro suffers from identical problems with getting full fps playback (using Decklink or nVidia Secondary Monitor) as DR 14.3 has now.
Piotr Wozniacki wrote:T
PS. Also, this is NOT a matter of my "exotic" setup with UHD TV as a HDR preview device; I have my Atomos Shogun Inferno hooked up to the SDI 12G output of my Decklink - a).
Martin Schitter wrote:again, this looks highly unplausible to me, because you can't regain the lost color information [without rescaling] in video footage by any way. if the source footage contains only 4:2:0 information resp. just a quarter of the full color attribution, it will never look better in 4:2:2 or 4:4:4 envrionments of the same spatial resolution. that's a principal technical fact, which can not be overcome. but what you may see perhaps, are subtile differences, which are more related to the actual handling of color subsampling and pixel format transformations in different software and hardware devices. it's a really challenging topic, and there are lots of quite insufficient implementations out there in the real world. it simply doesn't look everywhere just the same!
David Cherniack wrote:Piotr, one temporary way around the problem is to us the Shogun Inferno's scopes. They're just as accurate, if not moreso than the Resolve scopes. I do this and I also use the Inferno as a LUT box to calibrate my display. That way I don't have the issues of using the monitor LUT in Resolve which works in the Color page but not in the Edit page.
Piotr Wozniacki wrote:Martin Schitter wrote:again, this looks highly unplausible to me, because you can't regain the lost color information [without rescaling] in video footage by any way. if the source footage contains only 4:2:0 information resp. just a quarter of the full color attribution, it will never look better in 4:2:2 or 4:4:4 envrionments of the same spatial resolution. that's a principal technical fact, which can not be overcome. but what you may see perhaps, are subtile differences, which are more related to the actual handling of color subsampling and pixel format transformations in different software and hardware devices. it's a really challenging topic, and there are lots of quite insufficient implementations out there in the real world. it simply doesn't look everywhere just the same!
I don't agree with this reasoning at all - even if my preview indeed is only 420,, my output (export) will still be 422 as in the source material. Encoding this to 420 HEVC, I can see the lower color resolution which is a prof my preview during grading must have show full 422 resolution.
Pior
Andrew Kolakowski wrote:It's not 4:2:0 which makes you think your h265 encode looks "worse", but actual compression compared to your Resolve preview. 4:2:0 v 4:2:2 on progressive footage is not a easy thing to see. It can be visible, but only on specially chosen test material.
christopherreig wrote:Hello Piotr, and others!
I just wanted to chime in to say that I can confirm Piotr's claims re: poor playback of material with scopes active. We are presently experiencing this bug on 14.3 on a brand-new setup:
HP Z8 G4 (2x12-core Xeon)
64GB RAM, ACCUSYS Storage Array (1200MB/s)
4x NVIDIA 1080 TI in a Cubix for processing.
Windows 10 Professional, latest updates.
On a 4K DCI 'Scope' timeline (with 24.00p ARRI anamorphic material as source), the system crawls at 23 FPS with scopes enabled - and this is with no images operations, grades, nodes, LUT's - nothing. Turn the scopes off, and the performance returns to 24+ fps, even with multiple heavy nodes applied.
Have actually sent these logs to Blackmagic Design for investigation.
Cheers,
Christopher
Piotr Wozniacki wrote:So sorry, but it's not the culprit. Besides, as I also stress in most of my posts here, it used to work fine in previous Resolve releases, up to the 14.1 (and certainly still in the 12.5.6, as I wasn't able to test the 14.1 thoroughly enough; while in the 12.5.6 I was getting full 50 fps with ease - in the 14.1 the same project seems to already struggle at some 46 fps which suggests some H.264 playback "optimization" has already begun there but wasn't deep enough to slow down my playback by full 50% like it does in the 14.3).
Martin Schitter wrote:Piotr Wozniacki wrote:So sorry, but it's not the culprit. Besides, as I also stress in most of my posts here, it used to work fine in previous Resolve releases, up to the 14.1 (and certainly still in the 12.5.6, as I wasn't able to test the 14.1 thoroughly enough; while in the 12.5.6 I was getting full 50 fps with ease - in the 14.1 the same project seems to already struggle at some 46 fps which suggests some H.264 playback "optimization" has already begun there but wasn't deep enough to slow down my playback by full 50% like it does in the 14.3).
if you really think, the issues are not caused by the output chain, but more related to some kind of h.264 optimizations, you should simply use one of the test-pattern generators of resolve, pack into a compound clip and put it on an otherwise clean timeline. in this case, no h.264 related processing is involved at all -- you are just testing the output/monitoring capabilities free of any input related dependencies. if you don't see the same issues in this case, your approach should indeed be seen as verified and more plausible.
Piotr Wozniacki wrote:One more observation:
To me it looks almost the same as the result of applying a "HDR xxxx nits to Gamma 2.4" to 3D Scopes Lookup Table in the project settings (Color tab), which according to the manual, is supposed to increase legibility of the most important area of the scopes (especially WFM or Parade), in HDR projects. Even back in the times of the 12.5, when I had zero problems with playback speed in the Color page even with Scopes open - applying this 3DLUT would make the fps crawl - exactly at speeds I'm seeing now in the 14.3, even without the 3D Scopes Lookup Table applied. I could never comprehend why the overhead to the system would be that great from applying a 3D LUT to the scopes - but since it didn't really increase my scopes legibility much (if at all), I simply never used it...
Perhaps this observation will enable BMD to pin-point the problem?
Piotr