<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Multimedia on Tarragon</title><link>https://tarrragon.github.io/blog/tags/multimedia/</link><description>Recent content in Multimedia on Tarragon</description><generator>Hugo -- gohugo.io</generator><language>zh-TW</language><copyright>Tarragon (CC BY 4.0)</copyright><lastBuildDate>Thu, 02 Jul 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://tarrragon.github.io/blog/tags/multimedia/index.xml" rel="self" type="application/rss+xml"/><item><title>GUI 應用的安裝驗證：拆包、首跑對話框與播放判讀</title><link>https://tarrragon.github.io/blog/linux/install/gui-apps-install-verify/</link><pubDate>Thu, 02 Jul 2026 00:00:00 +0000</pubDate><guid>https://tarrragon.github.io/blog/linux/install/gui-apps-install-verify/</guid><description>&lt;p>GUI 應用的安裝驗證跟 CLI 工具走不同的判讀鏈：CLI 工具裝完 &lt;code>command -v&lt;/code> 加一次試跑就能定案，GUI 應用則有三個 CLI 沒有的失敗層——依賴鏈拆包（裝了本體、缺功能模組）、首跑同意對話框（程式要求使用者決策才繼續）、播放輸出鏈（視窗有了、聲音或畫面沒有）。這三層都有各自的權威判讀位置，本篇以一輪 VM 實測（檔案管理器、瀏覽器、媒體播放器、音樂串流）把它們走一遍。&lt;/p>
&lt;h2 id="拆包生態裝了本體不等於裝了功能">拆包生態：裝了本體不等於裝了功能&lt;/h2>
&lt;p>發行版為了控制依賴體積，會把一個應用的核心跟功能模組拆成多個套件，預設只裝核心。這個設計讓「安裝成功」跟「功能可用」變成兩件事，而缺件的症狀往往是靜默的：&lt;/p>
&lt;ul>
&lt;li>&lt;strong>VLC 的解碼器是獨立 plugin&lt;/strong>：Arch 的 &lt;code>vlc&lt;/code> 本體開得起來、UI 完整，播 H.264 影片卻回報 &lt;code>Codec 'h264' is not supported&lt;/code>——解碼能力在 &lt;code>vlc-plugin-ffmpeg&lt;/code>（或整組 &lt;code>vlc-plugins-all&lt;/code>）。judgment 訊號是「應用正常啟動、特定格式失敗」，權威來源是應用自己的 log（&lt;code>vlc --verbose=2&lt;/code>）。&lt;/li>
&lt;li>&lt;strong>pipewire 的 session manager 是獨立套件&lt;/strong>：&lt;code>pipewire&lt;/code> 常被依賴鏈拉進來，但沒有 &lt;code>wireplumber&lt;/code> 就沒有人建立音訊 graph——daemon 在跑、&lt;code>wpctl status&lt;/code> 的 Sinks 段是空的、所有應用無聲且不報錯。補 &lt;code>wireplumber&lt;/code> + &lt;code>pipewire-pulse&lt;/code>（多數 GUI 應用走 PulseAudio API）後輸出裝置立即出現。&lt;/li>
&lt;li>&lt;strong>optional dependency 不會自動安裝&lt;/strong>：套件宣告的 optdepends 是「裝了會多什麼功能」的提示、不是安裝動作。影片縮圖、壓縮格式支援、硬體加速常落在這層，&lt;code>pacman -Qi &amp;lt;pkg&amp;gt;&lt;/code> 的 Optional Deps 段列出哪些沒裝。&lt;/li>
&lt;/ul>
&lt;p>判讀原則：GUI 應用「開得起來但某個功能不動」時，先查發行版有沒有把那個功能拆成獨立套件，再懷疑設定或相容性。&lt;/p>
&lt;h2 id="首跑同意對話框程式在等使用者決策">首跑同意對話框：程式在等使用者決策&lt;/h2>
&lt;p>不少 GUI 應用第一次啟動會彈出需要使用者決策的對話框，最典型的是 VLC 的「Privacy and Network Access Policy」：&lt;/p>
&lt;p>VLC 聲明自己不蒐集、不傳輸任何個人資料，但它能自動向第三方網路服務抓取播放清單裡媒體的中繼資料（封面圖、曲名、演出者）——這個行為等於把「你在播哪些檔案」暴露給第三方服務，所以 VLC 開發者要求使用者明示同意（Allow metadata network access 勾選框、預設勾選）後才允許自動連網。&lt;/p>
&lt;p>這個對話框的判讀是用途導向：拿 VLC 播本機影片、看下載的影片檔，中繼資料抓取沒有用處、取消勾選讓播放器完全離線工作；拿它管理音樂庫、想要自動補封面跟曲目資訊，才需要同意。同意與否都能在偏好設定（Privacy / Network Interaction）事後改。&lt;/p>
&lt;p>首跑對話框對自動化流程有一層額外影響：無人值守安裝驗證時，應用會停在對話框等輸入、腳本側只看到「程式起了但沒繼續」。VLC 把這兩個決策記在 &lt;code>~/.config/vlc/vlcrc&lt;/code> 的 &lt;code>qt-privacy-ask&lt;/code> 與 &lt;code>metadata-network-access&lt;/code> 兩個鍵——首跑後檔案才生成，而且 VLC 退出時會整檔重寫（幾千行的完整設定 dump），把它納入 dotfile 版控會持續產生無意義的 diff，比較合理的處理是讓首跑對話框留給人、或在自動化腳本裡預先寫入只含這兩鍵的最小 vlcrc。&lt;/p>
&lt;p>同型的首跑決策也出現在瀏覽器（預設瀏覽器詢問、錯誤回報同意）跟大型 GUI 應用（遙測同意）。它們的共通判讀：對話框問的是「要不要讓程式自動連外 / 回傳資料」，答案取決於這台機器的用途與隱私要求，安裝驗證流程要把「首跑會有互動」納入預期、不是當成故障。&lt;/p>
&lt;h2 id="播放驗證鏈三個權威位置">播放驗證鏈：三個權威位置&lt;/h2>
&lt;p>「有沒有真的在播」的驗證不靠肉眼跟喇叭，三個權威位置各管一段：&lt;/p>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>驗證對象&lt;/th>
 &lt;th>權威來源&lt;/th>
 &lt;th>工具與判準&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td>視窗存在&lt;/td>
 &lt;td>compositor 的視窗表&lt;/td>
 &lt;td>&lt;code>hyprctl clients&lt;/code> 有該應用的 class 條目&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>音訊真的在出&lt;/td>
 &lt;td>音訊伺服器 graph&lt;/td>
 &lt;td>&lt;code>wpctl status&lt;/code> Streams 段有該應用的 stream 且 &lt;code>[active]&lt;/code>&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>失敗的原因&lt;/td>
 &lt;td>程式自己的 log&lt;/td>
 &lt;td>&lt;code>vlc --verbose=2&lt;/code>、瀏覽器 &lt;code>--enable-logging=stderr&lt;/code>&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table>
