Best (highest quality; smallest files) compression for web delivery

Hello all,

I have a 70 minute program, edited in FCP7, shot in 1920 x 1080/24p, and edited using ProRes 422 (created via ClipWrap from Sony NEX 6 AVCHD files). I want this material available via an pay-to-download site.

I have polled my viewers, and most will view on a laptop or iPad.

I have been experimenting with outputting 720p for web "HD" delivery. I have been experimenting with "Export via QT conversion"; the resulting file size varies from 310Mb (the lorez version, keyframe every 36 frames; the video is not pretty) all the way to 1.47Gb (which looks great, but will cost me hugely each time someone downloads, assuming they would download a file that big). I have even tried PAL and NTSC 16:9 versions (as I have found that if good enough quality, these will scale nicely from a laptop to an iPad).

So, before I delve into Compressor, I thought I would ask here for recommendations. The material is simple instructional exercise videos, no dissolves, some supers and simple open/closing titles. On-screen movement is not fast (think about reaching a hand up to scratch the back of your neck, as an example).

My big question is, does Compressor do a better job than exporting via QT conversion? And is there a simple way to adjust parameters via an application to get an idea of the output size before running the compression? TIA, KL

Your 1.47GB file corresponds to 2.8 Mbits/sec. A 1280x720/24p H.264 video can have decent quality at that bitrate, but significant further reduction in the bitrate will result in significant loss in quality.

Your original video was on the order of 25 Mbit/sec, also compressed H.264. What are you thinking, going lower and lower?

QuickTime's H.264 coding algorithm might be the same as Compressor's. However Compressor's downsampling (from1920x1080) when using its "Best (Statistical prediction)" setting is advantageous.

Dennis Couzin
Berlin, Germany

Dennis, thanks.

I know that what I am trying to do is heresy in the broadcast world, but a 1.47Gb file is punitively large in the web-based 'watch on the iPad' world of instructional video. It is simply a time-it-takes-to-download disincentive, for a $1.99 program. Not Hollywood, by any stretch of the imagination!

My competitors are using a frame size of 800 x 450 to get the 16:9 format, and program sizes of under 500Mb; this is what I am attempting to compete with.

I re-compressed the program using a number of Compressor options last night and will report back once I get into the studio.

And I will look into the "Best (Statistical prediction)" setting, too.

A few settings for H.264...

Set "key frames" to "automatic" and check frame re-ordering. Make sure it is set to "Best Quality (Multi-pass). Best tip I ever got is to export a short 20-30 second self contained Quicktime Movie set to "current settings" with as much movement as possible. And then try out different frame sizes and frame rates. With H.264, usually when you set the bitrate below a certain threshold, the image falls apart pretty quickly after that, so if you need to reduce the bitrate, you may need to reduce the frame size.

You can try going down to 853x480 and try to go at around 800-1000kb/s and see if the quality is acceptable.

Compressor's "best statistical prediction" is good, occasionally very problematic, but it can be VERY slow. You may want to use "better" option if you don't want to wait for days. Compressor is definitely better than at down scaling than Quicktime Conversion.



www.strypesinpost.com

strypes makes an important point. Kit L's limitation is with bitrate, while he is completely free as to resolution. I recently had to make a 45 second 1920x1080/50p ProRes video emailable! This meant it couldn't exceed about 3.5 Mbit/s. It would be H.264. I left the 50p 50p, because I have a thing about that, but tried various pixel resolutions all at about 3.5 Mbit/s. The 640x360 resolution looked best, so that's what we emailed.

If we change this example to 25p, the H.264 compression leading to comparable quality will be somewhat more than half the bitrate. Roughly, there's some bitrate between 2 Mbit/s and 3 Mbit/s at which 640x360 is the resolution at which H.264 looks best with 25p. This suggests that for even smaller bitrates, even smaller resolutions than 640x360 will look best with H.264. Try them and look.

Dennis Couzin
Berlin, Germany

I thought I had posted a second time yesterday, but maybe not.

I did try strype's suggestion:

Quote
You can try going down to 853x480 and try to go at around 800-1000kb/s and see if the quality is acceptable.

But as you warned, Compressor can be very slow; it reported a time of 16+ hours to do this job... so that's not practical.

So, today, Dennis's suggestion. I like this idea, because another program I have been working on (a different 50' class) needs a similar treatment. Dennis, what utility do you use to get your calculations? TIA, KL

>it reported a time of 16+ hours to do this job

16 hours with "better" quality resize? That doesn't sound sane. I would expect at most 3x real time.

Here's how to speed up Compressor. Most important thing is the exporting a self contained qt movie and using the cluster.

[www.digitalrebellion.com]



www.strypesinpost.com

@ Gerard:

Wow.

Two reasons: this first is that using your recommended 'Export as self-contained QT movie', then sending that file to Compressor speeded up the process considerably, but when I went back to that article you linked to, I realised that I had not set up my cluster as a four core cluster.

This is the result:



Over 90% CPU time devoted to compressing. This is a huge step forward, for me.

And I am still experimenting, but it look as though Part one (the first half) of the program we have been discussing will compress to 290Mb, at 853 x 480, 1,000Kbps. I have not seen the finished job yet, and I can work the parameters more, but this is looking very good, and I cannot thank you all enough.

KL

Update:

The finished files are the best of the lot, so far. I now have two 853 x 480 videos at 1,000Kbps, and both are very manageable sizes (290 and 335Mb, from memory; they are on the other machine); the artifacts and macro-blocking is minimal, and the video looks clean and the sound perfectly adequate for the intended use; and the self-contained files allow other conversions/compressions too, so will keep these.

Splitting the project gave me a 33' file and 37' one; setting up Compressor properly led to compression times of just under and just over an hour—so very much in line with strypes' suggested times of 2–3 times RT. Perfect. Thank you, thank you.