Ha, ha, media capacity issues of ProRes would literally be a show stopper for me. Till I can plug a 10tb m.2 into my camera. Right now I use 1tb and am limited to 2tb.

The new ProRes support in V18 is of great interest to me - do either of you know if SOURCE TIMECODE is supported. (You can check the media properties and look for a number in the timecode box. If it is just zeros then no. This does, of course, assume the original clip had timecode, if you are looking at a transcode.)

@Kinvermark Not sure exactly, best to give you a screenshot.

This clip was rendered out from VP18 b482. But I think I understand, the original clip had to have time code.

There are just zero's in the box. Do you have a source clip with timecode to test?

@Kinvermark I think your out of luck, but not certain. Two screenshots, 1st is from a GH5 showing timecode value, 2nd is rendered out Prores file showing zeros.

#1 Source #2 Prores rendered out

Can I take it that the 2nd. one should have the same time code as the source?

Mediainfo timecode details from source file. No such info available in the Prores file, just video and audio.

Other
ID                                       : 3
Type                                     : Time code
Format                                   : QuickTime TC
Duration                                 : 3 s 840 ms
Bit rate mode                            : Constant
Frame rate                               : 25.000 FPS
Time code of first frame                 : 00:09:14:15
Time code, striped                       : Yes
Encoded date                             : UTC 2017-04-11 15:12:07
Tagged date                              : UTC 2017-04-11 15:12:07

@JN-  Thanks for doing that! Much appreciated. You are right, the timecode is not being passed to the ProRes file (should be same as the GH5 original.) Maybe there is some other trick or fix, but for now I won't be rushing out to upgrade to V18.

Here's the same test run on my Dell xps15-9570 laptop rendered 1080p with Nvenc encoder w/studio drivers:

ProRes 422    v17.452: 1:24 sec;  v18.482: 0:38 sec
Hevc 420      v17.452: 0:43 sec;  v18.482: 0:47 sec

On this system, ProRes got dramatically better with v18 but Hevc got worse. I think that's probably because the laptop's cooling clamps down cpu and igpu performance under hevc processing load. Nuc's 4-core cpu has a tdp of 100 watts compared to the laptop's 6-core tdp of 45 watts. Good thing my Nuc and laptop both fit into a single carry-on.

@JN-  Thanks for doing that! Much appreciated. You are right, the timecode is not being passed to the ProRes file (should be same as the GH5 original.) Maybe there is some other trick or fix, but for now I won't be rushing out to upgrade to V18.

@Kinvermark I think the new v18 ProRes render presets are more aimed at satisfying clients that request it as a final delivery format and place value on it being Apple certified... which is quite common. I haven't tested changes in rendering v17 Magix Intermediate compared to the new v18 ProRes presets yet.

As far as I remember Vegas Pro never passed any timecode from any kind of source (except of smart render processes which doesn't work for ProRes). It reads some kinds of timecodes, it can display or use some kind of timecodes for synchronize processes but when it's about rendering the timecode will always be written anew (except of the smart render mentioned above).

"You are right, the timecode is not being passed to the ProRes file (should be same as the GH5 original.) Maybe there is some other trick or fix, but for now I won't be rushing out to upgrade to V18."

You would not want the timecode in your new file to match the original. Reason: When you are editing you are generally cutting, shortening and rearranging video on the timeline. If the TC matched, it would jump/change at each edit point. The purpose of Timecode is to give a continuous consecutive unique naming of frames. Normally your new ProRes file created would match the timecode that was set on your timeline in Vegas. (meaning if you use Drop Frame, the file should be drop, and non-drop etc)
I do not have 18 so I don't know if it is creating new timecode in the rendered file. Other NLEs normally do.

I am not sure that makes sense in a workflow where XML timelines are passed back and forth - but I will think about that some more :)

However, an important question remains: does the new Apple Prores decoder read & show timecode from an existing Prores file created by a camera or when transcoded by an outside program such as Kyno or Davinci Resolve. (These two do preserve timecode when transcoding.) This would be important if, for example, you had Prores camera files - edited in Vegas (minimally/no fx) - passed timeline as XML to Davinci Resolve - reconform in DR (needs timecode match) -cc & final export.

I think @alifftudm95 had this problem with the older versions - i.e. the XML timeline exported from Vegas to Davinci Resolve couldn't find the files.

It wouldn't affect projects passed back and forth because the XML refers to the timecode of the original source, not the finished render.

That's why Vegas needs to read the source timecode - so it can pass it to the other program in the XML. You may want to give this a try yourself to confirm, but I know this to be the case. If, for example, you use clips in a format that Vegas does NOT read timecode, then when you send the XML to Resolve it won't easily conform (you can often force it to do so by name overriding the timecode) and the edits won't line up.

Vegas can read timecode from some files, if I remember correctly, we had this discussion a few years ago and QT Timecode is different than AVI timecode and Vegas did not read QT timecode. You can fake it though by reading the first time code of the QT file and enter that into the Properties of the file in Vegas.

Ooops something went wrong with my post.

Yes, there are a bunch of types that work and a bunch that don't. Vegas 16 reads TC from MP4 (GH5 and GoPro) - also Cineform and Grass Valley HQX. Cineform is "visually lossless" which can be handy; Grass valley is not AFAIK, but otherwise works well. Cineform sometimes has problems with black frames in Vegas. Both are more "scrubable" in the trimmer tha the MP4 files, but perhaps V18 is better with these (or I need a faster computer.) Swings & roundabouts :) Apple ProRes seems to be emerging as the best all-round intermediate format, so would be nice to have TC read support.

Here is a short bit of a file in ProRes (about 12 MB). Transcoded by KYNO; confirmed TC readable in Davinci.

Perhaps someone can try it in Vegas 18 to see if TC can be read. THANKS!!!!!!!

https://www.dropbox.com/s/b5wx7fskwwyv2m7/P1050148-00495512-short%20bit.mov?dl=0

@Kinvermark 00:49:55:12

Thanks Magix!
Render times from a ONE Minute Test Video from a typical job on my 9900K / VEGA 64:

• 6:10 - V17 Magic Int 422 3840x2160 29.97 - 63% CPU / 3% GPU 597 Mb/s variable
• 1:39 - V18 ProRes 422 3840x2160 29.97 - 63% CPU / 13% GPU 664 Mb/s constant
   
• 8:33 - V17 Magic Int XQ 3840x2160 29.97 - 63% CPU / 3% GPU 1,077 Mb/s variable
• 2:04 - V18 ProRes XQ 3840x2160 29.97 - 80% CPU / 13% GPU 2,239 Mb/s constant
• 4:05 - V18 ProRes XQ (alpha) 3840x2160 29.97 - 80% CPU / 13% GPU 8,205 Mb/s constant

• 3:29 - V18 DNxHR 4444 3840x2160 29.97 - 48% CPU / 6% GPU 1,747 Mb/s constant

@JN-

Thanks mate! That confirms Vegas 18 can read timecode in a ProRes file - good news.

@Kinvermark You're welcome.