GH2 Hack Shootout Video

W

wigginjs

Member
I hope this patch comparison video is useful. The YouTube description has a link to the original mp4 file if you want to view it at full quality. I'm very interested to hear people's impressions.

cbrandin 66m GOP12 AQ2 1080p
cbrandin 32m GOP12 AQ2 720p
driftwood 132m GOP3 AQ2 1080p
driftwood 64m GOP3 AQ2 720p
mpgxsvcd 42m GOP12 AQ4 1080p
mpgxsvcd 32m GOP12 AQ4 720p
STOCK 24m 1080p
STOCK 16m 720p


 
Thanks for the effort and the original file! This first thing I see is the addition of highlights on the tower over the candle. On the stock setting they are not there. Worth the hack alone!
 
Thanks a lot for that. I've been holding off on hacking, but this has just about convinced me to go for it. It looks like there is way better shadow detail in all the hacked samples.

I'm less sure (in this test situation) how much difference there is between the high and low mbs hacks. I'll have to watch again and dig up a few more samples.

Thanks again for the great side by side comparison.
 
A bit off topic, however: Does the hacks only improve video quality or picture (stills) quality as well? Weird question I know but I use mine as a camera too. :Drogar-Happy(DBG):
 
Just video quality. The hack increases the amount of information that can be used as part of the video feed (minimizing the compression that can lose detail), but each still picture still has way more data than any video frame.
 
Hi wigginjs: Thanks for this, but for me the main advantage of Vitaliy Kiselev's GH2 firmware hack is its effect on _motion_ video quality.

A stock GH2 records motionless & low-motion scenes quite well for a relatively inexpensive interchangeable lens video camera.

However, low bit-rate video compression (such as the GH2's 24-megabits/sec. AVCHD) typically suffers from various motion-related artifacts.

The hack, together with settings provided by Chris Brandin, driftwood & others, enables a GH2 to record motion with fewer compression artifacts. In addition, some folks prefer motion rendering when recorded with short-GOP settings via the hack.

Designing a test to compare stock & hacked motion-related GH2 results is difficult, because the motion must be identical in each iteration.

Further, extremely brief downloadable _camera-original_ .MTS video files are more useful than ones modified during encoding for YouTube or Vimeo.

Cheers.
 
typically suffers from various motion-related artifacts
Click to expand...
yeah. im sorry. i need MOTION samples before im going to buy in to anything. be it a camera or a hack or whatever.
 
Peter:

Yes, motion would be a better test, but as you said a consistent and repeatable motion test is harder to orchestrate. I may attempt to do one in the future if I can find an old record player or some other low-speed, cheap motorized device that I can repurpose for a motion test.

I disagree however about the validity of rendered side-by-side comparisons for evaluating various patch results. While technically it would be best to compare the original mts files I think it matters very little to not at all practically. The re-encoded output from the MainConcept encoder is basically indistinguishable from the original mts files regardless of the bitrate used to encoded them. In addition, for any practical use of the camera footage it will at some point need to be re-encoded. With regard to YouTube, it is my assertion that if a patch makes a tangible difference it will be at least somewhat discernible even on YouTube or Vimeo. The effect may be more pronounced on the original footage, but if the improvement is so slight that it can't be detected on the 1080p YouTube footage I'm probably not that interested in the gain to begin with.

My 2c. If anyone else would like to create a better motion-oriented test I would love to see the results.
 
@wigginjs

Thanks for your reply. I basically agree with you. And, once again, thanks for posting this test.

On the difficulty of designing & executing useful tests: Look at how much effort & expense went into the Zacuto shootouts.

I find end-user tests useful mostly because there are so many of them. I'm guilty of same. ;-)

And of course, real productions are great, especially if the DP shares with the rest of us tips, tricks and cautions.

I learn something from almost every one of them. Thanks again.
 
This is a good test. Not a great one, but good.

Here are some visual ingredients for a great test:
1. Repeatable motion - like moderately moving traffic - to show cadence differences.
2. Dark bushy trees - to show macro blocking.
3. Good sky - to show color banding.
These seem to be the main areas where the AVCHD codec can disappoint. Get them all in one shot and you can answer A LOT of questions.

If you can get all this in your shot then I'm sure there will also be enough fine detail and probably color variation too.

~Cheers
 
DPStewart said:
This is a good test. Not a great one, but good.

Here are some visual ingredients for a great test:
1. Repeatable motion - like moderately moving traffic - to show cadence differences.
2. Dark bushy trees - to show macro blocking.
3. Good sky - to show color banding.
These seem to be the main areas where the AVCHD codec can disappoint. Get them all in one shot and you can answer A LOT of questions.

If you can get all this in your shot then I'm sure there will also be enough fine detail and probably color variation too.

~Cheers
Click to expand...

That sounds great! When can we expect it? 8)
 
