JMF 媒體框架深度解析（二）：Player 與 Processor 核心機制

承接上篇，本文深入剖析 JMF (Java Media Framework) 中最核心的兩個組件——Player（播放器）與 Processor（處理器） 的狀態機模型、方法調用約束與事件機制，為多媒體應用開發提供架構級指導。

Player：媒體播放的核心引擎

Player 負責從 DataSource 讀取媒體流，經解碼、渲染後輸出至音視頻設備。其生命週期由 6 個標準狀態構成有限狀態機：

六大核心狀態詳解

狀態轉換與方法調用約束

JMF 嚴格限制各狀態下可調用的方法，違規將拋出 NotRealizedError、ClockStartedError 等異常。關鍵約束表：

• getVisualComponent()：Realized 後可調用
• setRate()：Realized 後可調用
• syncStart()：Prefetched 後可調用
• deallocate()：除 Started 外均可調用

開發者必須透過 ControllerListener 監聽 TransitionEvent 確認狀態，再安全調用對應方法。

Processor：具備處理能力的進階 Player

Processor 繼承 Player，新增兩大能力：

1. 媒體流處理控制：編碼/轉碼/特效處理
2. DataSource 輸出：處理後數據可輸出為新 DataSource，供其他 Player/Processor 使用或存檔

擴展狀態機：Configuring 與 Configured

Processor 在 Unrealized 與 Realizing 之間插入兩個配置階段：

• Configuring：configure() 觸發，連接 DataSource、分析輸入格式
• Configured：配置完成，可設置輸出格式 setContentDescriptor()、軌道控制 TrackControl

此設計允許在實現前精確控制編碼參數（如比特率、幀率、關鍵幀間隔），是媒體轉碼應用的關鍵。

Controller 事件模型

所有 Controller (Player/Processor) 事件分三類：

1. 改變通知：RateChangeEvent、DurationUpdateEvent、FormatChangeEvent
2. 狀態轉換：TransitionEvent 實現狀態機監控
3. 關閉事件：ControllerClosedEvent 資源釋放通知

透過 addControllerListener() 註冊監聽器，實現非阻塞式狀態協調。

MediaHandler 建構架構

Player、Processor、DataSink 統稱為 MediaHandler，皆由 Manager 根據 DataSource 動態構建。JMF 採用 Plug-in 架構：

• Demultiplexer：分離復合流軌道
• Codec：編解碼轉換
• Effect：特效渲染
• Renderer：最終輸出設備適配

PlugInManager 管理所有底層插件註冊，實現格式支援的動態擴展。

最佳實踐建議

• 嚴格遵循狀態機調用序列，使用 StateHelper 輔助類管理異步轉換
• 預取階段控制 start latency，平衡啟動速度與流暢度
• Processor 輸出鏈設計：Processor → DataSource → Processor → DataSink 實現管道式處理
• 釋放資源務必調用 close() 而非僅 stop()

掌握 Player/Processor 狀態機與約束，是構建穩健 JMF 應用的基石。下篇將探討捕獲、傳輸與自定義插件開發。