Answers.Body: <p>I would try and see if you can't reduce the bitrate a little more even, you have a very low resolution here so you might be able to improve it even further. Just take it to a point where you can say the quality is still satisfiable, size matters on the web.
  Handbrake has a lot of options available to tweak the video size. The RF slider being the most straight forward one.</p>
  
  <p>Also like denjello suggested, you may want to offer other formats aswell, preferably webm.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-08-31T08:04:59.343Z
Answers.Text: With Handbrake, I can get that file to 7MB (bitrate 184 kbps) using RF 27. But I also see a Handbrake option to export at an average bitrate, instead of using RF. What's a... good average bitrate?
Answers.UserDisplayName: plugincontainer
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-08-31T16:46:06.783Z
Answers.Text: Depends on your content, the codec is very adaptive.
  Just try it out, its not like it takes long to encode. The only thing that is important is that it looks good, just reduce the bit-rate until it doesn't. I would start with ~150kbps
Answers.UserDisplayName: timonsku
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-09-01T13:12:43.253Z
Answers.Text: At 150 kbps, the pixels are huge. But at 30 RF (177kps, 6.8 MB) it's still OK.  Thanks for the tips.
Answers.UserDisplayName: plugincontainer
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-08-30T14:58:19.003Z
Answers.LastActivityDate: 2014-08-30T14:58:19.003Z
Answers.UserDisplayName: timonsku
Answers.Body: <p>Sure - it seems ok. However, it is also a good idea to offer other types of video for browsers that do not support mp4 / h264. The usual best practice involves supplying mp4, webm and ogg as containers. <a href="http://www.html5rocks.com/en/tutorials/video/basics/" rel="nofollow">This site is a good reference.</a></p>
  
  <p>A back of the napkin calculation:</p>
  
  <p>1000 viewers / month @ 7.4 MB = 7.4 GB / Month.</p>
  
  <p>Which is probably within the acceptable range for a generic server, just make sure the traffic allowed by your server provider can deal with it...</p>
  
  <p>Assuming your server has a gigabit uplink (which is generally a bit more expensive), you could "theoretically" serve this video to 5000 users concurrently, however this won't work with normal apache servers - and it is probably a good idea to host the media files at amazon AWS (or whatever) if you are expecting that kind of traffic.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-08-31T04:26:20.457Z
