GH2 Cake v2.3: reliability and spanning in 720p, HBR, 24p, and VMM at 2-2.5x stock bit rates

balazer

I am starting this topic to discuss ways to achieve constant quality encoding with variable bit rates. This idea can be applied to GOPs of different lengths.

balazer

Cake v2.3, for the GH2 v1.1 firmware image and PTool 3.64d or later

Designed for reliability and spanning in 720p, HBR, 24p, and Variable Movie Mode (NTSC and PAL)
2 - 2.5 times stock bit rates
SanDisk Extreme cards recommended, Class 10

Cake was designed with stability and spanning in 720p, HBR, 24p, and VMM as its highest priorities. It is intended for event coverage, where long recording times and reliability are required. For each mode I've set the bit rate limit with a wide margin of safety below the highest bit rate that is stable and spanning, to allow for variability in the rate control. This gives high confidence that the settings will span each time when you use a recommended memory card, even with erratic motion, high ISOs, or ETC mode.

For an even wider margin of safety, use a SanDisk Extreme Pro 95 MB/s card.

Of course image quality is also a priority. Rate control is primarily by adaptive quantization, very similar to how the stock encoder settings work.

Cake is optimized for 24H, HBR, and SH modes. 24L and H modes are set approximately 15-20 Mbps lower.

Cake release history:

1.0: initial release; for v1.0e firmware; rate control using frame size limits
1.1: rate control using fallback mode
1.2: for v1.1 firmware; adds support for all AVCHD modes
2.0: rate control using adaptive quantization; improved quality in HBR
2.1: adds spanning in 720p
2.2: improved rate control in 24L
2.3: improved rate control in 24H

balazer

Quality is subjective. A proper constant quality encoder will have models of human perception of quality, and try multiple quantization parameters on each macroblock until it finds the one that yields the quality it is targeting.

The GH2 has nothing so complicated in its encoder, but you can get very close to constant quality by using a constant quantization parameter or auto quantizer setting, while having no frame limit or bit rate limit to constrain the frame sizes and raise the QP. In my testing, I've found that this approach yields nearly identical quality in I-frames and P-frames, with no need to change quantizer table assignments. With stock quantizer table assignments, B-frames are way too small and don't match the quality of the other frames, even when they have the same QP. My observation of the B-frames in Flow Motion is that they don't match the quality of the I-frames as closely as P-frames do even with stock quantizer table assignments. Perhaps there is additional work that can be done to get B-frames to match more closely, but personally I don't see a lot of value in trying to include B-frames, since P-frames are not that much less efficient.

Generally you don't want to have truly unconstrained bit rates and constant quality: we have hardware limitations, after all. In Cake, I keep the GOP size small enough to span by limiting the frame sizes to 3.33 megabits, which if all the frames are that size, is 80 Mbps in 24-fps mode. Without that limit, the bit rate for QP22 can go as high as 100 Mbps when you shoot at ISO 12800. Using a frame limit is not ideal, since you will in some cases be limiting the sizes of I-frames even when you are not at 80 Mbps, which will decrease their quality relative to the P-frames. For a frame limit of 3.33 megabits and QP of 22, the limit is really only apparent on the I-frames for high detail, low noise, low motion scenes (ISOs 250 and below on a tripod). Once you add a bit of motion or noise, the I-frames fall below 3.33 megabits. In high noise, the frame limit makes the I-frames have lower quality than the P-frames, but you'll hardly notice such a small difference among all that noise.

Ideally we could use the GH2 encoder's bit rate limiter to keep the GOP sizes small enough to span, instead of using frame limits. That would open up the possibility of constant quality encoder settings at longer GOPs, like 6 or 9. GOP6 would be an awesome sweet spot for quality and efficiency. I'm working now on how to get the bit rate limiter to work correctly at GOPs shorter than the defaults.

Shorter GOPs span at higher bit rates. GOP12 spans at 32 Mbps; GOP6 at 60 Mbps; GOP3 at 80 Mbps; GOP1 at 88 Mbps or perhaps higher. My theory is that the camera is writing a GOP at a time to the memory card, and that the write operation needs to complete in less than some length of time for spanning to succeed.

