FAQ

H.264ストリーミングのデコードでブロックノイズが発生したときは?

ブロックノイズはH.264ストリーミングのデータが欠落すると発生します。データが欠落しやすい場所は以下の 2ヶ所です。

  • 伝送経路
  • アプリケーションの遅延

通信プロトコルに UDPを使用する RTP などでは、Armadilloまでの伝送経路でパケットロスが発生していないか確認してください。伝送経路に問題がない場合は、デコードアプリケーションが受信パケットを取りこぼしていないか確認してください。

受信パケットの取りこぼしは、以下のコマンドで確認出来ます。

cat /proc/[プロセスID]/net/udp

実行例

[armadillo ~]# ps
PID   USER     TIME   COMMAND
  :
 4263 root       0:00 gst-launch-1.0 -v rtpbin name=rtpbin latency=100 udpsrc caps= application/x-rtp,media=(st
 4265 root       0:00 [rto_h264_messag]
   :
[root@armadillo840-0 (pts/0) ~]# cat /proc/4263/net/udp
  sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode ref pointer drops
   31: 00000000:1388 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 4845 2 8a736040 137

上の例では PID 4263 の gst-launch-1.0 で 137パケットの取りこぼしを確認することが出来ます。

Armadillo-800 シリーズ上でビットレート3Mbps程度以上のストリーミングをデコードすると、この問題が発生することが確認されています。受信パケット取りこぼしは、受信バッファのサイズを適切な値に拡大することで解消される可能性があります。

受信バッファのサイズをデフォルトの10倍に拡大する例

[armadillo ~]# cat /proc/sys/net/core/rmem_max
163840
[armadillo ~]# cat /proc/sys/net/core/rmem_default
163840
[armadillo ~]# echo > /proc/sys/net/core/rmem_max 1638400
[armadillo ~]# echo > /proc/sys/net/core/rmem_default 1638400

受信バッファのサイズを拡大しても取りこぼしが改善されない場合は、デコードアプリケーションの処理速度を改善する必要があります。