First of all, we have no idea whatsoever on how to access the opencore functionality from our native code (or from java). We found a lot of posts from people saying they are using the encoders/decoders directly, or trying to add extra format-support etc. but nowhere do we find documentation on even the most basic things for using the native opencore API. If you could tell us how to directly access the encoders for example, that would take us a LONG way already.
As for RTP we really need to be in control of what is in the packages and how they are sent. Part of the research is working with a proxy that'll filter certain packets based on the available bandwidth and other resources of the network, so we really want full control over the RTP functionality on all ends. This means other RTP implementations are out of the question for us. We have been making some progress though. At the moment we are able to stream speex-encoded audio to the device, decode it (this step is very slow on emulator, but fast enough on the device itself) and play it as a .wav file (putting a dummy wav-header before the actual data seems to work just fine). We use the methode described here for good buffered playback from socket : http://blog.pocketjourney.com/2008/04/04/tutorial-custom-media-streaming-for-androids-mediaplayer/ (so the inputstream is not from an URL but from our native socket and we don't play .mp3 but .wav). As for video we can now transmit from the device to the desktop using the ParcelFileDescriptor-method. Native code on the device wraps the data in rtp-videopackets. On the desktop we buffer the packets and parse the h.263 headers until a full frame has arrived and then show it (the first 32 bytes android writes are the 3gpp header, just ignore it, the h.263 frames start right after that without .3gpp things in the videodata). While this gives us live video-feed (with minor delay) it is far from optimal for our research (no correct timing information in the rtp-packets for instance, making lipsync difficult etc.). We expect that sending audio wouldn't be that different from sending video, but for the moment we don't have a working amr-decoder on the desktop so we can't test it yet. Receiving video is going to be the hard one with these methods. For audio we can use the simple .wav format, but .3gpp is considerably more complicated and we think it's almost impossible to replicate for a live stream such as ours (if you can, please prove us wrong. Our main concern at the moment is the stsz-atom with the timing info). I hope this can help some others working on the same problem, but these solutions are NOT optimal. If anyone can tell me how to use the opencore functionality we will probably be able to find much better methods and share them. Thanks in advance and thanks to those who replied. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
