bjano

Nothing is uploaded, everything runs locally.

The creator of that repo has a blog with some posts on building a wasm version of FFmpeg, I mostly followed those: https://jeromewus.medium.com/ I also used some of their scripts for building the 3rd-party libraries.

It took a bit of trial and error to see which versions of the different libraries and build tools work together.

.avi file just shows a spinner in place of the preview, never finishes loading

.mkv files are not enabled in the file picker, if I select one anyway it loads, but the export hangs

hevc .mp4 loads, but the exported video is all black

The site claims "versatile codec support" but I couldn't get it work with anything except the most vanilla h264 files.

(though as I am working on a similar product I am aware that handling all the codecs is quite a bit more painful than it first seems)

You don't need to keep the video files in memory, it's enough to have the javascript File object and then you can read the packets you need on the fly. This way the app's memory usage should be okay.

This is what I did in my similar project (vidmix.app) and seems to be what OP's project is doing, except that they also copy the file to indexedDB to keep it around after the browser tab is closed.

It seems to me that the demonstration is calculated in sRGB space, so with non-linear brightness values and I suspect that most of the unnaturalness of the smear is due to that. To simulate the physics this would need to be done with linear brightness values and only at the end converted to sRGB.

(unless some non-linear effects in human visual perception cancel all that out, but it should at least be mentioned if so)

I've been having the same issue with an app. Random rejections with a single line copy-pasted from the (genuine) feature list in the app description. In this case the lines just start with a regular dash ("-").

This together with the sometimes 10+ day review times makes it impossible to maintain an app on the Play Store now.

I use a WebAssembly build of FFmpeg to extract the streams and packets from the video files and as a fallback for some codecs. But most of the decoding/encoding is done with WebCodecs which in most cases has access to hardware acceleration so can be much faster than ffmpeg.

I've built the UI library myself, it's written in C++ and is drawing with OpenGL. (translated to WebGL by emscripten) Javascript is only used for the browser-related parts. The point of this is that the javascript layer can be easily replaced and the project built for other platforms. (for example it runs on iOS natively: https://apple.co/3QVAYAq)

WebCodecs is missing. They say it's "worth prototyping" [1] but I don't know whether they are working on it.

1: https://mozilla.github.io/standards-positions/

For people who don't want to sign up but still like the idea of a video editor running in a browser (that doesn't upload anything), I am working on an alternative:

https://vidmix.app

https://vidmix.app checks all the boxes: in the browser, layers, no watermark, captions, giphy integration, mp4 in and out

