@LukeV

The pictures I posted are all lossless. They are exactly what you get out of the camera, both HDMI and AVCHD. You can do your own color grading on them.

I will post some data later, but here's what I'm seeing:
Using 88Mb/s ; AQ3; Video buffer 24p=0x3600000 ; 1080p24 T4=1080p24 T1

Note: All of the following three tests were static video on a high detail graph chart.

At ISO3200 (displaying a lot of noise), the p,b and i frames are all around the same height 350-400K
At ISO800 the p,b and i frames slightly increased to around 600K; the p frames lifted away a bit to 468K
At ISO200 the I frames shot up to 1.1M, p frames increased a bit more to 500K-530K

This may have been well know here, but I did not realize that noise is seen as motion to the AVCHD encoder.
I guess it makes sense since noise is not static.

Therefore, scenes with higher noise present may steal additional bitrate for motion vectors.

I quickly compared following settings' IQ for static shots, panning and grading quality.

cBrandin's 66Mb GOP12 AQ2
driftwood's latest 100Mb GOP3 AQ1
driftwood's 110Mb GOP3 AQ3

14-42mm @ 25mm, ISO 160, 1/250 shutter, B&W Nd filter

I can't see any IQ differences for the static shot.

For panning, GOP3 seems to have a slight motion advantage but I had to look for it. Both driftwood settings looked the same so I included only 1 image. I'm still eager for low GOP settings and I guess in other circumstances and a 1/50 shutter differences might be greater, I can't tell, with this test, quality is very close.

To test grading stability, files were transcoded to DNxHD 175 4:2:2 with 5DtoRGB and tweaked in After Effects. There is no difference between the 3, so overall higher bitrate than 66Mb doesn't affect grading stability any further it seems - at ISO 160 that is.

@stip Excellant test, many thanks for this. I'd imagine the 44Mbps AQ4 would give similar results too as chris said when he released the 66Mbps settings, especially with your test shot. I've settled with the 66Mbps GOP12 myself after shooting some footage in a dimly lit bar, even running at AQ2 with shots containing a lot of shadow I was getting an average bit rate of 45Mbps, which obviously the 44Mbps just couldn't. I'd expect it would have come close though, around the 37-40Mbps mark.

@Chris

Sun is changing constantly now, I'll repeat test tomorrow. Which settings should I compare, 44M AQ4 to 66M AQ2 or also include driftwoods GOP3 settings?

Try all, If you can. If you can demonstrate that 44M produces the same image quality as the higher settings, that's good to know. Likewise, if driftwood's settings produce a significant advantage in some way, that's good to know too. What I like about your tests is that you are looking at things like grading, rather than just bitrate numbers, etc... Our metrics based tests only tell part of the story.

FYI
Driftwood's GOP12, AQ4, 44Mbps (33M buffer produced at video buffer 24 = 0x3600000) untuned settings result on the buffer and streamparser/ pappas death chart. Nice stable buffer.
v
cbrandin's GOP12, AQ4, 44Mbps (33M buffer produced at video buffer 24 = 0x2400000) tuned settings result on the buffer and streamparser/ pappas death chart. Nice stable buffer.

EDIT: Spot the difference.... :-) The VBR encoder - which I was on aware of (see earlier posts) - works just as effeciently on the 3600000 settings. I'm not chasing constant bit rate, I'm after a stable starting point for the majority of GOPs etc... (hence testing on pappas) with a good fill of the buffers on the static chart.

@driftwood

There are a few things that occur to me about these StreamEye traces:

First, without any tuning the I frames aren't very big - the very purpose of tuning is to allow them to get bigger - and that absolutely improves quality. In fact, I believe the most significant indicator of increased quality is by far bigger I frames - especially with static scenes. I've noticed that with some tests of increased bitrate on static subjects all that happens is that P and B frames get bigger. If there is no change in the image those bigger P and B frames aren't really doing anything. The scene is static - they should be relatively tiny.

