1. 程式人生 > >音視訊同步-時間戳

音視訊同步-時間戳

媒體內容在播放時,最令人頭痛的就是音視訊不同步。從技術上來說,解決音視訊同步問題的最佳方案就是時間戳:首先選擇一個參考時鐘(要求參考時鐘上的時間是線性遞增的);生成資料流時依據參考時鐘上的時間給每個資料塊都打上時間戳(一般包括開始時間和結束時間);在播放時,讀取資料塊上的時間戳,同時參考當前參考時鐘上的時間來安排播放(如果資料塊的開始時間大於當前參考時鐘上的時間,則不急於播放該資料塊,直到參考時鐘達到資料塊的開始時間;如果資料塊的開始時間小於當前參考時鐘上的時間,則“儘快”播放這塊資料或者索性將這塊資料“丟棄”,以使播放進度追上參考時鐘)。

2.8 解決音視訊同步問題的時間戳方案

可見,避免音視訊不同步現象有兩個關鍵——一是在生成資料流時要打上正確的時間戳。如果資料塊上打的時間戳本身就有問題,那麼播放時再怎麼調整也於事無補。如圖

2.8,視訊流內容是從0s開始的,假設10s時有人開始說話,要求配上音訊流,那麼音訊流的起始時間應該是10s,如果時間戳從0s或其它時間開始打,則這個混合的音視訊流在時間同步上本身就出了問題。打時間戳時,視訊流和音訊流都是參考參考時鐘的時間,而資料流之間不會發生參考關係;也就是說,視訊流和音訊流是通過一箇中立的第三方(也就是參考時鐘)來實現同步的。第二個關鍵的地方,就是在播放時基於時間戳對資料流的控制,也就是對資料塊早到或晚到採取不同的處理方法。圖2.8中,參考時鐘時間在0-10s內播放視訊流內容過程中,即使收到了音訊流資料塊也不能立即播放它,而必須等到參考時鐘的時間達到10s之後才可以,否則就會引起音視訊不同步問題。

基於時間戳的播放過程中,僅僅對早到的或晚到的資料塊進行等待或快速處理,有時候是不夠的。如果想要更加主動並且有效地調節播放效能,需要引入一個反饋機制,也就是要將當前資料流速度太快或太慢的狀態反饋給“源”,讓源去放慢或加快資料流的速度。熟悉DirectShow的讀者一定知道,DirectShow中的質量控制(Quality Control)就是這麼一個反饋機制。DirectShow對於音視訊同步的解決方案是相當出色的。但WMF SDK在播放時只負責將ASF資料流讀出並解碼,而並不負責音視訊內容的最終呈現,所以它也缺少這樣的一個反饋機制。

為了更好地理解基於時間戳的音視訊同步方案,下面舉一個生活中的例子。假設你和你的一個朋友約好了今天

18:00在滬上廣場見面,然後一起吃飯,再去打遊戲。實際上,這個18:00就是你和你朋友保持同步的一個時間點。結果你17:50就到了滬上廣場,那麼你必須等你的朋友。10分鐘過後,你的朋友還沒有到,這時他打來電話說有事耽擱了,要晚一點才能到。你沒辦法,因為你已經在旁邊的餐廳預訂了位置,如果不馬上趕過去,預訂就會被取消,於是你告訴你的朋友直接到餐廳碰頭吧,要他加快點。於是在餐廳將來的某個時間點就成為你和你朋友的又一個同步點。雖然具體時間不定(要看你朋友趕過來的速度),但這樣努力的方向是對的,你和你朋友肯定能在餐廳見到面。結果呢?你朋友終於在18:30趕過來了,你們最終“同步”了。吃完飯19:30了,你臨時有事要處理一下,於是跟你朋友再約好了20:00在附近的一家遊戲廳碰頭。你們又不同步了,但在遊戲廳將來的某個時間點你們還是會再次同步的。

