MSE(Media Source Extensions)介紹

什麼是MSE?

媒體源擴展(Media Source Extensions, MSE)是一項由W3C制定的網頁API標準,旨在通過JavaScript動態生成和控制媒體流,從而實現無插件且基於Web的流媒體播放功能。MSE允許開發者將媒體數據源附加到HTMLMediaElement(如<audio><video>標籤),並動態地為這些元素構建媒體源

MSE的主要功能

  • 動態媒體流構建:MSE允許開發者使用JavaScript動態地創建和控制媒體流,這意味著可以根據需要動態加載和播放媒體數據,而不需要預先下載整個文件。
  • 自適應比特率流:MSE是實現自適應比特率流(如DASH和HLS)的基礎,這些技術允許根據網絡條件自動調整視頻質量,以提供最佳的觀看體驗。
  • 多種媒體格式支持:MSE支持多種媒體容器和編解碼格式,常見的包括H.264視頻編碼、AAC音頻編碼和MP4容器格式。

MSE的應用場景

  • 點播影片:MSE 可以用於點播影片服務,允許使用者在觀賞過程中動態加載不同解析度的影片片段,以適應不同的網路狀況。
  • 直播影片:MSE 也支援直播影片流,雖然在即時性要求較高的應用中(例如視訊通話),MSE 可能不如 WebRTC 那麼合適。
  • 自訂媒體播放:開發者可以利用 MSE 建立自訂的媒體播放器,實現更靈活的控制與功能,例如自訂緩衝策略及錯誤處理機制。

MSE的優勢

  • 動態加載:MSE允許根據需要動態加載媒體數據,減少了初始加載時間和帶寬消耗。
  • 自適應流媒體:MSE支持自適應比特率流媒體技術,如MPEG-DASH和HLS,提供更好的用戶體驗。
  • 高效緩衝管理:開發者可以精細控制緩衝區,實現更高效的媒體播放。

如何使用MSE

1. 確認瀏覽器支援度,可以使用以下JavaScript進行檢查:

if ('MediaSource' in window) {
    console.log('MSE is supported');
} else {
    console.log('MSE is not supported');
}

2. 創建MediaSource對象

創建一個MediaSource對象並將其附加到<video>元素上:

<video id="videoElement" controls></video>
<script>
    var video = document.getElementById('videoElement');
    var mediaSource = new MediaSource();
    video.src = URL.createObjectURL(mediaSource);
</script>

3. 處理sourceopen事件

mediaSource.addEventListener('sourceopen', function() {
    var sourceBuffer = mediaSource.addSourceBuffer('video/mp4; codecs="avc1.42E01E, mp4a.40.2"');
    fetchAndAppendSegments(sourceBuffer);
});

4. 獲取和附加媒體片段

使用fetch API或其他方法來獲取媒體片段,並將其附加到SourceBuffer中:

function fetchAndAppendSegments(sourceBuffer) {
    fetch('path/to/video/segment.mp4')
        .then(response => response.arrayBuffer())
        .then(data => {
            sourceBuffer.appendBuffer(data);
        });
}

5. 處理緩衝更新

sourceBuffer.addEventListener('updateend', function() {
    if (mediaSource.readyState === 'open') {
        fetchAndAppendSegments(sourceBuffer);
    }
});

MSE的瀏覽器支持度

請見此:https://caniuse.com/mediasource

一直以來有低延遲需求的高分發直播需求都會很困擾iPhone對MSE的不支援

但是好消息!!!

Safari 17.1 brings the new Managed Media Source API to iPhone

https://www.radiantmediaplayer.com/blog/at-last-safari-17.1-now-brings-the-new-managed-media-source-api-to-iphone.html

蘋果公司的 Safari 17.1 更新為 iPhone 帶來了新的 Managed Media Source API (MSS),這是 Media Source Extensions (MSE) 的進化版本,旨在提供更好的電池效能和網絡優化。

