A talking-head clip on a clean background is an easy extra to offer next to a small business site, and doing the background swap in the browser means no GPU server and no bandwidth bill for uploading someone's video. The part that costs money is the redo. So before offering it, I ran three CC0 clips from Wikimedia Commons through a browser-based video matting tool and read the output files the way a client's upload form or a picky editor would. The preview looking right told me very little. Everything below comes from the compatibility model, a solid white background, MP4 output, the default "Visually lossless · Recommended" quality and "Keep source audio" left on.
The first thing I check is whether the audio came back and in what form. It did on all four outputs, but none of them kept the original codec. A Vorbis track came out as AAC, an Opus track came out as AAC, and even an input that was already AAC was re-encoded: 160 kb/s went in, 173 kb/s came out, and the packet count changed from 372 to 375. That last one is a single sample, and it was a file I had converted myself with ffmpeg, so I wouldn't generalise from it. Sample rates were kept each time. The practical side for a client is simple. If they asked for the "original audio" and their editor checks codecs, it isn't the original stream any more, and the bitrate can go either way. The juggling clip's Opus went from 132 kb/s down to 94 kb/s AAC.
Sources: Wikimedia Commons CC0 "Tarun speaking 01", "Juggling with swing poi", "Folkloristic dance in Naples". Values read with ffmpeg.
Size is where I'd have got burned. On the three original Commons files, the output video bitrate stayed close to the source, between about 0.98× and 1.2×, and file sizes moved between −0.5% and +11%. That's what you'd hope for. Then I ran the same talking-head clip, but the H.264 copy I had made myself at 1487 kb/s, and the output came out at 2988 kb/s. The file went from 1.69 MB to 3.22 MB, roughly double, from the same clip. I don't know what the tool keys on to pick that bitrate, and with one sample I'm not going to guess. What I took away is cheaper than a theory: give it the file the client actually shot, not something you've already squeezed, and look at the output size before promising anything about upload limits.
The same goes for the size estimate in the export panel. It said 2.53 MB for the original talking-head clip and I got 3.42 MB. For the Naples street clip it said 1.90 MB and I got 1.55 MB. The juggling clip matched almost exactly at 606 KB. So it's in the right range and not something to quote. If a client's platform caps uploads at some number, I measure the real file.
Duration is the check that came out clean, with one footnote. Video duration matched the source within a millisecond on every clip, frame counts included. The audio track, though, runs 60 to 80 ms longer than the video in every MP4. When I decoded input and output audio with ffmpeg and lined them up by cross-correlation, the output was consistently late by 2112 samples, which is 47.89 ms at 44.1 kHz and 43.99 ms at 48 kHz, the same at every point I checked, so no drift. The source MP4 had an edit list and the output doesn't, which would fit an encoder delay that nothing compensates for. I have not checked whether a browser, a phone player or an editing app compensates on its own, and I haven't sat and watched lips against sound to see if anyone could notice. Right now it's an ffmpeg reading and nothing more. For a talking head I'd watch a few seconds of the final file in whatever the client uses before sending it.
One thing I only saw because I looked at the raw stream info: the MP4 carries metadata. The title tag reads the source filename plus the tool's name, and the comment says "Processed locally in the browser with ImgIng". Harmless for most jobs. But if the client is going to pass the video off as made in-house, they'd rather it didn't say where it came from, and I'd rather find that out before they do.
I don't have ffprobe installed on this machine, so the whole check was ffmpeg -hide_banner -i out.mp4, which prints the container, streams, bitrates and metadata and then complains that you didn't give it an output. The complaint is fine. Run it on the source and the output, compare codec, bitrate, duration and size, and open the file in the player the client will actually use.
The other two export quality settings, "High quality · Smaller" and "Balanced · Size first", I didn't try, so I can't say what they do to the size numbers above. That's the next thing I'd measure before quoting anyone a file size. The tool is at https://imging.ai/.
Top comments (0)