Creative Communities of the World Forums

The peer to peer support community for media production professionals.

Activity Forums VEGAS Pro Dropped/Black frames during rendering [PARTIALLY SOLVED]

  • Dropped/Black frames during rendering [PARTIALLY SOLVED]

    Posted by Kevin Bugay on January 25, 2014 at 12:28 am

    I’ve scoured the net for advice on the black frames problem in Sony Vegas 12. I’ve tried everything suggested, and even found a way to reliably reproduce the problem in a single video. First, my specs:

    Vegas Pro 12.0 (Build 770) 64-bit
    Windows 7 Ultimate 64-bit SP1
    Intel i7-2630QM @ 2GHz
    GeForce GTx 560M
    8GB RAM

    Next, one of the videos in question (714 MB): https://www.mediafire.com/watch/pn22zdgccd3t0au/CoP%201%201%203%20-M.avi

    The “trouble spot” is at precisely 00:29, with a lot of water particles moving across the screen. The bitrate climbs to around 166 Mb/s here. If you do a loop render from 00:24 to 00:32 you can do it quicker.

    The sample video was recorded using Mirillis Action!, which uses an FICV codec. Notably, Handbrake cannot open the video. In order to open this file in Sony Vegas, you must have the Action! codec. I have successfully edited, rendered, and uploaded over 9 hours of footage using this setup, though I had to redo some renders due to black screens. However, this video will reliably not render correctly except under very specific circumstances.

    Things I have tried:

  • Restarting the program before every render
  • Setting Vegas Pro 12.0 to High priority in Task Manager
  • Disabling my antivirus software
  • Unchecking “Close media files when not the active application”
  • Unchecking “Close audio and MIDI ports when not the active application”
  • Setting Dynamic RAM Preview max to 0, 128, 512, and 2048 MB
  • Setting maximum number of rendering threads to 1, 2, and 3
  • Turning GPU acceleration of video processing on and off
  • Rendering with Sony AVC/MVC using CUDA
  • Rendering with Sony AVC/MVC using CPU only
  • Rendering with MainConcept AVC using CUDA
  • Rendering with MainConcept AVC using CPU only
  • Rendering with MainConcept AVC at 720p instead of 1080p
  • Rendering with MainConcept AVC with a constant bitrate rather than variable
  • Rendering with MainConcept AVC with a much lower bitrate than desired
  • Things which work:

  • Previewing the “trouble spot” in Sony Vegas before rendering
  • From this I infer that the video is simply too large for my hard drive to dump into memory before the render process gets to the trouble spot. Therefore, I can only see two solutions to this problem:

  • Batch-convert every raw file to a lower bitrate before attempting to render in Vegas
  • Find a magical option/script which pauses renders until the video is loaded into memory
  • Any help on this would be greatly appreciated. I don’t relish the idea of dragging the timeline cursor all over my project before each render, then finding out I missed trouble spots after all in the final product.

    Edit: Partially solved. It turns out I’ve been editing with the raw video captures this whole time, and I was not aware that Action! came with an exporting feature. The problem video was exported at the top setting, 23.86 Mbps (I’m assuming that’s megabytes, not megabits), filesize dropped from 714 to 255 MBs, and 5 out of 5 test renders worked fine.

    There is still a general problem with being unable to properly render non-previewed high-bitrate (codec-unfriendly?) files without risking black screens, but I do not anticipate having this problem for the duration of my project.

Eric Rothkirch replied 11 years, 8 months ago 4 Members · 6 Replies
  • 6 Replies
    • Graham Bernard

      January 25, 2014 at 6:24 am

      Really out of my depth here, I’ll still have a go.

      Exactly WHAT is your media? What is the RAW, you speak of?

      Is it possible that the capture CODEC is fighting the CODECS that come with Vegas?

      What Bitrate of 150mb/s referring to?

      Could you download BITRATE Viewer and view the file in that and note the rate variation you’re getting?

      These are my questions that I’d be asking to ascertain the edges of the issue.

      Cheers

      Grazie

      Video Content Creator and Potter
      PC 7 64-bit 16gb * Intel® Core™i7-2600k Quad Core 3.40GHz * 2GB NVIDIA GEFORCE GTX 560 Ti
      Cameras: Canon XF300 + PowerShot SX50HS Bridge

    • Kevin Bugay

      January 25, 2014 at 7:03 am

      It’s an AVI recorded with Action!. I definitely think the Action! codecs are proprietary and not very compatible with just about anything. I’m probably going to switch to Dxtory or something if I can’t figure this out. It baffles me that Sony Vegas can (somewhat) tolerate these videos but Handbrake can’t read them at all.

      166 Mbps means “megabits per second”, or 21,248 KB/s. The file is 714 MB and 1:38 long, giving an average bitrate of 7,285 KB/s. The higher number represents the “current bitrate” of that spot in the video with lots of water particles moving around. I can’t open the video in Bitrate Viewer because “AvLib/FFMpeg Error: Codec not found.” Which is not surprising.

    • Graham Bernard

      January 25, 2014 at 9:18 am

      Ugh….

      G

      Video Content Creator and Potter
      PC 7 64-bit 16gb * Intel® Core™i7-2600k Quad Core 3.40GHz * 2GB NVIDIA GEFORCE GTX 560 Ti
      Cameras: Canon XF300 + PowerShot SX50HS Bridge

    • John Rofrano

      January 26, 2014 at 12:02 pm

      [Kevin Bugay] “It’s an AVI recorded with Action!. I definitely think the Action! codecs are proprietary and not very compatible with just about anything. I’m probably going to switch to Dxtory or something if I can’t figure this out. It baffles me that Sony Vegas can (somewhat) tolerate these videos but Handbrake can’t read them at all.”

      You can have the same problems with Dxtory and here’s why: Some codec are designed for acquisition. Some codecs and designed for editing. Some codecs are designed for delivery. Back in the days of DV, we had one codec that did all of these and it spoiled us, but today, cameras usually record highly compressed formats that are hard to edit but maximize SSD card space on the camera so sometimes we need to convert our footage to a digital intermediary like CineForm, DNxHD, ProRes, etc. for editing. Then we convert again to some form of AVC/H.264 for delivery.

      Your case isn’t any different. Action! is using a codec that is highly optimized for digital screen capture and fast compression so that your computer uses as little resource as possible and doesn’t drop frames while recording. Dxtory is probably the same, This isn’t the best format for editing as you have seen. Don’t be afraid to change your workflow to capturing all of your video, then converting all of your video into a format suitable for editing, then starting you edits. You will have far less problems if you adopt this workflow.

      ~jr

      http://www.johnrofrano.com
      http://www.vasst.com

    • Kevin Bugay

      January 26, 2014 at 7:05 pm

      I suppose you’re right. As long as I’ve found a method for getting reliable renders I shouldn’t complain about the extra clicking/waiting I have to do.

      Still though, I 100% blame the programming of Sony Vegas which defaults to “insert black frame” rather than “wait until loaded into memory”, and then doesn’t have the politeness to tell you how many frames were lost in the render. It’s nothing we can do about it, but I’m leaving this here for the record. Sony needs to fix that.

    • Eric Rothkirch

      September 19, 2014 at 1:54 pm

      Project Properties -> Video -> Uncheck “Adjust source media to better match project or render settings.” This fixed the problem for me.

    We use anonymous cookies to give you the best experience we can.
    Our Privacy policy | GDPR Policy