Forums > Jitter

jit.gl.videoplane uyvy problems under XP

May 5, 2006 | 3:37 pm

Dear list,

I have a little problem that occured under WinXP when trying to use

uyvy colormode for a jit.gl.videoplane.
On my G5 the same patch is working without any problems and

switching to uyvy mode the framerate increases as it should be.
But on my Thinkpad 1,8Ghz with XP and an ATI Mobility FireGL T2 and QuickTime 7.0.4 installed the framerate isn’t changing at all and a jit.gl.texture error appears, saying: invalid value. I tried around quite a bit with different attributes but that didn’t help either.
I am using HD 720p footage with foto-jpeg compression.
hope it’s not a quicktime problem under XP.

thanks

paul

Jitter 1.5.2, Thinkpad T42p, 1,8Ghz, ATI Mobility FireGL T2, XP SP1, QuickTime 7.0.4,

max v2;
#N vpatcher 289 402 1344 826;
#P origin -35 100;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P message 82 218 77 9109513 colormode uyvy;
#P message 9 218 72 9109513 colormode argb;
#P message 516 65 77 9109513 colormode uyvy;
#P message 443 65 72 9109513 colormode argb;
#P newex 175 302 74 9109513 print videoplane;
#P newex 175 278 75 9109513 route colormode;
#P message 164 190 64 9109513 getcolormode;
#P newex 367 152 66 9109513 print qt.movie;
#P newex 367 127 75 9109513 route colormode;
#P message 375 64 64 9109513 getcolormode;
#P toggle 688 48 15 0;
#P number 728 45 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 690 76 50 9109513 qmetro 50;
#P message 258 63 27 9109513 start;
#P toggle 430 251 15 0;
#P message 430 272 52 9109513 floating $1;
#P newex 30 31 45 9109513 loadbang;
#P message 30 60 53 9109513 autostart 0;
#P flonum 415 222 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 414 199 27 9109513 / 1.;
#P number 639 122 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 640 153 42 9109513 ortho $1;
#P flonum 138 162 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 100 162 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 60 162 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 35 189 85 9109513 pak scale 1. 1. 1.;
#P message 332 64 29 9109513 vol 0;
#P message 299 64 29 9109513 vol 1;
#P newex 87 60 40 9109513 r movie;
#P newex 744 142 43 9109513 s movie;
#P user jit.fpsgui 726 165 60 9109513 0;
#P newex 690 117 64 9109513 t b erase b b;
#P newex 679 234 91 9109513 jit.gl.render window1;
#P newex 344 201 58 9109513 pak size 1 1;
#P newex 362 326 178 9109513 jit.window window1 @border 0 @pos 1 80;
#P newex 151 247 153 9109513 jit.gl.videoplane window1 @dim 1 1;
#P button 193 35 15 0;
#P newex 282 202 57 9109513 pak dim 1 1;
#P number 282 177 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 326 177 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 282 151 54 9109513 unpack 1 1;
#P message 162 61 26 9109513 stop;
#P message 132 61 26 9109513 read;
#P newex 282 127 73 9109513 route moviedim;
#P message 193 61 62 9109513 getmoviedim;
#P newex 151 99 55 9109513 jit.qt.movie;
#P comment 212 35 132 9109513 Use movies native dimension;
#P connect 30 0 29 0;
#P connect 28 0 22 0;
#P connect 22 0 21 1;
#P fasten 23 0 21 2 105 183 90 183;
#P fasten 24 0 21 3 143 183 115 183;
#P fasten 33 0 1 0 263 89 156 89;
#P fasten 2 0 1 0 198 88 156 88;
#P fasten 4 0 1 0 137 88 156 88;
#P fasten 5 0 1 0 167 88 156 88;
#P connect 9 0 1 0;
#P fasten 18 0 1 0 92 89 156 89;
#P fasten 19 0 1 0 304 90 156 90;
#P fasten 20 0 1 0 337 90 156 90;
#P fasten 29 0 1 0 35 88 156 88;
#P fasten 37 0 1 0 380 90 156 90;
#P fasten 43 0 1 0 448 90 156 90;
#P fasten 44 0 1 0 521 90 156 90;
#P fasten 45 0 11 0 14 241 156 241;
#P fasten 46 0 11 0 87 241 156 241;
#P fasten 40 0 11 0 169 227 156 227;
#P fasten 21 0 11 0 40 227 156 227;
#P connect 1 0 11 0;
#P fasten 11 1 41 0 299 271 180 271;
#P connect 41 0 42 0;
#P fasten 10 0 2 0 198 55 198 55;
#P fasten 1 1 3 0 201 125 287 125;
#P connect 3 0 6 0;
#P fasten 6 0 8 0 287 174 287 174;
#P fasten 8 0 9 1 287 197 310 197;
#P fasten 6 1 7 0 331 175 331 175;
#P fasten 7 0 9 2 331 197 333 197;
#P fasten 31 0 12 0 435 307 367 307;
#P fasten 13 0 12 0 349 236 367 236;
#P fasten 1 1 38 0 201 122 372 122;
#P connect 38 0 39 0;
#P fasten 8 0 13 1 287 198 373 198;
#P fasten 7 0 13 2 331 198 397 198;
#P fasten 8 0 27 0 287 195 419 195;
#P connect 27 0 28 0;
#P connect 32 0 31 0;
#P fasten 7 0 27 1 331 195 436 195;
#P connect 26 0 25 0;
#P fasten 15 0 14 0 695 185 684 185;
#P fasten 15 1 14 0 713 185 684 185;
#P fasten 25 0 14 0 645 202 684 202;
#P connect 36 0 34 0;
#P connect 34 0 15 0;
#P connect 15 2 16 0;
#P connect 35 0 34 1;
#P connect 15 3 17 0;
#P pop;


May 5, 2006 | 4:44 pm

sorry,
just found the old topic from the maillist concerning uyvy under XP from Joshua.
With his uyvy2argb shader for PC its working but doesn’t bring significant speed boost. Is there any other way under XP as I am working right on the edge of my CPU.
By the way: In the old topic from 2005 was mentioned that there will be Version 1.5.3 by the end of the year with the uyvy problem solved. Couldn’t find it yet :)

best

Paul


May 5, 2006 | 5:04 pm

On May 5, 2006, at 6:44 PM, tom wrote:

> just found the old topic from the maillist concerning uyvy under
> XP from Joshua.
> With his uyvy2argb shader for PC its working but doesn’t bring
> significant speed boost. Is there any other way under XP as I am
> working right on the edge of my CPU.

Nope. In fact the UYVY solution for PC would just do this same shader
solution behind the scenes. Sounds like your bottleneck is elsewhere
(movie decompression for example)

> By the way: In the old topic from 2005 was mentioned that there
> will be Version 1.5.3 by the end of the year with the uyvy problem
> solved. Couldn’t find it yet :)

Forthcoming…schedule was shuffled based on a few things, including
the priority of the MacTel port.

-Joshua


May 5, 2006 | 5:56 pm

thanks,

> Nope. In fact the UYVY solution for PC would just do this same
> shader
> solution behind the scenes. Sounds like your bottleneck is
> elsewhere
> (movie decompression for example)

Thats not the problem, I am pretty sure.
If I set jit.qt.movie colormode to uyvy and leave the videoplane mode at argb the framerate is approximately doubled – sure with wrong color as there is no conversion done. So I conclude the problem is lying within this conversion process.

What is actualy happening in the jitter-background when I switch the colormode of the videoplane to uyvy? Is Jitter automaticaly switching to cpu conversion when he gets an error from openGL (because the outcome is correct, just a bit to slow).

thanks

paul


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