Re: [videoblogging] Re: H264 and quicktime 7
- On May 1, 2005, at 11:18 AM, Steve Watkins wrote:
> Thanks for the samples.Hey Steve,
> OK well I see your tests as being extremely promising for h.264.
> If I am thinking correctly Your h.264 example is handling 8 times
> more information than
> the 3ivx sample:
> Your 3ivx is at 320x240 wheras the h.264 at 640x480 has 4 times as
> many pixels. And
> the framerate on your H.264 clip is 30fps as opposed to 15fps in
> the 3ivx example. So
> thats 8 times as much raw video being handled in the h.264 clip,
> but the filesize is only
> twice as big as the 3ivx.
> have I got that right?
Actually, doubling the framerate doesn't double the file size. In
fact it only produces a slight increase. This is something that
seems very counter intuitive but I've run across it before. I have
no idea why this is. Does anybody out there know?
- Yes its because of the way many forms of compression works. They record complete
frames of video only occasionally (keyframes) and other frames are stored like ' what has
changed since the last frame' rather than the entire frame being stored.
If you tell the encoder to make video of a certain datarate, it cant go above that no matter
what framerate and resolution you use, so the file wont be any larger, just more
compressed and more ugly.
When I was talking about 4 and 8 times more information, I was talking about
uncompressed video, how much 'raw information' the video encoder has to squeeze into
whatever datarate you have specified.
So returnign to the tiger store opening video as an example:
The datarate for the 3ivx version is 258kbits/sec
The datarate for the h264 version has beeen set to around 658kbits/sec
These numbers probably include the audio too, but I wont worry about that for now.
So the h.264 codec has been given just over twice as many bits per second in which to
store the video. But it is being told to store the video with 4 times as many pixels and
twice the number of frames = 8 times more raw video information in just over twice as
Anyway the words Ive used to explain this has probably made my explanation not 100%
technically accurate, but hopefully its of some use.
A starting point for testing how good h.264 really is would be to encode with exactly the
same framerate, datarate, keyframe settings, resolution and audio settings as you already
use in 3ivx. Does it look better than 3ivx then?
More from me later once Ive actually managed to do testing on my mac.
Steve of Elbows
--- In email@example.com, Michael Verdi <michael@m...> wrote:
> Hey Steve,
> Actually, doubling the framerate doesn't double the file size. In
> fact it only produces a slight increase. This is something that
> seems very counter intuitive but I've run across it before. I have
> no idea why this is. Does anybody out there know?
- around the 1/5/05 Michael Verdi mentioned about Re: [videoblogging]
Re: H264 and quicktime 7 that:
>Actually, doubling the framerate doesn't double the file size. In1. frame rate can affect file size but it is not symmetrical (double
>fact it only produces a slight increase. This is something that
>seems very counter intuitive but I've run across it before. I have
>no idea why this is. Does anybody out there know?
fps doesn't = double size). This is due to delta frames, key frames
and frame differencing.
2. this is *basic* compression.
3. A good modern codec (eg H.264) should be allowed to auto insert
keyframes. If you override this you're going to produce stoopid sizes.
4. a key frame is the codec saying, hey, I need to remember *all* the
info for this frame, because it is so different from the last one.
Then the codec only remembers what is different from that key frame
for the next n frames. Until *it* decides it needs a new keyframe.
(this is why you let it decide.) Very good codecs do this forwards
and backwards (so how different from last keyframe, how different
from next keyframe).
5. this is why very good codecs do 2 passes, they have to analyse all
6. if you film yourself not moving, against a still background, you
can compress down to about 1 kbit a second and it will look great
(I'm serious). If you jump around all over the place then more
keyframes are needed, there is much more differencing, file size is
7. However, frame size makes a big difference. double frame size (say
160 x 120 to 320 x 240) and you quadruple the amount of data required.
8. However, dropping frame rate can also help since it doesn't have
to draw so much, and you get less key frames (potentially).
9. Never increase the frame rate in compression.
10. Compression is lossy, it throws data away. If you try to add data
then you are asking the codec to invent data it doesn't have. It
would be like compressing to jpeg in photoshop, then converting it to
32bit RGB, and complaining about the crappy quality of your eps
11. Never increase the frame size in compression.
12. Never increase anything in compression.
13. If you manually set keyframes (say every 5 seconds), and you've
got 10 seconds of a vase, then you've added a pile of data that is
100% irrelevant and unneeded.
14. If you are serving off RTSP (real time) then you do manually
insert keyframes. Videbloggers don't use rtsp, we use http (for very