This shows you the differences between two versions of the page.
|
h264-resource-wip:avchd [2012/02/14 00:00] driftwood created |
h264-resource-wip:avchd [2012/03/05 21:41] (current) driftwood |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | {{ :avchd-resource-wip:avchd:avchdlogo.png?nolink&100 |}} | + | Note from Driftwood (March 2012): Being edited in Word & 'pdf professional' before being made into wiki.This is a work in progress of AVCHD resource and info. Things we know need to be rewritten and simplified and put in here. Below is not the final order of the jigsaw - some of the sections may end up in other headings. I'm going to finish everything first, and then you guys can edit it down more. Everything is written in' my way of interpretation' ie nothing is copied from other sources - if its incorrect, correct it! |
| - | This is a work in progress of AVCHD resource and info. Things we know need to be rewritten and simplified and put in here. | + | |
| - | ====== AVCHD ====== | + | ====== What is AVCHD? ====== |
| - | === AVCHD Definition ===== | + | //**Definition;** AVCHD (Advanced Video Coding High Definition) is part of the AVC standard. AVCHD was jointly developed by Panasonic and Sony and introduced in 2006 primarily for use in high definition consumer camcorders. AVCHD is the codec of choice for the Panasonic GH1 and GH2. For a full description and reference please visit: [[http://en.wikipedia.org/wiki/AVCHD]] |
| - | //AVCHD (Advanced Video Coding High Definition) is part of the AVC standard. AVCHD was jointly developed by Panasonic and Sony and introduced in 2006 primarily for use in high definition consumer camcorders. AVCHD is the codec of choice for the Panasonic GH1 and GH2. For a full description and reference please visit: [[http://en.wikipedia.org/wiki/AVCHD]] | + | |
| // | // | ||
| - | === Specification ===== | + | ====== Specification ====== |
| Click this link for a full specification to AVCHD: [[http://www.avchd-info.org/format/index.html]] | Click this link for a full specification to AVCHD: [[http://www.avchd-info.org/format/index.html]] | ||
| - | === Quantization ===== | + | ====== AVCHD Conformance ====== |
| - | Definition, | + | How does the GH2 AVCHD codec conform to the standard & profiles? [to be written] |
| - | Quantization Tables | + | |
| - | Scaling Tables | + | ====== AVCHD Prediction ====== |
| + | A good analogy of AVCHD Prediction is how sampling works in music - you take musical sections and sample them so that you can copy and paste them later on (or before) in the song to make identical chorus or verse backing tracks. Similarly, in video the individual pictures can be broken up and sampled to form zones in the picture from previous (and/or future picture zones) to make up the current picture in the video - ie if the original sampled zones haven't changed much it forms a good prediction for the use in the current frame. This process is called Prediction and it helps maximise compression to save data/memory space whilst giving good reproduction of the original part of the picture. To achieve near perfect prediction the pictures are broken down into smaller blocks of pixels for even more accurate reproduction. But they each have a special meaning and way of working. | ||
| - | === Deblocking ===== | + | * **Prediction zones are chopped up into Macroblocks** |
| - | //Definition,// Deblocking is... | + | |
| + | //**Definition;** A macroblock (abbreviation = mb) is a series of non-overlapping 4 by 4 (4x4) or 8 by 8 (8x8) pixel blocks which put together make up the composition of the coded picture frame. In AVCHD GH2 terms, these mbs (macroblocks) are divided into 4x4 blocks. Every AVCHD macroblock has a prediction - an attempt to recreate the information inside the macroblock using previously coded data which is then subtracted from the macroblock to form the quantity left over - known as the residual. How much residual data is left over dictates how well the compression is working. Less residual = better compression performance. AVCHD has many of the effecient prediction characterisitics described in the H.264/AVC standard.// | ||
| + | |||
| + | * **I-Frame/P-Frame/B-Frame Macroblock prediction** - Macroblock prediction works as follows; an I-mb method (//I=Intra prediction//) predicts from neighbouring sample blocks in the same frame, a P-mb prediction (//P=predictive//) is a current frame predicted from a previous or future coded frame, whereras a B-mb prediction (//B=Bi-directionaly predicted//) is predicted from a combination of forward and/or backward coded frame/s. | ||
| + | |||
| + | ===== Intra prediction ===== | ||
| + | |||
| + | * **Intra prediction**; (//Intra meaning 'within itself'//) is a coded mb which does not refer to any other data outside itself - ie its current slice. Therefore, Intra prediction is created from adjacent previously coded block samples in the same slice to predict the values in the current block. (See fig.x taken from a GH2 Intra block sample). | ||
| + | * **Nine modes to predict a 4x4 block** - labelled 0 to 8, there are 9 ways of predicting a block from surrounding blocks (see fig.x and note the direction of the arrows) ;- | ||
| + | - Mode 0 (vertical) The upper samples are taken to form the prediction. | ||
| + | - Mode 1 (Horizontal) The left samples are taken to form the prediction. | ||
| + | - Mode 2 (DC) All samples are mean averaged from the 4x4 block to form the prediction. | ||
| + | - Mode 3 (Diagonal, Downwards-Left) The samples are taken at a 45 degree angle between lower-left and upper-right to form the prediction. | ||
| + | - Mode 4 (Diagonal, Down-Right) The samples are taken at a 45 degree angle between down and to the right to form the prediction. | ||
| + | - Mode 5 (Vertical-Left) Prediction samples are taken at an angle of approx. 26.6 degrees (ie width/height = 1/2) to the left of vertical. | ||
| + | - Mode 6 (Horizontal-Down) Prediction samples are taken at an angle of approx. 26.6 degrees below horizontal. | ||
| + | - Mode 7 (Vertical-Right) Prediction samples are taken at an angle of approx. 26.6 degrees to the right of vertical. | ||
| + | - Mode 8 (Horizontal-Up) Prediction samples are taken from an interpolation at an angle of approx. 26.6 degrees above horizontal. | ||
| + | |||
| + | |||
| + | * 4x4 luma prediction modes | ||
| + | * 16x16 luma prediction modes | ||
| + | * chroma prediction modes | ||
| + | * 8x8 luma prediction modes | ||
| + | * Intra prediction mode samples of GH2 (NOTE: images and text to be integrated with above) | ||
| + | |||
| + | ===== Inter prediction ===== | ||
| + | * **Inter prediction**; is the method of foretelling a block of luma or chroma samples from a picture that has previously been coded and stored (which becomes a reference picture) in the decoded picture buffer (DPB). | ||
| + | * ** Decoded Picture Buffer in GH2 ** The DPB is a repository of pictures coded from before or after the current picture in the display order. The dpb holds the number of previous frames each P-frame can use as references. Note that the H.264 spec limits DPB size for each profile level. The GH2 holds 2 reference frames maximum it seems, even though the H264 standard at level 4.0 profile allows 1,280×720 (9 ref frames max) and at 1,920×1,080 (4 ref frames max). A good reference about how the dpb works along with 2 reference frames is found here in a TI chip h264 implementation: 'Understanding H.264 Decoder Buffer Mechanism' [[http://www.ti.com/lit/an/sprab88/sprab88.pdf]] A very good reference about maximum size of dpbs exists at x264's link: [[http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels]] | ||
| + | |||
| + | Note: Everything in grey boxes to be written... | ||
| + | |||
| + | IRD Reference pictures | ||
| + | Insertion of reference pictures | ||
| + | Macroblock partitions | ||
| + | Motion vector prediction | ||
| + | Motion compensation | ||
| + | Inter prediction examples (GH2) | ||
| + | |||
| + | Loop Filter | ||
| + | Definition | ||
| [[AVCHD resource (WiP):AVCHD:Deblocking]] | [[AVCHD resource (WiP):AVCHD:Deblocking]] | ||
| + | Examples & Summary | ||
| + | ====== AVCHD Transform & Quantization ====== | ||
| + | Definition, | ||
| + | |||
| + | Transform & Quantization | ||
| + | Process | ||
| + | Transform & quantization of 4x4 blocks | ||
| + | *Transform & quantization of 8x8 blocks is not used in GH2 | ||
| + | ===== Quantization Scaling Tables ===== | ||
| + | **Achieving the balance in Quantiser Matrix Design** | ||
| + | Higher QM values will lead to bigger rounding errors, nullifying subtle luminance variations in Keyframes. Using high values for high frequencies in B/P-frame QM could improve compressability. However, the tradeoff for using too high values could cause ringing. | ||
| + | |||
| + | Lowering the high frequency QM values in I-frames could be used to add bits to fine detail in keyframes, possibly creating better values for the B/P-frame process to work with. | ||
| + | |||
| + | Using the same QM for both Inter and Intra frames is less efficient than using different QM's, because of the difference in method used. | ||
| + | |||
| + | Finally, the standard Panasonic Lumix GXX matrices are already quite well made. The only reason I could see anyone using a custom QM is for increasing the amount of detail/size of a video (since for higher compression you could just as well use a higher quant, no need for a custom matrix) or for making things look flatter or softer and less sharpe. | ||
| + | |||
| + | <b>What is colour space - YUV or YCbCr?</b> | ||
| + | |||
| + | In simplistic terms, component video's color space is also known as YUV or YCbCr, where Y encodes luminance, U or Cb (blue) the difference between the blue primary and luminance, and V or Cr (red) the difference between the red primary and luminance. The low chromatic acuity (clearness of vision) allows a percentage data reduction of the color difference signals. In digital video, this is achieved by chroma subsampling. | ||
| + | In AVC colour space profiles the notation used is as follows: | ||
| + | 4:4:4 = no chroma subsampling. | ||
| + | 4:2:2 = chroma subsampling by a factor of 2 horizontally; this sampling format is used in the standard for studio-quality component digital video as defined by ITU-R Rec. BT.601-5 (1995), for example. | ||
| + | 4:2:0 = chroma subsampling by a factor of 2 both horizontally and vertically; it is probably the closest approximation of human visual color | ||
| + | acuity achievable by chroma subsampling alone. This sampling format is the most common in JPEG or MPEG and in the GH2's AVCHD implemntation. | ||
| + | |||
| + | |||
| + | |||
| + | DC transforms | ||
| + | Coding (CAVLC/CABAC) | ||
| + | transform coefficients | ||
| + | definition; coefficients - A number used to multiply a variable. | ||
| + | |||
| - | === Video Buffers ===== | + | ====== AVCHD/GH2 Rate Control ====== |
| Definition1, | Definition1, | ||
| - | GH2 Buffers | + | Choosing the right bitrate & IQ and Q (Quantisation) |
| + | GOP (Group of Pictures) | ||
| + | GH2's Time Limits | ||
| + | GH2's Video & Video 24 Buffers | ||
| * 0x01800000 = 25165824 Dec | * 0x01800000 = 25165824 Dec | ||
| * 0x02400000 = 37748736 Dec | * 0x02400000 = 37748736 Dec | ||
| Line 29: | Line 104: | ||
| * 0x03000000 = 50331648 Dec | * 0x03000000 = 50331648 Dec | ||
| * 0x03600000 = 56623104 Dec | * 0x03600000 = 56623104 Dec | ||
| - | + | GH2's Frame Limits | |
| - | === Other#2 ===== | + | GH2's Frame buffer size |
| + | |||
| + | ====== AVCHD Stream Analysis ====== | ||
| //Definition2,// | //Definition2,// | ||
| - | item#2 | + | Using Streamparser |
| + | Other tools | ||
| + | Elecard Streameye Studio Lite & Pro | ||
| + | |||
| - | === Other#3 ===== | + | ====== Handling AVCHD Files ====== |
| //Definition3,// | //Definition3,// | ||
| - | item#3 | + | AVCHD File Structure .mts |
| + | Playback InCamera | ||
| + | Import into computer | ||
| + | Editing & conversion | ||
| + | .mts Repair tools | ||
| + | |||
| - | === Other#4 ===== | + | ====== Other#4 ====== |
| //Definition4,// | //Definition4,// | ||
| item#4 | item#4 | ||