Answers.Text: let me finish that comment... I have webm copies, done with Avanti/FFmpeg. Thanks for covering a few other points I'm mulling over. I'm getting about 15000 vistors a month for the Flash files. Irony is, in Flash the animation is 440Kb (16 times smaller than the mp4). But for mobiles, there's no alternative but video.
Answers.UserDisplayName: plugincontainer
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-08-31T11:32:49.877Z
Answers.Text: Sure - animations are just little bits of code - not pixel data. However, I disagree that video is your only option. These days many of the things that were previously done with flash can be realized with SVG / Canvas...
Answers.UserDisplayName: denjello
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-08-31T12:35:35.953Z
Answers.Text: And furthermore, soon we will all be using h265 / vp9. I have already had some success installing these and using them with ffmpeg, and it is true, the resulting size is (in my tests) about 30-40% smaller, and yes - it takes longer to encode them. Here is a bit more information:  http://bloggeek.me/h265-vs-vp9/
Answers.UserDisplayName: denjello
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-08-31T15:19:36.497Z
Answers.Text: I spent months converting Flash to Swiffy (including re-doing all the audio, because Swiffy wouldn't loop sounds). It did a great job with animations (SVG/Canvas), but unfortunately on mobiles (Apple and Android), the audio wouldn't play. More here: http://stackoverflow.com/questions/23634866/how-to-make-audio-in-swiffy-html5-files-play-in-mobile-browsers
Answers.UserDisplayName: plugincontainer
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-08-31T16:49:24.470Z
Answers.Text: h265 is miles away from being a web codec, its not even adopted on the desktop yet
Answers.UserDisplayName: timonsku
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-09-01T01:52:41.257Z
Answers.Text: with soon I meant years, and ffplay can decode vp9 / h265 already (if it's compiled right)
Answers.UserDisplayName: denjello
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-08-30T13:56:10.990Z
Answers.LastActivityDate: 2014-08-30T17:08:16.763Z
Answers.LastEditDate: 2014-08-30T17:08:16.763Z
Answers.UserDisplayName: denjello
Body: <p>I'm converting a Flash vector animation to an mp4 video for the web. After trying and failing with <a href="https://www.google.com/doubleclick/studio/swiffy/" rel="nofollow">Swiffy</a>, it's the only way I have of preserving the work "for posterity", once Flash is gone.</p>
  
  <p>When exporting a FLA to MOV, the frame rate changes. For example, an 18 fps FLA comes out as 9.6 fps in the MOV (according to the QT player properties).</p>
  
  <p>Because the animation is jittery, I used Handbrake to export the MOVs as h.264, with framerates of 24, 30 and 60. They look smoother. (I was surprised the time-length of the video doesn't change, I thought at higher framerates it'd speed up). </p>
  
  <p>Anyway, an mp4 produced like this has the following properties (according to the QT player):</p>
  
  <p>Format: H.264, 550 x 250, millions, AAC, Mono, 48 kHz</p>
  
  <ul>
  <li>FPS: 24.00</li>
  <li>File size: 7.41 MB</li>
  <li>Data rate: 202.25 kbit/sec</li>
  <li>Length: 00:05:07.09</li>
  </ul>
  
  <p>My newbie question is: can anyway tell me, at a glance, whether those properties are within the normal range for a video that is meant to be served from a dedicated web server or CDN? </p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-08-30T14:53:36.987Z
Comments.Text: Higher or lower framerate doesn't mean the video gets longer or shorter, it just means you show more information in the same interval.
Comments.UserDisplayName: timonsku
Tags: <mp4><framerate><webvideos>
Title: Are the properties (bitrate, fps) of my h.264 video OK for the web?
UserDisplayName: plugincontainer
ThreadText: # Are the properties (bitrate, fps) of my h.264 video OK for the web?
  
  (Asked by: username_0 on 2014-08-30)
  
  I'm converting a Flash vector animation to an mp4 video for the web. After trying and failing with [Swiffy](https://www.google.com/doubleclick/studio/swiffy/), it's the only way I have of preserving the work "for posterity", once Flash is gone.
  
  When exporting a FLA to MOV, the frame rate changes. For example, an 18 fps FLA comes out as 9.6 fps in the MOV (according to the QT player properties).
  
  Because the animation is jittery, I used Handbrake to export the MOVs as h.264, with framerates of 24, 30 and 60. They look smoother. (I was surprised the time-length of the video doesn't change, I thought at higher framerates it'd speed up).
  
  Anyway, an mp4 produced like this has the following properties (according to the QT player):
  
  Format: H.264, 550 x 250, millions, AAC, Mono, 48 kHz
  
  * FPS: 24.00
  * File size: 7.41 MB
  * Data rate: 202.25 kbit/sec
  * Length: 00:05:07.09
  
  My newbie question is: can anyway tell me, at a glance, whether those properties are within the normal range for a video that is meant to be served from a dedicated web server or CDN?
  
  **Tags:** mp4, framerate, webvideos
  
  > **Comments:**
  > **username_1**: Higher or lower framerate doesn't mean the video gets longer or shorter, it just means you show more information in the same interval.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2014-08-30. Score: 3 | Accepted answer
  
  Sure - it seems ok. However, it is also a good idea to offer other types of video for browsers that do not support mp4 / h264. The usual best practice involves supplying mp4, webm and ogg as containers. [This site is a good reference.](http://www.html5rocks.com/en/tutorials/video/basics/)
  
  A back of the napkin calculation:
  
  1000 viewers / month @ 7.4 MB = 7.4 GB / Month.
  
  Which is probably within the acceptable range for a generic server, just make sure the traffic allowed by your server provider can deal with it...
  
  Assuming your server has a gigabit uplink (which is generally a bit more expensive), you could "theoretically" serve this video to 5000 users concurrently, however this won't work with normal apache servers - and it is probably a good idea to host the media files at amazon AWS (or whatever) if you are expecting that kind of traffic.
  
  > **Comments:**
  > **username_0**: let me finish that comment... I have webm copies, done with Avanti/FFmpeg. Thanks for covering a few other points I'm mulling over. I'm getting about 15000 vistors a month for the Flash files. Irony is, in Flash the animation is 440Kb (16 times smaller than the mp4). But for mobiles, there's no alternative but video.  
  > **username_2**: Sure - animations are just little bits of code - not pixel data. However, I disagree that video is your only option. These days many of the things that were previously done with flash can be realized with SVG / Canvas...  
  > **username_2**: And furthermore, soon we will all be using h265 / vp9. I have already had some success installing these and using them with ffmpeg, and it is true, the resulting size is (in my tests) about 30-40% smaller, and yes - it takes longer to encode them. Here is a bit more information:  http://bloggeek.me/h265-vs-vp9/  
  > **username_0**: I spent months converting Flash to Swiffy (including re-doing all the audio, because Swiffy wouldn't loop sounds). It did a great job with animations (SVG/Canvas), but unfortunately on mobiles (Apple and Android), the audio wouldn't play. More here: http://stackoverflow.com/questions/23634866/how-to-make-audio-in-swiffy-html5-files-play-in-mobile-browsers  
  > **username_1**: h265 is miles away from being a web codec, its not even adopted on the desktop yet  
  > **username_2**: with soon I meant years, and ffplay can decode vp9 / h265 already (if it's compiled right)  
  
  ---
  
  ### Answer by username_1 on 2014-08-30. Score: 1
  
  I would try and see if you can't reduce the bitrate a little more even, you have a very low resolution here so you might be able to improve it even further. Just take it to a point where you can say the quality is still satisfiable, size matters on the web.
  Handbrake has a lot of options available to tweak the video size. The RF slider being the most straight forward one.
  
  Also like username_2 suggested, you may want to offer other formats aswell, preferably webm.
  
  > **Comments:**
  > **username_0**: With Handbrake, I can get that file to 7MB (bitrate 184 kbps) using RF 27. But I also see a Handbrake option to export at an average bitrate, instead of using RF. What's a... good average bitrate?  
  > **username_1**: Depends on your content, the codec is very adaptive. Just try it out, its not like it takes long to encode. The only thing that is important is that it looks good, just reduce the bit-rate until it doesn't. I would start with ~150kbps  
  > **username_0**: At 150 kbps, the pixels are huge. But at 30 RF (177kps, 6.8 MB) it's still OK.  Thanks for the tips.  
  
  ---
  
  