[Armadillo:07466] Re: Armadillo-420 MJPG-streamer の画像乱れ問題について

[Shin-ya Koga]

サムシングプレシャスの古賀です。

ちょっと間が空いてしまいましたが・・・

中村さん（[Armadillo:07444]）：
>>従って、UVC ドライバが再構築したフレームデータの内容が不正な
>>ものでないかどうかは、UVC ドライバの上位レイヤで判定する、と
>>いうのが自然な設計となるんじゃないかと思います。
>
>すべてが正しく書かれていれば、ですね。

というよりは、ソフトウェアの階層構造として、どのように役割
分担するのが妥当か、ということだと思います。UVC のペイロード
としては、MJPEG や非圧縮フレームに加え、MPEG2-TS も定義され
ていますが、それらのペイロードの構造をドライバが理解すること
が妥当かどうか、という観点から、先のメールを書いたのでした。

# OSI の7階層リファレンスモデルにおける、各階層での役割
# 分担の観点から書きました。たとえば、アプリケーション層の
# プロトコルのパケット構造を、トランスポート層で解釈して
# 不正パケット判定するような対応は、妥当ではないと思うので
# すね。

>ほとんど遭遇しないようなケースで（そこに今回ぶち当たった）、
>チョンボや条件判定の漏れなんてことがあって、間違った処理を
>してしまったとかであれば、その責任はドライバ。

どこでどうエラー検出し、検出時のエラー回避をするのかは、階層
構造の中で、適切に役割分担するのが自然だと思うのですね。
USB の場合、比較的安定した伝送路であり、その中で、アイソクロ
ナス転送は、帯域確保できない場合は、パケットロスの発生が起こ
り得る前提で設計されています。なので、ドライバを呼び出す側で
も、まず、必要な帯域を確保できるかどうかを確認し、十分な帯域
を確保できる範囲で使う（パケットロスの発生可能性を抑える）と
いうのが妥当な解なんじゃないかと思います。

# MPEG2-TS の場合だと、信頼性の低い伝送路での伝送を意識した
# プロトコル設計なので、MPEG2-TS のパケットレベルで（つまり、
# UVC のペイロード内容を解釈する側で）、パケット落ちなどを
# 検出することが容易です。一方、MJPEG の場合は、伝送路上での
# データ化けに対して堅牢ではないので、パケットの取りこぼしが
# 容易に発生し得る状況では、対応の役割分担が難しいところは、
# ありますね。

>フレームデータの内容が不正かどうかを知ることができるかどうか
>とは違う論点です。
>私が「もしかしたら・・・」と思ているのは、こちらの方です。

今回の場合の、安直な対応としては、UVC ドライバに手を入れて、
アイソクロナス転送のパケット取りこぼしを検出した場合は、その
フレームを捨ててしまうようにすることでしょうね。あるいは、
パケット取りこぼしの発生を、ドライバの呼び出し側が検出できる
ようにして、呼び出し側で、データ片が欠落しているフレームを
捨てるか、です。

--
古賀信哉 （株）サムシングプレシャス