Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

VLC For Android May Arrive In Early 2011

timothy posted more than 3 years ago | from the but-that's-next-year dept.

Google 90

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

cancel ×

90 comments

Sorry! There are no comments related to the filter you selected.

Video on mobile phones (1)

Anonymous Coward | more than 3 years ago | (#34666678)

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

Re:Video on mobile phones (3, Insightful)

0123456 (636235) | more than 3 years ago | (#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.

Re:Video on mobile phones (1)

morgan_greywolf (835522) | more than 3 years ago | (#34666844)

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.

Re:Video on mobile phones (0)

Anonymous Coward | more than 3 years ago | (#34666958)

... the bytecode is targeted for Dalvik ... Have you seen video on an Android phone? It's very smooth on 4G or WiFi, a little less so on 3G.

That's because of the following native libraries, and not anything specific to do with Java/Dalvik.

(list varies according to firmware/device/CPU)

libstagefright.so
libstagefright_amrnb_common.so
libstagefright_avc_common.so
libstagefright_color_conversion.so
libstagefright_omx.so
libstagefrighthw.so

libopencore_arcaudiolocal.so
libopencore_arcaudiolocalreg.so
libopencore_author.so
libopencore_common.so
libopencore_download.so
libui.so
libopencore_downloadreg.so
libopencore_motlocal.so
libopencore_motlocalreg.so
libopencore_motojanusreg.so
libopencore_motoma1.so
libopencore_mp4local.so
libopencore_mp4localreg.so
libopencore_net_support.so
libopencore_player.so
libopencore_rtsp.so
libopencore_rtspreg.so
libopencorehw.so

libomx_aacdec_sharedlibrary.so
libomx_amrdec_sharedlibrary.so
libomx_amrenc_sharedlibrary.so
libomx_arcomxcore_sharedlibrary.so
libomx_avcdec_sharedlibrary.so
libomx_evrcdec_sharedlibrary.so
libomx_m4vdec_sharedlibrary.so
libomx_mp3dec_sharedlibrary.so
libomx_qcelpdec_sharedlibrary.so
libomx_qcelpenc_sharedlibrary.so
libomx_sharedlibrary.so
libomx_wmadec_sharedlibrary.so
libOMX.TI.720P.Decoder.so
libOMX.TI.720P.Encoder.so
libOMX.TI.AAC.decode.so
libOMX.TI.AAC.encode.so
libOMX.TI.AMR.decode.so
libOMX.TI.AMR.encode.so
libOMX.TI.JPEG.Encoder.so
libOMX.TI.MP3.decode.so
libOMX.TI.Video.Decoder.so
libOMX.TI.Video.encoder.so
libOMX.TI.WBAMR.decode.so
libOMX.TI.WBAMR.encode.so
libOMX.TI.WMA.decode.so
libOMX.TI.mp4.splt.Encoder.so
libOMX_Core.so

libVendor_ti_omx.so
libVendor_ti_omx_config_parser.so

Re:Video on mobile phones (2)

morgan_greywolf (835522) | more than 3 years ago | (#34668380)

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.

Re:Video on mobile phones (1)

gilesjuk (604902) | more than 3 years ago | (#34667674)

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.

Re:Video on mobile phones (1)

TrancePhreak (576593) | more than 3 years ago | (#34667748)

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

Re:Video on mobile phones (1)

jo42 (227475) | more than 3 years ago | (#34668520)

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.

Re:Video on mobile phones (1)

postmortem (906676) | more than 3 years ago | (#34668744)

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:Video on mobile phones (1)

Anonymous Coward | more than 3 years ago | (#34668834)

ObjC comes with garbage collection.

You just outed yourself as a mac-using hipster.

Re:Video on mobile phones (1)

shutdown -p now (807394) | more than 3 years ago | (#34669264)

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

Re:Video on mobile phones (5, Insightful)

Simon Brooke (45012) | more than 3 years ago | (#34669328)

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:Video on mobile phones (0)

Anonymous Coward | more than 3 years ago | (#34670708)

When I can't sit around and wait for the garbage collector to hurry and give up the CPU already because I have a hard real-time deadline my code has to meet (and if it doesn't people get hurt or die), then yes, I do think it is good engineering. Some people have to work in systems like that. Garbage collection systems may work for you, but they aren't appropriate for every situation.

Re:Video on mobile phones (1)

TrancePhreak (576593) | more than 3 years ago | (#34680034)

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)

Re:Video on mobile phones (2)

Creepy (93888) | more than 3 years ago | (#34668566)

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

Re:Video on mobile phones (1)

shutdown -p now (807394) | more than 3 years ago | (#34669266)

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:Video on mobile phones (1)

Timmmm (636430) | more than 3 years ago | (#34667928)

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

Re:Video on mobile phones (1)

cynyr (703126) | more than 3 years ago | (#34668460)

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

Re:Video on mobile phones (1)

mooterSkooter (1132489) | more than 3 years ago | (#34666946)

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

Re:Video on mobile phones (0)

Anonymous Coward | more than 3 years ago | (#34666838)

If VLC won't use h/w acceleration on Android (for decoding... incl. post-transcoding playback) then it won't be able to play most videos. Battery life would be a minor concern.

I do have a question though. Is this going to be based on Gingerbread (and OpenSL)?

Re:Video on mobile phones (0)

Anonymous Coward | more than 3 years ago | (#34666900)

so what? it is not a jesusphone, you can actually swap the battery on android devices.

Standard codecs don't need the acceleration (1)

LostMyBeaver (1226054) | more than 3 years ago | (#34674664)

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.

What? (0)

Anonymous Coward | more than 3 years ago | (#34666690)

No link?

Re:What? (1)

Anonymous Coward | more than 3 years ago | (#34666718)

here you go [slashdot.org] .

Re:What? (1)

monkyyy (1901940) | more than 3 years ago | (#34666884)

+1 excellent troll

Vegan Chili Bird (-1)

Anonymous Coward | more than 3 years ago | (#34666738)

I'm a vegan, but I ***HATE*** Tofurkey with a passion. In fact I hate tofu. Period. So... For Christmas dinner tonight, I've constructed a molded Vegan Chili Loaf in the shape of a turkey. It's made of vegan chili cooked with a bit of a corn starch slurry and then molded into a bird shaped object.

Any thoughts?

Re:Vegan Chili Bird (0, Offtopic)

Shikaku (1129753) | more than 3 years ago | (#34666760)

Any thoughts?

What the fuck?

Re:Vegan Chili Bird (-1, Offtopic)

Anonymous Coward | more than 3 years ago | (#34666926)

Look, Vegan Chili Loaf may not be *YOUR* cup-o-tea, but dude, if you have nothing of value to add, why waste everyone's time?

Re:Vegan Chili Bird (-1)

Anonymous Coward | more than 3 years ago | (#34667170)

Are you dense?

Re:Vegan Chili Bird (-1)

Anonymous Coward | more than 3 years ago | (#34667532)

The OP must believe that the V in VLC means "Vegan" and the C in VLC means chilli. That is, OP is a retard.

Re:Vegan Chili Bird (-1, Offtopic)

Frosty Piss (770223) | more than 3 years ago | (#34666782)

Any thoughts?

Brown miso gravy.

Re:Vegan Chili Bird (-1)

Anonymous Coward | more than 3 years ago | (#34666920)

I have a thought. Take a big fat shit. Then stick it in the freezer and freeze it overnight. Tomorrow, you can use it as a dildo to fuck your self in the ass! Remember to lube it up a bit first, that will help with the temperature differential. If you're worried about the shit on your hands, wear some dish gloves (they'll also help with the cold).

Re:Vegan Chili Bird (-1)

Anonymous Coward | more than 3 years ago | (#34666928)

call it a Vegan Loaf de Chili and it'll almost be on topic

Can't tell from the summary... (2)

Servaas (1050156) | more than 3 years ago | (#34666752)

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.

Windows 7 Desktop Sharing? (0, Offtopic)

Doc Ruby (173196) | more than 3 years ago | (#34666772)

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?

Re:Windows 7 Desktop Sharing? (-1)

Anonymous Coward | more than 3 years ago | (#34666800)

Remote Desktop. Won't do everything you want though, sorry.

Re:Windows 7 Desktop Sharing? (-1)

Anonymous Coward | more than 3 years ago | (#34668000)

This method doesn't work?

http://forum.videolan.org/viewtopic.php?f=2&t=37055 [videolan.org]

Re:Windows 7 Desktop Sharing? (2)

Beezlebub33 (1220368) | more than 3 years ago | (#34669744)

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

Re:Windows 7 Desktop Sharing? (0)

Anonymous Coward | more than 3 years ago | (#34673390)

Off-topic, much? Fucktard.

codec support (0)

Anonymous Coward | more than 3 years ago | (#34666790)

This is good news, as I love VLC player. However, and correct me if I'm wrong, but the platform only supports select codecs so essentially it will be just like any other media player in terms of supported media?

Re:codec support (3, Insightful)

SuricouRaven (1897204) | more than 3 years ago | (#34667374)

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.

Re:codec support (1)

Jah-Wren Ryel (80510) | more than 3 years ago | (#34669952)

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.

A glimmer of hope from OpenSL ES (1)

cognoscentus (1628459) | more than 3 years ago | (#34666814)

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

Android does have a C/C++ (1, Insightful)

EEPROMS (889169) | more than 3 years ago | (#34667022)

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

Re:Android does have a C/C++ (1)

Anonymous Coward | more than 3 years ago | (#34667058)

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:Android does have a C/C++ (1, Redundant)

ModernGeek (601932) | more than 3 years ago | (#34667286)

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

Re:Android does have a C/C++ (0)

Anonymous Coward | more than 3 years ago | (#34667116)

I see you read the summary...

Re:Android does have a C/C++ (2)

EEPROMS (889169) | more than 3 years ago | (#34667280)

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.

Re:Android does have a C/C++ (1)

Timmmm (636430) | more than 3 years ago | (#34667930)

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.

Re:Android does have a C/C++ (1)

fraktus (632342) | more than 3 years ago | (#34669434)

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

Re:Android does have a C/C++ (0)

Anonymous Coward | more than 3 years ago | (#34667958)

Yes, Rockplayer on Android plays all the video formats I've thrown at it quite smoothly on my older phone.

Both VLC and WinAmp seem to be late arriving on Android...

Re:Android does have a C/C++ (1)

MacGyver2210 (1053110) | more than 3 years ago | (#34667870)

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"

Re:Android does have a C/C++ (1)

shutdown -p now (807394) | more than 3 years ago | (#34669302)

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

Re:Android does have a C/C++ (1)

drinkypoo (153816) | more than 3 years ago | (#34669566)

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.

Re:Android does have a C/C++ (1)

shutdown -p now (807394) | more than 3 years ago | (#34669580)

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.

Re:Android does have a C/C++ (1)

drinkypoo (153816) | more than 3 years ago | (#34669874)

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

only starting now? (1)

ardiri (245358) | more than 3 years ago | (#34667062)

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.

Re:only starting now? (0)

Anonymous Coward | more than 3 years ago | (#34667362)

Can you do it in a day, then, since you're so good? Because it's not that trivial for mere mortals.

Re:only starting now? (1)

ardiri (245358) | more than 3 years ago | (#34669330)

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.

Re:only starting now? (0)

Anonymous Coward | more than 3 years ago | (#34673826)

Then do it, it'll take a day, and it'll be done, oh grand master.

Re:only starting now? (1)

Beezlebub33 (1220368) | more than 3 years ago | (#34669758)

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!

Mhmm (1)

Anonymous Coward | more than 3 years ago | (#34667100)

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

Re:Mhmm (1)

leenks (906881) | more than 3 years ago | (#34667448)

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

Do want (1)

kikito (971480) | more than 3 years ago | (#34667528)

Really, do want.

Re:Do want (1)

Lunix Nutcase (1092239) | more than 3 years ago | (#34667768)

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

Re:Do want (0)

Anonymous Coward | more than 3 years ago | (#34668026)

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

Streaming.

Most people will agree that VLC is only mediocre as a basic media player. Although their massive out-of-box codec support is known far and wide.

The reason VLC is so useful and popular is because of the "LAN" part.

If you don't use that part at all then you probably should be using a different player.

Complaining about it makes you look like a nutcase. :)
"My GPS receiver is such a horrible watch!"

Re:Do want (1)

kikito (971480) | more than 3 years ago | (#34671948)

Sounds like the 4096 CPUs guy:

http://xkcd.com/619/ [xkcd.com]

Re:Do want (1)

koro666 (947362) | more than 3 years ago | (#34668604)

What other libavcodec-based player would you suggest then?

Re:Do want (1)

drinkypoo (153816) | more than 3 years ago | (#34669588)

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

Re:Do want (0)

Anonymous Coward | more than 3 years ago | (#34672584)

I won't suggest giving up VLC, but adding MPC is a good idea. It's lighter and faster and some of the UI features work smoother (like seeking).
http://sourceforge.net/projects/guliverkli2/files/Media%20Player%20Classic/

Now, MPC does not include much codec support, but don't fret! ffdshow tryouts is a multi-codec (not a pack) designed specifically for MPC. VLC does support slightly more Real and Quicktime files than this does, so if you need those you should also get real alternative and/or quicktime alternative and/or the official programs.
http://ffdshow-tryout.sourceforge.net/

There is another branch of MPC called MPC-HC. It has some added features including built-in codec support and it's a good program, but the new features kill some of the stability and snappiness that makes MPC really shine. Not bad to have, but I recomend MPC+ffdshow tryouts.

Re:Do want (1)

kikito (971480) | more than 3 years ago | (#34671934)

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.

Wow lack of supporting information (0)

Anonymous Coward | more than 3 years ago | (#34667620)

This entire post/threads seems to be lacking some important information:
1) The Android SDK is a subset of java commands + android specific ones that are then compiled into DEX bytecode by the SDK to run on the Dalvik VM (which is MUCH MUCH more efficient than JVM, is *nix thread safe, *nix process separate, etc... a lot of nice things... )
2) The Android NDK is for development of native (ARM assembly) code to be used by java objects for specific tasks
2.1) This allows a portion of an API/object to be processed with assembly/open GL/etc
2.2) This portion of the API/object will be called by an Android DEX bytecode app (an "App" as we mostly know it)
3) So VLC has used the NDK to translate their C code into ARM assembly/other stuff? and probably made a single class/object that "does" the audio/video portions of the VLC application, and that will be created/used by the GUI class/object

Hope this helps clarify things for those who didn't know

I must be from the future... (1)

thenickdude (1481249) | more than 3 years ago | (#34667752)

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

One more for the N900 and Maemo. (1)

sethstorm (512897) | more than 3 years ago | (#34668348)

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:One more for the N900 and Maemo. (0)

Anonymous Coward | more than 3 years ago | (#34668422)

Does it have Angry Birds?

Re:One more for the N900 and Maemo. (0)

Anonymous Coward | more than 3 years ago | (#34668492)

and farmville App edition?

Re:One more for the N900 and Maemo. (1)

Microlith (54737) | more than 3 years ago | (#34668530)

Yes, it actually does.

If you mean "Does it have Android?", yes. (1)

sethstorm (512897) | more than 3 years ago | (#34673506)

Not for the faint of heart, but there's Android (Nitdroid) for the N900:
Link [engadget.com]

Re:One more for the N900 and Maemo. (2)

bcmm (768152) | more than 3 years ago | (#34669174)

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? (2)

amicusNYCL (1538833) | more than 3 years ago | (#34668572)

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

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

patience please (1)

swell (195815) | more than 3 years ago | (#34668986)

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.

Re:patience please (0)

Anonymous Coward | more than 3 years ago | (#34669180)

I have run VLC on an Intel Macbook Pro running 10.6. It is as stable as VLC on windows so I have no idea why your having problems.

Use of native multimedia decoders in Android (1)

henrikba (516486) | more than 3 years ago | (#34669260)

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]

Based on Qt? (1)

dwater (72834) | more than 3 years ago | (#34669738)

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.

Vplayer? (0)

Anonymous Coward | more than 3 years ago | (#34670458)

Cool, but vplayer already plays just about everything on android. What will vlc add?

Try using VPlayer Beta in meantime (0)

Anonymous Coward | more than 3 years ago | (#34670526)

I've found it very hard to find a player on Android that can handle pretty much any video format. But recently a new player has appeared that's superb: VPLAYER BETA. Seriously, give it a go. It might be beta, but it's working better than RockPlayer does, which was my previous favourite.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>