<4D F736F F D20482E323634B5F8B054BD73BD58A4A7A5ADA6E6A4C6ACE3A8732E646F63>

Transcription

1 H.264 視 訊 編 碼 之 平 行 化 研 究 專 題 學 生 : 廖 友 誌 陳 彥 豪 指 導 教 授 : 李 良 德 教 授 大 同 大 學 資 訊 工 程 學 系 專 題 報 告 中 華 民 國 九 十 七 年 六 月

2

3 摘 要 H.264 是 新 一 代 的 視 訊 壓 縮 標 準, 它 提 供 了 更 高 的 壓 縮 效 能, 使 壓 縮 品 質 進 一 步 的 提 升, 也 使 得 影 像 傳 送 速 度 也 較 快, 若 利 用 cluster 做 編 碼 或 許 能 加 快 速 度 本 文 以 刀 鋒 伺 服 器 (blade server) 的 16 顆 CPU 為 開 發 平 台, 並 以 JM 編 碼 器 為 基 礎, 利 用 MPI 的 函 式 插 入 其 程 式 碼 中, 使 之 具 有 平 行 處 理 能 力, 再 利 用 刀 鋒 伺 服 器 以 1 顆 2 顆 4 顆 8 顆 CPU 分 別 跑 JM 編 碼 器, 將 所 花 的 時 間 記 下 來, 並 做 評 估 II

4 致 謝 感 謝 李 良 德 老 師 這 些 日 子 的 細 心 指 導 從 三 年 級 雜 誌 研 讀 時, 就 不 斷 地 提 供 我 們 建 議, 在 專 題 實 作 過 程 中, 提 供 了 許 多 的 知 識 還 有 感 謝 劉 岡 逺 學 長 在 我 們 做 專 題 期 間 在 程 式 設 計 方 面 提 供 許 多 的 教 導 III

5 目 錄 第 一 章 專 題 概 述 專 題 動 機 專 題 大 綱 專 題 目 標 所 遇 問 題 與 其 解 決 方 法 在 Linux 利 用 gcc 編 譯 JM 8.0 程 式 檔 (encoder) 的 問 題 在 Linux 利 用 MPI 編 譯 JM 8.0 程 式 檔 (encoder) 的 問 題 在 Linix 上 compile 含 有 數 學 函 式 的 程 式 程 式 有 時 候 在 執 行 中 出 現 奇 怪 訊 息 或 突 然 當 掉 的 情 形 開 發 工 具 硬 體 設 備 使 用 到 的 軟 體 開 發 平 台 專 題 進 度 與 工 作 分 配 專 題 進 度 工 作 分 配 專 題 成 果 概 述... 5 第 二 章 技 術 背 景 Blade Server 簡 介 定 義 Blade server 的 優 點 Blade server 的 缺 點 MPI 簡 介 六 大 指 令 介 紹 H 簡 介 特 色... 9 第 三 章 系 統 設 計 與 架 構 系 統 架 構 方 案 一 系 統 架 構 方 案 二 第 四 章 系 統 實 作 實 作 步 驟 系 統 評 估 第 五 章 結 論 與 未 來 發 展 IV

6 參 考 文 獻 附 錄...33 V

7 圖 目 錄 圖 一 H.264/AVC 之 功 能 框 圖 圖 二 網 路 提 取 層 單 位 流 之 階 層 架 構 圖 三 具 有 或 不 具 有 FMO 模 式 下 的 切 片 / 切 片 組 圖 四 H.264/AVC 之 SP-slice 圖 五 H.264/AVC 之 SI-slice 圖 六 H.264/AVC 之 intra_4 4 型 式 畫 面 內 預 測 技 術 圖 七 多 樣 尺 寸 區 塊 分 割 的 例 子 圖 八 圖 格 之 間 多 重 參 照 的 例 子 圖 九 方 案 一 流 程 圖 圖 十 方 案 二 架 構 圖 圖 十 一 方 案 二 流 程 圖 圖 十 二 JM/bin 裡 的 資 料 圖 十 三 編 譯 JM 編 碼 器 圖 十 四 JM 編 碼 器 執 行 畫 面 圖 十 五 利 用 Notepad++ 分 析 執 行 畫 面 圖 十 六 利 用 Notepad++ 分 析 輸 入 輸 出 點 圖 十 七 CPU 個 數 執 行 時 間 圖 圖 十 八 Speedup 曲 線 圖 VI

8 表 目 錄 表 1.1 專 題 進 度 規 劃 表... 4 表 1.2 專 題 工 作 分 配 表... 5 表 1.3 執 行 時 間 數 據 表 表 1.4 CPU 個 數 之 平 均 執 行 時 間 與 Speedup VII

9 第 一 章 專 題 概 述 1.1 專 題 動 機 H.264/AVC( 或 稱 H.264) 是 由 ITU-T 和 ISO 聯 合 制 定 的 新 一 代 視 訊 壓 縮 標 準, 比 起 MPEG-2 MPEG-4 和 H.263 而 言,H.264 提 供 了 更 高 的 壓 縮 效 能, 使 壓 縮 品 質 進 一 步 的 提 升 H.264 目 前 在 行 動 多 媒 體 通 訊 有 很 大 的 商 機, 如 :ipod 蘋 果 H.264 掌 上 播 放 監 視 器 等 等... 一 直 以 來 電 腦 都 是 由 一 顆 CPU 去 處 理 電 腦 上 的 所 有 程 序, 因 為 CPU 要 處 理 的 事 情 太 多 了, 所 以 慢 慢 加 大 CPU 的 頻 率 使 電 腦 能 夠 在 一 定 的 時 間 內 處 理 這 些 事, 後 來 頻 率 大 到 某 一 個 程 度 不 能 再 加 了, 所 以 Intel 又 推 出 Pentium D, 也 就 是 雙 核 心 因 為 未 來 的 電 腦, 很 有 可 能 會 發 展 成 雙 核 心 的 系 統, 但 現 在 卻 很 少 有 用 雙 核 心 處 理 影 片 的 軟 體, 所 以 我 們 想 H.264 既 然 壓 縮 效 能 高 使 得 影 片 播 放 速 度 快, 如 果 能 配 合 現 在 的 雙 核 心 CPU, 應 該 播 放 速 度 會 更 快 為 了 驗 證 心 中 的 想 法, 我 們 以 Blade server 來 模 擬 多 核 心 系 統, 利 用 MPI 來 測 試 看 看 是 否 符 合 我 們 的 假 設 1.2 專 題 大 綱 1. 了 解 MPI 六 大 指 令 的 用 法 並 能 夠 利 用 這 些 指 令 來 撰 寫 程 式 2. 到 H.264 JM 的 官 方 網 站 下 載 程 式 碼 3. 在 下 載 到 的 程 式 碼 裡 插 入 MPI 程 式 碼 4. 在 Blade server 上 Linux 環 境 下 利 用 MPI compiler 編 譯 後 執 行, 產 生 H.264 檔 1.3 專 題 目 標 利 用 刀 鋒 伺 服 器 (Blade Server), 將 YUV 檔 的 所 有 圖 格 (Frame) 平 分 給 每 顆 1

