本日、色々検証してみまして、分かったことを書きます。

送信側（優先）のPCで、whileループでひたすらsendto()しまくる単純なプログラムを動かしたところ、
何と1Gbps近く出ました！
動画圧縮・送信アプリで送信制限があるかに見えたのは、
単にエンコードのAPIが、一定以上のビットレートではデータサイズが飽和しているだけのようです。
このアプリを複数起動したところ、1プロセス×起動数分の帯域（12Mbps等）をちゃんと消費しました。

しかし、一方の受信側（無線）のタブレットPCでは、whileループでひたすらrecvfrom()しまくっても
5Mbps程度でやはり頭打ちしました。

これらはすべてUDPでの送受信ですが、
試しにTCPではどうか検証してみたところ、
フリーのFTP転送アプリで、送受信ともに、何と200Mbpsくらい出ました！

そんなバカな、と思い、自分でTCP送受信だけをひたすら行う単純なプログラムを書いて実行してみたところ、
200Mbpsには至らなかったものの、26Mbpsくらいまでは送受信ともに出せました。
なお、帯域を大きくすればするほど、送信に失敗する確率が高まる傾向が見られました。
これはTCPで見られる、受信側のバッファ枯渇によるものと思われます。
アプリ側でsetsockopt()で受信バッファを拡張してやると改善し、上記bpsに至りました。

FTP転送アプリがなぜ200Mbpsも叩き出せたかは分かりませんが、
今回の動画送受信アプリでは26Mbpsでも十分な帯域なので、結果的にはUDPからTCPに変更ことで対策が完了しました。