On Wed, Sep 2, 2015 at 5:30 AM, David Singer <sin...@apple.com> wrote:

> On Sep 1, 2015, at 4:03 , Robert O'Callahan <rob...@ocallahan.org> wrote:
> > How about a hard but realistic (IMHO) case: 4K video (4096 x 2160), 25
> fps,
> > keyframe every 10s. Storing all those frames takes 250 x 4096 x 2160 x 2
> > bytes = 4.32 GiB. Reading back those frames would kill performance so
> that
> > all has to stay in VRAM. I respectfully deny that in such a case, memory
> > buffering "isn't a big issue”.
> well, 10s is a pretty long random access interval.

It's easy to find sources on the Internet advising people to use 10s
keyframe intervals.

> Now that I think about it, I guess there are more complicated strategies
> > available that would reduce memory usage at the expense of repeated
> > decoding.
> which indeed QuickTime implemented around 10 years ago.

It appears that most platform and HW decoder interfaces are incompatible
with this strategy, so in practice implementing this across platforms is
still a big problem.

Nevertheless we can hope for that situation to improve, and negative
playback rates are implementable for some videos, so it makes sense to me
to leave negative playback rates in the spec.

The movie file structure (and hence MP4) has a table-of-contents approach
> to file structure; each frame has its timestamps, file location, size, and
> keyframe-nature stored in compact tables in the head of the file.  This
> makes trick modes and so on easier; you’re not reading the actual video to
> seek for a keyframe, and so on.

I think every important video container format has some kind of keyframe

lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr

Reply via email to