@terry2 It is VBR, and it will always be VBR, what driftwood has done is to make it behave like a CBR codec. The bitrates willl still alter dependent on shot, but not as dramatically. Its much, much harder to change the settings to make the codec behave like its CBR with a longer GOP, which is why ppl are noticing more bitrate variances with 720p footage.

@Adde well, driftwood has also changed the 720p settings with these new dark matter settings. He's moved away from using the Auto Quantiser and set the quantisers inital setting much higher. So it would be well worth trying 720p out again in various conditions (light/detail level) as it maybe won't have the same wide degree of variance now. I dunno on your other question, one to test, I figure it would be okay to shoot in bright light too, just need to test its response in the highlights too. As I understand it what Nick has done is mostly tweak the luma blocks (check out the colours too, wish I could find my colour card). @driftwood correct me if I'm wrong, I can't really test much at the moment, I'm just posting between non camera related work tests.

@ meierhans not saying it can't be played back. It can with Movist VLC but it does behave differently to 1.1 firmware files when you rewrap with Clipwrap. I think this is a valid point to make for people who rely on Clipwrap in their existing workflow. I use FCPX and my existing workflow with 1.1 GH2 HBR files was to use Clipwrap to rewrap the files as they would come in as 25i instead of p if you didn't. Fact is before hack Clipwrap works, after Orion upgrade it doesn't. 24p works fine I think

@peterosinski Rocket is your spanning solution for Sandisk 30 cards. Have field tested it numerous times (at least with 24h and etc)

Dark matter v3 - 12800 ISO why the hell not. Add some glass and have a flaregasm at the same time. If you're going to test low light and hit exposure, why not take it to the limit.

@driftwood I've dug into this a little and found the following comment on Wikipedia (http://en.wikipedia.org/wiki/Quantization_%28image_processing%29):

"Typically this process will result in matrices with values primarily in the upper left (low frequency) corner. By using a zig-zag ordering to group the non-zero entries and run length encoding, the quantized matrix can be much more efficiently stored than the non-quantized version.[1]"

So if I'm understanding correctly, the purpose of the quantization matrices is to improve the compression ratio. But if the aim is maximum image quality wouldn't it be best to set it to an identity matrix? Which would be all 16s for H.264 since it apparently does a division by 16 before using the matrix values - http://vcodex.blogspot.com/2009/08/quantization-flat-scaling-factor.html

I guess if I wanted to neat video everything I could get one of those awful lomo squarefront zooms and shoot at a 8 11 split and actually have a clear image.

Hi guys getting a little confused with all the new settings and matrices. Is it possible to use Quantum v9b with the 1.1 firmware with no problems? Is v9b still the most stable? Many people seem to be experience strange noise issues with Orion. Any advice would be welcomed.

Thanks

@rsquires: Ever tried to prepare sequences for professional mixing like Protools etc. in FCPX? For let´s say 32 tracks all cleaned up not to confuse the sound mixer:

Tracks 1- 8 dialogue, 9-15 foley, 16-24 ambience, 25-32 FX. Have fun with this task! (Or I missed an update...)

O.K, some further testing: Rocket VBR vs. Orion CBR. Just wild shaking and panning doing 2 min. recordings. Third party extensions like Perian and AVCCAM-Importer uninstalled. Clips directly taken from GH2 attached to USB. Quadcore i7 2.2ghz Macbook Pro 8GB RAM, Sandisk Extreme Pro 95mb/s, 64gB

Orion HBR: Looks great! Can be directly imported into FCP7 via Log and Transfer. Plays without glitches in VLC. Seems to play without problems in Quicktime after rewrap. But a drop in lightness when the shot pans across an overexposed window and you see interlacing lines. The field from earlier frame is superimposed over the actual field. This lasts about 4 frames, the everything plays fine again.

Rocket HBR: First rewrapped to .mov using Clipwrap: Play-stop-play-stop behavour in Quicktimev10 and 7. Then directly imported from camera to FCP7 using Log and Transfer, now it has become an interlaced ProRes422 file. Seems to play fluently in FCP7 "Viewer" window.

But he viewer window displays the upper field only.

On an external screen, which displays both fields, you see frames from previous and upcoming instances scattered all over and superimposed over the first field during the whole 1 min. recording.

So i guess, the roll-stop-roll behavour in Quicktime comes from unsuccessfully trying to combine upper/lower fields. And somehow CBR does not mess things up for Quicktime as much as VBR... (And unhacked HBR does not mess anything at all)

Again, VLC plays fine, but I need to edit, so I need Quicktime. But when I interpret the posts correct, FCPX/Lion does not seem to have problems with HACKED HBR-50i footage?

I posted stills from the frames affected. All the best, Frame

@Frame. HBR field weighting: try this for me. In GOP Related in 1080i60/50 try either 1, 1, 0, 0, 0, 0

Or

1, 0, 0, 0, 0, 0

Or if it isnt already ( i cant check at mo) try

1, 0, 0, 0, 1, 0

Oh yeah and...

Smooth -2, -2, -2, -2, SH Mode Rokinon 58mm - no filter f/1.4 Shutter: 1/50

Yes, page not found..