Glenn

cine file timecode

Recommended Posts

Hi.  

Relatively new resolve user here.  
Had a .cine job the other day and it looked to me like resolve was not reading the code off the .cine files correctly. 
I did a couple searches and I saw some threads from years back about there being some issues with this but nothing really recent. 
Still an issue?

I tried switching the raw file settings for cine in resolve prefs but nothing changed as far as the way the code was being read. 

Baselight and Phantom Cine Player read the code the same and that matches what was on the client edl. 

Ended up just changing the code for each shot in the resolve media pool to match the way the code is read by baselight and that worked. 

running 17.2.1 

Any other work arounds?

Thanks



 

Link to comment
Share on other sites
On 11/3/2021 at 2:38 PM, Glenn said:

Had a .cine job the other day and it looked to me like resolve was not reading the code off the .cine files correctly. 
I did a couple searches and I saw some threads from years back about there being some issues with this but nothing really recent. 
Still an issue ?

I tried switching the raw file settings for cine in resolve prefs but nothing changed as far as the way the code was being read. 

Baselight and Phantom Cine Player read the code the same and that matches what was on the client edl. 

Ended up just changing the code for each shot in the resolve media pool to match the way the code is read by baselight and that worked. 

 Hi Glenn,  I'm not a killer colorist but I have a bit of experience with .cine files as I 'm a lucky Phantom owner.

What exactly do you mean by reading the code ? Getting correct metadata ?

From what I understand, I assume you've tried to change global cine settings in the raw tab settings, but it didn't change a thing, while switching individual clip to custom settings does work. 

The only case I know these settings will be ignored is when using the DVR color managed mode. Is this your case here ?

From what I think I've understood by myself,  when Resolve is set to color managed mode, linear raw data is automatically mapped into your actual colourspace, bypassing the classic raw tab with specific phantom options, notably the transfer curve selection (rec709, log1 & log2 curves).

While I was trying to set a pipe to color grade .cine files in an HLG colourspace, I've noticed that when color management is ON, the result is quite different to any available curve you can get when in unmanaged mode. And I definitely prefer the rendition I get from the unmanaged mode, with the classic raw tab tools. This color science was probably provided by Vision Research at first, when I suspect the  curve being applied by Resolve in managed mode being developed by Blackmagic...

 

In the case you're in unmanaged mode, then this is an issue, as it has always worked well in any actual or previous Resolve versions...

 

 

 

Link to comment
Share on other sites

Thank you for the response David.  
I didnt do such a hot job explaining.  Sorry. 

This is all about timecode and conforming.   I'm supplied an XML and ref pic from the editorial company.   When I try to conform my spot with that xml and ref pic- no files link on resolve. .   It seems to me that the resolve does not "read" (for lack of a better word) the timecode correctly off my cine files. 

As an example file 4662_P5_8
when that file is dropped in resolve the start timecode on it is 19:45:22:02
Same file on baselight and phantom cine player the timecode on that file is 23:45:22:02
And that 23:45:22:02 is the code that is in the clients XML. 
So its a bit of a hassle to conform these spots on resolve. 

So I was just trying to figure out why resolve reads the timecode on that file differently than its read on cine player and baselight. 

Thanks. 

 

Link to comment
Share on other sites
(edited)

I'm also sorry for the confusion...

TC is a complex matter with hispeed files. SMPTE TC is derivated from a realtime timestamp, but does not really exists as such inside the metadata. Still, the SMPTE being generated on the fly is supposed to be same no matter what software is used. 

I had a quick check, here is what I've found so far :

• Resolve shows TC related to the inner timestamp (expected behavior)

• Silverstack shows also same TC as Resolve.

• PCC (Vision Research windows app) DOES NOT show the same TC as Resolve, and this TC is unrelated to actual realtime timestamp.

So, as weird as it seems, I'd say correct TC in the Resolve one, while PCC (and so phantom player) won't...

 

That being said, it's of no help for your actual issue...

 

Btw, did you notice a constant offset between those TCs ?

 

Edited by David Coiffier
Link to comment
Share on other sites
(edited)

David thank you very much for that info.  Very interesting,  particularly that nots on the PCC software.  

In the past I have seen definite constant offsets.  3hrs comes to mind.  But not with this lates job we had.   This one was all kind of random. 

And so it appears that resolve was not the system used to generate the transcodes that the editor used.   

Our solution going forward is going to be to not only get the raw cine files but the transcodes used.  This way in resolve we can assing the code from those transcodes to the cine so we can use the client xml to conform the spots.  

Not the greatest solution but it works.

Thanks again!



 

Edited by Glenn
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.