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.

 

Go Back   Doom9's Forum > Capturing and Editing Video > VirtualDub, VDubMod & AviDemux

Reply
 
Thread Tools Search this Thread Display Modes
Old 5th October 2018, 17:19   #661  |  Link
Revan654
Registered User
 
Revan654's Avatar
 
Join Date: May 2004
Posts: 324
Quote:
Originally Posted by shekh View Post
A lot of code around formats was cleaned, new colorspaces are more possible now.

x265: which options will be game changing? I reviewed the list and honestly all remaining options look too low level (do not fit simple UI).
All Flags needed for creating HDR in x265.

--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/
Revan654 is offline   Reply With Quote
Old 5th October 2018, 17:30   #662  |  Link
Revan654
Registered User
 
Revan654's Avatar
 
Join Date: May 2004
Posts: 324
Quote:
Originally Posted by imhh11 View Post
ok so after a couple more tests, I cannot get the same colors as the source with those small yellow/orange flowers. Magicyuv, cineform, uncompressed, other players, MediaExpress: all the same. it's not an encoding issue because encoding the source directly with the same settings output proper colors
so unless im doing something wrong in Vdub (doubt it), i guess it's because the decklink mini 4k cannot do Bt2020 even if they say it can on the box. smh
I doubt you can capture 1:1, If that's what your trying to do. I havn't been following the thread.

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).
Revan654 is offline   Reply With Quote
Old 5th October 2018, 18:08   #663  |  Link
shekh
Registered User
 
Join Date: Mar 2015
Posts: 775
Quote:
Originally Posted by Revan654 View Post
All Flags needed for creating HDR in x265.

--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/
--output-depth 10
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
shekh is offline   Reply With Quote
Old 5th October 2018, 22:38   #664  |  Link
imhh11
Registered User
 
Join Date: Jul 2016
Posts: 171
Quote:
Originally Posted by Revan654 View Post
I doubt you can capture 1:1, If that's what your trying to do. I havn't been following the thread.

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).


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



Quote:
Originally Posted by Revan654 View Post
Driver Update: Product now includes HDR support(About year+ after the Product was Launched).
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.
imhh11 is offline   Reply With Quote
Old 7th October 2018, 23:15   #665  |  Link
Revan654
Registered User
 
Revan654's Avatar
 
Join Date: May 2004
Posts: 324
Quote:
Originally Posted by shekh View Post
--output-depth 10
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.
If the encoder uses multilib --output-depth 10 does need to be declared. By default 8Bit is enabled.

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.
Revan654 is offline   Reply With Quote
Old 12th October 2018, 19:07   #666  |  Link
videoh
Useful n00b
 
Join Date: Jul 2014
Posts: 1,667
Quote:
Originally Posted by Midzuki View Post
That's fine. I will keep NOT using your mod, even though it is better than the original VirtualDub.

</END_OF_DISCUSSION>
Triggered snowflake alert!
videoh is offline   Reply With Quote
Old 15th October 2018, 20:46   #667  |  Link
wonkey_monkey
Formerly davidh*****
 
wonkey_monkey's Avatar
 
Join Date: Jan 2004
Posts: 2,493
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?
__________________
My AviSynth filters / I'm the Doctor
wonkey_monkey is offline   Reply With Quote
Old 15th October 2018, 20:52   #668  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
Windows DLL caching? VfW codecs are DLL's, they will probably be enumerated; not sure when, though (startup or calling compression dialog).
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 16th October 2018, 10:04   #669  |  Link
shekh
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
shekh is offline   Reply With Quote
Old 16th October 2018, 10:46   #670  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
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).
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid

Last edited by LigH; 16th October 2018 at 10:48.
LigH is offline   Reply With Quote
Old 16th October 2018, 12:09   #671  |  Link
Groucho2004
 
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
Groucho2004 is offline   Reply With Quote
Old 16th October 2018, 18:31   #672  |  Link
WorBry
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.
WorBry is offline   Reply With Quote
Old 16th October 2018, 19:55   #673  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,346
@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 .
poisondeathray is offline   Reply With Quote
Old 16th October 2018, 20:27   #674  |  Link
shekh
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
shekh is offline   Reply With Quote
Old 17th October 2018, 03:59   #675  |  Link
WorBry
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:
Originally Posted by poisondeathray View Post
"desireable" is debatable and depends on the situation - what looks good on a test pattern might not look so good on real material .
Which is fair point. Case in point - I freaked out when I saw the pattern of results produced when the 'original' Checker-444 (ProRes_4444) was exported to DNxHR_444 (10bit) in Resolve, and thought something must be wrong.



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.
WorBry is offline   Reply With Quote
Old 17th October 2018, 04:41   #676  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,346
Quote:
Originally Posted by WorBry View Post
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 ?
Nearest neighbor should not blur. And it should survive multiple generations . It's just duplicating the chroma samples when you go 422=>444 , dropping the exact same samples when you go 444=>422 . So it's a lossless transform if done properly, and you can do it infinite times. Any other algorithm will incur some loss each step, some rounding errors, some blurring which gets worse each successive iteration . But nearest neighbor does not necessarily look good on normal content (blocky color edges), in fact it's considered the worst usually for most types of content. But it's good for test patterns.

I haven't looked at those samples yet, but I'll take a closer look later


Quote:
Case in point - I freaked out when I saw the pattern of results produced when the 'original' Checker-444 (ProRes_4444) was exported to DNxHR_444 (10bit) in Resolve, and thought something must be wrong.


Only to discover that DNxHR_444 encoded with FFMPEG and DNxHD_444 exported from Avid Media Composer behaved the same way.
No . There something wrong with those last screenshots. Looks like a serious DNxHR issue somewhere in the workflow . Looks like adding some noise or dither . That' s not normal
poisondeathray is offline   Reply With Quote
Old 17th October 2018, 05:11   #677  |  Link
WorBry
Registered User
 
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,197
Quote:
Originally Posted by poisondeathray View Post
Nearest neighbor should not blur
I was saying that it's the convolution averaged 444>422 sub-sampling that introduces some blur.

Quote:
Originally Posted by poisondeathray View Post
…..It's just duplicating the chroma samples when you go 422=>444 , dropping the exact same samples when you go 444=>422
Which is how it appears on the scopes and checker pattern in the above example where I converted the 'Checker-422' clip to r210 with VDub2.

Quote:
Originally Posted by poisondeathray View Post
So it's a lossless transform if done properly, and you can do it infinite times. Any other algorithm will incur some loss each step, some rounding errors, some blurring which gets worse each successive iteration . But nearest neighbor does not necessarily look good on normal content (blocky color edges), in fact it's considered the worst usually for most types of content. But it's good for test patterns.
Based on the above test series and Shekh's interpretation of the conversion modalities it appears that that is also how Resolve up-samples 422 to 444 on import. Nothing I can do to change that. Resolve processes in 32-bit float, as I'm sure you know.

Quote:
Originally Posted by poisondeathray View Post
No .There something wrong with those last screenshots. Looks like a serious DNxHR issue somewhere in the workflow . Looks like adding some noise or dither . That' s not normal
Which is disconcerting to say the least. I had been thinking about switching to DNxHR_444 as a (Resolve) export intermediate but this has turned me off again. Unfortunately ProRes is not an export option in Resolve on Windows.

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.
WorBry is offline   Reply With Quote
Old 17th October 2018, 05:16   #678  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,346
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.
poisondeathray is offline   Reply With Quote
Old 17th October 2018, 06:27   #679  |  Link
WorBry
Registered User
 
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,197
Quote:
Originally Posted by poisondeathray View Post
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 View Post
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 View Post
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 View Post
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.
__________________
Nostalgia's not what it used to be

Last edited by WorBry; 17th October 2018 at 07:22.
WorBry is offline   Reply With Quote
Old 17th October 2018, 07:32   #680  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,346
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.
poisondeathray is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 16:06.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.