DLNA と Mac はとっても相性が悪かったのに今更気づいた話 — nasne・PC TV Plus を Mac で再生するために半日詰まった顛末

はじめに

nasne / PC TV Plus に貯めたテレビ録画を Mac で見たいだけ、というシンプルな要件のはずが、半日ハマった話を残しておきます。「Mac で DLNA プレイヤーって少ないんだろうな」とは思っていましたが、想像以上に選択肢が少なく、しかも残ってる選択肢それぞれに地雷があり、相性の悪さを体感した記録です。

要件はこうでした。

• 自宅 LAN 上の nasne 3 台 (mutsuki / kaiya / tenta) と PC TV Plus (Windows PC 上) の録画を、Mac から DLNA で視聴したい
• できれば自分用ダッシュボード (HTML) のリンクをクリックすると Mac 上で目的の録画が自動再生されるところまで自動化したい

以下、結論から先に書きます。

環境	結果
nasne 録画 → Mac DiXiM Play U	✓ 自動化込みで動く (~12 秒で再生開始)
PC TV Plus 録画 → Mac DiXiM Play U	✗ 全部グレーアウトで再生不可
PC TV Plus 録画 → Mac StationTV Link	✗ 認証サーバに繋がらず起動できない
PC TV Plus 録画 → Mac の他プレイヤー	そもそも存在しない

なぜここまで Mac は DTCP-IP / DLNA に冷たいのか。理由を調べると複数の構造的事情が絡んでいて、「Mac で PC TV Plus 録画を見る」というルートはほぼ袋小路になっています。本記事ではその確認の過程と、最終的に採用した実装を記録します。

前提となる規格: DTCP-IP と DLNA

まず用語の整理です。

DLNA (Digital Living Network Alliance) はホームネットワーク上のメディア共有規格。サーバ (DMS) がメディアを公開し、コントローラ (DMC) がブラウズし、レンダラ (DMR) が再生します。プロトコルは UPnP AV を使います。

DTCP-IP (Digital Transmission Content Protection over IP) は DLNA で配信される著作権保護コンテンツを暗号化して送り合う仕組み。1998 年に Hitachi / Intel / Matsushita / Sony / Toshiba の 5 社が DTLA (Digital Transmission Licensing Administrator) を設立して策定した DTCP 規格を、IP ネットワーク向けに拡張したもの (DTCP-IP の追補仕様は 2003〜2004 年頃) で、日本の地デジ・BS の再放送制限 (ARIB TR-B14 等) と紐づいて普及した、ほぼ日本ローカルの規格です。

nasne や PC TV Plus が貯めるテレビ録画はすべて DTCP-IP で暗号化されており、対応プレイヤーでないと再生できません。

DRM 周りのざっくりした世界観はこんな感じです。

• 海外: Widevine (Google) / PlayReady (Microsoft) / FairPlay (Apple) が主流
• 日本: それに加えて DTCP-IP / Marlin / DTCP2 が地デジ録画の世界に存在

つまり日本の録画再生インフラは、海外標準と別レイヤーのプロトコルを経由しています。

Mac で DTCP-IP に対応するアプリは事実上 2 つ

調べると、現時点で Mac 用の DTCP-IP 対応 DLNA プレイヤーは下記の 2 本に絞られます。

1. DiXiM Play U (Digion / 株式会社デジオン)
2. StationTV Link (株式会社ピクセラ)

Windows なら他に PC TV Plus / sMedio TV Suite / DiXiM Play / PowerDVD など 5〜10 本あるのですが、Mac は DiXiM と StationTV Link 以外がほぼ存在しません。sMedio も Mac 版は限定的で、現在実用できる状態ではありませんでした。

なぜこんなに少ないのか、理由はあとで整理します。先に当時の試行を書きます。

試行 1: DiXiM Play U Mac 版

App Store で 3,300 円、Mac App Store で買えます。実質「Designed for iPad」アプリが Mac でも動くという形態 (LSRequiresIPhoneOS=true / MinimumOSVersion=18.0) で、Catalyst でなく iPad アプリそのものを Mac 上で実行している扱いです。

nasne 録画は問題なく再生できました。サーバ自動 discover も効き、家族で使うレベルの安定性です。

ところが PC TV Plus を選択すると、録画一覧が全部グレーアウト。タイトル名は出るのに選択できません。

公式サポートに当たると、原因が書いてありました。

