On Tue, Sep 1, 2015 at 8:02 PM, Kevin Marks <kevinma...@gmail.com> wrote:

> QuickTime supports full variable speed playback and has done for well over
> a decade. With bidirectionally predicted frames you need a fair few buffers
> anyway, so generalising to full variable wait is easier than posters above
> claim - you need to work a GOP at a time, but memory buffering isn't the
> big issue these days.


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".

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. E.g. in a first pass, decode forward and store every Nth frame.
Then as you play backwards you need only redecode N-1 intermediate frames
at time. I don't know whether HW decoder interfaces would actually let you
implement that though...

What QuickTime got right was having a ToC approach to video so being able
> to seek rapidly was possible without thrashing , whereas the stream
> oriented approaches we are stuck with no wean knowing which bit of the file
> to read to get the previous GOP is the hard part.

I don't understand. Can you explain this in more detail?

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