Slashdot Mirror

← Back to Stories (view on slashdot.org)

VLC For Android May Arrive In Early 2011

Posted by timothy on from the but-that's-next-year dept.

dkd903 writes "The development of an Android client for VLC has been going on for months now, but it has been slowed down by the fact that Android's multimedia output libraries are in Java. VLC itself is based on C and so translating them to Java is difficult and takes time. With the newer Android NDK, however, using native codes for Android apps has been becoming easier. So, the VLC developers have developed two basic modules for audio and video output based on the new NDK and most of the VLC libraries have been ported to Android."

58 of 90 comments (clear)

  1. Video on mobile phones by Anonymous Coward · · Score: 1

    This isn't going to use battery at all, especially since VLC's codecs aren't hardware accelerated...

    1. Re:Video on mobile phones by 0123456 · · Score: 3, Insightful

      This isn't going to use battery at all, especially since VLC's codecs aren't hardware accelerated...

      And in Java, which is well-known for its efficient support of complex bit-twiddling algorithms.

    2. Re:Video on mobile phones by morgan_greywolf · · Score: 1

      Android programs aren't Java. Yes, they're written in Java, but the bytecode is targeted for Dalvik, which is not a JVM. Have you seen video on an Android phone? It's very smooth on 4G or WiFi, a little less so on 3G.

      --
      My blog
    3. Re:Video on mobile phones by mooterSkooter · · Score: 1

      I _really_ wish people would use sarcasm more to make their point around here.

    4. Re:Video on mobile phones by gilesjuk · · Score: 1

      Erm, they're written in a Java syntax but there isn't all the standard Java classes available. It's still running in a virtual machine, albeit a register instead of stack based one. It may be more optimal for a mobile device but it's still like writing in VB or some other easy option for coding.

      Still nowhere near as efficient as coding in C++, C or Objective C then compiling to a native executable.

      Coding on Android has none of the advantages of Java (apart from some familiarity of the syntax) and most of the disadvantages too.

    5. Re:Video on mobile phones by TrancePhreak · · Score: 1

      It seems to be better about memory management than ObjC in iOS, which has no garbage collector.

      --

      -]Phreak Out[-
    6. Re:Video on mobile phones by Timmmm · · Score: 1

      Pedant. And the parent didn't even mention virtual machines...

    7. Re:Video on mobile phones by morgan_greywolf · · Score: 2

      Agreed. But there was an implication that one couldn't do VLC on Android because it's Java. It's Java syntax, but the underlying VM isn't Java. That means that the performance problems that plague Java do not plague Dalvik (Android) applications.

      Undoubtedly Android VLC uses these libraries rather than the usual suspects.

      --
      My blog
    8. Re:Video on mobile phones by cynyr · · Score: 1

      JVM != VM. And yes, he/she mentioned java which 99% of the time means a JVM.

      --
      All of the above was encrypted with a Quad ROT-13 method. Unauthorized decryption is in violation of the DMCA.
    9. Re:Video on mobile phones by jo42 · · Score: 1

      You absolutely do NOT want a garbage collector on a mobile device with limited memory and CPU power.

      This is just one of the many things that Apple got 101% right in iOS.

    10. Re:Video on mobile phones by Creepy · · Score: 2

      Interpreted languages are very different now than they were 10-15 years ago. First, most are compiled into bytecode, which is pseudo assembly that can be compiled faster than source code. Second, the interpreter does dynamic recompilation and optimization on the fly, something C and C++ don't do (these code blocks were hand tuned in assembly in the past, but that is rare because the compiler is better than most humans at instruction order because of out of order optimization. While it may not be faster than C/C++, it isn't that bad, especially with systems that make calls to hardware (I get decent OpenGL performance on mine - way better than my old 1.3GHz Pentium on a 1GHz chip, and FAR better memory management). I would hope the optimizations made for Dalvik (the android runtime) also exist in the NDK VM, but I haven't had a chance to play with it yet (going to try to port a C++ library to it, but I have a feeling the OpenGL to OpenGL ES transition will be painful on that one).

    11. Re:Video on mobile phones by Surye · · Score: 1

      http://developer.android.com/sdk/ndk/index.html Not really an issue?

    12. Re:Video on mobile phones by postmortem · · Score: 1

      Why not? It is not mission critical (beside that phone must work all the time) so that it needs real-time behavior. It is their choice to have one app and responsive UI vs. real multi-tasking, as in android, where OS can unload RAM from apps.

    13. Re:Video on mobile phones by Anonymous Coward · · Score: 1

      ObjC comes with garbage collection.

      You just outed yourself as a mac-using hipster.

    14. Re:Video on mobile phones by shutdown+-p+now · · Score: 1

      Objective-C runtime only has GC on the desktop. This thread is about mobile. There's no GC on iOS.

    15. Re:Video on mobile phones by shutdown+-p+now · · Score: 1

      I would hope the optimizations made for Dalvik (the android runtime) also exist in the NDK VM

      There is no "NDK VM" - the "N" there stands for "native", as in native compiled code. There's nothing to optimize there.

    16. Re:Video on mobile phones by Simon+Brooke · · Score: 5, Insightful

      You absolutely do NOT want a garbage collector on a mobile device with limited memory and CPU power.

      This is just one of the many things that Apple got 101% right in iOS.

      My mobile phone has over six thousand times the compute power and over a million times the memory of the first computer I worked on, and that supported 18 concurrent users. More than that, my mobile phone has over five hundred times the compute power and one hundred times the memory of the first dedicated LISP workstation I worked on, and that had a full GUI and generational garbage collection. The idea that modern phones have limited memory or limited CPU power is an idea which only beginners or amateurs could possibly believe.

      Back at the beginning of the automobile age, cars were so primitive that they didn't have automatic oil pumps. If the driver didn't remember to keep pumping oil, the engine would seize. We no longer think that's good engineering. Nowadays, our cars have automatic oil pumps, which use a tiny fraction of the engine's power to prevent it happening. Back at the very beginning of the computer age, software systems were so primitive that they didn't have automatic memory management. If the programmer didn't remember to keep freeing memory, the memory system would silt up and the machine would freeze. Do you really think that's good engineering?

      --
      I'm old enough to remember when discussions on Slashdot were well informed.
    17. Re:Video on mobile phones by TrancePhreak · · Score: 1

      Then we can all hope you do not rely on an iOS device for your life, as restarting it is common practice when an app crashes on load. (This is because several apps leak memory)

      --

      -]Phreak Out[-
  2. Re:What? by Anonymous Coward · · Score: 1

    here you go.

  3. Can't tell from the summary... by Servaas · · Score: 2

    but does this mean VLC for android will have limited codec support for now? Bring it to be honest, Archos has stopped providing some exotic ones, until I grab my wallet, in the new fw update of my 101 and free is better.

  4. A glimmer of hope from OpenSL ES by cognoscentus · · Score: 1

    None of the pre-existing audio APIs for Android have proven very satisfactory so far, at least for anything that requires high performance and/or low latency - see the following links for details: http://createdigitalmusic.com/2010/05/android-2-2-badly-needed-improvements-to-audio-touch-more-whats-missing/ http://code.google.com/p/android/issues/detail?id=3434 However, it looks like OpenSL ES will provide the necessary C APIs VLC needs. Still, I guess any vestigial Java ports might prove useful for other platforms (J2ME maybe). On the other hands, whether Gingerbread will satisfy the requirements of audio creativity app developers is another question. It seems the ES standard might lack the rigor required for properly performant low latency audio apps. Some may doubt the value of such apps, but they are experiencing a huge boom in popularity on the iPad and iPhone. The multitouch surface offers a hugely expressive interface. With a bit more rigor from Google and phone manufacturers, it could seriously open up the market for realtime audio creativity apps on Android.

  5. here's the actual story link by Peganthyrus · · Score: 1

    http://gigaom.com/video/vlc-for-android-coming-soon/

    Not that there's much to it.

    --
    egypt urnash minimal art.
  6. Android does have a C/C++ by EEPROMS · · Score: 1, Insightful

    support so I dont have a clue what the VLC guys are going on about... more info here

    1. Re:Android does have a C/C++ by Anonymous Coward · · Score: 1

      support so I dont have a clue what the VLC guys are going on about... more info here

      That the NDK was not up to scratch until the 2.3 release?

      Like the news story says

      "With the newer Android NDK, however, using native codes for Android apps has been becoming easier."

    2. Re:Android does have a C/C++ by EEPROMS · · Score: 2

      GAH!, never reply to a slashdot article first thing post xmas morning with a hang over. The C/C++ NDK is two years old now, nothing stopping the VLC guys adding to it instead of complaining it doesnt have the lib they need. I think VLC are late to the party anyway, I already use rockplayer to play mkv,mpg video files (thanks to ffmpeg) without any issues.

    3. Re:Android does have a C/C++ by ModernGeek · · Score: 1, Redundant

      "Using native codes"

      Sounds like the author of this article isn't an actual programmer.
      Also, I don't think that porting VLC to android would be the difficult or meaningful part, it's all about the codecs.
      A direct port to Android would mean for a horrible interface, and a rewrite of the interface would just mean creating something new and calling it "VLC".

      --
      Sig: I stole this sig.
    4. Re:Android does have a C/C++ by MacGyver2210 · · Score: 1

      I know it's tempting to only read the headline and shoot some people down, but perhaps you could read the summary too:

      "With the newer Android NDK, however, using native codes for Android apps has been becoming easier. So, the VLC developers have developed two basic modules for audio and video output based on the new NDK and most of the VLC libraries has been ported to Android"

      --
      If the only way you can accept an assertion is by faith, then you are conceding that it can't be taken on its own merits
    5. Re:Android does have a C/C++ by Timmmm · · Score: 1

      Erm, until Android 2.3 the NDK didn't have any method for audio output (other than passing the audio back to java, which is slow and stupid). I'd say that's a pretty big barrier.

      Fortunately they made the NDK much more awesome for 2.3.

    6. Re:Android does have a C/C++ by shutdown+-p+now · · Score: 1

      Being able to run native code is no good if you don't have access to the APIs that you need to get the job done (such as audio).

    7. Re:Android does have a C/C++ by fraktus · · Score: 1

      What about debugging C++ code with the NDK?
      I found that very painful with the previous version of the NDK. I am sure the guys from VLC tried to run their code since a long time but found it not easy. I got some openGL code running with it but when I started to have problems and needed to debug my app it was too painful...

      --
      In cyberspace nobody knows you're a cat!
    8. Re:Android does have a C/C++ by drinkypoo · · Score: 1

      What's Android actually use for audio output, in the kernel? (Or is it userspace?) You could go straight to that with the NDK, though you might have to build some additional libraries.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    9. Re:Android does have a C/C++ by shutdown+-p+now · · Score: 1

      I don't know, but using a non-public (i.e. undocumented) API like that is not a good idea - it can go away, or change in a binary incompatible way, with any OS update, even minor.

    10. Re:Android does have a C/C++ by drinkypoo · · Score: 1

      Sure, there's warnings about that all over the NDK, but for something like vlc it seems like an acceptable risk.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  7. only starting now? by ardiri · · Score: 1

    the NDK has been available for years - what has taken them so long to find this out? create a texture, pass a pointer to it and compile the codec natively. nit more than a one-day job if you know what you are doing. the issue is more about the optimizations of the codecs, not the language barrier.

    1. Re:only starting now? by ardiri · · Score: 1

      yes - the issue with video tools is more the optimization and performance of the codecs, they are typically built for desktop environments and do not compile well for mobile platforms. just search slashdot for my 36 hour porting effort of lemmings to many platforms.. that was a complete game, not a mere codec.. the codec job is much easier. it is very trivial if you know what you are doing. google even made it easier recently:

      http://developer.android.com/sdk/ndk/index.html

      >> Android NDK, Revision 4b (June 2010)
      Adds support for Android 2.2, including a new stable API for accessing the pixel buffers of Bitmap objects from native code.

      how about doing some RTFM and then bitching about how difficult things are.. it is typical people comment before doing any form of research - this stuff is really simple. it didn't even deserve a slashdot mention in the first place.

    2. Re:only starting now? by Beezlebub33 · · Score: 1

      If his first name is Aaron, then yes, he probably could. BTW, it if is you, thanks for all the help on the Palm OS developer forums!

      --
      The more people I meet, the better I like my dog.
  8. Re:Windows 7 Desktop Sharing? by arielCo · · Score: 2, Informative

    Umm...
    VNC = Virtual Network Computing
    VLC = VLC media player (former VideoLAN Client)

    --
    This post contains no rudeness or derision of any kind. All arguments are friendly. Terms and exclusions may apply.
  9. Mhmm by Anonymous Coward · · Score: 1

    They're using Java for the frontend and some of the backend, with C++ for the codecs, obviously.

    1. Re:Mhmm by leenks · · Score: 1

      No, they aren't using Java. This is a bad article.

  10. Re:codec support by SuricouRaven · · Score: 3, Insightful

    VLC gets it's codec support from a selection of libraries, primarily libavcodec. There isn't much it won't play. I've thrown everything from old realmedia to quicktime to mpeg to x264 in mkv container with vorbis audio at VLC, and it's all worked.

  11. Do want by kikito · · Score: 1

    Really, do want.

    1. Re:Do want by Lunix+Nutcase · · Score: 1

      Why? VLC has to be one of the worst libavcodec-based media players in existence.

    2. Re:Do want by koro666 · · Score: 1

      What other libavcodec-based player would you suggest then?

    3. Re:Do want by drinkypoo · · Score: 1

      Citation needed. I keep trying other things and I keep coming back to vlc.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    4. Re:Do want by kikito · · Score: 1

      I don't care how "good" a "libavcodec-based" player is if it doesn't play everything out-of-the box.

      VLC has played everything I had, out of the box, in all the systems I've tested (Linux, Windows and Mac for now).

      I want that on my Android.

    5. Re:Do want by kikito · · Score: 1

      Sounds like the 4096 CPUs guy:

      http://xkcd.com/619/

  12. I must be from the future... by thenickdude · · Score: 1

    ... because I have been streaming video from VLC on my Android phone for months. Using VLC Stream & Convert.

  13. One more for the N900 and Maemo. by sethstorm · · Score: 1

    Not only does it have VLC, it also has mplayer and friends. That, and you can get USB out of it too.

    Local video, networked video, and no VM in between you and your media.

    --
    Twitter supports and protects racists - by smearing their critics with the "Hate Speech" label.
    1. Re:One more for the N900 and Maemo. by Microlith · · Score: 1

      Yes, it actually does.

    2. Re:One more for the N900 and Maemo. by bcmm · · Score: 2

      Instead of making us all look like Apple-style "ha, we can do $APP" fanboys, you should explain why. Deranged partition scheme aside, Maemo is pretty much a typical GNU/Linux distro, complete with glibc and xorg. It also comes with modified versions of GTK+ and Qt, to make interfaces work nicely on a touchscreen. Any Linux application can be ported trivially unless it doesn't compile on ARM for some reason, and will work fine unless it is extremely CPU-intensive or works badly on a small screen.

      --
      # cat /dev/mem | strings | grep -i llama
      Damn, my RAM is full of llamas.
  14. Codes? by amicusNYCL · · Score: 2

    With the newer Android NDK, however, using native codes for Android apps has been becoming easier.

    Codes, plural? What exactly is "one code"?

    --
    "Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
  15. patience please by swell · · Score: 1

    I love the idea of VLC. I can't imagine the blood, sweat and tears that went into this labor of love. It does a few things that QuickTime can't.

    But the fact is that after so many years it is still buggy on my Macs (can't even start, stop or scroll thru a video reliably) and I have never been able to export even a simple video to another format (could be my ignorance). QuickTime on Mac is relatively solid, exports flawlessly, and offers some commonsense play options that VLC lacks.

    Are we expecting a miracle in VLC for Android? Instant success? I recommend a great deal of patience.

    --
    ...omphaloskepsis often...
  16. Use of native multimedia decoders in Android by henrikba · · Score: 1

    Does anyone know if they are able to access and use the native multimedia decoders in Android directly? http://stackoverflow.com/questions/3912563

  17. Based on Qt? by dwater · · Score: 1

    VLC is oft quoted as being based on Qt, and I notice that Qt is being ported to Android (and iOS). I wonder if these facts are related.

    --
    Max.
  18. Re:Windows 7 Desktop Sharing? by Beezlebub33 · · Score: 2

    You are seriously off topic here. (But to answer your question, google for Remote Desktop to view remotely, use Camtasia to do recording)

    --
    The more people I meet, the better I like my dog.
  19. Re:codec support by Jah-Wren+Ryel · · Score: 1

    VLC gets it's codec support from a selection of libraries, primarily libavcodec. There isn't much it won't play. I've thrown everything from old realmedia to quicktime to mpeg to x264 in mkv container with vorbis audio at VLC, and it's all worked.

    Try interlaced vc1. It's remarkably common on blurays because - for some damn reason - the bluray spec does not include 25fps progressive video - so all of those euro programs that are native 25fps have to be encoded as 50fps interlaced. Sometimes you get vc1 and sometimes you get h264 (which has MBAFF for interlaced-but-really-progressive which works great as a workaround for bluray). Lots of BBC content like Doctor Who, Torchwood and Being Human are in 1080i50 vc1.

    --
    When information is power, privacy is freedom.
  20. If you mean "Does it have Android?", yes. by sethstorm · · Score: 1

    Not for the faint of heart, but there's Android (Nitdroid) for the N900:
    Link

    --
    Twitter supports and protects racists - by smearing their critics with the "Hate Speech" label.
  21. Standard codecs don't need the acceleration by LostMyBeaver · · Score: 1

    Ok, VLC is a pretty pluggable architecture... well even if it is a nightmare to code in. It's still a fair bit more manageable than coding for either GStreamer or ffmpeg.

    You can easily change out or extend nearly every component of a CODEC on VLC. So, here's how it'll work :

    1) Someone will port the code to run on Android
    2) Someone will say "wow it works, but H.264 is so slow it makes my eyes want to bleed"
    3) Someone will make it faster by optimizing for ARM.
    4) Someone will add hardware decoding for a specific ARM chip from a specific vendor.
    5) Someone will initiate a project to standardize the hardware acceleration decoding architecture on Android
    6) Google summer of code will sponser a project to finish it.
    7) The coder involved will start school again
    8) The project will be forgotten
    9) The forums will be filled with "Is there anyone working on this anymore" questions followed by guys who don't know how to code but seem to think they are "experts" providing useless responses including "it wouldn't be that hard to pick up the project an finish it".
    10) Someone will eventually get sick of waiting and 2 years later release something useful.