10 CPU 去 編 碼, 看 看 是 否 能 藉 此 加 快 現 行 H.264 的 編 碼 速 度 並 紀 錄 利 用 1 顆 2 顆 4 顆 8 顆 CPU 去 編 碼 時 所 花 時 間, 並 利 用 這 些 數 據 作 成 圖 表, 並 評 估 用 多 顆 CPU 編 譯 一 個 影 片 比 一 顆 CPU 快 多 少 1.4 所 遇 問 題 與 其 解 決 方 法 在 Linux 利 用 gcc 編 譯 JM 8.0 程 式 檔 (encoder) 的 問 題 在 windows 下 若 要 編 譯 JM 8.0 的 程 式 時, 必 須 利 用 visual C 或 其 他 C 程 式 開 發 工 具 的 compiler 來 編 譯 可 是 在 Linux 下 則 無 法 利 用 上 述 方 式, 必 須 利 用 make 指 令 通 常 只 要 輸 入 make 就 會 開 始 compile 了, 可 是 JM 8.0 卻 發 生 以 下 問 題 : checking dependencies compiling object file "obj/annexb.o"... Assembler messages: FATAL: can't create obj/annexb.o: 沒 有 此 一 檔 案 或 目 錄 make: *** [obj/annexb.o] Error 1 因 為 makefile 裡 有 一 行 :OBJDIR= obj, 表 示 compile 時 產 生 的.o 檔 放 在 名 叫 obj 的 資 料 夾, 但 是 在 JM 8.0 沒 有 此 資 料 夾, 所 以 必 須 自 己 建 立 出 來 ( 在 JM/lencod/), 這 樣 就 會 開 始 編 譯 了! 在 Linux 利 用 MPI 編 譯 JM 8.0 程 式 檔 (encoder) 的 問 題 依 的 問 題 得 知, 在 Linux 上 compile JM8.0 時, 只 要 修 改 makefile 裡 面 的 設 定, 在 命 令 列 輸 入 make 後,Linux 裡 有 個 叫 GCC 的 compiler 就 會 將 這 些 檔 案 一 起 編 譯 若 利 用 MPI 來 撰 寫 程 式 的 話 要 編 譯 時 則 用 到 的 compiler 叫 mpicc, 要 利 用 mpicc 來 編 譯 的 話, 必 須 修 改 makefile 的 設 定 makefile 裡 有 一 行 :CC= $(shell which gcc), 表 示 編 譯 程 式 的 compiler 是 gcc, 我 們 原 本 是 想 說 2

11 因 為 我 們 要 用 的 compiler 是 mpicc, 所 以 把 gcc 改 為 mpicc, 結 果 無 法 編 譯, 後 來 我 們 想 了 另 一 種 方 法, 方 法 如 下 : 1. 新 增 資 料 夾, 然 後 把 JM8.0 的 lencod 資 料 夾 裡 的 src 的 所 有.c 檔 跟 inc 所 有.h 檔 全 部 copy 到 新 資 料 夾 裡 2. 然 後 下 command: mpicc *.c -o 任 取 程 式 名, 之 後 即 可 編 譯 在 Linix 上 compile 含 有 數 學 函 式 的 程 式 當 C 程 式 裡 面 有 用 到 C 的 數 學 函 式 庫 時, 例 如 pow, 則 會 出 現 以 下 錯 誤 訊 息 : undefined reference to 'pow' 此 訊 息 的 意 思 就 是 C 語 言 將 檔 案 編 成.obj 檔 後, 要 連 結 pow 時, 沒 有 找 到 pow 函 數 的 相 關 定 義! 因 為 Unix C 中,pow 函 數 定 義 在 libm.so 函 式 庫 中, 不 像 一 般 Dev C++ 或 Turbo C 是 放 在 C 語 言 的 lib 下, 所 以 C 無 法 在 編 譯 連 結 時, 找 到 相 關 的 函 數 檔 連 結 到 執 行 檔 所 以 必 須 在 編 譯 時, 告 訴 C 函 數 庫 的 位 置 我 們 只 需 加 上 指 令 參 數 如 下 :gcc filename.c -lm 特 別 注 意,-lm 拆 成 兩 部 份 來 看,-l 是 請 C 加 入 某 函 式 庫 (library),m 是 指 libm.so 這 個 函 式 庫 所 以,-lm 是 告 訴 gcc 使 用 libm.so ( 或 libm.a) 函 式 庫 程 式 有 時 候 在 執 行 中 出 現 奇 怪 訊 息 或 突 然 當 掉 的 情 形 這 個 問 題 發 生 的 原 因 主 要 是 因 為 Blade server 長 期 的 開 機 使 用, 使 得 Blade server 上 的 CPU 過 熱, 只 要 用 風 扇 使 CPU 冷 卻, 此 問 題 即 可 得 到 改 善 有 時 此 方 法 沒 有 效 時, 看 blade server 的 後 面, 有 時 候 是 網 路 卡 亮 紅 燈 出 問 題, 只 要 拔 出 來 在 插 回 去 也 可 解 決 1.5 開 發 工 具 硬 體 設 備 3

12 Blade Server 的 16 顆 處 理 器 使 用 到 的 軟 體 Pietty( 命 令 式 介 面 : 能 夠 與 Blade Server 的 環 境 連 線 ) Winscp3( 圖 形 介 面 : 可 以 上 傳 檔 案 到 Server 也 可 從 上 面 下 載 檔 案 ) H.264 Player( 可 以 播 放 H.264 檔 案 ) Visual C++( 用 來 修 改 JM 程 式 ) MadEdit( 可 以 利 用 16bit 模 式 開 啟 YUV 檔 案 查 看 code) 開 發 平 台 Windows XP: 編 輯 MPI 程 式 或 播 放 編 碼 出 來 的 H.264 影 片 Linux Red Hat: 編 輯 編 譯 或 執 行 插 入 MPI 程 式 碼 的 JM 程 式 1.6 專 題 進 度 與 工 作 分 配 專 題 進 度 專 題 進 度 規 劃 表 如 下 表 1.1 表 1.1 專 題 進 度 規 劃 表 系 統 評 估 程 式 撰 寫 了 解 MPI 了 解 H.264 第 一 第 二 第 三 第 四 第 五 第 六 第 七 第 八 第 九 第 十 個 月 個 月 個 月 個 月 個 月 個 月 個 月 個 月 個 月 個 月 4

13 1.6.2 工 作 分 配 本 專 題 工 作 分 配 如 下 表 1.2 表 1.2 專 題 工 作 分 配 表 姓 名 工 作 分 配 1. 了 解 MPI: 先 看 老 師 給 我 們 的 MPI 資 料, 知 道 MPI 陳 彥 豪 的 function 怎 麼 使 用 之 後, 再 利 用 學 校 的 電 腦 多 執 行 資 料 上 的 例 子, 增 加 對 MPI 使 用 的 熟 悉 度 1. 認 識 MPI 的 六 大 函 數 -MPI_Init() MPI_Comm_size() MPI_Comm_rank() MPI_Send() MPI_Recv() MPI_Finalize(), 知 道 用 法 後, 利 用 MPI 廖 友 誌 練 習 寫 幾 個 簡 單 程 式, 增 加 熟 悉 度 2. 了 解 H.264 影 片 壓 縮 處 理 和 格 式 方 面 的 知 識, 並 下 載 JM8.0 的 程 式 碼 來 作 編 碼 解 碼 等 一 些 簡 單 動 作 3. 利 用 MPI 的 六 大 指 令 插 入 JM8.0 來 對 影 片 作 作 編 碼 1.7 專 題 成 果 概 述 我 們 將 JM 編 碼 器 插 入 MPI 程 式 碼 後, 使 編 碼 器 能 夠 利 用 多 處 理 器 來 編 碼, 然 後 把 YUV 檔 的 前 面 240 個 圖 格 (Frame) 分 為 16 個 檔 案, 每 個 檔 案 有 15 個 圖 格 (Frame) 執 行 JM 時 CPU 會 平 分 此 16 個 檔 案 去 編 碼,CPU 同 時 各 自 編 一 個 檔 案, 直 到 編 完 為 止 本 次 專 題 的 目 的 是 探 討 當 利 用 1 個 CPU 2 個 CPU 4 個 CPU 8 個 CPU 編 碼 的 時 間 情 形 5

