[ROM][GT-I9100][4.0.4] CyanogenMod 9 nightly builds | DEVELOPMENT THREAD

Entropy512 · Mar 27, 2012

codeworkx said:
Code:

float elevation; /** Azimuth of SV in degrees. */ float azimuth; #ifdef EXYNOS4210_ENHANCEMENTS /** Unknown field in Samsung I9100 libgps May be an indicator for constellation type (GPS, GLONASS, Galileo)? */ int samsung_broke_this; #endif } GpsSvInfo;

EXYNOS4210_ENHANCEMENTS is a global cflag we're using for all kind of galaxys2, att and galaxynote hacks since they're all identical.
https://github.com/CyanogenMod/android_device_samsung_galaxys2/blob/ics/BoardConfig.mk#L32

Since it's a header file and you dunno who includes it, we have to use a global flag.
Use the exynos one or create a new, more specific one.
BOARD_USES_SAMSUNG_GPS or something like this.

OK, thanks, I'll whip something up tonight and gerrit it.

I think I may go with BOARD_USES_SAMSUNG_GPS - I'm fairly certain other Samsung devices have this enhancement, including the Qualcomm abominations. I need to dig up some info, but I think this most likely was put in here for I9100 to allow framework compatibility with the Note and Skyrocket - http://xdaforums.com/showthread.php?p=19474107#post19474107

So there's a good chance that once he unbricks his Note, xplodwild might actually see numbers other than zero for the new field if he put in some logging code to print it for each sat in... I forget the file at the moment, I'll pull it up tonight.

I somewhat disagree on sourcecode = documentation - it saves a lot of time for a new contributor to have at least some high-level architecture documentation (Android itself might have this, although tbh the documentation on how the source is organized is a bit of a pain. Figuring things out often involves long grep runs across the whole tree to find something.

)

Phistachio · Mar 27, 2012

simionpetrus said:
Market unlocker is not working on 0326.

Sent from my GT-I9100 using XDA

THIS IS A DEVELOPMENT THREAD.

Plus, I think "Market Unlocker" is a hack. You shouldn't really post that stuff here...

@codework I'll research a bit about a videocam fix tonight, I'll see if I can figure anything out.

codeworkx · Mar 27, 2012

89luca89 said:
Yeah about compiling I'm already documented, I mean about the (for example) camera, what parts are involved
I understand its the android_hardware_samsung/exynos4 branch, but for the recording what files specifically have to be reviewed/corrected/studied??

Thanks for the clarification

camera.exynos4.so xD
Proprietary module = black box.
Have fun decompiling.

You can have a look at the tuna camera but that won't help much since it's a more or less clean implementation and has lots of omap specific stuff.
What samsung did on the i9100 camera... ask samsung. ;-)

And like Entropy said, grep and find are your friends.
Pick a error message from logcat and then grep the sourcecode for it.
This will point you the right direction.

89luca89 · Mar 27, 2012

codeworkx said:
camera.exynos4.so xD
Proprietary module = black box.
Have fun decompiling.

You can have a look at the tuna camera but that won't help much since it's a more or less clean implementation and has lots of omap specific stuff.
What samsung did on the i9100 camera... ask samsung. ;-)

And like Entropy said, grep and find are your friends.
Pick a error message from logcat and then grep the sourcecode for it.
This will point you the right direction.

I will ask them ahha xD
Ok so, At least I have the method now

I'll start troubleshooting

Thanks to you and Entropy to help me start! I'll try to be usefull

lodder · Mar 28, 2012

Bug Report:

http://pastie.org/3682928

Tried to play a video from the website m.sporza.be and got the following error log:

E/OMXNodeInstance( 1864): OMX_GetExtensionIndex failed
W/GraphicBufferAllocator( 1861): alloc(320, 240, 19, 00002900, ...) failed -22 (Invalid argument)
E/SurfaceFlinger( 1861): GraphicBufferAlloc::createGraphicBuffer(w=320, h=240) failed (Invalid argument), handle=0x0
E/SurfaceTexture( 1861): [SurfaceView] dequeueBuffer: SurfaceComposer::createGraphicBuffer failed
E/ACodec ( 1864): dequeueBuffer failed: Invalid argument (22)
E/ACodec ( 1864): Failed to allocate buffers after transitioning to IDLE state (error 0xffffffea)
E/NuPlayer( 1864): Received error from video decoder, aborting playback.
E/NuPlayer( 1864): video track encountered an error (-2147483648)
E/MediaPlayer(17436): error (1, -2147483648)
E/MediaPlayer(17436): Error (1,-2147483648)