Safari 17.1 的更新標誌著蘋果對 iPhone 的 Managed Media Source API 支持,這是一項長期以來由流媒體行業所期待的功能。MSS 是 MSE 的進化,旨在提供更高效的流媒體體驗,並且在 iOS 上的支持意味著現有的視頻播放器需要從 MSE 遷移到 MSS。MSS 允許瀏覽器更多地控制流媒體的邏輯和設備能力檢測,這些以往由視頻應用程序處理。蘋果強調 MSS 在電池消耗和網絡效率方面的優勢,尤其是在 5G 網絡下。儘管如此,蘋果仍然建議在 Safari 中僅支持蘋果設備的開發者優先使用原生 HLS。Radiant Media Player 已在測試 MSS 的過程中,並計劃添加對 iPhone Safari 中 MSS 的支持,同時保留原生 HLS 作為蘋果設備上的首選方案。

WebRTC 點對點特性帶來的複雜性

什麼是WebRTC

WebRTC(Web Real-Time Communication)是一種開源技術,允許瀏覽器和移動應用程序進行音頻、視頻和數據的實時通信。它能夠在瀏覽器內直接進行音頻和視頻通話,無需安裝任何插件或額外的軟件,這大大簡化了用戶的操作。支持多種平台,包括Web、Android、iOS、Windows、MacOS和Linux。其非常的低延遲,這對於需要即時反應的應用場景(如視頻會議、在線遊戲等)非常重要。

WebRTC的關鍵技術

參考資料:https://webrtc.github.io/webrtc-org/architecture/

WebRTC 的架構分為兩個主要層次,一層是針對瀏覽器開發者的 WebRTC C++ API,另一層是針對網絡應用開發者的 Web API。

WebRTC 支援的音訊與影像引擎具備多種功能,包括各種音訊編解碼器(如 iSAC、iLBC、Opus)、回音消除(AEC)、降噪(NR)、影像編解碼器(如 VP8)、影像抖動緩衝(Video Jitter Buffer)以及畫面增強等。除此之外,WebRTC 的傳輸與會話層包含 RTP 網路層、STUN/ICE 用於網路連線建立,以及抽象的會話管理層,讓應用開發者可自行選擇協議實作方式。

技術目標與限制

WebRTC 的目標是打造一個強大的端對端即時通訊平台,讓開發者能創建豐富的即時多媒體應用,並能夠在不同的網頁瀏覽器及平台上執行。

WebRTC 是一種支持瀏覽器間進行實時音視頻通信的技術,利用點對點(P2P)的 UDP 傳輸來實現低延遲的數據流傳輸。然而,由於網絡環境中的 NAT(Network Address Translation)和防火牆的存在,直接的 P2P 連接可能會受到限制。因此,WebRTC 使用了 ICE 框架來解決 NAT 穿透問題

WebRTC 的 NAT 穿透技術

WebRTC的NAT穿透技術是實現點對點(P2P)通信的關鍵。如果NAT穿透失敗,則無法建立直接的P2P連線,這會影響通信的品質和延遲。

WebRTC使用多種技術來實現NAT穿透,主要包括ICE(Interactive Connectivity Establishment)、STUN(Session Traversal Utilities for NAT)和TURN(Traversal Using Relays around NAT)。

  1. ICE(Interactive Connectivity Establishment)
    • ICE 是一個框架,整合了 STUN 和 TURN 技術,用於確保端點之間的連接
  2. STUN(Session Traversal Utilities for NAT)
    • STUN 用於獲取位於 NAT 後面的設備的公共 IP 地址,實現 UDP 打洞,以便建立直接的 P2P 連接
  3. TURN(Traversal Using Relays around NAT)
    • 當 STUN 失敗時,TURN 提供中繼服務器,用於轉發數據流,確保通信的可靠性

即使有了這些協議,WebRTC 在某些情況下仍無法達到 100% 的網絡穿透性,特別是在某些複雜的網絡環境中,而這會造成無法建立直接的P2P連線而無法播放串流,即使TURN伺服器能夠建立連接,由於數據需要通過中繼伺服器轉發,這會增加通信的延遲,影響用戶體驗。使用TURN伺服器會增加網路頻寬消耗,因為所有數據都需要通過中繼伺服器進行轉發,這對於高流量的應用來說是一個挑戰。

