2011年5月29日日曜日

RtmpClientの使い方その4.1 ほかのプロトコルのhandshakeについて

twitterでRTMPEをやっているという方からtweetが・・
そういえばやってなかったので実験してみました。

■Handshakeの動作がどうなっているか確認
conf/logback.xmlの設定のorg.red5.server.net.rtmpの指定をDEBUGに変更したらログが表示されるようになります。

FlashPlayer10(RTMPE)
Scheme1でHandshakeするようです。
その後でPublicキーの相互やりとりを実施となるようです。

RtmpClientの場合(RTMP(暗号認証指定時))
Scheme0でHandshakeをおこなってから
同じようにPublicキーのやりとりを実施しています。

FlashPlayer10(RTMPT)
Scheme1でHandshakeするようです。

・感想
全部Scheme1で認証するようにFlashPlayer側がかわってしまったのでしょうか・・・
内部にもいろいろ隠し仕様が追加されてるような気がします。(確定ではないです。)

■動作的にどうなるか？(demos/publisher.htmlにて確認)
FlashMediaServerの場合
・rtmpe://サーバー/liveで接続して
放送：ok
視聴：ok
まぁあたりまえです。

Red5の場合
・rtmpe://サーバー/liveで接続して
放送：ok
視聴：ng(パケットが送られてこなくてフリーズする？)
となっているようです。
根拠は
rtmp：視聴 rtmpe：放送では問題なく動作
rtmp：放送 rtmpe：視聴ではやはり固まります。

・rtmpt://サーバー:5080/liveで実行した場合
放送：ok
視聴：ok
だが、しばらくたつとフリーズしてブラウザが落ちるようです。(Chrome OSX)
内部でFlashPlayer動作用のプロセスがかたまったまま、ブラウザを閉じても終了しないそんな感じになっておりました。

・感想
かろうじてrtmpeで放送するのは使えますかね。ほかはちょっと・・・
というかrtmpeの放送処理もちょっと・・・

■まとめ
簡単におこなった実験ですので、確定ではありませんが、rtmp以外のプロトコルに関しては、今後のred5のバージョンアップを待つか、Red5の大本のソースコードに切り込んでいしか方法はないような感じかと思います。
しかし、Flashのバージョンアップしてから機能のメンテナンスをきちんと実行しないのは、面倒だからやっていないのか、はたまた問題がでてるのはわかっているけど、Flashの動作の解析がうまくいかなかったのか、どうなんでしょう。
投稿者 poepoemix 時刻: 11:16 0 コメント
ラベル:

2011年5月27日金曜日

RtmpClientの使い方その４　scheme1のValidation通してみる。

Red5の内部についている。RTMPClientをつかって別のRed5のサーバーにクライアントとして接続させると動作的に不正なクライアントと判定されます。
これはscheme1のValidationが有効になるようにRTMPClientがHandshakeしないためです。
Red5のサーバー動作側がscheme1でValidationの確認してるんだから、Red5チームがメンテしわすれたんでしょうね。

さて、この問題をなんとかしてみます。
ちなみに、現状のバージョンのRed5では別にValidation通さなくてもなんの問題もありません。判定だけしてそのまま処理続行してますから。ただの自己満足の色合いが強いです。

ソースコードの全体図はgithubにあげたred5_phpのリポジトリを確認してください。
ここのcom.ttProject.TestClassを実行するとlocalhostの1935ポートのRtmpサーバーのliveアプリケーションに接続しにいくようにしてあります。

まずは変更点の解説
■RtmpClientEx.javaの中
１：コンストラクタ上でioHandlerの初期化を実行
２：startConnectorのメソッドをRTMPClientよりオーバーライド
元ネタのRTMPClientではioHandlerをRTMPMinaIoHandlerとして初期化しています。
このHandlerの内部でつかっているOutboundHandshakeというクラスの中身を必要に応じて変更したいので、Handlerに細工する→Sessionに独自handshakeクラスを注入するという手を使います。
２の方のstartConnectorのメソッドのオーバーライドはioHandlerがprivateではなくprotectedだったら必要なかったのですが、まぁしかたないです。

