DEV Community: 合同会社Wandbox

WebRTC Load Testing Tool Zakuro を作った話

melpon — Thu, 24 Sep 2020 06:36:11 +0000

先日、WebRTC Load Testing Tool Zakuro がリリースされました。

Zakuro は WebRTC SFU Sora に対して負荷を掛けるためのクライアントで、自分（正確には合同会社Wandbox）が時雨堂から仕事として請けて開発したものになります。

ここでは、この Zakuro を実装するためにどんなことをしたのかを紹介します。

Zakuro の概要について知りたい場合は @voluntas さんの書いている

あたりを参照してください。

Momo から実装をコピーしてくる

Zakuro は大体 Momo と同じような機能を備えているので、Momo から以下のような実装をコピペしてきました。

Momo のビルドシステム
引数パーサー
Sora クライアント、Sora API サーバー
WebSocket、SSL などの通信周り
WebRTC の PeerConnection を確立してハンドリングする部分
カメラからのキャプチャ

その後、Zakuro を動かすために不要な部分、例えば Windows 専用のコード（Linux で動けば良い）、SDL を利用しているコード（受信側は不要）、ハードウェアエンコーダのコード（ハードウェアエンコーダは使わない）などを削除していきました。

これでひとまずビルドが通り、Zakuro でカメラキャプチャした映像が Sora Labo などで見れるようになりました。

複数クライアントに対応する

Momo は 1 プロセス 1 クライアントで接続しますが、Zakuro は大量のクライアントを接続して負荷を掛けるツールなので、複数クライアントに対応する必要があります。
これは元の Momo のコードが整理されていたので、RTCManager と SoraClient をクライアントの数だけ生成すれば動きました。

こんなコードになります。

class VirtualClient {
 public:
  VirtualClient(boost::asio::io_context& ioc,
                rtc::scoped_refptr<ScalableVideoTrackSource> capturer,
                RTCManagerConfig rtcm_config,
                SoraClientConfig sorac_config) {
    rtc_manager_.reset(
        new RTCManager(std::move(rtcm_config), std::move(capturer), nullptr));
    sora_client_ =
        SoraClient::Create(ioc, rtc_manager_.get(), std::move(sorac_config));
  }

  void Connect() { sora_client_->Connect(); }
  void Clear() { sora_client_.reset(); }

 private:
  std::unique_ptr<RTCManager> rtc_manager_;
  std::shared_ptr<SoraClient> sora_client_;
};

このように実装して、--vcs オプションで指定された数だけクライアントを生成するだけで Sora 側に負荷を掛けれるようになりました。

ただし、このまま一気に大量のクライアントを接続するのは Sora に接続時の負荷が掛かり過ぎるし、現実にも則していないので、徐々に接続するための --hatch-rate オプションも実装しました。

Safari みたいな Fake 映像/音声を実装する

Safari には Fake 映像/音声を生成するためのデバイスが用意されていて、そのデバイスを使うとこんな表示になります。

スクリーンショットだと分からないですが、複数のサイン波を組み合わせた音も流れています。

この Fake 映像/音声を Zakuro にも移植しました。

Fake 映像

Safari の場合、Fake 映像を作るためにグラフィックスライブラリである cairo を利用しています。
cairo は LGPL または MPL のデュアルライセンスで、まあ問題なさそうってことで当初はこれを使おうかと思っていました。

ただ、もう少し緩いライセンスのライブラリは無いかなと調べてみると Blend2D というのを見つけました。
これは Zlib ライセンスで、JIT コンパイルする上にマルチスレッド使えるとかいうなかなか凄いライブラリのようです。

どっちを使っても Fake 映像を作るには問題ないんですが、Blend2D の方が面白そうということで、Blend2D を使うことにしました。

実際使ってみた感じ、ほぼ問題なく使えて Fake 映像が実装できてしまったのであまり書くことは無いんですが、ちょっと嵌った点としては以下の2点ぐらいです。

