Giải mã luồng RTSP trực tiếp: độ trễ video lớn bằng MediaPlayer trên Android

Question

Tôi đang phát luồng RTSP trực tiếp từ VLC trên PC đến lớp Android MediaPlayer (cả trên cùng một mạng cục bộ). Nó chơi trơn tru không có lỗi - vấn đề là video được giải mã trên màn hình nằm trong khoảng từ 5 đến 7 giây sau khi phát trực tiếp.

Từ gỡ lỗi và gọi lại Tôi có thể thấy dữ liệu trực tiếp đến trên thiết bị < 1s sau khi bắt đầu mMediaPlayer.prepareAsync(). Đây là khi lớp MediaPlayer bắt đầu tìm ra định dạng luồng là gì với thứ nguyên vv. Sau đó, ngay trước khi video được hiển thị trên màn hình (từ 5 đến 7 giây sau), onPrepared() được gọi là nơi tôi gọi mMediaPlayer.start(). Có vẻ như đây là start() phát video đã được bắt đầu từ giai đoạn bắt đầu của giai đoạn chuẩn bị.

Tôi đã thử seekTo(5000) cả trước và sau start(), nhưng nó không ảnh hưởng đến độ trễ.

Đối với ứng dụng gọi điện video trực tiếp, thời gian trễ thiết lập vài giây là hoàn toàn tốt, nhưng độ trễ này khi video được trình bày là không thể đạt được với tôi.

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

Bất kỳ ý tưởng nào về cách tôi có thể giảm độ trễ này hoặc tìm đến phần cuối của bộ đệm được MediaPlayer đệm? Thiết bị của tôi là 3.1, minSdkVersion là 2.2.

EDIT:

Tôi đã tìm thấy một số nước đánh giá cao và thấp trong AwesomePlayer.cpp (2s và 8s). Như một bài kiểm tra nhanh, tôi đã hack libstagefright.so để tạo các số 0.1 và 1s này. Tuy nhiên điều này không ảnh hưởng đến sự chậm trễ. Tìm kiếm của tôi tiếp tục ...

Answer 1

Tôi đang đối mặt với cùng một vấn đề. Một cách để giải quyết vấn đề này là viết lại toàn bộ lớp phát lại để kiểm soát những gì được đưa vào bộ giải mã. Nhưng đây sẽ là khu nghỉ mát cuối cùng (và đau đớn). Tôi vẫn đang tìm kiếm ... tiếng thở dài ...

Answer 2

Tôi đang gặp vấn đề tương tự. Lúc đầu, tôi nghĩ rằng nó không hoạt động, nhưng tôi đã quên ứng dụng của mình được mở và sau một thời gian video hiển thị.

Điều thú vị là nếu tôi sử dụng video này [1] mà tôi tìm thấy trong hướng dẫn trên VideoView, độ trễ nhỏ hơn nhiều. Tôi đang nghĩ đến việc cài đặt máy chủ Darwin Streaming để kiểm tra xem nó có phải là vấn đề của VLC hay một vấn đề khác.

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

Answer 3

Tôi không đưa ra một câu trả lời cuối cùng, nhưng hãy để tôi chia sẻ những gì tôi có bây giờ.

• Tôi gặp vấn đề về độ trễ 5 phát trên máy tính, từ GStreamer đến GStreamer. Độ trễ đã biến mất sau khi thêm các thông số sau vào đường ống:
  • trên máy khách - latency=0 thông số rtspsrc;
  • trên máy chủ - v4l2src Tham số is-live=1 và, tất nhiên, x264enc tune=zerolatency.

Không có cách nào để kiểm soát MediaPlayer/VideoView 's codec/phương tiện truyền thông các thông số nguồn. Không có trong API MediaCodec, theo như tôi thấy.

Vì vậy, chúng tôi cần truy cập GStreamer hoặc ffmpeg.

• NDK quyền truy cập vào các codec tăng tốc phần cứng was introduced in Android 4.2 (JellyBean) (tìm kiếm "androidmedia"), và people had some success utilizing it.
• NDK tăng tốc phần cứng truy cập codec trong FFMPEG được thực hiện vào năm 2011, in FFMPEG 0.9

Dễ sử dụng và tính di động sẽ được phát hiện ra được nêu ra.