libaom 1.0.0-729-ged7d0d090 is buggy

[JJKylee]

I know this is an upstream problem, but I think I need to report this.

Currently, m-a_s builds AV1 standalone binaries and libaom-av1 wrapper using libaom ver. 1.0.0-729-ged7d0d090. After some testing, I found out that this version is buggy and fails to decode/encode AV1 streams.

Converting an rav1e encoded IVF video stream to the webm/mkv format using FFmpeg fails because libaom-av1 fails to read the AV1 stream correctly. Likewise, libaom-av1 encoder of FFmpeg fails and stops at the start of the process.

For comparison, I downloaded Zeranoe's FFmpeg (20181007-0a41a8b(N-92132-g0a41a8bf29), 64-bit, static) and succeeded in decoding/encoding/muxing AV1 streams without any issues. Its libaom version is 1.0.0-691-gbb8157b89.

[wiiaboo]

Well, you'd need to disable libvpx to get a newer libaom. Or really press upstream to fix this. There's no other way.

c.f. #951

[wiiaboo]

Also, zeranoe works because it's using an even older version.

[JJKylee]

I see. Thank you for the answer.

[wiiaboo]

At most I can clamp to the same version until they fix upstream.

[JJKylee]

I'd greatly appreciate it if you could do so. I can't forsake libvpx for libaom for now because there's no other alternative to libvpx on Windows that I can think of now. (Other than YouTube, of course.) The libaom build is of no use and just a piece of junk as it is now.

[JJKylee]

Hi.

m-a_s successfully builds the same version libaom-av1 as Zeranoe, but those two libaom-av1's yield different results. While Zeronoe's libaom-av1 succeeds in decoding, m-a_s version does not. Please see this screenshot:

I have no idea why this happens. I think I'll have to put up with this for now until the upstream problem is fixed.

Thank you.

[wiiaboo]

You can either ask zeranoe what options he used for compiling libaom, or you can look at \build\aom-git\build\cmake\aom_config_defaults.cmake and try to find the magic combination of options that make your sample work.

You can start with using -DCONFIG_LOWBITDEPTH=0 since that's the only non-default option the suite uses and that's what might be breaking your sample, suggested by #924.

Create a file called aom_options.txt in \build and add a single line to it containing -DCONFIG_LOWBITDEPTH=0 to it. The suite/cmake will use your option instead of the suite's default and if that fixes it, I'll revert c7ae490.

[JJKylee]

Hi.

Thanks for your advice. However, the -DCONFIG_LOWBITDEPTH=0 option in \build\aom_options.txt does not solve the problem. Per your advice, I guess I need to ask Zeranoe about this.

Thank you again.