yashsingh1/xdaforums huggingface dataset:
[HTC Amaze 4G] kusso92:
Hey can anyone help me with this issue? I have been using Supersayain 3 rom and just switched back to the Speedrom 6.5 that Eclipze released, I did a full wipe and also wiped both caches using 4ext recovery 1.0.0.5 rc3. I dont know what the problem is cuz Ive tried the 7.0 as well and still have the same wifi error problem. Can anyone help? I also have a problem when trying to run the team nightmare speedrom thing where it doesnt boot and stays on the spinning cyanogenmod screen, another rom having problems booting with is the sense 4.0 by team nightmare because it stays on the htc bootanimation screen and doesnt change, I remember I read in his thread that I need to install the kernel from his thread but the kernel is also down from goo.im. Anyone please help with some of my problems, before this I used to run supersayain 2 and had no problems at all with switching roms. I dont have any idea of what I couldve done wrong, before switching to any rom I also do a full wipe and wipe both caches and sometimes the int sd as well.
[HTC Amaze 4G] kusso92:
Can anyone give me any help, this thread has had over 100 views and not one person had replied. That's disappointing..
[HTC Amaze 4G] xDC23:
try using this http://d-h.st/Kt0

its the latest version of faux kernel. might fix your problem.
[HTC Wildfire S] csoulr666:
It's good that someone is doing research on this............

I think this might help

P.S.-You should consult all the people developing ICS for their respective ARMv6 devices

P.S.2-Submitted to portal
[HTC Wildfire S] modpunk:
Our hardware has MDP 3.0.2 and you need at least MDP 4.0 for the OMX stuff. You need new hardware for this and qcom will for sure not investigate a lot of money for old and dead hardware.
[HTC Wildfire S] benjamingwynn:
An idea of some wrapper around the GB codecs sounds good, but wouldn't the CPU be eaten doing this?
[HTC Wildfire S] 441Excelsior:
i think it will be better than nothing (like now)
[HTC Wildfire S] scottrix:
I have to admit that I know very little about the abilities of our hardware, and given your excellent work on this ROM I'm sure you know much more, however, our hardware CAN play videos using hardware OMX drivers on Gingerbread why specifically do you think that the hardware wouldn't be up to it on ICS ?
[HTC Wildfire S] scottrix:
Well, that might well be the problem, however, I have two thoughts on this:

1) Doing some of the decode in hardware and some in software should be better than all in software (depending on the hoops we have to jump through to get the APIs to match).

2) GB must be converting the output of the GB OMX drivers into some kind of native buffer so that it can display the frames so that would indicate it should be possible.

In the end, until we try we won't find out.
[HTC Wildfire S] Ko_Ka:
Just wondering, I'm not the most profficient in coding and the like, but what kind of programmer *may* be able to create a script for something like this? Someone with Android SDK and Java experience, or is it C based?
[HTC Wildfire S] scottrix:
Code is C / C++ look in vendor/qcom/opensource/omx
[HTC Wildfire S] scottrix:
Well, I have had some time to play and I have decided to change the code:

vendor/qcom/opensource/omx/mm-core/omxcore/src/common/omx_core_cmp.cpp

this seems to be a wrapper around the OMX codec, just making my edits with ENABLE_GINGERBREAD_OMX_DRIVERS define. Would be nice to come up with a cleaner solution, i.e. one that doesn't need changes to CM source as I doubt we would get modifications upstream, but until I get something working, it will do.

I have got rid of the get_extension_index problem, and some set_parameter problems, however, the underlying driver is giving:

Set Parameter called in Invalid State

Which isn't good since we don't have the source to know why it thinks it is invalid. My next step is to trace through the CM7.2 and CM9 code to work out how they are configuring the OMX driver differently. I should probably point out that my first goal is to get the codec running, I expect the screen output to be incorrect and need some colour format conversion, but one step at a time.

I am currently only looking at Decode, does anyone know if encoding (taking videos with the camera) works with the GB codec (can use logcat to tell if it is using sofware or GB codec).

BTW, there is code in vendor/qcom/opensource, have we asked qcom if they would be prepared to opensource the GB codecs ? they have obivously done it before so might be interested.
[HTC Wildfire S] scottrix:
Progress, well not quite, but I have found some more out. First in the code:

frameworks/base/media/libstagefright/OMXCodec.cpp

In the class constructor there is this code:

mNativeWindow(

(!strncmp(componentName, "OMX.google.", 11)

|| !strcmp(componentName, "OMX.Nvidia.mpeg2v.decode"))

? NULL : nativeWindow) {

If mNativeWindow is NULL then it doesn't do a get_extension_index for the nativebuffers and grepping the software codecs shows that these don't support it either. It's not the place in the code I wanted to start altering, but let's get something working first. So I added the qcom component name to this list and now get further...... but still no working video. I have been through the code from the component init to the point of failure:

I/OMXCodec( 106): [OMX.qcom.video.decoder.mpeg4] calling emptyBuffer with codec specific data

I/QC_CORE ( 106): OMXCORE: qc_omx_component_empty_this_buffer 1c894, 1f838

D/VCODEC omx_vdec( 106): omx_vdec::empty_this_buffer +

D/VCODEC omx_vdec( 106): omx_vdec::empty_this_buffer vdec_open +

D/VCODEC vdec( 106): vdec_open

W/VCODEC vdec( 106): vdec: failed to allocate pmem arena (5783552 bytes)

E/VCODEC vdec( 106): vendor/qcom/proprietary/qdsp5/mm-video/7k/7x27/vdec-omxmp4/../vdec-common/vdec.cpp:365 *** ERROR ASSERT(0)

and compared it to the cm7 code. I have also installed cm7 and compared the output from a logcat, and still no luck, I have found other differences, however, none have actually made a difference. next step is to output more tracing from cm7 and cm9 to determine if there are more differences. My worry is that there is something else on the system messing with this hardware and initializing it in a different way. Does anyone know if the adreno drivers use /dev/pmem ? as these have changed from cm7 to cm9.
[HTC Wildfire S] benjamingwynn:
Hm, maybe qcom tech support could help you with the /dev thing. It may sound dumb but qcom are pretty good with stuff like this.
[HTC Wildfire S] insink71:
omx

You won't find omx in gingerbread.. it was one of ics's new implimentations to enable hardware accelleration. Tis why qualcom released updated firmware to aid devs porting to ics. Pretty much our luck ran out there. The petition died when 1)Qualcomm said omx codecs were not possible for our chips and 2)Arm pulled the old arm11 development layer down.. So, pretty much not possible. Basically as I understand it, it requires adv sim.d or what arm calls neon (or a msm7x27a chip.. we have msm 7x27)

What is possible is what you mentioned. Using gb binaries with a wrapper. This wrapper is called a HAL. Unfortunately, CM has stated the time investment to do this for each cortex a8 is not worth it (and may break cvs); so, their official support (if we should even be able to get it for our beleagured device) would end with gb. And thus ends my input for the evening.

Rob
[HTC Wildfire S] scottrix:
OMX IS in gingerbread (or at least CM7), in fact the requirements for it are cleaner than ICS, ICS requires some google specific extensions. There ARE OMX drivers for the msm7x27, but they don't support the google extensions and so don't work (although it is a little more complicated than that). CM has stated that they will not support ARM6 devices so even if we were to get drivers from Qualcom, CM would not support it. Just cos CM say they aren't going to support it doesn't mean that it is not possible to produce a great ROM, as Ben and Modpunk and others have already proven, if you are looking for a CM supported version then you will need to buy a new phone.

I've been a little busy with other things over the last week or so and hope to get back to this soon.

One question I do have is that if I were to use the GB Adreno drivers on the ICS ROM would the phone still boot ? what would be the problems I'd notice ? not thinking of this as a long term solution, but might help me figure out what is going on, if my current thoughts turn up nothing.

