いろいろ考察した結果大抵のケースでは上り回線の品質(通信最適化)が悪いとなりました

この現象に陥っている配信者さんの枠にお邪魔して、詳しくお話をお伺いしたり、検証に参加したりしました
うち2件は、Softbank Air を利用中に陥っているようです
ネット上の記事を見る限りは、通信の最適化が上りで行われている可能性が高いと読み取れました

Pixiv Sketch Live上でブロックノイズ等発生し、画面が常に または 高頻度で乱れてしまう配信者さんから、
配信環境に関するお話が聞けたものを個人的にまとめています。

ユーザーさんA：Windows 7(x64) / CPU C2Q 8200(2.33GHz) / RAM 7GB(7?)　/ ATI radeon HD 4600
PhotoShop , TVP Animation 10 Pro / WiFiで接続 / Chrome 64.0.3282.167 x64
セキュリティソフトは Kaspersky
※sketch live サービス開始当初は問題なく配信出来ていたとの事
(恐らく、HLS環境に移行する前の話なので、エンコードの影響を受けていない状態？)

ユーザーさんB：WiFiで接続

ユーザーさんC：有線で接続 / Sai / アプリケーション選択で配信

ユーザーさんD：有線(ADSL)で接続 / Win7 / Sai / Chrome / メモリ8G (配信時は消費30%程で、負荷は高くなさそうなイメージ) / GeForce GT730 / i5-760(2.80GHz)

ユーザーさんE：ClipStudio / Chrome / アプリケーション選択で配信 / グラボはAMD製ではないはず、との事

ユーザー6(Jさん)：ADSL回線

ユーザー7(Yさん)：CPU A10-7700K 3.4GHz , グラフィック:Radeon HD 8770 (ずっとではないが、それなりの頻度でキャンバス映像の乱れが発生)
(OEM 中身はHD7770との事？)

ユーザー8(Mさん)：Softbank Air で接続が不安定 / iPhoneのインターネット共有 機能を使うと、接続は安定しやすい(が、映像は乱れる)
i5-6500 3.20Ghz / Mem 16G / Intel HD 530 / GeForce GTX 560 (グラフィックはこちらが利用されている模様)
3月下旬に実装された低画質モードでの配信でも乱れる模様
このスペックで映像が乱れるとは考えにくいので、回線の問題(特に上り？)説が濃厚
一旦の結論を、回線品質とすることに
WiMAX2+からソフトバンクエアーへの乗り換え。比較してやめた。

ユーザー9(Eさん)：
↓同じく上り速度が2.3MBps前後なのにもかかわらず、接続が切れない別の配信者さん
YahooWifi ymobile pocket wifi 上り 2.39で、快適に配信出来ている
YmobileのポケットWifi502 HW
既に新規の申込受付を終了している、3000円ほどの使い放題のプラン → Y!Fi（ワイファイ）データプラン2（4G/LTE）だそうです

ユーザー10(Cさん)：
win10 Home x64 / i7-6700K 4GHz / メモリ16G / GTX 660 1GB
Softbank Air 利用 / 最初は安定していたが、途中から常時映像の乱れが起こるように。
マイクをONにしていると、映像だけではなく音声チャンネルにも乱れが生じる
一度速度を測ったところ、上りは　1.68Mbps (210.58kB/sec)　との事(午後8時ごろ)
http://horobi.com/Saiteika/にて検証を行って貰った所、最適化なしのOKであったとの事
(※ただし、下りのみ判定であれば、肝心の上りが最適化されているかは検証不可能)
(安定している方) WiMAX2+ギガ放題という一番高いプラン / wimax W03 との事
http://iphone-apple.net/archives/3328 (紹介されている一番上のプラン)


【公式のヘルプをいくつかピックアップ】
SKETCH - Photoshopで画面共有をしようとしたのですが、キャンバスや画像が表示されません
SKETCH - 不具合が起こった場合の対処方法
SKECT - ライブ機能について
SKETCH - ライブが配信できるブラウザは？


【その他のこと】
「配信のサムネイルは、およそ10分周期で生成される」というのが前提として、
映像がほぼ常に乱れている配信は、サムネイルがなかなか更新されない現象を観測している。
↑映像に乱れの招じていない配信でも、なかなか生成されないケースは普通にあった

サムネイルの生成+アップロードは handleHeartbeat からの createThumbnailFromVideo 経路で行われているならば、
サーバーの障害ではなく、配信PC(クライアント)側で問題が起きていると推測される？

上り回線 or ブラウザ(やPC環境) が原因なのかなあ、と思ってはいるのですが、はてさて..(素人並みの感想)

CPU i7-3960X と i7-3930kでChrome視聴→カクカク
FireFoxに切り替えると快適、という体験談アリ。

CPUやGPU、メモリ等のスペックや負荷が原因？

全てのユーザーさんから、OSから内蔵のグラフィック機能まで情報を聞き取りはしていないのですが、
負荷だけが原因として説明はつきにくいと思っています

