Intensity Pro Capturing (HDYC colorspace headache)

[TheThrillness]

I'm trying to capture good looking 720p video using the Blackmagic Intensity Pro. The MJPEG codec is decent but too many artifacts for my liking. I don't have the resources for uncompressed capture.

I have decided to use a popular program called Amarec as it seems the author has this card and incorporated HDYC support. However, whatever I capture seems to have some color shift problems.

Here is an uncompressed capture from Media Express as to what should be captured: http://oi40.tinypic.com/2hhk4g2.jpg

I used these codec settings in Amarec: http://oi43.tinypic.com/nf4mep.jpg

This is the output I get: http://oi40.tinypic.com/2pzlhd2.jpg

There seems to have been a special HDYC build of Huffyuv but it had color issues. The last post here states that the Amarec codec was able to reproduce the SMPTE color bars properly.

http://forums.creativecow.net/thread/124/873380

Does anyone know the magic Amare codec settings I need for proper color reproduction and no color shift?

Thank you

[Digital-Overload]

Hello, I visit this forum now like once a year,

I do have an Intensity Pro, and Have had one since the initial beta batch before it went retail.

I'll have to Update all my firmware and stuff, as I've neglected to do so in over 4 years, just because Everytime it would goof something, but I later found out it was Windows 7 doing that.

Also, Can you provide a link to the software/codec you are using?

I've actually been looking for alternatives to the MJPEG Codec, I can capture RAW but I dont like doing it.

[jagabo]

HDYC is the same as UYVY except the U and V components are rec.709 rather than rec.601.

http://www.fourcc.org/yuv.php#HDYC
https://forum.videohelp.com/threads/329866-incorrect-collor-display-in-video-playback?p...=1#post2045830

That doesn't require anything special -- just appropriate decoding of the colors when converted to RGB, or to be flagged as rec.709 when encoded to the final format (like h.264). In fact, if you're capturing HD most programs will assume rec.709 if it's not flagged.

How do you know the uncompressed Media Express has the correct colors? How did the YUV video get converted to RGB for your JPG image?

[TheThrillness]

Digital, you can try if you like. The software is here: http://www.amarectv.com/english/amarectv_e.htm
The codec: http://www.amarectv.com/english/amv2_e.html

It might take awhile to get used to it though.

jagabo, I know Media Express is right from just visually looking at it. I've seen what the source looks like on a TV and another capture card I have that works in YUY2 mode shows the same colors as Media Express. I think the JPG images came from tinypic (it converted my PNGs that I uploaded).

Actually now I think about it, I don't really need to go and use Amarec codecs. If another codec that supports HDYC that gives me better quality than MJPEG, that is all I want.

[jagabo]

Can you provide an uncompressed (you can ZIP it) HDYC sample from the BMIP? Something with a variety of colors and intensities would be most useful.

[TheThrillness]

It's okay. I did about 7 hours testing last night and figured it out.

Thanks for helping!

[jagabo]

Why don't you post your observations to help out the next guy?

[TheThrillness]

You can use x264vfw in lossless mode with "keep input colorspace" in the settings.

It's the best result I obtained. There is still a slight color shift but there is nothing you can do about that. Impossible to get rid of.

[poisondeathray]

Try ut video codec. Newer versions support HDYC

There is a separate fourcc for the Rec709 variant , ULH2 (as opposed to the standard 601)

ULH2UtVideo YUV422 BT.709YCbCr (BT.709) 4:2:2 8bit limited
HDYC
YUY2 (YUYV YUNV)
UYVY (UYNV)
RGB24
RGB32

[jagabo]

Try ut video codec. Newer versions support HDYC

I was going to recommend UT but when I checked the version I had installed it didn't recognize HDYC.

To the OP: Even with the correct fourcc you must be sure the downstream software handles the video properly.

[TheThrillness]

Tried Ut and ULH2. It looks exactly like x264vfw (i.e. perfect).

I actually now have a new issue. I have perfect looking source material but when I encode it using x264 I get more "shifts" in the image. Take a look at these attachments.

forfoum is the raw ULH2 video (it should have no visibility issues).
x264encode is well... the x264 encode and if you look at the right side of the N you can see a faint black line appear.

I also just noticed the faint black line if I simply import the ULH2 or x264vfw source video into VirtualDub.

I'm using MPC and madVR.

[poisondeathray]

1) UT is using 709 (forforum.avi) , x264 encoded is using 601 (x264encode.avi)

Like jagabo said above, depending on how you set up your "viewing" software, the colors might still be wrong (which matrix is used to convert to RGB for display)

2) it looks like you underwent some other colorspace conversions with the x264 encode , it's RGB lossless, not YUY2 lossless => this is probably the cause for the other artifacts

3) The method and algorithm used for chroma upsampling can make a big difference on how it looks




You 're probably using x264vfw ?

You have to set --input-csp i422 --output-csp i422 in the CLI version , so look for that in the vfw configuration , if not add that to the commandline box

Also it's not clear how you're capturing this , what software ? It's possible that it might be doing some other conversion in between

[poisondeathray]

If you look in mediainfo (view=>text) , your x264 encoded version says

Color space : YUV
Chroma subsampling : 4:4:4
Matrix coefficients : RGB

(mediainfo is often incorrect, but I confirmed this with ffmpeg)


Here it's done properly, from the ULH2 file as input (if we assume the ULH2 file is "ok"), file is attached below (x264.avi), but I "cheated", it was done with the CLI version . If you can't find the options in the vfw version, just enter them in the extra command line box

Color space : YUV
Chroma subsampling : 4:2:2
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

(again confirmed with ffmpeg)


