- From: Robert O'Callahan <robert@ocallahan.org>
- Date: Tue, 1 Sep 2015 23:03:54 +1200
- To: Kevin Marks <kevinmarks@gmail.com>
- Cc: WHAT Working Group <whatwg@lists.whatwg.org>
On Tue, Sep 1, 2015 at 8:02 PM, Kevin Marks <kevinmarks@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
Received on Tuesday, 1 September 2015 11:04:23 UTC