Forums > Jitter

Jitter Video Playback – Amatuer or Professional Grade?


rvr
July 1, 2007 | 2:33 am

This is a simple question.

Can jitter be relied upon to provide stable playback at 30 fps
with more than 1 jit-object at 720×486?

If I have just 1 jit.qt.movie object all playsback fine but
I now extract an alpha with let’s say jit.unpack or jit.coerce,
etc, I can surely expect inconsistent playback, despite any
system specs (mine are beefy pc w/intel quad core).

Playback is ok most of the time, but "most of the time" isn’t
good enough for broadcast work.

Is there a consensus on this?

help!!!


July 1, 2007 | 5:01 pm

I would most definitely not use jitter in a broadcast environment.

You can guarantee a stable 30 fps *video signal* output from
something like a Kona card which jitter can output, but that doesnt
guarantee that the content will look like it has a stable 30 fps.

Yeah, I would shy away from that very fast.

On Jun 30, 2007, at 10:33 PM, robert vanrhyn wrote:

>
> This is a simple question.
>
> Can jitter be relied upon to provide stable playback at 30 fps
> with more than 1 jit-object at 720×486?
>
> If I have just 1 jit.qt.movie object all playsback fine but
> I now extract an alpha with let’s say jit.unpack or jit.coerce,
> etc, I can surely expect inconsistent playback, despite any
> system specs (mine are beefy pc w/intel quad core).
>
> Playback is ok most of the time, but "most of the time" isn’t
> good enough for broadcast work.
>
> Is there a consensus on this?
>
>
> help!!!
>
>

v a d e //

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


July 1, 2007 | 9:45 pm

Can anyone run me through exactly why Jitter can’t run smoothly at 30fps (or 25fps)?

I can understand it when you’re doing lots of complicated processing. But when you’re just trying to play back a quicktime with a few objects in the chain? And the processors are barely breaking into a sweat?

Is it to do with where Jitter is getting it’s timing from? From other posts I’m presuming that the metro object is not up to the task…

Is it a deep-rooted issue that is intrinsic to the program architecture? Or is it something that could be sorted out with a ‘timing external’ or something similar?

Could the output be buffered in some way to make it smoother? Even an additional frame delay would be tolerable if it was predictable and gave smooth output. This issue is the single thing that stops me using Jitter for a whole bunch of ‘professional’ projects. Looking forward to doing my design work with a graphics tablet, a Lemur, a Matrox MXO and a (rented in) HD deck. Someday?


July 1, 2007 | 10:13 pm

Well. Its complicated, you could probably improve your timing by

a) if just using playback use direct to window method (see help)

b) not use any UI elements that update rapidly, and if you have to
use qlim to slow them down.

c) if using matrix manipulation
use @unique and qmetro
play with your performance settings to optimize based on your patch
requirements.

d) use clocker message to spawn only one central clock (each metro,
delay, speedlim, qlim etc object spawns its own timer). (only matters
if you are using tons of line/delay etc objects)

and of course, try and optimize your patch.

But, im a professional video engineer as my day job (and a vigilante
jitter programmer at night ), and as far as I can tell, there is some
inherit jitter (pun intended) with the scheduler, and since at most
you will have one extra thread, youre going to hiccup occasionally.

I hope Jitter 2.0 tries to solve some of these issues, but its been
mentioned before numerous times.

On Jul 1, 2007, at 5:45 PM, marcus lyall wrote:

>
> Can anyone run me through exactly why Jitter can’t run smoothly at
> 30fps (or 25fps)?
>
> I can understand it when you’re doing lots of complicated
> processing. But when you’re just trying to play back a quicktime
> with a few objects in the chain? And the processors are barely
> breaking into a sweat?
>
> Is it to do with where Jitter is getting it’s timing from? From
> other posts I’m presuming that the metro object is not up to the
> task…
>
> Is it a deep-rooted issue that is intrinsic to the program
> architecture? Or is it something that could be sorted out with a
> ‘timing external’ or something similar?
>
> Could the output be buffered in some way to make it smoother? Even
> an additional frame delay would be tolerable if it was predictable
> and gave smooth output. This issue is the single thing that stops
> me using Jitter for a whole bunch of ‘professional’ projects.
> Looking forward to doing my design work with a graphics tablet, a
> Lemur, a Matrox MXO and a (rented in) HD deck. Someday?
>
>
>
>

v a d e //

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


July 1, 2007 | 11:47 pm

Thanks for the advice, Vade.

Not much point in using Jitter unless you’re getting into some GL at this point.

will look at clocker more carefully.

In the past, even a simple movie-playing patch has had problems playing back smoothly. (especially in PAL)

normally I run everything from a single qmetro or metro object and use the trigger object.

Inherent jitter sounds bad though. Obviously patches all do different things, but if we can’t get a basic movie player to work accurately, there’s not much of a benchmark.

Here’s what I’d like to do as a minimum:

play a quicktime movie in PAL or NTSC format.
do some minor processing (cropping thru submatrix, colour correction)
display 2 videos on videoplanes in window.
no tearing. locked 25fps or 30 fps playback.
output thru Matrox MXO or similar.

Any chance for Jitter 2.0, cyclists?

Stable playback= commercially viable = prepared to pay more money for product!


July 2, 2007 | 12:05 am

you’re going to have inherit issues with compositing in openGL and
then reading back to main memory to output to the MXO or other type
of professional playback device, since they dont have accelerated 3d
chipsets.

Ill agree with whats below.

If you have fast enough disks, try working with uncompressed
quicktime movies, you’ll get less CPU usage for qt decompression
which is currently not threaded, as far as my understanding is
concerned.

On Jul 1, 2007, at 7:47 PM, marcus lyall wrote:

>
> Stable playback= commercially viable = prepared to pay more money
> for product!
>

v a d e //

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


July 2, 2007 | 12:45 am

mxo runs straight outta the dvi output.

it basically converts dvi to hd-sdi. Sweet!

so whatever you do on the graphics card gets turned into video.

like a fulsom imagepro but cheaper……

M


July 2, 2007 | 2:09 am

Oh. thats fucking sexy. Nevermind then. I havent used a matrox
product in a long time. My bad !
On Jul 1, 2007, at 8:45 PM, marcus lyall wrote:

>
> mxo runs straight outta the dvi output.
>
> it basically converts dvi to hd-sdi. Sweet!
>
> so whatever you do on the graphics card gets turned into video.
>
> like a fulsom imagepro but cheaper……
>
> M

v a d e //

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



rvr
July 2, 2007 | 12:10 pm

Thanx Vade, as usual, your posts are excellent.
Its sooooooooo disappointing max/jitter isn’t ready for prime time. We should all ask Cycling’74 to officially comment on this issue of Jittery playback with Jitter… that’s probably
why they named it Jitter!

Having a "video product" produce unreliable playback at
"video resolution" is not kool. How about a car with oval
wheels… yeah it works.. but would you want to drive it?

C’mon Cycling’74, what’s your position on Jittery playback.
Why isn’t this a TOP PRIORITY!!!

I’m not pissed – just very disappointed. Max/Jitter is very
kool software – but seriously hobbled for professional video
usage.

rvr :<



rvr
July 2, 2007 | 6:39 pm

Hey Guys,

What about the "movie" object via MAX (no jitter).
Since there are no metros involved in its usage, should I expect
perfect playback as long as I have good hard-drive speed?

rvr


July 3, 2007 | 12:43 am

kinda sounds like you could use quartz composer then and save some money. Or are there similar problems there as well?

And if we keep this thread really active, do you think a cyclist will eventually bestow us with some info?

Seriously though, we all realise that we’re asking for a lot here. We haven’t bought a broadcast-spec product, nor are many of people concerned with this.

But. If it could be done, it would seriously open the market up.
It would mean I could actually get paid to use Max. Which would make a huge difference. Still dreaming of doing my moving graphics work with a wacom pen and lemur while humming and pretending I’m in a life drawing class. And smoothly outputting to that hd deck. And receiving cheques for it.
Does anyone else see the attraction?


July 3, 2007 | 3:05 am

I think a much much better option is to make pluggo for jitter, and
output an AE/Core Image compatible plugin that you can then use in
traditional media and more easily mix into existing workflows.

yes, ive made this feature request.
On Jul 2, 2007, at 8:43 PM, marcus lyall wrote:

>
> kinda sounds like you could use quartz composer then and save some
> money. Or are there similar problems there as well?
>
> And if we keep this thread really active, do you think a cyclist
> will eventually bestow us with some info?
>
> Seriously though, we all realise that we’re asking for a lot here.
> We haven’t bought a broadcast-spec product, nor are many of people
> concerned with this.
>
> But. If it could be done, it would seriously open the market up.
> It would mean I could actually get paid to use Max. Which would
> make a huge difference. Still dreaming of doing my moving graphics
> work with a wacom pen and lemur while humming and pretending I’m
> in a life drawing class. And smoothly outputting to that hd deck.
> And receiving cheques for it.
> Does anyone else see the attraction?
>
>

v a d e //

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


July 3, 2007 | 9:31 am

