I updated macOS to 15.0 yesterday, and I found some floating point value support under CMFormatDescriptionExtensions and CVPixelBuffer's Attachment seems to be broken. When I call CMSampleBufferCreateReadyWithImageBuffer() from CVPixelBuffer, macOS 15.0 always fail with floating point values. a. kCMFormatDescriptionExtension_GammaLevel Previous macOS 14.x works with double value like NSString* keyGamma = (__bridge NSString*)kCMFormatDescriptionExtension_GammaLevel; extensions[keyGamma] = @(2.2); b. kCMFormatDescriptionExtension_CleanAperture I am not sure yet but such non-integer value issue also seems to be applied to CleanAperture. kCMFormatDescriptionKey_CleanApertureWidth kCMFormatDescriptionKey_CleanApertureHeight kCMFormatDescriptionKey_CleanApertureHorizontalOffset kCMFormatDescriptionKey_CleanApertureVerticalOffset Also, When I add rational values to extensions, it cannot pass CMVideoFormatDescriptionMatchesImageBuffer() with: kCMFormatDescriptionKey_CleanApertureWidthRational kCMFormatDescriptionKey_CleanApertureHeightRational kCMFormatDescriptionKey_CleanApertureHorizontalOffsetRational kCMFormatDescriptionKey_CleanApertureVerticalOffsetRational Is there any known workaround?

Hi,I'd like to understand vImageConver for ARGB2101010. Please help me about endianness.> vImageConvert_ARGB16UToARGB2101010> vImageConvert_ARGB16UToXRGB2101010> vImageConvert_ARGB2101010ToARGB16UUnder header they show it is "little endian" a.k.a. "host endian".Accelerate.framework/Frameworks/vImage.framework/Headers/Conversion.h 10171 This format is 10-bit little endian 32-bit pixels. The 2 MSB are zero.But if I understand correctly, described pseudo code in header shows big endian to host endian conversion.(read in ARGB2101010)10180 The per-pixel operation is: 10181 @code 10182 uint32_t *srcPixel = src.data; 10183 uint32_t pixel = ntohl(srcPixel[0]); 10184 srcPixel += 1;On the other hand, described pseudo code in header seems to run in "host endian", in other word "little endian".(write out ARGB2101010)10303 uint32_t *destPixel = dest.data; 10304 destPixel[0] = (A2 << 30) | (R10 << 20) | (G10 << 10) | (B10 << 0); 10305 destPixel += 1; 10306 @endcodeIf the header doc is correct, vImage runs as "Reading in BigEndian and Writing in HostEndian".There should be some inconsistencies.Please tell me how to use these APIs.

I am currently working with AVAssetWriterInput with interlaced source.I want to know the proper procedure to preserve 'fiel' format description extension through AVAssetWriterInput compression operation.Do you anyone have an answer on this?>>Technical Note TN2162>>Uncompressed Y´CbCr Video in QuickTime Files>>The 'fiel' ImageDescription Extension: Field/Frame Information//What I have tried is following:First decode into sample buffer with Field/Frame information- Decode DV-NTSC source and get current FieldCount/Detail of source data- Create a kCVPixelFormatType_422YpCbCr8 CVImageBuffer from source- CMSetAttachments() kCVImageBufferFieldCountKey/kCVImageBufferFieldDetailKey with FieldCount=2/FieldDetail=14 to imageBuffer, same as DV-NTSC source- CMVideoFormatDescriptionCreateForImageBuffer()- CMSampleBufferCreateForImageBuffer()- Now decompressed samplebuffer has kCMFormatDescriptionExtension_FieldXXX same as sourceSecond encode using ProRes422- Next I create AVAssetWriterInput to transcode from _422YpCbCr8 into AVVideoCodecAppleProRes422- Now AVAssetWriter can produce ProRes422 mov file, but it does not contain the format description extension 'fiel'.- ProRes422 Encoder does preserve 'colr', 'pasp', 'clap' same as source, but no 'fiel' is there.I have also tried to serve format description with kCMFormatDescriptionExtension_FieldXXX with initWithMediaType:outputSettings:sourceFormatHint:but no success.//