Sto riproducendo un flusso RTSP live da VLC su PC a classe MediaPlayer Android (entrambi sulla stessa rete locale). Funziona senza intoppi e senza errori - il problema è che il video decodificato sullo schermo è tra circa 5 e 7 secondi dietro live.Decodifica streaming live RTSP: video lag di grandi dimensioni con MediaPlayer su Android
Da debug e callback È possibile vedere che i dati in tempo reale stanno arrivando sul dispositivo < dopo l'avvio mMediaPlayer.prepareAsync(). Questo è quando la classe MediaPlayer inizia a calcolare il formato del flusso con le dimensioni ecc. Quindi, appena prima che il video venga visualizzato sullo schermo (tra 5 e 7 secondi dopo), viene chiamato onPrepared() dove chiamo mMediaPlayer.start(). Sembra che questo start() riproduca il video che è stato originariamente catturato dall'inizio della fase di preparazione.
Ho provato seekTo(5000) sia prima che dopo start(), ma non ha alcun effetto sul ritardo.
Per un'app di videochiamata dal vivo, il ritardo di installazione di alcuni secondi è perfettamente soddisfacente, ma per me questo ritardo al momento della presentazione del video non è accattivante.
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();
...
Tutte le idee come posso ridurre questo ritardo, o di cercare fino alla fine di ciò che viene tamponato da MediaPlayer? Il mio dispositivo è 3.1, minSdkVersion è 2.2.
EDIT:
ho trovato un pò d'acqua-marchi di alta e bassa in AwesomePlayer.cpp (2s e 8s). Come test rapido ho hackerato il libstagefright.so per fare questi 0.1s e 1s. Ciò tuttavia non ha avuto alcun effetto sul ritardo. La mia ricerca continua ...
L'NDK v7 ora ha accesso alle API di streaming multimediale OpenMax AL di basso livello per quando la sorgente è un MPEG TS su 4.0. Qualcuno ha avuto esperienza con questo - il ritardo del video è migliorato? Ho letto nei documenti: "Dato che OpenMAX AL è un'API C nativa, i thread di applicazioni non-Dalvik che chiamano OpenMAX AL non hanno un overhead relativo a Dalvik come le pause della raccolta dei dati inutili, ma non ci sono ulteriori vantaggi prestazionali all'uso di OpenMAX AL diverso da questo: in particolare, l'uso di OpenMAX AL non determina una minore latenza audio o video ... "Oh bene. – barkside
Ti dispiacerebbe dare un aggiornamento sui progressi che hai fatto su questo? – Matt
Alla fine ho usato GStreamer (hanno ora il supporto per Android) che ti dà molto più controllo su queste cose ... un po 'di cop-out lo so ... – barkside