Some software can read flags (IIRC madVR can read the Bt.709 flags) , so it should use the correct matrix. But even non flag reading player software will usually convert to RGB for display using 709 if width > 1024 px , 601 if width <1024 px, so it's not a big deal . So it doesn't hurt to add the primaries, transfer and matrix flags, and there is a higher chance of getting correct colors in non player software (e.g. editors) (in x264 those 3 are just VUI flags, the actual bitstream isn't changed) , so I would add them in addition to input-csp and output-csp (these last 2 can do colorspace changes, they are not strictly VUI flags)

--input-csp i422 --output-csp i422 --colorprim bt709 --transfer bt709 --colormatrix bt709

Some software use 601 always for the RGB conversion (e.g. vdub) , also vdub uses a "cheap" chroma upsampling method so color borders are blocky (not as high quality as madvr). For these reasons, (you can't control the RGB conversion or matrix), vdub isn't necessarily a good preview software if you're examining colors, or at least you have to keep these things in mind when using vdub

[TheThrillness]

1) Can I ask how you check if a file is using 709 or 601? I never thought to check that since I always thought if a video had a resolution of 720p or greater it would be automatically flagged for 709 in the media player. I guess not.

2) Interesting. All I did was check "keep input colorspace" in x264vfw and it set it to RGB like you said. This must be a bug or something between x264vfw and Ut.

I actually just encoded the Ut and x264vfw lossless source files using a specialized encoding program called anri-chan (it's for video game speedrun encoding) and it produced perfect looking video. This program must be doing the flagging for 709 and other stuff with AviSynth to properly handle it.

Edit - I typed this after your last post. Good info and that attachment you posted looks exactly like the anri encode!

[poisondeathray]

1) Can I ask how you check if a file is using 709 or 601? I never thought to check that since I always thought if a video had a resolution of 720p or greater it would be automatically flagged for 709 in the media player. I guess not.

You can't really, unless you have a known reference. I assumed the ULH2 was using 709, so if you convert to RGB using 709 , that's what it should look like - ie. that was assumed to be the known reference. Your x264 encoded file was already outputting RGB , and the colors looked different (if you work backwards to YUV, you can figure out it was 601 by testing out different matrices)

2) Interesting. All I did was check "keep input colorspace" in x264vfw and it set it to RGB like you said. This must be a bug or something between x264vfw and Ut.

But it shouldn't be RGB, if you have it set to RGB it's converting to RGB (and using the wrong matrix , 601) . x264 doesn't have the ability to convert RGB<=>YUV using 709 , only 601 , so that's the other reason I strongly suspect it to be 601 RGB conversion (but it's possible the conversion was done in the other software, not x264)

If the card is outputing HDYC - it can be treated as YUY2, or UYVY - but definitely NOT RGB

I actually just encoded the Ut and x264vfw lossless source files using a specialized encoding program called anri-chan (it's for video game speedrun encoding) and it produced perfect looking video. This program must be doing the flagging for 709 and other stuff with AviSynth to properly handle it.

So these were direct captures using ut and x264vfw using anri-chan ?

It's not quite lossless (or it's more of a "gotcha") with avisynth . UT will output YUY2, but 4:2:2 x264 lossless will output YV16. For all intents and purposes and in most programs that can handle these formats - they can be treated as YUV 4:2:2, and identical, but if you do a subtract script or difference masking, there will be a tiny microscopic detected difference . I think it's due to rounding or some internal avisynth handling. If you convert both to YUY2 or both to YV16, it's bit for bit identical

[TheThrillness]

Attached an encode that I think is using 601. Can you confirm? Reason I ask is because the author of anri-chan has new software and I think when encoding HD video he did not flag 709 and it is getting treated as 601.

If you need comparisons here are other encodes I did which look like yours.

x264 (709) and UT Encode (709) were done in anri-chan. The 601 attachment is the new software that I think is wrong.

[poisondeathray]

To be clear, "601" and "709" refer to the matrix used for YUV<=>RGB conversion . You can't really say "is this 601 or 709" unless there was a prior YUV<=>RGB conversion, or you're suggesting what matrix is to be used for the RGB conversion for display

There can be several reasons why your display or preview software might choose different matrix for the RGB conversion for display, one is flags (like those BT.709 flags in the example I posted above) , dimensions, or some other factor . It's going to be different for different software configurations



All these last look similar when comparing the "konami" section , but the "is this 601" version has a slight levels difference (You can see it by comparing histogram() in avisynth or waveform monitor) , it's also 4:2:2 (the other 2 are 4:2:0) . Eitherway, it's not from a 709/601 discrepancy, the slight levels difference is from something else. Also, what I'm "seeing" might be different that what you are seeing depending on what software you're using to view and how it's configured

[TheThrillness]

Also, what I'm "seeing" might be different that what you are seeing depending on what software you're using to view and how it's configured

Yes I was referring to the slight levels difference. I thought it was something to do with 601 and 709 but obviously not.

Anyway, getting off track here. I can now make the final conclusion for anyone else who has this card.

Ut Video (ULH2) or x264vfw in lossless mode will give you perfect source video. When encoding make sure to set BT.709 and you should have no problems.

[jagabo]

If you did any filtering in VirtualDub: YUV sources are always converted to RGB by VirtualDub using a rec.601 matrix. In fact, it looks like your ULH2 source is being converted to RGB by default when loaded into in VirtualDub. Try using Video -> Color Depth to force a YUV mode.

[TheThrillness]

Yeah. Just did that and the issue of the black line on the N goes away.

Note that VirtualDub automatically selected RGB in Video > Color Depth without doing any filtering.