Any GH2 news on the HDMI output front?

Sandbox said:
It's the only digitizing system we've seen preserve the 24P cadence through HDMI.
Click to expand...

To be clear, the frame order is still a mystery and that is the key part in producing useful 24P video. I am going through a 10minute long test now to see if there are any long term patterns. The most common pattern i'm seeing at the moment in 50i is:

[AA BB AA BB AA BB AA BB AA BB AA BB] [BA AB BA AB BA AB BA AB BA AB BA] [AA BB etc

That is 12 progressive followed by 11 interlaced for a total of 23 usable frames in just under a second of footage.
Sadly, the 24 frames are not grouped very nicely.

I'm certain there is a pattern somewhere. Creating a random cadence would require a lot more technical effort to accomplish and I doubt that is what Panasonic had in mind. Though I fear the pattern is probably once every 5 minutes or so.
 
Yes, I understand it's still a combination of progressive and interlaced footage. But so far, only footage digitized with the Intensity card has been able to preserve progressive content over the interlaced HDMI signal.

As for the random nature of the cadence, I do hope you're right.

My uneducated theory was based (erroneously, I suppose) that the camera isn't necessarily sending out anything but a 60hz frequency over the HDMI stream, even though the HDMI is timed for 59.94 or whatever. I was thinking that the capture hardware is having to compile the fields into frames based on its own sync. As the fields approach frequencies that don't match between camera and recording device, the recorder makes rounding errors on where fields need to go, and thus this clumsy approach and departure occurs as we move from one type of cadence to another. Since there's no timecode, I assumed there was no master sync, so the randomness was being created simply because the GH2 is really operating on a different frequency than the HDMI protocol.
As I said, I hope you're right, but if it was a product of engineering, I would expect to see a repeatable cadence within the 16.67 seconds or so it takes to match up 60 hz to 59.94 hz. In fact, why wouldn't they make it reliable, if they were involved? They are obviously aware of it, and their comment to that guy on P Bloom's blog was that it was a signal that wouldn't work for digitizing specifically because the camera was not synced for HDMI.

So, I'm going out on an uneducated limb and saying they're simply feeding a 60 hz signal over a standard that is not 60 hz, and letting the monitor deal with the occasional hiccups that the human eye wouldn't really detect. 60i or 50i, they're really neither, and no-one would notice until they tried recording the signal.

But I'm probably wrong. lol.

Good luck to you - and whoever does discover a pattern is going to be a hero here, that's for sure. :thumbsup:
 
Last edited:
Ok, here's my theory based on what I have seen so far:

Looks like the HDMI output is reading from the memory buffer (or something) in the camera with its own independent clock at 50/60i.
The progressive frames in 50i appear to be just a coincidence where a frame happens to write to the buffer just before the first field. After about 12 frames the 24p vs 50i goes out of sync and the output writes out a duplicate field and the field order reverses and so on and so forth.

This appears to occur most of the time, but there are still some strange things happening such as a stray fields here and there that do not follow this pattern (and which make it impossible to predict the correct pulldown).
 
Check out farfromsubtle's 5 min test sample on p. 10 of this thread. There you'll see you can remove pull-down (3:2) fairly consistently for around 7-8 seconds before the clip stumbles around for a second and then advances to the next cadence. Don't try his 1 min clip, as that ended up getting resized somehow, and the interlacing is a mess. However, I would like confirmation from what I think you're saying. Is removing pull-down from the 50i footage a mess? Do you have to do everything by hand to make it work (at this point, barring a sudden revelation that there is indeed a pattern)? It seems like the PAL version of this camera is more "crippled" than the NTSC version for shooting 24P over HDMI. Am I understanding you right?
Thanks for sharing your tests . . .
 
A Solution!

A Solution!

Hello everybody,

I've been lurking for some time, and seing the problem Henry is having, well, I've just got to jump in.

I successfully extracted a clean 24 FPS from his Nanoflash clip. Go here and download the results.

http://www.sendspace.com/file/40pncr

The secret? I used AVISynth and the Decomb filter. Decomb is specifically designed to deal with irregular pulldown patterns (or the lack of them).
 
wow, thank you Ralph B! I have also some footage for AVISynth. Now I got pulldown patterned footage from my AJA io HD mybe because I reinstalled the drivers. I recorded a few seconds from the standby mode (all interaced) and after I pressed record, the pulldown pattern with interlaced and progressive frames starts.
setup:
horizontal moving bar on a laptop screen at 60fps, advancing 1 pixel per frame (just for smooth motion)
GH2:
PAL 1080i25 set to 1080p24 24MBit mode

https://www.yousendit.com/download/RlRwM25GaTFxRTFFQlE9PQ
 
The PAL footage is "workable" as in if someone sat there looking at every frame manually and decided what to do with it you could assemble a progressive stream.
The reason I suggested it was "impossible" (probably a poor choice of words) was my assumption that without a pattern I couldn't write a script to extract it automatically (or at least I thought...)

That decomb filter suggested by Ralph has me intrigued, looks like it separates the fields and discards any duplicates by comparing them. This method should work regardless of the cadence or randomness.
I've tried it with some NTSC footage posted here and my own PAL footage and it works well. The only issue is it doesn't detect duplicate whole frames so double frames (which show up as very brief pauses during playback) appear in both the NTSC and PAL output footage.

I should be able to write my own script to deal with this as the chances of a single video frame being bit-for-bit identical with the last should be absolutely impossible with CMOS and any duplicates can be discarded with certainty.
Thanks Ralph, I think you have moved us in the right direction!
 
Last edited:
hm, the result is 25p but should be 24p. Maybe the interlaced part at the beginning with the on screen info should be removed to not confuse the decomb filter ... I'll give AVISynth a try on my Bootcamp partition ...
 
Decomb appears to pulldown where it can and deinterlace everything else, hence the 25fps.

I've instead tried writing a utility to do a PAL pulldown manually, making sure to drop duplicate frames. So far it mostly works but there is a missed frame every few seconds I am trying to track down.
Comparing the fields side by side with the AVCHD footage shows that all the frames are there (which is a good sign) so I am hopeful it's just a bug on my part.
 
Wow. Great suggestion Ralph. Haven't tried avisynth myself, but the decomb filter could be the ultimate weapon here, as long as the software can actually decipher which fields belong where - especially once motion slows or gets too extreme. I have no experience with it, so can't help but be hopeful.
There are going to be be duplicate frames in here, though, as that's simply the nature of the beast, and if they aren't predictable, some sort of analysis would be required to drop them. AUZGC, what are you using to do a manual pulldown? Original software you're writing?
At some point, and this is probably just getting into the pixel-peeping side of things, it'd be nice to get a slow moving panning chart shot, and then compare an avisynth assembly to the original resolution, to ensure it's not interpolating on us.
Anyone have a suggestion about determining color space coming through the HDMI stream? That's the other nagging question that hasn't been explored yet . . .
 
As far as I can tell the HDMI stream is 4:2:2. Much more detail in the reds than AVCHD.

AVDHD

avchd.png

HDMI

hdmi.png

(open each in an image editing program and zoom in to see the detail)
 
Is there any chance that this avisynth adventure could translate into something on the Mac platform without having to use Bootcamp? Just curious...
 
What we're dealing with here is that the camera is running at 24P and outputing the picture into a 50i stream. This is going to result in a bizarre pulldown pattern which we can clearly see in aemonk's excellent test. We also have to consider the possibility that the camera is running at 23.976 which would result in an even more bizzare pulldown pattern. Perhaps this will be of some help to you, auzgc.
 
looking good.. if some re-order pattern works will progressive uncompressed 422 solution be possible?

At this stage would the PAL or NTSC be best for hdmi capture?

Thanks.
 
Nicky said:
At this stage would the PAL or NTSC be best for hdmi capture?

Thanks.
Click to expand...

It's a little too early to tell. Both may prove to be fine, but we don't know that for sure, yet.

I'll be receiving an NTSC GH2 next week, and I have a fully functioning Intensity Pro board ready to go.

So hopefuly, I'll be able to add something to our knowledge.
 
You must log in or register to reply here.
Back
Top