Youtube and Quicktime Streaming/Fast Start

Andy_L wrote on 2/17/2013, 1:48 PM
For better results, adjust your Quicktime settings to prepare videos for internet streaming...

Is the message I'm getting with all my V12 Sony AVC mp4 uploads to YouTube now.

My vague and hazy understanding of this issue is that there's some sort of bit that quicktime can set to optimize streaming, but which Vegas won't let you set. I've been assuming YouTube does this during conversion, and that there's no real quality hit versus uploading a compliant file, but I haven't seen any recent conversation here on the subject.

Can vegas set the fast start flag? Does it matter?

Comments

Former user wrote on 2/17/2013, 1:50 PM
It doesn't matter with youtube. It does its own thing.

If you were streaming a QT from your website, then it might make a difference.

Dave T2
musicvid10 wrote on 2/17/2013, 8:01 PM
Your upload + processing time to Youtube is greatly reduced with fast start, because the two can occur simultaneously, rather than sequentially. That's why Youtube sends the message; it reduces their server time too.

Some codecs in Vegas allow fast start now. I prefer to encode in Handbrake, which has a checkbox, you can also do it after the fact with AOA MP4 Patch or Drax. Stay away from MP4 FastStart, it has been fraught with problems.
Andy_L wrote on 2/17/2013, 9:10 PM
musicvid,

Are there any Vegas-native codecs with fast start option that you like (as an alternative to Handbrake) for YouTube uploads?
musicvid10 wrote on 2/17/2013, 9:49 PM
In newer versions of Vegas, Mainconcept AVC with "enable progressive download" checked should work great, esp. if not resizing or deinterlacing the output. Since I often do both (1080i->720p), my first choice is still Handbrake.
Andy_L wrote on 2/18/2013, 8:56 AM
Are you thinking Handbrake's advantage is primarily in the deinterlace/scaling stages, and encoding more or less matches Vegas' capabilities?
musicvid10 wrote on 2/18/2013, 11:44 AM
Mainconcept AVC compares favorably to x264 at higher bitrates and on a level playing field. Below ~8 Mbps differences start to show up, and Mainconcept can start to become intolerable below ~4 Mbps, depending on program motion content. Those numbers are approximated to 720p output.

Handbrake utilizes advanced decomb and resizing algorithms that are better than Vegas' in almost all circumstances, although downsizing is not as critical.

www.jazzythedog.com/testing/DNxHD/HD-Guide.aspx
http://www.compression.ru/video/codec_comparison/h264_2012/
Andy_L wrote on 2/18/2013, 12:47 PM
Thanks!

I don't care that much about bitrate differences if everything looks the same above 8Mbps. But maybe I'll do some scaling comps with Handbrake to see how noticeable the difference is--at least to my eyes.
VanLazarus wrote on 2/19/2013, 3:55 AM
Unfortunately, Mainconcept MP4 encoding currently has bugs right now when using the CPU. Weird macroblocking at high bitrates. And I can't use GPU without Vegas 12 crashing.
musicvid10 wrote on 2/19/2013, 8:51 AM
Actually, there's no real point in giving Youtube anything above 8 Mbps; if you'll download their processed video, you'll find their bitrates are pitifully low.
Andy_L wrote on 2/19/2013, 10:09 AM
Well I don't think I've ever heard anyone praise YouTube's encoders, but I would think that giving them a higher bitrate file in (with fewer artifacts) would lead to a better crappy encode out, all else being equal. Never tested that theory, though.
musicvid10 wrote on 2/19/2013, 10:38 AM
Like anything else, there is a point of diminishing returns, effectively approaching 0 at 8Mbps from both ends of the workflow with high-motion, high detail source footage encoded in x264. Jerry, Nick, and I have tested that theory extensively over a two year period, using HD camera footage from a variety of sources. If you'd like to get your feet wet, the jazzythedog page linked above is a good place to start; but that could use a little updating by now, so we eagerly await the results of your tests ;?)

With static footage (think slideshow with no fades), the sweet spot is around 250 Kbps (that's right). It's in the nature of interframe compression.