聊直播,這些知識點你必須要懂

2021-02-07 AWS 架構師之旅

宅時光之 Refresh 新知系列 2

申明

本站點所有文章,僅代表個人想法,不代表任何公司立場,所有數據都來自公開資料--轉載請註明出處--

本篇,我們一起來聊聊直播技術,剛開始接觸這塊發現有很多的「行話」和術語,對於一個架構師而言,無法統一語言的高效溝通是最痛苦的事情,意味著,你根本無法理解客戶的語言,今天先自我掃盲一些關鍵知識點和基本場景理解。

直播和點播有什麼不一樣?

點播,是視頻文件已經存儲在那裡,用戶可以隨時隨地進行播放,播放器進度可以由客戶控制,比如從頭,從上次觀看的時間點,快進播放等等;點播的平臺很多,比如國內的愛奇藝,騰訊視頻,國外的 Youtube,Netflix 等等;

直播,視頻源是通常由一方比如主播實時發起,由於是實時進行,播放器是沒有進度條的,直播流到最終客戶側傳輸可以是推流方式播放,也可以是拉流模式播放;我們接下來看看有哪些直播場景。

整個直播主要環節包括 採集,編碼,推流,轉碼,分發,拉流,解碼和渲染 這幾塊;

直播有哪些場景?

直播在今年突如其來的疫情期間,得到非常廣泛的傳播,無論是在家辦公還是停課不停學都少不了直播技術;

你聽過或參與過哪些直播形式?

直播賣貨:比如口紅一哥李佳琪的抖音直播

遊戲直播:比如國內的鬥魚、虎牙,海外的 Twitch

賽事直播:比如 企鵝直播,愛奇藝的西甲、WTA 網球賽直播

泛娛樂直播:比如 B站的二次元,直播答題,YY

教育直播:最近大火的,老師變主播在線給孩子們直播上課,比如滬江的 CCTalk平臺

在線會議:比如 騰訊會議,Zoom,Amazon Chime 等等

直播從最終用戶體驗來說,要做到觀看流暢,無卡頓,如果有互動,則互動更要儘可能「實時」。

千頭萬緒,到底要權衡哪些方面?

根據 Twitch 首席研發工程師沈悅時老師的一篇公開演講,所有的直播場景,主要權衡三方面內容:

任何直播場景都需要在三者之間找到一個最恰當的平衡,最終會影響直播平臺的技術實現和運營維護成本。

比如遊戲直播的場景,一個直播間同時參與在線的人數往往很多,一般比較火的網紅同時觀看人數會在 10萬左右(Twitch 的數據),單位觀眾的接入成本不能太高(成本包括伺服器資源消耗,流量,客戶的帶寬要求等等)這就要求可擴展性要很好;類似,教育直播,比如上海市教委最新通知的,中小學統一同時在線學習,一堂課容納的在線學生也是跟網紅聚集的在線人流差不多,三個指標中,首先要滿足的就是可擴展性,否則,同學們都不一定能進的了在線課堂教室;同時,這類場景的服務質量還要求很高,不能總是低清和卡頓,而高服務質量會犧牲一定的延遲。

再比如在線視頻會議,要滿足對話級的自然互動程度,通常端到端的延遲要控制在 200 ~ 400毫秒以內,所以,三個指標上,服務質量上會有所犧牲,比如畫質和卡頓率要求就沒有那麼高,而且常見的會議系統通常能容納的同時在線人數也只能在 20 ~ 100人左右,犧牲可擴展性,給低延遲讓路。

推流是什麼鬼?

直播中的視頻源需要從 PC 電腦或移動端發布到直播平臺,就稱為「推流」,也稱為「發布」。

技術面來講,目前基本上都是利用 RTMP(實時消息傳輸協議)進行「主播」端推流,RTMP 最初是由 Macromedia 為通過網際網路在 Flash播放器與一個伺服器之間傳輸流媒體音頻、視頻和數據而開發的協議。隨著視頻直播領域的興起,也成為業內廣泛使用的協議。

RTMP 推流有個顯著的特點就是低延時且低擴展性;

推流工具:PC 上有開源的 OBS (Open Broadcaster Software)軟體,或商業版的 xsplit;移動端通常每家直播平臺都會提供相應的開發 SDK;

被直播平臺廣泛採用:比如 B 站,鬥魚,Twitch, Youtube 等等

RTMP 有幾個變種:

