clipka <ano### [at] anonymousorg> wrote:
> Am 08.07.2018 um 22:12 schrieb Kenneth:
>
> > I still use VirtualDub as well, for certain videos... The interesting
> > thing about VirtualDub... is that the video is saved as all keyframes,
> > by default. My experience in playing
> > back such a 1920X1080 video as-is, is that it stutters on my own computer--
> > probably because that's a LOT of video information to decode on-the-fly.
>
> My guess would be that the stuttering is not due to an excessive amount
> of data to be /decoded/, but rather simply due to an excessive amount of
> data to be /read/ from hard disk.

That's probably the bulk of the problem, I admit, especially for a 1920X1080
video. But I've noticed 'stuttering' even in 960X520 h.264-encoded videos, when
all the frames are keyframes. (For some reason, I think it becomes more apparent
when a video is 'streamed' rather than with direct computer-playback.)

Chuck wrote:
> Key frames - I know what a keyframe is (perhaps), just not how to identify
> them in a video editor. I'm not sure but don't think ProShow gold will
> identify them.

Actually, VirtualDub itself shows which frames are keyframes ("I-frames"), in
the little info bar a the bottom of the playback window. (When a group of
POV-Ray animation images are first loaded into VD, they start off as all
keyframes.)

Essentially, video encoding is more efficient (smaller file size) when it uses
fewer actual keyframes for the final video. The 'in-between' frames (called
"P-frames" and "B-frames") are actually composed of only the *differences*
between an I-frame and its surrounding frames-- with very little quality loss.
Put very simply, those differences are made up of small 8X8- or 16X16-pixel
blocks ("macroblocks".) The encoder tries to find 'matching' macroblocks among
the adjacent frames (even if those blocks have moved during the frame changes.)
It re-uses those blocks when it can, in the adjacent P-frames and B-frames. So
the P's and B's contain much less 'new' information than would otherwise be the
case.

For an ALL-keyframe video, a crude analogy would be as if each individual frame
is encoded as an individual and separate JPEG image. While that's possible to do
(the "motion-JPEG" format does this, as far as I understand), it's not very
efficient-- the video decoder has to decode ALL the macroblocks in each
individual frame on-the-fly.

Post a reply to this message