■RTMPMinaIoHandlerEx
１：sessionCreatedをオーバーライド
このイベントの時に、オリジナルのRTMPMinaIoHandlerの処理を実施したあとに、sessionの設定属性を独自のものに書き換え。
テスト等でオリジナルのRTMPClientのHandshakeを実行したい場合は設定しているOutboundHandshakeExの部分をコメントアウトすれば大丈夫です。

■OutboundHandshakeEx
１：generateClientRequest1をオーバーライド
２：addBytesメソッド
３：calculateOffsetメソッド
２と３は内部で使う補助メソッドです。OutboundHandshakeの中でも定義されているんですが、privateになっているため、コピーしました。
問題は１の部分

大本のOutboundHandshakeクラスの中では次のようにHandshakeが進行します。
はじめにcreateHandshakeBytesメソッドで、timestamp(4バイト) + プレーヤーバージョン指定(4バイト*1) + 1528バイトのランダムバイトをひな形として作成します。
続いてgenerateClientRequest1メソッドで、送信バイトデータとして、Encrypted識別子(0x03)と先ほどつくったひな形をHandshakeのエントリーとして送信しています。(*2)

*1：ここでいうプレーヤーのバージョンは、adobeのFlashプレーヤーのバージョン確認ででるバージョンとは別のデータになります。内部管理用のバージョン番号が別にあるのでしょう。
*2：adobeのサイトのrtmpの仕様書によるとHandshakeの冒頭でc0 c1 c2 s0 s1 s2とクライアントが３回、サーバーが３回データを送信するように設計されていると記述されています。このc0c1に相当するデータが一度に送信されています。(ってか分けてる必要あんのこれ？)

OutboundHandshakeExではひな形はcreateHandshakeBytesでつくってもらってからgenerateClientRequest1上で次のようなことを行っています。
まず、ひな形をローカル変数に保持。
続いて772から４バイトがvalidation用のキーの埋め込み場所を指定するデータとなるため、その４バイトを取得する。
776から728バイトのデータがどうなっているかをキーにSHA256で暗号化するのでその計算を実行。
できたキーを先ほど計算した埋め込み場所に上書き。
でHandshakeのひな形できあがりとなります。

では最後に、conf/logback.xmlでorg.red5.server.net.rtmpをDEBUGにした状態でRed5 1.0.0 RC2 Rev 4222に接続させてみます。
まずは、エラーにRTMPClientでつないだ場合

[DEBUG] [NioProcessor-1] org.red5.server.net.rtmp.RTMPHandshake - Player encryption byte: 3
[DEBUG] [NioProcessor-1] org.red5.server.net.rtmp.RTMPHandshake - Detecting flash player version 9,0,124,2
[DEBUG] [NioProcessor-1] org.red5.server.net.rtmp.RTMPHandshake - Player version byte: 9
[DEBUG] [NioProcessor-1] org.red5.server.net.rtmp.RTMPHandshake - Scheme: 0 client digest offset: 342
[DEBUG] [NioProcessor-1] org.red5.server.net.rtmp.RTMPHandshake - Temp: 1f52f06ea4da019863e8d35badd242cb29be6224613996df3bf3becd2da28676
[DEBUG] [NioProcessor-1] org.red5.server.net.rtmp.RTMPHandshake - Scheme: 1 client digest offset: 1284
[DEBUG] [NioProcessor-1] org.red5.server.net.rtmp.RTMPHandshake - Temp: 32ba98dd706a7c8ecb089ea49c44c31aafe2bbcc5ad0b44e489bbf13e1d0761b
[ERROR] [NioProcessor-1] org.red5.server.net.rtmp.RTMPHandshake - Unable to validate client
[INFO] [NioProcessor-1] org.red5.server.net.rtmp.RTMPHandshake - Invalid RTMP connection data detected, you may experience errors
[DEBUG] [NioProcessor-1] org.red5.server.net.rtmp.RTMPHandshake - Using new style handshake
ちゃんと無効なクライアントと判定されてしまいました。Scheme 0もScheme 1も認証がとおっていません。

