Possible explanation for some slow renders .. bug?

Comments

OldSmoke wrote on 12/24/2014, 11:15 AM
[I]That is the spirit I was brought up with[/I]

While that is a good spirit and mine too, it breaks apart the moment finance has a say in what is going with a product.

If you want faster render, get a better hardware especially if you are making money and a living from it. If not, time shouldn't play such a big role.

Proud owner of Sony Vegas Pro 7, 8, 9, 10, 11, 12 & 13 and now Magix VP15&16.

System Spec.:
Motherboard: ASUS X299 Prime-A

Ram: G.Skill 4x8GB DDR4 2666 XMP

CPU: i7-9800x @ 4.6GHz (custom water cooling system)
GPU: 1x AMD Vega Pro Frontier Edition (water cooled)
Hard drives: System Samsung 970Pro NVME, AV-Projects 1TB (4x Intel P7600 512GB VROC), 4x 2.5" Hotswap bays, 1x 3.5" Hotswap Bay, 1x LG BluRay Burner

PSU: Corsair 1200W
Monitor: 2x Dell Ultrasharp U2713HM (2560x1440)

johnmeyer wrote on 12/24/2014, 12:04 PM
If you want faster render, get a better hardware especially if you are making money and a living from it. If not, time shouldn't play such a big role. That completely misses the point, and is a total non sequitur (i.e., it does not logically follow ...). Yes, a faster computer will make things go faster, but once you get the fastest computer in the world, then what? Your render simply cannot get any faster, and since the rate at which computers are getting faster has slowed dramatically in the past decade (no more "Moore's law;" just massive parallelism, which doesn't translate to performance for many tasks), you are going to be stuck with whatever performance you get from your new computer for many years to come.

But wait, your Vegas renders and preview performance CAN still get faster, because it is both the computer AND the software which determines performance and, as I have demonstrated in this thread and as others have confirmed, there is a HUGE amount of performance improvement possible for many projects, just by addressing this "issue" (since some don't like to call it a bug).

Why are people resisting? Is a nine hour render really fast enough for you? I am talking here about a guaranteed performance improvement that, depending on the nature of your project, could be far greater than any performance improvement ever offered in any new release of Vegas, including the introduction of GPU support. Yes, it will not improve performance on all projects, but for those that it does (like mine, or like most multi-cam projects), the improvement will be massive.

And yet, people here are arguing against it. Wow.
OldSmoke wrote on 12/24/2014, 1:02 PM
Ok, so I want to be a good sport and did some testing with footage that puts some strain on my system. I used several files of 4K XAVC-S footage from my AX100 spread over three tracks, cut to make out exactly 1min. and applied to Pan/Crop to the lower two tracks.

The Pan/Crop was applied so that it would leave a small frame of alpha channel around the image.
I rendered it to 1280x720@60p, which is completely off from the original footage, and I got:

33sec. with all tracks on
33sec. with the lower two track muted
33sec. with just one track only (I deleted the lower two tracks)
45sec. when I make a multicam track of the three video tracks with multiple 15frames cross cuts.
42sec. for the multicam track when I converted the cross cuts to straight cuts.

So, on my system, there is absolutely no difference between I track or many tracks.

Why I am resisting? I prefer Sony to focus on the real bugs, the ones that affect all of us and not introduce a potential problem by trying to convert the "brute force but works" rule in this case.

Edit:
I did a second test with different footage:
Track 1: 4K 30p from AX100
Track 2: 1080 60p from HF G30
Track 3: HDV 720 60p from HXR-NX5U

Result: 25sec. no matter whether there is a Pan/Crop, 1 track or three tracks it is always the same render time.

Proud owner of Sony Vegas Pro 7, 8, 9, 10, 11, 12 & 13 and now Magix VP15&16.

System Spec.:
Motherboard: ASUS X299 Prime-A

Ram: G.Skill 4x8GB DDR4 2666 XMP

CPU: i7-9800x @ 4.6GHz (custom water cooling system)
GPU: 1x AMD Vega Pro Frontier Edition (water cooled)
Hard drives: System Samsung 970Pro NVME, AV-Projects 1TB (4x Intel P7600 512GB VROC), 4x 2.5" Hotswap bays, 1x 3.5" Hotswap Bay, 1x LG BluRay Burner

PSU: Corsair 1200W
Monitor: 2x Dell Ultrasharp U2713HM (2560x1440)

farss wrote on 12/24/2014, 1:12 PM
[I]"Why are people resisting?"[/I]

1) Brute force might be faster. You ignored that aspect. Given that Vegas is a full blown compositing application the code that you want SCS to write may make what you're trying to do faster but make what others want to do slower.

