Criei um compressor de vídeo online pensado para usuários em português

高赫阳 — Fri, 14 Aug 2026 02:04:42 +0000

Estou construindo o Vidoro, uma ferramenta simples para compactar vídeos online.
Percebi que muitas ferramentas de vídeo são feitas principalmente para usuários de inglês, enquanto usuários de português (especialmente no Brasil) ainda têm poucas opções bem localizadas.
Por isso criei uma versão em português para ajudar pessoas a reduzir o tamanho dos vídeos antes de enviar pelo WhatsApp ou redes sociais.
Ainda estou melhorando a ferramenta e adoraria receber feedback de outros criadores.
https://vidoro.io/pt/comprimir-video-online

I Built Vidoro — A Browser-First Toolkit for Video Compression and Media Conversion

高赫阳 — Thu, 13 Aug 2026 07:32:04 +0000

Hi everyone!

I’ve been building a side project called Vidoro — a collection of simple online media tools focused on video compression, format conversion, privacy, and practical everyday workflows.

The idea is straightforward:

Choose a file → process it → download the result.

No complicated editing interface, no unnecessary account creation, and for tools that can reasonably run in the browser, no file upload to a remote server.

Vidoro currently includes a homepage, two versions of the video compressor, and a MOV-to-MP3 converter. I’m gradually turning it into a larger collection of focused media utilities.

💡 Why I Built It

A lot of online media tools technically work, but the experience often feels heavier than the task itself.

For something as simple as reducing the size of a video or extracting audio, users may have to:

upload a large file to a remote server
wait for the upload to finish before processing even starts
create an account
navigate several configuration screens
deal with watermarks or usage restrictions
wonder what happens to the uploaded file afterward

I wanted Vidoro to feel more like a local utility that happens to run in a browser.

Whenever browser-side processing makes sense, the file stays on the user’s device and FFmpeg runs through WebAssembly.

For heavier or smarter workflows, Vidoro can also use a backend processing pipeline, but I try to keep that distinction clear to the user.

🌐 Vidoro Homepage

👉 https://vidoro.io/

The homepage is the central entry point for the project.

Instead of building every tool as an isolated website, I’m putting them under one product and one design system.

The goal is for Vidoro to eventually become a toolbox for common media tasks such as:

video compression
audio extraction
video conversion
image conversion
video-to-GIF
audio processing
other lightweight media utilities

The homepage is intentionally simple.

Rather than showing dozens of settings or categories immediately, it introduces the available tools and lets users go directly to the task they need.

🎬 Compress Video Online — English

👉 https://vidoro.io/compress-video-online/

This is the English, privacy-focused version of Vidoro’s video compressor.

The main idea behind this page is:

compress the video directly in the browser without uploading it to a server.

The workflow is:

Choose a video
Select a compression level
Let FFmpeg WASM process the video locally
Download the compressed MP4

The current compression options are intentionally simple:

High Quality
Balanced
Maximum Compression

I didn’t want users to have to understand CRF values, encoding presets, audio bitrates, or other FFmpeg parameters just to reduce a file size.

Under the hood, the browser version currently uses FFmpeg with H.264 video and AAC audio and generates an MP4 output.

The page supports common formats such as MP4, MOV, AVI, MKV, WebM and other formats already handled by the converter.

One of the main goals of this version is privacy.

For the normal compression workflow:

the video stays on the device
there is no server upload
there is no account requirement
there is no watermark

This also means the performance depends heavily on the user’s device.

A powerful desktop can process videos reasonably well, while very large files on a phone can obviously be more challenging.

That tradeoff is something I’ve found interesting while building the project.

🇧🇷 Comprimir Vídeo Online — Portuguese

👉 https://vidoro.io/pt/comprimir-video-online/

The Portuguese version is currently more advanced than the English version.

It contains the same local FFmpeg WASM compression workflow, but it also includes a smart compression mode.

This mode is aimed at a problem I noticed while working on video compression:

Most users don’t actually know what compression settings they need.

They don’t think in terms of:

bitrate
codec
CRF
frame rate
resolution

They think in terms of:

“I need to send this on WhatsApp.”

“I need a smaller attachment for email.”

“I want to save storage space.”

