SOT:Hollywood movie post production

Comments

NormanPCN wrote on 4/13/2014, 4:24 PM
My reply was not in response to anything Bob(farss) said but specifically to something else and I believe the statement stands pat.

"That's true except the way Vegas does everything is based on time into THE file NOT source timecode ".

Okay, since you bring this statement up. This is not accurate in the following two instances.

Consider an XVAC MXF file with a timecode of 1:05.13.

If I open this in the trimmer window, the trimmer timeline starts at 1:05.13. Everything is relative to the file source timecode. So if someone told me to look at file X from timecode Y, and timecode Y is based on the source timecode, I could just punch that source timecode reference into Vegas and be looking at what was expected.

If via video prefs I have timecodes displayed in event thumbnails, the timecode relative to the source timecode is displayed and not a timecode zero based on time into the file.

Now if we are talking about low level, fundamentally accessing a specific frame within this XAVC MXF file, then ALL applications must translate source timecodes to zero based absolute frame counts. A video stream is just a sequence of frames 1,2,3 and so on. Any timing is computed from data taken from the file header(s) which may include a source timecode. I doubt we are talking about such low level use, but you never know.

I know what timecodes are and can be used for. I wish I would have synchronized GoPro timecodes. Vegas can use source timecodes to automatically line things up for me and I wish I could use that. It is a PITA to manually sync a bunch of these.

"Given many cameras, many audio sources, and many post-production steps you want an NLE to preserve timecode"

Getting to the topic of the workflow presented in the OP video.

They rendered a DPX image sequence which some parts were sent to vendors for effects.

In what way is the camera timecode of any use here?

We have just rendered a movie, from hundreds of camera files, cut however, and therefore have a new time reference. This being the movie time. So if I ask a vendor to do an effect from timecode 1000..1024, that would be relative to the movie time frame and not the specific camera time frame.

That is my view. Yours?

I still believe Vegas can to the NLE overview workflow presented. Edit from proxy, swap to RED, render DPX.
videoITguy wrote on 4/13/2014, 5:07 PM
Comments that are actually restricted to the OP's first post in this thread have as usual been few and far between. Most of the posts discussing timecode application that are appearing in this thread have absolutely nothing to do with the Original Post.

Topic on course of only the OP is not a strong point of this forum and probably will remain that way.

While you, NormanPCN, do suggest an NLE post process with Vegas based on time into file as a way to achieve collaboration with others - yes, that is true, but albeit a very restictive one, and not the way the industry as a whole handles post work.
NormanPCN wrote on 4/13/2014, 9:42 PM
I do not stipulate to the assertion that Vegas is based on time into file. It respects timecodes on input at least in the ways I have tested. I make no claims of a 100% test.

farss: "I wish it could and it hinges on just one thing that Vegas cannot do, render out video and preserve source timecode."

Vegas can preserve source timecode on render. Vegas certainly defaults to zero for a source timecode on render. I've only tested XAVC MXF files, but VMP said they had done the timeline thing with mpeg-2 MXF.

Would the steps to preserve source timecode qualify as a PITA? The fact that Vegas is scriptable and might help there.

It would be fascinating if anyone who knows could answer VMP's questions. Those questions were exactly mine at the time.

Specifically, the big one is if you have some NLE that really preserves source timecode in a render and you have the following
clip 1, a cross fade, clip 2.

In the rendered file does the timecode flip from the first clip to the second clip TC?
What is the TC during the cross fade?
Or
Is the TC of the render the TC of the first file on the timeline and everything after is consecutive from there.
OR
What?
paul_w wrote on 4/14/2014, 4:44 AM
Just jumping in here, haven't read all the posts.
"What is the TC during the cross fade?"

How can there be a cross fade? if all media is placed on the TL at their correct time code positions, there should never be a cross fade situation because all clips have their own time allocated. Start to End. The only way to make a cross fade would be to time shift a clip and that would break its timecode on render. It seems to me the only thing that gets rendered out is the timeline timecode start -> end, no gaps, no jumping. Just continuous.
If you wanted to transcode multiple clips and preserve their source timecodes, it seems to me you'd need a transcoder with batch rendering (maybe Production Assistant can do this with its batch render function) or write a script to do something similar to render out all the clips loaded on the TL.
Unless i missed the point!! :)

Paul.
videoITguy wrote on 4/14/2014, 5:29 AM
paul_w - in the old days of DV SD we had at hand several products that would transcode (make a render copy) of a DV file with timecode - alternately burned-in as well- which then preserved the timecode of the original.

