This is (or will be come June) my first experience with an android set. Now I've read that the codec support in Sensation is quite poor but I'm wondering if that support could be extended to include e.g. .mkv playback now that Sensation will (hopefully) be unlocked.
first: welcome to the android world
second: http://forum.xda-developers.com/showthread.php?t=1097503
Thanks! So the codec support depends on the media player like in PC OSs.
I'm also wondering if there's any possible "fix" for the quality of the photos taken with Sensation's camera. The photos I've seen aren't too bad but someone mentioned too high level of compression of the file which creates artifacts. Are there apps for the camera that will lower the compression level? The ones I've looked at on Android Market don't mention anything about compression. Or maybe it's a hardware limitation.
Welcome to android as well.
To be honest I am pretty new myself. The sensation when purchased, will be my first android smartphone. Had an Archos tablet for a few weeks before lending it to my sister 6 months ago lol...
Regarding the camera, I am not certain if we are talking about the same thing but they do seem similar. In the engadget review, they mentioned 'artifacts' where isolated areas of a picture were randomly soften or blurred. This is most likely due to software/settings that are processing the raw image before saving as pictures/files. With the recent HTC bootloader unlocking announcement, we should be able to see custom ROMs or even just single solution, fixes, tweaks, updates or whatever you want to call them to address issues like this. Or of course HTC can also fix the issue themselves.
Here is a link to the review if you need it
http://www.engadget.com/2011/05/27/htc-sensation-review/
if you are looking for the camera portion scroll down until you see the picture of the daisy? (sorry know very little about flowers)
apex84 said:
Thanks! So the codec support depends on the media player like in PC OSs.
I'm also wondering if there's any possible "fix" for the quality of the photos taken with Sensation's camera. The photos I've seen aren't too bad but someone mentioned too high level of compression of the file which creates artifacts. Are there apps for the camera that will lower the compression level? The ones I've looked at on Android Market don't mention anything about compression. Or maybe it's a hardware limitation.
Click to expand...
Click to collapse
This first post from me is going to be short. I welcome additional thoughts, of course. Sorry if this isn't the best place to drop this, but it's not a question and it's not anything in development!
First, an observation: the problem with 720p in CM10 is not bright light, it's the camera's ability to adapt to bright light from low light. In other words, the problem seems to be related to the light sensor. Although this is not completely new, what I noticed from playing around with LGCamera is that if I turn UP the video bitrate, the flickering is not as sever. The flickering will stop and stabilize when filming in consistent light. Any change in light quality will produce more sticking. This makes sense since 720p requires finer adjustments to light and dark than 420p. The other part of the equation is the h264 encoder. I'm guessing that certain values in the light sensor need to match up with the h264 encoder...
Second, I was playing around with these settings today: http://forum.xda-developers.com/showpost.php?p=17791551&postcount=20 I haven't had enough time to verify what makes a difference and what doesn't. I believe that some settings have helped a bit. Also, I felt that changing the ISO to 800 in camera and then switching to video improved the video, but that could be totally imagined! Essentially, what we need is ISO800 for the vidcam... I think!
Suggested fix that was here didn't work. I'm editing to see if I can correct the "Invalid User ID" error I keep getting on my XDA app. Started right after I went to correct this message.
if you think you have found a fix i'd suggest bringing it to the developer's attention, such as indeed posting this in the official thread.
Also your second post got chopped off lol
threi_ said:
if you think you have found a fix i'd suggest bringing it to the developer's attention, such as indeed posting this in the official thread.
Also your second post got chopped off lol
Click to expand...
Click to collapse
I'm just messing around right now. I don't think I've found a fix. A few things I've found: I can't find a way, using the included camera, to film above 25 fps. It doesn't matter what the settings are in media_profiles.xml, 25 is the cap. The cap should be a little above 30. I also can't force the camera to film above a bit rate of 6 Mbits/sec. I averaged around 8 Mbits on the stock camera and 10 in LG camera on GB. These settings will affect light responsiveness! Perhaps the oddest thing I've noticed is that the recording streams are inverted in JB. Everything I've filmed in GB has audio in stream 1 and video in stream 2. JB's streams are the other way around. EDIT: In fact, in GB 480p recordings use Stream 1 (or 0, depending on your player) for video and stream 2 for audio, but 720p recordings use Stream 1 for audio and Stream 2 for video. So, perhaps it's worth looking into the ways in which 720p recording is being "sent" to the codec.
In the process of sorting these things out, it would help if we could find out what the AVC h263 and MPEG4 profiles and levels were in GB. I'm not completely convinced that they are configured optimally for our phone.
[To Forum Mod: Is it possible to move this thread elsewhere? Possibly the Q&A section?]
I've spent more time on this than I intended today, so this will be brief(ish). I don't know if I've found a fix, but I may have discovered a good lead. This is definitely for people who can put together and test out kernel changes faster and more accurately than I can! The other day I thought I'd found something of use, a v4l2 driver modification for Crespo. I sent my findings over to Scotthartbti. The modification may still be of use, but there was an unanswered question: why is vidioc_dqbuf unable to to clear the buffer queue? If it's the preview screen size, the fix I discovered wouldn't repair everything. SO, when I read this morning that the kernel is actually based on a Rogers ROM with limited capabilities, I decided to run another diff on the JB kernel and the GB kernel from Samsung. What I discovered was that certain drivers s3c_bc.c and s3c_bc.h are absent from the JB kernel. These two files (?) contain information that sets screen and buffer size that I couldn't find replicated anywhere in the JB kernel. I don't think it's not there... so, in the process of trying to find out why these files might not be in the JB kernel, I discovered something better: the android exynos 3.4 Git. And surprise surprise! What is it that devs are fixing over there? Quite a few issues to do with s3c buffer size, particularly in s3c-fb, and the problem of the system ignoring preview frame size!
I suspect that some lingering bugs are being addressed here: https://android.googlesource.com/kernel/exynos.git/+/android-exynos-3.4
keep it up.
Thanks for working at this. I just learned how to pull a logcat and I nabbed one while barcode scanner was on. I'm running CM10 now and I ran CM9 until July. I wish I could help, but alas I am merely a padawan.
Thanks, reynaim. Yours looks pretty much like mine. It's useful to have that confirmation!
So, I've been working on this for awhile now, spending much more time than I ever thought I would. I'm not a developer. I taught myself html, css, and php and it looks to be following a similar route with c++ and python! I've learned a fair bit about how our phone works and I have some ideas about the problems with our camera. I'll list what I can here:
1. Google updated their camera code several revisions ago, but it appears Samsung either relied on aging code or has not released the actual code for the camera hal. Several commands that bind the driver layer to software are not up to date in our camera hal and may be part of the cause of the flickering. The way the camera works is that it calls up a preview, then dumps that information before it starts recording. I suspect that the camera is not clearing the buffer queue at that moment as it should. I am attempting to rewrite this portion of the driver, but it's laborious.
2. Let's be clear about what the problems actually are: Flicker in any transition of light conditions. I can get 720p to work in bright light if there are no shadows. The light sensor is not working with the camera correctly. Actually, the problem is the framerate. At the moment, the 720p stream is going through the wrong channel, as if it is running on a PAL device. Hence, not only is the datastream throttled, but the framerate is wrong. I tinkered a bit with the light sensor drivers - changed a few values here and there - but I haven't noticed a difference.
To note here: PAL = 25 fps, NTSC =30fps. Also, PAL = 50Hz, NTSC = 60 Hz. The Infuse may use a mixed mode that runs 30fps and 50Hz.
What you will notice as a user in addition to the flicker and stuck frames is that:
The video stream is stream 1. It should be #2 (you can check this most reliably in VLC on your computer or MX Player on your phone - VLC refers to the streams as 0 and 1).
FPS, despite media_profiles.xml demanding otherwise, will not rise above 25 and may drop to around 15.
Bitrate won't rise above 6Mbits/sec (interestingly, Android sdk has the bitrate capped at 8Mbits/sec). GB would ordinarily record at 10 - 11 Mbits/sec (there is a way to up the bitrate in JB, but it doesn't improve vid quality).
3. Some minor irritations can be corrected by adding the firmware packages back into the system folder. Add a directory called "firmware" to your system folder (so it should look like /system/firmware/), give it the permissions 754 (RWX,R-X,R-X), and add RS_M5LS_OI.bin, RS_M5LS_SI.bin, RS_M5LS_TB.bin (which you may find in an old GB backup). Give those the permissions RWX, R,R (or R-X, R-X for the last two - I'm not sure which is better!). Reboot. This gets rid of that odd lag you've probably noticed when you open up 3rd party cameras and they search for storage and sometimes crash as a result.
4. I don't think - I could be wrong! - that the problem is actually in fimc. Fimc is behaving normally. There are some curiosities in the current camera hal that fimc doesn't like.
5. In fact, it seems the camera hal was not written for an 8MP camera. Why doesn't Samsung release the camera hal? Does anyone know this? My best lead came when I bricked my phone and decided to take a couple of video logcats so I could at least pinch a few values and processes.
Its seems very long since update on this thread
Whizzpopper said:
Thanks, reynaim. Yours looks pretty much like mine. It's useful to have that confirmation!
So, I've been working on this for awhile now, spending much more time than I ever thought I would. I'm not a developer. I taught myself html, css, and php and it looks to be following a similar route with c++ and python! I've learned a fair bit about how our phone works and I have some ideas about the problems with our camera. I'll list what I can here:
1. Google updated their camera code several revisions ago, but it appears Samsung either relied on aging code or has not released the actual code for the camera hal. Several commands that bind the driver layer to software are not up to date in our camera hal and may be part of the cause of the flickering. The way the camera works is that it calls up a preview, then dumps that information before it starts recording. I suspect that the camera is not clearing the buffer queue at that moment as it should. I am attempting to rewrite this portion of the driver, but it's laborious.
2. Let's be clear about what the problems actually are: Flicker in any transition of light conditions. I can get 720p to work in bright light if there are no shadows. The light sensor is not working with the camera correctly. Actually, the problem is the framerate. At the moment, the 720p stream is going through the wrong channel, as if it is running on a PAL device. Hence, not only is the datastream throttled, but the framerate is wrong. I tinkered a bit with the light sensor drivers - changed a few values here and there - but I haven't noticed a difference.
To note here: PAL = 25 fps, NTSC =30fps. Also, PAL = 50Hz, NTSC = 60 Hz. The Infuse may use a mixed mode that runs 30fps and 50Hz.
What you will notice as a user in addition to the flicker and stuck frames is that:
The video stream is stream 1. It should be #2 (you can check this most reliably in VLC on your computer or MX Player on your phone - VLC refers to the streams as 0 and 1).
FPS, despite media_profiles.xml demanding otherwise, will not rise above 25 and may drop to around 15.
Bitrate won't rise above 6Mbits/sec (interestingly, Android sdk has the bitrate capped at 8Mbits/sec). GB would ordinarily record at 10 - 11 Mbits/sec (there is a way to up the bitrate in JB, but it doesn't improve vid quality).
3. Some minor irritations can be corrected by adding the firmware packages back into the system folder. Add a directory called "firmware" to your system folder (so it should look like /system/firmware/), give it the permissions 754 (RWX,R-X,R-X), and add RS_M5LS_OI.bin, RS_M5LS_SI.bin, RS_M5LS_TB.bin (which you may find in an old GB backup). Give those the permissions RWX, R,R (or R-X, R-X for the last two - I'm not sure which is better!). Reboot. This gets rid of that odd lag you've probably noticed when you open up 3rd party cameras and they search for storage and sometimes crash as a result.
4. I don't think - I could be wrong! - that the problem is actually in fimc. Fimc is behaving normally. There are some curiosities in the current camera hal that fimc doesn't like.
5. In fact, it seems the camera hal was not written for an 8MP camera. Why doesn't Samsung release the camera hal? Does anyone know this? My best lead came when I bricked my phone and decided to take a couple of video logcats so I could at least pinch a few values and processes.
Click to expand...
Click to collapse
Hi @Whizzpopper,
I was searching on Google for infuse 4g 720p recording on JB custom ROMs and found your thread,
it seems you had been gone throught very deep on this.
Have you found anything that help us on resolving this issue afterwards ?
yogi.306 said:
Hi @Whizzpopper,
I was searching on Google for infuse 4g 720p recording on JB custom ROMs and found your thread,
it seems you had been gone throught very deep on this.
Have you found anything that help us on resolving this issue afterwards ?
Click to expand...
Click to collapse
http://forum.xda-developers.com/showthread.php?p=38355903
Sent from my Galaxy Nexus using xda premium
yogi.306 said:
Hi @Whizzpopper,
I was searching on Google for infuse 4g 720p recording on JB custom ROMs and found your thread,
it seems you had been gone throught very deep on this.
Have you found anything that help us on resolving this issue afterwards ?
Click to expand...
Click to collapse
Indeed, I did leave the Infuse. There are so many variables, it's hard to say. The problem could be in the codec or in the settings used to interact with the codec (the media_profiles.xml or media_codecs.xml) or it could be in the kernel as Scott Hart used to suspect (don't know what he thinks now!). As you know, Samsung did not provide an honest release of the source for the Infuse.
Sorry I couldn't be of more help!
Thanks
Whizzpopper said:
Indeed, I did leave the Infuse. There are so many variables, it's hard to say. The problem could be in the codec or in the settings used to interact with the codec (the media_profiles.xml or media_codecs.xml) or it could be in the kernel as Scott Hart used to suspect (don't know what he thinks now!). As you know, Samsung did not provide an honest release of the source for the Infuse.
Sorry I couldn't be of more help!
Click to expand...
Click to collapse
Thank you for your updates,
Now Scott made a lot of improvement and fixed all most all the bugs for the kernel we are using in infuse 4g,
the only 720p recording and HDMi are not resolved yet, and i guess its not possible due to samasung not provided the source.
Thanks for your efforts on infuse.
Hi Folks,
I got an mxiii 4k / k200c / 2g / 8g / arm-A9 / mali-450MP box that works rather well for moving around the box (very speedy) and works perfectly for streaming 1080p content over LAN with Kodi but for some reason, some apps struggle with high quality video. It's most apparent with the DirecTV app but it also happens with Youtube (although much less). It starts playback, works fine but then the video starts slowing down as if the CPU or GPU were overwhelmed. This condition lasts for 3-5 seconds and then it goes back to normal until it happens again a few seconds later. It can also manifest itself as lost frames with random skips.
Anything I can do to improve the performance?
Thanks
Sounds to me like a caching problem, but perhaps it's the codec
rhtizzy said:
Sounds to me like a caching problem, but perhaps it's the codec
Click to expand...
Click to collapse
Might be, it doesn't appear to happen with all videos. Any way to overclock de GPU, see if that helps?
I believe so, there are a number of apps in the playstore I once used but you'll have to search if they still exist, look for sysinfo apps
Sent from my Nexus 7 using Tapatalk
Yo fellas, its your"rooting enthusiast SenpaiYank (lmao rooting enthusiast, as if such a thing exists)
Well, as you know, our device has a quite outdated and not so beefy (at all) SoC, the snapdragon 625. While its CPU is not tremendously ridiculously bad, the GPU quite is. This is not a prolem to people who don't care about games but a very prominent one on the other side.
With the help of this trick, tweak, whatever you decide to call it, you'll practically be able to play any game out there that you're not able to or play that same game at a higher setting than you would. The trick consists basically on lowering the screen resolution through a script, trading some of the visual quality for a noticeable night day performance boost. It's a common trick that works on other devices too and I've yet to find a game that had problems with it.
I'm using "profile" scripts to achieve it so you can change it on the go. I feel that way is the most ergonomic and quick one. Just run each script with root permissions according to your need. I recommend FX file explorer. Wanna play a graphically intensive game? Switch to gaming profile. Wanna do something else besides gaming? Switch to the default one.
As I side note, the trick can be done on unrooted users too but you'll need a computer and you'll have to apply the gaming profile permanently (unless you're willing to repeat the procedure whenever you want to go back to default). I can talk about it if you guys get interested on it.
Enough blah blah, how do I do it ?1st - Grab both of them (default.sh and gaming.sh)
2nd - Install (in case you don't have it), open and type this on the Terminal Emulator app:
Code:
su
To attain root access (not sure if needed but, just in case)
Code:
wm density
To get your current screen density value at 1080p (override density field).
Lets imagine you got 432.
3rd - Choose and calculate a new resolution for your gaming profile
So now lets ge to the actual work. Our device native resolution is 1080p (1920x1080) and we want to lower that.
I lower it to 810p (not a standard lmao) which is 75% of 1080p (1440x810) as it gives me agood balance between visual quality and performance. You can go even lower to something like 50% if you're ambituous about performance. At 810p I can expect a minimum of 25% performance uplift (not FPS).
So, to get your gaming profile resolution DPI, you multiply the relative percentage of it by the default profile resolution DPI.
Code:
[COLOR="darkred"]432[/COLOR] * [COLOR="RoyalBlue"]0.75[/COLOR] = [COLOR="Blue"]324[/COLOR]
This value will be your gaming resolution DPI a.k.a. the resolution from your gaming mode script.
4th - Edit default.sh and gaming.sh, apply the new values and save the files somewhere.
default.sh script should contain the values of your default resolution, in this case, 1920x1080 and 432. Size for resolution and density for DPI.
gaming.sh script should contain the values of your gaming profile resolution, in this case, 1440x810 and 324.
VOILÁ
To make the process much much easier and quicker, I use FX file explorer and its shortcut feature so I can switch between both profiles from my home screen pretty easily. Whenever I'm not playing a demanding game Is stick to the default mode, whenever I'm playing a graphically intensive game, I switch to the gaming mode and enjoy the improvement.
Cool, cool. So, is there an actual improvement in performance or is this just one of these so called placebo tricks ?It's definately not placebo and probably the most effective way around of increasing gaming performance!
I've tried to record a test with and without the trick (and failed, it doesn't look as effective in the video but I'll leave it here anyway). Take it with not 2 but 3 grains of salt due to all the uncontrallable factors that involved the scene, the actual gain in practical use is much more noticeable. The benchmark takes place in the super duper hot (pun intended) looking and intensive game, Shadowgun Legends.
On the first video, the device is running the Extreme Kernel, without the tweak, along a CPU cap of 2.5Ghz and a GPU cap of 855Mhz (or something around that). I didn't increase it further to prevent the device from overheating (which it already practically was) and because at a higher GPU clock, I would get arctifacts (my device does not support the 922Mhz frequency).
http://sendvid.com/zi9l8q44
On the second video, the device is running a beta batch of the velocity kernel, with the tweak, along a CPU cap of 1.9Ghz and GPU cap of 672Mhz. I ran the device at a lower speed so you can see how useful the improvement can also be.
http://sendvid.com/fqum12jw
I ran the game at the high graphical setting (30 FPS max) on one of its most intesive scenarios and were at very high ambient temperatures (30C) so again, take the videos with a grain of salt. Used an external gamepad to play and used Scrcpy to record the screen (through wifi so, the quality and framerate from the recording is considerably worse than the actual one). You should also remember the 5-6 FPS strain of capturing the screen.
I also used game bench to monitor the framerate (top right corner) where the last 1 minute of each benchmark were with the screen capturing off. Once again, sorry for the bad quality of the recordings, I'll leave a screenshot of the game bench results.
Not willing to write a outro so, yeah, basically thats it
Here's another sample video, of the same game, this time at medium settings. Along the very noticeable smoother gameplay you can also notice how the GPU load goes down from 95-100 to 70-80 and it becomes less of the bottleneck on the scenario. With the gaming profile could I could actually remove the 30 fps cap and run the game at +30.
Before:
https://photos.app.goo.gl/hwPg9KCwc6yLyt919
After:
https://photos.app.goo.gl/zDm4wkTHuAjQ7PA5A