FORUMS: list search recent posts

Native H.264 workflow in Resolve

COW Forums : DaVinci Resolve

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
Paul Campbell
Native H.264 workflow in Resolve
on Nov 24, 2016 at 4:39:31 pm

Happy Thanksgiving! I was just reading an old article from 2010 about editing native H.264 clips (in FCPX and Premiere, not Resolve obviously). The author suggests "decompressing the H.264 footage into the higher quality ProRes 422 or 444 before editing", as it makes your workflow much easier.

My question is the "decompressing" of H.264 footage. Sure, you can transcode H.264 into just about anything, but are you really "decompressing" it?? If the DSLR is recording footage as H.264, aren't you squished into a corner already? Isn't this like trying to "decompress" an mp3 into a wav?

So, ultimately I'm wondering if Resolve would be happier with ProRes stuff that's been transcoded from H.264. The work I've been doing with H.264 in Resolve so far seems to be moving along nicely, so is ProRes really necessary? Is transcoding to ProRes going to make my product look better?

Thanks.


Return to posts index

Joseph Owens
Re: Native H.264 workflow in Resolve
on Nov 24, 2016 at 11:17:49 pm

[Paul Campbell] "Is transcoding to ProRes going to make my product look better?"

Not really. Unless you do some chroma-sampling tricks and macro-block smoothing. The whole notion behind recoding H.264 to a codec like ProRes is to make the CPU usage more efficient. H.264 is a Long-GOP format, which means that the system needs to make whole "intra" frames on-the-fly out of the i-b-p sequence. Intermediate density codecs like ProRes and DnX are natively "intra" which means every frame is a whole frame and not a bi-directional or predictive "difference" entity. The faster you skip around in a Resolve timeline, the harder the CPU has to work in order to keep the video smooth.

Eventually you start getting gaps and skips, black holes and decoding errors when the processing overloads the system's ability to keep up the bitrate and - above all - do the translation into integer-float so that the application can do its work.

jPo

"I always pass on free advice -- its never of any use to me" Oscar Wilde.


Return to posts index

Paul Campbell
Re: Native H.264 workflow in Resolve
on Nov 25, 2016 at 2:49:24 pm

Quite a lot to take in here! Thanks very much.


Return to posts index


Toby Tomkins
Re: Native H.264 workflow in Resolve
on Nov 25, 2016 at 12:11:30 am

The best conversion is 5D2RGB. It does some nice chroma filtering.


Return to posts index

Paul Campbell
Re: Native H.264 workflow in Resolve
on Nov 25, 2016 at 2:49:43 pm

Gracias, Toby!


Return to posts index

Hector berrebi
Re: Native H.264 workflow in Resolve
on Nov 29, 2016 at 4:44:58 pm

Adding to what Joseph said.. and in response to your question about the usage of the word 'decompressing'

Decompressing is what the h264 codec does. a video compression, or codec is a math function eliminating redundant data - compressing ( the co part of codec) and then when played back the codec's math decompresses that data frame by frame (the dec part of codec). This is in part why high compression codecs are so hardware intensive (lots of calculations)

so.. to answer your question, no. by transcoding to PR or DNX you're rather re-compressing than decompressing.

However, since you are taking a highly compressed Long GOP chain of "bi-directional or predictive 'difference' entities" and turning them into actual "whole frames", one could see this as a sort of figurative decompression.. even more so if you transcode the long GOP h264 to some uncompressed format. figurative, not literal ☺

and there are fairly many h264 variants that are not long GOP but I-frame where re-compressing would maybe serve a different purpose that 'filling in' whole frames

recorded video quality would stay the same in any case...

It became so simple and abundant these days to shoot using a good video compression, that the real issue in my opinion, is why shooters and directors of small/medium projects keep using bad codecs, and how little they know about these things and the (lost forever) data sacrifice they take from their oh-so-important footage.

hector


Return to posts index


Paul Campbell
Re: Native H.264 workflow in Resolve
on Nov 29, 2016 at 7:51:25 pm

Hector, I've read so many articles about codecs, and am embarrassed to admit that the subject is still so sketchy to me. When you say "shooters and directors of small/medium projects keep using bad codecs", I don't think I understand what my options would be. I shoot video with a Canon T5i, which I know compresses the footage onto the SD card using the H264 codec. When it comes time to edit, I simply dump the card's footage straight to my Resolve timeline and start cutting away. Are you suggesting that I'd be better off with a different workflow? Or perhaps what I'm doing is about as good as it's going to get?

