VirtualDub2

[Groucho2004]

Groucho, "Breakpoint", does that suggest some kind of debug version LSMash ? (EDIT: or even Avisynth)No idea, sorry. I'm rather sure that it's not Avisynth.

[LigH]

GillesH:

FFMS2 and L-SMASH Works do the same for AviSynth as the FFmpeg input plugin does for VirtualDub: Using the core of FFmpeg to read media files and provide their content to the plugin's host system.

Building a keyframe index is nothing bad: It happens only once, and it adds another layer of reliability for the case that frames from the source clip are requested in a random order, instead of sequentially; sometimes the internal keyframe index in a container may even be damaged, and a source plugin relying on them would fail. The plugins do that additional indexing for your convenience. And L-SMASH Works offers two different technologies: LwLibav*Source uses an additional index (but supports a lot of containers, even those which do not have an internal index at all), and LSMASH*Source relies on an internal index inside the clip (but supports only a few containers).

[GillesH]

For LSMASHSource.dll, I use a modified version modified on 9/1/2016. File Size: 9.19 MB
There is no version number indicated.
For Avisynth, I use 2.6 MT and I am of the same opinion as Groucho. It's not Avisynth.

But it does not matter, I will continue with FFMS2 or FFMS2000 that manage to decode this MOV Clip.

Thank you for your help.

[LigH]

There have been several attempts recently to update both plugins to a newer FFmpeg core, and with better support for AviSynth+ and modern color spaces. You may try l33tmeatwad's test release with SWResample patch (https://github.com/l33tmeatwad/L-SMASH-Works/releases) as one of the latest binaries, you may not use any resampler, but the splitters and decoders should be the most recent available.

[shekh]

Thank you for your ideas. It's very nice!
I knew these possibilities.

With LSMASHVideoSource, I have a Avisynth crash: "Avisynth: breakpoint at 0x005D0E80"
This is probably related to the type of Apple Codec.

But I find it a pity not to use techniques that are always updated, like FFMPEG.
And since VirtualDub2 uses this technique, why not use it for AVS scripts.
When you open a Clip MP4 or MOV/Apple with VirtualDub2, there is no indexing, it's OK and it's fast.
Why not use these plugins for an AVS script ? Especially the avlib-1.vdplugin which must manage the MOV Apple.

I test again FFMS2 WITHOUT indexing. But I have not done all the tests yet. FFMS2 is probably the closest to the FFMPEG decoders.

Thanks again for your advice. Merci.

Without more context, "breakpoint" could mean anything. Better to report this to whoever could debug LSMASHVideoSource.

I actually do not update FFMPEG too often (last time somewhere before they announced WinXP end of life).
There is no clean way to index files with ffmpeg: my plugin does some guesswork which fails here and there. FFMS2 does something similar but is backed by much more experience.
In theory is is possible to use "vd input" in avisynth for convenience, but I don't have enough time/passion to implement this.

[poisondeathray]

It probably has more to do with your source


IsTruncated : Yes


This indicates file was not complete or cut incorrectly

[Groucho2004]

I will continue with FFMS2 or FFMS2000 that manage to decode this MOV Clip.You might still want to try DSS2Mod. LAV Filters are pretty mature and you can offload decoding to the GPU.

[GillesH]

Hi Shekh,
Congratulations for this VirtualDub2.
We will calmly wait for your passion and your time to have this future "vd input".

For the moment, FFMS2 seems to be suitable. Except for slow start.

All my encouragement for VirtualDub2.

[GillesH]

Hi poisondeathray,
This clip was given to me for testing. It is possible that it has a defect.
But why VirtualDub2 or FFMS2 in an AVS script manage to open it very well.
Impossible with LSMASH.

[poisondeathray]

Hi poisondeathray,
This clip was given to me for testing. It is possible that it has a defect.
But why VirtualDub2 or FFMS2 in an AVS script manage to open it very well.
Impossible with LSMASH.

Did you examine the frames for errors ? It might have to do with error correction handling

