Декодирование живого RTSP-потока: большая задержка видео с использованием MediaPlayer на Android

Я воспроизводю поток Live RTSP из VLC на ПК в класс Android MediaPlayer (оба в одной локальной сети). Он воспроизводится плавно, без ошибок - проблема в том, что декодированное видео на экране отстает от живого примерно на 5-7 секунд.

Из отладки и обратных вызовов я вижу, что оперативные данные поступают на устройство ‹ 1 с после запуска mMediaPlayer.prepareAsync(). Это когда класс MediaPlayer начинает определять, в каком формате поток, с какими размерами и т. д. Затем непосредственно перед тем, как видео отображается на экране (между 5 и 7 секундами позже), вызывается onPrepared(), где я вызываю mMediaPlayer.start(). Похоже, что этот start() воспроизводит видео, которое было изначально снято в начале этапа подготовки.

Я пробовал seekTo(5000) и до, и после start(), но это никак не влияет на лаги.

Для приложения для видеовызовов в реальном времени задержка установки в несколько секунд совершенно удобна, но эта задержка после показа видео для меня неприемлема.

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

Любые идеи, как я могу уменьшить это отставание или искать конец того, что буферизуется MediaPlayer? Мое устройство 3.1, minSdkVersion 2.2.

РЕДАКТИРОВАТЬ:

В AwesomePlayer.cpp я обнаружил несколько верхних и нижних отметок (2 с и 8 с). В качестве быстрого теста я взломал libstagefright.so, чтобы получить эти 0,1 с и 1 с. Однако на задержку это никак не повлияло. Мои поиски продолжаются...


person barkside    schedule 19.01.2012    source источник
comment
NDK v7 теперь имеет доступ к API потоковой передачи мультимедиа OpenMax AL низкого уровня, когда источником является MPEG TS на 4.0. Кто-нибудь сталкивался с этим - уменьшилась ли задержка видео? Я читал в документах: поскольку OpenMAX AL является собственным API C, потоки приложений, не относящиеся к Dalvik, которые вызывают OpenMAX AL, не имеют накладных расходов, связанных с Dalvik, таких как паузы для сборки мусора. Тем не менее, кроме этого, использование OpenMAX AL не дает дополнительных преимуществ в производительности. В частности, использование OpenMAX AL не приводит к уменьшению задержки аудио или видео... Ну ладно.   -  person barkside    schedule 03.02.2012
comment
Не могли бы вы дать обновленную информацию о прогрессе, которого вы добились в этом?   -  person Matt    schedule 25.03.2013
comment
В конце концов, я использовал GStreamer (теперь у них есть поддержка Android), который дает вам гораздо больше контроля над этими вещами... немного отговорки, я знаю...   -  person barkside    schedule 25.03.2013
comment
Я бы сказал, что это довольно хорошее решение, учитывая отсутствие поддержки настройки буферизации в Android API 17 и ниже.   -  person Matt    schedule 25.03.2013
comment
не могли бы вы объяснить, как вы запустили видеопоток VLC rtsp?   -  person Albert Chen    schedule 03.01.2015


Ответы (3)


Я не даю окончательного ответа, но позвольте мне поделиться тем, что у меня есть на данный момент.

  • 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;
    • на сервере - параметр is-live=1 v4l2src и, конечно же, x264enc tune=zerolatency.

Невозможно управлять параметрами кодека/медиа-источника MediaPlayer/VideoView. Ни в MediaCodec API, насколько я вижу.

Итак, нам нужно выбрать GStreamer или ffmpeg.

Простота использования и портативность еще предстоит выяснить.

person Victor Sergienko    schedule 15.07.2013

Я столкнулся с той же проблемой. Один из способов решить эту проблему — переписать весь класс воспроизведения, чтобы контролировать то, что передается кодеку. Но это было бы последним (и болезненным) средством. Я все еще оглядываюсь... вздох...

person MikeC    schedule 30.01.2012

У меня точно такая же проблема. Сначала я подумал, что это не работает, но я забыл, что мое приложение открылось, и через некоторое время появилось видео.

Самое смешное, что если я использую это видео[1], которое я нашел в учебнике по VideoView, отставание становится намного меньше. Я думаю об установке сервера Darwin Streaming, чтобы проверить, связано ли это с VLC или другой проблемой.

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

person jlanza    schedule 02.02.2012
comment
В источнике AOSP я вижу верхние/нижние водяные знаки для данных, а также время, поэтому, возможно, если скорость передачи данных велика, буфер будет заполнен до верхнего водяного знака данных раньше, что приведет к задержке короче. Это видео, которое вы упомянули, может иметь такую ​​высокую скорость передачи данных. - person barkside; 02.02.2012