wasm-av1 icon indicating copy to clipboard operation
wasm-av1 copied to clipboard

No Playback

Open cconcolato opened this issue 5 years ago • 13 comments

I was able to produce decode-av1.js and decode-av1.wasm, but when I load index.html in Chrome (Version 71.0.3578.62 (Official Build) beta (64-bit)), through localhost (not file://) I get:

decode-av1.js:1 wasm streaming compile failed: TypeError: Failed to execute 'compile' on 'WebAssembly': Incorrect response MIME type. Expected 'application/wasm'.
(anonymous) @ decode-av1.js:1
Promise.then (async)
doNativeWasm @ decode-av1.js:1
(anonymous) @ decode-av1.js:1
(anonymous) @ decode-av1.js:1
decode-av1.js:1 falling back to ArrayBuffer instantiation
(anonymous) @ decode-av1.js:1
Promise.then (async)
doNativeWasm @ decode-av1.js:1
(anonymous) @ decode-av1.js:1
(anonymous) @ decode-av1.js:1

I've tried applying https://github.com/mdn/webassembly-examples/issues/5#issuecomment-441366546 (I'm on a Mac) but to no avail. I've tried loading some IVF files, including the ones from http://download.opencontent.netflix.com/?prefix=AV1/ but nothing happens.

Is it a problem with my setup? Do you have an example of a file that plays?

cconcolato avatar Nov 26 '18 20:11 cconcolato

Here are a couple of files that should play: http://alex-wasm.appspot.com/av1/video/big_buck_bunny_360p24.ivf and http://alex-wasm.appspot.com/av1/video/elephants_dream_360p24.ivf Example command line I used for encoding: ~/src/wasm/wasm-av1/third_party/build/aomenc --cpu-used=4 --webm -o mother_daughter_cif.webm mother_daughter_cif.y4m and then I converted to IVF IIRC.

adanilo avatar Dec 11 '18 03:12 adanilo

Your files do work on my machine (even if the console shows the same error). Looking at them, they seem to have been generated with an old, non-standard version of aomenc. I'll try to follow https://developers.google.com/web/updates/2018/08/wasm-av1 with a more recent build.

cconcolato avatar Dec 11 '18 05:12 cconcolato

That'd be great. The version of libaom is checked in here under third_party

adanilo avatar Dec 11 '18 05:12 adanilo

I have a checkout of libaom in a folder aom next to wasm-av1 and the result of cmake (as described in your blog) in a folder called aom_wasm also next to wasm-av1.

In the Makefile

AOMDIR=third_party/aom
LIBDIR=third_party/embuild
INC=-I $(AOMDIR) -I $(LIBDIR)
X86LIBDIR=third_party/build

when I replace third_party/aom with ../aom and third_party/embuild with ../aom_wasm I get

decode-av1.c:35:10: fatal error: 'video_common.h' file not found
#include "video_common.h"
         ^~~~~~~~~~~~~~~~
1 error generated.
shared:ERROR: compiler frontend failed to generate LLVM bitcode, halting
make: *** [decode-av1.js] Error 1

Probably because I did not change X86LIBDIR but I don't know what to set it to. What am I doing wrong here?

cconcolato avatar Dec 11 '18 05:12 cconcolato

Found it, the new version of the aom code has files located differently compared to your checkout. You have to replace "video_common.h" by "common/video_common.h". Then compilation works but I get a green or pink rendering and duplicated images, as if the stride or pixel format was not correct.

cconcolato avatar Dec 11 '18 06:12 cconcolato

X86LIBDIR is only for building the test harness to run on the command line, so you don't need to change it. Do you see aom/video_common.h? You should probably just copy that over from here and it might build.

adanilo avatar Dec 11 '18 06:12 adanilo

Have you tried it with my IVF files or your samples? When debugging I had green rendering, so yes, it's a stride thing. Or 16bit vs. 8bit channel depth.

adanilo avatar Dec 11 '18 06:12 adanilo

Your (old aom) code with your files works fine. The latest aom code with your file does not work (no rendering, no message). The latest aom code with the Netflix files gives green/pink/dual rendering. Where can I change the stride or channel depth?

cconcolato avatar Dec 11 '18 06:12 cconcolato

The code in yuv-to-rgb.c contains the depth and chroma sub-sampling logic. That's what you'll need to modify for different bit-depth, etc.

adanilo avatar Dec 11 '18 21:12 adanilo

Yeah, I found it. Actually, with the latest libaom, I had to force generation of 10bit output in my encodes with aomenc, using --bit-depth 10, and then I had to change the yuv-to-rgb code as follows:

r = *y/scale + T1[*vline/scale];
g = *y/scale + T2[*vline/scale] + T3[*uline/scale];
b = *y/scale + T4[*uline/scale];

Note that I had to swap U and V and scale is set to 4. With these changes, I am able to decode and render correctly the first frame of my videos! There is a problem with the other frames but my goal is to use this code for AVIF demo, so I should be fine for now.

cconcolato avatar Dec 11 '18 22:12 cconcolato

Great, let me know if you run into anything more. It'd be nice to update to the latest library but it needs to play the video to be useful.

adanilo avatar Dec 11 '18 23:12 adanilo

FYI, I have now a working AVIF renderer, based on your code and the latest libaom (for 8 and 10 bits). Hopefully, I should be able to release it soon.

cconcolato avatar Dec 12 '18 06:12 cconcolato

Great, glad you worked it all out.

adanilo avatar Dec 12 '18 08:12 adanilo