This is a very specific question about how the
seek function (of a video element in HTML5 ) interprets a video, in this case a WEBM format video, and how it specifically relates to the keyframe interval in the process of rendering. encoding of said video.
What it does : The idea is to control the position of a paused video with the mouse scroll wheel… plus each frame of the video is copied to a canvas element, but I think that's unrelated. I mention it just in case.
What to look for: In Chrome (v66) and to a lesser degree in Firefox (v59) scrolling is pretty good when the video is encoded with a Maximum Keyframe Interval of 6 or less, but jumps are seen when the interval is every 24 frames or more. This is noticeable in the video and even more so in the canvas.
FFMPEG : When encoding a video with FFMPEG this is achieved with the option
-g24of Maximum Keyframe Interval. However, the file becomes heavier as we decrease the interval. You can see that there is no difference between the two formats when the video is in
You can switch the video in the snippet with the buttons.
Case 1 : When we use the video encoded with
-g 6the scrolling of the video is acceptable but it increases the size: 6.229 Mb .
FFMPEG string used:
ffmpeg -i INPUT.MOV -c:v libvpx -qmin 0 -deadline best -qmax 50 -crf 1 -b:v 100K -g 6 test/video_g6.webm
Case 2 : When we use the video encoded with
-g 24the scrolling is not smooth and suffers from jumps but the size decreases: 4.477 Mb .
FFMPEG string used:
ffmpeg -i INPUT.MOV -c:v libvpx -qmin 0 -deadline best -qmax 50 -crf 1 -b:v 100K -g 24 test/video_g24.webm
Why does this happen?
-force_key_frames ? Do they have any positive effect? Is it better to use something like
cgop (closed gop)?
I would appreciate any reference to this topic or a more or less detailed explanation of this relationship both for the WEBM container and for MP4 and OGG video.
I'm not so much looking for a magic ffmpeg string (although I'd appreciate it) but rather an explanation of how this relationship between
keyframes and a video
Thank you very much for reading this far.
PS One more thing, if the
seek function only stops at a
keyframe , is it possible that this frame has more quality than the others in such a way that the quality increases when the video stops?
I haven't solved the specific issue but you can already see a demo online with the result, if this question is solved, the load times (the size of the video clips) could be reduced a lot (in theory).
Note: Requires Chrome on desktop with mouse with scroll wheel.
I don't know how to use ffmpeg but the skipping issue is caused by the way video compression methods work.
The keyframes have complete information about what is shown while the other frames only have the variation with respect to the previous frame.
Two things can be deduced from this that serve as an answer to your question:
The more keyframes, the larger the file size. If you have a video with 100 frames, with a keyframe every 6, you have 16 frames in total with all the information to show and 84 with variations. If you had a keyframe every 24, you only have 4 frames with the complete information and 96 with variations. As the most common is that the changes do not affect the entire frame, these are smaller than the keyframes, producing the size variation.
Having to display a frame that is not a keyframe, it is necessary to first read the keyframe and the successive frames until the frame is "assembled" from the previous information. With a keyframe every 6, this implies that at most we would have to go through 5 frames to assemble the image to be displayed, while with a keyframe every 24, that amount rises to 23. The increase in possible frames to go through is what produces that the time of processing is greater and jumps occur.