Bernd

hopefully I can get some help here on this matter.

When comparing a dv pal movie (yes, PhotJPEG has the same results) which is played out via jit.gl.videoplane and the same movie played out via jit.qt.movie?s "@window foo", the opengl variant looks much more jerky.

It gets most obvious with movements in the scenes.So for example moving clouds on a sky are no more acceptable as a background projection.

I am attaching a comparison patch, so if anyone has an idea what is wrong I would be glad to hear.

P.S.: Using H264 the error gets more pronounced.

OSX 10.4.5
QT 7.04
Latest Max/MSP/Jitter
G5 DC 2.3GHz

choppier-dv-pal-video-via-opengl

would it be related to the nature of texturing ? I guess the videoplane

object is a wrapper that decode the movie and attach the matrix to a texture

and bind it to a plane mesh ..... right ?

would it be related to the nature of texturing ? I guess the videoplane
object is a wrapper that decode the movie and attach the matrix to a texture
and bind it to a plane mesh ..... right ?

On Feb 28, 2006, at 9:26 PM, William Wong wrote:

> When comparing a dv pal movie (yes, PhotJPEG has the same results) 

> which is played out via jit.gl.videoplane and the same movie played 

> out via jit.qt.movie?s "@window foo", the opengl variant looks much 

> It gets most obvious with movements in the scenes.So for example 

> moving clouds on a sky are no more acceptable as a background 

Not able to see much differences on my powerbook, however, for 

optimal results, you should use the same qmetro 33 to drive your 

display, rather than 50ms. This could easily account for some 

jerkiness as the 33 and 50 ms metros can alternatingly double and 

> P.S.: Using H264 the error gets more pronounced.

As previously mentioned, H.264 is more expensive to decompress. Would 

recommend you avoid, batch converting to Photo JPEG or DV25/DVCPro 50 

