Decodificación del flujo de RTSP en directo: gran retraso de vídeo con MediaPlayer en Android

Estoy reproduciendo un flujo de RTSP en vivo de VLC en una PC a la clase MediaPlayer de Android (ambos en la misma red local). Se reproduce sin problemas sin errores – el problema es que el vídeo decodificado en la pantalla está entre alrededor de 5 y 7 segundos detrás de vivir.

De depuración y callbacks puedo ver que los datos en vivo están llegando en el dispositivo <1s después de iniciar mMediaPlayer.prepareAsync() . Esto es cuando la clase MediaPlayer comienza a calcular el formato de la secuencia con qué dimensiones, etc. Entonces justo antes de que el video se muestre en la pantalla (entre 5 y 7 segundos más tarde), onPrepared() se llama donde llamo mMediaPlayer.start() . Parece que este start() reproduce el video que fue capturado 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 retraso en absoluto.

Para una aplicación de videollamada en vivo, el retraso de configuración de unos segundos está perfectamente bien, pero este retraso una vez que se presenta el video es imposible 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 el final de lo que está protegido por MediaPlayer? Mi dispositivo es 3.1, minSdkVersion es 2.2.

EDITAR:

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

No estoy dando una respuesta final, pero déjame compartir lo que tengo ahora.

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

No hay manera de controlar los parámetros de fuente de medios / codec de MediaPlayer / VideoView . Ni en MediaCodec API, por lo que veo.

Así que tenemos que ir para GStreamer o ffmpeg.

El acceso NDK a los codecs acelerados por hardware fue introducido en Android 4.2 (JellyBean) (buscar "androidmedia"), y la gente tuvo cierto éxito al utilizarlo .
El acceso de códec acelerado por hardware NDK en FFMPEG se implementó en 2011, en FFMPEG 0.9

La facilidad de uso y la portabilidad se encuentran todavía.

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

Estoy teniendo exactamente el mismo problema. Al principio pensé que no funcionaba, pero me olvidé de mi aplicación abierta y después de un tiempo apareció el video.

Lo curioso es que si uso este video [1] que encontré en un tutorial de VideoView, el retraso es mucho menor. Estoy pensando en la instalación de Darwin Streaming servidor para comprobar si se trata de una cuestión de VLC u otro problema.

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