Creative Communities of the World Forums

The peer to peer support community for media production professionals.

Activity Forums VEGAS Pro Video file size for web – How do these guys do it?

  • Video file size for web – How do these guys do it?

    Posted by Frank Manno on January 16, 2011 at 9:58 am

    I’m on a roll with questions.. Last one I promise. 🙂

    This has been bugging me for ages..

    I shoot at 1920×1080 and edit the same and need to always upload a 3-4 minute clip on vimeo.com

    My file sizes are always 300-400meg. I compress with Sony AVC and select a bit rate of around 4,000,000 mbits per second. Anything lower and the quality starts to not look good.

    Now these guys here https://vimeo.com/18245576 , I know use Final Cut and edit the same resolution footage that I do. How do they get their file sizes so small and quality so high for vimeo? The clip above is 66mb.

    I did ask and they said they are doing ‘nothing different’ other than standard final cut / pro res/ whatever apple encoding.

    I do know however that they grade with ‘apple colour’ which is why I guess the colours look nice and blacks look rich.

    I know nothing about apple anything, but I’d really love to be able to match their file sizes.

    Can anyone here recommend any way I can do this on my PC?

    -Frank

    Some contents or functionalities here are not available due to your cookie preferences!

    This happens because the functionality/content marked as “Vimeo framework” uses cookies that you choosed to keep disabled. In order to view this content or use this functionality, please enable cookies: click here to open your cookie preferences.

    Dave Haynie replied 15 years, 4 months ago 4 Members · 10 Replies
  • 10 Replies
  • Dave Haynie

    January 16, 2011 at 4:57 pm

    Is that 66MB on upload, or 66MB in the final Vimeo format?

    Vimeo is recommending HD be encoded at 5Mb/s for HD. That would mean 160MB for that particular video, assuming it’s really in HD (there are plenty of compression artifacts, but if I’m watching at a normal distance from my 24″ monitor, it looks good). Now, like YouTube, Vimeo doesn’t say a great deal about their presentation format (eg, they take your video and encode it into several streaming formats, including HD and SD, and these days, Flash and H.264/AVC versions). But the best possible video you can get with a really good video encoder (for low bitrate, I’d probably use MainConcept AVC in VBR mode, over Sony’s fixed-rate encoder, from Vegas) would be to encode to a format that won’t get changed at all. If I encode to 5Mb/s AVC and AAC, will Vimeo not re-encode it for the HD presentation format?

    It also may help to be sure you do the frame rate matching. If you upload at 1080/60i, and they deliver in 720/30p, you have no control over the de-interlacing OR the final encoding. In short, the more you know about the web streaming site (I’m on Vimeo, but I have generally used YouTube more), the better you can tailor your encoding to the potential damage the web site will do.

    Otherwise, you need sufficiently high quality. Unless upload time is a major issue, you probably don’t need to worry about upload format quite so much… a sufficiently large upload should deliver the best quality that their re-encoding is willing to deliver. Naturally, it helps to start with good video — this video was expertly shot and cut, so yeah, it does look good.

    Here’s a much less well edited video I shot, then uploaded to YouTube from a very high quality 1080p original. YouTube uses a lower bitrate for hosted video in 720p than Vimeo, but essentially, this is about as good as one can get on this video, based on it being recoded by YouTube.

    https://www.youtube.com/watch?v=X1rVPpT47hc

    Some issues are based on the encoder. Some encoders just handle things like fast motion better than others, and that’s where doing your best mastering job at a lower bitrate may pay off. For example, any time you go too fast in an AVC video, the encoder winds up with a few hard choices. It can try to just encode the video, but that’ll lead to visible DCT blocks (what consumers call “pixelized” video). Or they can apply selective blur — another name for a low-pass filter, which will make the encoder’s job much easier, since it reduces the high frequency information in that area. I’m not sure how adaptive either AVC CODEC is at this stuff, though I would expect the 2-pass encoder to have a better shot at doing this right.

    If you can get your video looked fairly decent at a lower bitrate, you can apply those same tricks to a higher bitrate upload, allowing some “room” for the recoding loss-of-quality, but dealing with the trouble areas that the Vimeo or YouTube encoders don’t handle well.

    -Dave

    Some contents or functionalities here are not available due to your cookie preferences!

    This happens because the functionality/content marked as “Google Youtube” uses cookies that you choosed to keep disabled. In order to view this content or use this functionality, please enable cookies: click here to open your cookie preferences.

  • Scott Francis

    January 16, 2011 at 4:57 pm

    If that is 66mb I would like to know as well!!

    Scott Francis
    Mind’s Eye Audio/Video Productions

  • Dave Haynie

    January 16, 2011 at 5:13 pm

    As I said, I’m very skeptical. For one, it does appear to be in HD. Last I really looked into it (about a year ago), Vimeo was streaming their 720p HD at 2500Kb/s (YouTube at 2000Kb/s). If that’s still true, you have about 80MB there.. and they could well have upped the rate.

    All I know for sure… it’s above 1500Kb/s, because I can’t stream in realtime over satellite.

    -Dave

  • Frank Manno

    January 17, 2011 at 1:07 am

    >>Is that 66MB on upload, or 66MB in the final Vimeo format?

    Well 66mb is what is now on vimeo. I basically downloaded the file and it’s 66mb on my drive. I don’t know how big the file was that they uploaded.

    Interesting post though I will try Mainconcept AVC and try to learn about what Vimeo does with the file.. Thanks 🙂

    -Frank

  • Frank Manno

    January 17, 2011 at 1:09 am

    What are you skeptical of? About that clip actually being in HD??

    -Frank

    >>As I said, I’m very skeptical. For one, it does appear to be in >>HD. Last I really looked into it (about a year ago), Vimeo was >>streaming their 720p HD at 2500Kb/s (YouTube at 2000Kb/s). If >>that’s still true, you have about 80MB there.. and they could well >>have upped the rate.

  • Dave Haynie

    January 17, 2011 at 6:05 am

    Ok.. this did get me curious enough to take a closer look. So yeah, the streaming link gives you a 66MiB (69.2MB) file. That’s spot on for 2000kb/s, which is lower bitrate than I was expecting from Vimeo. Could be they use 2500kb/s for 720/30p and drop to 2000kb/s for 720/24p, which is what you have here.

    The original upload was 158MB (they claim… don’t know if that’s really MB or MiB), which is spot on with the 160MB I calculated for this length of video encoded at 5000kb/s.

    Thing is, they’re using variable bitrate, just as I recommended. If you used the Sony encoder on this video, you’d have the whole thing encoded at 5000kb/s on the way up, and 2000kb/s on the way down.

    But look over this video… there’s a little bit of fast motion here and there, but most of it is nearly ideal video for AVC encoding. There’s practically no camera movement, which is the hardest thing for encoders to do well. There’s a whole section of talking heads, lots of scenes that are shot very photographically, with very little movement. Keep in mind, AVC encoders need bits to encode the changes from one frame to another… if they are very few changes, very few new bits need to go into P and B frames.

    The video starts out at around 750kb/s… the opening shot in the dark. The dancing scenes vary from about 1300kb/s to 2800kb/s. The talking heads rately get beyond 2000kb/s, mostly staying in the 1500kb/s, down as low as 1300kb/s. The higher rates here are largely because of the jumping back and forth between the bride and groom, they settle down once the subject stabilizes.

    Then we look at the scene out the window, and bitrate drops to nearly 500kb/s… both a fixed, non-moving subject and blur goes super efficiently into AVC.

    Next, the construction scenes. There’s a fair bit of jumping around, but most scenes have a fixed camera and little motion, also lots of depth-of-field blur. So you see fairly small numbers here, too, a few peaks to 2500kb/s, most under 2000kb/s. The jump to the bride opening packages peaks over 3500kb/s, but drops back down… again, little motion, lots of DOF blur.

    We go to the street scene, and a few sequences peak over 5400Mb/s… keep in mind, this was a 2000kb/s encoding… on average. You also see peaks over 5000kb/s when the groomsmen are walking up, but mostly, lots of sub-2000kb/s sequences. Most of the crowd scenes are shot with shallow DOF, so again, lots of blurring, which encodes very well.

    Some of the early church scenes are peaking up again, near 4000kb/s, as there’s camera motion. Then we see a shot of just the couple, down at 1000kb/s.

    So basically, at least in the delivery video, they’re doing some close to a constant quality encode, with a very wide range of peaks and valleys. Particularly for a video with this kind of variation, you’ll never get close to the same quality at the same bitrate using CBR. On a similar kind of video, I’d set the average bitrate to 2000, the peak to 5500-6000, and run it 2-pass. Try without the de-blocking filter, but if you see block artifacts, run it again with the de-blocking filter and compare.

    -Dave

  • Frank Manno

    January 17, 2011 at 8:33 am

    Hi David thanks for the response and doing some tests.

    Below, are you saying to do this with which codec from within Vegas?

    Sony AVC or MainConcept AVC/ACC? Which should I try? Actually aren’t they both MP4s?

    -Frankie

    >>On a similar kind of video, I’d set the average bitrate to 2000, >>the peak to 5500-6000, and run it 2-pass. Try without the de->>blocking filter, but if you see block artifacts, run it again with >>the de-blocking filter and compare.

  • Frank Manno

    January 18, 2011 at 12:43 pm

    Also forgot to ask –

    Although their footage (and also my footage) is on a 1920×1080 timeline, should I encode for vimeo at 1920×1080 or is that unneccesary?

    What size would you use for vimeo?

    -Frankie

  • Mike Kujbida

    January 18, 2011 at 1:41 pm

    [Frank Manno] “What size would you use for vimeo?”

    From the Vimeo site:

    Compression Guidelines

    Exporting with Vegas for Vimeo HD

  • Dave Haynie

    January 18, 2011 at 11:37 pm

    I’m saying MainConcept, only because Sony AVC doesn’t support VBR. One reason this video looked so good, so small, was the fact the shooting style was mostly just about ideal for AVC-style compression. But the second factor was the variable bitrate compression. You had large chunks well below 1500kb/s, and some segments near 5000kb/s. Assuming the render is essentially working on a constant quality basis, going to CBR, you would be wasting bits on that simpler video, and killing quality when the bit rate wants to jump up.

    -Dave

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy