3 ms·
Nothing at first, though we do validate that frame_rate is <= 300. We'd maybe even applaud you as the first user to try this. (Then we'd ask you to stop.) A FP
by jon_dahl 16y ago
Nothing at first, though we do validate that frame_rate is <= 300. We'd maybe even applaud you as the first user to try this. (Then we'd ask you to stop.)
A FPS-based pricing change is on our radar, though. In both directions: low frame rate video (like screencasts) should , and we'll formalize that soon for both low and high FPS video.
At some point, there is a fine line between protecting against abuse and having easy-to-understand pricing. 2c/minute is much more user-friendly than 2c per 30 frames. We haven't seen much abuse, and 99.9% of our customers use 20-30fps, so this hasn't been a high priority.
- nitrogen 16y agoMaybe you could charge high-volume users by minutes of CPU time used, instead of minutes of video? I suppose this would only make sense if it's possible for a high-fps but low-motion video to be easier to compress than a high-fps high-motion video.
- jon_dahl 16y agoWe considered that at one point. The problem: if we slow down our encoding, we make more money. If we optimize, we make less money. We want to align our incentives with our customers, and we're focused on being as fast as possible. That said, at really high volume, an approach like this can make sense.