相比之下,基於 HTTP 的協議如 HLS 更具有普遍性和 CDN 支援,但延遲較高。

不適合以下情境

  • 大規模廣播:WebRTC 的點對點架構非常適合小規模的通訊,但當需要大規模的多人廣播或直播時,WebRTC 效率較低,因為它需要每個用戶單獨建立連線。這樣會消耗大量的網路帶寬和資源。
  • 資料存儲與回放:WebRTC 主要設計用於即時通訊,不適合用來處理錄製和回放功能。如果需要錄製通訊內容,還需結合其他伺服器端解決方案來存儲和管理這些資料。
  • 多媒體品質保證:WebRTC 的多媒體傳輸受限於網路環境,無法完全保證高品質的影像和音訊。若需要穩定且高畫質的多媒體傳輸,可能需要更專業的解決方案。

為何不適合大規模直播的場景

WebRTC 雖然適合小規模通信(1-4 名參與者),但在大規模應用時需要後端基礎設施的支持。

這是因為WebRTC主要設計用於點對點(P2P)通信,這意味著它在處理大規模直播時會遇到性能瓶頸。當用戶數量超過一定範圍時,WebRTC的效能會顯著下降,並且需要額外的媒體伺服器(如MCU或SFU)來中繼和分發流量。

這邊網頁有介紹如何利用中繼點來避免效能瓶頸問題

https://medium.com/agora-io/webrtc-architectures-advantages-limitations-7016b666e1ae

WebRTC 的點對點特性帶來的複雜性

1. NAT 穿透(NAT Traversal)

  • NAT(Network Address Translation,網絡地址轉換) 是大多數家庭路由器或公司防火牆使用的技術,用來讓多個設備共享一個公共 IP 地址,並同時保護內網免受外部未經授權的訪問。
  • WebRTC 是點對點的協議,這意味著兩個終端需要直接互相通信。然而,當設備位於 NAT 後面時,直接的連線會變得困難,因為內網中的設備沒有公共 IP,無法直接被外部訪問。

NAT 穿透技術:

為了解決 NAT 穿透問題,WebRTC 使用了一些技術:

  • STUN(Session Traversal Utilities for NAT):STUN 伺服器幫助客戶端找到自己的公共 IP 和端口。當一個 WebRTC 用戶端連接到 STUN 伺服器時,伺服器會回傳用戶端的公共 IP 和端口,這些信息可以用來嘗試與另一個用戶端進行點對點連線。
  • TURN(Traversal Using Relays around NAT):如果 STUN 無法成功穿透 NAT(例如某些嚴格的 NAT 或防火牆阻止了連線),TURN 伺服器會作為中繼來幫助兩個用戶端進行連接。TURN 伺服器實際上會中繼點對點之間的數據,但這會增加延遲和成本,因為流量需要通過伺服器轉發。
  • ICE(Interactive Connectivity Establishment):ICE 是 WebRTC 中用來協調和選擇最佳連線方式的協議。它會嘗試使用 STUN 獲得公共 IP,並且如果 STUN 失敗,則會回退到使用 TURN 中繼伺服器來建立連接。ICE 的工作原理是嘗試多種連接路徑(直接連線、STUN、TURN),然後選擇最有效的路徑。

複雜性:

  • NAT 類型差異:不同類型的 NAT(如對稱 NAT 和全錐形 NAT)在處理穿透時行為不同,這會導致有時候需要 TURN 伺服器來中繼,即便兩個用戶端可能在理論上能夠直接通信。
  • STUN 和 TURN 伺服器部署:如果你在應用中使用 WebRTC,你需要設置和維護 STUN 和(可能的)TURN 伺服器,這增加了基礎架構的複雜性。

2. 信令伺服器(Signaling Server)

  • WebRTC 需要在兩個用戶端之間交換連線信息,例如 ICE 候選者、SDP(Session Description Protocol,用於交換媒體能力的協議),以協調和建立點對點的連線。這些交換的連線信息需要透過一個中心伺服器進行,這個伺服器稱為 信令伺服器
  • 信令本身不屬於 WebRTC 的範疇,這意味著開發者需要自行選擇或實現信令系統。信令系統可以使用任何協議,如 WebSocket、HTTP 或 WebRTC DataChannel。

