Slashdot Mirror
Lack of Manpower May Kill VLC For Mac
plasmacutter writes "The Video Lan dev team has recently come forward with a notice that the number of active developers for the project's MacOS X releases has dropped to zero, prompting a halt in the release schedule. There is now a disturbing possibility that support for Mac will be dropped as of 1.1.0. As the most versatile and user-friendly solution for bridging the video compatibility gap between OS X and windows, this will be a terrible loss for the Mac community. There is still hope, however, if the right volunteers come forward."
The DVD player that comes with Apple's computers is rather intolerant of scratches, etc., and will report "Skipping damaged area..." then skip ahead a ridiculous amount. VLC will play fine right through the supposedly damaged segment. Losing VLC for the Mac would be terrible. If I knew anything about programming, I'd think about joining this project.
Sad to see VLC struggling, but there's always Mplayer OSX Extended for the mac. Get the extra codec pack and it can play anything!
Moderation: +4. Modded 70% Funny and 30% Overrated. 100% Saturated.
Not exactly... Apple has been slowly squeezing the Carbon (std. C++ lib set) into non-existence, which means you get to do it in Cocoa (that is, Obj-C). IIRC, there's no 64-bit Carbon love in SL, though the 32-bit Carbon libs should still be happily intact.
There's also (IIRC) Grand Central to contend with when you're dinking around with video, and I doubt that you could find an easy parallel for that when porting in from *nix.
Been way the hell too long (something like 4 years) since I've had to do any serious OSX stuff though, so take all of this with a block of salt.
Quo usque tandem abutere, Nimbus, patientia nostra?
I thought Handbrake uses FFMPEG. Anyway, if Handbrake uses some VLC code then the Handbrake developers will probably continue to maintain that code without necessarily having to maintain VLC as a whole.
Mac has Perian which is FOSS, so while it would be a shame to lose VLC on OS X it won't be the end of support for codecs Apple doesn't support.
Caveat Utilitor
I wanted to respond directly to the person who put this post up, but I don't want to register for yet another forum.
I'll gladly help develop for the project. My knowledge in video and audio processing is very weak (I took a class on it, but I didn't really put too much work into it), but my skills in C and C++ are pretty good (but not expert). I'm also pretty well-versed in Java, though it's been a while since I needed to whip it out. Finally, I'm slowly, but surely, learning Objective-C.
Please e-mail me at the address listed here. I don't want to see this die! I just migrated over to OS X and find this app extremely helpful, especially from my use of it in Windows.
Whoever takes the job, please remove the stupid "anything I want to play gets added to a stupid playlist" thing. When I open a video with QuickTime, it plays that video. If I open another video at the same time, it opens up another QuickTime window.
VLC is more like QuickTime (video player) but it currently acts more like iTunes (media library player).
Have you even bothered to open the preferences? It right there in the Interface pane (simple settings view):
Allow only one instance [x]
Enqueue files when in one instance mode[x]
Just uncheck "Allow only one instance".
FYI:
Quicktime is more than a player. It is a massive video library (with a larger code base than windows 95) used to power video editing etc. Its OLD and used to be the basis of nearly all video editing software. It has gotten stale and others have replaced it but it was the foundation for digital video for many years and its still around being used for this.
The quicktime file format is the basis of the mp4 file format as well.
It is a solid library with a lot of extendability for its size, age, and complexity - its in C and I've coded for it a little bit... like 10 years ago.
What I see now is alternatives usually built around a single format library with an import/export system added on. This makes those easier to implement while quicktime has been open ended and not tied to any 1 format (other than its own container format) the timecode in quicktime is confusing because its not a video time code but an abstraction.
Basically apple dropped the ball when they didn't open source the library years ago (and they did ask for public input for a short period without much attention given to it) now we have MKV containers and the zombee avi containers and many specialized libraries.
Not much out there as far as I've seen that competes with the power of quicktime. It could have been the framework but it looks like mkv will be the open container and somebody will tie together enough libraries and codecs into a generalized framework--- or we'll just have to jam it all together ourselves. (which may not be any more difficult than trying to understand the old quicktime C API...)
Democracy Now! - uncensored, anti-establishment news
Depends on what he means by "owns", and ignoring the hyperbole (the "serious work" part is especially egregious, just like when "business" or gamers make the same claim in reverse), he's got a point. The programming one is a bit confusing, but the others are pretty accurate.
No, they aren't. High-performance computing most certainly isn't a strong area for Apple, with Linux being probably the most used platform and other Unix systems and Windows coming somewhere behind. While Macs are certainly used for some scientific modeling and visualisation tasks, I'm not aware of a particularly market share, definitely not to the point of "owning" the market.
In the end, the only item on his list that stands is "design", with a lot of programmers also using Macs nowadays but I wouldn't say they dominate at that either.
Not exactly... Apple has been slowly squeezing the Carbon (std. C++ lib set) into non-existence, which means you get to do it in Cocoa (that is, Obj-C).
Objective C / C++ is only required for doing the UI. 99% of your project can remain in C or C++ with only a very thin shim in Obj-C for the UI layer. There is no requirement to move your code base to except for the Mac-specific UI layer.
IIRC, there's no 64-bit Carbon love in SL, though the 32-bit Carbon libs should still be happily intact.
There is no 64 bit Carbon, because it's a relic. Cocoa easily mixes with C code (Obj-C is just C with extra stuff). Unless you're Adobe and you have a huge amount of UI code in Carbon, there is no reason to keep hanging on to it.
There's also (IIRC) Grand Central to contend with when you're dinking around with video, and I doubt that you could find an easy parallel for that when porting in from *nix.
Grand Central Dispatch is not required for video at all. Mac OS X supports the standard POSIX pthreads interface for threading.