Quote:
Originally Posted by poisondeathray
Ahh you're starting with 444 and the pattern is 5x5 ... sorry I should have read more closely. I'll look into it more
|
In those 'round tripping' tests I was starting with 10bit 422 ('Checkers-422'), up-sampling to 10bit 444 and then down-sampling to 10bit 422 again. In the Resolve 'round-trip' series the 'Checkers-422' import was simply 'passed through' to v210 export. In Resolve, all imports get passed to 32-bit float 'DaVinci YRGB'. There is no Uncompressed YUV422 'by-pass' as occurs in Vegas Pro with 'Sony YUV' export when no transforms are applied.
In the DNxHR/DNxHD_444 export tests I was using the 'Checkers-444' clip as the input source.
Quote:
Originally Posted by poisondeathray
The DNxHR/DNxHD "noise" would make it unsuable IMO . That's a separate issue that needs investigating . For example, how does the avid export look when re-imported back into avid (using avid's own decoder) ?
|
Unfortunately I didn't look at that when I ran the Media Composer trial - since uninstalled.
Quote:
Originally Posted by poisondeathray
Since ffmpeg/avid/resolve all look bad in resolve, it might be as simple as a bad decoder version in resolve
|
I wondered about that too. But like I said, when the ffmpeg/avid/resolve DNxHR exports were loaded into VDub2 to examine the checker patterns (copy/pasted source frame to Paint.net to produce the magnified, cropped checker images) they all looked 'bad' also:
Quote:
Originally Posted by poisondeathray
And maybe this should be split off, because shekh answered the vdub2 specific questions
|
Well it relates to VDub2 too if it is a wider decode issue, but if you wish maybe split-off to 'New and Alternative Codecs' section.