secco

I have serious problems with unstable movie playback and I can't figure out the reason.

I tried almost all suggestions from the forum but there's still this behavior sometimes:

a movie is playing, sometimes stable for several minutes.

sometimes it begins to stutter for a while like if there are two metros interfering. it stops rhythmically for about one frame. like if one frame is shown twice. this happens for about 3 to 15 sec, then this interrupts begin to appear less often or more often and then it runs smooth again.

-CPU CoreDuo 3GHz shows between 30 and 42% CPU usage for the whole system and max CPU usage always under 40%

I'm showing the movie on a GL videoplane. I'm using sync 1 for jit.gl.render.

But this jittering appears also in a jit.pwindow.

-overdrive on or off doesn't make a difference

-I tried to trigger the movie with a metro and with a line object. same results.

This stuttering also appears sometimes with GL Objekts!

Without any movie! For example: a sphere is moving slowly from left to right. for a while this is smooth, then suddenly there are those breaks and after a while it runs smooth again.

Like if the metro isn't running stable or is being interrupted by something.

I have serious problems with unstable movie playback and I can't figure out the reason.
I tried almost all suggestions from the forum but there's still this behavior sometimes:
a movie is playing, sometimes stable for several minutes.
sometimes it begins to stutter for a while like if there are two metros interfering. it stops rhythmically for about one frame. like if one frame is shown twice. this happens for about 3 to 15 sec, then this interrupts begin to appear less often or more often and then it runs smooth again.

I'm showing the movie on a GL videoplane. I'm using sync 1 for jit.gl.render.
But this jittering appears also in a jit.pwindow.

-The movie is 25fps
-Metro is 40
-overdrive on or off doesn't make a difference
-I tried to trigger the movie with a metro and with a line object. same results.

This stuttering also appears sometimes with GL Objekts!
Without any movie! For example: a sphere is moving slowly from left to right. for a while this is smooth, then suddenly there are those breaks and after a while it runs smooth again.
Like if the metro isn't running stable or is being interrupted by something.

I'm on Win XP, jitter 1.63, MAX 4.6
Nvidia 8600, 512MB
Core Duo 3GHz
4 GB RAM (3GB switch enabled)
resolution 1360x768, 50Hz
Movies: 1360x768 25fps, H264

metro-sometimes-unstable-not-accurate-movie-playback

why are you using a metro 40? does it happen if you use a qmetro 1, 

On Sep 26, 2007, at 6:38 AM, secco wrote:

> I have serious problems with unstable movie playback and I can't 

> I tried almost all suggestions from the forum but there's still 

> a movie is playing, sometimes stable for several minutes.

> sometimes it begins to stutter for a while like if there are two 

> metros interfering. it stops rhythmically for about one frame. like 

> if one frame is shown twice. this happens for about 3 to 15 sec, 

> then this interrupts begin to appear less often or more often and 

> -CPU CoreDuo 3GHz shows between 30 and 42% CPU usage for the whole 

> system and max CPU usage always under 40%

> I'm showing the movie on a GL videoplane. I'm using sync 1 for 

> But this jittering appears also in a jit.pwindow.

> -overdrive on or off doesn't make a difference

> -I tried to trigger the movie with a metro and with a line object. 

> This stuttering also appears sometimes with GL Objekts!

> Without any movie! For example: a sphere is moving slowly from left 

> to right. for a while this is smooth, then suddenly there are those 

> breaks and after a while it runs smooth again.

> Like if the metro isn't running stable or is being interrupted by 

why are you using a metro 40?  does it happen if you use a qmetro 1,  
for instance?