For lsmash, you can try threads=1, seek_mode=2 and/or changing the seek threshold

seek_mode=2 is aggressive setting and will return last good frame when errors occur

[kolak]

New RAW format which could be possibly added in in Vdub2.

https://www.blackmagicdesign.com/products/blackmagicursaminipro/blackmagicraw

link to SDK at the bottom. SDK provides everything including debayering.
Can RAW pixels bee accessed through it if wanted?

Sample are also in the link. It uses .braw, but in reality it's MOV container.

[shekh]

New RAW format which could be possibly added in in Vdub2.

https://www.blackmagicdesign.com/products/blackmagicursaminipro/blackmagicraw

link to SDK at the bottom. SDK provides everything including debayering.
Can RAW pixels bee accessed through it if wanted?

Sample are also in the link. It uses .braw, but in reality it's MOV container.

Interesting. This sounds like full competitor to cineform raw but it is not even mentioned on the page.

[shekh]

> Can RAW pixels bee accessed through it if wanted?

Just looked through the sdk: it is not very verbose. From what I understood they do not wrap traditional RGGB data at all, so maybe there is no way to interface with related tools/formats.

[kolak]

It's sort of Cineform competition, but only for RAW.
It's purely RAW codec at least atm. It's also used strictly by BlackMagic. No idea if they will allow for 3rd party recorders to implement it.

They say that some partial debayering is done in camera- so this may be true that data is not anymore typical RAW.
I would like to see this "pseudo RAW" data, how it differs to "real" RAW.

Is it easy to add to Vdub2 or lots of work?

[shekh]

It looks very easy to add as decoder.
But I don't see any mention of something raw. The minimum decoding is from compressed to RGB and includes some processing which can be controlled (like applying curves, white balance etc).
The mention of partial debayering is quite vague. Just a guess: it means it is actually demosaiced to planar rgb and then compressed (wavelet?), so the rawest raw you can get from it is some rgb.
This sdk is called "beta 1", quite possible things may change.

[kolak]

It's new, but won't change much.
They can't do full debayering as bitrates are to low.
All descriptions are based on RAW uncompressed as reference. This format is made to replace CinemaDNG RAW (if you know it). It's just developed, so should be decent. CPU/GPU support with CUDA, Metal and OpenCL (also all OSes).

Yes- there is processing possible and you can write simple JSON file which controls it (if you download sample you will see it). It's almost like Cinefrom active metadata, but more limited. It's possible to have different values for different timecodes with frame accuracy.

If there is no access to "RAW" data then we can't see what it exactly is, but this is not that important. If we could decode it then this would be great. They have simple player, but only for Mac atm. Other tool which supports it is Resolve.

You an read about it more here:
https://forum.blackmagicdesign.com/viewtopic.php?f=2&t=79208

It's just new RAW format for BlackMagic cameras. I will make sure BM users know Vdub2 supports it- 1st 3rd party tool :) And it will allow to create h264 preview files directly from RAW.

[StainlessS]

Mod or option request:-

Could it be possible to have "Run Video Analysis Pass" return when done, on last frame, rather than original start frame,
I always have avoided that function in VDub, as I might want to see accumulated metrics (in AVS) for final frame.

Cheers.

[shekh]

New build out.


Could it be possible to have "Run Video Analysis Pass" return when done, on last frame, rather than original start frame,
I always have avoided that function in VDub, as I might want to see accumulated metrics (in AVS) for final frame.

Cheers.

Don't know good reason to protect selected frame, so changed this permanently (no option).


A seek jump has always been 50 frames, that is Alt+Left/Right jumps 50 frames at a time. Is it possible to support different units? Eg. sometimes I want to jump 50 frames, but sometimes I want 2000 at a time...


I added new options to Preferences->Timeline
Also may be useful: in "Go to frame" dialog I can enter offsets. For example, type +5 to move 5 frames forward or -1 to move backward.

Minor bug? When reloading (with F2) an Avisynth script which is now longer than before, a white mark appears on the timeline...