So the smart compression mode analyzes information about the uploaded video and allows the user to choose a target use case such as:

WhatsApp
Instagram
Email
Website upload
Storage saving

Vidoro then recommends a compression profile.

The analysis can include information such as:

resolution
duration
codec
FPS
file size
bitrate where available

The system then recommends settings such as:

target codec
CRF
target resolution
FPS
estimated output size

I also spent some time improving the output-size estimation.

An early version could predict something like:

4.7 MB → 700 KB

while FFmpeg actually produced something closer to:

4.7 MB → 2.1 MB

That was obviously too optimistic.

The estimation system is now more conservative and takes more properties of the source video into account.

In one of my later tests:

Original: 329,498 bytes
Predicted: 166,045 bytes
Actual output: 159,576 bytes
Reduction: 51.6%

That was much closer to the real output.

🤖 AI / Smart Compression Architecture

One important design choice is that the smart compression system does not require an AI API to work.

It uses a hybrid approach.

The basic pipeline can work with:

ffprobe → video metadata → deterministic compression profiles

So even without an OpenAI API key, it can still analyze the video and generate recommendations.

An optional LLM layer can be used for richer recommendations, but the core functionality does not depend on it.

I like this architecture because I don’t want an “AI feature” to stop working just because an external API is unavailable.

The deterministic system remains the fallback.

🎵 MOV to MP3 Converter

👉 https://vidoro.io/mov-to-mp3-converter/

The MOV-to-MP3 converter is much simpler, and that is intentional.

Its job is just:

take a MOV video and extract the audio as MP3.

The entire conversion happens inside the browser with ffmpeg.wasm.

The MOV file is not uploaded to Vidoro.

The workflow is:

Select or drag in a MOV file
Choose MP3 quality
Convert it locally
Download the MP3

This can be useful for things like:

extracting audio from iPhone videos
interviews
lectures
voice recordings
video podcasts
saved clips
music or audio recordings stored inside MOV files

The default configuration is designed to be simple rather than expose every FFmpeg audio option.

For this kind of task, I think that is the right tradeoff.

Most users don’t want to configure sample rate, channels, codec profiles, and command-line flags.

They just want the audio.

🔒 Why I Like Browser-Side Processing

One of the most interesting parts of building Vidoro has been deciding which jobs belong in the browser and which belong on the server.

For tasks like:

MOV → MP3
normal video compression
simple format conversion

browser-side FFmpeg can work surprisingly well.

There are several benefits.

No upload time

If someone has a 300 MB video, a server-based tool may require the entire 300 MB upload before processing even begins.

With browser processing, work can start locally.

Better privacy

The media file can remain on the user’s machine.

For private recordings, internal work videos, family videos, interviews, or other sensitive material, that is useful.

Lower backend infrastructure requirements

Simple media jobs don’t necessarily need to consume server CPU, storage, queues, and bandwidth.

But there are tradeoffs

WebAssembly processing is not magically faster than native FFmpeg.

Large files can consume a lot of browser memory, and mobile devices can struggle with demanding workloads.

That is why Vidoro also has a server-side architecture for jobs where browser processing is not the right choice.

🧱 The Tech Stack

Vidoro currently uses:

Frontend

Next.js 16
React 19
TypeScript
Tailwind CSS
App Router

Browser Media Processing

FFmpeg
ffmpeg.wasm
WebAssembly

Backend

FastAPI
Celery
Redis
PostgreSQL

Server Media Processing

FFmpeg
ffprobe

Deployment

The frontend is designed to run independently from the backend.

Browser-local tools can work without sending media to the backend at all, while server-assisted features use the FastAPI/Celery pipeline.

⚙️ How the Server Compression Pipeline Works

For server-assisted compression, the architecture is roughly:

Video upload
→ FastAPI
→ storage
→ Celery task
→ FFmpeg
→ compressed result
→ download

Redis handles the task queue, while the backend and Celery worker share the same storage volume.

That last part sounds obvious, but it caused one of the bugs I ran into.

The backend successfully saved a file to:

/app/storage/uploads/...

but the worker had a different container filesystem and saw an empty directory.

The API worked.

The upload worked.

The Celery task started.

Then the worker reported:

Input file missing

The fix was to use a shared Docker volume between the backend and worker.

