HDMI Capture Problem SOLVED - AviSynth RULES!

@GrgurMG - I think the right screenshot does look better , but it seems to me there are still differences in the example RalphB posted (with the red pen, green background)

In 2.6, there are more options for chroma placement and resampling, but the default ConvertToYV12 is changed as well. For example, you could use ConvertToYV12(chromaresample="point"), and it would use point sampling instead of bicubic . There's actually a patch (that hasn't made it into avisynth 2.6 yet) that uses a 4pixel kernal vs. 2pixel kernal. There is no "good" way to resample chroma, they all have pros/cons. What I'm trying to say is there are dozens of combinations and options that might give better or worse results. I think in this case we actually want less accurate, more blurring

Thanks for that link, I downloaded it before ,but erased it long ago...GRRR :(
 
PDR said:
In 2.6, there are more options for chroma placement and resampling, but the default ConvertToYV12 is changed as well. For example, you could use ConvertToYV12(chromaresample="point"), and it would use point sampling instead of bicubic . There's actually a patch (that hasn't made it into avisynth 2.6 yet) that uses a 4pixel kernal vs. 2pixel kernal.
Click to expand...

Hrm, I switched over to 2.6 and it seems like ConvertToYV12() specifically is causing an issue with my script... both with and without the chromaresample variable. The clip plays, but either cuts to black or crashes at some point. The script with the ChromaSampleFix works though.

Which build of 2.6 do you use?
 
Last edited:
GrgurMG said:
Hrm, I switched over to 2.6 and it seems like ConvertToYV12() specifically is causing an issue with my script... both with and without the chromaresample variable. The clip plays, but either cuts to black or crashes at some point. The script with the ChromaSampleFix works though.

Which build of 2.6 do you use?
Click to expand...

What issue? post the error message

Some filters/plugins have specific .dlls for 2.6 versions, and < 2.6 versions .

I'm using the sept27,2009 build

If you type version() it will say what version

