Personal View site logo
Make sure to join PV on Telegram or Facebook! Perfect to keep up with community on your smartphone.
Please, support PV!
It allows to keep PV going, with more focus towards AI, but keeping be one of the few truly independent places.
GH2 Maximum Variation Experiment
  • 60 Replies sorted by
  • @cbrandin Gonna repeat the same test for 66M. Just in case.
  • @cbrandin I know you dont seem to use the 3600000 buffer but Im gonna give it a whirl changing it after this next test. I just find it more stable (more bandwidth). In theory you shouldnt have to... but who knows...
  • @cbrandin 66M tests on 0x2400000 video buffer (same conditions as 44M)
    Chart 1 OIS on 14-140 lens, 125 Shutter/800ISO Well Lit Room. very faint change in highlights (brighter) around 14 seconds.
    Chart 2 OIS off 14-140 lens, 125 Shutter/800ISO Well Lit Room. fine it takes me a few secs to move away from camera. The magic 0.53 delay. No removal delay errors. OIS off wins. :-)

    Overall, I think things are fine.
    cbrandin 66M 'QP maximum variation' - 14-140 lens OIS on - pappas death chart result.png
    1684 x 768 - 96K
    cbrandin 66M 'QP maximum variation' - 14-140 lens OIS off - pappas death chart result.png
    1686 x 835 - 180K
  • driftwood, was this at 3600000 buffer?
  • @cbrandin
    66M on the Driftwood favoured 36000000 video buffer. Same conditions as other tests. Safer bandwidth - better results - both on 0.53 crb delays with zero errors.
    Chart 1 OIS on 14-140 lens, 125 Shutter/800ISO Well Lit Room. The magic 0.53 delay. No removal delay errors.
    Chart 2 OIS off 14-140 lens, 125 Shutter/800ISO Well Lit Room. The magic 0.53 delay. No removal delay errors.

    Magic! Both Very good. :-)
    And still a bit more room to push it :-)
    driftwood 360000000 buffer change on cbrandin 66M 'QP maximum variation' - 14-140 lens OIS On - pappas death chart result.png
    1430 x 754 - 101K
    driftwood 360000000 buffer change on cbrandin 66M 'QP maximum variation' - 14-140 lens OIS off - pappas death chart result.png
    1496 x 802 - 118K
  • @proaudio4 the last test was.
  • thanks

    I take you left Chris's settings and only changed Video buffer 24p to 3600000?
  • @proaudio4 Yes, changed to 3600000... Still on 720p stuff so I havent got time to look at 88M - I know you and Stray are working on that - maybe you should follow Chris's lead here and look to adapt his settings for 88M. But try it on the 360000 vid buff too. Could get really good results.
  • So, that's all you changed in Chris's settings, the Video buffer 24p to 3600000?



  • hmmm...
    WTF, it looks like it's improved from your data. Was there a shift in anything detail, focus, light ?
  • @driftwood

    I know it's somewhat of an imposition, but could you re-run the tests with OIS off and using manual focus? The reason I ask is that in my tests I have noticed that the camera slightly changes focus every now and then, even in AFS mode. Also, OIS causes occasional tiny movements with a tripod.

    I would really like to nail down the video buffer issue and want to be absolutely sure nothing else is affecting tests.

    Chris
  • @cbrandin Sure. I can't now, but first thing tomorrow, I'll rerun the tests twice to confirm.

    Incidentally, for the record, Ive found these settings are specific to 66M and 44M with your checked settings. If you adapt them to say 24p at 110M, 55M, and 50M at 720p, 32M at 720p, 1080i60 etc... you get problems which suggests fine tunings to each settings.
    Good luck @Proaudio4 with 88M - you may have to find shifted settings.
  • Yes it's good idea to turn off OIS when a camera is on a tripod. By default AF-S would act like AF-C in GH2. Prolly you already know this. Go to Menu / Motion Picture / CONTINUOUS AF option OFF. Then AF-S wouldn't focus continuously. But that would disable continuous AF from AF-C. Basically AF-S and AF-C become the same mode for video. Quite annoying.
  • @driftwood Way ahead of you mate, I've been working on this approach to the 88M all day yesterday, still some problems at very extreme conditions so I'm still tweaking it.
  • HDMI COMPARISON TEST

    Here are three tests with simultaneous HDMI and AVCHD recording. The settings are:

    cbrandin 66M AQ2 (original)
    cbrandin 66M AQ2 (advanced)
    Driftwood 132M GOP3

    This is a nighttime test at ISO 6400.

    Rather than posting individual frame grabs, I've uploaded Photoshop TIFs with layers. I also lifted the levels to make the differences easier to see. The bottom layer is always the HDMI picture, and the top layer is AVCHD.

    IMPRESSIONS:

    cbrandin 66M AQ2 (advanced) is not as good as cbrandin 66M AQ2 (original). Red noise is more smeared and shadow detail is more smeared. Driftwood 132M GOP3 is a teeny bit better than cbrandin 66M AQ2 (original).

    [url]http://www.sendspace.com/file/g2dv4f[/url]
    [url]http://www.sendspace.com/file/9c2any[/url]
    [url]http://www.sendspace.com/file/4aali3[/url]

  • @Ralph_B ISO 6400? Is that a patch setting, or just pushing the exposure on A mode?
  • @Ralph_B Thanks, great test again. Dont wanna trouble you 'cus you are probably busy but there is one thing you could possibly do to add to that test. Stick Chris's original 66M AQ2 on a video buffer 36000000 and see if it improves a tad - to maybe 132M quality?

    All: Its worth noting that 132M is using GOP3 over the original GOP 12 employed on the 66M. Future test: Stick 132M on 12 GOP and analyse.
  • It's to be expected I think that the old AQ2 66M will provide better image quality than this 66M AQ2. I think it would make more sense to see if this patch, running at AQ3 or AQ4 provides better motion rendering as it can work with a wider QP range (as well as maybe at AQ3 providing the same, or better under some conditions, image quality as the old 66M AQ2).
  • @driftwood
    Good suggestion about raising 66M original buffer to 36000000. I'll try it. But, wouldn't 132M with 12 GOP just be a waste of bandwidth?

    @stray
    Also a good suggestion to try 66M advanced at AQ3 & 4. I'll test those. too.
  • There's something that's been bothering me for some time. No matter what settings and data rate are used, the noise on the AVCHD is always larger and somewhat smeared compared to the noise on the HDMI. It may not be that obvious on frame grabs, but it's noticable when you watch the movies at speed. The HDMI picture is subtly more refined.

    I'm wondering whether there's some sort of pre-filtering going on with the codec. Or perhaps there's some other parameter lurking in the darkness that Vitaliy and Chris haven't discovered yet.

    Or maybe not. Just thinking out loud.
  • @Ralph_B

    @vladnik has been contending for some time that there is a deblocking filter in the signal chain BEFORE AVCHD conversion. Check this thread: "AVCHD maximum image quality settings and testing" on page 6, or search within @vladnik 's postings. (Sorry I'm not sure how to reference a particular posting.)
  • Ralph, so you're also seeing this at 132M 3GOP?
  • @proaudio
    Yes, but don't freak out, it's very subtle. And I'm not sure, but the final encode at the end of post production might obliterate the difference, anyway.
  • @Ralph_B whoops! re: 132M with 12 GOP on 36000000 buffer: AQ to 4 :-) @Ralph_B have you looked at my HDMI + Ninjja posts? I need your reaction to this.