前段時間一直搞固定碼率的問題，在這里不得不吐槽國內的資料。
在固定碼率那里如果只是根據網上那種將bit_rate， rc_max_rate， rc_min_rate， 以及rc_buffer_size設置到特定的碼率下，在ts的模式下，你會發現還是vbr的編碼而不是網上說的cbr。
這個是第一個坑，大部分人轉載了那篇不知哪里來的文章，而且沒有驗證或者是特定格式的問題，導致了不是cbr的出現，
而在官網里面，你會發現在mpegts里面有個參數是muxrate,與這個結合才是真正的cbr模式。
但如果你將將murate也設置了，還是不成功，提示什么dts <pcr，這個時候才是真正煩人的時候。首先你要將delay設置后，問題緩沖了，但是沒有解決的話可以往下看看。
在這個坑里，我用了差不多2個星期時間去查資料，跟蹤源碼，以及調試。所幸的是在命令行下是可以成功的，但在我自己代碼里面不成功。這里也提供我一個方向去查找原因。
Google了一番，發現大家都遇見了這類的問題。但奇怪的是很少解決方案，大部分都是用命令行的解決。
一開始跟蹤源碼，發現這個問題引發是因為pcr是根據ts的文件偏移得到一個時間戳值，然后dts會跟它對比，只要dts小于pcr就認為這個幀其實是太慢了。這時你可能會懷疑
pts跟dts，但這個你去掉murate時候是沒有錯誤的。這個就側面證明了pts跟dts是正確的。那么真正的原因是什么呢？通過修改ffmpeg.c的源碼，發現每一個視頻幀都比我自己代碼
里面的視頻幀都要小。這會不會就是因為編碼時候不符合規格呢。最終對比參數發現了，真正的原因是量化因素導致。只要將qmin跟qmax設置好，ok煩人的提示沒有了。
ps:上述實驗在ffmpeg3.2版本，以及如果你不處理那個warning，在一些比較嚴謹的播放器下是播放不成功(vlc),但有些播放器如果只關注pts跟dts，不關注pcr的本身，那播放是沒有問題。

假如你發現有時候會是Stream #0:0: Unknown: none?這類問題，只要在avformat_write_header后av_dump_format就可以了。

編譯代碼時候-L/usr/local/lib -lavfilter -lpostproc -lavformat -lavcodec -ldl ?-lx264 ?-lmp3lame -lz -lpthread -lswscale -lswresample -lavutil

總結

以上是生活随笔為你收集整理的ffmpeg 奇葩问题2的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。