yashsingh1/xdaforums huggingface dataset:
[Galaxy S II Original Android Development] drakester09:
Hi all,

I took a quick look at the sources, maybe this whole guesswork can produce something useful, or it's a bunch of BS, be my guest.

The Error is being thrown by the function

MPEG4Writer::Track::checkCodecSpecificData().

This method calls mMeta->findCString(kKeyMIMEType, &mime) that looks up for a CString in mMeta (mMeta is a MetaData member inside the MPEG4Writer class), this value is then saved into the &mime parameter.

Internally the method findCString looks up a CString in a KeyedVector (the mItems member), that CString is mapped by the key "kKeyMIMEType" which in reality is part of an enum (the key's real value is 'mime').

My guess would be that MetaData's mItems does not contain any of the expected value for 'mime' or it's not populated/instanced.

The expected values are:

MEDIA_MIMETYPE_AUDIO_AAC
MEDIA_MIMETYPE_VIDEO_MPEG4
MEDIA_MIMETYPE_VIDEO_AVC

These are compared with a plain strcasecmp:

!strcasecmp(MEDIA_MIMETYPE_AUDIO_AAC, mime)

I think these comparison values might be the ones stored in the codec's static const CodecInfo kDecoderInfo[] but I'm completely clueless on that one for the moment, I'd have to look it up.

And that's as far as I have gotten a chance to check. I hope it helps at least a bit... I'm in no way an expert on codecs or media related sourcebases or even the Android platform, just a very bad programmer.
[Galaxy S II Original Android Development] LeoMar75:
Hi there,

I'm currently running CM9 and i love it!

I'd like to give my support to you, i will dive into the code ASAP!
[Galaxy S II Original Android Development] codeworkx:
MPEG4Writer is used for any kind of format. Not just for MPEG4.

Yeah, the name is confusing. And we already tried every format.

THIS IS A DEVELOPMENT THREAD

THIS IS A DEVELOPMENT THREAD
[Galaxy S II Original Android Development] codeworkx:
const char *MEDIA_MIMETYPE_IMAGE_JPEG = "image/jpeg";

const char *MEDIA_MIMETYPE_VIDEO_AVC = "video/avc";
const char *MEDIA_MIMETYPE_VIDEO_MPEG4 = "video/mp4v-es";
const char *MEDIA_MIMETYPE_VIDEO_H263 = "video/3gpp";
const char *MEDIA_MIMETYPE_VIDEO_RAW = "video/raw";

const char *MEDIA_MIMETYPE_AUDIO_AMR_NB = "audio/3gpp";
const char *MEDIA_MIMETYPE_AUDIO_AMR_WB = "audio/amr-wb";
const char *MEDIA_MIMETYPE_AUDIO_MPEG = "audio/mpeg";
const char *MEDIA_MIMETYPE_AUDIO_AAC = "audio/mp4a-latm";
const char *MEDIA_MIMETYPE_AUDIO_RAW = "audio/raw";

const char *MEDIA_MIMETYPE_CONTAINER_MPEG4 = "video/mpeg4";

https://github.com/CyanogenMod/andr...ponent/video/dec/h264/SEC_OMX_H264dec.c#L2517
[Galaxy S II Original Android Development] Entropy512:
Codeworkx - I figured out why the GPS is not reporting satellite status correctly.

Samsung added an extra 32-bit field (always seems empty on I777) to GpsSvInfo. As a result the first satellite report is aligned properly, and sometimes one of the later Svs. Adding an extra field in gps.h fixes the issue - the question is - how would I implement the attached patch in a way that doesn't break ALL THE DEVICES! (except ours...)
[Galaxy S II Original Android Development] 89luca89:
@codeworkx

hi! I really want to do something to help you, xploid and cm team to finally have a fully aosp working on gs2! I'm not an expert programmer, have academic only notion of C and little self tought of Java...

But I really want to help and also learn (so I can help better :P)

What can I do/test or simply some documentation to start to study to help the development? I'm at your orders :D I'll try to do my best!
[Galaxy S II Original Android Development] cdesai:
Can't you just ifdef it?
[Galaxy S II Original Android Development] Entropy512:
I have not seen precent for #ifdefing stuff in that part of the tree...

That's why I'm asking for codeworkx's input on the "right" way to do this. :)
[Galaxy S II Original Android Development] codeworkx:
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.
[Galaxy S II Original Android Development] codeworkx:
There's nothing except:

http://source.android.com/

http://wiki.cyanogenmod.com/wiki/Building_from_source

http://wiki.cyanogenmod.com/wiki/Howto:_Gerrit

Sourcecode = Documentation!!!
[Galaxy S II Original Android Development] 89luca89:
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 :D
[Galaxy S II Original Android Development] Entropy512:
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. :) )
[Galaxy S II Original Android Development] Phistachio:
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.
[Galaxy S II Original Android Development] codeworkx:
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.
[Galaxy S II Original Android Development] 89luca89:
I will ask them ahha xD

