Multiclip performance question

[Andy]

Hi all you knowledge ridden folks ;)

Had occasion today to do a 3 camera multiclip cut on a fully configured Edius HD Edit Station, running version 4.24. Timeline was set to 1080i Canopus HQ, source firmat was raw 2x XDCAM HD (35 Mbps) MXF plus 1x HDV.

Basically, the system couldn't handle the 3 streams... in fact ! went down to 2 streams and it died on that too ... hmmm. The files are not high data rate, the V drive was a full on HUGE Sytems UltraSCSI RAID array.

Can't understand why it choked. Any and all thoughts and feedback very welcome.

Cheers
Andy

[Khoi Pham]

Hi all you knowledge ridden folks ;)

Had occasion today to do a 3 camera multiclip cut on a fully configured Edius HD Edit Station, running version 4.24. Timeline was set to 1080i Canopus HQ, source firmat was raw 2x XDCAM HD (35 Mbps) MXF plus 1x HDV.

Basically, the system couldn't handle the 3 streams... in fact ! went down to 2 streams and it died on that too ... hmmm. The files are not high data rate, the V drive was a full on HUGE Sytems UltraSCSI RAID array.

Can't understand why it choked. Any and all thoughts and feedback very welcome.

Cheers
Andy

You need to captured your clips as HQ, using native format will not give you good RT performance because it as to decompressed. HQ will required larger file but they are not as compressed so it will give you much better RT performance.

[GrassValley_KH]

Khoi's right - your bottleneck isn't the disk throughput - it's the task of decompressing the XDCAM footage.

By the way, while I have not tested the "before/after" results with XDCAM, it's entirely possible that playback optimisations have worked their way into 4.5x. This is something that is an ongoing project within our dev team - improving native stream playback of all the different formats we support.

[Jerry]

Khoi's right - your bottleneck isn't the disk throughput - it's the task of decompressing the XDCAM footage.

By the way, while I have not tested the "before/after" results with XDCAM, it's entirely possible that playback optimisations have worked their way into 4.5x. This is something that is an ongoing project within our dev team - improving native stream playback of all the different formats we support.

That would be nice for Quicktime files, and especially the color issue.

[GrassValley_KH]

That one is a little harder, since we don't have a native file handler for QT. I'm not sure we ever will...the impression I get is that that's an Apple licenscing thing.

[Andy]

You need to captured your clips as HQ, using native format will not give you good RT performance because it as to decompressed. HQ will required larger file but they are not as compressed so it will give you much better RT performance.

cheers Khoi, this is just common sense, but your quick feedback was very much appreciated nonetheless.

for what its worth, when working with tapeless formats the whole point however is NOT to capture, just to import.

what I ws hoping was that someone was going to jump up and tell me that I should have flushed my flux capacitor setting and rejigged the doohickey and all would have been well ;)

had we not been up against the clock with this show I would have captured via HD-SDI to Canopus HQ as per normal. as it was we were still able to limp ... even with the zero performance issue it was faster than capturing to HQ, which would have taken around 3 hours where as ingesting the native MXF took about 45 minutes, as a background process, and we were able to continue to work whilst all that was going on.

bit dissapointing though, would have expected better than single stream decompression performance.

[GrassValley_KH]

Shake your fists at Intel/AMD - not us. :)

It's a fact of life that as long as there is bleeding-edge video format compression, there will be a place for intermediate codecs.

Native format editing exists for the quick ingest, quick cuts editing. The craft editing will almost certainly require extra time - either to convert footage, or forfiet your realtime playback performance.

DV editing has spoiled us so.

[Khoi Pham]

cheers Khoi, this is just common sense, but your quick feedback was very much appreciated nonetheless.

for what its worth, when working with tapeless formats the whole point however is NOT to capture, just to import.

what I ws hoping was that someone was going to jump up and tell me that I should have flushed my flux capacitor setting and rejigged the doohickey and all would have been well ;)

had we not been up against the clock with this show I would have captured via HD-SDI to Canopus HQ as per normal. as it was we were still able to limp ... even with the zero performance issue it was faster than capturing to HQ, which would have taken around 3 hours where as ingesting the native MXF took about 45 minutes, as a background process, and we were able to continue to work whilst all that was going on.

bit dissapointing though, would have expected better than single stream decompression performance.

Well have you try switching your project to DV and do multicam editing in that mode and see if you could have better RT performance and then switch back to HD? I could get more rt fx but don't know about more streams.

[Andy]

Shake your fists at Intel/AMD - not us. :)

consider them duly shaken at :)

have you try switching your project to DV and do multicam editing in that mode and see if you could have better RT performance and then switch back to HD?

thats some good lateral thinking right there. thanks Khio Pham, I'll give that a try and let you know how it goes. any workaround is a good workaround if it works!
theres bound to be a next time (and in fact the next time is next week as it happens, with a 3 camera OB shoot coming headlong to me from the Thai/Myanmar border ... and again we'll have minimal time -about 4 hours - to turn the show around from footage arriving at the airport to programme on air .. all fun and games!)

[Andy]

what I ws hoping was that someone was going to jump up and tell me that I should have flushed my flux capacitor setting and rejigged the doohickey and all would have been well ;)

Thanks to KP's lateral thinking I revisited the issue to see what I could find out, and whilst poking about I discovered the not so hidden "Skipped Frames" setting, which seems to be the doohickey key I was looking for. By bumping this setting from "None" to "5 frames" I was able to get satisfactory playback performance with 3 streams.

Well have you try switching your project to DV and do multicam editing in that mode and see if you could have better RT performance and then switch back to HD? I could get more rt fx but don't know about more streams.

KP's advice also worked a treat (thanks KP). By changing the project setting to DV I was able to further improve performance with the same 3 streams, letting me reduce the skipped frames setting to only 3 Frames whilst maintaing satisfactory playback.


Thanks guys.
Andy