VLC on Android

[riahc3]

Hello

I imagine this has been beated to death but since I dont see any updates, I first off wanted to thank the devs for making VLC and for "starting" a port for Android.

How is it going? Is there a "at your own risk" version out?

Thanks once again

[Arite]

ivoire made a post about the development status here:
http://ivoire.dinauz.org/blog/index.php ... on-Android

I haven't tried compiling it myself, however there is a HOWTO file in the Android branch of VLC here:
http://git.videolan.org/?p=vlc/vlc-andr ... roid/HOWTO

AFAIK there are no nightly builds of it etc.

Arite.

[theseeker]

Would it be possible for someone that has build VLC for Android already to post a .apk file somewhere? I tired to build it for myself, but I'm stuck at this error:

Code: Select all

make[1]: Entering directory `/local/mnt/workspace/umuff/vlc/vlc-android/extras/package/android/vlc-android' SharedLibrary : libvlcjni.so /usr2/umuff/workspace/umuff/vlc/vlc-android/builddir//modules/misc/dummy/.libs/libdummy_plugin.a(libdummy_plugin_la-decoder.o): In function `CloseDecoder': /usr2/umuff/workspace/umuff/vlc/vlc-android/builddir/modules/misc/dummy/../../../../modules/misc/dummy/decoder.c:159: multiple definition of `CloseDecoder' /usr2/umuff/workspace/umuff/vlc/vlc-android/builddir//modules/misc/stats/.libs/libstats_plugin.a(libstats_plugin_la-decoder.o):/usr2/umuff/workspace/umuff/vlc/vlc-android/builddir/modules/misc/stats/../../../../modules/misc/stats/decoder.c:106: first defined here /usr2/umuff/workspace/umuff/vlc/vlc-android/builddir//modules/misc/dummy/.libs/libdummy_plugin.a(libdummy_plugin_la-decoder.o): In function `OpenDecoder': /usr2/umuff/workspace/umuff/vlc/vlc-android/builddir/modules/misc/dummy/../../../../modules/misc/dummy/decoder.c:120: multiple definition of `OpenDecoder' /usr2/umuff/workspace/umuff/vlc/vlc-android/builddir//modules/misc/stats/.libs/libstats_plugin.a(libstats_plugin_la-decoder.o):/usr2/umuff/workspace/umuff/vlc/vlc-android/builddir/modules/misc/stats/../../../../modules/misc/stats/decoder.c:45: first defined here collect2: ld returned 1 exit status make[1]: *** [/local/mnt/workspace/umuff/vlc/vlc-android/extras/package/android/vlc-android/obj/local/armeabi/libvlcjni.so] Error 1 make[1]: Leaving directory `/local/mnt/workspace/umuff/vlc/vlc-android/extras/package/android/vlc-android' make: *** [vlc-android/libs/armeabi/libvlcjni.so] Error 2

[playing]

you should modifing the libvlcjni.h

marked the vlc_declare_plugin(stats) and vlc_plugin(stats)

[tachiorz]

I found interesting file extras/package/android/vlc-android/jni/egl-android-info.txt and have few questions. Will --vout egl_android be faster? Because now vlc is slow as hell. I managed to build egl_android support, but looks like i need appropriate changes on java side and libvlcjni, where i can see example?
or just screw that...

[Gearu]

I hope that when a pre release version is created, they only distribute it to truly trusted people, this is the most anticipated program for android and there are plenty who would leak it, here's hoping each one given out has a unique hidden tag code in it to identify any leakers.

Good work by the way.

[Rémi Denis-Courmont]

That's why it is not being distributed at all. Really motivated people can always compile it themselves.

[grondinm]

i know that vlc on android is still deep in devellopment but i would love to see it run on my phone. I have followed to wiki to the letter(many times) everytime i get the same result. I get all the way to Build the JNI interface for libvlc but this is what i get:

Code: Select all

~/BUILDS/vlc-android/extras/package/android$ VLC_BUILD_DIR=../../../build VLC_CONTRIB=../../contrib make === Creating Android.mk === === Building libvlcjni === make[1]: Entering directory `/home/marc/BUILDS/vlc-android/extras/package/android/vlc-android' Compile thumb : vlcjni <= libvlcjni.c Compile thumb : vlcjni <= vout.c Compile thumb : vlcjni <= aout.c Compile thumb : vlcjni <= thumbnailer.c SharedLibrary : libvlcjni.so ../../../../build/modules/misc/dummy/.libs/libdummy_plugin.a(libdummy_plugin_la-decoder.o): In function `CloseDecoder': /home/marc/BUILDS/vlc-android/build/modules/misc/dummy/../../../../modules/misc/dummy/decoder.c:159: multiple definition of `CloseDecoder' ../../../../build/modules/misc/stats/.libs/libstats_plugin.a(libstats_plugin_la-decoder.o):/home/marc/BUILDS/vlc-android/build/modules/misc/stats/../../../../modules/misc/stats/decoder.c:106: first defined here ../../../../build/modules/misc/dummy/.libs/libdummy_plugin.a(libdummy_plugin_la-decoder.o): In function `OpenDecoder': /home/marc/BUILDS/vlc-android/build/modules/misc/dummy/../../../../modules/misc/dummy/decoder.c:120: multiple definition of `OpenDecoder' ../../../../build/modules/misc/stats/.libs/libstats_plugin.a(libstats_plugin_la-decoder.o):/home/marc/BUILDS/vlc-android/build/modules/misc/stats/../../../../modules/misc/stats/decoder.c:45: first defined here /home/marc/android-ndk-r5b/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/../lib/gcc/arm-linux-androideabi/4.4.3/../../../../arm-linux-androideabi/bin/ld: cannot find -logg collect2: ld returned 1 exit status make[1]: *** [/home/marc/BUILDS/vlc-android/extras/package/android/vlc-android/obj/local/armeabi/libvlcjni.so] Error 1 make[1]: Leaving directory `/home/marc/BUILDS/vlc-android/extras/package/android/vlc-android' make: *** [vlc-android/libs/armeabi/libvlcjni.so] Error 2