iPad / iPhone / Mac の DiXiM Play U は、DR モード録画 (MPEG-2 インターレース) の再生をサポートしていません。グレーアウト表示は「デバイスが再生サポートしていないビデオ形式」の仕様です。

DiXiM Play U Mac/iPad版ヘルプ - 番組がグレー表示

PC TV Plus は録画を全部 DR モード (MPEG-2 TS、約 17 Mbps、インターレース) で保存します。よって Mac で見ようとすると全グレーアウトになるのは仕様の必然でした。

iPad / iPhone でも同様。Mac 版だけの問題ではなく、Apple のプラットフォーム共通で MPEG-2 インターレースを再生できないことが背景にあります。

iOS / iPadOS の方が DR モード非対応はやや緩い情報も見ましたが、結局 H.264 progressive にトランスコードして配信できるサーバが必要です。

試行 2: StationTV Link

「Mac 唯一の DTCP-IP 対応プレイヤー」と紹介されることが多いピクセラのアプリ。約 2,627 円、5 分制限の体験版あり。

ダウンロードして起動 → サーバ一覧画面で kaiya / PC TV Plus / BDZ-ET2000 まで自動 discover し、設定ダイアログ上では各サーバにチェックを入れられました。これなら DiXiM で詰まった PC TV Plus も再生できるかもしれない、と期待が高まります。

ところが**「サーバーのリストを更新」を押すと認証サーバに接続できません」というエラー**。

認証サーバに接続できません。
インターネットに接続できるか確認してから、接続しなおしてください。

DiXiM 側からは PC TV Plus が SSDP で advertise されているのが見えるので、ネットワーク自体は健全。lsof -i で見ると StationTV Link は kaiya とは TCP ESTABLISHED まで届いているのに、Pixela 側の認証サーバとの通信に失敗しています。

StationTV ... TCP 192.168.1.83:49161->192.168.1.10:58888 (ESTABLISHED)  ← kaiya

バイナリを codesign -dv で見ると最終署名は 2021 年 1 月。Pixela の StationTV Link はそれ以降アップデートが止まっていて、おそらく認証エンドポイントが現在の macOS の証明書チェーンと噛み合わないか、あるいは Pixela 側でサーバが事実上停止しています。

実機 Mac 1 台、家庭ネットワーク内で全サーバから外も到達できる状態で どのサーバを選んでも認証が通らない。これは StationTV Link 単体の話で、ピクセラとしては Mac 版を実質メンテしていないと判断するしかなさそうです。

試行 3: 他の Mac 用 DTCP-IP プレイヤー

ここで「Mac 用 DTCP-IP プレイヤー、もう一本あるはず…」と思って検索しても、出てこないのです。

• sMedio TV Suite: 現役は Windows 版・Android 版。Mac 版は過去に体験版があった程度で、現在は事実上の廃版扱い
• VLC: DTCP-IP 復号を持たない (合法な実装無し)
• IINA / mpv: 同上
• Plex / Infuse: そもそも DTCP-IP に対応していない

つまり Mac で DTCP-IP 配信を受けられるアプリは DiXiM Play U と StationTV Link の 2 つだけで、片方は DR モード非対応、もう片方は認証サーバ問題で起動不可、という状況でした。

なぜ Mac は DLNA プレイヤーが少ないのか

ここで一度立ち止まって、なぜ Mac の DLNA / DTCP-IP 対応がここまで貧弱なのか整理しました。複数の事情が重なっています。

1. DTCP-IP は日本ローカル規格

DTCP-IP の市場は地デジ・BS の ARIB 仕様と紐づいているため、事実上日本に閉じています。海外向けに Mac アプリを書く動機が薄く、開発元はほぼ日本企業 (Digion / Pixela / sMedio) に限られます。

2. Apple は DTCP-IP の公式 API を持たない

macOS の AVFoundation / Media フレームワークは FairPlay (Apple 自社) はサポートしますが、DTCP-IP のデコードパスは公式に提供されていません。各社は独自に DTCP-IP プロトコルスタックを書き、自前のコンテンツデコーダで AVFoundation の再生面に乗せる必要があります。

これはサードパーティ実装のコストが Windows と比べて格段に高くなる要因です。Windows Media Foundation には DTCP-IP プラグイン用のフレームワークがあり、PC TV Plus も DiXiM Play もそれに乗っかっています。Mac はこれが無い。

3. DTLA ライセンス料

