• Wondering which camera, gear, computer, or software to buy? Ask in our Gear Guide.

Does H.264 REALLY come apart in post?

superamazing

superamazing

All across the internet, I've heard that H.264 is not a resilient codec, and "comes apart in post." However, I have doubts about that.

I acknowledge that H.264 is a pain to edit, because it's slow. The intraframe compression means your computer has to look around for the relevant information.

But the information is still there. For this reason, I simply do not understand how color grading or some similar process would cause the image to "come apart."

Are there any examples of this? I want to see a test, where some H.264 footage is put through a grueling regime of color grading and effects, compared to that same footage converted to an intermediate codec and put through the same exact process. I suspect the output would look exactly the same.
 
Sort by date Sort by votes
I think the answer to your question can be found if you check out lossy (h.264) codecs and lossless codecs.

The rule of thumb is that you can export in lossless formats as many times as it is required to do your job, but only export to a lossy “delivery” format ONCE. This way, you minimize the loss of quality on the final render — the one that’s meant to reach your viewership. http://eugenia.queru.com/2007/10/19/understanding-intermediate-and-delivery-video-formats/
 
Upvote 0 Downvote
I guess the answer is much more that it is a mathematical certainty. Where you will "see" the difference is when you zoom the image in 200% before and after a render. Once you render several layers of effects, you will see the difference.

Think about this... make a copy of a copy of a copy, and you will see degradation of the image quality. It's a very similar analogy here.
 
Upvote 0 Downvote
sonnyboo said:
I guess the answer is much more that it is a mathematical certainty. Where you will "see" the difference is when you zoom the image in 200% before and after a render. Once you render several layers of effects, you will see the difference.

Think about this... make a copy of a copy of a copy, and you will see degradation of the image quality. It's a very similar analogy here.
Click to expand...

That's how it was explained to me and it makes sense and also H.264 will look better after editing in that format on a small screen than a larger screen.

You can add things to a lossy codec, but you'll lose something at the same time.
 
Last edited:
Upvote 0 Downvote
It says "The rule of thumb is that you can export in lossless formats as many times as it is required to do your job, but only export to a lossy “delivery” format ONCE. This way, you minimize the loss of quality on the final render — the one that’s meant to reach your viewership." Does this mean that you can only export once? But when editing, when would you ever need to export, import that file, and export again? Isn't that the only case where quality would be reduced?
 
Upvote 0 Downvote
The main "fall-apart" that they're talking about is more likely the little amount of info that makes it back to the editor. You say all the info is "still there" but it isn't, the compression throws away every bit it doesn't need and then some. The color sampling is generally pretty poor with it as well.

I have a 7D and it's great for the price, but the codec is the #1 thing that keeps it from really competing with the big boys. The image is never quite as "crisp" as I'd like.
 
Upvote 0 Downvote
As others have said, h.264 is a lossy codec, and to keep file sizes manageable it throws away a lot of image information. It does a very good job of maintaining a good looking image while doing so - but the key is good 'looking'. It's designed to throw away information that is unlikely to be perceived by the human eye, while maintaining the appearance of the stuff that is likely to be noticed.

There's two problems with this when it comes to post. The first is that once you start pushing the image around, in color correction or a similar process, you potentially move image data from a range that is unnoticeable to the human eye up into that range. An example is where you try to pull up detail in the shadows and blocky compression artifacts appear instead of clean image data - that's because the codec knew those areas were below a visible threshold (when you shot them) and applied more aggressive compression to that area.

The second problem is that the codec can't tell the difference between real image details and errors introduced by the previous generation of encoding. So minor errors get emphasized with each compression pass, and the additional 'details' from these errors make it more difficult to compress cleanly each time. This is called 'error concatenation' and results in your video looking progressively worse with each generation.

The first problem isn't solved by using a better codec for post - it's just the limitation of shooting with a camera that captures to h.264. The second problem can be helped though - codecs like cineform and prores are designed for post production, so in addition to being faster to decode they are optimized for multiple generations of compression with minimal error concatenation.

There's a third factor too - 8 bit vs. 10 bit codecs. The h.264 that comes out of your camera is 8 bit, and when you start pushing that data around and then render it back to an 8 bit codec you can end up with banding in gradients where data gets thrown out based on changes in contrast, etc. Rendering from 8 bits to a 10 bit codec won't improve your original data, but it does let you keep as much as possible through each step of the process. So even if you capture at 8, there are significant advantages to doing all of your post in a 10 bit format.
 
Upvote 0 Downvote
Is 8 bit really a problem? On my computer I've done some screengrabs of movies shot on film and of videos shot with DSLRs. All were converted to jpeg images (same degree of compression). Then I decreased the color depth to 8 bit (256 colors) for both. You can still very clearly see the difference. Film is still beautiful even in 8 bit per pixel images.
 
Upvote 0 Downvote
I definitely understand the weaknesses of capturing H.264. However, it seems to me that converting H.264 to an intermediate codec shouldn't give you any more ability to manipulate the data.