BLContext の rotation や translate がどういう順番で適用されるかが分からなくてちょっと時間を使いました。実験コード書いてみた感じ、最後に書いたのから順番に適用されていくようです（OpenGL と同じ）。
点線がどういう風に書いても反映されなくて、おかしいなーって調べてみたら、点線は未実装でした (#48)。なので点線を表示するのは諦めています。

あとはこの生成した画像をあたかもカメラから取り込んだかのようにエンコーダに送ってやると、映像がエンコードされて Sora に送信されます。

最終的な Fake 映像の実装は zakuro/fake_video_capturer.cpp at develop · shiguredo/zakuro にあります。

これで以下のような Fake 映像になりました。

Fake 音声

Safari の Fake 音声を調べると、プログラム上で以下の4種類のサイン波を生成していることが分かります。

hum 音。150 Hz で常時鳴り続けてる。
noise 音。3000 Hz で常時鳴り続けてる。
bip 音。1500 Hz で、bop 音の1秒後に一瞬だけ鳴る。
bop 音。500 Hz で、bip 音の1秒後に一瞬だけ鳴る。

Safari の Fake 音声の場合、ノイズキャンセリング機能を ON にしてると noise 音が消えるという実装が入ってましたが、Zakuro では実装していません。

Fake 音声は、これらのサイン波の合成をプログラムで作ってやるだけなので、作るのはすごく簡単でした。

大変だったのは、このデータを渡す部分です。
Fake 音声を生成して録音したデータとしてエンコードしてもらうには、AudioDeviceModule (ADM) を自前で実装する必要があります。
audio_device.h を見れば分かるように、ADM が要求している関数は凄い大量にあり、今のところ 58 個の純粋仮装関数を実装する必要があります。
大抵は無視するか何もしないで 0 を返せばいいだけなんですが、中にはちょっとした処理を書かないといけない部分もあってなかなか大変でした。

最終的な Fake 音声の実装は zakuro/zakuro_audio_device_module.cpp at develop · shiguredo/zakuro にあります。

映像と音声の受信を無視する

Zakuro は Sora クライアントとして振る舞うので、映像と音声の受信も出来る必要があります。
しかし、これらの映像を表示したり、音声を再生したりといったことをすると、その環境でのデバイスが必要になってしまうため、動かせる場所が限定されてしまいます。
そのため、映像データと音声データを受信した上で破棄する処理が必要になります。

映像に関しては、デコーダで CPU を使うのが勿体ないので、何もしないデコーダを作りました。こんな感じになっています。

class NopVideoDecoder : public webrtc::VideoDecoder {
 public:
  int32_t InitDecode(const webrtc::VideoCodec* codec_settings,
                     int32_t number_of_cores) override {
    return WEBRTC_VIDEO_CODEC_OK;
  }

  int32_t Decode(const webrtc::EncodedImage& input_image,
                 bool missing_frames,
                 int64_t render_time_ms) override {
    if (callback_ == nullptr) {
      return WEBRTC_VIDEO_CODEC_UNINITIALIZED;
    }

    // 適当に小さいフレームをデコーダに渡す
    rtc::scoped_refptr<webrtc::I420Buffer> i420_buffer =
        webrtc::I420Buffer::Create(320, 240);

    webrtc::VideoFrame decoded_image =
        webrtc::VideoFrame::Builder()
            .set_video_frame_buffer(i420_buffer)
            .set_timestamp_rtp(input_image.Timestamp())
            .build();
    callback_->Decoded(decoded_image, absl::nullopt, absl::nullopt);

    return WEBRTC_VIDEO_CODEC_OK;
  }

  int32_t RegisterDecodeCompleteCallback(
      webrtc::DecodedImageCallback* callback) override {
    callback_ = callback;
    return WEBRTC_VIDEO_CODEC_OK;
  }

  int32_t Release() override { return WEBRTC_VIDEO_CODEC_OK; }
  bool PrefersLateDecoding() const override { return false; }
  const char* ImplementationName() const override { return "NOP Decoder"; }

 private:
  webrtc::DecodedImageCallback* callback_ = nullptr;
};

何もしないとか言いつつ小さいフレームを生成して渡しているのは、WebRTC はいろんな場所の統計情報を使って処理を変えているため、ここで結果を作って渡してやらないと、どこかで不整合が起きるんじゃないかと思ったからです。

あとはこの NopVideoDecoder を生成する factory を実装して…

class NopVideoDecoderFactory : public webrtc::VideoDecoderFactory {
 public:
  std::vector<webrtc::SdpVideoFormat> GetSupportedFormats() const override {
    std::vector<webrtc::SdpVideoFormat> supported_codecs;
    supported_codecs.push_back(webrtc::SdpVideoFormat(cricket::kVp8CodecName));
    for (const webrtc::SdpVideoFormat& format : webrtc::SupportedVP9Codecs()) {
      supported_codecs.push_back(format);
    }
    return supported_codecs;
  }

  std::unique_ptr<webrtc::VideoDecoder> CreateVideoDecoder(
      const webrtc::SdpVideoFormat& format) override {
    return std::unique_ptr<webrtc::VideoDecoder>(
        absl::make_unique<NopVideoDecoder>());
  }
};

cricket::MediaEngineDependencies::video_decoder_factory に NopVideoDecoderFactory を設定するだけです。

media_dependencies.video_decoder_factory.reset(new NopVideoDecoderFactory());

これで映像データを受信して無視するようになりました。

音声に関しては、せっかく Fake 音声で ADM を実装したので ADM で音声データを無視するようにしました。
これだと音声のデコード処理は走ってしまいますが、映像データに比べれば大したことは無いと思うのでこのままにしています。
これで音声データも受信して無視するようになりました。

フォントを Zakuro バイナリに埋め込む

Blend2D は ttf 形式のフォントを読んで利用できるので、最初は macOS や Ubuntu の標準フォントのパスを適当に指定して表示していました。
ただ、これだと CentOS や他の OS 向けにビルドを追加する際に毎回フォントパスを探すことになってしまいます。
流石にそれは大変そうなので、Zakuro にフリーフォントを同封することにしました。

利用するフォントは Kosugi です。
Google Fonts の中から日本語が扱えて Apache ライセンスのものを探しました。

で、この Kosugi フォントを同封することにはしたのですが、Zakuro は今まで単体のバイナリで動くようになっていたので、出来れば変わらず単体で動かしたいところです。
なので Zakuro バイナリにフォントデータを埋め込むことにしました。

一番最初に考えたのは、フォントデータを C のソースに変換することです。

// 以下のコードを Kosugi.ttf ファイルから自動生成する
const char KOSUGI_TTF[] = {
  0x00, 0x01, 0x00, 0x00, 0x00, 0x0f, 0x00, 0x80,
  0x00, 0x03, 0x00, 0x70, 0x47, 0x53, 0x55, 0x42,
  ...
};

このようなコードを自動生成してコンパイルすれば、フォントデータを Zakuro バイナリに埋め込めます。

ただし、これはコードを自動生成するためのツールが必要になってきます。
公式に対応する予定は無いですが、Zakuro は一応 macOS でもビルド可能になっているため、macOS, Ubuntu, CentOS 上で動くコードの自動生成ツールが必要になります。
このようなツールを作るのも探すのも手間だし、そのツールのメンテナンスも必要になってきて大変なので、この方法は諦めることにしました。

もう少し調べてみると、Linux の場合、ld コマンドや objdump コマンドで、バイナリをそのまま .o ファイルに変換できることが分かりました。

$ ld -r -b binary Kosugi.ttf -o Kosugi.o
$ nm Kosugi.o
00000000001d4648 D _binary_Kosugi_ttf_end
00000000001d4648 A _binary_Kosugi_ttf_size
0000000000000000 D _binary_Kosugi_ttf_start

macOS の場合は、リンク時に -sectcreate <segment名> <section名> <対象ファイル> という指定をすると、そのファイルを指定したセクションに埋め込めるようです。

これらを利用すれば Zakuro バイナリにフォントデータを埋め込んでビルドできるということが分かりました。あとは CMake にバイナリを埋め込むコードを書いて、

if (TARGET_OS STREQUAL "macos")
  # バイナリの組み込み
  target_link_options(zakuro PRIVATE -sectcreate __DATA __kosugi_ttf Kosugi.ttf)
elseif (TARGET_OS STREQUAL "linux")
  # バイナリの組み込み
  add_custom_command(OUTPUT kosugi_ttf.o
    COMMAND ld
    ARGS -r -b binary -o ${CMAKE_CURRENT_BINARY_DIR}/kosugi_ttf.o ${CMAKE_CURRENT_SOURCE_DIR}/Kosugi.ttf
    MAIN_DEPENDENCY ${CMAKE_CURRENT_SOURCE_DIR}/Kosugi.ttf)
  set_source_files_properties(kosugi_ttf.o
    PROPERTIES
      EXTERNAL_OBJECT true
      GENERATED true
  )
  target_sources(zakuro PRIVATE kosugi_ttf.o)
endif()

macOS と Linux で共通してバイナリを返すクラスを作ってやるだけです。

#ifndef EMBEDDED_BINARY_H_
#define EMBEDDED_BINARY_H_

#ifdef __APPLE__
#include <mach-o/getsect.h>
#include <mach-o/ldsyms.h>
#endif

struct EmbeddedBinaryContent {
  const void* ptr;
  size_t size;
};

class EmbeddedBinary {
 public:
  static EmbeddedBinaryContent kosugi_ttf() {
#ifdef __APPLE__
    size_t size;
    const void* ptr =
        getsectiondata(&_mh_execute_header, "__DATA", "__kosugi_ttf", &size);
#else
    extern const unsigned char _binary_Kosugi_ttf_start[];
    extern const unsigned char _binary_Kosugi_ttf_end[];
    const void* ptr = _binary_Kosugi_ttf_start;
    size_t size =
        _binary_Kosugi_ttf_end - _binary_Kosugi_Regular_ttf_start;
#endif
    EmbeddedBinaryContent content;
    content.ptr = ptr;
    content.size = size;
    return content;
  }
};

#endif

こうすることで、無事 Zakuro バイナリにフォントを埋め込んで利用できるようになりました。

y4m ファイル、wav ファイルからのキャプチャを用意する

Zakuro は Fake 映像/音声だけではなく、指定した y4m ファイルや wav ファイルを流すことができます。

y4m ファイルは、YUV 形式の生データが並んでいる動画ファイルです。
これのパーサは探せばいくつかあったんですが、欲しい要件を満たすのが無かったのと、フォーマットを見てみると割と簡単だったので自前でパーサを書きました。

欲しかった機能は、

YUV420 形式のデータが取得できること
y4m は相当でかいファイルになることが予想されるので、メモリ上に全データを読まずにロードできること
WebRTC に送信する FPS と動画の FPS が一致しているとは限らないので、「何ミリ秒時点のフレームが欲しい」という要求をすればそこのフレームが取得できること
ファイルの終端を超えた時間を要求されたら、ループして最初から再生できること

あたりです。y4m_reader.cpp ではそのあたりに対応しています。

wav ファイルも、用途を限定すれば難しいフォーマットじゃないので、これも自前のパーサを書きました。

これはそんな大したサイズにならないだろうと思ったので、全データをメモリ上に乗せています。

これらを使って Fake 映像/音声の代わりに送信することで、無事 y4m と wav ファイルの映像/音声を流すことが出来るようになりました。

OpenH264 に対応する

Zakuro は VP8/VP9 に対応しているので H.264 にも対応したいところですが、基本的に H.264 を利用するにはライセンス費用を払う必要があります。
ただし、Cisco がビルドして公開している OpenH264 バイナリを利用すれば、Cisco がライセンス費用を肩代わりしてくれます。
なので Cisco が公開している OpenH264 バイナリを使って H.264 に対応しました。

Zakuro に --openh264 <libopenh264.so の絶対パス> を指定すれば、H.264 で映像を流せるようになります。

実装としては、WebRTC は OpenH264 を使ったエンコード機能を既に持っているので、これをコピーしてきて、OpenH264 の呼び出しを動的なものに書き換えただけです。

これで無事、Cisco の公開している OpenH264 バイナリを使った H.264 エンコードに対応できました。

WebRTC の利用する OpenH264 について

上記で WebRTC のソースを利用しているのを見れば分かるように、WebRTC ライブラリはデフォルトで OpenH264 に対応しています。
しかしこれは、OpenH264 のソースを組み込んでビルドしたもので、「Cisco がビルドして公開している OpenH264 バイナリ」を利用したものではありません。
そのため WebRTC ライブラリにデフォルトで入っている H.264 エンコーダを利用するとライセンス費用が発生してしまいます（ブラウザ経由で使う分には Google とか Mozilla が何とかしてくれるので問題ないです）。

そのあたりの問題があるため、Zakuro が依存している shiguredo-webrtc-build/webrtc-build のビルド済みバイナリでは、全て OpenH264 を無効にして提供しています。

その上で、Zakuro では Cisco がビルドして公開している OpenH264 バイナリを利用して H.264 エンコードを復活させたということになります。

まとめ

このような機能を入れて、無事 Zakuro はリリースされました。
いろいろ面白いことができて楽しかったです。

今後もいろいろと改善/開発をやっていく予定なので、Sora に負荷を掛けてみたいということがあれば使ってみてください。

Sora Unity SDK を iOS 対応した話

melpon — Mon, 17 Aug 2020 03:54:20 +0000

Sora Unity SDK は WebRTC SFU Sora の Unity クライアントです。
Sora Unity SDK は既に Windows と macOS と Android で動くようになっているのですが、今回新しく iOS に対応しました。

// Detect dark theme var iframe = document.getElementById('tweet-1293518685143879681-105'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1293518685143879681&theme=dark" }

この記事では、この対応のために具体的にどんなことをしたのかについて書きます。

iOS 対応の PR はこのあたりです。全体を見たい時に確認してください。

iOS 用 WebRTC を作る PR
- iOS ビルドに対応 by melpon · Pull Request #6 · shiguredo-webrtc-build/webrtc-build
- iOS 用パッチを適用する by melpon · Pull Request #7 · shiguredo-webrtc-build/webrtc-build
それを使って Sora Unity SDK 本体を iOS に対応する PR
- iOS に対応 by melpon · Pull Request #9 · shiguredo/sora-unity-sdk
Sora Unity SDK のサンプル更新
- Sora Unity SDK 2020.7 を利用する by torikizi · Pull Request #6 · shiguredo/sora-unity-sdk-samples

WebRTC の iOS ビルドを作る

Sora Unity SDK を iOS で動かせるようにするには、まず iOS 用の WebRTC ライブラリが必要です。

iOS 用の WebRTC ライブラリは、時雨堂の shiguredo/shiguredo-webrtc-build を置き換える目的もあるので WebRTC.framework を生成しています。

WebRTC.framework は WebRTC のソースに入っている tools_webrtc/ios/build_ios_libs.sh を叩くことで生成できます。こんな感じに利用します。

  ./tools_webrtc/ios/build_ios_libs.sh -o $BUILD_DIR/webrtc --build_config release --arch $TARGET_ARCHS --bitcode --extra-gn-args " \
    rtc_libvpx_build_vp9=true \
    rtc_include_tests=false \
    rtc_build_examples=false \
    rtc_use_h264=false \
    use_rtti=true \
    libcxx_abi_unstable=false \
  "

これで WebRTC.framework が生成できます。
ただし、Unity ではこのライブラリは利用しません。代わりにいつものように自前で GN と ninja を叩いて libwebrtc.a を生成して利用します。

これは他のライブラリと同じような感じでビルドするだけですが、iOS はユニバーサルライブラリが利用可能なので、x86_64 と ARM64 用のライブラリを 1 個の libwebrtc.a にまとめるところが違います。

こんな感じのコードになります。

    # x86_64 用
    gn gen $BUILD_DIR/webrtc/x64_libs --args="
      ... # いろいろ引数を入れる
    "
    ninja -C $BUILD_DIR/webrtc/x64_libs
    # ar でまとめて x86_64 用の libwebrtc.a を生成
    pushd $BUILD_DIR/webrtc/x64_libs/obj
      ar -rc $BUILD_DIR/webrtc/x64_libs/libwebrtc.a `find . -name '*.o'`
    popd

    # ARM64 用
    gn gen $BUILD_DIR/webrtc/arm64_libs --args="
      ... # いろいろ引数を入れる
    "
    ninja -C $BUILD_DIR/webrtc/arm64_libs
    # ar でまとめて ARM64 用の libwebrtc.a を生成
    pushd $BUILD_DIR/webrtc/arm64_libs/obj
      ar -rc $BUILD_DIR/webrtc/arm64_libs/libwebrtc.a `find . -name '*.o'`
    popd

    # x86_64 と ARM64 の libwebrtc.a をまとめてユニバーサルライブラリにする
    lipo \
      $BUILD_DIR/webrtc/x64_libs/libwebrtc.a \
      $BUILD_DIR/webrtc/arm64_libs/libwebrtc.a \
      -create \
      -output $BUILD_DIR/webrtc/libwebrtc.a

また、iOS 用の WebRTC は、デフォルトの実装では受信専用の場合でも録音の権限を要求してしまうため、不要な権限の要求ということで Apple の審査に落ちることがあるようです。
shiguredo/shiguredo-webrtc-build ではその問題を解決するためのパッチも用意されているので、そのパッチも当てています。

詳細は shiguredo-webrtc-build/patch_shiguredo_ios.md at develop · shiguredo/shiguredo-webrtc-build を参照して下さい。

このパッチを当てているため、Sora Unity SDK の iOS 版は受信専用の場合にマイクの権限を要求しません。

Sora Unity SDK を iOS ビルドする

これは普通に CMake に設定を追加するだけです。

CMake は 3.14 以上なら iOS ビルドに対応しているため、ちょっと設定をいくつか入れてやるだけです。

Sora Unity SDK のコードを iOS に対応する

iOS 専用の処理をいくつか入れてやる必要があります。

ただし、大体のコードは macOS と共通なので、そこまで変更する量は多くありません。

プラグインの登録を行う

Windows, macOS, Android では、ライブラリのロード時に UnityPluginLoad が、アンロード時に UnityPluginUnload が呼ばれるという仕組みがあり、この時に IUnityInterfaces を渡してもらうことで、Unity の機能をネイティブで触れるようになっています。

しかし iOS は静的ライブラリなので、この関数をエクスポートしていても呼ばれることはありません。
IUnityInterfaces を渡してもらうには、UnityRegisterRenderingPluginV5 関数を使ってロード時、アンロード時の関数を明示的に登録してやる必要があります。

調べた感じだと、この関数は本来、Unity の iOS 用ビルドをして生成された UnityAppController:shouldAttachRenderDelegate を実装して、その中で呼ぶのが良さそうなのですが、ここを弄るのは大変そうだったので、Sora オブジェクトを生成する時に一度だけ UnityRegisterRenderingPluginV5 関数を呼ぶようにしました。

#if defined(SORA_UNITY_SDK_IOS)
// PlaybackEngines/iOSSupport/Trampoline/Classes/Unity/UnityInterface.h から必要な定義だけ拾ってきた
typedef void (*UnityPluginLoadFunc)(IUnityInterfaces* unityInterfaces);
typedef void (*UnityPluginUnloadFunc)();
void UnityRegisterRenderingPluginV5(UnityPluginLoadFunc loadPlugin,
                                    UnityPluginUnloadFunc unloadPlugin);

bool g_ios_plugin_registered = false;

void UNITY_INTERFACE_API SoraUnitySdk_UnityPluginLoad(IUnityInterfaces* ifs);
void UNITY_INTERFACE_API SoraUnitySdk_UnityPluginUnload();
#endif

void* sora_create() {
#if defined(SORA_UNITY_SDK_IOS)
  if (!g_ios_plugin_registered) {
    UnityRegisterRenderingPluginV5(&SoraUnitySdk_UnityPluginLoad,
                                   &SoraUnitySdk_UnityPluginUnload);
    g_ios_plugin_registered = true;
  }
#endif
  ...
}

これで問題なく動いているので多分大丈夫だと思います。

ロード時、アンロード時の関数名を UnityPluginLoad ではなく SoraUnitySdk_UnityPluginLoad などとしているのは、iOS が静的ライブラリであるため、他のライブラリをリンクした際に UnityPluginLoad という関数名が衝突する可能性があるからです。

C#, C++ 間のインターフェースから bool を除ける

Sora Unity SDK を iOS の実機で動かしてみると、特定の C++ の関数を呼び出した時に、変な値が C++ に渡って落ちるという現象が起きました。
調査してみると面白いことが分かったので書いておきます。

C# から C++ のコードを呼び出すために P/Invoke を利用するわけですが、Unity iOS の場合はここはいい感じに IL2CPP で C++ に変換して呼んでくれます。

C# 上で、sora_connect 関数は以下の extern 宣言になっています（引数が多いのは気にしなくて良いです）。

#if UNITY_IOS && !UNITY_EDITOR
    [DllImport("__Internal")]
#else
    [DllImport("SoraUnitySdk")]
#endif
    private static extern int sora_connect(
        IntPtr p,
        string unity_version,
        string signaling_url,
        string channel_id,
        string metadata,
        string role,
        bool multistream,
        int capturer_type,
        IntPtr unity_camera_texture,
        string video_capturer_device,
        int video_width,
        int video_height,
        string video_codec,
        int video_bitrate,
        bool unity_audio_input,
        bool unity_audio_output,
        string audio_recording_device,
        string audio_playout_device,
        string audio_codec,
        int audio_bitrate);

この関数を呼ぶコードを書いて、Unity から iOS 用にビルドすると以下のような C++ コードが生成されます。

int32_t returnValue = reinterpret_cast<PInvokeFunc>(sora_connect)(
  ___p0,
  ____unity_version1_marshaled,
  ____signaling_url2_marshaled,
  ____channel_id3_marshaled,
  ____metadata4_marshaled,
  ____role5_marshaled,
  static_cast<int32_t>(___multistream6),
  ___capturer_type7,
  ___unity_camera_texture8, 
  ____video_capturer_device9_marshaled,
  ___video_width10,
  ___video_height11,
  ____video_codec12_marshaled,
  ___video_bitrate13,
  static_cast<int32_t>(___unity_audio_input14),
  static_cast<int32_t>(___unity_audio_output15),
  ____audio_recording_device16_marshaled,
  ____audio_playout_device17_marshaled,
  ____audio_codec18_marshaled,
  ___audio_bitrate19);

PInvokeFunc は以下の typedef になっています。

typedef int32_t (DEFAULT_CALL *PInvokeFunc) (
  intptr_t, char*, char*, char*, char*, char*, int32_t,
  int32_t, intptr_t, char*, int32_t, int32_t, char*, int32_t,
  int32_t, int32_t, char*, char*, char*, int32_t);

ここでよく見ると、sora_connect 関数にあった bool 型の引数が int32_t 型になっていることが分かります。

C#(というか生成した C++ コード)側では、int32_t 型であるため4バイトのデータとしてスタックに積んで関数を呼び出しているのに、C++ 側では1バイトのデータとしてスタックから取り出している処理になってしまうわけです。
そのため C++ 側の引数が変な値になってしまって落ちていました。

実のところ、アライメントのおかげで bool を使ったら即落ちるという訳でもないのですが、今回に関しては bool が 2 個連続で並んでる引数 bool unity_audio_input と bool unity_audio_output があったので、ここで引数がずれてしまって落ちました。

とにかく Unity の IL2CPP が bool を int32_t として扱うというのは変えようが無さそうなので、諦めて C++ のインターフェースとして bool を使うのはやめるようにしました。

typedef int32_t unity_bool_t; と定義して、bool の部分を unity_bool_t に置き換えていったら、無事 sora_connect を呼んでも落ちなくなりました。

ライブラリのリンク順序を入れ替える

上記の対応で Sora Unity SDK の iOS 版は動くだろうと思ってたんですが、まだ問題がありました。
H.264 ならハードウェアエンコーダを使って無事動くのに、VP8, VP9 だと動かないという現象が起きました。

詳細にエラーを追っていくと、VP8, VP9 ソフトウェアエンコーダである libvpx のバージョンが古い、というエラーが出ていました。

libvpx は libwebrtc.a に同封されていて、古いわけがありません。
いろいろ調べた結果、Unity の iOS ビルドで必ず必要になる libiPhone-lib.a の中に、めちゃめちゃ古い libvpx が含まれていて、それが利用されていることが分かりました。

// Detect dark theme var iframe = document.getElementById('tweet-1290223856221736960-943'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1290223856221736960&theme=dark" }

ググってみると、３年前に同じようなことで困ってる人が見つかりましたが、これは未回答のようでした。

Unity statically links libvpx, any way to prevent this in a build? - Unity Answers

なので頑張って調べた所、Xcode 用のプロジェクトを生成した後、

この libiPhone-lib.a を、

このように libwebrtc.a より後ろにしてやると、無事 libwebrtc.a の libvpx が使われるようになることが分かりました。

ほんとにこんなのでいいのか？って思ったんですが、

// Detect dark theme var iframe = document.getElementById('tweet-1290243855032266753-16'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1290243855032266753&theme=dark" }

ということらしいし、リンク先のをよく見てリンクのルールを考えると確かに問題無さそうなので安心です。

あとはこれをプログラム上で実現するだけです。Unity なら以下のようなコードを書くだけで実現できました。

public class SoraUnitySdkPostProcessor
{
    [PostProcessBuildAttribute(500)]
    public static void OnPostprocessBuild(BuildTarget buildTarget, string pathToBuiltProject)
    {
        var projPath = pathToBuiltProject + "/Unity-iPhone.xcodeproj/project.pbxproj";
        PBXProject proj = new PBXProject();
        proj.ReadFromFile(projPath);
        // 2020.3 より前か後かで処理が変わる
#if UNITY_2019_3_OR_NEWER
        string guid = proj.GetUnityFrameworkTargetGuid();
#else
        string guid = proj.TargetGuidByName("Unity-iPhone");
#endif

        // ライブラリを追加したりとかのいろいろな設定

        // libiPhone-lib.a 削除して追加するとリンク順序が一番後ろに行く
        string fileGuid = proj.FindFileGuidByProjectPath("Libraries/libiPhone-lib.a");
        proj.RemoveFileFromBuild(guid, fileGuid);
        proj.AddFileToBuild(guid, fileGuid);

        proj.WriteToFile(projPath);
    }
}

これで無事、VP8, VP9 での送受信に成功しました。

いろいろやる

その他、ADM をワーカースレッドで作るようにしたり、カメラの回転に対応したり、マイク権限を要求しないパッチでうまく再生できないのを回避するためのコードを追加したり、Metal の一部機能が iOS で使えないので除けたりといったことをしました。

ただ詳細に説明するほど面白いことは無かったので省略します。

感想

当初の想定では、既に macOS で Metal にも対応してたし、ビデオエンコーダ/デコーダも Objective-C のコードをちょっと呼ぶだけというのは分かってたので、ほぼ何もしなくても動くんじゃないかと思っていました。

が、上記の通り、実際にやってみると結構いろいろと罠を踏んで大変でした。でも無事動いて良かったです。

Sora Unity SDK を NVDEC に対応した話

melpon — Sat, 20 Jun 2020 07:37:42 +0000

Sora Unity SDK は WebRTC SFU Sora の Unity クライアントです。

Sora Unity SDK は NVIDIA VIDEO CODEC SDK を使ったエンコードとデコードに対応していて、2020.1 (2/27 リリース) でエンコードに対応して、2020.2 (4/14 リリース)でデコードに対応しました。

この記事では、2020.2 でリリースされた、NVIDIA VIDEO CODEC SDK のデコーダ（NVDEC)で具体的にどんなことをしたのかについて書きます。