標準協議工作在 TCP 之上,使用默認埠 1935

RTMPT 封裝在 HTTP 請求之中,可穿越防火牆

RTMPS 類似 RTMPT,增加了 TLS/SSL 的安全功能,使用 HTTPS 連接

近幾年由於基於 UDP 的協議比如 QUIC 或者 SRT 的發展,也有很多玩家嘗試自主研發 RTPM over UDP 的方案,比如國內的 B站團隊,就在研發和灰度上線基於 QUIC 的 RTMP 直播方案。

QUIC(Quick UDP Internet Connection)是谷歌制定的一種基於 UDP 的低時延的網際網路傳輸層協議,QUIC 可以兼容 HTTP 1.1或HTTP / 2,基於 UDP 的 QUIC 協議相對比 TCP/IP 來說,由於不需要握手機制,延遲大大降低(包括建立連接和丟包重傳都有優化)。

SRT (安全可靠傳輸)協議,開源且基於 UDP,同時專為高效安全視頻流而設計;目前無論是 QUIC 還是 SRT 協議規範都在進一步演進中,自主研發需要比較高的研發成本,且有一定的不確定性,比如 QUIC 在行動裝置的支持不夠好,等等。

直播流播放

這方面的技術選型最豐富,為了實現比較好的用戶體驗,有非常多的優化技術細節,不過目前主流玩家主要兩個方向:

國際上

主流方向是基於 HTTP 動態自適應流技術(HTTP Adaptive Streaming - HAS),HAS 是一種流化和 HTTP 漸進式下載混合的媒體內容分發方法;

代表廠商有 Youtube/Twitch/Hulu/Amazon 等。

海外廠商採用的主流方案包括 Apple 的 HTTP Living Streaming(HLS) 和 國際標準 MPEG-DASH(Dynamic Adaptive Streaming over HTTP)簡稱 DASH;

無論 HLS 還是 DASH,都會將內容分解成一系列小型的基於 HTTP 的文件片段,每個片段包含很短的可播放內容,再提供一個 播放清單(playlist)給到播放器,播放器收到播放清單才會一層一層向源站請求;

除此之外,市場上還有一些 HAS 方案,比如企業出品的 Microsoft Smooth Streaming(MSS),Adobe 的 HTTP Dynamic Streaming(HDS),以及OPEN IPTV Forum 定義的 OIPF 規範;

優勢:

高可擴展性,但高延遲

客戶端通過 HTTP 短連接不斷請求內容片段實現了直播流的播放

CDN 友好,部署方便、快捷,具有良好的防火牆穿透能力; 由於可以通過內容分發網絡進行緩存分發,極大降低直播平臺的流量成本;

可以直接在 HTML 5中播放;HLS 在蘋果生態完全支持,大部分 Android手機瀏覽器也非常給力;

核心指標

延遲:通常 10秒左右,可優化;Twitch 基於 HLS 的低延時互動直播技術可以將延遲中位數控制在 4.5 秒;

服務質量(QoS):由於是小的切片,可以通過碼率自適應播放(ABR)技術優化弱網下的觀眾體驗,即客戶端可以根據網絡狀況,設備能力和用戶偏好,實現自適應的碼率和QoE;有非常多的伺服器端和客戶端碼率自適應的算法;

切片大小:Twitch 通常是兩秒一個片段,Facebook 和 YouTube是一秒鐘一片;

國內客戶

典型代表 B站,快手,愛奇藝,虎牙等等,主要採用的實現方案包括 RTMP、HTTP-FLV、HLS/DASH 或者 自研基於 UDP 實現。通常一個平臺有可能會支持多種直播播放方案,比如同時支持 RTMP 和 HLS 等等。

RTMP & HTTP-FLV 直播流播放

為什麼把這兩個放在一起來講呢,因為他們都是 Adobe 公司的解決方案:

國內非常多的直播平臺採用該這兩種協議作為直播流播放解決方案;

都是低延遲,通常 2 ~ 5 秒,所以都是直播首選方案

視頻封裝的格式都是 FLV,傳輸的數據也都一樣,都是 FLV 文件的 Tag

FLV(Flash Video) 由 Adobe 公司主推的一種視頻格式,優化在網絡上傳輸流媒體數據的一種容器,格式簡單,整個 FLV 由 The FLV Header, The FLV Body 以及其它 Tag 組成,不需要很大的媒體頭部信息;在延遲表現和大規模並發方面都很成熟;

