Goodbye, QuickTime 7 and JPEG 2000
As part of the upcoming transition to 64-bit technology in macOS, you may see an alert in iMovie about media files that won’t be compatible with future versions of macOS, released after macOS Mojave.
These incompatible media files were typically created using formats or codecs that rely on QuickTime 7—an older version of QuickTime that is included in macOS Mojave for compatibility purposes. However, because versions of macOS after macOS Mojave will no longer include the QuickTime 7 framework, you’ll first need to detect and convert incompatible media files to continue to use those files in iMovie.
It’s a pity that Apple never brought the new QuickTime Player app up to the level of QuickTime 7.
Among those which won’t be supported under macOS 10.15 are several Avid formats, Cinepak, DivX, Flash Video, FlashPix, GlueTools codecs, JPEG 2000, Motion JPEG A and B, Perian codecs (MPEG-4, DivX, and more), RealVideo, several Sorensons, and Windows Media Video (WMV) 7, 8, 9. It’s possible that some vendors may port codecs or other tools to 10.15 to support some of them in the future, although this looks unlikely at present.
Unfortunately, there’s no system-level means of checking which video, audio and still image formats remain reliant on 32-bit components such as codecs. They aren’t included in Mojave’s System Information under its Legacy Software section, which only seems to cover apps and similar bundles. Most, perhaps all, of those listed in the Components section are provided in 32-bit form and will be unavailable in macOS 10.15, but there doesn’t appear to be any listing of formats which are supported in QuickTime X.
Most of the codecs which are becoming unsupported are those for video, but Apple’s list includes one still image format which could affect you, JPEG 2000. Although never popular, at some time in the past you may have saved photos or other images in this format, which is quite different from plain old JPEG (which won’t be affected by the loss of these codecs).
I wonder what this means for Apple Icon Image files, which can contain embedded JPEG 2000 images. Not to mention PDF files and NSBitmapImageFileTypeJPEG2000.
Previously:
- Removed in macOS 10.14 Mojave
- macOS 10.13.4 to Warn About 32-bit Apps Starting April 12
- Apple Stops Patching QuickTime for Windows Despite 2 Active Vulnerabilities
- qtmodernizer
- Hardware Audio Encoding, AVMovie Brings Back QuickTime Features
- AVFoundation in Yosemite
- QuickTime Banned From Mac App Store
- AV Foundation and the Void
- Transitioning QTKit Code to AV Foundation
- Perian to Cease Development
- What Is Apple Doing With QuickTime?
- The Curious Case of QuickTime X
- JPEG 2000
Update (2019-03-26): Simone Manganelli:
It’s weird... why wouldn’t Apple just update their JPEG 2000 codec to 64-bit?
I understand why the multitudes of video codecs would probably not be worth converting (and many of them used third-party plugins), but one measly image format natively supported in QT?
Because it isn’t Apple’s to update. And it is also already 64-bit. Apple is using Kakadu for JPEG2000. Kakadu is known for being expensive. Apparently Apple doesn't want to pay for it anymore. I guess Apple also doesn’t want to bother integrating with OpenJPEG either.
I have school projects in Sorenson, and Motion JPEG A, among other things. I understand dropping support in the system, but I think Apple aught to offer an automated route to detect and create compatible versions of those media files.
Update (2019-03-29): Howard Oakley:
If you’ve only got a handful of movies which need conversion to cope with the forthcoming loss of QuickTime 7 codecs in macOS 10.15, you’re probably happy using QuickTime Player to handle that. But if you want control over the codecs and settings to be used, or have a large batch to transcode, then you’re much better off using a dedicated app like Apple’s Compressor.
Update (2019-05-14): Josh Centers:
Those are just a few of the things I appreciate about IINA.
In any case, I recommend keeping both VLC and IINA on your Mac for when you encounter videos in obscure formats, especially now that Apple will be dropping support for many of them.
Previously: IINA 1.0.
17 Comments RSS · Twitter
It is especially sad that while Apple does have a plugin system for making their own “pro video formats” available to AVFoundation based apps (https://support.apple.com/kb/DL1947?locale=en_US), to the best of my knowledge this specification, unlike QuickTime, is not published for 3rd party developers to take advantage of?
Now that QuickTime is officially going away, with no real replacement for this functionality, do we need to start making a big stink about this before 10.15 shows up?
It makes a big deal in two cases...
1. Making encoding apps for other formats other than officially sanctioned AVFoundation codecs.
2. Yes my company literally makes a high end video playback and compositing application, this is crucial functionality for pro video software.
@Glaurung Potentially if you have old media files that are part of a project (iMovie or otherwise). Also, I’m not positive that VLC supports all the old QuickTime formats.
I’m an electronic musician and our community has been going through the 64-bit transition for a few years now. Most modern DAWs are either 32-bit or 64-bit only which is a big deal for using VST, AU, and AAX plug-ins. While there are some third party 32-bit wrappers like 32 Lives, I bought VMWare Fusion to run a macOS X 10.4 for some old projects. It works for supporting legacy projects, even if it’s inelegant.
Forget about legacy codecs, there are modern codecs that are in use by video professionals that will now require using custom tools to convert to and from AVFoundation formats, and this limits innovation in 3rd party codecs because you can't rely on batch exporter apps like Compressor working with your format.
My company has our own pro video codec that is now supported by most of our competitors, in over 30 products – and when Apple dropped this functionality we had to make our own batch exporting tool because AVFoundation doesn't have an official plugin format... in the world of concert and event production, as big as the Super Bowl and Olympics, pro video people have to use our weird open source batch exporter instead of a pro tool like Compressor in order to create movie files that are optimized for playback for the most popular media server systems. In the past you could just use any software that supported QuickTime for export.
Considering how much faster computers are now, why can’t the old QuickTime live on something like a self contained emulator, like Classic was in OS X… (disregarding possible license restrictions for the moment).
That being said, I will have no fast and easy tool to check several technical elements, add/remove tracks, try out if looped movies are working correctly etc once QT7 is gone. Not to mention having a player where the bloody interface elements aren’t on top of the media I’m watching and the corners are rounded (which sucks a lot if you create content for large LED elements that have low resolutions like 48x288px etc.)
I’ve not seen mention of future support for the PICT file format. Rendering QuickDraw pictures on OS X requires QuickDraw which is 32 bit only. PICT files aren’t simply bitmaps; they can also contain vector art and text. Prior to 10.15, PICT files could in principle be rendered to bits at a specific resolution and saved in a future supported format. Or they could be converted into PDF files, although that conversion is not perfect for every PICT file.
The QuickTime Component I rely on the most is an exporter that uses x264 instead of Apple’s slow/poor-quality h264 encoder. Because it was a QuickTime Component, it worked with Compressor.
Slowly but surely, one by one, Apple keep removing the little things that have traditionally kept me on the platform.
If OS or first party apps support a format once it should be supported from that point on.
That is why adding new formats must be a conservative decision,
especially if that is a general file format, and not from one particular app that is gone a while ago.
This lack of support is part of the pattern of neglect along with abandoned product lines, missing updates, lingering bugs.
[…] and QuickTime Player 7 and let the dead versions hang around for years until eventually sunsetting them, without ever reimplementing what was […]
It's happening! My company’s app uses QTMovieModernizer and our latest MAS submission using Xcode 10.2 was not accepted:
> Deprecated API Usage - Apple will stop accepting submissions of apps that use QuickTime or QTKit APIs starting from $rejectInkFrameworkFrom .
(lol Ink)
Jpeg 2000 part 1's seem to still work on OSX 10.15, so I am not sure how or when it will not be supported.
>It is especially sad that while Apple does have a plugin system for making their own “pro video formats” available to AVFoundation based apps (https://support.apple.com/kb/DL1947?locale=en_US), to the best of my knowledge this specification, unlike QuickTime, is not published for 3rd party developers to take advantage of?
So first, I believe that's correct and probably won't change.
I was curious and found that those formats install into /Library/Video/Plug-Ins.
That surprised me, because my original understanding was that AVFoundation didn't support plug-ins _at all_; that all supported codecs (really originally basically just H.264) were hardcoded. Either that was never actually true, or it has changed at some point (just on macOS? or perhaps also on iOS?). While H.264 still seems to built straight into AVFoundation itself (a strange design decision, given that was always very clear that there was, at some point, going to be a newer codec), H.265 and others appear to be implemented as plug-ins.
So from that path, I would surmise that there is an (undocumented) plug-in architecture, and that the available codecs aren't just hardcoded. I.e., someone _could_ (nudge nudge) try to spelunk into Apple's existing plug-ins and get a project like Perian going again.
I had thought that was flat-out _impossible_ in the AVFoundation world, but it now appears it is merely an awful lot of work (with questionable gain).
