Regarding adding movie formats to OIIO: I think it's a great idea, and it will be very useful to do things one is prepared to do to images directly to the frames of a movie. The sub-images notion does map well to frames. However, movie formats like Quicktime generally also support any number of video tracks, so it's not just a 1-d array of images, and their notion of time is a bit more complex. They also support audio. It would be annoying to use a tool which claimed to support Quicktime via OIIO to drop so much stuff on the way through.
One thing which has impressed by about OIIO is when you support a format there is every effort to support the whole format, not just the commonly used variants of it. It would be a shame for movie formats to break that trend. I'm not sure how to deal with these conflicting comments, so I'm just saying them. :) --jono On Fri, Mar 23, 2012 at 11:29 AM, Mikael Sundell <[email protected]> wrote: > I agree ( again :) )! > Limit the scope and get basic functionality up and running, would be enough! > I mentioned Quicktime in another post, it will play along nice with adding > sequence support in iv. Someone else sad ffmpeg, does it cover the Quicktime > format as well? > Mikael > > On Fri, Mar 23, 2012 at 6:23 PM, Ciaran Wills <[email protected]> wrote: >> >> >> On Mar 23, 2012, at 1:03 AM, Larry Gritz wrote: >> >> > 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? >> >> I've written one (Although I'm not sure I'd go as far as calling it >> 'good') and it is hard. The trick is to try to keep data streaming from >> disk to memory, decompressing and from memory to the gpu as fast as the >> hardware will let you and all at the same time - so think threads, careful >> caching/memory management and a certain amount of operating system and video >> driver voodoo. Dealing with different GPUs with different capabilities just >> makes it harder still. That's why we're more than happy to pay for RV >> rather than write another one ;) >> >> > 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. >> >> I definitely agree with Daniel - we should limit the initial scope of this >> project to being a in-memory flipbook, and add to it if we get that far >> (hey, did someone say quicktime support?) >> _______________________________________________ >> 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
