Personal View site logo
AVCHD maximum image quality settings and testing
  • 1002 Replies sorted by
  • @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.
  • Based on Ralphs HDMI frame grab compared to 66mb/s AQ4, the motion sample does not look good.
    Has anyone had any luck with 88mb/s AQ3?
  • 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.

  • @proaudio4 That is really great test and insight. I think you are onto something here. Thanks for sharing. This makes the case that @cbrandin has been making, namely: find the setting (NR -1?) for some noise reduction in camera for the best end result? Al
  • 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.
    66Mb_GOP12_AQ2_cBrandin.jpg
    1273 x 654 - 92K
    100Mb_GOP3_AQ1.JPG
    1294 x 678 - 98K
    110Mb_GOP3_AQ3_driftwood.JPG
    1271 x 633 - 174K
    66Mb_GOP12_cBrandin_still.png
    1920 x 1080 - 4M
    100Mb_GOP3_AQ1_driftwood_still.png
    1920 x 1080 - 4M
    110Mb_GOP3_AQ3_driftwood_still.png
    1920 x 1080 - 4M
    66Mb_GOP12_cBrandin_PAN.png
    1920 x 1080 - 4M
    100Mb_GOP3_AQ1_driftwood_PAN.png
    1920 x 1080 - 4M
    66Mb_GOP12_cBrandin_GRADED.png
    1920 x 1080 - 484K
    100Mb_GOP3_AQ1_driftwood_GRADED.png
    1920 x 1080 - 479K
    110Mb_GOP3_AQ3_driftwood_GRADED.png
    1920 x 1080 - 478K
  • @stip

    Is there any way you could also test the 44M AQ4 settings and compare?
  • @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.
  • @stip Now try 132M GOP3 AQ2/or 3 on 36000000 :-)
  • @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?
  • @driftwood

    ok, tomorrow I'll do your 132Mb AQ2/3
    I'm still a low GOP fan ;)

    and I'll replace crappy 14-42 with Nokton 25mm
  • 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.
  • @Chris

    ok, I will. I'll try to include a second run with higher ISO
  • 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.
    c08bin - test mts0044 - untuned 44Mbps GOP12 AQ4 33M buffer -streamparser result death chart.png
    1298 x 688 - 86K
    c08bin - test mts0044 - untuned 44Mbps GOP12 AQ4 33M buffer -elecard buffer analysis.png
    1679 x 942 - 120K
    cbrandin 44M vid buffer is 0x2400000 tuned - streamparser.png
    1300 x 684 - 90K
    cbrandin 44M vid buffer is 0x2400000 tuned - elecard vid analysis .png
    1681 x 931 - 130K
  • ProRes422 (or DNxHD115 or 175) is good enough for most grading work. It has 147Mbps peak bandwidth. Divided by 24. Then 6.125Mb per intra-frame seems more than enough. At least bit size wise.

    The 44Mbps GOP12 setting made 5~6Mb I-frame size on static or one-person interview using a tripod. When it's not properly focused or it's fast panning, I-frame dropped below 3Mb. I don't really care about that. When it's properly focused, it spiked up again to 5~6Mb I-frame. Many other settings I had tried didn't come back to peak Mb size.

    88Mbps GOP3... yeah that makes sense only if it can match IQ of 44Mbps GOP12 AQ4.

    44 GOP12 and 88 GOP3 would yield about same size files after transcoding to ProRes or DNxHD.
  • @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
  • @cbrandin Thanks for that info, confirmed a lot what I thought about some of the streams I've seen posted.

    The thing is it's difficult for me, and probably for others to judge what is a good stream. Obviously cadence problems are easy to identify (as are flatlines, pulsing etc), but for example I've raised doubts on my own GOP 6 66Mbps settings, which are based on your GOP 12 settings, that I posted in the low GOP thread today. The reason being during a single GOP on a static shot of the deathchart (which incidentally I rarely use now as I discovered that sometimes it didn't reveal cadence problems when a real world shot would) the P & B Frames dropped dramatically in size, then settled for the next GOP and onwards. Now, IQ wise, nothing is changing so it wouldn't matter at all, but it just raises a concern.

    Also, during an outdoor scene with a lot of movement there was a point where an I frame dropped to less than 10% of the two I Frames either side. Sure, the image was blurred as I was whipping the camera around, but again its behaviour I've not seen before so it raised a concern with me. You say you expect it to bounce around, and I understand there are too many vagaries to give a hard and fast rule but would such a large drop in an I frame in a single GOP only etc be over the line of acceptable/stable to you (assuming the main lightsource didn't turn off completely for a 1/25 second) ?
  • 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
  • Many thank, thats eased a lot of my concerns about what I'm seeing. I'm pretty confident about the GOP6 at 66Mbps now, but I will continue to test it.
  • 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
  • Ive found if it works on the death chart at base level and its a nice even chart - its the starting point (hence no tunings). It provides a basis for filming out in the field and then to adjust where neccesary. Ive had great results (which I will be publishing) with some of my footage and confirmed on Elecard Video Estimator testing YUV from the field results which I've been shooting all week.
  • @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
  • The sudden drop in I-frame seems more severe from 44Mbps GOP12 than from 100Mps GOP3.

    When there is motion, B-frames spike up. Then less bandwidth for I-frame? Yes motion would have given smaller I-frame regardless, but sometimes I-frame drops so ridiculously low. Almost like choking.

    Is there a way to keep I-frame size high enough while not suppressing B-frame's growth during motion? That would make average bitrate of moving scene to become higher than static scene. I know that sounds silly. But GOP12 would act more like shorter GOP. Sorta... the codec goes higher gear on motion.

    e.g. At static scene 44Mbps would give about 6Mb I-frame. On motion, 5Mb for I-frame, 3-Mb for B-frame, and 4Mb for P-frame. That would give 78Mbps for GOP12.

    Just an idea. Don't bash me too much. It's been a long week.
  • @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

  • Incidently, I'm starting to get dozens of PM's asking me to look at settings and other questions about using the hack. I've even gotten questions about GH1 settings and I don't even own a GH1 any more. I have to stop answering these for several reasons:

    1) I think these things should be public - not private, unless there is an extremely compelling reason for it. If you tell me you can't go through all the postings in a thread and put the effort into understanding them than I'm rather offended because that implies that your time is more valuable than mine (as I'm sure it is - at least to you).

    2) I posted my own settings for your consideration and use. Feel free to improve, etc... and post your results publicly so everybody can benefit. Please don't ask me to test your changes or derivations - you're supposed to be doing that.

    3) Abandon the idea that I am a better source for how to do basic things with PTool than anybody else.

    4) I am willing to do private, custom consulting. You won't like the price, though. My time to thoroughly evaluate and test your settings will cost you considerably more than your camera did. I volunteer my time in this as a public community effort, if you want private consulting it's billable.

    5) I simply can't devote the time - not that and be able to do any more development work.

    Chris
This topic is closed.
← All Discussions