@Sage Premiere Pro sucks big time. It always did. I don't get the marketing hype. In terms of usability, it is one of the crappiest programs adobe has created. Bad icons, lots of wasted space everywhere, half of the programs functions can't be assigned to keyboard shortcuts, many keyboard shortcuts don't do what you expect them to do, when importing footage, you cannot see clips, you can't import & copy clips to a set location, there is no OpenCL acceleration on modern day iMac's en MacBooks, DynamicLink fails half of the time... I don't see what's good. Everyone hated Premiere until FCPX and now suddenly it is great... I don't get it. People used to laugh at you when you used Premiere and now it is amazing and nobody complains anymore. Very strange.

I like Avid 6 much better... to me that is FCP 8 64-bit. FCPX is nice but has a long way to go.

@sohus I guess you're still living in 2004. Remember to sell your stocks when you approach 2006.

@rbna Premiere imports and exports both Final Cut Pro and Avid projects.

With a powerful system and right ("certified") video card -- Premiere has been a dream since version 5, not even the newest Avid Media Composer competes. Here in the US it's somewhere in every studio, and I understand the BBC implemented Premiere Pro on a large scale last year.

You can import almost anything, stick almost anything on any timeline, and color correct anything you import in a 12 bit 4:4:4 color space. Stability is exceptional. On my system (that doesn't suck) I'm encoding out at real time -- or much faster for low end stuff.

Relative to the "hacked" GH2 -- the workflow goes like this: 1) import 2) edit 3) export.

@onionbrain So do you just use the MTS files through your entire workflow, not transcoding at all before editing / compositing / color correcting etc? Or do you Clipwrap or such into ProRes?

Even if AVCHD its not a great format for editing, if you aren´t doing any major grading you just don´t need to transcode...it saves you valuable time and disk space...

@driftwood There is no mention of AQ value in the Quantum v8 patch. Is that mean that it reverts back to the stock value which is AQ=0 (all to motion)?

@driftwood This is a very interesting arrangement! Although former homework has not been finished yet, I can study moreover. Thanks mate! :-)

@everyone Please continue the NLE debate here: http://personal-view.com/talks/discussion/1888/gh2-post-production-workflows#Item_39

@driftwood not sure what I'm looking for. You know the drill with my test by now. 14-140 with some slow and quicker zooms.

All of the 720p60 h and sh write failed. With af on/off with zoom fast/slow all of the 1080i 60 failed fsh and sh. Same as above.

They all write errored right around the 3-4 sec mark. This was with sandisk 30mb/sec. They even failed when the camera was motionless and af off.

Since all of these failed so quickly streamparser doesn't have a lot, no up downs since it just fails. 720p sh is 2pframe, 1 iframe, both right at 230000. Same on h, values a little lower.

1080i fsh all i frame at 450000.

same on 95mb/ sec just lasted longer.

for 24p: went out to 40 seconds before stopping(not fail, I just stopped filming). I frames in streamp show some up down values. From 510000 to 680000. One big drop to 340000.

I am moving the camera and periodically zooming in with af so that's to be expected, I think.

Something strange happened on the job today. I hacked my GH2 with quantum v7 yesterday and it seemed stable with 64GB 95MB/s card. But this morning on the job, after taking six footages (each footage about 3 minutes long), I got a message saying I reached the maximum numbers on files. I had to pull out d7000 while downloading the footages from GH2 and reformatted the card, then I was able to take a few more. When I got home, I realized that 6th footage was corrupted. Has anyone encounter this issue before?

@chauncy Qv8 is very experimental - I already know death chart failures. But under most normal conditions the bitrate will now go up and down rather than constant on streamparser/streameye etc... and the Q looks in some cases more stabilised. However, taming it is a bitch at this early stage. We keep going... we keep testing... but I need to see how good QP is performing and what is causing macroblocking with these settings. Thanks once again for your strict testing and results. Nick

Guys, this is where I'm at with Quantum v8. I am looking more at setting up AVC rate control so that it performs allocating bitrate to detail quality. Presently, limiting the frames (Frame Limit = 6080808) keeps things constant (ie it will always record fixed i frame size for all frames). This is nice and high but wastes a lot of space for details not necessarily requiring that amount of bitrate. This is proven with the V8 patch, that if you record the same scene you'll see the bitrate being controlled more effeciently, the problem is high detail where the frame size needs a much higher requirement. The only way to enable bitrate to required quality (a part of rate control) is by lifting the frame limit to a higher setting (back towards the default like here in Quantum v8) and changing Quantisation. However in doing this, anything above 800,000b for frame sizes for more than x amount of seconds will eventually cause a write fail. It seems for INTRA (not other gops) a frame setting limit of around 6080808 is max. Now we are looking at matching all the other settings around this which means changing a lot of things like IQ, Q, Time, buffers and bitrate to alter the encoder to these factors we have found for INTRA. If we can crack rate control, we should be able to sort out a lot of problems which currently cause the recording to stop, spanning, and most importantly quality.

*** NEW *** Quantum v9 The Rate Controller!

This is the result of trying to harness rate control back with high bitrates and INTRA. Now you will see your recordings Q vary more (on some of the settings) according to detail being filmed. This has possibly a much better chance of spanning too. Settings: 1080p24H=154000000 (154M) 1080p24L=112000000 (112M) 1080i/720p FSH/SH=80000000 1080i/720p FH/H=60000000 Auto Quantizer for 1080 modes=4 Auto Quantizer for 720 modes=3 720p50 GOP Size=3 (GOP3) 720p60 GOP Size=3 (GOP3) 1080i50 and 1080p24 GOP Size=1 (INTRA) 1080i60 GOP Size=1 (INTRA) Encoder setting 1 1080i/p=1 1080p24 Frame Limit=6128320 60fps Frame Limit=1413779 50fps Frame Limit=1687144

This enjoys very good Q and needs testing on detailed real world subject matter. Let me know how you get on. Got a sneeky feeling we're getting close all rounder with this one. Some of the pictures I have shot with this patch have been stunning.

Test away! Nick

I realize I'm behind the curve here, but made some discoveries this week while testing for a patch to shoot heavily stylized Blade Runner type footage. (all tests are with 24H setting at ISOs 200, 400, and 800.) (edit: All tungsten lighting and WB)

The EOSHD's Roadrunner patch is unusable for what we're trying to do (Hazy noir type lighting with heavy crush in post). Data rate hovers about 25Mb/s, and when shooting haze/smoke it produces a TON of noise and Artifacting, and the data rate drops to 14.

Quantum v5 is noisy at anything short of - 1/3 EV. The data rate comes in at a consistent at 149Mb/s but won't span on my San Disk 32GB 95 card.

We've settled on shooting Q v2 which hovers around 88Mb/s, spans just fine, and produces a smooth fine grain even at -2 EV.

Also, with all patches, I've discovered that the manual white balance sample and set function (the next to last option to the right) creates noise. You really need to either use one of the presets or dial in the balance by adjusting the temp (last option on the right), using the sample white function to set white balance creates something similar to the ISO bug, insane noise.