DTCP-IP プロトコルを実装するには DTLA からライセンスを受ける必要があります。具体的な料金体系は DTLA の Adopter Agreement の Procedural Appendix 内にあって会員以外には開示されません。採択者コミュニティの伝聞ベースでは Small Adopter / Large Adopter 区分があり、年額数万ドル規模 + 製品単位ロイヤリティと言われます (一次ソース不可)。いずれにせよ個人開発者・小規模ベンダーには参入障壁になっています。

4. AirPlay / Apple TV にも DTCP-IP は流せない

iOS / iPadOS で DiXiM Play U が動いていても、AirPlay 経由で Apple TV に音声・映像を投げられません。DTCP-IP の出力先は HDCP で保護された画面のみで、AirPlay / Continuity 経路は対象外です。

つまり Mac で再生できれば、それで終わりで、Apple TV にミラーするとかの逃げ道もありません。

5. 既存の Mac 版アプリが軒並み更新停滞

• DiXiM Play U Mac/iPad版 (v1.5.0) — 一応継続。ただし DR モード対応など機能拡張は行われていない
• StationTV Link (v1.1.1) — 2021 年 1 月で更新止まり。認証サーバ事実上停止
• sMedio TV Suite Mac — 廃番扱い

「Mac での DLNA TV 視聴」の市場が小さく、各社とも継続投資の優先度が低い、という状態が透けて見えます。

6. ストリーミング時代のメガトレンド

そもそも「テレビ録画を見るために DLNA クライアントを買う」という需要自体が、YouTube / Netflix / Amazon Prime / Disney+ / TVer / FOD / U-NEXT など同時配信・見逃し配信プラットフォームの普及で年々細っています。

新規開発が起きにくく、既存アプリも開発リソースが減り、Mac 版だけ削られる傾向。

これらが重なって、「Mac × DLNA × DTCP-IP」 は事実上、過去の遺産で動いている古い選択肢しか残っていない領域になっています。

試行 4: 自動化レイヤーの実装

ここで「nasne については DiXiM Play U Mac で再生できる」というところまでは確認できました。次は「ブラウザのダッシュボードで ▶ kaiya のようなリンクをクリックすると Mac で自動再生する」という自動化を組みます。

DiXiM Play U には diximPlay://openAsPlayer?searchableItemType=1&serverUDN=...&objectID=... という URL スキームがバイナリ内にあります。CSSearchableItem (Spotlight) からの deep link 用。理論上、ブラウザで <a href="diximPlay://..."> を作ればクリック一発で起動・再生できるはずでした。

ところが macOS 上の DiXiM Play U は Designed for iPad アプリ ( LSRequiresIPhoneOS=true 、Catalyst ではなく iPad アプリそのものを Mac 上で実行) で、UISOpenURLAction が クエリ部分を strip して UIScene に渡す挙動を取ります。Firebase Analytics の内部ログにも Deep Link does not contain valid required params. URL params: ? と空のクエリしか届いていないことが残ります。

open -a 経由でも、osascript -e 'open location "..."' でも、PyObjC の NSWorkspace.openURLs_withAppBundleIdentifier_options_additionalEventParamDescriptor_launchIdentifiers_(...) で完全な NSURL を渡しても結果は同じ。

URL スキームでの deep link が破綻したので、最終的にこういう積み上げで自動化しました。

ブラウザの ▶ <server> リンク
   │ → http://localhost:7100/play?server=<name>&title=<title>
   ▼
launchd で常駐する localhost helper (Python http.server)
   │ → subprocess: tools/dixim_ax/play_by_title.sh
   ▼
play_by_title.sh
   ├─ AX で 家で見るタブをクリック (AXRadioButton, description='家で見る')
   ├─ Vision API + screencapture で OCR → サーバ名 / ビデオ / すべて 各位置を動的検出 → CGEvent click
   ├─ AX で Icon_Search ボタンをクリック (AXButton, description='Icon_Search')
   ├─ pbcopy + osascript で Cmd+V (System Events keystroke 直下)
   └─ OCR で TITLE 部分一致最長 → CGEvent click
   ▼
DiXiM Play U が録画を再生 (DTCP-IP 復号は DiXiM 内蔵)

ポイントは 3 つ。

