Forums > Jitter

Choppier DV PAL video via OpenGL

February 28, 2006 | 1:43 pm

Hi,

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.

Thanks

Bernd

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

—–

#P window setfont "Sans Serif" 9.;
#P window linecount 3;
#P comment 780 99 130 196617 btw. couldn?t get directtowindow work with @window foo1?!;
#P window linecount 1;
#P message 688 111 67 196617 window foo1;
#P message 905 252 68 196617 highquality 1;
#P newex 924 227 31 196617 sel 1;
#P newex 884 205 53 196617 unpack s i;
#P newex 885 183 55 196617 route read;
#P message 552 36 28 196617 read;
#P message 617 36 27 196617 stop;
#P message 583 36 31 196617 start;
#P user jit.fpsgui 58 200 60 196617 0;
#P window linecount 2;
#P comment 333 335 100 196617 smooth video via Quicktime;
#P window linecount 1;
#P message 564 252 68 196617 highquality 1;
#P newex 579 227 31 196617 sel 1;
#P newex 543 205 53 196617 unpack s i;
#P newex 544 183 55 196617 route read;
#P message 354 33 28 196617 read;
#P message 419 33 27 196617 stop;
#P message 385 33 31 196617 start;
#P newex 567 129 57 196617 qmetro 33;
#P newex 568 152 252 196617 jit.qt.movie @adapt 1 @autostart 0 @colormode uyvy;
#P newex 28 37 48 196617 loadbang;
#P newex 302 292 269 196617 jit.window foo1 @size 640 480 @interp 1 @mode noaccel;
#P newex 173 108 57 196617 qmetro 20;
#P newex 173 158 381 196617 jit.gl.videoplane foo @scale 1.333 1. 1. @interp 0 @automatic 1 @colormode uyvy;
#P newex 174 131 252 196617 jit.qt.movie @adapt 1 @autostart 0 @colormode uyvy;
#P newex 32 291 249 196617 jit.window foo @size 640 480 @interp 1 @mode auto;
#P newex 27 100 57 196617 qmetro 20;
#P newex 27 124 50 196617 t b erase;
#P newex 31 158 125 196617 jit.gl.render foo @ortho 2;
#P window linecount 2;
#P comment 68 333 100 196617 choppy video via OpenGL;
#P connect 2 0 1 0;
#P connect 2 0 20 0;
#P connect 25 1 26 0;
#P connect 26 0 27 0;
#P connect 10 1 24 0;
#P connect 24 0 25 0;
#P connect 9 0 3 0;
#P connect 9 0 7 0;
#P connect 9 0 11 0;
#P connect 9 0 28 0;
#P connect 16 1 17 0;
#P connect 28 0 10 0;
#P connect 27 0 10 0;
#P connect 22 0 10 0;
#P connect 21 0 10 0;
#P connect 23 0 10 0;
#P connect 11 0 10 0;
#P connect 17 0 18 0;
#P connect 6 1 15 0;
#P connect 15 0 16 0;
#P connect 7 0 5 0;
#P connect 12 0 5 0;
#P connect 13 0 5 0;
#P connect 14 0 5 0;
#P connect 18 0 5 0;
#P connect 5 0 6 0;
#P connect 2 1 1 0;
#P connect 3 0 2 0;
#P window clipboard copycount 30;


March 1, 2006 | 5:26 am

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 ?

William


March 1, 2006 | 7:58 pm

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

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

> 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
at greater CPU expense than Photo JPEG).

-Joshua


March 1, 2006 | 9:37 pm

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?

Thanks

Bernd


March 1, 2006 | 10:01 pm

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

v a d e //

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

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.

In fact, YOU WILL NOT BE SAVED!


March 1, 2006 | 10:05 pm

On Mar 1, 2006, at 1:37 PM, Bernd wrote:

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

-Joshua


March 1, 2006 | 10:42 pm

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

http://www.apple.com/quicktime/guide/hd/

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

Load and and compare.

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.

Bernd


March 1, 2006 | 10:52 pm

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.

-Joshua


March 1, 2006 | 11:08 pm

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

So, hoping for the next release…

Thanks anyway,

Bernd


March 2, 2006 | 5:42 am

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

Am I right ?

William


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