Scott.
[HTC Wildfire S] benjamingwynn:
If I remember correctly (I might be wrong here) using gingerbread drivers broke hardware acceleration.
[HTC Wildfire S] scottrix:
OK, I have put lots of tracing for all omx calls to the binary codec in the omxcore and got logs for this from both ICS and GB. There isn't any difference in the calls and there aren't any differences in the parameters passed to those calls. Looking at include files the structures used in these calls have not changed (which might make the tracing look OK, but the binary data different there by upsetting the GB driver when given ICS structures). My only conclusion is that the ICS drivers for hardware graphics acceleration (EGL, GLES, OpenVG) use more resources from the qdsp5, or affects the qdsp5 in a way that stops the GB OMX codecs working. I believe the ICS graphics drivers from QCom are:

vendor/qcom/msm7x27/proprietary/lib/libsc-a2xx.so

vendor/qcom/msm7x27/proprietary/lib/libgsl.so

vendor/qcom/msm7x27/proprietary/lib/libC2D2.so

vendor/qcom/msm7x27/proprietary/lib/egl/libGLES_android.so

vendor/qcom/msm7x27/proprietary/lib/egl/libq3dtools_adreno200.so

vendor/qcom/msm7x27/proprietary/lib/egl/libEGL_adreno200.so

vendor/qcom/msm7x27/proprietary/lib/egl/eglsubAndroid.so

vendor/qcom/msm7x27/proprietary/lib/egl/libGLESv1_CM_adreno200.so

vendor/qcom/msm7x27/proprietary/lib/egl/libGLESv2_adreno200.so

vendor/qcom/msm7x27/proprietary/lib/libOpenVG.so

vendor/qcom/msm7x27/proprietary/etc/firmware/a300_pfp.fw

vendor/qcom/msm7x27/proprietary/etc/firmware/leia_pm4_470.fw

vendor/qcom/msm7x27/proprietary/etc/firmware/leia_pfp_470.fw

vendor/qcom/msm7x27/proprietary/etc/firmware/yamato_pfp.fw

vendor/qcom/msm7x27/proprietary/etc/firmware/a225_pfp.fw

vendor/qcom/msm7x27/proprietary/etc/firmware/yamato_pm4.fw

vendor/qcom/msm7x27/proprietary/etc/firmware/a225_pm4.fw

vendor/qcom/msm7x27/proprietary/etc/firmware/a225p5_pm4.fw

vendor/qcom/msm7x27/proprietary/etc/firmware/a300_pm4.fw

Of these files I could only find the following in GB:

system/lib/libgsl.so

system/lib/egl/libGLES_android.so

system/lib/egl/libEGL_adreno200.so

system/lib/egl/libGLESv1_CM_adreno200.so

system/lib/egl/libGLESv2_adreno200.so

So I deleted the missing ones and copied the GB ones over the ICS ones. This seemed to give me a "working" system, but with no display. Does anyone know how to get graphics on ICS working without using hardware graphics drivers ? If I could do that it would test my theory that the ICS hardware graphics acceleration libraries (EGL, GLES and VG) are stopping the hardware OMX codecs from working.
[HTC Wildfire S] benjamingwynn:
Hm this looks promising. The HTC hero uses adreno(?) 100 graphics whereas we use adreno 200, since qcom never released adreno 100 libs it'd be interesting to see how they got hwa on ics.

github.com/teamics
[HTC Wildfire S] baluuu:
More importantly do the OMX drivers work on their build. If yes that would be worth looking into if not why bother, that automaticly eliminates the theory above.

Edit: I actualy looked that up myself and what i saw is Video playback does work on the Hero. However they havent goten HWA working. But thats what i got from the op on the CM9 and CM10 threads might be something im missing. But this seems to prove the theory about ICS libs stoping omx from working on our device. The question becomes now will it ever be possible to have them both working ?
[HTC Wildfire S] scottrix:
Looking at the Hero threads it seems that HQ video isn't working either. Does any one know different ?.
[HTC Wildfire S] Lt.Win:
May I add some input? :)

