GIFSane: GIF playback control using WASM and FFmpeg | Hacker News Reader

GIFSane: GIF playback control using WASM and FFmpeg

brunoluiz.net

37 pointsbrunoluiz9 comments

Neat project! You could use WebCodec's ImageDecoder plus some custom controls to do this all in JavaScript without transcoding if you wanted. Otherwise you could use VideoEncoder and MSE for native video support.

https://developer.mozilla.org/en-US/docs/Web/API/WebCodecs_A... https://w3c.github.io/webcodecs/samples/ https://developer.mozilla.org/en-US/docs/Web/API/Media_Sourc...

That is interesting to be fair, I didn't know these APIs. Certainly something to have a look for either replacing WASM or for new projects.

I've considered using some JS libraries that are around for sometime (like https://github.com/buzzfeed/libgif-js), but the challenge of using WASM seemed more interesting in a hacking perspective let's say hehe.

Many of these programs are small but not exactly lightweight by browser standards. This is cool, so I applaud the efforts but this is also dangerous IMO because many entry level developers go out in search of solutions not knowing about optimization and eventually what was meant to be fun but not serious ends up becoming the norm. Converting optimized videos already supported by the browser to sub-optimized images to convert back into bloated videos is just insanity IMO, but could quickly become the norm for how websites operate if we are not careful with WASM... and it does come at a performance costs, whether bandwidth or complexity... and I for one, as much as I despise JavaScript, like that it is at least semi-transparent. How long before we have people reverse-engineering WASM programs just to read what is happening in your web browser which has already became the preferred tool for fingerprinting and gathering user information? Malicious advertisers will see WASM as the holy grail.

> GIFs are ominous nowadays, being more popular than even newer and more efficient formats, such as WEBP or APNG. But, depending on their length and what has been recorded, you might want to pause, go back, jump sections etc. Video playback features basically… which GIFs don’t have.

The lack of video features are exactly the reason for which gifs are preferred in some contexts:

- you are 100% sure that you're not going to have audio surprises

- you don't have useless UI components. I'm just watching an idiot meme, why there is a time slider, a play/pause button, a muted audio button, a full screen button...? Ok, controls can be disabled and customized, but it requires effort that a simple <img src="funny-dog.gif"/> gives you for free

The only GIF's issue is that the format is not disk-efficient, but who cares? I can live with it when I'm watching a few-seconds-lasting-low-resolution-dumb-meme

I don't have anything against meme GIFs: they are short and meant to be repeatable, so all good.

But, as I wrote in the post, I came across too many GIFs with demos, tutorials or animated diagrams on GitHub and NPM. This was the motivation to create GIFSane, as sometimes you want to stop in a frame, or go back to check a detail.

> The software engineering world adopted them for a particular use case: recording tutorials and demos.

Besides, the whole thing was done in the name of the hacking spirit hehe Perhaps, one day, GitHub will convert any GIFs/WebM files into video components (similar to what Twitter does).

Interesting to hear the authors issues with mv2/3.

I’ve run into the same recently, while trying to build out a simple PoC extension. MV3 seems to be vague, and many of the changes specified do not seem to have actually been implemented yet. Such as chrome.tabCapture being namespaced to chrome.capture. Or these are bugs, it’s unclear.

It’s certainly odd that the schedule for moving to MV3 appears to be underway (not accepting MV2 extensions) when I’ve found the only way to enable my use cases has been to downgrade to MV2 (as the author also found)

Edit: The bug report I found, but unclear if it’s going to be fixed. As conflicting announcements else where state this api will be moved to the chrome.capture namespace for MV3. But neither presently works.

https://bugs.chromium.org/p/chromium/issues/detail?id=121484...

Yeah, I had the same feeling that MV3 has been rushed and is not 100% ready. The other issue as well is that Mozilla and Google roadmaps are quite different, so you might end-up having to support both MV2 and MV3 for a while at least. And even then, Mozilla will have some different APIs on MV3 (albeit they will be extra APIs when compared to Chrome).

I am looking forward to see the state of things in December 2022.

How about OpenH264[1]? It's not preinstalled and it's not clear whether it works for generic video (I think it does), but it might be useful in Firefox.

Granted, I would love if hardware video acceleration for some of the free codecs like AV1 would be more widely available.

[1] https://blog.mozilla.org/en/mozilla/video-interoperability-o...

I guess if the user install, it should be able to play (haven't tried). But, because this would require extra steps, I preferred to just have the ST + VP9 to Firefox. In future versions, I could give an options page where the user can adjust this.

Reply on news.ycombinator.com