>
> hi all,
>
> I have serious problems with unstable movie playback and I can't  
> figure out the reason.
> I tried almost all suggestions from the forum but there's still  
> this behavior sometimes:
> a movie is playing, sometimes stable for several minutes.
> sometimes it begins to stutter for a while like if there are two  
> metros interfering. it stops rhythmically for about one frame. like  
> if one frame is shown twice. this happens for about 3 to 15 sec,  
> then this interrupts begin to appear less often or more often and  
> then it runs smooth again.
>
> -CPU CoreDuo 3GHz shows between 30 and 42% CPU usage for the whole  
> system and max CPU usage always under 40%
>
> I'm showing the movie on a GL videoplane. I'm using sync 1 for  
> jit.gl.render.
> But this jittering appears also in a jit.pwindow.
>
> -The movie is 25fps
> -Metro is 40
> -overdrive on or off doesn't make a difference
> -I tried to trigger the movie with a metro and with a line object.  
> same results.
>
> This stuttering also appears sometimes with GL Objekts!
> Without any movie! For example: a sphere is moving slowly from left  
> to right. for a while this is smooth, then suddenly there are those  
> breaks and after a while it runs smooth again.
> Like if the metro isn't running stable or is being interrupted by  
> something.
>
>
> does anybody have an idea?
>
> I'm on Win XP, jitter 1.63, MAX 4.6
> Nvidia 8600, 512MB
> Core Duo 3GHz
> 4 GB RAM (3GB switch enabled)
> resolution 1360x768, 50Hz
> Movies: 1360x768 25fps, H264
>
> thanks
> secco
>
>
>
>
>


I'm using a qmetro 40. because I have 25 fps. thats 40ms between the frames. Wrong to do that? I use the same metro for the jit.gl.render. My VGA output is running with 50Hz. I have sync 1 set in jit.gl.render.

I tried to change the qmetro to 1 or 10 or 20 but the CPU usage rises then and the jittering still doesn't disappear. I also tried to use different qmetros for the movie and for the jit.gl.render.

what am I doing wrong? Sometimes it runs absolutely smooth for about a minute. but then...

How does this "sync 1" for jit.gl.render exactly work? If it syncs jit.gl.render to the screen refresh, can I then sync my movie to that?

thanks for your reply.
I'm using a qmetro 40. because I have 25 fps. thats 40ms between the frames. Wrong to do that? I use the same metro for the jit.gl.render. My VGA output is running with 50Hz. I have sync 1 set in jit.gl.render.
I tried to change the qmetro to 1 or 10 or 20 but the CPU usage rises then and the jittering still doesn't disappear. I also tried to use different qmetros for the movie and for the jit.gl.render.
what am I doing wrong? Sometimes it runs absolutely smooth for about a minute. but then...

and never, ever use metro in gl situations.

On Sep 26, 2007, at 4:17 PM, secco wrote:

> I'm using a qmetro 40. because I have 25 fps. thats 40ms between 

> the frames. Wrong to do that? I use the same metro for the 

> jit.gl.render. My VGA output is running with 50Hz. I have sync 1 

> I tried to change the qmetro to 1 or 10 or 20 but the CPU usage 

> rises then and the jittering still doesn't disappear. I also tried 

> to use different qmetros for the movie and for the jit.gl.render.

> what am I doing wrong? Sometimes it runs absolutely smooth for 

> How does this "sync 1" for jit.gl.render exactly work? If it syncs 

> jit.gl.render to the screen refresh, can I then sync my movie to that?

>
> hi joshua,
>
> thanks for your reply.
> I'm using a qmetro 40. because I have 25 fps. thats 40ms between  
> the frames. Wrong to do that? I use the same metro for the  
> jit.gl.render. My VGA output is running with 50Hz. I have sync 1  
> set in jit.gl.render.
> I tried to change the qmetro to 1 or 10 or 20 but the CPU usage  
> rises then and the jittering still doesn't disappear. I also tried  
> to use different qmetros for the movie and for the jit.gl.render.
> what am I doing wrong? Sometimes it runs absolutely smooth for  
> about a minute. but then...
>
> How does this "sync 1" for jit.gl.render exactly work? If it syncs  
> jit.gl.render to the screen refresh, can I then sync my movie to that?
>
> thanks
>
> secco
>


...this might eliminate any repeated frames.

