Personal View site logo
Make sure to join PV on Telegram or Facebook! Perfect to keep up with community on your smartphone.
GH2 AVCHD Encoder Motion Testing
  • There is a lot of static testing going on. I wonder, though, whether the real advantage of higher bitrates manifests itself in dynamic scenes more than static ones. Therefore, it seems logical to set up some sort of standardized test for resolution vs. movement. Something like shooting a resolution chart while panning slowly (at a fixed rate) might show whether there is improvement in dynamic scenes.

    Shutter speed will be an important consideration, as the slower it is the more blurring (and the less detail) there will be. At fast shutter speeds minute detail will change considerably between frames.

    With a static scene I frames dominate, and B and P frames don't play much of a role so quality improvements concerning those won't show up.

    I'm going to play with this a bit. In the meantime - any thoughts?

  • 43 Replies sorted by
  • Vitaliy,

    Let me see if I understand this right. When patching 24H, you also have to patch 24L in proportion, otherwise 24L may not work correctly, right? For the first tests I want to restrict myself to 24p cinema modes to keep things simple. Will that work, or are there other inter-dependencies?

    I've been playing with StreamEye Slim from Elecard ($50 - a really good price). It shows frame by frame analysis of motion vectors, macroblock types, etc... It's very nice and I would recommend it for serious testers as it shows many things StreamParser does not (and visa versa too). lpowell - are you around - hint, hint? The only catch is that StreamEye doesn't recognize GH2 filename extensions so you have to select "All" file types when opening files.

  • @Vitaliy_Kiselev The thread says too many static tests + first i saw the title which seemed to be for motion testing, if i misunderstood or not relevant enough to post here no problem but I was going purely by thread title at the time of posting it.
  • @OSGondar
    Are you sure that this is proper topic for this?
    May be better place it in topic that is in Showcase category?
  • @cbrandin

    About low bitrates.
    Rule here must be simple.
    Low modes (24L for ex) bitrate setting must be always in between top and boottom settings for high mode (24H).
    If it is not so, you'll get this problem.
  • For encoder motion testing i have made High motion images, high iso, some dead on exposures some under exposures all during some motion! I basically tested just about most of the shots i can imagine an average user would have. It's got a little bit of everything, sorry for the extra texts in it, i may put it on my blog and talk about progress with the hack so some extra info is in there. If you don't full screen, it looks a lot like the mts, full screen there is what seems to be more noise than the original file but original is available to download so that fixes that..

  • >Your second response is a lot more productive.

    If you stop talking to me in mentor tone it'll be even better.

    >Are those actually controlling multiple settings in the firmware now or is it one discreet field value. Those settings appear to act differently than they originally did.

    They are changing many things. I wrote this in main hack topic before release.
    Including corresponding top and bottom settings that you can find in testers section.
  • Your second response is a lot more productive.

    I have a question about the Video Bit Rate FSH/SH and 24H settings. Are those actually controlling multiple settings in the firmware now or is it one discreet field value. Those settings appear to act differently than they originally did.
  • @mpgxsvcd
    I understand that you want to help. And are doing testing. I value that.
    But read your message without emotions and after this read my response.
    If you do not understand me still, just do not go to testers topics.
  • @mpgxsvcd
    You are in wrong topic talking to wrong people and telling them things that you do not understand.
    To be simple.
    This is fucking testing topic, and here we make tests to understand how each setting works.
  • I wouldn't bother with testing the Top and Bottom Bit rate settings right now. I just tested those with a 94% of 32000000 value and it actually decreased the average bit rate. I did a completely controlled test on a tripod with identical settings which I saved in the C1, C2, and C3 slots for 720p, 1080i, and 1080p.

    I will post the sample files and the Stream Parser data in a moment. For now I haven't found a reason why just setting the bit rates to 32000000 isn't are best option for the time being? It is completely stable and offers extremely good picture quality. If stability isn't your main concern then the 42000000 setting works very well also.
  • I'm going to switch over to my motorized pan/tilt head for the next round of tests. That way, I can have total control. I'll get back to devising a simpler test for other participants afterwards. The main problem I had with the simple test was making sure the target didn't swing out of focus.

  • >Vitaliy, what is the "bottom bitrate", a minimum? If so, experimenting with that might make a difference.

    It might, but it might not. :-)
    Try to play with top and bottom numbers for 24H keeping the same bitrate setting.
    Keep bottom always smaller, and top < your bitrate setting /1024.
  • Well, it seems that putting the 24H settings into the 24L slot causes problems. I re-did the test with the factory firmware and got almost exactly the same results as with 42M (same bitrate and image quality).

    Vitaliy, what is the "bottom bitrate", a minimum? If so, experimenting with that might make a difference. Will it work to use the easy settings and then just change that one parameter in the tester section?

    You might want to remove my previous test images and post - I don't want to confuse people.

  • @cbrandin
    I also think so, as bitrate is too low.
  • I may have messed up the test. I put the Panasonic factory values for 24p cinema H in the 24p cinema L location using Ptool. I'm redoing the Factory setting test with the original, unmodified firmware to eliminate any other possible factors. I should have results in a few minutes.

  • Altitude doesn't have a measurable effect (at least not for these tests). Let's not get too fancy here, it isn't necessary.

    By the way, I didn't find much difference between frame types (as I expected), the big difference was in overall quality. I didn't do any image adjusting except for normalizing contrast.

  • I put up all this stuff so that everybody could do testing. It is pretty easy and doesn't cost anything (except the cost of an inkjet print). Hopefully, others will participate; especially those who have dug into PTool more than I have so far. I'll study up and test more over the next couple of days.

    Is there anybody out there who can run this test for Vitaliy now?

  • @B3Guy

    Doesn't altitude affect the period of the pendulum as well?
  • @cbrandin

    Try to test this with manually adjusted bottom bitrate for 24H mode (in testers section).
    Like at 90% of top bitrate.
  • String length = 1 meter. Use video from when the target goes from edge to edge (inside) - you just have to be somewhat wider when you start. Weight doesn't matter (except the swing will last longer). Pick frames close to the center. Make sure the target isn't swinging in and out of focus (takes a little practice). I have some test results. I wasn't all that precise and the results are very revealing - stay tuned.

  • guys, honestly! just remember your physics! :-)

    A pendulum's period (timing) is determined (basically) by its LENGTH. Settle on a standardized length, weight, release distance, and a chart. set up, shoot, repeat.
  • I'm not sure aperture, lens length, etc... makes any difference. Pretty much any lens configuration will max out 1080 resolution. It is important, however, to have the target the right size in the viewfinder. I plan to do most of my testing with the 20mm lens. What we're looking for is relative resolution between frame types; absolute metrics concerning lenses etc... is another issue. As for how fast the image is moving - well, we are shooting video after all, so speed should be easy to measure. Also, you could calculate image speed vs. angle from center as long as you know what the extremes are.

    Why would an image that corrects angular velocity be necessary? All we want to see is how well detail holds up in P and B frames vs. I frames, and whether higher bitrates improve the temporal behavior of the codec. I wonder, for example, whether even if a higher bitrate doesn't improve static images, if it does improve dynamic ones. For example, if you look at an I frame and the immediately preceding frames have much lower detail then we know detail is being lost, at a higher bitrate they might look better even if the I frame doesn't. After several seconds it should be possible to have captured samples of images in all positions and with every frame type.

    I'll play with this a bit more and see if I can come up with a simple protocol.
  • I suppose you could generate an image that would correct angular velocity, to check the evenness through the frame
  • The idea of a standardized testing setup is great. Just some ideas, Same lighting steps, same distance, as close as the same lens as possible, same fstops, etc.... Then we can post/graph/grid the results based on some type of quality indicator.
  • That's a good idea too. I was just trying to come up with a solution that doesn't cost anything so more people could participate.