14 第 二 章 技 術 背 景 2.1 Blade Server 簡 介 這 是 資 料 中 心 技 術 裡 最 新 也 是 最 熱 門 的 趨 勢 藉 由 把 所 有 的 伺 服 器 系 統 的 硬 體 如 處 理 器 記 憶 體 硬 碟 機, 以 及 網 路 連 線 整 合 到 單 一 的 擴 充 卡, 或 者 所 謂 的 刀 鋒 上 刀 鋒 把 伺 服 器 密 度 的 觀 念 推 到 極 致, 這 樣 的 整 合 代 表 了 更 吸 引 人 的 另 一 選 擇 : 可 以 降 低 成 本 降 低 溫 度 並 減 少 所 需 的 空 間, 進 一 步 的, 還 能 改 進 伺 服 器 的 穩 定 度 與 得 到 更 低 的 整 體 擁 有 成 本 (TCO) 密 集 的 刀 鋒 建 置, 其 真 正 的 好 處 在 於 你 可 以 很 輕 鬆 且 很 快 的 加 入 更 多 的 伺 服 器 不 用 再 浪 費 好 幾 個 小 時 的 時 間 去 安 裝 另 一 個 不 相 容 的 積 架 滑 軌 工 具, 現 在 管 理 員 只 要 幾 秒 鐘 時 間 就 可 以 插 入 一 台 全 新 的 伺 服 器 而 換 掉 一 台 壞 掉 的 伺 服 器 也 是 一 樣 的 簡 單 每 一 片 刀 鋒 都 是 相 互 獨 立 的, 插 入 或 者 移 除 一 片 刀 鋒 並 不 會 影 響 到 同 一 底 座 上 其 他 刀 鋒 的 運 作 定 義 所 謂 的 Blade server 是 指 將 處 理 器 記 憶 體, 甚 至 硬 碟 機 等 伺 服 器 系 統 的 硬 體 整 合 到 單 一 的 主 機 板, 或 是 所 謂 的 刀 鋒 上, 彼 此 共 用 機 箱 (chassis) 電 源 供 應 器 鍵 盤 顯 示 器 及 滑 鼠 等 資 源, 而 在 一 個 機 箱 內, 可 以 放 入 多 達 20 台 ( 片 ) 的 伺 服 器 Blade server 的 優 點 不 過 隨 著 企 業 對 於 節 省 空 間 的 需 求 日 益 提 升, 加 以 過 去 兩 年 全 球 經 濟 表 現 不 盡 理 想, 企 業 IT 採 購 成 本 緊 縮,blade server 這 種 集 中 度 高 易 於 管 理 總 持 有 6

15 成 本 低, 且 可 以 在 不 汰 換 整 個 系 統 的 情 形 之 下, 隨 著 企 業 的 需 求 增 加 而 逐 步 增 加 (capacity on demand) 的 特 性, 將 能 夠 進 一 步 刺 激 客 戶 採 用 該 類 產 品 的 需 求 Blade server 的 缺 點 由 於 blade server 的 密 度 (density) 相 當 的 高, 因 此 產 品 的 散 熱 能 力 好 壞 將 影 響 其 穩 定 性, 從 而 也 將 限 制 其 產 品 的 效 能 此 外, 由 於 個 別 blade server 相 對 於 high end server 而 言, 可 靠 度 (reliability) 仍 然 不 高, 因 此 應 用 上 仍 以 較 為 低 階 ( 如 web server) 的 功 能 為 主 而 在 產 品 的 規 格 方 面, 目 前 雖 然 有 些 供 應 商 提 供 較 為 開 放 的 PCI module 以 供 PCI add-on card 使 用, 不 過 大 多 數 仍 為 專 屬 (proprietary) 規 格 的 blade backplane interface 因 此, 對 零 組 件 供 應 商 而 言, 怕 產 生 呆 料 與 跌 價 的 風 險 ; 對 於 企 業 用 戶 而 言, 則 會 擔 憂 與 既 有 IT 架 構 相 容 或 未 來 升 級 不 順 等 問 題, 而 對 於 blade server 的 採 用 裹 足 不 前, 將 會 影 響 此 類 產 品 的 普 及 速 度 2.2 MPI 簡 介 MPI 是 一 套 可 用 於 分 散 式 記 憶 體 和 共 享 記 憶 體 架 構 的 平 行 電 腦 系 統 上 的 資 料 傳 送 界 面, 也 是 和 程 式 語 言 電 腦 種 類 無 關 的 標 準, 程 式 設 計 師 使 用 MPI 程 式 碼 來 傳 送 與 接 收 各 平 行 電 腦 之 間 的 訊 息 六 大 指 令 介 紹 1. MPI_Init, MPI_Finalize 在 叫 用 其 他 MPI 函 式 之 前 必 須 先 叫 用 MPI_Init 函 式, 來 啟 動 該 程 式 在 多 個 CPU 上 的 平 行 計 算 工 作 在 程 式 結 束 之 前 必 須 叫 用 MPI_Finalize 函 式, 以 結 束 平 行 計 算 工 作 所 以 MPI_Init 和 MPI_Finalize 在 主 程 式 裏 只 要 叫 用 一 次 就 夠 了 2. MPI_Comm_size, MPI_Comm_rank 通 常 在 叫 用 過 MPI_Init 之 後, 就 必 須 叫 用 MPI_Comm_size 以 得 知 參 與 平 行 7

16 計 算 的 CPU 個 數 (nproc), 及 叫 用 MPI_Comm_rank 以 得 知 我 是 第 幾 個 CPU (myid), 第 幾 個 CPU 是 從 0 開 始 起 算 所 以 第 一 個 CPU 的 myid 值 為 零, 第 二 個 CPU 的 myid 值 為 1, 第 三 個 CPU 的 myid 值 為 2, 餘 類 推 通 常 要 在 幾 個 CPU 上 作 平 行 計 算 是 在 下 執 行 命 令 時 決 定 的, 而 不 是 在 程 式 裏 事 先 設 定 當 然, 使 用 者 也 可 以 在 程 式 裏 事 先 設 定 要 在 幾 個 CPU 上 作 平 行 計 算, 其 意 義 只 供 程 式 人 員 做 參 考, 實 際 上 使 用 幾 個 CPU 作 平 行 計 算 是 根 據 job command file 裏 min_processors 和 max_processors 的 設 定 值, 或 -np 的 設 定 值 3. MPI_Send, MPI_Recv 參 與 平 行 計 算 的 各 個 CPU 之 間 的 資 料 傳 送 方 式 有 兩 種, 一 種 叫 做 點 對 點 通 訊 (point to point communication), 另 外 一 種 叫 做 集 體 通 訊 (collective communication) 此 處 先 介 紹 點 對 點 通 訊 類 的 MPI_Send 和 MPI_Recv, 其 他 常 用 的 點 對 點 通 訊 及 集 體 通 訊 指 令 容 後 再 介 紹 一 個 CPU 與 另 外 一 個 CPU 之 間 的 資 料 傳 送 屬 於 點 對 點 通 訊, 送 出 資 料 的 CPU 要 叫 用 MPI_Send 來 送 資 料, 而 收 受 資 料 的 CPU 要 叫 用 MPI_Recv 來 收 資 料 一 個 MPI_Send 必 須 要 有 一 個 對 應 的 MPI_Recv 與 之 配 合, 才 能 完 成 一 份 資 料 的 傳 送 工 作 2.3 H 簡 介 H.264 是 ITU-T 以 H.26x 系 列 為 名 稱 命 名 的 標 準 之 一, 同 時 也 是 MPEG-4 第 十 部 分, 是 由 ITU-T 視 頻 編 碼 專 家 組 (VCEG) 和 ISO/IEC 運 動 圖 像 專 家 組 (MPEG) 聯 合 組 成 的 聯 合 視 頻 組 (JVT,Joint Video Team) 提 出 的 高 度 壓 縮 數 字 視 頻 編 解 碼 器 標 準 ITU-T 的 H.264 標 準 和 ISO/IECMPEG-4 第 10 部 分 ( 正 式 名 稱 是 ISO/IEC ) 在 編 解 碼 技 術 上 是 相 同 的, 這 種 編 解 碼 技 術 也 被 稱 8

