プログラマ専用SNS ミクプラ

C言語、VC++2010、Winsockを使ってRTMPサーバ的なものを作成したいのです。
Windows上でサーバ起動
↓
スマフォやPCのブラウザでWindowsで起動したサーバにアクセス(http://192.168.○○.○:xxxx)
↓
サーバ上でOpenCVなどでWebカメラから取得した連続画像(動画？)のレスポンスを返し続ける
↓
上記レスポンスをブラウザに表示し続ける

このようなことは可能ですか？
どのように作ればいいのでしょうか？

オグニ さんが書きました: このようなことは可能ですか？

可能です。
RTMPプロトコルについては、対応しているブラウザは少ないと思いますが。

オグニ さんが書きました: どのように作ればいいのでしょうか？

質問が抽象的すぎるので答えられません。

h2so5 さんが書きました:

オグニ さんが書きました: このようなことは可能ですか？

可能です。
RTMPプロトコルについては、対応しているブラウザは少ないと思いますが。

早速の回答ありがとうございます。
では、通常ですと私がやろうとしてること

サーバ上でOpenCVなどでWebカメラから取得した連続画像(動画？)のレスポンスを返し続ける
↓
上記レスポンスをブラウザに表示し続ける

はRTMPプロトコルを使わずにどのような方法を用いればいいのでしょうか？
例えば、普通にWebページ(html)にアクセスしCGI(PHPやPerl)のsocketでWindows上のサーバーにアクセスするということですか？

[a.html]
<img src="./view_img.php">

[view_img.php]
$sock = fsockopen(グローバルIP,サーバPort);
fwrite($sock, "なんらかのリクエスト\r\n\r\n");
while(!feof($sock))
{
$res .= fgets($sock,128);
}
fclose($sock);
header('Content-Type: "image/png"');
echo $res;

[Windows起動サーバ]
リクエストを受け取ったらtest.pngをバイナリでfopenし
そのバイナリをレスポンスで返す

たぶん画像だったらこんな感じで表示できますよね？
これが動画だったらどうなりますか？

静止画と違って動画はどのブラウザでも確実にストリーミングできる方法はありません。
FlashやQuickTimeなどのプラグインを使う方法もありますが、ブラウザだけで再生したいのであればSRTPでしょうか。
WebRTCに対応しているブラウザならSRTPをサポートしていますが、スマートフォン用のブラウザではまだ対応していないことが多いと思います。

h2so5 さんが書きました:静止画と違って動画はどのブラウザでも確実にストリーミングできる方法はありません。
FlashやQuickTimeなどのプラグインを使う方法もありますが、ブラウザだけで再生したいのであればSRTPでしょうか。
WebRTCに対応しているブラウザならSRTPをサポートしていますが、スマートフォン用のブラウザではまだ対応していないことが多いと思います。

そういうことですか。
では、PCユーザーとAndroidユーザーはほとんど対応してると思われるFlashを使うとして
この場合、WinSock側のサーバではどのような処理の流れになりますか？

先程も書きましたが質問が抽象的なので答えられません。
詳しい手順に関してはHTTP Live Streamingnなどの仕様書を確認して下さいとしか言えません。

https://developer.apple.com/jp/devcente ... 6%9B%B8%27
この仕様書のPDFをダウンロードして読んでみたのですが、いまいち知りたいことと違いました。

私が知りたかったのはwebページでストリーミング再生するときに使用するストリーミングサーバーの作り方(リクエストをどう受け取って、どうレスポンスを返すか)です。

Webページであれば、仮に<a href="./test.html">テストページ</a>というリンクタグをクリックすると
----------------------------------------------------------------------------------------------------------
GET /test.html HTTP/1.1
Host: ホスト名
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:33.0) Gecko/20100101 Firefox/33.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ja,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive

----------------------------------------------------------------------------------------------------------
というリクエストが送られ
----------------------------------------------------------------------------------------------------------
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: close
Cache-Control: private, no-cache, no-store, must-revalidate
Pragma: no-cache
Vary: Accept-Encoding
Content-Encoding: gzip

HTMLソース

----------------------------------------------------------------------------------------------------------
というレスポンスがサーバーから返ってきてブラウザのレンダリングエンジンなどで処理されブラウザに表示されますよね？

では<img src="./test.png">という画像では？
----------------------------------------------------------------------------------------------------------
GET /test.png HTTP/1.1
Host: ホスト名
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:33.0) Gecko/20100101 Firefox/33.0
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: ja,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive

----------------------------------------------------------------------------------------------------------
というリクエストが送られ
----------------------------------------------------------------------------------------------------------
HTTP/1.1 200 OK
Server: Apache
Last-Modified: Sun, 23 Nov 2014 14:30:38 GMT
Accept-Ranges: bytes
Content-Length: バイナリのbyte数
Connection: close
Content-Type: image/png

画像のバイナリ

----------------------------------------------------------------------------------------------------------
という感じにレスポンスがサーバーから返ってきてブラウザに表示されます。


ここまではいいのです。
では動画は？
ファイルの存在する、たとえばtest.mp4があったとします。
<video src="test.mp4"></video>
こうすればリクエストは

GET /test.mp4 HTTP/1.1
Host: ホスト名
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:33.0) Gecko/20100101 Firefox/33.0
Accept: video/webm,video/ogg,video/*;q=0.9,application/ogg;q=0.7,audio/*;q=0.6,*/*;q=0.5
Accept-Language: ja,en-us;q=0.7,en;q=0.3
Range: bytes=0-
Connection: keep-alive

----------------------------------------------------------------------------------------------------------
となってレスポンスは
----------------------------------------------------------------------------------------------------------
HTTP/1.1 206 Partial Content
Server: Apache/2.2.25
Accept-Ranges: bytes
Content-Length: バイナリのbyte数
Content-Range: bytes 0-2598966/2598967
Keep-Alive: timeout=5, max=20
Connection: Keep-Alive
Content-Type: video/mp4

mp4のバイナリ

----------------------------------------------------------------------------------------------------------
となります。
ただこれは「動画ファイル」が存在する場合です。

では<video src="自作サーバーIP:自作サーバーポート"></video>とた場合、
リクエストは上記mp4再生と同じ？ようなものになると思います。
レスポンスはどうすればいいのですか？
206で
Content-Range: bytes 0-2598966/2598967
このようにして0～2598966バイトまでを返したとします。
このあたりまではわかります。
問題はMIME-Typeとデータです。

私がやりたいのは、OpenCVでWebカメラから取得した連続した画像をブラウザ(videoタグ内)に返してリアルタイム(に近い)で動画として表示させたいのです。
まず、サーバーを起動させたまま待機させます。
webページ(ブラウザ)からリクエストが来たらOpenCVでWebカメラから画像を取得しそのデータを連続でレスポンスで返す。
この場合、MIME-Typeはimage/pngやimage/jpegなどの画像になります。
この場合<video>だと読み込めないと思うのですが？

それともこの考え(連続した画像を動画として扱いvideoタグで処理させる)が間違っているのでしょうか？
他にやり方がありますか？

どうやるのが一番うまいのでしょうか？

今までの回答は何らかのコーデックを適用した動画をストリーミングするという前提で答えていたのですが、そうではなくて素の静止画像を連続で表示したいということでしょうか。

その場合はvideoタグは使えません。
WebsocketかHTTPロングポーリングで画像を受信し、Javascriptを使ってCanvasに連続で描画するという方法になると思います。
ただ、言うまでもなくこの方法は効率が悪いので実用的な速度が出るかどうかわかりません（特にモバイルデバイス）

h2so5 さんが書きました:今までの回答は何らかのコーデックを適用した動画をストリーミングするという前提で答えていたのですが

すみませんでした。
私の質問の仕方が悪く、誤解を招いてしまいましたね。

h2so5 さんが書きました:その場合はvideoタグは使えません。

やはり、そうなりますか。
MIME-Type、バイナリデータの関係でそうだとは思っていました。

h2so5 さんが書きました: WebsocketかHTTPロングポーリングで画像を受信し、Javascriptを使ってCanvasに連続で描画するという方法になると思います。
ただ、言うまでもなくこの方法は効率が悪いので実用的な速度が出るかどうかわかりません（特にモバイルデバイス）

確かにこれだと効率が悪く、速度的にも考え物です。

今回のようなアプリ(サーバー)を作成したい場合、通常はどのような手法を用いるのでしょうか？
やりたいことは単にOpenCVでWebカメラから取得した画像を連続で(動画のように)Webに表示させたいだけなのですが。。。

一般的なライブストリーミングサービスではFlashPlayer+RMTPを使っていることが多いようです。
モバイルでの視聴は専用アプリを開発するということになります。
「表示させたいだけ」といっても動画のライブストリーミングは単なる画像や動画のダウンロードと比べて高度な技術ですので、そこまで簡単に作れるものではありません。