multiple video mixing, optimizing

Dec 8, 2007 at 12:38am

multiple video mixing, optimizing

new user (<2mths)

i have been working on a multiple video mix patch that takes input from cv.jit/lkflow. I have the input for this patch working well… sending the integers -1,0,1 corresponding to movement in left and right direction.

the goal with this patch is to select random movies that correspond with movement direction: left=-1/right=+1. when the patch is inactive for 5 seconds it should (xfade) to randomly selected movie from the center list (0)

In addition Ive been trying to optimize for this playback. ive turned off “use onscreen” and attempted to use “qlim” on the “pwindows”

MacbookPro, OSX10.4
QTmovies are compressed: 640*480 jpg, 10fps

Any advice, suggestions, or references to specific tutorials would be much appreciated.

thank you, this is my first official post.

#34932
Dec 8, 2007 at 1:57am

Use raw (uncompressed) qt videos. And if available, keep the qt files on a FAST external hard drive.

#118479
Dec 8, 2007 at 3:40pm

this is not good advice.

there are very few applications which use uncompressed video well, and
jitter is one of them.

On Dec 7, 2007, at 8:57 PM, Colin Wright wrote:

>
> Use raw (uncompressed) qt videos. And if available, keep the qt
> files on a FAST external hard drive.
>

#118480
Dec 8, 2007 at 3:48pm

i mean, NOT one. use photojpeg if you have to jump from frame to
frame or play backwards.

if your source files are dv use those, and play them in gl with
jit.qt.movie @adapt 1 @colormode uyvy running into jit.gl.videoplane
[glcontextname] @colormode uyvy.

On Dec 8, 2007, at 10:40 AM, joshua goldberg wrote:

> this is not good advice.
>
> there are very few applications which use uncompressed video well,
> and jitter is one of them.
>
> On Dec 7, 2007, at 8:57 PM, Colin Wright wrote:
>
>>
>> Use raw (uncompressed) qt videos. And if available, keep the qt
>> files on a FAST external hard drive.
>>
>
>

#118481
Dec 8, 2007 at 5:32pm

Josh – uncompressed is ALWAYS the way to go if you have the drives to
handle it. Uncompressed video has no inter or intra frame encoding, so
jumping to a frame is just as easy as mjpeg etc – but you DO need fast
fast fast disks to handle it otherwise you will be seriously sluggish.

Uncompressed SD NTSC is 27MB/s, uncompressed HD is ~160MB/s

If you have a raid, go for it.

On Dec 8, 2007, at 10:48 AM, joshua goldberg wrote:

> i mean, NOT one. use photojpeg if you have to jump from frame to
> frame or play backwards.
>
> if your source files are dv use those, and play them in gl with
> jit.qt.movie @adapt 1 @colormode uyvy running into jit.gl.videoplane
> [glcontextname] @colormode uyvy.
>
>
> On Dec 8, 2007, at 10:40 AM, joshua goldberg wrote:
>
>> this is not good advice.
>>
>> there are very few applications which use uncompressed video well,
>> and jitter is one of them.
>>
>> On Dec 7, 2007, at 8:57 PM, Colin Wright wrote:
>>
>>>
>>> Use raw (uncompressed) qt videos. And if available, keep the qt
>>> files on a FAST external hard drive.
>>>
>>
>>
>

#118482
Dec 8, 2007 at 7:48pm

the video in question is an animation, original files are single jpgs. i have animated them with quicktime pro and reduced the file size to 640*480. It works very well until I run the aforementioned random movie editor with cv.jit. My jit.grab input framerate drops to about 4fps once I employ the editor. I have attended to the pwindow, turning off the “use onscreen” and attempted to use some of the techniques from an earlier post on “jitter optimization”. Still, my incoming video is no higher than 5fps until I close the attached “editor” patch.

thank you for the advice, I hope this clears up the problem a bit.

kc

#118483
Dec 8, 2007 at 7:55pm

can you post the patch?
otherwise – speculation abounds
On Dec 8, 2007, at 2:48 PM, kenneth wrote:

>
> the video in question is an animation, original files are single
> jpgs. i have animated them with quicktime pro and reduced the file
> size to 640*480. It works very well until I run the aforementioned
> random movie editor with cv.jit. My jit.grab input framerate drops
> to about 4fps once I employ the editor. I have attended to the
> pwindow, turning off the “use onscreen” and attempted to use some of
> the techniques from an earlier post on “jitter optimization”.
> Still, my incoming video is no higher than 5fps until I close the
> attached “editor” patch.
>
> thank you for the advice, I hope this clears up the problem a bit.
>
> kc

#118484
Dec 8, 2007 at 9:41pm

of course…

i am working on the solution you suggested, but am having trouble getting the three lists to output one at a time to a single window. i have been using “if/else” to control the bangs and it worked well on the first edit patch, but not yet on the “optimize edit” patch. see attached patch-

thanks for your advice re jit.gl, it does improve the fps. (the optimization post a few days ago has been helpful as well, i think i just need a little assist to implement it correctly)

kc

#118485
Dec 9, 2007 at 7:24am

will “pixelization”, rate change, or xfade work with the UYVY color optimization? It doesn’t appear to. Ive had a couple of crashes attempting it. I am trying to send the data out from the editor patch and mix it with another movie. Any suggestions?

Ive been looking through colorspace tutorial and multichannel playback optimization.

My movies are 640*480, highest quality jpgs. they range from 3-10mgs each… ive attached one of the smallest. (10seconds or so each) I wouldn’t mind recompressing them if need be, but need a compression that will work with time scrubbing in both directions, xfade, pixelization.

Thank you again,

#118486

You must be logged in to reply to this topic.