Instead of using your own RTP implementation, why are you not using OpenCore?
If you are OK with RTP on Java level you can port over the RTP implementation used in SipDroid. The quality is pretty good for PCM Voice. -- Roman Baumgaertner Sr. SW Engineer-OSDC ·T· · ·Mobile· stick together The views, opinions and statements in this email are those of the author solely in their individual capacity, and do not necessarily represent those of T-Mobile USA, Inc. On Aug 6, 4:03 pm, plun <[email protected]> wrote: > I'm also very interested in seeing if this is possible. > I tried following the method described at Mattakis, without success > (http://www.mattakis.com/blog/kisg/20090708/broadcasting-video-with- > android-without-writing-to-the-file-system). > > On Jul 31, 2:09 am, Robin Marx <[email protected]> wrote: > > > Hello, > > > For a research project we need to capturevideoon the HTC magic and > > transmit thisvideoover a network to other devices, both HTC magic's > > and desktop pc's (which have their own implementations of the > > codecs). > > > For the transmission over the network we are using some of our own > > native libraries, which have all compiled fine and work. These > > libraries work via the RTP (Real time transfer) protocol. This poses a > > significant problem because RTP expects detailed information about the > > contents of each packet (exact timestamp, sampling rate, which part of > > which frame is in each packet etc.) > > > So we tried the method described > > athttp://www.mattakis.com/blog/kisg/20090708/broadcasting-video-with-an.... > > This appears the only way to get the MediaRecorder to send it's data > > to our native application. > > > So we run a server-socket on the native side, send MediaRecorder > > output to a FileDescriptor of a javasocket. The native side does > > receive data. 2 problems however : > > > 1. Like said in the blogpost : header information etc. is not filled > > in, so if we write the data to file from the native-side, it's not > > playable. > > > 2. The socket we write to is TCP, so a stream implementation. So there > > is no clear way to know where each frame begins and ends (because the > > data comes in continuously). And that's the main problem : we can't > > package the data in good RTP packets for transmission! Nor can we get > > good information about the timing etc. > > > So we looked into OpenCore a little bit, hoping to be able to do it > > through JNI-interfaces ourselves (or maybe even directly with the > > native implementations from our native code). This has proven a > > daunting task, because so little documentation can be found on these > > things. > > > So the question is : > > Is it possible to get theencodedvideo(and audio) data with clear > > frame-separation and good timing-information for RTP transmission? > > > (It is not an option to use anything but RTP, as the research is > > partly about RTP possibilities) > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