全体のコードは以下の PR にあります。

Windows の NvDec に対応 by melpon · Pull Request #3 · shiguredo/sora-unity-sdk

C++ よりはビルド寄りの話です。

デコーダを実装する

NVDEC を使ったデコーダを書くのは、そんなに難しくないです。難しくないというか、めちゃめちゃ簡単です。
NVIDIA VIDEO CODEC SDK はサンプルに NvDecoder.cpp というのを用意してくれています。

video-sdk-samples/NvDecoder.cpp at master · NVIDIA/video-sdk-samples

これを使って（ライセンスの確認は忘れずに）、以下のように書けばデコードが出来ます。

class NvDecoderCuda {
public:
  // 初期化
  void Init() {
    cuInit(0);
    cuDeviceGet(&cu_device_, 0);
    cuCtxCreate(&cu_context_, 0, cu_device_);
    decoder_.reset(new NvDecoder(cu_context_, false, cudaVideoCodec_H264));
  }

  // デコード
  void Decode(const uint8_t* ptr, int size, uint8_t**& frames, int& frame_count) {
    decoder_->Decode(ptr, size, &frames, &frame_count);
  }

private:
  CUdevice cu_device_;
  CUcontext cu_context_;
  std::unique_ptr<NvDecoder> decoder_;
};