2) Your issue is already solved. SCS long ago provided us with the solution to this issue, use Vegas's Multicam Editing feature and your issue with how it does compositing goes away.


Bob.
videoITguy wrote on 12/24/2014, 1:16 PM
johnmeyer, You make very valid points throughout this thread. Your experience as a software engineer is invaluable, as is mine, and many others who have chimed in from that special perspective. I thank you for creating this thread - it does prompt investigation - but actually more relevant for VegasPro against other compositing apps rather than against itself.

The point is well made that there are many huge bugs existing in VegasPro and they should be corrected - but the summary of this thread would appear to be that this issue would not be a worthy option to prioritize. You may feel to the contrary, and I respect that, but look at the preponderance of real -world users experience...
Former user wrote on 12/24/2014, 1:18 PM
Bob beat me to it. I was about to say, "But that's what multicam editing is for..."

Merry Christmas all...
johnmeyer wrote on 12/24/2014, 1:58 PM
I give up.
larry-peter wrote on 12/24/2014, 2:18 PM
I am totally with marco's earlier suggestion of a "none" compositing mode that ignores all clips beneath universally. It doesn't seem that this option would introduce anything that compromises time in AI checking of properties when compositing is required.
OldSmoke wrote on 12/24/2014, 2:34 PM
I don't know what else to do. As my test above shows, there is absolutely no difference no matter what I did; unless I missed something.

Proud owner of Sony Vegas Pro 7, 8, 9, 10, 11, 12 & 13 and now Magix VP15&16.

System Spec.:
Motherboard: ASUS X299 Prime-A

Ram: G.Skill 4x8GB DDR4 2666 XMP

CPU: i7-9800x @ 4.6GHz (custom water cooling system)
GPU: 1x AMD Vega Pro Frontier Edition (water cooled)
Hard drives: System Samsung 970Pro NVME, AV-Projects 1TB (4x Intel P7600 512GB VROC), 4x 2.5" Hotswap bays, 1x 3.5" Hotswap Bay, 1x LG BluRay Burner

PSU: Corsair 1200W
Monitor: 2x Dell Ultrasharp U2713HM (2560x1440)

farss wrote on 12/24/2014, 2:46 PM
[I]"I am totally with marco's earlier suggestion of a "none" compositing mode that ignores all clips beneath universally. It doesn't seem that this option would introduce anything that compromises time in AI checking of properties when compositing is required. "[/I]

What do you want to happen when there's a fade?
What do you want to happen with unquantized frames?

What might make more sense would be a global "Early Avid Mode" switch. :)

Bob.
Warper wrote on 12/25/2014, 8:26 AM
Fade will produce fade with zero transparency. That is, black color at the end, no transparency.
Unquantized frames are lost. AFAIK they are lost anyway, but sometimes produce crashes, so losing them will not make things worse. There are other means to deal with unquantized frames.

farss wrote on 12/25/2014, 6:40 PM
I ran some more tests, I was planning on plotting the results but as shown below, that would seem rather futile:


# Tracks Render Time
in seconds
1 29
2 29
4 28
8 28
16 28
32 29


As before this was using EX1 footage, 25p MP4 rewrapped to MXF
and rendered to the same codec. All renders ran with "No recompression".
No FXs, no pan/crop, nothing but vanilla FullHD. Project and video on each track was 60 seconds long and each track contained different video.

This is different to what I got before, why?
This time I removed the audio tracks. Vegas will always have to at the very least to mix all the audio tracks and that does take CPU cycles and the more tracks of audio the more CPU cycles.

I wonder if this to some extent explains the variation in what posters above have reported?

Bob.
Jedman wrote on 12/25/2014, 7:47 PM
Just to complicate things further, but may be related-