17 為 AVC, 即 高 級 視 頻 編 碼 (Advanced Video Coding), 通 常 被 稱 之 為 H.264/AVC 而 JM (Joint Model) 是 一 般 常 用 來 處 理 H.264 編 碼 / 解 碼 演 算 法 之 公 用 測 試 程 式 特 色 1. 網 路 提 取 層 (Network Abstraction Layer,NAL) H.264/AVC 標 準 的 特 色 是 將 網 路 提 取 層 的 概 念 涵 蓋 進 來, 亦 即 以 NAL 封 包 為 單 位 的 方 式 來 做 為 VCL 編 解 碼 的 運 算 單 位, 這 樣 傳 輸 層 拿 到 NAL 封 包 之 後 不 需 要 再 進 行 切 割, 只 需 附 加 該 傳 輸 協 定 的 檔 頭 資 訊 (adding header only) 就 可 以 交 由 底 層 傳 送 出 去, 如 圖 一 所 示, 可 以 將 NAL 當 成 是 一 個 專 作 封 裝 (packaging) 的 模 組, 用 來 將 VCL 壓 縮 過 的 bitstream 封 裝 成 適 當 大 小 的 封 包 單 位 (NAL-unit), 並 在 NAL-unit Header 中 的 NAL-unit Type 欄 位 記 載 此 封 包 的 型 式, 每 種 型 式 分 別 對 應 到 VCL 中 不 同 的 編 解 碼 工 具 NAL 另 外 一 個 重 要 的 功 能 為 當 網 路 發 生 壅 塞 而 導 致 封 包 錯 誤 或 接 收 次 序 錯 亂 (out-of-order) 的 狀 況 時, 傳 輸 層 協 定 會 在 Reference Flag 作 設 定 的 動 作, 接 收 端 的 VCL 在 收 到 這 種 NAL 封 包 時, 就 知 道 要 進 行 所 謂 的 糾 錯 運 算 (error concealment), 在 解 壓 縮 的 同 時 也 會 嘗 試 將 錯 誤 修 正 回 來 如 圖 二 所 示, 一 個 完 整 的 H.264/AVC bitstream 是 由 多 個 NAL-units 所 組 成 的, 所 以 此 bitstream 也 稱 之 為 NAL unit stream, 一 個 NAL unit stream 內 可 以 包 含 多 個 壓 縮 視 訊 序 列 (coded video sequence), 一 個 單 獨 的 壓 縮 視 訊 序 列 代 表 一 部 視 訊 影 片, 而 壓 縮 視 訊 序 列 又 是 由 多 個 access units 所 組 成, 當 接 收 端 收 到 一 個 access unit 後, 可 以 完 整 地 解 碼 成 單 張 的 畫 面, 而 每 個 壓 縮 視 訊 序 列 的 第 一 個 access unit 必 須 為 Instantaneous Decoding Refresh (IDR) access unit,idr access unit 的 內 容 全 是 採 用 intra-prediction 編 碼, 所 以 自 己 本 身 即 可 完 全 解 碼, 不 用 參 9

18 考 其 他 access unit 的 資 料 access unit 亦 是 由 多 個 NAL-units 所 組 成, 標 準 中 總 共 規 範 12 種 的 NAL-unit 型 式, 這 些 可 以 進 一 步 分 類 成 VCL NAL-unit 及 non-vcl NAL-unit, 所 謂 的 VCL NAL-unit 純 粹 是 壓 縮 影 像 的 內 容, 而 所 謂 的 non-vcl NAL-unit 則 有 兩 種 :Parameter Sets 與 Supplemental Enhancement Information (SEI),SEI 可 以 存 放 影 片 簡 介 版 權 宣 告 使 用 者 自 行 定 義 的 資 料 等 ;Parameter Sets 主 要 是 描 述 整 個 壓 縮 視 訊 序 列 的 參 數, 例 如 : 長 寬 比 例 影 像 顯 現 的 時 間 點 (timestamp) 相 關 解 碼 所 需 的 參 數 等, 這 些 資 訊 非 常 重 要, 萬 一 在 傳 送 的 過 程 中 發 生 錯 誤, 會 導 致 整 段 影 片 無 法 解 碼, 以 往 像 MPEG-2/-4 都 把 這 些 資 訊 放 在 一 般 的 packet header, 所 以 很 容 易 隨 著 packet loss 而 消 失, 現 在 H.264/AVC 將 這 些 資 訊 獨 立 出 來 成 為 特 殊 的 parameter set, 可 以 採 用 所 謂 的 out-of-band 的 方 式 來 傳 送, 以 便 將 out-of-band channel 用 最 高 層 級 的 通 道 編 碼 (channel coding) 保 護 機 制, 來 保 證 傳 輸 的 正 確 性 圖 一 H.264/AVC 之 功 能 框 圖 10

19 圖 二 網 路 提 取 層 單 位 流 之 階 層 架 構 2. 視 訊 編 碼 層 (Video Coding Layer,VCL) 視 訊 壓 縮 的 原 理 是 利 用 影 像 在 時 間 與 空 間 上 存 有 相 似 性, 這 些 相 似 的 資 料 經 過 壓 縮 演 算 法 處 理 之 後, 可 以 將 人 眼 無 法 感 知 的 部 分 抽 離 出 來, 這 些 稱 為 視 覺 冗 餘 (visual redundancy) 的 部 分 在 去 除 之 後, 就 可 以 達 到 視 訊 壓 縮 的 目 的 如 圖 一 所 示,H.264/AVC 的 視 訊 編 碼 機 制 是 以 圖 塊 (block-based) 為 基 礎 單 元, 也 就 是 說 先 將 整 張 影 像 分 割 成 許 多 矩 形 的 小 區 域, 稱 之 為 巨 圖 塊 (macroblock,mb), 再 將 這 些 巨 圖 塊 進 行 編 碼, 先 使 用 畫 面 內 預 測 (intra-prediction) 與 畫 面 間 預 測 (inter-prediction) 技 術, 以 去 除 影 像 之 間 的 相 似 性 來 得 到 所 謂 的 差 餘 影 像 (residual), 再 將 差 餘 影 像 施 以 空 間 轉 換 (transform) 與 量 化 (quantize) 來 去 除 視 覺 冗 餘, 最 後 視 訊 編 碼 層 會 輸 出 編 碼 過 的 位 元 流 (bitstream), 之 後 再 包 裝 成 網 路 提 取 層 的 單 元 封 包 (NAL-unit), 經 由 網 路 傳 送 到 遠 端 或 儲 存 在 儲 存 媒 體 中 H.264/AVC 允 許 視 訊 影 片 以 圖 格 (Frame) 或 是 以 filed 的 方 式 來 進 行 編 碼, 兩 者 可 以 共 存, 而 圖 格 (Frame) 可 以 是 progress 或 是 interlace 形 式, 對 同 一 段 影 片 來 說 也 可 使 用 兩 者 來 混 合 編 碼, 這 個 特 性 與 MPEG-2 相 同 而 在 影 像 色 彩 格 式 的 支 援 上,H.264/AVC 第 一 版 的 標 準 只 支 援 YCrCb 4:2:0 取 樣 的 方 式, 而 在 增 修 的 第 11

