SafeVideoInput patch not recognized

the flag isn't part of the composition, it's part of the QC code, so doing the 10.5 -> 10.4 -> 10.5 hand waving wouldn't be profitable.

The patch doesn't show up because it doesn't add a new patch (you installed it to the correct place, thank you so much for reading that, and following the directions :)

From the plugin page: "Safe Video Input is a patch that modifies the existing built-in video input patch to work in safe mode." -- it doesn't make a new patch, it modifies the existing Video Input patch. To see if it's working, select the "Show Unsafe Patches" and see if the video input patch gets branded or not -- if it's working it shouldn't change (unsafe patches show a little yellow key symbol, safe ones don't).

D'Oh! Sorry, I missed the part about modifying the original patch (rather than adding a new one). You're right -- it now does not show the key icon for unsafe patches.

But, when I export as QT and try to open the QT, the QT Player and Finder both freeze so I need to do a Force Quit on both of them. Not able to open the QT. (I was able to "Test in Runtime" in QC without problem though). Even simply highlighting the exported QT without launching it will freeze the Finder as it tries to fetch info and do a preview that you see when you single click a QT movie.

It's a very simple patch configuration I'm using: connect "Image" from "Video Input" to "Image" from "Billboard". Works great in the QC environment.

Am I overlooking something else that makes the export to QT not work? (I export at 640x480, using "2" as the image parameter in "Width" for Billboard). One thing that is curious is that the icon for the exported QT movie isn't a QT movie icon -- it is the black/grey QC icon. Is something wrong with the creator type?

Many thanks!

This used to work -- maybe they've changed something in the QT exporter or QT player.

Either way, why are you exporting to a qt movie? it's not like you'll be able to distribute the movie and have it work for other people without the plugin.

In tracking it down some, it appears to be a bug with QuickTime/QTKit -- specifically, if you export a composition it works as expected (even in quicklook and quicktime), but with it as a movie QT deadlocks (meaning it's opened the camera or some part of the camera framework, so when the movie does it gets stalled, waiting for the camera/framework which never gets released)

Even more research: This only becomes a problem with the QT 7.5 update -- in 7.4.x it works as expected.

Conclusion: Don't blame us, blame apple. And don't export to movies.

[For those keeping score at home, feel free to follow this thread to track the discussion on the bug: http://lists.apple.com/archives/quicktime-api/2008/Jun/msg00094.html ]

Ah, thanks for the insightful and definitive comments.

Alas, this would have been for a museum exhibit (where I have control of the machines, and there are no privacy issues because people are expecting to see themselves in the program).

But because it is disabled, I won't be able to use the platform. It would have been very cool -- visitors would have walked into a room full of large screen iMacs, and been awed. But because this feature is now disabled, I have no way of pulling live video into the interactive, and will now have to go over to the Windows platform. (Granted, the cool CQ features won't at all be possible, but at least live video isn't so wrangled).

So, if there's a case to make to Apple: for those of us in the location-based media business, the disabling is a major downer. And rather than seeing Macs in high visibility public installations, they're going to see Dells. (I do like Dell, but was hoping to do this on a Mac to highlight cool video features)...

(end of rant)

I follow the rest, but I don't get why you can't just load the .qtz into quicktime?

The main reason I've found to export as quicktime is for capture - i.e. you can set the screen resolution to a specific size, then export the file as an mp4 or whatever.

I second this .... I still don't follow why a .mov is essential -- you can open a QTZ in QuickTime, and it still functions identically. You can embed QTZ in applications just like Movs or webviews... there's no functional difference that I can think of between qtzs and movs, except that movs exported from QC are useless (seriously, I've used the feature a total of 3 times, once because I thought it was cool until I found out it wasn't, and twice for bug reports [this being the second one])

Try using a .qtz, and tell us if it works or not -- you could be in for a pleasant surprise :)

...that I can't imagine applying here, but maybe somebody will find them useful.

• You can export as .mov, then use quicktime to add an audio track to the .mov file. That way you can make a distributable composition with audio (I don't know of any other way of doing that without multiple files and potential for things not working). Especially handy if you want a small, portable composition, as you can use midi. You could probably package all sorts of stuff in there actually.

• You can do other stuff with a .mov file. It's possible to set it to play fullscreen, and quit quicktime when it ends, so when you double-click the file, it plays fullscreen then quits. You can also limit what can be done with the file, and you can compress it (I looked into this for a bit of a mad scheme, it looks like you'd have to write a custom quicktime encoder, but you could compress the .qtz data with zlib or similar and include an mp3 or compressed midi in the file).

• I've not tried this, but quicktime effectively lets you edit a .mov like a video, so it's probably possible to mix several compositions and cut between them at set times, and save them as a single file.

It might not be the great feature it first looks like, but it has got its uses :D

Ah, I didn't know these were options -- (I just discovered Quartz Composer yesterday...). So I was able to open the .qtz file in QT Player. It wasn't optimal -- the video played for a few seconds, then jerked, then played again, and then continued in this fashion. Maybe I didn't have some settings optimized on the export?

But really I think I need a QT .mov (and not .qtz) so I can import it into another environment. Ideally Adobe's new Director 11, or possibly Flash. And while Director didn't allow import of the .qtz when I tried just now, it did allow import of the exported QT (the one that crashed the Finder). Surprisingly, on import, the QT behaved as expected, displaying live video.

If this continues to work, it's great. I'm a little leary of the fact that the QT crashed the Finder when I tried to launch from the Finder. Museum applications need to be rock solid for day to day operations. Though it does seem to run in the authoring environ (though with the jerks, and sometimes freeze of image, though not a crashed app). (Note: I think the freeze is just because the default time assigned to the qtz ran out).

Any suggestions on why the image might be jerky? I exported at 640x480 (I believe)...any other factors that might interfere? And is there reason to think this will or won't be stable over time, now that I basically seem to have it running in the authoring environ? (Once again I'm on the roller coaster thinking I can stay on Mac, but I've ridden this coaster before ;-) Many thanks!

The audio track thing is pretty slick -- hadn't thought of that. The rest of those features look like post-production-type stuff.

Playing fullscreen/quitting on end isn't difficult to do in a stand alone player (though granted, none do that out of the box presently, which is extremely stupid:( ). How useful is compression, really (curious, I've not really tried it) -- compositions are binary p-lists that are already pretty compact, and they only get large when you embed video/images, which zlib doesn't compress well anyway (except for some special cases).

I wonder how deterministic off-line editing is for compositions -- I'm willing to bet it's trivial to make a composition that will mis-render when accessed non-linearly (i.e. you're not "playing it", but reading it for editing, starting at different time offsets). [relatedly, we're fighting with this problem in the particlesystem patch]., so for me it's not nearly as useful as a rendered video where I can jump to arbitrary frames, and get consistent results. (I've been working on a multi-sampling offline renderer that will probably run into this problem as well, and I don't know of a good solution to it)

May or may not be a deal breaker, depends on what your needs are :) Thanks for pointing out its strengths though, good to know :)