fixed

I have another problem with the capture mode. My Logitech webcam has an "exposure" parameter, but it's not showing up in the "levels" window. Can you also map this parameter to the window?

I have added these parameters but it seems there is a lot of inconsistency (on drivers level?). However, since there is no harm if you don't touch the parameters, I decided to keep it.


One thing that will be nice if possible without much coding work will be to set the auto-size of panels for each one individually, for example, having the output panel maximized at his maximum display capacity while the input panel is at 25% and having this setting remembered from one session to another, saving this as a kind of template...


fixed
The first (left) pane can be set to fixed zoom, the other can still autosize. And this is saved.

[wonkey_monkey]

Excellent work, thanks shekh!

I know it's been mentioned before, but I think an option to change the background colour of the window would be really useful. I also think a borderless/centered pane option would be great - it can be really useful, and much easier on the eye, to have a large surrounding area of a solid colour, rather than have the video up against the top left corner and surrounded by a 3D border.

I made a couple of mock-ups:

https://imgur.com/a/N4BaiR9

Direct links:

1. Current (https://i.imgur.com/Wky4vWQ.png)
2. Centered, borderless (https://i.imgur.com/zLvULsP.png)
3. Centered, borderless. custom background colour (https://i.imgur.com/74RUNUD.png)

Tell me you don't find #3 just a little bit sexy...

[StainlessS]

Don't know good reason to protect selected frame, so changed this permanently (no option).
Fantastic, thanks muchley, just checked it out, works great.

Excellent work, thanks shekh!
+1 on that :)

[shekh]

3. Centered, borderless. custom background colour (https://i.imgur.com/74RUNUD.png)

Tell me you don't find #3 just a little bit sexy...

Mock looks good, I will think :)

[imhh11]

which one is better ?

MagicYUV or Cineform?

cineform compress a lot more but how is the quality compared to magicYUV and uncompressed ?

[shekh]

which one is better ?

MagicYUV or Cineform?

cineform compress a lot more but how is the quality compared to magicYUV and uncompressed ?

It seems there better places to compare codecs but at least what do you need it for in VD2?

[imhh11]

V210 capture

[LigH]

If any codec compresses "a lot better than" a lossless codec, then it is probably lossy. All lossless codecs will have a similar strength, and compared to uncompressed video with the same color space and depth, the ratio is hardly better than 1:5 in optimal cases, rather around 1:2.5 to 1:3.

The Ut Video Codec Suite is also very efficient and very versatile, supports many sample formats.

[shekh]

V210 capture

humble suggestions:
If you don't need lossless for some sensitive restoration, you can use near-lossless (cineform)

Also if you have enough cpu power, maybe you can get even better storage-quality ratio using x264-10bit (enable zerolatency)

[WorBry]

which one is better ?

MagicYUV or Cineform?

cineform compress a lot more but how is the quality compared to magicYUV and uncompressed ?

I've never used VDub(2) for capture per se, but based on my experience transcoding uncompressed 10-bit 422 sources I'm confident that Cineform at 'Film Scan 2' quality would be way, way beyond 'visually lossless' and very close to arithmetically lossless.

What are you planning to do with your captures btw? IMHO, far more important is the compatibility of the capture format with the video systems you use, or are intending to use for subsequent processing. Does the import interface preserve high-bit depth transfer, assuming said system does support high bit depth processing? How does the system handle luminance ranges on import with that particular format - very important to determine the behavior, especially if the system does not have native (SDK implementation) Cineform support ? Process performance in/through said system ? And can you export in the same format, if that is desirable - in which case similar considerations apply with respect to bit-depth transfer and luminance handling at export?

My two cents.

[imhh11]

thank you guys!!!

I don't think I see a difference in quality between the 2 codecs. Maybe when I zoom in, I can see that magicyuv is slightly better. So Cineform compression should be enough for me.

MagicYUV(766mbps) Vs Cineform(332mbps)
http://screenshotcomparison.com/comparison.php?id=116034

MagicYUV(766mbps) Vs Cineform(183mbps)
http://screenshotcomparison.com/comparison.php?id=116035

once encoded to hevc 25mbps:
http://screenshotcomparison.com/comparison.php?id=116040

[shekh]

once encoded to hevc 25mbps:
http://screenshotcomparison.com/comparison.php?id=116040

There is small color difference, probably different matrix at some step (709 vs 601). Something to be aware of.

[WorBry]

MagicYUV(766mbps) Vs Cineform(332mbps)
http://screenshotcomparison.com/comparison.php?id=116034

MagicYUV(766mbps) Vs Cineform(183mbps)
http://screenshotcomparison.com/comparison.php?id=116035


Out of interest, what Cineform quality settings did you use in the two shots ?

[imhh11]

There is small color difference, probably different matrix at some step (709 vs 601). Something to be aware of.

strange both were encoded x265 with the same setting in HDR BT2020 (DCI-P3).

after comparing with the source (untouched), the colors match magicyuv and cineform is slightly different. I wonder why, both are 422 10bit v210 capture of the same file.

Out of interest, what Cineform quality settings did you use in the two shots ?

film scan 1 & 3 but I'm not sure, I did the comparison a couple months ago and wanted the opinion of the doom9 experts :P

[imhh11]

Also, sorry if its a stupid question but could it be possible to add NVenc to Vdub ? my cpu can handle x264 encoding while capturing but at very fast or worse preset only and im mostly interested in HEVC for HDR.
of course my cpu cannot handle x265 in vdub but encoding h265 with nvidia should be fast enough ? or is it already possible and i dont know about it ?

[sneaker_ger]

You can use the "External Encoders" (see VirtualDub help) feature of VirtualDub (both vanilla as well as VirtualDub2) to use NVEnc (https://github.com/rigaya/NVEnc/releases) while doing "normal" encodes. For capturing I think there is no solution for VirtualDub, currently.

[shekh]

NVenc: there is no way for capture now, and not coming soon.

[WorBry]

...both were encoded x265 with the same setting in HDR BT2020 (DCI-P3).

Ah, OK, so these are HDR captures ? I was hesitant about mentioning your shots looked rather underexposed ;)


film scan 1 & 3 but I'm not sure.

Filmscan 3 is way overkill. It's a 'special' mode that is not available with the (GoPro) Cineform VFW codec and, to my knowledge, in other native implementations of the Cineform SDK:

https://forum.doom9.org/showpost.php?p=1826874&postcount=45

[imhh11]

Ah, OK, so these are HDR captures ? I was hesitant about mentioning your shots looked rather underexposed ;)



Filmscan 3 is way overkill. It's a 'special' mode that is not available with the (GoPro) Cineform VFW codec and, to my knowledge, in other native implementations of the Cineform SDK:

https://forum.doom9.org/showpost.php?p=1826874&postcount=45



yes HDR capture :) colors are triggered at x265 encoding. I captured a UHD-BD just to make sure I get proper colors/hdr etc.. now that I know that magicyuv works (at least when I compare 2 frames tone mapped with madvr), i can now capture my games in high-quality 4K HDR properly. Too bad cineform slightly change the colors, it would have saved tons of space(only have 1tb of capture space).