The GH2 codec is a VBR codec - constant buffer behavior is not what I would want to see. That just means you've figured out a way to make it behave like a CBR codec - which is contrary to what the codec was designed to do in the first place. I would fully expect to see blips in the buffer behavior, especially near the beginning when the MUX is catching up with the latency inherent with starting up streams. As long as buffers don't overflow or underflow it doesn't matter how much they bounce around.

The "death chart" isn't a very good subject, it has no gradations and it's monochrome, so U and V blocks will be practically empty. Also, because it has no gradations, improved quality will be practically invisible. Automatically generated quality metrics based on a pathological subject, like the death chart, aren't measuring anything that bears any resemblance to real world subjects.

Chris

P and B frames should change is size a lot, depending on motion - that's the correct behavior. Also, with blurring it's perfectly normal for an I frame to become dramatically smaller. On static shots I frames should be big and P and B frames should be relatively tiny. This is precisely what variable bitrate H.264 codecs are designed to do. If you are seeing different behavior, then something is probably wrong. The VBR H.264 codec is simply not designed for consistent frame sizes under differing circumstances - quite the opposite.

Chris

One challenge with testing is finding subjects that contain detail, gradations, subtle colors, etc... Charts generally are fairly limited in their ability to manifest such subtleties. I can think of at least two reasons for this: charts have much lower dynamic range than real world subjects, and there is no comparison in the gradation subtlety with a chart and the real world. In fact, most cameras - hopefully - outperform printers when it comes to these issues.

Chris

@driftwood

Are there any comparisons between these extreme bitrate, low I frame size, settings and lower bitrate, big I frame settings coming from the field - or are you only going to test extreme settings and compare them to nothing else?

All the death chart tests is the ability to film monochrome high contrast (absolute contrast, actually) busy subjects for stability. The chart simply contains no other data. That is somewhat useful, but not complete by any means.

Show me a real world subject where the results with 100Mb very short GOP looks better than 44M GOP 12 AQ4 with tuned buffers - side by side. They may be different, but I doubt one will be pervasively "better".

Look at @Stray's posting 5 postings above. He gave up on the death chart precisely because it proved to be inadequate.

Chris

@stonebat

Those are all good questions. I looked frame-by-frame at lots of footage captured at various bitrates. My findings were:

Individual frame IQ for static subjects is directly related to I frame size.

I have found no settings that produce a better IQ than tuned 44M AQ4 that are reasonably stable in all modes.

Looking at motion rendering, I try to determine whether everything in the frame moves correctly (no partial frame stuttering, etc...). At tuned 44M AQ4 everything looks good.

I've looked at all macroblocks looking for macroblocking, and whether the QP values used are consistent from the top of the frame to the bottom (determines whether codec has run out of bandwidth mid-frame). At tuned 44M I saw no such thing.

Big I frames just shouldn't happen with lots of blurring because the codec isn't rendering as much detail. If I frames stay the same size, that's rather a perversion. In fact, it can be a problem because there will be a visual inconsistency between frames with motion and without. It doesn't look right when blurry frames are rendered with more gradation detail than the rest.

Same thing with big P and B frames. IQ should be absolutely limited by I frames. If P and B frames add detail you get really ugly detail pulsing. I frames are not supposed to be improved upon - jut preserved. When motion suddenly stops between I frames, P and B frames become very big because they use intra encoded macroblocks (like I frames) instead of motion vectors, etc... In that case I guess detail is being "improved" - but the same kind of encoding is being used to do it as is used in I frames because entirely new detail is being rendered. If a high speed shutter is being used I suppose big bitrates would be better - but that's the only case where I can see it making a positive difference.

If you have settings that bloat P and B frames the codec will use less efficient, not necessarily better, encoding methods, and not even try the more clever methods - resulting in more bandwidth use with no improvement in IQ.

I challenge anybody to show me where any settings can produce bigger I frames that my 44M settings. I also challenge anybody to explain how even equal IQ can be achieved with smaller I frames, irrespective of P and B frame size.

It may be possible to get slightly better IQ at 66M - but you trade off stability for some modes and in camera playback can be affected.

Chris

@cbrandin

:-)