First, just load zip as attachment.
Second, use Patch Vault topic.

@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?

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! :(

@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.

@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.

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.

@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?

@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 I started writing a huge response then deleted it. Im not going to bother answering this. Do the testing.

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.

@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.

SANITY v2 is here with fixed buffers. I was also able to eek out a bit more bandwidth. Enjoy.

@driftwood
Yes, I'll check it out.