HDMI Capture Problem SOLVED - AviSynth RULES!

[Barry_Green]

The GH2 has the ability to shoot a slight overcrank. It runs its sensor at 29.97fps, and records that in a file that gets tagged as being 23.976fps. The result is that when you play the footage, it plays back at 80% speed -- a slight slow-mo.

The HDMI output therefore should have been a genuine 30p. The only field variation should be due to the 1001/1000 field insertion issues. There shouldn't be any IVTC done on it, you should just be able to run your script to reverse out the 1001/1000 and end up with a progressive 30p file.

 

[PDR]

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 ?

There isn't any IVTC done on the 3rd clip, it's supposed to be 30p. You would only IVTC if it was 24p in 60i.

For 30p in 60i, it should be as simple as aligning the fields, throwing out the inserted duplicate - if this was a 1001/1000 issue

If it was true (30000/1001) / (60000/1001) , you just have to match field pairs (AA field pairs become A the frame , BB field pairs becomes B the frame, etc...) because there are no inserts. All you would need to do is use TFM() because no decimation is required. You have perfect cadence to begin AA, BB , CC etc....



I'm probably not explaining it clearly - that 3rd file up to 1.9 seconds acts fine, exactly as you describe, and behaves nicely.

After that, it's doesn't and never recovers. It's not as simple as realigning fields or "you should just be able to run your script to reverse out the 1001/1000 and end up with a progressive 30p file." , because 1001/1000 isn't the problem in that clip. . If it was just an inserted field, you would get triplicates (for where the field was inserted) and duplicates (which are normal, like AA, BB), but never a single field

 

[JackBayer]

oh gosh, isn't it possible to speak a language that all of us understand?

Does this work accurately fine or not exactly?

easy answer: yes or no

I agree and disagree. I stopped following (still reading up though) but without a GH2 so far it is pure theoretical stuff for me and it´s hard to keep up.
But if I had one, I´d love to participate and learn all that is neccessary (especially since collegues keep telling me about how mighty this avisynth is...)
and what for now is completely not-understandable for me.

But I am sure that once every relevant question to this topic has been answered there will be a sticky or faq or updated first post.

 

[PDR]

Ok, this works for the "30p" clip

FFVideoSource("01295001.MXF",seekmode=0)
AssumeTFF()
TFM(mode=0)
AssumeFPS(30000,1001)

(again this is resized, just for cadence demonstration purposes, MJPEG in AVI, blah blah...)
http://www.mediafire.com/?qufvfi4xu59rady


So if you are using the "slo mo" mode, TFM (mode=0) is required, because of the mulitple single field inserts. It will properly discard the 3d of the triplicate field, and take the single field to produce it's own frame

If you wanted to make it 24p slowmo , Then use AssumeFPS(24000,1001) instead of AssumeFPS(30000,1001). AssumeFPS retains the same # frames (ie. same framecount), but just slows down the clip (it's analgous to conforming in an NLE, or changing the header in a clip to play slowly)





To summarize, everything works as it should with the proper script - at least according to the sample clips so far.

