Choosing the best file formats to edit with in Premiere

[Richard Herd]

Wow, that’s a huge question.

Video files are huge. That’s why they get compressed inside video and digital cinema cameras. Your first step is figure out the footage details: What codec will you be working with? This will determine how much throughput you need.

The drives containing media are called scratch disks because they used to be so damn expensive, you stored the media on cheap drives until it was time to edit and then you moved the video files to the scratch disk, then when you were done, you moved them off and so on. It was a pain. The term “scratch disk” still remains.

Before you can figure out your system and workflow, you’ll need to know what codec you’re working with. I would assume you will be using some kind of dSLR codec, like H.264; in which case, your workflow is pretty simple. You will still need (and I said NEED) some kind of external scratch disk. I think a thunderbolt drive would suit your needs pretty well (if my assumption is correct). Then, after your shoot it is super important (I said SUPER IMPORTANT) to transfer the entire contents of the card on the dSLR onto the scratch disk. I use folders for example based on client names. Inside of that folder is another folder called “Camera Archive.” Because a shoot can use many folders, inside of that folder is more folders containing the entire camera archive — not just the .mts, for example. You need the entire contents — the camera archive.

Then in premiere pro you navigate the media browser to that folder and PP will recognize what kind of native codec you will be using. Then drag the desired clips into the project pane. Then, and this is importan, right click the file you want to use and create a sequence based on that file.

Because your files are already compressed (again: that’s my assumption), you won’t gain any quality changing them to an uncompressed format. When you “uncompress” a compressed file, you are actually using your computer’s graphics card to interpolate any missing data (frame size, intraframes, etc). What you want to do is edit your piece and then export it to Adobe Media Encoder so your deliverable matches your requirements.

That’s a basic nutshell.

TL;DR: you gotta know what your camera codec is; what files you’re getting from the cinematographer.

[Audrey Chandler]

Hi, thank you for taking the time to write such a detailed reply, I appreciate it. But unfortunately I think there was a miscommunication about what I’m trying to understand. =) I know I tend to write a lot; I type really fast and I’m detail-oriented so it just happens.

You’ve explained a lot of good stuff about how to set up an editing hardware flow based on one’s situation and codecs in use. What I’m trying to understand is the reverse — what codecs and formats should I use, given a flexible (not-yet-constructed) HW system.

Let me try to TL;DR the most important questions from my post to make it a little more direct/readable:

Does PP have trouble keeping a smooth editing flow as file sizes increase? One example I was given is that anything over about 50GB will make PP stutter/lag on playback, and a 3TB source file would be almost uneditable.

Does PP have trouble keeping a smooth editing flow as source length increase? For example, if you ingest 5 hours of total footage, would it become very hard to scrub/playback while you trim it down?

If I hypothetically have the choice of editing in PP with any codec I want, are there any ‘darling’ codecs that behave better / edit smoother in general? Or, conversely, any codecs you should emphaticaly not edit with?

If I’m trying to maintain maximum fidelity, will PP behave better with Uncompressed sources (massive size, but low CPU burden) or Lossless codecs (much smaller size, but compressed/encoded)?

That’s my situation, I can choose to capture in basically any format I want (and likewise encode before editing, if appropriate). Thus I’d like to try to select the ‘best’ file design before choosing hardware so I can adapt the HW to the proposed design, rather than having to later adapt the editing choices to the available HW.

I hope that was a little more clear & I’m sorry if my first post was too disjointed/vague. This stuff is just super overwhelming when you’re first crash-coursing it so I’m a little scattered atm. =)

[Richard Herd]

[Audrey Chandler] “Does PP have trouble keeping a smooth editing flow as file sizes increase? One example I was given is that anything over about 50GB will make PP stutter/lag on playback, and a 3TB source file would be almost uneditable

Does PP have trouble keeping a smooth editing flow as source length increase? For example, if you ingest 5 hours of total footage, would it become very hard to scrub/playback while you trim it down?

If I hypothetically have the choice of editing in PP with any codec I want, are there any ‘darling’ codecs that behave better / edit smoother in general? Or, conversely, any codecs you should emphaticaly not edit with?

