wrong method to get movie dim ?

Jan 20, 2008 at 12:16am

wrong method to get movie dim ?

why is this not working properly ?
i want to retrieve the dimenesions of a movie immediatly after being loaded. when using the [route read] method to retrieve the dim i need to select the movie twice in order to get the correct dimensions, which should not be the case (?).
from the tutorial 4 about [route read] : “…This message has two purposes: first, to let you know that the movie file has been successfully located and opened; second, so that you can use this message to trigger subsequent actions in the Max patch…”
so if i undersand well if the movie has been properly located and opened i should be able to get its dimensions without any problem when usin this method ?

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P comment 294 127 100 196617 720 480;
#P newex 332 248 51 196617 print dim;
#P message 201 128 83 196617 read dvkite.mov;
#P message 187 110 83 196617 read dishes.mov;
#P user jit.pwindow 63 256 82 62 0 1 0 0 1 0;
#P toggle 65 104 15 0;
#P newex 64 132 52 196617 metro 33;
#P newex 223 248 47 196617 t getdim;
#P newex 173 223 60 196617 unpack s 1;
#P newex 173 201 328 196617 route read dim;
#P newex 64 170 155 196617 jit.qt.movie @adapt 1 @unique 1;
#P comment 280 109 100 196617 320 x 240;
#P connect 8 0 1 0;
#P connect 9 0 1 0;
#P connect 2 1 10 0;
#P connect 4 0 1 0;
#P connect 1 0 7 0;
#P connect 6 0 5 0;
#P connect 5 0 1 0;
#P connect 2 0 3 0;
#P connect 1 1 2 0;
#P connect 3 1 4 0;
#P window clipboard copycount 12;

#35454
Jan 21, 2008 at 1:04am

anybody ? pleazzzzz ?
could anybody point out what i am doing wrong here ?

Quote: (karrrlo) wrote on Sun, 20 January 2008 01:16
—————————————————-
> why is this not working properly ?
> i want to retrieve the dimensions of a movie immediatly after being loaded. when using the [route read] method to retrieve the dim i need to select the movie twice in order to get the correct dimensions, which should not be the case (?).
> from the tutorial 4 about [route read] : “…This message has two purposes: first, to let you know that the movie file has been successfully located and opened; second, so that you can use this message to trigger subsequent actions in the Max patch…”
> so if i undersand well if the movie has been properly located and opened i should be able to get its dimensions without any problem when usin this method ?
>
>
>
> #P window setfont “Sans Serif” 9.;
> #P window linecount 1;
> #P comment 294 127 100 196617 720 480;
> #P newex 332 248 51 196617 print dim;
> #P message 201 128 83 196617 read dvkite.mov;
> #P message 187 110 83 196617 read dishes.mov;
> #P user jit.pwindow 63 256 82 62 0 1 0 0 1 0;
> #P toggle 65 104 15 0;
> #P newex 64 132 52 196617 metro 33;
> #P newex 223 248 47 196617 t getdim;
> #P newex 173 223 60 196617 unpack s 1;
> #P newex 173 201 328 196617 route read dim;
> #P newex 64 170 155 196617 jit.qt.movie @adapt 1 @unique 1;
> #P comment 280 109 100 196617 320 x 240;
> #P connect 8 0 1 0;
> #P connect 9 0 1 0;
> #P connect 2 1 10 0;
> #P connect 4 0 1 0;
> #P connect 1 0 7 0;
> #P connect 6 0 5 0;
> #P connect 5 0 1 0;
> #P connect 2 0 3 0;
> #P connect 1 1 2 0;
> #P connect 3 1 4 0;
> #P window clipboard copycount 12;
>
—————————————————-

#120891
Jan 21, 2008 at 3:37am

Works fine for me. The unpack is unnecessary unless you actually want to filter out failed read attempts (in which case you want to pass it to a and then to the trigger obj). But it works nevertheless. Maybe you’re computer is slow and you need a deferlow after the trigger?

Zachary

#120892
Jan 21, 2008 at 3:47am

No wait, you’re absolutely right. Wasn’t paying close enough attention to it. Even with a deferlow it doesn’t work. Appears to be a period after the movie is loaded when the info hasn’t yet updated. A del 500 solves it for me:

max v2;
#N vpatcher 10 59 440 425;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 236 276 43 131137545 t getdim;
#P newex 236 252 40 131137545 del 500;
#P newex 236 229 30 131137545 sel 1;
#P newex 190 205 56 131137545 unpack s 1;
#P comment 274 85 100 131137545 720 480;
#P newex 219 183 51 131137545 print dim;
#P message 180 84 83 131137545 read dvkite.mov;
#P message 166 66 83 131137545 read dishes.mov;
#P user jit.pwindow 44 214 82 62 0 1 0 0 1 0;
#P toggle 45 62 15 0;
#P newex 45 90 52 131137545 metro 33;
#P newex 190 152 69 131137545 route read dim;
#P newex 45 128 155 131137545 jit.qt.movie @adapt 1 @unique 1;
#P comment 260 67 100 131137545 320 x 240;
#P connect 4 0 3 0;
#P connect 6 0 1 0;
#P connect 7 0 1 0;
#P connect 13 0 1 0;
#P connect 3 0 1 0;
#P connect 1 0 5 0;
#P connect 1 1 2 0;
#P connect 2 0 10 0;
#P connect 2 1 8 0;
#P connect 10 1 11 0;
#P connect 11 0 12 0;
#P connect 12 0 13 0;
#P pop;

#120893
Jan 21, 2008 at 4:15am

The ‘problem’ here is @unique 1

if you remove @unique 1, and do ‘read movie.mov, bang, getdim’ it
works as expected, at least, it does here. The getdim ‘issue’ happens
between the unique frames, thus the del 500 is long enough to wait so
that jit.qt.movie reads the next FRAME (since bang, with @unique, 1
does not update the frame immediately). ONCE the new frame is loaded
it appears to report the dim properly.

I would think this is a bug.

The workaround would be something like: This works everytime, as has
as small a delay as possible.

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P message 228 383 40 196617 getdim;
#P newex 285 315 32 196617 sel 1;
#P newex 225 339 45 196617 onebang;
#P comment 354 187 100 196617 720 480;
#P newex 392 308 51 196617 print dim;
#P message 214 199 83 196617 read dvkite.mov;
#P message 200 181 83 196617 read dishes.mov;
#P user jit.pwindow 124 336 82 62 0 1 0 0 1 0;
#P toggle 125 164 15 0;
#P newex 124 192 52 196617 metro 33;
#P newex 233 283 60 196617 unpack s 1;
#P newex 233 261 328 196617 route read dim;
#P newex 124 230 155 196617 jit.qt.movie @adapt 1 @unique 0;
#P comment 340 169 100 196617 320 x 240;
#P fasten 13 0 1 0 233 406 575 406 575 135 129 135;
#P connect 11 0 13 0;
#P connect 1 0 6 0;
#P connect 1 0 11 0;
#P connect 12 0 11 1;
#P connect 3 1 12 0;
#P connect 7 0 1 0;
#P connect 8 0 1 0;
#P connect 4 0 1 0;
#P connect 1 1 2 0;
#P connect 2 0 3 0;
#P connect 5 0 4 0;
#P connect 2 1 9 0;
#P window clipboard copycount 14;

On Jan 20, 2008, at 10:47 PM, Zachary Seldess wrote:

>
> No wait, you’re absolutely right. Wasn’t paying close enough
> attention to it. Even with a deferlow it doesn’t work. Appears to be
> a period after the movie is loaded when the info hasn’t yet updated.
> A del 500 solves it for me:
>
> max v2;
> #N vpatcher 10 59 440 425;
> #P window setfont “Sans Serif” 9.;
> #P window linecount 1;
> #P newex 236 276 43 131137545 t getdim;
> #P newex 236 252 40 131137545 del 500;
> #P newex 236 229 30 131137545 sel 1;
> #P newex 190 205 56 131137545 unpack s 1;
> #P comment 274 85 100 131137545 720 480;
> #P newex 219 183 51 131137545 print dim;
> #P message 180 84 83 131137545 read dvkite.mov;
> #P message 166 66 83 131137545 read dishes.mov;
> #P user jit.pwindow 44 214 82 62 0 1 0 0 1 0;
> #P toggle 45 62 15 0;
> #P newex 45 90 52 131137545 metro 33;
> #P newex 190 152 69 131137545 route read dim;
> #P newex 45 128 155 131137545 jit.qt.movie @adapt 1 @unique 1;
> #P comment 260 67 100 131137545 320 x 240;
> #P connect 4 0 3 0;
> #P connect 6 0 1 0;
> #P connect 7 0 1 0;
> #P connect 13 0 1 0;
> #P connect 3 0 1 0;
> #P connect 1 0 5 0;
> #P connect 1 1 2 0;
> #P connect 2 0 10 0;
> #P connect 2 1 8 0;
> #P connect 10 1 11 0;
> #P connect 11 0 12 0;
> #P connect 12 0 13 0;
> #P pop;
>
> –
> http://www.zacharyseldess.com
>

