Hi Michael, Have you tried your test in Quicktime Player too? QTP is one of the most optimized playback programs on OS X and would, I think, provide a more reliable baseline than NuVJ.
dan -----Original Message----- From: Michael Diehr <[EMAIL PROTECTED]> Date: Sat, 19 Apr 2008 12:11:32 To:Discussion list for users of Quartz Composer <[email protected]> Subject: Re: MovieLoader Patch / Movie Playback Performance Update: We've done more extensive testing of this issue. To recap: While one quicktime movie is playing, loading a second quicktime movie and starting playback causes a noticeable pause in the playback in the first movie. The pause occurs in spite of best efforts to avoid it (using an easy-to-decode format such as Photo JPEG and setting the Cache Hint flag). The problem shows up in more than one application (Quartz Composer and NuVJ) which makes it seem like a fundamental issue in QuickTime itself. The pause seems to be a function of the length (in bytes) of the quicktime movie file and the speed of the hard disk. For example, we ran the following test in NUVJ: On bank A, start a movie playing. On bank B, select a 2nd movie to play : movies are stored on different media (RAM disk, gigabit ethernet server, or internal SATA drive). Movie files are 50-100MB 720x486 photo JPEG clips (roughly 20-50 mbps data rates). Trigger the movie for the first time and observe results, then rapidly switch between 2 bank B movies and observe results on bank A playback. Tests were done in both 10.4 and 10.5. Results & Regression: * RAM Disk : perfect - you can start clips on bank B (and switch between them as rapidly as you want) without bank A pausing. * Gigabit ethernet: poor -- selecting a movie in bank B causes movie playback on bank A to stutter. Rapid switching of clips in bank B causes playback on bank A to stutter severely. However if the bank B movies have the cache hint flag set, the stutter is barely visible. * Internal SATA drive : very poor -- selecting a movie in bank B causes movie playback on bank A to stutter. rapid switching of clips in bank B causes playback on bank A to stop completely (if the bank B movies have the cache hint flag set it's much better). * We get similar results when doing a 2 clip playback in QC (as I reported earlier). * The Photo JPEG codec seems to have a slight performance edge over the Motion JPEG A codec, though the difference is barely noticeable. Conclusions & Questions: It appears as if QuickTime has a relatively slow and blocking process that takes place upon first movie playback, and this process is repeated each time the movie is played, unless the cache hint is on. The delay is proportional to the length (in bytes) of the movie file, and the speed/latency of the hard disk. This is odd behavior, as OS X generally is very aggressive about caching repeatedly accessed disk files in RAM. I suspect that QuickTime is intentionally overriding the cache behavior? The fact that the delay is proportional to the length of the file is also odd -- one would suspect that the initial playback of an easy-to- decode file format (Photo JPEG) would not require the entire file to be scanned or read. Is there perhaps a maximum cache size that is used, such that short movies (< 10MB) are cached in entirety, but longer ones are always re-read from disk? Hints: * the cache hint flag appears to matter -- use it! * there may be no way of avoiding an initial stutter in a movie, when opening a second movie file that is > 10MB. * in extremely performance-critical situations, use of a RAM disk is a good workaround that covers up the problem. Thoughts? From my perspective, which is wanting top performance of many looping clips, this cacheing performance seems like a bug. Since the cache hint flag seems to work, perhaps that's ok. My main concern is with the initial stutter that happens when loading a second movie -- other than using a RAM disk, is there a workaround? On Feb 23, 2008, at 9:13 AM, Michael Diehr wrote: > More info: > > * Asynch mode gives a fairly big performance increase. It does > prevent using different playback speeds, which may be a major > feature limitation. > > * Cacheing -- playing back 2 640x480 looping Photo JPEG movies, each > about 10-20MB long I noticed that the external hard drive was > churning -- checking Activity monitor revealed it was doing about > 60 disk read i/o operations per second. This led me to suspect > that the movies were not being cached at all. Opened each movie in > QuickTime player, edited the video track to enable the "Cache in > RAM" hint. This, in combination with the Asynch mode, reduced the > disk seeking behavior by about 80%. > > * Conclusion: QC is very un-aggressive about cacheing movie frames > in RAM: one can partially work-around this by turning on the "Cache > in RAM" hint in the quicktime movie, AND enabling Asynch mode in the > movie loader. > > The cache behavior is so bad that I'm almost wondering if there is a > bug? I know that OS X is very aggressive about cacheing disk > files, so I'm baffled why two 10MB looping movies wouldn't have been > cached by OS X or QuickTime after the first loop? > > * Question -- option-preferences in QC reveals two cache settings: > QCMaximumCacheRam : 0.00 > QCMaximumCacheVRAM : 0.00 > > What do these do? > > * Feature Request: I think QC should default to be much more > aggressive about caching movie data. Ideally, it would cache both > the decompressed movie frames and the raw movie data, perhaps with > some user-controllable settings as to the % of RAM / VRAM to use. > > * Bug? In a movie loader, when Async mode is off and/or the > CacheInRam hint in the movie is off, it seems as if QC is preventing > the normal OS X disk cache behavior -- is QC perhaps opening the > movies in editable mode or doing something else that is preventing > efficient OS-level disk cacheing? > > * Workaround? I'm going to experiment with using a RAM disk to > cache these movie files, to see if that helps override the poor > cacheing behavior. > > > On Feb 21, 2008, at 10:10 AM, Troy Koelling wrote: > >> You did not mention Asynchronous mode on the movie. That may not be >> an option in all cases but for the cases that it can be used, it is >> good for performance because QuickTime can pre-fetch frames. >> >> On Feb 20, 2008, at 10:49 AM, Michael Diehr wrote: >> >>> I'm trying to maximize movie playback performance under QC. >>> >>> These tests are all with 640x480 Photo JPEG movies, on macbook >>> pros (with ATI1600 and NVIDIA8600 cards). CPU utilization was >>> under 100% in all cases. >>> >>> In the movieloader patch: >>> * disable color correction (little or no effect) >>> * disable high quality hint (small effect) >>> * disable deinterlacing (small-moderate effect) >>> * scale movie to smaller # of pixels (very large effect) >>> >>> Some questions: >>> >>> 1. Why does deinterlacing have any effect. Wouldn't that step be >>> done in CPU/RAM? If so, and CPU was under 100%, why would that >>> affect frame rate? Or is this done in GL? >>> >>> 2. It appears as if the main bottleneck is simply the # of movie >>> pixels that are transferred from RAM to GPU/VRAM per second. It >>> appears fairly linear : double the # of pixels = half the frame >>> rate. >>> >>> I'm wondering if there's a way to speed this up at all -- would it >>> be possible for example to have QC pre-compute the image data into >>> a compressed GL texture format and then send that data to the >>> GPU? Or if one is using a JPEG compressed format, can that data >>> be sent directly to the GPU and decompressed in VRAM? >>> >>> I tried the following pathway: >>> RenderInImage[MovieLoader -> billboard] -> billboard >>> ...while experimenting with texture settings but that seemed to >>> have no effect (other than giving me blank screen with some >>> settings). >>> >>> Thoughts? >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Quartzcomposer-dev mailing list ([email protected] >>> ) >>> Help/Unsubscribe/Update your Subscription: >>> http://lists.apple.com/mailman/options/quartzcomposer-dev/tkoelling%40apple.com >>> >>> This email sent to [EMAIL PROTECTED] >> > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Quartzcomposer-dev mailing list ([email protected] > ) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/quartzcomposer-dev/md03%40xochi.com > > This email sent to [EMAIL PROTECTED] _______________________________________________ Do not post admin requests to the list. They will be ignored. Quartzcomposer-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/quartzcomposer-dev/dan%40danwinckler.com This email sent to [EMAIL PROTECTED]
_______________________________________________ Do not post admin requests to the list. They will be ignored. Quartzcomposer-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