Eoghan2t7, who's working on porting Firefox OS aka B2G, has looked at the files and has noticed that even though B2G is based off ICS, it uses the Gingerbread OMX libs. Now, we need to see of there's some code wrapped up around it, which allows the GB libs to work on ICS.

If we get that code (if it does exist) then our problem may have been solved.

Here's his quote:
[HTC Wildfire S] eoghan2t7:
Its not the libs its the omx source code from gingerbread I think but wont no until I read through the code and compair it the the code in cm7.
[HTC Wildfire S] scottrix:
I've removed the EGL/GLES support (Tweak to egl.cfg), however, I can't find a software version to run instead and so the Gallery app doesn't run (Nor does the launcher). I ran up the File manager I have installed (using am start -n) and clicked on the video, but that invokes the gallery application. Is there a way to replace the gallery app with a 3D version ? Or maybe there is another video playing app I could install to test hardware decoding ?.
[HTC Wildfire S] csoulr666:
How about trying QuickPic????

Or you can try video apps like MX Player,mobo player etc and play an MP4 with a minimum resolution of 320X480.......mentioning the resolution 'cause this resolution works very smoothly with Gingerbread but will be incredibly slow with S/W acceleration on ICS or JB
[HTC Wildfire S] infected85:
+1 for MX Player and Mobo player
[HTC Wildfire S] scottrix:
It is only after trying all your suggestions that I realise a typo in the above. "Is there a way to replace the gallery app with a 3D version ?" was meant to be "with a NON 3D version". I have basically disabled EGL and want a media player app that will not use EGL and allow me to play a video. Or is there some command line I can execute on the phone to get stagefright to play the video.
[HTC Wildfire S] csoulr666:
All you have to do for that is to rename the gallery app you wish to put(eg:quickpic)to the name of the gallery's apk and overwrite it and "chmod 644" the replaced apk
[HTC Wildfire S] scottrix:
Not really getting very far with this one. Don't seem to be able to locate an app that doesn't load egl libraries that will allow me to play a video. Does anyone have any app writing skills that would be able to create one for me ?

Does anyone know what the new requirements on EGL/GLES where from GB to ICS ? Also there were kernel changes from GB to ICS too, is there a detailed list of what was changed ? Or a way of getting a diff from the code ? would GB work with the ICS kernel ? Just some random thoughts I have on this issue.
[HTC Wildfire S] rallapag:
you could use the 2D gallery app from Cyanogenmod

https://github.com/CyanogenMod/android_packages_apps_Gallery/tree/jellybean
[HTC Wildfire S] mstfkaratas:
I built ics kernel from modpunk's sources and it is working fine on cm7. You can see the changes modpunk made from gb to ics by looking git log of ics branch.
[HTC Wildfire S] Dark Passenger:
Hi I am from the galaxy fit forum and since we too have this problem am in some doubt and need to know wether this will work or not.

Mx player allows for custom ffmpeg decoders and they even told how one can make it for their architecture on their site now if somehow we were able to add them to stagefright as a hw decoder our problems will be solved.

