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.
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).
Let's remember that Handbrake uses VLC for video decoding. No more VLC = no more handbrake.
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
But these wiseguys don't realise that I'd much rather deal with files that I can recognise by their filename, copy and move them with the well known 'cp' and 'mv' commands rather than having their craptastic software try to manage it all.
The feature you speak of can be turned off. Your music can be in one place or as many places as you like (even on removable storage). Most people, however, like the convenience of having all their music in one place which is managed automatically. "Most people" makes for a reasonable default. I also find it odd you categorize apple's naming scheme as "cryptic" given the scheme is artist/album/track, the filenames of which are not renamed as you claim. While my files are in different folders now, all of them retain the same filenames. Also, iTunes store's music no longer has DRM.
Yeah. Dang Apple for preventing GrandCentral use anywhere else. Imagine how cool it would be if another OS were to pick up the technology and Implement it.
Blast Apple and all their closed source stuff.
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.
I couldn't get OS X to use VLC by default. Selecting "open with" VLC ALWAYS only works for that single file, not the file type, despite it saying so.
To set a default application for a file type in OS X, you do the following:-
Right click on any MKV file and choose 'Get Info'
In the 'Open With' section, choose VLC
Click the 'Change All...' button underneath.
All MKV files will now open by default in VLC
Perian+Quicktime is awful for Matroska. Really, I wouldn't bother. See the first FAQ under http://perian.org/#support
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.
I know it doesn't do hardware acceleration (not supported at all in OS X yet) but I used to shoot and edit 1080i material (circa 2007/8) in XDCAM HD and it works just fine, and that's the XDCAM HD raw, AIC, H.264 and HDV formats.
The mpeg2 codec for quicktime costs extra from Apple (license issue, even though the DVD player app that ships with OS X plays mpeg2 already, crazy) - Windows does not come with native mpeg2 playback either for the same license reason.
Hardware accelerated video is a relatively new phenomenon outside of niche applications (like the old school Media 100 system I used to work on - 300Mhz of mayhem with hardware acceleration), and if it's not addressed soon I'm sure there will be problems, but right now it's not the be all and end all unless you're trying to make a media box with a beefy card and weak CPU - I expect the issue will be sorted when the Apple TV finally gets updated.
I have the same problem with the LiVES project. Over 3 years ago, I managed to compile the sourcecode for OSX/Darwin, it took a lot of fiddling around, but it worked. I excitedly posted the news on the website and mailing lists, but no OSX users seemed interested. Since then, the code has changed a lot, fixes were made for it to compile on IRIX and Solaris.
Recently somebody posted a forum message noting how easy it now is to compile under OSX. I again posted this news, and asked if somebody could kindly compile it and send me a link to the resulting binary. Since then...nothing. Hence I have come to a conclusion about OSX users...well, I will let you guess what it is.
Does that mean you've captured the video, and are now trying to edit the file in iMovie?
If so, you should be able to use an app called MPEG Streamclip to do the conversion.
You may have to purchase Apple's MPEG2 component for Quicktime, however.