4 Replies Latest reply on Nov 6, 2010 9:37 AM by BarryBrum

    Average rendered file size?

    BarryBrum Level 1


      Hey, guys. I just finished my first video with PrPro CS5. I exported it in MPEG-4 to 656x480. It's 10 minutes, 16 seconds long and it carries a file size of 122 MB and. Is that average or is the file overly large for such a short video?


      The assets include 67 images prepared in Photoshop to 720 x 480, seven 3D animated logos and titles, six GenArts Sapphire effects, 28 text titles, 7 minutes of WAV and Mp3 music and voice over, two minutes of stock AVI footage, and 3 minutes of HD new footage.  I uploaded it to my web server to try it out and it starts and stops on the first run-through. Do you think that is a problem with my download speed here or a server issue? Any suggestions as to the ideal bitrate tweak for my next export to bring the size down? Thanks, Barry

        • 1. Re: Average rendered file size?
          Jim_Simon Level 8

          I'm not aware of any surveys or databases that keep track of exported file sizes from Premiere Pro.  Without those, there's no way to know what an 'average' would be.


          Having said that, file size is monitored by duration and bitrate.  All else is largely irrelevant.

          • 2. Re: Average rendered file size?
            Colin Brougham Level 6

            There's really no such animal as an "average" size for a rendered (or exported) video. Typically, you're setting encoding parameters to work best within the environment and variables that you've been dealt.


            Based on the file size and duration you posted (the actual content of the video doesn't really matter too much), you're encoding at about 3Mbps, which is going to be a bit too much for a typical Internet connection to download and buffer fast enough to ensure smooth playback. Depending on the embedded player you're using, you ocassionally have parameters you can set to dictate how much of the video is buffered before playback begins, but again, you simply might run out of gas before you get there.


            I can get pretty good encodes at 640x480 by using a bitrate of about 1Mbps (usually, encoding with 2-pass VBR), and in your case, the file would be about a third of the size. At that bitrate, for each "unit" of video download, you'd have cached three times the duration of video for local playback--probably enough to ensure you don't have any stuttering or stopping. If the quality isn't quite to your liking (I'm generally pretty happy at this bitrate), you have the option of increasing the bitrate (though you might run into the same issue as before, without a dedicated/streaming server), or lowering the frame size. At something like 480x360, for example, you wouldn't be stretching the available bits quite as far, and the video quality will be somewhat higher. Whether that works for your purposes is up to you; that's why I said initially that you have to consider all of the variables and how you plan to distribute/view the video to find the best combination of settings.


            Hope that helps a bit.

            • 3. Re: Average rendered file size?
              BarryBrum Level 1


              Thanks, Colin. I'm using a few different combinations of bit rate and passes, then uploading and viewing them in my server. So far your suggestion of 1mbps and 2 pass VBR offered up in 480x360 hit it right in there for best quality and lower file size. Play back is smooth and quality is good. I appreciate your help. Barry

              • 4. Re: Average rendered file size?
                Colin Brougham Level 6

                Good to hear, Barry. As you'll discover as you play with the various encoding settings, encoding for the web or any other destination is a little bit science, a little bit artistry, and a lot bit alchemy One codec that might look great at a certain bitrate could look totally atrocious at another. Comparing H.264 to MPEG2 is a great example: in general terms, a video encoded with H.264 at X bitrate will look as good or better than a video encoded with MPEG2 at 2X or even 3X bitrate.


                There are other variables that come into play, but it's understandable then why H.264 is the codec du jour. Now, what happens with newer codec implementations, like Google's WebM (formerly On2 VP8), remains to be seen. Just when we start to figure things out, something new comes along


                The take home from this is experiment, experiment, and then experiment some more. There are few hard-and-fast rules about this stuff; if it looks good and you can play it back smoothly, you're on the right track. Have fun!