So, the technical essence of this problem is that jit.qt.movie defers all its input to the low priority (main) thread, right? You’d want an output at scheduler rate, which is currently impossible.

So I was thinking about two possible solutions:

a) provide an object that stores matrices and supports scheduler rate access (something like jit.matrixset except that it also defers to main).

b) currently, querying an attribute of any jitter object is also deferred. This is illustrated in the patch below. Now if for example the gettime message to jit.qt.movie in scheduler thread would not be deferred to the main thread, it would be possible to at least record the current times with a separate (scheduler-rate) metro and render the movie back later in a non-realtime situation. In broadcast quality.

#P newex 204 217 32 196617 print;
#P newex 119 154 20 196617 t b;
#P newex 66 94 51 196617 t gettime;
#P toggle 66 34 15 0;
#P newex 204 197 88 196617 mxj WhichThread;
#P newex 66 52 58 196617 metro 100;
#P newex 119 134 57 196617 route time;
#P newex 66 114 63 196617 jit.qt.movie;
#P window linecount 2;
#P comment 179 34 100 196617 make sure overdrive is turned on;
#P connect 3 0 6 0;
#P fasten 3 0 4 0 71 81 209 81;
#P connect 6 0 1 0;
#P connect 2 0 7 0;
#P connect 7 0 4 0;
#P connect 4 0 8 0;
#P connect 5 0 3 0;
#P connect 1 1 2 0;

Mattijs


July 3, 2007 | 10:08 am

And here is what I think could be a solution with the current options:

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P comment 175 205 100 196617 0) read movie file;
#B color 12;
#P comment 405 131 103 196617 4) turn off recording;
#B color 12;
#P window linecount 4;
#P comment 443 300 210 196617 5) this coll will contain the accurate frame times , and can be rendered back in a non-realtime situation , for example with jit.record.;
#B color 12;
#P window linecount 1;
#P comment 404 116 103 196617 2) turn on recording;
#B color 12;
#P newex 450 181 49 196617 t 0 clear;
#P newex 416 180 32 196617 sel 1;
#P newex 387 180 27 196617 t i i;
#P newex 387 240 29 196617 t b f;
#P newex 387 280 38 196617 zl join;
#N counter;
#X flags 0 0;
#P newobj 387 260 66 196617 counter;
#P window linecount 2;
#P comment 65 94 156 196617 preview rate an be anything , for example 12 fps , and jittery too;
#P window linecount 1;
#N coll ;
#P newobj 387 300 53 196617 coll;
#P comment 511 200 181 196617 oversample to 50 fps for 25 fps output;
#P newex 387 200 52 196617 metro 20;
#P toggle 387 116 15 0;
#P newex 387 220 27 196617 f;
#N vpatcher 789 677 1133 933;
#N comlet to movie;
#P inlet 180 29 15 0;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 26 48 29 196617 t b f;
#P newex 44 88 68 196617 prepend time;
#P window linecount 0;
#P newex 216 149 49 196617 !/ 1000.;
#P newex 44 68 35 196617 * 0.6;
#N comlet movie output;
#P outlet 44 148 15 0;
#P window linecount 1;
#P newex 170 189 74 196617 t gettimescale;
#P newex 44 109 136 196617 jit.qt.movie @rate 0 @vol 0;
#P newex 170 169 32 196617 sel 1;
#P newex 170 149 44 196617 zl nth 1;
#P window linecount 0;
#P newex 170 129 103 196617 route read timescale;
#N comlet (float) time to trigger;
#P inlet 26 29 15 0;
#P connect 0 0 10 0;
#P connect 10 1 7 0;
#P connect 7 0 9 0;
#P connect 5 0 4 0;
#P connect 9 0 4 0;
#P connect 10 0 4 0;
#P fasten 11 0 4 0 185 106 49 106;
#P connect 4 0 6 0;
#P connect 8 0 7 1;
#P connect 4 1 1 0;
#P connect 1 0 2 0;
#P connect 2 0 3 0;
#P connect 3 0 5 0;
#P connect 1 1 8 0;
#P pop;
#P newobj 49 205 93 196617 p timescaledmovie;
#P message 143 205 30 196617 read;
#P toggle 49 55 15 0;
#P newex 49 184 27 196617 f;
#P newex 49 73 57 196617 qmetro 80;
#P message 269 48 74 196617 0 , 1000 1000;
#P newex 269 66 40 196617 line;
#P user jit.pwindow 48 227 127 102 0 1 0 0 1 0;
#P comment 49 334 69 196617 preview only;
#P comment 346 48 141 196617 3) play one second of movie;
#B color 12;
#P comment 67 55 100 196617 1) turn on preview;
#B color 12;
#P connect 8 0 6 0;
#P connect 6 0 7 0;
#P connect 7 0 10 0;
#P connect 10 0 3 0;
#P connect 4 0 7 1;
#P connect 9 0 10 1;
#P connect 5 0 4 0;
#P connect 12 0 20 0;
#P connect 20 0 13 0;
#P connect 13 0 11 0;
#P connect 11 0 19 0;
#P connect 19 0 17 0;
#P connect 17 0 18 0;
#P connect 18 0 15 0;
#P connect 22 1 15 0;
#P connect 4 0 11 1;
#P connect 22 0 17 2;
#P connect 19 1 18 1;
#P connect 20 1 21 0;
#P connect 21 0 22 0;
#P window clipboard copycount 27;

Mattijs


August 24, 2007 | 6:59 pm

I was going on about the fact that Jitter doesn’t output at a clean frame-rate. (I know there are also other scheduling issues). But it turns out that very few QT apps do, unless they are in ‘mastering mode’. While researching the Matrox MXO, I found this……

"When Matrox MXO is used with QuickTime-based applications that support the V-out component including Final Cut Pro, Soundtrack Pro, Motion, and After Effects, it operates in ?Mastering Mode?.

:….Matrox MXO patent-pending technology uses the DVI port on your Mac computer in a unique way to provide frame-accurate audio/video output for insert editing and print-to-tape with guaranteed a/v sync……"

patent pending not so good. but frame accurate does…

"Normally when previewing video from a QuickTime application, the native YCbCr video (sometimes inaccurately called ?YUV? video) is converted to the RGB color space for output over the DVI connection. The frame rate of the RGB video does not match the standard for broadcast video. For example, it may be 75 Hz rather than the 59.94 Hz standard for NTSC. The frame sequence, therefore, inevitably includes dropped and/or repeat frames"

which is why you get problems with standards converters..

"….Matrox MXO, on the other hand, takes the YCbCr video from the QuickTime application and sends it directly out over the DVI connection with time-stamping information that allows the MXO box to reconstruct the frame sequence at the broadcast standard frame rate. It also sends eight digital audio tracks that are then embedded in the SDI signal in perfect sync with the video….."

Has anyone got one and tried to get broadcast video out of it?


August 24, 2007 | 7:16 pm

Well, see, the thing here is that Jitter still wont provide clean
framerate to the device. The device will clean this up and output a
solid 59.94/29.97 or whatever standard you want. Same for Decklink
and Kona cards, which I have tried this, and you get a perfectly
standard video signal, but it looks wobbly because jitter is..
jittery :)

from the MXO forums: http://forum.matrox.com/mxo/viewtopic.php?
p=252&sid=af33dc44c79859c043ab9a13bd775352

The MXO works in Mastering mode with any application that is based on
the QuickTime engine and has a *video output component*. If the app
is not based on the QT engine it will not work in Mastering mode.
There is nothing specific that we would be able to tell their
developers other than the above.

Since Jitter does not have a quicktime output component, no joy.
You’d probably not want that anyway, as youd have to readback from
the GPU, and the GPU is where all the fun is at.

THis is also the first I have heard of Mastering Mode in QT. Curious.
I could be wrong about all that though, but it makes sense to me.

On Aug 24, 2007, at 2:59 PM, marcus lyall wrote:

>
> I was going on about the fact that Jitter doesn’t output at a clean
> frame-rate. (I know there are also other scheduling issues). But it
> turns out that very few QT apps do, unless they are in ‘mastering
> mode’. While researching the Matrox MXO, I found this……
>
> "When Matrox MXO is used with QuickTime-based applications that
> support the V-out component including Final Cut Pro, Soundtrack
> Pro, Motion, and After Effects, it operates in ?Mastering Mode?.
>
>
> :….Matrox MXO patent-pending technology uses the DVI port on your
> Mac computer in a unique way to provide frame-accurate audio/video
> output for insert editing and print-to-tape with guaranteed a/v
> sync……"
>
> patent pending not so good. but frame accurate does…
>
> "Normally when previewing video from a QuickTime application, the
> native YCbCr video (sometimes inaccurately called ?YUV? video) is
> converted to the RGB color space for output over the DVI
> connection. The frame rate of the RGB video does not match the
> standard for broadcast video. For example, it may be 75 Hz rather
> than the 59.94 Hz standard for NTSC. The frame sequence, therefore,
> inevitably includes dropped and/or repeat frames"
>
> which is why you get problems with standards converters..
>
> "….Matrox MXO, on the other hand, takes the YCbCr video from the
> QuickTime application and sends it directly out over the DVI
> connection with time-stamping information that allows the MXO box
> to reconstruct the frame sequence at the broadcast standard frame
> rate. It also sends eight digital audio tracks that are then
> embedded in the SDI signal in perfect sync with the video….."
>
> Has anyone got one and tried to get broadcast video out of it?
>
>
>
>

v a d e //

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


August 24, 2007 | 7:17 pm

And interestingly enough, a search for mastering mode quicktime -mxo
(no mxo references) yeilds just about pure noise.

Methinks mastering mode is a marketing gimmic. But ive never worked
with the QT apis so im just shooting from the hip.

On Aug 24, 2007, at 2:59 PM, marcus lyall wrote:

>
> I was going on about the fact that Jitter doesn’t output at a clean
> frame-rate. (I know there are also other scheduling issues). But it
> turns out that very few QT apps do, unless they are in ‘mastering
> mode’. While researching the Matrox MXO, I found this……
>
> "When Matrox MXO is used with QuickTime-based applications that
> support the V-out component including Final Cut Pro, Soundtrack
> Pro, Motion, and After Effects, it operates in ?Mastering Mode?.
>
>
> :….Matrox MXO patent-pending technology uses the DVI port on your
> Mac computer in a unique way to provide frame-accurate audio/video
> output for insert editing and print-to-tape with guaranteed a/v
> sync……"
>
> patent pending not so good. but frame accurate does…
>
> "Normally when previewing video from a QuickTime application, the
> native YCbCr video (sometimes inaccurately called ?YUV? video) is
> converted to the RGB color space for output over the DVI
> connection. The frame rate of the RGB video does not match the
> standard for broadcast video. For example, it may be 75 Hz rather
> than the 59.94 Hz standard for NTSC. The frame sequence, therefore,
> inevitably includes dropped and/or repeat frames"
>
> which is why you get problems with standards converters..
>
> "….Matrox MXO, on the other hand, takes the YCbCr video from the
> QuickTime application and sends it directly out over the DVI
> connection with time-stamping information that allows the MXO box
> to reconstruct the frame sequence at the broadcast standard frame
> rate. It also sends eight digital audio tracks that are then
> embedded in the SDI signal in perfect sync with the video….."
>
> Has anyone got one and tried to get broadcast video out of it?
>
>
>
>

v a d e //

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


August 24, 2007 | 8:30 pm

On Aug 24, 2007, at 12:16 PM, vade wrote:

>
> Since Jitter does not have a quicktime output component, no joy.
> You’d probably not want that anyway, as youd have to readback from
> the GPU, and the GPU is where all the fun is at.

I would need to do more research before commenting on "mastering
mode", as this is the first I’d heard of it, but if the matrox has a
QT video output component, jit.qt.videoout will work with it just
like it does for DV, Media-100 cards, etc. on Macintosh. On windows,
we only support DV with jit.dx.videoout.

In general for future major upgrades, we’re considering ways to
improve stable clock timing for video output, but it will require
some alternate threading models, and possibly some different video
specific objects.

-Joshua


August 24, 2007 | 8:38 pm

I have to say, as someone who gets paid to watch/configure/set up
professional gear all the time, seeing those small but noticeable
hiccups in Jitter is really disheartening from an end user
perspective. Id say its really my largest complaint quality of life
wise.

Id really be more than happy to abandon some backwards compatibility
for new threading ‘apparati’ and objects.

Thanks! Not trying to prod or rip on jitter, but some constructive
observations!

Id also be very curious professionally about this ‘mastering mode’.
An apple developer docs search yielded nothing either.

:)

On Aug 24, 2007, at 4:30 PM, Joshua Kit Clayton wrote:

>
> On Aug 24, 2007, at 12:16 PM, vade wrote:
>
>>
>> Since Jitter does not have a quicktime output component, no joy.
>> You’d probably not want that anyway, as youd have to readback from
>> the GPU, and the GPU is where all the fun is at.
>
> I would need to do more research before commenting on "mastering
> mode", as this is the first I’d heard of it, but if the matrox has
> a QT video output component, jit.qt.videoout will work with it just
> like it does for DV, Media-100 cards, etc. on Macintosh. On
> windows, we only support DV with jit.dx.videoout.
>
> In general for future major upgrades, we’re considering ways to
> improve stable clock timing for video output, but it will require
> some alternate threading models, and possibly some different video
> specific objects.
>
> -Joshua

v a d e //

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


August 25, 2007 | 9:52 am

"In general for future major upgrades, we’re considering ways to
improve stable clock timing for video output, but it will require
some alternate threading models, and possibly some different video
specific objects."

I cannot express how great this would be.


August 25, 2007 | 10:00 pm

>I think a much much better option is to make pluggo for jitter, >and output an AE/Core Image compatible plugin that you can then >use in traditional media

It would be so great !



rvr
August 27, 2007 | 5:48 pm

Mastering-mode is simply matrox’s term for "outputting to tape".
There is no "Apple Quicktime-Mastermode".
VideoOutComponent (on Macs) is what is necesary for stable
NTSC output.

If Jitter could output stable video I believe my professional
life would change drastically… for the better.

I wonder when Cycling 74 will publically address this issue…
Its so disappointing because Max/Jitter is such an awesome program – so fuc$#@g habit-forming once you GET-IT!

So now I look for other applications because of unstable video..
me soooo sad :<

..but me still love max/jitter :> :<


August 27, 2007 | 6:25 pm

Well, you could always render to disk using something like Render
Node, and save in a broadcast formay lik Uncompressed 4:2:2 and drop
it into FCP :)

On Aug 27, 2007, at 1:48 PM, robert vanrhyn wrote:

>
> Mastering-mode is simply matrox’s term for "outputting to tape".
> There is no "Apple Quicktime-Mastermode".
> VideoOutComponent (on Macs) is what is necesary for stable
> NTSC output.
>
> If Jitter could output stable video I believe my professional
> life would change drastically… for the better.
>
> I wonder when Cycling 74 will publically address this issue…
> Its so disappointing because Max/Jitter is such an awesome program
> – so fuc$#@g habit-forming once you GET-IT!
>
> So now I look for other applications because of unstable video..
> me soooo sad :<
>
>
> ..but me still love max/jitter :> :<
>
>
>
>

v a d e //

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



rvr
August 27, 2007 | 9:09 pm

Vade,

I work in a TV broadcast environment as well… live TV.

I have 20 quicktime clips w/alpha… each clip is under 5 seconds – they are keyable animations actually… 720×486.

I want to be able to INSTANTLY playback any clip via a KEYBOARD
press or MIDI input. I also need to have the alpha extracted
as well because the clips will be keyed with a video switcher -
a Sony MVS 8000…but any switcher will do.

My plan was to use a "Miranda SDI DVIramp2" to extract the
VIDEO and ALPHA imagery straight from the DVI output… as per
DVIramp2 documentation.

There are many ways to build such a patch using Jitter or with
MAX using the MOVIE object. I have built many variations and
they all work very well… except for those damm HICCUPS…
I even see hiccups when not using Jitter! :< ... but not as much.

Yeah, I tried using editing apps but none have the response time of Max/jitter and dont allow for customization… these
apps are closed… you know what I mean…

So I am now going to look into other tools like QComposer,
diadora, cdmx, etc, etc, etc…and some VJ apps… I just keep coming back to max/jitter because… I dunno… I just want
to… I dig it.

But thanx Vade..
much appreciated.


August 27, 2007 | 11:34 pm

There’s a big market out there now for video playback servers for live events. Maybe have a look here, to see how big.

http://samsc-pm.com/index.php?option=com_content&task=view&id=6&Itemid=28

http://www.green-hippo.com/index.php?option=com_content&task=blogcategory&id=14&Itemid=46

http://www.maxedia.com/news.asp?ID=217&Typex=1

http://www.malighting.com/video_media.html

http://www.dataton.com/watchout

All of them are expensive, closed systems. So I don’t want to give these people my money. I want to give it to you. Because you have a community of artists that really want to push the envelope. And your software allows me to build things the way I need them.

But all of these other systems have perfect video timing. This means they can be used on professional jobs today. Video technicians will smile at me. Clients will comment on the smoothness of the playback. I will feel confident that the guitarist, looking at how his hugely magnified arm moves across a screen, will not be distracted by dropped frames. So they get the budget instead.

I’ve had a tiny Jitter patch out on the road with a large rock tour for about 12 months now. The crew have never had a crash. Even the video delay isn’t a problem, as the sound is often 3-4 frames late for a lot of the audience anyway.

But it’s only one scene in amongst many. You don’t notice the glitching too much, but I couldn’t do a whole show using it. We’re just dipping a toe in the water. In theory we could run the whole show from Jitter.

Now I know that non-jumpy video playback through Quicktime and OpenGL is possible, because I just worked on another show that uses Catalyst for playback, and it does just this.

OK, so my use is a little specialised, But what about trade show stands, public LED screen displays, point-of-sale screens, live TV, live concerts and a million other uses where client won’t pay for glitchy video playback? Especially when it’s forty feet high.