RTMP 在推流章節介紹過,該協議比較全面,也可以用來用在接受和播放直播流,採用 RTMP 的直播播放一個典型的特徵是 絕大多數使用 Flash 作為播放器!

HTTP-FLV,即將音視頻數據封裝成 FLV,然後通過 HTTP 協議傳輸給客戶端;HTTP-FLV 的原理是伺服器在響應客戶端 HTTP 請求時候,不返回 Content-length 欄位給客戶端,這樣瀏覽器就會不會認為數據已經傳完了,一直會接受數據,直到伺服器和客戶端斷開;

相較於 RTMP 協議,HTTP-FLV 能夠好的穿透防火牆,它是基於 HTTP/80 傳輸,有效避免被防火牆攔截;並且首開和延遲略低於 RTMP;

採用 RTMP/HTTP-FLV 作為直播流播放方案的話,從採集推流到源站再到用戶側的播放器是一條完整的主動式數據流,相對於國m際通用的 HAS 解決方案,有明顯的優勢:

低延遲

基於長連接,RTMP 基於 TCP 長連接;HTTP-FLV 基於 HTTP 長連接;

HTTP-FLV 支持大並發,也就是可擴展性比較好;同時支持 302 跳轉,便於靈活調度;

但,也不是沒有缺點:

伺服器端資源消耗高;HAS 方案是客戶端主動拉進行播放,而且 CDN 友好,單伺服器的用戶密度高,也就是整體成本要低很多;據沈悅時老師的分享,RTMP 推流播放對於伺服器端的資源消耗要遠大於 HLS 的拉流方式,Twitch 的經驗,單臺同樣配置的伺服器用戶密度是 1:5,Twitch 一開始也是採用 RTMP 推流播放,不過成本太高,因此改成了 HLS。

播放器方面,RTMP 支持 VLC/FlashPlayer 等,不支持 HTML5 直接播放,iOS 需要第三方解碼器;HTTP-FLV 需要集成 SDK 比如 flv.js 才能實現 HTML 5的播放;

這兩種方式在 碼率自適應播放調優方面能做的有限,後來 Adobe 出品了 HTTP Dynamic Streaming(HDS)來適應 HAS 的技術潮流;

HTTP-FLV 會在本地緩存流媒體資源,保密性不夠好

自研私有解決方案

很多客戶會針對性自研適合自身直播特點的解決方案,比如 Twitch 的直播,自建了全球適合直播的 CDN 網絡,並優化了 HLS 協議實現中位 3-4秒的端到端延遲,由於優化了協議,因此播放器必須嵌入自研的 SDK 方能播放直播流。詳情參考沈悅時老師的《基於HLS格式的低延時互動直播技術》

國內了解到的快手基於 UDP 自研了一套 KTP(Kuaishou Transmission Protocol) 協議,但由於自研協議 CDN 不支持,所以,KTP 目前根據公開資料只是加速推流以及連麥場景,直接跟快手機房 IDC 超低延遲通信;詳情可參考快手多媒體傳輸算法優化實踐

國內外 CDN 直播支持差異

國內廣泛採用的 RTMP 和 HTTP-FLV 兩種直播播放協議,大部分海外 CDN 廠商都不支持,本質上 不過由於 RTMP 和 HTTP-FLV 是基於 TCP或 HTTP的長連接,CDN 的內容緩存效果有限,對於這類直播流分發,最需要的是一個穩定的、大帶寬以及 BGP 線路的全球客戶觸達的網絡基礎設施。

以 AWS Cloudfront 為例,該 CDN 本身支持 HLS/MSS/DASH/HDS/CMAF 直播分發,都是 HAS 技術;那對於 RTMP 和 HTTP-FLV 可以利用 AWS Global Accelerator來進行加速,該服務也是利用龐大、無擁塞的 AWS 全球的網絡,支持 TCP 和 UDP 流量的應用,加速延遲敏感的直播應用;

再比如獨立的國外 CDN 廠商,Akamai 也只支持基於 HTTP 的流媒體 (HLS/HDS/MSS/DASH/CMAF)解決方案;

當然海外很多客戶也有選擇自建 CDN 網絡來支撐點直播業務,比如 Netflix 私有的 OpenConnect網絡;比如 Twitch 自建的遊戲直播 CDN 等等;

