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.
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).
To program for the iPhone, you need an iPhone. That's because you have to compile the final version of the app on the iPhone hardware.
Do you also need an iPad when you program for the iPad? Or will an iPhone also do the job?
You do not need to have an iPhone to be able to compile your program for the device, and you do not need to have an iPad to compile your program for that device either. It's good to be able to test it on an actual device before you submit it, but it is not necessary. All compilation happens on the computer, not on the iPhone or iPad.
You should have one. Those of us who released iPad apps on iPad release day can certainly tell you that there are differences between the Simulator and the device. I had two minor but ugly errors which went out with our first release of Reiner Knizia's Money for the iPad, one of which had to do with different case comparison on the two devices. I would have never seen them if I didn't have a device to check.
I would imagine that for testing alone you would need an iPad. Although I've never developed on either one, basic quality control says that you really should test any app on the actual hardware it is intended to run on.
I'd say Yes, you need an iPad. Reasons, precise and real memory warnings, device wifi's real speed latency, 3g. And here's the tricky one: Some libs/features just don't work on the simulator but they work on the device and viceversa.
But I mean, you can always be googlish and search for these later cases I mention, and just be sure that you are doing things right. Otherwise, get yourself an iPad, you don't lose anything.
-edit: I didn't read the question correctly... the short answer: You don't need an iPad to compile the final .app file, but take my advice.
YES. (Unless you have no respect for your users and don't care about the quality of your app)
No. You don't even have to get a developer license from Apple. You can just download XCode and the official iOS4 SDK and develop the application in the simulator.
However, there's small caveat - the simulator does not always behave like the real device. So at some point you want to have a device to test your app on.
It would certainly help to have one, but not necessary at first. Get some experience programming for your iPhone, and once you feel ready, start working on something for the iPad. The simulator works great for most tasks. However, I wouldn't release any finished product to the app store unless it had been thoroughly tested on hardware.
There are cases where it is necessary to have hardware. For example, I was doing some testing involving dragging your finger across the screen. I needed to step through the debugger while doing this. Using the simulator was impossible, since I couldn't lift my mouse pointer from the iPad screen and interact with the debugger at the same time. Having hardware allowed me to interact with the device, while working in XCode at the same time.
Not having the target device for your software is a recipe for poor user experience. Touch interfaces cannot be accurately duplicated with a mouse. There are also very specific problems with relying on the iPad simulator:
1) The actual iPad has a slower processor than the desktop simulator. Stuff that looks fast in your simulator can be slow on an actual iPad
2) The iPad simulator is not fully correct, especially in simulating web browser experience. Real iPads have weird painting issues, CSS sanity differences, caching oddnesses, and then just more crashes than the simulator.
3) Orientation changes need to be performed on a real iPad! The simulator can just misleading. Ditto for network fetch latencies, which can affect the user experience significantly especially on a 3G link. If you don't have a real iPad you'll never notice that you need load masks, "waiting for content" watermarks etc.