66 replies to this topic

[stare_spb]

skywave, on 13 May 2012 - 07:04 PM, said:

This is what happens if you try HW video decoding on ICS.


As you can see it loads the qcom decoder but then the qcom decoder craps out because of two not implemented commands: get_config and get_extension_index.

Did anybody tried to trace what the output of those commands (on msm7227a hardware)? Those commands does not seems to be taking arguments, so I guess the output is always the same on the same hardware? So what's preventing us to write the library, which would wrap the existing qcom decoder, +return the debugged static info on those 2 functions. Or do I miss something?  (sorry for bad english)

[tilal6991]

Thanks for the info sky wave. Really helped understand what is going on.

Is the Sony ST21i not an armv6 device however?

[t0mm13b]

stare_spb, on 14 May 2012 - 07:57 PM, said:

Did anybody tried to trace what the output of those commands (on msm7227a hardware)?

That's armv7 chipset - msm7227a. armv6 is msm7227

[stare_spb]

t0mm13b, on 14 May 2012 - 08:57 PM, said:

That's armv7 chipset - msm7227a. armv6 is msm7227

"  I know this, you missed the point of my post. My idea is to debug the get_config output on msm7227a hardware, and use the existing omx armv6 libs with wrapper, as the qdsp is basically the same.

[saransh9]

tilal6991, on 14 May 2012 - 08:45 PM, said:

Thanks for the info sky wave. Really helped understand what is going on.

Is the Sony ST21i not an armv6 device however?

Yes it is
http://www.xperiablo...engthy-preview/

[t0mm13b]

stare_spb, on 14 May 2012 - 09:14 PM, said:

"  I know this, you missed the point of my post. My idea is to debug the get_config output on msm7227a hardware, and use the existing omx armv6 libs with wrapper, as the qdsp is basically the same.

Edit:
Translating from armv7 code via debugging the output and translate into armv6 for a start, which brings about this.. how would you create a wrapper around the existing omx libs which are proprietary?!  

I am not sure if this could actually be done, i.e. intercept the library load process for the omx libs, and somewhat inject a method in there... you'd want to be very knowledgeable on the armv6 instruction set and determine where/when and how to intercept, its easier on the x86 platform in relation to windows, this is where it can go wrong....supply the wrong address and possibly crash the entire handset... just saying, its far more difficult than you realize...

Just have a look here - library preloading... ftw?

Edit#2: Just after reading it, its confirmed, library preload is not supported:

Quote

Placing hooks and operating within the application was pretty cool but it was unfortunately not possible on Android: The loader (ld) does not support library preloading via LD_PRELOAD

Edited by t0mm13b, 14 May 2012 - 09:38 PM.

[skywave]

saransh9, on 14 May 2012 - 09:24 PM, said:

Yes it is
http://www.xperiablo...engthy-preview/

No it isn't. Its the MSM7227A, the same SoC as the ZTE the rom in the OP is from.
http://www.themobile...-spotted-online
http://pdadb.net/ind...1i_sony_tapioca

[skywave]

The OPENMAX IL specification is online btw.

getExtensionIndex is on page 79

Quote

The OMX_GetExtensionIndex macro will invoke a component to translate from a
standardized OpenMAX or vendor-specific extension string for a configuration or a
parameter into an OpenMAX structure index. The vendor is not required to support this
command for the indexes already found in the OMX_INDEXTYPE enumeration, which
reduces the memory footprint. The component may support any standardized OpenMAX
or vendor-specific extension indexes that are not found in the master OMX_INDEXTYPE
enumeration.
This call is a blocking call. The component should return from this call within five msec.
The OMX_GetExtensionIndex macro is defined as follows.
#define OMX_GetExtensionIndex (
hComponent,
cParameterName,
pIndexType )
((OMX_COMPONENTTYPE*)hComponent)->GetExtensionIndex( \
hComponent, \
cParameterName, \
pIndexType)

Quote

3.2.2.10 OMX_GetConfig
The OMX_GetConfig macro will get a configuration structure from a component. This
macro can be invoked at any time after the component has been loaded. The
nParamIndex parameter indicates which structure is being requested from the
component. The caller shall provide the memory for the structure and populate the
nSize and nVersion fields before invoking this macro. If the configuration settings
are for a port, the caller shall also provide a valid port number in the nPortIndex field
before invoking this macro. All components shall support a set of defaults for each
configuration so that the caller can obtain the structure populated with valid values.
This call is a blocking call. The component should return from this call within five msec.
The OMX_GetConfig macro is defined as follows.
#define OMX_GetConfig (
hComponent,
nConfigIndex,
ComponentConfigStructure)
((OMX_COMPONENTTYPE*)hComponent)->GetConfig( \
hComponent, \
nConfigIndex, \
ComponentConfigStructure)
The parameters are as follows.
Parameters Description
hComponent
[in] The handle of the component that executes the call.
nIndex
[in]
The index of the structure to be filled. This value is from the
OMX_INDEXTYPE enumeration.
ComponentConfigStructure
[in,out]
A pointer to the IL client-allocated structure that the
component fills.
Section 3.3.9 describes the corresponding function that each component implements.

[stare_spb]

t0mm13b, on 14 May 2012 - 09:26 PM, said:

Edit:
Translating from armv7 code via debugging the output and translate into armv6 for a start, which brings about this.. how would you create a wrapper around the existing omx libs which are proprietary?!  

