10msec を、手のひらサイズに ― 超低遅延映像伝送装置 HLD-300C を振り返る

映像をリアルタイムで遠くへ届ける。言葉にすると単純ですが、「リアルタイム」の一語にどこまで本気で向き合えるかが、映像伝送機器の価値を決めます。 今回は、私が回路設計と小型化の取りまとめ、そして用途展開に携わった超低遅延コーデック HLD-300C について、スペック表の裏側にある設計の考え方を振り返りたいと思います。 回路設計は社内のチームで担当し、私もその一員として手を動かしました。基板レイアウトや筐体の設計は外部の設計パートナーに委託していました。要件を整理し、回路に落とし込み、パートナーと擦り合わせながら課題をひとつずつ解いていく ― そんな立場でこの製品に向き合いました。 すでに販売は終了した製品ですが、ここで積み上げた思想は、今の私たちの開発にもそのまま受け継がれています。

まず、受け継いだ「10msec」のこと

HLD-300Cの最大の特徴は、コーデック遅延わずか10msec(対向使用時)という超低遅延性能です。 この10msecという性能は、私が一から生み出したものではありません。HLD-20001に始まり、HLD-30002へと続いてきた、先輩方の地道な技術の蓄積です。映像圧縮で遅延を極限まで削るというのは、それだけで一本の長い物語になるほど難しいテーマで、その難所を乗り越えてきたのは諸先輩方でした。

私の役割は、その受け継いだ財産を「もっと多くの現場へ届けられる形」にすることでした。

図1:HLD-2000
図1:HLD-2000
図2:HLD-3000
図2:HLD-3000

なぜ10msecがそれほど重要なのか

本題に入る前に、この10msecが何を意味するのかを少しだけ。 これは「コーデックの符号化・復号にかかる処理遅延」です。ネットワークの伝送遅延とは別物で、エンコーダとデコーダを一対で使ったときに極限まで切り詰めた値です。圧縮方式には、放送や映像伝送で広く使われている H.264(MPEG-4 AVC)を採用しています。広く普及した方式でありながら、その符号化・復号をこれだけの低遅延で成立させているところに、HLDシリーズ3の作り込みがあります。

一般的な映像圧縮では、画質と圧縮効率を稼ぐためにフレームをまとめて処理します。その代償として、数百ミリ秒からときに秒単位の遅延が生じます。テレビ放送を観るぶんには気になりませんが、「映像を見ながら何かを操作する」用途では、この遅延が致命傷になります。HLDシリーズが向き合ってきたのは、まさにこの「映像を観る」のではなく「映像を見て動かす」という世界でした。

遅延予算(レイテンシバジェット)という考え方

ここで、もう少し全体の視点を持ち込みたいと思います。 オペレーターが手元を操作してから、その結果が映像となって返ってくるまで ― 体感する遅延は、ひとつの要素だけで決まるわけではありません。撮影、符号化、ネットワーク伝送、復号、表示。この一連の流れの各段階が、それぞれ少しずつ時間を消費します。これらを足し合わせたものが、現場で問題になる「総遅延」です。

そしてHLD-300Cは、IP通信による伝送が用途の大部分を占めます。IPネットワークを通る以上、経路や混雑、距離によって伝送遅延は変動し、ときに数百ミリ秒に達することもあります。実際、5G通信を使った建設機械の遠隔操縦実証でも、映像の遅れは0.2秒(約200msec)程度と報告されています。つまり、総遅延の大きな部分はネットワーク側が握っているのです。

だからこそ、考え方を「遅延予算(レイテンシバジェット)」として捉えると、機器の役割がはっきりします。総遅延という限られた予算のうち、ネットワークが占める分は完全には制御できません。一方で、コーデックが占める分は、設計と作り込み次第で確実に削れます。HLDシリーズが10msecという値にこだわってきたのは、「自分たちでコントロールできる遅延を限界まで小さくしておく」ことが、変動するネットワークと合わせた総遅延を実用域に収める鍵だからです。

図3:映像伝送の遅延予算。コーデックが占める分はわずかで、大半をネットワークが占める
図3:映像伝送の遅延予算。コーデックが占める分はわずかで、大半をネットワークが占める

私の仕事 ― 1U ハーフを、1/3U へ

HLD-2000、HLD-3000と受け継がれてきた性能は、1Uハーフサイズ4の筐体に収められていました。これでも十分にコンパクトな部類です。私が取り組んだのは、ここをさらに小さく、1/3Uサイズまで凝縮することでした。回路設計は社内のチームで手がけ、その回路を基板上にどう配置・配線するかというレイアウト設計、そして筐体の設計は外部の設計パートナーが担いました。どんな現場で、どんな条件で使うのかという要件を回路に落とし込み、レイアウトや筐体の制約と擦り合わせながら形にしていく ― 以下に挙げる課題も、こうした役割分担と協業の中で一緒に乗り越えたものです。

