The XAVC-I codec found for example on the Sony FS7 is normally regarded as a better alternative to XAVC-L. But is this always the case?
The other day I was chatting with some friends about recording options with the Sony FS7, and in particular whether anyone ever used XAVC-L. There was pretty universal agreement that XAVC-I was the way to go, until I mentioned that, broadly speaking, if I was recording a scene with little or no motion (such as an interview) I would choose ‘L’ and if I was filming a subject with a lot of movement, I would choose ‘I’. Unexpectedly, this aroused some puzzlement from the group. Read on and I’ll explain to you my reasoning.
What Is The Difference?
When one thinks about compression, one typically only thinks of spatial compression, which is the process of averaging colour and luminance values across a block of pixels in an image. While spatial compression does indeed play a major role in compressing video frames, it isn’t the only way to reduce file sizes. Temporal compression (from the Latin ‘tempus’, meaning ‘time’) is the often overlooked cousin of spatial compression and is the crucial differentiator between these two formats – XAVC-L employs temporal compression, whereas XAVC-I does not. Compressing frames over time involves using a special frame structure called a GOP (Group Of Pictures). XAVC-L uses a Long GOP structure, hence the ‘L’ in XAVC-L.
How Does Temporal Compression Work?
If you didn’t know better, you’d probably assume that when you set your camera to, say 24fps, it’s snapping 24 whole frames (intra coded ‘I’ frames) every second. Seems logical, doesn’t it? But if your codec employs temporal compression (and a lot do), most of these frames actually only contain parts of the recorded scene. By recording a small number of whole frames, and then only storing the differences in the other frames (either predictive coded ‘P’ frames or bi-predictive coded ‘B’ frames), the camera can drastically reduce the data rate and overall file size of your clips. It sounds like it should look awful, but if your data rate is high enough and your temporal compression algorithm is efficient enough, it often looks identical to non temporally-compressed footage. This goes against your intuition but can be born out by a few simple tests.
When your subject or camera movement is fast, erratic and unpredictable, XAVC-L (or any temporally compressed format) shows its weaknesses by introducing undesirable motion artefacts. If you shoot a relatively motionless subject in XAVC-I, the data rate, though higher, is spread more thinly and you actually end up with no (or sometimes actually less) benefit compared to shooting with a temporally-compressed codec – the stationary trees in this case are a perfect example of this effect.
Which Is Best?
Every scene is different and every time you shoot, you will find unique attributes that will dictate different settings. It’s just too simplistic to think that you can always shoot in XAVC-L and get better results than XAVC-I, or vice versa.
For example, if I were shooting an interview against a green screen, I definitely wouldn’t choose XAVC-L. There would be no background detail benefits, because there is no background, and XAVC-L is only 8bit 4:2:0, so there would be losses in colour fidelity (which is of paramount importance when pulling a key) by choosing it over XAVC-I, which is 10bit 4:2:2. You’ve simply got to ask yourself, do my circumstances demand all that extra data?
So, as you can see in the examples above, in certain circumstances temporal compression will actually improve your footage. But none of us should ever assume that one setting is going to work for all scenes. Every single time you shoot, you should make technical decisions about codec, gamma, frame rate, resolution, and a hundred other things, based on what is best for your scene and not what worked last week or what someone else tells you is right. But next time you’re reaching for an I-frame-only acquisition codec, like XAVC-I, spend a second thinking about whether all those extra frames are really going to benefit you, because it might just be that you’ve got gigabytes, or even terabytes of archived rushes, that could have been considerably smaller.
Do you choose codecs on a job-by-job basis? Let us know in the comments!