And of course we know that with the faster SanDisk Extreme Pro 95 MB/s 64 GB SDXC card, GOP1 spans at 146 Mbps. But I'm not keen on using that card, because, besides being very expensive, SDXC cards suffer from the occasional "file limit exceeded" error. If you need long recording times, imagine what happens when you encounter that error: to continue recording to the same card, you need to reformat it. That's a frightening scenario, avoidable by having multiple cards on hand (expensive), or by offloading the data before reformatting (slow). And yes, there is the technique of recording a short clip after spanning and before turning the camera off to avoid the error, but I don't trust myself to always adhere to that protocol to avoid a disaster.

duartix

Ah, I've tasted this Cake before! :) And since it's a whole different approach (VBR) I also think it deserves it's own thread.

Thanks again!

qwerty123

@balazer when you say "cake beats it for everything else" you mean FlowMotion L50 and not 24H setting of FlowMotion, yes?

balazer

I mean for scenes that are not on a tripod or at ISOs higher than 250, Cake beats Flow Motion's 24L (50 Mbps) setting for quality.

Flow Motion 24H (100 Mbps) of course always wins for quality. The bit rate is always higher (more than double, on average) and it doesn't span.

balazer

Thank you, @duartix. I want to quote what you said in the other thread about Cake:

Cake test 24p @ISO3200 & Panasonic 14-42mm. Very reactive bitrate. :) Amazing quality and detail. Great grainy shadows. No blocks. Absolutely no noticeable difference between I/P frames in my eyes.

I'm looking forward to having more people try these settings out and let me know how they're working.

feha

@balazer interesting approach , would this be possible even for fw 1.1 when hacked ?!

balazer

I would think so, but we'll have to wait and see.

qwerty123

Thanks for your efforts balazer.

erw456

Just tested it. (Cake) Quality looks good. With Quantum 50, although also generally good, I sometimes got weird looking 'low resolution parts' in darker segments of an image. This looks more stable in the dark area's. I only tested it at ISO 160, since I like to minimize noise.

driftwood

Test, after test after test... listen up motherfuckers. Youre never gonna be happy.

Vitaliy_Kiselev

listen up motherfuckers. Youre never gonna be happy.

Amen

balazer

Thanks for testing, @erw456.

Just to be clear, there's no question that 100 Mbps and 146 Mbps intra patch settings will beat Cake for quality every time. If you need the maximum quality, Cake isn't for you. Cake is about increasing efficiency while maintaining consistently high quality and spanning with a variety of cards. Cake is an improvement over existing 44-66 Mbps patch settings.

duartix

@balazer :

1 - About B-Frames and after some footage observations, I couldn't agree with you more, neither can the WIKI: http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Controversies

2 - How's the progress on the bit rate limiter?

3 - The pitfall.

For someone that does his encodes in VBR for more than 10 years, this is now the approach that makes the most sense to me, however there is something that I wonder if it could be pursued to produce more satisfactory results: the L mode! In a perfect world we would have a bigger and different quantizer for 24L. But this is a Constant Quantizer ~ Constant Quality patch and there is only one quantizer parameter. Even though it works wonders on 24H because it's practically not limited, what is to be expected of 24L when all that is there to work with are bitrates and frame limits? It's a hard if not impossible task to make it Constant Quantizer/Quality. Could there be a solution in the quantizer/scaling tables? Or should we assume right away 24L will always be a fallback and shouldn't be used unless we're prepared to give up true VBR?

And isn't it strange that the GH2 works originally in 24H & 24L modes with the same quantizer?

balazer

Thanks to LPowell's work on Flow Motion, I have a new version of Cake that does away with the frame limit and instead uses LPowell's method of limiting the bit rate. This approach combines the best features of both patch settings:

