Personal View site logo
Pro: GH2 AVCHD encoder settings
  • This topic is for testing patches residing in testers section.
    Carefully and systematically.

    Patches for testers>AVCHD movie mode>AVCHD research>Encoder setting 1 1080i/p when value changed from Original 3 to Modified 2 there are no b-frames encoded into the AVCHD stream.
  • 177 Replies sorted by
  • Screenshot
    nobfra.JPG
    1257 x 210 - 53K
  • Patches for testers>AVCHD movie mode>AVCHD research>Encoder setting 1 1080i/p when value changed from Original 3 to Modified 4 there is a silent crash with no recording, camera becomes unresponsive and needs to be rebooted by taking battery out.
  • Patches for testers>AVCHD movie mode>AVCHD research>Encoder setting 3 1080p when value changed from Original 4 to Modified 2 seems to have no visual effects, when changed to 8 causes very strong macro-blocking.
  • Patches for testers>AVCHD movie mode>AVCHD research>Encoder setting 4 1080p when value changed from Original 8 to Modified 4 average video bit rate in a 24H file drops to 8k and only I and P frames recorded with motion, b frames recorded without motion so it looks like an 8 frames a second film.
  • I changed topic title.
    I suggest to use original topic for all else, except 4 encoder settings (for each of 3 modes).
  • Very nice dkitsov.
  • Patches for testers>AVCHD movie mode>AVCHD research>Encoder setting 4 1080p when value changed from Original 8 to Modified 16 average video bit rate in a 24H file remains around 23-24mbps, no drop of frames
  • Mmm- ES4 1080i is 17.. I wonder
  • (Original) Encoder Settings table
    720p____1080p_____1080i
    1) 2________3_________3
    2) 3________3_________6
    3) 4________4_________8
    4) 9________8_________17
  • 0n 'encoder setting' 2 and 3, 1080i is double that of 1080p, and on ES4, 1080i is double 1080p, +1

    1080p and 1080i both have the same value for ES1
  • I'm not sure there is a pattern to the table. VK, can you tell us more about the code around the encoder settings?

    And what I mean is that there aren't 4 states for each resolution, and none of them share encoder settings in a way that would be cross functional. So therefor these have to be some kind of variables or otherwise some kind of pointers to other setups.
  • Maybe so... but I thought the similarities were curious, like the leap to a larger value at ES4, and a rise in values from ES1-4 across the 3 resolutions.
  • @svart

    It is just constants that are set up during overall AVCHD settings (including bitrate and others).
    As you can understand, they are different for three main AVCHD settings (1080i, 1080p and 720p).
    It can't be pointers, but it can be indexes for some tables, for example.
    It is hard to say currently as Panasonic cameras use very indirect approach so I can' track them to the actual usage.
    Other good idea is use trial version of Elecard StremEye - http://www.elecard.com/en/download/products.html
    and look at fields and other encoder things and looking for matches.
  • So it's probably a good idea to give a testing structure.

    My first thought is that we should ask for someone to test each encoder setting under each resolution and set up the camera to produce identical video files of 10 seconds on each and then run Streameye and Streamparser on each file. We can then easily compare what is different.

    However, the camera needs to take video of exactly the same subject with the same lighting, etc, every time so that there is no introduction of change to the file from external influence, so that we can only see what the encoder setting changes.

    My camera is out on loan until next week. If nobody can do this sooner, I'll do it when I get it back.
  • @svart

    Yes, something like that.
    Tripod and some paper targed are ideal.
  • I am going to try to do the bit rate tests tonight with the test charts on a tripod. I have a spreadsheet setup to keep track of every change. I will change one parameter at a time. Hopefully I can post some files tomorrow. I just did a quick test with half of the original GOP and bit rate set at 40 mb/sec for each resolution. The first 2 seconds of a tree blowing in the wind showed almost no compression artifacts just like the GH13. Then you can actually see the macro blocking suddenly start after 2 seconds. If we can get the whole video to look like the first 2 seconds everyone will be VERY HAPPY.
  • >Then you can actually see the macro blocking suddenly start after 2 seconds. If we can get the whole video to look like the first 2 seconds everyone will be VERY HAPPY.

    This is similar to my test expirience.
  • We will just keep testing away and see if we can find the magic setting. Those first two seconds look really good though.
  • @mpgxsvcd,
    Would you share your spreadsheet file to save others some time? Pretty please.
  • @mpgxsvcd
    Btw, I think that errors must be less frequent with new release.
    We also need mode data and more systematic testing.
  • I am trying to compile as much data as I can. I will share the spreadsheet tonight after I have enough test cases. Exactly what information from stream parser should we post? Just a screenshot of it? The "show big information panel" info?
  • Look at second post of this topic.
    I just need complete chart. Plus numbers.
    Also advise to use any MTS loseless cutter and cut first 2 seconds to get numbers for them separately.
  • I replicated the two second reset with initial higher bitrate. So I tried the opposite, lower bitrates to see if the flip would happen - no 2 second change, average bitrate of 20mbps. So there must be some kind of value that the encoder is using as a ratio ceiling... after the 2 sec reset, the average bitrate seems to be lower than if the bitrate was not manipulated..
  • >after the 2 sec reset, the average bitrate seems to be lower than if the bitrate was not manipulated..

    I know.
    But again. Please use full report form.
    You words are and ideas are fine, but they won't provide necessary data.
  • Interesting finding:
    I just tried high detail tree test with:

    1080i50 and 1080p24 GOP Size: 6 (half Gop)
    Encoder Setting 1 1080p: 2 (no B frames)
    No bitrate manipulation

    While there was little motion, the I frames had much higher bitrate (about 300k each) than P frames (about 100k each) as normal. Then I shook the cam like an earthquake - the bitrate leveled out between I and P as normal...
    When I held it still again, I frame bitrate did not rise again.. Instead it was treated as P frame, with identical bitrate. Seems a 'bitrate reset' occurred on high detail/motion based on GOP frame type bitrate distribution.
    Capture.JPG
    1264 x 217 - 66K