20 二 版 標 準 中 增 加 4:2:2 與 4:4:4 取 樣 格 式, 通 常 這 些 格 式 會 被 數 位 電 影 或 HDTV 影 片 所 採 用 3. H.264/AVC 影 像 格 式 階 層 架 構 H.264/AVC 的 階 層 架 構 由 小 到 大 依 序 是 sub-block block macroblock slice slice group frame/field-picture sequence 對 一 個 採 用 4:2:0 取 樣 的 MB 而 言, 它 是 由 16x16 點 的 Luma 與 相 對 應 的 2 個 8x8 點 Chroma 來 組 成, 而 在 H.264/AVC 的 規 範 中,MB 可 再 分 割 成 多 個 16x8 8x16 8x8 8x4 4x8 4x4 格 式 的 sub-blocks 所 謂 的 slice 是 許 多 MB 的 集 合, 而 一 張 影 像 是 由 許 多 slice 所 組 成 ( 圖 三 ),slice 為 H.264/AVC 格 式 中 的 最 小 可 解 碼 單 位 (self-decodable unit), 也 就 是 說 一 個 slice 單 靠 本 身 的 壓 縮 資 料 就 能 解 碼, 而 不 必 依 靠 其 他 slice, 這 樣 的 好 處 是 當 傳 送 到 遠 端 時, 每 接 收 完 一 筆 slice 的 壓 縮 資 料 就 能 馬 上 解 碼, 不 用 等 待 整 張 的 資 料 接 收 完 後 才 能 開 始, 而 且 萬 一 傳 送 的 過 程 中 發 生 資 料 遺 失 或 錯 誤, 也 只 是 影 響 該 筆 slice, 不 會 對 其 他 slice 有 所 影 響, 但 跟 MPEG-2 的 slice 不 同 處 在 於 它 允 許 slice 的 範 圍 可 以 超 過 一 行 MB, 也 就 是 說 H.264/AVC 允 許 整 張 影 像 只 由 單 一 個 slice 組 成 H.264/AVC 的 slice 架 構 還 有 一 項 特 性 稱 為 Flexible Macroblock Ordering (FMO), 也 就 是 說 組 成 slice 的 MB 可 以 不 必 侷 限 於 循 序 掃 描 (raster scan) 的 排 列 方 式, 例 如 : 圖 三 最 右 側 的 排 法 就 非 常 適 用 於 多 個 前 景 (foreground) slice groups 與 一 個 獨 自 的 背 景 (background) slice group, 好 處 是 對 不 同 的 slice group 可 以 用 不 同 品 質 的 壓 縮 參 數, 例 如 : 對 於 前 景 物 件 通 常 是 人 眼 較 感 興 趣 的 區 域, 可 以 用 較 小 的 壓 縮 率 來 維 持 較 好 的 品 質 12

21 圖 三 具 有 或 不 具 有 FMO 模 式 下 的 切 片 / 切 片 組 4. Slice 的 編 碼 模 式 H.264/AVC 的 slice 依 照 編 碼 的 類 型 可 以 分 成 下 列 種 類 :(1) I-slice: slice 的 全 部 MB 都 採 用 intra-prediction 的 方 式 來 編 碼 ;(2) P-slice: slice 中 的 MB 使 用 intra-prediction 和 inter-prediction 的 方 式 來 編 碼, 但 每 一 個 inter-prediction block 最 多 只 能 使 用 一 個 移 動 向 量 ;(3) B-slice: 與 P-slice 類 似, 但 每 一 個 inter-prediction block 可 以 使 用 二 個 移 動 向 量 比 較 特 別 的 是 B-slice 的 B 是 指 Bi-predictive, 與 MPEG-2/-4 B-frame 的 Bi-directional 概 念 有 很 大 的 不 同,MPEG-2/-4 B-frame 被 限 定 只 能 由 前 一 張 和 後 一 張 的 I( 或 p)-frame 來 做 inter-prediction, 但 是 H.264/AVC B-slice 除 了 可 由 前 一 張 和 後 一 張 影 像 的 I( 或 P B)-slice 外, 也 能 從 前 二 張 不 同 影 像 的 I( 或 P B)-slice 來 做 inter- prediction, 而 H.264/AVC 另 外 增 加 兩 種 特 殊 slice 類 型 :(1) SP-slice: 即 所 謂 的 Switching P slice, 為 P-slice 的 一 種 特 殊 類 型, 用 來 串 接 兩 個 不 同 bitrate 的 bitstream;(2) SI-slice: 即 所 謂 的 Switching I slice, 為 I-slice 的 一 種 特 殊 類 型, 除 了 用 來 串 接 兩 個 不 同 content 的 bitstream 外, 也 可 用 來 執 行 隨 機 存 取 (random access) 來 達 到 網 路 VCR 的 功 能 這 兩 種 特 殊 的 slice 主 要 是 考 量 當 進 行 Video-On-Demand streaming 的 應 用 時, 對 同 一 個 視 訊 內 容 的 影 片 來 說,server 會 預 先 存 放 不 同 bitrate 的 壓 縮 影 片, 而 當 頻 13

22 寬 改 變 時,server 就 會 送 出 適 合 當 時 頻 寬 位 元 率 的 影 片, 傳 統 的 做 法 是 需 要 等 到 適 當 的 時 間 點 來 傳 送 新 的 I-slice ( 容 量 較 P-slice 大 上 許 多 ), 但 因 為 頻 寬 變 小 導 致 需 要 較 多 的 時 間 來 傳 送 I-slice, 如 此 會 讓 client 端 的 影 像 有 所 延 遲, 為 了 讓 相 同 content 但 不 同 bitrate 的 bitstream 可 以 較 平 順 地 串 接, 使 用 SP-slice 會 很 容 易 來 達 成 ( 圖 四 ), 不 僅 可 以 直 接 送 出 新 的 bitstream, 也 因 為 傳 送 的 P-slice 的 容 量 較 小, 所 以 不 會 有 時 間 延 遲 的 情 形 出 現 當 client 端 的 使 用 者 要 切 換 到 新 的 接 收 頻 道 (channel) 時, 因 為 與 目 前 傳 送 的 bitstream 不 但 內 容 不 同 連 位 元 率 也 不 同, 傳 統 的 做 法 需 讓 client 重 新 緩 衝 (buffering) 一 段 新 頻 道 的 內 容 ( 圖 五 ), 此 時 是 為 了 要 接 收 新 頻 道 bitstream 的 I-slice, 然 後 再 開 始 傳 送 新 頻 道 bitstream 後 續 的 P-slice, 如 此 client 也 會 發 生 延 遲 接 收 的 現 象, 而 且 當 client 要 進 行 所 謂 的 快 轉 倒 轉 隨 機 存 取 (random access) 的 動 作 時, 傳 統 的 做 法 無 法 達 到 即 時 的 反 應, H.264/AVC 利 用 SI-slice 就 可 以 輕 易 地 達 到 目 的 圖 四 H.264/AVC 之 SP-slice 14

23 圖 五 H.264/AVC 之 SI-slice 5. 畫 面 內 預 測 技 術 (Intra-frame Prediction) 以 往 的 壓 縮 標 準 在 進 行 intra-prediction 時, 多 半 只 是 將 轉 換 係 數 做 差 值 編 碼, 而 H.264/AVC 在 空 間 領 域 (spatial domain) 來 進 行 像 點 之 間 的 預 測, 而 不 是 用 轉 換 過 的 係 數, 它 提 供 兩 種 intra-prediction 的 型 式 :intra_4x4 及 intra_16x16, 所 謂 的 intra_4x4 是 以 Luma 4x4 sub-block 為 單 位, 找 出 它 的 參 考 對 象 (predictor) 後, 再 將 其 與 參 考 對 象 相 減 後 所 產 生 的 差 餘 影 像 (residual) 送 入 轉 換 演 算 法, 而 尋 找 參 考 對 象 的 模 式 共 有 9 種 預 測 的 方 向 ( 圖 六 ), 以 mode 0 (vertical) 為 例, {a,e,i,m} {b,f,j,n} {c,g,k,o} {d,h,l,p} 的 參 考 對 象 分 別 為 A B C D;Luma intra_16x16 與 Chroma 的 模 式 跟 Luma intra_4x4 類 似 圖 六 H.264/AVC 之 intra_4 4 型 式 畫 面 內 預 測 技 術 15

