HDMI Capture Problem SOLVED - AviSynth RULES!

The uploaded image here are being resized. I will try to put them as link because I can't seem to find a way to put the originals here

https://picasaweb.google.com/lh/photo/mfhhOSHqZwCJphToj84adA?feat=directlink

https://picasaweb.google.com/lh/photo/j23ZqZo42N_wjImqb1WHQw?feat=directlink

https://picasaweb.google.com/lh/photo/HlKzw9XX22YeM3aIoenT3g?feat=directlink

https://picasaweb.google.com/lh/photo/0iNXqxTo8U6FIGBdsQg4RA?feat=directlink

https://picasaweb.google.com/lh/photo/Amtu_6Wzn3Oo_f34hgAk-g?feat=directlink

https://picasaweb.google.com/lh/photo/zhyabGhrnIewdmk1B08qAA?feat=directlink

https://picasaweb.google.com/lh/photo/BNoWlcUGk_2YWdVqYxHlLg?feat=directlink

https://picasaweb.google.com/lh/photo/2utkNWE0Z67j8iaz5FLFIw?feat=directlink

HlKzw9XX22YeM3aIoenT3g



 
Has anybody run that script on the file I sent, and verified that it is actually doing it accurately? If it can strip out the pulldown accurately out of the file I posted, then I'd believe it's working. And if it can't strip out the pulldown accurately, then it's not working on any file. The file I put up is a test case that should reveal any errors in the process...
 
For me the base GH2 :-) was already very good in terms of resolution/detail and low light from the test we have seen (to my level of expectation). What I could not figure out accurately was the Dynamic range and motion. Let me explain for the motion thing. Someone from the start was saying that his GH13 was much better that the GH2 when doing motion. I think the threat span on 20+ page. I thought that what he was saying was a bit exaggerated, he was making as if you could not film a lot of motion with the gh2, the codec could not follow it which resulted in mud (not as severe as the gh2). I found it a bit dubious from the example I have seen, but had no proof of it as I don't have the camera.

Now in terms of dynamic range, I had no test on that very very important quality for me. From sample footage I have seen, the Avchd gh2 seems to be doing quite well. This opinion entrails only me, but I thought that it did better than the Af-100. The skin roll-off were much more natural and should it clip it did it in a more gentle way. Unfortunately the AVCHD codec completely kills detail in the shadows. This is why my excitement if we hunt for more details in the shadows thus further extending the dynamic range. For me this is the last and most important look that we need to get the complete film look. That is why DP say that the Alexa is the closest to film, because of its 14 stop of dynamic range.
 
Barry_Green said:
Has anybody run that script on the file I sent, and verified that it is actually doing it accurately? If it can strip out the pulldown accurately out of the file I posted, then I'd believe it's working. And if it can't strip out the pulldown accurately, then it's not working on any file. The file I put up is a test case that should reveal any errors in the process...
Click to expand...

See post #19
http://www.dvxuser.com/V6/showthrea...Synth-RULES!&p=2240901&viewfull=1#post2240901

That clip is an almost worst case scenario; if you can produce a slightly longer clip it would help to verify

The cadence is slightly different than the other samples posted. I'm wondering if there might be differences in the recorders (in theory there shouldn't be)
 
The cadence can't/shouldn't be any different -- it's a 24p clip recorded on a GH2, and the Nano recording the HDMI output as 60i (not 59.94i). There should be no such thing as a worst-case scenario, they should all be a same-case scenario.

If there's anything different about the clip I posted, it should only be in that the presence of the duplicated fields (the 1001/1000 fields) will vary based on when you press "record" on the nano -- but that will happen with any and every clip anyone ever attempts to record. That's what I was asking before -- how does it know where the 1001/1000 fields are? They aren't part of the 2:3 pulldown, there are six of them every second but they could appear anywhere within the cadence, although presumably they would be evenly distributed once they were identified.

