Rendered webm files are broken (Chrome 52.0.2743.116)

[MagicPigeon]

After rendering replays with latest Chrome (or Opera) the webm files can't be played by any video player, uploaded to streamable/gfycat ("ffmpeg exited with code 69") or converted to other formats. It happens to new and old replays. The preview in browser still works, sometimes after rendering the checkmarks don't show up, or the render bar gets stuck some way along the way (and the extensions has to be reloaded). Now, installing the extension in Coowon works, the replays get rendered and play just fine, so it has to be something with the latest Chrome that causing this.

[MagicPigeon]

Also, I tested earlier builds of the extension (1.2.25, 1.2.23 and 2.0 beta) and the result was the same with webm files being unplayable.

[chrahunt]

Confirmed in Chrome 54.0.2824.0. It may be related to antimatter15/whammy#43, the reporter in that issue is working with fewer frames than are in a typical replay.

[ghost]

I looked in to this a bit this evening and confirmed Whammy is not working in my Chrome version (52.0.2743.116) but continued to work in my older Opera version (until I restarted Opera and it auto-updated, now no longer works). As best as I could tell by comparing them, the problem probably lies somewhere in the compiling step in the Whammy code (i.e., video.compile()). The video instance pre-compiling looked identical to the Opera one and contained valid webp images as frames.

Unfortunately the Whammy code that does the compiling is kind of hard to follow.

I couldn't directly compare the blobs that resulted after compiling, so it's still possible that those were identical too in Chrome and the old Opera, but that would mean that the problem lies in one of the steps to download the file (turning the blob into a url, most likely I guess?), but that seems less likely to me.

[ghost]

This project apparently also uses Whammy. Might be of use to see if they're also having problems recently?

[ghost]

This demo is still working for me (though I don't think it's using Whammy). After it records it displays the video, and I can right click and download it. Possible replacement for Whammy?

[chrahunt]

Okay, I figured out the issue. In Whammy here it skips the first 4 bytes of the VP8* chunk, assuming there's no additional metadata. Well now there is, but it isn't what the webp format is expecting. Replacing 4 with webp.data.indexOf('\x9d\x01\x2a') - 3 did the trick (get to the start_code then back up 3 bytes for the frame_tag as detailed here. I did a local test and was able to generate a webm that ffmpeg approved of.

I will patch the version used by the extension, do an additional test, and push out an update. It may be worth taking a look at alternatives to Whammy in the future.

[ghost]

Wow! Very, very nice work!

[chrahunt]

This will also need to be fixed in 2.x.

[chrahunt]

Refocusing dev effort to converge onto something that looks like 2.x instead of maintaining 2 separate branches and making a big jump.