Bizarre vertical lines

[poisondeathray]

RE: YV24 and destripe - I even downloaded the .avs uploaded above, loading that version manually (in case I copy & pasted incorrectly, or it was corrupted) , tried it on different sources . It's working here

Is your system overclocked ? try setting to stock speeds . Have you check memory integrity ?

[jagabo]

It looks to me like the chroma channels of the two interlaced fields have been blurred together. Maybe by converting YUY2 to YV12 or YV24 without specifying interlaced=true. Then the video was bobbed.

Here's the hamburger with a gamma stretch, two consecutive frames (previously fields) of the video:


Here's a strawberry from the earlier video with

AviSource() #interlaced YUY2 source
AssumeTFF()
ConvertToYV12()
Bob()

two consecutive frames (previously fields) same gamma stretch:

[Asterra]

No, jagabo was correct. At some point during my most recent efforts to force DeStripe to accept something besides YV12, I had removed the interlace flag. That was my bad.

Still not liking the way it increases brightness visibly on darker hues. I'm wondering if there might be a 32-bit step that I could use, and which AE would accept.

(Also not having the greatest luck finding the AviSynth importer for AE.)

[poisondeathray]

ahhh nice catch detective jagabo!


Asterra - If you don't like it, keep rec601

ConvertToRGB() uses Rec601 by default ie. same thing as ConvertToRGB(matrix="Rec601")

For the most part, avisynth uses 8-bit processing (some filters use 32-bit intermediate processing, then dithered down) but all exports are 8-bit .


