75Mbps GH1 Peak Performance Patch

Gorgeous footage, Alfonzo! I especially like the gliding shot at 0:33 with the out-of-focus foreground branches obscuring the crisply-focused trees in the background. Really love the color grading at 0:20 as well.
 
Thank you very much for this information.

If 24p requires a GOP length exactly divisible by 5, would it be possible to shorten it from 15 frames to 3 frames? Also would it be possible to shorten 60p to the same 3 frame GOP? I suspect that if it is possible, then some of the other settings would also have to be modified. Suggestions? Thoughts?

Most of the video I've been taking is of fast moving subjects. So would love to have a patch that optimizes AVCHD for this while still retaining peak performance for MJEP in 4:2:2 color


Yes, the patch values must look pretty arcane without any explanation. Here are some notes on how it all works:

* NTSC 24p and PAL 25p are locked together with the same patch settings (except for GOP length).
* NTSC 60p and PAL 50p are locked together with the same patch settings (except for GOP length).
* 24p and 25p are interlaced, 50p and 60p are non-interlaced.
* 24p requires a GOP-length exactly divisible by 5 (due to telecining).
* I could not fully stabilize a 24p GOP-length shorter than the default 15-frames, so I left it unchecked.
* 25p actually needed a longer GOP-length to stabilize it at a 75Mbps peak bitrate.
* Video Bitrate of 54000000 produces 50Mbps target bitrate limit.
* Overall Bitrate of 72000000 produces 75Mbps peak bitrate limit.
* Preset Bitrate was increased to help stabilize 24/25p at the 75Mbps peak bitrate.
* Preset Bitrate 2 needed no adjustment to stabilize 50/60p.
* Constant for 1080p helps balance 24/25p average/peak bitrates.
* Constant for 720p helps balance 50/60p average/peak bitrates.
 
If 24p requires a GOP length exactly divisible by 5, would it be possible to shorten it from 15 frames to 3 frames? Also would it be possible to shorten 60p to the same 3 frame GOP?
No, the only interlaced 24p GOP-lengths that are exactly divisible by 5 are 5, 10, 15, 20, etc. Unfortunately, 24p GOP-lengths shorter than 15 are unstable. For 60p video mode, GOP-lengths shorter than 20 degraded long-term stability at 75Mbps peak. My Fast Action 3-Frame GOP Patch was able to dramatically shorten the GOP-length by cutting the 60p frame rate in half to 30p. That will not work reliably at 60p.
 
No, the only interlaced 24p GOP-lengths that are exactly divisible by 5 are 5, 10, 15, 20, etc. Unfortunately, 24p GOP-lengths shorter than 15 are unstable. For 60p video mode, GOP-lengths shorter than 20 degraded long-term stability at 75Mbps peak. My Fast Action 3-Frame GOP Patch was able to dramatically shorten the GOP-length by cutting the 60p frame rate in half to 30p. That will not work reliably at 60p.

@ipowell - Have you looked at this thread about the 100MB/s AVCHD? http://www.dvxuser.com/V6/showthread.php?236855-AVCHD-1080p-GOP-1-100-Mbps
 
Yes, good luck with stabilizing Native 24p at over 100Mbps! I've found it very difficult to reliably control high bitrates at extremely short GOP-lengths. Unfortunately, the early 3.36 version of PTool required by that patch does not support all of the stability adjustments that are used in the Peak Performance Patch.
 
Understood.....Thank You.

I currently use your wonderful Fast Action Patch and love it. Will try this new patch next week and see how it works for me.

You and your work are greatly appreciated!


No, the only interlaced 24p GOP-lengths that are exactly divisible by 5 are 5, 10, 15, 20, etc. Unfortunately, 24p GOP-lengths shorter than 15 are unstable. For 60p video mode, GOP-lengths shorter than 20 degraded long-term stability at 75Mbps peak. My Fast Action 3-Frame GOP Patch was able to dramatically shorten the GOP-length by cutting the 60p frame rate in half to 30p. That will not work reliably at 60p.
 
thx lpowell , this is the most accurate and update i been looking for. I have all 3 hackable cameras gh1 gf1 and g2 ,on gh1 i still get error when use native24 even at 24mps, so i thinks for non 24fps work the hack camera is more prefer because it can do much higher bit rate.

