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."

8 of 398 comments (clear)

  1. This would be a great loss by Anonymous Coward · · Score: 5, Informative

    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.

  2. Mplayer OSX Extended by The+J+Kid · · Score: 5, Informative

    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.
    1. Re:Mplayer OSX Extended by Hatta · · Score: 5, Interesting

      That's a good option for playing videos. But what makes VLC VLC, and not just VC, is the LAN support. VLC can pretty easily be set up as a video server as well as a player. You can't do this with Mplayer.

      --
      Give me Classic Slashdot or give me death!
  3. Really? by Wesley+Felter · · Score: 5, Informative

    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.

  4. I'll help! by MrCrassic · · Score: 5, Informative

    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.

  5. A different view from a developer by rbrito · · Score: 5, Interesting

    (This message may be seen as inflammatory, but I assure you that it is just my opinion and not particularly anybody else---I don't speak for the projects on which I participate).

    Hi.

    I am not a developer of VLC, but I am part of the LAME team (that MP3 encoder that a good amount of people use). I see similar problems regarding LAME as those described by the VLC team: lack of continuous power and resources.

    Some users just magically think that "oh, this program won't exist anymore, so let's use this other one". The sad thing here is that they are shortsighted in the fact that they, by doing nothing (just receiving the programs), are not giving the incentive for the projects.

    What about if the proposed alternative dies a few days from now? The amount of alternatives is finite.

    Not only that, but the major players out there all share the same codebase: there are "incestuous" (in a good sene of the word) relations with VLC, xine, and mplayer: the all use, to some extent or another (well, in some cases, to the full extent) some common libraries: ffmpeg, libmp3lame, theora, vorbis, dirac, x264 and so on.

    Usually, also, the players also send some feedback to the people writing the libraries and, without them, the libraries would not be as good as they are. And the feedback that developers provide is, not infrequently, in form of patches, or constructive suggestions. Some users, like the one above, just cares less and, honestly, where would you just "grab the extra codec" if they all, come, essentially, from the first place?

    If you didn't know, perhaps it is a good reminder to put here that people from the VLC project developed the nice libdvdcss library, which benefited xine and mplayer, while people in the other projects have directly or indirectly benefited the others.

    I would not like to have the "Linux desktop" mainstream with a "community" with a person that doesn't want a community. For people that are more altruistic (and that show it, instead of just playing in slashdot all day), I am open to a more open talk.

    [Gee, from what I wrote the above, it seems like if I only saw Linux---I actually value the other Unix-like operating systems as much].

    I guess that what I meant to say here is: "Talk is cheap. Show me the code. Don't wish the death of what you may proudly use and not even know".

    Regards, Rogério Brito.

  6. Re:user-friendly? by Anonymous Coward · · Score: 5, Informative

    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".

  7. AbiWord faces the same issue by msevior · · Score: 5, Interesting

    There are very few Open Source developers for OSX. Unfortunately we, AbiWord, have exactly the same issue. We *almost* had version 2.8 ready for OSX but we lost our lead OSX developer and there is no one to replace him. Rather than delay 2.8, we simply went ahead with 2.8 for Linux and Windows.