Announcement

Collapse
No announcement yet.

Multiclip performance question

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Multiclip performance question

    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

  • #2
    Originally posted by Andy View Post
    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.
    I7-6900K, X99 Taichi, Geforce GTX 1070, Corsair RM850X, Corsair H100 IV2, Windows 10, Edius WG 9.30

    Comment


    • #3
      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.

      Comment


      • #4
        Originally posted by GrassValley_KH View Post
        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.
        Jerry
        Six Gill DV
        www.sgdvtutorials.com
        If you own the Tutorials and you need help, PM me.

        Vistitle YouTube Channel
        https://www.youtube.com/channel/UCMVlxC8Am4qFbkXJRoPAnMQ/videos

        Windows 10 Pro up to v.1803 Tweaks for Edius Users
        http://sgdvtutorials.com/WIN%2010%20...%20V.2.0.0.pdf


        Main System:: Azrock Z97 Extreme 6, [email protected], 32gb ram, Corsair H110, Win10 Pro 64, Samsung 850 pro, E7.5/8.5/E9 on separate SSD drives, HD Spark, Intensity Shuttle, 12tb RAID 0 on backplane ,2 BD, Benq 27 and Hanns-G 28 monitors, CC 2019, GTX 1080ti SC Black.
        Second System: EditHD Ultimax-i7, X58, [email protected], Corsair H80, Win764, 24gb ram, Storm 3g, Samsung 840 Pro 256, 4tb and 6tb RAID 0 on backplane, GTX 980ti Classified, Edius 9, Apple 30", Samsung 24", dual BD.

        Comment


        • #5
          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.

          Comment


          • #6
            Originally posted by Khoi Pham View Post
            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.

            Comment


            • #7
              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.

              Comment


              • #8
                Originally posted by Andy View Post
                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.
                I7-6900K, X99 Taichi, Geforce GTX 1070, Corsair RM850X, Corsair H100 IV2, Windows 10, Edius WG 9.30

                Comment


                • #9
                  Originally posted by GrassValley_KH View Post
                  Shake your fists at Intel/AMD - not us. :)
                  consider them duly shaken at :)


                  Originally posted by Khoi Pham View Post
                  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!)
                  Last edited by Andy; 09-28-2007, 05:35 PM.

                  Comment


                  • #10
                    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.


                    Originally posted by Khoi Pham View Post
                    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

                    Comment

                    Working...
                    X