If I’m trying to maintain maximum fidelity, will PP behave better with Uncompressed sources (massive size, but low CPU burden) or Lossless codecs (much smaller size, but compressed/encoded)?”

Let’s try this a different way:

Are you starting a business where people pay you to edit video?
Are you trying to make equipment purchases that seek a maximum return on investment?

Source files don’t get bigger. They are what they are. If you have 10 minutes of footage, and that file is 10GB, then when you edit, Premiere Pro only points to the media file (the video) and says “Audrey only wants to use frame 01 to 29.” Then when you save the Premiere Pro project file it retains that information, of your edit. That source file of the video footage will not get bigger, but the project file will get bigger as you import more footage and start to edit it. But they don’t get very big. You can add more files to your project and premiere pro does fine. It’s very smooth…

and that brings me to the next issue. The reason the playback is smooth is because the computer’s graphic cards can process the video quickly. So if you are going to spend money, don’t skimp on a graphics card. Basically, the more expensive the graphics card, the more codecs you can throw at Premiere Pro. Professional grade graphics cards are very expensive. And the reason the graphic card can process the video smoothly is because the scratch disk can get the video to the graphics card quickly.

The issue is not whether PP has a “darling codec,” but rather, what footage will you be getting to edit? Is someone going to hand you HDCAM SR tapes? Will they mail you a drive containing Arri Log files? Are you getting Apple Pro Res 422 HQ?

You really need to know what footage you will definitely be getting. The only way to find this out is to ask the shooter, and you can also tell the shooter, “I want Apple Pro Res 422.” Or “I want the camera archive.”

Maximum fidelity is a slippery question because maximum fidelity is relative to whatever camera the shooter used. There’s a difference between H.264 and Canon Log Gamma footage. It’s hard to say how exactly to maintain “maximum fidelity” without knowing what footage you’ve got. Each of those workflow pipes has a different problem. It would be unwise to invest in a workflow for Canon Log Gamma footage if you’re getting h.264.

A few years ago, the workflow pipeline meant transcoding video into an editable codec. Mostly those days are over. Premeire Pro can handle many codecs natively. The money issue is throughput. Sure PP can handle Canon Log Gamma but can your drives send the data fast enough? Can your GPU handle the dataset quickly?

If you’re looking at maximum of maximum of everything, you’d need to investigate HPZ820 with AMD radeons, a storage SAN, with fiber optics — can easily run into $100,000 BEFORE you buy the above mentioned HDCAM SR deck; that’d be another $100k. A gargantuan waste of money if you are getting h.264 footage.

Anyway, the sweet spot for “the basics” (as is this forum’s name) is about $10,000. Can you do it cheaper? Not really, because pro work includes storage, backup, audio mixing, audio i/o — there’s really a lot of details. You might want to post on the gigs forum for a quote from someone around the CreativeCow who sets up video suites/edit bays for a living. They are very knowledgeable.

I hope that helps some.

[Audrey Chandler]

Hi! Yes, thank you, we’re definitely making progress now, haha. I appreciate your patience. The explanation about the difference between Source and Project even answered a separate question I’ve been wondering about, too. =)

I was worried about codecs because I’ve read that some codecs are very much inappropriate for editing (like xVid and .wmv), and other people have expressed really bad editing issues with codecs like x264. I was just trying to avoid those and favor ‘good’ codecs that PP handles well.

I was dodging getting into too many details about my workflow to try keep the TL;DR factor down, but from how you’re talking it seems important to explain better:

I’m not starting a business, no. I wouldn’t mind being paid to do this, but I don’t have the experience yet at all, haha. =)

This is a personal creative passion, so no, ROI is completely secondary to just being able to finally do what I want.

I will do some editing of ‘IRL’ footage or cleaning up my animation work for upload, but I’m not doing tons of ‘shooting’ or anything professional like that.

Primarily, my worry point is relating to capturing and editing gameplay footage which I want to upload and share on video-sharing sites.

I know that last point usually meets with exasperation/dismissal, but understand the kind of data I’m moving:

I want to record at 1080p 60FPS.

Doing this Uncompressed (True Quality RGB24) passes roughly 350 MB/s (!) to the recording drive (since this is captured to disk in realtime) and requires roughly the same data rate to read it for playback.

It also occupies disk space at a rate of about 1.5 TB/hour (!!).

If you record to Lagarith Lossless (for example), you pay a CPU penalty while gaming (lower in-game FPS) but the data stream requirement to your disks is cut down to about 80 MB/s (!) and storage space down to about 300 GB/hour. However, Lagarith has issues in PP according to other editors (addressed below).

“1080p 60FPS for YouTube? You’re an idiot!” you may be saying, haha. I have thought it through, and I do have rational reasons for striving for this goal. =) But I’m happy to explain in more detail if asked.

More to the point about my design concerns: I was talking with someone else who has a very similar setup to the system I’m building (sans the storage choice):

i7 4770K (oc’d)

32 GB RAM

SLI GeForce GTX 780

Editing source media from 2 SSDs in RAID0 (!), with OS/Programs on a separate SSD.

That’s no slouch system. It’s not a dual-Xeon workstation, for sure. But the CPU is 4 core (hyperthread to 8), GPU is top-of-the-line current tech and totally CUDA-capable, and those SSDs should be providing about 1GB/s (!!) transfer rates in both directions.

But he says that editing a 3TB Uncompressed file in PP is ‘a struggle’ and he has to keep Low-Resolution Previews on at all times. Bringing in Lagarith Lossless footage is ‘too tedious’ to edit with because PP ‘struggles to play it back’ no matter what settings he tries.

That’s what has me so scared — I’m trying to figure out what I have to do to make it possible to edit smoothly, if his PP is choking that badly even on that system.

But unlike someone who has to work with a specific studio, or just accept whatever their clients bring them, I can choose exactly which formats/codecs I want to record and edit in. Hence why I feel so disoriented — everything seems to be either too big (and PP chokes) or too compressed (and PP chokes) or too low-quality (and negates my whole point). The ‘Goldilocks’ capture/editing format eludes me.

So, I thought that asking people who do this in serious quantities, with seriously huge/high-quality source footage, every day, for a lot (?) of money, might be able to just give me the straight dope about what file sizes and types do and do not work well in PP. =)

[Richard Herd]

[Audrey Chandler] “but understand the kind of data I’m moving”

Here’s a bunch of fancy terms to investigate:

— Chroma Subsampling
— Long Group of Pictures
— File size of 444 RGB video
— SMPTE Rec. 709

The kind of video that you want to work with is massively expensive and only a few places actually do that, and they’re in Hollywood (for example) in digital intermediate facilities. Here’s basically what happens. They shoot the movie on film and transfer the film to HDCAM SR. Then the HDCAM SR is transferred to an editing codec like APR422 or Avid’s DNxHD. It’s at this point where the film editor edits the movie, for several weeks or so. When she is done, then she sends an XML file or an EDL to the color correction artist who then uses the HDCAM SR tapes to color correct the movie and export a final version for the cinema (check out digital cinema initiative). That workflow is called “online/offline.” You, it appears, want to create an “online” facility. That’s awesome!

Footage in APR422 or AVCHD are fine codecs. The long gop problems you linked-to are largely irrelevant. Here is a screen capture from the Media Browser in Premiere Pro CS6.

screenshot2014-01-20at10.14.35am.png

You can see that PP has no problems looking at and processing the Long GOP formats and the other specialized codecs. The Creative Cloud also includes a nice program called Adobe Media Encoder which does exactly that–encodes media from one format to another. Here’s a picture of that.

screenshot2014-01-20at10.30.14am.png

(Quick footnote: In order for PPcs6 to manipulate the Long GOP formats, the entire camera archive must be present. Many people are mistakenly just copying the .mts files to their hard drives and wondering why they cannot edit the files very well. It’s because the camera archive contains metadata and hidden files that PP will see and therefore interpret the footage correctly.)

[Audrey Chandler]

