Hello, 各位 iT 邦幫忙 的粉絲們大家好~~~

在本系列文因為工作上的產品應用需求，進而探索到很多層面的點滴事。透過每篇 EP 的分享把這些點滴整理，看起來或許像是個獨立的小品抒發文、也或許是一系列技術研究文！？

總之，就當作的隨手雜記文吧！

本篇是 莫名其妙就跟世界等級的 OpenSource 專案攪和了!? 系列文的 EP11。

接續前回的指令：
gst-launch-1.0 filesrc location="c:/tmp/bbb_sunflower.mp4" ! qtdemux ! avdec_h264 ! x264enc ! filesink location="c:/tmp/new_bbb_sunflower.mp4"

如果能夠在接入 filesink 之前加上 h264parse 與 mp4mux 的處理，這樣就可以透過 h264pars 正確地完成 H.264 位元串流封裝正確，並透過 mp4mux 按照 mp4 的檔案格式寫入到檔案中。

於是就形成如下指令：
gst-launch-1.0 filesrc location="c:/tmp/bbb_sunflower.mp4" ! qtdemux ! avdec_h264 ! x264enc ! h264parse ! mp4mux ! filesink location="c:/tmp/new_bbb_sunflower.mp4"

這時候，一般常用的多媒體影音撥放程式，應該就可以正常開啟該檔案。

不過，會發現轉出來的這個 new_bbb_sunflower.mp4 檔案比起原 bbb_sunflower.mp4 檔案的大小，小了許多。

仔細一聽會發現，整個檔案安靜無聲。

這就得提到前一回說 "qtdemux 先忽略" 的 qtdemux 了。

由於這個 qtdemux 會把 audio (音訊)與 video (影像)分離出來，而後續又只針對影像作檔案保存的處理，所以就得到這樣的結果了。

注意看下圖 new_bbb_sunflower.mp4 (右)的音訊資訊是完全沒有的。

(雖然造成檔案大小變小的主要原因不是因為沒有音訊)

另外，當電腦執行下列指令時：
gst-launch-1.0 filesrc location="c:/tmp/bbb_sunflower.mp4" ! qtdemux ! avdec_h264 ! x264enc ! h264parse ! mp4mux ! filesink location="c:/tmp/new_bbb_sunflower.mp4"

過程中會發現 CPU 的運算會突然飆高。

這就要問問扮演 encoder 的 x264enc。

由於 x264enc 是一套完全透過 CPU 計算處理的通用型編碼器，所以如果要在各種有 gstreamer 的平台上運作時，透過 x264enc 來進行編碼是沒問題的。

但是付出的代價就是要大量花費 CPU 的運算量。

由於目前使用的電腦只有內建 Intel® Iris® Xe Graphics 的這個 GPU，在 Intel 的台灣官網上只能看到有列出來，但連結點進去沒顯示任何東西。

(畫面擷取自 Intel 台灣官網)

但在 gstreamer 的 plugin 當中有 qsv 的元件是支援使用 Intel Quick Sync 的一系列 decoder/encoder 的。

所以指令可以更換成：
gst-launch-1.0 filesrc location="c:/tmp/bbb_sunflower.mp4" ! qtdemux ! avdec_h264 ! videoconvert ! qsvh264enc ! h264parse ! mp4mux ! filesink location="c:/tmp/new_bbb_sunflower.mp4"

這此執行的過程中就會發現 CPU 的運算下降，而 GPU 的運算也變高。

雖然是透過不太優秀的 GPU 來運算，但再怎麼樣都透過比 CPU 運算來的好，所以完整跑完整個檔案的時間也大幅縮短。

透過這樣子對比就可以理解到為什麼有硬體加速是很重要的了。

PS avdec_h264 也是一種軟體解碼(仰賴 CPU 運算)的跨平台通用型 decoder。

所以，如果可以的話選擇於硬體解碼的 decoder 會是比較好的方式。

而在 windows 平台上通常也都可選 d3d11h264dec 或 d3d12h264dec 這兩個 decoder 來處理。