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

Jun 18, 2007 at 8:56pm

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

SUMMARY:

movie playback of 1080p content is substantially lower quzlity using jit.qt.movie @window direct mode than it is using the quicktime playing in fullscreen playback mode.

machine in question: intel mac mini, 1.67 mhz, current system, current max/jit

STEPS TO REPRODUCE

i used the 1080p ratatouille movie trailer here: http://www.apple.com/trailers/disney/ratatouille/ i used quicktime player to export it as a quicktime movie, codec MJPEG A, quality high, no fast start.

i played it with the following patch:

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P message 158 63 30 196617 read;
#P toggle 78 35 15 0;
#P message 240 84 77 196617 window boobah;
#P message 152 163 64 196617 fullscreen 1;
#P newex 85 198 212 196617 jit.window boobah @floating 1 @fsmenubar 0;
#P newex 87 118 155 196617 jit.qt.movie @adapt 1 @unique 1;
#P newex 84 71 51 196617 qmetro 1;
#P connect 4 0 1 0;
#P connect 0 0 1 0;
#P connect 6 0 1 0;
#P connect 3 0 2 0;
#P connect 5 0 0 0;
#P window clipboard copycount 7;

Expected results:

Video smooth like butter.

Actual results:

the resulting compressed movie played back seamlessly with the quicktime player, but when using the following patch, playing it back into a jit.window using @window direct, quality was stuttery and teary.

#32519
Jun 19, 2007 at 12:14am

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.

#107225
Aug 30, 2007 at 8:49am

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

#107226
Aug 30, 2007 at 7:50pm

> use Applescript to control QuickTime player from Max.

Oh ! interesting ! is it hard to do ?

#107227
Aug 30, 2007 at 8:25pm

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 //

http://www.vade.info
abstrakt.vade.info

#107228
Sep 7, 2007 at 2:01am

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

#107229
Sep 7, 2007 at 6:23am

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 //

http://www.vade.info
abstrakt.vade.info

#107230
Sep 12, 2007 at 7:03pm

Anyone care to comment?

v a d e //

http://www.vade.info
abstrakt.vade.info

#107231
Sep 13, 2007 at 9:21am

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

#107232
Sep 13, 2007 at 1:32pm

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

#107233
Sep 13, 2007 at 1:51pm

Hi Vade,

Yes I’d love to comment but, without wanting to sound too bitter,
ever since my last attempt at doing proper fullscreen pal dv mixing
(“Pmac quad 4xdv playback trouble” thread sept. 2006) and failing
miserably I have given up all hope of doing such a thing in jitter.
I’ve kept an archive of the recurring discussions surrounding this
topic and to my knowledge no one, except maybe dekam, dunno, has
managed to come to an agreeable result or solution (= proper
stutterless and ‘artifact-less’ playback when fullscreen mixing two
or more streams of DVPAL or higher resolution material). I’ve done
some more testing since last september, mainly looking for other
software solutions, and I’ve found that the problems I was
encountering were definetely not hardware related (harddrive speeds,
graphic cards, etc.). Software like Catalyst (http://www.samsc-
pm.com/) or Pandora (http://coolux.de/) has no problems doing similar
stuff with similar hardware setups. So my conclusion is that it must
be a problem somewhere inside jitter, and I’m waiting for the next
grand update to see if anything has changed .. In the mean time i’ll
have a look at your patch and report back. Could you possibly put
some testing material online ? (.mov)

best, Gideon.

On 12-sep-2007, at 21:03, vade wrote:

> Anyone care to comment?

#107234
Sep 13, 2007 at 6:09pm

All I can say at this point is that we take these complaints
seriously and are investigating some possible solutions. We can’t
commit to anything at this point and Max 5 is currently our biggest
priority. Since we aren’t a fixed architecture, dedicated video
mixing application, it’s not as easy for us to revisit our threading
model as some of the examples used in comparison. I will say that the
performance is noticeably better than many other programmable
interactive media software environments, but there’s several things
we can do to try and make this better. Thanks for your feedback.

-Joshua

#107235
Sep 13, 2007 at 7:23pm

Thanks Joshua. Sorry for harping/dragging this back up. I think the
issue is really comes down to what people can expect Jitter to do –
and there is some confusion about that very expectation ( I myself am
guilty). We all know Jitter was not designed explicitly for Mixing
HD, and inherits a legacy of non video us and architecture, but there
is no clear delineation, and it seems like users have had mixed
signals about this very topic.

I dont think anyone expects an immediate fix, nor wants it, but is
more confused about what to realistically expect.
I am however very encouraged by your remarks and anxiously look
forward to late next year when more 2.0 news might be available (yes
I am speculating on that date – I know 2.0 is not even in development :)

Thanks,

On Sep 13, 2007, at 2:09 PM, Joshua Kit Clayton wrote:

>
> All I can say at this point is that we take these complaints
> seriously and are investigating some possible solutions. We can’t
> commit to anything at this point and Max 5 is currently our biggest
> priority. Since we aren’t a fixed architecture, dedicated video
> mixing application, it’s not as easy for us to revisit our
> threading model as some of the examples used in comparison. I will
> say that the performance is noticeably better than many other
> programmable interactive media software environments, but there’s
> several things we can do to try and make this better. Thanks for
> your feedback.
>
> -Joshua

v a d e //

http://www.vade.info
abstrakt.vade.info

#107236
Sep 13, 2007 at 8:39pm

But, at a risk of repeating myself, I’d like to mention that there is always the possibility of recording all necessary parameters (including movie times) of your real time performance or mixing patch and making an ‘offline’ render later. The render will contain no hiccups.
Mattijs

#107237
Sep 13, 2007 at 10:11pm

Well, that kind of defeats the realtime nature of Jitter eh? I could
just use aftereffects then no?

;)