Wow. That’s probably the most education I’ve ever received from one single forum post. It’s also in competition for the most number of times I’ve had to stop reading and go to Wikipedia before finishing a single sentence, hahaha.

So, thank you, that clarified a lot of concepts and crash-coursed me in some major areas related to codecs and video processing that I was still missing.

Basically what I’m understanding is a few major points of interest:

• Very few people, even professionals, edit in Uncompressed or True Lossless formats because they are simply massive in size and data rate.
• Instead, even most professional work occurs in “intermediate” formats that are “acceptably lossy” so that they don’t impact perceived visual quality very much but do reduce bandwidth and file size significantly.
• Highly-compressed or very lossy formats are generally only used in the final export period when no editing is necessary and the product is being delivered to its target audience (broadcast, Web stream, etc.); these are “distribution” codecs and usually have nothing to do with the editing process.

For expensive/ultra-professional work, a general format like this is used:

• Perfect or very-high quality source is captured
• This source is then transcoded down to a smaller, lower-bitrate, more manageable format which is used as a ‘rough draft’ so that the editing process is smooth and responsive
• Once all edits have been made, those are applied to a copy of the source to produce a cut-down, edited source version which is still original/high quality
• This edited source is fed further down the production stream to people who can’t work with ‘rough’ versions, such as precise digital effects or color-correction.
• The overall goal is to minimize how much full-size, full-bitrate source needs to be manipulated at any given step, which allows less-expensive hardware to still function effectively.

Based on this, my problem is thus:

• There is no magic bullet that makes video footage smaller and faster to edit and causes no quality loss; every codec and format choice makes tradeoffs. Professional workflows handle this by having external storage that allows different versions of the footage to be split off to different parts of the production pipeline based on its minimum requirements.
• My “actors” and “studio” and “sets” are all digital inside my computer, meaning there is no ‘external’ source separate from my editing environment, unlike an HD format digital tape or an expensive studio camera that records directly onto SSDs.
• This means that transcoding my source into a ‘rough’ editing format can partially mitigate some issues (disk throughput requirements during editing), but actually makes the storage space issue worse (since I have to store both my source and my transcoded copy internally).
• Additionally, there is no way for me to get around the bandwidth requirements for the highest-quality part of my workflow, because I’m not using external hardware (like a studio camera) — I’m capturing the action directly from one part of my PC (RAM) to another (media storage disks), so my hardware must be capable of transferring the highest-quality bitrate in use (even if I transcode down and edit in a rougher format).
• Basically, I have two choices: pay a lot of money to make sure I have enough storage options and HW power to handle these extreme data rates and sizes, or accept some imperfections somewhere in the workflow: either less-smooth editing, a more destructive workflow, or lower-quality footage.

However, the problem here is not Premiere Pro. PP will gamely handle nearly everything you feed it (assuming you import properly). Instead, the problem is attempting to use PP to perform (unintentionally) professional-level editing with merely high-end consumer level hardware. For example:

• If PP is choking on 3TB Uncompressed files, it’s not PP’s fault — PP just doesn’t have access to enough disk data xfer rate and/or RAM and/or GPU power to keep up.
• If PP is choking on Lagarith or UT files, it’s not PP’s fault — PP just doesn’t have access to enough CPU cores to decode the video stream in real-time.

I think that’s a correct summary of my issue, based on everything you said and directed me to research. In this case, it seems the best approach is to stick within my budget and build the best system I can. Then, adapt my workflow around my PC’s capabilities, since I’m doing much more extreme work at the data level than I realized!

I guess it’s humbling to realize that even building a “top line” desktop PC that costs thousands of dollars is still nothing in the face of truly professional-level hardware demands, haha.

You’ve taken tons of time to read my stuff and answer, and I really appreciate it. I guess this post is mostly to collate my thoughts and assess everything I’ve learned. But if you do read through this response, feel free to let me know if I’ve misunderstood a concept. =)

[Jeff Pulera]

Hi Audrey,

Your enthusiasm is admirable, but I think you’re “overthinking” the whole thing a bit much. And getting some bad info perhaps. In scouring the entire internet for information, you’re getting the good, the bad and the ugly all mixed together and perhaps losing perspective of what is a “normal” editing experience to expect with Premiere.