thanks for the filmscan 3 explanation, I didn't know that.

*sorry for my english

[WorBry]

yes HDR capture :) colors are triggered at x265 encoding..... Too bad cineform slightly change the colors, it would have saved tons of space(only have 1tb of capture space)

I've no experience in that domain. Maybe others can help. It's surely color matrix related.

[shekh]

I doubt it is cineform that is guilty in this case. What software was used to do the encode to x265? Because you said it is encoded with DCI-P3 I assume there was (different) color conversion. How it is possible:
1) magicyuv+avi has no metadata at all -> everything default.
2) cineform+avi has some metadata -> replaces defaults (not same).
Just guessing.

[imhh11]

ok, I did another comparison because the other one was 3 months old so maybe I did something wrong. This time, I don't see a difference in the colors, can you?

MagicYUV RAW VS Cineform RAW filmscan 2
http://screenshotcomparison.com/comparison/121674

once encoded with exactly the same setting/ software: x265 Staxrip the GUI (source is dci-p3, encode is dci-p3) :

MagicYUV VS Cineform
http://screenshotcomparison.com/comparison/121673

MagicYUV VS Source
http://screenshotcomparison.com/comparison/121672

Cineform Vs Source
http://screenshotcomparison.com/comparison/121671



x265 2.8+19-bcdc610cf5f0:[Windows][MSVC 1914][64 bit] 10bit
/ wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=3840x2160 / interlace=0 / total-frames=723 / level-idc=51 / high-tier=1 / uhd-bd=0 / ref=4 / no-allow-non-conformance / repeat-headers / annexb / aud / hrd / info / hash=0 / no-temporal-layers / no-open-gop / min-keyint=24 / keyint=240 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=25 / lookahead-slices=4 / scenecut=40 / radl=0 / no-intra-refresh / ctu=64 / min-cu-size=8 / rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=2 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=3 / limit-refs=3 / limit-modes / me=3 / subme=3 / merange=57 / temporal-mvp / weightp / no-weightb / no-analyze-src-pics / deblock=3:3 / no-sao / no-sao-non-deblock / rd=4 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=1.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=abr / bitrate=22000 / qcomp=0.70 / qpstep=4 / stats-write=0 / stats-read=2 / cplxblur=20.0 / qblur=0.5 / vbv-maxrate=160000 / vbv-bufsize=160000 / vbv-init=0.9 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=9 / transfer=16 / colormatrix=9 / chromaloc=1 / chromaloc-top=2 / chromaloc-bottom=2 / display-window=0 / master-display=G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1) / max-cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / hdr / hdr-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=5 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-mv-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei


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

