Recovering VFR after an NLE forces all your clips to some high frame rate:įFmpeg has an mpdecimate filter that drops similar frames. This is a relatively small effect good h.264 encoders do ok with only 1 reference frame, but it's still somewhat harmful to compression efficiency, and a waste of power / battery life / CPU time on the decompression side to copy memory around decoding and displaying extra frames. h.264 can choose reference frames on a per-block basis. After a foreground object moves in front of some background detail, the encoder can save bits by referencing what it looked like in an older frame before it was obscured.
If all those candidates are the same image, that doesn't give it multiple options to find a better reference for each block.Į.g.
it's still a video, not a slideshow), padding with identical images will make it harder for the encoder to find and exploit that.ĭepending on encoding settings, the encoder will only keep some number of old frames as possible references for new frames, and can only search within a GOP (e.g. There is a compression downside to duplicating frames, though: If there is much redundancy between the different images (i.e. One reason I don't like duplicated frames, though, is that it interferes with single-stepping to go through the images manually. I wouldn't expect problems, but I also wouldn't be surprised if there at least some old hardware players that don't handle it well.Ī frame of all "skip" macroblocks only takes about 20bytes at 1080p, IIRC. Since variable-FPS videos from phones are now out there, hardware player support for them should be expected.
However, smartphones / tablets should have no problem playing variable-FPS video, since they usually record that way when light levels drop. I'd agree with other suggestions to have some duplicated frames, to bring the FPS up to at least 5 or something, just in case of bad players. It cranks up the psy optimizations, because temporal stability isn't an issue for this use-case. x264 won't insert IDR (GOP boundaries) all over the place if the images are somewhat related to each other. Also, players that can only seek to keyframes will seek in really large chunks (2 minutes or so!) if you don't reduce the keyframe interval. mplayer2 and mpv don't have this problem. So there was lag between user input and player response. I think one older player only checked for keyboard input when it displayed a frame. Software player behaviour with low-fps video isn't ideal, in the past. force x264 to not use B frames for this, because not-very-related images will need a lot of I macroblocks, and coding them in B frames is more expensive. I got some useful replies about the technical implications of this from x264 devs on doom9. I've played around with turning a bunch of still photos into a h.264 slideshow, mostly to compare the compression efficiency of JPG vs.
0 kommentar(er)