続いて修正版で接続した場合
[DEBUG] [NioProcessor-1] org.red5.server.net.rtmp.RTMPHandshake - Player encryption byte: 3
[DEBUG] [NioProcessor-1] org.red5.server.net.rtmp.RTMPHandshake - Detecting flash player version 9,0,124,2
[DEBUG] [NioProcessor-1] org.red5.server.net.rtmp.RTMPHandshake - Player version byte: 9
[DEBUG] [NioProcessor-1] org.red5.server.net.rtmp.RTMPHandshake - Scheme: 0 client digest offset: 691
[DEBUG] [NioProcessor-1] org.red5.server.net.rtmp.RTMPHandshake - Temp: 4f19642c794f70f130ac7b159cda40f71a754abbcea4fa40d8bc328923bf0504
[DEBUG] [NioProcessor-1] org.red5.server.net.rtmp.RTMPHandshake - Scheme: 1 client digest offset: 1217
[DEBUG] [NioProcessor-1] org.red5.server.net.rtmp.RTMPHandshake - Temp: 55671918c7a41de1e20d29b1f9b11e3c70951ce34e13f5c4b32b51054bbef963
[DEBUG] [NioProcessor-1] org.red5.server.net.rtmp.RTMPHandshake - Selected scheme: 1
[DEBUG] [NioProcessor-1] org.red5.server.net.rtmp.RTMPHandshake - Valid RTMP client detected
[DEBUG] [NioProcessor-1] org.red5.server.net.rtmp.RTMPHandshake - Using new style handshake
きちんとScheme1を検出して有効と判定してくれました。
まぁやってることは同じですけどw

最後にFlashPlayerでつないだ場合
[DEBUG] [NioProcessor-1] org.red5.server.net.rtmp.RTMPHandshake - Player encryption byte: 3
[DEBUG] [NioProcessor-1] org.red5.server.net.rtmp.RTMPHandshake - Detecting flash player version 128,0,7,2
[DEBUG] [NioProcessor-1] org.red5.server.net.rtmp.RTMPHandshake - Player version byte: 128
[DEBUG] [NioProcessor-1] org.red5.server.net.rtmp.RTMPHandshake - Scheme: 0 client digest offset: 374
[DEBUG] [NioProcessor-1] org.red5.server.net.rtmp.RTMPHandshake - Temp: e038bc995719caece95d042eb4e71a1ffbfb140d4a6ac3aa52e296c742d3082b
[DEBUG] [NioProcessor-1] org.red5.server.net.rtmp.RTMPHandshake - Scheme: 1 client digest offset: 1310
[DEBUG] [NioProcessor-1] org.red5.server.net.rtmp.RTMPHandshake - Temp: 8753c820eb1225042a7c13ce15bc5f99af692caa07986d0125b9567eec7f4bc4
[DEBUG] [NioProcessor-1] org.red5.server.net.rtmp.RTMPHandshake - Selected scheme: 1
[DEBUG] [NioProcessor-1] org.red5.server.net.rtmp.RTMPHandshake - Valid RTMP client detected
[DEBUG] [NioProcessor-1] org.red5.server.net.rtmp.RTMPHandshake - Using new style handshake

これで似た感じの動作になってきました。
投稿者 poepoemix 時刻: 7:02 0 コメント
ラベル:

2011年5月25日水曜日

xuggleを再度やってみる。

@wikiの方の記事には昔書きましたが、xuggleにそろそろまた手をだしたいと思います。
Red5のRTMPClientのpublish処理がまともに動きますからね。
いろいろとできるはず。