I read about this and it seems we still need omx I'll for this but if a custom renderer is used to directly decode it could let us have a better solution and even allow us to bypass omx I'll ... I need to know if this a feasable idea or not.
[HTC Wildfire S] scottrix:
I have got some minor changes to libstagefright that allows the ICS libstagefright to interface with the GB omx decoder. However, this fails. I have put lots of tracing in the generic OMX layer (That is actually the same on GB as ICS) and ICS is now driving the HW OMX decoder in the same way as on GB, but still it fails. My understanding is that on the Wildfire S the qdsp5 is used for hardware acceleration, this includes graphics acceleration (GLES) and media acceleration (OMX). We have new GLES drivers from Qualcom, but not new OMX drivers. My current theory is that the new GLES drivers are taking up more resources from the qdsp5 stopping the old OMX drivers from working. There could be other things happening and so I am trying to test this theory by getting rid of the ICS GLES drivers and just using the GB GLES and OMX drivers. When I do this the screen is completely blank, so I am trying to get a command line application that will play a video using OMX to see what happens (I can tell if it is working from logcat, I don't need to see the display). I have also got a setup where I have disabled only the EGL/GLES parts of the graphics and was trying to find an app that would play a video hoping this would work. I have yet to find an app that doesn't use EGL/GLES that can play videos.

If my theory is correct then we would need to hack ICS to be able to use a EGL/GLES driver from GB, I have no clue as to what is involved with this and hope we don't have to go there. If my theory is wrong and I still can't get the GB OMX driver to decode a video with ICS EGL/GLES drivers disabled, then I need to find another theory. Either way we are a long way off getting this working.

I don't suppose this helps much, but it is the current state of this investigation. Unfortunately I don't get much time to hack around with this, if someone is willing to help I can make my current changes available.
[HTC Wildfire S] Dark Passenger:
So if I understand you correctly omx I'l is working fine as its the same on gb and ics and the problem lies in the decoder right so how about integrating a custom decoder something else not gb omx

PS try older ics builds ones before the new adreno drivers cause they pretty much same functionality as after but slight deterioated user experience my thoughts are you should try a new approach so as to not ruin the user experience also

libstagefright allows for upperlimits to be set on resources you might want to check that it will limit resources for gles drivers.
[HTC Wildfire S] GUImess:
I'll just leave this here http://xdaforums.com/showthread.php?p=33374614
[HTC Wildfire S] csoulr666:
I found this too.......but I posted it in the CM threads
[HTC Wildfire S] GUImess:
Looked promising. I just don't understand it.
[HTC Wildfire S] Eskuero:
I'm gonna try to build using that thread, but I don't remember if we are using GB OMX libs or modded ICS OMX libs...
[HTC Wildfire S] benjamingwynn:
I'm also going to try and build with this.
[HTC Wildfire S] baluuu:
The code change is like 4 lines. Qualcom should hier this guy he fixed what they deemed imposible with few weeks of reading on the matter and 4 lines of code.
[HTC Wildfire S] iscree:
If this works on our device this day maybe could be the most exciting day in my life. New nexus 4 and 10 for soo low price and fixed only reason why I am not using cm9/10 on my wildfire s. Really hope this works
[HTC Wildfire S] Nightshadow931:
Anyone tried that ?
[HTC Wildfire S] scottrix:
Using my test video (a .3gp mpeg4 I recorded when on stock GB ROM), I get the same error that I reported with my changes earlier in this thread:

D/VCODEC vdec( 106): vdec_open

W/VCODEC vdec( 106): vdec: failed to allocate pmem arena (5783552 bytes)

E/VCODEC vdec( 106): vendor/qcom/proprietary/qdsp5/mm-video/7k/7x27/vdec-omxmp4/../vdec-common/vdec.cpp:365 *** ERROR ASSERT(0)

If someone does have a video that works then please let me know how to create one. I have not tested the h264 decoder as my main use case would be to play back videos I have recorded, maybe that is the one that works.
[HTC Wildfire S] VigiDroid:
It's probably not because they COULDN'T fix it, but rather they DIDN'T WANT TO fix it.
[HTC Wildfire S] scottrix:
I also finally got round to testing video with EGL/GLES not working. Turns out there is a stagefright program which will do it. However, still no luck on the above error. I next plan on putting the CM9 kernel on the CM7.2 build and seeing if my video still works there. Again if anyone has an ffmpeg line that will transcode a video to h264 that our phones can play on CM7.2 (GB) then that would be great.
[HTC Wildfire S] baluuu:
I read somewhere that mx player codecs are opn to look at at their site cant we just make custom codecs and set them for video decoding/encoding in media_codecs.xml ?

Edit: https://s3.amazonaws.com/mxvp-standard/ffmpeg.7z there it is actualy I looked it up.
[HTC Wildfire S] benjamingwynn:
sorry bumping this to resubscribe to thread :P
[HTC Wildfire S] izi501:
You can subscribe to thread without bumping any post :P
[HTC Wildfire S] pihug12:
With the stock ROM, I can play video made with this line :

ffmpeg.exe -i INPUT.avi -vcodec libx264 -vprofile baseline -s 480x320 OUTPUT.mp4

I don't know about CM7, but I think it would work the same way.
[HTC Wildfire S] midgetman7782:
I believe my Dev Team, ZTE+WFS have solved this. Not tested however. Check the forum for the thread
[HTC Wildfire S] scottrix:
Well, kudos to Ganster41 for getting there first with this, great work.

I finally got his changes working for me and it turns out I had a bug in some of my debug code, removing it, plus one more change, gets my changes working too.

With Ganster41's changes there are two processes, mediaserver and surfaceflinger each taking about 30% CPU (for my test video), with my changeset I have mediaserver taking about 60% CPU with surfaceflinger taking next to nothing. I think GB took 30% in total, but would need to try again. My changes are just to OMXCodec.cpp and AwesomePlayer.cpp, no changes to the softwareconversion stuff, I haven't tried many videos so maybe that would make a difference. It might be possible to reduce the number of changes to those files.

On the video encoding (video camera) front, I have a video that I recorded with stock GB. ffmpeg -i gives:

ffmpeg version 0.8.3-4:0.8.3-0ubuntu0.12.04.1, Copyright (c) 2000-2012 the Libav developers

built on Jun 12 2012 16:52:09 with gcc 4.6.3

*** THIS PROGRAM IS DEPRECATED ***

This program is only provided for compatibility and will be removed in a future release. Please use avconv instead.

[mov,mp4,m4a,3gp,3g2,mj2 @ 0x178e7a0] multiple edit list entries, a/v desync might occur, patch welcome

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'VIDEO0002.3gp':

Metadata:

major_brand : 3gp4

minor_version : 0

compatible_brands: isom3gp4

creation_time : 1946-02-21 18:03:00

Duration: 00:00:16.27, start: 0.000000, bitrate: 2075 kb/s

Stream #0.0(eng): Audio: aac, 44100 Hz, mono, s16, 63 kb/s

Metadata:

creation_time : 1946-02-21 18:03:00

Stream #0.1(eng): Video: mpeg4 (Simple Profile), yuv420p, 640x480 [PAR 1:1 DAR 4:3], 1624 kb/s, 19.61 fps, 30 tbr, 90k tbn, 30 tbc

Metadata:

creation_time : 1946-02-21 18:03:00

At least one output file must be specified

For one I created on CM9 I get:

ffmpeg version 0.8.3-4:0.8.3-0ubuntu0.12.04.1, Copyright (c) 2000-2012 the Libav developers

built on Jun 12 2012 16:52:09 with gcc 4.6.3

*** THIS PROGRAM IS DEPRECATED ***

This program is only provided for compatibility and will be removed in a future release. Please use avconv instead.

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'VID_20121112_215840.mp4':

Metadata:

major_brand : isom

minor_version : 0

compatible_brands: isom3gp4

creation_time : 1946-11-12 21:58:50

Duration: 00:00:08.46, start: 0.000000, bitrate: 2846 kb/s

Stream #0.0(eng): Video: h263, yuv420p, 640x480 [PAR 1:1 DAR 4:3], 2689 kb/s, 10.99 fps, 29.97 tbr, 90k tbn, 29.97 tbc

Metadata:

creation_time : 1946-11-12 21:58:50

Stream #0.1(eng): Audio: amrnb, 8000 Hz, 1 channels, flt, 5 kb/s

Metadata:

creation_time : 1946-11-12 21:58:50

At least one output file must be specified

in other words GB records mpeg4, aac - ICS records h263, amrnb. Is it possible to change this in ICS ? Will look around when I get time.
[HTC Wildfire S] csoulr666:
Really good to see progress.......I would like to request you to take a look over at JB as well