それを投げる方法は理解できます：最も簡単なオプションは、より大きなkitを取ることです。
見方-質問は少し困惑しました。
判明したこと：
- gstreamerは、チェーンでリンクできるプラグインのセットを提供し、あるプラグインの出力を別のプラグインの入力に供給します。 プラグインの中には、ファイル（{file、fd} {src、sink}）およびネットワーク（{tcp {client、server}、udp} {src、sink}）からの入力/出力、ビデオインターフェースを介したビデオキャプチャなどの単純な基本要素があります。 Linux（v4l2src）の場合、X（ximagesink）によるビデオ出力。 多くのマルチメディア形式用のエンコーダーとデコーダーがあります-私はmpeg4video、h263およびtheoraを試しました。 RTPストリームを生成および解析するためのツールがあります。 ストリームのフォーマットを自動的に決定し、デコード（decodebin）するためのツールがあります。
- かなり新しいgstreamerが標準のOS2008ファームウェアに含まれています。 コンソールの操作を完了するには、gst-launchおよびgst-inspectユーティリティを含むgstreamer-toolsパッケージをインストールする必要があります。
素晴らしい。
最初の試み
[n810] $ gst-launch -v v4l2src！ \
capsfilter caps = "video / x-raw-yuv、format =（fourcc）UYVY、framerate =（fraction）8/1、width =（int）640、height =（int）480"！ \
autovideosink
capsfilterフィルターは、ビデオキャプチャオプションを設定します。 これらは合理的な範囲内で変更できます。そのようなパラメーターでビデオをキャプチャできない場合、gstreamerは最も近い有効なパラメーターを書き込みます。
ネットワーク伝送
これをネットワーク経由で送信できたらうれしいです。 最も単純なオプションは次のようになります（デスクトップマシンIP 192.168.1.254）：
[デスクトップ] $ gst-launch -v tcpserversrc host = 0.0.0.0 protocol = gdp！ autovideosink
[n810] $ gst-launch -v v4l2src！ \
capsfilter caps = "video / x-raw-yuv、format =（fourcc）UYVY、framerate =（fraction）8/1、width =（int）320、height =（int）240"！ \
tcpclientsinkホスト= 192.168.1.254プロトコル= gdp
protocol = gdpパラメーターは、ネットワークを介して送信されるデータにストリーム形式を追加します。事実は、互換性のある形式の出力と入力を持つフィルターのみをチェーンで組み合わせることができるということです。 受信側でこのパラメーターを使用したtcp * srcの出力形式は、入力側で送信側のtcp *シンクと同じです。
シンプルなソリューションですが、Wi-Fiを介して一生懸命動作します。7メガビット、600パケット/秒-顕著な負荷。 640x480はすでに著しく遅いです。
明らかに、次のステップは圧縮を追加することです。
mpeg4にしましょう：
[デスクトップ] $ gst-launch -v tcpserversrc host = 0.0.0.0 protocol = gdp！ decodebin！ autovideosink
[n810] $ gst-launch -v v4l2src！ \
capsfilter caps = "video / x-raw-yuv、format =（fourcc）UYVY、framerate =（fraction）8/1、width =（int）320、height =（int）240"！ \
hantro4200enc！ tcpclientsinkホスト= 192.168.1.254プロトコル= gdp
すばらしい、すべてがmpegブロックになっていますが、110キロビットと1秒あたり30パケット（：
このスキームの他の重大な欠点は何ですか？ TCP / IP：パケットの損失により、無関係な画像が再送信されるため、遅延が発生します。 切断は、サーバーとクライアントを再起動することによってのみ処理されます。
RTP
したがって、RTPをねじ込む必要があります。
[デスクトップ] $ gst-launch -v gstrtpbin name = rtpbin \
udpsrc caps = "application / x-rtp、media =（string）video、clock-rate =（int）90000、encoding-name =（string）H263" port = 5000！ \
rtpbin.recv_rtp_sink_0 rtpbin。 ！ \
rtph263depay！ decodebin！ autovideosink
[n810] $ gst-launch -v gstrtpbin name = rtpbin \
v4l2src！ \
capsfilter caps = "video / x-raw-yuv、format =（fourcc）UYVY、framerate =（fraction）8/1、width =（int）320、height =（int）240"！ \
hantro4200encストリームタイプ= 5ビットレート= 512！ rtph263pay！ \
rtpbin.send_rtp_sink_0 rtpbin.send_rtp_src_0！ \
udpsinkポート= 5000ホスト= 192.168.1.254
何が変わった？
- mpeg4はh263に変わりました。 何らかの理由で、デスクトップマシンからのffmpegは、hantro4200から送信されたフレームを解読できませんでした。 送信側では、これはパラメーターstream-type = 5で表されます。 サイコロを少なくするには、ビットレート= 512を追加します。
- 名前付き入力および出力を介して使用されるrtpbinを追加しました-ビデオはチャンネル0に移動します。 圧縮ビデオストリームからRTPへ、またはその逆の変換は、rtph263payおよびrtph263depayによって実行されました。
- tcpはudpに変わりました。 受信側では、caps = "..."は、ストリームを復元するために欠落していた情報を吸収しました。 この行は、送信側でrtph263payによって印刷されました。
どのような効果がありますか？
- 接続が一時的に失われても、接続は切断されません。 接続がありません（：
- 表示を停止して再起動できます。 これは、ビデオサーバーにはまったく影響しません。
- 遅延フレームは、時間通りに到着したフレームの表示を妨げません。
残っているものは何ですか？
- エンコーダー間の理解できない摩擦：RTPを介したmpeg4videoは表示されません。 Theora圧縮には色変換が必要ですが、チェーン
v4l2src！ capsfilter！ ffmpegcolorspace！ テオラエンク
出力に黒い四角を与えます。 同時に、theoraでエンコードされたビデオを視聴しても問題は発生しません。 - 多分ねじ込みマルチキャスト。 もちろん、私の構成では、まだ必要ありません。 しかし、見るのは楽しいでしょう。
- 今日はサンクトペテルブルクで雨が降っています。 ヘビの場合、天気は飛んでいません。 太陽と風を待っている（：
公式ウェブサイトのgstreamerプラグインのヘルプ： gstreamer.freedesktop.org/documentation
インストールされたプラグインのリストとそれらのパラメーターのヘルプ-gst-inspect
PS gstreamerには一種の称賛の歌がありました。 ツールに率直に満足（：