※ 引述《Arton0306 (Ar藤)》之銘言： : 小弟最近用libav(ffmpeg)寫一個簡單的播放器(用qt作gui) : 目前已經可以解出 video audio packet : 現在要同步播放出來 : 但在這中間有個問題 - 要怎麼處理讀(play thread)寫(decode thread)packet的問題 : 假設我什麼都不管 就一直解碼存到兩thread的共用buffer : (buffer指兩個fifo) : 1秒20張ppm一定會把buffer炸掉 : 所以我目前想法是這樣： : play thread 在buffer中會不斷把audio packet讀進來 這qt有個物件可以吃pcm stream : 並根據video frame的時間適當畫出來 : 比較麻煩的是decode : decode要知道play thread播放到哪 : 根據這時間來決定要不要decode : 我想根據audio/video fifo中最大時間 - 播放時間 : 如果小於5個1/fps : 就解5個packet : 否則sleep 5msec : 以上是我的想法 尚未實作 : 不知一般播放器是不是有個既有的經典pattern？ : 如果沒有的話 我就先造我的方式coding : 感謝 一般的 audio 播放的 library 都有提供取得播放時間的方法 不管你是 Android 的 AudioTrack 或是 iOS/OSX 的 AudioQueueService 都能取得 audio time (callback or function) 一般的 AV sync 做法有 3 種選擇 1. 用一個 clock 讓 A/V 去對時 2. 以 video 時間為主的 sync 3. 以 audio 時間為主的 sync 在『感覺』上，如果聲音少了一段很容易被聽到。 而不同的 audio 播放機制需要的 buffer 時間不太一樣， 也就是當你叫他開始播的時候，並不是那個瞬間就能聽到聲音。 所以，通常用一個 clock 來 sync audio 方法其實很難對得準的。 如果是以 video time 來 sync ， 要怎麼處理來不及播完的 audio !? 或是你的 device 的 cpu 太弱了，video 畫得比你想得慢， 所以，就在等 video 畫出來才能開始播聲音 使用者就會聽到斷斷續續的，然後很想砸東西 .... (默) 以我們自己的經驗，除非沒有 audio stream。 那就使用 audio time 來做 sync 是最方便的。 來不及畫的 video frame 就 drop， 還沒到時間的就等待一下，不是很方便嗎？ --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 114.43.126.156