Premiere is designed to edit most formats natively. You don’t need to first convert to something lossless or uncompressed. I’ve been editing NLE professionally for over 15 years and have never used uncompressed video, or had any need to. I also seldom use “lossless” codecs – I just edit the native camera material, and might use lossless only to archive an edit master copy, or as an intermediate. Without a 4 or 8-drive RAID array costing thousands of dollars, your computer won’t be able to play uncompressed HD clips because the drive simply is not fast enough to move the data. Nothing to do with Premiere. Uncompressed files are actually EASIER for Premiere to play, since each frame does not need to first be decompressed for playback, as camera codecs require. All about drive speed. And having a 3TB source file? Unheard of, unless making a movie in Hollywood. Not typical at all.

The issues you’ve read about with Premiere having trouble with some formats is because those formats were not meant to be edited. MOST video editors are starting out with files from video cameras, or something you captured from a capture card or screen grab software. That is what editing is all about – taking raw footage and putting together a program. The folks having trouble are taking finished videos (pulled from the web no doubt), that are already in a DELIVERY FORMAT such as .wmv or Divx, and trying to re-edit those clips. That’s not how it’s supposed to work. Those formats are highly-compressed and optimized for delivery/viewing and do not lend themselves to being edited again.

I would disagree with the definition of “scratch disk”. A video editing system will have a dedicated “VIDEO” drive where your clips are stored. This is your fastest, largest drive (a RAID is a good choice). When importing, editing and rendering video, Premiere creates a LOT of small, temporary files in the background, transparent to the user. THOSE files are what you would send to a “scratch” disk. The TEMP files. Not the VIDEO files themselves.

Years ago, with small IDE hard drives, setting up several scratch disks (audio, render, etc.) could be quite beneficial to overall performance. With today’s screaming fast computers and hard drives, I think a lot of the benefit is lost. A large, fast video drive is capable of handling it all. If you want to have scratch drives, you are welcome to, just saying it is not a necessity by any means.

This does bring up a point – many new PC builds use an SSD system drive (C:) and those are not very large. Premiere does by default write Media Cache files to the C: drive and that can quickly fill up an SSD if you don’t keep the Cache cleaned/maintained, so in that case, it can be beneficial to designate another drive for that purpose. But setting up a specific “audio scratch” drive for instance is not really needed. A scratch drive does not need to be external, and for a PC, Thunderbolt is not a viable option anyway (mostly Mac, PC side is not developed much yet).

I have a 3-year-old Core i7 with a single RAID 0 video drive and I edit and export all kinds of HD formats and it works just fine. If I was suffering from slow editing, long exports, etc. then I would add more drives if I thought it would help, but I don’t need to. The system is quite responsive as is.

Back to hard drives – seeing as SSDs are quite small and expensive compared to SATA drives, I’m not recommending them for video. System drive and Scratch would be a good use as you’ve determined already. For VIDEO, you want SATA 6Gb, 64mb cache, 7200rpm units. Avoid “green” drives, they are low-performance. If you can use TWO of the SATA drives configured as RAID 0, you effectively DOUBLE the speed and size of the video drive and that works great for HD editing. Can be almost as cost-effective sometimes to just get an external RAID, with eSATA or USB 3.0 connections, but internal is fine.

Video cards – double 780s are overkill for editing (unless you feel you need it for the gaming side). There is such a thing as an unbalanced system. For instance a monster computer, with slow hard drives. Or a good i7 computer with monster video cards that can process more data than the computer can handle anyways. The video cards are “idling” and not able to be fully utilized (for editing).

You didn’t say what utility you would use to capture gaming clips, but the Lagarith codec should be good. I use that for an intermediate codec in one of my HD workflows and it plays fine (on my old computer).

I’m not totally sold on the Windows 8 thing and would use Windows 7 Pro 64-bit myself, up to you.

I hope this info helps clarify a few things. Put some fast storage in the machine and playback will be fine, no worries there.

Thank you

Jeff Pulera
Safe Harbor Computers