最終的なHLD-300Cの寸法は W146 × H39 × D185mm、重量約1.08kg。専用ラックを使えば1Uに3台を並べられます。 なぜ、ここまで小さくする必要があったのか。それは、この装置を持ち込みたい現場が「機材を据え付ける場所」ではなかったからです。

図4:HLD-3000シリーズ(1Uハーフ)とHLD-300C(1/3U)のサイズ比較(実寸比)
図4:HLD-3000シリーズ(1Uハーフ)とHLD-300C(1/3U)のサイズ比較(実寸比)

建設機械の現場へ ― 最初の用途

HLD-300Cを最初にリリースしたのは、建設機械向けの遠隔支援用途でした。

そもそもの発端は、現場の困りごとでした。建設機械の遠隔支援の領域では、映像の遅延が大きく、思うように操作できずに困っている人たちがいたのです。そこに対して、放送で培ってきた自分たちの10msecという超低遅延が活きないか ― そんな提案であり、模索が出発点でした。HLDシリーズは放送の世界で育ってきた製品群ですが、受け継いだ超低遅延という強みを、放送とは違うこの現場でどう役立てられるか。HLD-300Cは、その問いに答えようとした一台でもありました。

オペレーターが現地に行かず、送られてくる映像を見ながら重機を操作する。あるいは現場の状況を遠隔から確認し、支援する。こうした使い方では、手元の操作に対して映像が遅れて反応すれば、操作感は崩れ、安全性にも直結します。10msecの超低遅延がそのまま価値になる、典型的な現場です。 そしてこうした現場には、もうひとつの要求がありました。機材を置く余裕がないということです。重機まわり、車載、仮設の環境 ― きれいなラックが用意された部屋とは限りません。だからこそ、性能をそのままに、筐体を限界まで小さくする意味がありました。受け継いだ10msecを、こうした現場まで運んでいくための小型化だったのです。

小ささを、現場で使える形にする

ただ小さくするだけなら設計の一部にすぎません。難しいのは、小型化と「これまでとは違う現場で確実に動くこと」を両立させる点でした。ここでは、特に手こずった3つの課題を紹介します。

課題1 ― 「放送の耐圧」では持たない

最初に直面したのが、電源の耐圧でした。 HLDシリーズはもともと放送の世界で育った製品です。放送の現場では電源は12Vが基本で、バッテリーからのDC電源入力を見込んでも18V程度。回路も部品も、その電圧に耐えればよいという前提で設計が積み上げられてきました。ところが建設機械の現場は事情が違います。重機まわりの電源系統は電圧が高く、24V系を前提にしつつ、電圧の上振れも見越して30V近辺までは耐えられる耐圧を確保しなければなりませんでした。

問題は、これが単に「対応電圧の数字を書き換えれば済む」話ではなかったことです。より高い電圧に耐えるということは、その電圧を受ける部品の耐圧を見直し、回路の組み方そのものを設計し直すということです。放送向けに最適化されてきた設計を、そのまま流用することはできません。受け継いできた資産のどこを残し、どこを高耐圧の前提で作り変えるか ― 用途を広げたからこそ、回路設計の手で一つひとつ詰め直していく必要がありました。

課題2 ― 振動に耐えるための「引き算」

次が振動対策です。重機まわりという環境は、常に揺れにさらされます。揺れは、部品の半田付け部やネジの緩みといった「接続点」に効いてきます。 そこで取った方針は、足し算ではなく引き算でした。回路設計の段階で部品点数をできるだけ減らし、筐体側では設計パートナーと相談してネジも減らす。接続点そのものを少なくすれば、揺れに対して弱くなる箇所が減ります。機能を盛るのではなく、信頼性のために削る ― 過酷な現場と向き合うほど、この発想が効いてきました。

この「引き算」を象徴するのが、HLD-3000シリーズまで搭載していたVFD(蛍光表示管)を外す決断でした。VFDは設定値や状態を一目で確認できる便利な表示器ですが、ガラス管の部品であるがゆえに、振動や衝突で壊れるリスクを抱えています。現場で動かす機器として、ここは思い切って外しました。ただし、表示器をなくすと、IPコーデックとして肝心のIPアドレスが本体から読み取れなくなるというデメリットが生まれます。そこで、フロントパネルに初期化ボタンを設けました。これを押せば、IPアドレスを含む機器設定をデフォルト値に戻せる。表示器がなくても、現場で確実に既知の状態へ復帰できる ― 削ったうえで、その副作用をひとつの工夫で埋めたわけです。

課題3 ― 1/3Uに収めるための実装密度

そして、これらを抱えたうえで筐体は1/3Uに収めなければなりません。部品点数は振動対策のために減らしたい、一方でサイズは限界まで小さくしたい。私が組んだ回路を、限られた基板面積にどう配置・配線して収めるか ― ここはレイアウトを担う設計パートナーの腕の見せどころでした。回路側で部品や配置の意図を伝え、レイアウト側がそれを高密度に成立させる。この往復が、小型化の最後まで続きました。 性能はそのまま、削るべきは削り、それでも1/3Uに収める ― この綱引きが、小型化のいちばんの勘所でした。

