Descodificación de transmisión RTSP en vivo: gran retraso de video usando MediaPlayer en Android

Question

Estoy reproduciendo una transmisión RTSP en vivo desde VLC en una PC a la clase MediaPlayer de Android (ambas en la misma red local). Funciona sin problemas y sin errores: el problema es que el video decodificado en pantalla tiene entre 5 y 7 segundos de retraso.

De depuración y devoluciones de llamada, puedo ver que los datos en vivo están llegando en el dispositivo < 1s después de iniciar mMediaPlayer.prepareAsync(). Aquí es cuando la clase MediaPlayer comienza a determinar qué formato tiene la secuencia con qué dimensiones, etc. Luego, justo antes de que se muestre el video en la pantalla (entre 5 y 7 segundos más tarde), se llama al onPrepared() donde llamo al mMediaPlayer.start(). Parece que start() reproduce el video que se capturó originalmente desde el inicio de la etapa de preparación.

He intentado seekTo(5000) antes y después de start(), pero no tiene ningún efecto en el desfase.

Para una aplicación de videollamadas en vivo, el retraso de configuración de unos pocos segundos está perfectamente bien, pero este video lag una vez que se presenta es inaccesible para mí.

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(); 
... 

Alguna idea de cómo puedo reducir este retraso, o buscar hasta el final de lo que está amortiguada por MediaPlayer? Mi dispositivo es 3.1, minSdkVersion es 2.2.

EDIT:

he encontrado algunas altas y bajas marcas de agua en AwesomePlayer.cpp (2s y 8s). Como una prueba rápida, he pirateado el libstagefright.so para hacer estos 0.1s y 1s. Sin embargo, esto no tuvo efecto en el retraso. Mi búsqueda continúa ...

Answer 1

Estoy enfrentando el mismo problema. Una forma de resolver esto es volver a escribir toda la clase de reproducción para controlar qué se alimenta en el códec. Pero este sería el último (y doloroso) resort. Todavía estoy mirando alrededor ... suspiro ...

Answer 2

Estoy teniendo exactamente el mismo problema. Al principio pensé que no estaba funcionando, pero olvidé que mi aplicación se abrió y después de un rato apareció el video.

Lo curioso es que si utilizo este video [1] que encontré en un tutorial en VideoView, el desfase es mucho menor. Estoy pensando en instalar el servidor de Darwin Streaming para comprobar si se trata de VLC u otro problema.

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

Answer 3

que no estoy dando una respuesta final, pero permítanme compartir lo que tengo ahora.

• Tuve un problema de latencia de 5s localmente en PC, de GStreamer a GStreamer. La latencia desapareció después de agregar los siguientes parámetros a las tuberías:
  • en el cliente - latency=0 parámetro de rtspsrc;
  • en el servidor - is-live=1 parámetro y, por supuesto, x264enc tune=zerolatency.

No hay manera de controlar MediaPlayer/VideoView 's parámetros de la fuente códec/medios de comunicación. Ni en MediaCodec API, por lo que veo.

Así que tenemos que ir a GStreamer o ffmpeg.

• acceso a NDK codecs acelerados por hardware was introduced in Android 4.2 (JellyBean) (busque "androidmedia"), y people had some success utilizing it.
• NDK acceso códec acelerado por hardware en FFMPEG se llevó a cabo en 2011, in FFMPEG 0.9

Facilidad de uso y portabilidad han de ser descubierto todavía.