BTW, you can load prores directly by using QTSource , using QTInput() . You need quicktime installed. 10-bit prores will be truncated to 8-bit (But I think GH-2's output is 8-bit HDMI only, not sure)



There's something different about the that specific sample than say, AE monk's samples (which were also prores recorded with AJA kona IIRC) or Ralph B's examples. ConvertToYV12() will help improve up AE Monk's samples (and Ralph B's) more significantly for some reason. That person doesn't post here does he? From Japan?
 
Last edited:
Hrm, I'm using an August build.. let me switch on over. I wasn't getting an error message, the clip would start playing then either cut to black or crash. I bet it's just an issue with my version, I'll see in a sec.

Oh and thanks for the QT advice, I've always been iffy on how to best load various file types into AVISynth.
 
For example, here are some from AEMonk's samples, and I would say they improve more significantly than that other clip using variations on ConvertToYV12 (and his was prores 422 also)
http://www.mediafire.com/?gqv6cw510zn3w33


You can do dozens of different variations on the sampling ; you might use chromaplacement dv, or chromaresample lanczos or spline36, or bilinear if you wanted less sharp, etc....The point here is what Ralph B. suggested (even the default ConvertToYV12) seems to improve the clips . But for some reason, it doesn't do as good of a job on that clip from Japan...not sure why yet.
 
I'm going to shoot some samples using all color spaces and upload the raw files for you guys to play with. Hang tight.
 
Yep, switching to the Sept. build of AVISynth 2.6 fixed the problem. And yeah, I can see that convertToYV12() works much better. Although in the particularly clip I'm using, I'm iffy if I might still like FixBrokenChromaUpsampling() slightly better for some applications. I've gotta hunt down some different sample footage to test on.
 
There shouldn't be that much of a difference between 2.58 and 2.6 using default ConvertToYV12() ; I just suggested 2.6 because just allows you to access chroma placement and chroma resampling options besides bicubic; there might be some other combinations that yields better results

I would recommend using clips by people that actually post here, so questions can be asked, and details can be clarified
 
Actually, there was quite a bit of a difference between the default ConvertToYV12() for whatever version of 2.5 I had and the version of 2.6 we're both now using. The combing, as in my example picture, was still very evident through the chroma downsampling in 2.5. Much cleaner in 2.6... for whatever reason.
 
Here are links to the raw files of a GH2 HDMI chroma test. There are two archives, 24P and 60i. There are four clips in each archive - RGB lossless, 4:2:2 lossless, 4:2:0 lossless + AVCHD.

http://www.sendspace.com/file/xm7ytq

http://www.sendspace.com/file/89a3z8


In order to view these clips you will need to download and install UT Video Codec Suite.

http://www.free-codecs.com/download/Ut_Video_Codec_Suite.htm

The UT codec is a superb piece of software, and if you find yourself using it, please support the author. He deserves it.


The clips were captured with a Blackmagic Intensity Pro board directly into the various varities of UT. I used a program called Video Capture Master because Blackmagic's software does not give you the option to use third party codecs.
 
Hrm, is anyone else seeing some chromashifting in most clips too? Might have something to do with my workflow, but I'm getting chroma shifting of about a pixel or so each way.

I've been playing around with adding

ChromaShiftSP(-1,-1) or ChromaShiftSP(-0.5,-0.5) into my script before TFM()... the first being prefered. Tried in on the Green Screen footage, the Color Chart, and now the new UT Video codec stuff. Will post examples when I get back later.

-- edit --

Need the plugin for that.. which is here.... http://www.geocities.com/siwalters_uk/chromashift27.zip
 
Thanks for uploading those test clips , Ralph

I haven't looked at the 60i bunch, but my observations for Ralph B's 24p chroma test clips - in terms of fewest chroma artifacts - is to record YUY2 , IVTC, use FixBrokenChromaUpsamping(), ConvertToYV12() (or some variation of it , but the default works fine). You can get similar results by using RGB, but it doesn't make sense to waste bandwidth. "Skimping" by recording to YV12 directly yields worse results, probably because the HDMI signal=>YV12 conversion is done in the codec instead of avisynth

The AVCHD clips seem to have higher saturation for some reason; it doesn't appear to be a Rec601 vs. Rec709 issue.

The green pen cap (in the full sized screenshots) has aliasing even in the AVCHD version, so that's not a chroma issue

Interesting note: This is more noticable if you look at the actual video, but the HDMI version has more detail in the shadow region over the ball (in the black nylon) compared to the AVCHD recording, which has larger "patches" of detail missing, even though this is a static scene (shouldn't tax the codec that much). But even the HDMI version seems to have "patches" of detail missing for some reason...

AVCHD screenshots had their saturation adjusted to 85% to roughly match the HDMI , I used Rec709 for taking the screenshots, but included a Rec601 version of the AVCHD in the zip file for reference , which also has the full sized screenshots

Here are 1:1 crop comparison

2qtek9g.png



I've included the full sized screenshots in a zip file, and a Rec.601 version of the AVCHD for comparison

http://www.mediafire.com/download.php?okbtors96333oh3
 
ChromaShift

ChromaShift

Here are two examples of the chroma shifting and subsequent repair I'm seeing. Might the shifting have something to do with the switch back to RGB or is it native to the footage thus making the chromashift applicable to the standard script?

http://www.jerseyforged.com/sampleclips/originalchroma.png

http://www.jerseyforged.com/sampleclips/shiftedchroma.png


My script for the later is as follows...

AviSource(".....24P UT 422.avi")
AssumeTFF()
convertToYV12(chromaresample="Spline64")

ChromaShiftSP(-1,-1)

TFM()
TDecimate(mode=1)
AssumeFPS(24000,1001)

ConvertToRGB()
ImageWriter("<path>",start=33,end=33,type="bmp")

----

examplechroma.png


--- Edit ---

The chroma shift appears in your examples above too PDR.
 
Last edited:
Yes, there is chroma shifting - this has to do with the way avisynth handles YUY2<=>RGB conversions

The reason is the current code uses a 2 pixel kernal, so the shifts occur like this for progressive sampling :
Code: 
Progressive:
                  2.58 2.60
RGB->YV12:       H H+V
YV12->RGB:       OK -H
RGB->YV12->RGB:  H V

Code: 
Interlaced:
               2.58 2.60
RGB->YV12:       H H+V
YV12->RGB:       V -H
RGB->YV12->RGB:   H+V V

The shifts accumulate if you do consecutive colorspace conversions

I would hesitate to "hardcode" suggestions of this nature, rather let end user "tweak" their result, because the results will be slightly different if they say, use avisynth 2.58, 2.6 alpha 2 , vs. the next release. The next release will update the code to use a 4 pixel kernal and this will change behaviour again. So you would have to be very consistent in the system setup, decoder, filters, .dll's to ensure something is going to work as predicted. This is different than something like cadence , which should be consistent between system setups if you use a frame accurate source filter (ie. not something like DirectShowSource() )

Also there are tradeoffs. The black letters in the red ball might become less legible, there might be more red blurring "bloom" on the red ball top edge etc... than say, using a 0.5 shift. Or the white grille in the speaker will become yellow at the edges. For example, compare this to the 2 shots above (I adjusted for Rec.601) (flip back & forth between the 3 and you will see tradeoffs). There's actually pros/cons tradeoffs to every choice here - because there is no "perfect" way to resize or resample. For example a spline64 chroma resize will produce more chroma aliasing than a bilinear resize
http://www.mediafire.com/?ar0i0ohggs9clbx
 
Last edited:
PDR said:
Understood - so same number of frame count as 29.97 , but just header is changed for playback (similar as if you would conform in a NLE) is that correct ?
Click to expand...
I believe that is correct, yes. It is 29.97 from the imager, and recorded frame-for-frame, so I believe that just the header is changed. Could be wrong, but that is my understanding of it.

Now, if I understand what you're saying -- it just doesn't work at all? That 30p clips are pointless to record on HDMI... wonder why that would be...

Now, back to the original -- you're saying clip 2 works perfectly, but cip one is bugged?
 
Barry_Green said:
Now, if I understand what you're saying -- it just doesn't work at all? That 30p clips are pointless to record on HDMI... wonder why that would be...

Now, back to the original -- you're saying clip 2 works perfectly, but cip one is bugged?
Click to expand...

To summarize, everything works on the clips so far with the proper scripts

Clip 3's recording is very abnormal, but the algorithm is able to recover it - I would actually like a longer clip to verify.

Clip 1 is peculiar because of the white/black flashing rectangle.

For Clip 1, there are points where the black/white rectangle doesn't coincide at the same moment in time as upper "long rectangles" (i.e. at a single point in time on fields derived from the same progressive frame - its both white and black - which is impossible). This screws up the default algorithm, so an alternative is required. I though underlying cause might be rolling shutter (the leading edge appears to be the lower edge), but doesn't make sense if the scan was progressive frame then pulldown came after.

Right now a different script is required for clip 1 vs. clip 2 because of that. (For example if you crop out that rectangle, it works "normally" and behaves like clip 2). So if we could figure that out, then a more simplified approach could be used.
 
Last edited:
May be it'll be possible to write small standalone software using ffmpeg or similar library to convert captured footage to proper format?
 
You must log in or register to reply here.
Back
Top