not sure why it's jittering -- I have no idea what your composition is doing.

The stability isn't a "crash" bug, it's a simple framework init bug. If it doesn't get triggered on QT init, it won't randomly happen while it's running. The safe video patch only modifies some registration code (specifically, the function the video input patch uses to say it's unsafe, we change that to say it's safe) -- no impact on long-term stability, since it's not executed after the QC environment is up and running.

do some tests (run it over night how it will be deployed, etc), I'm almost 100% certain it will only crash on either startup, or never. no surprises in the middle.

I think you may have missed something important here. When you export to a .mov file, it doesn't actually make a video - it hides a .qtz file inside a .mov file. When you load the .mov in quicktime (or anything else) it's basically quartz composer playing the composition in realtime.

If it's a video .mov file you're after, export as .mov at your desired resolution, load it in quicktime, then export it from quicktime and chose the file type etc. The video will always be perfectly smooth - you can set it to record at high framerate too if you need that (I used this to do some video at 1080p60 - 60fps video for perfect smoothness!)

Another word of warning - director and flash might load a .mov export straight from quicktime, because they probably use quicktime for video playback and quicktime will call quartz to play it. But it will probably cause major headaches down the line - it definitely won't play on a PC until it's been converted to video, and the exported flash or shockwave files might not work.

Oh, and the jerkiness - it's probably just that your computer isn't fast enough to handle the video at full screen resolution. You're exporting the .mov version at 640x480, so it will play at that size, but the .qtz version doesn't have a resolution set so it will play at whatever your screen is set to - probably at least 4x higher, which means it will need 4x more power to play smoothly.

The fullscreen/quit thing is actually better using the .mov method than making an app I reckon. It has a fair few advantages - it's more portable, single file, smaller, pops up a quicktime movie controller for pause/fastforward etc., and drops back to windowed mode when you press escape. That's all assuming you have no plugins involved of course, otherwise forget it :)

Compression - I can't see it being all that useful to be honest. It would probably shrink the file a fair bit more, but .qtz files aren't generally that big unless they contain images etc. as you say, and it involves writing a custom .mov compression app as I don't think that feature of quicktime has ever actually been implemented anywhere. I was looking at it with a view to making a 64k demo in .mov format, as a challenge, using QC and midi.

If you are interested in crunching a .qtz file down, try editing the plist instead, you'll probably get rid of 30-50% with ease that way. Just rename the file to .plist and edit it with plist editor (or save it in that and use any xml editor once it's in normal plist format).

You can get rid of all the userdata stuff - actually anything not related to the actual patches can go. You can also completely remove every parameter that has a default value - the default will be put back in when you load or play the file again. If you're using patches with default settings that means all data can go apart from connections to other nodes!

When you're done stripping it, save it as a plist, and use the plutil CLI app to convert it back to bplist. I reckon that could be automated with a bit of shell scripting, plus replacing patch names + inputs with single characters to cut a few more bytes of fat. I doubt I'll do it now though, the hassle of persuading people that it's not just a heavily compressed video is too great ;D

Offline editing - yeah, not sure how useful it is (assuming it works at all :). Timing can certainly be a pain (especially if you have audio playback via a movie loader - that really messes up, even when exporting as a movie. It's easier to add the audio back in after export :/ ).

I can see it being handy to put a few examples of an effect into a single file quickly and easily though, which actually makes it a damn useful tip for sites like this :D I'll try it sometime.