My trusty friend FCP 7?

[Bill Davis]

I think you’ve got it right.

I’m about 90% of the way through creating the live show video playback reel for the 2012 Rocky Mountain Emmy Awards. Key factor about that is that there were a zillion submissions in formats that were all over the map.

85% of them imported directly into X just fine. But some didn’t. Mostly Flash, some oddball WMV files – and a handfull that MediaInfo couldn’t even figure out.

I transcoded all the oddballs into M4V files – and got them all into X with no problems.

Was going to slap them all into 1280×720 timelines but in the rush of processing literally 140 source clips, I noticed after the fact that I let some of my storylines default into the incoming clip settings.

Needing to work fast, I did NOT auto-render ProRes or Proxies figuring I could do that later.

So my many storylines were all over the map, depending on what came in from the submitteer.

A couple of my more complex storylines – like the big “section winners” showcases were truly mixed format hash – with 40 or so clips on a timeline with who knows what origination formats.

So when I went to master the files for the show, I just set the Share settings to make them all H-264 1280×720 and sure enough, X did any necessary re-sizing and transcoding on export. I didn’t even have to go to Compressor, since I could just export each one out of the Project Library sequentially and X queued them up and ran them automatically over my lunch break. When I returned I had a nice folder of export masters ready for FTP to the local sports stadium server that will playback the show.

Tells me that unless X can’t READ a file the only real reason to transcode PRIOR to ingest is if you need the efficiency of working ProRes or Proxy for internal editing efficiency.

If not, and your files work okay on your timeline – then just do your file transcoding as a regular part of the Share process.

I keep finding that X seems to be quite a bit smarter than I’m accustomed to – and I don’t have to do NEAR as much prep work as I used to on projects like this.

For what it’s worth.

Know someone who teaches video editing in elementary school, high school or college? Tell them to check out http://www.StartEditingNow.com – video editing curriculum complete with licensed practice content.

[Jeremy Garchow]

It’s hard to know what exactly is going on here.

As far as I know, a/v foundation doesn’t have that capability built in to it quite yet.

That doesn’t mean that fcpx can’t do what you’re describing, however.

The only testing I can do is by time, like you said, it takes the same amount of time, but that doesn’t tell us the whole story.

Sorry that I don’t know any more about it

[Bret Williams]

Best test might be to put hq in a 422 sequence and see how long that takes to render. If that goes in the same time, I figure it’s decompressing- but it’s just so much faster than 7.

[Bret Williams]

I don’t think this has anything to do with my post, but nice story anyway. 🙂

I’m looking to find out if proRes 422 IN a proRes 422 sequence gets retendered to proRes (gen loss) in X. In 7 the file is just repackaged, not rerendered. Your final is the sAme quality as your source. I think X might be doing it when you export a master file.

[Bill Davis]

[Bret Williams] “I’m looking to find out if proRes 422 IN a proRes 422 sequence gets retendered to proRes (gen loss) in X.”

Presuming the word above was rerendered, then I can’t imagine why. Again, X is all about sequestering data in it’s original state, then applying metadata to store changed state info.

Why would the coders employ an approach to force the entire original file to re-render to get back to the exact same data state that it was originally?

If you apply changes to some of the data – transitions, overlays, whatever, then the pointers have to change to the new render code, but there’s no transcoding in play, just re-compositing.

Doesn’t make much sense to require transcoding from a thing to the same thing – at least to my thinking.

But I’m not an expert on how the plumbing works. Just a guy who works with a whole bunch of original formats and exports – and IME, X does a pretty superb job of whatever transcoding and rendering it needs to do. I hardly EVER see any visible quality degradation unless I’m doing something really squirlly like plopping a low rez SD master into a HD storyline and re-sizing the original pixels. That’s about the only time I see visual quality that makes me cringe.

YMMV.

Know someone who teaches video editing in elementary school, high school or college? Tell them to check out http://www.StartEditingNow.com – video editing curriculum complete with licensed practice content.

[Mark Morache]

I too wonder about the rendering. I see that when you create a project, you can set the rendering to several different flavors of pro res, or uncompressed.

