Today's video is on another highly requested topic,
but I'm warning you right now
that it's probably gonna be a mess.
We're gonna be tackling video codecs, and I'm gonna do
everything I can to present as much useful information
as possible in a logical order, but no promises.
Let's get Undone.
[offbeat music]
♪ Gerald Undone ♪
♪ He's crazy ♪
What is happenin', everybody,
I'm Gerald Undone and today
we're talking about video codecs.
Now, today's topic is huge and there is zero chance
that I'm gonna be able to cover it all,
so I do apologize ahead of time if I skip something that
you would've liked more information on,
but I'm gonna try and cherry-pick the information
that I think will be useful to the average video shooter.
So, with that, there's some terms we need to cover
so that we can effectively discuss the various video files
that you'll encounter, and they are:
the intents of a codec, their naming conventions,
and the containers they're stored in.
And as always, we'll also be discussing
the practical applications of this topic,
including the usefulness of an external recorder.
So, when I say the intent of a codec,
we're talking about its purpose.
but let's just cover a quick definition
of what a codec actually is.
So, codec is a portmanteau of coder, decoder,
because it's responsible for encoding and decoding
a digital data stream, and codecs often go beyond
encoding and decoding and also incorporate compression,
which is a big part
of what we're gonna be talking about in this video.
When we ask what the purpose or intent of a codec is,
we mean, is it being used for acquisition,
delivery, or an intermediary.
An acquisition codec is the one your camera uses to record
the images that it sees as a file on your memory card.
A delivery codec is the one you export from your editor
when you're all finished with your project
to deliver to the client,
or distribute to the web, or present for broadcast.
This can be the same as your acquisition codec or it can be
different if the situation requires.
Lastly, an intermediary codec is the one that you use
between your acquisition and delivery codecs,
and it's usually chosen because it's more suitable
for editing and post-production.
You don't need to memorize all that because we'll be coming
back to it, but you need to have a general idea of
how they relate to one another. Finally, what are containers?
Containers are like the box that the video and audio files,
and potentially the metadata, are kept.
An example would be an MP4 or an MOV.
Now, these by themselves don't really tell you much
and they're not fully indicative
of the quality or codec used.
But you can draw some conclusions
based on the container, because there are some
combinations that you just won't see.
Okay, so with all that in mind,
let's discuss some commonly encountered combinations
that you're probably already familiar with
so that we can build our knowledge off of it.
And I think it makes sense to start with probably
the most ubiquitous one, the H.264 codec.
To start with a little history on the codec and its naming,
its full name is the H.264 MPEG-4
Part 10 Advanced Video Coding,
which is usually abbreviated to H.264 or MPEG-4 AVC.
The reason why it has two names is because it was developed
in partnership between two entities
that had pre-existing naming conventions.
One was using the H.26x convention and was just
changing the last digit, and the other was using
the MPEG-4 Part # convention,
and was increasing the part number.
The important thing to know here, though,
is that they are the same, which helps explain
why when you record on Sony, you see AVC,
but when you record on Panasonic, you see H.264.
Now, Sony actually took this a little bit further
in 2012 with their XAVC format,
which is of course built on MPEG-4 AVC, but uses
one of the highest levels supported by that standard,
and is generally stored in an MXF container.
Sony later streamlined that format for consumer products
in 2013 with the XAVC-S, which is normally stored
in an MP4 container, and it's the one that you'll find
on the a7 series of cameras, including the a7 III.
Outside of the Sony ecosystem you'll find that the term H.264
is used more commonly in consumer cameras,
but we're effectively talking about
the same family of codecs.
And so, that should hopefully help answer a question
I get asked all the time, which is what's the difference
between H.264 and Sony's XAVC, and the answer is,
there isn't really much of a difference.
Sony basically just specifically tuned
H.264 for their needs.
Now, in that last section I said a couple words
that need some elaboration.
I mentioned levels and the MXF container.
Containers, as we already talked about,
are just the storage boxes for the video,
and MXF is not different.
It's just not found as commonly in consumer devices.
MXF stands for Material Exchange Format,
and it's a container that was intended to probably be
a lot more popular than it is based on its versatility,
but we'll be talking about it again when we get into DNx.
But the most common containers for H.264
are the MOV and the MP4.
The other term that I mentioned a moment ago,
levels, refers to the specs of a given profile
being used by that codec.
These levels, which you'll usually find
in your editing software as options like 4.1, 5, 5.1,
detail the supported resolutions, the bit rate,
and the decoding speeds of the codec.
So, for example, to get 4K 60p, you'll need level 5.2,
because level 5.1 only supports up to 4K at 30fps.
You can easily look up a chart if you want to see
the breakdown of the different levels,
but I'll put some links in the description for the tables
that we discuss throughout this video.
Now, levels are different, but work in conjunction
with the profile, which is basically the overall
capabilities of the codec and is set with terms like
Main, High, and High10.
Profiles detail the broader capabilities of the codec
with things like bit depth and chroma subsampling.
And by bit depth we mean the 8-bit or 10-bit,
and for chroma subsampling we mean 4:2:2 and 4:2:0.
Now, I don't want to go into too much detail
about those aspects, because that's definitely
a topic for another video, but in broad strokes,
bit depth is basically how many colours you have per channel.
The more bits, the more colours.
And chroma subsampling is a method of reducing bandwidth
by focusing more on luminance than on colour.
And the ratios, like 4 to 2 to 0 are detailing how much
information was lost or combined during that process.
Again, with this one, the higher the number
the better, with 4:4:4 being the best.
Now, the interesting thing about H.264 is how it's used.
In the beginning, I said that there were generally
three intentions of a codec: acquisition, intermediary,
and delivery, but if you look at an average consumer's
workflow for distribution on the internet, H.264,
often in an MP4 container, is used for all three.
For example, I'm recording this on my GH5.
Now, internally the GH5 could record this video,
which is 4K, at 24fps, in an MP4 container,
using the H.264 codec, and it can do that at 10-bit--
that's the colour bit depth--
and at 4:2:2 chroma subsampling.
Now, I could take that file and upload it straight to YouTube,
and that would cover both the acquisition
and the delivery in an H.264 MP4.
And then YouTube would probably distribute
it to your screens using H.264 as well.
And if I wanted to edit that video before uploading,
I would import those files into my editor,
which is Premiere Pro, and keep it as an H.264 MP4.
So, that would make it my post-production codec as well.
Now, this doesn't exactly qualify as an intermediary,
because the codec isn't changing, but you get the idea.
So, it's pretty great that a codec can be so flexible
and universal, but there are some serious drawbacks.
First of all, that file I described,
the 4K 10-bit 4:2:2 and an H.264 MP4,
can be quite taxing on your computer to edit.
So, it doesn't make for the best post-production codec.
And as an acquisition codec,
it suffers from being in its lowest form from the get-go,
with considerable data loss and compression.
It is pretty great for web distribution,
video streams, and rips intended for portability.
But there are better performers in that area as well,
they just aren't as well adopted yet.
One of the most popular potential successors
for this purpose would be the High Efficiency Video Codec,
HEVC, appropriately known as H.265.
It's better for this kind of distribution
because it can double the compression of H.264
but keep the same level of quality.
So, it gets smaller, but you don't lose anything.
And you're starting to see HEVC show up as an acquisition codec
in cameras these days, too, with the latest GoPros offering
H.265 to handle their higher resolutions.
Now, let's go back to the shortcomings of H.264
and build off of it by exploring some potential solutions.
So, we talked about how H.264 isn't the greatest for editing.
And the first solution to this is actually included
in many cameras, and it's called All-I recording.
Now, this is another dense topic
that I don't want to cover completely here,
so I'm just gonna speak generally about it.
But the typical compression for H.264 uses something
called IPB, or LongGOP.
GOP stands for Group of Pictures and refers
to a sequence of frames which contain I, P,
and B frames, hence IPB compression.
Think of I-frames or intra frames as a complete picture,
but in order to save space, the codec also uses predictive
frames, P-frames, and bi-predictive frames,
B-frames, to only render out the portions of the image
that have changed throughout the sequence,
rather than redrawing the whole image each time.
This makes editing harder, because in order to pull up
a frame of your video, the computer has to read
and decode the frames before and after it
in order to compile a full sense of that picture.
And if you cut the footage, the IPB sequence needs to be
recalculated in order for it
to maintain its integrity at the cut.
And this can really bog down your edit.
All-I or All-Intra attempts to solve this by only using
the intra frame compression of I-frames
and not bridging the gap with predictive frames.
This means when you pull up a frame in your editor,
you only need to pull up that one frame
and not the surrounding ones, and when you place a cut,
no extra work needs to be done,
and this can make for a significantly
smoother editing performance.
Now, All-I is just a compression technique,
so it doesn't really help that much
when it comes to acquisition quality.
It's not gonna change your bit depth or modify
your subsampling, but it is more suitable
for post-production and gets you closer
to the performance of a dedicated intermediary codec.
However, there are some serious limitations to All-Intra,
and they mostly have to do with storage space.
Eliminating those P and B-frames means that
the bit rate and file sizes go up significantly
because there's much more data being recorded.
And because All-I is a solution built into cameras,
it generally works off of the same card slots
that you would use for IPB compression or photos.
This means you'll likely have to purchase faster cards
to handle the higher bit rate, and larger capacity cards
to grant you the same recording time.
And when it comes to SD cards, really fast cards
with high capacities are not priced very affordably
on $1 per gigabyte scale.
But we'll talk more about that in a minute.
The other issue that some people encounter with All-I
is the read speed limitations of their hardware.
A question I've been asked before is,
"Why is All-I performing slower on my machine than LongGOP?
I thought All-I was supposed to edit smoother."
And in this case,
often what it comes down to is hard drive speed.
Older mechanical drives, especially those found
in laptops, often can't feed the data fast enough
to the editor for the All-I files
like it could for the smaller IPB files.
So, in those cases, a faster solid-state drive
is definitely required.
Now, I want to talk more about the intermediary
intent of a codec.
I mentioned that All-I can serve as a decent
post-production codec, but there are others
that do this much better, like ProRes and Avid DNx.
When it comes to Avid, there's different codec groups.
There's DNxHD, which stands for Digital Nonlinear
Extensible High Definition, and is typically used
for resolutions up to 1080p.
And then there's DNxHR,
Digital Nonlinear Extensible High Resolution,
which is for resolutions above 1080p.
These codecs are typically stored in the MXF container
we were talking about earlier,
but can also be stored in an MOV.
When it comes to the HR variant,
there are five distinct profiles,
and these are kind of like the profiles we talked about
with H.264, but they have the level component
built in with pre-defined data rates.
And the same is true for ProRes, which has
six different versions, including a proxy variant.
Now, there's quite a few commonalities
between DNxHR and ProRes.
For example, they both use a minimum
chroma subsampling of 4:2:2.
They both use a intra frame compression method,
so they're All-I.
They're both optimized for editing,
and they both offer a range of different bit depths.
When it comes down to choosing between the two,
it's more important to look at compatibility
than it is their specs.
ProRes is an Apple codec, and thus is well-tuned
for use on a Mac, especially with Final Cut.
Now, ProRes will also work with other NLEs,
but most PC users report better performance when using DNxHR.
Now, another thing that these codecs
are commonly used for is making proxies.
Proxies are just what they sound like.
They're basically video files that stand in place
of the original file to make it easier to edit.
If you're working with source footage that's just too
demanding to edit, you can make a proxy of that footage
using a lower quality or bandwidth,
and using a more edit-friendly codec like ProRes or DNx.
Then when your project is complete, you export the video,
but it applies your edits to the original footage
and exports it from it rather than from the proxies,
so you retain full quality.
This makes sense as something that you would do
with massive raw files or uncompressed video
that's just too difficult to work with.
But a lot of people actually do this with their H.264 MP4s,
and use an intermediary codec like ProRes or DNx.
The idea is that it's much easier to edit a 1080p
or 720p ProRes video than it is a 4K H.264.
It's important to remember,
however, that this does not improve quality.
Because remember what we said earlier,
that one of the disadvantages of H.264 is that
you're starting off already compressed at sort of like
that lowest common denominator.
So, even though ProRes can have better subsampling or,
you know, more colours, you're not gonna get those just
from converting your footage from H.264 to ProRes or DNx.
You're still gonna be locked in
at whatever you recorded at with H.264.
Now, if you've been following up to this point,
you might've concluded, then, that the best of both worlds
would be to do your acquisition with a quality
post-production codec like DNx or ProRes.
That's what camera companies have concluded as well.
These codecs may have started as intermediary formats,
but they're becoming much more
commonly offered as acquisition codecs.
There are, however, some considerations to be made.
ProRes and DNx take a lot more space
and require much faster storage.
Faster and larger than most consumer cards
can deal with at a reasonable price.
To demonstrate this and give some more details
about ProRes and DNxHR, let's do a small comparative
case study with the Panasonic GH5.
As I was saying earlier, this video is recorded in Ultra HD,
which is 3840x2160 resolution,
at 24fps, in 10-bit 4:2:2.
If I use the standard LongGOP compression
which is offered by the GH5 for H.264,
it's gonna need 150Mbps,
which is 18.75MB/s, because 8 bits in a byte.
So, you divide 150 by 8 and you get 18.75MB/s,
which means it's gonna take about 64GB
to record about an hour of video.
And this is manageable because any V30 SD card
will be able to handle that, by the way,
if you wanna know more about designations
and speeds and stuff like that of SD cards,
make sure you check out my video on that.
But basically, V30 means it can do 30MB/s with video.
And that's higher than 18.75, so we're okay.
If I change the compression from LongGOP to All-Intra,
the bit rate increases from 150Mbps
up to 400Mbps, which is 50MB/s.
And this now exceeds a V30 card, and you start
to enter into the V60 and V90 card territory,
and into UHS-II cards,
which can cost up to five times as much.
Also the capacity of those cards will need to increase,
because it now takes 180GB to get an hour
of recording time, up from 64.
Now let's look at a comparable ProRes version.
ProRes 4:2:2 HQ would probably be the highest
quality available, if our GH5 could record ProRes internally.
It would take full advantage of the 10-bit colour
and the oversampled image and give us
the most latitude for grading and effects.
But ProRes 4:2:2 HQ,
when recording an Ultra HD image at 24fps like we are now,
requires 707Mbps.
That's 88.4MB/s
and nearing the upper limit for SD card recording.
And even if it could, it's 320GB for every hour
of footage, and that's just impractical.
The same goes for DNxHR, which has a version called HQX,
which is closely comparable to ProRes 4:2:2 HQ,
and this allows up to 12-bit 4:2:2 at 4K or Ultra HD.
Again, I'll provide links if you want to see
the complete tables for ProRes and DNx
and compare data rates of the different versions.
That'll be in the description below.
DNxHR HQX comes in very close
to the bit rate of ProRes 4:2:2 HQ
for our current setup at 83.26MB/s.
Which again is gonna be near the upper limit
of SD cards and 300GB for every hour of filming.
Now, cinema cameras are more capable of this type
of intermediary codec recording right out of the box,
but it's pretty rare in consumer-level cameras.
Blackmagic's Pocket Cinema 4K is probably the most
affordable camera I've ever seen offer this.
It offers raw as well as four ProRes versions,
and you can record this directly onto
a solid-state drive via a USB, so you don't have
to inflate your budget with overpriced memory cards.
But for consumer-level cameras and even the pro-level hybrids,
you're gonna need an external recorder to do this.
If your camera supports a clean HDMI out, my recommendation
would be the recently released Atomos Ninja V,
which can record 4K 10-bit 4:2:2
up to 60fps in both ProRes and DNxHR.
And it also provides an excellent screen,
which is doubly handy for those cameras
that don't have a vari-angle display.
And in the case of the GH5, it can take a clean,
uncompressed signal over the HDMI, and then capture it
using the edit-friendly codec of your choosing.
And the only cons I can really think of
are storage space, reduced portability, and price.
So, for the reduced portability thing,
there's no way around it, you're gonna get bigger
and heavier if you add a monitor/recorder.
The Ninja V I was particularly excited about because
it's insanely compact for its capabilities,
and the five-inch screen is much more my speed.
But, like I said, it's definitely bigger
and heavier than if you had no recorder at all.
The storage concern is unimportant, though,
and I'll explain why in the price section.
So, the Ninja V costs around $700USD or $900CAD,
and that's a decent chunk of change.
There's definitely cheaper recorders out there,
and there are also much more expensive ones.
I do think the Ninja V is a pretty good value package
and is priced really well, but it does cost quite a bit.
However, when I got my GH5, I went all out
on the SD cards because I wanted to be ready
for the All-Intra firmware update
that was coming out a few months later.
I started with a pair of 64GB SanDisk UHS-II cards
that were close to $200CAD each.
That worked out to $450 with tax for 128GB.
That's $3.50 per GB.
Now, prices have come down a little bit since then,
but if I compare that to this SSD that I got on sale
just last week, which is the Samsung 860 EVO 1TB,
it was $250 with tax, so that's $0.25 per GB.
That's 14 times cheaper than my SD cards were.
And that's a hell of a lot more useful than SD cards
for other applications because I can use it
as an external drive or put it in a PC build down the road.
My point is that while external recorders definitely
cost some money, they significantly
reduce your storage costs in the long run.
Probably not enough to pay for themselves, but definitely
enough to net a couple hundred dollars of recoupment.
So, if we combine everything we covered in this video,
I think that we can draw some conclusions.
If we go back to the beginning when we talked about
the intent of the codec and we talked about
acquisition, intermediary, and delivery,
I think the best acquisition ideally would be raw.
And then you would want to use a quality intermediary
for editing, and then you would want to archive
and potentially deliver in a perfectly suited,
quality DNxHR or ProRes version that'd suit that function.
And then if you want to distribute to web,
you would then do another export and convert to H.264,
uh, and use that for web delivery,
which will probably soon enough be replaced by H.265.
However, if you're shooting on a GH5, or a Sony a7 III,
or a Fuji X-T3, or any number of quality hybrid cameras,
that ideal scenario just isn't an option.
So, what can you do? If it's just for web delivery,
you can run through the entire process using just H.264.
And if the edit is bogging you down,
you can create some proxies using ProRes or DNx
in your editor for smoother performance.
In fact, some of the cameras, like the Sony,
actually allow for simultaneous proxy recording
right on the card, so when you import the footage,
the proxy is already created and ready to go.
Alternatively, if you have access to large
fast cards and your camera supports it,
you can use All-I recording for smoother editing as well.
But before you invest too heavy on expensive SD cards,
consider getting an external recorder
like the Atomos Ninja V if your camera supports it.
Because solid-state drives are faster, cheaper,
and more useful than SD cards, and it's a much cleaner
and higher quality process to use ProRes or DNxHR
as the acquisition codec instead of H.264.
But now I want to hear from you.
Let me know in the comments what your current
codec workflow is and how it's working for you.
And as a bonus question, I'd love to know
what your ideal workflow would be if you could use
any combination of hardware and software.
Older mechanical drives, especially those found
in Lobsta-- Lob-- Lobsters?
You also get a much dit bepth-- dit-- dit bepth?
Bit depth. Dit bepth. That's a funny one.
I'm not gonna be able to say it right now.
But that's gonna be it for me.
I hope you found this video helpful or at least
entertaining, and if you did, make sure you leave it
the old thumbs-up and consider
subscribing if you haven't already.
But if you did not find this video helpful or entertaining,
feel free to hit the dislike button twice.
Alright... I'm done.