It's possible that I'm going to reveal my lack of knowledge here, but I guess that's kind of the point of my post!

My understanding is that H.264 stores most of its data in periodic key frames. That's how it gets away with such insane compression--most of the data exists in relation to these key frames, which come along every 24 frames or so.

But when you convert H.264 to ProRes or whatever, your computer spreads the information that already exists around, so that the video looks virtually identical, except the compression is now optimized for editing. The quality is no higher than before, in fact it's slightly worse, because it's now a second-generation encoding.

So, your computer takes the data embedded inside the highly-compressed H.264, and spreads it around to create an intermediate. It can't create any new data, and any blocky artifacts that exist in the dark parts of the original data would be faithfully preserved.

Although most of the information is stored in these keyframes, there's nothing to prevent your computer from extracting the relevant data at any stage of the editing process. If your computer can create an intermediate, it can get access to the same data even if the colors have been altered or the time has been shifted. The original files with all the original data never change, so I don't understand where H.264 loses its information.

Reading all the responses to my original post, I'm getting to be more convinced that I'm wrong. If I were right, it seems likely that someone would agree with my analysis and defend it! At this point, I'm more just curious where my errors are.

Hopefully now you see the assumptions that lead me to this conclusion, and maybe you can point out which ones are wrong!
 
Upvote 0 Downvote
What is supposed to make the technicolor cinestyle profile "work" is that it tricks the compression into retaining more of the data in the shadows and highlights instead of throwing them away (because it has to throw something away so it chooses as noted above the areas that matter 'least"). This then comes at the expense of some of the information in the midtones.
 
Upvote 0 Downvote
superamazing said:
So, your computer takes the data embedded inside the highly-compressed H.264, and spreads it around to create an intermediate. It can't create any new data, and any blocky artifacts that exist in the dark parts of the original data would be faithfully preserved.
Click to expand...

I think we found the stumbling block.

This would be true if you didn't alter a thing from the original H.264 file in post. New data that would be created include:

1. Any color changes, including white balance or custom looks.
2. Any time changes.
3. Just about anything else you do to it. :)

Hmm..wait! Just for laughs, I'll try this experiment later to try out a theory -

Import an H.264 file into your NLE timeline noting the exact file size, let's say 1gb for easy math. Make NO changes and immediately export to an H.264 file.

Is it still 1gb or was it compressed again?

I'm curious to see what happens. Now you have me curious! :lol:
 
Upvote 0 Downvote
superamazing said:
I definitely understand the weaknesses of capturing H.264. However, it seems to me that converting H.264 to an intermediate codec shouldn't give you any more ability to manipulate the data.
Click to expand...

The problem is your misperception as to what happens to the original footage when you manipulate it. As you said, the H.264 codec footage is relying on filling in the "in between" frames with data from existing frames.... the INTERMEDIARY codecs, actually create those whole frames. Yes, they are based on the H.264 original files to create them, but it does create them whereas they do NOT exist as whole frames in the original file.

That is the root of how the intermediary codecs help in the processing during editing and also why the files are bigger. This helps because if you manipulate the original H.264 files with color correction, etc. it does not have whole frames for every frame to work with, so the CPU will "assume" things, thus creating artifacting and blockiness that the intermediary codec files will not because it already created whole frames.

Does that make sense?
 
Upvote 0 Downvote
I'm finding this educational! Considering how much the "H" seems to become prevalent in the internet, this is a good thread-lots of info here-thanks to the OP for starting it! :)
 
Upvote 0 Downvote
Yes 8 bit is actually a problem.

8 bit = 256 gradations per channel
10 bit = 1024 gradations
16 bit = 65536 gradations

The difference between 256 levels of color and 65536 levels should be self-explanatory. When altering the color palette, the more information that is available, the less intrusion of artifacts and errors in the calculations.

This allows for a strategy that is cheap and effective: convert your H264 to a better codec for color correction. Then convert it back for delivery. It won't give as much data as capturing uncompressed, but it will treat what you have captured with kid gloves and hopefully give more room for altering the colors, than otherwise.
 
Upvote 0 Downvote
My God, this stuff gives me a headache.
I hate computers and computer cr@p.

Well, naturally I don't wanna record material in a lossy format as H.264 (heretofore muttered as "Beelzebub" under my breath) but it seems rather inescapable for the fresh and soft meat classes of indie film makers.

http://www.luminous-landscape.com/tutorials/video-primer.shtml
"AVCHD (Advanced Video Codec High Definition) is the latest format standard, and has been adopted by the big three; Sony, Canon and Panasonic. It allows for a very high degree of compression without quality loss, but during its first couple of years on the market has been plagued with issues related to artifacting, overall image quality, and difficulty of editing. Now on its third generation these issues are starting to disappear, though the format still requires the most powerful computer possible if one is interested in transcoding AVCHD. Bit rates are around 17 Mbps, but the latest Canon cameras, like the HR-11 have upped this to the format's theoretical maximum of 25 Mbps.

Because of AVCHD's high degree of data compression batch processing to a more standard (and less compressed) format is the best way to work, though file sizes balloon considerably when this is done. This is called transcoding. AVCHD is based upon the AVC/H.264 MPEG-4 codec.

AVC/H.264 MPEG-4 (AVC) is the format used by Sanyo and Samsung. It uses a lower bit rate than AVCHD (usually 12 - 16 Mbps), but is easier to edit as it requires less processing power since it is less compressed. Now that AVCHD has matured in the latest generation of cameras it's likely that AVC/H.264's days may be numbered, and I wouldn't be surprised to see Samsung and Sanyo eventually adopt AVCHD along with the big three.

MPEG-2 Transport Stream is an alternative format exclusively backed by till now JVC, and used in its Everio line of camcorders. (JVC has recently adopted the AVCHD format as well). MPEG-2 Transport Stream is reported to not offer as high image quality as AVCHD and is not necessarily compatible with a broad range of editing programs, though it needs to be said that none of the new consumer HD formats is particularly easy to work with because of their demand for the most powerful computers when decoding."​

Beelzebub... I mean H.264 is everywhere, it just got here so it ain't going away anytime soon, so just deal, Lucile.

CamVader -
I like your 1gb test idea and am thinking of a couple others where H.264 is converted to a whopping AVI file, edited, then saved for viewer delivery as several different formats including right back into H.264/MP4.

My guess is that... well, first let me premise that I could be wasting my time as I have little idea what I'm actually doing, my guess is that much of the delivery outcome won't matter.
It'll largely look fine or arguably the same rather than notably worse.

Input/Output experiments to come, but don't hold your breath. Maybe next week. Maybe.

ItDonnedOnMe -
EXCELLENT explanation of WTH is happening:
As others have said, h.264 is a lossy codec, and to keep file sizes manageable it throws away a lot of image information. It does a very good job of maintaining a good looking image while doing so - but the key is good 'looking'. It's designed to throw away information that is unlikely to be perceived by the human eye, while maintaining the appearance of the stuff that is likely to be noticed.

There's two problems with this when it comes to post. The first is that once you start pushing the image around, in color correction or a similar process, you potentially move image data from a range that is unnoticeable to the human eye up into that range. An example is where you try to pull up detail in the shadows and blocky compression artifacts appear instead of clean image data - that's because the codec knew those areas were below a visible threshold (when you shot them) and applied more aggressive compression to that area.​
Understood.
This is why I'm wondering if the compressed file can be uncompressed as a larger AVI format, monkey with... I mean edited, then re-compressed back into H.264/MP4 or other.

I don't know how to designate the 8 vs 10bit output for delivery, but I'll figure out something.
Maybe it's because I'm working with a 2 bit computer (that was a joke, BTW) which already has a short a$$ shelf life.
(The buzzards be gatherin' about this gimpy mule.)


Somehow, the collective "We" need to figure out a standardized path from H.264 to delivery that we can just throw at every nube (myself included) who scratches his/her head and asks "WTH happened?"
Seems there's too much "Let everyone invent the wheel! The industry supports the right of consumers to figure it out on their own!" going on.
 
Last edited:
Upvote 0 Downvote
I haven't had time to do the experiment yet, but will report back when I do.

Just to reiterate from way back in the thread, if it's important work for a film festival or direct to video or (((God forbid)))) transferred to film, it deserves all the best in handling and is best served by using an intermediate codec.

If it's a YouTube submission, well, YouTube is going to murder it anyway, so have at it. ;)

BTW, I have 24GB of RAM and I still use an intermediate codec. I ain't playing around. :lol:
 
Upvote 0 Downvote
CamVader said:
1 - I haven't had time to do the experiment yet, but will report back when I do.

2 - Just to reiterate from way back in the thread, if it's important work for a film festival or direct to video or (((God forbid)))) transferred to film, it deserves all the best in handling and is best served by using an intermediate codec.

3 - If it's a YouTube submission, well, YouTube is going to murder it anyway, so have at it. ;)

4 - BTW, I have 24GB of RAM and I still use an intermediate codec. I ain't playing around. :lol:
Click to expand...

1 - Understood. Same here.

2 - EXACTLY! It would suck so bad if fortune turned her fickle eye in any of our ways just to have her balk at cr@ppy delivery output because we didn't understand the limitations of the media or know a simple pathway.
Personal pet peeve is to do the same job twice. I'd hate to have to re-edit an entire feature due to something a simple four-step hassle previously could've averted.

3 - YT has limitations. Cool. Just let me know how to edit something to accommodate them.

4 - Gack! Indeed, you are not. And I thought 4MB was minimal and 8MB more than good 'nuff.


GL!

EDIT: IGNORE THIS! I'm just parking this here for future reference.
http://www.google.com/search?sclien...aq=5&aqi=g3g-c1g4g-m2&aql=f&oq=&pbx=1&cad=cbv
 
Last edited:
Upvote 0 Downvote
You must log in or register to reply here.
Back
Top