i tried to delete my everything and start over but i got the same results. i am able to build the regular vlc with no issues i am unsure what i am doing wrong. I am using Ubuntu 10.04.

[Fraser67]

I have exactly the same problem, with libvlcjni.so. I have looked for the stats line to comment out and it is not present in the file. Using Xubuntu 11.04, if that makes any difference.

[Fraser67]

A little more digging and the Makefile is looking for LIBVLCJNI=vlc-android/libs/armeabi/libvlcjni.so in the path below vlc-android/extras/package/android. However the libs directory and subsequent directories and files does not exist.

Does this mean there was an error when building the contribs?

[Boomedan]

Any chance someone can post an APK for this? Android SDK refuses to cooperate with me.

By the way, does anyone have any information about when this will be officially released? I'm dying from the lack of a media player for my phone that plays MKV files properly.

[k9wkj]

been banging my head on the desk over building this for 3 weeks
how can one edit libvlcjni.h when it doesnt exist till after you need it?
i have yet to find it until after i try to build the jni interface with VLC_BUILD_DIR=../../../build VLC_CONTRIB=../../contrib make
then it is to late to keep it from bombing

that being said my understanding of programming flies as well as a mud coated brick

seems today some of the repos that make is trying to pull from are down uggg

[XilasZ]

There won't be any apk around until it's ready.

About libvlcjni.h, it's generated by the makefile if it doesn't exist.

[marquicus]

Maybe this post can help you, it worked for me

https://forum.videolan.org/viewtopic.ph ... 51#p300851

[mgtsai]

While building extras/contrib, I met a problem during compiling liveMedia, with the following log:

rm -rf live || true
gunzip -c live555-latest.tar.gz | tar xf - --exclude='[*?:<>\|]'
mv live555-latest live || true
mv: cannot stat `live555-latest': No such file or directory
touch live
patch -p0 < Patches/live-uselocale.patch
patching file live/liveMedia/include/Locale.hh
patching file live/liveMedia/Locale.cpp
patching file live/liveMedia/RTSPClient.cpp
Hunk #1 succeeded at 469 (offset -550 lines).
Hunk #2 succeeded at 483 (offset -550 lines).
patching file live/liveMedia/RTSPClient.cpp
Hunk #1 succeeded at 919 (offset -16 lines).
patching file live/liveMedia/RTSPCommon.cpp
patch -p0 < Patches/live-inet_ntop.patch
patching file live/groupsock/Groupsock.cpp
patching file live/groupsock/include/GroupsockHelper.hh
patching file live/groupsock/inet.c
patching file live/liveMedia/DarwinInjector.cpp
patching file live/liveMedia/OnDemandServerMediaSubsession.cpp
Hunk #1 succeeded at 294 (offset -71 lines).
Hunk #2 succeeded at 328 (offset -71 lines).
patching file live/liveMedia/PassiveServerMediaSubsession.cpp
patching file live/liveMedia/RTSPClient.cpp
Hunk #1 succeeded at 394 (offset -17 lines).
patching file live/liveMedia/RTSPServer.cpp
Hunk #1 succeeded at 123 (offset 12 lines).
Hunk #2 FAILED at 265.
Hunk #3 succeeded at 882 (offset 21 lines).
Hunk #4 succeeded at 960 (offset 21 lines).
Hunk #5 succeeded at 1525 (offset 76 lines).

With investigating build-src/Makefile, I found that the version of sources downloaded from live555.com is "latest", which means it varies from time to time. Thus the newly downloaded source (version 2011.6.16) mismatches from patch files build-src/Patches/live-*.patch (for version 2011.03.??), which cause compilation failure.

Can anyone provide the actual liveMedia source version which can pass the compilation?

[Sébastien Escudier]

the contrib patch has been update a few days ago... do you have the latest vlc-android sources ?

[mgtsai]

the contrib patch has been update a few days ago... do you have the latest vlc-android sources ?

Thanks for your noticing. I've updated new contrib patches, and the building process passed without any failure.

BTW, although VLC for Android is still in the development stage, I suggest that maybe the snapshot of live555-latest.tar.gz (about 440 KB) can be embedded as part of source distribution, since live555.com does not host their code with definite versions. Syncing contrib patches with sources of liveMedia may cause some disturbance for development or evaluation.

Other contrib packages need not be snapshot because they have definite version numbers.

[Lx_121]

Ok, so 2 quick questions, not meant to be unfriendly, but definitely meant to be blunt:

1. Why the hell is this taking so long!?

2. Re: a couple of comments earlier in this thread: vlc is open source, so who the hell cares if a development build gets "leaked"? & why would anyone care?!

o__0

It's fer chrissakes OPEN SOURCE; if it gets "leaked", it gets FIXED faster...

[Rémi Denis-Courmont]

1. Because this is pretty much an all volunteer effort, just like the rest of VLC.

2. Yeah it's open-source. You can get the code on http://git.videolan.org/ so I don't understand what you mean by getting leaked. If you're unable to compile it yourself, you're probably unable to help fixing it, so I don't see how that would help speed up development.

I do however see how that could gather negative feedback because the stuff is very much unfinished.

[Jean-Baptiste Kempf]

Exactly. If you don't know how to compile it yourself, you are unlikely to be able to help development.

You are therefore an end-user and will likely complain about it not working perfectly...

Still, if you have a weird phone and Android version, I can give you a build to test weird configurations.

[pointtofuture]

Can I help me! i am running on emulator android 2.2 .After i get vlc android on git and I build successful . But I run on emulator is error :
07-01 15:46:13.273: INFO/UsageStats(58): Unexpected resume of com.android.launcher while already resumed in org.videolan.vlc.android

- I hope everyone help me! thanks!

[Lx_121]

in reply to Rémi:

you make it available clearly marked as "use at you own risk: development/unstable/whatever"

that way at least you have SOMETHING for your "early-adopters" & it satisfies some of the demand that is out there, rather than losing vlc-"customers" to other apps/services. android is still going to be a "new" experience for the majority of people using it, so either you get them hooked on vlc as "their" player-of-choice, or you risk losing them permanently to other options.

& giving people NO option for using vlc ("until it's ready") is a good way to lose them permanently (especially when the development is taking SO LONG).

unless the code really IS crap, an option to "test" the current dev version shouldn't cause "negatives"; the people who choose to use it would clearly understand that it's a "rough draft"

& SOME of the people using it might be inspired to contribute back to the project in one way or another.

(for the record, i don't even HAVE a cellphone; can't stand them, for a number of reasons. but i was trying to help a friend figure out how to watch an .nsv stream on their android phone & was, to put it bluntly, GOBSMACKED that there isn't an android version of vlc out yet)

& the part about "leaked (etc.)" was in response to the comment:

"Re: VLC on Android
by Gearu » Sun May 22, 2011 10:03 am

I hope that when a pre release version is created, they only distribute it to truly trusted people, this is the most anticipated program for android and there are plenty who would leak it, here's hoping each one given out has a unique hidden tag code in it to identify any leakers.

Good work by the way.
Gearu
New Cone"


i.e.: why on earth would anyone bother with such a "security" effort on an open-source project?

[Jean-Baptiste Kempf]

Gearu is not part of the dev team... We don't care about his opinion.

"use at you own risk: development/unstable/whatever" don't get understood by people, especially since stupid people at Google and Mozilla decided to destroy the concept of alpha and beta software...

[Rémi Denis-Courmont]

you make it available clearly marked as "use at you own risk: development/unstable/whatever"

As JB implied, practically all software is already marked with "use at your own risk". Yet users do expect reasonable stability, and rightfully so.

I don't see the point in distributing software we know is so unstable and/or so slow that any user is bound to be disappointed.

Unstable and development releases work as an alternative for official releases. This is how we do VLC nightly releases; and it helps the community test bug fixes, new features and track regressions. That is a different situation.

that way at least you have SOMETHING for your "early-adopters"

The current VLC Android is only useful to developers because it does not work well enough for much practical use. Early adopters come into play only when the software reaches feature completion and "beta" quality.

it satisfies some of the demand that is out there

Non-functional software does not satisfy any demand.

rather than losing vlc-"customers" to other apps/services.

Either way, prospective users can and will be lost. The only way to reduce this is to get to beta quality sooner. At this point, more skilled developers, not more users/testers are needed.

(...)

unless the code really IS crap, an option to "test" the current dev version shouldn't cause "negatives"; the people who choose to use it would clearly understand that it's a "rough draft"

Crap code and incomplete code are different things. Please don't equate them.

& SOME of the people using it might be inspired to contribute back to the project in one way or another.

As said multiple times, the people that would be needed at this point have to be able to compile the software by themselves.

[Jean-Baptiste Kempf]

Anyway, until we have a YUV->RGB routine in NEON, there is no reason to release it.