2
我正在與一個VTCompressionSession編碼夫特3用下面的代碼:VTCompressionSession跳過第一幀
let pixelBuffer = CMSampleBufferGetImageBuffer(sampleBuffer);
let statusCode = VTCompressionSessionEncodeFrame(compressionSession!, pixelBuffer!, CMSampleBufferGetPresentationTimeStamp(sampleBuffer), CMSampleBufferGetDuration(sampleBuffer)/* CMTimeMake(counter, 1000), kCMTimeInvalid*/, nil, nil, nil)
if statusCode != noErr {
NSLog("VT Error!", statusCode)
}
的pixelBuffer變量是輸出一個AVCaptureSession。這個AVCaptureSession的回調然後調用上面的代碼。 問題是,上面的代碼被調用了n次,但VTCompressionSession的回調只調用了n - 10次,這讓我想知道其他框架的去向。他們只是存儲在隊列中以提高壓縮率還是存在問題? 我的最終h264流不是100%正確的,我不確定這是否會導致問題。
的VTCompressionSession與下面的代碼創建:
var error = VTCompressionSessionCreate(kCFAllocatorDefault,
270,
480,
kCMVideoCodecType_H264,
nil,
nil,
nil,
vtCallback,
selfPointer,
&tmpSession);
的VT回調定義如下:
let vtCallback : @convention(c) (UnsafeMutableRawPointer?, UnsafeMutableRawPointer?, OSStatus, VTEncodeInfoFlags, CMSampleBuffer?) -> Swift.Void =
{
(outputCallbackRefCon, sourceFrameRefCon, status, infoFlags, sampleBuffer) -> Swift.Void in
NSLog("vtCallback")
}
謝謝您的幫助!
非常好的猜測! 我確實沒有先打過電話,稍後再添加它,但沒有重新檢查。這並沒有解決我的「更深層次」的問題,因爲這顯然不是問題的根源。由於這個問題解決了框架走向的問題,這絕對是一個很好的答案。非常感謝你! –
不客氣!很幸運,我正在尋找一個「同花順」類型的API,這是最接近的事情。 –