Creating Good Workprints: export encoder settings

[soundslikejoe]

I've received many different video workprints from different editors..... occasionally I've encountered videos that perform terribly in my audio workstation. Upgrading my video card didn't fix the problem..... and after lots of asking and reading.... I learned those editors were using encoding presets with settings that were killing performance. In one case the editor said "I just use this YouTube setting".... those might be the worst!

http://soundslikejoe.com/video-codecs-for-audio/

The link is to a tutorial about encoding video for audio post or scoring. The important thing.... The video has to scrub well. I've tested these settings and the performance of the video is much better.

I plan to create presets for Premiere, FCP, FCPX, and AVID.... also Compressor and Adobe Media Encoder, and I'll host those in the blog. If anyone else has time to create a preset, please send it to me.

 

[trueindie]

In Premiere, I just choose QuickTime, and then under video codec at the bottom I choose Avid DNxHD, and that works fine in pro tools at least. Most other codecs look like crap in Pro Tools, at least for me.

 

[soundslikejoe]

Yep.... that tut explains why DNxHD works best. It's an editor's codec and doesn't use predictive encoding.... and compresses every frame. It's probably a freak'n huge file too.

h.264 can work... it just needs to use those settings mentioned in the article.

 

[Sweetie]

Out of interest, as someone who is very much unknowledgeable in PT, is it because Pro Tools is so processor intensive that your struggle with the h.264 files?

Is there any preferred resolution/bit rate that is preferred?

 

[soundslikejoe]

This isn't just a Pro Tools thing.... It's every DAW. Contrary to some opinions, audio can be just as demanding on computer systems as video. Especially when composing music. When intensive audio processes are happening, the last thing you want to waste system resources on is decoding a highly compressed video.

h.264 was designed and optimized for streaming and delivery. It was never intended to be used as a master print or work print. Add to that... What causes the problem isn't h.264 but is the lack of understanding of codec settings. People tend to select presets and export without understanding the technology behind the video. So... the problem isn't that "Pro Tools is so processor intensive" but that h.264 encoding presets can compress the video in ways that prevent it from performing well as a workprint.... scrubbing, stopping, shuttling backward and forward rapidly, start/stop, etc.

Higher bit rates are a given... resolution doesn't need to be 1080p. As the article states... 720 will save some resources. Most importantly.... B-frames and P-frames kill the video's performance and every frame needs to be a keyframe!

 

[AudioPostExpert]

Out of interest, as someone who is very much unknowledgeable in PT, is it because Pro Tools is so processor intensive that your struggle with the h.264 files?

As soundslikejoe stated, H264 is specifically designed as an online distribution format. In effect, H264 trades file size for processing power by creating a small encoded file, which requires considerable processing power to decode. Digital Intermediate (DI) formats are designed specifically to require minimal processing power, freeing up processing for audio processing in DAWs and video processing in NLEs, etc., but at the expense of file size.

Is there any preferred resolution/bit rate that is preferred?

No! It all depends on the individual composer and audio post person/facility. In other words, it's a discussion you (or your pic editor) will need to have with your composer and audio post team for each project.

My usual workflow dictates that I'll request the delivery of a H264 MOV file, with the standard keyframe interval of every 80 frames, using the same resolution and frame rate of the required distribution format and a bit rate around 30-60mb/s. Almost all of this is quite different from what soundslikejoe requires! BTW, my first task upon receiving the MOV file is to transcode it to ProRes 422 (or DNxHD)!

G

 

[Sweetie]

Thanks for the responses.

The reason I was asking about the processor load of PT (and obviously DAW) is it's hard to work out the effect it will have on a given system without knowing if it's already under strain. If it's under very little strain, the codec should perform reasonably on most systems unless when the encode has a keyframe interval that is too big. I personally do understand long-GOP process. I'd expect the whole issue to be a lot worse when h.265 becomes more popular.

By the sound of it, when it comes to delivery format, it's a personal preference thing?

 

[soundslikejoe]

Almost all of this is quite different from what soundslikejoe requires! BTW, my first task upon receiving the MOV file is to transcode it to ProRes 422 (or DNxHD)!

G

My recommendations are designed to avoid a transcode.... and to help clients understand why the "YouTube" h.264 preset sucks. We can work with h.264, but only if it's encoded to those specs. Otherwise.... creative time is lost to transcoding.

I wouldn't say it's a personal preference. It's more of a "know your codecs" thing. If you're paying an audio post house hourly or daily, do you really want them to spend part of that time transcoding the video because the export settings weren't "best practice" for a workprint?

 

[AudioPostExpert]

The reason I was asking about the processor load of PT (and obviously DAW) is it's hard to work out the effect it will have on a given system without knowing if it's already under strain.

That's a very tricky road to go down! It's not at all simple to calculate (or even guesstimate) processor load. A fair amount of digital audio processing uses recursive algorithms, effectively looped equations, where the result of the calculation is fed back into the equation, sometimes hundreds or more times. With this type of processing, it's not the amount of processing power one has available so much as processor speed. It's entirely possible for a 4 core machine to out perform a 6 or even 8 core machine when it comes to digital audio processing, depending on processors' speed.

It's much easier just to think of the problem the other way around, long-GOP codecs/settings require considerably more processing than DI codecs and just on that basis alone, it's usually worth using a DI codec. There are additional potential problems when trying to work with long-GOP codecs which should rule them out as a work-print codec. We're often jumping around (scrubbing or locating) to specific frames, frames which may not in reality actually exist but have to be calculated on-the fly, this can cause: 1. Processor spikes and potentially DAW errors/lockups and 2. Sync inaccuracies or errors, depending on the synchronisation architecture being used. These aren't issues one is likely to encounter when just playing back a long-GOP video file as a consumer would, it's only likely to become an issue when actually working with the file and particularly when constantly relocating, scrubbing or shuttling.

By the sound of it, when it comes to delivery format, it's a personal preference thing?

Not so much ... It depends on the workflow and the hardware/software being employed by the audio post team to view and sync the video.

My recommendations are designed to avoid a transcode....

My recommendations on the other hand; substantially reduces online storage requirements and exchanges potentially lengthy upload/download times for a relatively small loss of time spent transcoding. Again, there is no "one size fits all", it depends on workflows and various other factors.

G