In researching this issue, I found recommendations that 2.5mbps is probably the most you should plan for in North America. I'm not sure how accurate or current that recommendation is, but since I was seeing problems at 2.8mbps, it seems reasonable. (It also might explain why I have such a large proportion of international subscribers.) That said, I'd really love to get my bitrate below 2.0mbps, because that's what my actual videos come in at.
I went into my video export settings and fiddled (and fiddled, and fiddled) and ended up finding a compromise that gave me 1.94mbps at the cost of slightly-visible artifacting during transitions. [1] Bingo! Uploaded, deployed, done.
Well, not entirely done. I'm still using my old settings for most videos, because it doesn't have any visible compression artifacts at all, at least not until you get out the magnifying glass. (I can get away with such high quality because, although my screencasts have more transitions and motion than average, they're still mostly unchanging text.) But I don't want to run into this problem again. It's embarrassing. And I like killing problems dead. DEAD!
So I modified my deploy script to run `ffprobe` and pull out the bitrate for each new video. If it exceeds 1750kbps, I get a warning. And if it exceeds 2000kbps, the script fails. [2] That'll do it.
Of course, the real root cause here is that I don't have visibility into client-side performance issues. Eventually, I'd like to modify the client-side code to report back playback experience. That would have detected this problem much sooner, and it will protect me against CDN/network issues as well, which are particularly hard for me to get visibility into.
Thanks again to tankbot and alecthomas for helping me find this problem.
[1] The settings I ended up with, in case you're curious:
Video encoding: H.264; 24 frames per second; 2250kbps max bit rate; "High" quality; Single-pass
[2] These thresholds are pretty conservative, and I'll increase them if necessary. I like starting with low thresholds because it gives me more visibility into what's going on, at the cost of requiring me to be a bit more hands-on until I get things dialed in.
In researching this issue, I found recommendations that 2.5mbps is probably the most you should plan for in North America. I'm not sure how accurate or current that recommendation is, but since I was seeing problems at 2.8mbps, it seems reasonable. (It also might explain why I have such a large proportion of international subscribers.) That said, I'd really love to get my bitrate below 2.0mbps, because that's what my actual videos come in at.
I went into my video export settings and fiddled (and fiddled, and fiddled) and ended up finding a compromise that gave me 1.94mbps at the cost of slightly-visible artifacting during transitions. [1] Bingo! Uploaded, deployed, done.
Well, not entirely done. I'm still using my old settings for most videos, because it doesn't have any visible compression artifacts at all, at least not until you get out the magnifying glass. (I can get away with such high quality because, although my screencasts have more transitions and motion than average, they're still mostly unchanging text.) But I don't want to run into this problem again. It's embarrassing. And I like killing problems dead. DEAD!
So I modified my deploy script to run `ffprobe` and pull out the bitrate for each new video. If it exceeds 1750kbps, I get a warning. And if it exceeds 2000kbps, the script fails. [2] That'll do it.
Of course, the real root cause here is that I don't have visibility into client-side performance issues. Eventually, I'd like to modify the client-side code to report back playback experience. That would have detected this problem much sooner, and it will protect me against CDN/network issues as well, which are particularly hard for me to get visibility into.
Thanks again to tankbot and alecthomas for helping me find this problem.
[1] The settings I ended up with, in case you're curious:
Video encoding: H.264; 24 frames per second; 2250kbps max bit rate; "High" quality; Single-pass
Audio encoding: AAC; 44.1KHz audio (mono); "Normal" quality; 64kbps audio bit rate
[2] These thresholds are pretty conservative, and I'll increase them if necessary. I like starting with low thresholds because it gives me more visibility into what's going on, at the cost of requiring me to be a bit more hands-on until I get things dialed in.