When HDV and thus since other formats and containers like .mov have come on the scene - I only know of one product - dvmpro5 from the UK that can be used as a suitable timecode burned-in during the transcode process that will work on the VegasPro timeline.
paul_w wrote on 4/14/2014, 6:08 AM
Yes, its just while skimming through the thread, i see there are codecs in Vegas that will preserve timecode in the rendered output file. That is what lead to me think this can be done with scripting alone. Just needs a batch function. (and why i mentioned Production Assistant.)
I have to admit, i have never needed to use timecode before for any job (yet), so a bit out of my depth here really. I feel i may be about to learn something new from this thread.

Paul.
farss wrote on 4/14/2014, 6:38 AM
[I]"Any timing is computed from data taken from the file header(s) which may include a source timecode."[/I]

Certainly on videotape every frame carries timecode with it. I assume every frame in a video file is the same as they can also carry heaps of useful metadata such as all the lens parameters and they can change frame by frame.

[I]"Getting to the topic of the workflow presented in the OP video.

They rendered a DPX image sequence which some parts were sent to vendors for effects.

In what way is the camera timecode of any use here?"[/I]

Hugely useful. Someone gets the additional visual elements from a VFX house. Easiest way to line them up with what the camera recorded and ensure they stay where they belong is of their timecode matches the camera original. From what I've seen mostly there's a file or folder naming convention used as well which gives a good clue as to what goes with what. Remember multiple people from multiple companies work on these projects.

[I]"In the rendered file does the timecode flip from the first clip to the second clip TC?
What is the TC during the cross fade?"[/I]

Fades are handled by A and B roll. In any case Edit Decision Lists (EDL) only define cuts. Crossfades used to cost money, I think they were sort of considered Visual Effects. Even today you rarely see them in movies.

One used to be able to save a Vegas project as a comma delimited inliner text file.
I found this very useful and wrote my own VBA code to convert CMX EDL files into Vegas project files. The text version of a Vegas project file never contained timecode, just time into file as seconds to about 5 decimal places. I had to write functions that converted between time and timecode. Thankfully I was only handling PAL, NSTC Dropped Frame would have been a nightmare.

Back on topic I was discussing the video about how The Girl With The Dragon Tattoo was done with a FCP guy. Kind of funny in that he was protesting how it could have all been done in FCP! Who needs Ppro, AE and Clipster, right? Wrong, if you want a floating point pipeline :)

Bob.


rmack350 wrote on 4/14/2014, 11:34 AM
Correct me if I'm wrong, but I don't think the goal is to render a flat video file with the source clips' timecodes in it. Rather, the idea is to output an interchange file (XML for example) with source clip timecode in it so that the next application down the line can reference the right coordinates in all your media files and put them in the right spots on a timeline.

The key concept is reliable interchange. If you need to send something out for audio mixing or for color grading, or compositing, you may need to speak the timecode language of the system you're outputting for. It's bad to discover two years into a project that your NLE can't do something you'll need in order to finish it.

This is not a problem that's limited to Vegas, of course. I can remember meeting a design team from Adobe back in the CS1 or 2 period and we asked about timecode in DV media files. Blank stares. This was because adobe and everyone else was aiming for the consumer market. You could probably sell 10,000 licenses to consumers for every single license for professional users. Consumer cameras started every file or camera take at 00:00:00:00 so that's what programs like Premiere and Vegas supported. Adobe cleaned up their act a lot more quickly on this and I'd say that SCS has only gotten religion on it in the last couple of years. I do think SCS is making an effort on dealing with timecode, at least starting with Vegas12, but one release doesn't really constitute a trend.

I imagine the desire to have professional features in Vegas is a challenge to marketing and planning. 99% of the user base doesn't need high end capabilities "right now" but many users would like to feel like they *could* complete a big project. I think it's a good marketing strategy to have enough features to satisfy those very big jobs AND to have people talking about completing those big jobs on forums.

Rob

rmack350 wrote on 4/14/2014, 11:39 AM
Certainly on videotape every frame carries timecode with it. I assume every frame in a video file is the same as they can also carry heaps of useful metadata such as all the lens parameters and they can change frame by frame.

I've always been curious about where the timecode is in video files. I'm fairly sure that in *some* encodings it's just a starting timecode in the metadata with a frame count thereafter, but I'd hope that some encodings would maintain timecode for each frame, in addition to a frame count. I've never really found a reference that tells me what is actually going on in a file, though.

