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

[Shin-ya Koga]

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

中村さん（[Armadillo:07442]）：
>>>アプリが用意したバッファ（キュー）にドライバが画像を入れるとき、
>>>異常画像はキューに入らないようにするのが本来の姿ではないかと。
…
>mjpg-streamerには -m オプションがありますし、今回アプリが
>終了してしまう原因になっていた Ignoring empty buffer ... を
>出している部分でも、受信データのサイズが極端に小さかったら
>はじいているわけですから、すべて信じていいということでは
>ないのですが・・・私の書き方が悪かったです。
> 
>「異常データ」ってのは、カメラの送出データに異常があり、
>それをUVCドライバで検査しろということではなくて、
>フレームレートと解像度を上げるとほぼ全滅ということから、
>どこか（UVCドライバかその下のドライバか・・・）で壊している、
>というか、エラーをちゃんと処理していないなどの理由で、
>古賀さんが書かれている
>>データ片を集積してフレームデータを完成させるのみで
>が、正しく行われていないのではないかな？と。

USB アイソクロナス転送で読みこぼしが起きる結果、フレーム
データを UVC データが再構築する（データ片を集積してフレーム
データを完成させる）際に、不正なフレームデータが出来てしま
う（内容の一部が欠落したフレームデータが出来てしまう）、と
いうのが、今回問題となっている状況ですよね。

で、フレームデータを正しく再構築できたかどうかというのは、
UVC ドライバのレベルでは、知ることができません。UVC の場合、
フレームデータ片を UVC パケットへ載せる際、それがフレーム先頭
なのかということと、フレーム末尾なのかということは知ることが
できるのですが、フレーム全体のサイズは、（UVC デバイスから
ホストに）伝送されないからです。

UVC のコントロール転送において、フレームの最大サイズを知る
ことはできますが、各フレームのサイズを知ることは、できません。

従って、UVC ドライバが再構築したフレームデータの内容が不正な
ものでないかどうかは、UVC ドライバの上位レイヤで判定する、と
いうのが自然な設計となるんじゃないかと思います。

>で、そういうエラーまでをもアプリレベルで面倒を見る必要はない
>のではないかな？と思った次第です。

というわけで、面倒を見るとしたら、V4L のレイヤか、または
アプリケーション自身になるでしょう。たしかに、アプリケーション
より下のレイヤでやってもらう方が嬉しいので、せめて V4L で面倒
を見て欲しい気はしますが ;-)

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