これであとは Decode() 関数にエンコードされたフレームデータへのポインタを渡せばデコードされたデータが frames に設定されます。

なおデコードしたデータは NV12 形式なので、必要に応じて ARGB8888 などに変換してやる必要があります。

CUDA を使ったビルドに対応する

NVDEC を利用するには CUDA 環境が必須です。さりげなく上記のコードでも CUDA を初期化しています。

そして CUDA のソースコードは nvcc コンパイラでコンパイルしてやる必要があるため、ビルド環境に CUDA を使ったビルドを含めてやる必要があります。

幸いなことに、CMake はバージョン 3.8 以上で enable_language(CUDA) に対応しています。これを使うと nvcc コンパイラを自動で探してきてコンパイルしてくれるようになります。

enable_language(CUDA)

set_source_files_properties(
    NvCodec/NvCodec/NvDecoder/NvDecoder.cpp
    src/hwenc_nvcodec/nvcodec_video_decoder_cuda.cpp
  PROPERTIES
    # ファイル拡張子は .cpp だが C++ コンパイラではなく CUDA コンパイラを利用する
    LANGUAGE CUDA
    CUDA_SEPARABLE_COMPILATION ON
)

こんな風に書けば、これらのソースコードを nvcc でコンパイルしてリンクして実行出来るようになります。