GOP3 for better efficiency than GOP1
Consistently high quality at a variable 20-80 Mbps; under 50 Mbps, on average
Spanning. (tested with SanDisk Extreme HD Video cards)
Now you can have quality and spanning at the same time - no need to choose one or the other as you do in Flow Motion. The camera automatically varies the bit rate so as to achieve consistently high quality, using high bit rates only when necessary.
P-frame quality matches I-frame quality extremely well (better than Flow Motion's B-frames)
Frame sizes are unconstrained, for better quality in high detail scenes

I've done a fair bit of testing, and the results look extremely good. In the old version of Cake, I-frame quality could be limited for detailed, low motion, low noise video. But now for these scenes Cake does just as well as Flow Motion, and potentially better than 100-Mbps intra settings. Playing back footage shot on a tripod at ISO 160, the frames are so similar to each other that I thought my player was stuck, until I saw a truck drive by in the video.

At this point just 1080/24p and Variable Movie Mode are working. Other settings are copied as-is from Flow Motion, and might not work correctly.

In my testing, the patch settings are stable. But we'll need to have other people test before I can call these settings non-experimental. The new version is in the second post of this topic.

Big thanks to LPowell for making these new settings possible.

yrowan

I've been trying to follow these conversations about P-frames, b-frames, GOP, etc, and I have to admit it's over my head. I'm still not sure which patch I need. The real issue I find with the GH2, more than anything else, is noise. I just want decent bitrate, good motion, and extremely low noise (or as low as possible) in low light/low detail areas. Is cake what I'm looking for, or would I be better off with an older patch with a higher AQ level? I only need the camera to be stable in 1080 24p. Someone please help. My head is spinning over here.

balazer

The best thing you can do to keep the noise low is shoot at a low ISO. Do some tests and see how the noise increases at higher ISOs. Of course to shoot at low ISOs you'll want to do what you can with lighting, choose a fast lens, and keep the shutter speed as slow as you can tolerate.

If you shoot at low ISOs, your choice of patch settings doesn't matter too much. Cake, Flow Motion, Aquamotion, or Quantum 100 would all be fine. At higher ISOs, you're going to want to record that noise as accurately as you can, so it can be removed using Neat Video. Cake has no significant loss up to about ISO 3200. Above 3200, you'll be better off with 146-Mbps intra setting like Driftwood's Reaquanted or Seaquake, or Gop3zilla.

In the FAQs you'll find some generic patch setting recommendations and tips for low-light shooting. There's a link to the FAQs at the top of this page.

yrowan

I appreciate the response balazer. I know to keep my iso levels down. The problem I have is often my subject is lit but the background isn't. In that case the background is always noisy. Never heard of Neat Video, I'll have to check it out. What about Driftwood's Quantum v7? I saw some pretty impressive footage shot with that patch. Having trouble finding it though.

balazer

Quantum is still beta. There are other 146-Mbps intra settings that are stable and perform similarly.

nomad

And definitely check out Neatvideo, it can work wonders!

izash

@balazer Do you know if the 720P/60 mode works well in Cake 1.1? I need that sometimes? If not, what do I do to merge a good 720p/60 patch with Cake 1.1? Thanks Izhar

duartix

@izash : As far as I can recall, @balazer hasn't targeted the 720p modes in Cake 1.1. In principle you could merge them safely with FlowMotion. That's what I did for my TimeBuster patch.

balazer

what duartix said.

_gl

(bit late but) @yrowan, no patch will remove noise for you. In fact the high quality patches will preserve as much noise grain as possible, as the camera counts it as detail. That's actually a good thing, because the raw noise can be removed better later (with something like NeatVideo) than the splotches you get from noise-reduction or heavy compression.

_gl

@balazer, just tried Cake 1.1 with 1.1 firmware/3.64d - quick indoor test shows it working fine, with expected 24H bitrates (~50 average, 70+ top). Very exciting from reading your detailed description, I've been using Chris' 66mb as my go-to as it was totally reliable for me (except for spanning) & the right quality/filesize tradeoff.

I'll need to test outdoors in anger (will report back), but apart from the expected quality & motion increase and spanning @ similar file sizes, the lower GOP should also be faster to edit: win/win/win/win : ).

Mark_the_Harp

Thanks @_gl - just downloaded 3.64d and cake 1.1 and want to try exactly what you said above, so good to know my GH2 won't explode.

duartix

@_gl & @Mark_the_Harp : I believe you guys should wait for an updated patch since there's a lot of new GOP related settings that might need adjustment when transferred from the previous version.

balazer

@_gl, thanks for your report. But I've found that the rate limiting scheme in Cake 1.1 is not working in PTool 3.64d with the v1.1 firmware. For now I recommend sticking with the v1.0 firmware.

I believe PTool 3.64d should work the same as PTool 3.63d on the v1.0 firmware, but I haven't confirmed that.

My priority now will be getting HBR 1080/30p mode to work.

fatpig

Are there any plans to port cake to HBR mode? :)

_gl

@balazer, good to know (about rate limiting not working in 1.1) - but what effect does this have? Is there no upper limit (potential for write errors), or does it reduce general quality?

Mark_the_Harp

@duartix @balazer Thanks guys - for the moment I'll try out Cake with the 1.0 firmware using the prev version of ptools. Cheers!