And for 24fps works better go for gh2 or af100 (I gone with Af100 for sdi) my should be here in 2 days :).

I had the WORST error at the worst time last Friday on my GH13 with native 24p on an important event shoot, I still got the 1.4gb file on the sd card that can't copy or playback (still hope to salvage it) the clip was about 8min in very bright mid day, when i monitor and think this better not hang, or may be i should stop record just to be save. But NO i decide not to. so a few secord later it did hung.

if this was one of my movie I could just redo the scene again , but for an event i lost that moment for ever, im not complaining and lucky we have other vdo shooter as well, but as camera 1 it bad to loss the money shot. SOooo just be AWARE that native 24p can repeat can cause error.

I guest perhaps this is why not even panasonic can make GH2 to do both 24/25p.

Thx again this new patch work well i test with big tree shot and very sunny today no error. And from now on I will use af100 for 24p
 
Yes, good luck with stabilizing Native 24p at over 100Mbps! I've found it very difficult to reliably control high bitrates at extremely short GOP-lengths. Unfortunately, the early 3.36 version of PTool required by that patch does not support all of the stability adjustments that are used in the Peak Performance Patch.

Luck is what we all need with achieving patches that improve performance.

What I have experienced with humpmans original settings may not be stable in the most extreme cases. But for what ever reason it seems to be getting close with using v3.36 of ptools. I did some mods to humpmans settings with an unchecked the native 24/25p setting and had an increase to 27 mbps compared to the 11 Mbps with your current 75mbps peak performance v3 patch of the same subject and camera setup.

Does the increase in bit rate mean a better quality result or does it show that the patch is less efficient in compression? What would constitute a better image quality when adjusting patch settings. I'm not looking for the perfect stable patch that may not stand up to high desity detail. I have a few patches that have worked great for that. I'm just trying to see if I can get a better quality result when filming a controled lower detailed subject.

 
Last edited:
quote_icon.png
Originally Posted by Svart
Regardless of cards, the Native 24p patch has been shown to be buggy. That alone should invalidate any further testing of cards since you are now dealing with an unknown situation where you could be getting any number of odd I/P frame multiples or bitrates and you are now operating outside of the normal AVCHD design.

Yes it might *work* but what happens when you find yourself in the situation where it doesn't? There are plenty of people posting videos where they have gotten the "card speed" error unexpectedly while shooting something in Native 24p. While this might be OK for some folks, if that happens to me on my upcoming shoots, I'm screwed. I'm not willing to take that risk.
 
I did some mods to humpmans settings and had some success with my test shots of an increase to 41 mbps compared to the 13 Mbps with your current 75mbps peak performance patch of the same shot and camera setup. Here are the results.
rigs, are you certain the video labeled "lpowell 75mbps performance patch" that you uploaded to Vimeo was in fact recorded with the current version of my patch? I downloaded the original video from Vimeo and examined the 38700463.MTS file. Stream Parser indicates that it is a Native 24p video with a GOP-length of 10, which is not a format that would be recorded by any version of my 75Mbps Peak Performance Patch. If there is some mistake here, please correct it as soon as possible.

Whatever the source of this particular video may have been, it's a good example of how efficiently the AVCHD codec can encode scenes composed of softly-focused, low-detail static objects. In this case, the encoder needed to use only about 13.5Mbps on average to produce results visually comparable to the video labeled "GH13 ptool 3.36 100 mbps test". Since the latter video is composed entirely of intra-frames, it required an average of 43Mbps, which is over three times as many bits. In both videos, however, the individual I-frames required only about 1.8Mb to encode, which I've found to be fairly typical with moderate-detail images.
 
Sorry Ipowell I used an older verion of your patch. I did an updated test using v3 of your patch and have corrected my post and findings
 
I tested so many variants, with unchecked native 24p/25p and with GOP 1, all variants was unstable, actually when GOP 1 and native 24p/25p unchecked, there still exist P frames, i tried many variants of Bitrate Settings, but all videos was with artefacts. And i back to this lpowell settings.
 
Sorry LPowell I used an older verion of your patch. I did an updated test using v3 of your patch and have corrected my post and findings.
Thank you for acknowledging this mistake and correcting your Vimeo page appropriately. I downloaded your two new video files from Vimeo:

