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.
I know this is the Pro Editor sub, but I have been answering a lot of questions here lately that this video answered quite well and is at least a great starting point for anyone struggling with performance, quality, or just not confident in their knowledge of video editing codecs.
Many professionals are self taught or have supplemented their knowledge by just doing the work and getting better, and thats great. But it often means there are gaps and the most common gap I see is knowing what codec to use, when, and why.
I hope this can help some people out. Most videos I come across like this are trash but this one started playing this morning and I found it to be a nice "quick" resource on the topic.
Never heard of this guy, he had some informative stuff. That was a really great, accessible video about the world of codecs without going too far down the rabbit hole.
Was skeptical but holy calzone does this video have a lot of info.
Pretty solid. I think AVGuru did a 5Things on this at one point correct?
Def something every should be aware of. One thing Iād love and is more overlooked is videos about audio.
Ty