[shekh]

ok
ps. I don't get it, you ask which codec, and then show test which is 3 months old. Why :)
Out of curiosity, what hw you use for capture? From which source?

[imhh11]

ok
ps. I don't get it, you ask which codec, and then show test which is 3 months old. Why :)
Out of curiosity, what hw you use for capture? From which source?

as I said, I wanted to know the opinion of the doom9 expert and i have been busy lately so i didnt really use my card since i got it 3 months ago but now im back at it... sorry for posting my first test.

I'm using a decklink black magic card and the source is a UHD-BD played with my HTPC, my uhd player or my media player, it doesn't matter. the results are all the same. this one was done with the Nvidia shield (USB).

[WorBry]

I'm using a decklink black magic card...

I see FFMPEG supports capture over BMD Decklink:

https://trac.ffmpeg.org/wiki/Capture/Blackmagic

Maybe worth looking into as an alternative if you are familiar with FFMPEG. I don't know how feasible it would be to capture and encode to x265, tone mapping included, as a single command operation. You'd have to research the subject and test.

You could certainly do it with FFMPEG as a two stage process - capturing first to a 10-bit YUV422 'near lossless' intermediate, like DNxHR HQX. But I can't see that would offer any particular advantage over your existing two step process - I'd stick with VDub2 capture to Cineform (Filmscan 2) if that works for you. Just bear in mind that the resulting bitrates (and so file sizes) of your Cineform captures will be somewhat dependent on the complexity of the video content. But the same applies to lossless formats, like MagicYUV, also.

[poisondeathray]

I think there are some issues, at least with screenshots provided in post 639 . I made sure to save them and verified them by size. I didn't look at the "RAW" versions, just the others

The biggest easy one to see is the bottom of the blue dress . Look at the texture loss at the bottom in both magicyuv and cineform compared to the source. The noise and grain pattern is smoothed over .

There are some color sampling issues too . Look at the small yellow flower spots. Some of the smaller ones almost disappear in some spots in the cineform screenshot . The source has more "orange" spots, but they become yellow and more desaturated . Even the magicyuv screenshot is affected (albeit less)

