I'd suggest this project be a "flipbook" playback option. Scoping it down to limited range of frames (i.e. that are assumed to fit into CPU mem), play every frame, and try to hit 24 fps but don't guarantee it. Use a simple fixed texture cache of N frames. Start with just one and download to it before each frame and see which platforms can handle which range of image sizes and fps. Then move up to multiple textures with pipelined, single-threaded downloads (avoid multi-threaded, multi-context OpenGL).
Flipbook functionality will be helpful for examining basic image sequences. It fits better in iv, and should support the existing iv display options (e.g. channels, zoom). A full-fledged video player is a totally different project, larger than the entire iv app. At PDI, we wrote two separate tools and the video tool took twice as long to write. On Fri, Mar 23, 2012 at 5:09 AM, Colin Doncaster <[email protected]>wrote: > I'm not to sure if this was a rhetorical question or not for purpose of > proving a point, but in my not so vast experience it's not unlike what you > need to implement for fast playback of cached geometry which usually > results in fine tuning cache heuristics for read ahead/behind cache > buffers. As you say, it isn't easy to get right and with film makers > demanding 4k 48fps stereo playback the problem isn't getting any simpler. > > * > -- > Colin Doncaster > Peregrine Labs > http://peregrinelabs.com > * > > On 2012-03-23, at 4:03 AM, Larry Gritz wrote: > > On Mar 22, 2012, at 7:24 PM, Panks wrote: > > > I went through iv code today, as it already uses qtimer for 'slide show', > so if I implement the opengl part and use of double PBO, then giving iv a > playback capability won't be a big deal. We can add play, pause and forward > button easily later on. :) > > > Of course, the trick is that we can't read images from disk at 24 fps at > that resolution (I really don't think -- my intuition is that read speed is > probably 1-2 Hz), so a big part of this task is going to be to > intelligently buffer the images so that playback can happen at frame rate. > And we need to deal with detecting and handling gracefully what happens > when somebody wants to play back a stack of frames whose sum is greater > than the amount of GPU texture memory available, which happens pretty fast > -- a 2048x1536 x 3 channel x "half" (2 byte) = 18 MB per frame, you will > fill GPU memory with only several seconds of footage. > > Hey, how does that work? Has anybody here written a good playback app > before? (I haven't.) The one I use at work, for example, seems to be able > to play back essentially infinite amounts of video (I've certainly made it > play tens of seconds, maybe minutes), and it doesn't appear to be showing > me a lossy of lower precision image than when I view the stills, nor do I > ever notice it pausing to refill a buffer (other than when it first starts > up). So do apps like this work, particularly when the full image stack > would exceed RAM? > > Anyway, doing this well is certainly a good sized summer project, don't > fool yourself into thinking it's going to be a simple modification of the > current timer and adding a couple buttons. > > > -- > Larry Gritz > [email protected] > > > _______________________________________________ > Oiio-dev mailing list > [email protected] > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > > > > _______________________________________________ > Oiio-dev mailing list > [email protected] > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > >
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