Vitaliy_Kiselev

good to know (about rate limiting not working in 1.1)

You can use same limiting approach, but patches that need to be used are not the same (as 3.63 had ability to replace scaling table to another, not to change it entirely).

Mark_the_Harp

@balazar Hi there - I'm a bit behind the times here but because my computer was in many pieces I wasn't able to try out Cake when it came out, on the 1.0 / 3.63d ptools, and then I didn't go for it on the new version of ptools 3.42d. But I thought I ought to try it on 1.0 / 3.63d and it's amazing! Thank you - really good stuff. Looks wonderful - and I appreciate your work on it. If you can sort it for 3.64d it will become my go-to setting, but until then I'll keep this one. Thank you!!

balazer

Thanks, Mark. Work on Cake for the 1.1 firmware is progressing well.

balazer

New version of Cake for the GH2 v1.1 firmware image and PTool 3.64d, in the second post of this topic:

Cake 1.2:
- 24p and Variable Movie Mode at up to 80 Mbps
- HBR 1080 25p & 30p, 1080i, and 720p at up to 50 Mbps (PAL and NTSC)

Please test.

HBR seems to use the same interlaced encoding that 1080i uses, so I was unable to make HBR stable and span at the same bit rates I could for 24p and VMM. The quality is still good, but begins to suffer with prolonged high motion or above ISO 1250.

HBR 1080/25p is stable 10 Mbps higher than I set it, but it seems to share a setting with 1080/30p. I set it low enough to be stable with both. If you want 1080/25p and you don't care about 1080/30p, you can try raising Other Modes Top and Bottom bit rates by 10,000.

I didn't try very hard to get 1080i and 720p to work at higher bit rates. It might be possible.

Vitaliy_Kiselev

HBR 1080/25p bit rate settings are tied to 24p

This is wrong

because 1080/30p and 720/60p share GOP length and bit rate settings.

Also wrong.

balazer

edit: nm

Vitaliy_Kiselev

It is hard to understand that you are talking about.

As you are changing totally unrelated thing and making absolutely unfounded conslusions.

balazer

Vitaliy, you are right. I made a mistake in my testing. All PAL and NTSC modes are working in Cake 1.2. There was no reason for me to make a separate PAL version.

estib

Is it safe to use " Most to detail " for 1080p 30p HBR using Cake 1.2 ?

Kihlian

@balazer tested a little your settings 1.2. HBR mode: panning = 21165 kBits/s No moving objects and camera = 10739 kBts/s.
So the bitrate in HBR is not so high.
24P (moving) = 29443 kBts/s 24P still = 16766 kBts/s.
1280x720 50p = 18737 kBts/s

Playback in camera works, maybe sometime have to turn on and off to see the clips. Ex tele mode works.
I´m using a SanDisk HD Video Extreme 30MB/s.
There are changes in the Mjpeg too? Have some problem with it, don´t now if I made disorder in it settings, it don´t works..
I´m new in the hack. Hope thys help and look forward for your cake.

duartix

@Kihlian : Please reformat your post. The moving/still conclusions are very confusing. (edit) Thanks!

Mark_the_Harp