Rob
videoITguy wrote on 4/14/2014, 1:19 PM
Rmack350 - common in higher end consumer and as well prosumer cameras, the timecode is generated in the camera for every frame of video respectful of frame rate. Even better prosumer cameras can output the timecode itself thru a separate port.

For the media, be it AVCHD on memory card, or HDV videotape, the timecode is embedded in the file header for that medium of recording. You could extract it for VegasPro - one most notable plug-in , now discontinued, was SVDTS. But, this is at the camera original file, while the issue is that VegasPro cannot manage to export the timecode intact to another platform for uses like audio sync, color timing, etc.
VMP wrote on 4/14/2014, 1:34 PM
@ videoITguy For the media, be it AVCHD on memory card, or HDV videotape, the timecode is embedded in the file header for that medium of recording.

I've just checked the original '.m2ts' AVCHD file from my HXR NX5 with Media info. I don't see any timecode info listed. Just the audio video info.
I have selected the Text export function in media info. How can I view the TC?

VMP


VMP wrote on 4/14/2014, 1:51 PM
It seems this has been discussed before, including the HXR NX and its TC:

http://www.sonycreativesoftware.com/Forums/ShowMessage.asp?Forum=4&MessageID=730752RE: AVCHD Time Code --Resolve with Vegas 10.0[/link]


VMP
videoITguy wrote on 4/14/2014, 3:38 PM
SVDTS was a tool you could also use to expose timecode from AVCHD sources...

Subject: RE: AVCHD Time Code --Resolve with Vegas 10.0
Reply by: Chris N
Date: 10/11/2010 2:37:38 PM

So thanks to everyone that piped in on this thread, especially whoever it was that said that Vegas 10.0 might have support for AVCHD time code based on the new Sony AVCHD cams.

I first checked with DVMP Pro5 software and confirmed that my camera was outputting timecode, that Vegas Pro 9.0 could not read by itself..

I then upgraded to Sony Vegas Pro 10.0 and found that timecode is there and the clips are camera timecode (they don't start with 00:00) and they are not timeline timecode, when it is read at the media level.

As a note for anyone else that can't make this work please note that you have to import the entire file structure of the AVCHD "private" folder for Sony Vegas to be able to read the timecode, and you have to add the sony timecode media fx at the media not timeline level. I'm also assuming that renaming the mts file could mess up the time code, but I haven't tried that yet.

Well I'm glad this is fixed. I wish it could have been done a long time ago especially as I'd given up on it ever happening and no longer have the entire file structure for some of the older files that I'm still editing (thus the time code is gone)
rmack350 wrote on 4/14/2014, 4:43 PM
the timecode is generated in the camera for every frame of video respectful of frame rate. Even better prosumer cameras can output the timecode itself thru a separate port.

Yes, I am aware of that, at least for tape based media. The camera must generate TC for the entirety of the shot and for tape it must be recorded for each frame for a number of reasons: Playback head must read timecode at any point in the shot without going back to the head of the shot, and the next shot needs to pick up timecode from the previous shot, unless you're using free running TC or a time of day clock. And of course you need TC inputs and outputs to jam timecode from one device to another, like to a timecode slate.

That's tape. I'd love to see an authoritative resource describing how TC is recorded in files when you're tapeless. I imagine that it varies based on the file type and the encoder. Heck, DV25 timecode varied depending on whether it was Vegas or Premiere writing it (neither could read the other's timecode). It seems to me that files *could* go either way, or both ways. You could just have a starting timecode in the header or metadata and then just a frame count on the frames, or you could have actual imecode on the frame, or all of the above.

Could you clarify what you mean by "VegasPro cannot manage to export the timecode intact to another platform"? Do you mean exporting media timecode into an xml/omf/aaf/edl/etc file? Or do you mean copying the media timecode when transcoding media?

Rob
NormanPCN wrote on 4/14/2014, 9:15 PM
paul_w That is what lead to me think this can be done with scripting alone. Just needs a batch function. (and why i mentioned Production Assistant.)

The Vegasaur transcoder feature has a little checkbox to preserve timecode and file date/time among its many other features. This of course assumes the output file format supports a timecode, which they document, and that Vegas supports timecodes for that file. On that last part given the video I wondered what DPX files were, and rendered a few seconds as a test. Vegas does not output timecodes into DPX files. Mediainfo does not dump timecodes for those files either. I used ImageMagik to detect and dump the timecode information.

farss Hugely useful...

Thanks farss/Bob. Interesting info. Just enough without writing a book.