悟出什麼道理了沒有?其實,同步是一個動態的過程,是一個有人等待、有人追趕的過程。同步只是暫時的,而不同步才是常態。人們總是在同步的水平線上振盪波動,但不會偏離這條基線太遠。

相關推薦

視訊同步-時間

媒體內容在播放時,最令人頭痛的就是音視訊不同步。從技術上來說,解決音視訊同步問題的最佳方案就是時間戳:首先選擇一個參考時鐘(要求參考時鐘上的時間是線性遞增的);生成資料流時依據參考時鐘上的時間給每個資料塊都打上時間戳(一般包括開始時間和結束時間);在播放時,讀取資料塊上的時間

Live555用做RTSPClient時,利用RTP時間進行視訊同步的解決方案(必須有RTCP支援才可行)

http://www.mworkbox.com/wp/work/551.html 先看來自Live555官網的2個常見問題: 問題1:Why do most RTP sessions use separate streams for audio and video?

視訊、音訊打時間的方法及其視訊同步(播放)原理

每一幀音訊或視訊都有一個持續時間:duration: 取樣頻率是指將模擬聲音波形進行數字化時,每秒鐘抽取聲波幅度樣本的次數。 。正常人聽覺的頻率範圍大約在20Hz~20kHz之間,根據奈奎斯特取樣理論,為了保證聲音不失真,取樣頻率應該在40kHz左右。常用的音訊取樣頻率有8kHz、 11.025kHz、

10.基於FFMPEG+SDL2播放video---視訊同步(參考音訊時鐘)

繼續FFMPEG學習之路。。。 參考資料: An ffmpeg and SDL Tutorial 文章目錄 1 綜述 2 音視訊同步 3 DTS 和 PTS 4 音訊時鐘 5 視訊PTS 6 同步 7 不

[SimplePlayer] 8. 視訊同步

