5 Replies Latest reply on Oct 21, 2010 5:23 AM by Colin Brougham

    No DV stream out when mercury playback \ CUDA enabled

    wfmc01

      Hello friends. Having some issues with a new CS5 install. We are still using Premiere CS5 for DV editing with Sony DSR 11s. Normally we can can use a NTSC monitor for realtime previews during editing by using firewire out to the DSR 11, then analog out from the DSR 11 to the NTSC Monitor. Pretty standard DV editing set up. However after I applied the "CUDA hack" to get premire to recognize the GTX 480 as a supported card, premiere would no longer send out a DV stream to the DSR 11 while editing. It does seem however to be able to control, preview and capture DV from the Deck.  DV stream comes back if I reverse the CUDA hack.

       

      What I expected was mercury playback engine, accelerated encoding, and a realtime NTSC monitor via firewire.

       

      Is this a common issue?

       

       

      MSI X58 PRO-E INTEL X58

      12GB memory

      GTX 480

      Windows 7 Pro 64bit

      Sony DSR 11 DV deck

        • 1. Re: No DV stream out when mercury playback \ CUDA enabled
          Colin Brougham Level 6
          What I expected was mercury playback engine, accelerated encoding, and a realtime NTSC monitor via firewire.

           

          Is this a common issue?

           

          As we all did, but it just ain't the case. It's known and acknowledged, but there is no ETA on a fix. In the meantime, you don't have to disable the hack, but just turn off GPU acceleration in the Project Settings; you'll regain DV output.

           

          Also, just a semantic issue, but MPE doesn't accelerate encoding; it accelerates playback of certain effects and other activities like scaling and colorspace conversions. With hardware MPE, encoding of video elements that contain these effects will be faster in the sense that the GPU is handling the rendering, but the actual encoding still falls on the CPU's shoulders.

          • 2. Re: No DV stream out when mercury playback \ CUDA enabled
            wfmc01 Level 1

            Thank you so much.

             

            I manage this system for a lot of cable access users with different levels of "expertise" on project and file management. I would likely not enable MPE\CUDA if it is something that will vex a novice user.

             

            And I thought encoding(export) was speed up by CUDA.... perhaps that's limited to H264? We primarily output to mpeg2.

            • 3. Re: No DV stream out when mercury playback \ CUDA enabled
              Colin Brougham Level 6
              I manage this system for a lot of cable access users with different levels of "expertise" on project and file management. I would likely not enable MPE\CUDA if it is something that will vex a novice user.

               

              I can appreciate that--worked in cable access for several years, myself. Let's be diplomatic and just say that you never quite know what you're going to get Removing any potential stumbling blocks will save much frustration, at least until the bugs get ironed out.

               

              And I thought encoding(export) was speed up by CUDA.... perhaps that's limited to H264? We primarily output to mpeg2.

               

              Well, in a manner, it sort of is, but it really isn't...

               

              In an export from a Premiere Pro sequence, you basically have two processes going on: rendering and exporting. Rendering is compositing together the various video layers and creating an intermediate video source; exporting is taking that intermediate video source and recompressing it to a final destination video format. With GPU acceleration, the GPU is handling some or all of that rendering process, and then passing those frames to the CPU for compression to the export format. Without the GPU, the CPU is doing double-duty, rendering the frames but then also having to turn around and compress them. The export component of that process itself doesn't take any longer, but the total amount of time required to export a video is usually longer without the GPU than with it. However, this involves using effects that are written to take advantage of the hardware acceleration; if the effect is of the non-accelerated variety, regardless of the GPU acceleration being on or off, the rendering is done by the CPU instead of the GPU.

               

              Look at it this way: exporting a sequence with no effects on it is going to take about the same amount of time to export with GPU acceleration as it will without it. In this case, there is nothing for the GPU to do, so it's all about the CPU in this case. It's not until you add effects or perform certain transformations that you'll see the added speed-up benefit of the GPU acceleration.

               

              Hope that helps...

              1 person found this helpful
              • 4. Re: No DV stream out when mercury playback \ CUDA enabled
                Harm Millaard Level 7

                Colin,

                 

                To add to your remark, if there is scaling involved in the export, like AVCHD exported to MPEG2-DVD, that is done by the GPU, so even if there are no effects of transitions, there is a huge benefit from the GPU assisted scaling with MPE on. Additionally the scaling algorithm is of much better quality than with software MPE only, unless MRQ is turned on.

                • 5. Re: No DV stream out when mercury playback \ CUDA enabled
                  Colin Brougham Level 6

                  Thanks for adding that, Harm--I had mentioned that in my initial reply but hadn't added the more detail in the later reply. Good point.

                   

                  The upshot of all this is that, if you're not doing anything to alter the video beyond simple editing, hardware MPE offers no increase in either performance during playback or perceived performance during encoding. If you give something for hardware MPE to do, the speed increase is noticeable when compared to software MPE; it's the quality issues that I'm concerned with right now