Forums > Jitter

metro sometimes unstable not accurate movie playback

September 26, 2007 | 10:38 am

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 1360×768, 50Hz
Movies: 1360×768 25fps, H264

thanks
secco


September 26, 2007 | 1:19 pm

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

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

>
> 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 1360×768, 50Hz
> Movies: 1360×768 25fps, H264
>
> thanks
> secco
>
>
>
>
>


September 26, 2007 | 8:17 pm

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


September 26, 2007 | 8:23 pm

try using ‘qmetro 1′ instead.

and never, ever use metro in gl situations.

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

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



rvr
January 1, 2008 | 12:56 am

jit.qt.movie 640 480 @unique 1

…this might eliminate any repeated frames.


January 1, 2008 | 6:46 pm

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


January 3, 2008 | 1:07 am

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.

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


January 3, 2008 | 1:11 am

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’ –


January 3, 2008 | 2:08 am

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.
>
> http://www.cycling74.com/forums/index.php?t=msg&th=29333&start=0&rid=6240&S=d46591dbbd4d6ea4b92ea86a74159712
>


January 3, 2008 | 9:07 am

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
> 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.
>>
>> http://www.cycling74.com/forums/index.php?t=msg&th=29333&start=0&rid=6240&S=d46591dbbd4d6ea4b92ea86a74159712
>>
>


January 3, 2008 | 9:07 am

On Jan 3, 2008, at 1:07 AM, james wrote:

> 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 absolutely disagree with that.

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…

Cheers
Evan


January 3, 2008 | 10:18 am

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.


January 3, 2008 | 11:09 am

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 10000×10000 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
> 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 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
say there needs to be an understanding of the issues involved, and
techniques to work with them. I think we all gained a bit more
understanding from looking at this problem from different angles and
discussing different compression techniques (like uyvy vs rgb format
issues) on a public forum. More of that is good; less of "Damn
jitter! It’s skippy and will never work properly!"

I’ve got a patch that draws 1800 polygons at 50 fps. That’s pretty
darn good for jitter, and it took me awhile to find the right method,
which turned out to be more about OpenGL than Jitter. I think what
people are going up against is the limits of what can be done with
"simple" metaphors that Jitter presents on the surface vs. the all-
out mind-fuck complexity of digital video formats and compression, 3D
maths and OpenGL.

My 2cents. You use may vary.

Cheers
Evan


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