ただし、xuggle....いろんな問題をはらんでます。
コンパイルがとおらなかったり、以前ためしたときにはh264のエンコードが微妙だったり、faacの扱いがあるのかないのかわからなかったり、動作させるときに設定パラメータ大杉だったりと・・・

ま、とりあえずインストールですね。
まずは、yasmを入手します。一部のコンパイルで必要ですから。
http://www.tortall.net/projects/yasm/wiki/Download
こちらからtarballを入手して、configure make make installの３点セット
xuggleのbuild.xmlの設定を解析していないので、インストールせずにコンパイルを通す方法はわかりません。
なお、tarballのソースコードを入手すれば、configureがちゃんと入ってますが開発版のyasmを入手したところ、configureがなく動作させることができませんでした。

次にxuggle本体です。
http://xuggle.googlecode.com
こちらにいって、ソースからsvnをつかってダウンロードしました。
今回インストールしたいのは、xuggle-xugglerなので、
svnで落としたディレクトリ/java/xuggle-xugglerに移動して、antを実行しコンパイルを進めました。
一応動作確認も実行するant run-testsというコマンドもあるのですが、今回はただのantにしておきました。
ant run-testsやってみましたがやっぱりfaacでこけますね。

xuggleの設定してるテストが現状のffmpegに適合してないっぽい。
faacそのものが動作するかはあとで調べないとだめですね。

あと、前はコンパイルするとxuggle/java/xuggle-xuggler/dist/stage/usr/local/xuggle/....
という形でディレクトリが生成されていたのですがxuggleというディレクトリがなくなっているようです。
ant installを実行すると/usr以下の部分がPCの/usr以下にコピーするように動作するので、この部分書き直したほうがいいと思う。
このままインストールするとどこまでがxuggleかわからないので、現状のままほっといて以下のパスを環境変数に設定しておきました。

export XUGGLE_HOME=/Users/xxxxx/xuggletest/xuggle/java/xuggler-xuggler/dist/stage/usr/local
export PATH=$XUGGLE_HOME/bin:$PATH
export DYLD_LIBRARY_PATH=$XUGGLE_HOME/lib:$LD_LIBRARY_PATH
(DYLD_LIBRARY_PATHがまちがってたっぽいので修正Macの場合はこうするべき。)

とりあえずこれで目標達成。
あとで適当にflvファイルをコピーするプログラムでも書こうと思います。
投稿者 poepoemix 時刻: 19:59 0 コメント

2011年5月24日火曜日

放送を別のスコープに受け流す。

Red5のフォーラムにChange the scope/room of a streamというのがあったので放送を別のスコープに受け流すプログラム書いてみた。

どこかのコネクションがplayを始めるとそのコネクション用のBroadcastStreamをつくる。
どこかのコネクションがpublishをはじめるとそのstream内でながれているパケットデータをつくったBroadcastStreamに流していく。

FlashによるFlv1のストリームの場合は、放送を先にはじめてもOKですが、FMEによる放送の場合は、先に視聴を開始→放送を開始としないと視聴できないです。
これはたぶんH.264の場合先頭にメディアのヘッダ情報がないと放送が開始できないとかいった理由でしょう。
あと、プログラムをみればわかりますが、２つ以上の放送を開始してしまうと、両方のデータをパケットに流すことになってしまうので、壊れると思います。試していませんが。
終了まわり等きちんと書いていないので運用等で使いたい場合は、そのあたりの修正が必須になります。

ここんところRed5ネタばかりだ。
投稿者 poepoemix 時刻: 5:44 0 コメント
ラベル:

2011年5月22日日曜日

RtmpClientの使い方その3.2 FlashMediaServerに対応させるのは、やめときます。

さっそくですが、RtmpClientでFlashMediaServerに接続させるのは、やめようと思います。

どうも調べてる限りでは、Handshake以外の何かが抜け落ちているようです。
rtmpeの状態では接続が成立するので(動画データは送れないけど)、そっちから攻めればなにかわかるかと思いますが、これ以上は公開せずに会社で実験したいと思います。