• AX で取れる UI は限定的 — タブバーと上部の小ボタン群 (Icon_Search 等) は AXButton / AXRadioButton として exposed。一方サーバ一覧、フォルダ、録画行は AXGroup children=? で opaque。なので OCR と座標 click を組み合わせる必要があります
• Cmd+V は届くが、生キーストロークは届かない — tell application "System Events" to keystroke "v" using command down を tell process の外側で発火させるのが鍵。CGEvent や tell process 内の keystroke は UIKit text field に到達しません
• CGWindowListCreateImage が macOS 15 (Sequoia) で obsoleted — screencapture -l <windowID> 経由で代替。ウィンドウがフルスクリーン化されると -l が失敗するので、-x で全画面取得 → ウィンドウ bounds で crop に自動 fallback

最終的にブラウザクリックから 12〜15 秒で再生開始まで圧縮できました。実用範囲です。

ただし、PC TV Plus 録画はそもそも Mac DiXiM が再生できないので、ダッシュボード側で ▶ バッジを生成しない (PC TV Plus 録画は Windows PC TV Plus アプリで視聴する) という運用に落ち着きました。

「ダビングできるなら暗号化突破では?」への答え

ここまで読んで違和感がありそうな点に答えます。

sMedio DTCP MOVE で NAS にダビングできて、ダビング先から再生できるなら、PC TV Plus の DTCP-IP 暗号化問題は解決してるのでは?

これは、問題が DRM ではなくフォーマットだからです。

PC TV Plus (DTCP-IP 暗号、DR モード MPEG-2 インターレース)
    │
    ▼ DTCP-IP MOVE プロトコル (合法的コピー、暗号維持)
    │
NAS sMedio DTCP MOVE 受信側 (暗号化されたまま保存、MOVE 元は消える)
    │
    ▼ DLNA + DTCP-IP 配信
    │
クライアント (Mac DiXiM 等) で復号 → 再生

sMedio DTCP MOVE は MOVE 中も保管中も配信中も DTCP-IP 暗号を維持します。Mac DiXiM が困っているのは「暗号が解けない」ではなく「暗号を解いた先の MPEG-2 インターレース TS をデコードできない」という、AVFoundation のサポート範囲の話。

結果として、Mac でグレーアウトしないようにするには、配信元でフォーマットを H.264 progressive にトランスコードしてから DTCP-IP で再暗号化して配信する 必要があります。これはトランスコーダ搭載 NAS (Buffalo LS411DX、I-O DATA HVL-RS など) の固有機能。

ARMv7 ベースのエントリ NAS (例: QNAP TS-431K) では sMedio DTCP MOVE が動いても受信したフォーマットのまま保管・配信するので、Mac DiXiM 側の問題は解決しません。

教訓

ここまでの試行錯誤を圧縮するとこうなります。

1. Mac で DLNA / DTCP-IP は事実上の閉鎖領域。新しいプレイヤーが出てくる気配はないし、既存もメンテが止まりがち
2. DiXiM Play U Mac 版が残された唯一の現実解 — ただし DR モード非対応で、テレビ番組の DR 録画 (PC TV Plus・古いレコーダー由来) は再生できない
3. PC TV Plus は Mac 経路を諦めるのが速い — 視聴は Windows PC TV Plus アプリで完結させ、Mac は nasne 録画専用と割り切る
4. トランスコーダ NAS を導入すれば Mac でも DR 録画が見られる — Buffalo LS411DX や I-O DATA HVL-RS で、PC TV Plus → NAS → Mac DiXiM のパイプが組める。投資 2〜3 万円台から (容量・モデルにより変動)
5. Parallels Desktop で Windows PC TV Plus を Mac 内で動かす という代替もある。年額 1 万円台 (時期により変動、公式要確認) の投資でアプリ完結
6. 自動化は AX + OCR + CGEvent + Cmd+V のハイブリッドが現実解。URL スキーム任せにすると Catalyst の query strip で詰む

「Mac でテレビ録画を見たい」という、一見シンプルな要件の裏側にはこれだけの構造的事情があり、Mac の DLNA 親和性の低さは Apple の戦略 + 規格のローカル性 + 市場規模の小ささ + Apple Silicon の動向 + DRM 規格の閉鎖性 — の合算でした。

「DLNA プレイヤーが Mac には少ない」を実感した半日でした。今後新規導入を検討される方の時間節約になれば幸いです。

参考

• DTCP-IP 対応 メディアプレーヤーアプリ StationTV® Link | ピクセラ
• DiXiM Play U Mac/iPad版ヘルプ - 番組がグレー表示
• DiXiM Play で録画番組が再生できない場合の解決方法
• トランスコーダー搭載 NAS 利用のススメ
• DTCP-IP 対応 DLNA クライアント 機器/ソフト一覧
• sMedio DTCP MOVE | QNAP