[x264-devel] Global optimization of keyframes
Nicolas George
nicolas.george at normalesup.org
Mon Dec 27 11:51:27 CET 2010
Le sextidi 6 nivôse, an CCXIX, Jason Garrett-Glaser a écrit :
> This idea has a few problems.
>
> x264 currently makes all frametype decisions in the first pass. It
> also makes various decisions *based on* these frametype decisions,
> such as MB-tree. Changing frametypes in the second pass would require
> either ignoring the inaccuracy of the other decisions, or redoing them
> all.
That makes things difficult indeed.
> Secondly, I don't really get your example. Why would you want
> keyframes at all in that case? Keyframes are for scenecuts, and your
> described video has no scenecuts.
Unless I am mistaken, if the scene is too long, the encoder is expected to
add keyframes at regular intervals to allow seeking (and, for some codecs
but not H.264, tu avoid drifting due to rounding errors). Or am I using the
wrong words.
A stupid encoder would just put these periodic keyframes as far apart as
possible, but a good encoder would place them sometimes early if it detects
a better place. That is the selection of these "better places" that I think
would benefit from global optimization.
For the experiment I made, I forced each frame to be encoded at least once
as a P-frame and once as an I-frame, and used the size difference as an
estimate of the cost of each I-frame (with no B-frames and frameref=1). Then
I selected the set of I-frames that gave the minimal cost while maintaining
a maximum interval of 250 at most.
Unfortunately, it came to nothing, because, apparently, forcing the frame
type from outside prevents x264 from doing some optimizations.
Regards,
--
Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20101227/77b3fdc9/attachment.pgp>
More information about the x264-devel
mailing list