在回到國內,主流廠商的 CDN 拉流都支持 RTMP、HTTP-FLV 以及 HLS 協議;關於推流協議,基本都是 RTMP 推流外,部分還支持自研的 RTMP over QUIC 推流 SDK,比如騰訊雲直播服務,七牛雲等;

其他一些黑話什麼是連麥?

連麥其實就是原來主播的直播流中,同時加上多路粉絲的語音視頻流,本質上已經脫離了我們通常所說的廣播式短時延直播,而是類似視頻會議這樣的一種實時音視頻通信;所以,連麥對擴展性要求不高,也就是同時連麥在線的人數不會太多,比如騰訊雲直播 SDK 連麥人數就控制在 10人以內,但對延遲會更加敏感;

對話級語音視頻互動,端到端的延遲上面章節提到過,最好在 200 ~ 400毫秒之間;由於要求超低延遲,常規可以利用 RTMP 流媒體協議來實現,或者通過優化的基於 UDP 的協議,因為具備更好的擁塞處理,以及快速建立連接的優勢,比如 WebRTC,該協議是 Google的開源技術,降低了實時音視頻開發的門檻;

什麼是彈幕?

彈幕功能是 B站以及很多視頻網站非常受歡迎的一種互動功能,用戶的評論像子彈一樣從屏幕中穿過,英文稱為「Bullet screen」 或 」bullet comments「,技術人一般用 」danmaku「 表示,實現可以參考 B站的GOIM架構,通常用 Web Socket 來實現相對低延遲的消息推送 (1s內):

觀看體驗 QoE 主要影響因素?

QoE 就是觀眾看得爽,主要影響因素:

碼率 Data Rate:通俗一點的理解就是取樣率,影響視頻體積大小,碼率越大,文件體積也越大,其計算公式是文件體積=時間X碼率/8,而且一般文件包含視頻和音頻,各自會採用不同的碼率,文件的大小包含視頻和音頻的大小;

幀率 FPS(Frames Per Second):每秒鐘幀數(FPS)越多,所顯示的動作就會越流暢,幀率越大,畫面越流暢;幀率越小,畫面越有跳動感。如果碼率為變量,則幀率也會影響體積,幀率越高,每秒鐘經過的畫面越多,需要的碼率也越高,體積也越大;普通視頻直播幀率在 15fps ~ 25fps;

解析度:影響圖像大小,與圖像大小成正比,比如 480p就是指 640 x 480 個像素點,720p指 1280x720解析度;1080P 指1920x1080解析度;

後記

直播越來越火,隨著 5G 的到來,我相信語音視頻應用場景會更多融入我們的生活,去年底跟公司媒體專家在客戶現場旁聽了2個小時轉碼探討,才發現以前太高估自己了,隔行如隔山,先總結一篇,把看到的資料理一理,期望也能你有所幫助。

誕生於 2019,遇見 2020。

感謝關注,歡迎動動手指標星和置頂;

這樣就不會錯過少但精彩的技術探討、團隊建設、案例分享!

每周至少一更,轉發是對我的最大鼓勵!

學習之路漫漫,走走停停,
偶有所感,隨心所記,
言由心聲,問心無愧!

從客戶中來,到客戶中去!