CUDA と WebRTC を混ぜない

CUDA を扱う時にはちょっと気をつける点があって、それは CUDA と WebRTC を混ぜてはいけないということです。
つまり CUDA のソースを書く時に WebRTC の関数を一切使ってはいけないし #include してもいけないということです。

実際に WebRTC のソースコードを #include してみるとコンパイルエラーになります。詳細は見ていないですが、多分コンパイラごとの分岐で変な場所に行ってエラーになっているんじゃないかと思います。
なので CUDA を利用する処理は別の .cpp ファイルにした上で、CUDA 側は WebRTC を含むヘッダーファイルを一切 #include してはいけません。

実際今回の対応では webrtc::VideoDecoder を実装した nvcodec_video_decoder.cpp ファイルと、その内部で CUDA を使ったデコードのみを対応する nvcodec_video_decoder_cuda.cpp に分けています。
これで無事ビルドが出来るようになって、いい感じに Windows で NVDEC が動くようになりました。

GitHub Action に対応する

Sora Unity SDK は GitHub Actions で CI を行ったりリリースを作ったり出来るようになっています。
なのでこの CUDA を使ったビルドも GitHub Actions でビルドが出来るのが望ましいでしょう。

残念なことに、上記の対応では GitHub Actions でビルドが出来ませんでした。
なぜかというと、GitHub Actions の実行環境には CUDA 対応のビデオカードが入っていないため、CUDA Toolkit のインストーラを実行するとドライバのインストールでエラーになってしまうからです。

