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. |
5th October 2018, 17:19 | #661 | Link | |
Registered User
Join Date: May 2004
Posts: 324
|
Quote:
--output-depth 10 --colorprim bt2020 --colormatrix bt2020nc --transfer smpte2084 --master-display G(8500,39850)B(6550,2300)R(35400,14600)WP(15635,16450)L(10000000,1) --hrd --aud --repeat-headers --max-cll 1000,180 --no-open-gop + no-intro-smoothing & no-deblocking so the details don't get destroyed. Maybe allow a custom inputbox (like StaxRip & handBrake does) or port over(Since it already has VirtualDub features): https://sourceforge.net/projects/mpx.../x265vfw_v280/ |
|
5th October 2018, 17:30 | #662 | Link | |
Registered User
Join Date: May 2004
Posts: 324
|
Quote:
I know in my capture settings, there a box that says Colorspace: 2020. I also have a device that gives me exact readout going into capture so I know extactly what the colorspace is when it hits the capture box. There products are very misleading at times, or give you bad information. Rep: Out product included HDR from the very start(From Launch). Driver Update: Product now includes HDR support(About year+ after the Product was Launched). |
|
5th October 2018, 18:08 | #663 | Link | |
Registered User
Join Date: Mar 2015
Posts: 775
|
Quote:
This does not need to be specified. --hrd "The HRD parameters are carried by the Buffering Period SEI messages and Picture Timing SEI messages" --aud "Emit an access unit delimiter NAL at the start of each slice access unit." Can you briefly describe what the hell is this in human language --repeat-headers afaik this is solely controlled by container and should not be changed. --no-strong-intra-smoothing --no-deblock Simple options which can be added trivially. Well, inputbox can help with all options but with it comes laborious error checking. Since command line can be wrong in many ways.
__________________
VirtualDub2 |
|
5th October 2018, 22:38 | #664 | Link | |
Registered User
Join Date: Jul 2016
Posts: 171
|
Quote:
Hi, I have the Vertex as well so nothing is wrong with my HDR metadata. But you are right, it seems I cannot get a 1:1 copy. it's very close and acceptable to me but not perfect. http://screenshotcomparison.com/comparison/117314 I think this was for Davinci Resolve hdr playback. Anyway, this drivers and the latest one don't even work with Vdub. Last edited by imhh11; 5th October 2018 at 23:07. |
|
7th October 2018, 23:15 | #665 | Link | |
Registered User
Join Date: May 2004
Posts: 324
|
Quote:
Link: https://www.mysterybox.us/blog/2016/...delivering-hdr They go into detail about the different options when grading HDR and encoding. Jump down to middle of the page, They use Hybrid for Final Process. If the command line is wrong, in FFMPEG or x265 it should catch the error and report what error is(It shouldn't crash the software in most cases). Atlease have VD2 catch the error and report it in a form of a msgbox error or something or have it pass some kind of check. |
|
15th October 2018, 20:46 | #667 | Link |
Formerly davidh*****
Join Date: Jan 2004
Posts: 2,496
|
If I haven't loaded VirtualDub for a while (I think it used to do this on pre-fork versions too) it takes a while to load - 5-10 seconds. After that, subsequent instances load up instantly. Any idea why this is? Is it enumerating something?
|
16th October 2018, 10:04 | #669 | Link |
Registered User
Join Date: Mar 2015
Posts: 775
|
Never paid attention to this. VD itself does not do anything heavy at startup, it must be somewhere in Windows. Maybe something involving swap file or something worse.
__________________
VirtualDub2 |
16th October 2018, 10:46 | #670 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,782
|
Yes, as already mentioned: the "Windows DLL Cache" and "Prefetch" folders as possible factors, and even delayed DLL unloading (keeping a DLL resident in the RAM even after it could be unloaded, until RAM is required to be swapped).
Last edited by LigH; 16th October 2018 at 10:48. |
16th October 2018, 12:09 | #671 | Link |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
Another possibility - Hard drive taking a moment to wake up from sleep mode.
I just got a couple of WD Gold drives which fall asleep after a few minutes without activity.
__________________
Groucho's Avisynth Stuff |
16th October 2018, 18:31 | #672 | Link |
Registered User
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,197
|
@Shekh,
Question about YUV444 <-> YUV422 inter-conversion in VDub2. I've been involved in some studies over on the BlackMagic Design DaVinci Resolve forum. There was concern about the degree of chroma loss seen when Uncompressed 10bit 422 sources are serially 'passed through' (i.e. no transforms applied) Resolve, which pointed to sub-optimal YUV422 chroma-sub-sampling. As you probably know Resolve uses it's own proprietary 'DaVinci YRGB' color-science for processing - the inner workings (algorithms) of which are not publicly known and one can only speculate based on observed behavior. One of the forum members uploaded a couple of test clips that have proved very useful in gaining more insight. The 1080p clips (created with Natron) have a two-color checkerboard pattern. The size of the checkerboard blocks are exactly 5px wide/high, such that every second border will be placed in the middle of a color sub-sampled region. Here's a more complete explanation and the download links for the test clips - one ('Checker-444') in ProRes_4444 format and the other ('Checker'-422) in ProRes HQ (10bit 422) format: https://forum.blackmagicdesign.com/v...=79163#p440425 I also have uncompressed v410 and v210 versions. What has come to light is that when the Checker-422 (v210) is cycled through v410 in VDub2 (by which I mean encoding to v410 and then reconverting the export to v210) the pattern of results (as revealed by the Resolve Histogram and Parade scope profiles) is identical to that obtained when the 'Checker-422' clip is serially 'passed-through' Resolve. https://imgur.com/nfUcnE4 https://forum.blackmagicdesign.com/v...art=50#p446976 Which suggests that they use the same chroma up-sampling and sub-sampling algorithms. Sony (Magix) Vegas Pro 16 however appears to manage 422 chroma sub-sampling in a different way and one that, at face value, produces the more desirable outcome. https://imgur.com/fCw4TvI Could you shed some light on the specific algorithms used in VDub2 when inter-converting 10bit YUV-444 <-> YUV-422. Thanks.
__________________
Nostalgia's not what it used to be Last edited by WorBry; 16th October 2018 at 18:50. |
16th October 2018, 19:55 | #673 | Link |
Registered User
Join Date: Sep 2007
Posts: 5,377
|
@WorBry - if you have serially changing each generation , it suggests some interpolation going on, probably bicubic. If you have blocky sharp color borders and preserved same up/down over each generation, it can only be nearest neighbor . You can verify this by controlling the algorithm in say vapoursynth or avisynth or ffmpeg , export either v210 or v410 and check . You can check the RGB conversion algorithm this way too
"desireable" is debatable and depends on the situation - what looks good on a test pattern might not look so good on real material . |
16th October 2018, 20:27 | #674 | Link |
Registered User
Join Date: Mar 2015
Posts: 775
|
Checked what is going on with chroma,
444 -> 422: each pixel is convolved with kernel 0.25, 0.5, 0.25 As I understand this creates some blurring. 422 -> 444: odd pixel is copied as is, even pixel is blended from two neighbor source pixels This is simple.
__________________
VirtualDub2 |
17th October 2018, 03:59 | #675 | Link | |
Registered User
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,197
|
OK, thanks both. So, if I understand correctly, its 'nearest neighbour' (point) up-sampling and it's the convolution averaged chroma sub-sampling that brings about the separation of the R/B and G channel plots on the Resolve Parade scope, which manifests as blur ?
Up-sampled in that example to r210, because Resolve wont import v410 I wonder then how Vegas Pro sub-samples 444 to 422 to achieve the outcome it does ? Quote:
Only to discover that DNxHR_444 encoded with FFMPEG and DNxHD_444 exported from Avid Media Composer behaved the same way. It was only after reading that DNxHR_444 encoding intentionally adds a small amount of blur to minimize aliasing/blocking that I came to terms with what looked like degradation on the scopes and checker pattern - reasonable explanation being the repeating 5x5 pixel checker pattern amplifies the blur. Still have some doubts that there is not more too it though.
__________________
Nostalgia's not what it used to be Last edited by WorBry; 17th October 2018 at 04:23. |
|
17th October 2018, 04:41 | #676 | Link | ||
Registered User
Join Date: Sep 2007
Posts: 5,377
|
Quote:
I haven't looked at those samples yet, but I'll take a closer look later Quote:
|
||
17th October 2018, 05:11 | #677 | Link | |||
Registered User
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,197
|
I was saying that it's the convolution averaged 444>422 sub-sampling that introduces some blur.
Quote:
Quote:
Quote:
If the issue is somewhere in the workflow, then where ? Those blotchy checker board patterns also occur when FFMPEG and Media Composer DNxHR/DNxHD 444 exports (mov and MXF) of the Checker-444 clip (ProRes_4444 and v410 versions) are imported into VDub2, so it can't be something happening in Resolve.
__________________
Nostalgia's not what it used to be Last edited by WorBry; 17th October 2018 at 05:51. |
|||
17th October 2018, 05:16 | #678 | Link |
Registered User
Join Date: Sep 2007
Posts: 5,377
|
Ahh you're starting with 444 and the pattern is 5x5 ... sorry I should have read more closely. I'll look into it more
But you also have to look at how you are upsampling and converting to RGB for the preview - that could be doing something too . There could be other issues with chroma center interpretation which can add additional issues. Ideally you would separate all the processes out 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) ? Since ffmpeg/avid/resolve all look bad in resolve, it might be as simple as a bad decoder version in resolve And maybe this should be split off, because shekh answered the vdub2 specific questions Last edited by poisondeathray; 17th October 2018 at 05:28. |
17th October 2018, 06:27 | #679 | Link | |||
Registered User
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,197
|
Quote:
In the DNxHR/DNxHD_444 export tests I was using the 'Checkers-444' clip as the input source. Quote:
Quote:
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.
__________________
Nostalgia's not what it used to be Last edited by WorBry; 17th October 2018 at 07:22. |
|||
17th October 2018, 07:32 | #680 | Link |
Registered User
Join Date: Sep 2007
Posts: 5,377
|
Regarding previewing results - it matters how it's interpreted (in terms of chroma location), that makes a big difference , and the way it's upsampled to RGB , or the way you zoom for the screenshot (what algorithm). You can get completely different results appearance wise with the same video in a different application or player
Within resolve itself , if you were only to look at the histogram, you can get fewer spikes using nearest neighbor, chromaloc left Does it "look" better ? It really depends on what is used, and how it's interpreted, or what scenario you're using it for I'll try to figure out what sony is using. I only have vegas 13, but it produced the same v210 as in your screenshot That DNxHR result is completely unexpected and unacceptable. Something is up And I'm getting similar results with Adobe's DNxHR/DNxHD implementation , also on encoding/decoding. It looks like some sort of DCT compression issues. Last edited by poisondeathray; 17th October 2018 at 07:50. |
Thread Tools | Search this Thread |
Display Modes | |
|
|