I found this a few months ago, most of what I do is multicam, and about half the time for various reasons I nest the cams in their own projects and pull the vegs in to a new project to form the multi cam track.

With one 4k nested cam in a 5 cam multi the playback is woeful, so I use a proxy 1080p version of the 4k in its project,
-render to a new track and mute the 4k track underneath. Sfap file gets rebuilt in the multi cam project and preview is back to Best full in the multicam project.... or so it should be. But its not. 5fps :(

So, suspecting some funny business, go back into nested 4k project and delete the muted 4k track....
Sfap file gets rebuilt in master project ( I wonder why, since it was muted and should not be affecting the playback of the 1080p track above)..... and it still previews at 5 frames a sec. Not happy.

Go back to nested 4k and go Tools- Clean Project Media.
So now all that is in that Project is the 1080p proxy.

Finally, playback is back to Best Full in the multicam project.

So, why is Vegas looking at unused footage in the media bin when processing a Nested Veg file?
OldSmoke wrote on 12/25/2014, 8:36 PM
Could it be that the project settings in your nested project where still set at 4K even tough you where not using the file?

Proud owner of Sony Vegas Pro 7, 8, 9, 10, 11, 12 & 13 and now Magix VP15&16.

System Spec.:
Motherboard: ASUS X299 Prime-A

Ram: G.Skill 4x8GB DDR4 2666 XMP

CPU: i7-9800x @ 4.6GHz (custom water cooling system)
GPU: 1x AMD Vega Pro Frontier Edition (water cooled)
Hard drives: System Samsung 970Pro NVME, AV-Projects 1TB (4x Intel P7600 512GB VROC), 4x 2.5" Hotswap bays, 1x 3.5" Hotswap Bay, 1x LG BluRay Burner

PSU: Corsair 1200W
Monitor: 2x Dell Ultrasharp U2713HM (2560x1440)

Jedman wrote on 12/26/2014, 4:11 AM
No, project settings for editing are always 1080p 8bit through all nests and same in the multi project.
It was very weird
Marco. wrote on 12/26/2014, 5:22 AM
"I wonder if this to some extent explains the variation in what posters above have reported?"

In my case: No. I used the test project John linked in the first post and there is no audio in the timeline.

To me it rather looks like in case of smart rendering things change. So why not trying some video which does not smart render?
farss wrote on 12/26/2014, 6:40 AM
[I]" So why not trying some video which does not smart render?"[/I]

So we are comparing apples to apples I used the same projects but rendered to PAL DV WS:


Unstretched Stretched
# tracks PAL DV WS PAL DV WS
1 27 42
2 58 26
4 72 27
8 125 27
16 804 27


Now that WAS interesting.
It seems that not having video that is simplistically seen as filling the frame causes Vegas to decode and composite every track. I suspect the huge blowout at 16 tracks of unstretched PAL DV WS was due to Vegas running out of RAM to buffer all the GOPs worth of frames from 16 tracks.

Bob.

OldSmoke wrote on 12/26/2014, 8:25 AM
@Bob

Maybe your result is what John was seeing too. If he doesn't have stretch to fill ticked then every layer has a small bar on the sides and hence Vegas will tread it as alpha, trying to composite the underlying layer. I don't see that when I render to NTSC DVD because I use 704x480 which doesn't require stretch to fill and Inalso have it always ticked anyways.

Proud owner of Sony Vegas Pro 7, 8, 9, 10, 11, 12 & 13 and now Magix VP15&16.

System Spec.:
Motherboard: ASUS X299 Prime-A

Ram: G.Skill 4x8GB DDR4 2666 XMP

CPU: i7-9800x @ 4.6GHz (custom water cooling system)
GPU: 1x AMD Vega Pro Frontier Edition (water cooled)
Hard drives: System Samsung 970Pro NVME, AV-Projects 1TB (4x Intel P7600 512GB VROC), 4x 2.5" Hotswap bays, 1x 3.5" Hotswap Bay, 1x LG BluRay Burner

PSU: Corsair 1200W
Monitor: 2x Dell Ultrasharp U2713HM (2560x1440)

farss wrote on 12/26/2014, 2:48 PM
[I]" Maybe your result is what John was seeing too. If he doesn't have stretch to fill ticked then every layer has a small bar on the sides and hence Vegas will tread it as alpha, trying to composite the underlying layer."[/I]

Possibly so.
The sudden blowout between 8 tracks and 16 tracks is also interesting, going from 125 to 804 seconds! All the cores were running at around 80% and over 5GB of the 8GB of RAM were being used.

Bob,
rmack350 wrote on 12/27/2014, 1:32 PM
Just some observations. I'm sitting in a hospital and writing on my tablet so I can't test anything.

Bob made a kind of telling comment when he talked about testing on a pixel by pixel basis. Obviously that'd incur a bigger cpu cost than testing frame by frame or event by event. I assume Vegas tests on a frame by frame basis but it could read the events and set a variable.

Once you have the event flagged as compositing=true then vegas has to compute the events below and do the composting math. Sometimes the end result is no change but you still have to do the computation to find out.

I think it was hit on that getting events unto the same track helped and was easier to visualize in a more traditional A/B view.

I wonder what happens if the underlying events are just generated solid colors. Can you add fix to make thme impact render times? Just looking for a way to simplify the problem.

Rob
Grazie wrote on 12/27/2014, 1:49 PM
Rob - hospital? More important. I wish you well.

Graham

larry-peter wrote on 12/27/2014, 2:44 PM
I'll leave it to others to interpret, but my tests point to something more than simply seeing alpha, or "black" around lower tracks. I can confirm Bob's results when rendering to a different screen aspect ratio with "stretch to fill" NOT checked. Here's what I got today:

Project settings - 8 bit, 1080p 23.976fps
From highest track down, first 4 tracks are 1080p 23.976 AVCHD
5th track is 720p 23.976
6th track is HDV 1440 23.976
rendering selection 10 sec

Rendering to .mxf HD-EX 1920X1080 - 24p
track 1 only - 10sec
1 & 2 - 10 sec
1,2,3 - 10 sec
1,2,3,4 - 10 sec
1,2,3,4,5 - 10 sec
1,2,3,4,5,6 - 10 sec

Rendering to .mxf HD-EX 1920X1080 - 24p with all tracks other than track 1 rotated or pan/cropped to expose black around edges:

Same results as above

Rendering to .mxf DV 24p widescreen
1 track - 14 sec
1,2 through 1,2,3,4,5,6 - 14 sec No difference

Rendering to .mxf DV 24p widescreen with all tracks other than track 1 rotated or pan/cropped to expose black around edges:

Same results as above

Rendering to .mxf DV 24p (stretch to fill NOT checked)
1 only - 12 sec
1,2 - 16 sec
1,2,3 - 13 sec
1,2,3,4 - 16 sec
1,2,3,4,5 - 40 sec
1,2,3,4,5,6 - 1:05
(checked twice and the 13 second anomaly with three tracks is consistent)

Identical results in DV 24p with lower tracks rotated/cropped.

Edit: To be clear, this was done in Vegas 11 with all audio tracks removed.
larry-peter wrote on 12/27/2014, 4:10 PM
I had posted the above test and realized that I couldn't reproduce the results of my first test (WAY up in this thread) where as soon as I added a clip of a different size (a 720 clip beneath a 1080 clip in a 1080 project) that rendering time increased. I went back to see what format I had rendered to (I didn't even check at the time) and it was a 720 X 480 NTSC mp4.

Looking quickly through the tests by others in this thread (including johnmeyer's) it seems that this "covered-up-track" compositing is only taking place when altering pixel aspect ratio from project settings to render settings. Have I missed a test where this WASN't the case?
rmack350 wrote on 12/28/2014, 10:58 AM
Grazie, Aging parent, not me. We're managing. I'm learning the names of everyone on my mother's floor. Hospital has WiFi, which is great as I can read while I watch her sleep. Also starting to see a use for phone and tablet video cameras as I can bring her other people's good wishes.

As for Vegas having a bug or a design bottleneck, the question to me is weather this should be addressed as logic or as design. A design approach would lead you away from troubles and give you easy ways to pinpoint and fix the trouble you created. A logic or programming approach would attempt to male the software foolproof, which we all know is impossible because we fools are so ingenious.

Rob