Forums > Jitter

Preparing QT for playing in reverse

January 11, 2009 | 4:46 am

I’m using jit.qt.movie to play 720 X 480 QT movies in reverse.
I’m presently using H.264 compression, but the interframe compression slows down playback in reverse considerably in contrast to forward playback.

Does anyone have a recommendation on a codec for compressing QT movies that works better than H.264 for playing in reverse with hit.qt.movie, but keeps the visual quality high?

Thanks
Robert


January 11, 2009 | 5:12 am

OK, I’ve tried Motion JPeg A and Motion JPeg B–both are a vast improvement.

If anyone has other suggestions, I’m open. But these work pretty well.

Thanks,
Robert


January 11, 2009 | 5:28 am


January 11, 2009 | 6:01 am

I also noticed that with an audio track, jit.qt.movie seems to have more problem changing speed rapidly, and going in reverse. With no audio track it seems to be fine, the video frames seem to play pretty smoothly, but scaling the audio seems to cause the problems (which kind of makes sense I guess, seems harder processor-wise).

Similar but a bit off-track: … in the audio world–sfplay~ also seems to be much less stable with changing speed, particularly in reverse, compared to groove~ :: I’ve had a lot of crashes with sfplay~ changing speeds, but never with groove~… XP, 5.0.4. The benefit of sfplay~ is the instant-start as opposed to loading files into a buffer~, but if you want to do mad manipulation of speed and loop-points etc., groove~ has never failed me.

That said, the crashes with sfplay~ have been only on my laptop, so that might be something else. I’ve also seen sfplay~ "die" a lot (simply stop playing, but not crash Max) with lots of speed changes, and it needs to be restarted to "wake up" and work again, on a number of computers. Anyone else notice a big difference between groove~ and sfplay~, on other comps/platforms?

CJ


January 12, 2009 | 11:53 pm

I can say that including audio in the playback clearly slowed down the program’s playback. It was much smoother without audio. However, I want the audio, so not using it isn’t an option for me.

-Robert


January 13, 2009 | 1:49 am

one minor piece of advice on that one is to make sure the audio is encoded
in a pcm format (e.g. AIFF or WAV). if the audio is MP3 or AAC or anything
like that then it will have the same problems playing in reverse that
temporally-compressed video (e.g. H.264) has.
/luke

On Mon, Jan 12, 2009 at 6:53 PM, Robert Edgar wrote:

>
> I can say that including audio in the playback clearly slowed down the
> program’s playback. It was much smoother without audio. However, I want the
> audio, so not using it isn’t an option for me.
>
> -Robert
>


January 13, 2009 | 9:22 pm

i’ve always preferred extracting the audio to a separate file and playing it with msp objects. much more control that way. you can easily sync your qt.movie to your sound file.

http://www.cycling74.com/forums/index.php?t=msg&goto=147602

Quote: rbedgar@stanford.edu wrote on Mon, 12 January 2009 16:53
—————————————————-
> I can say that including audio in the playback clearly slowed down the program’s playback. It was much smoother without audio. However, I want the audio, so not using it isn’t an option for me.
>
> -Robert
—————————————————-


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