Another "poor RT" thread

[antonsvideo]

is the HQ clip 1440x1080i? if so, is the project also set to 1440x1080i and is the rendering format set to canopusHQ

my tsakmanager shows Edius using 225mb while sitting idle with no clips loaded

I also use 128mb for hardware and OHCI

does anything improve if you set hardware to 256 or higher?

[PaulTV]

clips are 1440 1080 50i as is the project - if I change the hardware or OHCI there is no change in behaviour.

I also had a situation with 4.61 which caused slow down of the gui if I had more than 5 sequences open at once, now its down to 2 with V5, I can only really edit with one sequence open now.

Also, I keep rendering sections to playback OK in realtime, and they won't, unless I switch off the video track underneath as though there's transparency on, which there isn't..

This is making me crazy as I've a project to get out today - no hope at all.

This is deranged - my rendered clip appears on the timeline after render, it won't playback in realtime, move it elsewhere on the timeline it plays - put it back where it should be and it stalls, unless I switch off the tracks underneath - it behaves as though transparency is on for sure..

Paul

[PaulTV]

OK, I've found a repeatable oddity - I have motion Blur on two timelapse clips on track 1 with a colour balance filter as well - shift Q render to timeline - render appears on track 2 - playback is crabby.

Turn off the motion blur on track 1 - playback is good.

So track 2 can see the motion blur filter on track 1 below it - is this right??

Paul

[Khoi Pham]

OK, I've found a repeatable oddity - I have motion Blur on two timelapse clips on track 1 with a colour balance filter as well - shift Q render to timeline - render appears on track 2 - playback is crabby.

Turn off the motion blur on track 1 - playback is good.

So track 2 can see the motion blur filter on track 1 below it - is this right??

Paul

It has always been like this since I started to use Edius in version 3, doesn't make sense to me but they said that is the way it is, after you shift Q it, you still need to "hide" lower layers or it will take away your RT.

[PaulTV]

never had that one happen to me before - how odd - needs fixin eh?

Paul

gonna get a new dual quad core monster - can't deal with this any longer -

[Martin_Gleeson]

It has always been like this since I started to use Edius in version 3, doesn't make sense to me but they said that is the way it is, after you shift Q it, you still need to "hide" lower layers or it will take away your RT.

Unless you are speaking about motion blur specifically, then this was never the cae. When I have tracks (such as multiple PiP or Vitascene transitions) which will not play in realtime, I simply Shift-Q rendering In-Out and the newly rendered file plays fine - regardless of whether the track below is enabled or not. If I needed to disable the lower track, then this would be a bug, pure and simple!


Cheers
Martin

[PaulTV]

It would appear that this applies only to motion blur - try it - very funny indeed!!

Paul

[GrassValley_BH]

Just a reminder to put things into perspective. A major version is a bit of a reset. While we generally won't intentionally slow things down, there are changes that can cause things to perform more slowly. For example, handling more transparency equals having to deal with more data. More data = more work = less real-time

We usually try to err on the side of quality over speed, but of course we always aim for speed.

[PaulTV]

To bring this one back: I've put 4.6 back on a laptop and it does not display this "see thru to lower tracks" behaviour - so I'd say that it is a bug. If I ever shift Q and make a rendered track above the "heavy" layers, I've never had to switch anything off to make it play. The tracks below are simply hidden. This is not the case with V5 - it sees through the layers and creates poor RT.

I have the same project on V5 and V4.6 and the playback results are different.

Can someone from GV let me know if this is a known bug?


Paul

[PaulTV]

So now I think I know what it is - the rendered files from 4.61 are "see thru" by version 5, if I re-render a new shiftQ in V5 it works correctly, so there is a difference between 4.6 rendered files in HQ and V5.

Paul