そもそもやりたかったことは、FlashMediaLiveEncoderでFMSにデータを流したやつを、Red5経由でやりとりしてやれば、FMS１つ分のライセンスで放送し放題じゃないの？ということでした。
まぁ、FMS自身に放送データを別のサーバーにpublishする方法があるので、そっちからせめてRed5サーバーにpublishさせてやれば要件は満たせるかなとおもいます。

では、一応いままでにやったこと。
■Flashのバージョンを落として各サーバーに接続させてみた。
・ver 7,8ではRed5のpublisherが起動できず。
・ver 9で接続ができ、FlashMediaServerにも接続させることができた。

■Red5のRtmpClientでRTMPEで本当に接続できるか再度確認
・きちんとつながりFlashMediaServerのログ上にも接続したという記録がつきました。

■ver 9のプレーヤーが吐いたデータをそのまま投げてHandshakeを実行させてみる。
・ver 9のプレーヤーがRed5サーバーにつねげたときに送られてきたパケットデータをそのまま投げるようにして、FlashMediaServerに接続させてみた。→動作せず。

ちなみにver 9のプレーヤーでも接続元のページの情報等をFlashMediaServerはログに残していたので、なにかがあるのかもしれませんね。

9/23追記
なお、JavaのRtmp実装で接続したい場合はFlazrというライブラリを利用すれば可能です。
投稿者 poepoemix 時刻: 15:09 0 コメント
ラベル:

RtmpClientの使い方その3.1 うまく動かないのでHandshakeについて調べてみた。

先の記事での動作を実際にliverepeaterに適応してみたら、動画のデータへの対応がうまくいかず、動作不良がおこる模様でした。

やっぱりHandshakeがおかしいみたいです。(というかrtmpeの接続と認識されるような構成になってるっぽい。)

そこでorg.red5.server.net.rtmpをDEBUGに変更してサーバー、クライアントを動作させHandShakeがどうなっているか確認してみました。
以下サーバー側のログから動作概要抜粋

■RtmpClientでつないだ場合

  • RTMPMinaConnection - RTMPMinaConnection created
  • RTMPConnManager - Connection created, id: 5
  • RTMPHandshake - Handshake ctor
  •  - Player encryption byte: 3
  •  - Detecting flash player version 9,0,124,2
  •  - Player version byte: 9
  •  - Scheme: 0 client digest offset: 310
  •  - Temp: バイトデータ
  •  - Scheme: 1 client digest offset:1168
  •  - Temp: バイトデータ
  •  - Unable to validate client
  •  - Invalid RTMP connection data detected.
  •  - Using new style handshake
  •  - Public key: 数字の羅列
  •  - Public key as bytes - length [128]: バイトデータ
となります。

■RtmpClientをEncrypt有効にしてつないだ場合

  • RTMPMinaConnection - RTMPMinaConnection created
  • RTMPConnManager - Connection created, id: 5
  • RTMPHandshake - Handshake ctor
  •  - Player encryption byte: 6
  •  - Detecting flash player version 9,0,124,2
  •  - Player version byte: 9
  •  - Scheme: 0 client digest offset: 497
  •  - Temp: バイトデータ
  •  - Valid RTMP client detected.
  •  - Using new style handshake
  •  - Public key: 数字の羅列
  •  - Public key as bytes - length [129]: バイトデータ
  •  - Truncated public key length to 128
  •  - Incoming public key [128]: バイトデータ
  •  - Outgoing public key [128]: バイトデータ
  •  - Shared secret [128]: バイトデータ
こちらの場合はScheme0の段階で有効なクライアントと判定されてそのあとで送られてくるPublish Keyのバイトが129バイトに、そのあとIncomming public key、Outgoing public key、Shared secretの３つのキーをやりとりしています。