I know I’m sounding dreadfully commercial here, but those are the jobs that pay for me to do art. It’s deeply frustrating to know that I can make something great in Jitter, but I can’t use it on 99% of paid jobs because people will moan about the glitchy playback. Why bother to launch fully into Jitter, if you’re going to have to find another way to deliver the idea anyway? It kinda relegates Jitter to being a prototyping tool.

Hmmm. Another rant there. I guess I have a bit to get off my chest. Again, not trying to be critical, just trying to point out the potential for what you have.



rvr
August 28, 2007 | 12:07 am

yesyesyes,

I can blow-away so many "professional-broadcast" products
with max/jitter… if there were no hiccups/stable 30fps :<

maybe someday… :<


August 28, 2007 | 12:08 am

Hi Guys,
In the interest of keeping this critique constructive, could somebody
post an example patch that demonstrates the issue clearly, with
supporting media if necessary?

FYI, there isn’t much action in Jitter-land these days, as all of our
resources are being focussed on the next big version of Max. However,
these issues are important to us, and we hope to address it in some
various ways in a future version of Jitter.

Best,
Andrew B.


August 28, 2007 | 1:33 am

Try playing an uncompressed 1080P movie off of a fast enough disk
into Jitter, with multiple slab processing (order of 10 slabs or more).

This has been mentioned and documented many times. Its CPU/System
dependent, but you can get any system to hiccup.

ie: if someting hiccups on my Macbook Pro, it may not hiccup on a
Quad G5, but, if I push the patch more I can get things to hiccup.

Multiple QT clip playback blocks OpenGL drawing (I saw this quite
often today), even with an idle 30% CPU usage on my performance patch
(lots of OpenGL).

If really need a specific patch, in 2 weeks i may have some breahting
time to document Jitter VS other environments to show the difference
in performance with playback and GL effects.

BTW, I dont think this was a rag on Jitter, I think we all know it
wasnt designed to do this, and those who are trying know damn well
they are pushing it. Its just…. *so close* :)

On Aug 27, 2007, at 8:08 PM, andrew benson wrote:

> Hi Guys,
> In the interest of keeping this critique constructive, could
> somebody post an example patch that demonstrates the issue clearly,
> with supporting media if necessary?
>
> FYI, there isn’t much action in Jitter-land these days, as all of
> our resources are being focussed on the next big version of Max.
> However, these issues are important to us, and we hope to address
> it in some various ways in a future version of Jitter.
>
> Best,
> Andrew B.

v a d e //

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


August 30, 2007 | 2:54 am

andrew, i have. there was no answer from cycling at all.

http://www.cycling74.com/forums/index.php?
t=msg&goto=108347&rid=0&S=e1eb31609661290bc11abd264858ee62&srch=hd
+performance+with+jit.qt.movie#msg_108347

is that sufficient?

On Aug 27, 2007, at 8:08 PM, andrew benson wrote:

> Hi Guys,
> In the interest of keeping this critique constructive, could
> somebody post an example patch that demonstrates the issue clearly,
> with supporting media if necessary?
>
> FYI, there isn’t much action in Jitter-land these days, as all of
> our resources are being focussed on the next big version of Max.
> However, these issues are important to us, and we hope to address
> it in some various ways in a future version of Jitter.
>
> Best,
> Andrew B.
>



rvr
August 30, 2007 | 8:32 pm

regarding smooth multiclip playback via jitter…

I have noticed that if you use a STOP message, then a START
message… you will get smooth playback more consistently,
not always :>, but better…

also, audio will always be in sync if you use a STOP, START.
but these audio issues (on my pc, not mac – mac is fine) may be specific to my pc – not sure – will test further..

anyway, for example…
my BANG triggers a message "time ####, stop, start" to a
jit.qt.movie object. This appears to help a bit.
I use the "time" message because I condensed my 20 clips
into 1 long clip, then loadram the entire clip.

Yes, this doesnt give the HYPER-SUPER-CRAZY cueup/playback
speed of merely sending a "time ####" message only…
buts its fast enough for some of my usages…

rvr



rvr
August 30, 2007 | 8:41 pm

also vade,

regarding disk speed… wouldnt loading an entire clip into ram
via LOADRAM be better than any disk based recalls?

have you ever played with ramdrives?

ive tried commercial apps which make s RAMDRIVE with whatever amount you specify… let my content live in the RAMDRIVE… then still use LOADRAM for my clips… I see no performance
difference…

that kinda tells me that LOADRAM (without RAMDRIVE) is doing
a nice job… i tried this because I wanted to see if diskspeed
was ever a culprit… seems for me… its loadram or nothing.

rvr



rvr
August 30, 2007 | 9:25 pm

marcus,

thanx for those links – those products look like "GVG-profile"
units after they have ingested ECSTACY… instead of NTSC…
very trippy video servers.

IN the US broadcast we use a lot of "grass valley profile
video servers"… but they dont have trippy software like your
links…

but like you… i prefer to "roll my own" :>


August 30, 2007 | 9:49 pm

er. you cant load a 1080p clip into ram, #1. #2, disk access with
those drives are inredibly sub par. Ive read quite a few testimonials
with people moding Mac Book Pros with ramdrives, and all have had
worse performance.

and if you mean Ram Disk, you deal with the OS’s concept of ram,
which also contains virtual memory, which also hits the disk.

This is not a problem with disks, this is a jitter problem, as
Quicktime, QC Modul8, etc, can handle this more robustly.

On Aug 30, 2007, at 4:41 PM, robert vanrhyn wrote:

>
> also vade,
>
> regarding disk speed… wouldnt loading an entire clip into ram
> via LOADRAM be better than any disk based recalls?
>
> have you ever played with ramdrives?
>
> ive tried commercial apps which make s RAMDRIVE with whatever
> amount you specify… let my content live in the RAMDRIVE… then
> still use LOADRAM for my clips… I see no performance
> difference…
>
> that kinda tells me that LOADRAM (without RAMDRIVE) is doing
> a nice job… i tried this because I wanted to see if diskspeed
> was ever a culprit… seems for me… its loadram or nothing.
>
> rvr
>

v a d e //

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


August 30, 2007 | 9:55 pm

*tiny*

This is what I see as one of the issues. It is my belief that these
performance problems come from complicated patches above a certain
threshold of events. I can make a simple one slab 1080p clip playback
fine, but adding more slabs, even if disabled, cause slowdowns (yes,
there is more processing that has to be done), but more importantly,
larger hiccups. I understand reduced performance, but the hiccups are
serious. I can tolerate 20 fps, but not 25->15 ->20 etc.

yes, I know, I know, not constructive, but I think at some point, it
becomes very very hard to submit a bug report of a simple test case,
because inherently the issue is due to the size of the patch, number
of gl calls, or something that becomes an issue as patch complexity
grows.

On Aug 27, 2007, at 7:34 PM, marcus lyall wrote:

> ‘ve had a **********tiny******** Jitter patch out on the road with
> a large

v a d e //

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


August 31, 2007 | 10:49 pm

rvr: the concert stuff I do is very similar to broadcast tv. we use profiles, doremis and 360′s to do playback. same sort of thing.

Very aware that I am trying to replace about $100,000 of dedicated video hardware with home-brew software. It just seems so close…
If FCP and Catalyst can sort out the timing issues, I’m sure it’s possible to sort it out in Jitter.

Not trying to criticise C74′s efforts at all. It’s wonderful to even imagine being able to write my own video software, something I wouldn’t have dreamt of doing ten years ago.

andrew, will do some more testing soon, new mac arriving next week.


September 5, 2007 | 9:15 am

Hi vade and cycling and others following this thread,

Once again, don’t you think the hiccups are inherent to the fact that jit.qt.movie (and everything later in the chain) operate in the low priority queue? Low priority threads are likely to be interrupted by any kind of threads running in the background.

Isn’t what you want simply a jit.qt.movie in the scheduler thread?

Mattijs

Quote: vade wrote on Thu, 30 August 2007 23:55
—————————————————-
> *tiny*
>
> This is what I see as one of the issues. It is my belief that these
> performance problems come from complicated patches above a certain
> threshold of events. I can make a simple one slab 1080p clip playback
> fine, but adding more slabs, even if disabled, cause slowdowns (yes,
> there is more processing that has to be done), but more importantly,
> larger hiccups. I understand reduced performance, but the hiccups are
> serious. I can tolerate 20 fps, but not 25->15 ->20 etc.
>
> yes, I know, I know, not constructive, but I think at some point, it
> becomes very very hard to submit a bug report of a simple test case,
> because inherently the issue is due to the size of the patch, number
> of gl calls, or something that becomes an issue as patch complexity
> grows.
>
>
>
>
> On Aug 27, 2007, at 7:34 PM, marcus lyall wrote:
>
> > ‘ve had a **********tiny******** Jitter patch out on the road with
> > a large
>
> v a d e //
>
> http://www.vade.info
> abstrakt.vade.info
>
>
>
>
>
>
—————————————————-


September 26, 2007 | 11:39 pm

here’s a test patch.

running this patch alongside qt player.

same media on two different fast drives.
qt movie is uncompressed, captured from decklink card.

macpro 8core. 16gb ram.

