I'm not sure if this actually helps, because I haven't been able to reproduce
the issue so far, but at least this should make it less likely the decoder
thread ends up in an infinite loop.
Previously every (internal) update the decoder would advance 0 or 1 frame. Now
it will advance until it catches up. Like before, if it takes too many steps
(5) before catching up, it seeks instead. This should mostly mean seeking
forwards has less latency.
--HG--
branch : minor
This makes the internal API more modular, but the split also forces a cleaner
implementation. It also means the OggDemuxer is now responsible for the
ogg-specific stuff like seeking and (ogg-specific) type detection.
Backported from the love.video-vpx branch of love-experiments
--HG--
branch : minor
Before it would return the playing status of the FrameSync, but a DeltaSync doesn't stop at the end of the video, now it returns the least of the FrameSync and the EOS condition
Instead of returning the frame past our target, now return the frame for our target.
Also defer to rewind implictly, rather than explicitly.
Lastly, detect seeking past the end of the stream, and set EOS appropriately.
The basic APIs are:
video = love.graphics.newVideo("myvideo.ogv")
love.graphics.draw(video, ...) -- Video objects are Drawables.
video:play(), video:pause()
video:getDuration(), video:tell(), video:rewind(), video:seek(seconds)
video:getSource()
video:getWidth(), video:getHeight(), video:setFilter(min, mag)
More advanced APIs include video:setSource(source), video:getStream(), and videostream:setSync.
To use a custom pixel shader when drawing a Video, call the new TexelVideo(texcoords) function instead of Texel(texture, texcoords) in order to get the pixel colors of a video frame.
George Paton
Sasha Szpakowski
Miku AuahDark
Bart van Strien