ノートPCで映像の乱れ無く配信している方もいれば、
負荷の少なそうな環境でこの現象が起きている方もいらっしゃいました

画面を取り込む過程で、特定の機構を利用しているソフトやハードでこの現象が発生する..
とかならまだ分かるのですが、CPU/メモリ/グラフィックの三大スペックに絞る限りは、
映像乱れの共通性を自分は見いだせていません

同時に起動している何かしらのソフトが原因？

負荷路線とは別に、常駐させているソフトが画面取り込み or データの送信過程で悪さをしている。
これも考えにくいですが、かろうじてありそうならセキュリティソフトでしょうか。

ユーザーさんの一人がセキュリティソフトで Kaspersky を利用していました。

また、セキュリティソフトが関係するにしても、ポート単位でブロックするでしょうし、
データの一部を送信前に加工・フィルタリングする
→その結果、アップロードされる映像が乱れる、というのもなさそうな話だと自分は思うのですが..

回線の遅さが原因

Wifiや回線の遅さが原因かな？とも思いましたが、
そうであれば接続が頻繁に止まるほうが自然なのかなと思いました。

PCをWifiで利用されている方もいれば、有線で繋いでいる方も居るようです
流石にWifiの規格や強度まで聞き取りは行っていないのですが。

運営側のサーバー負荷が原因

重い時間帯が存在しているので、そういった所も関係しているのかなと思ったのですが、
深夜帯(AM2:00とか)明け方・早朝レベルでも乱れる現象に遭遇していますし、
重い時間帯でも(遅延などはありますが)高画質で視聴できる配信者さんも沢山いらっしゃるので、
純粋にサーバーが重いから乱れる、という説明はつきにくいと考えています

運営側のサーバー負荷が原因 その2

大前提として【特定のユーザーがこの現象に陥りやすい】というものがあります。
それゆえに、ユーザーのID(何かしらの規則性)で処理を行うサーバーを割り振っており、
その一部のサーバーで、障害や高負荷による映像処理(入力or変換or出力)の乱れが生じている可能性
..というのも考えました。

ちなみに、この現象に陥っているユーザーさんが別アカウントで配信した所、
映像品質の改善は行われませんでした...

回線の品質(経路)が原因

詳しく回線の内容を聞き取っていないのですが、うち2件、ADSLであるとのお話を聞いています
また、Sonfbank Air を利用していると必ずなる (そして、回線を他に変えると乱れはなくなる)という話が2件ありました

環境によって乱れが発生する ＝ スペック,エンコード関連での相性の悪さ と考える
この場合、利用している技術(WebRTC)に関する物との関連性を調べた方が良いのかな？と思い、
まずは広い範囲から探りを入れて、徐々に焦点を絞っていく感じに

HLS (HTTP Live Streaming)という「配信技術」で配信されている。
m3u8 + .ts 形式

WebRTC以前の予備知識 : コーデック
H.264 , H.265

H.265（HEVC）へのハードウェアエンコード、デコードへの対応

コードを覗く限り、handleSoraInitializeメソッドで、配信用サーバに送っている情報に
videoCodecType: "H264"
が指定されているので、これに関しては H.264 のような気はする

コンテナフォーマットは .ts 形式で良いのかな？
H.264という動画コーデック(アリゴリズム形式/そういう名前の技術)でエンコード(変換)されている
用語解説辞典 - MPEG-4 AVCを見るに、H.264 = MPEG-4 AVC は同義らしい
音声コーデック：？

https://shiguredo.jp/
https://sora.shiguredo.jp/#demo-box / Sora 配信デモ

Twitter @pixivsketch / WebRTCからHLSへの仕様変更のお知らせツイート

デバッグ chrome://webrtc-internals/

.ts ファイル (高画質版)
解像度 1920*1090 表示解像度 1920*1080 FPS 24
コーデック H264 - MPEG-4 AVC (part10) (h264)
発行者:FFmpeg
オーディオ 48000 Hz 128kb

・低画質配信の解像度を弄る
this.getMaxVideoSize メソッド書き換え
"low" 時の値が 960x540 なので、これを敢えて落とす

・パラメータ操作
handleSoraInitialize メソッド内でSoraサーバーへ投げるパラメータを弄る
https://github.com/shiguredo/sora-js-sdk
全てのパラメータが鯖で受け付けられているとは限らない

配信者側は n.publisher() の第三引数で与えられているオブジェクト
videoBitRate: を与えてみたけど、明確に何かが変わったような感じはしない

https://sora.shiguredo.jp/js-sdk-doc/devguide.html
https://sora.shiguredo.jp/doc/DEMO.html
https://testrtc.com/webrtc-internals-parameters/
chrome://webrtc-internals/

観測していると、Stats graphs for bweforvideo (VideoBwe)
googAvailableSendbandwidth などのラインは下がっているみたいだった