Just a few questions

Hi!

Well, 10-bit territory is not an easy one, there are a lot of pitfalls. A lot depends on how the host app (VirtualDub2/etc.) handles the raw pixels, sometimes the slowdown can come from there.

1080p60 should be no problem at all to compress at 10 bits. To view how the codec performs, enable logging in the global codec settings (Start menu -> MagicYUV VFW configuration), do an encoding session, then look at/send me the log files.

To better understand, what is your encode pipeline? Is it capture card, what post software, etc., all details?

Regarding 10-bit 4:2:0, there isn't any good raw pixel format that is supported by apps. 10-bit+ is hindered mostly by app-codec communication lack of support. That gets better with app specific plugins (like the Adobe plugins for example, but ones for Vegas are also being developed).

Thanks for the reply.

I realized to late i forgot to mention the resolutions. I wanted to record at 2160p60 in 10bit (4:2:2). But got to a max of 46fps at that. When i switch to 8bit YUV 4:2:0 it works fine. For now i've switched to 1440p60 in 10bit 4:2:2 and that seems to work as well.

I'm recording 1 pc with another with a capture card atm (magewell pro capture hdmi 4k plus LT), been recording some HDR content with VD2 and encoding it with a x265-10bit hdr profile i've been using for a while (using MeGUI). It's all games i'm recording, just recording the glory days before i get to old, so i can relive it a little down the road :P.

I've noticed UHD movies are all in 4:2:0 10bit, so when troubleshooting the low FPS it just made me wonder why there was no 4:2:0 option. Your explanation for it already goes over my head, so i'll believe you. But the 10bit 4:2:2 i'm recording now has to be converted to 4:2:0 anyway as my media pc gets completely destroyed trying to play the 4:2:2 version. Even my 5960x has trouble with it. over 50% cpu use the whole time. hitting 70%+ regularly, with the GPU also at 25%.

I will do the logging later today and get back to you with the log/results on that.

Well i did the logging. VD showed 46.something fps the whole time. Did only 323 frames though, log is confusing to me, you'll probably understand though. Says 202.72 fps at the bottom, so yeah that's confusing to me, but i'm guessing its not the codec then but the program, so VD2 that can't handle the data?

It's definitely not the drive its writing to, getting just under 200MB/s writes. CPU and GPU are barely being used. (both around 20% to 30%). Upload doesn't accept the logfile.. so ill guess ill just post it here then.

