MediaPlayer can't load file from asset?

by arnouf » Fri, 22 May 2009 01:56:53 GMT


Sponsored Links
 Hi all,

I put in my assets project folder a 3GP file that I'm trying to load.
I tried to method
MediaPlayer mp = new MediaPlayer();
AssetFileDescriptor is = getAssets().openFd("video.3gp");
mp.setDataSource(is.getFileDescriptor());

and still using mp
mp.setDataSource("file:///android_assets/video.3gp");

My application is crashing with the following issue (I didn't find a
lot of help with group and Google search):
05-21 17:51:20.545: ERROR/PlayerDriver(542): Command
PLAYER_SET_DATA_SOURCE completed with an error or info
PVMFErrNotSupported
05-21 17:51:20.556: ERROR/MediaPlayer(1313): error (1, -4)

Somebody can help me?

Regards


--~--~---------~--~----~------------~-------~--~----~



Other Threads

1. OOT: Paging Sindhu.....?

Sori numpang jalum...
Ane lupa no.telpnya..
Mau minta no.resi pengiriman. 
Stikernya belum sampe juga :(

@yopiesuryadi
www.jeruknipis.com/forum

-- 
"Indonesian Android Community [id-android]" 

2. A slightly altered pattern for extending the life span of a broadcast receiver (Not entirely verified yet)

How would one go about making sure a broadcast receiver (triggered)
code can run for more than 10 secs (this is the limit when you start
seeing not responding warnings),

This has been much disccussed in this group and excellent suggestions
and even working code like "wakefulintentservice" (thanks to Mark
Murphy) is available now.

Some of the available mechanisms are

1. Use a static wake lock in the broadcast receiver and start a
service. Have the service spawn a thread. Pass a handler to the thread
so that the thread can terminate the service when it is done. (A
static variable is only way to communicate between independently
invoked service and the broadcast receiver)

2. The protocol above is formalized in the SDK in 1.5 with something
called an IntentService quite nicely except for the wake lock

3. Mark's WakefulIntentService updates the solution 2 with a partial wake lock

I have been tinkering with these ideas and have some early sample code
that further narrows the problem space to specifically a
broadcastreceiver that is intentionally for long running code.

Here is the usage pattern.

Step1. Code a broadcast receiver inheriting from an abstraction that
is called "ALongRunningBroadCastReceiver". Here is an example

public class TestLRBCR extends ALongRunningReceiver
{
        @Override
        public Class getLRSClass()
        {
                Utils.logThreadSignature();
                return TestLRBCRService.class;
        }
}

The "LRBCR" stands for Long Running Broad Cast Receiver. Only thing
the derived class needs to do is specify the classname of a delegated
long running service. In this case it is called "TestLRBCRService".

Step2: Service code: Here is code for that service. I have excluded
some spurious lines that deal with debugging etc.


public class TestLRBCRService extends ALongRunningBroadcastService
(extends from IntentService)
{
        //Required by IntentService
        public TestLRBCRService()
        {
                super("com.ai.android.service.TestLRBCRService");
        }
        
        /*
         * Perform long running operations in this method.
         * This is executed in the
         */
        @Override
        protected void handleBroadcastIntent(Intent broadcastIntent)
        {
                Utils.logThreadSignature();
                String message =
                        broadcastIntent.getStringExtra("message");
                Log.d(tag,message);
                               // Sleep for a few minutes here if you want,
                               // it will keep the device partially on
and honor the delay
        }
}

Clearly one has to define the broadcast receiver and the service class
in the manifest file.

Under the covers the abstract classes starting with "A...." will use
the wake lock and the intent service to make this work. The novelty i
have tried to accomplish is

1. Make the whole thing look like just a broad cast receiver and hide
the service as much as possible with only one method exposed

2. Pass along the broadcast intent all the way to the receiving
service method as if the service method is getting the broadcast
intent.

3. I have also taken a very slightly different approach to holding and
releasing the locks with an extra release from the "onDestroy" of the
service just in case (although unlikely) if the start and stop
services don't coincide due to exceptions or errors in code

I am hesitant and suspect that this may be a fishy thought.

Let me know if it is not the best of ideas...

Thanks
Satya

-- 

3. OOT : Tukeran Gtalk

4. Diffie hellman key exchange android and server.

5. Using a ListView and an Adapter: How to use notifyDataSetChanged()?

6. WebView.setEmbeddedTitleBar (public API or not?)

7. HTC Hero 1,6Jt Saja!!!