Best approach for enlarging your videos: encoding vs runtime stretching
January 24th, 2008 . by polyGeekIf you want to display large videos in your website you have two options:
- Increasing the dimensions of the video encoding - width/height - and making a corresponding increase in your data rate to maintain playback quality, or
- Keeping the encoded dimensions/data rate small and enlarging the width/height of the video at runtime on the client.
The downside to option one is that you use up more bandwidth on your server and the client must be able to accept the data rate you are sending to them.
The downside to option 2 is that the video quality decreases and it places more of a load on your clients machine to do the scaling.
I did some tests on my old Dell laptop. First with a small video - specks below - to see the results of runtime scaling and smoothing.
Video encoding settings for small video below
- Video: 400kb/sec,
- Dimensions: 320×173
- Audio: 96kb/sec
- Keyframe: auto
- Framerate: 30 ( same as source )
( I found that the best way to compare is to start the top video and then the bottom one about 3 seconds later. )
Notice that you can toggle the smoothing and video size.
Large video encoded at 640×346 and 1600bits/sec.
The bottom is encoded at 2x the size of the top one so that we don’t have to scale it - same as source dimensions. The settings are all the same except that I bumped the bits/sec on the video to max out at 1600. That’s because this video has 4x the pixels of the small version. There’s no good way to adjust the data rate but this is an upper bound. I doubt that the bits/sec ever came close to this value. Just as the small version never came close to400kbs.
Here are screen captures of my CPU usage for each of the tests:
Note: I waited for the video to completely download before playing.
From the CPUs standpoint the usage was pretty much the same between viewing a video at it’s native size of 640×346 with the smoothing off verses a video encoded at half the size and then stretched by a factor of 2 by the client and smoothing turned on.
You can compare the two videos and see what the quality looks like. If you have both running at the same time you can see that the bottom version - without scaling - is clearly superior in quality. But is the bandwidth savings worth it? You’re call.
I’d be interested in reading what you think.
[…] did some research on video quality when the video is stretched by 2x and smoothing applied vs natively large video without […]
Hi there,
interesting comparison, thanks very much for this valuable info. It actually looks like the smaller video isnt smoothed, is it?
@Manuel, You’re right, the top video didn’t have smoothing on. It’s fixed now.
You can also toggle the smoothing off/on with the button on the left.
I think what you need to do to make a comparison is to encode both at the same bitrate. Then the question becomes, which is better: a small video at N bits/s stretched to a large size… or a large video at the same N bit/s (unstretched). I believe you’ll find the stretched version works better… but it might depend on the content.
Also, certain dimensions work better than others… see: http://www.adobe.com/devnet/flash/apps/flv_bitrate_calculator/video_sizes.html
@Phillip, good idea. I’ll do that in a follow up post. Thanks for the suggestion and link.