nvcc だけ取り出す

理論的には、nvcc コンパイラと cuda.lib と cuda.h さえあればビルドできるはずです。
いろいろ調べてみると、CUDA Toolkit のインストーラで local タイプ（全部入りのダウンロード）をダウンロードして unzip してやると、インストールするそれぞれのコンポーネントをそのまま見ることができることが分かりました。

この中に入っている nvcc というディレクトリが欲しかったコンパイラです。
わざわざインストーラを実行しなくても、この nvcc ディレクトリを持ってきて利用すれば動くはずです。

CMake を修正する

CMake で enable_languages(CUDA) をすると、自動で nvcc コンパイラを探してくれます。
じゃあどうやって探しているかというと、Windows では CUDA の Visual Studio Integration を使っています。
この CUDA の VS Integration は CUDA Toolkit のインストール時に選択してインストールするものですが、さっき書いたように GitHub Actions では CUDA Toolkit のインストーラは動きません。

そのため、GitHub Actions からの利用を考えた場合 enable_language(CUDA) は使えません。

そこでどうするかというと、FindCUDA を利用します。
これは CUDA の言語サポートが実装されたため deprecated になっている機能ですが、これは VS Integration を見たりしないので安心して使えます。

以下のように利用します。

# nvcc コンパイラの配置場所を設定する
set(CUDA_TOOLKIT_ROOT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/_install/cuda/nvcc)

# FindCUDA を利用する
find_package(CUDA REQUIRED)

