Step 2: The core component is the forwarding the received sample buffer to the webRTC core
let pixelBuffer = CMSampleBufferGetImageBuffer(sampleBuffer)
let rtcpixelBuffer = RTCCVPixelBuffer(pixelBuffer: pixelBuffer!)
let timeStampNs: Int64 = Int64(CMTimeGetSeconds(CMSampleBufferGetPresentationTimeStamp(sampleBuffer)) * 1000000000)
let videoFrame = RTCVideoFrame(buffer: rtcpixelBuffer, rotation: rotation, timeStampNs: timeStampNs)
self.webRTCClient?.feedCapturer(videoFrame: videoFrame)
The "webRTCClient?.feedCapturer" is finally just satisfying this delegate of an RTCVideoCapture descendant:
- (void)didCaptureVideoFrame:(RTCVideoFrame*)videoFrame;
The format of the sample buffer is kCVPixelFormatType_420YpCbCr8BiPlanarFullRange, so YUV. Width is 886 and height 1920 on my iPhoneXS.
Step 3: Video quality and latency good at receiving side. Since the default connection between a Chrome browser and the native device is using VP8 codec, the memory limit of the extension (50 MB) is reached relatively quickly and the extension is kicked off the memory then w/o mercy by Apple, I switched to H.264 by favouring the H.264 codecs in the SDP
Step 4: Here I noticed a chopped out video at receiving side the first time. Since it is ONLY that bad on my iPhone XS but not on an iPhone 8, iPad 201 and iPad mini 2013 second generation up to now I thought, it would be due to a particular issue with either the iPhone XS H.264 hardware encoder or the driver.
Step 5: Tried to limit the memory load by using a cropping/scaling initialiser for the RTCVideoFrame
let rtcpixelBuffer = RTCCVPixelBuffer(pixelBuffer: pixelBuffer!, adaptedWidth: 640, adaptedHeight: 480, cropWidth: 640, cropHeight: 480, cropX: 0 , cropY: 0)
In fact: The video on the receiving side is now exactly 640x480 cropped out as this rectangle from (0,0). But now I'm having this chopped out effect on both codecs, VP8 and H.264.
So my theory is now, that the effect is NOT caused by a special issue of the iPhone XS hardware, but by some internal cropping/scaling or other handling applied to the video buffer by the WebRTC core, which can be provoked similarly by using the cropping/scaling initialiser for RTCCVPixelBuffer. But I have no clue, why the hell this happens.
Here is a video of the effect seen on the remote side: