Why we upload the sound before the video

When you upload a video for dubbing, most of the file can be picture. But the first part of the dubbing process needs to hear what people are saying.

We were making that work wait for the whole video to arrive.

That was a reasonable place to start. One file goes up, one job begins, and everything it needs is there. It becomes less reasonable when the connection is slow and the audio could have arrived much earlier.

So we changed the upload. Where the file supports it, the browser copies out the sound and sends it separately. The dubbing work can begin while the video is still on its way.

Copying the sound, not recording it again

We didn't want this to become another expensive task before an upload could start. Re-encoding audio would add work on the device and introduce another version of the sound to check.

Instead, we use Mediabunny to copy the compressed audio into a suitable container. AAC goes into an M4A file; supported Opus and Vorbis tracks go into WebM. The audio is not re-encoded.

There is a small but important timing detail here. A video's first sound doesn't necessarily start at the same timestamp as its first picture. Extracting a track and moving its first sample to zero can lose that relationship. The extraction uses the video's timeline so the copied sound can line up with the picture later.

Not every file works with this path. The codec might not support copying, there might be no audio track, or extraction might take too long. Those are reasons to keep uploading the video normally, not reasons to reject someone's upload.

Two uploads, one job

Sending a smaller file first creates a coordination problem: the server must know that the sound and the video belong together.

Both uploads attach to the same job. If the server doesn't support the sound-first route, the browser falls back to the video path. It also checks the job identity rather than assuming that any successful response is safe to use.

The video is still needed. We can do the audio work early, but we can't produce the finished video without its picture. If the dubbed sound is ready first, the job waits for the video before that final assembly.

The example above is a timing model, not a benchmark. It assumes the same video-upload time in both paths and adds a separate sound-upload duration. Real uploads share bandwidth; extracting and uploading sound also have a cost. The useful question is how much work we can overlap, not whether every file gets a fixed speed increase.

The fallback matters as much as the faster path

If the video arrives before the sound is ready, we don't hold it up to preserve the optimization. We use the video.

If the connection drops while the page is still open, the upload code can wait and retry. That is different from promising that a phone will keep sending a large video after its browser has been closed. It won't always do that, and we shouldn't describe it as if it will.

This is a change to when work starts. It doesn't make translation instantaneous, and it doesn't remove the need to upload the video. It means the server can use the sound as soon as it has enough to begin, instead of waiting for the picture to catch up.