@tblackman, amazing results, i also use Cake 2.1 for now on both GH2 and GF2, very stable and good quality ...

Can someone enlighten me about the difference between the Cake 24h and 24L modes? I can't find any information about the 24L. I am looking for the stability/reliable spanning for longer recordings. I have currently used the Cake 24H and it has been working good. Just a little nervous to use it during a paying gig.

interesting. Could someone else test this with hbr 25p?

Thanks for all of the feedback. I'm pleased that the settings are working well for a lot of people.

towi, but it didn't crash, right? ;) In HBR 25p I'm using GOP3 and a max average bit rate of 45 Mbps, which is fine for normal scenes but obviously insufficient for very high quality in highly detailed scenes. Increasing the GOP length is not something I'm willing to do, because that would force me to lower the bit rate in 24p and VMM. And you don't need to raise the bit rate by very much in HBR before you risk spanning failures. My settings aren't just "successfully tested" for spanning. They're designed in such a way that virtually guarantees spanning 100% of the time. If you can create settings that do better in HBR 25p, then good for you. :)

albertdros, you can test it.

smontoto, the bit rate in 24L is set about 15 Mbps lower than in 24H - not a very large difference. The bulk of my testing was in 24H, but it seemed stable in 24L. The way I've designed the settings doesn't give me the flexibility to have a 24L mode that's much lower than 24H and still give good quality. If you need lower bit rates, you should look at other settings like Cbrandin 44M or Sanity.

@balazer

"towi, but it didn't crash, right? ;)"

Right. However the footage is unusable.

"In HBR 25p I'm using GOP3 and a max average bit rate of 45 Mbps, which is fine for normal scenes but obviously insufficient for very high quality in highly detailed scenes. Increasing the GOP length is not something I'm willing to do (...) If you can create settings that do better in HBR 25p, then good for you. :)"

bkmcwd's "Natural", "GOP3ZILLA" and "GOLGOP13" are all 3GOP settings ... and they work great in HBR/25p mode ... However they do not span in HBR/25p mode ...

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

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.

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

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.

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.

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

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

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.