Quote:
Originally Posted by poisondeathray
There is an intermediate RGB step in Resolve too. If there wasn't, and Resolve could work in YUV, you would expect Y to be the same since you're measuring Y psnr in those graphs, not Y, U, V or aggregate YUV PSNR. For programs that are YUV capable, there is no alteration of the Y plane . v210 gets special treatment - it actually gets special treatment in other NLE's too, even ones that work internally in RGB . It's a native format that gets passthrough . For some Windows based NLE's, you can use IYUV (8bit 4:2:0, with fourcc IYUV, or 8bit 4:2:2 with fourcc UYVY) and those gets passthrough , but Resolve is really devloped from a Mac environment , there is no way to get it to work with uncompressed 8bit 4:2:0
|
I guess I can't speak to what resolve is doing internally. I presumed it converts to RGB all the time, but maybe not. I unchecked the box for "Bypass re-encode when possible". Obviously I couldn't make any changes to the video or I'd lose my ability to do a PNSR. I guess I could have use two inline grade nodes that cancel each other out. I didn't try that.
I also didn't realize I was only looking at the Y plane. Oops. I'm brand new to using the MSU VQMT tool.
Quote:
Was this internal avs function conversion, or z_convert_format?
Recall there is a chroma shifting issue in the internal avs resizers . It's not a true point resize. There are workarounds such as resize8, but z_convert_format works properly
But it would partially depend on how resolve is defining the chroma placement too.
|
I tried both internal avs function and z_convert. I need to retest using YUV PNSR.
How are you measuring PNSR with ffmpeg? The free version of MSU VQMT can't do 10-bit which makes this a big pain.