question about variable framerate

[Rasi]

just a general question...

would variable framerate mean....


lets say i have a 1 minute scene, in which there is a moving face in front of a static wall.

would vfr mean that i only have to encode each frame of the static wall ONCE, but set its framerate to a lower timer? while at the same time i encode the moving face with normal 25 (pal) fps?

and if... can vfr frames dynamically change their framerate after this minute, when the scene changes?

if i got the idea of it right, then it is awesome and i am nothing but looking forward to 1st encoders to do it :P

[crusty]

I don't know if it's possible to do what you are saying, but I think variable framerate will work by adjusting the amount of frames on the detected motion, further evaluated by a psychovisual model of how the human eye detects movement. So if you have a still scene, like say a postsign, you will have one frame for that entire scene, and for a scene that the human eye would see as 5 movements per second, it would have 5 frames per second.

But I don't even know if there is some form of psychovisual modelling done at all. It could just be some form of mathematical motion detection.

[Atamido]

What Rasi is talking about has nothing to do with variable frame rate. The background and face are both encoded in each frame. However with MPEG, it basicaly says that there is no change from the previous frame for all of the area that the wall occupies. It works by saying where the changes are from the previous frame.

crusty hit it right on the nail. If you have a scene where you have a perfectly static picture, then you only need to have one frame that lasts a few seconds, instead of many frames per second saying that there was no change from the previous frame.

Currently we are waiting for better support from encoding applications and codecs to better support this. Once it has full support, look forward to ultra low bitrates for those low motion scenes.

[Sirber]

With RV9, the codec uses about ~30kbps when nothing is moving. It's not variable FPS, but it don't take too much space...

[Atamido]

Its all relative. 30kbps isn't much compared to 600kbps. But its a whole lot more than the 0kbps it takes to not have the extra frames.

[duartix]

Just out of curiosity does anyone know how much does a regular (lets say 640x480) dropped frame take in DivX or XVid?
Does it depend on size? Is it a specially tagged frame or a whole set of null macroblocks?

[ooops!]

I tried to do this, some 2 years ago at work. When some of our clients wanted still shots incoporated within their video's.

The stills needed to be 3 seconds long (75frames PAL). I altered the key frame rates for these sections only and tweaked a few other settings.

The process seemed to work ok but ran better from a PC's hard drive. But when burned and run from a CD the results were not so good.

It's a good idea, maybe todays PC's can cope. Not so sure about stand alone DVD players.

If any of you have a DVD with THX 'setup tests' on it. Try extracting the 'audio test' section and re-encoding the .vob to say, DivX. You can get the audio file to playback in real time but getting the video to encode in sync is very difficult. I'm not sure, but this may be an example of what Rasi is saying.

[duartix]

Let me share some numbers after a quick test. XVid compression with 80 frade drop ratio.
"Das Experiment", 720x400, Pal 25 FPS. First seconds of Credits. Almost nothing is moving.
(EDIT)I'm talking about 1 pass quantizer - Q2.

Bitrate values are a bit rounded.

(EDIT) In the hurry calculations were wrong:
In the first seconds, the frames do really get dropped:
Bitrate is (22.38KB - 21.70KB)/2seconds(50 frames) = 0.34 KB/s = 2.72 Kb/s.

(EDIT) These fade in/out credits do exibit some minimal amount of movement, so these frames don't get dropped (I suppose mostly null macroblocks are used)
Bitrate is (209.74KB - 150.87KB)/2seconds(50 frames) = 29,435 KB/s = 235.48 Kb/s.

(EDIT)Well even though 2.75Kb/s is nothing, 235.48 Kb/s is already an expensive bitrate. Assuming you encode it at:
Q8 --> 58.87 Kb/s
Q16 --> 29,435 Kb/s
Q31 --> 15.19 Kb/s

Possibly not much but definately worse than dropping frames or using VFR.

[ooops!]

In actual fact, when you encode the credits at the end of the movie, the bitrate can go quite high. If you are doing an encode using 2pass vbr there is very little advantage including these bitrate changes to your average bitrate total.

This is a good reason for some people don't encode the credits. As well as reducing the overall run time.

If peolpe are keen on seeing/keeping the credits they could be encoded as a separate entity. And spliced back onto the end of the movie.

Doing such, would would help increase the average bitrate of the main movie encode.

[duartix]

Heavily edited my previous post due to severe misscalculations.