[Audrey Chandler]

Hi Jeff! Thanks so much for your reply. Big thank you to both Richard and Jeff, actually. You have both helped so much with understanding this stuff and sorting out — as you put it — the “good” from the “bad” in terms of what I need to know. I feel so much more confident about what I’m doing now. =)

As far as lossless/uncompressed, it’s actually the other way around — my source can come in those formats if I choose (since I can capture to any codec I want via Dxtory), and I wanted to do so for the image quality advantages because computer-generated subjects break down in quality faster under compression since they have simpler lines and more areas of solid color, etc.

However, these lossless/uncompressed formats are huge and, as you point out, require crazy disk throughput both for reading (editing) and writing (capture). So I was trying to find ways to “cheat” I guess — capture at very high quality and uncompressed (for minimal CPU load during play), then encode down to a slimmer format to reduce disk storage and bandwidth needs once I have idle CPU time.

Unfortunately, a 3TB source file is actually quite easy to create when doing game capture! Capturing in True Quality RGB 24 in Dxtory produces about 1.3 TB per hour in 1920x1080p at 60FPS. It’s not uncommon to record 5-6 hours over several days before finally editing it down to a final video.

But from what Richard explained, that kind of footage is (unwittingly on my part) on par with the sort of data Hollywood productions push, apparently. Oops. =(

I wanted to use Thunderbolt 2 for external drives because it’s faster and less bogged-down by the presence of other peripherals than USB3. I know it’s mostly on Macs, but since the motherboard I’m considering supports TB2, I figured I should take advantage. =)

I agree with you about the SSDs for editing — a lot of people keep encouraging me to, for example, RAID0 two 840 EVO 1TB for the ~1GB/s throughput. But I have a hard time spending ~ $1000 for 2TB (…) of storage with video editing. I’d rather have more space. I guess there is some argument for capturing/editing to the SSD array and then storing the files on a big HDD for archive when finished, but it still seems really expensive for what you gain.

The 780s are most definitely overkill for Premiere, hahaha. No arguments there. They are there to allow me to game at 120 FPS when not recording and to ensure I maintain 60 FPS during capture, because I start to get really bad motion sickness when things dip toward the 30-40 FPS range. =)

I am curious about your disapproval of Windows 8 — from my understanding, the issues people have are mostly with the clunky UI (which can be remedied). I thought Win8 would be a good idea since tech types have told me it has higher performance and better design at the code/OS/technical level. But if there’s issues with Win8 in terms of creative/professional workflows, I am definitely interested to know about it! =(

Your other comments and recommendations about disk setup and different codecs, as well as your own experiences, were very helpful. Thank you.

Whew. Every time I think I can rest and have everything wrapped up, you guys come back with even more insights and comments that get me thinking again. It’s totally great — I love having such experienced users helping me plan. Again, I feel so much more confident about this compared to how lost and overwhelmed I was when I started. =)

TY both, as always. ♥

[Richard Herd]

Yep, you got it.

So what are you going to do?

[Richard Herd]

Have you seen this page? It might help: https://www.adobe.com/products/premiere/tech-specs.html

With regard to scratch disks, here is the PP interface:

So you can see what I’m working on 🙂 More importantly, these scratch disks are used to store media files, so they are fast. As a mograph artist and commercial editor, I often run multiple layers of video in the same timeline, so each layer of video doubles the amount of necessary throughput. On the full rez stuff you were contemplating, you will need one of the fastest GPUs out there and also the scratch disk could be a RAID (obviously, RAID 0) being the fastest. In the old days, the scratch disk was literally a place where the media sat only during the editing session — because they were very expensive SCSI gadgets. Now that’s an old-school term, because the drive space is cheap enough where you can keep many projects on the scratch disk — so in practice we call it the media drive, or the video drive, etc., but the legacy term of “scratch disk” remains — as you can see. You could even have 4 separate separate scratch disks depending on various stuff (like where your audio engineer puts their sequence, and how its conformed). For my workflow, I try to keep the files “same as project” but these are not the drive running the OS.

I’ll be curious what system you set up.