I am working on a mobile project that is built for iPad. The project includes an OSMF-based media player. However, the app is locking intermittently. I created a bare test application to try and narrow down the problem:
The app creates an instance of StrobeMediaPlayback. The player is fed an MP4 via HTTP (progressive). When the player reports complete (TimeEvent.COMPLETE dispatched by the StrobeMediaPlayback instances 'player' property), the player is fed another MP4 and begins playback ('configuration.src' is set followed by a call to 'loadMedia'). The player cycles through a list of four MP4s in this fashion, like a looping playlist. Eventually, the app will lock when beginning to load a new file. This sometimes happens immediately, sometimes it takes minutes, sometimes it takes half an hour, but it always happens.
If I disable 'autoplay' on the player, listen for the player to enter the ready state, and then insert a small delay before calling 'play', the app will run for hours without any problems. If I enable 'autoplay' or begin playback as soon as the player reports 'ready', the app will lock.
My original test was with my own OSMF-based player. I have not seen anyone else report anything similar to this, so I set it up with Strobe just to make sure I wasn't handling OSMF badly. The results have been identical.
I can find no useful information in the app's crash log. The app is simply shut down by iOS for becoming unresponsive. I have tried running the app hooked to the debugger, but nothing is reported.
Strobe Player 1.6.328
iPad 2 running iOS 5.0.1
Flash CS 5.5 patched with Air 3 (app reports Flash Player IOS 11,1,102,58 )
I can provide code for my main test class if more detail is required.
Can anyone offer any insight into this? Right now this project is stuck because the app is unstable.
please report an issue with the code snippet to https://bugs.adobe.com/jira/browse/FM .
SMP was not designed and certified against such usage - so the problem could be in yorur code, SMP, OSMF, AIR or undelying Flash. I would bet on the fact that the downloaded assets are not cleaned from the memory when you end the playback. I would suggest to try streaming assets for low-memory systems as the portable devices, not progressive.
Could you replicate the issue on AIR on desktop?
Strobe was used to verify that the problem was not with my OSMF implementation. Since the results were the same, I am more supsicious of OSMF itself or the underlying AIR framework than the player implementation. Either way, the information I've seen says that progressive download of h.264 video is supported on mobile devices with AIR. It would appear that this is not true in all cases.
The issue has not been observed on not occur on the desktop. It only occurs with StageVideo enabled playback with autoplay on.
In the actual product the videos play one at a time. Once the user has finished with a video, the player clears the references to the media. These are OSMF calls; the media assigned to the player is nulled. If this is not sufficient for garbage collection, then I am at a loss as to how to proceed. My test uses four videos that are roughly 1 MB. If there is a memory use problem, then it would appear something is broken in AIR or OSMF.
I want to be sure I report this correctly. The code involved is more than a snippet, it's a media player designed to be embedded in an app. Do I need to include the complete implementation or will a description be sufficient?
Ideally a snippet replicating the issue is the best thing to attach to a bug report. If not (and the code is secret), a description would be enough - this will allow us to make a simple app to replicate it, when we start investigating the bug.
I would say that it's not an OSMF bug, but an AIR issue on that device.
I have reported the issue in the Strobe project in the bug tracker as suggested. If it is an AIR issue, should I report it elsewhere or will it be transferred internally? I do have a workaround I can put in place until AIR and the development tools are updated, so my project can continue at least.