VirtualDub2

[Revan654]

Yep, BM is not very reliable- not the best hardware (eg. poor fans, electronics) and more important terrible drivers which keep breaking things every release.
AJA is miles better.

You also have to read the specs very carefully, Some of the wording can be very misleading at times. The BD Decklink for HDR 4K + 60fps. The colorspace only goes up to BT.709. There 8K model however does reach BT.2020 but it doesn't have any HDMI.

I went with Magewell for my Setup, Since they were the only ones I could find that supported Fully Rec.2020 and Had allot of hardware Functions that are missing in others.

Base Functions can reach 12 Bits as well with full 7.1 Audio. If your PC can handle it 144FPS recording.

[imhh11]

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

https://extraimage.net/images/2018/10/02/49b9702c45733da97ec0af752c770135.png

[WorBry]

Dumb question (maybe)...but what was the reported colorspace of the Cineform and MagicYUV captures? You didn't include that portion of information from the MediaInfo report. And your file uploaded didn't include samples of the original captures.


here's the files:
https://uptobox.com/vs384dq3ssci

Format : CineForm
Codec ID : CFHD
Codec ID/Info : CineForm 10-bit Visually Perfect HD (Wavelet)
Duration : 30 s 989 ms
Bit rate : 426 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 (24000/1001) FPS
Scan type : Progressive
Bits/(Pixel*Frame) : 2.144
Stream size : 1.54 GiB (100%)


Format : M0Y2
Codec ID : M0Y2
Duration : 31 s 490 ms
Bit rate : 870 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 (24000/1001) FPS
Bits/(Pixel*Frame) : 4.373
Stream size : 3.19 GiB (100%)

My (maybe dumb) point being, even if decklink does output Rec2020, surely the10-bit 422 Cineform and MagicYUV captures are assuming and encoding as Rec709 ? I don't see any configuration setting for Rec2020 color-space input in my copy of MagicYUV (2.0.0 Ultimate)

[poisondeathray]

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


Did you check x265 with lower crf or lossless ?

