分散型ソフトバスにより、アリババの商人はマルチデバイスライブ放送を再生できる

[[428752]]
詳細については、以下をご覧ください。
51CTOとHuaweiが共同で構築したHongmengテクノロジーコミュニティ
https://harmonyos..com

1. はじめに

HarmonyOS 2 の正式リリースから 3 か月以上が経過しました。最新のデータによると、1 億 2,000 万台以上のデバイスが HarmonyOS 2 オペレーティングシステムにアップグレードされています。しかし、HarmonyOS の核となる技術的ハイライトである分散ソフトバスについては、多くのアプリケーション開発者が、それをどのように実装するか、ましてやそれを自社のビジネスとどのように統合するかについて、まだよくわかっていません。 1688 もこの問題を調査してきました。

1688は中国を代表するB2B電子商取引プラットフォームであり、主な顧客には工場所有者、タオバオ販売業者、実店舗所有者、屋台商人などが含まれます。流行によりオフラインの実店舗ビジネスが縮小したため、ますます多くの工場所有者や屋台所有者が商品を販売するためにオンラインライブストリーミングへの転換を模索しています。 1688 は事業の発展に伴い、今年、商人専用のアプリ「1688 Merchant Edition」も開発しました。このアプリは、ライブ放送、交渉、ワークベンチなど、商人にさらに専門的なサービスを提供します。

図1 1688マーチャントバージョンライブブロードキャストドメインシナリオ

1688 Merchant Edition は、ライブブロードキャスト領域の供給側でマーチャントのブロードキャスト機能を向上させ、ブロードキャストコストを削減する方法を常に模索してきました。分散型ソフトバスの特性を学んだ後、彼らはHarmonyOSのこれらの機能が1688マーチャントのマルチデバイス放送の要求と非常に一致していることに気づき、分散型ソフトバスと組み合わせたこのマルチデバイス放送ソリューションを開発しました。

この記事では、1688 ライブブロードキャストの供給側が HarmonyOS の分散ソフトバステクノロジーを使用してマルチデバイス共同ブロードキャストを実現し、1688 マーチャントのブロードキャストコストを削減し、ブロードキャスト機能を向上させる方法について技術的な観点から説明します。

通常の携帯電話放送とは異なり、1688 Live の供給側のマルチデバイス放送ソリューションには、複数のデバイスと複数の画面が含まれます。アンカーの録画だけでなく、追加のカメラを接続して商品を具体的に録画したり、ライブ放送データやプレビューを大画面に表示したり、大画面でアンカーと対話したりすることもできます。まず、この技術製品ソリューションの実装効果をビデオで見てみましょう。

ビデオリンク: https://harmonyos..com/show/8728

2. 事業背景

1. 問題点

1688 ライブ放送のホストのほとんどは商人自身です。彼らは自社製品に精通していますが、eコマースのライブ放送を開始するための専門的な能力と設備が不足しています。限られたリソースを投資しながら、ライブストリーミングの敷居を下げ、ライブストリーミングの品質を向上させるために、小売業者を支援するにはどうすればよいでしょうか? 1688 は、オフラインで加盟店を訪問した結果、ライブストリーミング加盟店はライブストリーミング機器に関して次の 3 つの大きな問題点を抱えていることを発見しました。

（１）ライブストリーミングには特定の機能機器が不足している

製品カメラが不足しています。現在のカメラは商品から遠いため、キャスターは商品の詳細を伝えるために放送機器に頻繁に近づく必要があり、ライブ放送の体験に影響を与えています。
インタラクティブな大型スクリーンが不足しています。携帯電話のインタラクティブ画面は小さいです。アンカーは、視聴者のメッセージを確認し、視聴者とやり取りするために放送機器に近づく必要があり、これがライブ放送の体験に影響を与えます。

（２）ライブ放送機器同士の連携が難しい

放送ツールの調整が難しい。キャスターが使用する録画機器、インタラクティブ機器と共同放送局が使用する中央制御装置が相互運用できず、操作が困難です。
アンカー同士がやり取りするのは困難です。通常、キャスターは商品の説明をしたり、放送局がクーポンを配布するのを手伝ったりします。双方のデバイス間の相互作用がないため、口頭でのコミュニケーションしかできず、プライバシーが欠けています。

（３）生放送機材は性能差が大きく、携帯性が悪い

放送設備への投資は少ない。 1688 のアンカーの多くは中小企業です。生放送ではコストパフォーマンスを追求しており、放送機材もバラバラ。
放送機器は持ち運びできません。工場の作業場などの複雑なシーンでは、常駐放送局と移動放送局の間で放送を調整する必要があります。この機器は持ち運びが難しく、複数の場所から放送する機能がありません。

2. 商人のニーズ

既存のデバイスは、大画面、複数のカメラ、デバイス間の共同操作、参入障壁の低い携帯性など、小売業者の要求を満たしていますか?まずそれぞれの機能を比較してみましょう:

図2 放送機器の選択の比較

放送は携帯電話で開始され、ストリーミングとインタラクションを担当します。ある程度の連携携帯性はありますが、画面が小さい、カメラが対応していないなどの問題があります。

放送は、設定可能なカメラと大画面を備えた PC で開始されます。ハードウェアコストは高くないが、デバイスが大きく携帯性が悪く、機能が1つのデバイスに集中しているためインタラクティブ性に欠ける。

ライブ放送一体型機が放送を開始しました。生放送用に特別にカスタマイズされた機器は、画面が大きく機能が強力ですが、ハードウェアの敷居が高く、ハードウェアが焼けてしまいカスタマイズができません。

まとめると、1688 が小売業者に提供したいと考えているライブブロードキャストツールには、マルチデバイスコラボレーション、大画面でのインタラクション、接続回線の少なさ、構成可能なハードウェア、高いコストパフォーマンスなどの機能が必要です。では、これらすべての利点を同時に満たすライブ放送ソリューションはあるのでしょうか?

3. ソリューション設計

統計によると、1688 Merchant Edition アプリのアンカーの 30% 以上が HarmonyOS ユーザーです。 1688 は、HarmonyOS デバイスをすでに所有している中小規模の小売業者向けに、分散型ソフトバスに基づくマルチデバイス共同ブロードキャストソリューションを提案しました。

1. ソリューションの概要

ホストが携帯電話を使用して放送する場合、大画面デバイスに遭遇すると、ワンクリックでライブ放送機能を大画面デバイスに転送できます。このとき、ホストの携帯電話はリモコンの状態になっており、大画面ディスプレイ画面にはリアルタイムデータダッシュボード、リアルタイムインタラクティブ情報、ホストの説明の収集画面が表示されます。シーン内に製品カメラがある場合は、ホストの携帯電話から製品カメラを起動することもできます。製品カメラは収集したオーディオとビデオのデータを大画面デバイスに送信して表示し、最後に大画面デバイスが結合されたストリーミングを完了します。共同放送者は大画面デバイスに接続してリアルタイムのオーディオおよびビデオのストリーミング再生を取得し、ホストと視聴者との共同インタラクションを実現できます。このソリューションには、デバイス間でのライブインタラクティブブロードキャストの移行とフロー、および複数のデバイスでのオーディオおよびビデオストリームの調整された伝送という 2 つのコア技術機能があります。

図3 分散ソフトバスに基づくマルチデバイス協調放送ソリューション

2. ソリューションの特徴

このソリューションには、上記の起動ツールの利点もあります。

（１）複数デバイス間の効率的な連携

司会者の説明を記録するためにカメラが特別に使用され、商品画像を撮影するためにカメラが特別に使用され、大画面デバイスが司会者の説明画像を表示し、ビデオストリームを結合して配信します。ホストの携帯電話はすべての放送デバイスを制御し、共同放送の携帯電話は視聴用にビデオストリームを再生します。

（２）大画面インタラクション

大画面デバイスには、ライブ放送データとインタラクティブな情報が表示されます。司会者の携帯電話は大画面でのやりとりを制御でき、共同放送の携帯電話は大画面上で司会者や視聴者とやりとりできます。

（３）ポータブル回線の減少

複数のデバイスを同じローカルエリアネットワーク内でワイヤレスで接続できます。

（４）装備できるもの