I am not sure if this could actually be done, i.e. intercept the library load process for the omx libs, and somewhat inject a method in there... you'd want to be very knowledgeable on the armv6 instruction set and determine where/when and how to intercept, its easier on the x86 platform in relation to windows, this is where it can go wrong....supply the wrong address and possibly crash the entire handset... just saying, its far more difficult than you realize...

Just have a look here - library preloading... ftw?

Yup, I meant some kind of library preloading technique, not direct injection hacks which sure are near to impossible.

Quote

Edit#2: Just after reading it, its confirmed, library preload is not supported:

OK. Next idea: patch libstagefright, by replacing the get_config and getextensionindex requests with debugged data?

[t0mm13b]

stare_spb, on 14 May 2012 - 09:55 PM, said:

Yup, I meant some kind of library preloading technique, not direct injection hacks which sure are near to impossible.



OK. Next idea: patch libstagefright, by replacing the get_config and getextensionindex requests with debugged data?

My understanding is the proprietary omx libs are crapping out with the two said un-implemented functions - refer to post #18 on this thread on the previous page.

Quote

E/QCvdec  (  115): Error: get_config Not Implemented

and

Quote

E/QCvdec  (  115): get_extension_index: Error, Not implemented

[stare_spb]

t0mm13b, on 14 May 2012 - 10:16 PM, said:

My understanding is the proprietary omx libs are crapping out with the two said un-implemented functions - refer to post #18 on this thread on the previous page.

and

Your understanding is not fully correct. That's not the omx libs which are crapping out, but a code in a libstagefright which tries to access those unimplemented functions. So the obvious solutions seems to be patch this code, replacing the actual calls with data retrieved from msm7227a hardware.

[t0mm13b]

stare_spb, on 14 May 2012 - 10:24 PM, said:

Your understanding is not fully correct. That's not the omx libs which are crapping out, but a code in a libstagefright which tries to access those unimplemented functions. So the obvious solutions seems to be patch this code, replacing the actual calls with data retrieved from msm7227a hardware.

The error tag identifier points to Qualcomm libs right?

[skywave]

t0mm13b, on 14 May 2012 - 10:25 PM, said:

The error tag identifier points to Qualcomm libs right?

Yeah but stare_spb is right. OMXnoddeInstance (part of libstagefright tries to access those two methods, get unimplemented back so it moves on to the next codec. Which is the software codec. The obvious hack is indeed to try to get revert back omxnodeinstance to try to workaround these two methods, by for example revert those two commits i put in the big post.
But there could be tremendous sideeffects of that, they were commited in Feb 2011. Quite resonable to assume they are used all over in ICS and upcoming NDK apps.

Edited by skywave, 14 May 2012 - 10:40 PM.

[stare_spb]

t0mm13b, on 14 May 2012 - 10:25 PM, said:

The error tag identifier points to Qualcomm libs right?

You mean QCvdec? You mean some code in propietary qcom libs requests unimplemented functions in some other propietary libs? Seems highly unlikely. I may not fully getting your poing, though, correct me if you think so.  My understanding is that errors is caused by libstagefright code such as:


    mComponent->GetConfig = GetConfigWrapper;
    mComponent->SetConfig = SetConfigWrapper;
    mComponent->GetExtensionIndex = GetExtensionIndexWrapper;

[skywave]

There is a very very tiny chance though, that there is an updated QDSP5 Openmax wrapper somewhere in some gingerbread rom. But then again its more likely that qualcomm kept these changes in an ICS branch.

[t0mm13b]

stare_spb, on 14 May 2012 - 10:42 PM, said:

You mean QCvdec? You mean some code in propietary qcom libs requests unimplemented functions in some other propietary libs? Seems highly unlikely. I may not fully getting your poing, though, correct me if you think so.  My understanding is that errors is caused by libstagefright code such as:


mComponent->GetConfig = GetConfigWrapper;
mComponent->SetConfig = SetConfigWrapper;
mComponent->GetExtensionIndex = GetExtensionIndexWrapper;

My bad, I must have mistook the error tag identifier as the proprietary libs..

Bloody black boxes...

[t0mm13b]

@stare_spb:

Is this what you're thinking of - page 124 of my favourite book. Interpositioning - replace a global c library function with your own, as in this case, override the omx lib's unimplemented methods with a call to a library for example, 'omxFooLib' in which it returns a spoofed or constant value to satisfy the libstagefright? But beware, omx could break somewhere if it calls 'omxFooLib' for the function get_extension_index and get_config

Just saying, that you're correct so far, but what does those two functions return on a pure ICS running ARMv7 chipset? - if its pointers of some sort to some omx structure that could be trouble? Or does it return a block of memory allocated or does it return 0 for success? (ICS can be recompiled for that handset and simply add a logcat to dump whatever it is returning for those two calls?)

Edited by t0mm13b, 14 May 2012 - 11:54 PM.

[h1989826]

so  good !   i   hope the orange v880  also can  run  wp

[KonstaT]

There was a second ICS update for N880E the other day. Not much new except this ZTE live wallpaper was now included. Anyone who's watched MWC/CES videos of upcoming ZTE devices should be familiar with this. It took a small modification to make it work in Blade and it still only works in some ZTE devices.

Spinning 3D shrooms, wtf ZTE.

 Screenshot_2012-05-26-11-34-49.png   416.91K   63 downloads

MushroomDay.apk
http://www.mediafire...cg13i98fglcr2k9

[shmizan]

probably what they ate when they put the .35 kernel sources out