If anyone is recording in YUY2 (4:2:2), or RGB (4:4:4) (not sure why you would, it's a waste of bandwidth) - then add ConvertToYV12() to the script . If you're starting in RGB, use ConvertToYV12(matrix="rec709") to use BT.709 matrix coefficients

@Ralph B - I asked this earlier but didn't see a reply - When you record in YV12 (4:2:0) directly (for example with UT) , are the chroma artifacts present?


The only thing that bothers me still, is the flashing white/black rectangle on the 1st clip. Barry , if you can provide more information on that, then instructions could be simplifed. Theoretically your clip#1 and clip#2 should be the same, and the algorithm used for them should be the same. You shouldn't have to use a different algorithm for both

 

[ghosttv]

So hdmi works with 30p only? Or 60i ? Not bad!

 

[Ian-T]

So hdmi works with 30p only? Or 60i ? Not bad!

He said....

To summarize, everything works as it should with the proper script - at least according to the sample clips so far.

 

[zidane]

So hdmi works with 30p only?

no 24p?

but the original poster says 24p

 

[Ralph B]

@Ralph B - I asked this earlier but didn't see a reply - When you record in YV12 (4:2:0) directly (for example with UT) , are the chroma artifacts present?

Hi PDR,

Sorry, I've been busy. I recorded directly to UT lossless 4.2.0 codec and yes, the red chroma jaggies are present. As a result, I feel that converttoYV12() should be a permanent part of the script.

 

[Caesar]

Hi PDR,

Sorry, I've been busy. I recorded directly to UT lossless 4.2.0 codec and yes, the red chroma jaggies are present. As a result, I feel that converttoYV12() should be a permanent part of the script.

Does this step solve 100% the red chroma jaggies ?

 

[Ralph B]

Does this step solve 100% the red chroma jaggies ?

Yes, it does.

 

[PDR]

Hi PDR,

Sorry, I've been busy. I recorded directly to UT lossless 4.2.0 codec and yes, the red chroma jaggies are present. As a result, I feel that converttoYV12() should be a permanent part of the script.

No problemo. So this suggests you have to record in YUY2 or RGB, and use ConvertToYV12() to get rid of the jaggies ?

If you record to YV12 in UT directly, it's already YV12 , and ConvertToYV12 doesn't do anything

So then what was the workflow for that picture of the fellow on the roof? (The caption read: "HDMI captured with UT lossless codec at 4.2.0"). If I zoom in I can sort of make out jaggies, but it's not 100% definitive



RE: the flashing black/white rectangle - could it be a partial exposure / cmos issue? The leading edge in Barry's clip #1 seems to be the lower part of the frame - but I still don't see how it's possible if the sensor is really outputing 24p and the pulldown is added after...

 

[Ralph B]

Thanks. So this suggests you have to record in YUY2 or RGB, and use ConvertToYV12() to get rid of the jaggies ?

If you record to YV12 in UT directly, it's already YV12 , and ConvertToYV12 doesn't do anything

No, no, you misunderstood me. You get the red jaggies no matter what color space you record to, including 4.2.0. The only way to remove them is to use converttoYV12() in Avisynth. I know logically it doesn't make sense, but that's the way it is.

So what was the workflow for that picture of the fellow on the roof? (The caption read: "HDMI captured with UT lossless codec at 4.2.0")

That was an example of recording directly to a 4.2.0 codec, in this case, a lossless 4.2.0 codec.

RE: the flashing black/white rectangle - could it be a partial exposure / cmos issue? The leading edge in Barry's clip #1 seems to be the lower part of the frame - but I still don't see how it's possible if the sensor is really outputing 24p and the pulldown is added after...

I'm still working on Barry's clips. They are quite a challenge and very helpful.

 

[PDR]

No, no, you misunderstood me. You get the red jaggies no matter what color space you record to, including 4.2.0. The only way to remove them is to use converttoYV12() in Avisynth. I know logically it doesn't make sense, but that's the way it is.

Thanks for clarifying.

This really doesn't make sense , because YV12 input and ConvertToYV12() is a NOP in avisynth (nothing is done)

If you take that UT 420 footage, and use info() and preview the script what does it report as the colorspace?




Can you make out jaggies in that picture, or am I imagining things? Did you apply ConvertToYV12() to that UT 4:2:0 footage as well for that screenshot?

Your screenshots were slightly different frames, but the detail difference is definitely there

There is a slight color discrepancy - how did you take the screenshots (what matrix did you use to convert to RGB for the screenshot? Rec601 vs. Rec709 ? Or how did you take the screenshots? )

Now this is "pixel peeping", but am I imagining these jaggies?

These were enlarged 4x , (nearest neighbor algorithm) from your screenshots

 

[Ralph B]

This really doesn't make sense , because YV12 input and ConvertToYV12() is a NOP in avisynth (nothing is done)

If you take that UT 420 footage, and use info() and preview the script what does it report as the colorspace?

OK, one mystery cleared up. If you record with a 4.2.0 codec, there are no red jaggies when you open the file directly in Avisynth. However, there are red jaggies when you open the same file in VirtualDub or play it in Media Player Classic. This is what led me to think the red jaggies were being recorded with the 4.2.0 codec. But, I think Avisynth is showing the true situation. So, if you record in 4.2.0, you don't need to converttoyv12() in the script. It would be interesting to know what's going on with these other programs.

Did you apply ConvertToYV12() to that UT 4:2:0 footage as well for that screenshot?

That was a straight frame grab - no processing whatsoever.

There is a slight color discrepancy - how did you take the screenshots (what matrix did you use to convert to RGB for the screenshot? Rec601 vs. Rec709 ? Or how did you take the screenshots? )

The color discrepency between HDMI and in-camera is real, and it's not unique to the GH2. I've seen it in other video cameras that output an uncompressed picture, including the Sony EX1.

Now this is "pixel peeping", but am I imagining these jaggies?

Your guess is as good as mine!

 

[Amadeus5D2]

Hi all,

unfortunately I have so far no GH2 to test. But I had similar probelms with my 5d II. At the moment canon change fps from 60 to 59.94 I can capture liveview via blackmagic ( set to 59.94) without any interlaced effects ( if I make file settings AE from interlaced to progressive I have a clean 29.97 and progressive 4:2:2 file ). My question is GH2 output only "29.97" or have you the option to capture via hdmi at 59.94?

 

[stoneinapond]

no 24p?

but the original poster says 24p

Go back a read carefully.

 

[GrgurMG]

Chroma Issue

Chroma Issue

Okay, I've been playing with some of people's uploaded footage myself (as I don't have a GH2 just yet). I was in particularly looking at the chroma issue. As I see, understand, or perhaps misunderstand it... the GH2 is actually pumping out something sorta like 4:2:2.... no? The issue being that it's not clean and contains those artifacts, thus converttoyv12() is utilized which does fix it, but in the sense that it obscures the chroma detail that shows the artifacts, as it's losing chroma resolution going from 4:2:2 to 4:2:0.... correct? Yes no? Am I way off?

Perhaps it's just the clip I'm using that's confusing me, but seeing that I decided to do some fiddling with AVISynth... in fact I have more fiddling to do, but this is one thought I've come across so far.

Instead of utilizing converttoyv12() to correct the 4:2:2 captured footage, what do you think of how FixBrokenChromaUpsampling() looks? It was largely made to correct a problem with the old Canopus DV codec... but it's effect on the HDMI footage interest me. Observe below...

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

At least on this clip, you can still make out the combing on the ConverttoYV12 clip, it's just very obscured and less distracting. On the FixBrokenChroma clip, there is no combing and the red is protruding less out of the square. Also, you'll notice less of that blue fringing/combing on the bottom side of the yellow square.

IMO, the chroma in the last image looks before, although feel free to pix apart. One this I did notice, which really isn't highlighted in my example, is I'm not thrilled how I like how the green channel is dealt with... although I'm looking into a possible work around.

Thoughts? I prolly do something wrong with the ConverttoYV12() or is this a defuct sample clip or something?

 

[PDR]

OK, one mystery cleared up. If you record with a 4.2.0 codec, there are no red jaggies when you open the file directly in Avisynth. However, there are red jaggies when you open the same file in VirtualDub or play it in Media Player Classic. This is what led me to think the red jaggies were being recorded with the 4.2.0 codec. But, I think Avisynth is showing the true situation. So, if you record in 4.2.0, you don't need to converttoyv12() in the script. It would be interesting to know what's going on with these other programs.

That was a straight frame grab - no processing whatsoever.


The color discrepency between HDMI and in-camera is real, and it's not unique to the GH2. I've seen it in other video cameras that output an uncompressed picture, including the Sony EX1.

Sorry to be a PITA, but it's important to be specific here.

The difference is the method of chroma upsampling. You're not viewing Y'CbCr , you're viewing a RGB representation of it (it's already been converted to RGB when you view in vdub,mpc or take a screenshot)

Vdub will use ITU Rec.601 , media players may use something different depending on how you set it up

The "jaggies" that we're referring to are different between interlaced chroma sampling, and different versions of chroma upsampling (for example if the chroma was point resized, vs. bilinear resized, or the type of kernal used in the calculation). I explained this partially in the other thread; to avoid geekspeak - the big problem was interlaced chroma sampling, not different ways of sampling that may look blockier or smoother. Some programs use different algorithms that lead to "chroma smoothing." The interlaced sampling will show notches like ridged lines .

To illustrate, if you look at the screenshots in this post in the mediafire link, compare shots 4 and 5. These are the exact same video frame from AVCHD YV12, but different methods of chroma upsampling used - one looks like chroma is smoothed because of the sampling .

http://www.dvxuser.com/V6/showthrea...output-front&p=2198647&viewfull=1#post2198647

Your guess is as good as mine!

If you have a chance, could your post video of the red pen / green background video ? I would like to see a recording in RGB (if possible), YUY2 and YV12 . It doesn't need to be long, as this will just be for chroma testing purposes

BTW, What capture card are you using ? I want to know where in the process chain is the YUY2=>YV12 conversion occuring when you record to UT 420 or any other YV12 format? is it the card itself, or the codec?

If you recorded RGB, and let the codec do the YV12 conversion it or didn't specify matrix , coefficients , then usually Rec.601 is specified. Then there will be a color shift compared to the AVCHD recorded material when viewed with Rec.709 matrix

I suspect there is a difference in quality (with the chroma sampling) if you used YUY2 (and ConvertToYV12() to capture vs YV12 directly)

 

[PDR]

Thoughts? I prolly do something wrong with the ConverttoYV12() or is this a defuct sample clip or something?

It's "broken" eitherway - I mean the video.

We're just looking at methods to "improve" it

ConvertToYV12() algorithm actually is different depending on the version of avisynth you're using, it's slightly different in 2.58 vs. 2.6

Do you have a link to actual Y'CbCr video from that ?

 

[GrgurMG]

I downloaded the Zip from here.... http://www.dvxuser.com/V6/showthrea...output-front&p=2189156&viewfull=1#post2189156

I used the ss60_24pHDMIprores.mov clip, although did some editing and converting so I could load it into AVISynth as an Uncompressed AVI. The original capture seems to be ProRes 4:2:2. I dunno if those clips have been uploaded individually anywhere... if not I can see if I can reupload the clip I'm using somewhere.

Also, I'd gladly test on any better clips with good examples of the chroma issue. And as for AVISynth, I am using 2.58.