So that's what I'm getting at -- if it can't work right with the clip I posted, then it isn't working right with any clip at all. The clip I posted is designed to make it obvious as to whether it's working or not. Any proposed script to strip out the pulldown should work perfectly with the clip I posted, or else it's not working at all.

A longer clip is no problem, I'll go shoot another clip, at an even higher shutter speed and a higher bitrate, which should make the presence of interlaced fields extremely crisp and obvious.
 
Barry_Green said:
The cadence can't/shouldn't be any different -- it's a 24p clip recorded on a GH2, and the Nano recording the HDMI output as 60i (not 59.94i). There should be no such thing as a worst-case scenario, they should all be a same-case scenario.
Click to expand...

Exactly. It shouldn't be, but it is compared to the clips in the other thread .

The cadence in any of the clips posted isn't regular 3:2 (or 3:2) in either case. It's "almost worse case" because it is irregular. ie. You don't have a nice A1A2B1B2B3C1C2D1D2D3 etc... and it's not evenly distributed.

There's more going on with your clip than just (60.0)i vs. (60000/1001)i - It's not as simple as only some extra fields inserted every "x" fields, there's actually missing fields in other sections (in theory, this shouldn't happen on a contiguously recorded clip). This was not the case on the other clips I viewed. You can step through the fields and see for yourself. If it was that simple and regular, you could use a selectevery() function to get perfect IVTC, but that isn't the case here

If there's anything different about the clip I posted, it should only be in that the presence of the duplicated fields (the 1001/1000 fields) will vary based on when you press "record" on the nano -- but that will happen with any and every clip anyone ever attempts to record. That's what I was asking before -- how does it know where the 1001/1000 fields are? They aren't part of the 2:3 pulldown, there are six of them every second but they could appear anywhere within the cadence, although presumably they would be evenly distributed once they were identified.
Click to expand...
As Ralph explained earlier, TFM is an adaptive field matcher. Even if you have cadence breaks , it will attempt to align up the matching fields. Of course decimation is required after to get rid of the duplicates. Straight M in N decimation won't work here - because of the irregularities.


So that's what I'm getting at -- if it can't work right with the clip I posted, then it isn't working right with any clip at all. The clip I posted is designed to make it obvious as to whether it's working or not. Any proposed script to strip out the pulldown should work perfectly with the clip I posted, or else it's not working at all.
A longer clip is no problem, I'll go shoot another clip, at an even higher shutter speed and a higher bitrate, which should make the presence of interlaced fields extremely crisp and obvious.
Click to expand...

The modifed script does work, so far . Have a look at the "IVTCed" sample clip in that post

In theory, an inserted or deleted field (but outside of the TFM range where it "looks" to match fields) could screw up the IVTC. This is the reason I would like to look at a longer clip . (TFM mode7 actually keeps track of previous matches, so it should work eitherway). But just because it works on that clip, doesn't prove it will work on everything. The cadence isn't regular. If the cadence were regular, then yes, I would agree that clip would suffice.
 
Last edited:
Well -- see, here's the thing -- if my clip is somehow broken, then that means the whole process is broken. It either works or it doesn't... my clip is designed to be a clear and precise measuring of whether it's working or not... if it only works on some clips, but not all, then -- the process is flawed. Or, the camera is outputting spurious clips that the process won't work on. Either way -- either it works on every clip, or it's not a reliable workflow, right?

If it matters, my clips are recorded when the camera is recording. The output is different depending on whether the GH2 is recording or not, and it's only accurate if the GH2 is recording to its internal SDHC card. If other clips were made without the camera itself recording, they can't be trusted because the color and gamma and colorspace are all different...

New clips coming momentarily.
 
Last edited:
Okay, two new clips to experiment with...