I liked knowing that FCP7 kept the timeline codec the same as the footage, and I thought rendering the footage with the same coded, giving me essentially the same ones and zeros, be they pro res, hdv or xdcam.

Most of my editing these days is xdcam 35. I believe that when I edit, anything I render is done in pro res, and when I export my final video as xdcam 35, that everything probably gets transcoded again. If the renders are pro res, why would it not recompress the entire timeline? If it didn’t recompress clips that were totally unaltered, I’d love to know that.

I gotta say however, I really miss qt reference clips. If you exported a long clip and needed to make a very short fix, you didn’t need to wait for the entire thing. I like to use turbo hd by elgato to do my h264 compression, but it doesn’t work with X, and I don’t like exporting a huge pro res file first.

———
Don’t live your life in a secondary storyline.

Mark Morache
FCPX/FCP7/Xpri/Avid
Evening Magazine,Seattle, WA
https://fcpx.wordpress.com

[Bret Williams]

If you’re exporting XDCAm it’s always going to have to get recompressed isn’t it? It’s a long gop mpeg2 variant, right? Even in 7 XDCam would have to be conformed either while you edited or when you exported. Either was painful. I always worked in a ProRes sequence and exported as ProRes. No need to rerender xdcam down a generation as xdcam again. ProRes won’t improve it, but it should preserve it.

And yes, reference clips would be great! And if that’s not possible, then the system is probably not working like legacy.

[Bill Davis]

I’m still confused by this thread.

I thought the whole point of X was to sequester original files unchanged. Then give you the OPTION to create intermediates (ProRes and Proxy) to enable you to “see and edit” more efficiently – but I never took that to mean that those “functional transcodes” meant that X was somewhow using THOSE files for making it’s export soup. The edit/change data is just more metadata. So when you elect to Share something – X intelligently looks at what your target format might be, and decides whether it makes sense to export from your TEMP files (ProRes) or whether it makes more sense to go back to the sequestered originals and calculate everything anew based on your output requirements.

It’s an established fact that X does it’s “inside the timeline” calculations using background rendering while splitting it’s resources to allow the user to both work and render in small blocks – but when you go to Share a final, the program focuses on using as much of the OS and Hardware resources as possible to create the newly requested master.

This whole structure seems to me (if I understand it correctly) to be why we have such flexibility in place.

X essentially doesn’t dump the links to the original files simply because you make ProRes versions for your timeline functions.

Instead it uses what makes the most sense depending on how you elect to export.

If you’re dumping out an iPhone file, why use your full Alexia files as the source? ProRes or even thumbnail transcodes might be way more than is required to scale footage to that resolution.

Then again, if you elect to output 4k – then it only makes sense to re-link to the original source files in order to make a high rez export.

Seems just common sense to me.

Or is my thinking off here?

Know someone who teaches video editing in elementary school, high school or college? Tell them to check out http://www.StartEditingNow.com – video editing curriculum complete with licensed practice content.

[Jeremy Garchow]

[Bret Williams] “And yes, reference clips would be great! And if that’s not possible, then the system is probably not working like legacy.”

And this is where A/V Foundation isn’t like Quicktime. You can’t do as many things with A/V Foundation as you could with the Quicktime API.

This is why I say I can only test with the amount of export time.

Export a ProRes file to ProRes, check time.

Add a filter, export, record time.

Add a filter, render, export, record time.

It’s not very scientific.

I have a hunch FCPX is recompressing every thing on the way out, but it is hard to know for sure.

FCPX, in this regard, works similarly to Pr (most of the time), although Pr has received some updating in this area. The term used by Adobe is “Smart Rendering” and Pr now supports a few codecs with Smart Rendering.

https://helpx.adobe.com/premiere-pro/using/smart-rendering.html

[Jeremy Garchow]

[Bill Davis] “If you’re dumping out an iPhone file, why use your full Alexia files as the source? ProRes or even thumbnail transcodes might be way more than is required to scale footage to that resolution.”

Garbage in, Garbage out.

Even if it’s an iPhone file, I want FCPX to use the best quality it can. ProRes Proxy is truly a Proxy.