This is correct - I had it confirmed to me by Apple in a bug report, that HLG is correctly recognised but converted to PQ/HDR10 by the Apple TV.

Thanks, yes I've never seen it before with any text editor, it's the first time I've encountered it after upgrading to Monterey and only with TextEdit. I'll certainly file a bug report as it basically means I cannot easily use TextEdit to edit my own sh files, which surely cannot be the intention.

The pairing is just really flakey. At the moment I have to keep repairing every time I wake the Apple TV up! It's absurd. This on two ATVs. For no reason, a third ATV does not have this issue. All are latest model ATV 4Ks. Latest Xcode. New MacBook Pro 16. Devices & Sims says the device is locked, what does that even mean for an ATV anyway? Well, the ATV is not locked as I am navigating using the remote. It's obviously visible to the MacBook and vice versa because when I go to Remote & Apps, the Pair button appears in Xcode devices + Sims. As soon as I turn the ATV off, or it sleeps, or some period of time passes, I have to go through the rigmarole again. Painful to dev for ATV with things like this.

Same here. The app contains one or more corrupted binaries. Rebuild the app and resubmit. With error code STATE_ERROR.VALIDATION_ERROR.10 Tried many times, from two different locations. Presume something about Apple's system is broken at the moment as I have also been getting lots of other errors at various stages trying to upload builds (can't find record, wrong credentials etc). Usually a retry solves these errors early in the upload process, but I cannot yet get past the corrupted binary error.

I've had issues all day. Either it failed during uploading, or finally, just now it completed uploading....but then I got the same dreaded email as you did above. I also have no problems with the Validate App option. I haven't change any code I can think of that should cause this. Unless I was doing something naughty that Apple have now disallowed. In any case, the message is useless as it refers to "APIs listed above" but there aren't any! "If method names in your source code match the private Apple APIs listed above, altering your method names will help prevent this app from being flagged in future submissions. In addition, note that one or more of the above APIs may be located in a static library that was included with your app"

On my macOS 13.1 there is this file inside /System/Library/Plug-Ins AV1DecoderSW.bundle Inside the contents there is this plist: However, when creating a VTDecompressionSession for AV1, it cannot find a decoder, failing with kVTCouldNotFindVideoDecoderErr. If I export the symbols from the binary inside the above bundle, it has the following top two entries: /Users/oliver/Desktop/AV1DecoderSW (for architecture arm64e): 00000000000362dc T _AV1Decoder_CreateInstance 0000000000037794 T _AV1RegisterDecoder I tried manually loading the plugin bundle as an CFBundleRef and getting a pointer to the AV1RegisterDecoder function shown above, and called AV1RegisterDecoder but this still didn't make a difference. Would it be a correct assumption, then, that this is WIP that hasn't been enabled yet, or does anyone know of a way to enable it? Finally, I loaded the executable into a text file and noticed that it appears to be linked directly to a static build of libdav1d, as I could see the function names and error messages.

I find the FFmpeg source code is a useful reference for things like this, in this case check out videotoolbox.c and there will be a function in there that creates the AVCC extradata.

I would like this too. I know it's possible programmatically by checking for the availability of HEVC hardware decoding, but in my case the app is an exclusive HEVC streaming app, so I really don't even want it to be installed/used on anything before the first Apple TV 4K.

It's really sloppy that I've allowed the final release of Xcode 15 to still have this issue - I'm getting thousands of these every time I run a build. Ridiculous.

I know this is 7 years ago but I've just discovered this on macOS 14.0 with a Mac Studio. shutdown -h -u ...simply does not work. It powers off the macOS immediately. This makes it really hard to work as a NUT client.

It would be great if Apple could provide an example of how to decode AV1 video on an iPhone 15 Pro Max or one of the new M3 MacBook Pros, using VideoToolbox. The information appears not to be anywhere.

Might these links be of use: https://chromium.googlesource.com/chromium/src/+/master/media/gpu/mac/vt_video_decode_accelerator_mac.cc https://chromium.googlesource.com/chromium/src/+/HEAD/media/gpu/mac/vt_config_util.mm Specifically the function CreateVideoFormatAV1 in 1 and the function CreateFormatExtensions in 2.?

Well this is annoying. Just tried to profile for the first time in ages and it fails with this issue on both tvOS and iOS. And this issue goes back a year, with no apparent solution. How exactly is one supposed to develop when a basic tool like this is not working for so many people....?

Just posting back here as I got all this working in the end. In case it's useful, here are the stumbling blocks I encountered. Probably, these are just more a reflection of my lack of understanding but maybe it'll help someone. To construct AV1 Codec Configuration Box outside of FFmpeg etc, then this describes the structure: https://aomediacodec.github.io/av1-isobmff/#av1codecconfigurationbox-section The information needed comes from parsing the Sequence Header OBU: https://aomediacodec.github.io/av1-spec/#general-sequence-header-obu-syntax If you're writing from scratch (i.e. not. using ffmpeg or whatever), then you need to write or find code to parse the sequence header OBU. Once you've written the 4 bytes described in 1. then you also need to append the sequence header OBU data block to the end of the block. If you don't, then the decoder setup will fail. This is then added to the extensions dictionary, along with all the other basic information needed to initialise the decoder (the Chrome references detail all this information). You then create the video format description using CMVideoFormatDescriptionCreate, passing in the extensions. I then got caught out with a decode error because I didn't realise that I also had to pass in the Sequence Header OBU with the first frame data I attempted to decode. It wasn't enough that I had already given the same Sequence Header OBU when creating the video format description (via the extensions). After that it worked. Decoding itself is slightly simpler than with HEVC, in that you don't need to parse the OBUs, you just pass the data straight to the decoder. With HEVC, you had to parse the NALUs and only pass in slice segments, while also doing some minor conversion of the way the NALU's length is presented to the decoder. It would be helpful, Apple, if you could consider writing something like CMVideoFormatDescriptionCreateFromAV1SequenceHeaderOBU similar to the existing CMVideoFormatDescriptionCreateFromH264ParameterSets and CMVideoFormatDescriptionCreateFromHEVCParameterSets. This would lower the bar a little to AV1 hardware decoding.

Sorry for the late reply I hadn't set up notifications (I have now). If you don't append the sequence header OBU data to the end of the AV1CodecConfigurationRecord then decoder initialisation will fail with error -12911. if you don't include the sequence header OBU data at the start of the first frame you decode, then you will get error -12909 inside the decompression callback. In my scenario, I am in control of the encoder (NVENC) so I get the sequence header OBU when I initialise the encoder, and send this across as my "extra data" before I send any encoded frame data. On the decode side, I then use this in 1 and 2 above. My encoder then doesn't send any further sequence header OBUs at all as in my case the format doesn't change. In a more general scenario, there might be a sequence header with every IDR frame, so you'd just need to make sure you wait until you get the first sequence header so you can initialise the decoder as per 1. above, and then since the sequence header is already part of the encoded packet data 2. would be taken care of anyway.