Joined: 11/4/2007
Posts: 1772
Location: Australia, Victoria
Just a quick note, I feel that these issues may be caused by either the high keyint rates, frame dropping, or a combination of both that we've been using for video encodes. I do feel that it may be worth simply ditching frame dropping and lowering out keyint rates down from 600 to 200-300, the filesize increase isn't really too much anyway and the compatibility is improved dramatically, especially on older computers.
Emulator Coder, Site Developer
Joined: 11/6/2004
Posts: 833
For the record, H264 does not suffer quality degredation with high keyint values the way MPEG4/DivX does. You lower it to provide good seek capabilities.
Joined: 11/4/2007
Posts: 1772
Location: Australia, Victoria
Which is where the problems come in. My laptop has sometimes been unable to be powerful enough to play back my own video encodes sometimes when the videos have keyint values of 600, while the same video with a keyint of 300 wouldn't have a problem. I just kept using them because the Quad Core desktop had no issues playing them, and that no one (until now) reported similar issues. I'm feeling pretty ashamed of myself right now.
sgrunt
He/Him
Emulator Coder
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
The decoding speed isn't going to be affected by the number of key frames unless there are a very large number of key frames - in fact, fewer key frames would, in principle, speed up playback. EDIT: split discussion about keyints over to the encoder's corner.
Publisher
Joined: 4/23/2009
Posts: 1283
DeHackEd wrote:
For the record, H264 does not suffer quality degredation with high keyint values the way MPEG4/DivX does. You lower it to provide good seek capabilities.
Actually it does, you get the pulsing effect. It's partly why opengop has been added for blu-ray due to the fact blu-ray requires keyint to be a keyframe every second or so.
Banned User, Skilled player (1163)
Joined: 12/26/2006
Posts: 231
Location: Lonely City
keyint rates in 500-600(FPS*10) looks better in SD Video.What about --min-keyint(Minimum interval between IDR-frames)?disable?1?25?
work hard
Publisher
Joined: 4/23/2009
Posts: 1283
I usually set it to 1 to allow x264 decide if it really needs consecutive I-frames, to allow it to place it. I don't think it happens very often or at all, so I don't think there will be much of an increase of filesize.
Senior Moderator
Joined: 8/4/2005
Posts: 5769
Location: Away
sgrunt wrote:
in fact, fewer key frames would, in principle, speed up playback
What would be behind that principle? Keyframes should require less processing power—in principle!—because they are complete images that don't require information from other frames. An all-keyframe stream is compatible with any device, while most of them pose limitations on the amount of consecutive b-frames, as those are the most computationally intensive.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
sgrunt
He/Him
Emulator Coder
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
I can't even remember what I was thinking back when I made that comment, so let me try thinking about this again. How much keyframing or not impacts playback would depend on whether you're being limited by decoding speed or by IO speed; if it's decoding speed, then more keyframes would indeed be desirable for the reason stated; if it's by IO speed, fewer keyframes would be desirable on account of reducing the incoming bitrate.
Senior Moderator
Joined: 8/4/2005
Posts: 5769
Location: Away
Well, thankfully, we're not going to deal with I/O bottlenecks at the rates we're using. On the other hand, I'm honestly surprised it's --keyint, and not --b-pyramid or --bframes 16, or anything else like that, slowing down playback on Flygon's machine. </drunkposting>
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.