When customers update to Ventura on M1 Mac Minis, ProRes decoding using 64RGBALE breaks, supplying all-black images without reporting any error. All continues to work fine on M1 Max and Pro machines. DTS says (as expected) it's a macOS bug; file a bug report. Reported as FB11771668 a month ago, but have heard nothing. Trying to get a little visibility for it, or similar reports.

I'd seen something that suggested that AVAssetWriter could write ProRes in MXF files, likely as part of MTRegisterProfessionalVideoWorkflowFormatReaders() and/or VTRegisterProfessionalVideoWOrkflowVideoDecoders/Encoders. All of this is undocumented. Is it possible to use AssetReader/Writer to handle MXF-wrapped ProRes? (without writing MXF handlers from scratch).

I want to modify my long-standing fully operational commercial VTDecompressionSession-based QT movie reader to read ProRes files to produce 16-bit/channel data. Requesting kCVPixelFormatType_64ARGB VTDecompressionSessionCreate just crashes internally. With kCVPixelFormatType_48RGB, VTDecompressionSessionDecodeFrameWithOutputHandler results in a -12905 error status. What are working methods to decode this data? I need RGB data out; I'm not interested in re-creating a YUV decoder pathway. I see AVAssetReaderTrackOutput discussing reading ProRes, but that would require a separate path and it seems to be more limited --- I need random access to frames, which VTDecompressionSession isn't good at either but at least I've worked that out.

I have a small command-line tool (a service) that gets compiled by Xcode, then I'm signing it during a Run Script phase. When I try to run it, it gets "Killed". Here's the signing command: % /usr/bin/codesign -s "Developer ID Application: ..." --keychain "/Users/.../Library/Keychains/login.keychain" --timestamp -f -o runtime --entitlements /Code/.../mytool.entitlements  /Code/.../mytool I've got an Info.plist and entitlements for it. % codesign -vvvv ./mytool ./mytool: valid on disk ./mytool: satisfies its Designated Requirement % codesign -dvv ./mytool Executable=.../mytool Identifier=com.myorg.mytool Format=Mach-O universal (x86_64 arm64) CodeDirectory v=20500 size=10271 flags=0x10000(runtime) hashes=310+7 location=embedded Signature size=8952 Authority=Developer ID Application: ... Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=Dec 8, 2021 at 6:28:25 PM Info.plist entries=19 TeamIdentifier=... Runtime Version=12.0.0 Sealed Resources=none Internal requirements count=1 size=180 When I run spctl I get: % spctl -a -v --raw ./mytool ./mytool: rejected (the code is valid but does not seem to be an app) <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>assessment:authority</key> <dict> <key>assessment:authority:flags</key> <integer>0</integer> <key>assessment:authority:source</key> <string>obsolete resource envelope</string> <key>assessment:authority:weak</key> <true/> </dict> <key>assessment:cserror</key> <integer>-67002</integer> <key>assessment:remote</key> <true/> <key>assessment:verdict</key> <false/> </dict> </plist> What's it mean? How can I get this tool to run signed OK? All of this stuff is highly opaque, and the documentation out of date (for example, where it says you can run spctl on /bin/ls, but it gives the same exact error output that /bin/ls isn't an app.) Note that ultimately this tool gets distributed in a ZIP file that contains Windows and Linux executables also; there is not, and ought not be, any macOS-specific installer... I have a lot of other things to do than jumping through these hoops. Info.plist: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>CFBundleDevelopmentRegion</key> <string>English</string> <key>CFBundleExecutable</key> <string>mytool</string> <key>CFBundleIdentifier</key> <string>com.myorg.mytool</string> <key>CFBundleInfoDictionaryVersion</key> <string>6.0</string> <key>CFBundleName</key> <string>mytool</string> <key>CFBundlePackageType</key> <string>APPL</string> <key>CFBundleVersion</key> <string>2.0.0</string> <key>NSHumanReadableCopyright</key> <string>...</string> </dict> </plist> Entitlements: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.apple.security.cs.disable-library-validation</key> <true/> </dict> </plist>

Any reference to actual performance information on the Blas with AMX? I don't use Blas in the first place, so to know whether it's worth doing so, I need to know the performance characteristics of Blas/AMX ---- what the startup overhead is, and actual speedup is on common ops ---- in order to justify spending any time to take advantage of it (it could easily wind up being slower than what I already do). Some matrix multiply times with and without for various matrix sizes at the least, for example. A 5% speedup isn't going to do it, need to see some "factor-of" improvements.

I'm converting Tensorflow models to CoreML .mlmodel using coremltools for a commercial macOS app. Results work, but checking the models with File/Open in Xcode report "Availability" of macOS 10.15+. That's no good for many existing customers, app must run on CoreML's minimum, macOS 10.13 (TBH 10.13 will throw many customers under the bus.) What controls the reported minimum macOS version? Is the reported number correct? What can be done to change it? Using different models or even retraining the existing models isn't practical for many reasons. Is there a coremltools option to convert to a mlmodel that runs on 10.13, even if the converted model has lower performance than one converted for 10.15? (I'd select the appropriate mlmodel to load dynamically.)