That was one of those bugs where every individual component looked healthy, but the full workflow still failed.

🧪 Things I Learned

A few lessons from building the project so far:

Browser FFmpeg is useful, but it has limits

For many everyday jobs, ffmpeg.wasm is genuinely useful.

For very large 4K videos or CPU-heavy transformations, native server-side FFmpeg is still much more capable.

“AI” works better when it solves a specific problem

I don’t want Vidoro to add a chatbot just because AI is popular.

The useful application here is helping users answer questions like:

What settings should I use?

or:

How do I make this small enough for email?

That is much more practical than adding a generic chat panel.

Output-size prediction is harder than it looks

You can’t simply say:

output = original × 0.2

Video content, existing bitrate, motion, codec, resolution, and CRF all matter.

A prediction that looks impressive but is consistently wrong is worse than a conservative estimate.

Privacy can be a product feature

Moving media processing into the browser is not only an implementation detail.

It changes the user experience.

“No upload required” is something users can actually understand.

Keep the interface simpler than FFmpeg

FFmpeg exposes hundreds of options.

That doesn’t mean an online tool should.

The job of the product is often to hide complexity rather than reproduce a command-line interface in a browser.

🚧 What I’m Working on Next

I’m continuing to expand Vidoro with more focused media tools.

I’m also experimenting with a more intelligent workflow where users can describe what they want instead of choosing technical parameters.

For example:

“Make this video small enough to email.”

or:

“Extract the audio from this MOV.”

or:

“Make this smaller but keep the text readable.”

The long-term idea is that Vidoro can understand the task, choose the appropriate tool, and configure it automatically.

Underneath, the actual media processing can still be handled by deterministic tools like FFmpeg.

The AI layer would help with intent and parameter selection rather than replace the media-processing engine.

🌍 Try Vidoro

Homepage:

👉 https://vidoro.io/

English Video Compressor:

👉 https://vidoro.io/compress-video-online/

Portuguese Video Compressor:

👉 https://vidoro.io/pt/comprimir-video-online/

MOV to MP3 Converter:

👉 https://vidoro.io/mov-to-mp3-converter/

I’m still actively improving the project, especially browser performance, compression quality, UX, and the balance between local and server-side processing.

I’d love feedback on:

the browser-first approach
ffmpeg.wasm performance
the compression workflow
privacy positioning
the smart compression idea
mobile usability
which media tool would be useful to build next

I Built a Portuguese Video Compressor for Brazil Users

高赫阳 — Fri, 07 Aug 2026 06:40:06 +0000

When I was building a video compression tool, I noticed something interesting.

Many online tools are created mainly for English-speaking users. They work worldwide, but users from other languages often don't get a localized experience.

Brazil is a good example.

Video sharing is very common in Brazil, especially through WhatsApp and social media. Many users need to reduce video size before sharing, but there are not many simple tools designed for Portuguese speakers.

So I created a Portuguese version of my video compressor:

https://vidoro.io/pt/compactar-video

The tool works directly in the browser, allowing users to compress videos without installing additional software.

🇧🇷 Versão em português

Enquanto desenvolvia uma ferramenta de compactação de vídeos, percebi uma oportunidade interessante.

Muitas ferramentas online são criadas principalmente para usuários de inglês. Elas funcionam globalmente, mas nem sempre oferecem uma boa experiência para pessoas que falam outros idiomas.

No Brasil, muitas pessoas compartilham vídeos pelo WhatsApp, redes sociais e outras plataformas. Porém, encontrar uma ferramenta simples de compactação de vídeo em português nem sempre é fácil.

Por isso, criei uma versão em português:

https://vidoro.io/pt/compactar-video

A ferramenta funciona diretamente no navegador e permite reduzir o tamanho dos vídeos sem precisar instalar programas.

No futuro, também pretendo lançar uma versão em espanhol, pois existe uma grande demanda de usuários que falam espanhol na América Latina e em outras regiões.

DEV Community: 高赫阳

Criei um compressor de vídeo online pensado para usuários em português

I Built Vidoro — A Browser-First Toolkit for Video Compression and Media Conversion

I Built a Portuguese Video Compressor for Brazil Users

The tool works directly in the browser, allowing users to compress videos without installing additional software.