Edit: youtube works.

eseregin · Mar 28, 2012

lodder said:
Bug Report:

http://pastie.org/3682928

Tried to play a video from the website m.sporza.be and got the following error log:

Not sure, but think this is what about Codeworkx said in 1-st post

* Submitting bug reports on nightly builds is the leading
* cause of male impotence.

Please use
DISCUSSION THREAD FOR USERS:
http://xdaforums.com/show....php?t=1419102

Entropy512 · Mar 28, 2012

At least he included a logcat and instructions on how to reproduce. (If possible - can you give a link to the exact video?)

lodder · Mar 28, 2012

Entropy512 said:
At least he included a logcat and instructions on how to reproduce. (If possible - can you give a link to the exact video?)

In the pastie link is the logcat and is also the video url. But if you need more I'll re try it in the weekend when I have more time.

Zlodo · Mar 29, 2012

I've been digging into the video recording issue and here's what I found so far, starting from the "missing codec specific information" error logged by MPEG4Writer (part of libstagefright in frameworks/base/media). So far the issue doesn't seem linked specifically to the camera but more of an issue with video codecs and the way they interface with libstagefright.

This "codec specific information" can apparently be obtained in different ways, but in that specific case it's supposed to be written by the codec into its output buffer at some point, which is indicated by kKeyIsCodecConfig being set to true in the meta-data, at which point MPEG4Writer should parse it and store it.

This happens in MPEG4Writer::Track::threadEntry(), which calls makeAVCCodecSpecificData() if kKeyIsCodecConfig is found to be true in the metadata.

In our case, traces added in there shows that this never happens, kKeyIsCodecConfig is never set to true.

It is supposed to be set by OMXCodec while treating an omx_message::FILL_BUFFER_DONE if the buffer data flags is set to OMX_BUFFERFLAG_CODECCONFIG. Adding traces in there shows that the code that test this flag is reached, but the flag is never set.

I then decided to see what was happening at the other end, inside of the samsung h264 OMX codec (which is the encoder used in this case), whose code is located in hardware/samsung/exynos4/multimedia/openmax/sec_omx/component/video/enc/h264/SEC_OMX_H264enc.c
I enabled logging in there by #undefing SEC_LOG_OFF at the beginning, and added some logging in the two places where the codec configuration data is emitted and OMX_BUFFERFLAG_CODECCONFIG is set. It turns out that it does happen, once at the beginning.

The interesting thing is that OMXCodec in libstagefright doesn't receive a corresponding omx_message::FILL_BUFFER_DONE once the codec have done the above, which is where it would test for the OMX_BUFFERFLAG_CODECCONFIG flag and relay the information by setting the kKeyIsCodecConfig flag in the metadata.

It was getting late so that's where I am now, but maybe it can be of some help.

I've studied the code in more detail today and more or less mapped the code path that is supposed to result in that fill_buffer_done message to be sent once the codec outputs the codeconfig flag so I'll add traces along that tonight to see where the information seems to be lost.

espenfjo · Mar 29, 2012

Zlodo said:
I've been digging into the video recording issue and here's what I found so far, starting from the "missing codec specific information" error logged by MPEG4Writer (part of libstagefright in frameworks/base/media). So far the issue doesn't seem linked specifically to the camera but more of an issue with video codecs and the way they interface with libstagefright.

This "codec specific information" can apparently be obtained in different ways, but in that specific case it's supposed to be written by the codec into its output buffer at some point, which is indicated by kKeyIsCodecConfig being set to true in the meta-data, at which point MPEG4Writer should parse it and store it.

This happens in MPEG4Writer::Track::threadEntry(), which calls makeAVCCodecSpecificData() if kKeyIsCodecConfig is found to be true in the metadata.

In our case, traces added in there shows that this never happens, kKeyIsCodecConfig is never set to true.

It is supposed to be set by OMXCodec while treating an omx_message::FILL_BUFFER_DONE if the buffer data flags is set to OMX_BUFFERFLAG_CODECCONFIG. Adding traces in there shows that the code that test this flag is reached, but the flag is never set.

I then decided to see what was happening at the other end, inside of the samsung h264 OMX codec (which is the encoder used in this case), whose code is located in hardware/samsung/exynos4/multimedia/openmax/sec_omx/component/video/enc/h264/SEC_OMX_H264enc.c
I enabled logging in there by #undefing SEC_LOG_OFF at the beginning, and added some logging in the two places where the codec configuration data is emitted and OMX_BUFFERFLAG_CODECCONFIG is set. It turns out that it does happen, once at the beginning.