If you import v210 (10bit 4:2:2 Y'CbCr) encoded avs file, AE will treat it as higher bit depth (in 16bpc or 32bpc mode). e.g. less banding in histogram . If you import direct .avs, everything is 8-bit (even in 16bpc or 32bpc mode) and gradients are more "quantized" . Just because you can use the importer, doesn't mean you should. There are pros/cons to it.


The importer is actually for premiere, but will allow you to import avs directly into CS4 AE and below
http://videoeditorskit.sourceforge.net/


Another reason to use avisynth to convert to RGB, is the chroma upsampling is lower quality in AE (blockier colors around color edges). It uses a nearest neighbor algorithm. This is really noticable on 4:2:0 content

[Asterra]

Is your system overclocked ? try setting to stock speeds . Have you check memory integrity ?

No overclocking. I actually verified the complete stability of my system recently in an effort to solve some issue which turned out to be software-related.

Perhaps the culprit variable is the source file, which in my case is a UT Video Codec file.

Actually I just verified my earlier finding that QTGMC is the function which is causing the corruption. (DeStripe absent, corruption present. QTGMC absent, corruption absent.) DeStripe does indeed handle YV24 just fine.

[Asterra]

ConvertToRGB() uses Rec601 by default ie. same thing as ConvertToRGB(matrix="Rec601")

Looks like Rec601 generates pretty much the same result. It's really just a quibble, and probably only bothers me because of the time already invested in this project. ;p

If you import v210 (10bit 4:2:2 Y'CbCr) encoded avs file, AE will treat it as higher bit depth (in 16bpc or 32bpc mode). e.g. less banding in histogram . If you import direct .avs, everything is 8-bit (even in 16bpc or 32bpc mode)

So the recommendation then is to render v210 raws with VDub and use those? (And is there an AviSynth command which would perform this conversion?)

The importer is actually for premiere, but will allow you to import avs directly into CS4 AE and below
http://videoeditorskit.sourceforge.net/

Ah, that's why I couldn't find it. In actuality, I had used the importer years ago (with Premiere Pro) when making a rather complicated home video Bluray, so my inability to find it again was perplexing.

[poisondeathray]

If you import v210 (10bit 4:2:2 Y'CbCr) encoded avs file, AE will treat it as higher bit depth (in 16bpc or 32bpc mode). e.g. less banding in histogram . If you import direct .avs, everything is 8-bit (even in 16bpc or 32bpc mode)

So the recommendation then is to render v210 raws with VDub and use those?

Depends on what you are doing . It gets the Rec709 treatment, so you probably don't want to use it for this one

"v210" is special for both premiere and AE. For some reason it's the only non native Y'CbCr format that gets this special treatment . Other commonly used "lossless" formats (like lagarith, huffyu, ut) in Y'CbCr mode get the Rec601 treatment, regardless of HD vs. SD.

Actually I just verified my earlier finding that QTGMC is the function which is causing the corruption. (DeStripe absent, corruption present. QTGMC absent, corruption absent.) DeStripe does indeed handle YV24 just fine.

Here is one of my bigggest gripes about avisynth. The various plugins and filters are so disorganized. e.g. There are 10 different versions of remove grain LOL.

Did you look at the QTGMC post, and download those recommended plugins. Don't use the plugin package, download from the original sources . The post gives instructions on specific versions, and specific dlls to use (don't unzip them all)

For masktools the "26" version is for avisynth 2.6.x , the "25" version is for avisynth 2.5.x , don't use them both. One or the other



What does the "corruption" look like? Like the previous screenshot where bottom of the frame is green ?

[jagabo]

ConvertToRGB(matrix="rec709") shouldn't cause a levels shift at the low end. It will cause red and greens to get brighter or darker at the high end. I posted some samples a while back.

[Asterra]

ConvertToRGB(matrix="rec709") shouldn't cause a levels shift at the low end. It will cause red and greens to get brighter or darker at the high end. I posted some samples a while back.

I don't guess I have a way of showing what I mean since copying a YV24 frame into PS just converts it to RGB. But the way you describe it sounds about right. An area of smooth gradient from dark red to slightly less dark red gets a green tinge added to it when converted to RGB, which also increases its brightness.

[Asterra]

Depends on what you are doing . It gets the Rec709 treatment, so you probably don't want to use it for this one

I'd still be interested to see whether or not the improved bit depth would help with the brightness enhancement I'm seeing. Is there a command within AviSynth which will perform the v210 conversion, or should I try to use VDub's options?

Did you look at the QTGMC post, and download those recommended plugins. Don't use the plugin package, download from the original sources . The post gives instructions on specific versions, and specific dlls to use (don't unzip them all)

For masktools the "26" version is for avisynth 2.6.x , the "25" version is for avisynth 2.5.x , don't use them both. One or the other

I gave it another gander, but it looks like I have the latest versions of all the required plugins, and I was sure to only extract the dlls which were a match for my system.

What does the "corruption" look like? Like the previous screenshot where bottom of the frame is green ?

Yes. It's only green most of the time, though, and the brightness of the green pulsates randomly. Other states include B) mostly lacking in color, C) poorly deinterlaced, D) ghost images of previous frames superimposed, etc.

[poisondeathray]

I'd still be interested to see whether or not the improved bit depth would help with the brightness enhancement I'm seeing. Is there a command within AviSynth which will perform the v210 conversion, or should I try to use VDub's options?

What is this "brightness enhancement" you're referring to? From Rec601 or 709? from one of the filters? or something else?



Increased bit depth won't help with luminace . Avisynth is just a frameserver, it doesn't encode.

You could encode the .avs script with ffmpeg for example, or make batch scripts if you have a lot to do

ffmpeg -i input.avs -vcodec v210 -an output.mov

You can use avi wrapped v210 also. v210 will get rec709 treatment in AE, so if you didn't like the converttorgb rec709, you're not going to like this.

[jagabo]

ConvertToRGB(matrix="rec709") shouldn't cause a levels shift at the low end. It will cause red and greens to get brighter or darker at the high end. I posted some samples a while back.

I don't guess I have a way of showing what I mean since copying a YV24 frame into PS just converts it to RGB.

Of course, displaying YUV video on your monitor or TV also requires conversion to RGB whether you do it explicitly or just let the software or hardware handle it. The issue is whether you use the rec709 or rec601 matrix. Both of these perform the normal contrast stretch from Y=16-235 to RGB=0-255. VirtualDub, and many other programs, always uses the rec601 matrix to convert YUV to RGB. If the colorimetry is flagged in the video you should use the what's flagged. In the absence of the flag the general rule is to use rec601 for standard def, rec709 for high def.

General YUV/RGB conversion info:
https://forum.videohelp.com/threads/329866-incorrect-collor-display-in-video-playback?p...=1#post2045481

This post shows what happens when the wrong rec matrix is used:
https://forum.videohelp.com/threads/329866-incorrect-collor-display-in-video-playback?p...=1#post2045830

Some programs, Sony Vegas for example, use the PC matrices instead. Those do not perform the contrast stretch leaving the black level too high and the white level too low for display. The AviSynth equivalent is ConvertToRGB(matrix="PC.601") or PC.709.

[poisondeathray]

also how are you viewing this? vdub ? media player ?

you can have other effects of various renderer, post processing, graphics card settings



for example in vdub do you have directx enabled in the display options ? that can affect how things look


as jagabo says above - you're not looking at Y'CbCr directly, you're looking at the RGB representation of it. If you open it directly in vdub, it will use Rec601 to convert that Y'CbCr input format to RGB for display


If you prefer Rec601, then use Rec601 for your RGB processing . But your distributions formats need to be specially prepared. For example Youtube will convert your Y'CbCr video to RGB for display using Rec709 (regardless of HD or SD) , and most blu-ray players will use Rec709 - so you have to compensate for that when upload to youtube or making BD (you need to specify matrix and flags when converting RGB back to some Y'CbCr distribution format)

