Hi Jim: Some additional thoughts: * Your camera person kept moving the camera to follow your movements. Not only does this motion take an enormous number of bits to encode, it is also quite distracting (motion sickness, anyone?). Have him/her zoom out a bit & leave the camera still. (I mean _really_ still; use a large heavy tripod to make sure that there's no vibration whatsoever -- any vibration increases the bit rate unnecessarily. This vibration can be eliminated in post-production using various kinds of filters, but these filter will also kill the crispness of the highdef video.) * You do use some high motion video clips which won't work at low frame rates. But the originals of these videos was considerably lower resolution than your 1920x1080/30fps HD. Rather than taking a picture of the video playing, edit in the original video -- this looks considerably better & also takes many fewer bits. * Consider using _variable bit rate_ encoding with a "constant quality" setting (see the ffmpeg documentation). Under these conditions, the compressor will notice that certain material is more challenging for the encoder than other material, and allocate more bits. Thus, when there's no motion -- e.g., a picture of a slide -- the compressor will use very few bits. However, if you include some video clips, the compressor will ramp up the bit rate so as to continue to provide high quality even on challenging material. The problem with "variable bit rate" ("VBR") is that it may cause glitching during real-time playback when the bit rate exceeds the bit rate of the network. Using extremely large playback buffers can help (i.e., use the excellent "VLC" player & adjust its parameters) smooth over these humps in VBR videos. * I rarely watch videos downloaded in real time, but prefer to download them in advance. This enables me to use the VLC player to _speed up_ the video during boring parts -- sometimes to 2X the normal rate. The VLC player is capable of speeding up the audio without affecting the pitch; the speaker doesn't sound like he/she is breathing helium. At 07:40 AM 6/16/2015, James Propp wrote:

Thanks for the suggestions, Henry!

There's still some editing work being done on the file, so it'd be premature to create a low-rate version, except as a proof of principle. I'll guessing that when the final edits are done, I'll avail myself of your kind offer and make your low-rate version available alongside the high-rate version.

I'd be the last person to be able to judge how much value my facial expressions and body language add to the presentation. I expect that Kahn is right about the comparative unimportance of these things when the material is highly technical and there's not really an authorial point-of-view at work. But in more personal presentations (like some of the more impassioned TED Talks I've seen), seeing the speaker adds a lot. My talk falls somewhere in the middle.

I like the suggestion of getting rid of stereo audio, but I just told the video editor "These are my edits, there won't be others", so I'm reluctant to go back on my word. But I'll certainly keep this issue in mind for future videos I make.

Jim

On Tue, Jun 16, 2015 at 10:11 AM, Henry Baker <hbaker1@pipeline.com> wrote: Re your 36-minute video:

Excellent/outstanding math content. However:

This HD (1080p/30fps) video data rate is ~5Mbits/sec, which far exceeds the capabilities of many home networks -- e.g., DSL.

Here are some ways to get the data rate down to a reasonable rate.

1. A math talk never requires 30fps unless you're doing animations. The physics lectures at UCSB KITP use 0.1fps (yes, that's 1/10 of a frame per second = 1 frame every 10 seconds). 0.1fps is perhaps a bit extreme, but even 1 fps is just fine for many/most lectures.

2. Alternatively, put the picture of the lecturer in a little "picture-in-picture" in one of the corners, and use the rest of the screen for the slides. Due to the way video compression works, the slides themselves take almost zero bits to encode, with the bulk of the bits being used to represent the moving picture -- the lecturer.

3. Follow the advice of Sal Khan (of the Khan Academy) and dispense with the picture of the lecturer entirely. He has actually done tests that show that for complex mathematical concepts, looking at the lecturer instead of the blackboard or slides is actually counterproductive. Khan's "disembodied" lectures have been proven extremely effective.

4. Cut down on the resolution of the video. UCSB KITP uses 960x540, which is 1/4 of the number of pixels of 1920x1080. This resolution seems to handle all but the most challenging slides just fine.

5. Try out the various options of ffmpeg to get better compression. I use WinFF (I think this is also available on Linux) as a GUI for ffmpeg, and you can edit the XML files of WinFF to create your own video & audio compression recipes.

6. You don't need stereo audio for most lectures, which can also save a few bits. UCSB KITP uses 16 KHz sampling for a 32.5Kbits/sec "AAC" audio rate.

Bottom line: UCSB KITP gets their video lectures into 65.5 Kbits/sec (half video, half audio), which is a factor of 76x smaller bandwidth than your 3.8 GByte video file.

If you'd like, I can re-encode your video using these parameters to show you what it would look like. However, since much of the video focuses on the speaker, rather than the slides, it won't look as good as the KITP material.