#120894
Jan 21, 2008 at 7:42am

On 21 janv. 08, at 05:15, vade wrote:

> I would think this is a bug.

I don’t think it’s the case. My understanding of the behavior is that:
sending getdim to [jit.qt.movie] returns the size of the output
matrix, as adapt attribute is on, this means that it will change as
soon as it needs to output the first frame. The problem is that you
ask for the dimension of the matrix just after reading the file, not
after outputting the first frame. That’s why I suggested using
getmovie_dim instead of getdim.

Cheers,
ej

#120895
Jan 21, 2008 at 11:59am

thanks for your help Emmanuel, Vade, Zach for your help , some questions/comments :

—————————————————-
> On 21 janv. 08, at 05:15, vade wrote:
>
> > I would think this is a bug.

i wasn’t sure about it but i would expect that when a file is opened most of the quicktime info is ready to be retrieved without needing to play a first frame (?).
what if one needs the dim of a movie before starting actually playing it and/or being set on “autosart 0″

> Quote: Emmanuel Jourdan wrote on Mon, 21 January 2008 08:42 :
—————————————————-
> On 21 janv. 08, at 05:15, vade wrote:
>
> > I would think this is a bug.
>
> I don’t think it’s the case. My understanding of the behavior is that:
> sending getdim to [jit.qt.movie] returns the size of the output
> matrix, as adapt attribute is on, this means that it will change as
> soon as it needs to output the first frame.
The problem is that you
> ask for the dimension of the matrix just after reading the file, not
> after outputting the first frame.

yes Emmanuel but isn’t one of the function of the adapt mode to get out of the [jit.qt.movie]‘s default 320×240 dim ? why would a first frame be needed to actually “adapt” the [jit.qt.movie] to the actual movie dim ?

anyway the “getmovie_dim” message works like a charm, thanks Emmanuel, i oversaw this message in the help and reference file
( although it is spelled “getmoviedim” (both work fine) ).
it makes more sense to use this message then the getdim anyway ( at least for my needs )
thanks a lot Vade for your work around, it works fine but i need to be in unique 0 mode ( which of course could be set after receiving the dim info, in my case…)

thanks Zach for doublechecking i was not crazy :)

anyway problem solved all is good now:

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P message 319 222 50 196617 720 480;
#P newex 319 197 62 196617 prepend set;
#P newex 196 197 88 196617 t b getmovie_dim;
#P newex 197 174 254 196617 route read movie_dim;
#P comment 281 92 100 196617 720 480;
#P message 187 91 83 196617 read dvkite.mov;
#P message 173 73 83 196617 read dishes.mov;
#P user jit.pwindow 51 221 82 62 0 1 0 0 1 0;
#P toggle 52 69 15 0;
#P newex 52 97 52 196617 metro 33;
#P newex 52 135 217 196617 jit.qt.movie @adapt 1 @unique 1 @autostart 0;
#P comment 267 74 100 196617 320 x 240;
#P connect 9 1 1 0;
#P connect 9 0 1 0;
#P connect 1 1 8 0;
#P connect 1 0 4 0;
#P connect 2 0 1 0;
#P connect 6 0 1 0;
#P connect 5 0 1 0;
#P connect 10 0 11 0;
#P connect 8 1 10 0;
#P connect 8 0 9 0;
#P connect 3 0 2 0;
#P window clipboard copycount 12;

#120896
Jan 21, 2008 at 1:36pm

On 21 janv. 08, at 12:59, karl-otto von oertzen wrote:

> yes Emmanuel but isn’t one of the function of the adapt mode to get
> out of the [jit.qt.movie]‘s default 320×240 dim ? why would a first
> frame be needed to actually “adapt” the [jit.qt.movie] to the actual
> movie dim ?
>
> anyway the “getmovie_dim” message works like a charm, thanks
> Emmanuel, i oversaw this message in the help and reference file
> ( although it is spelled “getmoviedim” (both work fine) ).
> it makes more sense to use this message then the getdim anyway ( at
> least for my needs )

yeah, my understanding is that when you query the [jit.qt.movie]
object to get the output matrix dimension, the adapt hasn’t been made
yet, because this is done, the first time you ask for a frame (when
you send a bang). Whereas getmoviedim just ask the dimensions of the
file that you just successfully opened.

ej

#120897

You must be logged in to reply to this topic.