Compression Sequence APIs - codecErr returned when compressing with H.264

Q: When using Compress Sequence and Standard Compression APIs to encode H.264 video, SCCompressSequenceFrame returns codecErr (-8960). I have no problems with other codecs such as MPEG-4. Why is H.264 failing?

A: This error is being returned from Standard Compression because the Image Compression Manager Sequence APIs such as SCCompressSequenceFrame do not support encoding with the H.264 codec.

The H.264 codec (introduced in QuickTime 7.0) can produce I-frames (independently decodable), P-frames (predicted from a previous I or P-frame) and B-frames (predicted from past and future I or P-frames). H.264 also supports multipass compression (a feature of the codec allowing it to analyzes source data multiple times before the actual encoding process begins).

While the pre-QuickTime 7.0 Image Compression Manager Sequence APIs such as CompressSequenceBegin, CompressSequenceFrame, SCCompressSequenceFrame and so on support any codec producing I-frames or P-frames, they do not support features such as multibuffered compression, multipass compression, frame reordering, or a lookahead window all required by the H.264 codec.

To support H.264. developers must migrate to the new Image Compression Manager Session APIs such as ICMCompressionSessionCreate, ICMCompressionSessionEncodeFrame and so on.

These new modern APIs support all the features required to compress and decompress H.264 while also supporting all the features required by pre-QuickTime 7.0 codecs.

Note: Standard Compression will still present H.264 in the list of available codecs even if the scAllowEncodingWithCompressionSession feature flag is NOT set.


Back to Top 

Document Revision History

2006-11-15First Version

Posted: 2006-11-15

Did this document help you?
Yes: Tell us what works for you.
It’s good, but: Report typos, inaccuracies, and so forth.
It wasn’t helpful: Tell us what would have helped.