8

I'm playing a Live RTSP stream from VLC on a PC to Android MediaPlayer class (both on same local network). It plays smoothly with no errors - the problem is that the decoded video on screen is between around 5 and 7 seconds behind live.

From debug and callbacks I can see that the live data is arriving on the device < 1s after starting mMediaPlayer.prepareAsync(). This is when the MediaPlayer class begins to work out what format the stream is with what dimensions etc. Then just before video is shown on screen (between 5 and 7 seconds later), onPrepared() is called where I call mMediaPlayer.start(). It looks like this start() plays the video that was originally captured from the start of the prepare stage.

I've tried seekTo(5000) both before and after start(), but it has no effect on the lag at all.

For a live video calling app, the setup delay of a few seconds is perfectly fine, but this lag once video is presented is unaccaptable to me.

public void surfaceCreated(SurfaceHolder holder)
{
   mMediaPlayer = new MediaPlayer();
   mMediaPlayer.setAudioStreamType(AudioManager.STREAM_MUSIC);
   mMediaPlayer.setOnInfoListener(this);
   mMediaPlayer.setOnErrorListener(this);
   mMediaPlayer.setOnVideoSizeChangedListener(this);
   mMediaPlayer.setOnBufferingUpdateListener(this);
   mMediaPlayer.setDataSource("rtsp://192.168.1.4:5544/test");
   mMediaPlayer.setDisplay(holder);
   mMediaPlayer.setScreenOnWhilePlaying(true);
   mMediaPlayer.setOnPreparedListener(this);
   mMediaPlayer.setOnCompletionListener(this);
   mMediaPlayer.prepareAsync();
   ...
public void onPrepared(MediaPlayer mediaplayer)
{
   mMediaPlayer.start();
...

Any ideas how I can reduce this lag, or seek to the end of what is buffered by MediaPlayer? My device is 3.1, minSdkVersion is 2.2.

EDIT:

I've found some high and low water-marks in AwesomePlayer.cpp (2s and 8s). As a quick test I have hacked the libstagefright.so to make these 0.1s and 1s. This however made no effect on the delay. My search continues...

barkside
  • 3,951
  • 4
  • 23
  • 32
  • The NDK v7 now has access to low level OpenMax AL media streaming APIs for when the source is an MPEG TS on 4.0. Has anyone had any experience with this - is the video lag improved? I read in the docs: "As OpenMAX AL is a native C API, non-Dalvik application threads which call OpenMAX AL have no Dalvik-related overhead such as garbage collection pauses. However, there is no additional performance benefit to the use of OpenMAX AL other than this. In particular, use of OpenMAX AL does not result in lower audio or video latency..." Oh well. – barkside Feb 03 '12 at 11:05
  • Would you mind giving an update on the progress you made on this? – Matt Mar 25 '13 at 12:19
  • 2
    In the end I used GStreamer (they have Android support now) which gives you a lot more control over these things... bit of a cop-out I know... – barkside Mar 25 '13 at 13:10
  • I'd say that is a pretty good solution given the lack of support for customization of buffering in Android API 17 and below. – Matt Mar 25 '13 at 17:13
  • could you explain how did you start VLC rtsp video stream? – Albert Chen Jan 02 '15 at 21:55

3 Answers3

1

I'm not giving a final answer, but let me share what I have by now.

  • I had a 5s latency issue playing locally on PC, from GStreamer to GStreamer. The latency was gone after adding the following parameters to pipelines:
    • on client - latency=0 parameter of rtspsrc;
    • on server - v4l2src's is-live=1 parameter and, of course, x264enc tune=zerolatency.

There is no way to control MediaPlayer/VideoView's codec/media source parameters. Neither in MediaCodec API, as far as I see.

So we need to go for GStreamer or ffmpeg.

Ease of use and portability are to be found out yet.

Victor Sergienko
  • 13,115
  • 3
  • 57
  • 91
0

I'm facing the same problem. One way to dsolve this is to rewrite the whole playback class in order to control what gets fed into the codec. But this would be the last (and painful) resort. I'm still looking around... sigh...

MikeC
  • 223
  • 1
  • 4
  • 15
0

I'm having exactly the same problem. At first I thought that it was not working, but I forgot my app opened and after a while the video showed up.

The funny thing is that if I use this video[1] which I found in a tutorial on VideoView, the lag is much smaller. I am thinking on installing Darwin Streaming server to check if it is a matter of VLC or another issue.

[1] rtsp://v5.cache1.c.youtube.com/CjYLENy73wIaLQnhycnrJQ8qmRMYESARFEIJbXYtZ29vZ2xlSARSBXdhdGNoYPj_hYjnq6uUTQw=/0/0/0/video.3gp

jlanza
  • 1,208
  • 3
  • 23
  • 43
  • In the AOSP source I can see high/low water-marks for data as well as time, so perhaps if the stream data-rate is large, the buffer will be filled to the high data water-mark sooner, therefore making the experienced lag shorter. This video you mention may have this high data-rate. – barkside Feb 02 '12 at 09:07