I suspect there is hardware limit of capture card. It could be like this:
just preview: it is 8-bit for display, enough power
no preview capture 10-bit: can handle 54 fps
capture 10-bit+preview: it has some extra processing so dropping to 46
Time to read the manual/specs? 🙂
Manual and specs aren't of much help, at least for me. Only thing it says about performance is this
"Support for capture frame rates up to 144fps (Actual capture frame rate can be limited by PCIe bandwidth & image resolution)".
So if we're only going off that, it has to be the PCIe bandwidth limit. Because the capture of 2160p60 does work on 8bit. I'm terrible at math, only thing i know is that it is a gen2 4x card. gen2 has 500MB/s per lane, so 2GB/s total. I'm pretty sure it's not getting to that at 2160p60 4:2:2 10bit. But i'm sure there is a way of calculating it exactly.
I am REALLY interested now to see what it does on 10bit 4:2:0 though. If only there was a codec that could do that 😛
Which card btw? Specs are important.
2160p 4:2:2 at 8-bit is: 3840*2160*2*60 bytes/sec = 1 GB/sec roughly.
What does Magewell recommend for 10-bit capture?
The card i use is the pro capture hdmi 4k plus LT. I have done a lot of searching on it but there's very little info on any 10 bit capture in general. Let alone recommendations on the systems they run in. Nothing about it on the magewell site that i could see.
Just to complete the topic, i thought i'd mention this.
I opened a ticket with magewell to ask them about it. As expected they completely ignored my questions and just said that i have to "utilize Magewell SDK if you are a developer". So that's the end of this i suppose.
Now the best i can hope for is that you add 10bit 4:2:0 and that makes it work at 60fps. Or an actual miracle happens and someone somewhere builds a recording app with the SDK that does everything i want.
Anyway, my thanks to the both of you for the help and suggestions.
If someone sends me a sample capture card, I promise to look at the SDK thing 🙂
Hah! I would, but i need my current card and don't have the money for another. All i can promise is that i would help you test it :P.
I did find a codec which does YUV 4:2:0 10bit however, UT Video. With the overlay disabled it captures at 2160p60 (well 59,94, is what the card runs at) without a problem. The problem with it, is that i can't edit and encode it. MPC-HC wont play it, premiere shows no video and avisynth can't open it.
So adding the 4:2:0 10 bit to MagicYUV would solve my problem(s) :D.
OK, I'll add it then 🙂 I'll make a preview release and share it privately, so you can test first.
Also, what I think might be happening with 10-bit 4:2:2 is that perhaps the card driver is doing some conversion there which slows it down. The official docs only mention this ( https://www.magewell.com/tech-specs/pro-capture-hdmi-4k-plus-lt ):
Support for 4:4:4 10-bit capture formats: V410, Y410
It doesn't mention 4:2:2 or 4:2:0 10-bit at all.
So in the meantime, what happens if you capture at 10-bit 4:4:4 using v410?
EDIT: Btw, I saw you're still using version 2.1.0 of the codec. 2.2.0 has been out for awhile and it has Adobe plugins too.
Thank you for adding it, can't wait! 😀
About the conversion, i did notice that on the page and figured it was something they added later. Tried 4:4:4 10bit v410. Getting the same numbers as 4:2:2. So ~46fps with overlay, ~54fps without.
Been thinking and wondering something. Is it possible to also add the rec. 2020 color space? It's more colors, and more is always better, so they say. Don't know how much work this is but it would be really nice to have.
The codec doesn't really care much about color spaces, especially for 10-bit+ formats. The only case where color space matters from the codec's point of view is when it does YUV <--> RGB conversion.
With 8-bit, there are a couple of assumptions that are being made. First is that all 8-bit RGB formats are assumed to be sRGB color space with gamma correction. For 8-bit YUV, it can either be Rec.709 or Rec.601, which is either specified during encoding explicitly using the codec encode settings, or comes stored with the encoded data during decoding. Again, it only matters when YUV-RGB conversion is being made.
For 10-bit+ formats, no such assumptions are made.
In general, the codec simply compresses numbers and gives back the same numbers (except when doing YUV-RGB conversion). The interpretation of those numbers (ie. the color space) is up to the user/application. For 10-bit+ formats, the codec does no YUV-RGB conversion at all, on purpose. This sidesteps the color space issue entirely. So if you feed the codec YUV 4:2:2 10-bit data (P210 for example), it is up to you to be sure about what color space the data is in, the codec doesn't make any use of color space there. It compresses numbers and gives back the same numbers.
So in fact if your input data is in Rec.2020, it'll just work as-is, the only thing you have to make sure is that when you import the encoded video to an editing application, you must tell the app explicitly how to interpret the footage, namely Rec.2020 in this case.
Perhaps the only caveat here is the Adobe plugin. During decoding through the Adobe plugin, the codec does tell Adobe whether YUV is 601 or 709, even for 10-bit YUV, but those are the only two options there (that's just how Adobe presents it's internal pixel formats). And I'm not even sure how or whether if you can specify manually to Adobe how to interpret the footage.
I know this all sounds very confusing, and unfortunately it is, and the main reason why, is that communicating color space information is impossible through standard codec interfaces (like VFW), and even in the case of app-specific plugins, it's also sometimes unclear how to do it right.
In any case, 10-bit+ is hard to get right, especially because of the color spaces, and you have to actually plan your workflow ahead and be sure about the formats and how apps handle them. So if you have a concrete workflow or use-case in mind, we can walk through it whether it makes sense or not.
Whether having "more colors" is better or not depends on on what display and how you view it also.
I hope that makes some sense 🙂
Seems pretty clear. I guess it's just a little confusing to see the color space as rec. 709 when you choose 10bit, and still be able to change it. For me that indicates that it matters what you choose there, from there knowing there's a color space above that, just makes you want to be able to choose it.
I fed the codec rec.2020 data and encoded it with hdr, it came out just as i expected, all good. So it seems to be working as its supposed to.
anyway, thanks for clearing it up!
Just want to second adding P010 support as it's the only 10-bit format supported by the AVerMedia Live Gamer 4K and the Elgato 4K60 Pro. Besides, your archnemesis Ut Video added P010 in 21.1.0 😋
I’m also having a lot of difficulty capturing 2160p60 video with VD2 and MagicYUV. I have to use Ut Video with FFmpeg for lossless capture. My CPU is a 2700X. A “how to capture with VD2 and MagicYUV” tutorial would be much appreciated.
Regarding Rec.2020: Yes, it is a bit unfortunate how it works now. Adding Rec.2020 could also increase confusion btw, since it might give the false impression that it'll be Rec.2020 just be setting that option. So there are no easy answers here. I'll think about what to do here.
@trevor Suggestion noted. P010 support and 10-bit YUV 4:2:0 is already done, I'm just pondering about releasing it together with the Vegas plugin, as that is also basically ready.
Still eagerly awaiting the update, any idea when i can start making some glorious 2160p60 10bit video's? Don't want to rush you but please say soon 😋
