Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
29th March 2020, 13:45 | #21 | Link | |
Registered User
Join Date: Dec 2002
Location: Region 0
Posts: 1,436
|
Quote:
|
|
29th March 2020, 14:28 | #22 | Link |
Registered User
Join Date: Sep 2007
Posts: 5,377
|
I mentioned it to you in a previous thread - there is a completely lossless workflow , but it involves EXR sequences and vapoursynth . There were issues before, but Resolve handles EXR float properly now, since v12 or 13 I think . Definitely with v15 it's ok.
Float enables you to convert YUV<=>RGB losslessly when done properly. If avs+ gets a float importer (import EXR that doesn't clip to 16bit int, like ffmpeg) , then it should possible in avs+ too since it can handle float now too. |
29th March 2020, 14:54 | #23 | Link |
Registered User
Join Date: Dec 2002
Location: Region 0
Posts: 1,436
|
I've never messed with vapoursynth. Not sure of the learning curve of it vs. avisynth. Maybe I'll take a look at it later.
However, I suspect I'm missing the forest for the trees getting lost in the minutia here. The less than idea PNSR result doesn't mean mean it looks bad or has visible artifacts. I didn't do a super exhaustive comparison, but in my quick look at a few frames, I couldn't see any quickly apparent difference in the before and after frame despite the sub 50dB PNSR of the worst spots (using uncompressed video formats). |
29th March 2020, 15:09 | #24 | Link | |
Registered User
Join Date: Sep 2007
Posts: 5,377
|
Quote:
But it seems the min values are lower than expected. This is qp 1 intra. You should be getting results higher than prores xq or cineform fs2. PSNR is good for is detecting lossless (or not), and indicating trends, and potential workflow problems So I'm wondering if something else going on there |
|
29th March 2020, 22:09 | #25 | Link | |
Registered User
Join Date: Dec 2002
Location: Region 0
Posts: 1,436
|
Quote:
1) The "retain sub-black and super-white data" in Resolve's export has to be checked. 2) You have to also use z.lib explicitly set to full range, the matrix and transfer coefficients seem to have no effect, but the range certainly does. I also found that if you're using the internal avisynth functions converting to 8 bit first then to YV12 gives a slightly better PNSR score. I was not able to find a matrix for the internal function that gave similar results. Here's the best z.lib/avsresize result I was able to get: Here's the best internal function result I could get: |
|
30th March 2020, 05:59 | #26 | Link | |||
Registered User
Join Date: Sep 2007
Posts: 5,377
|
Quote:
My thinking was input=output so it's a no-op, so I omitted the args. Lesson learned! Quote:
Quote:
My results using the clip in avsresize/zimg. Not sure if it was the same clip because it was 5002 frames vs 5000. And the trends seem different w.r.t the frame ranges . My U plane seemed more problematic than V , but your V seemed to have more trouble than your U . Values seem slightly higher too , the min was 56.288 in vqmt , but you have clear V drops below 50 https://postimg.cc/QHcjV8V7 VQMT scales the U,V planes to Y plane size, that might introduce some errors. I tried unchecking that option , but it would crash. It might be a pro version feature. Anyways it's the trends that are important FWIW this is ffmpeg PSNR , and the abs. min value is higher , and the U,V averages are higher than VQMT - maybe some of the difference is from the VQMT UV scaling, not sure. Often there are slightly different calcs too between programs PSNR y:65.979368 u:64.950274 v:66.120163 average:65.812176 min:59.375502 max:88.556475 You can combine methods too. If a different method produces higher values in a plane you mix/match with combineplanes. But like you said this is splitting hairs these higher PSNR values. It just sucks to see drops like that in sections |
|||
30th March 2020, 13:49 | #27 | Link | ||||
Registered User
Join Date: Dec 2002
Location: Region 0
Posts: 1,436
|
Quote:
Quote:
Quote:
Quote:
I also found that you want to make sure the two sources are exactly the same length or ffmpeg will give you erroneous numbers where as VQMT just uses the length of the shorter source for the comparison. |
||||
30th March 2020, 16:00 | #28 | Link | |
Registered User
Join Date: Sep 2007
Posts: 5,377
|
Quote:
Yes, for all types of metrics, you also need frames to align exactly, and frame accuracy. FFmpeg can tricky because it uses timestamps to guide it. There are some side cases that can still yield incorrect results if you're not careful. eg. If container timebases are off (e.g. MP4 vs. MKV express differently), or jitter in the timestamps, the results can be off. 23.976 is not the same thing as 24000/1001. There are ways to reset timebase and set framerate within ffmpeg to try to get it to align (there is an example in the docs with settb and setpts). But there are still other cases - ffmpeg psnr/ssim/vmaf calcs will drop negative timestamps or open GOP b-frames at the beginning in the calculation. But if you were to decode the same video to rawvideo (ES), and use that as input, it keeps those b-frames. So on one hand ffmpeg keeps the frames, but on the other it drops them. That inconsistency can cause a problem. For example , official vmafossexec (Netflix VMAF) takes rawvideo input . This can cause discrepancies in the reported values, even though they use the same library If you feed it avs script or vpy script , you can check for alignment (e.g. in avspmod or vsedit) , and be certain the same frames are decoded the same way and have the same timestamps (info , or use AssumeFPS if they differ) Did you use avs input for ffmpeg ssim ? That 5-6db delta between our avg U,V results is too large for my liking if it was the same clip. And the avg Y values are close, so it doesn't suggest some misalignment issue Same with VQMT - it can't be exactly the same clip because I had 5002 frames vs. your 5000. |
|
30th March 2020, 17:30 | #29 | Link | ||
Registered User
Join Date: Dec 2002
Location: Region 0
Posts: 1,436
|
Quote:
Quote:
However, I just went back and redid the whole thing and made sure I got 5002 frames this time. PSNR y:65.979373 u:57.686445 v:51.298844 average:57.726204 min:53.681992 max:88.556475 |
||
30th March 2020, 17:50 | #30 | Link |
Registered User
Join Date: Dec 2002
Location: Region 0
Posts: 1,436
|
I also got curious and decided to try something. Simply changing the iDCT algorithm used by MPEG2Source can change the output quite a bit in PSNR terms. All using the same 5002 frame MPEG-2 source.
The three 32 bit routines compared to the IEEE-1180 Reference: PSNR y:62.449197 u:62.938405 v:62.566806 average:62.546733 min:58.816064 max:90.653474 The 64-bit floating point compared to the IEEE-1180 Reference: PSNR y:102.999039 u:104.085312 v:104.101176 average:103.334047 min:89.595436 max:inf SSEMMX (Skal) compared to the IEEE-1180 Reference: PSNR y:62.376757 u:62.547402 v:62.376608 average:62.404711 min:58.623051 max:90.653474 Simple MMX (XviD) compared to the IEEE-1180 Reference: PSNR y:65.242412 u:67.925161 v:66.576349 average:65.801940 min:61.771485 max:90.653474 ffms2 vs MPEG2Source (IEEE-1180 Reference): PSNR y:65.346402 u:66.217016 v:65.103104 average:65.437119 min:61.781376 max:inf Does H264 have similarly vague iDCT specs that allows different decoders to do different things that give slightly different results? |
30th March 2020, 18:16 | #31 | Link | |||
Registered User
Join Date: Sep 2007
Posts: 5,377
|
Quote:
Quote:
Quote:
The only decoder side switch you might sometimes see is disable deblocking |
|||
Tags |
chroma bug, resolve |
|
|