I will be really sad to see it go. Perian is one of the first five things I download when I'm on a clean install of OS X. Support has sadly been lagging when it comes to MKV, and for that I still keep VideoLan around; but otherwise I love having full system-wide QuickTime support for all common video formats (AVI).
This is a shame. I absolutely love Perian and it has made it much easier to just play content without having to download VLC as well, and it just worked.
One thing I have noticed is that support for MKV/VP8/WebM has always been pretty bad. It uses a LOT of CPU time and in general was really slow. When YouTube put me in the HTML 5 beta it was unbeknownst to me sending me WebM content because I had Perian installed and it was causing HUGE spikes in CPU usage and overall lag because it was trying to decode and render WebM, whereas h264 requires almost no CPU power on my older MBP.
I hope that the community as a whole picks up the project and helps it succeed, it would be fantastic to still have it around.
Under the heading "Frequently Asked Questions" on the linked page, it says:
Why does it take so long for MKV to load?
QuickTime expects to know the location of every single frame in a movie in order to play it. This is easy with its native format, MOV/MP4, but more difficult for several others, including MKV. Perian has to read in the entire file in order for seeking and playback to work.
That's probably (part of) the reason MKV and WebM are slow for you (since WebM uses the MKV container format).
I did a little bit [just a little] research on this, and I believe the main reason those things are slow is because Apple refuses to provide an API to allow 3rd parties to use the GPU for decoding video. Apple itself provides a codec for h264 that uses your graphics card, so that one performs well.
Best of luck to the whole team there. It's such a great tool, and seamlessly pulled off. I'll be sad to see it go, and I'll be crossing my fingers in the hopes that it will work with future OS releases for a while.
>I'll be sad to see it go, and I'll be crossing my fingers in the hopes that it will work with future OS releases for a while.
Given that Apple has seemed to feel, for the last few OS releases, that it's acceptable for "deprecate" and "break" to happen in the same step, I wouldn't get my hopes up.
It's a shame, but I hope some other devs consider picking up development where the Perian guys left off. Perian is one of my favorite Mac utilities because I love using QuickTime for everything when possible.
To the team, thanks for all your years of hard work and best of luck on future projects.
It's not so much an issue of picking up Perian in that the new Quicktime 10 API doesn't work anything like the old Quicktime API.
Perian just made open source codecs work with Quicktime's API. Quicktime X however demands much more that makes it impossible to do without rewriting all the codecs. Those same codecs are directly embedded in other players (like VLC) so it's not a big issue. Quicktime X is pushing towards hardware acceleration, better battery life (with a few tricks), and multicore processing that the old model just doesn't work with.
Right now when you run older codecs, Quicktime X actually runs a little host process in 32bit that actually does the decoding using a fork of the old Quicktime 7 code. Native codecs run in 64bit using multiple cores and hardware acceleration.
I used this at one point, but long ago switched to MPlayerOSX, finding it a much more straightforward interface for playing random format movies than QT, with noticeably better performance. VLC is also... an option.
MPlayer lacks a playlist though, which is annoying.
VLC's recent UI changes have been a step backward (specifically making it impossible to see the playlist and the video at the same time), but at least you can queue things up to play.
Perian used to be me first download on every Mac, but 10.7 does not let me hide the file preview (top right) in column view anymore. If I scroll through a list of video files and hit something complicated (like MKV) the Finder just hangs. Has this bothered anyone else? Or is detail view more common in the wild?
I love the VLC redesign though, and it arrived just in time, so I'm happy.
It's really sad. I installed it because Quicktime and iPhoto can't play any video taken from my Canon digital camera. Perian provided system-wide Quicktime support for many video format and this is what VLC or MPlayer cannot compare.....
Interesting thread. I too am truly sad to see this go, while everyone is suggesting stand alone players, I personally loved that Perian actually extended the native tools to support all these other formats.
[+] [-] SeoxyS|14 years ago|reply
[+] [-] peter_l_downs|14 years ago|reply
[+] [-] X-Istence|14 years ago|reply
One thing I have noticed is that support for MKV/VP8/WebM has always been pretty bad. It uses a LOT of CPU time and in general was really slow. When YouTube put me in the HTML 5 beta it was unbeknownst to me sending me WebM content because I had Perian installed and it was causing HUGE spikes in CPU usage and overall lag because it was trying to decode and render WebM, whereas h264 requires almost no CPU power on my older MBP.
I hope that the community as a whole picks up the project and helps it succeed, it would be fantastic to still have it around.
[+] [-] thristian|14 years ago|reply
Why does it take so long for MKV to load?
QuickTime expects to know the location of every single frame in a movie in order to play it. This is easy with its native format, MOV/MP4, but more difficult for several others, including MKV. Perian has to read in the entire file in order for seeking and playback to work.
That's probably (part of) the reason MKV and WebM are slow for you (since WebM uses the MKV container format).
[+] [-] Schlaefer|14 years ago|reply
Are there any alternatives?
[+] [-] notJim|14 years ago|reply
[+] [-] kschults|14 years ago|reply
[+] [-] mistercow|14 years ago|reply
Given that Apple has seemed to feel, for the last few OS releases, that it's acceptable for "deprecate" and "break" to happen in the same step, I wouldn't get my hopes up.
[+] [-] atlbeer|14 years ago|reply
Thank you for appropriately assigning the root cause. I would have never linked the two.
[+] [-] filmgirlcw|14 years ago|reply
To the team, thanks for all your years of hard work and best of luck on future projects.
[+] [-] zbowling|14 years ago|reply
Perian just made open source codecs work with Quicktime's API. Quicktime X however demands much more that makes it impossible to do without rewriting all the codecs. Those same codecs are directly embedded in other players (like VLC) so it's not a big issue. Quicktime X is pushing towards hardware acceleration, better battery life (with a few tricks), and multicore processing that the old model just doesn't work with.
Right now when you run older codecs, Quicktime X actually runs a little host process in 32bit that actually does the decoding using a fork of the old Quicktime 7 code. Native codecs run in 64bit using multiple cores and hardware acceleration.
[+] [-] ye-olde-taper|14 years ago|reply
[+] [-] WiseWeasel|14 years ago|reply
[+] [-] xymostech|14 years ago|reply
[+] [-] Stokestack|14 years ago|reply
VLC's recent UI changes have been a step backward (specifically making it impossible to see the playlist and the video at the same time), but at least you can queue things up to play.
[+] [-] gurkendoktor|14 years ago|reply
I love the VLC redesign though, and it arrived just in time, so I'm happy.
[+] [-] victorlamhk|14 years ago|reply
[+] [-] Feoh|14 years ago|reply
[+] [-] kylebrown|14 years ago|reply
[+] [-] breidh|14 years ago|reply
http://www.mplayerhq.hu/design7/news.html
[+] [-] tyler_ball|14 years ago|reply
[+] [-] ye-olde-taper|14 years ago|reply
But as others have pointed out, there is indeed another major open source media player.
At what point did VLC start using the ffmpeg libraries?
If I'm not mistaken mplayer has used them since its inception.
[+] [-] amanuel|14 years ago|reply
A sad day.
Perian team, great job guys and thanks for the many years of awesomeness.