This shows you the differences between two versions of the page.
|
gh2-hack:hack-terms-faq [2013/01/23 01:06] vitaliy_kiselev |
gh2-hack:hack-terms-faq [2013/01/24 15:16] (current) briansiano |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== Hack Terms FAQ ====== | ====== Hack Terms FAQ ====== | ||
| - | Maybe we ought to have a thread where we draft up and refine a good FAQ on the subject. Here's a first stab at it, and obviously, changes, amendations, and clarifications are needed. | + | Vitaly's hack enables users to reconfigure the way the GH2 camera encodes the video, in order to improve the quality of its recorded images and motion. New or less-techy users, trying to decide which patch to try or use, may find it daunting to read through Personal View's lengthy forum discussions. This FAQ is intended to give such users a rough idea of what's going on. |
| ===== The Basic Overview ===== | ===== The Basic Overview ===== | ||
| - | In an ideal world of fast cameras and unlimited data storage, video would be stored as a series of high-resolution frame images, all stored in a lossless and uncompressed data format. | + | In an ideal world of fast cameras and unlimited data storage, video would be stored as a series of high-resolution frame images, all stored in a lossless and uncompressed data format. Imagine storing your video as a series of TIF or RAW files. |
| - | Sadly, most video cameras don’t support these luxuries. When video is recorded, it is usually compressed; otherwise, it'd require writing massive amounts of data to the memory card, which may not be large enough or fast enough to handle it. This requires the camera to perform some very intensive processing to compress the video data, so that it can be written to the memory card. | + | Only the really high-end video cameras, like the Red or the Arri, support this method. But for most other cameras, video is usually compressed. This is needed because the memory card may not be large or fast enough to capture the massive data streams created by uncompressed video. This requires the camera to perform some very intensive processing to compress the video data. |
| - | Because this processing takes place during shooting, the camera has to do this very quickly. So the camera relies on shortcuts, which will be described later in this FAQ. As a result, the camera uses "lossy" data compression, and the image and motion quality can be compromised. (For now, we recommend reading Wikipedia on http://en.wikipedia.org/wiki/Video_coding#Video.) | + | This processing takes place during shooting, so the camera has to do this very quickly. So the camera relies on shortcuts, which will be described later in this FAQ. As a result, the camera uses "lossy" data compression, and the image and motion quality can be compromised. (For now, we recommend reading Wikipedia on http://en.wikipedia.org/wiki/Video_coding#Video.) |
| - | Vitaly's hack enables users to reconfigure the way the GH2 camera encodes the video, in order to improve the quality of its recorded images and motion. | + | Vitaly’s hack enables us to change the camera’s shortcuts a little, and improve the quality of its video. This reconfiguration is complex. Sometimes, the settings may not work with each other. (For example, some patches with high image quality may have trouble recording acceptable sound, or "spanning" across multiple files. More about this below.) |
| - | This reconfiguration is complex; sometimes, the settings may not work with each other. (For example, some patches with high image quality may have trouble recording acceptable sound, or "spanning" across multiple files. More about this below.) So some users have spent a lot of time and effort experimenting with the settings, and they have developed "patches" with various strengths and weaknesses. These include the Sanity patch, the FlowMotion patch, and the many patches developed by Driftwood.) | + | So some users have spent a lot of time and effort experimenting with the settings, and they have developed "patches" with various strengths, weaknesses, and reliabilities. These include the Sanity patch, the FlowMotion patch, and the many patches developed by Driftwood. |
| - | New or less-techy users may find it daunting to read through Personal View's lengthy forum discussions, just to find out what patch is best for their needs. This FAQ is intended to give such users a rough idea of what's going on. | + | The material below will help you understand what your camera is doing with these patches. |
| ===== Video Compression Basics ===== | ===== Video Compression Basics ===== | ||
| - | Imagine that you have a car that’s controlled by a computer, and you want it to travel down ten miles of perfectly straight highway all by itself, with no driver. One way to do this is to drive the car yourself, once, and have the car’s computer “record” the data—the car’s position, its orientation, speed, steering, etc. In theory, you could then put the car at its starting point, hit the Playback button, and the car should follow the same route every time. | + | ===== Intraframe and Interframe compression ===== |
| - | Recording video is like driving the car on its initial trip down the highway, and assembling the data about the trip. | + | Earlier, we said that video could be stored as a series of full-resolution TIF files, but this would create far too much data. One way of compressing that data would be to store each frame not as a TIF file, but as a compressed JPEG. (As you may know, saving a TIF file as a JPEG makes a much smaller file.) This technique of compressing each frame individually is called **intraframing**. Video compression doesn’t use JPEG format, but you get the idea. (See http://en.wikipedia.org/wiki/Intraframe for more information.) |
| - | Ideally, you’d want to record every bit of data every second. But let’s also say that you have technical reasons to make the data smaller. Maybe the computer can’t record the data at every second—or, when it plays the data to the car, the car can’t respond very quickly. So, you find ways of making the data smaller. Maybe you decide to record the data every five seconds; that’d reduce the data down by 80%. Or, consider this: when you’re actually driving, you just tap the steering wheel every couple of hundred yards or so, and you’ll stay on course well enough. That might shrink the data down even further. So you just record the data when it changes. | + | The fact that we’re compressing video files, and that video frames look very much like each other, enables a more complicated technique called **interframing**. This is the technique used by the GH2. |
| - | In theory, the car should stick close enough to the road to get where it’s supposed to go, without any catastrophic problems. But the more you use these data shortcuts, the more the car will drift from its intended path. It may not drift much, but it’ll drift. | + | Here, the camera records an initial frame (or “**I-frame**”). Usually, this I-frame is compressed by intraframing, similar to a JPEG. But the second frame is recorded as only the changes that occur from the I-frame. (See http://en.wikipedia.org/wiki/Video_coding#Video) for a discussion.) So the video file may consist of the I-frame (Frame 1), and then data that contains only changes between Frame 1 and 2, and then, the changes between frames 2 and 3, etc. This is what interframing is. This is a form of "temporal compression" because it involves using information from other frames in the sequence. |
| - | This is what video data compression is about. If you record the full data for every frame, you get perfect data, but those big files can be difficult to play back. But the techniques to make the data smaller introduce uncertainty, noise, and drift. | + | Again, Interframing requires the camera to perform a LOT of math before writing the data to the memory card. (And such data requires a lot of math to play back.) It can also be a lossy technique, especially when combined with further compression techniques such as macroblocking and motion prediction. |
| - | ===== Interframe and Intraframe ===== | + | ===== Macroblocking and Motion Prediction ===== |
| - | There are two basic techniques by which video can be compressed. One very simple technique is to take each frame of the video, and use a compression system like the JPEG standard to compress it. (Think of taking an uncompressed TIFF file and saving it as a JPEG.) This can be very lossy, or even lossless, but it also requires a lot of processing work by the camera. | + | Earlier we said that, in interframing, the video records only the changes between one frame and the next. The recording of these changes can be compressed even more. |
| - | The fact that we’re compressing video files, and that video frames look very much like each other, enables a more complicated technique called "interframing." This is the technique used by the GH2. | + | Sometimes, instead of recording all the individual pixel changes, it’s easier to say (in essence) “Take this group of pixels and move it one pixel to the left.” So, instead of recording the changes for every individual pixel, the camera may calculate the changes for small blocks of pixels—perhaps a 2x2 block, or a 4x4 block, a 4x6 block, or even a 16x16 block. These are called **macroblocks**. This technique enables the camera do perform its recording math much more quickly, but it does lose some data because the camera’s basically averaging the content of those blocks. (Consult http://en.wikipedia.org/wiki/Macroblocks for more details.) |
| - | Here, the camera records an initial frame as a full photo. The camera then records the subsequent frames as only the changes that occur from the previous frame. (See http://en.wikipedia.org/wiki/Video_coding#Video) for a discussion.) So the video file may consist of the initial Frame 1, and then data that contains only changes between Frame 1 and 2, then between frame 2 and 3, etc. | + | When macroblocking isn’t done properly, you’ll see little squares in your video that look like flickering blocks. (This is usually seen in areas like the crowds at sports events, leaves on trees, or water in a running stream—where the details of motion can be lost because there’s a lot of similar movement nearby.) This is an artifact of macroblocking, and it’s one of the reasons why people hack the GH2 camera; we want to reduce or eliminate that garbage. |
| - | Again, Intraframing requires the camera to perform a LOT of math before writing the data to the memory card. It is also a lossy technique, especially when combined with further compression techniques such as macroblocking and motion prediction. | + | In addition to macroblocking, the camera uses **motion prediction** to compress the data further. This involves examining the frames, examining how parts of the image move between certain frames, and then storing estimates of where those parts are in the frames in-between. |
| - | ===== Macroblocking and Motion Prediction ===== | + | It’s like this. The camera is looking at Frame 1 and sees a bundle of pixels in one spot. It looks at Frame 5 and sees a similar batch of pixels somewhere else. So it assumes that the two groups of pixels depict the same object, and it’s moved between the five frames. So it estimates where those pixels would be on frames 2, 3 and 4. This is called “motion prediction.” Again, it loses some data if it’s not done properly. Again, this is a complicated operation, so read http://en.wikipedia.org/wiki/Inter_frame for more information. |
| - | Earlier we said that the video records only the changes between one frame and the next. There are several ways of recording these changes, some of which allow greater compression. | + | But here’s what you can take away for now. The video compression used by the GH2 works like this. The first frame is stored as-is. Each subsequent frame is stored as the changes from the previous frame. The changes are calculated using techniques like macroblocking and motion prediction. And these techniques sometimes make mistakes. Errors crop up. Motion doesn’t always match predictions. Macroblocking can look blocky. Both of these are lossy compression techniques. So some correction needs to be performed as well. |
| - | For example, instead of recording the changes for every pixel, the camera may calculate the changes in small groups of pixels, called “macroblocks.” This FAQ won’t go into the complicated description (consult http://en.wikipedia.org/wiki/Macroblocks if you want that), but think of it this way. Sometimes, you’ll see little squares in your video, especially in areas of movement that are difficult to resolve (like water in a turbulent stream). This is an artifact of macroblocking, and it’s one of the reasons why people hack the GH2 camera; we want to reduce or eliminate that garbage. | + | ===== P frames and B frames ===== |
| - | Another technique involves examining the frames, examining how parts of the image move , and recording how whole blocks or areas move about. Sometimes, instead of recording all the individual pixel changes, it’s easier to say (in essence) “Take this group of pixels and move it one pixel to the left.” This is called “motion prediction.” Motion prediction can compress the data even further, because sometimes it’s possible to predict the motion of certain pixels across several frames, and not only the next frame. | + | We said earlier that full video would be a series of full frames stored at full resolution, while compressed video stores only one frame and estimates the rest. So you may have one initial, perfect frame, but the frames that follow become less and less perfect because prediction’s never quite accurate. |
| - | Let’s go back to that robot car we were talking about earlier. Let’s say the car is at a certain point on the highway, but we know where it’s facing, how fast it’s going, and where the steering wheel is pointed. So we can predict where the car will be, and all of the other data about its travel, five or ten seconds from now. And in video, we can predict where a group of pixels will be four or five frames into the future. (The further into the future, the less reliable the predictions are. Like the weather.) Again, this is a complicated operation, so read http://en.wikipedia.org/wiki/Inter_frame for more information. | + | So, to compensate for this, maybe you have the camera record every tenth frame at full resolution. That way, the data compression doesn’t get too out of line: it’s as though you’re nudging it back to being accurate every third of a second. |
| - | But here’s what you can take away for now. The video compression used by the GH2 works like this. The first frame is stored as-is. Each subsequent frame is stored as the changes from the previous frame. The changes are calculated using techniques like macroblocking and motion prediction. And these techniques sometimes get it wrong. Errors crop up. Motion doesn’t always match predictions. Macroblocking can look blocky, so both of these are lossy compression techniques. | + | This is where data compression and video can get very complicated. The Wikipedia page http://en.wikipedia.org/wiki/Inter_frame#Frame_types has a good description of this, and we’ll use its illustrations as an example. |
| - | ===== P frames and B frames ===== | + | Every tenth frame will be the initial, I-frame; it’s usually compressed by intraframing, but these frames are the least compressed in the data. Your camera uses motion prediction to “predict” what the fourth and seventh frames will be, based on the surrounding I-frames. The fourth and seventh frames are called P-frames (for “predicted”) |
| + | And the frames in between the P-frames—the B-frames, for “bi-directional”) are, in turn, “predicted” from the surrounding P-frames. | ||
| - | We said earlier that full video would be a series of full frames stored at full resolution, while compressed video stores only one frame and estimates the rest. So you may have one initial, perfect frame, but the frames that follow become less and less perfect because prediction’s never quite accurate. So, the camera uses another technique to check the predicted frames against later frames. | + | The three types of frames differ in terms of their reliability for accuracy. I-frames are, of course, accurate and reliable. P-frames are estimates derived from the I-frame—they’re not perfect, but they’re very good. B-frames are estimates derived from P-frames—so they’re not as good as P-frames. (Some video codecs allow for deriving B-frames from other B-frames, but we don’t have to worry about that for now.) |
| - | This is where data compression and video can get very complicated. The Wikipedia page http://en.wikipedia.org/wiki/Inter_frame#Frame_types has a good description of this, and we’ll use its illustrations as an example. | + | Because the predicted frames are checked against frames in the past and future, the ‘drift” from macroblocking and motion prediction is reduced. |
| - | Every tenth frame will be a perfect, uncompressed frame—it’s called an I-frame (for “initial”). Your camera uses motion prediction to “predict” what the fourth and seventh frames will be from that I-frame. The fourth and seventh frames are called P-frames (for “predicted”) | + | ===== Quantization and Deblocking Tables ===== |
| - | And the frames in between the P-frames—the B-frames, for “bi-directional”) are, in turn, “predicted” from the surrounding P-frames. | + | This FAQ’s intended to explain things so that people have a //general// idea of what Vitaly’s Hack changes. But these topics– quantization and deblocking tables– can be deeply detailed. Unless you’re writing patches for the GH2, this is something you can skip. |
| - | + | ||
| - | The three types of frames differ in terms of their reliability for accuracy. I-frames are, of course, accurate and reliable. P-frames are estimates derived from the I-frame—they’re not perfect, but they’re very good. B-frames are estimates derived from P-frames—so they’re not as good as P-frames. | + | |
| - | + | ||
| - | Because the predicted frames are checked against frames in the past and future, the ‘drift” from macroblocking and motion prediction is reduced. | + | |
| + | Here’s a general idea of what they are. We’ve mentioned that data compression requires the GH2 to perform a lot of math in compressing the data. One way to speed up that process is to provide the GH2 with pre-calculated tables of data to use, because it's faster to look up information than calculate it. Some hacks, like Flow Motion, use custom-designed tables of data to improve the quality of the compressed video. | ||
| + | |||
| ===== Group of Pictures (GOP) ===== | ===== Group of Pictures (GOP) ===== | ||
| Line 72: | Line 71: | ||
| The GOP Size is the number of frames between each P-frame. In our example above, that value would be 4. | The GOP Size is the number of frames between each P-frame. In our example above, that value would be 4. | ||
| + | |||
| The GOP Length is the number of frames in the group—or the number of frames between I-frames. In our example, this value would be 10. | The GOP Length is the number of frames in the group—or the number of frames between I-frames. In our example, this value would be 10. | ||
| - | Obviously, changing these numbers affects the quality of the data compression. If the GOP Length was reduced, we would have more frequent I-frames, and the video data would be less compressed and more perfect. If the GOP Size were reduced, then we would have more P-frames and fewer B-frames—the data would be less compressed, less lossy, and with less drift. | + | (Duartix has pointed out that, in many of the discussions on Personal View, people use both “GOP Size” and “GOP length” to refer to the length between I-frames. This may confuse some people. But for the purposes of this FAQ, we’re not trying to turn everyone into a patch-designer; we just want people to have a good idea of what’s going on under the hood.) |
| - | So, at long last, we learn something about how the GH2 patches improve the quality of your video—by changing the GOP values. | + | Obviously, changing these numbers affects the quality of the data compression. If the GOP Size were reduced, then we would have more P-frames and fewer B-frames—the data would be less compressed, less lossy, and with less drift. And if the GOP Length was reduced, we would have more frequent I-frames, and the video data would be less compressed and more perfect. |
| + | So, at long last, we learn something about how the GH2 patches improve the quality of your video—**by changing the GOP values**. | ||
| + | ===== Variable GOP Values and Bitrates ===== | ||
| - | ===== Bitrate ===== | + | The GH2 can also change its strategy for compression, by changing the GOP values “on the fly.” For a video with very little movement—a shot of a still pond with no wind ruffling the trees-- it may use high GOP values, use large macroblocks, and thus, compress the data by a huge margin. For a video with a lot of movement and action, where every pixel changes from frame to frame (like a panning shot of a football game), the camera will switch to low GOP values, store more I-frames, use smaller macroblocks, and create data that isn’t as compressed so you get to see more details. (It can also do things like use bigger macroblocks, change how it predicts movement, etc.) |
| + | But there are limits on how much the GH2 can do with this. That’s where bit rates come in. | ||
| - | If the GH2 is shooting a lot of action, it can’t decide to simply shoot constant I-frames, because that’d create too much data for the system. And if it’s shooting a lot of placid, low-movement images, it can’t compress it down to a still image. It can’t decide to use macroblocks that are too big, because the image would start to look blocky, and it can’t use small macroblocks too often because, again, it’d create too much data. | + | ===== Bitrates ===== |
| - | So the camera has to have limits. The camera is creating data that falls within a range, a sweet spot between good compression and high detail. This range is specified by the bit rates. | + | The GH2 can handle only so much data at a time. So the GH2 can’t simply shoot constant I-frames, one after the other, because that’d create too much data for the system. But it can’t rely too much on the predictions of P-frames and B-frames, because they’ll start to look bad. It can’t use macroblocks that are too big, because that’d look blocky, but it can’t use macroblocks that are too small because it’d create too much data. |
| - | A unhacked GH2’s highest bit rate is 24mbps. So the GH2 is constantly adjusting its compression techniques, as described above, so that the data stream doesn’t exceed 24mbps. | + | So the camera has to have limits. All of the techniques above can be adjusted, on the fly, for greater or lesser compression. So the camera is adjusting these techniques so that its data falls within a range, a sweet spot between good compression and high detail. This range is specified by the **bit rates**. There has to be a minimum bit rate so that all the frames have a minimum standard of quality, but also a maximum bit rate so the data limits of the camera aren’t broken. A unhacked GH2’s highest bit rate is 24mbps. So the GH2 is constantly adjusting its compression techniques, as described above, so that the data stream doesn’t exceed 24mbps. |
| - | But if you have a hacked GH2, you can specify a higher bit rate—say, 40mbps, 80mbps, or in the case of some of Driftwood’s patches, more than 100 mbps. Now, the camera has the leeway to use compression techniques that are less lossy, and preserve movement and detail more effectively. That is the advantage of higher bit rates. | + | But if you have a hacked GH2, you can specify a higher bit rate—say, 40mbps, 80mbps, or in the case of some of Driftwood’s patches, more than 100 mbps. A camera using one of these patches has the leeway to use compression techniques that are less lossy, and preserve movement and detail more effectively. That is the advantage of higher bit rates. |
| - | This does not always work. You can’t simply use Vitaly’s hack to specify a 100 mbps bit rate and the camera to work flawlessly. Your memory card may not be fast enough or large enough to handle a flood of uncompressed data. The CPU can overload. Or, the other settings, like the GOP values, create conflicts or don’t work right. Happily, we don’t have to go into why this doesn’t always work. That’s for the people who design and test the patches, and who read all of the forum posts about these things. They try various combinations of GOP sizes, bit rates, specs for the macroblocking and motion prediction, until they find combinations that do work. | + | This does not always work. You can’t simply use Vitaly’s hack to specify a 100 mbps bit rate and expect the camera to work flawlessly. Your memory card may not be fast enough or large enough to handle a 100 mbps flood of data. The CPU can overload. Or, the other settings create conflicts or just don’t work right. |
| - | + | ||
| - | The rest of us don’t need to understand this at that level. All we need to know for now is what the “bit rate” really means for us. The bit rate is a number that shows how much range the camera has in compressing video; the higher the number, less loss in compression. | + | |
| - | + | ||
| - | + | ||
| - | ===== Interframe and intraframe ===== | + | |
| - | + | ||
| - | These are two techniques by which video is compressed. The simpler technique is "intraframing." For each frame of video, the camera compresses it down in the same manner as a JPEG picture file. This can be very lossy, or even lossless, but it also requires a lot of processing work by the camera. | + | |
| - | A more complicated method is "interframing." Here, the camera records an initial frame as a full photo. The camera then records the subsequent frames as only the changes that occur from the previous frame. (See http://en.wikipedia.org/wiki/Video_coding#Video) for a discussion.) So the video file may consist of the initial Frame 1, and then data that contains only changes between Frame 1 and 2, then between frame 2 and 3, etc. | + | Happily, we don’t have to go into why this doesn’t always work. That’s for the people who design and test the patches, and who read all of the forum posts about these things. They try various combinations of GOP sizes, bit rates, specs for the macroblocking and motion prediction, until they find combinations that do work. But the rest of us don’t need to understand this at that level. All we need to know for now is what the “bit rate” really means for us. The bit rate is a number that shows how much range the camera has in compressing video; the higher the number, less loss in compression. |
| - | Since most frames aren't stored as full frames, but are calculated, this technique requires the camera to make a lot of calculations before writing the data to the memory card. It is also a lossy technique. It can be made less lossy by sampling full frames more frequently. | + | ===== Conclusion ===== |
| - | Refinements to interframe Not written yet: see http://en.wikipedia.org/wiki/Inter-frame#H.264_Inter_frame_prediction_improvements for now. | + | We hope this FAQ's helped you understand a little more about Vitaly's hack, the various patches, video compression and your GH2 camera. As we said, this FAQ doesn't explain everything in fine detail: for that, you really do have to Read the Forums. But you should be able to follow the discussions there with less confusion, and maybe get better video from your camera. |