Understanding Rendering

FoskeyMedia wrote on 5/19/2015, 9:01 AM
My 40 min - 1 hr video from church services takes from 6-10 hours to render. here's a typical file/ track order from top downt

* Lower 3rds randomly throughout to identify the speaker
* One video track of speaker
* One live audio track (for sync...muted)
* Actual audio track from board (we can't run feed from board to cam yet... working on it)
* third audio track (muted) that is .bwf to mark the spots where we splash the text
* Video track for text (anywhere from 5 - 15 spots through out)
* When text is displayed use Track Motion to minimize speaker video and text on screen
* A Motion Background track to go behind the text and minimized video (this track is normally stretched for pretty much the length of the video. Would it be better to just have it splced and just set in placed where it will be seen instead of running when it's covered up by a track above it ?)

I'm wondering if cutting and copying that motion background and having 7 different instances if better or worse than just one long file. Also, does muting the tracks effect rendering ? Should I delete them (I'd rprefer to keep them in the project incase I need to go back and edit.. but I guess it's not that hard to add them again).

Comments

riredale wrote on 5/19/2015, 10:19 AM
Audio is trivial.

There was some discussion a few months back about how sometimes Vegas would slow down if there was additional video underneath, even if it was covered.

In any event, lots of pixels per frame and a challenging encoding format can make for a long render. Latest versions of Vegas can off-load the rendering to a video card. Choosing the right card can make things much faster.

EDIT: And of course the more power you have for a processor the faster things go.
videoITguy wrote on 5/19/2015, 11:06 AM
Fosko, the process of rendering is mostly about what codec you are rendering from and TO. For example a lossless codec such as MagicYUV renders almost in real time.
Then in order of severity:
1) Format, project settings, and frame-size
2) Compositing in a production setting for fast-turn around is a no-no in workflow.
Please set up your most complex compositing and render to intermediates, then file back into production timeline.

There is no excuse for 40min video - that it takes 8 hrs render. No way. Production workflow optimization will get you this render in less than 3 hrs., much less is possible.
FoskeyMedia wrote on 5/19/2015, 11:41 AM
Thanks..
This may help. Source file size is often between 8 -12 gigs. One thing I know I could/should do is dial back the resolution I'm shooting. It's generally 1080/30fps. I probably don't need to go that high.

The render selection I use is the Internet HD 1080p Audio: 192 Kbps, 48,000 Hz, 16 Bit, Stereo, AAC
Video: 29.970 fps, 1920x1080 Progressive, YUV, 12 Mbps
Pixel Aspect Ratio: 1.000
videoITguy wrote on 5/19/2015, 3:58 PM
Fosko, your source resolution input is totally unnecessary -given where you want to go.

Secondly, your output choice is really far off track.

Goback to squareone. What is your final destination? What is your sourcing choices?
FoskeyMedia wrote on 5/19/2015, 4:40 PM
Final Destination is Web (YouTube)
Source options are varied from SD to 720/60p to 1080/24, 30, and 60p
I work with a Sony HXR NX70- and a Canon XA10

I was going for best qualith (of course) but maybe I'm over doing it.
videoITguy wrote on 5/19/2015, 5:25 PM
What does "best quality" mean?

1) Absolute color faith in original values?
2) Highest pixel resolution of original framing?
3) Least amount of picture stutter in play mode?
4) Download delay to begin play speed?
5) Low Bitrate versus a clear picture?
6) ?

Question: How much control do you believe you have of what Utube does to your video track?
FoskeyMedia wrote on 5/19/2015, 6:56 PM
BEst quality to me means as crisp clear picture as I can get.
I know YouTube compresses the picture and there's a loss in quality...so I figured the better I start out with the better I end up with ?
videoITguy wrote on 5/19/2015, 8:10 PM
You need to read my last post again and really wrap your mind around the concept.

Utube is not a place to display high-resolution even if that is all you want out of it.
Hi-resolution could be achieved with displaying a single picture non-motion - well dare say not on Utube at all with their compression schema. Still-picture database sites will give you hi-resolution.

Please think about your concepts.
riredale wrote on 5/20/2015, 10:14 AM
There has been a lot of discussion on this board over the past few years regarding delivery to YouTube. I'd suggest you do a search based on the term "youtube."

There are quick and easy ways and there are more-sophisticated protocols that deliver the very finest quality--but at considerable effort. Either way, it's common to encode for YouTube delivery and it shouldn't take many hours of rendering time to do it.
pilsburypie wrote on 5/20/2015, 3:58 PM
Try the frameserving method to Handbrake - I've just responed to a post about this. Works very well at low bitrates i.e. 10mbs for youtube and does a great job of it PQ wise. It also kicks Vegas renders into touch speed wise.
musicvid10 wrote on 5/20/2015, 9:16 PM
"...so I figured the better I start out with the better I end up with ?"
Only up to a point. The encoding quality approaches parity with the source on a relatively steep bitrate curve that rapidly decays. So once it starts to flatten out, you're wasting time encoding bits for very little payout in quality.

A graphic representation might look something like the function Y=1-(e^-x) or Y=1-(1/e^x) (only in Quad I, of course). On the Y-scale, 1.0 represents source parity (100% quality), and X-scale "might" be something like 2 Mbps per division for typical 720p web delivery. On Youtube, the ceiling is lower. Hope this visual helps.





Grazie wrote on 5/21/2015, 2:02 AM
MV10, nicely explained. Thanks for sharing this spectre of "diminishing-returns".

Grazie

musicvid10 wrote on 5/21/2015, 10:01 AM
Thanks Graz!

Zelkien69 wrote on 5/21/2015, 10:46 AM
It's the track motion. That will greatly hinder render times.
PeterDuke wrote on 5/21/2015, 11:09 PM
"Thanks Graz!"

Or as the Italians would say:

"Grazie Grazie"