I've worked on two project recently where time-remapping a clip causes oddities with other clips on the same timeline. For example, I have successfully time-remapped a clip to my desire.
The first oddity I notice is that the clip must remain visually much longer on the timeline than it actually displays info... I've seen this in two different projects... you speed up a clip, for example, so it ends earlier, yet the clip length must remain longer... if you cut it, the time remapping gets messed up.
The above issue is not a big deal because I just don't cut the clip... it's the typical quirky viable workaround. But then...
Today, I'm remapping a clip which contains a photo montage, largely PSD files. It looks great, but as I soon as I start adding the next scene (another clip) on a track above or below the time-remapped photo montage clip, parts of the time-remapped photo montage are blacked out. Two things on this: a) The issue goes away if I disable the newly added track (i.e.,clicking eye icon as shown in screenshot below), and b) the location (in time) of interference of the time-remapped track by the newly added clip seems dependent on where the newly added clip is placed on the timeline (even though that newly added clip is nowhere near the point of interference).
In the below, V9 is causing the point in V8 shown with the time indicator to be black. If I disable V9, that part of V8 becomes visible. If I move V8 further down, it will let that part off V8 be visible. Something else.. the location of V9 is important in that it provides a transition from the montage to the next part... and I need to place V9 further down on the track than the actual end of V8 for that to work... so this all smells of some buggy time skew issues caused by remapping not being accounted for in a manner which messing with timeline visuals and behavior. ... either that or I'm missing something here. 
The experience outlined in the latter paragraph seems to clearly indicate some bug in Premiere timeline/track handling of time-remapping and the visual representation of time, and how tracks interact.
It would be great to hear if anyone has a workaround... the only one that comes to mind, since nesting the time-remapped clip doesn't help, is to render the time-remapping... which I'd like to avoid if possible.
Any thoughts?
I'll file a bug if it seems I'm not doing something wrong here.
1 Correct answer
Workaround is to take time-remapped clip and nest it. The outer clip hosting the nest is not affected by this bug! 
7
Replies
The following new info may be helpful as part of a bug report... I rendered the photo montage which is nested, the outer sequence hosting the nest is the one which is time-remapped (and it's on the main timeline where I was seeing the above issues). After rendering the nested photo montage, the issue goes away. I can even clip the time-remapped clip at its opacity 0% endpoint.
This seems to indicate that time-remapping a sequence which has within it or within its nests some Photoshop PSDs (at the very least, if not other types off images), time skew and other anomalies may arise (or do arise 
).
Seemingly connected with the earlier posts, the following is another time-remapping anomaly...
Opacity is effectively 0% (meaning item is now invisible/gone/transparent) at the time indicator location in the following screenshot, which is prior to any opacity keyframes and notice opacity is 100%....
... when the timeline indicator enters into the range of the two opacity keyframes (typical 100% to 0% keyframes), the opacity value actually starts to diminish (even though the actual footage is already effectively at 0% per above)....
This is consistent with my earlier findings... time-remapping is affecting scaling of when the opacity keyframes are encountered, but such is not reflected in the user interface (UI). There seems to be a bug not so much with time-remapping but with how the UI maintains proper scaling to the true internals of time-remapping. It's as if whatever code interacts with the UI to do this is using the older figures/math to calculate time as if not affected by time remapping when in fact time remapping is in effect. Something like that. The time-remapping is working, so perhaps itself not buggy, but the UI isn't reflecting things which is a bear for the person editing.
I'm filing a bug.
Okay, this is easy to reproduce... just made a simple project I'll send with a bug report. Basically, here's what I did:
- Create 23.9 fps clip (not sure if fps or sequence type matters).
- Place h.264 mp4 on first track (not sure if footage type matters).
- Change to Show time-remapping keyframes on clip.
- At about 50% into the clip (doesn't matter but just makes the example clear/easy), add a time-remapping keyframe,
- To the left of that time-remapping keyframe, raise the time-remapping time bar higher up to like 350% or higher.
- In Effect Controls, place opacity keyframes going from 100% to 0% after the time-remapping.
- You will see Opacity transition takes place prior to the time-remapping keyframe which is well-before the opacity keyframes.
Below is an example screenshot... the first marker is where Opacity takes effect, the second marker is where Opacity keyframes are located. The Opacity change should not take effect until the keyframes are encountered.
Test recommendations: Have a test(s) which adjusts a clip using time remapping and verifies that keyframes both before and after take visual effect where the keyframes are located, and not elsewhere. This should catch a bug like this automatically before the product leaves the house.
Workaround is to take time-remapped clip and nest it. The outer clip hosting the nest is not affected by this bug! 
AdChoices