Forums > Jitter playback pausing when loading in Windows 7, it works under OSX

March 7, 2013 | 11:40 pm

When I play the same simple patch on OSX, there are no pauses / breakes after loading.
But under Windows 7 playback pausing after loading for about 0.5-1 second.
I have tested each, on the same computer with OSX and Windows 7. See below.

OSX SL and Lion or Windows 7 on a:
MBP QuadCore i7 with BootCamp
Hackintosh QuadCore i7 and SSD with dual boot
Newest QuickTime
Codec: Motion JPEG A 800×400 Quality70%, same with other codecs!

Is QuickTime bad implemented under Windows? Someone knows a solution or has experienced something similar?

March 8, 2013 | 8:23 pm

Hy, are I’m alone with tat?
Have the same problem with the simple help-patch.

March 11, 2013 | 10:14 pm

Please help!

I un- and reinstall Max6 and QT. Still the same problem. It’s curious with usage of a SSD.
I have the same problem with the simple help-patch! No difference if I use preroll 1 or not. Under OSX it load and play direct with NO pause or freeze, not under Windows! Resolution 800×600 not 800X400 ;)
It would be nice if I could use cheaper Windows hardware!

May someone could give a feedback? Is this normal or not?

March 12, 2013 | 1:33 am

I have no definitive news for you, but it sounds like a platform issue. Perhaps related to other things like a large search path, virus protection, etc.

If you send an absolute path, rather than just the file name, is the behavior different? That would suggest search path size/overhead.

However, you might want to use the asyncread message to do the loading in a background thread.

March 12, 2013 | 11:08 pm

Thanks Joshua for response!

The videos are in the seventh path level and I already used absolute path.
I tested asyncread, just the file name, turned off the only virus scanner Windows Defender (real time protection), move the folder to a higher path level. No difference, also not on the other MBP with BootCamp! There still is about 300ms freeze after read!

Tests with other codec’s such as H.264 in HD plays fine under OSX, but still not under Windows. (In the folder there are 36 videos MJPGA aprox. 20sec long).

I noticed that when I run the QuickTime-application, the mouse-circle-spinning and blocks for 6sec. After that I can open a second video without spinning. Is this normal?

It’s a fresh Windows 7 Prof. 64bit. 3.4GHz i7 quad core, 32GB, 30GB free of 111GB SSD, Radeon HD6800, OpenGL, actual QT7.7.3, all benchmarks looks fine. I use only one User=Admin.
The other computer is a MBP BootCamp Windows 7 Prof. 64bit. 2.2GHz i7 quad core, regular HD.

Where could be the problem? Perhaps with the 64bit system?

March 12, 2013 | 11:48 pm

Unfortunately, this sounds like QT is at fault. You can try loading all your movies in advance like the "poly~ for movies" example patch.

Otherwise, I’d recommend searching online for general QT performance issues under windows.

Sorry for the nuisance. That sounds like an impressively fast machine, and frustrating to have QT as your bottleneck. Under Jitter 64bit, we do have preliminary support for using DirectShow for playing back movies, but it is a long way towards being useful, and I’m not sure if it exhibits any better loading performance.

If you discover anything, please share your experience here.

March 29, 2013 | 5:18 pm

Hi michel8 !

Your "playback pausing after loading for about 0.5-1 second" is troubles with installed directshow codecs & video splitters (muxers/demuxers).

We must know – what codecs use Windows for playing video files in different formats !

In Graphedit (graphedt.exe is present in x32 & x64 different versions) we can see as Windows build graph for correct playing video, by using active codecs/splitters.

GSPOT.exe – x32 codec management tool – will help to change merits and re-regiser/unregister installed codecs.

Win7DSFilterTweaker & CodecTweakTool from K-LITE codec pack will help generally manage video codecs for x32 & x64 systems.

BUT time to time MAX 6 uses other codecs unlike graphedt.

At first, deinstall ALL thrid-party codecs for h264 & DivX.

Check Your system about codecs errors in CodecTweakTool.exe => General => Fixes

Try to unstall free LAV filters x32 or(and) x64.
In LAV Video Decoder property page You can select different GPU-accelerated modes.

For controlling activation LAV filters – check the box for tray icon in LAV slitter & LAV codec

I start codecs theme

I want to buy MAX x64 – and learn actively & it differences from x32 version.
And must say – Max 6.1.1 x32 – works much better than Max 6.1.1 x64 in questions of Jitter.

March 31, 2013 | 2:28 pm


So had this work-flow helped you to eliminate the playback pause after loading in Max6 x32 with Win x64 ??

For me it would be great to run my patches with Win x64 and Max6 x32. (It is still too early for a complete functionality to work with Max6 x64 for me).


Thanks JOSH

I have not figured out regarding QT and Win x64.
poly~ would be a solution, but I have to reprogram a lot of logical work flow.

April 3, 2013 | 4:12 pm

Max6 x32 works fine on Win7x64.
You can (windows must) use all internal standart & thrid-party x32 videocodecs.
On your hardware should not be any lag !!!
I need thrid-party codecs only on MAX6 x64.
Try QuickTime Alternative 3.22 + 3ivx videocodec.

April 3, 2013 | 5:52 pm

From my experience on PCs, it probably doesn’t have anything to do with that DSfilter stuff Vital VJ is talking about. The Codec itself can make a huge difference in playback rate/processor use, but I’m not sure what he is talking about is even happening within Jitter and the quicktime object on a 32bit system.
Max/Jitter on PC has always been problematic in ways that aren’t addressed, but subtly disappoint. This is especially true of anything to do with file handling/loading/parsing. If you have a finite set of videos, I’ve found that creating a bunch of qt objects and starting and stopping the videos gets you proper triggering without delays. This is sort of like the poly object idea, but perhaps less limiting if you want to do something like crossfade the videos without having two sets of them. This approach should work fine if you’ve got something like a finite set of 20 videos, or even "sets" that you can load (realizing there will be a long, cludgy pause when loading the entire set).
It is good to go through all the parts of your process and see if something unexpected is causing the pause. I’ve eliminated some issues that were related to using umenu for file choosing as an example. The "@frames unique" attribute can cause things to be less crisp. There’s also the question of whether the loading is freezing the entire output, or just the source itself. So, if you have a second movie playing, does it freeze when you load another in a separate object? If it is freezing everything, it may have as much to do with UI, threading, or screen updating as it does to do with that one file loading. I’m not sure if the example patch you’re referencing involves dragging and dropping files, but that is pretty much a complete joke on a pc.
All that said, if it works cleanly on a Mac and dirty on a PC, then you may just be screwed. That level of system specific tweaking doesn’t seem to be a high priority. It probably does come down to Quicktime on PC implementation, and of course Apple has a vested interest in making sure that never works quite as well on a different platform than their own.
If you have an example/direction of what you’re aiming at, maybe I can provide a more constructive response.

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