Yes, the shortcomings of the html video tag are quite unfortunate. Just some very small improvements would make it a lot more useful. One other issue I found at the time I was looking at it (not sure if it's still the case) was that stepping one frame forward wasn't any faster than seeking from a random location. Seemed like the video was decoded from the last keyframe every time, making it inefficient to iterate through the frames.

In Chrome and Edge you can use WebCodecs to decode and display video frames one-by-one. (this is what I used for the video editor at https://vidmix.app )

In other browsers you could build FFmpeg with webassembly and use that for frame-by-frame decoding but it's not going to be nearly as performant.

Couple years ago there was a similar site with the same idea about listing all private keys. If you "found" an active address it was immediately emptied. (I am not sure if it had a search bar or you had to edit the URL)

The biggest problem is not supporting h264 encoding for the output.

Also as the preview playback is done with html video elements and those can't be started at a precise enough time, the timing of these videos are imprecise and may not align with other elements. This only happens at playback or scrubbing, not when staying on a single frame and the exported result should not be affected.

At the moment I don't have plans to make it open source.

I suspect that the drag and drop limit of 5 may be a browser/OS limitation, now I couldn't reproduce this but will look out for it. And yes, probably it would make more sense to put them on the same track after each other so I will change that. Thanks for pointing this out!

It doesn't have WebCodecs: https://caniuse.com/?search=videodecoder

Thank you, great to hear that you like it!

mp3 files not loading was an embarrassing bug, I just fixed it, should work now. (only remaining issue I just realised is that the volume panel doesn't show up when the track is first selected, I'll look into that later)

Hello HN! WebCodecs landed in chromium recently opening new possibilities for browser-based video editing: instead of relying on cloud-based processing, everything can now be done locally. As I never had a good answer when app developer friends asked me how to quickly edit their screen recordings for appstore listings, I decided to build something with this: a no download, no sign-up, no BS video editor.

pros:

- Everything is processed locally, nothing is sent to the cloud. This means privacy, but also speed: if you want to extract a 20 seconds part of a 800 MB video file, you don't have to wait for the upload. - No limits on frame size or video length. It isn't using any cloud resources so no need to put artificial limits on that. - Precise timing. Seems like a small thing, but surprisingly difficult to get it right with html <video> tags. - Preview matches exactly the final result: the exact same code generates the preview and the exported video, not some ugly hack attempting to replicate what you see in the browser to the cloud renderer.

cons:

- It only works properly in Chrome and Edge, with some acceptable fallbacks in Firefox. - HEVC is not supported by any browser, so for that FFmpeg is needed but that's only fast enough on recent computers - Everything needs to be loaded into memory. Compared to the cloud-based editors this isn't much of an issue as those typically limit you to 100-200 MB files anyway, but eventually I'd like to use the Filesystem API to make it possible to edit videos of any size.

Also there are plenty of more advanced features: unlimited number of layers, motion tracking, blending modes, using LUT files, a not-so-basic painting tool, etc.

Let me know if you have any questions or feedback!

WebCodecs is available since the latest Chrome, so it is now possible to use hardware accelerated codecs from the browser. Instead of uploading & downloading GBs of data and paying for someone else's processing power, you can do everything locally as long as you don't mind a few limitations.

I am working on a project using this approach: https://vidmix.app

(still plenty of minor bugs, I was planning for a proper Show HN soon)

Also because both the preview and the rendering is done with WebGL the result is guaranteed to match what you see while editing, unlike with some cloud-based editors where a different stack on the rendering backend is trying to replicate what the browser is doing with js+css

They published their demo calculator app on the Play Store: https://play.google.com/store/apps/details?id=uno.platform.c...

All the top reviews are talking about how slow it is. A calculator app.

I also use a cross-platform framework that "renders every pixel". The two major problems I had are the lack of native input and the integration with native ad SDKs. I solved the input with overlaying a native input view on top of everything but it's very clunky and have to be careful to keep it the topmost in the view hierarchy. I haven't found a solution for native ads.

Most of the other things are relatively easy to solve if they come up as actual problem.

They are using openface: https://cmusatyalab.github.io/openface/#openface

The library gets the picture as input and spits out a 128-element vector. The more similar the vectors are for two pictures the more likely they are of the same person.

You don't need to train it, there is a pretrained version available.

There seems to be a huge conflict of interest here: as card processors slap you with an extra chargeback fee for the fraudulent transactions (in addition to the amount they take back anyway) it's difficult to believe that they would work very hard to help you avoid this.

Yes, customers of other budget VPS providers are complaining about this too.

> why should a network you're paying $20-$100 do everything they can to keep a target online and threaten other customers?

I am not a network engineer and I know that this is a very difficult problem. But when the provider doesn't even _seem_ to try, it only encourages further attacks.

> blackholing is a blunt but crucial weapon in our arsenal, giving us the ability to ‘cut off a finger to save the hand’ – that is, to sacrifice the customer who is being attacked in order to keep the others online

There is something very ironic about this. They have a policy which instead of addressing the problem actively assists anyone wanting to attack their customers. No surprise that these customers have been complaining about this practice for a long time. But until now it was Somebody Else's Problem so they didn't bother figuring out some proper (or at least less terrible) solution. Now this lack of preparedness bit them in the ass...

So the main purpose of most of the 18000 classes is to make it possible for the app to scale up to 18000 classes? :)

Similar but less high-profile news: the once biggest hungarian social network site, iwiw.hu is shutting down tomorrow.

Launched in 2002, by 2006 it had pretty much every hungarian internet users signed up who could be bothered by such sites. T-Mobile/Deutsche Telecom acquired it for 4 million euros in 2006 and at the time it seemed unthinkable that it would lose its momentum.

As a result, Hungary was one of the very last countries for Facebook to overtake the local competition, but eventually people with international friends started to sign up for Facebook too and the network effect kicked in: for the past 1-2 years iwiw.hu was in a free fall and one month ago they announced that they would pull the plug completely.

I also tried mining Wikipedia, but I found it's much more reliable to use the categories of the movies instead of the links.

The links are very often unrelated: "unlike in the movie X", "who by then had already became famous playing X in movie Z", etc. Instead of using the entire article, I only used links from the very first sentence. (" X is an Italian 1984 drama starring Z, etc...") These links could be connected to categories.

The problem I didn't expect was that the "hierarchy" of the categories is a mess. Seems easy in concept: "comedy-drama films" is a subcategory of both "comedy films" and "drama films", so you can use all the parent categories. In practice you get to completely unrelated categories in a few steps. The biggest challenge was cleaning this mess up algorithmically. Once that was done, I had a very nice taxonomy of the movies.

The result didn't come close anywhere to the top contestants, but it was a very interesting learning experience.