[2020-04-21 17:35:25] Log opened - MagicYUV lossless video codec 2.1.0 (Ultimate) (64 bit)
[2020-04-21 17:35:25] Codec variant: MagicYUV 10-bit YUV 4:2:2
[2020-04-21 17:35:25] Application: D:\Apps\VirtualDub2\VirtualDub64.exe
[2020-04-21 17:35:25] --------------------------
[2020-04-21 17:35:25] Setting codec preferences (init from global config):
[2020-04-21 17:35:25]     Encode:
[2020-04-21 17:35:25]         Auto threads:  YES
[2020-04-21 17:35:25]         Threads:       16
[2020-04-21 17:35:25]         YUV color matrix:          Rec.709
[2020-04-21 17:35:25]         Full range YUV:            NO
[2020-04-21 17:35:25]         Assume interlaced:         NO
[2020-04-21 17:35:25]         Interpolate downsampling:  YES
[2020-04-21 17:35:25]         Compression method:        Median
[2020-04-21 17:35:25]     Decode:
[2020-04-21 17:35:25]         Auto threads:  YES
[2020-04-21 17:35:25]         Threads:       16
[2020-04-21 17:35:25]         Allow YUV 4:4:4 conv. to: RGB
[2020-04-21 17:35:25]         Allow YUV 4:2:2 conv. to: RGB, YUV 4:4:4
[2020-04-21 17:35:25]         Allow YUV 4:2:0 conv. to: RGB, YUV 4:4:4, YUV 4:2:2
[2020-04-21 17:35:25]         Allow YUV 4:0:0 conv. to: RGB, YUV 4:4:4, YUV 4:2:2, YUV 4:2:0
[2020-04-21 17:35:25]         Suggest RGB first:  NO
[2020-04-21 17:35:25] --------------------------
[2020-04-21 17:35:25] --------------------------
[2020-04-21 17:35:25] Setting codec preferences (from client app state):
[2020-04-21 17:35:25]     Encode:
[2020-04-21 17:35:25]         Auto threads:  YES
[2020-04-21 17:35:25]         Threads:       16
[2020-04-21 17:35:25]         YUV color matrix:          Rec.709
[2020-04-21 17:35:25]         Full range YUV:            NO
[2020-04-21 17:35:25]         Assume interlaced:         NO
[2020-04-21 17:35:25]         Interpolate downsampling:  YES
[2020-04-21 17:35:25]         Compression method:        Median
[2020-04-21 17:35:25]     Decode:
[2020-04-21 17:35:25]         Auto threads:  YES
[2020-04-21 17:35:25]         Threads:       16
[2020-04-21 17:35:25]         Allow YUV 4:4:4 conv. to: RGB
[2020-04-21 17:35:25]         Allow YUV 4:2:2 conv. to: RGB, YUV 4:4:4
[2020-04-21 17:35:25]         Allow YUV 4:2:0 conv. to: RGB, YUV 4:4:4, YUV 4:2:2
[2020-04-21 17:35:25]         Allow YUV 4:0:0 conv. to: RGB, YUV 4:4:4, YUV 4:2:2, YUV 4:2:0
[2020-04-21 17:35:25]         Suggest RGB first:  NO
[2020-04-21 17:35:25] --------------------------
[2020-04-21 17:35:25] Compress query: RGB16 (160 x 120): NOT SUPPORTED
[2020-04-21 17:35:25] Compress query: RGB24 (160 x 120): NOT SUPPORTED
[2020-04-21 17:35:25] Compress query: RGB32 (160 x 120): NOT SUPPORTED
[2020-04-21 17:35:25] Compress query: r210 (160 x 120): NOT SUPPORTED
[2020-04-21 17:35:25] Compress query: R10k (160 x 120): NOT SUPPORTED
[2020-04-21 17:35:25] Compress query: b48r (160 x 120): NOT SUPPORTED
[2020-04-21 17:35:25] Compress query: BGR0 (160 x 120): NOT SUPPORTED
[2020-04-21 17:35:25] Compress query: b64a (160 x 120): NOT SUPPORTED
[2020-04-21 17:35:25] Compress query: BRA[64] (160 x 120): NOT SUPPORTED
[2020-04-21 17:35:25] Compress query: YV12 (160 x 120): NOT SUPPORTED
[2020-04-21 17:35:25] Compress query: YV16 (160 x 120): NOT SUPPORTED
[2020-04-21 17:35:25] Compress query: YUY2 (160 x 120): NOT SUPPORTED
[2020-04-21 17:35:25] Compress query: HDYC (160 x 120): NOT SUPPORTED
[2020-04-21 17:35:25] Compress query: YV24 (160 x 120): NOT SUPPORTED
[2020-04-21 17:35:25] Compress query: v308 (160 x 120): NOT SUPPORTED
[2020-04-21 17:35:25] Compress query: P010 (160 x 120): NOT SUPPORTED
[2020-04-21 17:35:25] Compress query: P016 (160 x 120): NOT SUPPORTED
[2020-04-21 17:35:25] Compress query: v210 (160 x 120): OK
[2020-04-21 17:35:25] Compress query: RGB16 (160 x 120): NOT SUPPORTED
[2020-04-21 17:35:25] Compress query: RGB24 (160 x 120): NOT SUPPORTED
[2020-04-21 17:35:25] Compress query: RGB32 (160 x 120): NOT SUPPORTED
[2020-04-21 17:35:25] Compress query: r210 (160 x 120): NOT SUPPORTED
[2020-04-21 17:35:25] Compress query: R10k (160 x 120): NOT SUPPORTED
[2020-04-21 17:35:25] Compress query: b48r (160 x 120): NOT SUPPORTED
[2020-04-21 17:35:25] Compress query: BGR0 (160 x 120): NOT SUPPORTED
[2020-04-21 17:35:25] Compress query: b64a (160 x 120): NOT SUPPORTED
[2020-04-21 17:35:25] Compress query: BRA[64] (160 x 120): NOT SUPPORTED
[2020-04-21 17:35:25] Compress query: YV12 (160 x 120): NOT SUPPORTED
[2020-04-21 17:35:25] Compress query: YV16 (160 x 120): NOT SUPPORTED
[2020-04-21 17:35:25] Compress query: YUY2 (160 x 120): NOT SUPPORTED
[2020-04-21 17:35:25] Compress query: HDYC (160 x 120): NOT SUPPORTED
[2020-04-21 17:35:25] Compress query: YV24 (160 x 120): NOT SUPPORTED
[2020-04-21 17:35:25] Compress query: v308 (160 x 120): NOT SUPPORTED
[2020-04-21 17:35:25] Compress query: P010 (160 x 120): NOT SUPPORTED
[2020-04-21 17:35:25] Compress query: P016 (160 x 120): NOT SUPPORTED
[2020-04-21 17:35:25] Compress query: v210 (160 x 120): OK
[2020-04-21 17:35:25] Compress query: P210 (160 x 120): OK
[2020-04-21 17:35:25] Compress query: P216 (160 x 120): NOT SUPPORTED
[2020-04-21 17:35:25] Compress query: v410 (160 x 120): NOT SUPPORTED
[2020-04-21 17:35:25] Compress query: Y410 (160 x 120): NOT SUPPORTED
[2020-04-21 17:35:25] Compress query: Y416 (160 x 120): NOT SUPPORTED
[2020-04-21 17:35:25] Compress query: v210 (168 x 120): OK
[2020-04-21 17:35:25] Compress query: v210 (164 x 120): OK
[2020-04-21 17:35:25] Compress query: v210 (162 x 120): OK
[2020-04-21 17:35:25] Compress query: v210 (161 x 120): NOT SUPPORTED
[2020-04-21 17:35:25] Compress query: v210 (164 x 120): OK
[2020-04-21 17:35:25] Compress query: v210 (160 x 128): OK
[2020-04-21 17:35:25] Compress query: v210 (160 x 124): OK
[2020-04-21 17:35:25] Compress query: v210 (160 x 122): OK
[2020-04-21 17:35:25] Compress query: v210 (160 x 121): OK
[2020-04-21 17:35:25] Compress query: v210 (160 x 122): OK
[2020-04-21 17:35:25] Compress query: P210 (320 x 240): OK
[2020-04-21 17:36:13] Compress query: P210 (3840 x 2160): OK
[2020-04-21 17:36:13] Compress get format size: P210 (3840 x 2160): 72
[2020-04-21 17:36:13] Compress get format: P210 (3840 x 2160): M0Y2 [YUV 4:2:2 10-bit (Rec.709) (limited)] (3840 x 2160)
[2020-04-21 17:36:13] --------------------------
[2020-04-21 17:36:13] Compress begin:
[2020-04-21 17:36:13]     Threads:            16
[2020-04-21 17:36:13]     Input format:       P210
[2020-04-21 17:36:13]     Compressed format:  YUV 4:2:2 10-bit (Rec.709) (limited)
[2020-04-21 17:36:13]     Resolution:         3840 x 2160
[2020-04-21 17:36:13]     Interlaced:         NO
[2020-04-21 17:36:21] Compress end:
[2020-04-21 17:36:21]     Compressed:         323 frames
[2020-04-21 17:36:21]     Raw data (input):   10716364800 bytes (10219.92 MBytes)
[2020-04-21 17:36:21]     Compressed data:    1328029064 bytes (1266.51 MBytes)
[2020-04-21 17:36:21]     Compression ratio:  8.07
[2020-04-21 17:36:21]     Encode-only time:   00:00:01.593
[2020-04-21 17:36:21]     Encode speed (avg): 4.93 ms/frame (202.72 fps, 1681.47 MPix/sec)

