2012-10-16, 15:16
OpenMAX IL components might be 'easy' but their usage is heavily tuned to specific vendors, there are lots and lots of quirks that you have to handle to be 'universal'.
2012-10-16, 17:05
(2012-10-16, 15:16)davilla Wrote: OpenMAX IL components might be 'easy' but their usage is heavily tuned to specific vendors, there are lots and lots of quirks that you have to handle to be 'universal'.
True. The implementations will probably not be 100% compliant, and some quirks might exist.. But I wonder if it really is so for a single component... I suppose that we would not need to tunnel multiple components to achieve what we want.. It is enough to only use a single instance of the decoder and feed it with buffers. Not much tweaking that the vendors could have done to the codes itself... Most differences exist in the extradata/synchronization/component tunneling realm... Simple decoding is usually just without weirdness...
//OwL
2012-10-16, 18:41
I got curious about how vlc solved the "experimental " hw decoding... They seem to use the stagefright omx components... That is also an idea, and those should be compliant with stagefright.. So any vendor supporting the stagefright omx layer should behave in a stagefright-compliant way... Could be one track to investigate..
2012-10-17, 17:11
Haven´t tested any inoffical apk yet. Can someone confirm that it will support HDMI out for movie playback ?
2012-10-17, 17:14
(2012-10-17, 17:11)tequila Wrote: Haven´t tested any inoffical apk yet. Can someone confirm that it will support HDMI out for movie playback ?
There are reports that is is working on some devices I believe. You can also search the XDA thread for HDMI and see what others have said about it previously. A lot of information has accumulated over there.
2012-10-17, 17:15
Since most HDMI implementations for android just clone the UI, so it works most of the time.... I can not guarantee anything.. It works on my devices (msm8960).. 
Beware that HW decoding is not working yet.
Beware that HW decoding is not working yet.
2012-10-17, 18:09
Has anyone tested the diceplayer modified ffmpeg version?
http://diceplayer.inisoft.co.kr/technical-note
diceplayer seems to work hwaccelerated very well.....
http://diceplayer.inisoft.co.kr/technical-note
diceplayer seems to work hwaccelerated very well.....
2012-10-17, 18:30
Compared the ffmpeg 10.2 original source with the diceplayer one.. and the changes where minor.... they are using libstagefright out of the box it seems! ... so... a glance at their included config.log might provide hints of what they do differently compared to the missing symbols builds we have?... maybe missing rpath-link to the stagefright libs?
The config line from diceplayer ffmpeg:
# ./configure --target-os=linux --prefix=./android/armv7-a --enable-cross-compile --extra-libs=-lgcc --arch=arm --cc=/home/inisoft/android-ndk/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-gcc --cross-prefix=/home/inisoft/android-ndk/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi- --nm=/home/inisoft/android-ndk/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-nm --sysroot=/home/inisoft/android-ndk/platforms/android-8/arch-arm/ --extra-cflags=' -O3 -fpic -DANDROID -DHAVE_SYS_UIO_H=1 -Dipv6mr_interface=ipv6mr_ifindex -fasm -Wno-psabi -fno-short-enums -fno-strict-aliasing -finline-limit=300 -mfloat-abi=softfp -mfpu=neon -marm -march=armv7-a -mtune=cortex-a8 ' --disable-shared --enable-static --extra-ldflags='-Wl,-rpath-link=/home/inisoft/android-ndk/platforms/android-8/arch-arm//usr/lib -L/home/inisoft/android-ndk/platforms/android-8/arch-arm//usr/lib -nostdlib -lc -lm -ldl -llog' --enable-parsers --disable-encoders --enable-decoders --disable-muxers --enable-demuxers --enable-swscale --disable-ffplay --disable-ffprobe --disable-ffserver --disable-ffmpeg --enable-network --enable-indevs --disable-bsfs --disable-filters --enable-protocols --enable-asm --disable-avdevice --disable-avfilter --enable-neon
The config line from diceplayer ffmpeg:
# ./configure --target-os=linux --prefix=./android/armv7-a --enable-cross-compile --extra-libs=-lgcc --arch=arm --cc=/home/inisoft/android-ndk/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-gcc --cross-prefix=/home/inisoft/android-ndk/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi- --nm=/home/inisoft/android-ndk/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-nm --sysroot=/home/inisoft/android-ndk/platforms/android-8/arch-arm/ --extra-cflags=' -O3 -fpic -DANDROID -DHAVE_SYS_UIO_H=1 -Dipv6mr_interface=ipv6mr_ifindex -fasm -Wno-psabi -fno-short-enums -fno-strict-aliasing -finline-limit=300 -mfloat-abi=softfp -mfpu=neon -marm -march=armv7-a -mtune=cortex-a8 ' --disable-shared --enable-static --extra-ldflags='-Wl,-rpath-link=/home/inisoft/android-ndk/platforms/android-8/arch-arm//usr/lib -L/home/inisoft/android-ndk/platforms/android-8/arch-arm//usr/lib -nostdlib -lc -lm -ldl -llog' --enable-parsers --disable-encoders --enable-decoders --disable-muxers --enable-demuxers --enable-swscale --disable-ffplay --disable-ffprobe --disable-ffserver --disable-ffmpeg --enable-network --enable-indevs --disable-bsfs --disable-filters --enable-protocols --enable-asm --disable-avdevice --disable-avfilter --enable-neon
2012-10-17, 18:45
Yeah hardware decode is some sort of must I guess ;-) Otherwise HD won´t work on most tablets. However shouldn´t it be possible by using an external player?
My cheap tablet GPU=Mali-400 MP says it plays 2160p (never tested though).
My cheap tablet GPU=Mali-400 MP says it plays 2160p (never tested though).
2012-10-17, 21:32
Yes, you can use an external player to get hw acceleration.. But then you won't get the nice ui from xbmc in the player...
2012-10-17, 22:56
Sorry if this has been asked before (I did search but didn't find anything).
But is the plan to have Android device able to source over wifi? I ask cause in my family we each have a tablet, and I assume my daughter etc would love to watch her movies/tv shows etc on her tablet in bed etc while we are using the two main tv's (running Xbmc via my HTPC). But we have way too many movies etc to fit on the actual tablets, so sourcing through to the HTPC would be ideal?
Cheers
But is the plan to have Android device able to source over wifi? I ask cause in my family we each have a tablet, and I assume my daughter etc would love to watch her movies/tv shows etc on her tablet in bed etc while we are using the two main tv's (running Xbmc via my HTPC). But we have way too many movies etc to fit on the actual tablets, so sourcing through to the HTPC would be ideal?
Cheers
2012-10-17, 23:24
XBMC works over a network, the content doesn't need to be local. Now, streaming of WiFi has issues of its own unrelated to XBMC. With some of the alpha apks floating around, I'm able to stream SD content (mostly DVD isos) just fine over WiFi to my Samsung Galaxy Tab 2. HD content suffers more than not due to lack of hardware accelerated video decoding, but I could also see WiFi throughput being a bottleneck in the future.
2012-10-17, 23:59
(2012-10-17, 18:30)OwLOwL Wrote: Compared the ffmpeg 10.2 original source with the diceplayer one.. and the changes where minor.... they are using libstagefright out of the box it seems! ... so... a glance at their included config.log might provide hints of what they do differently compared to the missing symbols builds we have?... maybe missing rpath-link to the stagefright libs?
The config line from diceplayer ffmpeg:
# ./configure --target-os=linux --prefix=./android/armv7-a --enable-cross-compile --extra-libs=-lgcc --arch=arm --cc=/home/inisoft/android-ndk/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-gcc --cross-prefix=/home/inisoft/android-ndk/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi- --nm=/home/inisoft/android-ndk/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-nm --sysroot=/home/inisoft/android-ndk/platforms/android-8/arch-arm/ --extra-cflags=' -O3 -fpic -DANDROID -DHAVE_SYS_UIO_H=1 -Dipv6mr_interface=ipv6mr_ifindex -fasm -Wno-psabi -fno-short-enums -fno-strict-aliasing -finline-limit=300 -mfloat-abi=softfp -mfpu=neon -marm -march=armv7-a -mtune=cortex-a8 ' --disable-shared --enable-static --extra-ldflags='-Wl,-rpath-link=/home/inisoft/android-ndk/platforms/android-8/arch-arm//usr/lib -L/home/inisoft/android-ndk/platforms/android-8/arch-arm//usr/lib -nostdlib -lc -lm -ldl -llog' --enable-parsers --disable-encoders --enable-decoders --disable-muxers --enable-demuxers --enable-swscale --disable-ffplay --disable-ffprobe --disable-ffserver --disable-ffmpeg --enable-network --enable-indevs --disable-bsfs --disable-filters --enable-protocols --enable-asm --disable-avdevice --disable-avfilter --enable-neon
no stagefright falgs there? or is this due to the hacked ffmpeg?
2012-10-18, 08:26
Havnt really investigated it further... further down in the config.log I see that libstagefright-h264 is indicated with a "yes".. so maybe the selection of disabled/enabled codecs could be done with environment variables also... (no expert on ffmpeg and its build structure, and I could not find the diceplayer application source either)
Wish I had more time.. but with a family to also tend to and at work (althou I work as a software developer, and can do some other stuff while building) I don't have the time.... So many other android applications exist using HW acceleration, so it is "just" a matter of finding an approach that will cover the most amount of devices with the least amount of effort (not trying to do individual support per chipset vendor).... Althou, looking at the main vendors there exist 3 major chipsets that cover >90% of the devices. If firm support for: Adreno, Mali and Nvidia could be achieved, then all would be set.
Regards // OwL
Wish I had more time.. but with a family to also tend to and at work (althou I work as a software developer, and can do some other stuff while building) I don't have the time.... So many other android applications exist using HW acceleration, so it is "just" a matter of finding an approach that will cover the most amount of devices with the least amount of effort (not trying to do individual support per chipset vendor).... Althou, looking at the main vendors there exist 3 major chipsets that cover >90% of the devices. If firm support for: Adreno, Mali and Nvidia could be achieved, then all would be set.
Regards // OwL
