昨天我們介紹了gst-inspect-1.0這個工具，今天就要教大家怎麼把元件串起來

gst-launch-1.0作用

像是ffmpeg、curl這些非常有名的專案除了提供開發用的程式庫之外，也提供了CLI工具讓開發者可以快速的去使用這個程式庫的功能，對於測試或者是簡易的應用來說是非常方便的。GStreamer同樣也提供了gst-launch-1.0這個工具，我們直接舉個讀取MP4並播放的例子，因為WSL有官宣的播放問題(參考FAQ)，所以就先讓串流只播放不顯示

gst-launch-1.0 filesrc location=/opt/nvidia/deepstream/deepstream/samples/streams/sample_720p.mp4 ! decodebin ! fakesink sync=1

執行之後你就能看到下方的計時狀態。

另外，如果你是第一次執行會發現怎麼跳出好多警告，但不用緊張，大部分的載入錯誤都是我們用不到的插件，GStreamer會把插件的載入紀錄存放在~/.cache/gstreamer-1.0，後續執行的時候就不會再出現這些警告了。同樣地，如果你有做任何插件的更新，也記得把那個暫存資料刪掉，確保GStreamer重新辨識插件哦。

讓你的串流使用GPU的硬體資源

首先我們先來了解你的的GPU有什麼樣的硬體可以使用吧！其實現代GPU除了玩遊戲所熟知的3D渲染硬體之外，還有一些有用的硬體可以加速特定的應用，在本系列文章中除了運算單元外最重要的就是編碼器(Encoder)和解碼器(Decoder)。

我們可以執行指令來查詢GPU的詳細資訊，目標資訊在Utilization欄位，我們往後查10行

nvidia-smi -q | grep -A 10 "Utilization"

可以看到類似這樣的輸出，像我的GPURTX 3050(卡荒時期僅存的選擇)是有編碼器和解碼器的，這對DeepStream來說非常有幫助，你可以省下大量的CPU資源及運算時間。

安裝一下酷炫的工具

假設我們只有Terminal可以使用(只是看起來比較厲害)，你要同時執行GStreamer指令，又要同時顯示硬體使用率，我們可以裝上tmux、nvtop、htop

• tmux 讓可以在同一個進程(Process)內分割多個Terminal
• nvtop 比較炫的GPU資源檢視TUI，類似htop。如果你不想用這個也可以使用指令nvidia-smi dmon，就只是輸出是純文字
• htop 可以檢視CPU及記憶體使用率的TUI

執行以下命令安裝工具，因為在容器內是root，不用加上sudo

apt update && apt install -y tmux nvtop htop

使用tmux分割Terminal

執行tmux，會進入tmux的Terminal。接著按下CTRL+%進行垂直分割，你可以得到下圖的結果

如果你要水平分割就使用CTRL+"

接著你就可以用CTRL+b+方向鍵切換到不同的Terminal，剩下關於tmux的操作有興趣的可以自己Google，這邊就只提到用得上的操作

使用nvtop檢視GPU資源使用率

執行nvtop會進入下圖的TUI

然後預設編碼器跟解碼器只有在運作時才會跳出使用率並維持一段時間，我們可以這樣設定：F2->Devices->Enter->Keep displaying Encoder/Decoder rate ...->Enter，狀態應該會從30sec變成always，回到主頁之後就會看到額外的資訊

使用htop檢視CPU及記憶體使用率

預設是看不到CPU的總使用率的，我們可以透過F2->Meters->Available meters->CPU Average->Enter把總使用率打開

硬體解碼器示範

前面我們有做過簡易的播放MP4範例，那我們搭配nvtop再來執行一次剛才的範例。有趣的事情發生了，DEC使用率上來了，代表我們成功使用到GPU上的解碼器，另外CPU使用率也是相對充裕的。

那中間發生了什麼神奇的事情呢？回到我們前面提到過的autoplugging，decodebin就是支援這項功能的高階元件，使用decodebin等效於以下指令

gst-launch-1.0 filesrc location=/opt/nvidia/deepstream/deepstream/samples/streams/sample_720p.mp4 ! qtdemux ! h264parse ! nvv4l2decoder ! fakesink sync=1

decodebin會根據進來的資料去挑選解碼所需要的元件，qtdemux就是把影像資料從MP4容器內拆出來，經過h264parse轉為h264封包，最後使用nvv4l2decoder解碼成影格(Frame)

之前我們不是有提到Rank這個數值的用意，可以看到nvv4l2decoder的Rank分數是267，預設情況也沒有其他已安裝的解碼元件的分數比他還高，所以decodebin就會優先選擇它作為解碼元件

軟體解碼 v.s. 硬體解碼

預設DeepStream容器是沒有特別安裝軟體解碼元件的，這部分NVIDIA有提供使用者一個腳本自行安裝額外的插件，腳本位置在/opt/nvidia/deepstream/deepstream/user_additional_install.sh，我們就執行腳本安裝一下。

安裝完成後我們改用ffmpeg的GStreamer解碼元件來測試一下

gst-launch-1.0 filesrc location=/opt/nvidia/deepstream/deepstream/samples/streams/sample_720p.mp4 ! qtdemux ! h264parse ! avdec_h264 ! fakesink sync=1

可以發現CPU資源還是挺充裕的，其實我也是在寫這篇文章的當下才發現這件事情，原本預期應該是CPU使用率會上升不少，看來720p影片對CPU的壓力還是太小了。而且如果我把fakesink設定為sync=0，讓影片全速解碼再比較兩者之間的運行時間，得出的結果如下，反而軟體解碼的速度不減反超將近一倍

# nvv4l2decoder
Execution ended after 0:00:00.984187540

# avdec_h264
Execution ended after 0:00:00.498357942

這部份如果要細查原因就有點超出這次主題的範圍了，目前推估是因為我CPU的時脈都維持在4.5GHz以上，以及ffmpeg是個發展許久的程式庫，或許有針對Intel CPU做許多優化，當然這只是猜測，有興趣的人就自己去深究囉

結語

雖然我們實測的結果軟體解碼反而超越硬體解碼的速度，但其實DeepStream的價值是讓你可以在串流應用中更容易使用GPU上的硬體資源。像編碼器/解碼器這些資源都是可以執行特定任務的，我們就能透過這些硬體資源減輕CPU的負擔，讓應用有更多CPU資源可以做其他的事情，特別是在邊緣運算平台上，CPU的資源就顯得更加珍貴，這時候額外的硬體資源就能幫上大忙。