I think the FCP was only taking about getting the DPX output from FCP if it could do that. Not the whole chain. All NLE use, including PPro seemed to be gone after the DPX stuff was rendered.
farss wrote on 4/14/2014, 9:42 PM
rmack350 said:
[I]"Yes, I am aware of that, at least for tape based media. The camera must generate TC for the entirety of the shot and for tape it must be recorded for each frame for a number of reasons: Playback head must read timecode at any point in the shot without going back to the head of the shot, and the next shot needs to pick up timecode from the previous shot, unless you're using free running TC or a time of day clock. And of course you need TC inputs and outputs to jam timecode from one device to another, like to a timecode slate."[/I]

For those youngsters amongst us, the difference between DV and DVCAM was nothing primarily in the two formats timecode capabilities. I should also mention that back then people we doing things such a Insert Edits on tape. It sounds positively Byzantium today but it can be way faster than all the ingest > edit > render > PTT required today.

[I]"That's tape. I'd love to see an authoritative resource describing how TC is recorded in files when you're tapeless. I imagine that it varies based on the file type and the encoder."[/I]

I'm as much if not more in the dark here as you. All I've been going on is that cameras today do manage to record a lot of frame by frame metadata.

[I]"Could you clarify what you mean by "VegasPro cannot manage to export the timecode intact to another platform"? Do you mean exporting media timecode into an xml/omf/aaf/edl/etc file? Or do you mean copying the media timecode when transcoding media?"[/I]

The latter, the former can be achieved by 3rd party tools such as Automatic Duck. These cost money but if you're in an environment where you need this it's probable that you can afford the cost.

Bob.
paul_w wrote on 4/15/2014, 6:16 AM
Is there a list anywhere of Vegas codecs that can render out with timecodes?

Paul.
farss wrote on 4/15/2014, 6:24 AM
paul_w said:
[I]"I have to admit, i have never needed to use timecode before for any job (yet), so a bit out of my depth here really."[/I]

Where I've found it really useful is when I've sent something to a client for review.
If every frame has source filename and timecode for them to send back alongside their comments it's way more flexible than project timecode.

If I use project timecode then it only holds true if I don't cut or move anything around on the timeline.


Bob.
paul_w wrote on 4/15/2014, 7:01 AM
Yes, i can see the advantage of source timecode rather than timeline. Thanks for that.

How would a client typically view the media for comments etc? Are they viewing a complete rendered out file with various timecoded clips in it, or maybe just individual clips like dailies.. Just trying to get my head around the process.

Paul.
ushere wrote on 4/15/2014, 7:16 AM
i do this regularly with a number of clients by sending mp4's with burnt in tc of both source AND tl footage.

clients can make their decisions regarding tl and shot frame accurately - and i make suitable changes with ripple OFF till i've clean all the edits up.
farss wrote on 4/15/2014, 7:17 AM
[I]"How would a client typically view the media for comments etc? Are they viewing a complete rendered out file with various timecoded clips in it, or maybe just individual clips like dailies.. Just trying to get my head around the process."[/I]

Send them whatever works the best, generally put it all in one file with burnt in source TC and file name. It's a pity that Vegas's TC FX doesn't have the facility to include the file name.

I suspect V13 will make this much easier. Certainly Vegas needs to play catch up in this area, Adobe has been making this much easier for years with their cloud based collaborative tools and not just for video. Even M$'s Word has markup capabilities.

Bob.
paul_w wrote on 4/15/2014, 7:34 AM
And by the term 'burn in' we are talking info printed to the actual viewable image right? Viewable by any player for the client to make reference to.

So, would the best solution be something similar to the Sony TC FX but with, as you say, filename burnt in too and if that timecode displayed was the 'clip source' TC not the timeline version. Hmm, did i get that right?
So during a client playback, they would see timecodes changing from clip to clip depending on what edits you have done.
Sorry if this is taking the thread away here.. Appreciate it.

Paul.
paul_w wrote on 4/15/2014, 7:43 AM
Ah, Ushere, just read your post and this seems to be what you are doing. Burning in both Source TC and timeline TC. Interested to know how you burn in the Source TC.
Thanks

[edit] nevermind, found it Scripting->Add Timecode to All Media.

Paul.
NormanPCN wrote on 4/15/2014, 1:16 PM
One thing to remember about Sony Timecode effect. The help documentation is incomplete/wrong.

...as Media Fx, you get the source timecode.
...as Track Fx, you get the timeline timecode.
...as Event Fx, you get the event timecode (zero based from start of event).