[Asterra]

What is this "brightness enhancement" you're referring to? From Rec601 or 709? from one of the filters? or something else?

I figured it out. Well, I figured out what's going on, but not why.

There seems to be some sort of incompatibility between UT Video Codec and AviSynth, and possibly VirtualDub. It's something transparent which doesn't affect the final output, but it does seem to affect what shows up in VDub's preview. Try looking at this in VDub:

pm_1frame_ut.avi

It's a single interlaced frame using UT Video Codec at 4:2:2 - no modification whatsoever from the capture. Pay close attention to the greenish glow on the red wall to the right of Pac-Man.

Now just load this Avisynth script up:

AVISource("pm_1frame_ut.avi")

and look at the same wall. The greenish glow, on my screen at least, is gone. (Other dimming phenomena are visible, but this example is the one I first noticed.) I had been assuming that this version, lacking the glow, was the correct output, and that all the versions I was seeing with the glow were the result of excessive inaccuracy in RGB conversion.

Live and learn. ;p (Back in a bit. Must eat eventually.)

[jagabo]

They look the same on my screen (I can see the glow):



Try disabling DirectX in VirtualDub: Options -> Preferences -> Display (left pane) -> Use DirectX... Exit and restart VirtualDub for the change to take effect. Now VirtualDub will do the YUV to RGB conversion (always rec.601), eliminating the graphics card's conversion (DirectX) as a variable.

I guess the real question is what did the xbox 360 put out? rec.709 YUV? rec.601 YUV? Or if it put out RGB which matrix did the graphics card use to convert to YUV? My guess, from looking at the caps, is that the xbox 360 is putting out rec.601 YUV. rec.709 makes the greens look a little dull.

[poisondeathray]

Some programs, Sony Vegas for example, use the PC matrices instead. Those do not perform the contrast stretch leaving the black level too high and the white level too low for display. The AviSynth equivalent is ConvertToRGB(matrix="PC.601") or PC.709.

Just to clarify, this is only for native camera formats like DV-AVI, HDV, and the one special uncompressed 4:2:0 IYUV (not YV12) . Other non native Y'CbCr formats like huffyuv, lagarith, ut video (in their Y'CbCr modes) etc.. get the standard Rec601/709 treatment


