# ALL-I vs IPB



## jlev23 (Apr 10, 2012)

Andrew over at eoshd says to use A-I, even though his first post said he saw a fizz noise at 160 iso, which i don't see on my camera,these are his setting suggestions:
Menu settings

SHOOT 4
Movie rec. size: 1920 24/25p, ALL I
SHOOT3
High ISO speed NR – OFF
Highlight tone priority (HTC, D+) – OFF
SHOOT2
Auto Lighting Optimiser – OFF
C.Fn2 Disp./Operation
In Custom Controls set the SET button to Mag/Reduce for your focus assist


but another person says this:
"(I work with these codecs at the software level in my day job). My low level analysis of video frames shows artifacts present in ALL-I but not in IPB (part of the issue is PPro CS5.5.2). Thus, my findings show IPB is higher quality vs. ALL-I (especially lower noise, and less macroblock artifacts). ALL-I is useful for editing on slower computers; IPB provides higher quality (please post images from video frames if you find otherwise). I understand it's counter-intuitive, however I have tested it. You too can test it. More info here: http://www.dvxuser.com/V6/showthread.php?279229-Canon-5D-Mark-III-IPB-contains-more-detail-and-has-less-artifacts-than-ALL-I/page3"

but everything on the internet i see that says this, actually comes from him, so i don't know whether to believe it or not, I've already done two professional shoots in A-I mode and all seemed good, but if IPB is better, which canon says the opposite, then id love to know other peoples opinion.

and canon says this:
"The edit friendly intraframe ALl-I only compresses information in the current frame and does not use any temporal processing. Meaning the compression algorithm is not doing any type of comparison between frames. Think of it as a continuous series of still images that are each individually compressed. Intraframe compression is easier to edit with because the computer does not need to interpolate any data between each frame. With intraframe ALL-I, quality is higher, file size is larger, and the video files will use less computer processing power.

The file size conscious intraframe IPB uses some complex algorithms to compare neighboring frames and tries to find similarities from one frame to another. It can then achieve higher compression rates because it deals less with the parts of the image that stay the same from frame to frame. With interframe IPB, quality is lower (although Canon says not by much), file size is smaller, and the video files will use more computer processing power."


----------



## unruled (Apr 10, 2012)

I can definitely vouch for IPB being more resource hungry and achieving far better compression. I wouldn't bet on there being a huge difference in quality though, maybe some minor stuff in certain types of scenes. Im curious to hear what the pro's say.


----------



## jlev23 (Apr 10, 2012)

unruled said:


> I can definitely vouch for IPB being more resource hungry and achieving far better compression. I wouldn't bet on there being a huge difference in quality though, maybe some minor stuff in certain types of scenes. Im curious to hear what the pro's say.


you can vouch for it being a better compression? how and why???
what do you mean by resource hungry?


----------



## unruled (Apr 10, 2012)

http://en.wikipedia.org/wiki/Inter_frame


----------



## HenrikBC (Aug 10, 2012)

Semi old topic - but I don't think there's enough info about this out there. I've noticed some issues with the red channel on the mk3 - which was also evident on the mk2 - and tested IPB vs ALL-I on the mk3. This is what it looks like:







Camera picture style is: 0, -4, -2, 0 (HTP off)

My best guess is chroma subsampling. A 1 pixel tall blur applied to just the chroma in AfterFX does remedy the artifact. I have only ever seen this in the red channel - never in green or blue.

Anyone else found this - or even better, found a way to remedy it in-camera?


----------



## peederj (Aug 10, 2012)

That post clearly looks like a slam-dunk for All-I, but there's a certain Heisenberg uncertainty principle involved. ALL-I is easier for NLE's to render a still frame of, because there is no inter-frame interpolation to be done. IPB relies on the decoder to render a still frame.

So I'm not sure whether these 400% still crops are also affecting your red channel in motion from camera (a ProRes conversion could in theory also introduce the problem). Are they? I should test it myself, if the 5D3 is screwing up the reds in IPB then it's something that's well worth spending the memory/bandwidth to avoid. This is the first I've personally seen of this issue. Thanks for the report.


----------



## HenrikBC (Aug 10, 2012)

Not sure what you mean by "in motion from camera". The two framegrabs where produced using After FX. Playback in Premiere using the Mercury engine at full resolutions displays the same discrepancy between the clips.

The problem looks (somewhat) similar to the example on the top right of 5DtoRGB's front page: http://rarevision.com/5dtorgb/

