Better (faster) way of rendering stills in video?

Liam_Vegas wrote on 1/27/2004, 9:48 AM

In the type of videos I produce I often have lots of stills (jpegs) on the timeline and (probably as a result of the way I use them no doubt) the render times for typical segments of video containing them may drop to about 1-2 frames per second. This on a 3.0Ghz system which has a rendertest score of 1min 34sec.

I do have other FX's active including broadcast colors but in my limited testing I believe these FX's to be less of an impact on the render speeds than the use of the stills on the timeline.

On some of the slides I do quite a bit of panning/zooming so for those I tend to load images about 1440x960 resolution and for others that I do not zoom I use at standard DV resolution.

I also often have a PIP affect where the still is on the top right and the video of a presenter is in lower left.

I have a feeling that my approach to doing this may be contributing to the slow (to me at least) render times of these segments.

I have an idea that if I converted each non-panning/zooming slide into a small AVI clip that I might get a faster render for those parts of the video where I use them. So in other words instead of having a still that I stretch across the track to the desired time-span I would just render that slide (1 frame) to an AVI file then load that back onto the timeline in place of the original slide.

The reason I think this should be faster is that I am sometimes forced to use video of the slides rather than high-res versions of those slides (the presenter did not have them in a format that I could use). In those cases these segments skip along during rendering (but of course the quality of the video of those slides is dreadful).

Is this a crazy idea?

I will give this a try on a small segment of a video in any case and report back the results.

Does anyone have any other recommendations for how I might improve the render times?

Thanks in advance for all your suggestions/ideas!

-Liam

Comments

Chienworks wrote on 1/27/2004, 10:11 AM

I think you've got a very valid method going there. You can even use the same thing for the pan/zoom images too: set up the pan & zoom on that image and render it to a little .avi file, then use that .avi file in the full project.

However, you're really only saving time on the previewing & prerendering. While the final render may go much faster, you've still spent all that time savings up front doing all the individual image renders (you don't get something for nothing). Of course, how you use this time in your workflow can make a big difference. If you have a limited amount of time for editing but then can let the final render run all night, then doing these individual still -> avi conversions will probably eat up most of your work time. On the other hand, if you're going to be doing final renders to several different formats, or you need to spend a lot of time previewing at relatively full speed frame rates, then doing the little renders first will be a blessing.

Liam_Vegas wrote on 1/27/2004, 10:18 AM

While the final render may go much faster, you've still spent all that time savings up front doing all the individual image renders (you don't get something for nothing).

Yep... if I were to render say a 20 second AVI clip from an original still that would definitely not save me time overall... but my idea here is to render a 1 frame AVI and then to load that back onto the time-line and "loop" it across the original slide length.

This comes down to my (non-scientific) impression that if the source is DV AVI then everything happens much faster (if I have two DV AVI sources that I combine into a PIP effect the rendering goes MUCH faster than if one of them is a slide/jpeg and the other is video).

Not sure I am explaining myself clearly here... hopefully you get the subtle difference in the approach I am suggesting.

[edit] and in any case... you may still be absolutely correct... there is a time hit as far as the workflow to create all these 1-frame AVI files and load them back across the timeline. I am just anticipating that I'll get some time gain.

I do do a lot of my rendering in the we-small hours of the night... but if I can still manage to speed things up by a <perhaps> small change to my workflow I am all for it!

Chienworks wrote on 1/27/2004, 10:32 AM

I just had one more (possibly depressing) thought on the idea. For those images that are used as PIPs, this method may not help speed up the final render much at all. It should still be a timesaver for the full screen images though.

Liam_Vegas wrote on 1/27/2004, 12:20 PM

I'll get back with a real number when I do this later today... but as I said the reason I am doing this at all is that when I do the exact same arrangement of PIP with two DV AVI files (instead of one AVI and one JPEG) it renders a <lot> faster.

I am prepared to be disappointed :-|

TheHappyFriar wrote on 1/27/2004, 12:24 PM

I've had PNG images render much faster then most other formats. I don't know why, butt when I has about 50 pictures to be displayed, first I tried PSD's. Took forever to render. 2nd I tried highest quality jpg's. Faster. 3rd I tried PNG's. Rendered even faster.

Hope that helps.

Liam_Vegas wrote on 1/27/2004, 12:41 PM

In fact I was originally using png's but heard there was some color-shift issue/bug (although to be honest I had never noticed anything). I do seem to recall stuff rendering quicker back when I was using pngs. Hmmm... another comibination to try.

I'll be back,

Chienworks wrote on 1/27/2004, 12:49 PM

Also consider that PNG files generally are much less compressed than JPG files. It may take Vegas a lot longer to deal with uncompressing JPG than uncompressing PNG.

johnmeyer wrote on 1/27/2004, 1:21 PM