ひとつの筐体に、エンコーダとデコーダを

HLD-300Cは、モード切替によってエンコーダにもデコーダにもなります(半二重)。1台で送信側にも受信側にもなれるため、運用側は機材の在庫や配置をシンプルにできます。

図5:HLD-300Cの対向構成。1台がモード切替でエンコーダにもデコーダにもなる
図5:HLD-300Cの対向構成。1台がモード切替でエンコーダにもデコーダにもなる

これを支えているのが、FPGA5という土台です。固定機能のハードウェアではなく、書き換え可能なFPGA上に機能を構成しているからこそ、1台の機器をエンコーダにもデコーダにも振り分けることができます。そして、そのFPGAに載せているのが、自社開発したエンコーダ/デコーダ回路です。これはHLD-300Cだけのものではなく、HLDシリーズ共通の技術資産として受け継がれてきたものです。10msecの超低遅延も、エンコーダとデコーダの柔軟な切り替えも、この自社開発の回路を自分たちでコントロールできるからこそ実現できたものでした。圧縮処理の心臓部を外部任せにせず社内に持っていることが、HLDシリーズの強みの源泉になっています。

圧縮方式についても同じことが言えます。HLD-300C は H.264 に加えて MPEG-2 にも対応していました。この MPEG-2 のコーデックコアも自社開発した資産で、H.264とともに回路としてライセンス提供、また装置として、今も継続的に提供しています。後継機種ではオプション機能という形で選べるようにし、長く使われてきた方式への対応を絶やさず残しています。放送や既存設備との接続では、今も MPEG-2 が求められる場面があるためです。

小さな筐体でこの柔軟性まで成立させるのは、設計上も悩ましいテーマでした。それでも、現場の運用負担を減らすというねらいを最後まで手放さずに形にできた部分です。

振り返って

HLD-300Cは販売を終えましたが、HLD-2000、HLD-3000から続く系譜は、その後も受け継がれています。HLD-300Cの機能を踏襲しつつ新たな機能を加えた HLD-300N、そして 4Kの高精細映像に対応した HLD-5000シリーズ(エンコーダの HLD-5000E、デコーダのHLD-5000D)は、この延長線上にある製品です。先輩方が築いた10msecという財産を、自分の代で「より多くの現場へ運べる形」にできたこと。社内の知見と外部の設計パートナーの技術を持ち寄り、ひとつずつ課題を解いて形にできたこと。そして建設機械の遠隔支援という、映像伝送が人の安全と仕事を支える現場に届けられたこと。HLD-300Cの開発は、技術はバトンのように受け継がれ、また多くの人の手を借りながら次の形へ広げていくものだと、あらためて教えてくれた製品でした。

映像を翼に。

Footnotes

  1. 当社独自開発によりMPEG-2コーデック時間を限りなくゼロに近づけ、遅延の感じられない画像・音声伝送を可能にした、ハイビジョン対応/超低遅延MPEG-2コーデック装置

  2. HLD-2000に搭載されていたMPEG-2に加え、MPEG-4/H.264にも対応したコーデック装置

  3. Hyper Low Delayの略で、超低遅延コーデック製品群はHLDシリーズと呼ばれています。

  4. 1U は19インチラックに機器を収める高さの単位で約44mm。「1/3U」はその高さのまま幅を3分の1に抑えた意味。

  5. Field-Programmable Gate Array の略で、「後から中身の回路を書き換えられる半導体」です。一般的なICが工場出荷時に機能を固定されているのに対し、FPGAは設計データを書き込むことで、用途に合わせた専用回路を自分たちで構成できます。ソフトウェアの柔軟さと、ハードウェアならではの高速・低遅延な処理を併せ持つのが特長です。

関連記事

heroImage

ROS2 ノードとして使う FPGA: KR260 の DPU で 3D LiDAR の物体検出をリアルタイム処理してみた

3D LiDAR の点群を入力に、AMD Kria KR260 の FPGA(DPU)上で PointPillars を 10 FPS リアルタイムで動かし、そのまま ROS2 ノードとして使える仕組みを構築しました。OS も ROS も標準インストールのまま。「FPGA は難しそう」というロボットエンジニアの方にこそ読んでいただきたい記事です。

heroImage

FDF2026@CERN探訪記

スイスとフランスにまたがる世界最大規模の素粒子物理学研究所CERNで開催されたFPGA開発者向けフォーラム(FDF)へ参加してきました。FDFの概要とCERNでの生活をご紹介します。

heroImage

IPAC-1000ユーザーからの声~東北大学~

IPAC-1000ユーザーの東北大学Waidyasooriya Hasitha Muthumala准教授から研究内容やIPAC-1000の採用理由を伺いました。