I think there is an issue with that capture setup , and or method of taking screenshots

EDIT: or did I misunderstand ? Those were re-encoded x265 screenshots ? So those were caused by x265 ? That would make more sense

[imhh11]

the smoothing on grain is definitely coming from the x265 encoder even if I used --no-soa and --no-strong-intra-smoothing
thanks for pointing out the yellow flowers, I didn't notice it. I'll have to investigate what's causing this, I don't think this is an encoding issue.

screenshots were made the same way with madvr hdr to sdr pixels shader (200nits) so this is not the issue but just to be sure, I'll try to encode the source with the same setting.
I'll also try to capture uncompressed to see if it changes anything.

[poisondeathray]

You re-encoded it to 10bit 4:2:0 right? So you would expect some color loss going from 4:2:2 to 4:2:0 , so that could be within expected limits

But then again, the original, original, was UHD BD right? UHD 4:2:0 ? So there might be a problem...

[imhh11]

yes, the source is 10bits 4:2:0, shied played it in 12bit 4:2:2, capture is 10bits 4:2:2 and encode is 10bits 4:2:0.

how come it changes only the colors of those yellow flowers and not the other colors? and how come cineform is worse?
i'll test uncompressed later today.

[poisondeathray]

yes, the source is 10bits 4:2:0, shied played it in 12bit 4:2:2, capture is 10bits 4:2:2 and encode is 10bits 4:2:0.

how come it changes only the colors of those yellow flowers and not the other colors? and how come cineform is worse?
i'll test uncompressed later today.

I don't know, but it's unexpected.

And you'd expected cineform to be very slightly worse, but there are more differences there than I would expect

[Revan654]

NVenc: there is no way for capture now, and not coming soon.

FYI, That SDK I gave you awhile back had source code showing how to add NVenc.

-----

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?

[Revan654]

I see FFMPEG supports capture over BMD Decklink:

https://trac.ffmpeg.org/wiki/Capture/Blackmagic

Maybe worth looking into as an alternative if you are familiar with FFMPEG. I don't know how feasible it would be to capture and encode to x265, tone mapping included, as a single command operation. You'd have to research the subject and test.



x265 by it self is very doable(CPU Only), I've done it on my Skylake CPU(Quad Core).

I used the following Codec, Which works in VD2(It's like the x264 Codec): https://sourceforge.net/projects/mpxplay/files/x265vfw/x265vfw_v280/

As for FFMPEG, It's kind of doable from what I understand, but you are likely to run into Framedrops due to the Tonemapping + x265 at the same time. It would be very useful to split it up the process on multiple GPU's. One GPU handles all the tonemapping and the other deals with compression. Not sure if FFMPEG support multiple process on different devices.

There are other Standalone Software that Supports Blackmagic like Adobe and Vegas. Along with there own DaVinci Resolve. If all else fails you could try those.

If External encoding is ever added to VD2 Capture mode. Allot more doors would open. You could pipe data through to other encoders.

I know it was said it was possible but, not sure if any kind of development has been done for that.

If I was familiar with C# I would help out the dev on VD2.

as I said, I wanted to know the opinion of the doom9 expert and i have been busy lately so i didnt really use my card since i got it 3 months ago but now im back at it... sorry for posting my first test.

I'm using a decklink black magic card and the source is a UHD-BD played with my HTPC, my uhd player or my media player, it doesn't matter. the results are all the same. this one was done with the Nvidia shield (USB).

Blackmagic is famous for having buggy drivers and some of there devices are at the high end when comparing them to similar products. You do get full support of all there software and 3rd Support, Which is likely why the price is much higher.

The buggy Drivers is one of the reason why I avoided them when I upgraded my Capture System. Plus at the time starting price for the card was 1500 dollars vs another company(Exactly same features) for 800 dollars.

There Win7 drivers for Intensity series is a mess.

[kolak]

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.