Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Google Java Media Technology

VLC For Android May Arrive In Early 2011 90

Posted by timothy 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."
This discussion has been archived. No new comments can be posted.

VLC For Android May Arrive In Early 2011 More

VLC For Android May Arrive In Early 2011

Comments Filter:

  • Video on mobile phones (Score:1)

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

    • Re:Video on mobile phones (Score:4, Insightful)

      by 0123456 ( 636235 ) on Saturday December 25, 2010 @03:32PM (#34666770)

      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.

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

        • 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 th

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

            • Re: (Score:2)

              by jo42 ( 227475 )

              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.

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

              • Re: (Score:1)

                by Anonymous Coward

                ObjC comes with garbage collection.

                You just outed yourself as a mac-using hipster.

              • Re:Video on mobile phones (Score:5, Insightful)

                by Simon Brooke ( 45012 ) <stillyet@googlemail.com> on Sunday December 26, 2010 @05:45AM (#34669328) Homepage Journal

                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 [htc.com] has over six thousand times the compute power and over a million times the memory of the first computer I worked on [wikipedia.org], 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 [wikipedia.org] 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?

          • Re: (Score:3)

            by Creepy ( 93888 )

            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

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

        • Re: (Score:2)

          by Timmmm ( 636430 )

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

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

      • Re: (Score:2)

        by Surye ( 580125 )
        http://developer.android.com/sdk/ndk/index.html [android.com] Not really an issue?
    • 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 specif
  • 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.

  • I know it's not VNC (or is it?) or Android, but I'm looking for a way to share my local Windows 7 desktop across the LAN to another Windows 7 user who watches as I do something onscreen. And a recorder to play it back. If the recorder can take a microphone narration, that's perfect.

    Is something like that built into Windows 7? Or is there a free app that can do it?

  • 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/ [createdigitalmusic.com] http://code.google.com/p/android/issues/detail?id=3434 [google.com] 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 oth
  • support so I dont have a clue what the VLC guys are going on about... more info here [android.com]

    • Re: (Score:1)

      by Anonymous Coward

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

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

      • Re: (Score:2, Redundant)

        by ModernGeek ( 601932 )
        "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".

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

    • 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).

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

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

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

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

  • Mhmm (Score:1)

    by Anonymous Coward

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

  • Really, do want.

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

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

    • Re: (Score:3)

      by bcmm ( 768152 )
      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.

  • Codes? (Score:3)

    by amicusNYCL ( 1538833 ) on Saturday December 25, 2010 @11:32PM (#34668572)

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

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

  • 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

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

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

Slashdot Top Deals

The truth of a proposition has nothing to do with its credibility. And vice versa.

Close