Because I suspect lack of Rec.2020 support won't cause those types of issues you're referring to . It looks more like a chroma subsampling or lossy CbCr (high quantization) issue in the screenshots (but that could just as easy be from x265). Take a look at the Cb or Cr plane (granted, I'm looking at an 8bit PNG, but you can see right away the problems) , you will see general blurriness and encoding artifacts . Small color details like those small flowers will be blurred away

eg.
#Your PNG
ConvertToYV24()
UtoY # or VtoY

So check lower crf or lossless x265 first, if problem still there go back 1 more step and look at direct capture (e.g magicyuv)

[imhh11]

Dumb question (maybe)...but what was the reported colorspace of the Cineform and MagicYUV captures? You didn't include that portion of information from the MediaInfo report. And your file uploaded didn't include samples of the original captures.



My (maybe dumb) point being, even if decklink does output Rec2020, surely the10-bit 422 Cineform and MagicYUV captures are assuming and encoding as Rec709 ?

that was all the information from the MediaInfo, there is nothing more. But when I play the file madvr is saying/guessing bt709, perhaps because the flag is not there. magicyuv is reporting rec709 as well.

Capturing uncompressed in Mediaexpress gave the same result.

if I make an mkv with the avi file, mediainfo report more but still nothing on bt709 /bt2020

Video
ID : 1
Format : V_MS/VFW/FOURCC / M0Y2
Codec ID : V_MS/VFW/FOURCC / M0Y2
Duration : 1 s 710 ms
Bit rate : 398 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (23976/1000) FPS
Bits/(Pixel*Frame) : 2.002
Stream size : 81.2 MiB (100%)
Default : Yes
Forced : No


https://extraimage.net/images/2018/10/02/947b88a573e520bdd5a6f59c093eac87.png



Did you check x265 with lower crf or lossless ?

Because I suspect lack of Rec.2020 support won't cause those types of issues you're referring to . It looks more like a chroma subsampling or lossy CbCr (high quantization) issue in the screenshots (but that could just as easy be from x265). Take a look at the Cb or Cr plane (granted, I'm looking at an 8bit PNG, but you can see right away the problems) , you will see general blurriness and encoding artifacts . Small color details like those small flowers will be blurred away

eg.
#Your PNG
ConvertToYV24()
UtoY # or VtoY

So check lower crf or lossless x265 first, if problem still there go back 1 more step and look at direct capture (e.g magicyuv)

the encode were CRF17 slow. but thats a good idea, i'll try lossless. thanks

when i encoded the source with the same setting CRF17 slow.. the colors stay perfect

[poisondeathray]

when i encoded the source with the same setting CRF17 slow.. the colors stay perfect

Right, but look at the U, V planes . It show more damage than up/down scaling only

4:2:0 => 4:2:2 => 4:2:0 . You would expect some blurring if they were not using nearest neighbor (aka point resize in avisynth) , so very small color details will be expected to be blurred. But you have compression artifacts on top as well. Encoding source bypasses that up/down scaling step

But it still looks like something additional is going on too

[imhh11]

ok, i'll try the lossless x265 tomorrow.
I might have something wrong with my pc. if nothing work, maybe a fresh windows installation would fix my issue.

[WorBry]

that was all the information from the MediaInfo, there is nothing more.

Ah, yes you're right, MediaInfo doesn't report the color matrix/primaries. Vdub2 will report the Cineform capture as Rec709 though.

[shekh]

Any Progress on adding BT.2020 / ST.2084? It's been about a year since I last asked, Maybe you made some progress in that area or adding HDR to capture mode.

Also any chance we will see more functions added to x265 codecs (Like the VUI & Bitstream) areas?

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

[imhh11]

Did you check x265 with lower crf or lossless ?


So check lower crf or lossless x265 first, if problem still there go back 1 more step and look at direct capture (e.g magicyuv)

Hi, I tried CRF0 very slow preset and the blurring on grain is less worse but the little flowers are still washed out.


tone mapped
http://screenshotcomparison.com/comparison/121830


I tried re-installing the BM drivers, no luck :(

maybe its the best my card can do.


magic yuv 422 8 bit HDYC capture VS source ----> no issue at all ?? how the hell..
http://screenshotcomparison.com/comparison/121857

[Revan654]

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/mpxplay/files/x265vfw/x265vfw_v280/

[Revan654]

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.

https://pbs.twimg.com/media/Dcnv2vpVQAEUBC0.jpg
https://pbs.twimg.com/media/Dcnv2wwU8AAyp0g.jpg


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

[shekh]

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/mpxplay/files/x265vfw/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.

[imhh11]

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

https://extraimage.net/images/2018/10/05/21f915c50a9223e1eb16a57745acd095.png


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.

[Revan654]

--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/10/27/hdr-video-part-5-grading-mastering-and-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.

[videoh]

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!

[wonkey_monkey]

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?

[LigH]

Windows DLL caching? VfW codecs are DLL's, they will probably be enumerated; not sure when, though (startup or calling compression dialog).

[shekh]

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.

[LigH]

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

[Groucho2004]

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.

[WorBry]

@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/viewtopic.php?f=21&t=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/viewtopic.php?f=21&t=79163&start=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.

[poisondeathray]

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

[shekh]

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.

https://i.postimg.cc/gJ7VB4QS/checker422.png

[WorBry]

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 ?

http://i.imgur.com/BepuPGSm.png (https://imgur.com/BepuPGS)

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 ?


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

http://i.imgur.com/QJhw7E1m.png (https://imgur.com/QJhw7E1)

Only to discover that DNxHR_444 encoded with FFMPEG and DNxHD_444 exported from Avid Media Composer behaved the same way.

http://i.imgur.com/SBXKqWBm.png (https://imgur.com/SBXKqWB)

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.

[poisondeathray]

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


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

[WorBry]

Nearest neighbor should not blur
I was saying that it's the convolution averaged 444>422 sub-sampling that introduces some blur.

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


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.


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.

[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

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

[WorBry]

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.

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.


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:

http://i.imgur.com/SBXKqWBm.png (https://imgur.com/SBXKqWB)


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.

[poisondeathray]

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
https://i.postimg.cc/1fqpmZyX/nearestneighbor-left.png (https://postimg.cc/1fqpmZyX)

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.

[shekh]

From the screenshot it seems Sony is using bilinear downsampling for 444->422, this blends max 2 neighbor pixels as opposed to summed area.
I changed various interpolation options until I got very similar picture.
For 442->444 it is still bilinear upsampling, no changes.
https://i.postimg.cc/zX4JT3bR/checker-2.png

[WorBry]

Thanks again Skekh,

Just to be clear about VDub2:

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.


So is the 422 > 444 in VDub2 (by definition) Nearest Neighbor (Point) up-sampling, which is how I first interpreted your description, or Bilinear upsampling ?

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 ?

http://i.imgur.com/BepuPGSm.png (https://imgur.com/BepuPGS)

Up-sampled in that example to r210, because Resolve wont import v410


As regards Resolve; actually prior to 15.1.1 version update, the v210 'round-trip/pass-through' behavior (using the 'Checker-422' clip) was different

http://i.imgur.com/Ytpokj0m.png (https://imgur.com/Ytpokj0)

The change in behavior seen in 15.1.1 came in response to concern (from BMD forum members) about the quality of the export 422 sub-sampling:

http://i.imgur.com/v6xjp3Fm.png (https://imgur.com/v6xjp3F)

Which is when it became apparent that the 'new' behavior bore a striking similarity to that seen in VDub2 for 422 > 444 > 422.

In fact, referring back to the series I posted earlier....

http://i.imgur.com/nfUcnE4m.png (https://imgur.com/nfUcnE4)

....when I ran quality metrics (FFMPEG) on the matched v210 exports from the Resolve and VDub2 series, the SSIM scores were 1.000000 (lossless) for Luma and UV chroma.

[shekh]

So is the 422 > 444 in VDub2 (by definition) Nearest Neighbor (Point) up-sampling, which is how I first interpreted your description, or Bilinear upsampling ?

Bilinear. Even sample is centered so it is not blended but odd sample is blended.

[WorBry]

Thank-you Shekh.


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.

FWIW - Here's the Checker-444 clip and an FFMPEG DNxHR_444 (10bit) transcode loaded into VDub2 and examined on Color Tools 1.4 videoscopes:

http://i.imgur.com/ucqNVXJm.png (https://imgur.com/ucqNVXJ)

Same pattern as seen on the Resolve scopes.

[Morku]

Hi, I want to capture avi with an usb grabber which works without issue, but... the preview image not work.

Weirdly it worked at the first attempt. I go to capture mode and Video was set to Overlay and it was previewed. Then I opened Capture settings and the preview image got stuck... So I closed, reopen VirtualDub -> no more preview.
So I changed "Display with Filters" and got a (distorted) preview, but it worked... also only for a moment. Next day, now every preview not show an image :(
So I deleted the VirtualDub regedit settings to start from beginning, but no chance, I don't get a preview.

The only way to get a preview is, when I open the Cropping dialog.
So I wanted to cheat VirtualDub and start a recording during Cropping dialog is open. Of course, it doesn't work. It also not work to open Cropping dialog when it is in capture mode.
Even open a second VirtualDub instance not work, because the USB grabber is taken of the first VirtualDub...

Any idea how I get the preview back and what made the preview vanish. Many thank you for the idea.

The Device itself is Dazzle DVC100 Video Device (DirectShow)

Capturing the videosource just works, but without the preview I can't see if there is content.

[shekh]

Morku, do you see anything in the log (Capture->Log)? What is capture format?
It is interesting that crop dialog can show preview. Maybe because it does not use audio. Try to disable it (previewing audio).

[Morku]

Yes, there is an error:
[i] CapDShow: loading video filter state: (error code: 800704df,
ERROR_ALREADY_INITIALIZED)

[i] CapDShow: loading audio filter state: (error code: 800704df,
ERROR_ALREADY_INITIALIZED)

[i] Connected to capture device: Dazzle DVC100 Video Device (DirectShow)

Audio preview is not enabled, only that audio capture is enabled and to show Volume meter.
I switched the Audio device and for now, I have a preview with "Display with Filters". I reopen VDub, but with Audio "0 Line (DVC100)".
Still, I can't say if there is a relation to the audio setting.
Overlay preview still not work at all, no matter which audiosetting I pick (or disable).

[richardpl]

Thank-you Shekh.



FWIW - Here's the Checker-444 clip and an FFMPEG DNxHR_444 (10bit) transcode loaded into VDub2 and examined on Color Tools 1.4 videoscopes:

http://i.imgur.com/ucqNVXJm.png (https://imgur.com/ucqNVXJ)

Same pattern as seen on the Resolve scopes.

What's point in using different scopes? Avid encodes behaves in similar way.

I could show you ffmpeg scopes, but that would be totally pointless.

[shekh]

Yes, there is an error:
[i] CapDShow: loading video filter state: (error code: 800704df,
ERROR_ALREADY_INITIALIZED)

[i] CapDShow: loading audio filter state: (error code: 800704df,
ERROR_ALREADY_INITIALIZED)

[i] Connected to capture device: Dazzle DVC100 Video Device (DirectShow)


Unfortunately these are not real errors. It means part of settings are not restored but this is irrelevant to the preview problem.
Also there is nothing special in the cropping dialog. I'm suspecting everything actually works but the window which should hold preview somehow disappeared. Can you see any preview with different device (usb camera?), or video file (emulation), or UScreenCapture?

Edit: I misunderstood, do you now have stable preview using mode "display with filters"? Overlay mechanism is a bit vague to me, I consider it may work or not depending on some driver/system weirdness.

[WorBry]

What's point in using different scopes? Avid encodes behaves in similar way.


Purely as further validation that the issue is not with Resolve's decoder/scopes. Plus this is VirtualDub2 thread.

Since ffmpeg/avid/resolve all look bad in resolve, it might be as simple as a bad decoder version in resolve


Anything useful to add yourself ?

[poisondeathray]

Anything useful to add yourself ?

No, just the Adobe tests - confirmed it's the same for DNxHD/DNxHR encode /decode

If richardpl's comment "Avid encodes behaves in similar way" means avid encode and re-import behaves the same way, that pretty much means that's how it is - since it's avid's own official encoder and decoder.



Rant: Historically, it's the worst (near lossless) intermediate ever. Enormous issues and inconsistencies with levels across applications - all over the place. You almost needed to use Avid MC to ensure consistency . Performance isn't even that great decoding wise (FPS), and quality wise it's almost always lower in all tests , PSNR, SSIM or eyeball. This noise on the pattern test doesn't help either

[WorBry]

Anything useful to add yourself ?

I was responding to richardpl there.


If richardpl's comment "Avid encodes behaves in similar way" means avid encode and re-import behaves the same way, that pretty much means that's how it is - since it's avid's own official encoder and decoder.


I wasn't sure what he meant there. Anyway I went ahead and re-installed Media Composer to clear that one up. Still can't figure if/how it's possible to export DNxHR_444 from a 1080p project, but the re-imported DNxHD_444 export of the Checkers-444 clip shows the same 'degraded' pattern on the Media Composer scopes.

Do I need to post some scope images or would that be "pointless" ?


Rant: Historically, it's the worst (near lossless) intermediate ever. Enormous issues and inconsistencies with levels across applications - all over the place. You almost needed to use Avid MC to ensure consistency . Performance isn't even that great decoding wise (FPS), and quality wise it's almost always lower in all tests , PSNR, SSIM or eyeball. This noise on the pattern test doesn't help either

I'd read (same reference that mentioned the intentional 'blur') that DNxHR_444 was designed to be 'visually' (assumed psychovisually) lossless, whereas ProRes_444 tries to get closer to 'mathematically' lossless. But I've seen a number of anecdotal reports complaining about block artifacts especially.

Pity as its really the only 444 export option in Resolve on Windows. Cineform RGB 12bit exports at Filmscan 1/2 quality are too large for my purposes.

[poisondeathray]

I wasn't sure what he meant there. Anyway I went ahead and re-installed Media Composer to clear that one up. Still can't figure if/how it's possible to export DNxHR_444 from a 1080p project, but the re-imported DNxHD_444 export of the Checkers-444 clip shows the same 'degraded' pattern on the Media Composer scopes.

Do I need to post some scope images or would that be "pointless' ?

Personally I think it's pointless . That's confirmation enough for me

[Morku]

@shekh
I tried my Logitech 9000 Pro. Shown as "Logitech QuickCam Pro 9000 (DirectShow)".
It is the same thing. Overlay not show anything. Display with Filters may work, but in a strange way (but always when I start capturing, the Preview is in that mode fine).

Device Screen capture works without issue. I always get a preview (Overlay, Preview and Display with Filters).

Than there is Microsoft WDM Image Capture (Win32) (VFW) -> it also always work (Overlay is greyed out, no problems with Preview and Display with Filters). This mode anyway is shaky and also the recordings aren't correct.

So the only relation I see between my Webcam and USB grabber is DirectShow. Anything I could try here?

[shekh]

Display with Filters may work, but in a strange way

And when you open cropping dialog, it is normal (not strange)? Btw how it is in strange way, may a screenshot show this?
I also received a somehow related ticket https://sourceforge.net/p/vdfiltermod/tickets/186/
Do you have Nvidia drivers?

[wonkey_monkey]

When directly opening an MKV (H.264/AVC) what does [+] mean when shown as the frame type (instead of [I], [B], [K], [P], etc)? Does it indicate a problem reading the file?

(also what's the difference between [I] and [K]?)

[shekh]

When directly opening an MKV (H.264/AVC) what does [+] mean when shown as the frame type (instead of [I], [B], [K], [P], etc)? Does it indicate a problem reading the file?

(also what's the difference between [I] and [K]?)

[+] is a "no frame", frame is expected at this place, but when actually decoding ffmpeg does not report matching timestamp.
some possible reasons:
wrong framerate - you would see + at repeating intervals
or variable framerate,
wrong duration,
also possible corrupt file

If you think it is wrong maybe I need to look at sample.

[I] is frame type as reported by ffmpeg, [K] is frame which I assume is keyframe (IDR) because it is marked as key in the index table.
However I noticed weirdness about it. index in ffmpeg is in damn dts units/order which is slightly off real frames even in best case.

[WorBry]

@ poisondeathray

@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


Just as a post script. I've been doing just that with the 'Checkers-422' clip in AVISynth+ - converting to 10bit YUV444 and back to 10bit YUV422 using different chroma-sampler combinations and then (via p210 output) encoding to v210 in VDub2. Based on the pattern of results seen on the Resolve scopes and comparative quality metrics (SSIM and PSNR) I'm convinced that Resolve applies Bilinear chroma up-sampling and down-sampling when v210 is 'pass-through' exported to v210. Any other 'chroma-sampler' combination would produce measurably different results.

There I'm done. Sorry to interrupt more important VDub2 business.

[wonkey_monkey]

[+] is a "no frame", frame is expected at this place, but when actually decoding ffmpeg does not report matching timestamp.
some possible reasons:
wrong framerate - you would see + at repeating intervals
or variable framerate,
wrong duration,
also possible corrupt file

If you think it is wrong maybe I need to look at sample.


It's a DVB-S recording from BBC One HD, remuxed using MakeMKV because FFMPEG has major problems with it in its raw state, and it only shows [+] when it gets to the end credits, which are interlaced (the rest of it is progressive, or progressive-in-interlaced or however it's done).

DGIndexNV/dgsource has no such trouble.

Here's a sample, including the final (progressive) scene which plays back fine. The sample is a Trimmed TS output from DGIndexNV, rather than the full remuxed file I mentioned above:

http://horman.net/credits.ts

VLC and MPC-HC both have the same problem, causing stuttering. Windows Media Player is okay. I'm guessing it's purely an FFMPEG problem.

[shekh]

I did not study ts internals. It appears this format typically needs full parsing to understand frames timing (which I assume is what DGIndex is doing).
Also the magic of switching progressive and interlacing.. ffmpeg provides some info when decoding but I'm not sure what could I do with it.