Fails on Catalina with AVEBridge Error: AVEEncoder_CreateInstance: returning err = -12908

[aikinai]

Seems to be throwing this error on Catalina:

AVEBridge Info: AVEEncoder_CreateInstance: Received CreateInstance (from VT)
Assert - (remoteService != NULL) - f: /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleAVEBridge/AppleAVEBridge-18/AppleAVEEncoder/AppleAVEEncoder.c l: 290
AVE XPC Error: could not find remote service
Assert - (err == noErr) - f: /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleAVEBridge/AppleAVEBridge-18/AppleAVEEncoder/AppleAVEEncoder.c l: 1940
AVE ERROR: XPC failed
AVEBridge Info: connectHandler: Device connected (0x00007ff0a01b3470)AVEBridge Info: stopUserClient: IOServiceClose was successful.

AVEBridge Error: AVEEncoder_CreateInstance: returning err = -12908

[aikinai]

I edited my comment since I originally thought it was failing, but I see the conversion is completed despite the errors.

[biodranik]

Did you recompile it with a new XCode? I've just done it and published v0.3. I don't see any errors in the console with both older and new versions.

[aikinai]

Thanks for the response!

I tried compiled and interpreted and got the same thing. But I don't have the full Xcode installed, just the command line tools. Maybe I need the full install? My swiftc version is:

Apple Swift version 5.1 (swiftlang-1100.0.270.13 clang-1100.0.33.7)
Target: x86_64-apple-darwin19.0.0

[frankrolf]

I am getting that error too. However, I also get it when using sips (just found out about it in #6). Also, the same message is output in the Console when using Preview to save an image to HEIC.

I assume this is an OS issue (mine is 10.15.4 (19E287))

[biodranik]

That's interesting. My binary works on the same Catalina 10.15.4 (19E287). And sips also converts some jpg to heic. Do you have XCode installed?

[frankrolf]

Well, the binary works! The conversion process also works normally (AFAICT), just there is more output than expected.
I do have XCode 11.4.1 installed.

[pbalinov]

The same "extra" output appears for me as well. The converted image is fine. I am converting images with Q=1 option or Lossless in Preview. I am using script below for converting all images in a folder:

for x in *.jpeg; do echo "$x"; HEIF -q=1 "$x"; done;

When using Preview for this task, some of the images are corrupted - there is thin line of colors on the top. Like this:

While the same image, converted with this script is fine.

[aikinai]

It's not nearly as clean, but I later ended up using a combination of ffmpeg and mp4box to do my HEIF encoding. Just thought I'd share in case others here were interested.

[quantumgolem]

@aikinai What's the advantage of your script over using sips or this repo's tool?

[aikinai]

@sn0wyfall I haven't tested to be sure, but I would expect x265 to provide higher quality encoding than Apple.

Apple does encode billions of images on iPhones and likely cares about quality to a certain extent, but I assume they are using hardware and optimizing for speed and power consumption, with quality the third priority or so. I also don't know how that code flows back to their MacOS implementation.

On the other hand, x265 seems to be the highest-quality encoder available, and it has no reason to be prioritizing speed or hardware-compatibility over quality.

Of course this is just speculation, and could be easily verified or disproved with a real head-to-head comparison, but I don't have time to spend doing that so I just assumed x265 is better.

[quantumgolem]

@aikinai Thanks for the reply. You're right, I heard hardware accelerated encoding sacrificed quality. I wish I saw your comment before encoding thousands of images. I prefer retaining quality over speed.

I'll compare your tool and sips and I'll report back with my findings.

[quantumgolem]

@aikinai I did a blind test on four images. I used your script to encode with RF 26 and then generated sips images with many quality values, and chose the one that was closest in size. In all four cases I preferred the sips image when viewing at a 1:1 ratio. In my experience it was able to hold more detail despite having a comparable file size. It seems like if Apple is using hardware accelerated encoding, it's extremely good. In conclusion, at least for me I prefer using sips as it's fast and quite easy to use (also wrote a script to use it). Anyway, thanks for introducing me to the x265 encoding tool. Cool to know about it.

[aikinai]

@sn0wyfall Cool, thanks for doing the test! I commented on the other issue for how to change CRF if you want to try other sizes, but this is great to know. Maybe I'll switch back to sips too then.

[aikinai]

This seems to finally be fixed at least on Big Sur on Apple Silicon.

[bartzy]

Anyone knows if this is fixed/being addressed by Apple for non-Apple (i.e. Intel) based macs?
I'm still experiencing that error log on Big Sur 11.5.2.

[acecilia]

Experiencing this also on intel and bigSur 11.4

[biodranik]

It works without warnings on Intel Big Sur 11.6.

[biodranik]

@bartzy does it work despite the error log?

[acecilia]

It does work despite the error log in my case. The setup I followed is the one here

[bartzy]

It works without warnings on Intel Big Sur 11.6.

@biodranik Interesting! I'll upgrade soon and test as well.

@bartzy does it work despite the error log?

It does work (with the warning) on Big Sur 11.5.2.

[bartzy]

It works without warnings on Intel Big Sur 11.6.

@biodranik I upgraded to Big Sur 11.6 (MBP 16" 2019 i9) and I still get the warning.
Can you try sips -s format heic input.png -o output.heic and see if it finishes without any warnings?

[biodranik]

MBP 2014 - no warning neither for sips nor for my HEIF binary. Do you have the latest XCode installed?

[bartzy]

Xcode 13.0 (13A233). I guess this is a hardware thing. Probably something to do with the GPU on my MBP.
If anyone can test with a MBP 16" i9 with a Radeon 5500M and check if there's a warning when running sips -s format heic input.png -o output.heic, that would be nice.

[Colerar]

I've tested on a MBP 16" i9 with a Radeon 5500M, there is still a warning like this.

I think it's a Apple internal framework issue and we can do nothing.

Actually, Preview.app shows the similar warning, you can try it with Automator.app.

Related: mczachurski/wallpapper#42