Search on the Forum : "Jitter Movie Optimization Methods"

Vade posted great tricks few days ago.
Search on the Forum : "Jitter Movie Optimization Methods"


i've posted regarding this / or similar issue recently - spoke to many peoeple and did a ton of testing - and the result - theres simply a glitch in the clock / threading in Jitter - which causes unreliable / jumpy playback. period. I have not met / seen - or even heard of a current ( recent versions of max and jitter on newer pc's mac) configuration that doesnt have this problem. eventually after phone calls and lots of iquiries with other vj's & video artists - many have said either live with - or use something else! - I couldnt believe this issue would be put aside, so I contacted cycling74 - and the response "we will address this issue after the release of Max 5".

so i am mostly posting not to bash cycling74 - but to help people save time testing and wondering "is it my machine?" - 

99% chance is its NOT. its Jitter code....

this playback issue is a huge problem, and I've not been able to record any realtime output of Jitter yet - the hiccup or jump, to me, is unacceptable for recorded media. maybe for live performance its ok, but...

I know other video / vj software doesnt have this playback problem, so it must be the code behind jitter/max 

previous thread on the 'jitter' in jitter.

https://cycling74.com/forums/index.php?t=msg&th=29333&start=0&rid=6240&S=d46591dbbd4d6ea4b92ea86a74159712

i've posted regarding this / or similar issue recently  - spoke to many peoeple and did a ton of testing - and the result  - theres simply a glitch in the clock / threading in Jitter - which causes unreliable / jumpy playback. period. I have not met / seen - or even heard of a current ( recent versions of max and jitter on newer pc's mac) configuration that doesnt have this problem. eventually after phone calls and lots of iquiries with other vj's & video artists - many have said either live with - or use something else! - I couldnt believe this issue would be put aside, so I contacted cycling74 - and the response "we will address this issue after the release of Max 5".

so i am mostly posting not to bash cycling74 - but to help people save time testing and wondering "is it my machine?" - 
 99% chance is its NOT. its Jitter code....

I know other video / vj software doesnt have this playback problem, so it must be the code behind jitter/max 
--
previous thread on the 'jitter' in jitter.

https://cycling74.com/forums/index.php?t=msg&th=29333&start=0&rid=6240&S=d46591dbbd4d6ea4b92ea86a74159712


