Vegas and rendering :( fed up. Again.

Back to post

Comments

farss wrote on 6/14/2010, 6:04 AM
"I think that's probably quite true... but I don't think it has anything to do with a "memory leak"."

It's hard to say for certain however in modern code memory management and "leaks" are very complex things to diagnose.
Certainly speaking with another Vegas user recently who has done indepth investigation of the complexities of the H.264 codec it is a beast of a thing to work with.

On the other hand, yes V9 is over a year old. In that time I and others have seen basic functionality such as preview over firewire go from not working to working and now in V9.0e it is broken again.
SCS do not have a particularly good track record at getting things fixed. Way back when I first bought V4 a hot topic on the audio forum was the UAD-1 audio card. Most users could not get it to work without crashing due to memory leaks. Sonic Foundary kept blaming it on the vendor yet other audio apps had gotten it to work just fine. As recently as this year SCS say they've made some progress, pity the card is now obsolete.

I should add back in V4 days the audio forum was as active as the video forum. After a couple of years there were many major brawls like we're seeing here, one of the more vocal beta testers was banned. The audio forum is now all but dead. Peter (SonyPCH) is still there, he still listens and talks to users and exchanges ideas but he isn't at the helm and he posts in his own time.


Bob.
K-Decisive wrote on 6/14/2010, 11:03 AM
I hope I don't sound fan boyish with this, I'm just throwing this as an 'experience report'.

Did a crash project over the weekend, the final film was 8 minutes. Camera was 7D with sound recorded separately. there was probably about 120 minutes of source footage. I created sony.mxf 720p proxies to sync sound and edit with. no issues during editing. when it came time to do the final render, I swapped back in the source footage by renaming the directories and reopening the project. Reloaded with no issues, rendering time 20 minutes, flawless.

I've also thrown about 40 minutes of raw H264 on the time line without vegas crashing. And no, it will never play real time, it will play nearly real time if you make the preview small enough. Rendering proxies takes about 1.2 times the running time of the source footage. Probably the same or less time as it takes something like FCP to render to Prores I imagine.
Cliff Etzel wrote on 6/15/2010, 10:21 AM
Here's an issue that's been kept quiet for the most part with every version of Premiere Pro: Project files becoming so bloated as they no longer open - one user says that their project file (the same thing as a veg file) had grown to 10GB! Links here and here

I tested PPro CS5, it's ok, nothing to write home about. I've been quietly testing the latest NLE's available for the past 3+ weeks and I've come to realize for what I do, Vegas Pro - even with it's challenges, is far more a capable NLE for the kinds of work I shoot/edit than the other offerings. Edius is another solid NLE, but I'm not impressed to much with the others available for the Windows Platform. My perspective is around one man army shooter/editors like myself. No collaboration is done.

I've been getting some solid responses around post production workflow here on the forums that I'm developing a manual for accurate workflow methodology - and hoping the next longer form project I shoot/edit will be as smooth as possible with the new informaiton for workflow at my disposal.

Cliff Etzel
Solo Video Journalist | Micro Documentary Film Maker
bluprojekt | SoloVJ Blog
--------
Desktop: OS: Win7 x64 | CPU: Q9400 | Mobo: Intel DG33TL | 8GB G.Skill Dual Channel RAM | Boot/Apps Drive: Seagate 160GB 7200RPM | Audio Drive: Seagate 160GB 7200RPM | Video Source: WD Black 2x750GB RAID 0 | Video Card: nVidia GeForce GT 220 1GB

Laptop: Dell Latitude D620 | C2D 2.0Ghz | 4GB G.Skill RAM | OS: Vista x64 | Primary HD: WD 320GB 7200RPM | Video HD: WD 250GB 5400RPM
farss wrote on 6/15/2010, 4:22 PM
Long form projects if done improperly can kill any NLE, not just Vegas. A few years back I tried to elp out another Vegas user doing a feature length movie. Not only was it around 90 minutes long there was 140 tracks. Holly Molly, even IF Vegas didn't fall over what a management mess, finding something becomes diabolical.

Way, way saner to follow the usual industry practice of breaking the project down into "reels". Also follow another practice. Lock vision or lock sound then work on the other side. Just because you're a one man band doesn't mean you cannot work and think like you're collaborating with departments.

Bob.
Cliff Etzel wrote on 6/15/2010, 5:36 PM
farss said:

"Just because you're a one man band doesn't mean you cannot work and think like you're collaborating with departments"

Excellent advice Bob - think & work like you're collaborating, but be a self contained production entity ;)

Cliff Etzel
Solo Video Journalist | Micro Documentary Film Maker
bluprojekt | SoloVJ Blog
--------
Desktop: OS: Win7 x64 | CPU: Q9400 | Mobo: Intel DG33TL | 8GB G.Skill Dual Channel RAM | Boot/Apps Drive: Seagate 160GB 7200RPM | Audio Drive: Seagate 160GB 7200RPM | Video Source: WD Black 2x750GB RAID 0 | Video Card: nVidia GeForce GT 220 1GB

Laptop: Dell Latitude D620 | C2D 2.0Ghz | 4GB G.Skill RAM | OS: Vista x64 | Primary HD: WD 320GB 7200RPM | Video HD: WD 250GB 5400RPM
Opampman wrote on 6/15/2010, 8:35 PM
Very good advice, Bob. When I was shooting 35mm features, we always worked with 1000' reels. Each reel was handled as an individual project for post production mixing, timing, etc. More than a reel became a nightmare to work with!
DrLumen wrote on 6/17/2010, 5:41 PM
Like others have said, i tend to think there is something wrong with that file. Even some of Canon's own software won't work on that file. Per the press releases even Final Cut Pro is having some trouble with it.

http://www.northlight-images.co.uk/cameras/Canon_5d2_3d_7d.html

5D Mk2 Firmware changes



Adds or changes the following movie frame rates.

NTSC: 	PAL:

1920x1080 : 30 fps (changed - actual 29.97 fps) 	1920x1080 : 25 fps (added - actual 25.0 fps)

1920x1080 : 24 fps (added - actual 23.976 fps) 	1920x1080 : 24 fps (added - actual 23.976 fps)

640x480 : 30 fps (changed - actual 29.97 fps) 	640x480 : 25 fps (added - actual 25.0 fps)



    * Adds a function for manually adjusting the sound recording level (64 levels).

    * Adds a histogram display (brightness or RGB) for shooting movies in manual exposure.

    * Adds shutter-priority AE mode (Tv) and aperture-priority AE (Av) mode to the exposure modes for shooting movies.

    * Changes the audio sampling frequency from 44.1 KHz to 48 KHz.

    * Fixes a phenomenon where communication between the camera and the attached lens is sometimes interrupted after manual sensor cleaning. (This phenomenon only affects units with Firmware Version 1.2.4.)



It is recommended that you use the latest Canon applications* to edit movies captured with EOS 5D Mark II cameras that have the latest firmware because some previous versions do not support movie-editing functions and the frame rates that are added or changed by the latest firmware.


And



    * London, 8th February Month 2010 – Canon today announces the development of a plug-in that will enable quicker and easier editing of EOS MOVIE footage in Final Cut Pro. A free Beta release of the plug-in will be available to download for testing and evaluation in March 2010.

    * ‘EOS MOVIE Plugin-E1 for Final Cut Pro’ is being developed to provide an even smoother workflow for EOS MOVIE users who edit using Apple’s Final Cut Pro software suite. The plug-in will enable the ‘log and transfer’ of video footage from Canon’s EOS 5D Mark II, EOS 7D and EOS-1D Mark IV Digital SLR cameras – all of which offer full 1080p HD video recording.

    * The plug-in will convert EOS MOVIE footage to Apple’s high quality ProRes 422 codec at approximately twice the speed of Apple’s standard conversion. Additionally, users will also be able to add timecode, reel names and metadata to footage quickly and easily – further enhancing the experience of EOS MOVIE users when editing their footage.



# This from a US release (no sign of it yet)

# The EOS E1 video plug-in is a free download available at http://www.apple.comdownloads/macosx/finalcutstudio/.

# The plug-in is compatible with Final Cut Pro 6 or higher and currently supports Canon EOS 5D Mark II, EOS 7D and EOS 1D Mark IV cameras.


Instead of blaming SCS and whining on here perhaps you should be in contact with Canon. From what I have seen, that camera is about as stable as a drunk mountain climber.

intel i-4790k / Asus Z97 Pro / 32GB Crucial RAM / Nvidia GTX 560Ti / 500GB Samsung SSD / 256 GB Samsung SSD / 2-WDC 4TB Black HDD's / 2-WDC 1TB HDD's / 2-HP 23" Monitors / Various MIDI gear, controllers and audio interfaces

apit34356 wrote on 6/17/2010, 7:39 PM
There has been a number of issues with the earlier firmware for the 5D2 and quicktime itself has had a number of updates....... the clip from larsHD seems to contain an embedded problem.......SO, we should converted it to uncompressed AVI then back to "mov" and then tested in his test model.
A. Grandt wrote on 6/18/2010, 2:17 AM
I only have QT Pro 7, and did at some point try to load it into QT and Save As. Same result, but that doesn't recode the h.264 either, and I assume that is where the problem is.
From what I can tell, the file may play back reasonably well, but it is not optimal for editing, and that may be where Vegas is wasting all that memory, to index the file, in an attempt to make it more suitable for random access, which is essential for editing.

I tried to recode the clip with QT Pro 7's export feature, using the max settings (actually higher bandwidth than the original). That too was giving some trouble, though I did manage to put 50 clips on the timeline (with the CCF modification of qt7plug.dkk and FileIOSurrogate.dll) and made an interesting observation when looking at the Processes tab of Windows Task Manager. It was FileIOSurrogate that was allocating all the memory, and it was that file that was finally crashing Vegas. At one point by suddenly allocating 6GB though that was an odd one. Normally it dies at around 2.2GB here.

The "simple" solution from SCS would be a new version of FileIOSurrogate that is better able to handle this scenario. and a 64bit version that is better able use the system.

It is my opinion that while it looks like it's FileIOSurrogate that is the problem, I'm still fairly confident that FIS is a wrapper around for instance qt7plug, and thus hides the actual problem. But it does suggest that one qt7plug.dll is instantiated per file, and IT is the one needing too much memory. Again, recoding the clip to Cineform solved all the problems displayed with the original.

Rob Franks wrote on 6/18/2010, 4:30 AM
"I only have QT Pro 7, and did at some point try to load it into QT and Save As. Same result, but that doesn't recode the h.264 either, and I assume that is where the problem is."

When I started playing around with Lars's test file, I was initially interested in skinning the QT container off the file (without re-encoding) so that I could get at the raw undisturbed files.(My theory is that the MOV container has a lot to do with all of this).

TSmuxeR will allow you to do this and works on every other MOV file I have. Yet with Lars's above sample TSmuxeR refuses to open it. This in itself I find quite interesting and it SUGGESTS a problem with the file itself.
farss wrote on 6/18/2010, 4:58 AM
Why would the MOV container have anything to do with this?

It is only a container after all.The data in there is read to determine what is contained, that's it.

Yes, there is something wrong with the video in that file, as Lars pointed out it was recorded prior to that latest firmware upgrade to the camera. The issue of duplicated frame in the video has nothing to do with the issue at hand at all.

If the file is in some way corrupt how come the video is basically OK. The probability of their being a problem that does not cause a pixel to be out of place and yet can cause Vegas grief has to be trillions to one.

On top of this SCS have seemingly admitted there is something not right with their code. You're almost at the point of arguing against SCS now.
I'd also point out that well written code is not supposed to fall apart from ANY data input. That's software engineering 101. If you're claim was correct, that something in the file is causing the problem then you're effectively saying Vegas has more problems than even Lars was saying. Somehow I think the SCS codesmiths are better than you think they are.

Bob.
Rob Franks wrote on 6/18/2010, 5:12 AM
"On top of this SCS have seemingly admitted there is something not right with their code. You're almost at the point of arguing against SCS now. "

Don't jump to conclusions. This doesn't necessarily mean SCS is at total 100% fault. There has to be a valid reason why TSmuxeR opens every other MOV file I have.... but not Lars's test file

Containers have a LOT to do with it. Put a H.264 file into a M2TS container and vegas opens it with no issues. Drop that file into a MOV container and all of a sudden you need the quicktime codec on your machine to read it. That is by no means a small detail.
farss wrote on 6/18/2010, 7:02 AM
Firstly it's not Lars's test file. It's one from someone else that he simply chose because it had a fair amount of fast full frame motion in it and it was easy for everyone to download. If I can find the time when our 5D is back in the shop I'll shoot some more test files, our camera is running the latest firmware.

"There has to be a valid reason why TSmuxeR opens every other MOV file I have.... but not Lars's test file"

There's other 5D files on the same site, have you tried them with TSMuxeR?

"Put a H.264 file into a M2TS container and vegas opens it with no issues."

Not in my experience. I've had H.264 files rendered out of Vegas that Vegas couldn't decode correctly.

I've had other problematic H.264 MOV files that Vegas did other wierd things with like sync wnadering. Ppro CS3 played those files just fine. That problem got fixed in V9.0e so that one certainly wasn't due to QT.

I'm not so certain Vegas even uses QT anymore. I haven't updated QT since 2008, I might try unistalling it. Vegas does seem to use its own QT7plug.dll which is copyright Sony Creative Software. Its version 1 Build 4713.


My gut feeling and I could be quite off the mark here is that a lot of these problems arise because Vegas is still using vfw instead of DirectShow. VFW was declared obsolete by Microsoft over a decade ago. Microsoft's last notes on it said that bugs would not be fixed and developers should stop using it and move to DirectShow.

Bob.
apit34356 wrote on 6/18/2010, 1:01 PM
OK, Bob, remember the rendering engine is from maincept/divx (some else now owns them), and LarsHD did choose this file instead of furnishing one of his files in his claimed "problemic" project veg. As for Codex design, not all possible combinations of encoding errors are coded for, because ..... mainly timing and memory resources overhead of "fixing" all possible events. The odds are, that the other companies codex simply skips the defective stream and inserts a null seq or simpler data. The odds are, guessing at this, a lot very small broken audio streams segments, meta data out place in stream and more common, a defective file header value( a common event with many xvid encoders). But with the memory errors, I would lean towards the damaged audio being patched with the generated frames requiring too much memory being used to align the seq of frames correctly.
farss wrote on 6/18/2010, 4:37 PM
"OK, Bob, remember the rendering engine is from maincept/divx"

That's a good point although SCS have recently added the Sony Media Encoder. Pretty confusing when there's TWO ways to encode H.264! This is another issue that SCS need to get under control, they seem to be heading towards a unified media encoder like Adobe use and that would be a big step in the right direction.


The rest you could well be right about and indeed many of the issues could relate to 3rd party code from Mainconcept.

Bob.
A. Grandt wrote on 6/19/2010, 3:33 AM
Just a quick note about the effectiveness of Intermediaries, for instance Cineform.

I decided to go overboard, and converted the defective clip Lard linked to CF, using NeoHD (version 4.3.0) and the Film Strip setting, resulting in a 279MB file.

I then made 299 copies of it.

Loading all 300 to the timeline in Vegas took a little while, it did have to render the audio wave forms after all.
After that, I noticed that Vegas weren't really using a lot of memory here, and FileIOSurrogate was only allocating 24MB.

Scrubbing back and forth is smooth, from playback to 20x, both directions.

Playback is smooth, at any point in the ~1h5m time line that the 300 clips resulted in. All in all I HAVE to conclude that the Vegas Pro internals are fully capable of handling full HD, it's the file handling that kills it.
I can also say with absolute certainty, using Cineform makes a difference or the better by such a wide margin that I'm starting to think maybe Sony should just bundle it with Vegas, if only it wouldn't add $500 to the cost of Vegas Pro :)
But from what I understand, NeoScene is sufficient for most users, and is a bit cheaper. At any rate, it's recommended.