アンカーや商品を録画するためのカメラや、大型スクリーンのインタラクティブ機器はオプションです。

（５）費用対効果の高い機器

ホストと共同放送者は通常の HarmonyOS 携帯電話を使用し、通常のモニターは外部の HarmonyOS デバイスに接続され、カメラは鮮明度の要件に応じて構成できます。

4. 技術的な実装

上記の製品ソリューションを実現するための中核となる技術的機能は、ライブインタラクティブ放送の移行とフロー、およびオーディオとビデオのストリームの調整された伝送です。これら 2 つの機能の基盤となるテクノロジーは、当プロジェクトにおける HarmonyOS の分散ソフトバスの拡張とカプセル化に基づいています。次に、分散ソフトバスについて簡単に紹介します。

分散バスは、Huawei HarmonyOS によって提案されたコンセプトです。そのインスピレーションはコンピュータシステムから得られるはずです。コンピュータシステムにおいて、CPU、入出力デバイスなどの間で情報を伝送するための公開チャネルをバスと呼びます。ソフトバスは、複数のデバイス間に仮想通信接続を確立し、物理的な回線接続なしで複数のデバイス間の相互接続を実現します。これにより、デバイス間の低遅延かつ高帯域幅の情報伝送が可能になり、無線手段によるデバイス間の効率的なデータ伝送が可能になります。

図4 HarmonyOS分散ソフトバスの概略図

上記のアーキテクチャ図から、分散ソフトバスが複数の通信プロトコルをカプセル化し、デバイスの検出、接続、および送信を外部に対して透過的なインターフェイスに統合していることがわかります。開発者は、接続の詳細を気にすることなく、単純な呼び出しを行うだけで複数のデバイス間の相互接続を実現できます。

ソリューション内のライブインタラクションは、分散ソフトバスに基づいており、複数のデバイスの移行とフローを実現し、オーディオストリームとビデオストリームもソフトバスチャネルを介してデバイス間で送信されます。以下では、これら 2 つの技術的な製品機能の実現について詳しく紹介します。

1. ライブインタラクティブの移行プロセス

（１）製品の特徴

図5 ライブインタラクティブマイグレーションフロー機能の紹介

複数のデバイスでのライブインタラクティブストリーミングには、主に 3 つの機能があります。

リアルタイムデータ移行を大画面でライブ中継します。
ホストと共同ホストは大画面で対話できます。
アンカーセンターコントロール操作画面

（２）技術的解決策

図6 ライブインタラクティブ移行および転送テクノロジーソリューション

アンカー側のアプリは、元の Android プロジェクトを変換し、HarmonyOS Ability 依存関係を追加し、ブロードキャスト制御用の新しい FA を追加します。
大画面アプリは、ライブデータFAやリアルタイムインタラクティブFAなど、オリジナルアプリに大画面を追加したHAPです。
共同放送アプリは、アンカーやバイヤーとやり取りするために元の Android プロジェクトに追加された新しい FA です。

ホストアプリはまず近くの大画面を検出して接続し、ライブデータ FA とリアルタイムインタラクティブ FA を大画面デバイスにシームレスに転送します。ホストアプリはブロードキャスト制御 FA にジャンプします。ホストアプリは、中間プラットフォームコントロールを介して大画面と共同ブロードキャストアプリを操作できます。デバイス間の相互作用は IDL 通信を通じて実現されます。なお、上記 3 つのデバイス用のアプリはすべて、元のプロジェクトをベースに新たに機能が追加されたものであり、3 つすべてが同じアプリです。

（３）コードの実装

アンカー側のアプリが大画面アプリを呼び出し、同時にミドルエンドのコントロールにジャンプする例を考えてみましょう。

図7: ライブインタラクティブマイグレーションフローコードの実装

1. LiveControlAbilityにストリーミングデバイスを登録します。

継続レジスタマネージャー継続レジスタマネージャー = getContinuationRegisterManager();
継続RegisterManager.register(getBundleName(), null 、コールバック、リクエストコールバック);

2. ContinuationDeviceCallback 接続デバイスコールバックが成功したら、connectAbility を呼び出して大画面 PA ScreenServiceAbility を呼び出し、関連するパラメータを渡します。

プライベートIContinuationDeviceCallbackコールバック = 新しいIContinuationDeviceCallback() {
        @オーバーライド
パブリックvoid onDeviceConnectDone(文字列デバイスID、文字列デバイスタイプ) {
            デバイスIDを選択します。
            （selectDeviceIdがnullの場合）{
                connectAa(デバイスIDを選択)
                継続RegisterManager.updateConnectStatus(abilityToken、selectDeviceId、DeviceConnectState.CONNECTED.getState()、 null );
            }
        }
    }

3. 大画面の ScreenServiceAbility の onConnect でデータを受信し、大画面の FA ScreenPageAbility をプルアップします。

     パブリックIRemoteObject onConnect(インテントインテント) {
        clientRole = intent.getStringParam( "client_role" );
             if ( "コントローラー" .equals(clientRole)) {
            ジャンプスクリーン();
新しい ScreenRemoteForController()を返します。
        }
 }

4.ScreenRemoteForController は HarmonyControllerInterfaceSkeletonScreen から継承され、OnConnect コールバック後に初期化されます。アンカーアプリから他のデバイスの呼び出しなどの指示を受け取り、EventHandler を通じてイベントを配信します。

クラスScreenRemoteForControllerはHarmonyControllerInterfaceSkeletonを拡張します。
        スクリーンリモートコントローラ() {
            スーパー( "IScreenRemoteInterface" );
        } 
 
        @オーバーライド
パブリックvoid sendCommand(String command) は RemoteException をスローします {
            スイッチ（コマンド）{
場合  "近い" ：
                    MyApplication.getHandler().sendEvent(1);
デフォルト：
                    壊す;
            }
        }

（４）困難と限界

①デバイス間通信

HarmonyOS デバイスの現在の通信方法は IDL のみをサポートしており、IDL は一方向の通信です。デバイス間の双方向通信を実現するために、IDL にコールバックを追加する方法、または 2 つの双方向 IDL を作成してデバイス間の双方向通信を実現する方法を採用します。

② AndroidとHarmonyOSに対応した開発

現在、1688 のライブインタラクティブ機能はすべて、元の Android プロジェクトに基づいた HarmonyOS の段階的な開発です。今後、より多くの基本ライブラリがHarmonyOSの移行と適応を完了し、HarmonyOSとAndroidの互換性と通信が向上するにつれて、1688のライブインタラクティブ機能のパフォーマンスが向上します。

2. オーディオとビデオのストリームの協調伝送

（１）製品の特徴

図8 音声・映像ストリーム連携伝送機能

デバイス間でのオーディオストリームとビデオストリームの調整された送信には、主に 4 つの機能があります。

ホストのオーディオとビデオのコレクションが大画面カメラに転送されます。

製品カメラを起動して製品画像を収集し、大画面デバイスに送信します。

大画面デバイスでは、製品とアンカー画面の再生とプッシュストリーミングが組み合わされます。

オーディオとビデオのストリームは、再生のために共同放送携帯電話に送信されます。

（２）技術的解決策

図9 オーディオとビデオのストリームの共同伝送技術ソリューション

アンカーアプリは、大画面デバイスに接続すると、オーディオとビデオのキャプチャおよびプレビュー機能をオフにします。

大画面アプリでは録画プレビューと連結ストリーミング機能が追加され、収集したオーディオとビデオのストリームを共同放送アプリに送信するために追加のエンコードが必要になります。

製品カメラには、音声とビデオを収集し、大画面デバイスに送信する機能が備わっています。

共同放送アプリはクラウドからストリームを取得するのではなく、ローカルでデコードした後にオーディオおよびビデオストリームを再生します。

アンカーアプリが大画面デバイスに接続されると、大画面デバイスのカメラが起動し、音声とビデオが録画され、プレビューが表示されます。大画面デバイスを起動すると、製品カメラが起動され、収集されたオーディオとビデオのストリームがエンコードされます。ストリームは合流およびプッシュのために大画面デバイスに送信されます。共同放送を行う携帯電話では、大画面のオーディオおよびビデオストリームを取得して再生できます。

（３）コードの実装

製品カメラを起動して音声とビデオを収集し、大画面に送信する例を見てみましょう。

図10 オーディオとビデオのストリームの共同伝送のコード実装

1. 製品カメラが起動したら、まず SurfaceProvider を初期化し、surfaceCallback コールバックでバックグラウンドの ScreenServiceAbility サービスに接続し、同時にカメラをオンにします。

 保護されたSurfaceOps.Callback surfaceCallback = 新しいSurfaceOps.Callback() {
        @オーバーライド
パブリックvoid サーフェスが作成されました (サーフェスオペレーション サーフェスオペレーション) {
            プレビューサーフェス = surfaceOps.getSurface();
            CameraUtil.checkPermission(getApplicationContext()) の場合 {
                カメラを開きます。
            }
        }
 }

2. 開始されたバックグラウンドサービス ScreenServiceAbility は、onConnect 中にオーディオおよびビデオデータを送信します。

パブリックIRemoteObject onConnect(インテントインテント) {
新しいScreenRemoteFoSlave()を返す{
                @オーバーライド
パブリックvoid onPcmReady(byte[] pcmData) は RemoteException をスローします {
                        mControllerCallback.onPcmReady(pcmData);
                } 
 
                @オーバーライド
パブリックvoid onYuvData( int type, int length, int seq, byte[] cameraData) は RemoteException をスローします {
                        mControllerCallback.onReturnData(タイプ、長さ、シーケンス、カメラデータ);
                }
            };
戻る ヌル;
 }

3. 製品のカメラで収集されたビデオデータを例に、YUV データ形式にエンコードして送信します。

パブリックvoid YuvCode() {
 fmt.setObjectFormat(Format.MIME、Format.VIDEO_AVC);
 mCodec.registerCodecListener(新しいCodec.ICodecListener() {
                @オーバーライド
パブリックvoid onReadBuffer(ByteBuffer byteBuffer、BufferInfo bufferInfo、 int trackId) {
                    byte[] msg = 新しいbyte[bufferInfo.サイズ];
                    バイトバッファをクリアします。
                    byteBuffer.get(メッセージ);
                    sendEncodedDataToRemote(msg,bufferInfo);
                }
        );
       mCodec.setCodecFormat(fmt);
       mCodec.start();
 }

4. 変換された YUV ビデオフレームデータをスライスし、ScreenService バックグラウンドサービスを通じて送信します。

プライベートvoid sendEncodedDataToRemote(byte[] data, BufferInfo bufferInfo) {
                  byte[] msgTemp = 新しいbyte[bufferInfo.サイズ- 位置];
                  System.arraycopy(データ、位置、msgTemp、0、msgTemp.length);
                  mScreenServiceProxy.onYuvData(CameraUtil.IRemoteMsg.MSG_TYPE_SLICE_END、バッファ情報。サイズ、0、データ);
  }

5. 大画面デバイスは、製品カメラから送信されたオーディオおよびビデオデータを受信し、デコードして再生します。

プライベートControllerCallbackStub mControllerCallback = 新しいControllerCallbackStub( "com.alibaba.cameraohos.IControlFaCallback" ) {
        @オーバーライド
パブリックvoid onPcmReady(byte[] pcmData) は RemoteException をスローします {
            pcmData を再生します。
        } 
 
        @オーバーライド
パブリックvoid onReturnData( int type, int length, int seq, byte[] cameraData) は RemoteException をスローします {
                    デコーダーを作成します。
                    initMuxer();
        }
    }

（４）困難と限界

① オーディオおよびビデオストリームのローカルエンコードおよびデコード伝送

従来のローカルエンコーディングストリーミングとは異なり、このソリューションでは、デバイス間のオーディオストリームとビデオストリームはローカルエリアネットワーク内で送信されます。ローカルエリアネットワークの帯域幅が限られており、ビデオデータが大量であるため、1688 はローカルビデオストリームの YUV データをエンコードおよびデコードし、スライスと統合を通じて 720P ビデオストリームの伝送を実現します。

② マルチデバイスネットワーキング

セキュリティ上の理由から、HarmonyOS デバイスのネットワークは、同じ WiFi 上、Bluetooth がオン、一時的に同じ Huawei アカウントへのログインのみをサポートするという前提条件に基づいている必要があります。ただし、このシナリオでは、すべてのデバイスが同じライブブロードキャストアカウントを提供するため、同じ Huawei アカウントにログインしてからブロードキャストを開始するのが妥当です。

V. 要約と展望

1. 要約

1688 ソリューションには次の 3 つの特性があります。

（１）ハードウェアの限界に対処するソフトウェアソリューション

HarmonyOS 分散ソフトバス技術を活用したソフトウェアソリューションを採用し、1688 ライブブロードキャストシナリオのハードウェア制限を打ち破り、最も適合するハードウェアデバイスにアプリケーション機能を分散することで、ハードウェアリソースの相互支援と補完を実現します。

（２）シナリオに応じた放送機能の拡張

このソリューションは、1688 マーチャントのライブブロードキャストシナリオの特性と HarmonyOS の分散型ソフトバスの特性を組み合わせ、ライブブロードキャストのインタラクションとオーディオおよびビデオの伝送のシームレスなフローを確保し、大画面インタラクションとマルチデバイスブロードキャスト機能を実現します。

（３）低コストかつ高効率で商店の悩みを解決する

基本的にオリジナルの 1688 ライブブロードキャスト機能を変更しないことを前提として、ソフトウェアレベルで複数のデバイス上で同じアプリケーションのさまざまな機能を実現します。ハードウェアレベルでは、開発コストが低く、商人の投資も少なくて済むため、商人の強みに応じて適切な機器を選択できます。

分散ソフトバスは HarmonyOS オペレーティングシステムの独自の機能であり、現在は HarmonyOS ユーザーのみがこの機能を利用できます。

2. 展望

1688 は、ライブインタラクティブ移行とオーディオおよびビデオの共同伝送という 2 つの主要な技術的機能に基づいて、今後この 2 つの方向性をさらに追求していきます。

（１）複数のカメラと複数の位置で放送し、ライブ放送コンテンツを充実させる

グループの Artc が徐々に HarmonyOS に適応し、より多くのストリーム処理機能を提供するにつれて、1688 は製品を記録するための専門的な高解像度カメラ、放送工場への移動式カメラ、ライブ放送画像をキャプチャするためのマルチアングルカメラを提供できるようになり、1688 のライブコンテンツの品質がさらに向上します。

（２）標準化された中央制御ボックスにより放送コストを削減

オーディオおよびビデオストリームの合流と配信、スクリーン投影表示、およびブロードキャスト制御の機能が中央制御装置に集中しています。アンカーは、上記のパッケージ化された放送機能を実現するために、このデバイスのみを備える必要があります。

現在のソリューションは主にソフトウェアアプリケーションの開発に関するものであり、ハードウェアの開発は含まれません。そのため、実際の使用に必要なカメラや大画面デバイスの機能はすべてHarmonyOSモバイルフォンで完結します。しかし、ソリューションにハードウェア開発が含まれ、OpenHarmony で焼き付けられたカメラやプロジェクションボックスを使用できれば、小売業者のコストがさらに削減され、放送機能が強化されます。 5Gの発展とあらゆるものがインターネットになる時代を迎え、将来の展望は依然として非常に広いです。

参照:

1. 分散音声撮影：

https://gitee.com/panthole/harmonyos-codelabs/tree/master/VoiceCamera

2. デバイス間でビデオコンテンツを移行する:

https://gitee.com/panthole/harmonyos-codelabs/tree/master/DistributedVideoCodelab

3. HamonyOSビデオデコード機能再生プレビュー画面：

https://gitee.com/panthole/harmonyos-codelabs/tree/master/CodecDemo

詳細については、以下をご覧ください。

51CTOとHuaweiが共同で構築したHongmengテクノロジーコミュニティ

https://harmonyos..com

<<: ロック後も同時実行の問題は残りますか? Redis 分散ロック、本当に正しく使用されていますか?

>>: 調査レポート: EUの技術規則はGoogleやIBMなどのクラウドコンピューティングプロバイダーも制限すべき