信令的功能:

  • 交換 SDP 和 ICE 信息:信令伺服器的主要作用是幫助兩個用戶端交換 SDP 和 ICE 信息,以便雙方可以建立連線。
  • 管理連線建立與斷開:信令伺服器還負責管理連線的建立和斷開,例如用來處理 WebRTC 呼叫的邀請、接受、取消和斷開等控制訊息。

複雜性:

  • 不標準化:WebRTC 並沒有標準的信令協議,這意味著開發者需要選擇或設計一個合適的信令系統。常見的做法是使用 WebSocket 來實現實時的雙向信令通信。
  • 額外伺服器需求:信令伺服器必須在應用中持續運行,以支持每個連線的初始設置,這增加了額外的伺服器和開發成本。

3. 連線穩定性(Connection Stability)

由於 WebRTC 依賴點對點連線,網絡條件的波動會直接影響連線的穩定性。特別是在移動設備或網絡不穩定的情況下,WebRTC 連線可能會中斷或劣化。

挑戰:

  • 網絡切換:如果使用者在 Wi-Fi 和行動數據網絡之間切換,WebRTC 連線可能會中斷,因為 IP 地址和路由會發生變化。
  • 封包丟失與延遲:在不穩定的網絡環境中(如高延遲或丟包率高的網絡),WebRTC 連線的質量會受到很大影響,導致視頻或音頻卡頓、延遲增加,甚至連線斷開。
  • 重連機制:WebRTC 並沒有內建的自動重連機制,如果連線中斷,應用需要自己實現重連邏輯,這增加了實作的複雜性。

介紹 OpenAI o1-preview

官網介紹o1-preview

介紹 OpenAI o1-preview:https://openai.com/index/introducing-openai-o1-preview

首次瞭解:探索 GitHub Copilot 中的 OpenAI o1:
https://github.blog/news-insights/product-news/openai-o1-in-github-copilot/

在2024/9/12,OpenAI推出了o1-preview的模型,這個模型的最大特色就是具備有先進推理能力,可解決難題。測試顯示o1-preview在程式碼分析和優化方面效果良好。該模型能思考挑戰並能夠將複雜任務分解為步驟,這可以優化程式碼以解決性能問題,加速開發工作流程。

透過這樣的思考流程,ChatGPT可以完成更複雜的程式撰寫任務,過去,我們仍會需要透過人的思考將任務拆細後一步一步請ChatGPT幫忙完成,再由工程師將任務功能組合起來,而現在o1-preview則自己就能夠具備有將複雜任務拆細的能力。