Thanks for bearing with me guys, I'm trying to keep up with you.


Return to posts index

Hector berrebi
Re: Native H.264 workflow in Resolve
on Nov 30, 2016 at 10:53:32 am

Hi Paul

The full answer would be too long for me to write here..

even the short answer is kind of long..
you'll excuse me for terribly simplifying and omitting details. ☺

yes, its probably the best you'd ever get out of that camera and its codec.
However, I did see all types of flat, Log-ish settings used on Canon cameras (https://vimeo.com/7256322 video that sort of started that wave) that increased dynamic range and detail levels when well exposed. that in turn would give you more to work with later when grading and will improve visual quality.
Others use firmware hacks like Magic Lantern, forcing the camera to write RAW image sequences far grater in quality than what it was engineered for. Not sure it works on your model, but even if it does, I wouldn't trust this workflow on any payed production or shots longer than a minute or so. I also do believe it kills your camera faster by pushing its limited hardware beyond its abilities..

My point was about the choice to shoot on a specific format.

video formats can be roughly divided into 3 groups the 4:4:4 the 4:2:2 and the 4:2:0 (based on something called Chroma Sub Sampling)
*of course there are other factors like color depth (8,10,12 bits), type of compression, and RAW-ability but these are roughly parallel to the Chroma Sub Sampling groups in a way that a 4:2:0 camera will usually be also 8 bit, more compressed and no RAW recording, while a 4:4:4 capable camera will generally be 10-12 bits, with better compression and in many cases a RAW option.

traditionally they are used by different industries, for many different purposes
4:2:0 dominates consumer/procumer cameras and even sips in to some pro models. it is also how all web video from smartphones to youtube and everything in between is (and quite a few other delivery formats)
4:2:2 is the TV and Broadcast choice as well as many post workflows related to that industry (PR and DNX for example)
4:4:4 is the highest group meant for high-end workflows, digital cinema, acquisition of commercials, series and such.

the past 5-7 years mixed everything up a little and made it much easier to use cameras capable of 4:4:4 acquisition.
From external recorders to the Black Magic cameras or the abundance of RED/ALEXA cameras for (cheap-ish) rent, it would seem completely normal for me that productions, even small/medium ones would choose this option, ensuring maximum data quality at acquisition, and allowing better, more robust post workflows (including color work).
Yet, 4:2:0 cameras with their inferior codecs and limited color depths seem to thrive, and so does their usage by many talented shooters and directors who are very often unaware of video chemistry and its tolls.

Just 10 years ago, it was so expensive and difficult to work in a full 10 bit 4:4:4 workflow that only big capable productions could afford it. today it seems no production is too small (excluding family type private events) to at least consider it.

And since as color people, we meet these productions at the end of the pipeline... We're also the ones hearing them whine about the final result's look in comparison to expectations or to the last GoT episode they saw 😉

hector


Return to posts index

Paul Campbell
Re: Native H.264 workflow in Resolve
on Nov 30, 2016 at 1:27:51 pm

Ok, that might've been the best short-long, terribly simple and detail-omitting reply ever 😂

Clearly, I'm a 4:2:0 guy with aspirations to continue growing in a field that has me so obsessed lately. This has been a very productive thread for me, and I really thank all of you guys for planting just enough seeds to keep pushing me forward. Now it's time to wiki and then hit you up again later. Stay cool,

Paul


Return to posts index


Marc Wielage
Re: Native H.264 workflow in Resolve
on Dec 3, 2016 at 5:17:05 am

I think the best answer is not to shoot on little cameras like DSLRs for long projects. I don't have a problem with people who have limited resources and want to do an internet short or a student project on a camera like this, but for entire features, you really need to go to a camera that can handle 444 10-bit. Whether HD or 4K or beyond is another issue. But the devices shooting H.264 8-bit give you far more limited options in post.

I've started to call 8-bit "Hate-Bit" lately, because it creates a lot of problems in color. And there's a ton of that material that people routinely use for stock footage.


Return to posts index

Paul Campbell
Re: Native H.264 workflow in Resolve
on Dec 3, 2016 at 3:05:13 pm

Got it, thanks Marc. Fortunately for me, my projects certainly fall within the scope of "internet short" and "student project".


Return to posts index

Marc Wielage
Re: Native H.264 workflow in Resolve
on Dec 4, 2016 at 2:27:35 am

Not a problem, Paul -- and I get that there are budget-challenged projects and small shorts with which people are just learning and having fun. Those are fine for DSLRs. I would recommend you avoid clipping the highlights, shoot color charts if possible, and consider transcoding to ProRes (on Mac) or DNxHD (on Windows) for post. You should also shoot camera tests and know the limitations of 8-bit color up front.

I've been dealing with that for the past couple of weeks on a project that's pretty well-shot, but the stock footage is mostly 8-bit H.264. I'm a little stunned to find that some of this material is 3840x2160!


Return to posts index


Paul Campbell
Re: Native H.264 workflow in Resolve
on Dec 4, 2016 at 1:33:56 pm

Curious what camera was used to shoot 4k with H.264, but from what I've learned here there are a ton of things out in the world that acquire with H.264, and not just DSLR's.

Buy hey, since you brought it up, would you mind describing briefly your workflow with this project you mention? Are you transcoding the H264 stock stuff to PR so that it will play nicely in your timeline without giving your processor a migraine? How was the other footage compressed that isn't H264? (Or maybe it was shot with a serious rig, and there was no compression to begin with??)

This is what I love about the Cow. Just when you think you're done, something new pops up and pulls you right back in. I feel like Michael Corleone from Godfather III 😂 Thanks again, Marc.


Return to posts index

Hector berrebi
Re: Native H.264 workflow in Resolve
on Dec 5, 2016 at 8:19:13 am

H264 at its highest variants can support 4:4:4 and 12 bits (and even 14 bits though I don't know of any application/device using it), on the other hand, many cameras (DSLR included) shoot 4K, 8 bit 4:2:0 video, from iPhones to much more expensive cameras.

and considering HD h264 in long GOP is processor demanding... you can imagine how "fun" it is to work with 4K material of the same kind. So transcoding to some 4:4:4 I-frame codec not only ensures no color data is lost (4:4:4) but also goes a bit easier on your system.


again... it will not make anything look better. that extra data is forever lost by some cheap chip-set/camera brain's internal process.


Return to posts index

Paul Campbell
Re: Native H.264 workflow in Resolve
on Dec 5, 2016 at 2:18:40 pm

I've not worked with 4k material so far, but I imagine the file size of a transcoded h264-to-PR422 must be ginormous. But hey, drive space is cheap nowadays.

So, for now the workflow will probably be h264 footage -> MPEG Streamclip/transcode to pr422 -> import/cut in Resolve -> export to Compressor -> crunch to mp4 (most of the time for me, anyway).

I suddenly find my focus shifting to cameras that can stream directly from their hdmi ports to one of those Ninjas to avoid acquisition compression. I know the t5i can do this, but the hdmi output isn't true 1080p, so it would be a waste of $. But this is a discussion for another forum 😁 Thanks again. I'm glad I started this thread, it's been enlightening!


Return to posts index


Ole Kristiansen
Re: Native H.264 workflow in Resolve
on Dec 5, 2016 at 3:32:09 pm

"So, for now the workflow will probably be h264 footage -> MPEG Streamclip/transcode to pr422 -> import/cut in Resolve -> export to Compressor -> crunch to mp4 (most of the time for me, anyway)."

First, try to import your H.264 to Davinci Resolve and use Generate Optimized Media and see how it goes with the editing
and then switch to the original footage before starting to color grade !

Or do like this and then switch to the original footage before starting to color grade !







Return to posts index

Paul Campbell
Re: Native H.264 workflow in Resolve
on Dec 5, 2016 at 4:04:35 pm

So is the point of this to do the edits with file copies that behave better in the timeline, like proxies? You edit the proxies, these edits get carried over to the original files, and then I go in to grade?


Return to posts index

Ole Kristiansen
Re: Native H.264 workflow in Resolve
on Dec 5, 2016 at 4:19:37 pm

Yes !

It is easy to switch between Optimized Media and original footage in Davinci Resolve ! Just uncheck: Use Optimized Media if Available !



Return to posts index


Paul Campbell
Re: Native H.264 workflow in Resolve
on Dec 5, 2016 at 4:43:51 pm

Very slick, thanks for pointing me in that direction!!


Return to posts index

Marc Wielage
Re: Native H.264 workflow in Resolve
on Dec 5, 2016 at 11:09:50 pm

If the transcodes lose no quality of the original, you can use those for final color. That's a big "if."

Bear in mind I'm not a fan of 8-bit color, and I think that puts a huge limitation on how hard you can push the image in Resolve (or any other color correction program). Not enough bits.


Return to posts index

Paul Campbell
Re: Native H.264 workflow in Resolve
on Dec 6, 2016 at 12:37:27 am

I've used this analogy before, but transcoding H.264 to PR would be the video equivalent of converting an mp3 back to wav, yes? You can't get the original uncompressed information back, all you're doing is creating a larger file size, but it's a necessary step if you want to color grade since you'll at least be grading in 10-bit space, yes? This of course is with the big "if" you mention. I guess all I can do is transcode and compare, and hope the transcode preserves the original. I'll have to shoot some tests and do an A/B.


Return to posts index

Marc Wielage
Re: Native H.264 workflow in Resolve
on Dec 7, 2016 at 7:58:32 am

[Paul Campbell] "I've used this analogy before, but transcoding H.264 to PR would be the video equivalent of converting an mp3 back to wav, yes? You can't get the original uncompressed information back, all you're doing is creating a larger file size, but it's a necessary step if you want to color grade since you'll at least be grading in 10-bit space, yes?"
No. It's like pouring 8 gallons of water in a 10-gallon bucket: there's no extra water there. But it is less stress on the computer and it will play more easily, since the CPU doesn't have to work as hard in decoding the H.264 compression. You don't get any more bits that way, even if you pad it out to 10-bit. It'll still "step" in gradiated-edge or clipped situations.


Return to posts index

Ole Kristiansen
Re: Native H.264 workflow in Resolve
on Dec 7, 2016 at 9:16:12 am

Why you should use Avid DNxHD and Apple ProRes

PAGE OF 3

http://www.redsharknews.com/post/item/88-why-you-should-use-dnxhd-and-prore...


Return to posts index

Paul Campbell
Re: Native H.264 workflow in Resolve
on Dec 7, 2016 at 1:34:54 pm

Thanks for the link, Ole.

Of course, now I have more questions about using Optimized Media in Resolve, but I'll save that for a new thread since it's off-topic from this one.

Stay cool, herd.


Return to posts index

Ole Kristiansen
Re: Native H.264 workflow in Resolve
on Dec 7, 2016 at 1:40:35 pm

Faster Resolve Editing Using Optimized Media







Return to posts index

Paul Campbell
Re: Native H.264 workflow in Resolve
on Dec 7, 2016 at 1:30:34 pm

Hey, that's a fine analogy right there, so fine in fact that I'm using it from now on. Ok, I get it. (This time I actually think I do ☺ ) Thanks again.


Return to posts index

Marc Wielage
Re: Native H.264 workflow in Resolve
on Dec 8, 2016 at 2:20:28 pm

[Paul Campbell] "Buy hey, since you brought it up, would you mind describing briefly your workflow with this project you mention? Are you transcoding the H264 stock stuff to PR so that it will play nicely in your timeline without giving your processor a migraine? How was the other footage compressed that isn't H264? (Or maybe it was shot with a serious rig, and there was no compression to begin with??)"
I have no idea what camera was used to shoot the material. It could have been a reasonable camera, and for whatever reason the stock footage company opted to sell their material only as 8-bit H.264 2K and 4K. I'm taking it all and transcoding to the exact same resolution in ProRes 422HQ (for 8-bit) or ProRes 444 (for the 10-bit material). I've gotten a few oddball QuickTime Photo ad QuickTime PNG files over the years, even some QuickTime Animation (which is a gnarly format), and always converted them to 444.

Given enough horsepower and storage, I'd gladly use DPX for everything. I think ProRes 444 is a good compromise for my clients and certainly doesn't compromise the material at all. It makes the workflow simpler and is one less thing to have to worry about. I have a whole set of instructions for the editor when it comes to turning over the material for color, but the problem nowadays is a) everybody's in a hurry, b) a lot of people don't read, and c) I basically get told, "well, this is the way we did it the last time" and I just deal with it as best I can.

There are some other H.264 issues, like video range vs. data range clips, and you have to stay on top of that as well.


Return to posts index

Paul Campbell
Re: Native H.264 workflow in Resolve
on Dec 8, 2016 at 5:53:05 pm

Marc, thanks for all of this, and everyone else, too. I could keep asking you guys questions all day, but I fear it'll get off-topic and I don't wish to annoy the Admins. (This thread really picked up some steam, for me anyway!) My original question has been more than sufficiently answered, and it's been quite an education.

Happy Holidays to all of you, and I'll see you out in the ether.


Return to posts index

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
© 2017 CreativeCOW.net All Rights Reserved
[TOP]