I just discovered that my demo video is recorded at too high a bitrate. It's at 2.8Mbit/s, compared to 1.3-1.8Mbit/s for subscriber videos. That's probably because I used my standard screencast encoding settings (which are set nice and high) for a video that has a lot more motion than my standard screencast.
Fixing this alone will probably do wonders for my conversion rate.
Thanks a million to tankbot for starting the conversation rolling and to alecthomas for helping me to troubleshoot it over email.
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.
Thanks! I have the videos on a geo-balanced CDN which is well overprovisioned, so it should be okay. I just tried it myself and everything seemed fine. Of course, because it's geo-balanced, there could be a problem I'm not seeing. If anybody else has problems, could you let me know?
It's unwatchable for me too. It appears to be buffering fine (I see the gray buffering bar quite a bit ahead), but just stalls and stutters quite a lot.
I should clarify that the video quality was fine, but it would pause for buffering often at the beginning. Once I made it a few minutes in this cleared up. I'm in the Pacific Northwest, USA if that helps with troubleshooting.
jdlshore|12 years ago
I just discovered that my demo video is recorded at too high a bitrate. It's at 2.8Mbit/s, compared to 1.3-1.8Mbit/s for subscriber videos. That's probably because I used my standard screencast encoding settings (which are set nice and high) for a video that has a lot more motion than my standard screencast.
Fixing this alone will probably do wonders for my conversion rate.
Thanks a million to tankbot for starting the conversation rolling and to alecthomas for helping me to troubleshoot it over email.
jdlshore|12 years ago
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.
tankbot|12 years ago
jdlshore|12 years ago
alecthomas|12 years ago
tankbot|12 years ago
hex-|12 years ago