Personal View site logo
Make sure to join PV on Telegram or Facebook! Perfect to keep up with community on your smartphone.
Pro: AVCHD Quantization process
  • 131 Replies sorted by
  • @driftwood

    what do you do?
  • @Butt Make films! Driftwood Productions. I bought two GH2's (instead of going for an AF101) to B cam alongside my EX3s and 5DmkIIs, etc... With this hack, I'm just trying to understand the mechanics to get the best out of the equipment and I'm sorry if I don't understand the deeper in/outs of the engine. I just want to learn like everyone else! And help. Gonna donate some more dosh to Vitaly now. I can't believe the amount of work he has to process. And with the help of some incredible guys around him. Really pleased with what some of you experienced guys have achieved so far. Sometimes I feel he would be better telling us 'drones' what to do to help - I have no problem with that. You pros can then analyse the results. :-)
  • @driftwood
    ok, thank you!
  • We made some progress with Chris discussing all this stuff.
    Also it seeems like we found the bug causing strange bitrate behaviour sometimes.

    Chris will make few things and test them so we'll understand it even better.
  • @Vitaly_Kiselev How's the progress here going? Any news from Chris? Also wondered if there were any chips out there which were sort of similar to Panasonics encoder like the Ti stuff here which could be of help?

    http://processors.wiki.ti.com/index.php/DM36x_H.264_encoder_FAQ
    http://processors.wiki.ti.com/index.php/DM365_Codecs_FAQ
  • We're working away at it. I've been looking at quantization scaling matrices, etc... There's still some more work to do. It will take a while longer. Hopefully, some good stuff comes out at the end...

    I'm pretty familiar with the TI offerings. We've been looking at several codec's as background information. The Panasonic codec is pretty different, so it's a bit of a challange.

    Chris
  • @cbrandin thanks mate. Let me know if you want me to run any distinctive tests - dont mind bricking my spare! ;-)
  • Wow.. nice offer. But I don't think it will come down to that. There are, however, lots of tests that will need to be run, so you'll be the first to know when the time comes.

    Thanks!

    Chris
  • @cbrandin Question: So the AVCHD picture parameter set include 8 scaling matrixes set at 4x4 (0-15) and 8x8 (0-63)?
    Analysis of a 1080p24 Stock Setting (24 mb/s bitrate) recording
    There are 6 scaling matrixes employed between flags 0-5 and are 4x4 [0-15]), However, Flag [6] is not ever present (ie = 0), flag matrix 7 (always present is an 8x8 [-0-63]).

    Have you got a full copy of this?
    http://webstore.iec.ch/preview/info_isoiec14496-10%7Bed6.0%7Den.pdf
  • Yes, I've read the standard. Gh2 uses 4x4 matrices only (as far as I can tell), which is legal

    Chris
  • Getting differing features of the H264 Sequence Parameter set between different bitrates.
    Elecard Stream analyser is showing wrong integers in section "bit_rate_value_minus1[0] =" above 42mb/s. Here, 24mb/s Stock versus 42mbs and 65mbs
    24mbs gh2 - h264 Sequence parameter set.txt
    2K
    42mbs gh2 - h264 Sequence parameter set.txt
    2K
    65mbs gop3 gh2 - h264 Sequence parameter set.txt
    2K
  • @cbrandin No, GH2 is using 4x4 AND 8X8's depending on the parameters. Look >
    edit: ok, these are scaling matrix!

    edit: ignore the first 24mbps wrong upload! Plus all the first picture frame sets start off the same in the first second, 6 4x4 and two 8x8, then as pfs change patterns seem to emerge from different bitrates.

    edit: I noted all the first 6 matrices [0-5] were similar 4x4 tables of equal values, table matrix 6 was either =2 or =0 and matrix 7 (the 8th and last matrix) was mainly =54 or =0
    24mbs gh2 - h264 picture parameter set.txt
    2K
    42mbs gh2 - h264 Picture parameter set.txt
    3K
    24mbs gh2 - h264 picture parameter set.txt
    3K
    24mbs gh2 - h264 - further into the recording - Picture parameter set.txt
    3K
    32mbs gh2 - h264 Picture parameter set.txt
    3K
  • Yes, one of the bugs currently in the patch/factory firmware combinations is this issue. It will be fixed with the new release.

    I don't understand what you mean with the matrices. The GH2 only uses 4x4 matrices. The 16x16 matrix is a synthesis of the 4x4 matrices. And what is "pfs"? And what do you mean by 4x4 matrices of equal value? I think you need to slow down and explain things more simply for us idiots...

    Chris
  • I guess I was a little unclear. There are no 8x8 matrices in the firmware. If they are using them they are default matrices, which means we have no control over them. Vitaliy has published the IDA dis-assemblies of the GH1 firmware, which is fairly similar to the GH2 firmware when it comes to quantization matrices. Download it and IDA Free and look at the code - if you can point me to any 8x8 matrices I'm all eyes.

    Chris
  • @cbrandin I understand that it may be too early what Im doing but Im just trying to examine 'trends' in the data provided by my basic gh2 tests from the 24mbps v 32 v 42 v 65 that I did in the short GOP thread last week. Bringing the mts files into Elecard Studio allows me to analyse these trends. Hence the supplied data regarding scaling matrices. pfs = picture frame set. sorry for the confusion.

    Note: Just so I can put a cap on the GH2's use of scaling matrix test, I have found a summary to what the 8 [0-7] scaling matrix flags mean. As follows;-

    A seq_scaling_matrix_present_flag equal to 1 specifies that the flags seq_scaling_list_present_flag[ i ] for i = 0..7 are present.
    A seq_scaling_matrix_present_flag equal to 0 specifies that these flags are not present and the sequence-level scaling list specified by Flat_4x4_16 shall be inferred for i = 0..5 and the sequence-level scaling list specified by Flat_8x8_16 shall be inferred for i = 6..7.
    When seq_scaling_matrix_present_flag is not present, it shall be inferred to be equal to 0.
    The scaling lists Flat_4x4_16 and Flat_8x8_16 are specified as follows:
    Flat_4x4_16[ i ] = 16, with i = 0..15, ( 7-6)
    Flat_8x8_16[ i ] = 16, with i = 0..63. ( 7-7)
    In all my test data below all the 4x4 matrices are = 0 (not present) and the two 8x8 scaleing matrices (flags 6-7) are either being used (> 0) or not (= 0)
    When the 8x8 scaling matrices are being used flags 6 or 7 are represented by =2 or = 54 it seems.

    Another good read = http://www.scientificatlanta.com/products/customers/white-papers/7007887b.pdf
  • As far as I can tell, the GH cameras rely entirely on these pre-calculated matrices, which are all 4x4. There are a bunch of them; for each resolution mode there are four sets of six:

    I frame Y-intra/Y-inter Cb-intra/Cb-inter Cr-intra/Cr-inter
    B frame: " " " " " "
    P frame " " " " " "
    Special " " " " " "

    My best guess about the "special" matrix is that it is used as a fallback when bandwidth runs out.

    There are several sets of these: 1080p, 1080i, 720p high, 720p mid, 720p low. 720p low isn't used and 720p high and 720p mid are identical, so I don't know why they were built as separate tables - one would have sufficed. Actually, this is a good thing because we might be able to use the 720p low settings space for custom tables. The 1080p, 1080i, and 720p tables are all different. The 1080 and the 720 tables are entirely different; the 1080i tables differ from the 1080p tables in that the vertical values in the 1080i tables are adjusted to account for 1/2 the number of vertical pixels, otherwise they are the same.

    By the way the best book on H.264 I've found is the one written by Iain Richardson. The second edition came out. It's kind of expensive, but worth it if you really want to get into this stuff. The standard - like all standards - is virtually unreadable, and the various papers published on the web typically over simplify things.

    Chris
  • I looked at I frames from the GH2. As far as I can tell they don't have any 8x8 macroblock components. I assume they are using a 4x4 array of 4x4 blocks for luma, and two 4x4 blocks for chroma. If that is correct, then it wouldn't matter what the flags for 8x8 blocks contain.

    I see the matrices for 8x8 in your printouts - I have no idea where they come from, or if they are used. I wonder is they are synthesized from the 4x4 matrices. I'll have to plot them and see if any patterns arise.

    What are you using to get these stream item dumps?

    Chris
  • I looked at the 8x8 matrices in your printout. Have you noticed that they contain strange entries? They contain zeros, and the patterns make no sense - I've never seen tables like these, they seem to contain nonsense. They certainly aren't the default tables, or even close. The 4x4 tables I do recognize - they are straight out of the GH2 internal matrices.

    Chris
  • @driftwood

    Can you help me with something?

    I assume your printouts are at the first frame unless otherwise noted. In those the matrices are very sparse, containing entries that are 255. The one you got from later on in the stream has more standard entries. I'm trying to figure out exactly what the "special" matrices are for. It appears they are used during the first GOP. Do you ever see these tables anywhere else?

    Also, can you provide dumps for I frame, B frame, and P frame (later in the stream, not the beginning)? This would help me definitively nail down which tables are used for what. I think I know, but this would be great for confirmation (or, correction).

    I would really appreciate it.

    Chris
  • @cbrandin sure. btw I just posted my findings regarding buffer sizes at initial startup of recordings. see stable settings thread
  • Thanks,

    I think your parser barfs if 8x8 matrices aren't used and just attempts to decode whatever data follows. Past the 4x4 matrices everything looks like nonsense.
  • @cbrandin something definitely is going on with those unusual 8x8s. Because the data is changing as I look at each slice - not all the time, but they definitely differ when something 'changes' in the picture. I'll conduct test on my moving tests later tonight to confirm.

    BTW: 'Special' frames are normally used as follows;-
    "Depending upon on the subset of coding tools used, a slice can be of I (Intra), P (Predicted), B (Bi-predicted), SP (Switching P) or SI (Switching I) type. A picture may contain different slice types, and pictures come in two basic types – reference and non-reference pictures. Reference pictures can be used as references for interframe prediction during the decoding of later pictures (in bitstream order) and non-reference pictures cannot. (It is noteworthy that, unlike in prior standards, pictures that use bi-prediction can be used as references just like pictures coded using I or P slices.) In the next section we describe the coding tools used for these different slice types."

    I quite like your theory that they are employed twhen the bandwidth adjusts but I'm not 100% that's correct.
  • I suspect that these are basically "I give up" matrices. You might only see them when the bitrate is over 32K during the "blip". Looking at your printouts, that seems to be the only time they appear. I've only ever seen one slice per frame with the GH2.
  • @cbrandin What you asked for. Here's a comparitive dump of the I,B P frames at beginning to middle of recording on a GOP3 KAe recording. Ill do a 24mps Stock copmparison soon.
    comparisn of gh2 1080p24 GOP3 scaling matrices.txt
    66K
  • @cbrandin Im using Elecard Stream Analyser to produce these patterns. Download the trial. Im using a full copy of Studio.