set_source_files_properties(
    NvCodec/NvCodec/NvDecoder/NvDecoder.cpp
    src/hwenc_nvcodec/nvcodec_video_decoder_cuda.cpp
  PROPERTIES
    CUDA_SOURCE_PROPERTY_FORMAT OBJ
)
cuda_compile(CUDA_FILES
    NvCodec/NvCodec/NvDecoder/NvDecoder.cpp
    src/hwenc_nvcodec/nvcodec_video_decoder_cuda.cpp
  OPTIONS
    # Visual Studio C++ コンパイラに渡す追加のコンパイラオプション
    -Xcompiler /utf-8
    -Xcompiler /I${CMAKE_CURRENT_SOURCE_DIR}/NvCodec/include
    -Xcompiler /I${CMAKE_CURRENT_SOURCE_DIR}/NvCodec/NvCodec
)
target_sources(SoraUnitySdk PRIVATE ${CUDA_FILES})

これに加えて GitHub Actions のキャッシュ機構も利用して、毎回 2.5 GB ある CUDA Toolkit インストーラをダウンロードしてしまうことが無いようにしました。

こうすることで、無事 CUDA のインストールできない環境、つまり GitHub Actions でもビルド出来るようになりました。

感想

見て分かる通り、デコーダの実装はすぐに終わったのですが、ビルド環境の整備で苦労しました。
GitHub Actions 対応は、CUDA Toolkit がインストールできない時点で諦めようかと思っていたんですが、何とか動かせて良かったです。

Sora Unity SDK を Android 対応した話

melpon — Thu, 11 Jun 2020 21:27:05 +0000

Sora Unity SDK は WebRTC SFU Sora の Unity クライアントです。
Sora Unity SDK は既に Windows と macOS で動くようになっているのですが、今回新しく Android に対応しました。

std::めるぽん

@melponn

無事 Sora Unity SDK を Android に対応した（画像は Sora Labo と繋いでるところ）。

05:51 AM - 05 Jun 2020

V

@voluntas

github.com/shiguredo/sora… Sora Unity SDK 2020.4 をリリースしました。こちら KDDI テクノロジー様からの優先実装依頼として Android 版への対応を行いました！ OSS へのご理解本当にありがとうございます！！！！

07:33 AM - 11 Jun 2020

この記事では、この対応のために具体的にどんなことをしたのかについて書きます。

Android 対応の PR はこれです。全体を見たい時に確認してください。

Android 対応 by melpon · Pull Request #4 · shiguredo/sora-unity-sdk

WebRTC の Android ビルド

Sora Unity SDK を Android で動かせるようにするには、まず Android 用の WebRTC ライブラリが必要です。

WebRTC は既に Android で動作するようになっているので、これをビルドするだけで良いです。
ただし、Android のライブラリは AAR になっているのに対して、ネイティブの実行に必要なのは libwebrtc.a と jar ファイルなので、そのあたりをうまくやる必要があります。

WebRTC のビルドは Sora Unity SDK ではなく、shiguredo-webrtc-build/webrtc-build というリポジトリで管理していて、ここでネイティブの Android 向けの WebRTC に対応しました。

ネイティブ用 Android 対応 by melpon · Pull Request #1 · shiguredo-webrtc-build/webrtc-build

このビルド済みバイナリを Sora Unity SDK でダウンロードして利用する形になります。

Android のカメラに対応する

WebRTC ライブラリには既に Android のカメラを利用してキャプチャする機能が既にあるので、これを Sora Unity SDK から利用するだけです。

ただし、このカメラキャプチャの機能は Java で書かれています。Sora Unity SDK は C++ なので直接扱うのは出来ません。そこでどうするかというと、まあ JNI (Java Native Interface) ですね。

JNI を使ってカメラの映像をキャプチャする

Android 用 WebRTC を使って Java でカメラを利用するには、以下のようなコードを書きます。

// Android のいつものコンテキスト
Context context = UnityPlayer.currentActivity.getApplicationContext();
// キャプチャ処理をやったりするスレッド
SurfaceTextureHelper helper = SurfaceTextureHelper.create("VideoCapturerThread", null);
// デバイスからキャプチャラを作る
Camera2Enumerator enumerator = new Camera2Enumerator(context);
CameraVideoCapturer videoCapturer = enumerator.createCapturer(enumerator.getDeviceNames()[0], null /* eventsHandler */);
// キャプチャ開始
videoCapturer.initialize(helper, context, capturerObserver);
videoCapturer.startCapture(width, height, fps);

これで毎フレーム capturerObserver オブジェクトにコールバックがやってきます。

これを C++ で再現すればうまく動くので、頑張って書くだけです。
例えば UnityPlayer.currentActivity.getApplicationContext() に相当する処理は以下のように書きます。

webrtc::ScopedJavaLocalRef<jobject> GetAndroidApplicationContext(JNIEnv* env) {
  // Context context = UnityPlayer.currentActivity.getApplicationContext()
  // を頑張って C++ から呼んでるだけ
  webrtc::ScopedJavaLocalRef<jclass> upcls = webrtc::GetClass(env, "com/unity3d/player/UnityPlayer");
  jfieldID actid = env->GetStaticFieldID(upcls.obj(), "currentActivity", "Landroid/app/Activity;");
  webrtc::ScopedJavaLocalRef<jobject> activity(env, env->GetStaticObjectField(upcls.obj(), actid));

  webrtc::ScopedJavaLocalRef<jclass> actcls(env, env->GetObjectClass(activity.obj()));
  jmethodID ctxid = env->GetMethodID(actcls.obj(), "getApplicationContext", "()Landroid/content/Context;");
  webrtc::ScopedJavaLocalRef<jobject> context(env, env->CallObjectMethod(activity.obj(), ctxid));

  return context;
}

こんな感じのコードを大量に書いて何とかします。

問題は Java から C++ へのコールバックを受け取る部分ですが、これは大変ありがたいことに、C++ のキャプチャコールバックを受け取るクラスである webrtc::jni::AndroidVideoTrackSource を Java の CapturerObserver に変換するための仕組みを WebRTC 側が用意してくれているので、それを利用するだけで C++ 側にコールバックが渡ってくれるようになります。

JAR ファイルを設定する

