When I choose “mov” option instead of stream or image sequence, I see only a static frame. Is anyone else having this issue?
I noticed this in the release notes from Build #2019.09.032 - September 25, 2019:
Fixed bugs
[Media representation] For a file sequence version not beginning by frame 1, when you open Create to show the “Movie” source path of that version, you will see repeated frames. [VMR-2558]
But I’m on the latest SG create version and it still doesn’t work for me. Any ideas?
I assume you are using the Create version that was released 2 days ago (Oct 29th).
Are the first-frame/last-frame/frame-count fields properly set in the Version?
Was this version created by Create or the web-app?
Just in case you’re using a version from before tuesday’s release : In compare mode, there was a bug that causing this exact problem (repeated frames). It has been fixed.
[Player] Media representation option is not properly applied in Compare mode. [VMR-2677]
It seems like it has something to do with the frame range. I published two versions, one starting at frame 1, and one on frame 1001.
The one on frame 1 worked perfectly but the one starting at frame 1001 just showed me a static frame. It’s the same entity and all, even done from the same scene in Maya.
The Create Player will honor the timecodes of media sources. Could you validate that the movie file is properly tagged with the right metadata (ie.: start time, frame rate, duration, etc.) so that it matches the data in SG. Given your screenshot, the Player will consume frames 1001 to 1064, in 24.000FPS. This is equivalent to ~41.71 seconds up to 44.33 seconds.
If for instance, the movie file is tagged with a start frame of 1001 but an FPS of 60, the first frame will be seen as 1001/60=16.68 seconds up to 1064/60=17.73 seconds. In this case, you would probably see the last frame repeated all along.
How does Create handle slate frames? We usually have a slate frame in the beginning of our movs, but our frames does not. Does Create respect the “movie has slate” field like RV does?
I’m curious how other people are dealing with this? I’ve tried to publish from Nuke using the default config and review submit tool, and also RVs submission tool and none of these seems to work for me in Shotgun Create, in regards of playing the movie. As I mentioned before, we’re using our own tool to publish versions, but even the tools provided by Shotgun does not seem to work for me.
Just to clarify, the SG fields “First Frame”, “Last Frame”, “Frame count”, as well as the “Frame Rate” is specifying the temporal window on the media you wish to playback. If the source frame range and rate is specified in the media file (as it usually is for movie file), the player will honour these in order to determine the actual frames to playback (as well as in what frame rate), repeating source frame is needed.
We usually try to store the original timecode from editorial in our .movs that we generate. So by doing this, it’s not possible to playback the movie files in Create? I think that is the issue that I’m running into.
Storing the original timecode from editorial in the .movs is supported and even recommended. However they need to match the SG fields “First Frame”, “Last Frame”, “Frame count” and “Frame rate”. As mentioned before, these fields specifies the source timecode window to playback.
Oh, so for a shot where the timecode starts at 10:10:50:18, at 24 fps, my “First frame” field of that version would need to be 879618?
If that’s the case then I don’t think that’s going to work for us. The timecode is just for editorial/conform references, all artists just refers to our frame count, which starts at 1001, unless we have offsets in editorial.
Any chance Create will work (in future updates) similar to RV in this matter? Because in RV we are not having these issues.
TX for explaining your workflow. So if I understand well, you use the SG “First Frame” field to overwrite the media source time so that any media starts in the timeline UI at 1001 instead of the actual media timecode. Am I understanding well?
SG-Create is honouring the media source range (timecode) in order to deal seamlessly with the multiple representations of the media (file sequence, movie and streaming) of potentially different frame range. This allows to switch between the EXR, MOV and MP4 (streaming) representation and ensure that the annotation falls on the proper frames regardless of the representation used. This also ensures the right frames are in sync when comparing 2 different versions with different source start time.
All this to say that interpreting the “First Frame” SG field to overwrite the media first frame might be difficult in the context of multiple representation support.
I will bring back to the engineering team your workflow around the use of the SG “First Frame” field to see if we can find any workaround.
Note that if you do not set the “First Frame” field in SG, SG-Create will infer the “First Frame” from the media first frame (timecode) metadata. But this would not really help you since, even if now the media will not show any more static frames, the clip will start in SG-Create timeline UI at frame 879618.
RV is honouring the media first frame (timecode) metadata. Loading your clip in RV and you should have the RV timeline starting at frame 879618. The particularity with RV is that it honours “partially” the SG “First Frame” field. If larger than the actual media first frame, it will adjust the window on the media accordingly (as in SG-Create). If smaller, it will not. Instead it simply slips the clip to the specified “First Frame”… which is the behaviour you are looking for if I understand right.
Sorry for the long wordy reply… Hoping that it clarifies a bit the situation.
To explain further how we work:
All VFX shots are conformed to start at frame 1001 at first, it’s our base start frame. If a shot is extended in the beginning of the shot, it can change to start at 950 instead, for example. This simplifies it a lot for the artists, not needing to have crazy frame ranges as we would have if we were working on the actual timecode frames. But the timecode is still important for later use if we’re sending stuff back to editorial for example. So a typical Nuke publish would look like this:
The comp rendered as exr image sequence:
Starts at frame 1001, with original timecode intact in the metadata.
A proxy .mov based on the same exrs generated for upload to SG
This one will have the timecode intact, the same timecode as the exrs
This proxy also has a slate, but that’s another issue I guess, but worth mentioning. Since Create does not care about slate frames like RV does, we would have a one frame offset here.
Fields in Shotgun
In Shotgun the “First Frame” field is set to the same as the comp, 1001 in most cases
What would be the proposed workflow instead?
Would that be to always use the timecode as Frame Range instead of us “making up” our own using 1001? I can confirm that I got this to work, by only using timecode, in exrs, mov, and Shotgun fields.
Yes, the way RV behaves is definitely how we would prefer it would work.
How are your exrs named… xxx.1001.exr or xxx. 879618.exr? They are named xxx.1001.exr
Do the exrs, mov and uploaded movie always match in terms for first frame, count and rate? Frame rate and count, the .mov has a slate frame before the shot starts, so it’s one frame longer. But this is another issue, I guess that it would be a new feature request.
The FPS, yes, the input/frame_rate tag in the exr metadata is the same fps as in the mov, and in Shotgun.
It seems like Create will use the EXR file name to infer timing values. In your case, that is what you want, but if we were to consider this a bug and switch to considering the EXR metadata (timecode), you would get the same issue with EXR as the one you get with MOV.
I just wanted to highlight this, to make it clear that this is not a MOV specific issue.
Just a quick message to say that we are actively working on how to support your scenario of decoupling source timecode from timeline source range. We don’t have yet a perfect solution, which need to be at the same time backward compatible and future proof, but will keep you post as soon as we’re converging.