從下圖可看見,ChatGPT的程式撰寫能力瞬間從11分進步到89分(圖片來源: https://openai.com/index/learning-to-reason-with-llms/)

o1-preview 模型的新功能總覽

隨著 o1-preview 模型的推出,這個模型在性能、功能和未來更新方向上展現了許多新亮點。

  • 模型大小與性能
    o1 系列的模型中,o1-mini 和 o1-preview 各有特色。o1-mini 相較於 o1-preview 體積更小,速度更快,預計將來會提供給免費用戶使用。o1-mini 雖然在世界知識上較有限,但在 STEM 任務和編碼相關任務上表現出色,且能探索更多的思考鏈。而 o1-preview 則作為一個早期檢查點,位於性能和大小之間,能夠處理更開放的任務,並支持長鏈思考過程。
  • 輸入 Token 與上下文處理能力
    o1 的輸入 token 與 GPT-4o 採用相同的 tokenizer 且能夠處理更長的上下文,在未來版本中還會進一步擴展輸入上下文的長度,減少對輸入內容的分塊需求。儘管目前無法在連鎖思考(CoT)期間暫停推理來添加更多上下文,但這項能力有望在未來實現。
  • 工具與功能更新
    目前 o1-preview 尚未開放工具使用,但未來將支持函數調用、代碼解釋器與瀏覽功能。此外,將加入工具支持、結構化輸出與系統提示等增強功能。用戶將來可能還能控制思考時間和 token 限制,並支援流式傳輸。
  • 連鎖思考推理
    o1 模型在推理時會生成隱藏的思考鏈,這使得它能夠在處理複雜問題時展現更強的推理能力。目前 CoT token 會被摘要,尚未開放給 API 用戶,但隨著強化學習技術的加入,模型的連鎖思考能力將進一步提升
  • API 與使用限制
    o1-mini 在 ChatGPT Plus 用戶中設有每週 50 次提示的限制,並計劃推出更多 API 訪問層級和更高的速率限制。提示緩存是用戶的熱門需求,未來可能會加入此功能。
  • 價格、微調與擴展
    o1 的定價將遵循每 1-2 年降價的趨勢,並支持批量 API 定價。模型的微調尚無具體時間表,但研究與工程人才的限制可能會影響未來的推理擴展計劃。
  • 模型開發與研究亮點
    o1 模型在創造性思維、哲學推理及複雜任務處理上展現了強大能力,甚至內部測試中也表現出色。未來版本將進一步擴展世界領域知識,並更新數據以提升性能。
  • 提示技術與最佳實踐
    o1 模型對於提示的接受度高,尤其是在檢索增強生成(RAG)技術的輔助下,能夠進一步改善推理性能。提供相關上下文有助於提高表現,而無關的內容可能會降低其效果。
  • 未來展望
    o1-preview 正處於早期測試階段,未來將繼續優化延遲和推理時間,並大幅增強模型的創造性與推理能力。

o1-preview 模型功能實測

先說結論,真的非常的強,不論是產生程式、理解程式、修改程式,都和過去是完全不同等級的狀況!非常的厲害。

這是我今天使用o1-preview 來製作一個HTML的俄羅斯方塊的對話紀錄,可以看到ChatGPT完美的完成任務,真的是沒有BUG的完整的遊戲,而且修改的動作也都非常的完美,真的可以靠指令達到我的許多要求。我覺得這樣的程度的模型是真的會影響到許多工程師的未來性。

對話紀錄在此:https://chatgpt.com/share/66e6bcf1-4254-8005-a573-a250e1b51702

我們可以看見現在的o1-preview會有著更多細緻的思考流程,為我們將一個很大的指令拆分成許多個步驟,並重新檢視、整個整個程式碼,接著則是設置遊戲的玩法。

接著我請他增加計分板和顯示下一個方塊的功能也完美達成

請他幫忙調整版面也非常完美的完成功能

這個是成果:https://claire-chang.com/wp-content/uploads/2024/09/test.html

操作說明:

  • 使用 左箭頭鍵右箭頭鍵 控制方塊左右移動。
  • 使用 下箭頭鍵 加速方塊下落。
  • 使用 上箭頭鍵 旋轉方塊。
  • 使用空白鍵直接下降。

利用emscripten來編譯WebAssembly 

WebAssembly 是甚麼

WebAssembly(Wasm)是一種二進制格式的指令集,用於在網頁瀏覽器中高效地執行程式碼。它由 W3C 標準組織制定,目的是提供一種高性能、跨平台的執行環境,讓開發者可以在網頁上運行接近原生效能的應用程式,尤其是使用 C、C++、Rust 等語言編寫的程式碼。

以下是 WebAssembly 的主要特點:

  1. 高效能:WebAssembly 使用二進制格式,這使得程式在瀏覽器中能夠快速加載和執行,效能接近原生應用(如桌面程式)。它的運行效率遠超 JavaScript,特別適合計算密集型的應用,如遊戲、圖形處理、數學計算等。
  2. 跨平台:WebAssembly 可以在所有現代主流瀏覽器中運行(如 Chrome、Firefox、Safari 和 Edge),並且它不依賴於具體的操作系統或硬體架構,確保跨平台兼容性。無論在桌面、移動設備還是其他嵌入式設備上,只要有瀏覽器支持,Wasm 程式都可以執行。
  3. 語言無關:雖然 WebAssembly 最初是為了 C、C++ 和 Rust 這些高效能語言設計的,但理論上任何語言都可以編譯成 WebAssembly。這使得許多非 JavaScript 語言的開發者可以將他們的程式碼移植到網頁上運行。
  4. 與 JavaScript 互操作:WebAssembly 可以與 JavaScript 互相調用,讓開發者在不拋棄現有 JavaScript 代碼的情況下,把 WebAssembly 作為性能密集型任務的輔助工具。JavaScript 可以用來處理前端邏輯,而 WebAssembly 則負責複雜的數據處理或計算任務。
  5. 安全性:WebAssembly 運行在瀏覽器的沙盒環境中,這意味著它繼承了網頁應用的安全模型,無法直接訪問用戶的系統或資料,確保了安全性。

WebAssembly 是一種讓網頁能夠運行接近原生應用效能的技術,特別適合對性能要求較高的應用,同時保持了跨平台的便利性。

WebAssembly 的應用場景

  • 遊戲開發:開發者可以將原生遊戲引擎(如 Unity、Unreal)編譯成 WebAssembly,從而在瀏覽器中直接運行高效能的 3D 遊戲。
  • 視頻處理和圖像處理:如實時編碼、解碼或濾鏡應用,能夠大幅提升處理速度。
  • 數據密集型應用:如科學計算、機器學習模型運行等,能夠在網頁端完成重度計算任務。

使用Emscripten將C專案編譯為WebAssembly

Emscripten 是一個開源編譯器工具,可以將用 C 和 C++ 編寫的程式碼編譯成 WebAssembly(.wasm)或 JavaScript,使這些程式能夠在瀏覽器中運行。它的主要目的是讓開發者能夠將桌面應用程式、遊戲或其他基於 C/C++ 的軟體移植到網頁環境中。

具體來說,Emscripten 的功能有以下幾個重點:

  1. 編譯到 WebAssembly:Emscripten 可以將 C/C++ 程式編譯成 WebAssembly(Wasm),這是一種高效的二進位格式,專為瀏覽器和其他環境中的快速執行而設計。Wasm 比 JavaScript 執行效率更高,特別適合需要高性能的應用。
  2. 編譯到 JavaScript:除了 WebAssembly,Emscripten 還可以將 C/C++ 程式編譯成 asm.js,這是一種高度優化的 JavaScript 子集,主要用於在沒有 WebAssembly 支援的舊瀏覽器上運行。
  3. 跨平台支持:Emscripten 支援多種系統函式庫和 API(如 POSIX、OpenGL 等),這使得在桌面應用中常用的功能也能在網頁中運行,減少了移植工作的難度。
  4. 使用 LLVM 編譯框架:Emscripten 基於 LLVM 編譯架構,這使得它能夠將編譯過程標準化,並且能很好地支援現代 C 和 C++ 標準。

Emscripten安裝流程

下載檔案

https://github.com/msys2/msys2-installer/releases/download/2024-01-13/msys2-x86_64-20240113.exe

開啟模擬器

開啟ucrt64.exe

cd /D/Git/lbde265/

安裝所需套件

pacman -Syu
pacman -S python3 clang cmake git make autoconf automake gcc
pacman -S mingw-w64-ucrt-x86_64-nodejs
pacman -S mingw-w64-ucrt-x86_64-gcc
pacman -S mingw-w64-ucrt-x86_64-emscripten
pacman -S base-devel mingw-w64-x86_64-toolchain

安裝Emscripten

nano ~/.bashrc
export EMSDK="/D/Git/lbde265/emsdk"
export PATH="$PATH:/D/Git/lbde265/emsdk"
source ~/.bashrc

git clone https://github.com/emscripten-core/emsdk.git
cd emsdk
./emsdk install latest
./emsdk activate latest --permanent
source ./emsdk_env.sh

nano ~/.bashrc
export PATH="$PATH:/d/Git/lbde265/emsdk/upstream/emscripten"
export PATH="$PATH:/d/Git/lbde265/emsdk"
export PATH="$PATH:/c/msys64/ucrt64/bin"
export PATH="$PATH:/c/msys64/usr/local/bin"
export PATH="$PATH:/c/msys64/usr/bin"
export PATH="$PATH:/c/Windows/System32"
export PATH="$PATH:/c/Windows"
export PATH="$PATH:/c/Windows/System32/Wbem"
export PATH="$PATH:/c/Windows/System32/WindowsPowerShell/v1.0/"
export PATH="$PATH:/c/msys64/usr/bin/site_perl"
export PATH="$PATH:/c/msys64/usr/bin/vendor_perl"
export PATH="$PATH:/c/msys64/usr/bin/core_perl"
source ~/.bashrc

測試

emcc -v

安裝libde265.js

git clone https://github.com/strukturag/libde265.js.git
chmod +x ./configure
sh build.sh

wget https://github.com/strukturag/libde265/releases/download/v1.0.15/libde265-1.0.15.tar.gz
tar xzf libde265-1.0.15.tar.gz
cd libde265-1.0.15
./configure --disable-sse --disable-dec265 --disable-sherlock265 --enable-log-error --enable-log-info --enable-log-trace
emmake make

———->引用 gcc 或 g++ 的行。對於 Emscripten,您需要將它們替換為 emcc 或 em++。(子目錄也要改)

如果您要針對 WebAssembly 進行編譯,您需要使用 Emscripten 編譯器(emcc 或 em++)代替傳統的 gcc(C 編譯器)或 g++(C++ 編譯器)。


———->改成CFLAGS = -g -O2 -Wall

CFLAGS 是編譯時傳給 C 編譯器的選項。這裡的選項有:

  • -g:產生調試信息,便於使用調試工具。
  • -O2:啟用優化等級 2,使生成的程式碼更高效。
  • -Wall:開啟所有警告,便於識別代碼中潛在的問題。

編譯AV1的WebAssembly

https://github.com/GoogleChromeLabs/wasm-av1

原本官方的教學是使用

make

但是這樣會失敗

應該要使用

emcmake cmake ./third_party/aom -DAOM_TARGET_CPU=generic
emmake make

Coze:快速產生專屬於你的聊天機器人

Coze是甚麼

Coze是ByteDance出來的一個AI聊天機器人開發平台,讓你不會寫程式也能建立自己的AI聊天機器人,在這個平台可以用拖拉的方式來完成創建、設定、發布、管理專屬於你的聊天機器人功能,並與多種平台如Line、Slack、Telegram等整合。這平台支持各種AI應用,像是客服、資訊助手或是其他智能工具。

官方網站:https://www.coze.com/home

Coze的主要優勢

其主要優勢如下:

  1. 快速上手:用拖拉的方式,你就能快速架設自己的AI聊天機器人。
  2. 支援多模態輸入: Coze不只文字,還能處理圖片、語音等多種輸入,功能很全面。
  3. 靈活部署: 你開發的聊天機器人能放到Discord、Telegram、LINE、Slack和Reddit等多個平台上。
  4. 可整合各種插件:天氣、地點、日曆等各種插件都能整合,功能更加豐富。
  5. 讓機器人學習專屬於你的知識:你能從後台直接上傳和整理知識庫,讓機器人學會專屬於你應用場景的知識,強化機器人的回答能力。
  6. 應用場景:無論是客服、資訊查詢、任務調度、個人助理或教育輔助,Coze都能派上用場。

可以直接詢問機器人如何使用Coze

在登入之後,Home這邊會有一個Coze的專屬客服機器人,透過詢問機器人問題,可以請機器人幫我們搜尋教學文檔。

創建步驟詳細圖文教學

最主要要創建自己的客服機器人我們可以按下左側的Personal進入創建介面:

Coze的個人區域允許用戶管理他們的機器人、插件、工作流程、知識庫,以及其他個人化設定。這個區域有幾個主要標籤:

  1. 機器人(Bots):在這裡創建和管理你的聊天機器人。
  2. 插件(Plugins):查看和管理已安裝的插件,Coze支持超過60種不同類型的插件,涵蓋API和多模態模型,協助用戶執行信息檢索、旅行計劃和生產力提升等任務。更可以支持自己的API擴展,讓機器人可以連結到自己的客製化功能,以達到更彈性的客製化。
  3. 工作流程(Workflows):Coze有靈活的工作流程,這個功能旨在管理複雜的任務並保持高穩定性。平台提供了多種可組合的節點,如大型語言模型(LLM)、自定義代碼和邏輯判斷,也可以串接自己的知識庫、用卡片的型態呈現回覆結果,這個介面使用戶能夠通過簡單的拖放界面,自動化複雜的機器人設定流程。
  4. 知識庫(Knowledge):透過在這邊建立和維護知識庫,並且結合工作流程,讓機器人在回覆使用者的問題之前可以先去你所建立的知識庫搜尋相關知識,這可以讓機器人回答專屬於你的商店或個人形象的問題。
  5. 卡片(Cards):創建和管理互動卡片,結合工作流程和知識庫的功能可以讓機器人以圖文的方式回覆你要回覆給使用者的資訊。

例如透過以下Workflows創建範例就可以建立一個可以回覆我的相關背景資訊的客服機器人:

上圖的工作流程包括了幾個主要的步驟和節點,來處理和回答用戶的輸入。

  1. 啟動節點(Start):這是工作流程的開始,用來初始化信息,例如設定必要的變數,這裡的例子中使用了「BOT_USER_INPUT」這個變數來存儲用戶輸入。
  2. 知識節點(Knowledge):此節點從指定的知識庫中,基於用戶輸入(BOT_USER_INPUT)尋找最佳匹配的信息。在這個例子中,使用「ClaireChangIntro」作為知識庫的參考,並根據語義搜索策略來找到匹配程度高的內容。
  3. 大型語言模型(LLM)節點:這個節點調用大型語言模型(例如GPT-4o mini 128K)來生成回應。它利用前面節點的輸出作為參考資料和查詢內容,生成用戶的問題回答。
  4. 結束節點(End):工作流的最後一個節點,用來返回處理後的信息給用戶。在這裡,將LLM節點生成的輸出設置為回傳的變數。

整個工作流程通過這些互相連接的節點來自動化處理用戶輸入,生成並提供相關的回答。這種設計允許機器人以高效且靈活的方式回應用戶,並可以根據需要輕鬆地修改或擴展其功能。

這樣的對話機器人可以直接經由簡單設定發佈到Coze Bot Store、Cici、Discord、Telegram、Messenger、LINE、Instagram、Slack、Lark和WhatsApp多種平台。

下面為一個使用範例:

Coze要如何收費?

Coze提供多種收費方案,根據不同用戶的需求,從免費到高級的付費方案都有。收費方案大約有以下幾種:

  1. 免費方案(Free):提供每月0美元的免費使用權,每日可獲得10 credits的信息額度。這適用於只需基本功能的用戶。
  2. 輕量級高級版(Premium Lite):每月9美元,每日提供100 credits的額度。此方案適合需要更高使用頻率但不需要大量信息的用戶。
  3. 高級版(Premium):每月19美元,提供每日400credits的額度,適合需要大量信息處理的用戶。
  4. 進階高級版(Premium Plus):每月39美元,每日可使用1000 credits,是最高級的付費方案,適合極高頻度的商業用戶或開發者。

各個方案都提供不同的AI模型使用權限,例如GPT-3.5、Gemini 1.5 Flash、Claude 3 Haiku等,並根據模型的收取不同的信息額度。例如,使用GPT-40 mini會消耗比GPT-3.5更多的額度。

選擇方案時,應該考慮以下因素:

  1. 預計每日的交互數量
  2. 需要哪些AI模型來實現你的需求
  3. 你的預算範圍

根據這些指標,你可以選擇最符合你需求的方案,以確保你支付的費用與你從Coze獲得的價值相匹配。如果你剛開始使用,可以從免費方案開始,隨著需求增長再升級到更高級的方案。