音訊與視訊在播放當中可能會由於種種原因(如:音視訊並非在同一時間開始播放,或視訊由於解碼任務繁重導致輸出影象延遲等)導致音訊與視訊的播放時間出現偏差,這種就是音視訊的同步問題,本文會對音視訊同步進行討論。 有三種音視訊同步方式: 視訊同步到音訊時鐘(synchronize video to audi

vlc原始碼分析(五) 流媒體的視訊同步

轉載地址:https://www.cnblogs.com/jiayayao/p/6890882.html vlc播放流媒體時實現音視訊同步,簡單來說就是傳送方傳送的RTP包帶有時間戳,接收方根據此時間戳不斷校正本地時鐘,播放音視訊時根據本地時鐘進行同步播放。首先了解兩個概念

如何實現視訊同步 (live555)

live555中視訊和音訊是分別進行編碼的,如何實現兩者的同步呢? 如果可以做到讓視訊和音訊的時間戳,都與NTP時間保持同步,就可達到音視訊同步的目的。 Network Time Protocol (NTP) is a networking protocol for 

視訊同步(播放)原理

每一幀音訊或視訊都有一個持續時間:duration: 取樣頻率是指將模擬聲音波形進行數字化時,每秒鐘抽取聲波幅度樣本的次數。 。正常人聽覺的頻率範圍大約在20Hz~20kHz之間,根據奈奎斯特取樣理論,為了保證聲音不失真,取樣頻率應該在40kHz左右。常用的音訊取樣頻率有

深入理解Android視訊同步機制(四)MediaSync的使用與原理

MedaiSync是android M新加入的API,可以幫助應用視音訊的同步播放,如同官網介紹的 From Andriod M: MediaSync: class which helps applications to synchronously r

DTS和PTS(HLS視訊同步)

原由: 近來在研究HLS(HTTP Live Streaming),以實現android上播放m3u8檔案。由於TS段的切分不統一,每個視訊網站給出的m3u8 playlists總有差別,在時間戳顯示上有差異,所以對DTS和PTS進行了研究。DTS和PTS是音視訊同步的

FFmpeg 視訊同步

音視訊播放器的工作的具體流程如下圖所示: 播放器工作流程 簡單的來說包括:解協議,解封裝,對音訊和視訊分別進行解碼,音視訊同步播放這幾個部分,各部分詳細解釋請看後面參考資料。由於我們是分別解碼和播放音訊和視訊的,所以各自播放的節奏需要同步,否則會出現音畫不一致的情況。本文主要介紹一個簡單的音視訊同步的

從零開始學習視訊程式設計技術(八)FFMPEG Qt視訊播放器之視訊同步

前面分別講解了: 現在我們就將視訊和音訊合併,並讓聲音和畫面同步。 加入音訊的部分就不做講解了,這裡主要講下聲音和視訊同步的步驟。 首先剛開始播放的時候通過av_gettime()獲取系統主時鐘,記錄下來。 以後便不斷呼叫av_gettime()獲取系統時鐘

如何使用mp4v2將H264+AAC裸流錄製成mp4檔案,並保持視訊同步【原始碼】【mp4】【錄影】

前言:    mp4檔案目前已經成為了流媒體音視訊行業的通用標準檔案格式,它是基於mov格式基礎上演變來的,特別適合多平臺播放,錄製一次,多個平臺都可使用。但是,由於mp4格式相對比較複雜,直到mp4v2這個開源工程的出現,解決了這個問題。    通常,我們在使用mp4檔案時

ffmpeg學習---7.視訊同步視訊同步音訊

#include <libavcodec/avcodec.h> #include <libavformat/avformat.h> #include <libswscale/swscale.h> #include <libswresample/s

視訊同步之系統中的快取

前言 這幾天做錄屏軟體,生成的h264檔案,用vlc播放是音視訊同步的,但是用自己寫的播放器,總是差那麼一點點。從感知上來看大概0.2s~0.4s之間。 原始視訊是音視訊同步的。 就是當人快速說話的時候,口型跟聲音是對上的。 音視訊同步的兩種方

流播放器視訊同步的一點思考

音視訊同步是一個坑,一個繞不過去的坑,一個無可奈何的坑,一個主動跳進去的坑。 時間戳是前提。沒有時間戳或者時間戳錯誤,一切播放端音視訊同步的方法基礎都是不牢靠的。 生成的音視訊流要音視訊同步。可以轉成檔案要本地播放器來驗證一下 rtmp播放器特點: 1,不能堆積資料。

WebRTC 視訊同步原理與實現

> 所有的基於網路傳輸的音視訊採集播放系統都會存在音視訊同步的問題,作為現代網際網路實時音視訊通訊系統的代表,WebRTC 也不例外。本文將對音視訊同步的原理以及 WebRTC 的實現做深入分析。 # 時間戳 (timestamp) 同步問題就是快慢的問題,就會牽扯到時間跟音視訊流媒體的對應關係,就有

1小時學會:最簡單的iOS直播推流(九)flv 編碼與視訊時間同步

最簡單的iOS 推流程式碼,視訊捕獲,軟編碼(faac,x264),硬編碼(aac,h264),美顏,flv編碼,rtmp協議,陸續更新程式碼解析,你想學的知識這裡都有,願意懂直播技術的同學快來看!! 前文介紹瞭如何獲取音視訊的aac/h2

視訊傳輸中時間平滑處理

在音視訊中一般時間戳從裝置中系統時間得來,通常是以毫秒作為單位的linux時間。因為網路傳輸或者時間有時候突變的因為,造成了時間戳混亂。有必要對時間戳做一下處理。包括突變時候平滑處理,包括音視訊不同步的時候的處理,下面演算法解決了時間戳計算問題,在移動裝置上很有好處: st

I版本和J版本打給rtsp視訊幀打時間公式

status_t ARTPConnection::parseRTCP(StreamInfo *s, const sp &buffer) {     if (s->mNumRTCPPacketsReceived++ == 0) {         如果收到的是第一個rtcp包會給MyHandle