Hello,
On May 16, 12:52 am, inon <
ini2...@gmail.com> wrote:
> Hi,
> I am working on an application that streams video between android
> devices using SIP/RTP.
> since android's media player does not support RTP streams directly I
> have come up with a solution
> to run an RTSP server on the client and wrap the RTP stream with RTSP
> stream, then set the media player's data source to
> that RTSP server (i.e, rtsp://localhost:5544/video.3gpp).
This is interesting. Are you streaming video from the camera to a
3gpp file, that you are then streaming via SIP/RTP?
If so, is this on a dual-camera device, or are you using the primary
camera.
If so, how are you dealing with the failure of most primary camera
hardware on Android to deliver a streamable video stream?
Indeed, it is possible that this is the source of the problem, if you
have the camera capture to SDcard, say, and then try to play that
stream live, it simply will not work on devices using the Qualcomm msm
chipset (most phones I have seen), because the 3gp file will be
missing the header (first 24 bytes all zero), and then the MDAT box
follows, but without the trak info boxes, which don't get written
until the stream is closed.
You can verify if this is the problem by streaming a pre-recorded 3gpp
file, instead of streaming one while it is still recording. If that
works, then you have probably hit this problem.
It is possible to re-container the MDAT box containing the raw H.263
stream in a friendlier format (AVI is probably the best if you can
play it on the phone), but if you are running at <29.97fps (H.263
native frame rate) you will have trouble because the trak info boxes
are needed to give the frame presentation times.
We currently have a hack solution for this, using a patched ffmpeg to
re-container the raw H.263 video, which is far from ideal.
We are also looking at better solutions, such as inserting dummy
frames to get the frame rate back to 29.97fps to solve the re-timing
problem and get rid of the need for ffmpeg.
> The problem:
> when the RTSP server runs on a different device than the media
> player's device, everything works great, BUT
> if the RTSP server runs on the same device (localhost) than after
> media player do RTSP OPTIONS and DESCRIBE it fails.
> that is, after DESCRIBE response (the same response that is returned
> when it works on 2 devices) I get the following
> error in logcat:
>
> 05-15 15:44:26.374: WARN/MediaPlayer(4243): info/warning (1, 26)
> 05-15 15:44:26.374: INFO/MediaPlayer(4243): Info (1,26)
> 05-15 15:44:26.374: ERROR/PlayerDriver(121): Command PLAYER_INIT
> completed with an error or info PVMFFailure
> 05-15 15:44:26.374: ERROR/MediaPlayer(4243): error (1, -1)
> 05-15 15:44:26.384: ERROR/MediaPlayer(4243): Error (1,-1)
> 05-15 15:44:26.384: DEBUG/VideoView(4243): Error: 1,-1
>
> I am really clueless on how to solve this one, so any help would be
> great
Have you tried changing the address on loopback that you are using
from 127.0.0.1 to something else in the
127.0.0.0/8 range, as there
may be some code that does not well tolerate the use of localhost
specifically.
Also, if you try to use loopback while there is no data connection,
the phone may mistakenly not realise that it can still use loopback.
We (Serval Project) encountered this problem while trying to point
SIPDroid at an asterisk instance running on localhost on the phone.
We only needed to patch a few lines in the end, but it was frustrating
in the meantime.
Paul.
> Thanks