For the AVI directly loaded vs. AVS loaded into vdub, I also see the glow in both

Jagabo - If I take snapshot of input or output pane (CTRL+1 or 2) , and paste into image editor, there are slight difference between the AVI loaded and AVS loaded. It looks maybe like different chroma upsampling (the AVI directly loaded looks "blockier" and there is a slight shift). Why would this be ? Shouldn't the upsample and RGB conversion be the same ?

[jagabo]

If I take snapshot of input or output pane (CTRL+1 or 2) , and paste into image editor, there are slight difference between the AVI loaded and AVS loaded. It looks maybe like different chroma upsampling (the AVI directly loaded looks "blockier" and there is a slight shift). Why would this be ? Shouldn't the upsample and RGB conversion be the same ?

Yes, I see that too. I think VirtualDub simply duplicates the chroma samples to upscale, whereas AviSynth interpolates (bilinear? bicubic?) the chroma channels.

[poisondeathray]

If I take snapshot of input or output pane (CTRL+1 or 2) , and paste into image editor, there are slight difference between the AVI loaded and AVS loaded. It looks maybe like different chroma upsampling (the AVI directly loaded looks "blockier" and there is a slight shift). Why would this be ? Shouldn't the upsample and RGB conversion be the same ?

Yes, I see that too. I think VirtualDub simply duplicates the chroma samples to upscale, whereas AviSynth interpolates (bilinear? bicubic?) the chroma channels.

But the upsampling isn't done by avisynth , the avs script is feeding YUY2 . ConvertToRGB() isn't specified in the script. So the upsample is done by vdub (or should be). Why is vdub treating them differently ?

File => file information shows UT video codec YUV422 for the AVI as expected, and File=> File information shows Internal DIB YUY2 as expected for the avs

[Asterra]

Try disabling DirectX in VirtualDub: Options -> Preferences -> Display (left pane) -> Use DirectX... Exit and restart VirtualDub for the change to take effect. Now VirtualDub will do the YUV to RGB conversion (always rec.601), eliminating the graphics card's conversion (DirectX) as a variable.

Sure enough, this causes both iterations of the video to produce the same display (with the glow).

I guess the real question is what did the xbox 360 put out? rec.709 YUV? rec.601 YUV? Or if it put out RGB which matrix did the graphics card use to convert to YUV? My guess, from looking at the caps, is that the xbox 360 is putting out rec.601 YUV. rec.709 makes the greens look a little dull.

It can do all three, but as it happens I had it set to RGB - presumably the default. As for the conversion, that would be a matter for the doubtless limited documentation on the AverTV HD DVR.

This does bring up a good point, though. Would you say it's preferable to continue telling the 360 to output RGB, or to change to one of the YUV settings? My uneducated guess is that the 360's graphics are already being rendered internally as RGB and it would have to do a conversion of its own to output YUV, which would mean it doesn't make any difference unless the 360's conversion is somehow superior to the HD DVR's.

[Brad]

The HD DVR converts (720p+) RGB to YUY2 by assuming studio levels and using Rec.709. It also adds some dithering. I determined this using the Spears & Munsil Blu-ray and capturing the same patterns while swapping output modes.

If the 360 natively outputs YUV with less dithering it would help with compression but could lead to more banding.

By the way, how are you going to compress it to maintain 4:2:2 while uploading to YouTube?

[Asterra]

The HD DVR converts (720p+) RGB to YUY2 by assuming studio levels and using Rec.709. It also adds some dithering. I determined this using the Spears & Munsil Blu-ray and capturing the same patterns while swapping output modes.

This sounds like a big "aha" moment. Before having done any tests to determine one way or another, it sort of sounds like the HD DVR is responsible for the checkerboard pattern which engenders faint vertical lines upon deinterlacing.

By the way, how are you going to compress it to maintain 4:2:2 while uploading to YouTube?