■本物のFlashPlayerでつないだ場合

  • RTMPMinaConnection - RTMPMinaConnection created
  • RTMPConnManager - Connection created, id: 5
  • RTMPHandshake - Handshake ctor
  •  - Player encryption byte: 3
  •  - Detecting flash player version 128,0,7,2
  •  - Player version byte: 128
  •  - Scheme: 0 client digest offset: 526
  •  - Temp: バイトデータ
  •  - Scheme: 1 client digect offset: 940
  •  - Temp: バイトデータ
  •  - Selected scheme: 1
  •  - Valid RTMP client detected.
  •  - Using new style handshake
  •  - Public key: 数字の羅列
  •  - Public key as bytes - length [129]: バイトデータ
  •  - Truncated public key length to 128
Playerのencryption byte:3になっているので、暗号化は行わないと宣言されています。
versionは固有の値だからおいといて。
Scheme 1の認証で有効なクライアントと判定されています。
Publicキーでは先頭に0x00が追加された129バイトのデータになっています。
そして、Cryptを有効にしたときの接続で見られた３つのキーのやりとりはありません。

というわけでCryptを有効にした場合ともともとの状態との中間になる方法で接続しようとしないとだめっぽいです。

■RtmpClientのデフォルトで接続するが、Scheme1の認証を強制的に受け入れる場合
  • RTMPMinaConnection - RTMPMinaConnection created
  • RTMPConnManager - Connection created, id: 5
  • RTMPHandshake - Handshake ctor
  •  - Player encryption byte: 3
  •  - Detecting flash player version 9,0,124,2
  •  - Player version byte: 9
  •  - Scheme: 0 client digest offset: 674
  •  - Temp: バイトデータ
  •  - Selected scheme: 1
  •  - Valid RTMP client detected.
  •  - Using new style handshake
  •  - Public key: 数字の羅列
  •  - Public key as bytes - length [128]: バイトデータ
  •  - Truncated public key length to 128
最後のPublic keyのバイトの長さが128バイト・・・あたまに0x00をいれないとだめというわけか？
ちなみにこのバージョンでは、サーバー側のプログラムを書き換え認証を強制受け入れとしてあります。

■今後の攻め方
  • Cryptを有効にした場合をベースにいらないものを省くという方向でせめればいいと思われる。
  • Scheme1で認証されるようにすること。
  • Public keyのバイト数は129バイトになるように調整する。
とすれば、うまくいきそうな気がします。
なお、暗号化のHandshakeをクライアントで実行させかつ、Player encryption byteを3(暗号化しないと宣言)として動作させ、Flash Media Serverに接続させようとしたところつながった瞬間に切断されました。
無効なクライアントと認証されてるっぽいです。Scheme0で有効性を検証してるのがだめなんだろうねぇ・・・
投稿者 poepoemix 時刻: 10:01 0 コメント
ラベル:

2011年5月21日土曜日

RtmpClientの使い方その３ Red5側のプログラムを修正してみる場合

Red5に搭載されているRTMPClient(とそれに付随する継承クラス)では２つの問題をはらんでいます。
１つ目は、サーバー側からのクライアント上の関数実行命令に対する返答のしかたがおかしいこと。
２つ目は、HandShakeの仕方が不正であること。

１つ目の問題では、Red5サーバーに接続しにいった状態で、放送を受信しつつサーバーからクライアント関数の実行を実施されると、パケットが混乱し、サーバーから切断されるという不具合があります。
(相手がRed5ならNG、Wowzaなら発生せず、FMSの場合は不明)

２つ目の問題では、Red5サーバーに接続しにいったときにサーバー側で不正なクライアントによる接続と判定されます。また、FMSには接続したあとにすぐ切断させられます。
(相手がRed5なら警告でてそのままつながる、Wowzaつながる、FMS接続後即切断)