On Sep 13, 2007, at 4:39 PM, Mattijs Kneppers wrote:

>
> But, at a risk of repeating myself, I’d like to mention that there
> is always the possibility of recording all necessary parameters
> (including movie times) of your real time performance or mixing
> patch and making an ‘offline’ render later. The render will contain
> no hiccups.
> Mattijs
> –
> SmadSteck – http://www.smadsteck.nl
> Hard- and software for interactive audiovisual sampling

v a d e //

http://www.vade.info
abstrakt.vade.info

#107238
Sep 14, 2007 at 3:22pm

Hehe, 3D studio max is what I had in mind, talking about non-realtime.. ;)

But seriously, performing in low-res but realtime with jitter (thus adding some ‘groove’ and ‘vibe’ and ‘feeling’) and rendering back non-realtime in hi-res can be very interesting if the final product is to be used in a non-realtime production.

Of course it would be utterly ideal if Jitter had the same constant realtime playback performance as quicktime does.

Mattijs

Quote: vade wrote on Fri, 14 September 2007 00:11
—————————————————-
> Well, that kind of defeats the realtime nature of Jitter eh? I could
> just use aftereffects then no?
>
> ;)
>
> On Sep 13, 2007, at 4:39 PM, Mattijs Kneppers wrote:
>
> >
> > But, at a risk of repeating myself, I’d like to mention that there
> > is always the possibility of recording all necessary parameters
> > (including movie times) of your real time performance or mixing
> > patch and making an ‘offline’ render later. The render will contain
> > no hiccups.
> > Mattijs
> > –
> > SmadSteck – http://www.smadsteck.nl
> > Hard- and software for interactive audiovisual sampling
>
> v a d e //
>
> http://www.vade.info
> abstrakt.vade.info
>
>
>
>
>
>
—————————————————-

#107239
Sep 19, 2007 at 7:54pm

Hello, does anybody have experience with 1080i input via a Decklink
Intensity card?
We are using a MacPro 2.66 with 3GB RAM with a Decklink Intensity
card. We have a very basic patch using jit.qt.grab sending the image
directly to a videoplane.
The framerate we get is around 22 fps, even if we put several slabs
between the jit.qt.grab and the videoplane. So it looks like it has
to do with system/hardware limitations.
Are there any tricks to speed this up, is there a faster/better way
to get the grabbed image into the videoplane?
Best Lucas

#107240
Sep 20, 2007 at 9:43am

here’s something for the wishlist – honestly, I’d like to see jitter
use ffmpeg (like mplayer) for more support of codecs and cross-
platform capability, plus what I think is better performance and
handling of dropped frames.

of course, maybe that’s a dream… ffmpeg is not the easiest library
to use, but it works pretty darn well when it does

…and then there could be a linux version sometime in the future…

cheers
evan

On Sep 14, 2007, at 4:22 PM, Mattijs Kneppers wrote:

>
> Hehe, 3D studio max is what I had in mind, talking about non-
> realtime.. ;)
>
> But seriously, performing in low-res but realtime with jitter (thus
> adding some ‘groove’ and ‘vibe’ and ‘feeling’) and rendering back
> non-realtime in hi-res can be very interesting if the final product
> is to be used in a non-realtime production.
>
> Of course it would be utterly ideal if Jitter had the same constant
> realtime playback performance as quicktime does.
>
> Mattijs
>
> Quote: vade wrote on Fri, 14 September 2007 00:11
> —————————————————-
>> Well, that kind of defeats the realtime nature of Jitter eh? I could
>> just use aftereffects then no?
>>
>> ;)
>>
>> On Sep 13, 2007, at 4:39 PM, Mattijs Kneppers wrote:
>>
>>>
>>> But, at a risk of repeating myself, I’d like to mention that there
>>> is always the possibility of recording all necessary parameters
>>> (including movie times) of your real time performance or mixing
>>> patch and making an ‘offline’ render later. The render will contain
>>> no hiccups.
>>> Mattijs
>>> –
>>> SmadSteck – http://www.smadsteck.nl
>>> Hard- and software for interactive audiovisual sampling
>>
>> v a d e //
>>
>> http://www.vade.info
>> abstrakt.vade.info
>>
>>
>>
>>
>>
>>
> —————————————————-
>
>
> –
> SmadSteck – http://www.smadsteck.nl
> Hard- and software for interactive audiovisual sampling

#107241
Sep 4, 2013 at 7:58am

Hello,

I’m resurrecting this because it has been a few years and two versions of Max later and this seems to continue being an issue. Trying to play two 1080p videos using jit.qt.movie gives bad results with the videos stuttering. Exactly the same two videos play simultaneously and completely smooth using standalone QuicktimePlayer. I’ve also tried all sort of different suggestions found here in the forums without any improvement (including using OpenGL). The videos are compressed using Photo JPEG, as suggested by some here in the forums as the best format for Jitter. I also tried using ProRes. For a video installation we had to abort the idea of using Max and resorted to using ArraySync by NaSoLab. It would be nice to be able to use Max instead, though.

Best,

Hector

#264231
Sep 4, 2013 at 8:06am

Hello, have you tried the HAP codec?

http://cycling74.com/toolbox/jit-gl-hap/

#264234
Sep 4, 2013 at 10:50am

another option to jit.gl.hap is to use the 64 bit max6 jit.qt.movie.
the 64 bit version of direct-to-window should perform better than the 32 bit version.

you might even want to try h264 codec with this, if you’re not frequently jumping around in time, or changing speed.

if you don’t want direct-to-window, jit.gl.hap is your best bet.

#264264

You must be logged in to reply to this topic.