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

Reply via email to