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.
yes -- i really understand this point. i was just considering, if your actual troubles could be more related to communication problems between your decklink card and the tv set, than just some other kind of performance regression in resolve. even the fact, that it only appears in recent releases of resolve isn't a strict indicator for the 2nd case, because this kind of indirect response to some underlaying problem could be also become more visible, if more efficient methods of asynchronous output were chosen in this more recent releases etc. ...
again: 50fps/10bit/4:2:2 over HDM 2.0a is usually seen as an non-specified transport mode!
it's one of the reasons, why display port connections are usually seen as the better choice, if you need this kind of pixel format and framerate on computer/consumer screens. but in the case of a tv set and unavoidable need of hdmi connectivity, you simple have to find some kind of smallest common denominator, which flawless works in practice.
one technical solution would be utilizing 12bit mode -- even if the two additional LSBs would't be never used in this case --, because for 12bit connections 4:2:2 is again officially available resp. provided by hdmi standard again. but this possible workaround unfortunately doesn't seem to be supported by your tv set.
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!
in this case, some kind of 8bit transport seems to be going on in reality resp. become negotiated between your decklink card and the tv set. that's more or less independent of the actual source and even the pixal format, which is used to feed the decklink card. it's just another reminder, which highlights the fact, that you can not control all this transport related settings and issues from a higher level of software access.
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).
i would guess, that you'll hardly notice the difference of of both subsampling modes on a tv screen in practice. more significant differences are in most cases rather related to inadequate implementations of the actual subsampling implementation than a principal consequence or necessary limitation of this more compressed transport.
it's much more important, that you find a realistic solution, which actually works on your given setup!
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.
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!
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.
these are very interesting new findings!
they look very close to another test, which i would have suggested otherwise:
utilizing ffmpegs/ffplays decklink output capabilities trying to reproduce a similar issue as in resolve.
in this case you could specify by a very simple explicit -pix_fmt argument on the command line to determine, how the data is actually feed to the decklink card resp. which kind of transport mode should be used.
this is not a perfect proof, that the decklink card or its driver doesn't do any further pixel format changes, when it finds out in the negotiation stage of the connection, that a connected devices doesn't like some kind of given input, but it could be seen at least as a strategy to isolate/reproduce/model the actual issues with more simple means.
i'm not very surprised, that especially the sony variant doesn't show this issues. in this case, i'm quite sure, that a proper 4:2:0 enforcement will be used. this doesn't have to be the case in the other more versatile applications.
i really like the exemplary way, how you are used to fight all this practical troubles in a very reasonable and technical proficient manner. you are handling it so well, that i can not do more, than just watching your efforts and sometimes throw in a little bit of food for thought.
if it's caused -- like i guess right now -- more by a decklink related problem resp. it's interplay with the tv set, this could be nevertheless be seen as some kind of "fundamental resolve bug", although less depended to the high level software itself. i'm sure, experienced blackmagic engineers are able to verify or reject this possible explanation without any difficulty.
i just think, they never stumbled over this issue in advance, because you are using a setup resp. communication requirements, which are still quite rare to find in practice elsewhere. but a reproducible bug is a bug and should be solved properly anyway.
Tue Mar 20, 2018 1:37 pm
