VirtualDub2 lossless FFV1 HDMI captures, no RGB option?

DragonQuarter · #1 05-23-2021, 07:58 PM

Hello!

I'm looking to capture lossless RGB video from an HDMI source (and potentially analog sources in the future), specifically for various game consoles. I was following this RetroRGB guide for lossless game captures using the FFV1 codec and they had recommended VirtualDub2 over AmarecTV, the latter of which I had be using until now.

With VirtualDub2 however, I'm not seeing a "RGB24" or "RGB32" selection in the Capture pin "Color space" section. Instead, it's BGR and BGR32. I've been told these are not exactly the same, and I'm not sure why only these options pop up for Color space since my Magewell HDMI Pro Capture card is cable of RGB.

The short of it is...should I be worried about selecting BGR or BGR32 if I'm really intending to do RGB24 or RGB32? Not sure why the RetroRGB guide shows RGB as an available color space, but it doesn't show it for me.

VirtualDub2 WTF.jpg

latreche34 · #2 05-23-2021, 09:35 PM

You should capture YUV2 not RGB for video tapes.

lordsmurf · #3 05-24-2021, 08:53 AM

Don't use FFV1. It's a lousy capture codec, lots of overhead, causes dropped frames, problems. Use Huffyuv, or at worst Lagarith.

Analog video is YUV, not RGB.

Magewell has problems with SD footage, infamous for it. You'll have problems, often black frames, or duplicate frames -- and VirtualDub/2 won't report the drops/inserts because those are happening in-card without reporting. Not good.

HDMI capturing suggested 1080p resolution, possibly NOT suggested. Never for videotapes, but video games has factors. 640x480 wouldn't be HDMI.

The game is not 60 fps, but 59.94i (not the same)

This capture setup is a mess right now.

That RetroRGB guide sounds like it was written by somebody clueless, if you've been instructed to use the above settings. I'd have to read it to verify my gut feeling here.

traal · #4 05-24-2021, 10:04 AM

I use VirtualDub (not VirtualDub2), and I installed the ffdshow encoder pack to give me ffv1.

Then in VirtualDub's capture mode, I go to Video > Compression, select 'ffdshow Video Codec' and click Configure. Then when I choose the 'FFV1' encoder, it gives me the following list of colorspaces:

ffdshow-ffv1-colorspace.png

NJRoadfan · #5 05-24-2021, 10:10 AM

For game consoles and computer sources I have been using the UT-Video RGB (ULRG) codec. These sources are native 4:4:4 RGB, not YUV. My capture card natively does 4:4:4 RGB from DVI/HDMI sources that support such. Frame rate is going to vary by console, arcade PCB, or computer source and needs to be set appropriately.

hodgey · #6 05-24-2021, 11:26 AM

BGR and BGR32 would be rgb but ordered differently, the bit depth should be the same otherwise though, so maybe that's the correct option. (the 32 variants include an alpha channel)

Quote:

Originally Posted by lordsmurf

HDMI capturing suggested 1080p resolution, possibly NOT suggested. Never for videotapes, but video games has factors. 640x480 wouldn't be HDMI.
...
The game is not 60 fps, but 59.94i (not the same)
...
That RetroRGB guide sounds like it was written by somebody clueless, if you've been instructed to use the above settings. I'd have to read it to verify my gut feeling here.

HDMI can carry pretty much any resolution, if one is dealing with a RGB/VGA source from a game console or computer, NTSC or PAL SD resolution may not be what it's outputting.