24 6. 畫 面 間 預 測 技 術 (Inter-frame Prediction) 至 於 橫 跨 每 張 畫 面 之 間 的 預 測 技 術,H.264/AVC 提 供 了 更 豐 富 的 編 碼 模 式, 計 有 下 述 幾 種 區 塊 分 割 (partition) 的 方 法 :16x16 16x8 8x16 8x8 8x4 4x8 4x4, 多 樣 的 分 割 方 式 可 以 讓 移 動 向 量 的 預 測 更 準 確, 如 圖 七 所 示, 畫 面 中 有 些 移 動 的 區 域 並 不 是 正 方 形, 使 用 長 方 形 或 較 小 的 4x4 分 割 來 做 預 測 的 區 域, 可 以 大 幅 降 低 差 餘 影 像 的 數 值 來 增 加 了 壓 縮 比, 但 也 因 此 P-slice 中 的 MB 最 多 可 有 16 個 移 動 向 量 (motion vector), 而 B-slice 中 的 MB 最 多 可 擁 有 32 個 移 動 向 量, 雖 然 這 些 會 增 加 移 動 向 量 檔 頭 (header) 的 容 量, 但 整 體 來 說 對 壓 縮 比 仍 有 正 面 的 益 處 再 者, 以 往 的 壓 縮 標 準 所 使 用 的 動 態 估 測 (motion estimation), 只 有 使 用 前 一 張 圖 像 來 作 為 預 測 的 對 象,H.264/AVC 提 供 了 多 重 參 考 圖 像 (multiple reference frames) 的 概 念, 使 得 移 動 向 量 不 再 只 限 於 前 後 相 鄰 的 影 像, 而 是 可 以 跨 過 多 張 影 像, 如 圖 八 所 示, 在 時 間 點 t 的 圖 塊, 可 以 使 用 t-1 到 t-2 圖 像 中 的 圖 塊 來 作 為 預 測 的 對 象, 當 影 片 有 週 期 重 複 性 的 內 容 時, 例 如 : 背 景 影 像 週 期 性 的 出 現 或 被 遮 蓋 物 件 有 來 回 跳 動 的 行 為 形 狀 忽 大 忽 小, 或 是 攝 影 機 在 拍 攝 時, 因 為 有 多 處 的 取 景 點, 並 且 攝 影 畫 面 在 取 景 點 之 間 來 回 移 動, 這 種 情 形 在 球 類 比 賽 轉 播 時 常 出 現, 這 些 狀 況 都 能 得 到 較 好 的 動 態 預 測 結 果, 因 而 提 高 了 壓 縮 的 效 能 16

25 圖 七 多 樣 尺 寸 區 塊 分 割 的 例 子 圖 八 圖 格 之 間 多 重 參 照 的 例 子 17