The interesting thing is that OMXCodec in libstagefright doesn't receive a corresponding omx_message::FILL_BUFFER_DONE once the codec have done the above, which is where it would test for the OMX_BUFFERFLAG_CODECCONFIG flag and relay the information by setting the kKeyIsCodecConfig flag in the metadata.

It was getting late so that's where I am now, but maybe it can be of some help.

I've studied the code in more detail today and more or less mapped the code path that is supposed to result in that fill_buffer_done message to be sent once the codec outputs the codeconfig flag so I'll add traces along that tonight to see where the information seems to be lost.

This is great work.
Keep it up.

However, for me it seems like FILL_BUFFER_DONE is actually hit all the time.
OMX_BUFFERFLAG_CODECCONFIG is also set.

E/OMXCodec(11944): EFO: OMX_BUFFERFLAG_CODECCONFIG: 128
E/OMXCodec(11944): EFO: msg.u.extended_buffer_data.flags: 16

However as the test checks for bitwise and those two values will always return 0, making the test fail.
Changing the test makes the app crash

Zlodo · Mar 29, 2012

espenfjo said:
This is great work.
Keep it up.

However, for me it seems like FILL_BUFFER_DONE is actually hit all the time.
OMX_BUFFERFLAG_CODECCONFIG is also set.

E/OMXCodec(11944): EFO: OMX_BUFFERFLAG_CODECCONFIG: 128
E/OMXCodec(11944): EFO: msg.u.extended_buffer_data.flags: 16

However as the test checks for bitwise and those two values will always return 0, making the test fail.

Yep, it does mean the bit isn't set

I've gone much further now. Investigating some more, I pinpointed the codec specific data missing issue to the interface between the kernel MFC driver and the OMX codec implementation: it is defined by a data structure in a file called mfc_interface.h. Both the kernel driver and the omx codecs in samsung/hardware use their own copy of that file, and it turns out the structures are mismatched.

In hardware/samsung/exynos4/multimedia/codecs/sec_codecs/video/exynos4/mfc/include/mfc_interface.h, line 132, there is a field called in_output_mode that doesn't exist in the kernel driver.
I've commented it as well as the three places where something was written to it (comments mention this isn't a supported feature of the driver anyway), and things fell into place to the point that the "missing codec specific data" error doesn't happen anymore.

It still doesn't work but had an effect on the end result: the camera now records a video consisting of solid green, instead of black.

[edit]
There are a lot of other discrepancies between the mfc kernel module and the code that interfaces with it in the omx codecs. It may very well explain why it still doesn't work. It's like the user side and the kernel side of that interface aren't exactly the same version.

espenfjo · Mar 29, 2012

Zlodo said:
Yep, it does mean the bit isn't set

I've gone much further now. Investigating some more, I pinpointed the codec specific data missing issue to the interface between the kernel MFC driver and the OMX codec implementation: it is defined by a data structure in a file called mfc_interface.h. Both the kernel driver and the omx codecs in samsung/hardware use their own copy of that file, and it turns out the structures are mismatched.

In hardware/samsung/exynos4/multimedia/codecs/sec_codecs/video/exynos4/mfc/include/mfc_interface.h, line 132, there is a field called in_output_mode that doesn't exist in the kernel driver.
I've commented it as well as the three places where something was written to it (comments mention this isn't a supported feature of the driver anyway), and things fell into place to the point that the "missing codec specific data" error doesn't happen anymore.

It still doesn't work but had an effect on the end result: the camera now records a video consisting of solid green, instead of black.

[edit]
There are a lot of other discrepancies between the mfc kernel module and the code that interfaces with it in the omx codecs. It may very well explain why it still doesn't work. It's like the user side and the kernel side of that interface aren't exactly the same version.