(DVCPro 50 has much better color sampling and image quality, though 

> On 2/28/06, Bernd  wrote:
> When comparing a dv pal movie (yes, PhotJPEG has the same results)  
> which is played out via jit.gl.videoplane and the same movie played  
> out via jit.qt.movie?s "@window foo", the opengl variant looks much  
> more jerky.
>
> It gets most obvious with movements in the scenes.So for example  
> moving clouds on a sky are no more acceptable as a background  
> projection.

Not able to see much differences on my powerbook, however, for  
optimal results, you should use the same qmetro 33 to drive your  
display, rather than 50ms. This could easily account for some  
jerkiness as the 33 and 50 ms metros can alternatingly double and  
skip frames.

As previously mentioned, H.264 is more expensive to decompress. Would  
recommend you avoid, batch converting to Photo JPEG or DV25/DVCPro 50  
(DVCPro 50 has much better color sampling and image quality, though  
at greater CPU expense than Photo JPEG).

The qmetro 20/33 differnce just happened when stripping down the patch.

Using 33 all the time doesn?t change the behaviour.

Btw. 40 would be appropriate for PAL but this also doesn?t change anything.

Did you really compare with PAL sources? I have the impression that with NTSC DV the picture isn?t that jerky.

Is there a chance that rendering on the cpu could improve the jerky movies? I forgot, what was the message for rendering Cg-wise?

The qmetro 20/33 differnce just happened when stripping down the patch.
Using 33 all the time doesn?t change the behaviour.
Btw. 40 would be appropriate for PAL but this also doesn?t change anything.

perhaps you are seeing the difference between 25fps and 29.97? Pal 

(25) looks much more like film, but "jerky" is a qualitative 

statement, so Im uncertain what you are referring to..

I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I 

You will not be saved by the Holy Ghost. You will not be saved by the 

perhaps you are seeing the difference between 25fps and 29.97? Pal  
(25) looks much more like film, but "jerky" is a qualitative  
statement, so Im uncertain what you are referring  to..

I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I  
LIVE! I LIVE! I LIVE! I LIVE!

You will not be saved by the Holy Ghost. You will not be saved by the  
God Plutonium.

> Did you really compare with PAL sources? I have the impression that 

> with NTSC DV the picture isn?t that jerky.

I don't have any PAL footage. If you post a link to example footage, 

we can investigate further, however there's no reason I can think of 

that the behavior would be markedly different, aside from the reduced 

color sampling possibly requiring 2 axes of interpolation for DV PAL 

internal to the QT codec. There is nothing different about NTSC vs 

PAL as far as Jitter itself is concerned. If you could experiment by 

taking your footage and converting it to other codecs to determine if 

it is the codec. I tested with DV25 NTSC and did not notice any 

perceptible difference between direct to window and playback via 

> Is there a chance that rendering on the cpu could improve the jerky 

> movies? I forgot, what was the message for rendering Cg-wise?

There is no codec rendering on the GPU. It all happens on the CPU. 

The rendered image is then used as a texture. I'm not sure what 

you're referring to w/r/t "rendering Cg-wise".

Basically, there is no other thing I can think of to improve 

performance here in Jitter (as you're using colormode uyvy and 

jit.gl.videoplane), aside from using a more efficient codec like 

Photo JPEG (as recommended *several* times, Bernd...please consider 

batch converting your footage to maximize performance, or use direct 

> Did you really compare with PAL sources? I have the impression that  
> with NTSC DV the picture isn?t that jerky.

I don't have any PAL footage. If you post a link to example footage,  
we can investigate further, however there's no reason I can think of  
that the behavior would be markedly different, aside from the reduced  
color sampling possibly requiring 2 axes of interpolation for DV PAL  
internal to the QT codec. There is nothing different about NTSC vs  
PAL as far as Jitter itself is concerned. If you could experiment by  
taking your footage and converting it to other codecs to determine if  
it is the codec. I tested with DV25 NTSC and did not notice any  
perceptible difference between direct to window and playback via  
jit.gl.videoplane in your patch.

> Is there a chance that rendering on the cpu could improve the jerky  
> movies? I forgot, what was the message for rendering Cg-wise?

There is no codec rendering on the GPU. It all happens on the CPU.  
The rendered image is then used as a texture. I'm not sure what  
you're referring to w/r/t "rendering Cg-wise".

Basically, there is no other thing I can think of to improve  
performance here in Jitter (as you're using colormode uyvy and  
jit.gl.videoplane), aside from using a more efficient codec like  
Photo JPEG (as recommended *several* times, Bernd...please consider  
batch converting your footage to maximize performance, or use direct  
to window mode).

For example download the "Deep Sea 3D" excerpt at

Then convert it to DV PAL / DV NTSC / PhotpJPEG 75%

Here the differnce between direct to window and opengl is really obvious with all codecs (tried it also on a powerbook G4, same behaviour).

If you have movements all over the screen, the video is not as smooth as when played direct out(and it seems that the disk is more often active, but this could be also a bit of delusion).

Sorry, I mixed up the native shader functionality via Cg with this thread.

If this is the case, then there's nothing in the current version 

which will change this, aside from perhaps disabling the window's 

If you want the improved performance, please use direct to window. 

This is simply a choice you have to make. There's no further 

If this is the case, then there's nothing in the current version  
which will change this, aside from perhaps disabling the window's  
sync attribute.

If you want the improved performance, please use direct to window.  
This is simply a choice you have to make. There's no further  
optimization settings.

I have already tried with sync 0/1 but also no difference.

> There is no codec rendering on the GPU. It all happens on the CPU.

> The rendered image is then used as a texture. I'm not sure what

> you're referring to w/r/t "rendering Cg-wise".

I am really confused if there is no hardware acceleration in our graphic

I believe most modern graphics card have a video engine to decode and

That's what i guess the reason of video playback directly onto a window (no

3d involved and so the video is output directly) and a videoplane (3d

involved and so the video image has to be stay back for texturing before

> There is no codec rendering on the GPU. It all happens on the CPU.
> The rendered image is then used as a texture. I'm not sure what
> you're referring to w/r/t "rendering Cg-wise".

 I am really confused if there is no hardware acceleration in our graphic
cards to decode and display a video...

I believe most modern graphics card have a video engine to decode and
display video.

That's what i guess the reason of video playback directly onto a window (no
3d involved and so the video is output directly) and a videoplane (3d
involved and so the video image has to be stay back for texturing before
rendering out) are different.

Choppier DV PAL video via OpenGL