26 第 三 章 系 統 設 計 與 架 構 3.1 系 統 架 構 方 案 一 我 們 一 開 始 的 想 法 是 以 blade server 的 CPU0 作 為 主 節 點, 其 餘 7 顆 CPU 作 為 僕 節 點, 主 節 點 先 讀 入 YUV 檔, 並 將 其 以 15 個 圖 格 (Frame) 為 單 位, 利 用 MPI 分 送 到 server 上 各 僕 節 點, 各 僕 節 點 再 把 收 到 的 15 個 圖 格 (Frame) 進 行 H.264 編 碼, 再 將 編 碼 完 成 的 15 個 圖 格 (Frame) 送 回 主 節 點, 以 整 合 成 一 個 H.264 格 式 的 影 片 詳 細 流 程 圖 見 下 圖 : START 主 節 點 收 集 YUV 影 片 主 節 點 (node 0) 將 影 片 以 15 個 訊 框 為 單 位, 利 用 MPI 分 送 到 各 僕 節 點 CPU 圖 格 編 碼 ) node 1 ( 進 行 15 個 圖 格 編 碼 ) node 2 ( 進 行 15 個 圖 格 編 碼 ) node 3 ( 進 行 15 個 圖 格 編 碼 ) node 7 ( 進 行 15 個 主 節 點 收 集 各 僕 節 點 編 碼 好 的 訊 框 後, 產 生 H.264 檔 END 圖 九 方 案 一 流 程 圖 但 是 這 個 方 法 無 法 實 現, 因 為 MPI 在 撰 寫 struct 這 個 類 型 時 相 當 的 麻 煩 在 C 18

27 程 式 中 寫 struct 類 型 只 要 先 宣 告 structure 的 名 字, 再 宣 告 裡 面 的 欄 位 即 可 ; 而 MPI 則 必 須 呼 叫 許 多 函 式 這 個 方 法 雖 然 麻 煩, 可 是 只 要 照 著 做 就 可 達 成 struct 功 能 本 專 題 所 使 用 的 JM 編 碼 器 的 程 式 碼 所 用 的 struct 類 型 裡 面 有 許 多 筆 欄 位, 而 且 有 的 欄 位 是 struct,mpi 對 於 struct 裡 還 有 struct 的 類 型 用 上 表 的 宣 告 方 式 無 效, 因 此 本 方 案 才 失 敗 3.2 系 統 架 構 方 案 二 因 為 上 個 方 法 無 法 利 用 MPI 來 分 送 圖 格 (Frame), 所 以 這 一 次 由 我 們 自 己 將 切 割 程 式 YUV 檔 分 割, 想 法 如 下 圖 ( 本 圖 以 8 顆 CPU 執 行 編 碼 為 例 ): YUV YUV 檔 Blade Server H.264 檔 file8 file0 CPU0 file0 file8 file9 file1 CPU1 file1 file file15 file7 CPU7 file7 file15 圖 十 方 案 二 架 構 圖 首 先 讀 入 YUV 檔, 然 後 利 用 本 文 附 錄 的 程 式 將 YUV 檔 以 15 個 圖 格 (Frame) 為 單 位, 分 成 一 個 個 檔 案 以 本 實 驗 為 例, 所 用 的 YUV 檔 有 240 個 圖 格 (Frame), 19

28 因 此 可 分 成 16 個 檔 案 這 16 個 檔 案 依 序 為 file0~file15, 看 有 幾 顆 CPU 執 行 本 程 式 就 讓 它 們 從 這 16 個 檔 案 中 依 序 讀 入 並 編 碼, 之 後 會 出 現 一 個 個 H.264 檔, 沒 有 整 合 以 下 為 本 實 驗 之 流 程 圖 : 圖 十 一 方 案 二 流 程 圖 20

29 第 四 章 系 統 實 作 4.1 實 作 步 驟 1. 了 解 MPI 的 六 大 函 式 並 知 道 如 何 應 用 此 步 驟 是 我 們 專 題 的 基 礎, 會 了 以 後 我 們 才 能 利 用 MPI 函 式 做 我 們 的 專 題 2. 分 析 JM8.0 程 式 碼 的 輸 入 檔 案 和 輸 出 檔 案 的 地 方 這 問 題 若 沒 辦 法 解 決 的 話 專 題 就 沒 辦 法 往 下 做 了, 我 們 花 了 一 些 時 間 才 確 實 找 到 一 開 始 想 說 只 要 找 到 fopen 的 函 式 就 找 出 來 了, 結 果 fopen 有 好 幾 個, 後 來 我 們 先 執 行 編 碼, 了 解 程 式 輸 出 至 螢 幕 上 的 資 訊, 於 是 找 出 程 式 裡 輸 出 此 資 訊 的 printf 函 式 所 使 用 的 變 數, 再 查 哪 個 fopen 用 到 此 變 數 就 是 了 3. 在 輸 入 YUV 檔 案 和 輸 出 H.264 檔 案 的 地 方 插 入 MPI 程 式 碼 此 步 驟 的 主 要 目 的 是 某 CPU 將 YUV 檔 讀 取 一 個 圖 格 (Frame) 後, 再 送 往 其 他 CPU 去 編 碼, 將 每 顆 CPU 分 工 合 作 但 是 此 步 驟 因 為 必 須 用 到 MPI 的 其 他 函 式, 我 們 對 MPI 不 是 了 解 得 很 透 徹, 所 以 此 方 法 不 可 行 4. 自 行 將 YUV 檔 的 所 有 圖 格 (Frame) 平 分 給 CPU 去 編 碼 因 為 上 個 步 驟 不 可 行, 所 以 我 們 自 行 撰 寫 程 式 將 YUV 檔 分 成 幾 個 檔 案, 再 指 定 去 負 責 將 哪 幾 個 檔 案 編 碼 5. 執 行 並 記 錄 時 間 最 後 記 錄 1 顆 2 顆 4 顆 8 顆 CPU 將 YUV 檔 編 碼 成 H.264 檔 所 花 費 的 時 間 並 評 估 以 下 是 本 專 題 實 驗 的 步 驟, 說 明 如 下 : 21

30 Step1: 首 先 把 下 載 下 來 的 JM8.0 程 式 碼 解 壓 縮, 尋 找 JM 目 錄 下 的 tml.dsw 並 執 行 以 對 JM 編 碼 器 做 編 譯 圖 十 二 JM/bin 裡 的 資 料 22

31 Step2: 本 實 驗 以 visual C 程 式 為 例, 出 現 visual C++ 的 視 窗 後, 左 邊 有 ldecod lencod rtpdump 三 個 專 案, 分 別 對 此 三 個 專 案 做 建 置 建 置 完 以 後, 執 行 檔 產 生 在 JM 的 bin 資 料 夾 裡 圖 十 三 編 譯 JM 編 碼 器 23

32 Step3: 執 行 bin 資 料 夾 裡 的 lencod.exe, 出 現 以 下 畫 面 由 下 圖 紅 線 圈 出 來 的 地 方 可 得 知 我 們 把 哪 個 YUV 檔 編 成 H.264 檔 編 出 來 的 H.264 檔 名 是 什 麼 以 本 實 驗 得 知 輸 入 的 YUV 檔 為 foreman_part_qcif.yuv, 而 輸 出 的 H.264 檔 為 test.264, 這 兩 個 地 方 是 本 實 驗 插 入 MPI 程 式 碼 的 關 鍵 圖 十 四 JM 編 碼 器 執 行 畫 面 24

33 Step4: 以 Notepad++ 軟 體 為 例, 將 JM 裡 的 lencod\src 裡 的 所 有.c 檔 開 啟, 然 後 利 用 其 搜 尋 功 能 尋 找 所 有 的 printf, 找 出 Step3 紅 線 圈 出 來 的 資 訊, 如 下 圖, 得 知 輸 入 YUV 檔 名 的 變 數 為 input->infile, 而 輸 出 H.264 檔 名 為 input->outfile 圖 十 五 利 用 Notepad++ 分 析 執 行 畫 面 25

34 Step5: 利 用 搜 尋 功 能 尋 找 所 有 的 fopen, 看 哪 個 fopen 用 到 Step4 找 到 的 兩 個 變 數 : input->infile input->outfile, 用 到 input->infile 的 fopen 為 輸 入 YUV 檔 的 地 方, 用 到 input->outfile 的 fopen 為 輸 出 H.264 檔 的 地 方 圖 十 六 利 用 Notepad++ 分 析 輸 入 輸 出 點 26

35 Step6: 由 上 面 找 到 的 兩 個 fopen 得 知 輸 入 YUV 檔 的 地 方 在 configfile.c, 輸 出 H.264 檔 的 地 方 在 filehandle.c 在 這 兩 個 地 方 插 入 MPI 程 式 碼 來 控 制 每 個 CPU 必 須 負 責 編 譯 或 輸 出 哪 些 檔 案, 在 lencod.c 的 main function 設 迴 圈, 控 制 一 次 幾 個 CPU 去 跑 27

36 4.2 系 統 評 估 為 求 準 確, 下 表 是 利 用 1 個 CPU 2 個 CPU 4 個 CPU 8 個 CPU 分 別 執 行 10 次 所 得 到 的 時 間 : 表 1.3 執 行 時 間 數 據 表 CPU*1 CPU*2 CPU*4 CPU*8 花 費 時 間 花 費 時 間 花 費 時 間 花 費 時 間 第 1 次 s s s 69.79s 第 2 次 s s s 69.56s 第 3 次 s s s 71.89s 第 4 次 555.2s s s 70.14s 第 5 次 s s s 72.63s 第 6 次 s s s 70.02s 第 7 次 s s s 75.47s 第 8 次 s s 143.9s 70.23s 第 9 次 555.4s s 139.6s 71.61s 第 10 次 s s s 69.93s 平 均 每 一 秒 鐘 有 30 張 圖 格 (Frame) 連 續 通 過, 人 眼 感 覺 不 出 其 中 影 片 的 交 互 替 換, 本 實 驗 所 使 用 的 影 片 檔 有 240 張 圖 格 (Frame), 所 以 照 理 說 應 該 8 秒 鐘 就 要 跑 完 可 是 依 上 表 的 數 據 來 看 明 顯 的 發 現 至 少 要 花 1 分 鐘 以 上, 主 要 的 問 題 在 於 此 實 驗 必 須 透 過 網 路 與 blade server 連 接, 網 路 是 否 流 暢 是 影 響 執 行 時 間 的 最 大 因 素 Speedup 代 表 平 行 計 算 提 升 的 倍 數, 計 算 方 式 是 將 執 行 緒 數 目 為 1 28

37 的 時 間 除 以 多 個 執 行 緒 的 時 間, 根 據 上 表 的 數 據 我 們 分 別 求 出 各 情 形 的 平 均 時 間 與 speedup: 表 1.4 CPU 個 數 之 平 均 執 行 時 間 與 Speedup #CPU 平 均 執 行 時 間 Speedup s s s s 依 上 表 可 得 以 下 兩 圖 : 平 均 執 行 時 間 曲 線 圖 與 speedup 曲 線 圖 Time (sec) Numbers of CPU 圖 十 七 CPU 個 數 執 行 時 間 圖 29

38 10 Speedup T1/Tn Numbers of CPU 圖 十 八 Speedup 曲 線 圖 由 上 圖 得 知 這 個 程 式 平 行 計 算 測 試 結 果 幾 乎 呈 現 線 性 的 成 長, 其 原 因 在 於 這 次 實 驗 我 們 自 行 切 割 YUV 檔, 並 送 到 blade server 做 編 譯, 省 去 了 CPU 之 間 互 相 傳 送 圖 格 (Frame) 的 動 作,speedup 曲 線 圖 才 會 這 麼 好 看 雖 然 編 碼 花 了 這 麼 多 時 間, 由 執 行 時 間 圖 的 走 向 可 以 知 道 只 要 CPU 再 多 一 點, 一 定 可 以 達 到 本 專 題 的 目 的 對 人 眼 來 說, 平 均 每 一 秒 鐘 有 30 張 圖 格 (Frame) 連 續 通 過, 感 覺 不 出 其 中 影 片 的 交 互 替 換, 自 然 而 然 的 認 為 是 影 像 在 動 本 實 驗 所 使 用 得 影 片 檔 有 240 圖 格 (Frame), 因 此 應 該 花 8 秒 以 實 驗 數 據 來 看,CPU 個 數 若 為 原 來 的 兩 倍, 則 平 均 執 行 時 間 約 為 原 來 的 一 半, 所 以 當 1 顆 CPU 平 均 花 了 秒, 則 64 顆 CPU 大 約 花 了 / 秒 因 此 若 利 用 64 顆 CPU 即 可 達 到 每 秒 30 張 圖 格 (Frame) 30

39 第 五 章 結 論 與 未 來 發 展 本 次 專 題, 我 們 設 計 利 用 多 顆 CPU 對 YUV 檔 編 碼 我 們 實 際 利 用 軟 體, 使 用 MPI 函 式 嵌 入 到 JM 程 式 碼 中 其 中 了 解 MPI 函 式 的 使 用 參 數 和 使 用 時 機 以 及 H.264 的 運 作 方 式, 和 Linux 的 VI 文 書 指 令 雖 然 沒 辦 法 利 用 MPI 將 圖 格 (Frame) 傳 送 回 去, 不 過 在 其 中 我 們 得 到 了 將 理 論 化 為 實 際 的 經 驗 31

40 參 考 文 獻 [1] 鄭 守 成,"C 語 言 MPI 平 行 計 算 程 式 設 計 ",Jan 2002 [2] 鄭 守 成 周 朝 宜,"MPI 程 式 撰 寫 與 實 作 ",Nov 2006 [3] 林 勝 峰,"MPI 平 行 程 式 設 計 ", 勁 智 數 位 科 技 股 份 有 限 公 司 技 術 研 發 部 [4] 黃 圳 柏 邱 基 峰 黃 文 祥 謝 錫 堃,"Design and Implementation of Web-Based Parallel Computing Environments"2003 [5] Shiping LI,Mei YU,Gangyi JIANG,Tae-Young CHOI,Yong-Deak KIM, "Approaches To H.264-Based Stereoscopic Video Coding",2004 [6] Galina Sabeva,Salma Ben Jamaa,Michel Kieffer,and Pierre Duhamel,"Robust Decoding of H.264 Encoded Video Transmitted over Wireless Channels",2006 [7] Li Zhuo Qiang Wang David Dagan Feng Lansun Shen,"Optimization and Implementation of H.264 Encoder on DSP Platform",2007 [8] Maxine Lee,Alex Moore,"H.264 Encoder Design",May 2005 [9] 楊 士 萱 陳 柏 源,"H.264/AVC 技 術 與 應 用 簡 介 ",2007 [10] San Jose,"Revision of the H.264/MPEG-4 AVC Reference Software Manual",April 2007 [11] 曾 現 鈞,"H.264 先 進 視 訊 編 碼 概 述 ",

41 附 錄 這 是 本 次 專 題 所 所 用 到 的 程 式, 用 來 分 割 YUV 檔 #include <stdio.h> #define WIDTH 176 #define HEIGHT 144 #define ALL_FRAMES 300 #define INFILE "foreman_qcif.yuv" #define FRAME_SIZE (WIDTH*HEIGHT + WIDTH*HEIGHT/4 + WIDTH*HEIGHT/4) /* frame_size = Y_frame + U_frame + V_frame = width*height + width*height/4 + width*height/4 */ int main(int argc, char* argv[]) { int fnum, i, j; //fnum:frame 編 號 unsigned char *img [FRAME_SIZE]; FILE *fptr, *fptr1, *fptr2, *fptr3, *fptr4, *fptr5, *fptr6, *fptr7, *fptr8, *fptr9, *fptr10, *fptr11, *fptr12, *fptr13, *fptr14, *fptr15, *fptr16, *fptr17, *fptr18, *fptr19, *fptr20; fptr=fopen(infile, "rb"); fptr1= fopen("out_foreman_qcif_00.yuv", "wb"); fptr2= fopen("out_foreman_qcif_01.yuv", "wb"); fptr3= fopen("out_foreman_qcif_02.yuv", "wb"); fptr4= fopen("out_foreman_qcif_03.yuv", "wb"); fptr5= fopen("out_foreman_qcif_04.yuv", "wb"); fptr6= fopen("out_foreman_qcif_05.yuv", "wb"); 33

42 fptr7= fopen("out_foreman_qcif_06.yuv", "wb"); fptr8= fopen("out_foreman_qcif_07.yuv", "wb"); fptr9= fopen("out_foreman_qcif_08.yuv", "wb"); fptr10=fopen("out_foreman_qcif_09.yuv", "wb"); fptr11=fopen("out_foreman_qcif_10.yuv", "wb"); fptr12=fopen("out_foreman_qcif_11.yuv", "wb"); fptr13=fopen("out_foreman_qcif_12.yuv", "wb"); fptr14=fopen("out_foreman_qcif_13.yuv", "wb"); fptr15=fopen("out_foreman_qcif_14.yuv", "wb"); fptr16=fopen("out_foreman_qcif_15.yuv", "wb"); fptr17=fopen("out_foreman_qcif_16.yuv", "wb"); fptr18=fopen("out_foreman_qcif_17.yuv", "wb"); fptr19=fopen("out_foreman_qcif_18.yuv", "wb"); fptr20=fopen("out_foreman_qcif_19.yuv", "wb"); for(fnum=0; fnum<all_frames; fnum++) { fread(img, 1, FRAME_SIZE, fptr); if(fnum>=0 && fnum<=14) // 將 frame 0~14 寫 入 檔 案 { printf("\n%d", fnum); fwrite(img, 1, FRAME_SIZE, fptr1); } if(fnum>=15 && fnum<=29) // 將 frame 15~29 寫 入 檔 案 { printf("\n%d", fnum); fwrite(img, 1, FRAME_SIZE, fptr2); } 34

43 if(fnum>=30 && fnum<=44) // 將 frame 30~44 寫 入 檔 案 { printf("\n%d", fnum); fwrite(img, 1, FRAME_SIZE, fptr3); } if(fnum>=45 && fnum<=59) // 將 frame 45~59 寫 入 檔 案 { printf("\n%d", fnum); fwrite(img, 1, FRAME_SIZE, fptr4); } if(fnum>=60 && fnum<=74) // 將 frame 60~74 寫 入 檔 案 { printf("\n%d", fnum); fwrite(img, 1, FRAME_SIZE, fptr5); } if(fnum>=75 && fnum<=89) // 將 frame 75~89 寫 入 檔 案 { printf("\n%d", fnum); fwrite(img, 1, FRAME_SIZE, fptr6); } if(fnum>=90 && fnum<=104) // 將 frame 90~104 寫 入 檔 案 { printf("\n%d", fnum); fwrite(img, 1, FRAME_SIZE, fptr7); } 35

44 if(fnum>=105 && fnum<=119) // 將 frame 105~119 寫 入 檔 案 { printf("\n%d", fnum); fwrite(img, 1, FRAME_SIZE, fptr8); } if(fnum>=120 && fnum<=134) // 將 frame 120~134 寫 入 檔 案 { printf("\n%d", fnum); fwrite(img, 1, FRAME_SIZE, fptr9); } if(fnum>=135 && fnum<=149) // 將 frame 135~149 寫 入 檔 案 { printf("\n%d", fnum); fwrite(img, 1, FRAME_SIZE, fptr10); } if(fnum>=150 && fnum<=164) // 將 frame 150~164 寫 入 檔 案 { printf("\n%d", fnum); fwrite(img, 1, FRAME_SIZE, fptr11); } if(fnum>=165 && fnum<=179) // 將 frame 165~179 寫 入 檔 案 { printf("\n%d", fnum); fwrite(img, 1, FRAME_SIZE, fptr12); } 36

45 if(fnum>=180 && fnum<=194) // 將 frame 180~194 寫 入 檔 案 { printf("\n%d", fnum); fwrite(img, 1, FRAME_SIZE, fptr13); } if(fnum>=195 && fnum<=209) // 將 frame1950~209 寫 入 檔 案 { printf("\n%d", fnum); fwrite(img, 1, FRAME_SIZE, fptr14); } if(fnum>=210 && fnum<=224) // 將 frame 210~224 寫 入 檔 案 { printf("\n%d", fnum); fwrite(img, 1, FRAME_SIZE, fptr15); } if(fnum>=225 && fnum<=239) // 將 frame 225~239 寫 入 檔 案 { printf("\n%d", fnum); fwrite(img, 1, FRAME_SIZE, fptr16); } if(fnum>=240 && fnum<=254) // 將 frame 240~254 寫 入 檔 案 { printf("\n%d", fnum); fwrite(img, 1, FRAME_SIZE, fptr17); } 37

46 if(fnum>=255 && fnum<=269) // 將 frame 255~269 寫 入 檔 案 { printf("\n%d", fnum); fwrite(img, 1, FRAME_SIZE, fptr18); } if(fnum>=270 && fnum<=284) // 將 frame 270~284 寫 入 檔 案 { printf("\n%d", fnum); fwrite(img, 1, FRAME_SIZE, fptr19); } if(fnum>=285 && fnum<=299) // 將 frame 285~299 寫 入 檔 案 { printf("\n%d", fnum); fwrite(img, 1, FRAME_SIZE, fptr20); } } fclose(fptr); fclose(fptr1); fclose(fptr2); fclose(fptr3); fclose(fptr4); fclose(fptr5); fclose(fptr6); fclose(fptr7); fclose(fptr8); fclose(fptr9); 38

47 fclose(fptr10); fclose(fptr11); fclose(fptr12); fclose(fptr13); fclose(fptr14); fclose(fptr15); fclose(fptr16); fclose(fptr17); fclose(fptr18); fclose(fptr19); fclose(fptr20); return 0 } 39