I found a good balcony to shoot from but there's not enough detailed objects or foliage in the background....I shall keep searching.
 
I would like to see running water with the hacks. I have been shooting nature stuff for a doc Im working on about a river nearby. The stock camera just cannot handle anything moving on screen. Water looks terrible.
 
Well, be prepared to be blown away. If you look around there are plenty of raw mts files at higher bitrates.
Over a month ago Ralph_B (on VK's site) showed the differences for motion comparing 176Mb/s GOP1, 66Mb/s, and 44 MB/s (AQ4).
The GOP1 was virtually indistinguishable from the HDMI uncompressed frames.

Motion is unreal especially if you go with the GOP1 driftwood settings. All i-frames, no vector motion (b,p) frames.
The high GOP3 also is incredible.

What many have overlooked is why noise now appears to be more defined with the hack.
Noise is seen as motion frame-to-frame and creates demands on the b and p frames.
The extended bitrate during motion allows these larger b,p frames to offer more accurate motion vectors.

Of course the more i-frames the better, assuming we have the bandwidth. Driftwood is workig his ass off to get the largest
i-frames while maintaining GOP1. Of course, high data rates means some of the SDHC cards that used to work, do not with these higher data rate demands.
Also, at some of these higher rates, SDHC card space can disappear in a hurry. At high detail recordings at 24FPS using driftwood's 800K i-frames, we're looking at
19.2MB/s. Granted this number (remembering AVCHD is not constant bitrate) is assuming a sustained detail demand creating larger i-frames, but it certainly gives us an idea
that 1GB per minute can disappear under certain extreme conditions. Granted, under "normal" we would not hit this, but it's good to have this in mind when wondering about
space left on our cards.

Also, driftwood is currently trying to squeeze even larger i-frames at GOP1.
Also, even low GOP6 and GOP3 can reach ~1.1M i-frames with enough leftover bitrate to sustain strong motion vector frames. These "may" be good enough for some for excellent motion
rendering frame to frame.

Hector I certainly hear you regarding motion! This is our concern and why many want the GOP1, or lower GOPs.
Vitaliy K, Chris B, and all the hard working testers are working hard to get the most out of each ptool release. I can't commend Vitaliy
enough for what he has done here.
 
Last edited:
I'd still like to see a motion test for Driftwood's latest (such asAQuamotion v2) versus Cbrandin's 66mb. I've done a few minor, very unscientific tests with motion, and it's hard for me to see much of adifference. I haven't done much testing with grading the two, so that would be another area.

There's obviously a *technical difference* between these two (as evident from streamparser and thefile sizes) but what most of us care about is an *vissible difference*. A lot of folks point to there being visible motion differences between gop1 and gop12--but I'd like to see tests for this. I don't want to turn this into flame thread about gop1 vs long gop. I just want to put in a vote for people to do some more tests in this area for people to make up their own minds.
 
Last edited:
I can imagine that he light from the candle looks different because the candle looks different :)
Thanks for doing this test, I think a prime lens might bring out some of the subtle differences.
The stock firmware looks fine to me, nice and sharp on the bricks.
 
You must log in or register to reply here.
Back
Top