This first clip is the same thing as before, but longer, at a higher bitrate for hopefully cleaner compression, and with a higher shutter speed for less blur. This was shot in the cinema 24 mode, so it should be a 24p file, with 3:2 pulldown to insert it into a 59.94 file, and then with further 1001/1000 pulldown inserted to turn it from 59.94i into 60.00i.
http://www.mediafire.com/?xbx693awbb3mcx3

The second clip is an experiment but you may find it quite helpful in getting to the bottom of this... in this second clip, I shot the same thing, but in 80% slow-mo mode. The idea here is that this should be a 29.97p clip. It should be 29.97 within 59.94i, so each and every "frame" should be a perfect progressive frame. Now, it isn't, and the reason it isn't is because of the 1001/1000 pulldown that gets inserted, that causes the fields to be split. So the idea here is, if someone can develop a 60.00i->59.94i pulldown-stripper-outer, then they should be able to turn this second file into a perfect 29.97p file with each and every frame looking as it should. And if they can do that, then they will be in a great position to fix the 24p file.
http://www.mediafire.com/?22677vcqyiqn23b

To summarize, for anyone interested in experimenting with this stuff, here's the situation as I understand it:
The GH2 shoots 23.976 fps.
The GH2 records 23.976 fps to its internal card.
The goal here is to get 23.976 progressive frames per second captured by an external recorder.

The HDMI output does not output 23.976 fps. Instead, it only outputs 60.00 interlaced fields per second. To get the HDMI output, the GH2 adds 3:2 pulldown to its 23.976 footage, turning it into 59.94i footage. And then, furthermore, it adds 1001/1000 pulldown, turning its 59.94i footage into 60.00i footage.

In order to be a useful recording solution, the bare minimum that has to happen is that there needs to be a utility that strips out the duplicated fields in the 60.00i footage to return it to a true and exact 59.94i with every field exactly where it belongs. Once that is accomplished, we can then use conventional inverse telecine functions to turn the resulting 23.976-within-59.94i footage back into true progressive 23.976p footage, with every field exactly where it belongs.

Hopefully these two files will give you folks exactly what you need, in order to make this happen.
 
Barry_Green said:
This first clip is the same thing as before, but longer, at a higher bitrate for hopefully cleaner compression, and with a higher shutter speed for less blur. This was shot in the cinema 24 mode, so it should be a 24p file, with 3:2 pulldown to insert it into a 59.94 file, and then with further 1001/1000 pulldown inserted to turn it from 59.94i into 60.00i.
http://www.mediafire.com/?xbx693awbb3mcx3
Click to expand...

