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. 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.
On Fri, Aug 28, 2015 at 6:02 PM, Xidorn Quan <quanxunz...@gmail.com> wrote: > On Sat, Aug 29, 2015 at 8:27 AM, Robert O'Callahan <rob...@ocallahan.org> > wrote: > > On Sat, Aug 29, 2015 at 8:18 AM, James Ross <ja...@james-ross.co.uk> > wrote: > > > >> Support is certainly poor; Internet Explorer/Trident and Edge both > support > >> negative playback rates on desktop (I haven’t tested mobile) but do so > by > >> simply showing the key frames as they are reached in reverse, in my > testing. > > > > That's not so hard to implement, but it's also mostly useless since > > keyframes are often several seconds apart or more. > > It could be useful for a few usecases like fast-backward. Windows > Media Player does it this way. > > FWIW, QuickTime supports per-frame backward playback if you press and > hold the left arrow. I guess they cannot guarantee the rate, which > makes them require holding the key instead of providing a playback > rate setting. > > - Xidorn >