<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>

CC BY-SA 3.0
2014-08-31T08:04:59.343Z
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?
plugincontainer
CC BY-SA 3.0
2014-08-31T16:46:06.783Z
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
timonsku
CC BY-SA 3.0
2014-09-01T13:12:43.253Z
At 150 kbps, the pixels are huge. But at 30 RF (177kps, 6.8 MB) it's still OK.  Thanks for the tips.
plugincontainer
CC BY-SA 3.0
2014-08-30T14:58:19.003Z
2014-08-30T14:58:19.003Z
timonsku
<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>

CC BY-SA 3.0
2014-08-31T04:26:20.457Z
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.
plugincontainer
CC BY-SA 3.0
2014-08-31T11:32:49.877Z
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...
denjello
CC BY-SA 3.0
2014-08-31T12:35:35.953Z
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/
denjello
CC BY-SA 3.0
2014-08-31T15:19:36.497Z
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
plugincontainer
CC BY-SA 3.0
2014-08-31T16:49:24.470Z
h265 is miles away from being a web codec, its not even adopted on the desktop yet
timonsku
CC BY-SA 3.0
2014-09-01T01:52:41.257Z
with soon I meant years, and ffplay can decode vp9 / h265 already (if it's compiled right)
denjello
CC BY-SA 3.0
2014-08-30T13:56:10.990Z
2014-08-30T17:08:16.763Z
2014-08-30T17:08:16.763Z
denjello
<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>

CC BY-SA 3.0
2014-08-30T14:53:36.987Z
Higher or lower framerate doesn't mean the video gets longer or shorter, it just means you show more information in the same interval.
timonsku
<mp4><framerate><webvideos>
Are the properties (bitrate, fps) of my h.264 video OK for the web?
plugincontainer
# 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.  

---

