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. > "GOP"? 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? Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr esn