Thanks for uploading the test clips. (I'm going to refer to them as clip 1 for the very first clip, 2 and 3 for the ones in post #69)

The default settings works perfectly here for the 2nd clip

FFVideoSource("01294001.MXF",seekmode=0)
AssumeTFF()
TFM()
TDecimate()
AssumeFPS(24000,1001)

I think the difference is the flashing black/white rectangle (at the bottom middle of the frame) in the 1st clip. Can you explain what that is? and what frequency it's supposed to be?

On the 1st clip, on some consecutive fields, despite being in the same "time" frame as determined by the "moving bands", the rectangle is white on one field but black on the other. This causes TFM to associate the wrong field, leaving an incorrect duplicate - hence the need for the modified settings for it to work. In fact, if you crop it out before IVTCing, the default settings work too - suggesting that the flashing rectangle at least part of the reason the default settings don't work

But on the 2nd clip, that flashing rectangle isn't present, and you just have "regular" duplicated fields inserted , but the fields are "correct" . This is what the other clips in the other thread look like in terms of cadence. Thus there is no need for modified settings.


The second clip is an experiment but you may find it quite helpful in getting to the bottom of this... in this second clip, I shot the same thing, but in 80% slow-mo mode. The idea here is that this should be a 29.97p clip. It should be 29.97 within 59.94i, so each and every "frame" should be a perfect progressive frame. Now, it isn't, and the reason it isn't is because of the 1001/1000 pulldown that gets inserted, that causes the fields to be split. So the idea here is, if someone can develop a 60.00i->59.94i pulldown-stripper-outer, then they should be able to turn this second file into a perfect 29.97p file with each and every frame looking as it should. And if they can do that, then they will be in a great position to fix the 24p file.
http://www.mediafire.com/?22677vcqyiqn23b
Click to expand...


This 3rd clip, the "29.97" clip - is screwed up. It's begins perfectly normal AABBCC....as you would expect, but later on the field cadence becomes irregular with triplicates and single fields. I'm afraid it doesn't provide much information, because it's doesn't appear to be because of the inserted fields as you've suggested. Inserted fields wouldn't leave a single field (you should always have duplicated, or triplicate if field is inserted). It's almost as if the 3rd field in the triplicate is supposed to be the 1st field of the next field pair (for the next frame). Also, this occurs far more frequently than just inserted fields for 60000/1000 vs 60000/1001 would produce. Something else is going on here with the recording - it occurs after ~2.9s (or field 175 and on). It's almost as if something "switched" in the recording mode after that point in time
 
Last edited:
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
 
There is no easy answer yet. I've submitted three clips, one is said to work, two are said not to. I don't know if there was a testing error on the third clip (i.e., did you try to run just the 1001/1000 on it, or the full reverse telecine too?... because it's not a 24p clip, it's a 30p clip).

I will have to review the first clip to see what's being asked about the black/white rectangle.

So if you want an easy answer, I would say we cannot say it works, until it works on every clip every time.
 
Last edited:
To clarify , the clips 1 & 2 work . Clip 3 I think is a weird experiment - I'm not even sure it has any value

But there is something peculiar about the way you recorded clip 1 - the cadence isn't the same as everyone else's HDMI recordings. There is a disconnect between the fields with respect to the flashing white/black rectangle. If it was truly 24p (24000/1001) read from the sensor , at the same moment in time , you should never get a field that shows both black and white rectangles - but for some reason you do. To illustrate I posted field 38,39 .
http://www.mediafire.com/?1rg2bgd3et169tq

Even if "spurious" fields were inserted, they should be duplicates , not different (ie. at the same moment in time, as shown by the upper moving rectangles, the lower black/white rectangle should be the same color) .

So for clip 1 , because of this "disconnect", you have to use modified settings, and then you get perfect IVTC - this is why I said it's "almost worse case scenario" . Note the other HDMI recordings didn't exhibit this behaviour - which is why I asked for more information on the black/white flashing rectangle

Everyone else's clips work in that other thread, similar to Barry's 2nd clip here, and it's just default settings to IVTC. If anyone recalls, the big issue wasn't cadence in that other thread, the issue was chroma sampling.

Here is the IVTCed clip for Barry's clip #2 (again, it's reduced to 960x540 MJPEG, but it's just for cadence demonstration purposes)
http://www.mediafire.com/?q7h47lb3izbbxsy



But the 3rd clip is way off. But I'm not really sure how you even recorded "80% slow mo... "

did you try to run just the 1001/1000 on it, or the full reverse telecine too?... because it's not a 24p clip, it's a 30p clip
Click to expand...
It's not working like you think it is, at least not after the point where the cadence changes. I was describing the native field cadence as is; before even applying ITVC or anything. If this is 30p in 60i (or even remotely similar) - You should never get a single field that represents it's own moment in time - and there are too many of them.

If this was 30p in 60i , you should get consecutive field pairs AA, BB, CC, DD etc.... And you do, until that point where everything switches. It's almost like 2 different clips from 2 different settings after that point

Then you get something like AAA B CC DDD E FF GG ... It's almost like the last of the triplicate (the last "A") should really belong to the 1st "B" . Similarly, the last "D" of the triplicate, should belong to the next E. It's reminiscent of the GH13 hack issues

I'm not sure what to make of clip #3, or if it's even valid. How was "80% slow mo" done ?
 
You must log in or register to reply here.
Back
Top