CVPixelBufferGetBytesPerRow() for CVImageBufferRef returns unexpected wrong value for 1080p video frame

Question

I am developing an application doing real-time video processing using AVFoundation with back cameras of iDevices. The AVCaptureSession is configured with sessionPreset AVCaputeSessionPreset1920x1080 (full HD), video settings kCVPixelBufferPixelFormatTypeKey=kCVPixelFormatType_32BGRA and outputs sample buffers of type CMSampleBufferRef to a AVCaptureVideoDataOutput delegate. Video/Interface orientation portrait is used (means frames of size 1080x1920 are expected). On each arrival of a frame, a CVImageBufferRef is retrieved from the sample buffer for further access to it's raw bytes. When accessing CVPixelBufferGetBytesPerRow() of this CVImageBufferRef instance, I get the value 4352 which is totally unexpected in my opinion. My expectation is, that bytes per row reflects 4 bytes (BGRA) per pixel for the entire frame width (1080) resulting in the value 4320 (=1080*4bytes). With bytes per row = 4352, divided by 4bytes this would give a frame width of 1088. Does anyone have a clue why this is actually happening? I can't work with the expected width of 1080 when analyzing pixel-wise as it leads to distorted images (checked converting to UIImage and save to disk), I definitly need to work with 1088 as width so the image is straight and analysations give proper results - but this is weird.

As I am using the raw frame bytes for real-time analyzation and expect to use a width of 1080, this is very essential for me so I really appreciate help on this issue.

Devices used: - iPod touch 5G with iOS 6.0.1 - iPhone 5S with iOS 7.0.2

Code excerpt:

- (uint8_t*) convertSampleBuffer: (CMSampleBufferRef) sampleBuffer {
CVImageBufferRef imageBuffer = CMSampleBufferGetImageBuffer(sampleBuffer);
size_t bytesPerRow = CVPixelBufferGetBytesPerRow(imageBuffer); // = 4352 (=1088*4)
.....
}

Answer 1

Apple released "Technical Q&A QA1829 Understanding the bytes per row value returned by CVPixelBufferGetBytesPerRow" on 5/1/2014 which states that this is due to hardware alignment requirements. See the tech note for details.