mostly the playback is excellent, but stuttering after the movie loops around to the start, from then on…

seems to be intermittent. sometimes it’s fine. sometimes not…..

doesn’t seem to be losing time though. was running in sync with the qt player over 4 mins.

max v2;
#N vpatcher 505 182 1746 1044;
#P window setfont "Sans Serif" 9.;
#P message 328 153 29 196617 stop;
#P message 281 151 33 196617 start;
#P comment 223 307 84 196617 set blend amount;
#P flonum 223 323 35 9 0. 1. 3 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 223 344 82 196617 color 1. 1. 1. $1;
#P flonum 523 371 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 485 371 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 445 371 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 417 395 95 196617 pak position 0. 0. 0.;
#P user jit.fpsgui 862 770 60 196617 0;
#P message 357 303 35 196617 1.333;
#P window linecount 2;
#P comment 397 298 238 196617 change x scale to match aspect ratio. e.g. typical 4:3 video would have an x scale of 1.333;
#P flonum 435 324 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 397 324 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 357 324 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 1;
#P newex 332 351 85 196617 pak scale 1. 1. 1.;
#P message 839 652 85 196617 rect 0 0 640 480;
#P toggle 1018 673 15 0;
#P message 1018 691 55 196617 floating $1;
#P hidden message 825 634 68 196617 camera 0 0 4;
#P toggle 945 673 15 0;
#P newex 906 672 35 196617 sel 27;
#P message 945 691 68 196617 fullscreen $1;
#P newex 863 715 229 196617 jit.window jeez1 @depthbuffer 1 @size 720 576;
#P newex 861 672 40 196617 key;
#P newex 47 141 77 196617 t b erase b b b;
#P number 263 508 35 9 0 2 3 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 263 527 45 196617 ortho $1;
#P newex 226 557 93 196617 jit.gl.render jeez1;
#P newex 210 425 265 196617 jit.gl.videoplane jeez1 @blend_enable 1 @depth_enable 1;
#P button 46 112 15 0;
#P button 89 37 15 0;
#P user jit.fpsgui 81 316 60 196617 0;
#P message 142 165 30 196617 read;
#P newex 115 206 218 196617 jit.qt.movie 720 576 @autostart 0 @preroll 1;
#P newex 89 76 58 196617 clocker 40;
#P fasten 0 0 5 0 94 114 51 114;
#P connect 5 0 10 0;
#P connect 10 2 3 0;
#P connect 4 0 0 0;
#P fasten 10 3 1 0 106 180 120 180;
#P fasten 2 0 1 0 147 190 120 190;
#P connect 34 0 1 0;
#P connect 35 0 1 0;
#P connect 1 0 6 0;
#P connect 31 0 6 0;
#P fasten 20 0 6 0 337 396 215 396;
#P fasten 27 0 6 0 422 430 373 430 373 401 215 401;
#P connect 32 0 31 0;
#P fasten 8 0 7 0 268 546 231 546;
#P fasten 10 1 7 0 70 497 231 497;
#P fasten 10 0 7 0 52 518 231 518;
#P connect 9 0 8 0;
#P connect 25 0 21 0;
#P connect 21 0 20 1;
#P fasten 22 0 20 2 402 345 387 345;
#P fasten 23 0 20 3 440 345 412 345;
#P connect 28 0 27 1;
#P fasten 29 0 27 2 490 390 478 390;
#P fasten 30 0 27 3 528 390 506 390;
#P connect 12 0 26 0;
#P fasten 19 0 12 0 844 700 868 700;
#P fasten 17 0 12 0 1023 710 868 710;
#P fasten 13 0 12 0 950 710 868 710;
#P fasten 11 0 14 0 866 693 903 693 903 670 911 670;
#P fasten 14 0 15 0 911 693 943 693 943 670 950 670;
#P connect 15 0 13 0;
#P connect 18 0 17 0;
#P pop;


September 27, 2007 | 12:06 am

As you have a bumping machine just well it might be a dum question
but why not use qmetro 40 instead of clocker to feed the bumper

> what happens with short DV movies is there any difference???

Hubert


September 28, 2007 | 3:53 pm

I’ve tried qmetro, clocker, the lot.
someone else sent me a patch with exactly that in it.
but there’s still an issue with qmetro too.

Interestingly, I just went to look at a ‘professional video server’, a piece of software (written by a company that shall remain nameless) and costing some thousands of pounds.

And guess what? They’ve got exactly the same problem too. Stuttering video images. And they hadn’t even noticed it. The sales guy phoned the programmer and asked him what was up. He hadn’t seen it either and is checking it out.

I’ve done a lot of online editing for broadcast, so I’m used to looking for picture errors.but don’t think i’m being stupidly anal about this. Stick it on a big screen, and the problem becomes pretty obvious. As it does when you try to play back ‘narrative film’ instead of abstract stuff.

Reading between the lines, it looks like this company’s clients use this software for playing back video on low-res screens where you don’t notice the glitches, then use Doremi’s for SD playback.

They were using a very similar method to Jitter, texturing videoplanes with video. As do pretty much all the other software servers out there.

What does this tell us?

We were playing back AVI’s and QT’s on a PC. So the issue is not exclusive to Mac, or to quicktime, or to Jitter. But there is no issue if you play back the same media using Quicktime Player on the mac.

I thought it could be a screen refresh problem, but the QT Player test kinda rules this out…..


September 28, 2007 | 4:46 pm

Well, I can also say FCP Studio 2.0 does not have this issue as well,
and they use OpenGL for playback. If you set Dynamic RT to Full,
Resolution to Full and Framerate to full within the timeline, you can
play back up to 2K material on an FCP station at full framerate
supposing you have the drive bandwidth. Of course other software wont
be as optimized, and I dont think anyone said this was a jitter only
issue, but lets flip it around and say, other people are doing it,
and we would absolutely love to be able to do it, and I also think,
at this point, Cycling understands, gets that we want to do it, has
other priorities with getting Max 5 out the door, and has publicly
stated they would love to do this as well, but if it will happen, it
will happen in Jitter 2.0

I think that about sums it up.

:)

On Sep 28, 2007, at 11:53 AM, marcus lyall wrote:

>
> I’ve tried qmetro, clocker, the lot.
> someone else sent me a patch with exactly that in it.
> but there’s still an issue with qmetro too.
>
> Interestingly, I just went to look at a ‘professional video
> server’, a piece of software (written by a company that shall
> remain nameless) and costing some thousands of pounds.
>
> And guess what? They’ve got exactly the same problem too.
> Stuttering video images. And they hadn’t even noticed it. The sales
> guy phoned the programmer and asked him what was up. He hadn’t seen
> it either and is checking it out.
>
> I’ve done a lot of online editing for broadcast, so I’m used to
> looking for picture errors.but don’t think i’m being stupidly anal
> about this. Stick it on a big screen, and the problem becomes
> pretty obvious. As it does when you try to play back ‘narrative
> film’ instead of abstract stuff.
>
> Reading between the lines, it looks like this company’s clients use
> this software for playing back video on low-res screens where you
> don’t notice the glitches, then use Doremi’s for SD playback.
>
> They were using a very similar method to Jitter, texturing
> videoplanes with video. As do pretty much all the other software
> servers out there.
>
> What does this tell us?
>
> We were playing back AVI’s and QT’s on a PC. So the issue is not
> exclusive to Mac, or to quicktime, or to Jitter. But there is no
> issue if you play back the same media using Quicktime Player on the
> mac.
>
> I thought it could be a screen refresh problem, but the QT Player
> test kinda rules this out…..
>
>
>
>
>
>
>
>
>

v a d e //

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


September 28, 2007 | 5:20 pm

but isn’t this a drive-related (or throughput you might say) issue?
if you’re working with HD on FCP you need a RAID or striped array to
play back cleanly. without the redundancy you’ll get dropped frames
and such. and if you add any processing into the equation you’ll
suffer even more, whereas working with final cut or after effects
you’ll need to render out your effects.
b

On Sep 28, 2007, at 12:46 PM, vade wrote:

> Well, I can also say FCP Studio 2.0 does not have this issue as
> well, and they use OpenGL for playback. If you set Dynamic RT to
> Full, Resolution to Full and Framerate to full within the timeline,
> you can play back up to 2K material on an FCP station at full
> framerate supposing you have the drive bandwidth. Of course other
> software wont be as optimized, and I dont think anyone said this
> was a jitter only issue, but lets flip it around and say, other
> people are doing it, and we would absolutely love to be able to do
> it, and I also think, at this point, Cycling understands, gets that
> we want to do it, has other priorities with getting Max 5 out the
> door, and has publicly stated they would love to do this as well,
> but if it will happen, it will happen in Jitter 2.0
>
> I think that about sums it up.
>
> :)
>
>
> On Sep 28, 2007, at 11:53 AM, marcus lyall wrote:
>
>>
>> I’ve tried qmetro, clocker, the lot.
>> someone else sent me a patch with exactly that in it.
>> but there’s still an issue with qmetro too.
>>
>> Interestingly, I just went to look at a ‘professional video
>> server’, a piece of software (written by a company that shall
>> remain nameless) and costing some thousands of pounds.
>>
>> And guess what? They’ve got exactly the same problem too.
>> Stuttering video images. And they hadn’t even noticed it. The
>> sales guy phoned the programmer and asked him what was up. He
>> hadn’t seen it either and is checking it out.
>>
>> I’ve done a lot of online editing for broadcast, so I’m used to
>> looking for picture errors.but don’t think i’m being stupidly anal
>> about this. Stick it on a big screen, and the problem becomes
>> pretty obvious. As it does when you try to play back ‘narrative
>> film’ instead of abstract stuff.
>>
>> Reading between the lines, it looks like this company’s clients
>> use this software for playing back video on low-res screens where
>> you don’t notice the glitches, then use Doremi’s for SD playback.
>>
>> They were using a very similar method to Jitter, texturing
>> videoplanes with video. As do pretty much all the other software
>> servers out there.
>>
>> What does this tell us?
>>
>> We were playing back AVI’s and QT’s on a PC. So the issue is not
>> exclusive to Mac, or to quicktime, or to Jitter. But there is no
>> issue if you play back the same media using Quicktime Player on
>> the mac.
>>
>> I thought it could be a screen refresh problem, but the QT Player
>> test kinda rules this out…..
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
> v a d e //
>
> http://www.vade.info
> abstrakt.vade.info
>
>
>

bruce tovsky
http://www.skeletonhome.com

"The secret to creativity is knowing how to hide your sources."
Albert Einstein


September 28, 2007 | 6:29 pm

I didnt say it was a drive related issue. Read more closely.

And you will always have a limit of how many effects you can have on
a hardware of sofgtware based system. You never have unlimited and
infinitely efficient processing. We are discussing a playback issue
withing Jitter. I think youve misunderstood what ive stated, and
perhaps others.

On Sep 28, 2007, at 1:20 PM, bruce tovsky wrote:

> but isn’t this a drive-related (or throughput you might say) issue?
> if you’re working with HD on FCP you need a RAID or striped array
> to play back cleanly. without the redundancy you’ll get dropped
> frames and such. and if you add any processing into the equation
> you’ll suffer even more, whereas working with final cut or after
> effects you’ll need to render out your effects.
> b
>
> On Sep 28, 2007, at 12:46 PM, vade wrote:
>
>> Well, I can also say FCP Studio 2.0 does not have this issue as
>> well, and they use OpenGL for playback. If you set Dynamic RT to
>> Full, Resolution to Full and Framerate to full within the
>> timeline, you can play back up to 2K material on an FCP station at
>> full framerate supposing you have the drive bandwidth. Of course
>> other software wont be as optimized, and I dont think anyone said
>> this was a jitter only issue, but lets flip it around and say,
>> other people are doing it, and we would absolutely love to be able
>> to do it, and I also think, at this point, Cycling understands,
>> gets that we want to do it, has other priorities with getting Max
>> 5 out the door, and has publicly stated they would love to do this
>> as well, but if it will happen, it will happen in Jitter 2.0
>>
>> I think that about sums it up.
>>
>> :)
>>
>>
>> On Sep 28, 2007, at 11:53 AM, marcus lyall wrote:
>>
>>>
>>> I’ve tried qmetro, clocker, the lot.
>>> someone else sent me a patch with exactly that in it.
>>> but there’s still an issue with qmetro too.
>>>
>>> Interestingly, I just went to look at a ‘professional video
>>> server’, a piece of software (written by a company that shall
>>> remain nameless) and costing some thousands of pounds.
>>>
>>> And guess what? They’ve got exactly the same problem too.
>>> Stuttering video images. And they hadn’t even noticed it. The
>>> sales guy phoned the programmer and asked him what was up. He
>>> hadn’t seen it either and is checking it out.
>>>
>>> I’ve done a lot of online editing for broadcast, so I’m used to
>>> looking for picture errors.but don’t think i’m being stupidly
>>> anal about this. Stick it on a big screen, and the problem
>>> becomes pretty obvious. As it does when you try to play back
>>> ‘narrative film’ instead of abstract stuff.
>>>
>>> Reading between the lines, it looks like this company’s clients
>>> use this software for playing back video on low-res screens where
>>> you don’t notice the glitches, then use Doremi’s for SD playback.
>>>
>>> They were using a very similar method to Jitter, texturing
>>> videoplanes with video. As do pretty much all the other software
>>> servers out there.
>>>
>>> What does this tell us?
>>>
>>> We were playing back AVI’s and QT’s on a PC. So the issue is not
>>> exclusive to Mac, or to quicktime, or to Jitter. But there is no
>>> issue if you play back the same media using Quicktime Player on
>>> the mac.
>>>
>>> I thought it could be a screen refresh problem, but the QT Player
>>> test kinda rules this out…..
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> v a d e //
>>
>> http://www.vade.info
>> abstrakt.vade.info
>>
>>
>>
>
> bruce tovsky
> http://www.skeletonhome.com
>
> "The secret to creativity is knowing how to hide your sources."
> Albert Einstein
>

v a d e //

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


September 28, 2007 | 6:56 pm

no, YOU read more closely – i said "isn’t this a drive related
issue?" i believe my response was on topic and relevant, though my
experience is more in the commercial video world rather than with
jitter or gl specifically. however, they all have to deal with the
same set of hardware requirements. i think we’re both saying the same
thing (i saw you mention drive bandwidth, i was just adding some
detail) and optimization is also very important, and of course apple
has the inside edge on that front. but i think that data bandwidth is
more critical than optimization, but that’s just me… ;-)
cheers
bruce

On Sep 28, 2007, at 2:29 PM, vade wrote:

> I didnt say it was a drive related issue. Read more closely.
>
> And you will always have a limit of how many effects you can have
> on a hardware of sofgtware based system. You never have unlimited
> and infinitely efficient processing. We are discussing a playback
> issue withing Jitter. I think youve misunderstood what ive stated,
> and perhaps others.
>
> On Sep 28, 2007, at 1:20 PM, bruce tovsky wrote:
>
>> but isn’t this a drive-related (or throughput you might say)
>> issue? if you’re working with HD on FCP you need a RAID or striped
>> array to play back cleanly. without the redundancy you’ll get
>> dropped frames and such. and if you add any processing into the
>> equation you’ll suffer even more, whereas working with final cut
>> or after effects you’ll need to render out your effects.
>> b
>>
>> On Sep 28, 2007, at 12:46 PM, vade wrote:
>>
>>> Well, I can also say FCP Studio 2.0 does not have this issue as
>>> well, and they use OpenGL for playback. If you set Dynamic RT to
>>> Full, Resolution to Full and Framerate to full within the
>>> timeline, you can play back up to 2K material on an FCP station
>>> at full framerate supposing you have the drive bandwidth. Of
>>> course other software wont be as optimized, and I dont think
>>> anyone said this was a jitter only issue, but lets flip it around
>>> and say, other people are doing it, and we would absolutely love
>>> to be able to do it, and I also think, at this point, Cycling
>>> understands, gets that we want to do it, has other priorities
>>> with getting Max 5 out the door, and has publicly stated they
>>> would love to do this as well, but if it will happen, it will
>>> happen in Jitter 2.0
>>>
>>> I think that about sums it up.
>>>
>>> :)
>>>
>>>
>>> On Sep 28, 2007, at 11:53 AM, marcus lyall wrote:
>>>
>>>>
>>>> I’ve tried qmetro, clocker, the lot.
>>>> someone else sent me a patch with exactly that in it.
>>>> but there’s still an issue with qmetro too.
>>>>
>>>> Interestingly, I just went to look at a ‘professional video
>>>> server’, a piece of software (written by a company that shall
>>>> remain nameless) and costing some thousands of pounds.
>>>>
>>>> And guess what? They’ve got exactly the same problem too.
>>>> Stuttering video images. And they hadn’t even noticed it. The
>>>> sales guy phoned the programmer and asked him what was up. He
>>>> hadn’t seen it either and is checking it out.
>>>>
>>>> I’ve done a lot of online editing for broadcast, so I’m used to
>>>> looking for picture errors.but don’t think i’m being stupidly
>>>> anal about this. Stick it on a big screen, and the problem
>>>> becomes pretty obvious. As it does when you try to play back
>>>> ‘narrative film’ instead of abstract stuff.
>>>>
>>>> Reading between the lines, it looks like this company’s clients
>>>> use this software for playing back video on low-res screens
>>>> where you don’t notice the glitches, then use Doremi’s for SD
>>>> playback.
>>>>
>>>> They were using a very similar method to Jitter, texturing
>>>> videoplanes with video. As do pretty much all the other software
>>>> servers out there.
>>>>
>>>> What does this tell us?
>>>>
>>>> We were playing back AVI’s and QT’s on a PC. So the issue is not
>>>> exclusive to Mac, or to quicktime, or to Jitter. But there is no
>>>> issue if you play back the same media using Quicktime Player on
>>>> the mac.
>>>>
>>>> I thought it could be a screen refresh problem, but the QT
>>>> Player test kinda rules this out…..
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> v a d e //
>>>
>>> http://www.vade.info
>>> abstrakt.vade.info
>>>
>>>
>>>
>>
>> bruce tovsky
>> http://www.skeletonhome.com
>>
>> "The secret to creativity is knowing how to hide your sources."
>> Albert Einstein
>>
>
> v a d e //
>
> http://www.vade.info
> abstrakt.vade.info
>
>
>