相關焦點

  • 沉迷國外直播?你必須要懂的爐石英文
    *但auto-pilot在英語裡顯然要比中文的「無腦」一詞顯得更中性例句:你不能auto-pilot奇蹟賊。【BM】 v./n.「bad manner」的簡稱,相當於中文的「敗人品」,最初指喋喋不休地發表情,後泛指一切故意的額外動作。更有甚者把錯過斬殺也說成「next level BM」或者「extended BM」。
  • 微信上線新功能,這些必須要重視!
    大家可以先來看下有關這次更新的簡介內容:-可以給群聊設置備註-可以在聊天列表中不顯示某個聊天-可以在群裡進行最多15人的語音和視頻通話-可以解決了一些已知的問題雖然,這些功能很多都已經出現在了手機上。但在PC端,還是第一次出現。
  • 想和外國人聊天,這些英語縮寫你必須要看懂!
    如果你有和外國朋友聊天或發簡訊的經歷,是不是都曾遇見對網絡用語摸不著頭腦的情況?很多英文單詞特別長,為了有效溝通,外國人習慣在聊天中使用縮寫、替代等形式。如果你懂英文卻看不懂這些常用表達,當別人在笑的時候你就只能獨自尷尬了……今天就和小壹老師一起來看看,外國人聊天時有哪些常用的網絡用語吧!
  • 【面試篇】寒冬求職之你必須要懂的Web安全
    作為前端工程師的我們也逃不開這個問題,今天一起看一看Web前端有哪些安全問題以及我們如何去檢測和防範這些問題。非前端的攻擊本文不會討論(如SQL注入,DDOS攻擊等),畢竟後端也非本人擅長的領域。攻擊者在目標網站上注入惡意代碼,當被攻擊者登陸網站時就會執行這些惡意代碼,這些腳本可以讀取 cookie,session tokens,或者其它敏感的網站信息,對用戶進行釣魚欺詐,甚至發起蠕蟲攻擊等。XSS 的本質是:惡意代碼未經過濾,與網站正常的代碼混在一起;瀏覽器無法分辨哪些腳本是可信的,導致惡意腳本被執行。
  • 儲君老師,聽說你最近獲獎了?
    儲君老師:也不是啥大獎啦,就是昨天收到千聊官方平臺,說我運營的【Excel學習交流中心】榮獲11月千聊金字塔計劃最具潛力直播間。熱心學員: 什麼是千聊金字塔計劃呀?儲君老師:千聊金字塔計劃是千聊官方,針對能持續輸出優質內容的知識從業者的一項篩選計劃,為優質講師背書。熱心學員: 那是不是很難加入呀?
  • 和外國人更順利的聊天,這些新興網絡英語縮寫你要懂!
    如果你懂英文卻看不懂這些常用表達,當別人在笑的時候你就只能獨自尷尬了……今天就一起來看看,外國人聊天時有哪些常用的網絡用語吧!英語中的網絡用語經常使用縮略(abbreviation)的形式,比如有些是首字母縮寫,有些是用數字代替某些發音,有些省略了部分音節。
  • 你一定要了解的真實兔聊
    色彩豐富,真實明確的直播界面,直播還包含寶島和大陸的不同選項~Ok,看到這裡,大家肯定對兔聊APP有了初步的了解,那針對今天看到的抄襲者,各位小夥伴要怎麼做來杜絕被騙呢?、不理會一些從未在群裡發言或頭像就是可疑字眼的主動添加你的用戶;關注兔聊微信公眾號:tuliaoapp,認準公眾號內發布的官方消息,因為無論我們有什麼改動或活動,都會第一時間通知大家~;不在一些可疑渠道下載兔聊APP,可從微信公眾號或官網進行下載。
  • 百度輸入法AI助聊:一款更懂你的輸入法!
    ,有些輸入法體驗很差,用戶使用時總是很難找到自己需要的詞,有些輸入法體驗很好,往往懂你需要什麼詞,根據你的習慣,大概率的命中你所需要的詞,因此可以省去很多時間,體驗非常的好,在眾多輸入法中,小編發現百度輸入法重磅發布的V10.0全新版本是體驗最好的了。
  • 射出成型—這些你必須要懂!(下集)
    1.3保壓的工程1.3.1保壓切換(二次壓切換)為使成形材料於模具內完全地充填,成形機必須於瞬間內給予射出壓力,然後保壓維持一段時間這樣的過程叫做射出成形技術過程。如果射出壓不變地保持一段時間,這樣會在GATE附近承受有害的壓力以至會有變形及破裂情形發生,也就是射出壓力太高,但是射出壓力不高,材料又無法在模具各處充填完全,像這種狀況就必須想個辦法(TECHNIC)來解決。
  • 跨境電商蝦皮定價 蝦皮電商要懂英文嗎
    我這裡給大家安排一堂直播課,可以系統的幫你解決做亞馬遜的各種問題。跨境電商蝦皮定價做shopee這個平臺一定要搞懂產品的定價和物流費的計算,如果這點都搞不懂的話那麼結果只有兩種,第一是你壓根就賣不出去,第二就是賣出去的東西是賠錢的,所有搞到蝦皮的物流計算這點很重要。
  • 地產人春節「被尬聊」,7大送命話題
    就當是一個玩笑,聊過就過了,然後再開始正常的科普。這個話題是接著第一個話題來的,當大家知道你在做房地產後,都會忍不住問你一嘴「幹房地產工資很高吧」「年終獎是不是發了幾十萬」。在很多人外人看來,房地產是一個很土豪的行業,畢竟賣一套房子都是幾十萬上百萬,各種高大上的排場,廣告。在他們看來,房地產就是一個遍地黃金,輕鬆掙錢的行業。
  • 直播語音群聊 vs. 播客
    今天這篇,「播客一下」繼續聊聊「直播語音群聊 (live group audio)vs. 播客」。在一個社會關係著重依賴於網絡媒體的時代,聲音的親密使得音頻媒體更具吸引力。尤其在疫情背景下,這種情感滿足被突出了。播客就是一個很好的例子。無畫面的內容讓人們更專注於聲音,你能直接從語調中感知到說話人的情緒、暗示或是別的信息,而這些信息往往受限於文字。
  • 《絕地求生》新地圖你必須了解的知識點
    為了方便大家快速適應新第圖卡拉金,下面助手哥特地為各位玩家整理了一些知識點,一起學習起來吧!提前跳傘,更快到達新地圖卡拉金是《絕地求生》目前所有地圖裡最小的一個地圖,這也決定了在卡拉金跳傘不能與在其他地圖跳傘用一樣的方法了。
  • 淘寶直播互動轉化利器,教你玩轉直播拍賣
    當前交易結束時,系統在群內會自動給買家發送催付款信息,同步,訂單也會在你的商家後臺生成,與現有的訂單管理在一起。 1.4 群聊加拍賣互動玩法拍品的選擇與添加。選擇好拍品並點擊確認後,拍品就會出現群聊頂部的抽屜裡。 我們需要注意上圖紅框裡的數字,當你設置太多的營銷活動後,這裡的數據就可能會變成零,導致你的無法添加拍品,這時就需要你去群聊後臺調整,然後再繼續操作的。
  • 想要從FPGA小白成為達人,這些你必須知道
    近期很多人問我該如何去學FPGA,那麼今天咱們就來聊一聊。        第一句話是:還沒學數電的先學數電。然後你可以選擇verilog或者VHDL,有C語言基礎的,建議選擇VHDL。因為verilog太像C了,很容易混淆,最後你會發現,你花了大量時間去區分這兩種語言,而不是在學習如何使用它。
  • flv.js源碼知識點(上)
    •load()該方法必須要手動調一下,把裡面的_hasPendingLoad置為true,關鍵代碼如下:這裡講其中三種有知識點的Loader一般常見的Fetch 返回的處理是轉成某種格式並通過Promise進行返回,例如res.json() res.arrayBuffer(),這就意味著要返回的body整體結束才能夠觸發,而直播場景中的flv數據是流的形式,直播不結束返回也不會結束
  • 照片模糊變清晰,這些常識你必須懂!
    不過這些披著「神秘色彩」的照片都有一個共同點——照!片!模!糊!照片模糊,引發了社會大討論,討論不出結果就成了不解之謎。除此之外,拍照模糊也給我們的生活帶來了煩惱。溫馨提醒:夏天帶女朋友去海邊(浪)拍照直 男 兄 dei,不是所有的順光都適合拍主體,拍人臉特寫要善於用側光拍攝,那樣能顯得臉部更有立!體!感!
  • Android視頻開發進階——這些你必須要知道!
    第一次我打算分享一下視頻開發中常見的一些知識點,概念和術語,給不熟悉的朋友們先"掃掃盲"。所以Codec這種程序就出現了,它會把這些連續的圖片們通過一定的算法壓縮成體積更小的文件格式,這就是我們所謂的編碼,壓縮。但是在播放器的客戶端,不管是PC,手機也好,他們要顯示在屏幕上的,必須是實實在在的圖片啊,所以這些被壓縮過的文件最終又必須被還原成圖片格式,這就是解碼,解壓縮。
  • 千聊課程直播微信公眾號關注
    1、千聊課程千聊圍繞「讓家庭更幸福、讓自己更有魅力、讓自己更厲害」這三個方向,衍生出了以千聊變美、千聊親子、千聊情感、千聊生活、千聊職場、千聊理財為主的20個細分領域,提出「與你有關,對你有用」的理念。
  • 這些直播小技巧你知道嗎?
    2.揚長避短要懂得一個主播不可能什麼都會,選擇自己的長處來展示和放大給粉絲。學會營造輕鬆愉快的直播環境,有幽默感的主播能更容易引起粉絲好感,可以平時多積累段子在心裡,直播前就嘗試說出來,直播時再搭配熱門的話題,這樣才不會讓你的直播間顯得枯燥。