Adam Wieckowski

Closed accidentally. I misread the issue number to close.

I think clang v15 is way too early to take its warnings seriously. We had a lot of problems with early compiler version, and I'd rather wait out for those...

Hmm. We were not really looking into it. Do you know how much of a potential that would have?

I'll put it on the agenda to try out, but there isother stuff to be finished first (planning to compile a roadmap soon). Until than I'll put the issue as...

VVenC is for now an encoder supporting exclusively the x86 platform. For that reason there is no need to support any other build targets. We support compilation under Mac OS...

Its neither _blocked_ or _intentional_. It has just never been intended to work or tested. If you only develop on one platform for one platform your code eventually only works...

Thanks. As mentioned, you can expect ARM support, with proper testing as a supported platform, after the summer.

Error resilience is still on the roadmap, we'll look into that. Technically you could just keep feeding the decoder the frames, and starting at the next random access point it...

For now, the cause of the issue is unknown, but somehow connected to Xcode. Building under MacOS without Xcode helps. For `make`-based build, please use `g=ninja` or `g=umake` to select...

Yes. On Linux the one output reports CPU time and the other the wallclock time. The former will be larger than the latter in multi-threading encoding. On Windows both outputs...