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/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
