d'oh! Still have too keep on looking for the perfect setting. A reliable one that spans in all modes and has a good 24L mode for long recordings, too. If that would be included one day -> whohoo! (anyway thanks for all the work you put into all that testing!)

@balazer thanks for the advice! (Cbrandin 44M and Sanity both span in all modes, right?)

Thanks for response and cake.

i restart camera settings and 24h is ok. 24L not ok. 24L look bad. Can be memory card problem?

izash, in my Cake 2.1 experimental timelapse version, only HBR 30p mode is changed. HBR 25p, 24p, VMM, and 720p work exactly as in Cake 2.1.

@balazer Please explain your Cake 2.1/Timebuster hybrid patch. Is 24H still the same as regular Cake 2.1? 720p/60fps? If I switch to PAL, will HBR work as usual? I'm still using Cake 2.0 and it is fantastic. Thanks!

Is This Normal? in 24L and 24H.Cake v2.1.No moving camera or action.I'll try later v2.0.

Here's a quick test I ran today using Cake 2.0 with a Voigtlander f0.95

And here is the same video with a much higher bit rate (9.17 GB) [210 Mbps bitrate upload]

I'm curious to see if there is any appreciable difference on Youtube.

towi, looking at the stock encoder GOP table settings, it's pretty clear that they refer either to frame/field counts per GOP. But the stock settings are all one GOP per half second (except for PAL settings which are one GOP per 24/50 second), so I don't know if the settings are actually per GOP or per half second. It makes more sense to me that they are per GOP.

One funny thing in the GOP tables is that some of the 720p settings are specifying an I-frame slice 2 count of 1, even though the theory would suggest no such slice exists in the 720p output. I just change this to zero in my settings, and it seems to work fine.

From testing it's clear that the GOP table values are used in rate control calculations. At stock GOP lengths, the encoder generates files with a max average bit rate around or just above the Top bit rate setting. But if you change the Top bit rate setting by much, or if you change the GOP length, the rate control no longer puts the max average bit rate around the Top bit rate setting. I believe that there are some encoder constants used in rate control calculation that PTool is not exposing, which would need to be changed when using non-stock GOP lengths. But without access to those, changing the GOP tables achieves largely the same effect with no apparent downsides.

In my settings I keep the GOP table counts in the ratio of actual frame/field counts per GOP. I don't know if the ratio actually matters. What I do know is that if I keep the actual ratio, lowering the sum raises the max average bit rate, and raising the sum lowers the max average bit rate. I start with the Top bit rate setting that I'm targeting, and adjust the sum of the GOP table settings while maintaining the ratio until I get the max average bit rate at or just above the Top setting. Doing it this way, the encoder produces equal quantization in I-frames and P-frames. But again, I don't know if the ratio actually matters. I never tested it while not maintaining the actual ratio. I'm not sure if raising the P-frame counts, for example, would make the encoder produce smaller P-frames while keeping the I-frames the same size, or if the I-frames would get smaller also. From one test, if I remember correctly, raising the P-frame counts lowers the bit rate, and raising the I-frame counts raises the bit rate. And I have no idea what would happen if you specify non-zero P-frame counts when P-frames are not present. I guess they are things for someone to test. But I'm quite happy with what I've been able to achieve while using the actual ratios, so I'm not likely to switch. I see a kind of beauty in not just getting the settings to work, but in giving the settings some truth, and using them closer to the way that I believe they were originally intended.

@balazer

"The values in the GOP table are counts per half second of the following:

• I-frame (progressive) or I-frame first field (slice 1, intra coded)
• P-frame (progressive) or P-frame first field
• P-frame second field
• I-frame second field (slice 2, p-coded)
• B-frame (progressive) or B-frame first field (slice 1)
• B-frame second field (slice 2)"

I have a question about the GOP tables. If we use a 3GOP with B-Frames (like in "GOP3ZILLA" or "Flowmotion" or so)... wouldn't it make sense to increase the P-Frames values (second and third value) rather than the B-Frame values? As P-Frames are not used in a 3GOP patch with only I- and B-Frames enabled this would increase the size of the B-Frames ... or is this a wrong assumtion?

"I try to keep the GOP table values in the ratio of actual frame/field counts per second of video"

My (limited!) understanding of the GOP tables is that they do not refer to frames/field per second. They refer to the GOP length. The checksum of the stock values is either 12 (once GOP12 for 24p) or 24 (twice GOP12 for PAL modes) or 30 (twice GOP15 for NTSC modes). What do you think?

I don't have slower cards to test, so I really can't say how they'll perform. All else being equal, lower bit rates are likely to span more reliably. If your card spans most of the time in 24H and SH, my guess is it will span 100% of the time in 24L and H. If you want more certainty about spanning, get your hands on some SanDisk Extreme cards. The 30 MB/s and 45 MB/s 32-GB cards are inexpensive. The 95 MB/s cards are the fastest in the GH2.

I believe Cbrandin 44M has not been updated for the v1.1 firmware image. It will work just the same as it did with v1.0e for all modes, except possibly for HBR.

@vstardust : This is a simple process that only takes about 1m. It's all documented here: http://www.personal-view.com/talks/discussion/2135/gh2-2.5fps-avchd-24h-timebustertimehbuster-2.0-settings-the-day-is-not-over/p1

First and since you are targeting HBR 30 you should download 24h TimeHBusteR http://www.personal-view.com/talks/uploads/FileUpload/d3/74771b9a22eaeb84dc143d8fd54b9c.zip

Then you have to decide decide what your SS is going to be: 2fps or 2.5fps? I advise on 2.5 because you will get a 360º shutter. If that is your choice there is little you have to do, you just load the 24h TimeHBuster Base version (which is setb.ini). Then (as documented) you uncheck "1080i50 and 1080p24 GOP Size" to fully preserve the 24p, 25HBR and VMMmodes and you just Alt+Click Cake 2.x. If you want a different shutter speed you'll have to change "1080i60 GOP Size" accordingly.

Save firmware, and there you have it: Cake HBusteR. :) But I can't guarantee you how it will perform on 24p now that B-Frames are re-enabled...

@balazer : I tried that (and my brain went on vacation with me for the last 10 days so I'm not so sure anymore) but even though at first I thought that the odd P-Frame Field that accompanies the even I-Frame Field shared the I-Frame Scaling Table instead of the P-Frame Scaling Table, I was under the impression that it came one field too late. That's why I ended up using regular P-Frame Scaling Tables. It could be a workflow bug of mine though...