HD performance with jit.qt.movie in @window direct mode

I've had the same problems with the same setup as you. In the end it seemed the best way to play back HD movies was to use Applescript to control QuickTime player from Max.

Joshua,

I read the video, then press 'window boobah' and without enabling the metro, the video starts playing and is being displayed properly in the window. That's intended behaviour, right?

Then, when I set the window to fullscreen or move the window to another screen, the window stops updating (but the sound continues playing). Only when I switch on the metro the window starts being updated again. And when I switch the metro off it continues being updated properly. Seems a little buggy.

Anyway, I noticed no hiccups of any kind, neither in the small window or fullscreen.

Mattijs

Max 4.6.3, Jitter 1.6.3, Mac OS 10.4.10, Quicktime 7.2.0, Quad Intel 2.66

> use Applescript to control QuickTime player from Max.

Oh ! interesting ! is it hard to do ?

Compare it to straight quicktime player, there are framerate hiccups
(whose size ad frequency vary with your performance settings and
window update intervals), but they are there. I believe this is
because of low priority queues needing to be serviced interrupting/
blocking drawing, but I am speculating about the cause. However, I
have seen this on all systems I work with, from Octo Mac Pros with
Quadro FX 4500's to Powerbooks.

It is not as bad with uncompressed media, and much more noticeable
with higher compressed video (h.264), and again I believe this is
because decompression and drawing happen serially in the same thread
(again, speculation), but regardless of the cause, it is there
regardless of codecs.

And it gets worse when playing that video to a GL world without
direct to window, even with YUV.

On Aug 30, 2007, at 4:49 AM, Mattijs Kneppers wrote:

>
> Joshua,
>
> I read the video, then press 'window boobah' and without enabling
> the metro, the video starts playing and is being displayed properly
> in the window. That's intended behaviour, right?
>
> Then, when I set the window to fullscreen or move the window to
> another screen, the window stops updating (but the sound continues
> playing). Only when I switch on the metro the window starts being
> updated again. And when I switch the metro off it continues being
> updated properly. Seems a little buggy.
>
> Anyway, I noticed no hiccups of any kind, neither in the small
> window or fullscreen.
>
> Mattijs
>
> Max 4.6.3, Jitter 1.6.3, Mac OS 10.4.10, Quicktime 7.2.0, Quad
> Intel 2.66
>
> --
> SmadSteck - http://www.smadsteck.nl
> Hard- and software for interactive audiovisual sampling

v a d e //

www.vade.info
abstrakt.vade.info

Quote: Kyred wrote on Thu, 30 August 2007 13:50
----------------------------------------------------
> > use Applescript to control QuickTime player from Max.
>
> Oh ! interesting ! is it hard to do ?
----------------------------------------------------

The script looks like this:

tell application "Finder"
    open ("/Users/me/Documents/Video/MyVideo.mov" as POSIX file)
end tell

tell application "QuickTime Player"
    set looping of document 1 to true
    present document 1 scale screen
end tell

You can use the tap.applescript external to launch it.

Jean-Marc

But with this method, should you want to queue more than one movie
back to back, as separate files, dont you get the weird QT window
pop over? Can you queue movies seamlessly back to back without
leaving fullscreen at the end of one movie?

Curious , as I have not had the chance to try this in any capacity,
if the above is possible, I wish I knew a few days ago! :)

======

Back to jitter land,

Jitter 1.6.3/Max 4.6.3

I have a patch (attached to this mail) I am using for a performance,
an incredibly paired down/simple qt/gl patch, on a quad 2.5 Ghz G5
with 8GB of ram and NVidia Quadro FX 4500. It cues with movies with
19 jit.qt.movies with @preroll 1, @unique 1, @colormode uyvy, @adapt
1 and @loop 0.

Only one movie plays at a time, and bangs are gated and switched
'around' all others so only one is active. All movies are stopped
untill needed. I have one GL object, a slab, @automatic 0. I use a
uyvy2rgba shader and a simple 'fade to color' custom shader. I have
playback issues if the shaders are not in the pipeline as well, just
so you know.

There are no ui objects. not even an fpsgui. Main timing is triggered
by a qmetro 2.

Playing DVCProHD (that is, 1280x720p@60Hz) footage with this simple
of a patch will continuously stutter. Very visibly.

Direct to window leads to even worse performance (oddly enough). if
I follow the direct to window noaccel route in fullscreen, I get
consistent very low frame rates in full screen, regardless of menubar
being visible or windows being overlayed. Playback seems somewhat
better, but still not in any way shape or form 'right' in a windowed
mode. Replacing 'fullscreen' with a rect message that still takes up
the full screen still results in impressive stuttering for such a
machine. I have this behavior on the quad and on my macbook pro.

For reference, I have benchmarked the drives (they are 90% empty) and
there is more than sufficient disk througput.

Movies can be long, but nothing but playback at rate 1 occurs. this
is simply sending 'start' to the movies.

I have confirmed that Quicktime and Final Cut can play back these
clips to the same size output (second monitor) without any visible
framerate drops, hiccups or glitches.

Converting to UYVU seemed to somewhat improve the situation, but
stuttering still happens.

I have attached a version of the patch with cuing missing. I feel as
though I havent gotten a straight answer from anyone about this when
I send a patch, except the 'it works for me'. Maybe Im better at
seeing stuttering?

I know this topic is a little sore, so apologies Cycling, I really
hope this is not seen as a nagging/get your shit together/etc sort of
a rant, I am attaching the patch in an attempt to isolate or identify
any strategies I (and others) can use to, in the real world, on real
systems in real patches, get top performance with Jitter for high
quality playback.

I feel i should note that, myself withstanding, other people working
with me have noted the stuttering, but deem it somewhat acceptable
(so we are sticking with Jitter for its flexibility and ease to
change cues/timing etc). So it isnt "just me".

Ive also played back these files with the movie and slab help files
with the @adapt 1 added to jit.qt.movie, and see the same stuttering
behavior.

I do not expect or want any immediate fixes for this either, im
simply curious at this point what the response will be. Again,
apologies for bringing /extending this sore topic. Thanks in advance.

p.s. Yes, I am aware that other codecs might free the CPU and
scheduler to do more, but, at this point, I dont think that is much
the issue?

v a d e //

www.vade.info
abstrakt.vade.info

Anyone care to comment?

v a d e //

www.vade.info
abstrakt.vade.info

Hi vade, the attachment doesn't show up on the forum :/

Could you post the attachment via the forum or upload the patch somewhere and post the link?

Thanks,
Mattijs

hello vade, for a playback project last year we made a basic app with
jitter for mixing two pal quicktime files (720*576). we tried
everything we could think of and everything that people on the list
suggested, but it kept stuttering. the ammount of pixels we used with
two files are roughly the same as you do with one file. if you work
on lower resolution the stuttering will probably dissapear......;-(
we are also very interested to know what causes these playback
problems and it would be great to know when they are scheduled to be
solved.
best lucas