Ok so, At least I have the method now :D I'll start troubleshooting :D Thanks to you and Entropy to help me start! I'll try to be usefull :D
[Galaxy S II Original Android Development] lodder:
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.
[Galaxy S II Original Android Development] eseregin:
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
[Galaxy S II Original Android Development] Entropy512:
At least he included a logcat and instructions on how to reproduce. (If possible - can you give a link to the exact video?)
[Galaxy S II Original Android Development] lodder:
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.
[Galaxy S II Original Android Development] Zlodo:
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.
[Galaxy S II Original Android Development] espenfjo:
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 ;)
[Galaxy S II Original Android Development] Zlodo:
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.
[Galaxy S II Original Android Development] espenfjo:
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.
[Galaxy S II Original Android Development] 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.
[Galaxy S II Original Android Development] espenfjo:
Test it, those two fixes works for me ;)
[Galaxy S II Original Android Development] Zlodo:
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.
[Galaxy S II Original Android Development] espenfjo:
It seems to be normal here, ratio isnt exactly widescreen, but i guess that is how it is..
[Galaxy S II Original Android Development] Zlodo:
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 :)
[Galaxy S II Original Android Development] espenfjo:
:)

It is a start at least.

Next thing would be the FIMC Scaler issue, to stop the kernel from crashing with HD recordings.
[Galaxy S II Original Android Development] codeworkx:
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
[Galaxy S II Original Android Development] espenfjo:
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.
[Galaxy S II Original Android Development] Zlodo:
So if I got this straight, basically we have camera.exynos.so, which is a wrapper around the proprietary binary vendor-camera.exynos4.so, and that thing communicates with the fimc driver in the kernel. Is that right?

So the issue would be likely to be there. I have a question though, does the cm9 built-from-sources kernel works with the stock samsung ics rom? And if so, does hd video recording work in that setup?

Because it could be a good way to determine whether the problem actually comes from the interface between the camera module and the kernel's fimc driver, and not from something else.

(disregard all that if my assumptions are wrong, I'm currently at work and can't do much more than speculate based on greping things in the sources)
[Galaxy S II Original Android Development] Entropy512:
There are some differences between CM kernels and Touchwiz-targeted kernels, mainly in initramfs.

If you want to play with a Touchwiz firmware and a source-built kernel, my repo at https://github.com/Entropy512/kernel_galaxys2_ics should be useful.

Instrumenting the fimc driver might be useful.

I might look at it later this weekend - but the cpufreq issues with all I9100/I777 ICS kernels have been my kernel priority lately.
[Galaxy S II Original Android Development] Zlodo:
Yeah, I think it's the easiest way to go about it.

I've tried to figure out how exactly the fimc driver is supposed to receive the size from the userland code.

It's done through a standard interface called v4l2 (video for linux, version 2) (sorry if this is obvious, I never worked on that stuff, I'm discovering as I go)

Docs for it can be found there: http://v4l2spec.bytesex.org.

Of interest here are the ioctl() calls that are used to specify cropping and scaling: http://v4l2spec.bytesex.org/spec/x1904.htm

Those ioctl are received in the kernel by drivers/media/video/v4l2-ioctl.c, and dispatched to the actual driver through function pointers.

It means that the desired capture size should basically "enter" the fimc driver in the following functions:

fimc_s_crop() in fimc_v4l2.c (VIDIOC_S_CROP ioctl, cf http://v4l2spec.bytesex.org/spec/r9994.htm)

and

fimc_s_fmt_vid_capture() in either fimc_capture_u1.c or fimc_capture.c (i'm not sure which one is used) (VIDIOC_S_FMT ioctl, cf http://v4l2spec.bytesex.org/spec/r10944.htm)

Those should be interesting places to add some instrumentation, or to try and force it to another size.
[Galaxy S II Original Android Development] espenfjo:
/* subdev handling macro */
#define subdev_call(ctrl, o, f, args...) \
v4l2_subdev_call(ctrl->cam->sd, o, f, ##args)
..
..
ret = subdev_call(ctrl, video, enum_framesizes, &cam_frmsize);
.
.
.
if (cam_frmsize.discrete.width > 0 && cam_frmsize.discrete.height > 0) {
ctrl->cam->window.left = 0;
ctrl->cam->window.top = 0;
printk(KERN_INFO "<HACK> %s: non-rot camera width=%d, height=%d\n", __func__, ctrl->cam->width, ctrl->cam->height);

ctrl->cam->width = ctrl->cam->window.width = cam_frmsize.discrete.width;
ctrl->cam->height = ctrl->cam->window.height = cam_frmsize.discrete.height;
printk(KERN_INFO "<HACK> %s: non-rot camera frame width=%d, height=%d\n", __func__, cam_frmsize.discrete.width, cam_frmsize.discrete.height);
printk(KERN_INFO "<HACK> %s: non-rot camera window width=%d, height=%d\n", __func__, ctrl->cam->window.width, ctrl->cam->window.height);

fimc_info2("enum_framesizes width = %d, height = %d\n",
ctrl->cam->width, ctrl->cam->height);
}

<6>[ 206.743748] <HACK> fimc_streamon_capture: non-rot camera width=1920, height=1080

<6>[ 206.743814] <HACK> fimc_streamon_capture: non-rot camera frame width=640, height=480

<6>[ 206.743884] <HACK> fimc_streamon_capture: non-rot camera window width=640, height=480

So some instrumentation in the v4l2 code might perhaps shed some light on where the kernel misses the Camera size
[Galaxy S II Original Android Development] Skyline92:
Hi guys. Maybe it's not useful, but HD recording works with this app.

https://play.google.com/store/apps/details?id=com.moblynx.cameraics&hl=de

Hope it helps.
[Galaxy S II Original Android Development] espenfjo:
Yup, It is very helpful :)

We are looking into it now.

http://pastebin.com/R7VztYp5 - Kernel logs with CM Camera and Camera ICS app.
[Galaxy S II Original Android Development] Skyline92:
Nice :-).

Two more things:

There's always some background noise. Seems like the mic is a bit overtuned.

Second thing is, that the displayed resolution while filming is wrong (wrong aspect ratio?). The output is fine, though.

I'm outta here. Do your work, geeks ;-)
[Galaxy S II Original Android Development] codeworkx:
@Zlodo

i would say: nice teamwork! ;-)

thanks for your help. we really need guys like you.
[Galaxy S II Original Android Development] Zlodo:
I'm too lazy to do that kind of stuff on a regular basis, but I'm glad I could help. Thanks for making CM9 happen in the first place :)
[Galaxy S II Original Android Development] D4rKn3sSyS:
Hello guys. Im having a issue while building from sources, maybe stupid for you, but well, not much used to build CM from sources (i'm more into app developing)

build/core/dynamic_binary.mk:112: atención: se imponen comandos para el objetivo «.so»
build/core/dynamic_binary.mk:95: atención: se ignoran las instrucciones viejas para el objetivo «.so»
build/core/shared_library.mk:54: atención: se imponen comandos para el objetivo «.so»
build/core/dynamic_binary.mk:112: atención: se ignoran las instrucciones viejas para el objetivo «.so»
find: «src»: No existe el archivo o el directorio
[B]build/core/base_rules.mk:166: *** platform/external/android-mock: MODULE.TARGET.JAVA_LIBRARIES.android-mock-runtimelib already defined by external/android-mock. Alto.[/B]

If you need translated to english just tell me.

Thanks

PS. Didnt post on discussion thread because it gets full of spam and my post will get lost surely
[Galaxy S II Original Android Development] alangrig:
After applying the camera patch, modding in media_profiles.xml doesn't take effect?!

<EncoderProfile quality="high" fileFormat="3gp" duration="30">

<Video codec="h264"

bitRate="20000000"

width="1920"

height="1080"

frameRate="30" />

Video recording bitrate still lower up to 9.5mbit at 1080p or 5.7mbit at 720p, despite changes in media profile.xml

Is video bitrate with latest patch being embedded in camera.apk?

In addition changed as well

VideoEditorCap maxInputFrameWidth="1920"

maxInputFrameHeight="1080" maxOutputFrameWidth="1920"

maxOutputFrameHeight="1080" maxPrefetchYUVFrames="5"/>

So now its possible in movie studio to export project in 1080p, but only from recorded 720p, exporting 1080p fails. Logcat will be uploaded later.
[Galaxy S II Original Android Development] espenfjo:
It seems like your checkout is missing something

Try to run a new repo sync.
[Galaxy S II Original Android Development] tsubus:
I've noticed that there is an issue when using adb from recovery (can't su, no root permissions). Where would I look in the source code to see what the issue is?

adb shell

shell@android:/ $ su
su
Segmentation fault