I try to force a S5 to focus at Infinity using the following code:
myCamera.cancelAutoFocus();
parameters.setFocusMode(Camera.Parameters.FOCUS_MODE_INFINITY);
myCamera.setParameters(parameters);
before displaying the preview:
myCamera.setPreviewDisplay(myHolder);
myCamera.startPreview();
I control the setting with
parameters = myCamera.getParameters();
which yields "infinity" alright
but the camera still hunts for focus the same way it does in continuous-picture.
(the same code used with a Nexus 7 works fine).
Does anyone have already experienced such trouble with a S5?
Thank-you for any suggestion.
Yes, Samsung seems to have screwed up, and then users end up blaming unrelated app developers for their device's auto-focus problem. The Galaxy S5 is by far the biggest offender in my experience, but other recent Samsung models seem to do it too. It did not seem to be a problem on the older S3.
These somewhat recent Samsungs will report that they support infinity focus, and will accept that mode setting, but that's completely broken... It will just continually refocus while recording, making the resulting video downright irritating to watch and often unusable.
I have not found a fix for this, other than to just avoid using the infinity mode entirely, and instead using fixed mode (if supported), or attempting to fix the focus in auto mode. In my case, I made it a user option, which is turned off by default due to the sheer number of people using broken Samsungs.
Related
So i had been making video tutorials for my friends on how to program. On my old computer i had been all ways running simple screen recorder and it recorded fine. But recently i got a new computer. And so when i got a fresh install of arch linux on the box. I set up the environment with every thing i needed to make another video. When i downloaded simple screen recorder using yaourt, and started recording. I had recorded up to a two hour session with out knowing that it was glitching out. When i look at my computer i do not see the same issue as when the final product is done rendering. I think it might be a rendering error or i do not have the right codecs. After a hour or two searching on the web i could find no forum posts on the codec. I took in multiple things that could be wrong with it fps was my first choice but when i had recorded with 25 and even 50 fps it was still glitching out. The next idea i had was that i had the wrong codec H.264. But with searching i could find no solution to that one. Then i thought that i might have been encoding at to high of a speed (23). But still that proved me wrong. so now i am confused with how to get my answer.
Settings Screen shot:
Video Link:
https://www.youtube.com/watch?v=zfyIZiJCDa4
The glitches are often relate to the rendering backend of the window compositor you are using.
Solution 1 - Change the rendering backend of the window compositor
#thouliha reported having issues with compton. In my case I had glitches with openGL (2.0 & 3.1) and resolved the issue by switching to XRender for recording.
On KDE you easily change the rendering backend of the window compositor in the settings .
Solution 2 - Change the Tearing Prevention method
To keep using OpenGL, for example for better performance, you can also tweak the tearing prevention method.
In my case switching from Automatic to Never allowed me to record video with OpenGL compositor without glitches.
Solution 3 - Intel iGPU specific issues
Intel iGPU (Intel graphics) has some rendering issues with some CPUs.
You can check the Troubleshooting section of ArchLinux wiki to check those.
Example of features creating tearing or flickering related issues:
SNA
VSYNC
Panel Self Refresh (PSR)
Check also /etc/X11/xorg.conf.d/20-intel.conf if your system has put tweaks in here.
I'm not exactly sure what you mean by glitching out, especially since the video is down now, but I've found that the video is choppy when using compton, so I had to turn that off.
My app is streaming audio fine on all devices except Nexus 5. On Nexus 5, the MediaPlayer randomly stops playing. Not sure if the changes with respect to Loudness (http://developer.android.com/about/versions/android-4.4.html#Multimedia) in 4.4 has broken something.
Is anyone else noticing this issue? Seems to be happening to some users, but I'm unable to reproduce on my own Nexus 5.
UPDATE: So I was able to reproduce the issue on my Nexus 5. It seems to actually be happening near the end of the clip. With about 1 - 5 seconds left in the clip, the OnCompletionListener.onCompletion() method is called by MediaPlayer. This is only happening on the Nexus 5 and it's happening on some clips at random. I'm able to reproduce it almost 30% of the time. Note that, when the clip finishes early, if I try to go back and play the clip again it finishes playing the clip entirely the second time. I know Android 4.4 just got released, but hopefully someone out there can help! Thanks.
UPDATE: I've filed a bug against Android: https://code.google.com/p/android/issues/detail?id=62304
Alright, I've found the solution. I'm not sure if this is the issue you're all facing now, but it fixes mine. Basically, Android 4.4+ introduces many new power management features and one of them includes shutting the CPU down while the screen is off. Quote from Android docs:
Because the Android system tries to conserve battery while the device
is sleeping, the system tries to shut off any of the phone's features
that are not necessary, including the CPU and the WiFi hardware.
However, if your service is playing or streaming music, you want to
prevent the system from interfering with your playback.
Hence, without a CPU wake lock the MediaPlayer loses its ability to stream properly, causing it to stop playback before the clip is complete. The solution for this is simple: add a PARTIAL_WAKE_LOCK to the MediaPlayer. As documented on Android:
mMediaPlayer = new MediaPlayer();
// ... other initialization here ...
mMediaPlayer.setWakeMode(getApplicationContext(), PowerManager.PARTIAL_WAKE_LOCK);
I guess a bunch of us failed to see this in the docs. I don't remember seeing this, so maybe it was just added. Anyway, hopefully this fixes the issue for everyone!
Run into almost the same problem recently: MediaPlayer works perfectly on Android 4.3 and below, but fails to play the same videos on Android 4.4.
Decided to switch to vitamio library and now my app works on 4.4 as well. vitamio API is identical to the MediaPlayer's one, so the migration was quite easy.
But this solution still has some drawbacks:
You have to buy a license if you are not an individual developer
The app size will be increased ~11 megabytes
This problem is possible related to bug: http://code.google.com/p/android/issues/detail?id=63032
The problem associated with the above bug is fixed in 4.4.1/4.4.2. The change log entry that is suspected to be the issue has the following information:
https://android.googlesource.com/platform/frameworks/av/+/7fa0152
Restore NuPlayer error and EOS handling This was erroneously removed
by commit a73c954
I'm trying to port an android/iOS game to windows phone 8(cocos2dx v 2.2). I'm using the exact same code base that I've used for android and iOS. The game functions just fine, but I facing some major FPS drop. The game runs flawlessly at 60FPS in android and iOS, but I'm getting roughly about 35FPS on wp8. Has this got to do anything with differences in OpenGL and directX?
I doubt its got to do with the game's logic and calculations because when the game starts in windows phone, it starts with 60FPS on the main menu, which has got like 5 sprites. But as I add more sprites on the screen, say about 30 of them(average number of sprites when I'm IN the game) the FPS rapidly drops to 35-40 range. Note that there are no schedulers or update functions running at this point. I did the same test on Android, but the FPS didn't drop. Does the win8 port of cocos2dx suck?
Any help,comments or redirection to useful articles would be appreciated.
Thank you.
In case anyone runs into similar issue, I reduced the number of children in the scene and deployed the build in release mode. Gave a major boost to the FPS. Also, I had a bunch of float to string and int to string conversions happening in every frame inside the update function. That was eating away on the processing speed too.
Actually, the Cocos2dx port for WP8 is ok, but outdated. Cocos2d-x is now at 3.0 beta, but the WP8 was left at 2.0 alpha.
Anyway... in Cocos there are some recursive drawing functions which are very heavy on the CPU, and also, keep in mind that even though WP8 is supposed tu support arrays, lists, maps etc. they are very slow on WP8.
And since you came to this subject, Please let me know if you managed to successfully put cocos2d-x on an XAML+D3D Interop project. I am getting tons of crashes.
EDIT: Indeed, the recursive calls which process (draw or update) child "CCNode"s are very heavy on the device. However, after putting Cocos2d-x ver. 2.0alpha for WP8 into a XAML+D3D interop project, I found a whole lot of memory related issues. Apparently, after doing this (or just because I don't know how to properly configure my VS project and allow loose addressing), a lot of uninitialized pointers and data cause some memory overlaps, leading to major crashes.
This proves only that it was truely an alpha release :) Too bad no newer version of Cocos2d-x for Wp8 is available.
I recently I came across an error that I cannot understand. The game I'm developing using Cocos2D just freezes at a certain random point -- it gets a SIGSTOP -- and I cannot find the reason. What tool can I use (and how do I use it) to find out where the error occurs and what's causing it?
Jeremy's suggestion to stop in the debugger is a good one.
There's a really quick way to investigate a freeze (or any performance issue), especially when it's not easy to reproduce. You have to have a terminal handy (so you'll need to be running in the iOS simulator or on Mac OS X, not on an iOS device).
When the hang occurs pop over to a terminal and run:
sample YourProgramName
(If there are spaces in your program name wrap that in quotes like sample "My Awesome Game".) The output of sample is a log showing where your program is spending time, and if your program is actually hung, it will be pretty obvious which functions are stuck.
I disagree with Aaron Golden's answer above as running on a device is extremely useful in order to have a real-case scenario of where the app freezes. The simulator has more memory and does not reproduce the hardware of the device in an accurate way (for example, the frame rate is in certain cases lower).
"Obviously", you need to connect your device (with a developer profile) on Xcode and look at the console terminal to look for traces that user #AaronGolden suggested.
If those are not enough you might want to enable a general exception breakpoint in Xcode to capture more of the stacktrace messages.
When I started learning Cocos2D my app often frooze. This is a list of common causes:
I wasn't using sprite sheets and hence the frame rate was dropping drammatically
I was using too much memory (too many high-definition sprites. Have a look at TexturePacker and use pvr.ccz or pvr.gz format; it cuts memory allocation in half)
Use instruments to profile your app for memory warnings (for example, look at allocation instruments and look for memory warnings).
I'm a newbie developer who worked on Movist media player over the last months.
The project seems to be dead so I started to look at the code and try to understand how it behaves.
I have been able to add hardware decoding (with VDADecoder), fix all deprecated functions, plus other minor things and everything seems to work nicely on Snow Leopard.
When testing the app on OSX Lion, instead, I encounter a very annoying issue and I'm short of idea because I tried quite everything..
The video playback freezes for about 0.1 - 0.2 seconds always at the same instant during the playback. It seems to freeze just when the decoder reaches the end of file and when the remaining (already) decoded frames get displayed.
The issue appears with both hardware and software decoding and it's not related to the part of code that I have added.
Obviously, the same movie file plays smoothly on Snow Leopard (with both software and hardware decoding) and on Leopard (with software decoding) (hardware decoding isn't supported).
I tried to use Instruments to debug this issue but I don't know how to catch that instant. Sometimes Instruments records a lot of "sys enter trap" around that instant..is this a hint?
I tried to rebuild the project with Xcode 4 and SDK 10.7 and to fix all the warnings but the issue still persists.
Is there a way to debug this issue?
I don't know how to discover the bug...if there is any..
I hope you can help me.
Regards
Andrea
Just to let everyone know, I found what was causing the issue.
It was given by the Restorable feature of the movie window which was causing that periodical stuttering.