Edit: I forgot to mention that reload does take a few seconds. but considering it's 300 clips I'll accept that.
ushere wrote on 6/19/2010, 3:52 AM
why not .mxf? it's free in vegas.
Cliff Etzel wrote on 6/19/2010, 9:48 AM
Leslie - MXF is still a compressed format - albeit an excellent one.

I've experienced less issues since moving to Cineform now since 9.0e has been released.

The recent price hike on the Edius HDSpark card has me locking more now to Vegas Pro than ever before - The Blackmagic Intensity Pro card is more or less ready to use with Vegas PRo 9 according to the thread I started here. And for less than $190, it's a bargain compared to the entry level monitoring solution offered by Edius.

I also inquired with Cineform around the latest update of their products and whether there was any performance enhancements to be had with Vegas Pro, I was told more or less no there wasn't. So I"m sticking with NeoScene 1.6 for the time being.

I'm hopeful 9.0e becomes like the fabled 7.0e of Vegas - considered by many as one of the most stable versions of Vegas.

Then we are left to wonder what's next for Vegas Pro 10 - Although I still like the name someone else came up with - Vegas Pro Edit.

Cliff Etzel
Solo Video Journalist | Micro Documentary Film Maker
bluprojekt | SoloVJ Blog
--------
Desktop: OS: Win7 x64 | CPU: Q9400 | Mobo: Intel DG33TL | 8GB G.Skill Dual Channel RAM | Boot/Apps Drive: Seagate 160GB 7200RPM | Audio Drive: Seagate 160GB 7200RPM | Video Source: WD Black 2x750GB RAID 0 | Video Card: nVidia GeForce GT 220 1GB

