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 720p50/60 and 1080i60 Settings
  • It's time for SANITY!

    While great work has been done with the GH2 hack for improving the 24P picture, I've been dissatisfied with the quality of the 50/60P and 60i patches. The biggest problem is mud in the shadows, and that has been the focus of my work - to minimize it.

    So, may I present 'SANITY' - the patch that DOES IT ALL, and at reasonable bitrates. 'SANITY' produces the best 50 and 60 fps pictures you've ever seen from the GH2! Plus a sane 24P setting that isn't going to bust the bank - bkmcwd's superb 66M GOP12.

    "SANITY' is the patch I load into my camera and go out shooting, and don't worry about it anymore. And I bring back great looking footage no matter what mode I shoot in.

    'SANITY' has exceptionally clean 720 50/60P and 1080 60i. And of course, 24P.
    (however, I can't guarantee 1080i 50 because it's settings are tied to 24P)

    For those interested, the key to increasing the quality of 50 and 60 fps, is to use a larger GOP than the stock setting.

    1080 60i - GOP 18
    720 60P - GOP 39
    720 50P - GOP 30

    When you do this, all the stars align and good things happen.

    So, load it up and get a taste of 'SANITY'!

    NOTE: Only use FSH/SH mode for SANITY. Do not use FH/H.
    SANITY.zip
    622B
  • 254 Replies sorted by
  • First, just load zip as attachment.
    Second, use Patch Vault topic.
  • sorry, that is if you click that link, so please remove it
    SANITY.zip
    622B
  • @Ralph_B
    Gonna try it out tomorrow! How did you figure out to use longer GOP? Is it important to activate B-frames? Can you use say 24Mbts with 50p and still get good results?
  • @Vitaliy_Kiselev
    Sorry, but P-V rejected my zip. But when I tried later, it worked. Go figure.
    I created a new topic because I'm sure people will want to discuss this.

    @oscillian
    Just try it!
  • when i first saw this topic i was thinking.. did someone enabled the 1080 50/60p ? omg! a dream come true! i must see! but! nope! :(
  • @Ralph_B Check these charts, its not making good use of the buffers and slides rapidly. The GOP size could be interesting and this may well be the ideal setting to obtain clean 60fps, however the other settings need adapting I believe. Also the quality settings are not living up to the 'required' settings you have input producing good but not hi quality macroblocks. Can you upload some graphics tests for Sanity?
    ralphb1.png
    1644 x 928 - 518K
    ralphb2.png
    1608 x 882 - 653K
  • @driftwood, what do you mean "good use of the buffers"? If the buffer has data in it and it's not being overrun or underrun, that's good use. Buffer fullness isn't a goal.
  • @driftwood Ralph_B's experience with low GOP mirrors my own when it comes to 60P and 50P. It's been pretty dicey getting any of them to work in recent patches (and I'm certainly having major issues with 60P using SpanMyB***Up) and in the past I could mitigate them by increasing the GOP.

    By the way, has anybody else been getting weird error messages or problem when switching back and forth between PAL and NTSC modes on their GH2? I tried switching my (originally Australian) back to PAL for the first time since I applied the hack several months back and it's giving me trouble.

    *End my short hijack* ;)
  • @balazer You set your buffers up to equal xx0000 and bitrate to a height which will make use of the size of the buffer or vice versa. This is why I use buffer analysis as a first check - to fully make use of the buffer size and bring the bitrate up or down so that it is as close to the buffer fullness as possible. If you can plot a graph that is making very good use of the buffer then it is highly unlikely you will underrun or overflow and that you will achieve excellent data flow and at good cadence. Such tools are used for this reason.

    However, the overall total bitrate settings which include other settings (the bitrate hi /top/ low top/ bottom settings found at the bottom of ptools for example) will collectively enlarge or decrease the overall size. So even though Ralph's settings are fairly low on the initial bitrate, his other settings are actually upsetting something.

    The above graphs show on a recording of Stray's death chart for example that he has a lot more room available in his bitrate/buffer ratio - in other words the data rate of the recording is very low. Therefore you either lower the ceiling by reducing bitrate (giving yourself more recording time and not wasting space) or heighten the ceiling by lifting bitrate and further toggling with his ratios in hi/top/low/bottoms etc... in an effort to increase the data rate and obtaining better pictures. :-) Use trial version of elecard buffer analysis to test. What I'm trying to say is that buffer analysis tools can show a wider picture of what is happening to your data.
  • @driftwood
    I have a fundemental problem with Elecard - what buffer is it refering to? For example, in the screenshot you posted, it says the buffer is 27,419,648 (bits, I presume). But this number does not correspond to any buffer setting in ptools. In fact, it's not even close. It's off by an order of magnitude.
  • Its not supposed to. The buffer from the GH2 (as set by ptools) doesn't magically appear in any analysis software. The buffer shown on elecard is the overall video picture buffer. You can only plot the results of the encoded file. It is a calculation made up of the elements. The bitrate you set is there though and it shows how much of the buffer space in terms of size is being created from the total settings from ptools. Elecard handles lots of different codecs. It is analysing the AVCHD data as recorded. And different tools do different things. I'm not saying elecard is perfect - its an old not updated program suite - but it does the job very well. For example, 1080i60 GOP1 in Streamparser viewed as all i frames, shows the p (predicted) fields of the interlaced signal in elecard buffer analysis. Along with showing me how much the video buffer increases or decreases in size according to how much bitrate you set in ptools. It also correctly spots overruns and underruns where data goes skewith. I've found it invaluable but there are other tools out there.
  • The most annoying thing is for 60p no matter what settings I provide in ptools (inc drastic lowering of the frame buffer) I cannot get GOP1 working beyond 7 seconds on current sd cards at constant top quality (approaching 190,000 on streamparser) like I can get the other settings. And believe you me Ive probably done around 300 tests on 60p over the last few months. Ive played with everything. This is why I dropped down to GOP3 and although you can get satisfactory results - and AQ2, there is smearing on movements and mud in the highlights. The GH2 just isnt very good for 60p, yet 50p isn't too bad. However, I am trying big time now to improve GOP3 for it. and the next patch will confirm this.
    I am also analysing @Ralph_B's GOP of 39 as no one knows a picture better than him after his exhaustive testing. I would like to see some results showing why GOP39 is devoid of smearing. Whilst virtually everything is not.

    The hi/top /low top/bottom bitrate settings are rather temperemental that is why Ive chosen to stay away from them (ive been through hundreds of tests trying to impove things with them) but Chris @cbrandin and I both agreed that only very small increments were really required to perhaps stabilise things. I havent seen massive improvements utilising them - but I am there to be proved wrong.

    I think we're all in agreement though that 60p is a royal pain in the arse trying to find the best setting.
  • @driftwood

    Sorry, but I still don't get it.

    "The buffer shown on elecard is the overall video picture buffer." What does that mean? I can only assume it's refering to a buffer in Elecard. And as long as the clip plays back smoothly, what relevance is it?

    "The bitrate you set is there..." Where?

    "and it shows how much of the buffer space in terms of size is being created from the total settings from ptools." Again, what freaking buffer are we talking about! And where is it physically? In the camera? In Elecard? In the transport stream?

  • In Elecard's measurement reading of the AVCHD ts file. 'Declared bitrate' in elecard. See the graphic.
  • @Ralph_B, Elecard Buffer Analyzer plots the fullness of the decoder's coded picture buffer.

    The decoder's coded picture buffer is where coded frames wait temporarily after they've arrived and before they are ready to be decoded. In the case of rigidly timed streaming video, like terrestrial, cable, and satellite television broadcasts, the bits of each coded frame are dumped into the CPB as they arrive, right after demodulation and demuxing. When playing back an MTS file in software on a PC, the decoder might simulate a hardware CPB and dump coded frame bits into the CPB at their simulated arrival times (derived from the PCR time stamps embedded in the stream), or the decoder might not have a CPB at all, and instead just read the coded frames from the transport stream file or from a read-ahead buffer when the decoder asks for them. Frames are removed from the CPB at times dictated by information embedded in the stream, set by the encoder.

    The CPB exists so that coded frame bits can arrive at a rate different from the rate that they will be consumed at by the decoder. That's particularly relevant in situations like terrestrial broadcasts where the transport stream multiplex has a fixed speed: the buffer lets the decoder exceed that fixed speed, at least for a brief time. The encoder can fill up the CPB, and then tell the decoder to start pulling frames out of the buffer more quickly than they are arriving. It all works, so long as the buffer never overflows or underflows. The buffer is also relevant to the case where you have I, P, and B frames, since the decoder will need to pull several coded pictures from the CPB quickly just to decode the first B frame in the GOP.

    In the case of Intra coding from the GH2, looking at the CPB shows nothing very interesting. The encoder has a coded picture buffer of its own, and a model of the decoder's CPB. It has a simple feedback mechanism that ensures no overruns or underruns of either buffer: when its model of the decoder's buffer fills to a certain level, the encoder stops flushing coded frames from its buffer to the stream. When the decoder's buffer is nearly empty, the encoder flushes frames to the stream more quickly. (it's slightly more complicated than that, and the encoder seems to have a few different modes of operation. But the feedback mechanism I described is the essence of it) Since it's all I-frames, the decoder pulls frames from the CPB at a constant rate. Thus you see ups and downs as the feedback mechanism hits the different turning points. And if the buffer has more than a few frames in it, the amount of data in the buffer varies with the sizes of the frames.

    @driftwood, buffer fullness is not a goal. It's the sizes of the frames that matters - how much picture information you have in the coded frames. All that matters about the buffer is that it's not being overrun or underrun, and it's not. I really think this whole buffer fullness thing is a red herring. The buffer has space for lots of frames, so it's normal and expected and allowed for the buffer fullness to vary by a lot.
  • @balazer

    Thank you so much for that explanation! Just wondering, where is the size of the "coded picture buffer" set? Is it's size something that travels along with the transport stream, or is it set in the decoding software?
  • @balazer I started writing a huge response then deleted it. Im not going to bother answering this. Do the testing.


  • @Ralph_B, the coded picture buffer size is set by the encoder and written into the stream. Maximum buffer sizes are imposed by each level of the h.264 spec.

    @driftwood, you know I want to learn from you anything you're willing to share. I like to ask you lots of questions.
  • From testing this Sanity hack and from my own testing I believe the GH2 incapable of producing 60i video that is as sharp and detailed as it's 24p video. Maybe next years GH3 release with AVCHD 2.0 60p we will get 60fps video as detailed as the GH2 24p.
  • @balazer
    Do you see any place in ptools where you could change the coded picture buffer size?

    @zzap64
    You might be having unrealistic expectations regarding 60i. An interlaced picture will always be less detailed than a progressive one because of dual row readout. This has nothing to do with the hack. Check out this article by Adam Wilt.
    http://www.adamwilt.com/TechDiffs/FieldsAndFrames.html
  • @Ralph_B, my hacked videos have a really large coded picture buffer size, so it would seem that one of the hack settings is affecting it. But I haven't bothered to figure out which one.

    Interlaced video need not be any less sharp than progressive video. Dual-line readout is not a requirement for interlaced video. Of course without some kind of vertical filtering, you get a lot of interline flicker and vertical aliasing, which is why most interlaced video cameras have dual-line readout or some kind of vertical filtering. But film DVDs, for example, often have no vertical filtering.
  • @Ralph_B, the best thing for you to do is start reading the AVCHD standards, download some of the elecard trials and start by looking at maybe Elecard Stream Analyser or similar header viewer tools (you don't have to use elecard) so you can understand sequence parameter sets, picture parameter sets, and the hrd parameters etc...
    With these tools, you'll notice inside the encoded h264 files where in the hrd parameters the bitrate size is and the coded picture buffer size are to be found.
    In simplified terms, the size of the coded picture buffer is assembled from the various settings you instruct ptools to build (ie it will fluctuaate according to your settings) and the answer to how to view the total size is in the tools / the hrd parameters.
    With ptools we test to see how far we can push the GH2 ;-)

    For example:
    Some of the HRD parameters from Seaquake 1080p24H shows;-
    bit_rate_value_minus1[0] = 160040, cpb_size_value_minus1[0] = 112050...

    A typical 720p60 value Im currently working on produces;-
    bit_rate_value_minus1[0] = 94752, cpb_size_value_minus1[0] = 64896...

    There's loads of links Vitaliy has included throughout personal-view with some tremendous stuff in the quantise matrices thread.

    The reason why I like using the buffer analysis tool because it plots for me the bitrate, shows whats happening to the buffer;- the delay time of the buffer (before and after) and its cadence, and of course instantly shows underflows and overflows and where they happen. It also shows me the size of my i frames for my INTRA patches. I do all my tests with this, and the rest of the elecard suite. It's not perfect, but it works for me.

    @balazer So to answer your thesis on cpb - yes - its about the timing and buffer underruns and overflows, yet it also plots the maximum size you have set for it - allowing you to see the results of your ptools settings; therefore, if its much lower in fullness on death charts, trees of death etc... movement tests... whatever, then you can safely lower your bitrate setting, maximising data bandwidth and recording times.
    I am trying to simplify all this for the benefit of anyone starting out.
  • SANITY v2 is here with fixed buffers. I was also able to eek out a bit more bandwidth. Enjoy.

    seta.zip
    596B
  • @Ralph_B Yep, that looks great Ralph. Sanity 2 then ;-) Like it. Ralph, could you try out some of my encoder settings from 'Quantum' (low gop thread) and test them out with your settings for 720p? Just want to see if you see any further picture improvements - should be better QP.
  • @driftwood
    Yes, I'll check it out.