TrevorSundberg

It almost sounds like it’s not using your dedicated graphics card. Do other WebGL demos run alright for you?

I haven’t done a lot of testing with Firefox, I’ll take a look!

Not yet, the port is still a work in progress. For the old Zero docs you can go here:

https://github.com/zeroengineteam/ZeroDocs

The runtime is currently about 37MB, and when served with gzip it’s around 11MB compressed. Once it’s downloaded it should be cached and quickly startup. I think a lot of the challenge is going to be spent getting the binary to be smaller, or potentially breaking it up into separate individually loadable parts.

Thanks for this info! I had a feeling that we weren't handling DPI scaling correctly, but don't have a Retina screen to test it on.

That's so cool! Zilch was my baby, that makes me so happy :D

The main reason was just because this engine was entirely built for native platforms originally in C++ (not for the Web). This is a port, hence why the UI is running in WASM/WebGL.

Ah sorry about that, this is still a big work in progress. A lot of the old links have died so we're porting over things like documentation still. I'll add a back-link to the github!

I'm sure there are higher performing engines out there, but it certainly should be easily deployed to any site. For rendering, this engine currently just uses WebGL. It was built on OpenGL originally (with a swappable renderer backend so we could target other 3d APIs). Eventually we may support WebGPU when support grows among the other browsers.

The mobile version needs a lot of work! But we'd love to support the full editor on phones eventually :P

Four months ago I had posted the first version of this project which was just the video editor. After garnering positive feedback, I decided to turn it into the social platform Gifygram where you can share your animations.

A major inspiration for the social aspect was MIT's Scratch game editor, which allows users to "Remix" other people's content into their own versions. Gifygram builds on this by showing all remixes under the original author's thread which adds another avenue of interaction on top of commenting and sharing.

For those curious, the inspiration for the animator was an old and purposefully goofy video from 2007, the 300 PG version: https://www.youtube.com/watch?v=gNqiSkd1M6k

And lastly for the WebAssembly fans, all the rendering and video encoding on Gifygram is done entirely within the browser, no video processing server required :)

Indeed, I made a bug to track it for myself: https://github.com/TrevorSundberg/madeitforfun/issues/2

I am using H264, but I'm now considering other options!

Great suggestion! I could use this with requestFrame()!

https://developer.mozilla.org/en-US/docs/Web/API/CanvasCaptu...

I think I will make this change because the ffmpeg legality seems hairy. Thank you!

I haven't tested in Safari since I don't own any Apple devices :(

However, I'll happily take fixes for it!

It could certainly be adapted to work on live streams, but I'm not sure what kind of setup they have to track the ball in that example. Seems decently complicated!

For sure! Although this project is using a worker for ffmpeg, currently it only runs one which means it's like you're running encoding on a single core machine, but with even more JavaScript overhead.

You could spin up simultaneous workers but you'd have to figure out how to break up what you're doing into separable parts. The file system is not shared between workers so you'd need to either send all the data back over or do something clever. This would be very doable, but I don't want to overload the browser especially on mobile.

Looking forward to when web threads are safe again... SharedArrayBuffer ;)

This is a good point, actually this might be what ffmpeg.js is already doing. I was wondering why they went out of the way to run the worker and pull ffmpeg code from unpkg.com, but I suppose that makes sense now!

Thanks for the tip, I'm certainly no legal expert!

The original inspiration for this was a very old video from 2007, the 300 PG version: https://www.youtube.com/watch?v=gNqiSkd1M6k

I had originally named this project Cake Town as an homage to a scene in that video, however the domain cake.town was taken so I chose https://madeitfor.fun/ instead :)

The goal was to be able to animate images and gifs over a video with controls that worked easily on both mobile and desktop, all on a website. I started to realize that with more things being compiled to WebAssembly, I could take advantage of video encoding directly on the page (no server encoding required). The web is truly a powerful platform!

Done! I took a bit of a shotgun approach because I don't have an iOS device to test, and the documentation on playsinline seems lacking (or at least non-standard). Hope that works!

I would definitely recommend trying something with JavaScript/HMTL5 videos. Doing anything native has always been decently complicated and there's a lot of setup work involved. If you want to get your toes wet, writing basic filters is fun :)

I laughed way too hard at this

Haha thanks for sharing, it's the first time I've seen anyone use it and share the link so I'm pretty excited!

Thanks for the tip, I'll try and write something up :)

Good suggestion. What would you think about a marker that sits above the timeline that you can drag?

Will do!

Absolutely, feel free to add it!

Overall ffmpegjs/ffmpeg.js has been really nice. I would honestly prefer less API: they wrapped everything into a worker and made their own API calls, but I'd prefer the raw Emscripten filesystem and no worker/proxying. Then maybe a second library that wraps it up would be nice for ease of use.

I ran into one issue where the memory being used by ffmpeg was too great for running on an Android Pixel 3a (malloc failed). I split up the video encoding into 30 frame chunks. I don't think this was related to ffmpegjs/ffmpeg.js however.

This version isn't any different than the normal puppeteer you use with Chromium. However, doing a quick search I found these two methods which you may be able to use to automate uploads: https://github.com/puppeteer/puppeteer/blob/master/docs/api.... https://github.com/puppeteer/puppeteer/blob/master/docs/api....

The server source is also in that same repo, it's under relay: https://github.com/TrevorSundberg/skugo/tree/master/relay

There's some code shared between the relay, client, and server (for message structure) in the shared directory.

I'll check out ngrok, it looks really handy! I was actually thinking that could be another use is to make a tunnel, but I decided to just scope it to browser apps only so you don't have to install anything on the client machine. I added ngrok to the related projects :)