40Mbps AVCHD High Reliability Patch

LMGvideo said:
Shot this at an ISO of 200 in a mixed lighting environment with a manual WB of 5200k. We just used the bar practicals, the light from the front windows and a Chimera as a "natural" wash for the talent. The shoot involved a DVX 100a, an HVX200 and my GH13 (used as the wide shot). Shot using the SH settings to better match the SD footage. I'm going under the assumption that the patch works in the SH setting.
Click to expand...
Yes, the patch has been tested in SH, H, and L video modes as well as FHD.

Thanks for posting sample images, they illustrate important color balancing principles for shooting video with the GH1. The crucial step is the one you took before shooting: evaluate the light sources and fine-tune your color temperature and color correction in-camera as closely as you can. The GH1's Bayer sensor provides raw 12-bit color data to the firmware, and it does a very good job of color balancing when it's properly tweaked. You can't push it nearly as far in post because the encoded pixels contain at best 8 bits of color data.

The other technique you used well was to lower the contrast and saturation in your Film settings. While this produces dull-looking images out of the camera, it gives you finer granularity in tonal range. As is visible in your processed samples, contrast and saturation can be easily recovered in post, but only when you have high quality images to work with.
 
I just hacked using your settings. Went perfectly. Thanks.
I also filmed with no hitches whatsoever on a class 6 card.
 
LPowell, thanks for the feedback on this, I agree with your assessment. Coming from an EX1, there was quite a bit of latitude in being able to adjust the image in post, so what I'm hearing is that with the GH13, it's important to get really close at acquisition. I think my next tests will be using different in-camera image settings to see what that would offer. Do you have any settings that you've found seem to work well with this patch?

Given that the compressed image has 8 bits of color data, have you found any differences in the quality by using different codecs when transcoding? I used ProRes LT for this particular shoot, have you had any experience with Cineform or ?? that makes a difference in post processing?
 
The patch simply increases the maximum bitrate to the highest I've found reliable. It will work with any Film setting, and I agree with the general consensus that Smooth with -2 settings produces the most gradable results. For incandescent lighting, I like the subtle sepia bias of Nostalgic with -2 settings.

For best grading latitude, the patch's 35Mbps MJPEG mode produces 4:2:2 color depth, whereas the AVCHD encoder only supports 4:2:0 color. In addition, the MJPEG encoder's average bitrate holds up better in low-light conditions than AVCHD.

Note that the 8-bit YCC resolution of both MJPEG and AVCHD encoders is best-case, whereas the 12-bit GRGB Bayer sensor resolution is not degraded by compression. With MJPEG and AVCHD, you will only get near-8-bit resolution under well-illuminated, high bitrate conditions. In less ideal situations, YCC resolution will be compressed down to as few bits as the encoder can manage.

As long as you transcode to a 4:2:2 format with a decent intraframe bitrate, you will lose no significant quality in the process.
 
lpowell,

I've been playing around with your settings. As you might imagine I have a large collection of test clips I use for testing Stream Parser that exhibit all kinds of faults and image problems. I've tried my best to break your settings and have had no success whatsoever. They produce a very nice bitrate, the images look great and stability is there too. These are now my standard settings. Thanks!

Chris
 
yay!
me too - after many variants and much testing i think lpowell's settings are holding good for me too - thanks so much all you ardent testers.
Summat I still don't get is why the MJPEG files look SO much smoother and more saturated than the AVCHD settings: I'm tempted to stay shooting the MJPEG but of course 1280x720 just is not quite the size of 1920x1080, and therefore not really "HD" as such: Does size matter?
yeah yeah, ask any girl, but what I need to know is, does anyone think there's enough quality contained within the MJPEG 1280x720 to upres it (fake 1920?) without it showing too much? waddya think?
thanks again for some great setttings, you guys rock
 
Thanks for confirming my results, Chris. Your GH13 Stream Parser was the crucial analysis tool I needed to thoroughly test my AVCHD settings. I could not have done it without your assistance.

One question, the maximum bitrate displayed in Stream Parser rises in coarse steps of about 11Mbps as AVCHD settings are increased. How did you determine this number from your analysis of the AVCHD file?
 
Good question. The maximum bitrate is calculated from the TS timecode increment, which governs the camera's writing to flash. When settings are put in the camera it calculates the minimum time-slice between packets accordingly. This number represents the minimum time allowed between 192 byte packets and thus the maximum possible bitrate the camera can produce. It does change in rather crude increments. The settings you found are just below the next bitrate (56Mb, or so) that results from the "C" settings. At that bitrate I can get occassional failures. The rate you found is the highest rate (I believe) that is stable all the time. It might be worth looking into exactly what the maximum settings are before it jumps up to the next level, although I think you're close to that anyway.

Chris
 
Thanks for the explanation Chris. It confirms what I suspected, that the C settings reduce the time available to process each packet to a rate where it will occasionally fail. I did consider fine-tuning my 44Mbps max bitrate settings to the next significant digit, but it wouldn't have improved the average bitrate by any more than about 1%. Since the bitrate jumps dramatically when it crosses each max bitrate threshold, I felt it would be more reliable to stay safely below the point where it increases, rather than fine-tune it right up to the edge.
 
Also, the time increment is fixed. When the bitrate is low (like with low detail images) the camers just skips time-slots. If the increment is xxx, a packet can be written every xxx timer ticks (it's based on the 90KHz clock). If the camera doesn't need to write that much data it simply doesn't write anything in that time window. So the time between packets will always be a multiple of xxx.

Chris
 
I agree. I think we are seeing a limitation of the camera, not so much the flash. True, a faster card will slightly improve things - but probably not enough to be able to handle the 11Mb jump in bitrate reliably.

Chris
 
After testing thoroughly, grass, trees, panning, auto focus, blue sky etc. i am happy to say these settings work well on my Sandisk Ultra 4GB 15Mb/s SD card.
Thank you.
Paul
 
i'm a bit confused. it seems like the settings are no different than any previous setting with 24p unchecked. haven't the majority of shooters been able to up the bitrate as long as they were shooting without the 24p patch? wasn't the goal to shoot with native 24p without any hiccups?
 
The lpowell settings have slightly lower peak bitrates than the C settings. The main difference is that the lpowell settings don't stress the flash writing routine as much and they leave some extra processing power in the camera for other things (like compression, etc...). This results in better stability. Where I can still get the C settings to fail under some circumstances (especially in SH mode) the lpowell settings have proven to be completely reliable. Also, lpowell has set the MJPEG settings as well to quite usable levels. These settings affect each other to one degree or another, so it's nice to have a complete set that always seem to work and look good too - and lpowell has provided all that. I think the point of his settings were to find the maximum settings that are completely stable - go lower and you lose quality - go higher and you lose some stability; the devil is in the details.

Chris
 
Last edited:
I'm using a little lower Video bitrate (36 Mbit/s), a higher Audio bitrate (384 kbit/s) and Native 25 FPS (no interlacing wrapper) with FHD recording without any problem on a SanDisk 32 GB Class 10 (200x) SDHC.

I really don't see why the Native sensor output option would yield problems. If anything this lowers load on the card-writing as well as on the video-processing of the GH1. If checking the Native mode causes problems, the reason MUST be something accidentally linked.
 
You must log in or register to reply here.
Back
Top