今回はRed5側のプログラムを修正して再コンパイルして直す方法です。
まず、Red5のプログラムをSubversionで取得、ant(1.7以降)を準備しておきます。
まずは問題その１、クライアント関数の実行応答が不正な件
src/org/red5/server/net/rtmp/BaseRTMPClientHandler.javaのonInvoke関数の一番最後の部分に手を加えます。

} else if (!onStatus) {
    Invoke reply = new Invoke();
    reply.setCall(call);
    reply.setInvokeId(invoke.getInvokeId());
    log.debug("Sending empty call reply: {}", reply);
    channel.write(reply);
}
となっている部分を

} else if (!onStatus) {
    Invoke reply = new Invoke();
    call.setStatus(Call.STATUS_METHOD_NOT_FOUND);
    reply.setHeader(source);
    reply.setCall(call);
    reply.setInvokeId(invoke.getInvokeId());
    log.debug("Sending empty call reply: {}", reply);
    channel.write(reply);
}

強制的に実行しようとした関数はありませんでした。と応答させてみました。
実行結果を返したい場合はRed5_phpのリポジトリのRtmpClientExのonInvokeの中に記述書いてあるので興味ある人はのぞいてみてください。

つぎに問題その２、Handshakeがこける問題。(FMSにはつながりにいくようになりますが、放送の受信ができなくなる。どうやらこの方法だとRTMPEの動作と認識されるっぽい。[つまり本物のFlashのHandshakeのやり方とは違うということ。])
src/org/red5/server/net/rtmp/RTMPMinaIoHandler.javaのsessionCreated関数をいじります。中盤あたり

if(rtmp.getMode() == RTMP.MODE_CLIENT) {
    // create an outbound handshake
    OutboundHandshake outgoingHandshake = new OutboundHandshake();
    // if handler is rtmpe client set encryption on the protocol state
    // if (handler instanceof RTMPEClient) {
        // rtmp.setEncrypted(true);
        // set the handshake type to encrypted as well
        // outgoingHandshake.setHandshakeType(RTMPConnection.RTMPENCRYPTED);
    //}
    // add the handshake
    session.setAttribute(RTMPConnection.RTMP_HANDSHAKE, outgoingHandshake);
}
となっている部分を・・・
if(rtmp.getMode() == RTMP.MODE_CLIENT) {
    // create an outbound handshake
    OutboundHandshake outgoingHandshake = new OutboundHandshake();
    // if handler is rtmpe client set encryption on the protocol state
    // if (handler instanceof RTMPEClient) {
        rtmp.setEncrypted(true);
        // set the handshake type to encrypted as well
        outgoingHandshake.setHandshakeType(RTMPConnection.RTMPENCRYPTED);
    //}
    // add the handshake
    session.setAttribute(RTMPConnection.RTMP_HANDSHAKE, outgoingHandshake);
}
この２カ所のコメントをはずせば暗号化されたプレーヤーのバージョン情報が記録されるようになり、ただしくプレーヤーからの接続のHandshakeが完了するようになります。
--追記--
すみません、この記述うそです。
Rtmpeとして接続しにいこうとして、Handshakeは成立しますが動画データのやりとりでこけます。Red5やWowzaとデータのやりとりをする場合は元のRTMPMinaIoHandlerつかって処理してもらって、内部判定はInvalidClientとして操作させるかScheme1でValidationを通るように修正するかするといいかと思います。
別の記事であきらめていますが、Scheme1でValidと判定されるようにしてもFlashMediaServerへの接続は失敗します。
--追記ここまで--

あとは、大本のディレクトリにもどって、antを実行すればコンパイルがおわり修正されたRed5.jarが生成されました。

一応これで動作するようにはなるのですが、Red5そのものの修正するのはバージョンがかわるたびにパッチを当てないといけなくなって面倒なので、ちょっと拡張クラス側で対応できないか模索したいと思っています。
僕のつくったRtmpClientExで対応完了するなら、その方が使いやすいですからw

投稿者 poepoemix 時刻: 20:11 0 コメント
ラベル:
登録: 投稿 (Atom)