Actually "you could argue that they're even better than the camera originals since they've undergone high quality *chroma smoothing*" sounds a lot like this is part of what 5DtoRGB does - apart from bypassing Quicktime decoding of the files.

If you make a red channel test of the two codecs on your mk3, please share the results.


----------



## peederj (Aug 10, 2012)

I just did a quick test with white lettering on a red background and I can't tell any difference between 24fps 1080p ALL-I vs. IPB at 100% or 300% crop, either when still frame or playing the movie, in FCPX after opening the clip direct from camera.

So no deal, I think you are having some kind of issue unique to your own setup. I will await confirmation from another source that isn't using your specific workflow, I figure it's in your decoding process that's tripping you up. It is not in the camera or in QuickTime/FCPX, they are not having this problem you are reporting.


----------



## HenrikBC (Aug 10, 2012)

Interesting... It should be noted that I run AfterFX and Premiere in a Windows7 environment.
When opening the files in the Quicktime player _both_ of the files have ugly edges - not just the IPB footage. You may be right on the decoding part. I just find it odd that AfterFX would decode the two files differently - as I have the impression that AE uses Quicktime for en/decoding anything - well - Quicktime related.

Would love to hear more views on these issues. Your findings suggest it may be avoided altogether.


----------



## paul13walnut5 (Aug 10, 2012)

Quicktime has a legacy issue that is not well publicised...

It dates from the days when computers had virtually no VRAM and so by default installation plays back at a compressed rate.

You need to go into preferences and check the 'play high quality video where available' to get anything like decent video from quicktime as a player.


----------



## HenrikBC (Aug 11, 2012)

The plot thickens. However, enabling the "High Quality" setting under preferences does not make any difference when opening the two videos - they both still look blocky in the Quicktime player.


----------



## victorwol (Aug 11, 2012)

HenrikBC said:


> Semi old topic - but I don't think there's enough info about this out there. I've noticed some issues with the red channel on the mk3 - which was also evident on the mk2 - and tested IPB vs ALL-I on the mk3. This is what it looks like:
> 
> 
> 
> ...



What you see is normal because of the 4:2:0 subsampling of the codec used by these cameras. And is far more noticeable on the red channel than any other. 

Just make a test on AE a 1 pixel width red line over black BG, make it diagonal, render it out to h.264 QT and you will see the same effect. Now render it to Proress 4:4:4 or uncompressed (no codec) QT and will look perfect. 

This is independent of using all-I or the othe codec. In fact. Several test have showed to me I can get better quality with the old codec than with the all-I since the data rate is better used with the old one unless you have a killer motion in which you might see bad motion artifacts. But so far, the overall look I get out of the old codec is better and less noisy.


----------



## HenrikBC (Aug 12, 2012)

victorwol: Did you read the posts after the one you replied to? Your answer does not explain why AfterFX decodes one of the streams prettier than the other - while Quicktime shows both of them as ugly - and peederj claims to have no problems with the red channel in neither IPB or ALL-I when shooting red against white.


----------



## peederj (Aug 12, 2012)

I should note, I claimed I don't see a difference. I don't know whether the output I see would be closer to the good or bad versions; it may well be the bad version. In which case, it's possible there is some resolution enhancing magic going on in your ALL-I version which would be a nifty thing to know if so.

What you need to do is look at your raw-from-camera footage on a Mac in a variety of players/NLEs and see which Windows version you are closest to. If there is damage I could be avoiding with better choices of workflow I would love to know.


----------



## HenrikBC (Aug 12, 2012)

Will check it out once I get a chance. 

RAW quicktime files from the camera can be fetched here:
http://junk.chown.dk/hbc/5d_redchannel/


----------



## M.ST (Aug 12, 2012)

ALL-I is better in quality and better in cutting.


----------



## HurtinMinorKey (Aug 13, 2012)

M.ST said:


> ALL-I is better in quality and better in cutting.



ALL-I shows macro blocking because it has to draw each frame independently, and the bit-rate is just not high enough to draw all the detail. This is the reason that inter frame often looks better when viewed in motion.


----------



## victorwol (Aug 13, 2012)

M.ST said:


> ALL-I is better in quality and better in cutting.



I respectfully disagree.... as HurtinMinorKey stated, even if you have more bits per frame, those need to represent the full frame, on each frame, while the other one, only the difference so at the end, you see less compression with the IPB than with the ALL-I yes it is easier to edit with it, but if it comes to image quality, I rather have IPB by far.


----------