tests were on Mac and PC - following every optimization possible (killing system operations, cpu, max prefs, Vade's recommendations.. etc)

the only time this jumpy playback goes away, is if you render the jitter video 'direct to window' -

tests were on Mac and PC - following every optimization possible (killing system operations, cpu, max prefs, Vade's recommendations.. etc)
-

the only time this jumpy playback goes away, is if you render the jitter video 'direct to window' -


i know for a fact that cycling is aware of this and its enormous 

importance. as soon as max5 is out of the door, there will be 

attention paid to it. vade and i have bugged cycling about it plenty, 

and i am satisfied that it's a very high priority issue for them.

> i've posted regarding this / or similar issue recently - spoke to 

> many peoeple and did a ton of testing - and the result - theres 

> simply a glitch in the clock / threading in Jitter - which causes 

> unreliable / jumpy playback. period. I have not met / seen - or even 

> heard of a current ( recent versions of max and jitter on newer pc's 

> mac) configuration that doesnt have this problem. eventually after 

> phone calls and lots of iquiries with other vj's & video artists - 

> many have said either live with - or use something else! - I couldnt 

> believe this issue would be put aside, so I contacted cycling74 - 

> and the response "we will address this issue after the release of 

> so i am mostly posting not to bash cycling74 - but to help people 

> save time testing and wondering "is it my machine?" -

> 99% chance is its NOT. its Jitter code....

> this playback issue is a huge problem, and I've not been able to 

> record any realtime output of Jitter yet - the hiccup or jump, to 

> me, is unacceptable for recorded media. maybe for live performance 

> I know other video / vj software doesnt have this playback problem, 

> so it must be the code behind jitter/max

> previous thread on the 'jitter' in jitter.

i know for a fact that cycling is aware of this and its enormous  
importance.  as soon as max5 is out of the door,  there will be  
attention paid to it.  vade and i have bugged cycling about it plenty,  
and i am satisfied that it's a very high priority issue for them.

>
> i've posted regarding this / or similar issue recently  - spoke to  
> many peoeple and did a ton of testing - and the result  - theres  
> simply a glitch in the clock / threading in Jitter - which causes  
> unreliable / jumpy playback. period. I have not met / seen - or even  
> heard of a current ( recent versions of max and jitter on newer pc's  
> mac) configuration that doesnt have this problem. eventually after  
> phone calls and lots of iquiries with other vj's & video artists -  
> many have said either live with - or use something else! - I couldnt  
> believe this issue would be put aside, so I contacted cycling74 -  
> and the response "we will address this issue after the release of  
> Max 5".
>
> so i am mostly posting not to bash cycling74 - but to help people  
> save time testing and wondering "is it my machine?" -
> 99% chance is its NOT. its Jitter code....
>
>
> this playback issue is a huge problem, and I've not been able to  
> record any realtime output of Jitter yet - the hiccup or jump, to  
> me, is unacceptable for recorded media. maybe for live performance  
> its ok, but...
>
> I know other video / vj software doesnt have this playback problem,  
> so it must be the code behind jitter/max
> --
> previous thread on the 'jitter' in jitter.
>
> https://cycling74.com/forums/index.php?t=msg&th=29333&start=0&rid=6240&S=d46591dbbd4d6ea4b92ea86a74159712
>


I should also point you to my optimization patches I posted earlier in 

the list. They can be useful to expose some small performance gains 

that can help ease out any inherit stuttering.

If you patch is single channel and well suited, Josh and Lukes 

workaround that ive expounded on in the last two patches can make a 

pretty big difference in performance/stutter.

On Jan 2, 2008, at 9:08 PM, joshua goldberg wrote:

> i know for a fact that cycling is aware of this and its enormous 

> importance. as soon as max5 is out of the door, there will be 

> attention paid to it. vade and i have bugged cycling about it 

> plenty, and i am satisfied that it's a very high priority issue for 

> On Jan 2, 2008, at 8:07 PM, james wrote:

>> i've posted regarding this / or similar issue recently - spoke to 

>> many peoeple and did a ton of testing - and the result - theres 

>> simply a glitch in the clock / threading in Jitter - which causes 

>> unreliable / jumpy playback. period. I have not met / seen - or 

>> even heard of a current ( recent versions of max and jitter on 

>> newer pc's mac) configuration that doesnt have this problem. 

>> eventually after phone calls and lots of iquiries with other vj's & 

>> video artists - many have said either live with - or use something 

>> else! - I couldnt believe this issue would be put aside, so I 

>> contacted cycling74 - and the response "we will address this issue 

>> so i am mostly posting not to bash cycling74 - but to help people 

>> save time testing and wondering "is it my machine?" -

>> 99% chance is its NOT. its Jitter code....

>> this playback issue is a huge problem, and I've not been able to 

>> record any realtime output of Jitter yet - the hiccup or jump, to 

>> me, is unacceptable for recorded media. maybe for live performance 

>> I know other video / vj software doesnt have this playback problem, 

>> so it must be the code behind jitter/max

>> previous thread on the 'jitter' in jitter.

I should also point you to my optimization patches I posted earlier in  
the list. They can be useful to expose some small performance gains  
that can help ease out any inherit stuttering.

If you patch is single channel and well suited, Josh and Lukes  
workaround that ive expounded on in the last two patches can make a  
pretty big difference in performance/stutter.

> i know for a fact that cycling is aware of this and its enormous  
> importance.  as soon as max5 is out of the door,  there will be  
> attention paid to it.  vade and i have bugged cycling about it  
> plenty, and i am satisfied that it's a very high priority issue for  
> them.
>
> On Jan 2, 2008, at 8:07 PM, james wrote:
>
>>
>> i've posted regarding this / or similar issue recently  - spoke to  
>> many peoeple and did a ton of testing - and the result  - theres  
>> simply a glitch in the clock / threading in Jitter - which causes  
>> unreliable / jumpy playback. period. I have not met / seen - or  
>> even heard of a current ( recent versions of max and jitter on  
>> newer pc's mac) configuration that doesnt have this problem.  
>> eventually after phone calls and lots of iquiries with other vj's &  
>> video artists - many have said either live with - or use something  
>> else! - I couldnt believe this issue would be put aside, so I  
>> contacted cycling74 - and the response "we will address this issue  
>> after the release of Max 5".
>>
>> so i am mostly posting not to bash cycling74 - but to help people  
>> save time testing and wondering "is it my machine?" -
>> 99% chance is its NOT. its Jitter code....
>>
>>
>> this playback issue is a huge problem, and I've not been able to  
>> record any realtime output of Jitter yet - the hiccup or jump, to  
>> me, is unacceptable for recorded media. maybe for live performance  
>> its ok, but...
>>
>> I know other video / vj software doesnt have this playback problem,  
>> so it must be the code behind jitter/max
>> --
>> previous thread on the 'jitter' in jitter.
>>
>> https://cycling74.com/forums/index.php?t=msg&th=29333&start=0&rid=6240&S=d46591dbbd4d6ea4b92ea86a74159712
>>
>


Yes, there are some issues, but 99% OF THE TIME IT'S PEOPLE WHO ARE 

SHIT AT PROGRAMMING. If I hear one more noob yelling "Why won't the 

timing in jitter work right?" when they don't even understand what 

fps is or the difference between a qmetro and a metro, I am going to 

DO NOT tell them that they shouldn't search the forums. There are 

excellent solutions that will solve your playback problems in many 

The other 1% of the time it's a real problem, usually seen by people 

who understand what they're doing (which may include you, from what 

you're saying). There are ways to fix these things, but video is 

complicated and I dare you to find a single, working, realtime video 

option that does everything you need it to, is not a nightmare to 

install or configure, is flexible, and doesn't have any glitches. 

But yeah, in other specific, precise cases of writing sequential non- 

skipping video frames, you are simply fucked.

I am also satisfied that cycling74 is on the problem. In the 

meantime, there are some good systems out there for starting about 

> so i am mostly posting not to bash cycling74 - but to help people  
> save time testing and wondering "is it my machine?" -
>  99% chance is its NOT. its Jitter code....
>

Yes, there are some issues, but 99% OF THE TIME IT'S PEOPLE WHO ARE  
SHIT AT PROGRAMMING.  If I hear one more noob yelling "Why won't the  
timing in jitter work right?" when they don't even understand what  
fps is or the difference between a qmetro and a metro, I am going to  
vomit in realtime.

DO NOT tell them that they shouldn't search the forums.  There are  
excellent solutions that will solve your playback problems in many  
cases.
The other 1% of the time it's a real problem, usually seen by people  
who understand what they're doing (which may include you, from what  
you're saying).  There are ways to fix these things, but video is  
complicated and I dare you to find a single, working, realtime video  
option that does everything you need it to, is not a nightmare to  
install or configure, is flexible, and doesn't have any glitches.   
But yeah, in other specific, precise cases of writing sequential non- 
skipping video frames, you are simply fucked.

I am also satisfied that cycling74 is on the problem.  In the  
meantime, there are some good systems out there for starting about  
$6,000-$30,000, if you really need it...

I think that last response is a little harsh. I think the longer you use Jitter the more you learn to accept the foibles. Perhaps this angered kneejerk reaction is just the defensive response that most of us develop after having to explain to peers/clients/critics when a big gank appears in the middle of a performance. I use Jitter because of the creative possibilities it offers, in spite of underwhelming framerates and irritating freezes. While coding may be the answer to some of these problems, these are issues that occur when using the software as recommended and involve solutions that require breaking out of the creative model that max/jitter encourages. These are high hurdles for the programmers, but they are obviously deal-breakers for a lot of people that need to provide reliable solutions in performance situations.

While it is tempting to demand faster framerates and better performance statistics, I think it would be more beneficial to focus on methods of increasing stability and consistency. I'd rather have a flawless 30fps than an occasional freeze at 50fps.

Certainly poor programming can make these issue worse, but expert programmers such as Vade and Joshua are still spending time making workarounds for these issues rather than working on the creative elements of their work.

I think that last response is a little harsh.  I think the longer you use Jitter the more you learn to accept the foibles.  Perhaps this angered kneejerk reaction is just the defensive response that most of us develop after having to explain to peers/clients/critics when a big gank appears in the middle of a performance.  I use Jitter because of the creative possibilities it offers, in spite of underwhelming framerates and irritating freezes.  While coding may be the answer to some of these problems, these are issues that occur when using the software as recommended and involve solutions that require breaking out of the creative model that max/jitter encourages.  These are high hurdles for the programmers, but they are obviously deal-breakers for a lot of people that need to provide reliable solutions in performance situations.
While it is tempting to demand faster framerates and better performance statistics, I think it would be more beneficial to focus on methods of increasing stability and consistency.  I'd rather have a flawless 30fps than an occasional freeze at 50fps.
Certainly poor programming can make these issue worse, but expert programmers such as Vade and Joshua are still spending time making workarounds for these issues rather than working on the creative elements of their work.


On Jan 3, 2008, at 10:18 AM, Leo Mayberry wrote:

> I think that last response is a little harsh. I think the longer 

> you use Jitter the more you learn to accept the foibles. Perhaps 

> this angered kneejerk reaction is just the defensive response that 

> most of us develop after having to explain to peers/clients/critics 

> when a big gank appears in the middle of a performance.

I don't think it was harsh. When I was in school, they drilled it 

into us that we were not gods and there were lots of better ways to 

do things. Probably always. That humility is lacking in a lot of 

posts I see. People forget that most people who use jitter are 

shitty programmers (not there aren't brilliant ones out there, but 

I'd put it generously at 5%). Also, the hands-on approach to coding 

makes it a visual form of crack - I see so many people who get into 

jitter and then just code on some sort of animal instinct as if 

stepping back and thinking about what they are doing (e.g. squeezing 

a 10000x10000 cell matrix into 20 stacked filters with patch cords 

crossing left and right) is a useful and intelligent thing to do.

If you are getting glitches, do some experiments like Vade and show 

what the issue is. This vague blabbering is really bothering me. I 

looked into Quartz composer, Objective C, Quicktime, Mplayer, etc and 

did some heavy research before asking my inane little questions. I 

hate empty whining on email lists. If you have evidence, I'd really 

like to see it. Or descriptions of the problem that are useful. 

Most regular contributors to this list follow these standards, anyway.

> I use Jitter because of the creative possibilities it offers, in 

> spite of underwhelming framerates and irritating freezes. While 

> coding may be the answer to some of these problems, these are 

> issues that occur when using the software as recommended and 

> involve solutions that require breaking out of the creative model 

> that max/jitter encourages. These are high hurdles for the 

> programmers, but they are obviously deal-breakers for a lot of 

> people that need to provide reliable solutions in performance 

> While it is tempting to demand faster framerates and better 

> performance statistics, I think it would be more beneficial to 

> focus on methods of increasing stability and consistency. I'd 

> rather have a flawless 30fps than an occasional freeze at 50fps.

> Certainly poor programming can make these issue worse, but expert 

> programmers such as Vade and Joshua are still spending time making 

> workarounds for these issues rather than working on the creative 

I don't know, I thought those experiments were pretty creative. And 

I wouldn't call them workaround, either - this is what I mean when I 

metro sometimes unstable not accurate movie playback