Does anyone have any other recommendations for how I might improve the render times?

ALWAYS render to a different physical hard disk. This can make almost a 2:1 difference in rendering time.

corug7 wrote on 1/27/2004, 1:44 PM

I ran into the same problem using TIFFS on a large project, to the point where my computer just locked up. I also got around it by rendering after every 10 minute segment was completed. Imovie (gasp!) prerenders in the background. Does anyone know if Vegas will move to a similar rendering style?

jetdv wrote on 1/27/2004, 1:52 PM

TIFF is NOT a good choice of formats for Vegas. They require Quicktime to decode causing them to be a VERY slow format.

Liam_Vegas wrote on 1/27/2004, 2:27 PM

Based upon my own ideas (and a few suggestions here) I have done a few tests that I am sharing with the forum.

TESTING TWO TRACK PIP
=====================

I took a small segment of a typical project where I have two tracks one with video and the other is a slide. These tracks are arranged using track motion to be visible on the screen simultaneously.

Below are the test scores for rendering this segment to NTSC DV AVI with different varieties of file format for the slide either represented as jpeg, png or AVI

Length of segment = 86 seconds

with JPG slide : 304 seconds
with PNG slide : 302 seconds
with AVI slide : 235 seconds

Summary of findings... it makes no difference if the slide file is PNG or JPG they seem to take an almost identical time to render. The biggest difference (although not as much as I had hoped) is with the AVI version of the slide

The AVI slide was created (rendered) from one full frame of the original JPG slide (it took lass than one second to do this) and then overlayed over the original slide on the timeline as a new take and then the 1m26s segment was rendered which completed in the 235 seconds specified.

This to me does come up with a result in line to what my gut was telling me would happen. That is if I have a static frame/slide it is far better to take the trouble to render a 1-frame AVI of that slide and use that on the timeline rather than let Vegas figure it out for itself.

TESTING ONE TRACK SLIDE
=======================

I then performed another test of another common use for slides. I'll often have a slide full screen but with a small track-motion "zoom" to fit the slide within the safe areas of the screen.

For a comparison test with the above video I created a small test track containing the same slide I used before (set to a size of 1m26 seconds) and recorded the time taken to render this small segment to DV AVI.

JPG 49 seconds (no track motion to reduce size of slide)
PNG 49 seconds (no track motion to reduce size of slide)
JPG 44 seconds (with track motion to reduce size of slide to fit safe areas... odd that doing an extra step of track motion actually speeded up the render)
AVI 14 seconds (after creating a single frame AVI file containing the slide at the required zoom to fit within the safe areas I placed this AVI back on the timeline and rendered the test file).

So... to me at least it seems as if rendering these 1-frame AVI's of the static slides I use can save potentially a large amount of time in rendering.

I hope I have made it clear the approach I took to doing these tests and that you can understand (through my less than adequate communication skills) the significance of the results (that I believe I see).

Now all I need is some script that will automatically render the first frame of every event on specific track on the timeline to DV AVI and then to replace the original event (slide) with the rendered AVI file as a take of the exact same duration as the original slide.

I think if Vegas could be given a little bit of AI smarts it might be possible to code this sort of "awareness" into the software. Really what I have done here could be "figured out" by the code... but I admit that (being a software developer) I can see there would be a significant amount of processing through a VEG to determine if there were situations that could be "optimized" automatically using the approach I have done manually.

It was fun. I hope some of you found my results of some use.

I am going to be using this approach on my next job (which starts right..... now)

johnmeyer wrote on 1/27/2004, 2:37 PM

Liam,

Man, I love it when someone takes the time to do scientific tests. THANKS!

Given your results, it would seem that a script that would take all still images on a timeline, or in a folder, render them to AVI files, and then replace the original image files with the AVI files, could be quite a winner.

Liam_Vegas wrote on 1/27/2004, 2:51 PM

Sounds like a cool add-on to Tsunami or Excalibur... or if I had the time to figure it out a new/free tool maybe called "Liami".

I have written a few scripts (or I should say ripped apart someone elses script) so i know I could get there... but it will take me longer than someone like you who is already there!

If it helps....

I hereby state for the record that I forever and completely release any and all rights that I might otherwise (knowingly or unkowingly) have to the ideas I have shared for improving the render times using this approach. Furthermore I believe I have the right to convey said rights to the world as far as I know because the ideas came from my head mostly through chemical reactions that I think happened as a result of my own thought process *

He he :-)

(just keeping this whole copyright discussion theme going... this time from another odd angle... hope it is appreciated :-)

so.. if anyone wants to write the script that John described that would be just GREAT with me!

* although I must admit that I may have had a few thoughts bouncing around along the way that might have been a result of someone elses idea so maybe I cannot claim this is totally and completely my idea after all.... I guess we'll just have to risk it

Chienworks wrote on 1/27/2004, 3:31 PM

In effect, Vegas already does sorta do this. The problem, and what causes the slowness, is that Vegas then redoes it for the 2nd frame, and then redoes it again for the 3rd frame, and then again redoes it again for the 4th frame ... etc. On the one hand it would be nice if Vegas could detect that the still image being shown in this frame is identical to the one shown in the last frame and simply reuse what it had just done. On the other hand, i can see how this would be a very dicey thing to figure out since Vegas alows just about everything to change from one frame to the next, what with keyframeable panning, cropping, motion, effects, filters, etc. it could be quite a nightmare. Then again, on the other hand (just call me Zaphod), i think the number of cases in which a still image does just sit there unchanging on the timeline is probably quite significant and the little bit of program intelligence we're talking about could substantially benefit a lot of the renders done by a lot of folks.

Maybe there could be a switch that is automatically set when an image is placed on the timeline that says "this image doesn't change throughout the duration". If any keyframes are placed at all then this switch would automatically be unset. Vegas could then use this switch to decide if the "render once, repeat that DV frame" method would be applicable.

Liam_Vegas wrote on 1/27/2004, 4:19 PM

That's exactly it. It is your description of the "on the other hand" stuff that illustrates the logical spagetti that might result although as you point out it does not seem to be insurmountable.

busterkeaton wrote on 1/27/2004, 4:47 PM

Liam,

Do you work in multiple instances of Vegas? It definitely seems like your work flow would benefit from starting a render in one instance while continuing to edit in another.

Liam_Vegas wrote on 1/27/2004, 6:09 PM

I have thought about doing it like that... but I have not quite managed to implement that concept as well as I might. I need to be able to cut down content from approx 2 hours down to 30 minutes (2 of these every month) and I find it quite difficult to manage this across multiple instances of Vegas. By the time I have decided which bit stays and which bit gets thrown away I have gone through the timeline dozens of times and I even find myself going back to areas that I previously had thought were rock solid. Some of these editing decisions alter the placement of titles and other graphics and that somehow just does not fit too well with splitting it up for rendering. But.. then again... I might just be doing it wrong.

[edit] I have tried working on just the main content editing... rendering that... and then going back and adding titles etc (and I suspect that is the <correct workflow)... but that seems to add additional rendered AVI files to the mix... and while I know space is cheap... I don't have an unlimited budget.

Overall however I do a lot of multi-veg editing. Just for this particular project I have not been able to do that so well.

Thanks

jetdv wrote on 1/28/2004, 6:55 AM

On the one hand it would be nice if Vegas could detect that the still image being shown in this frame is identical to the one shown in the last frame and simply reuse what it had just done.

Kelly, this already happens. On a program I edit every week, we have one section that is a still with a text generated media over it. The still does not zoom and the text does not change. As soon as the first full frame is generated (after the fadein), it zooms to the end very quickly. It is able to do so because the frame has not changed from the previous frame.

Now, if you have a pan/crop applied - no matter how slight - the image IS changing between each frame even if it might not be 100% visible.

Liam_Vegas wrote on 1/28/2004, 8:34 AM

I think if you check my timings for the tests there is something that Vegas is <not> doing "already" otherwise it would have done things more efficiently than my testing appears to prove.

No doubt it <is> doing something to re-use stuff from frame to frame... but it is not <perfect> at it. I tend to believe that if I can figure out a way to manually improve the speed of some operation then a programmer could have figured out a way to do the same thing internally. I am not screaming for a product change here but on the other hand I would not want my testing to be mis-interpreted as that is what I think you must have done (or at least that is the implication of your claim to me). My tests were very specifically defined to include a single event Pan/Crop so there <is nothing> changing from frame to frame in this test.

Alternatively can you point out a mistake in my process that has somehow hidden the fact that Vegas is more efficient than I am giving it credit for?

busterkeaton wrote on 1/28/2004, 10:30 AM

You may be able to set up a workflow where you have your images on separate track from the rest of your project. When you get an image set up the way you want, yout hen just select only the Image in region and choose render loop region only. When you import back into the main project if you need to end this clip, you can just trim it like a regular clip and since it's now avi, it won't re-render upon completion.

Or is this too simplified for you projects?

Liam_Vegas wrote on 1/28/2004, 10:55 AM

Erm.... that is <exactly> what I said that I am now going to do as part of the workflow based upon my tests. I did say that I thought my communications skills are lacking... but I guess that proves it.

[edit] although I did say that I would not do what I think was being suggested earlier which was doing this as a mult-veg project workflow. The "solution" you refer to is the one that my tests were basically proving was the way to go. Now... if I could find the time to write that script... it would be plain sailing!