Does not work correctly on Apple Silicon after successful compilation

[Stefan-Olt]

While fmtconv compiles fine on Apple Silicon, it doesn't seem to work correctly. I noticed that nnedi3_rpow2 doesn't seem to work correctly (with different input formats): luma seems to be fine, but chroma is all solid green. While I thought nnedi3 is the problem, it works perfect if I do not use fmtconv (disabling all the chroma alignment corrections).

I'm not sure what is causing this issues, are there automated test cases that can identify incorrect functions or could someone else confirm?

[EleonoreMizo]

Unfortunately I haven’t an Apple machine for testing, and there are no automated tests. I’m even surprised it could compile without issue. I’ve got a nano ARM computer at home, I’ll see if I can install Vapoursynth and fmtconv on it, but I will be AFK within the next two weeks. In the meantime, it would be very helpful if you could nail down the culprit function and parameters.

[Stefan-Olt]

Why is that surprising? There was issue (#30) fixed October last year to allow compilation on m1 macOS. I will try to nail the problem down, in case that's relevant: For compilation clang 13.1.6 is used on the Mac I experienced this problem.

[Stefan-Olt]

I traced it down: Only the resample function seems to be affected, no matter if changing bitdepth or size for different input formats. For YUV the colors are completly wrong (it's all green), for RGB everything is way to dark.

[EleonoreMizo]

This is a surprise because without regular testing, code can break at any time and I’m excellent at breaking working code! Thanks for the tests. This is probably a scale issue, I’ll check ARM code when I return.

[ViRb3]

Tested on MacBook Pro 2021 M1 Max, macOS 12.6, both Apple's compiler and LLVM from homebrew:

Apple clang version 14.0.0 (clang-1400.0.29.102)
Homebrew clang version 15.0.3

Using the sample code:

from vapoursynth import core
import vapoursynth as vs

core.std.LoadPlugin(path="libfmtconv.dylib")
core.std.LoadPlugin(path="/opt/homebrew/Cellar/ffms2/2.40_3/lib/libffms2.4.dylib")

clip = core.ffms2.Source(source="sample.mp4")
clip = clip.fmtc.resample(css="444")
clip = clip.fmtc.matrix(mat="709", col_fam=vs.RGB)
clip = clip.fmtc.bitdepth(bits=BITS)

clip = clip.fmtc.matrix(mat="709", col_fam=vs.YUV)
clip = clip.fmtc.resample(css="420")
clip = clip.fmtc.bitdepth(bits=8)
clip.set_output()

Input video ffprobe:

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'sample.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf59.27.100
  Duration: 00:01:12.22, start: 0.000000, bitrate: 1372 kb/s
  Stream #0:0[0x1](und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9], 1241 kb/s, 12 fps, 12 tbr, 12288 tbn (default)
    Metadata:
      handler_name    : ISO Media file produced by Google Inc. Created on: 05/16/2019.
      vendor_id       : [0][0][0][0]
  Stream #0:1[0x2](und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 127 kb/s (default)
    Metadata:
      handler_name    : ISO Media file produced by Google Inc. Created on: 05/16/2019.
      vendor_id       : [0][0][0][0]

Then executing:

vspipe -c y4m main.py  - | mpv -

Results for BITS:

• 32
• 16
• 8

And another scenario:

from vapoursynth import core
import vapoursynth as vs

core.std.LoadPlugin(path="libfmtconv.dylib")
core.std.LoadPlugin(path="/opt/homebrew/Cellar/ffms2/2.40_3/lib/libffms2.4.dylib")

clip = core.ffms2.Source(source="sample.mp4")
clip = clip.fmtc.bitdepth(bits=BITS)
clip.set_output()

16 and 32 bits seem to work great. But with 8 bits:

Happy to run any further tests.

[ViRb3]

I found a workaround for colorspace conversion that is built-in and works on arm64:

# to RGB
clip = core.resize.Bicubic(clip, format=vs.RGBS, matrix_in_s="709")
# to YUV
clip = vs.core.resize.Bicubic(clip, format=vs.YUV420P8, matrix_s="709")

[SaltyChiang]

Part of the problems above might be fixed by #40. Conversion from int to float on Apple M1 returns the wrong result.

@ViRb3 @Stefan-Olt would you please check this?