This is actually a post that belongs in this thread : http://groups.google.com/group/android-developers/browse_thread/thread/e677b894b4c502d9/5eb4d892c12a8393
But since it is closed I will open a new thread. If a moderator could add this post to the above thread and re-open it, that would be appreciated. As you can read in the other thread, no real solutions were given to the streaming of RTP video problem I posted about a year ago. Since then, I've been getting a lot of mails from people who are trying to do the same thing and I always have to give them the same answer. Tired of re-typing the same mail, I'm posting our experiences here for reference. I'm going to disappoint you from the start: we did NOT find a full solution to the problem. We were able to stream audio and video from the phone to a desktop pc and decode/play it there, but the other way around was impossible. Our project switched to a Windows XP mobile tablet pc. I'll explain what we did to stream to the PC. The method with the socket to send the data to native code worked perfectly. Then, in native code, we needed to buffer the data, extract h.263 frames, which we could then pack into RTP packets and send over the network. This works because android tries to save the video as an .mp4 file, which is basically just a container for unmodified h.263 data. Android writes almost all the mp4 data at the END of the file, so don't trouble yourself with that if you're constantly streaming the video. All you need to do is cut off the first few bytes of .mp4 data at the very beginning (can't remember the exact number, but it's always a fixed number of header bytes). After this, it's all just h.263 data. This is a well documented format which you can write a simple parser for yourself. All we did was buffer and parse the frames to retrieve the size in bytes of the current frame. If this amount of bytes was present in the buffer, we knew we had read a full frame and could send it in an RTP packet. (I have some of our code for parsing the h.263 data. You can contact me if you want this code. But attention! it won't be directly usable code as it is an excerpt from our framework and is just intended to give you the general idea and insight in how h.263 data can be interpreted). It should be clear that this is if you capture video ONLY. If you would capture audio and video in the same capturer, the h.263 data would be interjected with audio data in an undefined manner (unless google documented it somewhere, but this was not the case at the time we think). It is possible to capture audio seperately however and use the same logic as we did for the video stream. The big problem then will be to sync audio and video, especially if you want to use RTP for transmission. We did all this natively on android in C++ because we wanted to test our RTP library and network parameters. If you just want to send video to your pc, you can just parse the h.263 frames on your computer to feed to a decoder and don't bother yourself with putting everything in RTP packets on android. Then you can just use a TCP socket connected to the server PC and send all video data directly to it. However, this should only be used in research or personal project settings and is not fit for commercial or serious applications! This all is still a non-optimal method which will have some delay and processing overhead, so don't expect miracles. As for the receiving of video on the android, we simply couldn't get it working. Android can only play video FILES, so the only way to do this would be to write the received data to a file and fake android into playing it. And here is the big problem: we could ignore the .mp4 data for sending the data, but for playing a file... android really needs the data. And this means we would have to fake it, a very troublesome process. We didn't even finish our attempts at faking mp4 header data. There is a possibility to play video from a stream of RTSP which you should definitely look into if you don't need to control SIP or RTP data yourself but just want to playback video. I hope this was informative and if there are any more questions you can always contact me at my email address. Happy coding! -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