Java のコードを利用するということは、class ファイルを Unity のビルド時に含んでやる必要があるということです。
幸いなことに Unity には JAR ファイルを Android に組み込む機能が入っている(JAR プラグイン - Unity マニュアル)ため、上記の「WebRTC の Android ビルド」で作った Android 用 WebRTC に入っている jar ファイルをそのまま持ってくるだけで良いです。

Java から C++ にコールバックを渡るようにする

この状態で普通に libSoraUnitySdk.so を作って実機で動かしてみたのですが、すぐにクラッシュしました。
ログを追いかけてみると、Java 側から Java_org_webrtc_Histogram_nativeAddSample みたいな C++ の関数を呼ぼうとして、その関数が見つからなくてクラッシュしているようでした。

この関数は libwebrtc.a には存在しているのですが、それをリンクした libSoraUnitySdk.so には含まれていませんでした。
それも当然で、C++ のコードからは Java_org_webrtc_Histogram_nativeAddSample 関数を一切呼んでいないため、リンク時にこの関数が取り除かれてしまうのです。
なのでこの Java から呼び出している関数に関しては libSoraUnitySdk.so に含めてやるようにしました。

具体的には、リンカーに渡すオプションとして -Wl,--undefined=Java_org_webrtc_Histogram_nativeAddSample を追加しました。
--undefined を使うことで、未使用の関数であってもライブラリに含められます。

ただし Java から呼び出す C++ 関数はこれだけではないため、これらの関数の一覧を列挙してオプションを作ってやる必要があります。
こういうシンボルを見るためのツールが Android NDK にあるので、それを利用して libwebrtc.a の関数を列挙し、Java_org_webrtc_ から始まる関数を取り出してオプションに加工しています。

具体的には以下のようなコードになります。

# Android 側からのコールバックする関数は消してはいけないので、
# libwebrtc.a の中から消してはいけない関数の一覧を作っておく
if [ ! -e $INSTALL_DIR/android/webrtc.ldflags ]; then
  # readelf を使って libwebrtc.a の関数一覧を列挙して、その中から Java_org_webrtc_ を含む関数を取り出し、
  # -Wl,--undefined=<関数名> に加工する。
  # （-Wl,--undefined はアプリケーションから参照されていなくても関数を削除しないためのフラグ）
  _READELF=$INSTALL_DIR/android-ndk/toolchains/llvm/prebuilt/darwin-x86_64/bin/aarch64-linux-android-readelf
  _LIBWEBRTC_A=$INSTALL_DIR/android/webrtc/lib/arm64-v8a/libwebrtc.a
  $_READELF -Ws $_LIBWEBRTC_A \
    | grep Java_org_webrtc_ \
    | while read a b c d e f g h; do echo -Wl,--undefined=$h; done \
    | sort \
    > $INSTALL_DIR/android/webrtc.ldflags
fi

これで動かすと、無事カメラ映像のキャプチャが出来るようになりました。

Unity カメラのキャプチャに対応する

Sora Unity SDK には、Unity カメラが写している映像をキャプチャする機能が用意されています。
つまりこういうことです。

Sora Unity SDK サンプル集を動かしてみたfor Android - torikiziのブログより

仕組みとしては、Unity カメラがレンダリングしているテクスチャを指すポインタを C++ 側に渡して、それをゴニョゴニョっとして映像データを取り出すようになっています。
このゴニョゴニョする部分が大変なところで、Windows なら Direct3D 11 を使ったり、macOS なら Metal を使ったり、今回の Android なら Vulkan を使ったりして映像データを取り出します（Android は OpenGLES の場合もあるんですが、そちらは今回対応していません）。

Unity は、ネイティブで Unity のテクスチャを扱えるようにするための仕組みを用意してくれていて、導入に関しては以下のドキュメントに書かれています。

低レベルネイティブプラグインインターフェース - Unity マニュアル

これを利用するのと、あとは Vulkan のドキュメントを読みながら書くだけです。

Unity テクスチャのポインタ

実際書いてみてハマった点としては、「Unity から渡されるテクスチャへのポインタは、Vulkan のテクスチャを指すわけではない」というのがあります。

Unity から渡されるテクスチャへのポインタは、例えば Windows(D3D11) なら ID3D11Resource* のことだったり、macOS(Metal) なら id<MTLTexture> のことだったりしました。
なので Android の場合も Vulkan 用のイメージである VkImage だと思っていたのですが、全然違っていました。

Android の場合、Unity から渡されたテクスチャへのポインタは自前のデータ構造になっているようで、この構造の実際の定義は公開されていないようです。
そしてこの不透明なデータ構造の内容を展開するための関数として IUnityGraphicsVulkan::AccessTexture というのがあり、この関数に Unity から渡されたテクスチャへのポインタを渡すと UnityVulkanImage というのを返してくれるようになっています。

これで得られた UnityVulkanImage を使って、Vulkan の関数を色々と呼び出して何とかして映像データを取り出します。
具体的な処理は sora-unity-sdk/unity_camera_capturer_vulkan.cpp at 469a326213c3b8a7eb4a202c5b0030c9103bc113 · shiguredo/sora-unity-sdk にあるので、気になった人は見てください。

ハードウェアエンコーダに対応する

Android 用の WebRTC は大変素晴らしくて、ハードウェアエンコーダに対応しています。ただし Java コードで。
DefaultVideoEncoderFactory というクラスは、出来る限りハードウェアを利用し、利用できるハードウェアがなければソフトウェアにフォールバックするという実装になっています。

ということで DefaultVideoEncoderFactory オブジェクトを C++ から生成して、それを C++ 用の video_encoder_factory に設定するだけです。

カメラデバイスの列挙に対応する

Android にはフロントカメラとバックカメラの２つが付いている機種があったりするので、その辺を列挙するための機能があると便利です。
Android 用の WebRTC は大変素晴らしくて、このカメラデバイスの列挙に対応しています。ただし Java コードで。
Camera2Enumerator というクラス（以下略）

感想

ということで、振り返ってみると大体はビルド周りと JNI 周りをうまく整備してやる感じで、あとは Unity テクスチャと Vulkan について調べて書く程度しかやっていません。

ただ、Android も JNI も Vulkan もあまり触ったことが無いので結構大変でした。
ひたすら動かなくて、Android のログを眺めてトライアルアンドエラーを繰り返しまくってました。何とか無事動いて良かったです。