GNOME Bugzilla – Bug 584429
Change default keyframe setting for the video Theora encoding
Last modified: 2010-08-09 00:45:44 UTC
I have been playing with the Keyframe-force setting used by Cheese for the Theora encoder. I feel that forcing every frame to be a key-frame (or "golden frame" as called in Theora) is a bit overkill (because it creates bigger files). But I may be wrong as I don't know why one (1) was chosen by default in Cheese. Maybe to allow easier editing later? Or to navigate the video easily (without seeking jumps/lags)? To do streaming without transcoding? I tested with keyframe-force 1, 2, 3, 8, 32 and 128 and found that the kayframe interval vs. bitrate curve drop real soon around 8. These videos with a forced key-frame every 8 frames don't feel "laggy" when seeking/browsing them with VLC or Totem (a problem with videos which have very sparse key-frames). And they are smaller than those encoded with keyframe-force=1. I tested the quality setting using both a keyframe-force=1 and keyframe-force=8. The resulting video with with sparser key-frames are half the size for the same quality (both the set in Theora and the apparent one). Also, if using a higher quality setting (+16) the video has the same size but with better quality (for example KF=1 and Q=15 has the same size than KF=8 and Q=31). At first I was thinking about a slide to choose the keyframe interval, or even a check box to use 1 or something like 8; but maybe that would be too confusing either. So I only suggest that the default value be something higher than 1 (like 8), unless there is a reason for using 1. Regards, MV
Created attachment 135713 [details] Keyframe-force vs. bitrate (filesize) The first graph shows how the file bitrate and size drops when the value of keyframe-force is increased. The second graph shows how using a value of 8 for keyframe-force produces smaller video files with the same quality than using a value of 1; or how using a value of 8 for keyframe-force with a higher quality value (+16) produces video files of the comparable size than using a value of 1.
I have to step back here. I always wondered about the reason of that keyframe-force value. I did some git blaming and apparently it was set by Jaap in commit 8ff5ec5363b7a10345ea7841d7380798a9260473 , it was set to "5" before. So, Jaap, was there any particular reason for that setting? Is it still valid?
A pity that we don't use bzr. In that case you could have done some bzr praising ;-) It's a long time ago, that I made this code and I think I copied it from a nokia tablet maemo example. The only reason I can think of why we only use I/keyframe frames is that P and B are computationally harder (because of the motion estimation) to compute so you need more CPU performance. If a keyframe rate of 8 doesn't signficantly impact CPU performance I'd go for that and keep that as a default (No reason to confuse users with this setting)
(In reply to comment #3) > A pity that we don't use bzr. In that case you could have done some bzr > praising ;-) Hehe git serves us well too here :) > If a keyframe rate of 8 doesn't signficantly impact CPU performance I'd go for > that and keep that as a default (No reason to confuse users with this setting) Ok for me too, I don't see any reason against an higher keyframe. Regarding quality I did some test increasing video quality and I noticed that video recording feature becomes unusable as the quality, I was able to record videos with up to 30-35 quality but then the cpu load the preview starts to lose frames and sometimes the video is just empty as in the "netbook" bug. Note that I have a quite recent cpu (core duo 2 1,7 GHz). I'd suggest to set quality parameter a bit higher by default (32?) and maybe make it configurable through gconf for demanding users.
Well now that I tested it better I'm not sure I'm completely for this change. Increasing force-keyframe (and quality as well) has a bad impact on the cpu usage for the encoding. We already have issues with low power cpus (netbook) I'm not sure if it is a good idea to increase video recording load. Maybe we should use a faster encoder if we want high quality videos.
*** This bug has been marked as a duplicate of bug 564957 ***