AndroidでRTP/TCP/AVPビデオストリームを再生する

Question

私たちはAndroidプラットフォームでビデオストリームを再生しようとしていますが、 は成功していません。 VideoViewを使用して、我々は、このURLが正常に動作します例えば （ユーチューブモバイルビデオを再生することができます： RTSP：//v3.cache7.c.youtube.com/CjYLENy73wIaLQnMYzt2FtQmqxMYESARFEIJbXYtZ29vZ2xlSARSBXdhdGNoYI6vr52RlLW1Sww=/0/0/0/video.3gp 01​​）

しかし、私たちは制御を持たない のストリームを（特定のRTSP URLから）再生する必要があります。 RTSPサーバは、RTSPでインターリーブされたRTP/TCP/AVPパケットを配信します。 RTSP自体は、ポート80を介したHTTPトンネリングでサポートされています。 ビデオフォーマットはMPEG4-Part2（H.263）です。 さらに、rtsp urlは一度だけ使用できます。毎回鍵で 文字列で構築されています。デスクトップシステムでは、quicktimeは ストリームを再生する可能性があります.VLCはストリームを再生できませんでした。

このようなストリームをAndroid搭載端末で再生することは可能ですか どういうわけか？

内蔵の（openCore？）RTPスタックのみ はTCPではなくUDPでRTPをサポートしています。これは（まだ）本当ですか？ この問題を何とか回避できますか？

ありがとうございます！ TurimAndrás

Answer 1

UDPの場合は、ローカルUDPポート（または別のポートにパケットを転送することができます。これにより、組み込みのRTPスタックにパケットを送ることが簡単になります）。

VLCは再生できませんデフォルトではサポートしていないオーディオコーデックのためです。詳細を知らないと知りにくい。

Answer 2

クライアントとしてuがrtsp：// serveradress：port/path ポートを開いている場合、vlc、 のポートは通常vlcで554です。 私は決してアンドロイドを使用していませんが、あなたはそこにvlcを持っていればネットワークストリームを開き、上記のアドレス形式を入力する必要があります。 どのポートストリームが送信されているかを調べるには、554でなくてもかまいません。 ファイアウォールがストリームを送信しているポートをブロックしていないことを確認してください。ここ

あなたは私はあなたのための部分的な解決策を持っている幸運に

vlc documentationとvlc wiki

Answer 3

をいくつかのVLCのマニュアルを持っています。

私は現在、サーバーからAndroidクライアントへのメディアのRTPストリーミングを含むRa & Dプロジェクトに取り組んでいます。

この作業を行うことで、私は自分自身のライブラリsmpte2022libに貢献しています。ここにはhttp://sourceforge.net/projects/smpte-2022lib/があります。

このようなライブラリ（Javaの実装は現在のところ最高のものです）を使用すると、プロのストリーミング機器、VLC RTPセッションから来るRTPマルチキャストストリームを解析することができます。

キャプチャされたプロフェッショナルなRTPストリームからのストリームをSMPTE-2022 2D-FECで、またはVLCで生成された単純ストリームで正常にテストしました。

残念ながら、ここでコードスニペットを使用するプロジェクトは著作権で保護されていますが、RtpPacketコンストラクタを使用してUDPストリームを解析するだけで簡単に使用できます。

パケットが有効なRTPパケット（バイト）である場合、パケットはそのままデコードされます。

現時点では、デコードされたペイロードをメディアファイルとして実際に格納するスレッドにRtpPacketのコンストラクタへの呼び出しをラップします。次に、このファイルをパラメータとしてVideoViewを呼び出します。また

クロッシング指;-)

よろしく、

デビッド・フィッシャー

参照RTP on Android MediaPlayer

Answer 4

私はRTSPのでhttps://net7mma.codeplex.com/

@それは特に醜い取得する今、これを開発していますインターリーブ（RTP/AVP/TCP）には、固定長のコンテンツ長が必要です。これはトンネルインには適していませんgリンゴによって提案された方法。あなたは、コンテンツの長さを無視することができますが、いくつかのプロキシがで長さを観察すると、私はMulti-Part/Chunked応答オプションを使用してチャンクとして戻って各$ブロックを掲示向かうより良い努力を見ることがhttps://web.archive.org/web/20130501053040/https://developer.apple.com/quicktime/icefloe/dispatch028.html

@アップルによると

コンテンツの長さと接続を閉じ、Interleaved RTP中にこれは悪いです！