&lt;p>把「管線通不通」跟「應用會不會播」拆開驗證能大幅縮短歸因：先用本機音檔 &lt;code>pw-play &amp;lt;file&amp;gt;&lt;/code> 打通音訊路徑（stream 出現 &lt;code>[active]&lt;/code> 代表 guest 側無誤），再測應用層；應用層失敗就跟管線無關，往解碼器、DRM、應用 log 查。串流再多拆一層：先用無 DRM 的串流（一般影音網站）確立網路串流基線，DRM 內容（Spotify、Netflix 類）的失敗才能歸因到 DRM 層——DRM 在非 x86_64 架構的可用性判讀見 &lt;a href="../platform-divergence-map/">平台與發行版差異的判讀地圖&lt;/a> 的套件存在性段。&lt;/p>
&lt;h2 id="vm-特有硬體解碼回退">VM 特有：硬體解碼回退&lt;/h2>
&lt;p>在 VM 裡播放影片，第一次開檔常會閃一個錯誤對話框（&lt;code>failed to create video output&lt;/code>）然後正常播放——這是硬體解碼回退的痕跡：播放器預設先嘗試硬體加速解碼（VDPAU / VAAPI），虛擬 GPU（如 virtio-gpu）沒有視訊解碼能力，嘗試失敗後回退軟體解碼重建輸出。log 上的特徵是一次性的 decoder error 加上之後穩定的 &lt;code>avcodec decoder&lt;/code> 軟體解碼行；實體機器有 GPU 解碼時不會出現。VM 裡想要乾淨啟動，在播放器偏好設定停用 hardware-accelerated decoding 即可——這是機器特性設定，適合留在該機器本機、不進共用 dotfile。&lt;/p>
&lt;h2 id="下一步路由">下一步路由&lt;/h2>
&lt;ul>
&lt;li>套件在這個平台 / 架構存不存在、名字叫什麼：&lt;a href="../platform-divergence-map/">平台與發行版差異的判讀地圖&lt;/a>&lt;/li>
&lt;li>音訊、行程、服務狀態的權威判讀：&lt;a href="../../debug/">Linux 除錯與診斷&lt;/a>&lt;/li>
&lt;li>GUI 應用清單怎麼進 bootstrap：&lt;a href="https://tarrragon.github.io/blog/linux/dotfile/08-sync-bootstrap/bootstrap-script-packages/" data-link-title="Bootstrap Script 與套件清單管理" data-link-desc="寫 dotfile 的 install script、或整理「這台機器裝了什麼」的套件清單時回來讀">模組八：Bootstrap script 設計&lt;/a>&lt;/li>
&lt;/ul></description><content:encoded><![CDATA[<p>GUI 應用的安裝驗證跟 CLI 工具走不同的判讀鏈：CLI 工具裝完 <code>command -v</code> 加一次試跑就能定案，GUI 應用則有三個 CLI 沒有的失敗層——依賴鏈拆包（裝了本體、缺功能模組）、首跑同意對話框（程式要求使用者決策才繼續）、播放輸出鏈（視窗有了、聲音或畫面沒有）。這三層都有各自的權威判讀位置，本篇以一輪 VM 實測（檔案管理器、瀏覽器、媒體播放器、音樂串流）把它們走一遍。</p>
<h2 id="拆包生態裝了本體不等於裝了功能">拆包生態：裝了本體不等於裝了功能</h2>
<p>發行版為了控制依賴體積，會把一個應用的核心跟功能模組拆成多個套件，預設只裝核心。這個設計讓「安裝成功」跟「功能可用」變成兩件事，而缺件的症狀往往是靜默的：</p>
<ul>
<li><strong>VLC 的解碼器是獨立 plugin</strong>：Arch 的 <code>vlc</code> 本體開得起來、UI 完整，播 H.264 影片卻回報 <code>Codec 'h264' is not supported</code>——解碼能力在 <code>vlc-plugin-ffmpeg</code>（或整組 <code>vlc-plugins-all</code>）。judgment 訊號是「應用正常啟動、特定格式失敗」，權威來源是應用自己的 log（<code>vlc --verbose=2</code>）。</li>
<li><strong>pipewire 的 session manager 是獨立套件</strong>：<code>pipewire</code> 常被依賴鏈拉進來，但沒有 <code>wireplumber</code> 就沒有人建立音訊 graph——daemon 在跑、<code>wpctl status</code> 的 Sinks 段是空的、所有應用無聲且不報錯。補 <code>wireplumber</code> + <code>pipewire-pulse</code>（多數 GUI 應用走 PulseAudio API）後輸出裝置立即出現。</li>
<li><strong>optional dependency 不會自動安裝</strong>：套件宣告的 optdepends 是「裝了會多什麼功能」的提示、不是安裝動作。影片縮圖、壓縮格式支援、硬體加速常落在這層，<code>pacman -Qi &lt;pkg&gt;</code> 的 Optional Deps 段列出哪些沒裝。</li>
</ul>
<p>判讀原則：GUI 應用「開得起來但某個功能不動」時，先查發行版有沒有把那個功能拆成獨立套件，再懷疑設定或相容性。</p>
<h2 id="首跑同意對話框程式在等使用者決策">首跑同意對話框：程式在等使用者決策</h2>
<p>不少 GUI 應用第一次啟動會彈出需要使用者決策的對話框，最典型的是 VLC 的「Privacy and Network Access Policy」：</p>
<p>VLC 聲明自己不蒐集、不傳輸任何個人資料，但它能自動向第三方網路服務抓取播放清單裡媒體的中繼資料（封面圖、曲名、演出者）——這個行為等於把「你在播哪些檔案」暴露給第三方服務，所以 VLC 開發者要求使用者明示同意（Allow metadata network access 勾選框、預設勾選）後才允許自動連網。</p>
<p>這個對話框的判讀是用途導向：拿 VLC 播本機影片、看下載的影片檔，中繼資料抓取沒有用處、取消勾選讓播放器完全離線工作；拿它管理音樂庫、想要自動補封面跟曲目資訊，才需要同意。同意與否都能在偏好設定（Privacy / Network Interaction）事後改。</p>
<p>首跑對話框對自動化流程有一層額外影響：無人值守安裝驗證時，應用會停在對話框等輸入、腳本側只看到「程式起了但沒繼續」。VLC 把這兩個決策記在 <code>~/.config/vlc/vlcrc</code> 的 <code>qt-privacy-ask</code> 與 <code>metadata-network-access</code> 兩個鍵——首跑後檔案才生成，而且 VLC 退出時會整檔重寫（幾千行的完整設定 dump），把它納入 dotfile 版控會持續產生無意義的 diff，比較合理的處理是讓首跑對話框留給人、或在自動化腳本裡預先寫入只含這兩鍵的最小 vlcrc。</p>
<p>同型的首跑決策也出現在瀏覽器（預設瀏覽器詢問、錯誤回報同意）跟大型 GUI 應用（遙測同意）。它們的共通判讀：對話框問的是「要不要讓程式自動連外 / 回傳資料」，答案取決於這台機器的用途與隱私要求，安裝驗證流程要把「首跑會有互動」納入預期、不是當成故障。</p>
<h2 id="播放驗證鏈三個權威位置">播放驗證鏈：三個權威位置</h2>
<p>「有沒有真的在播」的驗證不靠肉眼跟喇叭，三個權威位置各管一段：</p>
<table>
  <thead>
      <tr>
          <th>驗證對象</th>
          <th>權威來源</th>
          <th>工具與判準</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>視窗存在</td>
          <td>compositor 的視窗表</td>
          <td><code>hyprctl clients</code> 有該應用的 class 條目</td>
      </tr>
      <tr>
          <td>音訊真的在出</td>
          <td>音訊伺服器 graph</td>
          <td><code>wpctl status</code> Streams 段有該應用的 stream 且 <code>[active]</code></td>
      </tr>
      <tr>
          <td>失敗的原因</td>
          <td>程式自己的 log</td>
          <td><code>vlc --verbose=2</code>、瀏覽器 <code>--enable-logging=stderr</code></td>
      </tr>
  </tbody>
</table>
<p>把「管線通不通」跟「應用會不會播」拆開驗證能大幅縮短歸因：先用本機音檔 <code>pw-play &lt;file&gt;</code> 打通音訊路徑（stream 出現 <code>[active]</code> 代表 guest 側無誤），再測應用層；應用層失敗就跟管線無關，往解碼器、DRM、應用 log 查。串流再多拆一層：先用無 DRM 的串流（一般影音網站）確立網路串流基線，DRM 內容（Spotify、Netflix 類）的失敗才能歸因到 DRM 層——DRM 在非 x86_64 架構的可用性判讀見 <a href="../platform-divergence-map/">平台與發行版差異的判讀地圖</a> 的套件存在性段。</p>
<h2 id="vm-特有硬體解碼回退">VM 特有：硬體解碼回退</h2>
<p>在 VM 裡播放影片，第一次開檔常會閃一個錯誤對話框（<code>failed to create video output</code>）然後正常播放——這是硬體解碼回退的痕跡：播放器預設先嘗試硬體加速解碼（VDPAU / VAAPI），虛擬 GPU（如 virtio-gpu）沒有視訊解碼能力，嘗試失敗後回退軟體解碼重建輸出。log 上的特徵是一次性的 decoder error 加上之後穩定的 <code>avcodec decoder</code> 軟體解碼行；實體機器有 GPU 解碼時不會出現。VM 裡想要乾淨啟動，在播放器偏好設定停用 hardware-accelerated decoding 即可——這是機器特性設定，適合留在該機器本機、不進共用 dotfile。</p>
<h2 id="下一步路由">下一步路由</h2>
<ul>
<li>套件在這個平台 / 架構存不存在、名字叫什麼：<a href="../platform-divergence-map/">平台與發行版差異的判讀地圖</a></li>
<li>音訊、行程、服務狀態的權威判讀：<a href="../../debug/">Linux 除錯與診斷</a></li>
<li>GUI 應用清單怎麼進 bootstrap：<a href="/blog/linux/dotfile/08-sync-bootstrap/bootstrap-script-packages/" data-link-title="Bootstrap Script 與套件清單管理" data-link-desc="寫 dotfile 的 install script、或整理「這台機器裝了什麼」的套件清單時回來讀">模組八：Bootstrap script 設計</a></li>
</ul>
]]></content:encoded></item></channel></rss>