38711938.mts - "GH13 ptool 3.36 100 mbps test"
38711238.mts - "lpowell 75Mbps performance v3 patch"

Stream Parser identifies the 38711238.mts file as a 24p video wrapped in an interlaced 60i container, with a 15-frame GOP and a max bitrate limit of 73.5Mbps. This is the type of video the Peak Performance Patch produces in FHD 24p video mode. The low average bitrate and consistent pattern of I-frames and P-frames are typical of static, low-detail scenes that the AVCHD codec can encode in a highly efficient manner without significant loss of detail.

The "100Mb Test" 38711938.mts file showcases an interesting malfunction of the AVCHD codec when it's patched with an unstable GOP-length. Although it does not use the Native 24p patch, this video appears to have a one-frame GOP and a max bitrate limit of 110Mbps. Its average bitrate is around 29Mbps, produced by a consistent, aberrant pattern of four I-frames followed by a single P-frame. Near the end of the video, the P-frames degenerate into malformed data frames that Stream Parser cannot identify.

Does the increase in bit rate mean a better quality result or does it show that the patch is less efficient in compression? What would constitute a better image quality when adjusting patch settings? I'm not looking for the perfect stable patch that may not stand up to high desity detail. I'm just trying to see if I can get a better quality result when filming a controled lower detailed subject.
When the AVCHD encoder is working with low-motion, easily encoded subject matter, each GOP will contain a large I-frame followed by a sequence of small P-frames. When scene motion and/or detail is increased, the encoder allocates more bits to the P-frames and if it doesn't have enough bitrate available, it may be forced to reduce the quality of its I-frames. It is these extreme cases where increasing the encoder's maximum bitrate can produce significantly higher image quality.

With a one-frame GOP, the AVCHD encoder produces nothing but I-frames, and the bitrate naturally rises to handle the need to encode each frame separately. You can evaluate the resulting image quality by measuring the amount of bits allocated to each I-frame. In your 38711938.mts 1-frame GOP video, peak I-frame size is about 1.2Mb, which turns out to be the same as the I-frames in the 38711238.mts Peak Performance Patch video. Aside from the dysfunctional condition of the one-frame GOP video, this indicates that both videos will look very similar in image quality. So in the case of this test, the Peak Performance Patch is performing much more reliably and efficiently than the intra-frame encoder, and with no significant loss in image quality.
 
Last edited:
This weekend I continued to use the v3 Peak Performance patch in this thread and experienced no failures! Nothing but stunning video clips. I visited the Sea Lions congregating along a beach north of Hearst Castle in California. The Sea Lions give birth and mate for the next round here at this time. There were thousands of Sea Lions and hundreds of pups. The weather was overcast, breezy and cold, but all my video clips were simply awesome. I think this is your best hack, lpowell. I thank you for all your work and for sharing it and your expertize... Al
 
First off thank you for all your hard work on your patches. I have been using the fast action patch, 60mps mjpeg, and love it. The only errors I have are sometimes when hitting record on something complex (which can be avoided by blocking the viewfinder before hitting record), an error occurs immediately, or the bit rate hits over 72mps somewhere in the scene. Cards used , Transcend class 6, Delkin Class 10.

Using this patch, I have had no errors on a Delkin class 10 card, so far. And am very happy with this patch. Any chance I can go into ptools and change the frame size to 1280x720 for mjpeg?
 
Is there any advantage to score a 25p native for PAL?
Unlike the case with interlacing 24p into an NTSC 60i video stream, 25p does not require 3:2 pulldown for interlacing into a PAL 50i video stream. Since the 25p frames are evenly divided into 50i fields, it is a simple process to deinterlace them in post without loss of image quality.
 
I tested so many variants, with unchecked native 24p/25p and with GOP 1, all variants was unstable, actually when GOP 1 and native 24p/25p unchecked, there still exist P frames, i tried many variants of Bitrate Settings, but all videos was with artefacts. And i back to this lpowell settings.
Thanks for your efforts to find a high-bitrate Native 24p patch. I know from my own experience how challenging it is to test the encoder for reliability at extremely high bitrates!
 
Back
Top