Get Ready for 64 Bit: QuickTime and FreeFrame

mark

Dear All,

As I continue working on the 64 bit version of Isadora which we'll release in September, I wanted to offer you all a couple of friendly reminders.

1) None of your 32 bit FreeFrame plugins will work in this new version. There's really no way around it: you simply can't load 32 bit code into a 64 bit app. That means that any patches that rely on 32 bit FreeFrame plugins won't work properly in the new version. (You'll be happy to know that the Quartz Composer plugins I've tested work fine as long as they don't contain compiled 32-bit code, which a handful of them do.)

2) As noted in this CDM article the writing is on the wall. QuickTime is going to die pretty soon. Apple has no plans to fix or update it, even though it is still superior to the native playback systems on Mac and Windows in many respects.

For Mac OS: We will continue to support QuickTime as for older versions of MacOS for as long as we can. But, for sure, any legacy codecs that rely on QuickTime will not work with MacOS 10.14 (the new version coming this fall) because QuickTime is 32 bit and will not run under the new operating system. By now you're probably not using (hopefully) ancient codecs like Animation, but if you are, you'll need to convert them if you expect them to play.

For Windows: We probably won't offer an option to play .mov files, though I'm willing to hear feedback on this. The security holes in QuickTime for Windows well known by now – though as I've said before, the reality of getting these getting exploited on your personal computer is rather low IMHO. Still, the American Dept. of Homeland Security actually tells public insitutions they cannot install it because of those security problems. (In theory, this means every public university in the USA.) The bottom line is that QuickTime will be less and less viable on PCs as time goes by.

So start getting yourself prepared for these changes. I'll be posting more about my progress on Isadora 3 in Mark's Blog. Check there to learn more about my progress, or to comment on things I'm thinking about.

Best Wishes,
Mark

CitizenJoe

So @Mark, I'm curious. Will there ever again be interactivity on Windows with video files the way there is on 32 bit QT video files?

Cheers,

Hugh

mark

@citizenjoe said:

Will there ever again be interactivity on Windows with video files the way there is on 32 bit QT video files?

We may need to make our own format to get that back (not to mention cross-platform compatibility). I'm taking a look a this https://www.indiegogo.com/proj...

However, we can't be the only one to adopt it. We'd need to get Arkaos, Resolume, QLab, etc. on board to make this work.

Best Wishes,
Mark

DillTheKraut

Arkaos is using FFmpeg. I'm pretty shure you already know, and there are reasons why you don't already consider it, but I'm curious why it isn't a possible solution? Open Source, crossplatform and if you follow the Arkaos developers, good performance.

https://www.arkaos.net/blog/20...

mark

@dillthekraut said:

and there are reasons why you don't already consider it

Mostly it is the legal considerations page of ffmpeg, specifically the section about patents. For example, they say:

Q: Does FFmpeg use patented algorithms?
A: We do not know, we are not lawyers so we are not qualified to answer this.

This leaves at least a potential door open for lawsuits that could put us out of business. It's just feels too dangerous.

Having a container and codecs that were clearly open source would certainly make me feel a lot more comorftable.

Best Wishes,
Mark

Fred

@mark I had also suggested ffmpeg for playback, as it seems a few other softwares are using it. I am guessing this refers particularly to a few licenced codecs, namely I would guess, the proress encoding library and as mentioned the MPEG LA owned stuff. I dont know how other companies are getting around it, but there are a large number of paid applications that utilise ffmpeg and I am guessing without fear of reprisal. It is not so hard to recompile ffmpeg without the risky functionality and there are some hints on doing so, it would take some reading I guess. However, this is a pretty amazingly powerful tool and I would guess a deep investigation into using it (and coding in a way that if it had to be removed fast it would only require users change video codecs or containers) would be a more realistic approach than the indiegogo link above. Maybe the conversation to have with other software makers like arkaos or madmapper, is how they are using ffmeg.

jhoepffner

@mark

Touchdesigner uses a fork from FFmpeg, it works flawlessly, with .avi, .mov, .mp4 and with h264 and hap codecs. They ported last year the app from windows to macOS without problems concerning media player. They just chose not to use proRes and other proprietary codecs. Their performances for reading and recording video and audio are tip-top

I think FFmpeg is the safe way to go.

https://www.derivative.ca/wiki...

Jacques

LPmode

In regards to FFMPEG, I understand the concern, but would it be possible to make it available as a plug-in in a separate download with the appropriate terms and conditions.

I was also looking at the VLC libraries . The player has a bunch features including hardware decoding, transformations, video walls splitting, streaming, NDI.

mark

@fred said:

I dont know how other companies are getting around it, but there are a large number of paid applications that utilise ffmpeg and I am guessing without fear of reprisal.

Fred, have you heard directly from someone at these companies that they have no fear of reprisal? Or is that an assumption on your part?

Do you know someone at one of those companies who would be friendly enough talk to a competitor (i.e., me) about it? If so, PM me the contact.

Well, the only way to find out about this for sure is to consult a lawyer who is well versed in the topic. I have posted on FB seeking some advice on a lawyer, especially targeted at two guys I know who spent years working in Silicon Valley. Of course it's going to cost a fortune to consult with someone like that, but I guess its something I'm going to have to do.

Best Wishes,
Mark

mark

To everyone,

Btw, I'm not trying to be difficult here, just prudent. Here's another detailed thread (a bit old yes, but still relevant) on the topic that gives me quite a bit of pause.

https://news.ycombinator.com/i...

It seems clear that adding ffmpeg is going to require solid legal advice from an expert attorney focused on that field.

Best Wishes,
Mark

mark_m

@citizenjoe said:

So @Mark, I'm curious. Will there ever again be interactivity on Windows with video files the way there is on 32 bit QT video files?
Cheers,
Hugh

I am seeing a lot of blowback in the Adobe After Effects public forums about their abandoning of HAP as a workable codec, and some kind of commitment of the part of Adobe to fix it...
https://adobe-video.uservoice....

Perhaps their fix will be our gain? The direct show version of HAP: is that 32bit too? Will that work with 64bit Isadora?

.mox seems to have been funded and forgotten. Or the indegogo money spent on beer and pretzels.

DusX

@mark_m
I believe all DirectShow playback will be 64bit, so this means Hap Avi will be 64bit.
I just did a show using all Hap Avi content (128gb of content) and the only issue I have with it (other than know limitations like no backwards) was the compression time. It is slow.
It took days (using adobe media encoder). Where I was able to make a Hap MOV (backup plan) batch (using Livids Batch utility 'no longer available'), took just a few hours.