Laptop: Dell Latitude D620 | C2D 2.0Ghz | 4GB G.Skill RAM | OS: Vista x64 | Primary HD: WD 320GB 7200RPM | Video HD: WD 250GB 5400RPM
arbory wrote on 6/19/2010, 1:42 PM
Hi everybody

I have quite some experience with 5d2 mov files and vegas.
I prefer now working with cineform intermediates - but tried some time to get the files on the timeline with little sucess.
one interesting point when you try to put 5d2 mov files on the timeline:

it only matters how MANY clips you put on the timeline not how long they are.

for example i had over 100 clips which was and is still impossible to import in vegas.
when i stick them together in QT PRO to one - or lets say maximum 10 files (via copy&paste or drag n drop) it is absolutely no problem.
you can either save the movie in QT to one big file (which goes pretty fast because there is no re-rendering in QT - the files are only stitched together) or you can even save the qt movie with all clips in it as referenced movie, which you can also open in vegas.

the downside is, that you have to split all clips manually to single clips again - but it works very solid.

So Vegas CAN handle hours of original 5d2 mov h264 material at once, and even referenced QT movies from 5D2 files.
(but preview of movs h264 is even on my fastest computer max about 15fps).
But Vegas can´t handle many mov h264 files at once (on older versions it was about 10, now (i have 9.0c 64bit) maybe 20-30 you can handle easy until red frames an crashes.
i have noticed when FileIOSurrogate.exe goes over 1,5-2Gb in task manger its over.....(thanks for the CFF trick - it helps a little)
So i stick to intermediates for now - but i would also like to see a solution with GPU powerd playback in Vegas10
(on Windows 7 and a quadcore i have only about 10%-15% CPU usage on original 5D2 mov files via playback in WMP!)