That's a good question and I frankly haven't made it far enough along in this project to start tackling that facet. If it's not possible, then it doesn't even matter anymore since I have never gotten DeStripe to work with anything besides YV12.

[Asterra]

I think I figured out why QTGMC is free and Fieldskit isn't. Here's a frame from the game's menu, wherein things were scrolling at a fast rate:


The miniature maze on the left is exiting the screen, leaving a ghost of itself behind. The S-crown near the right is scrolling in from the right and is both preceded and followed by ghosts of itself, as are other moving elements.



Here's a frame from the Fieldskit raw I thankfully did not delete. (Complete with the vertical lines, of course.) Although Fieldskit seems incapable of handling bob flicker, at least it appears to know what to do with fast moving objects that lack motion blur. So what I'm wondering is if QTGMC has a setting which might be more appropriate for this kind of footage.

Edit: I should note that these two frames aren't from the same source capture but they are nonetheless from the same event in the game with more or less identical visuals.

[Asterra]

Answering my own question. That magical setting would appear to be: "Very Slow".

Yep. Anything less and there are still some artifacts here and there. But man. It's not joking, is it.

[jagabo]

If I take snapshot of input or output pane (CTRL+1 or 2) , and paste into image editor, there are slight difference between the AVI loaded and AVS loaded. It looks maybe like different chroma upsampling (the AVI directly loaded looks "blockier" and there is a slight shift). Why would this be ? Shouldn't the upsample and RGB conversion be the same ?

Yes, I see that too. I think VirtualDub simply duplicates the chroma samples to upscale, whereas AviSynth interpolates (bilinear? bicubic?) the chroma channels.

But the upsampling isn't done by avisynth , the avs script is feeding YUY2 . ConvertToRGB() isn't specified in the script. So the upsample is done by vdub (or should be). Why is vdub treating them differently ?

Oh, I thought you were converting to RGB in the AVS script (that's what I was doing when I saw the issue). I've played around with it some more and verified what you found -- even when receiving YUY2 from AviSynth the display is less blocky than opening the UT AVI file directly.

As an experiment I set Video -> Color Depth to Autoselect and added an internal filter (Brightness/contrast, because internal filters aren't limted to working in RGB now) and enabled the Show Image Formats option in the Filters dialog. That allows you to see what colorspace the video is in at each filter. The video that's opened directly in VirtualDub shows RGB24 as the colorspace. The AVS script (that's putting our YUY2) shows YV16. The latter is smother on-screen. If I force the color depth to YUY2 both ways of opening the file show YV16 and both are smooth. So the difference appears to be what colorspace VirtualDub is working in and where it converts to RGB for display. I don't know if this effects the output too. That's something to look into...

<edit>
After a few more tests, the Color Depth setting does indeed effect the video output, not just the display. One more thing to keep track of...
</edit>

[jagabo]

The HD DVR converts (720p+) RGB to YUY2 by assuming studio levels and using Rec.709. It also adds some dithering. I determined this using the Spears & Munsil Blu-ray and capturing the same patterns while swapping output modes.

This sounds like a big "aha" moment.

Yes! I'd try forcing the xbox 360 to output YUV 4:2:2.

By the way, how are you going to compress it to maintain 4:2:2 while uploading to YouTube?

That's a good question and I frankly haven't made it far enough along in this project to start tackling that facet. If it's not possible, then it doesn't even matter anymore since I have never gotten DeStripe to work with anything besides YV12.

Youtube will convert to 4:2:0 anyway so there's little/no benefit to uploading anything as 4:2:2.

[Brad]

This sounds like a big "aha" moment. Before having done any tests to determine one way or another, it sort of sounds like the HD DVR is responsible for the checkerboard pattern which engenders faint vertical lines upon deinterlacing.

Dithering is random noise though, not lines. See the background on this cap (from PS3).



For what it's worth, Digital Foundry determined that the 360 doesn't output the exact contents of its frame buffer over HDMI even in full RGB.