10-bit YUV 4:2:0 could be a worthwhile addition, I'll look into it.

Yes, as you can see from the log the codec spends 5 ms on average compressing a frame (200 fps). If VD2 reports 46 fps, that means altogether 1000/46 = 21.7 ms is spent on each frame, of which 5 ms is the codec, the rest 16.7 ms is something else combined.

CPU usage can be misleading, as you have a 16 thread CPU but if something is processing only on a single thread somewhere in the encode pipeline, then that can become a bottleneck, and CPU usage will show low utilization. For example, if VD2 or something is doing conversion of the pixel data on a single thread. I'm not even sure that VD can grab true 10-bit from the Magewell card. It's very well possible that it's getting 8-bit data and then doing useless conversion to P210 (a variant of 10-bit YUV 4:2:2 pixel packing), but this would have to be verified somehow.

Do you know of any software that does grab the true 10-bit? I did some searching and found at least 1 youtube video that uses VD2 as well for 10bit capture. So there's at least more people who believe it does haha.

Really curious to know how other people capture 2160p60 10bit 4:2:2, i'm guessing its not many people. Good to know it's not the codec though, now just need the app that can handle it.

Tried the magewell premiere plugin as well. That doesn't give you much in terms of settings, certainly not video formats. It captures in 8bit and can't even select a codec. So that's not it. Same for vMix.