bruce tovsky
http://www.skeletonhome.com

"The secret to creativity is knowing how to hide your sources."
Albert Einstein


September 28, 2007 | 7:16 pm

…………..

You pointed out that other systems have the same issue as Jitter with
regard to hiccuping playback.

I pointed out that other systems, software based, can, in fact play
back HD without dropping a frame. It seems we both interface with
these sorts of systems daily.

I mentioned drive throughput offhandledly as a pre-requisite for
simply being able to read the data at its required bitrate (obvious).
It is clear drive throughput is NOT the problem with jitters playback
hiccups, but an obvious pre-requisite FOR ANY system to be able to work.

if you cannot get the data fast enough, how on earth do you expect to
be able to play it sans hiccup?

Anyway, i think are in agreement .

FLAME OFF!

On Sep 28, 2007, at 2:56 PM, bruce tovsky wrote:

> no, YOU read more closely – i said "isn’t this a drive related
> issue?" i believe my response was on topic and relevant, though my
> experience is more in the commercial video world rather than with
> jitter or gl specifically. however, they all have to deal with the
> same set of hardware requirements. i think we’re both saying the
> same thing (i saw you mention drive bandwidth, i was just adding
> some detail) and optimization is also very important, and of course
> apple has the inside edge on that front. but i think that data
> bandwidth is more critical than optimization, but that’s just
> me… ;-)
> cheers
> bruce
>
> On Sep 28, 2007, at 2:29 PM, vade wrote:
>
>> I didnt say it was a drive related issue. Read more closely.
>>
>> And you will always have a limit of how many effects you can have
>> on a hardware of sofgtware based system. You never have unlimited
>> and infinitely efficient processing. We are discussing a playback
>> issue withing Jitter. I think youve misunderstood what ive stated,
>> and perhaps others.
>>
>> On Sep 28, 2007, at 1:20 PM, bruce tovsky wrote:
>>
>>> but isn’t this a drive-related (or throughput you might say)
>>> issue? if you’re working with HD on FCP you need a RAID or
>>> striped array to play back cleanly. without the redundancy you’ll
>>> get dropped frames and such. and if you add any processing into
>>> the equation you’ll suffer even more, whereas working with final
>>> cut or after effects you’ll need to render out your effects.
>>> b
>>>
>>> On Sep 28, 2007, at 12:46 PM, vade wrote:
>>>
>>>> Well, I can also say FCP Studio 2.0 does not have this issue as
>>>> well, and they use OpenGL for playback. If you set Dynamic RT to
>>>> Full, Resolution to Full and Framerate to full within the
>>>> timeline, you can play back up to 2K material on an FCP station
>>>> at full framerate supposing you have the drive bandwidth. Of
>>>> course other software wont be as optimized, and I dont think
>>>> anyone said this was a jitter only issue, but lets flip it
>>>> around and say, other people are doing it, and we would
>>>> absolutely love to be able to do it, and I also think, at this
>>>> point, Cycling understands, gets that we want to do it, has
>>>> other priorities with getting Max 5 out the door, and has
>>>> publicly stated they would love to do this as well, but if it
>>>> will happen, it will happen in Jitter 2.0
>>>>
>>>> I think that about sums it up.
>>>>
>>>> :)
>>>>
>>>>
>>>> On Sep 28, 2007, at 11:53 AM, marcus lyall wrote:
>>>>
>>>>>
>>>>> I’ve tried qmetro, clocker, the lot.
>>>>> someone else sent me a patch with exactly that in it.
>>>>> but there’s still an issue with qmetro too.
>>>>>
>>>>> Interestingly, I just went to look at a ‘professional video
>>>>> server’, a piece of software (written by a company that shall
>>>>> remain nameless) and costing some thousands of pounds.
>>>>>
>>>>> And guess what? They’ve got exactly the same problem too.
>>>>> Stuttering video images. And they hadn’t even noticed it. The
>>>>> sales guy phoned the programmer and asked him what was up. He
>>>>> hadn’t seen it either and is checking it out.
>>>>>
>>>>> I’ve done a lot of online editing for broadcast, so I’m used to
>>>>> looking for picture errors.but don’t think i’m being stupidly
>>>>> anal about this. Stick it on a big screen, and the problem
>>>>> becomes pretty obvious. As it does when you try to play back
>>>>> ‘narrative film’ instead of abstract stuff.
>>>>>
>>>>> Reading between the lines, it looks like this company’s clients
>>>>> use this software for playing back video on low-res screens
>>>>> where you don’t notice the glitches, then use Doremi’s for SD
>>>>> playback.
>>>>>
>>>>> They were using a very similar method to Jitter, texturing
>>>>> videoplanes with video. As do pretty much all the other
>>>>> software servers out there.
>>>>>
>>>>> What does this tell us?
>>>>>
>>>>> We were playing back AVI’s and QT’s on a PC. So the issue is
>>>>> not exclusive to Mac, or to quicktime, or to Jitter. But there
>>>>> is no issue if you play back the same media using Quicktime
>>>>> Player on the mac.
>>>>>
>>>>> I thought it could be a screen refresh problem, but the QT
>>>>> Player test kinda rules this out…..
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> v a d e //
>>>>
>>>> http://www.vade.info
>>>> abstrakt.vade.info
>>>>
>>>>
>>>>
>>>
>>> bruce tovsky
>>> http://www.skeletonhome.com
>>>
>>> "The secret to creativity is knowing how to hide your sources."
>>> Albert Einstein
>>>
>>
>> v a d e //
>>
>> http://www.vade.info
>> abstrakt.vade.info
>>
>>
>>
>
> bruce tovsky
> http://www.skeletonhome.com
>
> "The secret to creativity is knowing how to hide your sources."
> Albert Einstein
>

v a d e //

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


September 28, 2007 | 8:16 pm

hi vade
On Sep 28, 2007, at 3:16 PM, vade wrote:

> You pointed out that other systems have the same issue as Jitter
> with regard to hiccuping playback.

well, the potential issue if not correctly hardware/software
optimized, yes. i work on an Avid system (turnkey/hardware optimized)
at work and Final Cut at home, and i know how tricky it can be
optimizing a FCP system: video cards, RAIDS, software settings all
combine to make a big headache. the edit facility i rent a room in
has switched from Avid to FCP for cost savings but the headaches are
fierce.

> I pointed out that other systems, software based, can, in fact play
> back HD without dropping a frame. It seems we both interface with
> these sorts of systems daily.

more than i like, for sure. just getting my feet wet with HD, about
to upgrade to avid adrenaline HD.

> I mentioned drive throughput offhandledly as a pre-requisite for
> simply being able to read the data at its required bitrate
> (obvious). It is clear drive throughput is NOT the problem with
> jitters playback hiccups, but an obvious pre-requisite FOR ANY
> system to be able to work.

interesting. i haven’t seen much mentioned about that in the posts
i’ve read. i would assume that people who are trying to work with HD/
2K must be knowledgeable about drive bandwidth… as you said "obvious".

> if you cannot get the data fast enough, how on earth do you expect
> to be able to play it sans hiccup?

you said it! can our expectations be too high? ;-)

> Anyway, i think are in agreement .

across the board.

> FLAME OFF!

never was on, on my side…
cheers
b

bruce tovsky
http://www.skeletonhome.com

"Flying is learning how to throw yourself at the ground and miss."
Douglas Adams


September 29, 2007 | 10:40 am

Er..

I just thought it would be useful to post a patch that showed the problem, even on a fast machine, as requested.

The point I was trying to make was that you don’t need a complex chain of slabs to see the problem. Just playing the movie back on a gl videoplane shows it.

I went to see this video server software because I’ve got a job coming up which needs video playback from a computer. What interested me was the fact that these guys had released the software with a similar stuttering problem and hadn’t noticed it.
So it’s obviously not an easy one to spot.

FCP is built around playing stable video. You can’t do anything to it while it’s playing. I’ve been wondering whether there’s an intrinsic issue with keeping a stable frame rate and being able to ‘play with’ the video at the same time.

I’m not asking for the problem to be solved overnight. I was just curious about whether it’s a relatively straightforward thing to do, or a massive change in software architecture.


May 8, 2011 | 11:24 am

So what happened in the past 3 years? Has jitter improved it’s clock? Does any of you now use it for commercial purposes or is it too much of a custom multimedia software thing?



FP
June 8, 2013 | 6:25 am

And now ? What’s new ? I noticed this problem is still not solved ? Any trciks ? Or did I miss something ? Thx.



dtr
June 8, 2013 | 6:47 am

Lots of threads on video performance in the forums. What’s your specific issue? What playback method are you using? There’s a lot of common patching inefficiencies to avoid before the only thing left to blame is Jitter or Quicktime.



FP
June 8, 2013 | 6:55 am

