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.