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
  • cbrandincbrandin
    Attached is a variation of my 66M patch taking a completely different approach.

    So far most patches have attempted (deliberately, or not) to achieve a fairly high constant bitrate. In other words - bitrate has been king. This patch takes an entirely different approach. In this patch measured quality is king, and bitrate use and buffering is allowed to vary.

    The basic architecture of a VBR H.246 codec is to set up boundaries for min/max bitrate and QP settings. As a frame is encoded a range of QP (quality) values are attempted for each macroblock. The searching stops under one of two circumstances - either the macroblock reaches a quality level within the number of bits allocated for it, or the quality is degraded until the allocated bits are not exceeded. The problem with this is that the codec isn't perfect, so it may degrade the image somewhat before the frame is finished as all this is estimated, and few higher QP values are attempted.

    This patch allows many more QP settings to be attempted for each I frame. Thus if a desired quality level is reached with a higher QP value it will be used and bandwidth is made available for later macroblocks that may need it more. The best way I can put it is that this patch does more to use actual measured quality rather than theoretical quality.

    I've done some testing - but I would like additional input. Unfortunately, spanning is still an issue. This is pretty experimental at this point, so don't rely on this patch yet.

    Chris
    seth.zip
    522B
  • 60 Replies sorted by
  • clarkpnoyclarkpnoy

    Continous Focus test:

  • cbrandincbrandin
    @Stray is right - my original statement about P and B frames only maintaining quality related to static scenes. Big P and B frames can make a huge difference in motion quality. Think about it, if the scene changes a lot there isn't really anything to "maintain".

    If detail were improved between I frames you would get a very bad looking detail pulsing between them. most codecs are designed to avoid this.

    Chris
  • sam_sticklandsam_stickland
    @Stray Cool. I've just finished a 48 Hour Film Project entry on cbrandin's 66M settings, so I should have some more time for some testing myself now. Prior to this stable was very important!
  • StrayStray
    @sam_stickland It doesn't actually drop that low tbh, also the 66M patch here runs stable on AQ3. I've been shooting with it for a few days with no issues. Wouldn't be surprised to find it was also stable at AQ4. I created an 88M AQ2 the same way as this and it holds a high I-frame size under lots of conditions really well too. As for P and B frames maintaining quality, that really relates to a static shot I think. If there is a lot of movement then they're going to be holding a lot more detail and motion.

    I've seen a few times B + P frames climb higher in size than the preceeding I-Frame during fast motion and high detail leading onto a larger I-Frame in the next GOP.
  • sam_sticklandsam_stickland
    @cbrandin is there a danger that in allowing the codec to vary the bitrate on the I frame that it might pick a low bitrate for a low detail I-Frame that can't be improved upon by the following B/P frames - i.e. the quality is now low for the entire GOP?
  • Ralph_BRalph_B
    @driftwood
    This is veering off-topic for this thread. Let's continue in the ST: HDMI Team thread.
  • driftwooddriftwood
    @Ralph_B gettting the 1080p24 gh2 recordings which record at 30 fps hdmi .mov in the Ninja out of post at 24p, as Its probably different for other hdmi recorders I'm wondering if my solution on the GH2 + Ninja thread is quicker than using your AVIsynth variation/less painless for Ninja users?
  • Ralph_BRalph_B
    @driftwood
    Still not sure what you're asking.
  • driftwooddriftwood
    @Ralph_B The pattern removal of the hdmi to get it back to 24p, have you looked at the lower field?
  • Ralph_BRalph_B
    @driftwood
    What would you like to know?
  • driftwooddriftwood
    @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.
  • Ralph_BRalph_B
    @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.
  • proaudio4proaudio4
    Ralph, so you're also seeing this at 132M 3GOP?
  • bdegaziobdegazio
    @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_BRalph_B
    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_BRalph_B
    @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.
  • StrayStray
    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).
  • driftwooddriftwood
    @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.
  • kronkron
    @Ralph_B ISO 6400? Is that a patch setting, or just pushing the exposure on A mode?
  • Ralph_BRalph_B
    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]

  • StrayStray
    @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.
  • stoneystoney
    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.
  • driftwooddriftwood
    @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.
  • cbrandincbrandin
    @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
  • proaudio4proaudio4
    hmmm...
    WTF, it looks like it's improved from your data. Was there a shift in anything detail, focus, light ?
Add a Comment