hello, I’m not really a noob. I use optimization patch like Vade and others posted few years ago. If you need it I can detailed what the format of movies and the programming I use. but I’m pretty sure all is optimizated. the problem is that the rate oscillates between 35 and 50 fps and make a stroboscopic movie (at 25fps) not playing accurate…


June 8, 2013 | 6:55 am

"So what happened in the past 3 years? "

Video performance seems to be a bit problematic (especially when build around [jit.qt.movie])… I think, many things are now open for changes, with 64bit Max…

Moreover, personally, I’l be very happy with deeper integration with Quartz – on OSX Quartz can offer some useful things.



dtr
June 8, 2013 | 8:50 am

give us something to test… ideally with the actual video that causes problems

> the problem is that the rate oscillates between 35 and 50 fps and make a stroboscopic movie (at 25fps) not playing accurate…

why play back a 25fps movie at higher frame rate? seems to me it’s always going to be jittery unless multiples of the original fps are used (50, 75, etc).



FP
June 8, 2013 | 9:06 am

>why play back a 25fps movie at higher frame rate? seems to me it’s always going to be jittery unless multiples of the original fps are used (50, 75, etc).
yes I konw and tried already, for sure. but the framerate is NEVER exactly at 25, 50, 75 fps but oscillates a little bit up and under this value. in that case there’s some frames dropped and make the movie playing not straight.

the test is easy. make a movie with a stroboscopic effect and try to play it in openGL with accuracy. the problem is well related in this thread. jit.qt.movie is set on unique 1, preload 1, with a preload ram of the first 2s, playing to few ji.gl.slab, then jit.gl.cornerpin… then render and window.

you know, I noticed this problem for looooong time but until now it was not a real problem. and if I want to solve it just I have to use modul8 or resolume… :-)

find enclosed a capture of propriety of the movie.

Attachments:
  1. Capture-d’écran-2013-06-08-à-18.08.26


dtr
June 8, 2013 | 9:16 am

a snippet of a movie would be real handy…



FP
June 8, 2013 | 9:17 am

As Vade said : This is what I see as one of the issues. It is my belief that these performance problems come from complicated patches above a certain threshold of events. I can make a simple one slab 1080p clip playback fine, but adding more slabs, even if disabled, cause slowdowns (yes, there is more processing that has to be done), but more importantly, larger hiccups. I understand reduced performance, but the hiccups are serious. I can tolerate 20 fps, but not 25->15 ->20 etc.

yes, I know, I know, not constructive, but I think at some point, it
becomes very very hard to submit a bug report of a simple test case,
because inherently the issue is due to the size of the patch, number
of gl calls, or something that becomes an issue as patch complexity
grows.



FP
June 8, 2013 | 9:48 am

here’s extracts but I suppose it will be difficult to notice the same problem as it appears sometime after few seconds, sometime after one min…

http://we.tl/MjlXiAqV4F



FP
June 8, 2013 | 10:15 am

And once again, just make a simple movie with a stroboscopic effect. play it with QT, and play with a simple openGL player with max and you’ll see the difference.
Make the test with a second screen or a vp.


June 8, 2013 | 11:44 am

have you tried jit.gl.hap?

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



dtr
June 8, 2013 | 4:39 pm

I tried your test2 movie with the patch below. I definitely saw stutters at some point while trying different frame rates. Then it went away and didn’t reappear, also not at the frame rate I first saw it. I seem to be having good results with rendering at my monitor’s refresh rate with sync on (60Hz). I’m not seeing fps fluctuations regardless of the set frame rate.

Out of curiosity, what OS and system are you on?

Btw, I’ve had my share of GL rendering jitter in the past:
http://cycling74.com/forums/topic/cyclical-frame-rates/#post-205739 (resolved by swapping the gfx card…)

http://cycling74.com/forums/topic/gl-render-weirdness-fluctuating-fps-with-2-contexts-2-screens/

<code>

– Pasted Max Patch, click to expand. –

</code>



FP
June 16, 2013 | 3:46 am

@rob: oooooh yes it seems very intereting. I’ll check this asap. thx a lot.
@dtr: os10.6.8, max6.1.2 – I didn’t get time to go furtherwith this problem. will check your links asap.


June 16, 2013 | 10:17 am

Could using an external sync source such as an AJA Gen10 help solve some of these problems? In broadcast land they are used to ensure that the frame rate always stays locked at the desired rate.

IIRC these devices just put out a signal of clicks at a precise rate. Using a small buffer frames could theoretically be drawn and output at each click. Video gear with SDI genlock input is necessary of course.



FP
February 6, 2014 | 7:38 am

Back to this big issue. jit.gl.hap didn’t solve as I suspect the problem comes from the fact we have to use qmetro to render. And qmetro is not stable…
So the only solution we found is to use another software to play the videos (like resolume)…
It’s really bad for Max and a little bit disappointing…


February 6, 2014 | 8:41 am

yes, it is really a shame, that we can not play a single movie without stuttering.
so we can not use max in a proffessional show context :-(

which i would love to do !!!

it is so disappointing that these smal, but important things are not on the roadmap of cycling ….

i think jit.gl.hap was a big step in the right direction !
perhaps something is happening in max7 :-)



dtr
February 6, 2014 | 9:38 am

Can you share your patch and a sample video? I’d like to try it too.



dtr
February 6, 2014 | 9:39 am

Btw, I think anyone criticizing C74 on this should provide material to confirm the claims.



dtr
February 6, 2014 | 9:40 am

Also, there’s no obligation to use qmetro over metro.



FP
February 6, 2014 | 10:21 am

Even with metro it’s not accurate. I just tried it…

but for sure HAP improves te result…



dtr
February 7, 2014 | 1:02 am

Patch and sample?

What do the glitches look like? Are you sure it’s not a combination of display refresh frequency, (q)metro frequency and video framerate? Respectively 60 / 24 / 23.976 hz (for example) is bound to yield duplicated or skipped frames. Don’t forget that the frequency of the display is also a factor.



FP
February 7, 2014 | 1:53 am

hello dieter, we had already this discussion just above in this thread… ;-)
the problem is still the same. I tried already many different configurations.

here’s a patch and a sample. try to play one with QT and one with the patch. the strob and the move are not constant in the patch.

for sure it’s better with the HAP codec but not perfect in my performance patch.

maybe it’s because of other process (kinect, sound, multi tracks audio in the video file, etc)

video test PhotoJPEG : http://we.tl/sk2yGqZLYI
video test HAP : http://we.tl/aMDccrsPnP

<code>

– Pasted Max Patch, click to expand. –

</code>


February 7, 2014 | 6:56 am

hello all,

its good that this thread is comming up.
it would be great, if it could be possible to play and mix full hd movies without hickups in max/msp/jitter !

i had the best experience in making a standalone hap movie player+mixer, which does not have any gui element inside.

all the gui elements i put in a seperate standalone connected with osc to the player.

smaler patches plays fine, if the 2 applications are on the same computer.
if i still have hickups, i use a macpro for playing and a seperate computer for organizing the movies.

@ft: the moviefiles, you have uploaded are damaged !

best,
pc



FP
February 7, 2014 | 9:05 am

ha maybe because the wetransfer…
here it is in zipped : http://we.tl/w7VFh3sSis



dtr
February 7, 2014 | 2:05 pm

Ok I’m seeing stutters as well. 1 video playing is smooth but with 2 I get occasional stutters.

This might sound counter intuitive but I seem to be getting it smooth again by increasing the qmetro frequency to a multiple of the video framerate. In attached patch I set it to 10ms, which clips to 60hz/16ms because of sync enabled on jit.window. I didn’t test it awfully long though.

I have a feeling that when the (q)metro is set at exactly the video frame rate Max misses a frame when it lags a little bit. By increasing the qmetro frequency we’re banging the player multiple times per frame, making sure that we’re not missing any. Something like Nyquist rate in the audio domain. Now if jit.gl.hap had a ‘unique’ attribute like jit.qt.movie we wouldn’t get unnecessary processing of doubled frames down the line.

This is all total hypothesis so please confirm/negate…

<code>

– Pasted Max Patch, click to expand. –

</code>

I’m on a beefy i7 quad-core desktop with GTX 670 graphics.



FP
February 7, 2014 | 2:31 pm

I confirm your feeling. In the case of my performance patch, I can’t set to 60Hz because I have variations from 40Hz to 60Hz due to the other processes. so…

but I will try the tricks of 2 applications asap.



dtr
February 8, 2014 | 11:15 am

I’m doing this for my heavy setups too. Separate apps for camera/kinect tracking, sensor inputs, openGl rendering, etc. Data gets passed via Max’s networking objects, which also makes it easier to spread things over multiple computers if need be.


February 11, 2014 | 4:46 am

Is there a patch demonstrating ‘off-line’ rendering to a matrix and subsequent sequencing of matrix frames to a video recording device without frame drops?



dtr
February 11, 2014 | 5:06 am

That should work by setting the render metro (not qmetro) to something slow (to make sure every frame has the time to be rendered) and jit.qt.record/jit.vcr (don’t remember which) to non-realtime mode.


Viewing 76 posts - 1 through 76 (of 76 total)