Thank you @balazer for this great setting (not sure if I'm allowed to call it a patch any more)!

My experiments with the prev version have been fantastically rewarding, and just tried the new version 1.2 with the 1.1 firmware / ptools 3.64d. Need to do a longer term experiment, but the pictures have a wonderful quality about them, and bitrates seem to work well to match the movement in the image. More importantly - looks absolutely great. Using a class 6 card, believe it or not!

My first quick trial with 14-140 lens / 24H / Handheld with wild zooming and ISO160 gave a bit allocation: max 64 248 892 / avg 38 244 284 / min 15 309 758 and perfect picture quality throughout that clip, whatever movement was happening on screen. So obviously if the image needs a lot of bits, you will get them!

The clip below is my second test, this time with much less movement which gives rates of max 33 278 556 / avg 29 741 610 / min 22 451 166. This shows the encoder is really responding well to need and giving exactly what it says on the tin - constant quality. Have a look at the raw mts (link below) shot at ISO320 using the 14-140 at f5 and 1/25, on 24H using standard film setting and -2,0,0,-2. Ignore the crappy on-mic sound of course - it's cold at home and the harps don't like that. Download and play with the original mts if you want as I think it takes grading well. It seems to produce a sort of "rounded" quality to the image. Don't know if that sounds flaky, but it looks nice even using the Panasonic lenses!

Link if you can't see it below is http:// vimeo.com /37112107 (just remove the gaps)

gameb

Nice cake with beautiful music, cheers Mark

balazer

Mark, thanks for testing. Looks good. (and sounds good!) The on-board mics are not terrible, but do you know how one would mic a harp? I may be able to recommend a mic that you can plug straight into the GH2.

@estib, you should not change the Auto Quantizer setting in Cake. Cake uses a constant quantization parameter. If you want higher quality, you can try changing the Quantizer for 1080 (or 720) modes to 20 or 18.

@Kihlian, thanks for testing. Glad to know ETC mode works - I hadn't tested that myself. The bit rate will be high only when the video demands it. HBR is the same quality as 24p, just with a lower limit. MJPEG settings were copied straight from Flow Motion 1.0 without testing. You can try using them as they are, or remove all of them.

_gl

I've done a quick outdoor comparison of Cake 1.2 vs Chris 66 (1.0E firmware). Two GH2 bodies mounted side-by-side (my 3D rig). Stats:

24H, 1min 39s, ISO160, (IIRC) F4.0

Cake 1.2: 592MB (Min/Ave/Max) = 48,505 / 49,162,211 / 81,036,126

Chris 66 : 603MB (Min/Ave/Max) = 48,505 / 50,170,214 / 70,510,484

Check out the attached pics (Still|Motion|More Motion). To my tired eyes they look very similar, but the still shot looks more detailed with Cake (check the finest tree branches that seem to smudge more with Chris66), but it seems that Chris' holds onto more detail during motion. However it could also just be differences in firmware (1.1 is supposed to have different NR), lenses and/or focus. Opinions?

I also don't see much motion difference in general (at least single-stepping), so I'm not sure low GOP really makes much difference to that. (I'll look at it again tomorrow with fresh eyes).

balazer

Thanks for testing. A short GOP was not my goal with this approach. If you can get all of the frames to be equal quality, the GOP length doesn't matter so much. The short GOP was necessary to make spanning work at these bit rates. Cake should achieve the same quality on every frame, motion or not, so long as the bit rate limit is not hit. Chris's 66 Mbps settings can look very good, but it depends on the shooting conditions. With low noise and low detail, it looks good. But when the detail or noise go up a bit, the B-frames become lower quality than the other frames. My approach is an attempt to prevent that. Chris is using a lower quantization parameter than I am. If you want the constant quality VBR approach with higher quality, you can change the quantizer to a lower value. You can also raise the 24p high top bit rate limit, though you'll lose spanning if you're not using the 95 MB/sec 64-GB card.

Mark_the_Harp

Hi @balazer @gameb Thanks! I was being a real tart in not actually tuning the thing - as for mics I do have a few but didn't bother for this test. I'm very impressed with the low noise levels (which I think are a result of the 1.1 firmware rather than the hack?) and the general quality of images - given this was in a fairly dark room at ISO320. I've had a go at doing some subtle corrections to the video I uploaded and really your patch does seem to cope well with a bit of messing about in post. I've done a repost of it with a bit of correction to give it some warmth and intimacy here: http:// vimeo.com /37143813 (remove gaps in url to visit vimeo page) or see below:

Can't wait to do more video with it!

@_gl Great test - to me that's really helpful. Interesting about the bitrates you were getting - and how close they were between your two patches. I've been using Chris's 66/44 patch on the 1.0 firmware up until now. I think you're right that 1.1 does have better NR in my limited experience of it so far.

@balazer (post above this) what exactly might I change where you say "If you want the constant quality VBR approach with higher quality, you can change the quantizer to a lower value". That's got me intrigued - if I can get even better with my very lowlife SD card. Where is that in ptools?

balazer

To increase quality, in PTool go to Patches for testers, AVCHD Movie Mode, Quantizer, and then set the 1080 and/or 720 quantizer values. Try 20 or 18. If you go too low, the bit rate will bump up against the limit.

The low noise levels come from using a low ISO and using encoder settings that don't add (much) compression noise. 320 gives exceptionally low noise when you avoid the ISO noise bug.

cosimo_bullo

@_gl - Extraordinary test! Great stuff.

@Mark the harp - Holy crap, you actually play the harp?!!! Great!

Howdy, Stranger!

Categories

Participants

Tags in Topic

Top Posters