Ok..
So your fix (http://review.cyanogenmod.com/#change,14174) together with http://review.cyanogenmod.com/#change,14108 will make video work.

Thank you for your fantastic work, Zlodo.

Zlodo · Mar 29, 2012

espenfjo said:
Ok..
So your fix (http://review.cyanogenmod.com/#change,14174) together with http://review.cyanogenmod.com/#change,14108 will make video work.

Thank you for your fantastic work, Zlodo.

Alas, I don't think so. My fix solves one problem but exynos4/multimedia/codecs/sec_codecs/video/exynos4/mfc/include/SsbSipMfcEncAPI.h also differs quite a bit from the same file in the kernel driver, which is bound to cause more issues. I've tried to copy over the kernel's headers over to video/exynos4, but there are some significant changes that need to be made in the code. For instance, there are commands to set driver configuration that have changed, which means that currently those commands can't possibly work properly since we send stuff to the driver in a format it doesn't recognize anymore.

Basically the stuff in exynos4/multimedia/codecs/sec_codecs/video/exynos4/mfc/ seems to be intended to work with an older version of the driver in kernel/drivers/media/video/samsung/mfc5x. I think that stuff needs to be updated with a version that matches with the kernel.

espenfjo · Mar 29, 2012

Test it, those two fixes works for me

Zlodo · Mar 29, 2012

It does work, although only really properly with the front facing camera. With the back camera, the video is partly shifted around and mangled, so there's probably some remaining issues with the memory layout of the data. It might also be because I've updated my repo but only rebuilt and installed libstagefright.

I still think that such problems will keep cropping up as long as the interface between the codecs and the driver is semi-broken. I'm currently downloading the samsung source code distribution to see if new version of those files matching the kernel driver can be found in there.

espenfjo · Mar 29, 2012

Zlodo said:
It does work, although only really properly with the front facing camera. With the back camera, the video is partly shifted around and mangled, so there's probably some remaining issues with the memory layout of the data. It might also be because I've updated my repo but only rebuilt and installed libstagefright.

I still think that such problems will keep cropping up as long as the interface between the codecs and the driver is semi-broken. I'm currently downloading the samsung source code distribution to see if new version of those files matching the kernel driver can be found in there.

It seems to be normal here, ratio isnt exactly widescreen, but i guess that is how it is..

Zlodo · Mar 29, 2012

espenfjo said:
It seems to be normal here, ratio isnt exactly widescreen, but i guess that is how it is..

I probably messed up my build.

Well nothing in samsung's files, they only provide the kernel. I guess It's always possible to hack it around, there aren't that many differences.
But when I tried to copy those two .h from the kernel to the sub directory in exynos 4 it wouldn't compile out of the box, there are things to change in the .c files, which means there are probably some parameters and such that aren't passed properly between the driver and the codec.

Oh well, if it works it works

espenfjo · Mar 29, 2012

It is a start at least.
Next thing would be the FIMC Scaler issue, to stop the kernel from crashing with HD recordings.

codeworkx · Mar 30, 2012

espenfjo said:
It is a start at least.
Next thing would be the FIMC Scaler issue, to stop the kernel from crashing with HD recordings.

the fimc scaler doesn't get informed about the correct resolution.
it always assumes we're on 640x480. 480p is 640x480, that's why this works without problems.
If we go on 720p or 1080p, fimc scaler still thinks we're doing 640x480 and this causes an overflow.

this hack https://github.com/teamhacksung/and...mmit/4bf9f60e5e5f5033f4531094ca3540d888f7b118 fakes this values but results in corrupted frames for 720p and 1080p. somehow fimc doesn't receive the correct resolution. should come from HAL. but dunno what we're missing.

Stock ROM:
fimc_capture_scaler_info: CamOut (1920, 1080), TargetOut (1920, 1080)

CM9 without hack:
fimc_capture_scaler_info: CamOut (640, 480), TargetOut (1920, 1080)
results in overflow and camera crash

CM9 with hack:
fimc_capture_scaler_info: CamOut (640, 480), TargetOut (1920, 1080)
<HACK> fimc_capture_scaler_info: CamOut (1920, 1080), TargetOut (1920, 1080)
results in corrupted frames, but no crash. looks like misssized.

need to debug it this evening if there's time.

maybe fakeing in an earlier step does the trick:
http://pastebin.com/1ZWgvwVW

espenfjo · Mar 30, 2012

Faking the earlier step does not work, even if you do width/height the correct way

Neither does it work to set cam->width instead of cam->window.width.

[ROM][GT-I9100][4.0.4] CyanogenMod 9 nightly builds | DEVELOPMENT THREAD

Senior Recognized Developer

Senior Member

Senior Recognized Developer

Retired Recognized Developer

Member

Senior Member

Senior Recognized Developer

Member

Member

Senior Member

Member

Senior Member

Member

Senior Member

Member

Senior Member

Member

Senior Member

Senior Recognized Developer

Senior Member

Similar threads

Top Liked Posts