If you could add the 10bit 4:2:0 that would certainly give it less data to process so that might make it doable.

VD2 in theory should work. Though I'm pretty sure it uses the Magewell DirectShow filter, so it depends whether that can give 10-bit.

Other than that another option would be to write a capture software using the magewell SDK. I thought about it some time ago, but never got around to actually create anything.

Where can you select 10-bit as capture format btw in VD2?

Also, I can ask Anton about it (he is the dev of VD2) I used to talk with him a while back, maybe he can tell how to know for sure what capture format is grabbed, etc.

Got an answer from the VD2 dev, I'll post it below:

To see the actual format use Video->Set custom format (current format is selected). Other formats listed there are r210, R10k, v210, P210, P010, v410, Y410, Y416.

If I remember correctly all of these were tested by one Magewell user. However, the driver will probably not allow changing configuration from this menu. He needs to check driver specific dialogs:

Video->Capture filter

Video->Capture pin

or maybe even specific setup tool from the Windows control panel.

 

Another place to see the pixel format is Video->Compression dialog ("source" is the pixel format coming from the card/DirectShow).

Yeah, i set those already. Your codec doesn't accept anything but v210 and P210 for 10bit 4:2:2 so i had to set all that up properly before it would work.

So, good to know that VD2 is set up properly, if only it would reach the framerate i wanted :(.

Posted by: @ignus

Another place to see the pixel format is Video->Compression dialog ("source" is the pixel format coming from the card/DirectShow).

Regarding the above, what do you see as the "source" there?

I see exactly what i set in the capture pin screen. P210. So it's all as it's supposed to be. If i change it in the capture pin, the source changes as well.

Hi, please run capture test and open the "Capture->Real-time profiler", then share some screenshots.

This will hopefully help me improve it a little bit.

hi, i'll make all the screenshots you need, but the real-time profiler screen makes even less sense to me then the encoding log, so you'll have to tell me what you need to see, there's a lot of info on this. Made one anyway, maybe(hopefully) it's just what you need.

Good. Main stats are on the left. Major CPU consumers are

V-Compress ~5ms (this includes MagicYuv compression)

V-BlitOut ~8ms (this is not optimal and can be saved)

However, basically 5+8<16 and in theory it should work for 60fps. So there is something else that I can't see. Maybe there is performance limit in the capture card.

V-In (loop) measures actual frequency of incoming frames, 1000/21.4 = ~46fps

Please do another test:

disable video compression

disable audio capture

disable video display

run capture test and make another screenshot like that.

If it does not help to get better performance, try to experiment with different pixel formats from the capture card (just a guess).

Well there is improvement, i disabled all 3 and made the screenshot attached, hitting 54fps now. After i changed the compression back to 10bit 4:2:2. The framerate didn't change, neither did it after turning audio capture back on. But it dropped back to 46 after enabling the overlay.

I think i should mention again that when just displaying the input it shows a constant 60fps in the bottom right. Don't really know if its relevant though. I thought the capture card had nothing to do with the actual compression/saving of the video. Is that wrong? Does this mean the card can't do 2160p60 @ 4:2:2? I'm getting more confused by the minute haha.