Frame may also not be 59.94i in all cases, especially with RGB (but it's possible it could be different even with composite/s-video, game consoles and 8-bit computers often did a bunch of no-quite-standards stuff and tricks with video output to save costs). One would really have to check resolution and bit depth depending on what system one is capturing from.

The guide is for capturing game consoles, not videotapes, so the settings will be quite different. For composite/S-Video signal one of course want to capture in original interlaced SD resolution and correct frame rate.

A RGB signal will also have a lot of correlation/little variation between frames and lines, so codec differences may be more noticeable than with say noisy vhs output. May be worth trying UTVideo T2 as it can do some temporal compression.

lordsmurf · #7 05-24-2021, 11:57 AM

Raw framerate of console is variable, true. But 59.94i was the target, 59.94p is the modern target. (Or 50i/50p)

Though HDMI can be many resolutions, it often is not. It depends on factors, mostly the devices. It's generally safe to assume 720p/1080p only unless proven otherwise. I've always hated narrow uses of specs.

DragonQuarter · #8 05-24-2021, 12:24 PM

Thanks everyone for the messages. The guide I'm following is right here: https://www.retrorgb.com/vdub2capture.html

I was hoping to check my current FFV1 captures against my Magewell card's direct feed by comparing screenshots of the two, but unfortunately it doesn't look like Magewell's Capture Express software shows the direct uncompressed feed when I take a PNG image. Perhaps I should try BMP instead.

I should've shared my exact setup right now, but currently I am capturing from an Analogue Super Nt, which is a HDMI SNES console. I haven't tried any analog consoles yet but if I was, I'd be using an OSSC (Open Source Scan Converter) which line-doubles analog sources and passes them through HDMI.

Current settings are as follows:

*Analogue Super Nt console, set at 720p60
*Magewell HDMI Pro Capture Card
*Magewell Device Settings:
Input: Color Format: RGB
Quantization: Full Range (0-255)

*VirtualDub2
Color Space: BGRX 32Bits (since XRGB 32 is not showing)
Image Size: 1280x720
Frame Rate: 60 FPS
Compression: FFV1 lossless codec, 8-bit depth, RGB

The result is a pretty nice, high-quality video with a big file size, but I still need to see if there's a way to compare it to the default capture window. I also noticed however that my Adobe Premiere Pro only fetches the audio of the AVI file that's recorded, so I may attempt the other codecs you all recommended (UTVideo T2, HuffyUV, or Lagarith).

I'll also give VDub1 a try and see if I get better mileage out of that.

Some additional context for why I pick 720p: SNES game resolution is 240p, and 720p is a 3X scale of that. I'm trying this crazy experiment where I scale 720p to 4K using Virtual Dub Nearest Neighbor resizing, per RetroRGB's above guide. Wanted to see it for myself!

lordsmurf · #9 05-24-2021, 12:49 PM

That guide author acknowledges some of the issues I see, including wrong frame rate. So I won't fault him too much, but it really should result in updates to the guide and not mere notes. 60fps is definitely wrong.

I remember seeing the Analogue Super Nt. Was it ever on Kickstarter?

DragonQuarter · #10 05-24-2021, 01:03 PM

Quote:

Originally Posted by lordsmurf

That guide author acknowledges some of the issues I see, including wrong frame rate. So I won't fault him too much, but it really should result in updates to the guide and not mere notes. 60fps is definitely wrong.

I remember seeing the Analogue Super Nt. Was it ever on Kickstarter?

Yeah I should change it to 59.94fps in that case..but out of complete curiosity, what's the issue with selecting 60 in this case?

Yes, the Analogue Super Nt was a Kickstarter thing but now it's sold commercially (but very limited unfortunately): https://www.analogue.co/super-nt

NJRoadfan · #11 05-24-2021, 03:29 PM

The Super NES doesn't natively output frames at 59.94fps, but at 60.01fps. I don't know if the Magewell cards detect the proper frame rate from signal alone, I know my Epiphan DVI2PCIe card will pick up the frame rate from the video source and set capture to that.

lordsmurf · #12 05-24-2021, 05:02 PM

I was apparently tired (and grumpy) this morning, before a nice nap.

For some reason, I was thinking of TV incoming psuedo-requirement of 59.94i, and forgetting the console could do whatever seemingly-dumb thing it wanted. Framerates for consoles were never precise, and SNES is faster than 60. So while I was wrong about 59.94, I was still right that 60fps wasn't correct.

When you get a framerate wrong, it can lead to dropped frames and audio sync errors. It's not much different than dropped frames alone. Interlacing can also get screwed up. (I've not tried to capture game console in many years now. I don't even remember if the output from the console is interlaced or progressive.)

Here's a good chart of framerates: http://tasvideos.org/PlatformFramerates.html

DragonQuarter · #13 05-24-2021, 07:01 PM

Thanks for the additional insight! So the Analogue Super Nt has settings to account for the SNES's weirdo 60.08Hz.

With the "Zero Delay" Buffer on, they limit the framerate to 60.00Hz exact which works fine for recording short clips, but there will eventually be a desync after 10 min.

For longer recording clips, I can set it to Full Buffer, which will cause a dropped frame every 10 seconds.

lordsmurf · #14 05-25-2021, 12:24 AM

Quote:

Originally Posted by DragonQuarter

Thanks for the additional insight! So the Analogue Super Nt has settings to account for the SNES's weirdo 60.08Hz.
With the "Zero Delay" Buffer on, they limit the framerate to 60.00Hz exact which works fine for recording short clips, but there will eventually be a desync after 10 min.

I would not assume that. "zero delay" could means anything.

DragonQuarter · #15 05-25-2021, 02:12 AM

Quote:

Originally Posted by lordsmurf

I would not assume that. "zero delay" could means anything.

It's not an assumption, but rather what the designers and reviewers of the Super Nt have stated.

lordsmurf · #16 05-25-2021, 04:15 AM

Excellent, I can only guess the clock has been adjust downward to 60.000 precisely.

I would follow NJRoadfan's advice here. If he has a good experience with Utvideo, do that. I just know my experiences with FFV1 are that it has too much resource overhead, causes frame drops. And when you're using a card known to not report drops, that's a problem.

What game are you doing? Of all my SNES games, I want to play X-MEN the most. I still have my original console, but had been looking into modern HDMI/etc consoles that improved everything from game lag to clarity. I remember seeing some of the first hacks for consoles almost 20 years ago, to use component and HDMI. The biggest problem I noticed was that the hardware was emulated, not true, so some games still won't work. Is that Analogue Nt actual hardware, or emulation? I may as well build a Raspberry Pi if emulated.

NJRoadfan · #17 05-25-2021, 07:10 AM

The Analogue Nt consoles are FPGA reproductions of the original hardware with added features (HDMI output being the big one). It is not software emulation and the FPGA code has been tested against most if not all of the SNES library at this point. If bugs crop up, the unit can be updated by the user with new code.

If using original hardware, there are a wide variety of video upscalers and capture solutions for RGB video now.

DragonQuarter · #18 05-25-2021, 11:57 AM

Yeah, what I truly wanted to do was use my SNES (which I had sent out to be custom-modded for RGB) to capture from using my OSSC connected to my Magewell capture card, but unfortunately there's a huge audio skipping/video flickering issue that occurs due to the way both the SNES and Magewell are designed. I'd have to get my SNES modded with a "deflicker mod" in order to fix the issue (or get a converter that plays nice with the Magewell) but at this point I'd rather just keep it simple and use the Analogue Super Nt.

I thought about getting a Retrotink 5X since that one plays nice with capture cards, but unfortunately it's 256 "sharp pixel" mode for SNES stretches the 4:3 aspect ratio a bit so it's not the "true" aspect ratio of the SNES. And if I'm looking to do accurate captures, that's not ideal to me.

Hoping perhaps that "OSSC Pro" that's in the works addresses those flickering issues with SNES.