3

サーブレットからWindowsMediaPlayerにビデオをストリーミングしようとしています（プログレッシブダウンロードスタイル）。ストリーミングは機能しますが、いくつかの奇妙な動作があります。これは、実装の問題が原因ではないことを除外したいと思います。

WMPを使用してサーブレットからURLを開く場合、WMPは同じリソースに対して合計4つのhttp-getリクエストを実行しますが、毎回ヘッダーがわずかに異なります。最初の3つのリクエストの接続は、リクエスト（ヘッダーを含む）が送信されるとすぐに閉じられるようです。4番目のリクエストは接続されたままで、実際にレスポンスヘッダーとファイルコンテンツを配信できます。

最初の3つのリクエストを監視するためにwiresharkを使用してみました。4つのリクエストすべてに対して同じ応答の開始が送信され、最初の3つのリクエストは、閉じられる前に応答ヘッダーとファイルコンテンツの一部を送信することができました。（関連性があるかどうかはわかりませんが、wiresharkがストリームを正しく解析するには、「IP TSO対応ハードウェアからのパケットキャプチャのサポート」を有効にする必要があります。有効にしないと、http-responseを含む最初のパケットが不正な形式であると見なされます。）

以下の4つのリクエストヘッダー：

GET /basic/test.mpg HTTP/1.1
Accept: */*
User-Agent: Windows-Media-Player/12.0.7600.16415
Accept-Encoding: gzip, deflate
Host: 192.168.1.34
Connection: Keep-Alive

GET /basic/test.mpg HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: getIfoFileURI.dlna.org
Accept: */*
User-Agent: NSPlayer/12.00.7600.16385 WMFSDK/12.00.7600.16385
GetContentFeatures.DLNA.ORG: 1
Host: 192.168.1.34

GET /basic/test.mpg HTTP/1.1
Accept: */*
User-Agent: NSPlayer/12.00.7600.16385 WMFSDK/12.00.7600.16385
Icy-Metadata: 1
Accept-Encoding: gzip, deflate
Host: 192.168.1.34
Connection: Keep-Alive

GET /basic/test.mpg HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: getIfoFileURI.dlna.org
Accept: */*
User-Agent: NSPlayer/12.00.7600.16385 WMFSDK/12.00.7600.16385
GetContentFeatures.DLNA.ORG: 1
Host: 192.168.1.34

応答ヘッダー：

HTTP/1.1 200 OK
Content-Type: video/mpeg
Content-Length: 130549760
ETag: TEST1286565215430
ContentFeatures.DLNA.ORG: DLNA.ORG_PN=MPEG_PS_PAL;DLNA.ORG_OP=00
Server: Jetty(6.1.x)
4

1 に答える 1

0

最初の 3 つのリクエストの接続は、リクエスト (ヘッダーを含む) が送信されるとすぐに閉じられるようです。

「そうらしい」？先に進む前に、特定の方法または方法を見つけます。応答ヘッダーが設定された後に接続を終了している場合は、プレーヤーが非常に具体的なヘッダーが存在することを期待していた可能性があります。例には、Range:またはが含まれますCache-Control:。

于 2011-12-05T12:23:09.970 に答える