spuzvabob

I've built a similar video editor and have been considering pure client side implementation vs transcoding into a known format beforehand, went with transcoding for wider format support and easier video playback implementation.

I'm interested in how you handle demuxing different container formats any which ones are supported?

I get "Audio decode failed: your browser cannot decode the audio in "41b1aee9-ac65-43f6-b020-e8fed77c3c72_webm.bin". Try re-encoding the file with AAC audio." for a WEBM with no audio.

h264/aac MP4 works, is that demuxed with mp4box.js? I noticed seeking (clicking or scrubbing on timeline) initializes a new VideoDecoder and destroys the previous one for every new frame, leading to abysmal performance as you lose decoder state and a lot of decoding work has to be repeated. Plus the decoder reinitialization time. Is that because the demuxing logic doesn't give precise access to encoded frames? iirc mp4box.js didn't support that last time I checked.

> So you use a library that takes in text and vectorizes it to canvas shapes? That could work in theory, do you have a demo of this?

Yea, it's harfbuzz compiled to WASM: https://harfbuzz.github.io/harfbuzzjs/ Then all text layout features must be implemented on top of it, like linebreaking, text align, line spacing, kerning, text direction, decoration etc.

> Totally understand the appeal and immediacy of a browser app, I was lured in by that too. For what it's worth I've reported showstopping WebCodecs issues in Chromium and there's basically no indication they'll get fixed on a predictable timeline.

Interestingly I have the exact opposite experience, I've reported issues both in the WebCodecs specification and the Chromium implementation, in all cases they were fixed within weeks. Simply though reports on public bug trackers and it wasn't really a major issue in any instance.

> Another issue I ran into that I just remembered is animating text on canvas. It's basically impossible to get pixel-perfect anti-aliased text animation using a canvas. I would have to dig up the exact details but it was something to do with how browsers handle sub-pixel positioning for canvas text, so there was always some jitter when animating. This coupled with the aforementioned WebCodecs issues led me to conclude that professional-quality video rendering is not currently possible in the browser environment. Aliasing, jitter and artifacts are immediately perceptible and are the type of thing that users have zero tolerance for (speaking from experience).

We're doing SOTA quality video rendering with WebCodecs + Chromium with millions of videos produced daily, or near SOTA if you consider subpixel AA a requirement for text. In general for pixel perfection of text, especially across different browsers and operating systems, you can't just use text elements in DOM or in canvas context, instead text needs to be rasterized to vector shapes and rendered as such. Honestly not sure about potential jittering when animating text, but we've never had any complaints about anything regarding text animations and users are very often comparing our video exports with videos produced in Adobe AE or similar.

Neat! We made a similar thing years ago in the pre-AI era, with strong focus on detection of how the planned workouts were executed rather than making plan adjustments just on a single scalar metric (e.g. TSS). Didn't really go anywhere unfortunately.

https://www.kickstarter.com/projects/1725424103/summit-train...

Congrats on the launch! The usage examples make a lot of sense, I'm wondering if you plan to provide preconfigured implementations for the most common checks or is custom coding the only option?

For a very similar use case I've developed custom text rendering in browser with support for CJK, Thai, Arabic (including bidirectional text with Arabic text within Latin or vice versa) and bitmap emojis.

Tbh all the complex part is handled by: https://github.com/harfbuzz/harfbuzzjs which handles the entire text shaping part (which glyphs to draw and the offset from previous glyph), then all that remains is text layout (linebreaking, kerning, line height, font size etc.) and the actual rendering ofc. Still took about 4 months of full-time work.

There is a well maintained Wasm build of harfbuzz: <https://github.com/harfbuzz/harfbuzzjs> with both OpenType and AAT shapers support, which should be enough but you can also provide your own shaper implementation in Wasm yes.

We're successfully using Wasm harfbuzz to render text in a web-based design tool with relatively high usage so there should be no issues integrating it :)

If you are considering upgrading from Vue 2 with Vuex note that store getters caching is not working in Vuex for Vue 3, potentially hindering performance significantly.

The issue was reported multiple times but it's not yet fixed: https://github.com/vuejs/vuex/issues/2102 https://github.com/vuejs/vuex/pull/1883